A word about systemd
skarnet.org
skarnet.org
"It's as if we had learned nothing from the mistakes of the past 20 years."
My quibble is it's as if we had learned nothing from the mistakes of the last 40 years, not 20. The problem I see with the whole discussion/argument around systemd is it ignores there's two philosophies in computer science, which for convenience sake I'll call the Unix way and the Windows way. I believe the reason so many people, especially us old-timers, are railing against systemd is because it adheres to the Windows way. The problem is there's a lot of Windows people who've now migrated over to Linux and so they love it. It's like Linux has been gentrified and we've all been kicked out of our homes. At least that's why I think people are so intensely emotional about this subject.
As for me, I've decided the hell with it. If Linux now wants to follow the Windows way and adopt systemd - there's nothing I can do about it. It's not even really my fight. I had nothing to do with the creation or maintenance of Linux, GNU, the init tools, etc. Though it's all free I've decided to vote with my time and usage - and that now goes to BSD. So long as BSD follows the Unix way I'll stick with it. Maybe you'll join me, maybe you won't. You use what you want to use and I'll use what I want to use. Peace.
Right now, every biggish daemon has to implement the same old logic in a slightly different way. How many logging systems and files do you know?
I am totally looking for more programs to use systemd's socket activation. This is the true Unix way -- a server should do only one thing (serve), and not worry about logging, uids, and other system peculiarities.
(yeah, we could do it with daemontools as well.. but no one did the hard job of converting thousands of packages to daemontools)
Package: systemd
Description-en: system and service manager
In any case, Linux is not systemd yet. You still have Arch and Gentoo at least. You will miss out the latest security features, but presumably you would not want to do this anyway.
Out of curiosity, what do you mean by this? Arch has used systemd as the default for over six years now (https://wiki.archlinux.org/index.php/systemd), and switching to something else is not officially supported (although technically possible).
It is not how I would do logging. I wouldn't have the fan-in, only to have to filter it all back out into individual streams again in most of my use cases. I wouldn't run log services as the superuser, or as the same user accounts as other services, or as user accounts that owned anything other than the log files that they create. (Subvert an instance of cyclog, which does not use alloca(), and all that you'll gain is write access to one service's log files and log directory. You won't get superuser access. You won't get access to the logged service process, which is running as another user. You won't get access to any other service's loggers, which are running as other users. You won't even get owner access to the log directory, and the rights to alter its permissions, as the logger only has has a non-owner ACL on the directory.)
* http://jdebp.eu./Softwares/nosh/guide/log-service-security.h...
But systemd does do logging.
You are predicating your argument upon a fallacy. AT&T Unix had a service manager from 1988 onwards.
* http://jdebp.eu./FGA/unix-service-access-facility.html
Indeed Laurent Bercot's s6 is one of the very toolsets where all of those things are done by the toolsets. Arguing that the idea is having each program incorporate this is at best foolish and pretty much the very only-systemd-or-van-Smoorenburg-rc fallacy called out by the Uselessd Guy years ago.
* http://jdebp.eu./FGA/daemontools-family.html
* http://uselessd.darknedgy.net./ProSystemdAntiSystemd/
> no one did the hard job of converting thousands of packages to daemontools
Ahem!
% find /package/admin/nosh/config/services -name run | wc -l
849
% find /var/sv -name run | wc -l
816
%
* http://jdebp.eu./Softwares/nosh/debian-binary-packages.html#...
* http://jdebp.eu./Softwares/nosh/guide/creating-bundles.html
Re "nosh": this looks pretty good. I like that it can read systemd's unit files as well -- this means it provides a feasible systemd alternative for those who don't like systemd, but are not ready to rewrite all service files manually.
Void Linux is close. It uses runit as its init/service supervision and implements the daemontools uid/env commands with its chpst command. Logging is managed through svlogd which can timestamp output, rotate files etc. I couldn't be happier with a Linux distribution.
You really don't need to convert anything, unless it's explicitly written to interact directly with some specific supervision mechanism, which I don't think is the case for "thousands of packages".
But I do believe we still need to move towards supervision trees, just not with systemd.
But, it appears the Linux community overall likes it. Which is their prerogative. I don't, which is mine. I look at it like an amicable divorce. I'm leaving Linux, but there's still visitations (work). I wish the community the best.
Regarding b), what do you mean exactly? If you're talking about cgroups, you can delegate part of the hierarchy to a supervisor process via the Delegate= directive, as documented at https://systemd.io/CGROUP_DELEGATION