Re:Rustproofing Linux (Part 1/4 Leaking Addresses) (2023)
by itishappy on Tuesday August 27, 2024 @07:27PM
(#41374382)
Why have any? Zero errors is trivially achievable by not writing code.
Re:Rustproofing Linux (Part 1/4 Leaking Addresses) (2023)
by dartos on Tuesday August 27, 2024 @09:53PM
(#41375222)
What if not writing code is an error in and of itself?
Re:Rustproofing Linux (Part 1/4 Leaking Addresses) (2023)
by bravetraveler on Thursday August 29, 2024 @08:15AM
(#41390006)
If it's worth doing it's already done
Re:Rustproofing Linux (Part 1/4 Leaking Addresses) (2023)
by oneshtein on Wednesday August 28, 2024 @03:35AM
(#41376946)
It's true, /bin/true.
Re:Rustproofing Linux (Part 1/4 Leaking Addresses) (2023)
by stouset on Tuesday August 27, 2024 @06:36PM
(#41373980)
Why try to improve anything when you could just keep the original implementation around for forever?
Re:Rustproofing Linux (Part 1/4 Leaking Addresses) (2023)
by throwawaymaths on Tuesday August 27, 2024 @08:28PM
(#41374805)
As they say, if it ain't broke, don't fix it
Re:Rustproofing Linux (Part 1/4 Leaking Addresses) (2023)
by stouset on Tuesday August 27, 2024 @10:20PM
(#41375379)
The evidence that C is broke is pretty overwhelming at this point.
Re:Rustproofing Linux (Part 1/4 Leaking Addresses) (2023)
by atoav on Wednesday August 28, 2024 @06:20AM
(#41377943)
For varying definitions of "not broke".
Thinking about my uncle, running Windows 97 in his company.
Re:Rustproofing Linux (Part 1/4 Leaking Addresses) (2023)
by akira2501 on Wednesday August 28, 2024 @05:21AM
(#41377628)
The El Camino was supposed to be an improvement. A combination between a car and a truck. It turns out it was not an improvement. It's better to just have a car or a truck. Cutting them in half and then weirdly stitching the two parts together creates a Frankenstein nightmare of bad engineering. Which even the best explanations on the planet can't fix.
Re:Rustproofing Linux (Part 1/4 Leaking Addresses) (2023)
by Wowfunhappy on Wednesday August 28, 2024 @06:57AM
(#41378169)
^ If I can try to steel man this, it may be that having two different languages is simply worse than having one, even if the one language is non-optimal. Sure, if you were starting Linux today you wouldn't choose C, and hopefully Linux won't be the last operating system to ever exist, and the next one can use Rust. But Linux uses C, and no one is contemplating a full rewrite, so it's best to stick with C.
I have no idea if this is true, I am very much not a kernel developer.
Why have one class of logic errors when you can have two?