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.

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.

It already exists.

Is it better?

Where…?

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

It’s much worse: they created Matrix.

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?

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.

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

Less Stallman and more the GPL. Companies hate it.

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.

GPLv3 is incompatible with embedded (Ubuntu Core) use cases

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

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

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

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.

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

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.

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

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.

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.

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

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

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.

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.

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

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.

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.

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

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

Hardly relevant to TFA though

What is the GPL software that is being replaced?

Coreutils

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.

Guix?

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

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

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.

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 solve no new problems, just imaginary boogeymen.

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

Rust can't even self-host on most of the architectures that abortion of a library was written for.

Holy fuck are Rust people all petty activists?

Stop spending every waking minute telling everyone how great it is and making knockoff clones of 40 year old software and go solve new problems.

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

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.

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.

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.

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.

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.

Thanks, Dad.

I'm sorry that my suggestion that people comment on this forum in more constructive ways bothers you

He's your dad? You have a pretty cool dad.

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

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.

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

agree

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?

> 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")

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

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.

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.

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.

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

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

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

You can install it in replacement as sudo on Linux.

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

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.

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.

> I honestly can't understand the appeal.

Virtue signaling.

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

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.

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

And pimp up my CV kind of stuff.

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.

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.

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.

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

[delayed]

Interfaces are not supposed to change while keeping "the spirit". I don't care if you keep "the spirit" or not, if you change an interface, please change the name or at least the version.

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

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.

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

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.

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

Look at this guy still using flint

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.

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

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

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.