Hacker News

points by Vaushite 4 days ago | 0 comments

Tools have to be allowed to evolve. Half the Linux ecosystem's problems are caused by sticking on some design that made sense in 1980.

At least the command is still called sudo or run0. Changing it to doas would have been a much more breaking change.

Alas, TFA blocks me with no workaround because I'm using Tor Browser so I can't read about the nature of the changes.

[–] WhyNotHugo 1 day ago

sudo.rs is a really weird direction for an evolution — it re-implements a complex piece of security dropping some arbitrary choices but keeping it pretty complex. It has the exact same security model. I honestly can't understand the appeal.

If you want something similar but simpler, go for doas.

If you need all the features in sudo, keep using sudo.

If you want to try new security models, try s6-sudo, or any other of various tools out there.

sudo-rs keeping the same name is actually a worse breakage — because it doesn't have the same API as sudo (as described by op), but has the same name and pretends to be a drop-in replacement while also not being a drop-in.

[–] egorfine 23 hours ago

> I honestly can't understand the appeal.

Virtue signaling.

[–] KitsumiTheFox 23 hours ago

I fail to see how the term virtue signaling applies to what you highlighted, care to elaborate?

[–] egorfine 22 hours ago

Rust rewrites of existing rock stable applications is only done for performative reasons as there are no merits.

[–] db48x 16 hours ago

Sudo may not be as “rock stable” as you suppose. The sudo-rs project has discovered a number of exploitble bugs in sudo that had existed for years.

And remember that sudo was itself a replacement for earlier tools like su. It has no special claim to be the one and only tool for the job.

[–] pjmlp 22 hours ago

And pimp up my CV kind of stuff.

[–] kelseyfrog 22 hours ago

The virtues being signaled are trust, reliability, and generosity. The mechanism is rust-washing. Like greenwashing, rust-washing has the appearance of and takes credit for the virtues without actually delivering on them.

[–] bikvfeee 4 days ago

To many of us it's not about the features which you obliquely refer to when you say "evolve" but about licensing. It's extremely concerning that we're replacing GPL stuff for non GPL, and just as concerning that so many folks don't recognise this point.

[–] thesuperbigfrog 1 day ago

sudo is MIT-licensed: https://github.com/sudo-project/sudo/blob/main/LICENSE.md

sudo-rs is MIT-licensed: https://github.com/trifectatechfoundation/sudo-rs/blob/main/...

Perhaps you are thinking of uutils? https://github.com/uutils/coreutils/blob/main/LICENSE

[–] solyin 1 day ago

That is the problem. MIT isn't GPL. In our new AI powered future, we want the source so we can fix it ourselves.

[–] burnte 1 day ago

MIT is a source code license. If you have MIT licensed source code then you already have the source code and can fix it yourself. No different than GPL.

[–] gatlin 1 day ago

It is materially different to the GPL and inferior in all such ways.

[–] burnte 17 hours ago

I disagree on both points. The only difference is the lack of a requirement to share your changes under MIT. That makes it only inferior depending on your perspective. You are entirely allowed to feel it's inferior, but it's not FACTUALLY inferior, just different.

[–] dekhn 19 hours ago

I think it's time to recognize that copyleft as an idea is not great and LGPL makes the license even worse. I want licenses that don't have a core philosophy that attempts to overturn existing copyright.

[–] jeremyjh 1 day ago

Sudo is already MIT. What are you concerned about here? Why hasn't it already happened?

[–] criemen 1 day ago

Well, in the AI-powered future, you can reverse engineer and patch about anything without the source, too. That's not an argument against the GPL, but everything you can download is now effectively source-available for a modest fee to an inference provider.

[–] thesuperbigfrog 1 day ago

> That is the problem. MIT isn't GPL. In our new AI powered future, we want the source so we can fix it ourselves.

GPL would be ideal, MIT is okay, but in our new AI-powered future, we may not even need the source code:

