6 ms·

I've been FreeBSD wherever I can (mostly personal machines), but did work on a high availability VPN based off FreeBSD that a major Telco bought years ago. The

I've been FreeBSD wherever I can (mostly personal machines), but did work on a high availability VPN based off FreeBSD that a major Telco bought years ago. There is another post mentioning the desktop/web thinking and the server/sysadmin thinking. My thinking - the server/sysadmins are right, but the majority are people in the desktop/web crowd. I actually expect things to get worse once you rope in the container (docker/deis/kubernetes/mesos/etc) crowd. The general attitude seems to be "this doesn't work for me, let me invent something new". If you've spent anytime trying to develop on top of containers and have a deep systems background, you are resisting a hell we had in the late 90s and early 2000s...because "new shiny thing". SystemD is endemic of the new generation trying to solve problems on top of linux. Rather than understand and address the problem, invent something monolithic that isn't better than what it replaced. Oh then force it on distros and not be open to criticism. I really hate this debate and probably should keep quiet.

jamespo 11y ago
I'm an admin and really like a lot of the features SystemD brings, my main concern is that it seems to be overreaching.
- creshal 11y ago
  I'm mainly sysadmin, but I also do some occasional embedded development, and use systemd-enabled Arch on the desktop. Systemd solves so many pain points in all areas that I don't care about ideological debates. And most of the touted "advantages" of sysvinit are, in practice, a nightmare. "people should just know what they're doing"? Well, too bad, nobody does! Distribution maintainers don't know how to write robust init scripts, software vendors don't know how to write robust init scripts, nobody does! Taking away the "freedom" to introduce the halting problem to service definitions is, in practice, godsent. "With BSD init, I can just edit the /etc/rc script and replace it with arbitrary shell code." And now try to debug it one year later when you don't even remember that you did any changes to it. The shit I've seen on Linux systems' /etc/rc.local would give Lovecraft nightmares. And the ability to sprinkle echo statements all over your init system does not make a system "easy to debug", unless you're a PHP "devop" who thinks that OOP is the source of all evil in the world. "The way systemd does parallel startup bothers me. If service A depends on service B, they were traditionally started in sequence; A only starts after B is done starting." Unless it doesn't, because init scripts _cannot_ reliably determine whether a daemon has started up. Grab, say, debian's sysvinit sctipts and count the amount of sleep statements sprinkled all over them. That's not sequential startup, that's a race condition waiting to happen! "Why should systemd implement NTP when ntpd already exists?" Because ntpd is a steaming, insecure pile of crap. And no, openntpd is not a solution, it's just a nicer problem. Why do I need an ntp server on a pure client machine? Just because ntpdate is an even bigger pile of crap? "Being unable to shutdown the system." As if that never happened with sysvinit. Badly behaving init scripts can cause a lot of havoc, at least systemd has a configurable hard cut-off. "Debian should not have adopted it for at least a few more years; they’re supposed to be the slow, steady, and stable distro. " Debian profits the most from ripping out the unusable joke that was their own "parallelized startup enabled" sysvinit. I've seen more Debian stable+sysvinit systems unable to boot up than I've seen Arch+systemd systems.
  - _yy 11y ago
    Full ACK. It makes so many things so much easier and, notably, much more resilient. Ever had to debug a broken init script? The ability to "simply edit init scripts so that it works" often results in nasty, broken hacks ending up in production.
    - digi_owl 11y ago
      And once more the whole debate goes of into file format lala land.
_yy 11y ago
> invent something monolithic that isn't better than what it replaced What. Even if you disagree with systemd, literally anything is better than init.
- cperciva 11y ago
  literally anything is better than init What a peculiar thing to say. The init process does almost nothing -- it just spawns getty processes and launches /etc/rc. On FreeBSD, init.c is a mere 1737 lines of code. For all practical purposes init is just a boot loader; the important parts all come later.
  - _yy 11y ago
    Literally anything is better than init and the jumbled mess of shell scripts accompanying it, then. init (the process) != init (the system), but you're right about the terminology, of course.
    - vox_mollis 11y ago
      Jumbled mess of shell scripts as opposed to jumbled mess of unit files? /lib/systemd/system is identical to /etc/rc.d in terms of maintenance complexity
    - jude- 11y ago
      I also find this a peculiar thing to say. Systemd replaces a few thousand lines of shell scripts and several dozen small well-tested binaries (i.e. coreutils and friends) with a suite of tightly-coupled daemons and tools written in a few hundreds of thousands of lines of C. They haven't removed the "jumbled mess" or made the implementation less complex; they've just hidden it away inside opaque binaries. I'll grant that LSB sysvinit scripts aren't the easiest on the eyes, but they're hardly the shining example of what a scripted init system can look like. OpenBSD's rc scripts are far more elegant and just as featureful, IMHO.
    - feld 11y ago
      I'm sorry that on Linux you don't have a nice rc script framework like the BSDs do so the entire wheel doesn't have to be reinvented in every init script. https://svnweb.freebsd.org/base/head/etc/rc.subr?view=markup https://svnweb.freebsd.org/base/head/etc/rc.subr?view=markup

