10 ms·

Results of the Debian systemd survey

88 points by radimm 13y ago

radimm 13y ago
If you haven't done so I recommend reading 'systemd - The Biggest Myths' http://0pointer.de/blog/projects/the-biggest-myths.html http://0pointer.de/blog/projects/the-biggest-myths.html
- VLM 13y ago
  That's a good list of 30 or so myths and a pro-systemd explanation. It would be interesting to have an anti-systemd rebuttal. The explanation that systemd is non-monolithic "in design" because each binary can be separately packaged "in packaging phase" was pretty lame because it confuses the topic to "win", although also completely irrelevant (A better answer would have been, ok, assume inductively for the sake of this discussion that it's monolithic... given that inductive assumption, so what?). 1) Are there any significant/serious myths not listed? 2) Does it matter? What I mean by that is the systemd wars remind me a lot of the sound wars from years ago. $user installs a sound system (alsa, pulse, oss, doesn't really matter). It'll probably either work perfectly or miserably fail. If it works, $user will blindly love that sound system and brag about it. If it doesn't work, $user will trash talk it all over the internet. The facts don't seem to matter, just the results of one anecdotal experience. In an environment like that its nearly impossible to learn anything from the community about systemd. It reminds me a lot of those geniuses who post on world wide forums how no one in the world should sign up for $cellphone_provider because their local tower has poor coverage. That's just great, as if the other 99.9999% of the population should care.
  - rmk2 13y ago
    Of course its a "pro-systemd explanation", it's Lennart Poettering's blog. Not that it takes anything away from his explanations, it's a good post. One can at least assume he knows what he's talking about...
  - bkor 13y ago
    Seems you're just confusing things. Why do you suggest systemd is monolitic. What is the problem actually? There are various independant parts. E.g. the logind bit is now used by Canonical on upstart. Seems your issue is some theoretical problem while in practice systemd is just not monolithic.
viraptor 13y ago
If Debian manages to actually use systemd by default, that may have interesting implications for Ubuntu which I think is the only major distro using upstart. All depends on how deeply would systemd be integrated of course, since Ubuntu already rewrites most of the system startup scripts for use with upstart anyway. I'd like to see some comment from Canonical people about how that would affect them.
- buster 13y ago
  Well, i hope this way Canonical learns the difference between open source community projects and going your own lonely path.
  - nknighthb 13y ago
    So, "open source" now means "Do everything Red Hat's way."? Interesting change in definitions.
    - buster 13y ago
      In my own definition open source means "work together, be open about your intentions, contribute".
      - nknighthb 13y ago
        Lennart works almost alone, his "open intentions" are to explicitly not support the wider open source community (like non-Linux kernels and non-GNOME desktops), and he "contributes" to virtually nothing but his own inventions of questionable technical merit. Why you think Canonical is any worse eludes me.
        mseepgood 13y ago
        > Lennart works almost alone He does not. Systemd has over 370 individual contributors, 15 other people have commit powers beside him. Myth 27: http://0pointer.de/blog/projects/the-biggest-myths.html http://0pointer.de/blog/projects/the-biggest-myths.html
buster 13y ago
Sounds great.. i'm using Debian on my Desktop and i would welcome such a move! Let the good old sys-v init system die, it has served long enough. I understand that most old init scripts would even work in systemd, so i imagine the migration not being as painful as it may seem..
- viraptor 13y ago
  I've got mixed feelings about this. I really like the idea behind systemd/upstart (they're quite similar in practice) and was glad to migrate to systemd when Arch sorted out most of its integration issues. But to be honest, I prefer upstart much more. It's simple, it does one thing, it's clear about what happens (most of the time). With systemd I find myself quite often with no idea where to even look for information about something not starting. I still have a service in the system that I don't know how to remove (it's failing to start apparently, not even sure where does it get created). I spent hours debugging issues and trying to get it all-green on my system... and failed. In my opinion it's just too big and complex for it's own good. For my deployments upstart provides the equivalent behaviour in the part that matters (actually running the software) in a simpler way and does not try anything else.
  - fuzzix 13y ago
    "With systemd I find myself quite often with no idea where to even look for information about something not starting" You could read the (currently) 20-part sysadmin guide. http://0pointer.de/blog/projects/socket-activated-containers.html http://0pointer.de/blog/projects/socket-activated-containers... /sbin/init and its simple shell scripts never required this much explanation.
    - viraptor 13y ago
      I read (most of) it, but there's a big difference between "I know how this works" and "I can debug why things don't work as I expect them to work after reading documentation" with systemd. This gap doesn't exist with sysv style init scripts and I couldn't find much information addressing the issue.