https://bramble-apps.github.io/

Maybe all software will become open source or free software?

[–] lakeviewterrace 1 day ago

This is by design.

They are slow-rolling the cancellation of Stallman's connection to the OS because their first attempt failed.

In 10 years, no one will have heard of GNU after all components have been replaced with corporate clones.

[–] tomkarho 1 day ago

I find it hard to believe that all of this movement is because of Stallman. That seems so... petty.

[–] fwip 1 day ago

Less Stallman and more the GPL. Companies hate it.

[–] tomkarho 1 day ago

I can see that. I've been part of a conversation where GPL is treated like the son of satan because it requires giving back and no one seems to agree on the scope or what the license actually demands. So legal goes apeshit and management shits bricks because they might have to share some code.

[–] pantalaimon 1 day ago

GPLv3 is incompatible with embedded (Ubuntu Core) use cases

[–] direwolf20 1 day ago

no it isn't. Please don't spread FUD.

[–] 7e 1 day ago

Open source predates Stallman. His mental illnesses are a distraction from it, though.

[–] boorbat 1 day ago

Stallman is being canceled because an MIT licensed program (sudo) is being replaced with a different MIT licensed program (sudo-rs)?

[–] Vaushite 3 days ago

Licensing is downstream of software existing. The person who actually writes software gets to make the license. If you want a GPL one you have to make that.

[–] bikvfeee 2 days ago

It already exists.

[–] warkdarrior 1 day ago

The default sudo (written in C) has an MIT license: https://www.sudo.ws/about/license/

Where is this GPL-licensed sudo that already exists?

[–] Vaushite 2 days ago

Is it better?

[–] cpach 1 day ago

Where…?

[–] Shish2k 1 day ago

This conversation is very reminiscent of

"if you want people to use open chat protocols, you need to make user-friendly clients"

"we already have irssi"

the vast majority of people abandon IRC for discord

shocked Pikachu face from the free software community

[–] nsoam 1 day ago

It’s much worse: they created Matrix.

[–] jeremyjh 1 day ago

What is the GPL software that is being replaced?

[–] pantalaimon 1 day ago

Coreutils

[–] collinfunk 1 day ago

We still maintain GNU Coreutils upstream, FWIW. I had to beg Canonical to address bug reports on the version that they distribute, which was ignored after the switch to uutils.

For that reason I suggest switching to any other distribution. Of the ones I have interacted with, I have had good experiences with all of them.

[–] thrill 1 day ago

Guix?

[–] collinfunk 16 hours ago

It has always seemed interesting to me, but I haven't gotten a chance to give it any substantial use, yet.

[–] iknowstuff 1 day ago

Hardly relevant to TFA though

[–] ForHackernews 1 day ago

Maybe the GPL people need to get with the times, then. LLVM exists largely because the GCC people were so obstinate. I'm a big believer in copyleft software, but it only works if people want to use your software with their projects.

[–] ahartmetz 1 day ago

LLVM was supposed to be a virtual machine initially, hence the (original) name: Low-level virtual machine. The direction that it took, and especially the development of Clang: that was at least partially because of GCC's intentional anti-modularity.

[–] jcranmer 1 day ago

