"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.
How is having every single daemon implement setuid, chroot, logging, privilege dropping and so on "unix way"?
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)
The biggest problem with systemd is it purported itself to be an init system - and then set out to do a whole lot more. That's where it abandons the Unix way, as far as I'm concerned. But you like it and the Linux community overall seems to like it. That's fine. That just means I'm no longer in synch with the Linux community - I'm not aligned with their vision - so I'm leaving it. I no longer have any hard feelings about it. I don't feel my 25 years of using Linux have been "wasted." It worked well for what I needed it for but now it's time for me to move on. So I am.
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.
> In any case, Linux is not systemd yet. You still have Arch and Gentoo at least.
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).
You are somewhat confused, systemd doesn't do priv sep, systemd doesn't do 'logging' and there are already tools that do what you want via chain loading
systemd very much does do logging. systemd-journald is a compulsory part of the system. It is one big daemon that is a huge fan-in point for all log output streams. It is also the locus of the well-publicized security holes which hit the headlines recently that allowed one to gain superuser access by subverting it.
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.)
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.
If I am reading this right, it looks like you are agreeing with me? We both think that centralized service managers are good, and are consistent with Unix way; and having each daemon implement chroot and logging manually is bad.
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.
> (yeah, we could do it with daemontools as well.. but no one did the hard job of converting thousands of packages to daemontools)
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".
Did you try systemd? My biggest problems with it is that a) it's written by macho C programmers, who couldn't produce anything secure even if their lives dependent on it and b) it's not unixy, i.e. not defining protocols and not letting everyone implement their own supervisors and their own behaviors and c) it's too sloppy wrt changing files on disk, making it really hard to keep control over that.
But I do believe we still need to move towards supervision trees, just not with systemd.
I've used systemd and I'll still continue using systemd at work where we use RHEL, because our decision to use RHEL isn't going to change any time soon, if ever. But on my own devices? No. That's not to say systemd doesn't have some good points, it does. It's good at being an init system - the problem is it's gone on and taken over so much more. It's like kudzu. We wanted some greenery but damn! Now it's everywhere!
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.
Agree about a) [but: doesn't that rather contradict "it's not unixy"... ].
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
17 comments
[ 2.9 ms ] story [ 49.8 ms ] thread"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)
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).
* https://framagit.org/taca/archnosh
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!
* http://jdebp.eu./Softwares/nosh/freebsd-binary-packages.html...* 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