Live data from Hacker News

Memory-safe sudo to become the default in Ubuntu

trifectatech.org

241–250 of 282 posts

Re: Memory-safe sudo to become the default in Ubuntu

#242
post #209

Earlier quoted context omitted.

Linux wants to lay claim to "the Rust kernel" Entirely untrue. It may happen, but there is zero consensus to port Linux to rust. Not even the tiniest bit.

> Entirely untrue. It may happen, but there is zero consensus to port Linux to rust. Not even the tiniest bit. ... But I did not say there was a consensus to port Linux to Rust? I'm sorry you misunderstood. Now, why would Linux want to lay claim to being 'the Rust kernel' and how is that different than Linux being rewritten in Rust? I believe that there are many reasons why Linus chose to give Rust for Linux a chance…

Now, why would Linux want to lay claim to being 'the Rust kernel' and how is that different than Linux being rewritten in Rust?

This isn't a thing. Linux isn't laying claim to any such assertion.

If you want to know Linus's reasons, then read the LKML. He's quite open in all of his thoughts in this regard, and it has nothing to do with labeling Linux 'the Rust kernel'.

I don't know if this is some weird sort of advocacy, or you're just listening to a lot of over the top rust people, but nothing you're saying here is real.

Re: Memory-safe sudo to become the default in Ubuntu

#243
post #242

Earlier quoted context omitted.

> Entirely untrue. It may happen, but there is zero consensus to port Linux to rust. Not even the tiniest bit. ... But I did not say there was a consensus to port Linux to Rust? I'm sorry you misunderstood. Now, why would Linux want to lay claim to being 'the Rust kernel' and how is that different than Linux being rewritten in Rust? I believe that there are many reasons why Linus chose to give Rust for Linux a chance…

Now, why would Linux want to lay claim to being 'the Rust kernel' and how is that different than Linux being rewritten in Rust? This isn't a thing. Linux isn't laying claim to any such assertion. If you want to know Linus's reasons, then read the LKML. He's quite open in all of his thoughts in this regard, and it has nothing to do with labeling Linux 'the Rust kernel'. I don't know if this is some weird sort of advoc…

>> ... 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 after that. See my quoted comments above. I made very clear these are strictly my beliefs.

> If you want to know Linus's reasons, the read the LKML.

Perhaps when I said "I believe" I was being too subtle about what "my beliefs" are or what "beliefs" mean.

I hope you would agree -- just because one has expressed certain technical reasons/desires does not mean that there were not any unexpressed social reasons/desires, or what philosophers also call "higher order volitions" (long term volitions, or volitions about volitions), for one's actions.

Now -- I do not know but I do believe there may be social reasons for Rust being adopted in the Linux kernel, because I have read the LKML and I have reasoned about why Linux is experimenting with Rust drivers from things Linus and others have said.

Feel free to disagree, of course, but, in the future, please make more of an effort to avoid mischaracterizing me again.

Re: Memory-safe sudo to become the default in Ubuntu

#244
post #183
post #121

> This move is part of a broader effort by Canonical to improve the resilience and maintainability of core system components. Sudo-rs is developed by the Trifecta Tech Foundation (TTF), a nonprofit organization that creates secure, open source building blocks for infrastructure software. Ubuntu continuously updates itself without permission, killing apps and losing previous state. You have the Javascript based Gnome…

> Ubuntu continuously updates itself without permission... It does default to installing security updates automatically. However, this is completely configurable. It isn't reasonable to have different default behaviour - otherwise the majority of users would be vulnerable from a security perspective. If you want different behaviour, just configure it as you wish. > The Ubuntu packages, drivers and kernel are laughabl…

> It isn't reasonable to have different default behaviour - otherwise the majority of users would be vulnerable from a security perspective.

A better default behaviour would be to alert the user and allow them to choose to indefinitely defer by "accepting the risk". Some setups, rightfully or wrongfully, have a very long running time and cannot be restarted.

> If you want different behaviour, just configure it as you wish.

I'm not sure if it changed, but they made it extremely difficult on purpose. You can stop snap from updating, but then lots of other things also break.

> This just isn't a reasonable description of reality.

It's my experience with packages I use.

Re: Memory-safe sudo to become the default in Ubuntu

#245
post #183

Earlier quoted context omitted.

> Ubuntu continuously updates itself without permission... It does default to installing security updates automatically. However, this is completely configurable. It isn't reasonable to have different default behaviour - otherwise the majority of users would be vulnerable from a security perspective. If you want different behaviour, just configure it as you wish. > The Ubuntu packages, drivers and kernel are laughabl…

