All I’m really hearing is that this guy rubs you the wrong way, so you’re not going to give him the benefit of the doubt that you’d give to others.
I mean, maybe you’re right that his personality will turn everyone off and none of this stuff will ever make it upstream. But that kind of seems like a problem you’re actively trying to create via your discourse.
Well, technically both WaitOnAddress and SRWLOCK use the same "wait/wake by thread ID" primitive. WaitOnAddress uses a hash table to store the thread ID to wake for an address, whereas SRWLOCK can just store that in the SRWLOCK itself (well, in an object on the waiter's stack, pointed to by the SRWLOCK).
> If you want to claim that a language is memory-unsafe, POC || GTFO.
There's a POC right in the post, demonstrating type confusion due to a torn read of a fat pointer. I think it could have just as easily been an out-of-bounds write via a torn read of a slice. I don't see how you can seriously call this memory safe, even by a conservative definition.
Did you mean POC against a real program? Is that your bar?
I guess if the arch’s varargs conventions do something other than put each 32-bit value in a 64-bit “slot” (likely for inputs that end up on the stack, at least), then some of the arguments will not line up. Probably some of the last args will get combined into high/low parts of a 64-bit register when moved into registers to pass to the kernel. And then subsequent register inputs will get garbage from the stack.
Need to cast them to long or size_t or whatever to prevent this.
Supposedly “ampersand” comes from when the alphabet song/rhyme used to end in “and ‘per se’ and”. School kids mushed it together into “ampersand”, and over time it became the name for &.
> As for animators having to find new work... good?
Isn’t this a paternalistic point of view? Why do you know better than the animators who are accepting these jobs? Who are you to tell them that their career choice is wrong?
I can’t agree. Combining alloc and free into one API is a false economy. You’re not really going to save any significant amount of space, and at best you’ll have an extra predictable branch or two (but probably unpredictable, I’d guess).
More importantly, it’s harder to interpret the calling code’s intent in the edge cases. What does alloc(NULL, 0) mean? Did the caller try to free a null pointer, or allocate a zero-byte object? With separate functions, you can support either or both or neither, but with the combined model the only safe thing is to support neither and panic, lest you interpret an alloc as a free or vice versa.
Although I’ll note that the line between a VMM and hypervisor are not always clear. E.g., KVM includes some things that other hypervisors delegate to the VMM (such as instruction completion). And macOS’s hypervisor.framework is almost a pass through to the CPU’s raw capabilities.
I think Spintronics resistors will resist motion with a force proportional to rotational speed, which I think follows from the resistance coming from oil in the bearings. So the torque will be the same for both resistors (since the battery applies constant torque), but the speed at which the resistors apply this torque will be different by a factor of two.
Yes. But user space can take dependencies on features we didn’t implement yet or we implemented incorrectly or that have bugs in combinations with other features. E.g., more software is starting to depend on namespace features that we implemented incompletely in earlier versions of WSL1. So Docker worked for a while until they starting using a different subset of kernel features, for example.
At another point, glibc started depending on more precise behavior of CLONE_VFORK, which we originally didn’t implement fully. So essentially all of user space was broken. We fixed it as soon as we could, but I think glibc may have added a workaround, too. I feel bad that the community had to work around our bugs.
We work very closely across the file system, kernel, and virtualization teams, so I don’t think we can blame Conway’s Law for WSL2. And actually our WSL1 fork performance wasn’t too bad IIRC—we have real fork at the Windows kernel level, it’s just not something that can realistically work with the Win32 programming model. I also think we will eventually resolve the file system performance issues.
No, the most important reason to choose a VM instead of a reimplementation of the Linux ABI is long tail compatibility. You can’t realistically replicate and then keep up with every corner of the Linux kernel’s interface. And so with WSL1, software will randomly not work, or it will randomly break after an apt upgrade, and users will get frustrated and switch to a VM anyway. Might as well get perfect compatibility and still have nice integration with Windows via the WSL2 approach.
I mean, maybe you’re right that his personality will turn everyone off and none of this stuff will ever make it upstream. But that kind of seems like a problem you’re actively trying to create via your discourse.