jeltz 13y ago
Does anyone know if the GSoC last year attempting to write a systemd -> sysvinit converter got anywhere? To me that sounded like a very ambitious project given the socket activation in systemd. https://github.com/akhilvij/systemd-to-sysvinit-converter https://github.com/akhilvij/systemd-to-sysvinit-converter
- secure 13y ago
  It got to a state where it is somewhat working, but it doesn’t handle a lot of cases. When I tried to use it for a simple real-world daemon, it didn’t work. AFAICT, nobody actually cares enough to continue development (though some people want to see it succeed).
npsimons 13y ago
This is one of many reasons why I love Debian. Very agnostic, very reasonable approaches to issues like this, and above all, whether or not systemd ends up as the default, I can almost guarantee people will still have the option to very easily switch to (or from) it in Debian. That being said, I can definitely second many of the top concerns listed, chief among them: non-greppable logs (binary formatted) and too much complexity/trying to do too much.
- jlgreco 13y ago
  I had no problems with systemd when I was using Fedora on my laptops (I never had to interact with it at all), though right now I'm using Debian without systemd and have no problems either. I don't really have a dog in this fight; it seems either solution is going to stay out of my hair and do what it needs to. Nevertheless, the concept of binary logs really annoys me and I have yet to see a satisfying explanation of why it should be necessary. The best I've seen is "well windows uses binary logging too" and "the syslog text format sucks", but neither of those satisfies. Windows does plenty of shit that should not be mimicked, and the benefits of text logging are severely dampened on Windows anyway (on account of Windows not being Unix.) Furthermore, the syslog text format sucking is not an argument for not using text logs in general, only an argument for not using the syslog text format specifically. Why can't we have a reasonable non-syslog text format for logs?
  - anonyfuss 13y ago
    > Why can't we have a reasonable non-syslog text format for logs? I think the real question is: why is systemd defining a logging format at all?
    - jlgreco 13y ago
      Well, technically I suppose systemd doesn't, journald does (and systemd requires journald, and journald is made and shipped by the same people....). I'm not opposed to a "next-gen syslog", but yeah, that isn't a push that should be done in such close connection with systemd. A better approach would be to make rsyslog more than just a syslog daemon and build up a new protocol and storage format with it, with the full intention of standardizing it. (the syslog protocol is a pain in the ass, particularly that hard limit on facility numbers... Fix that first, then roll from there. Make rsyslog treat syslog like Vim treats vi: capable of falling back to compat mode, but better by default.)
kunai 13y ago
I wonder why no distributions have adopted launchd as their SysV init replacement. Not only does it combine cron, at, and other daemons into init itself, but it's also licensed liberally and would serve as a quite decent replacement for init. It's also cross-compatible with BSD and Linux systems. Is it perhaps the stigma that comes with using a product developed by Apple?
- jff 13y ago
  > Not only does it combine cron, at, and other daemons into init itself I think I found the reason.
  - kunai 13y ago
    When is that last time you used cron to schedule jobs? Be honest.
    - jff 13y ago
      I use it to this day to keep my dynamic DNS records up to date. I also use it daily, although not explicitly, when the various Debian cron jobs run. Logrotate, that kind of thing. It's the idea that all this shit should be rolled into init, the goddamn boot process, that revolts me.
    - e1ven 13y ago
      Earlier this morning? It might be because I'm an ops guy, but I use Cron to schedule things on a regular basis, even in my personal work. It's pretty crazy good at what it does. Being able to say "Filter my email every 5 minutes", is awesome. */5 * * * /usr/local/bin/filter-email.sh
    - jlgreco 13y ago
      Thursday.
    - runjake 13y ago
      On non-OS X and non-Windows OSes? Probably daily. Heck, I even use cron (via Cygwin) on my Windows box at work.