> It does default to installing security updates automatically. However, this is completely configurable. Man, but have you personally tried to disable it? Did you stop apt-daily.service apt-daily.time apt-daily-upgrade.service and apt-daily.timer? Did you repeat the same but masking and disabling those services. Don't forget to repeat that for unatended-upgrades.service. Even after that whenever our CI fails an apt-…

Their answer will be "just make your server robust to restarts bro", not really understanding the fact that some stuff simply cannot be restarted. We have Ubuntu desktop running a robot arm (not our choice of OS, but the manufacturer). Mid-operation snap decides to kill the robot that would otherwise be happy operating away and sending stats to the cloud.

I'm personally moving to Debian. It's 99% how Ubuntu used to be and most Ubuntu stuff is just a .deb that is relatively compatible.

Re: Memory-safe sudo to become the default in Ubuntu

#246
post #121

> This move is part of a broader effort by Canonical to improve the resilience and maintainability of core system components. Sudo-rs is developed by the Trifecta Tech Foundation (TTF), a nonprofit organization that creates secure, open source building blocks for infrastructure software. Ubuntu continuously updates itself without permission, killing apps and losing previous state. You have the Javascript based Gnome…

> 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 generally be in favour of just introducing better memory management to C/C++ and hard enforcing it in particular repositories.

Re: Memory-safe sudo to become the default in Ubuntu

#247
post #183

Earlier quoted context omitted.

> Ubuntu continuously updates itself without permission... It does default to installing security updates automatically. However, this is completely configurable. It isn't reasonable to have different default behaviour - otherwise the majority of users would be vulnerable from a security perspective. If you want different behaviour, just configure it as you wish. > The Ubuntu packages, drivers and kernel are laughabl…

> It does default to installing security updates automatically. However, this is completely configurable. Man, but have you personally tried to disable it? Did you stop apt-daily.service apt-daily.time apt-daily-upgrade.service and apt-daily.timer? Did you repeat the same but masking and disabling those services. Don't forget to repeat that for unatended-upgrades.service. Even after that whenever our CI fails an apt-…

> Man, but have you personally tried to disable it?

Sure. It's just a one line change in the configuration file (/etc/apt/apt.conf.d/50unattended-upgrades). Or, if you're doing a mass deployment, just don't install the unattended-upgrades package.

> figure out what other dark pattern canonical came up with

The mechanism is inherited from Debian. It isn't Canonical's architecture.

If you want to hack internals to do things in a more complicated way, then that's up to you, but you can't then complain that it's unnecessarily complicated.

Re: Memory-safe sudo to become the default in Ubuntu

#248
post #244
post #183

Earlier quoted context omitted.

> Ubuntu continuously updates itself without permission... It does default to installing security updates automatically. However, this is completely configurable. It isn't reasonable to have different default behaviour - otherwise the majority of users would be vulnerable from a security perspective. If you want different behaviour, just configure it as you wish. > The Ubuntu packages, drivers and kernel are laughabl…

> It isn't reasonable to have different default behaviour - otherwise the majority of users would be vulnerable from a security perspective. A better default behaviour would be to alert the user and allow them to choose to indefinitely defer by "accepting the risk". Some setups, rightfully or wrongfully, have a very long running time and cannot be restarted. > If you want different behaviour, just configure it as you…

> A better default behaviour would be to alert the user and allow them to choose to indefinitely defer by "accepting the risk".

That would be terrible UX and is exactly contrary to Ubuntu's philosophy, which is to do the right thing by default.

The alternative is to bombard the user with questions that they're generally not in a position to understand, and force them to receive an education on stuff that doesn't matter to most users before they can use their computer.

Re: Memory-safe sudo to become the default in Ubuntu

#249
post #191

Earlier quoted context omitted.

> which is not some proof from god or anything that you seem to be seeking You know what, you or anyone else can start with actual proofs. I don't want your lived experience and memes as proof, I need messages, posts from people (bonus points for sudo-rs members) that show how zealous they are about Rust and rewriting all the things in it. I'm a Java dev, that just dabbles in Rust. I've seen observed many claims abou…

