4 ms·

You seem like someone who's used a variety of init systems, so I have some questions: 1. Why is systemd considered "un-unix"? 2. Why is sysv considered to "fo

You seem like someone who's used a variety of init systems, so I have some questions: 1. Why is systemd considered "un-unix"? 2. Why is sysv considered to "follow unix"? 3. Can you provide or point to some explanations on the ideologies that motivate the difference of opinions regarding sysv/systemd? 4. Really, can someone provide some context and history for all this?

uselessdguy 12y ago
I don't think anyone really considers sysvinit to "follow Unix". In fact, I'd say sysvinit is more of a historical accident than anything. An actual example of a service manager that follows the Unix philosophy would probably be daemontools and its derivatives (s6, perp, nosh, daemontools-encore and runit).
- krylon 12y ago
  When I first started using Linux, I found SysV init very intimidating (along with the rest of the system). When I eventually stumbled upon Slackware, and then FreeBSD, I was euphoric about how simple it was to configure system startup. Which, I guess, is why the BSDs feel a lot less pressure to replace their init/rc system than Linux distros.
ja30278 12y ago
With the caveat that I haven't kept up closely with systemd 1. It is attempting to unify a bunch of previously disconnected functionality into a single program. Typically unix is composed of small single-purpose utilities that perform a single function, rather than a giant monolithic blob of code (with obvious exceptions, like emacs). 2. Partially because it has been around for so long and has so much history, and partially because it follows a unix tradition of using plain text configuration and shell scripting to solve problems. 3. The systemd folks believe that sysv init isn't capable of doing things that are important to modern systems (ex. dependencies between services, reacting to devices coming and going, intelligent daemon management, etc), and that doing those things correctly requires that an init system be 'more' than people previously thought it needed to be. They are also very....confident in their ideas, and don't hesitate to re-implement functionality (like logging) if it makes is easier to interoperate with their other code. People opposed to systemd believe that it is too complex for such a critical piece of system functionality. They also resent the fact that systemd seems to require tight coupling to the rest of the system, and that it is aggressively pushing into so many linux systems. Many of them also probably have a long history with sysv init, and are comfortable with the way that it works. (Some portion also probably recall pulseaudio, which had similar grand visions, was similarly aggressively pushed into use before it was fully baked). 4. I think 1-3 probably cover most of this.
- digi_owl 12y ago
  >and don't hesitate to re-implement functionality (like logging) if it makes is easier to interoperate with their other code. And in the process makes old mistakes. http://seclists.org/oss-sec/2014/q4/592 http://seclists.org/oss-sec/2014/q4/592 What is the saying again? Those that don't learn from history is doomed to repeat it?
- nieve 12y ago
  I was one of those burned by Pulseaudio and the way Lenart basically dumped the project as soon as it got enough traction and before it was stable or truly functional. The design was, as you point out, very reminiscent of systemd - one giant, poorly documented and not very well tested audio system was supposed to replace all other parts of the Linux audio stack (above the kernel drivers) and give us near-realtime performance and a lot of fancy device management and dynamic control. Short form: it didn't until he had already moved on. He still trots that disaster out as proof of his fitness to lead, so it's hard for me to trust that systemd is both well-designed and likely to not be abandoned by him for his next shiny pursuit of Windows. The involvement of other devs helps, but not enough to convince me systemd is worth getting near. Two years of audio fail made a good object lesson for me about Lenart's professionalism and dedication.
chubot 12y ago
Those are good questions, but answering them won't fit in a comment. It takes more like a book. One of the best books on the Unix philosophy is "The Art of Unix Programming", which is available for free. (I recommend getting a hard copy and reading the whole thing.) http://www.catb.org/esr/writings/taoup/html/ http://www.catb.org/esr/writings/taoup/html/ Other books include The Unix Programming Environment by Pike et. al., though it's less explicit about the philosophy. Here's one part of the argument: systemd breaks the Unix design style because it's monolithic: http://www.catb.org/esr/writings/taoup/html/ch01s06.html#id2877537 http://www.catb.org/esr/writings/taoup/html/ch01s06.html#id2... But then systemd developers claim it's not monolithic because it's actually composed of multiple processes. They say there is a misconception that all code is contained in PID 1. There are many executables and many processes, so they would say systemd is modular. But the problem is that all the binaries are released together, without well-defined interfaces. Moreover they are also tightly coupled to kernel features. If you have 2 binaries A and B, but the interfaces between them is not documented or stable, then it's not really modular, because you can't write your own B' to work with A or A' to work with B. The recent thread here about dbus is a good example. Traditional Unix is simple text protocols. dbus is this weird text/binary RPC-ish mix which is not documented. There are lots of other issues with systemd and the Unix philosophy, but that should give you a flavor.
- GFK_of_xmaspast 12y ago
  Eric Raymond is not worth taking seriously except as a bad example. That aside, poking around I found this: http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart/ http://www.freedesktop.org/wiki/Software/systemd/InterfacePo... which looks like reasonably well-defined interfaces? Also not really seeing the problem with a binary protocol, works fine for tcp/ip.
  - deleted 12y ago
    [deleted]
  - chubot 12y ago
    If you don't think the content of that book is relevant to the systemd debate, then you haven't read it. I'd like to see you point to a better book about the Unix philosophy. http://en.wikipedia.org/wiki/Ad_hominem http://en.wikipedia.org/wiki/Ad_hominem
