191–200 of 902 posts
I'm not sure it can replace non-trivial setups - sudo/doas looks set to stay. e.g when you need to restrict a set of users to run only certain applications with certain other users. sudo can do this (even if the config format can be painful).
Earlier quoted context omitted.
It's not difficult to use some parts of systemd without using others. Is it any different than something like coreutils, another package of linux utilities that are synergistic but usable seperately? Nobody complains about coreutils being bundled. Even the rewrite in rust crowd bundle them.
It really is not. This "sudo replacement" (which under the hood is systemd-run) will apparently require quite a bit of the systemd stack to operate. That is not something you have access to in many lightweight container distros or on other non-systemd distros. And coreutils is expected because most people use GNU/Linux. Coreutils is that GNU userland part. And either way, the majority of coreutils are GNU implementat…
Earlier quoted context omitted.
People blame systemd for making the liblzma problem larger than it should have been. https://marc.info/?l=openbsd-misc&m=171227941117852&w=2 "Liblzma ends up dynamically linked to sshd because of a systemd-related extension added by many Linux packagers that pulls in liblzma as an unrelated dependency." https://news.ycombinator.com/item?id=39866076 "openssh does not directly use liblzma. However debian and several ot…
What relevance does this have? Poettering's complaint is that sudo is way too big for a SUID binary, sshd is not a SUID binary? And neither Poettering nor the systemd developers patched said, the Debian people did that. Seems weird to blame systemd for that?
The inclusion of a library to send notifications shouldn't have external dependencies, it shouldn't need them. The library is included in the customer's codebase at execution time, so it is a hole in the customer's security model. This immediately opens a supply chain attack vector (which is what we saw).
This is being taken as evidence that they shouldn't have responsibility for truly security sensitive code - the replacement of sudo.
Some of this is a long-term dislike for systemd and some representative bias. However, Systemd has missed the opportunity to make their client libraries safer.
Personally? I wouldn't have thought to limit the dependencies of my client libraries. It's a growth and project age thing. One moment you're on one side of a line, the next you have to skill up and do things differently.
Using systemd as intended shouldn't result in security holes for their customers.
Why do they have to do this? This is really, really stupid. My issue isn't even that someone tries to replace sudo. That may or may not be a completely fine thing to do, depending on the state of sudo and what improvements can be made. But what makes me really upset is this completely unexplainable need to make everything part of one particular init system. There is absolutely no reason to tie your new sudo replaceme…
> But what makes me really upset is this completely unexplainable need to make everything part of one particular init system. There is absolutely no reason to tie your new sudo replacement to systemd. Absolutely none. The systemd developers are tying it to systemd because they are systemd developers. If somebody else made something like this, it wouldn't be tied to systemd. But somebody else hasn't made something lik…
Earlier quoted context omitted.
Your speculation on what is right and what was fair is of no consequence to me. Their error was not simply using a compression library, it was creating a large central point of failure. If Systemd was smaller, it would not have caused this error. By being large, it made itself vulnerable. It made itself a target. It made other software insecure. These facts are inescapable. And you cannot justify this by simply sayin…
Why is this an argument specifically against systemd, rather than all large software projects? Linux kernel, gcc, glibc - all bundle "a large amount of functionality under a single system" - does this make their design fundamentally flawed as well?
On the whole, I do not like monolithic software projects, but I can accept that they are necessary or beneficial in some cases. Systemd is simply a much bigger target than these other things because it is an especially bad example. It has many components which are only tentatively connected. It is also more fixable. Alternate init systems are used much more widely than something like Hurd to replace Linux. The laptop I'm typing this from runs GuixSD which ships without Systemd and I can hardly notice the difference. I doubt a different kernel architecture would provide such a seamless experience.
Earlier quoted context omitted.
Nobody needs to adopt the changes. Everybody did because it's better than the alternatives. There are still systemd-less distros if you like it.
My issue is not with systemd. My issue is with the argument that all development is good. In this example I am pointing out how Gtk3 has suffered from development attention from GNOME over the last decade and became worse. Maybe run0 is worse than sudo. Maybe not. I have no personal experience on that topic and I doubt anyone here does.
Earlier quoted context omitted.
The implicit premise of this comment is that linux is broken and needs to be changed. It isn't. The changes are not inherently good. Development is not inherently good. Just look at Gtk3 from 2014 to 2024. It was far more functional in 2014 (re: keyboard input) and now that has been removed because "progress".
Nobody needs to adopt the changes. Everybody did because it's better than the alternatives. There are still systemd-less distros if you like it.
So each component is interrelated, and holding one back means sacrificing compatibility with the new features (and security fixes!) of many other components.
In this way we can find ourselves dragged into using software that is actually worse than it used to be. This is important to note because it means our use of a component is not proof that it's good. It just means that the ecosystem is good enough overall that it can force us to accept devolved versions of certain components.
It makes sense to argue about what the consensus of the ecosystem should be even while recognizing that we will probably accept it regardless.
I'm not sure it can replace non-trivial setups - sudo/doas looks set to stay. e.g when you need to restrict a set of users to run only certain applications with certain other users. sudo can do this (even if the config format can be painful).
If the host is to get most scenarios off sudo, exceptions aren't a problem.
If the goal is to delete sudo, exceptions matter, and migrating what is migratable will clarify what the remaining requirements are.
Earlier quoted context omitted.
I tried it a bit ago (when it was still called uid0, pre-release), I also wasn't a fan of the tinting. I like the intent behind it, but some terminals already tint the header color when running sudo, I haven't tested if its done specifically for sudo or if its in a more generic way that could handle this as well.
I can think of a number of things this tinting would break.
Piece by piece, Red Hat is taking over the Linux ecosystem.
Wayland seems to be a solution without a problem, and it's only winning by default. I've toyed with the idea of forking Xorg - the code is a bit odd by today's standards, but I didn't find any direct problem with it, and it works fine - the biggest problem I discovered in Xorg is a lack of project management as nobody knows what it should and shouldn't do
My gentoo system has some gentoo-specific fork of udev without systemd in it.
We don't have to use run0 and can just use sudo.