88 points by radimm 13y ago

If you haven't done so I recommend reading 'systemd - The Biggest Myths' http://0pointer.de/blog/projects/the-biggest-myths.html http://0pointer.de/blog/projects/the-biggest-myths.html

VLM 13y ago
That's a good list of 30 or so myths and a pro-systemd explanation. It would be interesting to have an anti-systemd rebuttal. The explanation that systemd is non-monolithic "in design" because each binary can be separately packaged "in packaging phase" was pretty lame because it confuses the topic to "win", although also completely irrelevant (A better answer would have been, ok, assume inductively for the sake of this discussion that it's monolithic... given that inductive assumption, so what?). 1) Are there any significant/serious myths not listed? 2) Does it matter? What I mean by that is the systemd wars remind me a lot of the sound wars from years ago. $user installs a sound system (alsa, pulse, oss, doesn't really matter). It'll probably either work perfectly or miserably fail. If it works, $user will blindly love that sound system and brag about it. If it doesn't work, $user will trash talk it all over the internet. The facts don't seem to matter, just the results of one anecdotal experience. In an environment like that its nearly impossible to learn anything from the community about systemd. It reminds me a lot of those geniuses who post on world wide forums how no one in the world should sign up for $cellphone_provider because their local tower has poor coverage. That's just great, as if the other 99.9999% of the population should care.
- rmk2 13y ago
  Of course its a "pro-systemd explanation", it's Lennart Poettering's blog. Not that it takes anything away from his explanations, it's a good post. One can at least assume he knows what he's talking about...
- bkor 13y ago
  Seems you're just confusing things. Why do you suggest systemd is monolitic. What is the problem actually? There are various independant parts. E.g. the logind bit is now used by Canonical on upstart. Seems your issue is some theoretical problem while in practice systemd is just not monolithic.

viraptor 13y ago

If Debian manages to actually use systemd by default, that may have interesting implications for Ubuntu which I think is the only major distro using upstart. All depends on how deeply would systemd be integrated of course, since Ubuntu already rewrites most of the system startup scripts for use with upstart anyway. I'd like to see some comment from Canonical people about how that would affect them.

buster 13y ago
Well, i hope this way Canonical learns the difference between open source community projects and going your own lonely path.
- nknighthb 13y ago
  So, "open source" now means "Do everything Red Hat's way."? Interesting change in definitions.
  - buster 13y ago
    In my own definition open source means "work together, be open about your intentions, contribute".
    - nknighthb 13y ago
      Lennart works almost alone, his "open intentions" are to explicitly not support the wider open source community (like non-Linux kernels and non-GNOME desktops), and he "contributes" to virtually nothing but his own inventions of questionable technical merit. Why you think Canonical is any worse eludes me.
      - mseepgood 13y ago
        > Lennart works almost alone He does not. Systemd has over 370 individual contributors, 15 other people have commit powers beside him. Myth 27: http://0pointer.de/blog/projects/the-biggest-myths.html http://0pointer.de/blog/projects/the-biggest-myths.html

buster 13y ago

Sounds great.. i'm using Debian on my Desktop and i would welcome such a move! Let the good old sys-v init system die, it has served long enough. I understand that most old init scripts would even work in systemd, so i imagine the migration not being as painful as it may seem..

viraptor 13y ago
I've got mixed feelings about this. I really like the idea behind systemd/upstart (they're quite similar in practice) and was glad to migrate to systemd when Arch sorted out most of its integration issues. But to be honest, I prefer upstart much more. It's simple, it does one thing, it's clear about what happens (most of the time). With systemd I find myself quite often with no idea where to even look for information about something not starting. I still have a service in the system that I don't know how to remove (it's failing to start apparently, not even sure where does it get created). I spent hours debugging issues and trying to get it all-green on my system... and failed. In my opinion it's just too big and complex for it's own good. For my deployments upstart provides the equivalent behaviour in the part that matters (actually running the software) in a simpler way and does not try anything else.
- fuzzix 13y ago
  "With systemd I find myself quite often with no idea where to even look for information about something not starting" You could read the (currently) 20-part sysadmin guide. http://0pointer.de/blog/projects/socket-activated-containers.html http://0pointer.de/blog/projects/socket-activated-containers... /sbin/init and its simple shell scripts never required this much explanation.
  - viraptor 13y ago
    I read (most of) it, but there's a big difference between "I know how this works" and "I can debug why things don't work as I expect them to work after reading documentation" with systemd. This gap doesn't exist with sysv style init scripts and I couldn't find much information addressing the issue.