newscracker 12y ago
Quoting a few points from http://boycottsystemd.org/ http://boycottsystemd.org/ "1. systemd flies in the face of the Unix philosophy: "do one thing and do it well," representing a complex collection of dozens of tightly coupled binaries1. Its responsibilities grossly exceed that of an init system, as it goes on to handle power management, device management, mount points, cron, disk encryption, socket API/inetd, syslog, network configuration, login/session management, readahead, GPT partition discovery, container registration, hostname/locale/time management, mDNS/DNS-SD, the Linux console and other things all wrapped into one. ... 3. Since systemd is very tightly welded with the Linux kernel API, different systemd versions are incompatible with different kernel versions and portability is unnecessarily hampered in many components. This is an isolationist policy that essentially binds the Linux ecosystem into its own cage, serving as an obstacle to developing software portable with both Linux variations and other Unix-like systems. It also raises some issues backporting patches and maintaining long-term stable systems. ... 7. systemd is viral by its very nature, due to its auxiliaries exposing APIs, while being bound to systemd's init. Its scope in functionality and creeping in as a dependency to lots of packages means that distro maintainers will have to necessitate a conversion, or suffer a drift. As an example, the GNOME environment often makes use of systemd components, such as logind, and support for non-systemd systems is becoming increasingly difficult. ... 9. systemd is designed with glibc in mind, and doesn't take kindly to supporting other libcs all that much14. In general, the systemd developers' idea of a standard libc is one that has bug-for-bug compatibility with glibc." For more information, read through: http://boycottsystemd.org/ http://boycottsystemd.org/ - lot of links to follow http://en.wikipedia.org/wiki/Systemd http://en.wikipedia.org/wiki/Systemd

uselessdguy 12y ago

I don't think anyone really considers sysvinit to "follow Unix". In fact, I'd say sysvinit is more of a historical accident than anything. An actual example of a service manager that follows the Unix philosophy would probably be daemontools and its derivatives (s6, perp, nosh, daemontools-encore and runit).

krylon 12y ago
When I first started using Linux, I found SysV init very intimidating (along with the rest of the system). When I eventually stumbled upon Slackware, and then FreeBSD, I was euphoric about how simple it was to configure system startup. Which, I guess, is why the BSDs feel a lot less pressure to replace their init/rc system than Linux distros.

ja30278 12y ago

With the caveat that I haven't kept up closely with systemd 1. It is attempting to unify a bunch of previously disconnected functionality into a single program. Typically unix is composed of small single-purpose utilities that perform a single function, rather than a giant monolithic blob of code (with obvious exceptions, like emacs). 2. Partially because it has been around for so long and has so much history, and partially because it follows a unix tradition of using plain text configuration and shell scripting to solve problems. 3. The systemd folks believe that sysv init isn't capable of doing things that are important to modern systems (ex. dependencies between services, reacting to devices coming and going, intelligent daemon management, etc), and that doing those things correctly requires that an init system be 'more' than people previously thought it needed to be. They are also very....confident in their ideas, and don't hesitate to re-implement functionality (like logging) if it makes is easier to interoperate with their other code. People opposed to systemd believe that it is too complex for such a critical piece of system functionality. They also resent the fact that systemd seems to require tight coupling to the rest of the system, and that it is aggressively pushing into so many linux systems. Many of them also probably have a long history with sysv init, and are comfortable with the way that it works. (Some portion also probably recall pulseaudio, which had similar grand visions, was similarly aggressively pushed into use before it was fully baked). 4. I think 1-3 probably cover most of this.