jamespo 11y ago

I'm an admin and really like a lot of the features SystemD brings, my main concern is that it seems to be overreaching.

creshal 11y ago
I'm mainly sysadmin, but I also do some occasional embedded development, and use systemd-enabled Arch on the desktop. Systemd solves so many pain points in all areas that I don't care about ideological debates. And most of the touted "advantages" of sysvinit are, in practice, a nightmare. "people should just know what they're doing"? Well, too bad, nobody does! Distribution maintainers don't know how to write robust init scripts, software vendors don't know how to write robust init scripts, nobody does! Taking away the "freedom" to introduce the halting problem to service definitions is, in practice, godsent. "With BSD init, I can just edit the /etc/rc script and replace it with arbitrary shell code." And now try to debug it one year later when you don't even remember that you did any changes to it. The shit I've seen on Linux systems' /etc/rc.local would give Lovecraft nightmares. And the ability to sprinkle echo statements all over your init system does not make a system "easy to debug", unless you're a PHP "devop" who thinks that OOP is the source of all evil in the world. "The way systemd does parallel startup bothers me. If service A depends on service B, they were traditionally started in sequence; A only starts after B is done starting." Unless it doesn't, because init scripts _cannot_ reliably determine whether a daemon has started up. Grab, say, debian's sysvinit sctipts and count the amount of sleep statements sprinkled all over them. That's not sequential startup, that's a race condition waiting to happen! "Why should systemd implement NTP when ntpd already exists?" Because ntpd is a steaming, insecure pile of crap. And no, openntpd is not a solution, it's just a nicer problem. Why do I need an ntp server on a pure client machine? Just because ntpdate is an even bigger pile of crap? "Being unable to shutdown the system." As if that never happened with sysvinit. Badly behaving init scripts can cause a lot of havoc, at least systemd has a configurable hard cut-off. "Debian should not have adopted it for at least a few more years; they’re supposed to be the slow, steady, and stable distro. " Debian profits the most from ripping out the unusable joke that was their own "parallelized startup enabled" sysvinit. I've seen more Debian stable+sysvinit systems unable to boot up than I've seen Arch+systemd systems.
- _yy 11y ago
  Full ACK. It makes so many things so much easier and, notably, much more resilient. Ever had to debug a broken init script? The ability to "simply edit init scripts so that it works" often results in nasty, broken hacks ending up in production.
  - digi_owl 11y ago
    And once more the whole debate goes of into file format lala land.

_yy 11y ago

> invent something monolithic that isn't better than what it replaced What. Even if you disagree with systemd, literally anything is better than init.

cperciva 11y ago
literally anything is better than init What a peculiar thing to say. The init process does almost nothing -- it just spawns getty processes and launches /etc/rc. On FreeBSD, init.c is a mere 1737 lines of code. For all practical purposes init is just a boot loader; the important parts all come later.
- _yy 11y ago
  Literally anything is better than init and the jumbled mess of shell scripts accompanying it, then. init (the process) != init (the system), but you're right about the terminology, of course.
  - vox_mollis 11y ago
    Jumbled mess of shell scripts as opposed to jumbled mess of unit files? /lib/systemd/system is identical to /etc/rc.d in terms of maintenance complexity
  - jude- 11y ago
    I also find this a peculiar thing to say. Systemd replaces a few thousand lines of shell scripts and several dozen small well-tested binaries (i.e. coreutils and friends) with a suite of tightly-coupled daemons and tools written in a few hundreds of thousands of lines of C. They haven't removed the "jumbled mess" or made the implementation less complex; they've just hidden it away inside opaque binaries. I'll grant that LSB sysvinit scripts aren't the easiest on the eyes, but they're hardly the shining example of what a scripted init system can look like. OpenBSD's rc scripts are far more elegant and just as featureful, IMHO.
  - feld 11y ago
    I'm sorry that on Linux you don't have a nice rc script framework like the BSDs do so the entire wheel doesn't have to be reinvented in every init script. https://svnweb.freebsd.org/base/head/etc/rc.subr?view=markup https://svnweb.freebsd.org/base/head/etc/rc.subr?view=markup