jeltz 13y ago

Does anyone know if the GSoC last year attempting to write a systemd -> sysvinit converter got anywhere? To me that sounded like a very ambitious project given the socket activation in systemd. https://github.com/akhilvij/systemd-to-sysvinit-converter https://github.com/akhilvij/systemd-to-sysvinit-converter

secure 13y ago
It got to a state where it is somewhat working, but it doesn’t handle a lot of cases. When I tried to use it for a simple real-world daemon, it didn’t work. AFAICT, nobody actually cares enough to continue development (though some people want to see it succeed).

npsimons 13y ago

This is one of many reasons why I love Debian. Very agnostic, very reasonable approaches to issues like this, and above all, whether or not systemd ends up as the default, I can almost guarantee people will still have the option to very easily switch to (or from) it in Debian. That being said, I can definitely second many of the top concerns listed, chief among them: non-greppable logs (binary formatted) and too much complexity/trying to do too much.

jlgreco 13y ago
I had no problems with systemd when I was using Fedora on my laptops (I never had to interact with it at all), though right now I'm using Debian without systemd and have no problems either. I don't really have a dog in this fight; it seems either solution is going to stay out of my hair and do what it needs to. Nevertheless, the concept of binary logs really annoys me and I have yet to see a satisfying explanation of why it should be necessary. The best I've seen is "well windows uses binary logging too" and "the syslog text format sucks", but neither of those satisfies. Windows does plenty of shit that should not be mimicked, and the benefits of text logging are severely dampened on Windows anyway (on account of Windows not being Unix.) Furthermore, the syslog text format sucking is not an argument for not using text logs in general, only an argument for not using the syslog text format specifically. Why can't we have a reasonable non-syslog text format for logs?
- anonyfuss 13y ago
  > Why can't we have a reasonable non-syslog text format for logs? I think the real question is: why is systemd defining a logging format at all?
  - jlgreco 13y ago
    Well, technically I suppose systemd doesn't, journald does (and systemd requires journald, and journald is made and shipped by the same people....). I'm not opposed to a "next-gen syslog", but yeah, that isn't a push that should be done in such close connection with systemd. A better approach would be to make rsyslog more than just a syslog daemon and build up a new protocol and storage format with it, with the full intention of standardizing it. (the syslog protocol is a pain in the ass, particularly that hard limit on facility numbers... Fix that first, then roll from there. Make rsyslog treat syslog like Vim treats vi: capable of falling back to compat mode, but better by default.)

kunai 13y ago

I wonder why no distributions have adopted launchd as their SysV init replacement. Not only does it combine cron, at, and other daemons into init itself, but it's also licensed liberally and would serve as a quite decent replacement for init. It's also cross-compatible with BSD and Linux systems. Is it perhaps the stigma that comes with using a product developed by Apple?

jff 13y ago
> Not only does it combine cron, at, and other daemons into init itself I think I found the reason.
- kunai 13y ago
  When is that last time you used cron to schedule jobs? Be honest.
  - jff 13y ago
    I use it to this day to keep my dynamic DNS records up to date. I also use it daily, although not explicitly, when the various Debian cron jobs run. Logrotate, that kind of thing. It's the idea that all this shit should be rolled into init, the goddamn boot process, that revolts me.
  - e1ven 13y ago
    Earlier this morning? It might be because I'm an ops guy, but I use Cron to schedule things on a regular basis, even in my personal work. It's pretty crazy good at what it does. Being able to say "Filter my email every 5 minutes", is awesome. */5 * * * /usr/local/bin/filter-email.sh
  - jlgreco 13y ago
    Thursday.
  - runjake 13y ago
    On non-OS X and non-Windows OSes? Probably daily. Heck, I even use cron (via Cygwin) on my Windows box at work.