LLVM was never meant to be a virtual machine, which is the reason why its name was ultimately changed. (It's closer to an instantiation of the C abstract machine, which is where the "virtual machine" came from.)

[–] ahartmetz 1 day ago

AFAIK, being a flexible JIT compiler (for C-like languages, not Java) was a large part of the idea. The pivot to static compilation only happened "accidentally" in the first few years until the by then pretty broken JIT part was officially removed. Correct me if I'm wrong.

[–] jcranmer 16 hours ago

You're wrong. See e.g. https://llvm.org/pubs/2002-12-LattnerMSThesis.pdf, the original thesis proposing LLVM.

LLVM was always trying to pitch itself as a whole-lifetime optimization system. In practice, this meant focusing on LTO and PGO compilation modes. The idea of runtime or idle-time optimization were always kind of a next-todo step rather than anything actually implemented.

[–] dofm 1 day ago

Ref: https://lists.gnu.org/archive/html/emacs-devel/2015-02/msg00...

[–] graemep 1 day ago

If you read the article you would know this is a regression, not an improvement. Stuff breaking silently is never good. If you change config options error when you read the config file that no longer works.

[–] jeroenhd 1 day ago

It's not a regression, it's a documented, deliberate decision to change the behaviour of the program.

    The sudo-rs 'sudoers' manual page suggests that this is a deliberate decision, which makes the Rust version of sudo very definitely not a compatible implementation. The manual page has a nice full section and description of 'Wildcards', and then at the end casually says:
    
    > Wildcards in command line arguments are not supported—using these in original versions of sudo was usually a sign of mis-configuration and consequently sudo-rs simply forbids using them. The only supported use is ‘*’ as the final argument to indicate “zero or more subsequent arguments as noted above.

The manual should probably drop the wildcards section it's not implementing anyway, though.

[–] throw0101d 1 day ago

> It's not a regression, it's a documented, deliberate decision to change the behaviour of the program.

If I install and setup and run "sudo" I expect it to work like sudo.

If you want your program to not work like sudo do not call it "sudo". This is what the OpenBSD folks did with doas.

POLA.

(It's fine if they want it to work differently than sudo; not fine that they called it "sudo".)

[–] graemep 1 day ago

Maybe a deliberate decision in sudo-rs but its a silent failure when Ubuntu is upgraded so its a regression in Ubuntu.

[–] dmitrygr 1 day ago

And when one upgrades and OS and something that worked since 1980 stops working, what do we call that, class?

That’s right. “A regression”

Whether it was accidental or purposeful changes nothing.

[–] wavemode 1 day ago

I don't understand that logic. If it's fine for sudo-rs to have different behavior from sudo, why can't it also just have a different executable name? So that people who are expecting traditional sudo will get "executable not found" instead of having subtle silent problems.

[–] simon_void 1 day ago

according to https://itsfoss.com/news/ubuntu-25-10-sudo-rs/:

"Canonical's Jon Seager mentions that the sudo-rs developers are collaborating with Todd Miller, the original maintainer of sudo, and to think of sudo-rs as a "handshake across generations of secure systems".

He also added that sudo-rs is not expected to bring over all the features of sudo, as the devs are taking a "less is more" approach, excluding features that are too niche or outdated."

So sudo.rs drops some features because "less is more", but it's still called "sudo" because by working together with the original maintainer they capture the spirit of the original, a "sudo 2.0" so to speak.

[–] wavemode 19 hours ago

Even if this change had been in the C version of sudo, I would expect deprecation warnings before the change, followed by error messages after the change, rather than silent failure. That's just good maintainership.

[–] throw0101c 22 hours ago

> So sudo.rs drops some features because "less is more", but it's still called "sudo" because by working together with the original maintainer they capture the spirit of the original, a "sudo 2.0" so to speak.

Except when the change of features are seemingly arbitrary. As the article points out when it comes to regexes, the following is not allowed:

    /usr/sbin/exim -bp[acru]

but the following would be

    /usr/sbin/exim *

So, as the author notes:

> The Rust sudo has apparently opted to keep the single most dangerous wildcard while disallowing all of the wildcards that allow one to be narrow and specific about what you're allowing […]

If the goal is a safer system: WTF?

[–] Grimeton 1 day ago

You can perfectly write a replacement with advanced features w/o breaking anything. Best example breadth-first implementation of find. It mostly exists because find can't handle statx and so doesn't have access to all file properties like their birthtime.

It's 100% compatible to find plus some additional features. That's why it mentions find's manual for the basics and only points out what was added on top in its own manual.

[–] pjmlp 22 hours ago

UNIX creators moved on from their creations into Plan 9, Alef, Inferno, Limbo, Go.

Meanwhile FOSS OSes keep cloning UNIX.

However Ubuntu's approach to rewrite proven CLI tools into cool new language wasn't necessarily the best idea to do another RIIR.

[–] cowlevel 1 day ago

It's treating command patterns in the sudoers file as literals when the previous one treated them as regexes.

[–] operator-name 1 day ago

Evolving tools or their defaults should be lead to silent and unexpected experiences on stable distros.

A transition period with warnings and logs, changes and key differences at the top of the man docs and helpers to find, migrate or at least fail loudly. These are all important bring everyone along, and vital to transition a critical tool like sudo.

[–] lakeviewterrace 1 day ago

> Tools have to be allowed to evolve.

Great, then give it a new name.

> At least the command is still called sudo or run0

You're happy it's a knockoff?

> would have been a much more breaking change

All these "Rust rewrite" projects are creating breaking changes all over the place, whilst solving no real problems. They can shove them up their arses.

[–] novafunc 1 day ago

It’s not a knockoff. They have a friendly relationship with the original creator of sudo. And their work helps uncover bugs of the original sudo so they send fixes upstream.

[–] Twirrim 1 day ago

Friendly relationship or not, the end user experience is that something that was working, no longer is, because it's not feature compatible. This is despite it being used to replace it under the same name. If it had been `runas` or anything else it'd be fine.

There's a strong principle in upstream Linux kernel about "You don't break userspace"[1], that I really wish more folks would get into their heads, but most especially a variant "You don't subtly break userspace".

If you're going to replace an existing binary, under the same name, you need to be like-for-like in commands, even if your guts are completely different. Very few people give a damn about how it's actually implemented, just does it do what they need it to do.

If you want to do things differently, do it under a different name and have it be an explicit break for an end user by not shipping with the original and let people choose to install it if they really don't want the new thing. Breaking things subtly is completely unacceptable.

[1] espoused really clearly, as part of an infamous rant https://lore.kernel.org/all/CA+55aFy98A+LJK4+GWMcbzaa1zsPBRo...

[–] Grimeton 1 day ago

Yeah "You don't break userspace" refers to the kernel <-> userspace interface (libc) because that's the smallest common denominator and the reason why stuff like snap works.

Besides that userspace has been incompatible between distros for at least 30 years because everyone has that one special patch the library needs on their distro that isn't accepted upstream and breaks things beyond repair.

This was already the case in the 1990s when Applixware shipped 30 different versions of their software on one CD-Rom because it should run on different distros and their versions.

And back then there weren't that many, mostly Red Hat, SuSE and Debian.

[–] lakeviewterrace 1 day ago

All the time wasted on navel-gazing could have been spent auditing and fixing the original projects' code.

Starting anew WILL introduce new bugs. This is a statistical certainty.

Most Rust rewrites are justified upon imaginary boogeymen. The complex security nightmares of 'cp' 'ls' and 'rm' were begging for a new design.

[–] danielheath 1 day ago

One would never return “*” to signal an error in rust code (or any language with an option type).

[–] Scoring6931 1 day ago

Nothing precludes error handling in C. It's on the programmers to actually do it.

[–] danielheath 6 hours ago

If you forget to do it in C, everything still looks superficially right.

If you forget to do it in rust (or zig, or typescript, or any of the hundreds of languages with option types), your code doesn't compile.

Nothing precludes "simply do not fall off" when working off heights, either, but there's a reason safety harnesses are mandatory when working at heights in most of the developed world.

[–] Ygg2 1 day ago

Nothing precludes having legible programs in Brainfuck[1]. It's on programmers to actually do it.

[1] Other than the language itself.

Same goes for C, it's reliance on weakish type system is what causes its numerous fuckups.

[–] mxey 16 hours ago

Imagine every Rust program just calling unwrap on this result, and therefore the Rust library deciding to just never return an error. That’s analogous to what happened here.

[–] saghm 1 day ago

If your goal is to convince people that you're right, describing things as "time wasted on navel-gazing" is not the type of thing that will win people over. It comes across as arrogant and entitled, as if the world would be better if everyone would just recognize you're smarter and therefore should do whatever you want.

If you're just pissed and trying to blow off steam, maybe this choice of words will help a bit, but because of the issues described above, it also might just cause a bunch of people to react negatively towards you and therefore make your mood worse.

If you're just commenting here as something to reference in the future for when you expect to say "I told you so!" to everyone, I guess this is a reasonable way of doing it. It still doesn't really seem like there's much need for phrasing it like that though; people still might look back and think that you're right but still sound arrogant and entitled.

[–] UqWBcuFx6NV4r 1 day ago

I can’t stress this enough: there are—rightfully—a whole bunch of people that simply do not want to work on C codebases, because in the typical case, working wIth C sucks. Your outbursts are never going to change this, no matter how petulant or vitriolic. Amazing how a group of people has made “[aversion to{ languages with far fewer footguns” into some sort of culture war issue. Sorry that the industry is forcing you to read a book or whatever.

[–] fukaiall 1 day ago

Rust is a very good language, but some dogmatic people hyped in the language are ruining the reputation of the language.

[–] lakeviewterrace 1 day ago

agree

[–] simonask 1 day ago

Who, exactly?

Every time Rust is mentioned, these mythical zealots are mentioned. Yet somehow they never seem to actually show up. Most elusive!

Are they with us in this room right now?

[–] serf 1 day ago

>Tools have to be allowed to evolve. Half the Linux ecosystem's problems are caused by sticking on some design that made sense in 1980.

the other half of the problems are from people who think redesigning the wheel is a good idea and try to wedge conformity-breaking tools into the thing.

[–] mtmail 1 day ago

> TFA blocks me with no workaround

I hope this copy works https://pastebin.com/mxAZyQJL (I was surprised the website even blocked archive.ph with "suspicious old browser")

[–] jms703 1 day ago

Yes, they do. Put them into your stable server distribution AFTER they are complete.

[–] dmitrygr 1 day ago

Why? Do knives need to evolve? Screwdrivers? Hammers? Can’t good be good?

[–] dwattttt 1 day ago

I don't know the history of knives and hammers, but screwdrivers _have_ evolved, in backwards incompatible ways.

Slot screws date back to the ~15th century, Phillips to the 1930s, and Torx to the 60s. They all brought improvements.

[–] throw0101c 21 hours ago

> Slot screws date back to the ~15th century, Phillips to the 1930s, and Torx to the 60s. They all brought improvements.

But Torx does not call itself "Phillips": you know the difference and plan accordingly.

Calling something "sudo" and then not working like sudo is the problem.

Sudo used to be in OpenBSD, but they found it too troublesome (at least as a default) so they created something else / 'better' for their needs: they didn't call it "sudo", they called it "doas", because it did not work the same way as sudo.

[–] dwattttt 15 hours ago

I dunno, all those arguments work both ways. They're both called screws as well, they have a functional interface that's the same on both, they were all changes that broke backwards compatibility in the service of improving their purpose, and if you got a product that includes "screws" you don't know which one you're getting.

[–] tmtvl 22 hours ago

You may still be using flint-knapped knives, but the world as a whole moved on to bronze, then iron, and, more recently, steel. Hammers evolved as well, with more ergonomic grips being invented to reduce repetitive strain injuries, as well as various heads which are better suited to different tasks (like the claw hammer or ball-peen hammer).

[–] fluidcruft 21 hours ago

Look at this guy still using flint

[–] doublerabbit 1 day ago

Doas is already a replacement to sudo especially in the OpenBSD world.

You can install it in replacement as sudo on Linux.

[–] direwolf20 1 day ago

Did you mean changing it to doas or run0 would be breaking?