The Ubuntu 26.04 Rust sudo is not compatible with standard sudo | Hacker News Reader

The Ubuntu 26.04 Rust sudo is not compatible with standard sudo

utcc.utoronto.ca

206 pointswondersky193 comments

Further validation of our decision to move to Debian (as if the sluggish kernel updates and ramming of snaps down our throats weren’t enough). We migrated a few hundred lab machines this summer, and have around half of our servers and containers switched over. It has gone very smoothly.

i set up a bunch of machines at my new place. ubuntu.

my weekend project is moving them over to debian.

it pains me, ubuntu used to be “the” linux i would point people to. the “un-fuckup-able” thing people should try if they’re switching.

The Rustaceans will come for you too. While you’re asleep, they’re watching Claude port the entire Debian userspace to Rust in the name of Jesus Christ amen.

You're so very right https://news.ycombinator.com/item?id=50399400

Oohhh there’s one more C vulnerability. Oh my gosh, what ever will I do? Should I buy a new smart toaster? I’m not sure. I just really don’t know what to do right now.

It’s called pay attention and f*king upgrade your packages.

I guess I forgot the /s on my post.

I don't understand the behaviour behind "the language I'm using is better than X because it has option M and N"

I was there not so long ago when Java was supposed to replace everything, and then C# came, and then Go but my pay was still handled by COBOL that was also supposed to be better.

Yeah I hear ya. I mean they all work fine there will always be something better at some things than others. And there will always be vulnerabilities.

Programmers have some hyper optimization disease where they don’t see things clearly.

what has this got to do with rust?

As someone who's been using ubuntu since warty warthog, what did you end up switching to / what are other people using these days?

They said—Debian

doh - im an idiot. I read that as "from debian", assuming they were referring to the wider debian suite. TY.

I used to use ubuntu for most everything. This year I'm trying arch a la cachyos. It's actually super nice to not have to wait for hardware support and security patches. Has anything broken? Nope. In fact, things that I would just have to deal with as "teehee isn't linux quirky?" shit is mostly gone. Turns out that it really is as simple as canonical and gnome being the problem.

I use Fedora if that's helpful. Well, I've been using Bluefin for the last few months and it's certainly different.

Bluefin uses sudors and uutils too!

Debian for servers and could also be for desktop, though for desktop Mint seemed okay (still Ubuntu based, just without the focus on snaps and the Cinnamon desktop is nice; this one doesn’t fit the question exactly, but figured I’d mention it anyways cause had a pleasant experience).

Whereas on the RPM side Fedora is pretty good for desktop and something like RockyLinux for your servers (essentially carries on the spirit of the old CentOS).

Then again, I never really needed any of the more fancy modern distros, most of the time I just need good LTS and to run Docker, many might prefer Podman.

I just sidelined Ubuntu 24.04 for Debian stable on new home desktop hardware.

Impressions:

1. Installer a bit rough. Tried both "graphical" and curses modes: Both truncated partition-specific strings from the manufacturer's Windows setup. No contextual help; wiki seemed out-of-date.

2. Good choices for initial packages; good apt speed from default server.

3. Firefox base version is four months old -- but is a ".7", so maybe seven rounds of bug fix backports? Ubuntu FF snap version on old hardware is by contrast a ".0", tracking much more recent upstream. Which mostly seems to get me a lot of annoying confections and semi-weekly demands to restart for the new version -- after each of which I must then manually repopulate GNOME's desktop workspaces.

4. Snap-induced clutter of home dir and filesystem utility output is gone! Loving that part.

Debian, openSuSE, Fedora, Rocky, Arch depends what you are using for. One of the first 3 if you're running it on a desktop. Debian if you want the LTS part and the huge amount of packages. Arch if you're feeling more adventurous and don't mind weekly updates. Fedora if you can put up with redhatisms, SuSE otherwise. Rocky if you're running a server and don't want to bother with Debian's config dir OCD or openSuSE's shorter lifecycles.

