2 ms·

Yea, I didn't actually try systemd on Debian because of the unstable-ness. I actually tried it on Fedora, and like I said, had nothing but trouble. Normally I w

Yea, I didn't actually try systemd on Debian because of the unstable-ness. I actually tried it on Fedora, and like I said, had nothing but trouble. Normally I would fight through it, file bug reports, etc, but the benefits of switching to systemd didn't seem to be worth it. When I see debates about systemd, I rarely see compelling technical reasons from _either_ side. The only technical reason I can see to move to systemd is improved boot times, which doesn't seem worth it when (like someone else in this thread mentioned) most of your systems are either always on, or suspended to disk. EDIT: I should probably also say, my desktop GUI setup is rather sparse. I usually run a debian server edition with SLiM & XMonad, which starts up ridiculously fast no matter which init system I am using. So, systemd seems a bit like overkill for my usecase.

pantalaimon 12y ago
> The only technical reason I can see to move to systemd is improved boot time What about service isolation & monitoring and the unified journal? IMO those are huge improvements to the status quo.
- untothebreach 12y ago
  Those very well might be better, in the technical sense, but none of them seem particularly compelling to me. None of those solve a problem I am having (or have had). Change is fine, I will happily learn a new init system when it provides solutions to my problems, but switching because "the current init system is old" doesn't seem worth it to me.
- e12e 12y ago
  First, I think the work in Debian to support kfreebsd and hurd is pretty important. Fringe (for now), but important. But more importantly [ed:than what is good for just Debian], a Linux monoculture would be a bad thing. We need (open)solaris, openbsd, freebsd, netbsd and OS X - which means any Linux-only, not-very-portable solution to these things just should not be mainstream. Consider that jails on freebsd works with, but do not demand, zfs. Even if arguably zfs solved a lot more real nuisances and problems than systemd does. Last time systemd was mentioned, I addressed the issue of the journal, and how it being prone to corruption on bad crashes didn't really help its utility. There's room for improvement in init handling (see eg daemontools/runit) - and there may be a case to replace init. But so far I've yet to see any compelling arguments for systemd that have much to do with systemd. And their stance on portability, and complexity demonstrate to me an absolute ignorence of risk: portability, simplicity and small components are effective tools to mitigate risk. Probably the most compelling argument is that simple services can now have simple config files rather than complex redundant shell init scripts - but it must surely be possible to take a simple config and generate a correct script for most of those services that really benefit from simple configs (iow those that have pretty straightforward demands).
  - makomk 12y ago
    A Linux monoculture would be a bad thing for users, but it'd be very beneficial for big Linux-centric companies like Red Hat - if everything depends heavily on Linux-specific functionality, there's less risk of another Unix they can't offer like Solaris coming along and eating their lunch.
  - vertex-four 12y ago
    > but it must surely be possible to take a simple config and generate a correct script for most of those services that really benefit from simple configs The nosh init system[0] supports exactly this, although it outputs nosh scripts rather than shell scripts. nosh is an execline-style interpreter and set of commands for that interpreter that implements a simple init system where almost no code is run unless you explicitly ask for it to be run. It also supports configurable logging, socket activation, and some compatibility with other init systems - it could be a significant part of an alternative to systemd. [0] http://homepage.ntlworld.com/jonathan.deboynepollard/Softwares/nosh.html http://homepage.ntlworld.com/jonathan.deboynepollard/Softwar...
    - edwintorok 12y ago
      Interesting, this seems to be complementary with systembsd[0]. [0] http://undeadly.org/cgi?action=article&sid=20140915064856 http://undeadly.org/cgi?action=article&sid=20140915064856

pantalaimon 12y ago

> The only technical reason I can see to move to systemd is improved boot time What about service isolation & monitoring and the unified journal? IMO those are huge improvements to the status quo.

untothebreach 12y ago
Those very well might be better, in the technical sense, but none of them seem particularly compelling to me. None of those solve a problem I am having (or have had). Change is fine, I will happily learn a new init system when it provides solutions to my problems, but switching because "the current init system is old" doesn't seem worth it to me.
e12e 12y ago
First, I think the work in Debian to support kfreebsd and hurd is pretty important. Fringe (for now), but important. But more importantly [ed:than what is good for just Debian], a Linux monoculture would be a bad thing. We need (open)solaris, openbsd, freebsd, netbsd and OS X - which means any Linux-only, not-very-portable solution to these things just should not be mainstream. Consider that jails on freebsd works with, but do not demand, zfs. Even if arguably zfs solved a lot more real nuisances and problems than systemd does. Last time systemd was mentioned, I addressed the issue of the journal, and how it being prone to corruption on bad crashes didn't really help its utility. There's room for improvement in init handling (see eg daemontools/runit) - and there may be a case to replace init. But so far I've yet to see any compelling arguments for systemd that have much to do with systemd. And their stance on portability, and complexity demonstrate to me an absolute ignorence of risk: portability, simplicity and small components are effective tools to mitigate risk. Probably the most compelling argument is that simple services can now have simple config files rather than complex redundant shell init scripts - but it must surely be possible to take a simple config and generate a correct script for most of those services that really benefit from simple configs (iow those that have pretty straightforward demands).
- makomk 12y ago
  A Linux monoculture would be a bad thing for users, but it'd be very beneficial for big Linux-centric companies like Red Hat - if everything depends heavily on Linux-specific functionality, there's less risk of another Unix they can't offer like Solaris coming along and eating their lunch.
- vertex-four 12y ago
  > but it must surely be possible to take a simple config and generate a correct script for most of those services that really benefit from simple configs The nosh init system[0] supports exactly this, although it outputs nosh scripts rather than shell scripts. nosh is an execline-style interpreter and set of commands for that interpreter that implements a simple init system where almost no code is run unless you explicitly ask for it to be run. It also supports configurable logging, socket activation, and some compatibility with other init systems - it could be a significant part of an alternative to systemd. [0] http://homepage.ntlworld.com/jonathan.deboynepollard/Softwares/nosh.html http://homepage.ntlworld.com/jonathan.deboynepollard/Softwar...
  - edwintorok 12y ago
    Interesting, this seems to be complementary with systembsd[0]. [0] http://undeadly.org/cgi?action=article&sid=20140915064856 http://undeadly.org/cgi?action=article&sid=20140915064856