5 ms·

Not trying to start a flamewar over systemd (I'm definitely more of a BSD guy so it doesn't matter much to me other than hoping Linux stays healthy), but just r

Not trying to start a flamewar over systemd (I'm definitely more of a BSD guy so it doesn't matter much to me other than hoping Linux stays healthy), but just reading through this description of all the stuff systemd does made my eyes water. There's always tension between simplicity and necessary complexity, but a lot of this strikes me as being unnecessary complexity to achieve simplicity in the wrong place.

zozbot123 8y ago
No surprise there https://en.wikipedia.org/wiki/Second-system_effect https://en.wikipedia.org/wiki/Second-system_effect My guess is that systemd was developed in order to solve some very real but fairly specific issues, and that ultimately the community will get around to replacing it with something more sensible. It's just not a huge priority at the moment.
- zzzcpan 8y ago
  This is the only positive thing about systemd - it's so bad that it pushes people to try other things and other ideas. However, I don't see anything sensible coming from popular distros that adopted systemd in the first place. Instead we are heading towards more fragmentation and new distros.
  - marcosdumay 8y ago
    Nobody else is doing the political/power play that made systemd widespread. As far as there is a well financed party interested on pushing its code into mainstream (what's not entirely a bad thing), I don't thing there's anybody capable of fighting. Well, maybe I'll be more optimistic when we replace pulse audio for a start.
    - microcolonel 8y ago
      I don't think it took much political will to get systemd everywhere. I switched to Fedora, then to ArchLinux specifically because I wanted to use systemd. I've found it to be great the whole time (if missing a little bit in terms of using device units/events in user instances). It may well be possible for there to be better general solutions to these problems, but systemd has been the best for my use cases (laptop, desktop workstation, server, headless embedded) each time I've evaluated anything else. Are there problems? Probably (I haven't noticed, mind you); should they be addressed? Yes, certainly; Do problems people see in systemd mean that the whole thing is doomed and should be replaced with some unknown contender? I don't really think so. If there were a better init system, an easier reliable NTP, better integration with Linux device events, more useful logging, simpler dhcp, etc. etc. etc. I would be using them (whether they were separate or integrated). For me, it makes a huge amount of sense to enable ntp with timedatectl (assuming the upstream NTP is configured properly), to boot with systemd-boot† (formerly gummiboot), and to configure my simple networks with systemd-networkd. I have never needed to fuss with these things to get the essential benefit they claim to provide; and it has never been more convenient. If I were starting a distribution today for anything except self-initializing applications or tiny microcontrollers, systemd would be the obvious choice, including most of its components. † This is going to get even better and more universal as the ARMv8 ecosystem, and the RISC-V ecosystem inevitably continue to rally around UEFI. As far as I can tell, a universal distro installer for IA32, AMD64, AArch64, ARMv7, and every common Linux-capable (within reason, not counting μClinux here) RISC-V ABI is not actually going to be that crazy to make (apart from size restrictions on the install disk maybe) in a couple years.
nickik 8y ago
Honestly systemd is large as a project but most of it is separated and doesn't actually impact you if you don't use it. And BSD people really should not complain about managing to much software in a single project.
- Walkman 8y ago
  That's starting to be not true. In the beginning, there was just systemd, now starting with bionic, it's components are tied together so much that's it's hard to turn them off or not use it. I liked systemd a lot, but started to understand the complaints when we had a lot of problems with systemd-timesync, systemd-resolved and co...
  - slrz 8y ago
    How is it even remotely hard to not use timesyncd or resolved? Just don't enable them (or disable them, if your distro ships them enabled by default) and use your preferred alternatives instead.
    - Walkman 8y ago
      They are enabled by default and you can't simply just disable, some of them will still start. You have to mask them in order to block them entirely. Also it doesn't matter if you have ntpd running, systemd-timesyncd still started for us...
- village-idiot 8y ago
  They just patched Vim to work correctly with systemd, and it now runs its own DHCP daemon and custom log format. That's not separated.
  - ciupicri 8y ago
    What are you talking about?
    - 8y ago
