You can uninstall the sudo application and add sudo as an alias for run0 in your shell initialization script. That’s better than them renaming run0 to sudo, because that will prevent people from running the real sudo if they want it.
The vast majority of Linux users consider systemd as a good thing because it apparently makes system administration easier. They also don’t agree that systemd is monolithic, because it’s actually designed modular.
But of course there are detractors. The only thing I like about systemd is its declarative service definition and parallel service startup. But if I wanted to run an OS with bloated and inscrutable software (even with the source code), my choice wouldn’t be Linux or Systemd.
I also routinely switch parts of my OS. This is harder with systemd. Although it is modular, the modules are so tightly coupled that it will prevent the replacement of modular components with alternatives. Frankly, I think systemd is killing the innovation in system component development.
That’s rich, coming from a company that sued a child whose website domain name was mikerowesoft.com. (His name was Mike Rowe, and the site was about the software he made).
There are other applications that use suid (like newuidmap). And there are programs that use capabilities (like ping). I’m pretty sure that this logic will be used to justify assimilating those applications too. But I’m sure that the crowd will cheer them on as if they did something revolutionary.
The problem is that all of those interdependent parts and software that are dependent on it become entrenched. There is no freedom to replace individual parts with an alternative because something else will break. That’s what I call ‘Modular in theory, monolithic in practice’.
In practice, all those tight coupling between components mean that it behaves more or less monolithic, despite the claims to the contrary. Replacing them with alternatives is a pain because something else breaks or some software has a hard dependency on it.
Mir is not a good example of distro engineering, because it’s an extreme case of NIH syndrome. Unlike what it is today, the original Mir was an alternative to Wayland.
The story started when Canonical decided that X isn’t good enough and they needed an alternative. They chose Wayland first, exciting the entire Linux desktop community. But then they dropped Wayland in favor of the new in-house Mir project, citing several drawbacks to Wayland. The Wayland community responded with several articles explaining why Canonicals concerns were unwarranted. But in typical Canonical style, they simply neglected all the replies and stuck with Mir.
This irked the entire Linux community who promised to promote Wayland and not support Mir at all. This continued for a while until Canonical realized their mistake late, like always. Then they repurposed Mir as a Wayland compositor.
Now this is a repeating story. You see this with Flatpak vs Snap, Incus vs LXD, etc. The amount of high handedness we see from Canonical is incredible.
LXD was under the Linux containers project earlier. After the Canonical takeover of LXD, the following changes were made:
The repo privileges of the original LXD developers were revoked. Those developers are driving the development of Incus now.
LXD’s license was changed to AGPL+CLA
The first point means that Incus is the true successor of the original LXD. The current LXD is a jealously guarded pet project of Canonical in the same manner as Snap and Mir.
As for the second point, I’m usually a proponent of AGPL. But CLA corrupts it so much that it’s more harmful than with a permissive license. The real intention of this license change is to prevent Incus from incorporating changes from LXD (since the copyleft license of LXD code is incompatible with the permissive license of Incus). Meanwhile LXD continues to incorporate changes from Incus, although the Incus developers haven’t signed any CLA. This move by Canonical is in very bad faith, IMO.
So yes - I consider LXD to be untrustworthy. But that doesn’t cover the old LXD code, its developers or its community. Those transformed fully into the Incus project the same way OpenOffice was forked into LibreOffice. And I don’t trust the LXD name anymore in the same way nobody trusted the OpenOffice name after the fork (before it was donated to the Apache foundation).
I have serious doubts about that due to the role of early Ubuntu in popularizing desktop Linux. For many including me, Ubuntu was the first taste of GNU/Linux and it was a breath of fresh air compared to the contemporary clumsy and cumbersome distros like Fedora. Only Ubuntu from those days has any resemblance to the experience we expect from desktop Linux today.
The problems at Canonical seems like a systemic institutional issue, probably related to egotistic management with temper issues. That of course means that Shuttleworth is the source of those personality disorders. But still…
There are two components that define a Linux distribution. The first is the kernel. The other is the core user land that includes the coreutils and libc. This part is made of GNU coreutils and glibc or compatible alternatives like busybox and musl. Every Linux distro has this. The other user land software stack are also similar across distributions, like X/Wayland, QT/GTK, dbus, XDG, etc.
In Android, everything in the user land is different. It doesn’t have the same coreutils or libc unless you install it. ls and find are so common across *nixes that Android coreutils may be reimplementing it. Then you have APKs, surfaceflinger, etc that are not part of regular Linux distros.
An easy test for this is to see if a Linux program compiled for your platform runs on your OS. Linux programs easily run on alternative distros. But Linux programs won’t run on Android or vice-versa, unless you install a compatibility layer.
Markdown and LaTeX are meant for entirely different purposes. It’s somewhat analogous to HTML vs PDF. While it’s possible to write books with Markdown, it’s a vastly inferior solution compared to latex or typst (for fixed format docs like books).
Asciidoc is a good example of why everything should be standardized. While markdown has multiple implementations, any document is tied to just one implementation. Asciidoc has just one implementation. But when the standard is ready, you should be able to switch implementations seamlessly.
I looked at the post again and they do talk about recursion for looping (my other reply talks about map over an iterator). Languages that use recursion for looping (like scheme) use an optimization trick called ‘Tail Call Optimization’ (TCO). The idea is that if the last operation in a function is a recursive call (call to itself), you can skip all the complexities of a regular function call - like pushing variables to the stack and creating a new stack frame. This way, recursion becomes as performant as iteration and avoids problems like stack overflow.
c/unixsocks for more (lemmy.ml)
Systemd Looks to Replace sudo with run0 (news.itsfoss.com)
OpenTofu ecosystem?
I’m looking forward to switch from Terraform to OpenTofu, but i have the impression that the ecosystem around it didn’t catch up yet....
Red Hat Announces RHEL AI (www.phoronix.com)
deleted_by_author
Systemd wants to expand to include a sudo replacement (outpost.fosspost.org)
what do you think about my tier list of distros (lemmy.ml)
I AM SO DISAPPOINTED WITH UBUNTU 24.04 😡 (news.itsfoss.com)
What is the most popular Linux distribution on PC?
Which communication protocol or open standard in software do you wish was more common or used more?
Whether you’re really passionate about RPC, MQTT, Matrix or wayland, tell us more about the protocols or open standards you have strong opinions on!
Some of my iterations are delightfully recursive (lemmy.world)