Systemd wants to expand to include a sudo replacement
Systemd lead developer Lennart Poettering has posted on Mastodon about their upcoming v256 release of Systemd, which is expected to include a sudo replacem...
You're viewing a single thread.
But for why (I'm commenting this before reading) wouldn't it make more sense to home I'm the scope of systemd so it can be easier to maintain? Why have it do everything?
systemd is more of a set of products and software components branded under a single name rather than a single thing.
systemd itself is rather simple, as most other pieces systemd-* software, like systemd-boot, systemd-networkd and systemd-resolvd. these are usually more stable and less bloated than more popular alternatives
As long as they can work independently, yes. If they are modular and a distro admin (or just a computer admin) can choose to install and use systemd-x but not install or use systemd-y, we are in good business
Now if you have to take a few you don't like or need to use so that the one component you do want works, then no
I honestly don't know enough of systemd to say either way
Most of systemd stuff is decoupled well. You don't need to use networkd to make use of resolved for example.
Good to know, thanks for the answer
Oh okay I didn't know that thanks
You can't think of it a single massive project. It's actually lots of small components.
We could argue the linux kernel is bloated too. The reality is though, provided the project is designed to be modular (as SystemD is), it actually makes sense to keep it together, to ensure there is a standard base and all the components are synchronised fully with their API's.
It also saves distro's a lot of effort.
distro's
You can pluralize without the apostrophe. In fact, you never need an apostrophe to pluralize.
It also saves distro's a lot of effort.
Only if they want to break free.
And they don't need nfsroot or a separate consolidated /usr mount or, really, a whole host of things that lennart didnt understand and unilaterally broke like an arrogant noob.
But that's blasphemy.
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.
Oooh okay that makes more sense. Thanks I didn't know that
I can understand that it makes it easier to add changes that would benefit systemd and distros in general. I read that they introduced run0 to solve long shortcomings of sudo (I'm not aware of which). That sounds logical.
Why have it do everything?
Isn't the guy behind systemd a (former?) Microsoft employee? I feel as though that might offer a clue as to why the trajectory towards bloat.
He's working for Microsoft now but it's very recent, he developed systemd while working at RedHat.
I don't even know of he's still working on it. There are a lot of things to be said about systemd and Lennart but the link to Microsoft is irrelevant.
It is. He is poisoning Linux, slowly, from the inside. Like the XZ attack, just smarter and much slower.
The guy who discovered the xz attack was also a Microsoft employee, for what it's worth.
Maybe they discovered xz attack because they are familiar with these things.
Why do you consider it as poisoning? I've heard the argument about not doing things the traditional Linux way (binary logs for example). But if the alternative provides so many benefits, why is it an issue? Systemd is a piece of cake for all parties compared to sysvinit and alternatives, so why is it bad when it solves so many issued, and makes it super easy to use by just adding e.g. a new option to a Unit?
Another example: timers are more complex than cronjobs, but timers offer additional needed features like dependencies, persistence, easy and understandable syntax, and more. So although more complex, once you get the hang of them, they're a very welcomed feature imo
By itself, solely doing init, it would have been fine, however, binary logging (even if you eventually end up with a text log, that's wasting disk space on a binary format no one wants or needs), and it didn't stop there. He keeps replacing Linux subsystem after subsystem, and many of those replacements are not progress, just duplication of effort and creates more ways for configuration drift.
Here is the rationale for the Journal. In short it is really not that simple and it has a lot of advantages over simple text files and it saves disk space.
Having the logs twice is saving space, got it. Do you hear yourself?
You can still forward to text syslog or to a central logging server like Loki if working with multiple hosts. I still don't get the issue with binary logs.
Yes, and many distros have that out of the box... But they don't have it sent to keep the binary journal as close to empty as possible. So you end up with twice the space in use for logs. As for the issue with binary logs, text logs can be read by far more tools and utilities, rather than just journalctl and pipes.
You can set the space limit for journals logs really low then, to avoid double space usage. As for the last argument, that also was an issue for me years ago because not all tools were compatible with the journald format, but that's since long fixed now and I've not experienced any issue for a long time. Journal logs provide a standard format for all applications, so third party tools don't need to be compatible with every log format of your applications. And it also comes with great additional features like -b or --since etc. So I still don't get the issue here
The issue is logs are suppose to be text. Seriously, wtf. You some Poettering fan boy or something?
I was arguing how it is a very useful tool with many great additions, rather than rely on the: "no old better!" reply based on ignorance. But it looks like your replies have turned full removed, so no point in continuing here to try and educate you.
Text is compatible with all the grep, awk, sed, text editors, what have you. As for the argument of it binary saving space, not on modern filesystems with compression, like zfs, btrfs, and bcachefs. The entire resistance against tampering is bogus, any systems where that is a concern already live scrape logs to an off server indexing service. If you are concerned about poorly formatted logs, that is an application configuration issue. Address it directly with the application. There are no benefits to a binary log, especially when journalctl is absolutely no faster at jumping to the end of the long log than standard less is. Poettering has you chasing phantoms. He always does. He's like the politician who justifies horrible bills by saying it's to protect the children.