gerdesj 8y ago
There's always tension between simplicity and necessary complexity I have used a lot of Linux distros from Yggdrasil onwards via say Mandrake. My first kernel was 0.something. Back then we only had Miguel's method for init scripts. (I think). I use Debian, Redhat, Ubuntu, Arch, Gentoo, Centos and others at least these days. I now have only one initscript language to worry about.
- sverige 8y ago
  The last time I set up a Linux box, it used SysV init. I know there are others, but I was under the impression that SysV was sort of the default. It was kind of a pain as I recall, but not terrible. But I wasn't managing dozens or hundreds of boxes, so maybe I didn't really feel the pain that presumably caused someone to come up with this solution.
  - ibotty 8y ago
    The problem with Sysvinit is that while there was not one sysvinit, but many forks, and even more script libraries for the init scripts. You did not stand a chance to have a native (using the systems' shell libraries) init script that would work on different systems.
  - JdeBP 8y ago
    Where gerdesj says "Miguel's method", xe is talking about the init and rc system written by Miquel van Smoorenberg (originally for Minix and later ported to Linux) that copied some, but far from all, of AT&T System 5 init, rc, and adjuncts. gerdesj is specifically referring to the well-known problem that the helper utilities and functions for rc scripts varied wildly from operating system to operating system. It's worth noting that the Debian people introduced another set of conventions recently, in 2014, with rc scripts in the Debian variant of the van Smoorenburg system now interpreted by a /lib/init/init-d-script command instead of a shell. * http://jdebp.eu./FGA/system-5-rc-problems.html http://jdebp.eu./FGA/system-5-rc-problems.html * http://jdebp.eu./FGA/inittab-getty-is-history.html http://jdebp.eu./FGA/inittab-getty-is-history.html * https://unix.stackexchange.com/q/480896/5132 https://unix.stackexchange.com/q/480896/5132
peterwwillis 8y ago
The sad thing is, as a service manager, it's halfway decent. It has stupid technical aspects, but in general it's more useful for admins that want to manage services on Linux than older solutions. But then there's all the other crap that systemd's developers cling to religiously that hold back both the project and the development of complementary software. Their single-minded obsession over total control of a system, and having everyone (even kernel developers) bend to any crazy idea they have, resulted in a bad relationship with both users and developers. I don't think people hate systemd as much as how it was forced down their throats. The really funny thing is how it's now basically just an overcomplicated init script. You don't use systemd in anything resembling modern service architectures (cloud-based, decentralized, etc) except to start some other tool that actually deals with those things.
- sverige 8y ago
  > it's now basically just an overcomplicated init script. That's probably the better way to express what I was trying to say. It seems really complex and rigid (and probably brittle?) for a script that's used basically to start services, but I may be missing something since I don't use Linux much and only then usually on a spare laptop. And as Theo once said, the process of booting an operating system is non-trivial. (Or words to that effect.)
  - peterwwillis 8y ago
    I've written init replacements and it's not trivial, but it's not hard either. The majority of the starting of an operating system can be put in a single shell script (and in fact that used to be standard). But if you want to get really complicated, you can turn every boot operation into a service. Services are a common feature of modern operating systems. You have a dependency graph, you start something based on it, you either watch the process or wait for one to die, you reap it, you figure out what to do next (which is usually "restart the things I need to keep that thing running" or "die and warn the admin"). All of that is useful for daemons, things that need to keep running. For 99% of the rest of system booting, it's one-shot loading of stuff. So, many people (myself included) like just having a shell script to keep all that in, as one a system is built, the boot-up rarely changes. By keeping booting and a service manager separate, you can change things out as you wish. You can do that easily if all pid 1 does is kick off the boot-time stuff, which itself kicks off the service manager. You can't do that if the service manager is the boot manager and both are pid 1. Or at least, now you need to kick off a second service manager from the first one and pretend the first one doesn't exist, which is non-trivial. The more responsibilities you take over, the more crap you need to support. So as a result, systemd is an entire kitchen sink, because it needs to be for you to get anything done, due to its design decisions. With a different design they could offer any functionality and you could pick and choose what to use, but from what I understand now it's more like you have no choice.
phil21 8y ago
Agreed fully. Systemd is the sole reason after 20 or so years in the Linux ecosystem (to the point of fanboying a bit too much here and there) I'm seriously toying with the idea of moving to FreeBSD in production. Every time I come across a new "strange" issue in some server distro these days it's almost always systemd related - and usually something utterly insane.

zozbot123 8y ago

No surprise there https://en.wikipedia.org/wiki/Second-system_effect https://en.wikipedia.org/wiki/Second-system_effect My guess is that systemd was developed in order to solve some very real but fairly specific issues, and that ultimately the community will get around to replacing it with something more sensible. It's just not a huge priority at the moment.

zzzcpan 8y ago
This is the only positive thing about systemd - it's so bad that it pushes people to try other things and other ideas. However, I don't see anything sensible coming from popular distros that adopted systemd in the first place. Instead we are heading towards more fragmentation and new distros.
- marcosdumay 8y ago
  Nobody else is doing the political/power play that made systemd widespread. As far as there is a well financed party interested on pushing its code into mainstream (what's not entirely a bad thing), I don't thing there's anybody capable of fighting. Well, maybe I'll be more optimistic when we replace pulse audio for a start.
  - microcolonel 8y ago
    I don't think it took much political will to get systemd everywhere. I switched to Fedora, then to ArchLinux specifically because I wanted to use systemd. I've found it to be great the whole time (if missing a little bit in terms of using device units/events in user instances). It may well be possible for there to be better general solutions to these problems, but systemd has been the best for my use cases (laptop, desktop workstation, server, headless embedded) each time I've evaluated anything else. Are there problems? Probably (I haven't noticed, mind you); should they be addressed? Yes, certainly; Do problems people see in systemd mean that the whole thing is doomed and should be replaced with some unknown contender? I don't really think so. If there were a better init system, an easier reliable NTP, better integration with Linux device events, more useful logging, simpler dhcp, etc. etc. etc. I would be using them (whether they were separate or integrated). For me, it makes a huge amount of sense to enable ntp with timedatectl (assuming the upstream NTP is configured properly), to boot with systemd-boot† (formerly gummiboot), and to configure my simple networks with systemd-networkd. I have never needed to fuss with these things to get the essential benefit they claim to provide; and it has never been more convenient. If I were starting a distribution today for anything except self-initializing applications or tiny microcontrollers, systemd would be the obvious choice, including most of its components. † This is going to get even better and more universal as the ARMv8 ecosystem, and the RISC-V ecosystem inevitably continue to rally around UEFI. As far as I can tell, a universal distro installer for IA32, AMD64, AArch64, ARMv7, and every common Linux-capable (within reason, not counting μClinux here) RISC-V ABI is not actually going to be that crazy to make (apart from size restrictions on the install disk maybe) in a couple years.

nickik 8y ago

Honestly systemd is large as a project but most of it is separated and doesn't actually impact you if you don't use it. And BSD people really should not complain about managing to much software in a single project.

Walkman 8y ago
That's starting to be not true. In the beginning, there was just systemd, now starting with bionic, it's components are tied together so much that's it's hard to turn them off or not use it. I liked systemd a lot, but started to understand the complaints when we had a lot of problems with systemd-timesync, systemd-resolved and co...
- slrz 8y ago
  How is it even remotely hard to not use timesyncd or resolved? Just don't enable them (or disable them, if your distro ships them enabled by default) and use your preferred alternatives instead.
  - Walkman 8y ago
    They are enabled by default and you can't simply just disable, some of them will still start. You have to mask them in order to block them entirely. Also it doesn't matter if you have ntpd running, systemd-timesyncd still started for us...
village-idiot 8y ago
They just patched Vim to work correctly with systemd, and it now runs its own DHCP daemon and custom log format. That's not separated.
- ciupicri 8y ago
  What are you talking about?
  - 8y ago

gerdesj 8y ago

There's always tension between simplicity and necessary complexity I have used a lot of Linux distros from Yggdrasil onwards via say Mandrake. My first kernel was 0.something. Back then we only had Miguel's method for init scripts. (I think). I use Debian, Redhat, Ubuntu, Arch, Gentoo, Centos and others at least these days. I now have only one initscript language to worry about.

sverige 8y ago
The last time I set up a Linux box, it used SysV init. I know there are others, but I was under the impression that SysV was sort of the default. It was kind of a pain as I recall, but not terrible. But I wasn't managing dozens or hundreds of boxes, so maybe I didn't really feel the pain that presumably caused someone to come up with this solution.
- ibotty 8y ago
  The problem with Sysvinit is that while there was not one sysvinit, but many forks, and even more script libraries for the init scripts. You did not stand a chance to have a native (using the systems' shell libraries) init script that would work on different systems.
- JdeBP 8y ago
  Where gerdesj says "Miguel's method", xe is talking about the init and rc system written by Miquel van Smoorenberg (originally for Minix and later ported to Linux) that copied some, but far from all, of AT&T System 5 init, rc, and adjuncts. gerdesj is specifically referring to the well-known problem that the helper utilities and functions for rc scripts varied wildly from operating system to operating system. It's worth noting that the Debian people introduced another set of conventions recently, in 2014, with rc scripts in the Debian variant of the van Smoorenburg system now interpreted by a /lib/init/init-d-script command instead of a shell. * http://jdebp.eu./FGA/system-5-rc-problems.html http://jdebp.eu./FGA/system-5-rc-problems.html * http://jdebp.eu./FGA/inittab-getty-is-history.html http://jdebp.eu./FGA/inittab-getty-is-history.html * https://unix.stackexchange.com/q/480896/5132 https://unix.stackexchange.com/q/480896/5132

peterwwillis 8y ago

The sad thing is, as a service manager, it's halfway decent. It has stupid technical aspects, but in general it's more useful for admins that want to manage services on Linux than older solutions. But then there's all the other crap that systemd's developers cling to religiously that hold back both the project and the development of complementary software. Their single-minded obsession over total control of a system, and having everyone (even kernel developers) bend to any crazy idea they have, resulted in a bad relationship with both users and developers. I don't think people hate systemd as much as how it was forced down their throats. The really funny thing is how it's now basically just an overcomplicated init script. You don't use systemd in anything resembling modern service architectures (cloud-based, decentralized, etc) except to start some other tool that actually deals with those things.

sverige 8y ago
> it's now basically just an overcomplicated init script. That's probably the better way to express what I was trying to say. It seems really complex and rigid (and probably brittle?) for a script that's used basically to start services, but I may be missing something since I don't use Linux much and only then usually on a spare laptop. And as Theo once said, the process of booting an operating system is non-trivial. (Or words to that effect.)
- peterwwillis 8y ago
  I've written init replacements and it's not trivial, but it's not hard either. The majority of the starting of an operating system can be put in a single shell script (and in fact that used to be standard). But if you want to get really complicated, you can turn every boot operation into a service. Services are a common feature of modern operating systems. You have a dependency graph, you start something based on it, you either watch the process or wait for one to die, you reap it, you figure out what to do next (which is usually "restart the things I need to keep that thing running" or "die and warn the admin"). All of that is useful for daemons, things that need to keep running. For 99% of the rest of system booting, it's one-shot loading of stuff. So, many people (myself included) like just having a shell script to keep all that in, as one a system is built, the boot-up rarely changes. By keeping booting and a service manager separate, you can change things out as you wish. You can do that easily if all pid 1 does is kick off the boot-time stuff, which itself kicks off the service manager. You can't do that if the service manager is the boot manager and both are pid 1. Or at least, now you need to kick off a second service manager from the first one and pretend the first one doesn't exist, which is non-trivial. The more responsibilities you take over, the more crap you need to support. So as a result, systemd is an entire kitchen sink, because it needs to be for you to get anything done, due to its design decisions. With a different design they could offer any functionality and you could pick and choose what to use, but from what I understand now it's more like you have no choice.

phil21 8y ago

Agreed fully. Systemd is the sole reason after 20 or so years in the Linux ecosystem (to the point of fanboying a bit too much here and there) I'm seriously toying with the idea of moving to FreeBSD in production. Every time I come across a new "strange" issue in some server distro these days it's almost always systemd related - and usually something utterly insane.