Hacker News: jstarks

New comment by jstarks in "Linux Sandboxes and Fil-C"

jstarks — Mon, 15 Dec 2025 01:20:55 +0000

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.

New comment by jstarks in "Without the futex, it's futile"

jstarks — Tue, 19 Aug 2025 19:31:05 +0000

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).

New comment by jstarks in "There is no memory safety without thread safety"

jstarks — Thu, 24 Jul 2025 17:32:15 +0000

> 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?

New comment by jstarks in "Let's Learn x86-64 Assembly (2020)"

jstarks — Mon, 14 Jul 2025 15:17:02 +0000

What about ROL r/m16, 8?

New comment by jstarks in "Linux Syscall Support"

jstarks — Thu, 07 Nov 2024 16:22:09 +0000

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.

New comment by jstarks in "The C23 edition of Modern C"

jstarks — Wed, 16 Oct 2024 15:11:48 +0000

No inline functions in library headers, then.

New comment by jstarks in "Microsoft Open Sources OpenHCL, a Linux-Based 'Paravisor'"

jstarks — Tue, 24 Sep 2024 19:57:18 +0000

Despite the title, it's not actually open source yet. Soon!

New comment by jstarks in "QUIC is not quick enough over fast internet"

jstarks — Mon, 09 Sep 2024 15:03:06 +0000

Your NIC can already access arbitrary RAM via DMA. It can read your keys already.

New comment by jstarks in "Jiff: Datetime library for Rust"

jstarks — Mon, 22 Jul 2024 08:38:44 +0000

I think the MPL attempts to be that license.

New comment by jstarks in "Do you still count on your fingers?"

jstarks — Sun, 16 Jun 2024 23:28:27 +0000

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 &.

New comment by jstarks in "AI in software engineering at Google: Progress and the path ahead"

jstarks — Fri, 07 Jun 2024 01:54:39 +0000

Do you find this problematic?

New comment by jstarks in "Anime is a $25B industry that pays its animators pennies"

jstarks — Sun, 21 Jan 2024 03:29:00 +0000

> 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?

New comment by jstarks in "So you want custom allocator support in your C library"

jstarks — Mon, 18 Dec 2023 04:53:12 +0000

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.

New comment by jstarks in "Coding4Fun Hardware Boneyard – Using the CueCat with .NET (2006)"

jstarks — Tue, 05 Dec 2023 05:07:25 +0000

You could also just cut a trace on the motherboard and it would type out the UPC codes unencoded.

New comment by jstarks in "We replaced Firecracker with QEMU"

jstarks — Mon, 10 Jul 2023 14:58:16 +0000

Keep fighting the good fight, friend.

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.

New comment by jstarks in "Cargo-semver-checks: Scan your Rust crate for semver violations"

jstarks — Sun, 09 Jul 2023 10:45:49 +0000

If looking at types is the least useful way to enforce versioning, then what are _any_ better ways?

New comment by jstarks in "Mechanical circuits: electronics without electricity [video]"

jstarks — Tue, 03 Jan 2023 05:42:52 +0000

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.

New comment by jstarks in "Windows is the strangest, or hardest, operating system to keep curl support for"

jstarks — Wed, 30 Nov 2022 14:17:21 +0000

NT4 already had the graphics stack in kernel mode.

New comment by jstarks in "macOS Subsystem for Linux"

jstarks — Mon, 19 Sep 2022 14:33:23 +0000

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.

New comment by jstarks in "macOS Subsystem for Linux"

jstarks — Mon, 19 Sep 2022 12:07:11 +0000

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.