newpavlov

10 ms·

91.
by newpavlov 2y ago
>Changing C interfaces will often have implications for the Rust code and may break it; somebody will the have to fix the problems. Torvalds said that, for now, breaking the Rust code is permissible, but that will change at some point in
92.
by newpavlov 2y ago
You forgot about the third option: specify "stable" and properly documented API boundaries in relevant subsystems. Developers of Rust drivers would have to rely only on those APIs, in turn, if subsystem maintainers want to change
93.
by newpavlov 2y ago
Types usually describe values. Compilers use types to prove various things about possible values, like their size, alignment, valid bit patterns, etc. Effects describe code. For example, a "panic" effect states that function may t
94.
by newpavlov 2y ago
I think truncating packets would make live of application developers significantly harder since it breaks the nice atomic property and requires development of ad-hoc feedback protocols which account for potentially truncated packets. Smalle
95.
by newpavlov 2y ago
Yes, you are right. I completely forgot about ICMP Packet Too Big messages since they are effectively not used in practice for application-level stuff. One minor difference between it and the behavior desired by me is that the error packet
96.
by newpavlov 2y ago
I think IP has two main issues: fragmentation and TCP. Possibility of fragmentation means that we can not rely on "atomicity" of IP packets. We have to limit ourselves to conservative MTU sizes if we want reasonable performance on
97.
by newpavlov 2y ago
>one which tips the scales of everything at every level towards a specific outcome According to the SD, this is nothing more than an artifact of splitting an entagled system into an "observer" and an "observed" parts.
98.
by newpavlov 2y ago
It's not a some sort of particle conspiracy. The idea is not so different from the Laplace's demon. We have an initial state of the Universe at the moment of Big Bang (a PRNG seed, if you will) and a set of differential equations
99.
by newpavlov 2y ago
It's no different from any other interpretation .
100.
by newpavlov 2y ago
I would say it differently. Suprdeterminism opposes to the deeply ingrained assumption that we can design experiments in a way which removes influence of a measurement apparatus (including experementators themselves) on the measured process
101.
by newpavlov 2y ago
There is a very important and often forgotten caveat to the Bell's inequalities: it covers local hidden states. If we are to assume that measurement and particle creation apparatuses are entangled with each other (after all, they had
102.
by newpavlov 2y ago
There is also a middle ground of requiring to pad 16/48-bit sequences with 16-bit NOP to align them to 32 bits. I agree that at this time it's not clear whether the C extension is a good idea or not (same with the V extension).
103.
by newpavlov 2y ago
Another argument against the C extension is that it uses a big chunk of the opcode space, which may be better used for other extensions with 32-bit instructions.
104.
by newpavlov 2y ago
The handling of misaligned loads/stores in RISC-V is also can be considered a disappointing point: https://github.com/riscv/riscv-isa-manual/issues/1611 It oozes with preferring convenience of hardware d
105.
by newpavlov 2y ago
Are you talking about the Hawking-Penrose theorems? Have you read the Kerr paper?
106.
by newpavlov 2y ago
>The simplest way to see this is to realize that Kerr's statement that if a theory predicts singularities, the theory is wrong, is something that virtually all physicists who work in GR agree with! Maybe it was my misfortune, but th
107.
by newpavlov 2y ago
A very simplified idea is that the denser you get, the slower time flows (for an "outside" observer). So while for an "inner" observer density rises "fast" to the point of singularity, for an "outside&quot
108.
by newpavlov 2y ago
Plenty of physicists are still "resistant" to the idea of black holes having a real singularity. The recent Kerr paper [0] only adds fuel to this resistance with its hilarious statement "Faith, not science!" about singul
109.
by newpavlov 2y ago
For a more in-depth understanding, I recommend reading "Rust Atomics and Locks": https://marabos.nl/atomics/ It uses Rust for examples, but it more or less applicable to C/C++ as well.
110.
by newpavlov 2y ago
Yeah, the whole blog post reads like "if you worked too much with a hammer, everything starts looking like a nail". In other words, it puts the cart before the horse. Effects is a MUCH more general and powerful technique than coro
111.
by newpavlov 3y ago
sshd should not have used libsystemd in the first place for the trivial notification. And the ifunc stuff is its own security nightmare. Papering over this by dlopen-ing some libs in libsystemd does not address the deeper issues.
112.
by newpavlov 3y ago
Lack of stable syscall ABI is what stops me. It can be only done by OS developers.
113.
by newpavlov 3y ago
I do not dispute that it made sense during early days of UNIX. But today we write system software for these operating systems in many languages other than C. Maybe it's time to reconsider the dominant libc position instead of reinforci
114.
by newpavlov 3y ago
In this particular case, I think it's distros who make life hard for themselves by trying to force a square peg into a round hole. Cargo supports vendoring quite well, so, in my opinion, distros should simply vendor all dependencies of
115.
by newpavlov 3y ago
Honestly, I think that making libc THE system interface is a mistake. Ok, I understand issues with the Linux approach of exposing raw syscalls (though it works well enough in practice and ossification could be amended by some kind of syscal
116.
by newpavlov 3y ago
Sigh... It gets tiring to hear about embedded from async/await advocates as if it's a unique advantage of the model. Fibers and similar mechanisms are used routinely in embedded world as demonstrated by various RTOSes. Fibers are
117.
by newpavlov 3y ago
Yes, it's what I wrote about in the last paragraph. If you can compute maximum stack size of a function, then you can avoid dynamic allocation with fibers as well (you also could provide stack size manually, but it would break horribly
118.
by newpavlov 3y ago
https://github.com/Xudong-Huang/may The project has some serious restrictions and unsound footguns (e.g. around TLS), but otherwise it's usable enough. There are also a number of C/C++ libraries, but I can no
119.
by newpavlov 3y ago
In my opinion, by default fibers should use "full" stacks, i.e. a reasonable amount of unpopulated memory pages (e.g. 2 MiB) with guard page. Effectively, the same stack which we use for threads. It should eliminate all issues abo
120.
by newpavlov 3y ago
Fibers and async/await are backed by the same OS APIs, they can achieve more or less the same latency. The main advantage of async/await (or to be more precise stackless coroutines) is that they require less memory for task stacks

More ›