@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.
Maybe that could be a good thing, but only if the distros do not include sudo by default, the fact to have one thing to update to update more things is good in the security side! If it’s well implemented I’m okay with it
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.
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.
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.
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.
Well… Poettering will eventually work his way up to browser engines and then we’ll get something efficient… Here’s the announcement:
"There’s a new component in systemd, called “engined”. Or actually, it’s not a new component, it’s actually the long existing “WebKit” engine now done properly. The engine is also a lot more fun to use than “WebKit” or “Blink” because you can finally have hundreds of tabs open in your browser without running out of RAM.
Add comment