251–260 of 282 posts
Earlier quoted context omitted.
Given that Ubuntu uses systemd like the vast majority of Linux systems nowadays, how does sudo-rs differ from run0?
You might not have a systemd instance inside a container, but you still might want to switch user IDs there.
Earlier quoted context omitted.
Given that Ubuntu uses systemd like the vast majority of Linux systems nowadays, how does sudo-rs differ from run0?
sudo-rs doesn’t gratuitously require a root privilege daemon that regularly ships filesystem destruction and remote unauthenticated arbitrary code execution bugs. If your bar is “I’ll tolerate such crap”, you may as well run your desktop session as root.
Earlier quoted context omitted.
A trivial Google search answers that. run0 requires systemd-type OS.
Given that Ubuntu uses systemd like the vast majority of Linux systems nowadays, how does sudo-rs differ from run0?
He was comparing to "normal" sudo, but sudo-rs have the same problems he highlighted anyway
How does sudo-rs compare to run0? https://news.ycombinator.com/item?id=40205714
This one is easy: run0 is not implemented in a memory-safe language, but in C. It is likely to be hit by exploitable memory-handling bugs, like the rest of systemd, as has happened multiple times before.
Earlier quoted context omitted.
This one is easy: run0 is not implemented in a memory-safe language, but in C. It is likely to be hit by exploitable memory-handling bugs, like the rest of systemd, as has happened multiple times before.
An already existing and tested C software gonna have less bugs than a new rust rewrite
It’s not that simple.
Earlier quoted context omitted.
This one is easy: run0 is not implemented in a memory-safe language, but in C. It is likely to be hit by exploitable memory-handling bugs, like the rest of systemd, as has happened multiple times before.
An already existing and tested C software gonna have less bugs than a new rust rewrite
And if we're talking about memory bugs (which we were up to now), then definitely no.
But run0 is new C code anyway so I don't see how your claim is relevant.
Earlier quoted context omitted.
> That all said, Rust is not a smoking gun for incorrect application logic. It could still happily incorrectly execute stuff with the wrong permissions or blow something up badly. This side steps the issue which is "Does Rust help you make software more correct?" No one is arguing that Rust is perfect. There are plenty of bugs in my Rust software. The question is only -- are we better off with Rust than the alternati…
> This side steps the issue which is "Does Rust help you make software more correct?" No one is arguing that Rust is perfect. There are plenty of bugs in my Rust software. The question is only -- are we better off with Rust than the alternatives? There is a lot of embedded knowledge in existing implementations, Rust deals with just one small class of bugs but drops a lot of this knowledge in the process. I would gene…
Agree. The question whether to rewrite and/or whether to use any new implementation should take this fact into account.
> Rust deals with just one small class of bugs but drops a lot of this knowledge in the process.
Hard disagree. Rust explicitly deals with several very important classes of bugs (memory safety and concurrency), and also aids correctness via other helpful design features like tagged unions and immutability by default. But Rust, the language, does not drop any knowledge in the process, though any decision to rewrite in any language may drop some knowledge, and/or may create new bugs, in the process.
> I would generally be in favour of just introducing better memory management to C/C++ and hard enforcing it in particular repositories.
This is really easy to say, but in practice it just hasn't worked out, and there is loads of empirical evidence to back that up.[0] It is not as if market incentives don't exist to create better C/C++ code.[1] If you have a way to do it better, I have no doubt Google, half a dozen other hyper-scalers, and the US government will pay you handsomely for your solution. But, at this point in time, if this is the solution, I'm afraid it's time to put up or shut up.
[0]: https://www.usenix.org/conference/enigma2021/presentation/ga... [1]: https://www.darpa.mil/research/programs/translating-all-c-to...
Earlier quoted context omitted.
>> ... I believe that there are many reasons why Linus chose to give Rust for Linux a chance. I believe at least one of those reasons is mindshare. If Linux chose not to experiment with Rust drivers, then that mindshare might go somewhere else. Again, very sorry you misunderstood me. However, I am now pretty certain one of your difficulties is that you stop short of reading my next sentence, and then my next sentence…
Now, why would Linux want to lay claim to being 'the Rust kernel' and how is that different than Linux being rewritten in Rust Drop the "mischaracterising" routine. You're asserting specific things, so expect to get challenged when they're nonsense.
If I said "Coca Cola wants to lay claim to being the best cola soda in the world", I'm sure you would also say to me: "Patently untrue. Where exactly in Coca Cola's public statements are we to find that statement?!", instead of, perhaps reflecting, and asking yourself -- is that a reasonable belief for one to hold, given Coca Cola's marketing?
If I am not conforming to your expectations, perhaps it is because your expectations that need a reset.
Earlier quoted context omitted.
Why does it matter, really? I mean sure, ada could've been an alternative language that everyone pushed for using but it kind of missed the boat due to historical circumstances , the context around its early use, etc. It might even be that rust users are just more enthusiastic and have been able to push more... But so what? But why does it matter if the language that has seen some traction in terms of "rewriting soft…
This sounds like a dismissal. It is worth getting rid of the misunderstandings of Ada. It is worth letting people know that safe alternatives to C do exist and have existed long before Rust. You said it yourself that the issue may have been historical circumstances, in which case it should be clarified. Ada has a lot of great things built-in to the language. I especially love its type system and constructs for concur…
Earlier quoted context omitted.
> This side steps the issue which is "Does Rust help you make software more correct?" No one is arguing that Rust is perfect. There are plenty of bugs in my Rust software. The question is only -- are we better off with Rust than the alternatives? There is a lot of embedded knowledge in existing implementations, Rust deals with just one small class of bugs but drops a lot of this knowledge in the process. I would gene…
> There is a lot of embedded knowledge in existing implementations, Agree. The question whether to rewrite and/or whether to use any new implementation should take this fact into account. > Rust deals with just one small class of bugs but drops a lot of this knowledge in the process. Hard disagree. Rust explicitly deals with several very important classes of bugs (memory safety and concurrency), and also aids correct…
It really wasn't too difficult to get high reliability for memory management in C/C++ which is also concurrency safe (I have active projects running for years like this). The difficulty was enforcing it so that you are reduced to a subset of the language and it has to be followed with discovery at compile time.
The trap I'm concerned we are falling into is the "just re-write the C/C++ project in Rust". I still believe the solution is in enforcing better practices at compile time.