I mean i switched because of current packages including changes like rust sudo if it makes it better (I do remember a few sudo CVEs).

Are you know running debian with testing or unstable?

My employer has similar plans. Ubuntu 24.04 will be the last Ubuntu release in use for production. Once the support period ends, we are migrating to NixOS.

I don’t have any skin in this rs-coreutils debate. But Ubuntu still hasn’t patched CVE-2026-98432. We’re migrating too

They have. I just updated my resolute system to the patched kernel 7.0.0-43.43. Patched kernel versions have been available via the -proposed pocket before: https://ubuntu.com/blog/fixes-available-in-proposed-pocket-f...

> we are migrating to NixOS

So you're moving from a distro that's being wrecked by ideologically-driven decisions, to one that is almost entirely ideologically motivated and notable for internal drama. Great choice, best of luck.

Care to elaborate?

Haha, I didn't believe what they told me about the community until I experienced the toxicity first hand.

Still wouldn't switch to another distro anytime soon, you know, sunk cost fallacy and all that.

We're an redhat (originally) and derivatives based shop for 30 years now, but if I was going to choose a different stable enterprise level distro to base a fleet on, there's a very good chance it would be Debian.

Why would you move to Debian? Have you used it recently?

I am struggling to remember, but the last time I tried Debian a year ago there was a lot of setup and a few things broken (I think it was outdated packages). One of the things I tried to setup was a RAID array which was a very involved experience. It felt like things were not being tested. While on RHEL it was a simple point and click in Cockpit.

I honestly don't understand why there isn't more people talking about debian. Ubuntu is always mentioned, but it's going down hill, and debian is the obvious alternative. When I went from Ubuntu to debian, I got way more recent versions of my software. That used to be the only complaint people had with debian.

Ubuntu is a frozen debian/sid. At least it was back in the day.

I wish debian would include ssh-import-id in the installer, its a minor change but big quality of life improvement that ubuntu has

would Userify solve that need for you? old but reliable

Whether Debian or Ubuntu LTS have newer versions of software really just depends on which was most recently released - they both have a 2 year release schedule but release on alternating years.

Debian testing seems to be more stable than what most distros put in main. I bend the rules and get most everything from backports to have the best of both worlds (stable + testing).

From my experience (albeit 20 years ago) Debian testing was basically unusable since it could get into an unworkable state quite easily. You were much better off running unstable instead if you needed the absolutely most recent versions of stuff. It would still break occasionally but would get fixes would be available much sooner.

Backports are quite variable. Distro packaging systems are really awkward for software from language ecosystems with many dependencies. I end up having to install a static build of podman if I want a recent version. A backport basically seems impossible.

I have been running with backports for years and can't remember the last time I had a problem. Perhaps things have matured over the years to explain the different experiences.

Backports don’t break a stable install, they tend to either work or are incompatible due to underlying library mismatches (eg libc upgrade.)

However running a testing install can result in a broken system after an apt upgrade and it can stay broken for some time while fixes work their way in from unstable.

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.

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 are justified upon imaginary boogeymen. The complex security nightmares of 'cp' 'ls' and 'rm' were begging for a new design.

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

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.

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.

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

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?

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.

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.

Sudoers glob expressions are a horrible footgun and I have little empathy for anyone complaining about their removal, especially when it’s trivial to fix with 3 extra (explicit) lines.

> Sudoers glob expressions are a horrible footgun and I have little empathy for anyone complaining about their removal […]

Except sudo-rs did not remove them.

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 *

As the author notes:

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