digi_owl 12y ago
>and don't hesitate to re-implement functionality (like logging) if it makes is easier to interoperate with their other code. And in the process makes old mistakes. http://seclists.org/oss-sec/2014/q4/592 http://seclists.org/oss-sec/2014/q4/592 What is the saying again? Those that don't learn from history is doomed to repeat it?
nieve 12y ago
I was one of those burned by Pulseaudio and the way Lenart basically dumped the project as soon as it got enough traction and before it was stable or truly functional. The design was, as you point out, very reminiscent of systemd - one giant, poorly documented and not very well tested audio system was supposed to replace all other parts of the Linux audio stack (above the kernel drivers) and give us near-realtime performance and a lot of fancy device management and dynamic control. Short form: it didn't until he had already moved on. He still trots that disaster out as proof of his fitness to lead, so it's hard for me to trust that systemd is both well-designed and likely to not be abandoned by him for his next shiny pursuit of Windows. The involvement of other devs helps, but not enough to convince me systemd is worth getting near. Two years of audio fail made a good object lesson for me about Lenart's professionalism and dedication.

chubot 12y ago

Those are good questions, but answering them won't fit in a comment. It takes more like a book. One of the best books on the Unix philosophy is "The Art of Unix Programming", which is available for free. (I recommend getting a hard copy and reading the whole thing.) http://www.catb.org/esr/writings/taoup/html/ http://www.catb.org/esr/writings/taoup/html/ Other books include The Unix Programming Environment by Pike et. al., though it's less explicit about the philosophy. Here's one part of the argument: systemd breaks the Unix design style because it's monolithic: http://www.catb.org/esr/writings/taoup/html/ch01s06.html#id2877537 http://www.catb.org/esr/writings/taoup/html/ch01s06.html#id2... But then systemd developers claim it's not monolithic because it's actually composed of multiple processes. They say there is a misconception that all code is contained in PID 1. There are many executables and many processes, so they would say systemd is modular. But the problem is that all the binaries are released together, without well-defined interfaces. Moreover they are also tightly coupled to kernel features. If you have 2 binaries A and B, but the interfaces between them is not documented or stable, then it's not really modular, because you can't write your own B' to work with A or A' to work with B. The recent thread here about dbus is a good example. Traditional Unix is simple text protocols. dbus is this weird text/binary RPC-ish mix which is not documented. There are lots of other issues with systemd and the Unix philosophy, but that should give you a flavor.

GFK_of_xmaspast 12y ago
Eric Raymond is not worth taking seriously except as a bad example. That aside, poking around I found this: http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart/ http://www.freedesktop.org/wiki/Software/systemd/InterfacePo... which looks like reasonably well-defined interfaces? Also not really seeing the problem with a binary protocol, works fine for tcp/ip.
- deleted 12y ago
  [deleted]
- chubot 12y ago
  If you don't think the content of that book is relevant to the systemd debate, then you haven't read it. I'd like to see you point to a better book about the Unix philosophy. http://en.wikipedia.org/wiki/Ad_hominem http://en.wikipedia.org/wiki/Ad_hominem

newscracker 12y ago

Quoting a few points from http://boycottsystemd.org/ http://boycottsystemd.org/ "1. systemd flies in the face of the Unix philosophy: "do one thing and do it well," representing a complex collection of dozens of tightly coupled binaries1. Its responsibilities grossly exceed that of an init system, as it goes on to handle power management, device management, mount points, cron, disk encryption, socket API/inetd, syslog, network configuration, login/session management, readahead, GPT partition discovery, container registration, hostname/locale/time management, mDNS/DNS-SD, the Linux console and other things all wrapped into one. ... 3. Since systemd is very tightly welded with the Linux kernel API, different systemd versions are incompatible with different kernel versions and portability is unnecessarily hampered in many components. This is an isolationist policy that essentially binds the Linux ecosystem into its own cage, serving as an obstacle to developing software portable with both Linux variations and other Unix-like systems. It also raises some issues backporting patches and maintaining long-term stable systems. ... 7. systemd is viral by its very nature, due to its auxiliaries exposing APIs, while being bound to systemd's init. Its scope in functionality and creeping in as a dependency to lots of packages means that distro maintainers will have to necessitate a conversion, or suffer a drift. As an example, the GNOME environment often makes use of systemd components, such as logind, and support for non-systemd systems is becoming increasingly difficult. ... 9. systemd is designed with glibc in mind, and doesn't take kindly to supporting other libcs all that much14. In general, the systemd developers' idea of a standard libc is one that has bug-for-bug compatibility with glibc." For more information, read through: http://boycottsystemd.org/ http://boycottsystemd.org/ - lot of links to follow http://en.wikipedia.org/wiki/Systemd http://en.wikipedia.org/wiki/Systemd