https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que... Have fun. (I'm sure if I pick any specific quotes, you'll start arguing the semantics of what is "zealous", how whatever number of comments I pick are outliers, or not proof enough, etc. So, here's one query, of many, that you can pick through.) In the end, I really could not care less if you agree with the characterization or not. But your enthusiastic…

Fine let's dig in: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que... I'm analyzing the first page

First, a simple grading system: 0 - No RIIR sentiment 1- Joking or 2 - Mentioning Rust in positive light 3 - Suggesting Rust positive light for project 4 - Asking for RIIR, saying stuff like this wouldn't happen in Rust 5 - Demanding RIIR

    |     |                                               | RIIR grade (0 -> 5) | Notes                                                       |
    | --- | --------------------------------------------- | ------------------- | ----------------------------------------------------------- |
    | 1   | https://news.ycombinator.com/item?id=43912708 | 4                   | Parent post is talking about Rust                           |
    | 2   | https://news.ycombinator.com/item?id=43910022 | 0                   | Talks about Fish rewrite                                    |
    | 3   | https://news.ycombinator.com/item?id=43909844 | 0                   | Discusses Issues                                            |
    | 4   | https://news.ycombinator.com/item?id=43909222 | 1                   | Jokey on RIIR                                               |
    | 5   | https://news.ycombinator.com/item?id=43906665 | 0                   | Talking about RIIR                                          |
    | 6   | https://news.ycombinator.com/item?id=43905224 | 0                   | Promotes a rewrite in C versus a Rust rewrite               |
    | 7   | https://news.ycombinator.com/item?id=43897309 | 2                   | Discusses Rust in positive light, but nothing about rewrite |
    | 8   | https://news.ycombinator.com/item?id=43865281 | 0                   | Discusses negatives of JS backends                          |
    | 9   | https://news.ycombinator.com/item?id=43851214 | 0                   | Talks about knowledge bias                                  |
    | 10  | https://news.ycombinator.com/item?id=43851075 | 5                   | RIIR (maybe joke)                                           |
    | 11  | https://news.ycombinator.com/item?id=43840479 | 0                   | RIIR is mentioned in passing, not actually used             |
    | 12  | https://news.ycombinator.com/item?id=43833836 | 4                   | RIIR suggestion                                             |
    | 13  | https://news.ycombinator.com/item?id=43832828 | 0                   | Advises against Rust                                        |
    | 14  | https://news.ycombinator.com/item?id=43832638 | 0                   | Not RIIR                                                    |
    | 15  | https://news.ycombinator.com/item?id=43832349 | 4                   | Asks for RIIR (maybe jokingly)                              |
    | 16  | https://news.ycombinator.com/item?id=43827713 | 0                   | Congratulates on Rewriting in C#/Unity                      |
    | 17  | https://news.ycombinator.com/item?id=43797673 | 0                   | Neither it nor the GP are acually RIIR                      |
    | 18  | https://news.ycombinator.com/item?id=43791746 | 3                   | Mentions Rust in positive light                             |
    | 19  | https://news.ycombinator.com/item?id=43791093 | 1                   | Joke                                                        |
    | 20  | https://news.ycombinator.com/item?id=43791090 | 1                   | Joke                                                        |
    | 21  | https://news.ycombinator.com/item?id=43781819 | 2                   | Arguments for writing code in Rust                          |
    | 22  | https://news.ycombinator.com/item?id=43769094 | 5                   | RIIR                                                        |
    | 23  | https://news.ycombinator.com/item?id=43768282 | 0                   | Negative on RIIR                                            |
    | 24  | https://news.ycombinator.com/item?id=43766357 | 0                   | Explaining what RIIR means                                  |
    | 25  | https://news.ycombinator.com/item?id=43766000 | 4                   | Asks for RIIR                                               |
    | 26  | https://news.ycombinator.com/item?id=43764348 | 0                   | Discusses implementation in Rust                            |
    | 27  | https://news.ycombinator.com/item?id=43757201 | 0                   | Talks about Rust                                            |
    | 28  | https://news.ycombinator.com/item?id=43731538 | 2                   | Mentions Rust in positive light                             |

In summary, there are 28 items on the first page, totalling 38 points. Doing an average, it's about 1.35 points, which suggest that on average, people are somewhere between joking about RIIR and mentioning Rust in positive light.

However actual number of RIIR between 2-5 depending how you look at it, 5-17%. Assuming the rest of pages have a similar spread, and that targeting only keywords of RIIR captures accurately the sentiment - I suspect the latter is the case. I've seen more negativity about Rust in https://news.ycombinator.com/item?id=43910745 in few hours, than positivity about Rust in several days.

And I've seen my comments that are positive about Rust get way more downvoted, than comments skeptical or negative on Rust.

Re: Memory-safe sudo to become the default in Ubuntu

#250
post #242

Earlier quoted context omitted.

Now, why would Linux want to lay claim to being 'the Rust kernel' and how is that different than Linux being rewritten in Rust? This isn't a thing. Linux isn't laying claim to any such assertion. If you want to know Linus's reasons, then read the LKML. He's quite open in all of his thoughts in this regard, and it has nothing to do with labeling Linux 'the Rust kernel'. I don't know if this is some weird sort of advoc…

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

Post reply on HN