> I do not really have words for this. 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, and it buries this at the end of a section that devotes a bunch of words to describing functionality it doesn't have and doesn't support, with absolutely nothing else in that section to say this (either up front or in the descriptions of how all the wildcards would work if sudo-rs supported them, which it doesn't).

> Also, this is documentation calculated to mislead busy system administrators who are skimming it to see if there is some big difference between the Rust sudo that Canonical has stuck them with and the real version of sudo.

just.. wow.

This is trivial to fix, at least for you.

  %corestaff ALL=NOPASSWD: /usr/bin/mailq "", \
                           /usr/sbin/exim -bp, \
                           /usr/sbin/exim -bpa, \
                           /usr/sbin/exim -bpc, \
                           /usr/sbin/exim -bpr, \
                           /usr/sbin/exim -bpu

That being said there definitely should be an automated way to check for incompatibilities between normal and rust sudo.

forgive me if i’m wrong. i don’t think you’ve ever had to administer more than a handful of machines. your “fix” is irrelevant.

> That being said there definitely should be an automated way to check for incompatibilities between normal and rust sudo.

yes. it’s called the bare minimum.

If you're using `sudo` for something beyond trivial `reboot`, you're doing something VERY wrong.

Like.... apt-get?

So you want users to be able to install any package? So that the attack surface is now literally all the Debian archive?

Yeah, no.

You either use `sudo` when you want full root access or for something completely trivial.

My sudoers is set up to let me run update and upgrade (with no args) without a challenge, but not install.

I'm pretty sure I can b0rk the system by interrupting the upgrade in an inconsistent state. Or maybe inject some fun environment variables into the `apt-get` context. And I think you can launch the shell during conflict resolution for conffiles, giving you instant full access to the whole system?

A more robust design is to have a systemd one-shot unit that users can activate (via a trigger file or sudo).

So my point still stands and your example illustrates it perfectly. Either you use `sudo` for full root access or for something entirely trivial.

`sudo apt install my-custom-backdoor-script.deb`

With NOPASSWD you would also invite someone pulling a `.deb` via `curl` as part of a supply chain attack in a some non-descript NPM package via a git hook or something.

If you're not in the user community of a tool, having an opinion on whether or not the replacement should work doesn't seem like it should matter to you at all.

The complexity of tools and the associated danger absolutely matters.

What are you doing wrong?

I do manage more than a handful of machines, and that means using automation tools and IaC as much as possible, while avoiding humans using shells as much as possible. I’m struggling to enumerate a lot of use cases for a bespoke sudo configuration that shouldn’t be a proper setup.

Before you know it, you will be needing a workaround for every replacement tool you use in Ubuntu. This is what makes it unacceptable.

> This is trivial to fix, at least for you.

Or one could just install (real) sudo instead of (fake) sudo.

Installing real sudo is something I will have to do when (if) we move to 26.04 because we need LDAP functionality, and fake sudo does not provide that.

I think ubuntu-minimal is an empty package that depends on all the core system packages to be installed by default. If you remove it, nothing will happen immediately but the next autoremove will try to uninstall most of the system as it's no longer a required dependency of something.

Seems in Linux land, compatibly, even between distros, is going out the window. :(

Individuals can deal with that, but companies will have a hard time. You would think the Linux Foundation (LF) would chime in with all these differences. But they seem more concerned with AI than Linux these days.

If it was up to me, I would standardize on OpenBSD's doas, but me doing that would make for more incompatibilities.

>Seems in Linux land, compatibly, even between distros, is going out the window. :(

That happened 30 years ago. Userland is not compatible. Too many distro related patchese, especially on Debian/Ubuntu.

The only common denominator is libc because daddy Torvalds doesn't allow the kids to break it. That's why things like snap work but come with a full blown os stack inside.

> If it was up to me, I would standardize on OpenBSD's doas

doas is ~ 1k LOC of easy to understand C code. It can quite literally be made 100% bug-free.

But it was never about that, never about finding a better replacement. It's about religious proselytizing of their chosen language.

If they were going to make breaking changes anyways, they should have just switched to the much simpler `doas`

Ah, but then you don't get to skip editing docs, proclaim walking on a tightrope, or make a new TiVo!

I prefer to have sudo uninstalled.

Strange that such issues haven’t been probed with ai. It’s good st finding regressions

It also doesn't work with ansible, as I recently found out...

To op: ubuntu-minimal is a meta packaged that contains nothing itself. Safe to remove.

Could someone remind me why people use Ubuntu?

I remember 20 years ago Ubuntu was marginally more user friendly. Is it the power of inertia? Ubuntu is just Debian actively made worse.

Yes, I would guess that a combination of inertia and network effects explain Ubuntu's prevalence.

Ubuntu typically has more packages available and newer versions of them, besides supporting PPAs and Snaps to expand the easily available software.

Also, Gnome and KDE are both horribly unintuitive for newcomers. Ubuntu makes a several tweaks to Gnome to make it more user-friendly. Debian just gives a list of names and says to choose one or more.

It is mostly just inertia though.

From my experience, Kubuntu barely changes anything about KDE these days, and that's a good thing, too. I compile my own KDE on my usual machines, but I also have stock Kubuntu on one, and it's pretty much the same.

KDE is basically a clone of the Windows UI when it comes to how things work and there's a billion people out there that know how to handle Windows.

So it can't be that much of a hurdle.

Debian at the time of a new release has up to date software. Ubuntu feels more updated just because it releases every 6 months.

Agree on all other points though. Ubuntu's take on the Gnome interface is what makes it usable. Stock Gnome is just too barebones.

One reason is that we have a lot of developers who get into programming in the last 10 years. Ubuntu was catering directly to "beginners". Many people who only used Ubuntu because they wanted "a linux" never really reconsidered and just use what they know (and often don't even know there are other options).

There's a lot of inertia. That is leading to various major companies shipping their software for, and only supporting, Ubuntu, and if you're lucky Red Hat.

Ayenertia, 'tis not to be under-estimated. Tis why, with certainty, many a hacker here maintain some rudimentary Facebook account despite an open disdain for Meta.

I started off with Ubuntu in the 2010s because I wanted to try out Linux but was sure as hell didn't have the patience nor resources to make consumer conveniences like WiFi just work. The local LUG was also heavily promoting it; that's even more inertia.

Then I got fancy and started really customizing my configuration---I got a dotfiles repo. The oldest commit touching a top-level file in my dotfiles is 11 years ago (almost unthinkable to me!). I haven't really tried it out on any other distro but I'm pretty sure I've written some shim or personal bash command relying on something Ubuntu-specific.

I happen to be in the market for a new laptop right now. I'm looking at Starlabs but unfortunately they do not ship with Debian. Today, however, I saw a random woman in a cafe with Linux Mint so that might be my sign to investigate that ecosystem.

CachyOS.

Never been happier.

I run Ubuntu on my framework laptop. I still run Win11 on my desktops to play games and to have less faff when remoting into work.

I want the simplest possible experience. There is more documentation for Ubuntu, which means things are more likely to work. Or if they don’t work, someone might have posted about the issue.

sudo being slightly different doesn’t make a difference for me when my laptop experience of sudo is “sudo apt …”.

I'm on nvidia jetson, and it comes with ubuntu, and running anything else is a surefire way to run into problems.

The GPU and unified memory is great though.

For me it is entirely inertia, I have hordes of TODO items (more and less urgent ones) and switching OS on my laptop took noticeable time last time.

Despite that it was just upgrade to new OS version and SSD replacement.

Though one of servers is getting upgraded to Debian from Ubuntu adware.

Debian releases lag behind quite considerably. Debian 13 for instance comes out of the box with Python 3.13, whereas Ubuntu 26.04 LTS comes with Python 3.14.

I should note I am a Debian diehard been using it 20 years my main workstation is still on deb12 lol. But recently I have been pivoting away from Debian and towards Fedora. Running Fedora 44 on my Framework 13 Pro and my Chuwi N150 netbook and it has been very stable and pleasant. Relatively cutting edge, too. I am on KDE 6.8 for instance.

PLEASE don't spread misinformation. Debian releases every 2 years (usually summer of odd years). During the summer of even years, Ubuntu takes what is in debian, makes a copy, and calls it their release. Thus they leapfrog. For python specificall, the main maintainer is even the same person in both. It's not possible for Debian to "lag behind quite considerably". Here's the current situation:

  dima@shorty:~$ rmadison python3
  python3    | 3.9.2-3       | oldoldstable | amd64, arm64, armhf, i386
  python3    | 3.11.2-1+b1   | oldstable    | amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x
  python3    | 3.13.5-1      | stable       | amd64, arm64, armel, armhf, i386, ppc64el, riscv64, s390x
  python3    | 3.14.7-3      | testing      | amd64, arm64, armhf, i386, loong64, ppc64el, riscv64, s390x
  python3    | 3.14.8-1      | unstable     | amd64, arm64, armhf, i386, loong64, ppc64el, riscv64, s390x

  dima@shorty:~$ rmadison -u ubuntu python3
   python3 | 3.4.0-0ubuntu2    | trusty             | amd64, arm64, armhf, i386, powerpc, ppc64el
   python3 | 3.5.1-3           | xenial             | amd64, arm64, armhf, i386, powerpc, ppc64el, s390x
   python3 | 3.6.5-3           | bionic             | amd64, arm64, armhf, i386, ppc64el, s390x
   python3 | 3.6.7-1~18.04     | bionic-updates     | amd64, arm64, armhf, i386, ppc64el, s390x
   python3 | 3.8.2-0ubuntu2    | focal              | amd64, arm64, armhf, i386, ppc64el, riscv64, s390x
   python3 | 3.10.4-0ubuntu2   | jammy              | amd64, arm64, armhf, i386, ppc64el, riscv64, s390x
   python3 | 3.10.6-1~22.04    | jammy-security     | amd64, arm64, armhf, i386, ppc64el, riscv64, s390x
   python3 | 3.10.6-1~22.04.1  | jammy-updates      | amd64, arm64, armhf, i386, ppc64el, riscv64, s390x
   python3 | 3.10.6-1~22.04.2  | jammy-proposed     | amd64, arm64, armhf, i386, ppc64el, riscv64, s390x
   python3 | 3.12.3-0ubuntu1   | noble              | amd64, arm64, armhf, i386, ppc64el, riscv64, s390x
   python3 | 3.12.3-0ubuntu2.1 | noble-security     | amd64, arm64, armhf, i386, ppc64el, riscv64, s390x
   python3 | 3.12.3-0ubuntu2.1 | noble-updates      | amd64, arm64, armhf, i386, ppc64el, riscv64, s390x
   python3 | 3.12.3-0ubuntu2.2 | noble-proposed     | amd64, arm64, armhf, i386, ppc64el, riscv64, s390x
   python3 | 3.14.3-0ubuntu2   | resolute           | amd64, amd64v3, arm64, armhf, i386, ppc64el, riscv64, s390x
   python3 | 3.14.7-3          | stonking           | amd64, amd64v3, arm64, armhf, i386, ppc64el, riscv64, s390x
   python3 | 3.14.7-3          | tenacious          | amd64, amd64v3, arm64, armhf, i386, ppc64el, riscv64, s390x
   python3 | 3.14.8-1          | tenacious-proposed | amd64, amd64v3, arm64, armhf, i386, ppc64el, riscv64, s390x

The ubuntu server reporting this is super slow (one of a million paper cuts you suffer when you use ubuntu instead of debian). The latest Debian stable has 3.13.5 as you say. The latest ubuntu lts release (i.e. what anybody actually uses) was released a year later, and has 3.14.3. Next summer, Debian will be ahead. Also note that the current bleeding-edge ubuntu is 3.14.8-1, which is exactly the same as the bleeding-edge debian. Because they're copies of one another

nothing I said was wrong

Ubuntu is african for "I can't install Debian.". At least that's the joke we mad on irc back in the day :-D

It works fine, has broad support for many packages from Canonical, has well over a decade of kernel and core program updates (up to 15 years for free up to five computers with a personal account!) and is often the target distribution for third-party packages. Most guides for professional software target either Red Hat or Ubuntu, and many driver packages for platforms like Arch are just the Ubuntu .debs that are extracted and shoved back into a different format.

If you need to run a five year old version of [PHP|Apache|Nginx|Caddy|whatever], Ubuntu is a solid bet. None of that "we need to update our configuration to a new format to solve a criticial CVE issue" nonsense, for much longer than Debian is offering free labour.

Debian has its own flaws, like its controversial patches, lack of real LTS releases, and lack of business contracts guaranteeing support directly from the source if you're a business.

I have yet to encounter any issues with either sudo-rs or their coreutils rewrite. From what I've come to expect from utcc.utoronto.ca, I'm not surprised they're using some obscure feature that Canonical chose to remove, though. I'm surprised they're even running Ubuntu.

In my day-to-day use of Ubuntu 26 "LTS", I've found bugs with chown, sudo, date, ls and sort.

Did you report them with ubuntu-bug?

When did i sign up to work QA for Ubuntu? Did I miss my orientation and providing my direct deposit info?

You get a very good Linux distro without paying a single penny for it. Why not do a little work to help make it better?

I do get a good one. From debian.org and I’ll report any bugs I find in it.

Honest question, is it worth it for an average user to file reports?

The first time I tried this was the last time I tried. It was ca. 2012 on an Acer laptop that I personally configured to dual-boot. My memory is not to be trusted but

- the biggest problem for me was that it asked for a core dump/logfile, which I agreed to, but for some reason or another it could not produce/extract said debug info and I got stuck in a loop of whoopsie trying and failing.

- smaller grievance (I might be wrong) is that I had to create some account (Launchpad?) in order to report the bug. Why can't it be anonymous?!

Everytime I turned this Acer laptop on, there will be 2-3 such prompts from Ubuntu that something report-worthy went wrong. You learn to blend it out like the cookie consent dialogs but still annoying. Plus, everything is still perfectly usable so it does seem like the OS is just making a mountain out of a molehill.

In my experience every time I go to report a bug or submit a feature request on anything, I find that someone else has already done so it and a maintainer has responded with one of these:

- "why would anyone want that?"

- "that bug is not possible."

- "it's working as intended."

I reported either on Ubuntu's tracker, or the uutils GitHub, unless they'd already been reported.

The chown bug took 18 months to be fixed. The ls bug isn't fixed after 6 months. Sort was fixed in about 3 months.

There are hundreds of open bugs: https://github.com/uutils/coreutils/issues — the project clearly wasn't suitable for an LTS release.

GNU Coreutils also has hundreds of open bugs:

https://debbugs.gnu.org/cgi/pkgreport.cgi?package=coreutils

It's normal to find hundreds of open bugs in large open source projects

True. :)

I really should close some of them, e.g., 8559, since Gnulib, which we depend on, doesn't support IRIX anymore since it is EOL.

> I have yet to encounter any issues with either sudo-rs

I feel like this is just ignoring the issues raised in the post, or saying “well, I didn’t use those features so I don’t care”.

You personally not caring is ok. The distro not caring is generating some hate.

I'm answering the question "why do people use Ubuntu".

I'm also of the opinion that sometimes change is good. The Linux world is held back by design decisions and quirks coded into ancient operating systems that have long since died.

Luckily for the people on old Ubuntu versions, Ubuntu 24.04 without the sudo-rs rewrite will be supported until May 2034 or May 2039 if you pay up. The sudo-rs people have about 7-8 years to fix any problems that might exist before you have to think about doing `sudo do-release-upgrade`.

It's quite a bit more up to date than Debian

It's _the_ operating system for GPU / AI.

I started with Ubuntu because it was more up to date than CentOS or Debian and didn’t require a ton of weird repos to get a modern LAMP stack.

Those days are likely done.

Theress a bug. That happens. Reporting it should take way less time than writing a sarcastic blog post ("I haven't filed a bug because we aren't Canonical's free debugging resource"). It's open source, so I think reporting bugs or submitting a PR is just good citizenship.

On the other hand, they seemingly think that Canonical is their free Linux provisioner. The irony.

> Theress a bug. That happens.

It's not a bug, it's a deliberate incompatibility, as noted by the article's author:

If someone tries to do an in-place upgrade to Ubuntu 26.04, sudo-rs could potentially be installed instead of 'regular' sudo, and now you have a potentially system with borked functionality.

> It's open source, so I think reporting bugs or submitting a PR is just good citizenship.

LOL, the author's very next weblog post:

> One reaction to my entry on how the Rust Sudo is not fully compatible with proper Sudo is that I should have filed a bug report about this behavior. One of the reasons I have not done this comes down why I was using the Rust Sudo, and in my view it's a wider issue with bug reporting in general. To put it simply, I am (or was) an involuntary user of the Rust Sudo, not a voluntary one.

[…]

> In a project centered view, all people using Rust Sudo 'should' report issues to the project because that's how FOSS projects improve (this is not really true, the project unquestionably only wants what it considers 'good' bug reports and will be unhappy about ones that, for example, revisit decisions it has no intentions of changing). In the people centered view, many people have not chosen to use the new Rust Sudo or the Rust Coreutils, they've been stuck with them by Canonical's decisions. These people are under no obligation to help out with Canonical's apparent project of improving these projects (or help out the projects themselves); the Ubuntu project does not get to make everyone using Ubuntu into obligatory bug reporters through its own choices.

* https://utcc.utoronto.ca/~cks/space/blog/sysadmin/BugReports...

Can't read the article because

> You're using a suspiciously old browser

m8 it's firefox mobile from two months ago, calm down

“Calculated to mislead” feels like an absurd overreaction to some docs not being formatted the way you feel is appropriate.

It's an absolutely obnoxious post, full of empty accusations and grudges towards a free (as in free beer) software.

Canonical don't owe them anything. . I really think some people just need to keep their opinion to themselves.

What a ludicrous take.

Nobody's forcing you to use Ubuntu, a software that is free of charge by the way.

It's fine to disapprove of a decision. It's another thing to come with accusations and grudges like this post does.

Ubuntu’s new ln -h is a similar tire fire:

It does something in bsd:

https://man.freebsd.org/cgi/man.cgi?ln

Returns error in gnu:

https://www.man7.org/linux/man-pages/man1/ln.1.html

No-ops the command and returns success in new Ubuntu:

https://manpages.ubuntu.com/manpages/resolute/man1/rust-ln.1...

Given that the selling point of the rust rewrite is gnu compatibility, you’d think they’d RTFM of the thing they were replacing, or at least fuzz the two to confirm identical side effects.

I’m increasingly considering just pretending Ubuntu doesn’t exist. It’s a clown show, and devuan is fine.

And this is why you don't just jump to rust-written alternatives because they're supposedly "safer": the "safer" implementation might actually be incompatible (intentionally or otherwise) from the original, which for something like sudo or coreutils is... Erm, kinda important. Maybe "rewrite it in Rust" was a bad idea after all...

Sidebar: TFW I haven't updated Thorium Mac since V150.

I got dumped to https://utcc.utoronto.ca/~cks/cspace-bad/cspace-old-browser.... trying to visit the page.

Obligatory XKCD: https://xkcd.com/1172/

I start using Ubuntu because my company used it, and they remind me of Redhat and the other Linux vendors that got too big for their breeches. For my personal stuff, I went all in on Debian, FreeBSD and OpenBSD and will never run Ubuntu for personal stuff. I still can't forgive them for adopting systemd or the Wayland mess and I suspect they are going to break more stuff.

Reply on news.ycombinator.com