5 ms·

People thinking that using a superior tool (on paper) enables them to automatically write better tools than the ones who are battle tested over the years baffle

People thinking that using a superior tool (on paper) enables them to automatically write better tools than the ones who are battle tested over the years baffles me to no end. Yes, you can go further, possibly faster. OTOH, nothing replaces experience and in-depth knowledge. GNU Coreutils embodies that knowledge and experience. uutils has none, and just tries to distill it with tests against the GNU one. ...and they get 44 CVEs as a result in their first test.

hombre_fatal 6mo ago
There was an article posted to HN recently that enumerated bugs in the rust rewrite. Iirc the bugs had to do with linux system details like fs toctou and other things you'd only find out about in production. Ideally we'd have a better way of navigating platform idiosyncrasies or better system APIs, so that every project doesn't have to relearn them at runtime. But the rewrite isn't pure downside.
- bayindirh 6mo ago
  I'm personally not against Rust rewrites in principle. But doing them in this drive-by hostile manner, esp. with non-GNU licenses smells "hostile takeover" for me, and dismantling core free software utilities is not nice in general. > Ideally we'd have a better way of navigating platform idiosyncrasies or better system APIs I believe trying to make something idiot-proof just generates better idiots, so I prefer having thinner abstractions on the lower level for maintenance, simplicity and performance reasons. The real solution is better documentation, but who values good documentation? Graybeards and their apprentices, mostly from my experience. I personally still live with reference docs rather than AI prompts, and it serves me well.
pdimitar 6mo ago
My read on those was basically that the classic filesystems are hopelessly broken and we need ACID guarantees in the next-gen filesystems, like 20 years ago. Not saying all of them were about FS TOCTOU bugs but once I got to these, that was my takeaway. Obviously just using Rust cannot fix _all_ bugs, and I reject any criticisms towards Rust rewrites that tear down this particular straw man (its goal being to make it impossible to argue against). That's toxic and I get surprised every time people on HN try to argue in that childish way. But if we can remove all C memory safety foot guns then that by itself is worth a lot already. Losing decades-old knowledge on how the dysfunctional lower-level systems work would be regrettable and even near-fatal for any such projects. That I'd agree with. But it also raises the question on whether those lower-level systems don't need a very hard long look and -- eventually -- a replacement.
- LtWorf 6mo ago
  But removing all the memory footguns while introducing hundreds of syscalls footguns where rust won't help you at all might not be better at all,
  - pdimitar 6mo ago
    I agree, absolutely. Hence my adjacent thought that maybe all this should just be thrown away and we should invent an FS with ACID semantics. I'm all for gradual improvements but at one point and on we should zoom even further out and pick our battles well.
    - overfeed 6mo ago
      > maybe all this should just be thrown away and we should invent an FS with ACID semantics. You're describing WinFS, which looked into and ultimately abandoned Microsoft 20 years ago. I'm sure other groups have looked into this as well, but there's no such thing as free lunch. > I'm all for gradual improvements but at one point and on we should zoom even further out and pick our battles well. That sounds a lot like picking up more battles, yet we all still have 24 hours a day. Recursively trying to perfect lower layers will have you like Hal changing the lightbulb https://youtu.be/AbSehcT19u0 https://youtu.be/AbSehcT19u0
      - pdimitar 6mo ago
        Well, recursively trying to perfect lower layers is what I am advocating for us to not do. As a guy who prefers to stop and think before coding, to me a lot of the older UNIX / GNU primitives seem broken (like the env vars process inheriting discussion that was here a while ago) and should be completely rethought. I also think people overreact and believe "everything will break". And we have libraries and runtimes that only implement small parts of libc and the deployed apps that use them are running mostly fine for years. My broader point was: shall we not start breaking away from all this legacy? Must we always rely on corporations to lead the charge? But yes, I do of course agree with the only 24h a day thing. And likely nobody would want to pay for such a trail-blazing work anyway. Sad world.

hombre_fatal 6mo ago

There was an article posted to HN recently that enumerated bugs in the rust rewrite. Iirc the bugs had to do with linux system details like fs toctou and other things you'd only find out about in production. Ideally we'd have a better way of navigating platform idiosyncrasies or better system APIs, so that every project doesn't have to relearn them at runtime. But the rewrite isn't pure downside.

bayindirh 6mo ago
I'm personally not against Rust rewrites in principle. But doing them in this drive-by hostile manner, esp. with non-GNU licenses smells "hostile takeover" for me, and dismantling core free software utilities is not nice in general. > Ideally we'd have a better way of navigating platform idiosyncrasies or better system APIs I believe trying to make something idiot-proof just generates better idiots, so I prefer having thinner abstractions on the lower level for maintenance, simplicity and performance reasons. The real solution is better documentation, but who values good documentation? Graybeards and their apprentices, mostly from my experience. I personally still live with reference docs rather than AI prompts, and it serves me well.

pdimitar 6mo ago

My read on those was basically that the classic filesystems are hopelessly broken and we need ACID guarantees in the next-gen filesystems, like 20 years ago. Not saying all of them were about FS TOCTOU bugs but once I got to these, that was my takeaway. Obviously just using Rust cannot fix _all_ bugs, and I reject any criticisms towards Rust rewrites that tear down this particular straw man (its goal being to make it impossible to argue against). That's toxic and I get surprised every time people on HN try to argue in that childish way. But if we can remove all C memory safety foot guns then that by itself is worth a lot already. Losing decades-old knowledge on how the dysfunctional lower-level systems work would be regrettable and even near-fatal for any such projects. That I'd agree with. But it also raises the question on whether those lower-level systems don't need a very hard long look and -- eventually -- a replacement.

LtWorf 6mo ago
But removing all the memory footguns while introducing hundreds of syscalls footguns where rust won't help you at all might not be better at all,
- pdimitar 6mo ago
  I agree, absolutely. Hence my adjacent thought that maybe all this should just be thrown away and we should invent an FS with ACID semantics. I'm all for gradual improvements but at one point and on we should zoom even further out and pick our battles well.
  - overfeed 6mo ago
    > maybe all this should just be thrown away and we should invent an FS with ACID semantics. You're describing WinFS, which looked into and ultimately abandoned Microsoft 20 years ago. I'm sure other groups have looked into this as well, but there's no such thing as free lunch. > I'm all for gradual improvements but at one point and on we should zoom even further out and pick our battles well. That sounds a lot like picking up more battles, yet we all still have 24 hours a day. Recursively trying to perfect lower layers will have you like Hal changing the lightbulb https://youtu.be/AbSehcT19u0 https://youtu.be/AbSehcT19u0
    - pdimitar 6mo ago
      Well, recursively trying to perfect lower layers is what I am advocating for us to not do. As a guy who prefers to stop and think before coding, to me a lot of the older UNIX / GNU primitives seem broken (like the env vars process inheriting discussion that was here a while ago) and should be completely rethought. I also think people overreact and believe "everything will break". And we have libraries and runtimes that only implement small parts of libc and the deployed apps that use them are running mostly fine for years. My broader point was: shall we not start breaking away from all this legacy? Must we always rely on corporations to lead the charge? But yes, I do of course agree with the only 24h a day thing. And likely nobody would want to pay for such a trail-blazing work anyway. Sad world.