Posted by wondersky 5 days ago
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.
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.
Still wouldn't switch to another distro anytime soon, you know, sunk cost fallacy and all that.
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.
It’s called pay attention and f*king upgrade your packages.
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.
Programmers have some hyper optimization disease where they don’t see things clearly.
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.
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.
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.
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.
Are you know running debian with testing or unstable?
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.
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.
Virtue signaling.
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.
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
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?
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.
Where is this GPL-licensed sudo that already exists?
"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
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.
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.
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.
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".)
That’s right. “A regression”
Whether it was accidental or purposeful changes nothing.
"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.
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]
/usr/sbin/exim *
> 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?
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.
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.
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.
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.
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...
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.
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.
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.
[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'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.
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?
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.
I hope this copy works https://pastebin.com/mxAZyQJL (I was surprised the website even blocked archive.ph with "suspicious old browser")
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.
You can install it in replacement as sudo on Linux.
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]
/usr/sbin/exim *
>> 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?
> 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.
%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
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.
> 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.
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.
Yeah, no.
You either use `sudo` when you want full root access or for something completely trivial.
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.
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.
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.
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.