@starman
Systemd is nice. I miss GUI apps for #SystemD.
Permanent mounting a Network drive or creating new Services and inspect and modify is such a point.
Even when that releases, it doesn't mean distros will switch to it. Just because it's systemd, doesn't always mean it's better. Just look at network manager vs systemd-networkd. Correct me if I'm wrong but afaik they are made to serve the same purpose and most distros prefer Network Manager over systemd-networkd.
Honestly, though, NM is useless on a server or VM. I don't know why they still have that kludge installed on 90% of machines.
Having said that. Lennart's Cancer is junk from junk process. It WILL be adopted by every distro but PCLinuxOS because no other distro is putting effort towards stability and reliability.
I'd hoped that moving to Microsoft would allow IBM to re-evaluate the shit shoveled into its declining enterprise product, but that's not looking likely given staffing and IBM's ancillary priorities. RHEL only needs to be Good Enough so it can sell certs and classes and AAP and other make-work.
I honestly started out not liking systemd at all, mostly due to the reports that it did waaay to much, but nowadays, I like the concept.
It is basically officially moving daemon management from a script-based approach to a table/database-based approach. That improves static analyzability, therefore increasing clarity, and probably even performance.
I agree that we should abandon scripts and move towards declarative software management, and abandoning sudo for a more declarative system seems like a good step to me.
Actually no. The thing is just that systemd handles so many things that makes the lives both developers/distro maintainers and users easier, but most of it happens in the background. You can forget about having to learning complexer tools, just do it all via systemd
Looking at the implementation, it doesn't really implement sudoers or tools like sudoedit in any way. systemd-run has already been an existing tool for quite some time and this is really just a different CLI for it. That tool asks systemd to make a temporary new service and immediately run it. That, in turn, requires blanket yes/no approval for org.freedesktop.systemd1.manage-units via polkit.
So with run0, you can either do everything or you can do nothing. In-betweens are just not a thing at the moment. There's very little new backend code running as root.
run0 bash should behave very similar to something like systemd-run --uid=0 --gid=0 --wait --same-dir --send-sighup --pty --pipe --collect bash and the majority of those options have been available for quite a while.
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?
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.
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
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.
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
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.
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.
What you're refering to as Linux, is in fact, Systemd/Linux, or as I've recently taken to calling it, Systemd + Linux. Linux is not an operating system unto itself, but rather another free component of a fully functioning Systemd system made useful by the Systemd corelibs, shell utilities and vital system components comprising a full OS as defined by POSIX
I'm no Linux expert, but I've never had any problems with sudo, it just works. Shouldn't systemd have higher priorities on their mind? This feels like change for the sake of change. And if this does happen, I sincerely hope that it just works, like sudo.
Not that I'm opposed to a better sudo alternatives, but I find it rather ironic that one of the reason stated is the large attack surface, considering systemd is a massive attack surface already.
I think wayland has potential but in it's current state it's just half baked. Once more protocols get merged, maybe in a decades time Wayland should be quite flexible and robust.
It does have potential. I think anyone denying that is simply wrong. the issue with wayland is purely how slowly it moves and the fragmentation. Now the fragmentation is actually in large part due to how slowly it moves. There are numerous WIP protocols that will greatly decrease fragmentation when all are merged.
I can't wait because it seems like it will happen in the short future of one or two decades xD
This is great. Not having the attack surface of sudo (and not even being a SUID binary) certainly are great additions.
And I hope people realize that systemd is not one large thing, but a (large) collection of tools.
XZ-utils rings a bell ? It was among others Debian wanting to pull in part of a systemd tool into openssh and that almost turned into a world wide disaster :(
