6 ms·

Not again... I think this was already decided.. Can we just move on? I've switched to systemd on my laptop months ago and had not a single problem. Boot times a

by buster 12y ago

Not again... I think this was already decided.. Can we just move on? I've switched to systemd on my laptop months ago and had not a single problem. Boot times are noticably faster. Does Linux have to stay at software from the sixties forever? Can't we just move on to systemd and wayland and whatever fits better into the 21st century?! I really feel this is all too political and FUD after months and months of senseless complaining about systemd and particularly far too personal regarding Lennart Poettering. If people like SysV init so much there will always be alternatives but this shouldn't hinder the majority of users to move forward with systems that just work with systemd (e.g. Debian+Linux). Nobody really uses Debian/kFreeBSD anyway, for example. Yet, it's a common statement that is brought up.

untothebreach 12y ago
I would be thrilled if Debian gave users the choice of init systems. I switched to systemd a couple months ago as well, and had nothing _but_ problems. My laptop never turns off, so boot times are irrelevant to me, and I would like to have a linux system that actually allows me to listen to audio, obtain an IP address, etc. I would gladly switch back to Debian if I could swap systemd out for something else.
- pantalaimon 12y ago
  systemd in Debian is still in testing, it's expected to be buggy at this point. Have you tried a distribution which already comes with systemd preconfigured, such as Fedora, Suse or CentOS?
  - untothebreach 12y ago
    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
  - vezzy-fnord 12y ago
    Fedora is known to be horribly unoptimized: http://freedesktop.org/wiki/Software/systemd/Optimizations/ http://freedesktop.org/wiki/Software/systemd/Optimizations/ I've also noticed that the unit ordering and dependency chains can be quite flimsy and slow, occasionally freezing entirely before the display manager is started.
    - krakensden 12y ago
      IIRC, Fedora 20, out of the box, will block your login screen on setting up wireless.
ultramancool 12y ago
Please do not dismiss legitimate issues as personal attacks. Just because you did not hit issues, doesn't mean others didn't. My experience was quite negative: - Binary log files, which are also prone to corruption and crashes - Unnecessarily complicated and unfamiliar init script structure. I feel like I went from one that was arguably too verbose to one which is too vague. - The need for unnecessary things like dbus to be run at startup - Complication of some simple configuration tasks (in my experience on Arch at least, network configuration was a bitch) - udev has apparently been hijacked and may cause issues for those who don't want systemd All in all, it feels like change for the sake of change to me, I see no advantages which I desire, and several minor to moderate disadvantages, but learning and using it is pushed on me for no reason. Personally, I've moved to running FreeBSD, it's simple and stable, though I've been considering Debian/kFreeBSD, I'd be sad to see it go. But it's the farthest of the issues with systemd IMO. As far as your boot time improvement goes, that's great, but modernly, my systems are either always online or suspended to RAM or disk, rarely rebooted.
- buster 12y ago
  Sorry, but all your reasons are no bugs or technical problems. Frankly, it seems to me that this is your inability to accept change. Yes, sometimes we need to embrace new things and learn new things. That doesn't mean they are bad. And sorry, but i don't see how 99,9999% of Debian users should stay on sysv init just because you might or might not use Debian/kFreeBSD at some point in the future (instead of FreeBSD in the first place). If i remember correctly kFreeBSD even is in such a bad unmaintained state the the discontinuation of it is discussed. Yet, you bring it up as an argument against systemd. (FYI: As of February 2014, popcon registered 130 kFreeBSD, compared to 32 HURD users, and 165,821 Linux users. ) P.S.: I reboot my laptop everyday, i don't suspend.
  - ultramancool 12y ago
    > Frankly, it seems to me that this is your inability to accept change. I'm more than willing to accept change if that change is at all beneficial. Systemd simply fails to offer any beneficial changes to me and several harmful ones. You're right, they're not so much technical issues or bugs as usability and system philosophy issues. But issues which should not be simply dismissed nonetheless. So, please, tell me, why should I accept change just for the sake of change? Especially when those changes seem to be against the philosophy of a simple, easy to understand system. EDIT: thought I should note this too > And sorry, but i don't see how 99,9999% of Debian users should stay on sysv init I'm not suggesting that they do. By all means, change the default if most users desire it. This post is simply about allowing for flexibility of init system. I don't see why you have such a problem with that.
monstermonster 12y ago
Not really a deep Linux user here but systemd brings the bad bits of windows to Linux: Abstract stateful configuration, black boxes and communications to do simple tasks. As someone who supports lots of software built on this approach (windows desktop) then I will assure you it's a pain in the butt big time. Sure it may work for you but if N machines have state A and P machines have state B then getting all N and P machines to state B is incredibly difficult. It looks easy until you do it. That's probably one of the largest and most common things we do when deploying more than a trivial single machine. To put it into perspective, everything becomes as much of a PITA as RPM packages without yum. That was immediately obvious to me when I installed CentOS 7 on a couple of test machines to replace our costly Riverbed appliances and timedatectl threw "failed to issue RPC" on one machine but not the other. Same steps to install. That's where we don't want to go. We are now running FreeBSD and nginx on a HyperV cluster.
- sethrin 12y ago
  Abstract stateful configuration might be a bad thing, but having a configuration file execute arbitrary, complicated code sounds like a much worse thing to me. I would be interested in differing opinions, but I think in another context the words "executable configuration file" would be a cause for deep concern.
  - monstermonster 12y ago
    I don't know of any executable configuration files on any Unix derivatives. There are init scripts, but they are not configuration; they are instructions. There are scripts with metadata attached (rc.d items) which may be ambiguous but that is no different from a shared library containing an export table or a set of runtime linker dependencies.
    - sethrin 12y ago
      Systemd unit files, as far as I am aware, are functional replacements for init scripts. They do contain executable code, which is perhaps unavoidable. However, they are primarily what you would call a configuration file. Given that they are functionally equivalent to init scripts, init scripts must also handle configuration. You're making a semantic argument, not a technical one. Why is it a good thing that your init system consist entirely of executable scripts? Because to me that sort of arbitrary executable code would be something to minimize: abstract out common functionality, DRY, and have each component do as little as necessary. If you believe otherwise, please support that idea.
andmarios 12y ago
Since you switched to systemd on your laptop and everything is ok, I have to inform you that on Wednesday I switched my PC to systemd and nothing was ok to the point where I had to install another Linux distro and lose some good hours in the process.

by buster 12y ago

untothebreach 12y ago

I would be thrilled if Debian gave users the choice of init systems. I switched to systemd a couple months ago as well, and had nothing _but_ problems. My laptop never turns off, so boot times are irrelevant to me, and I would like to have a linux system that actually allows me to listen to audio, obtain an IP address, etc. I would gladly switch back to Debian if I could swap systemd out for something else.

pantalaimon 12y ago
systemd in Debian is still in testing, it's expected to be buggy at this point. Have you tried a distribution which already comes with systemd preconfigured, such as Fedora, Suse or CentOS?
- untothebreach 12y ago
  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
- vezzy-fnord 12y ago
  Fedora is known to be horribly unoptimized: http://freedesktop.org/wiki/Software/systemd/Optimizations/ http://freedesktop.org/wiki/Software/systemd/Optimizations/ I've also noticed that the unit ordering and dependency chains can be quite flimsy and slow, occasionally freezing entirely before the display manager is started.
  - krakensden 12y ago
    IIRC, Fedora 20, out of the box, will block your login screen on setting up wireless.

ultramancool 12y ago

Please do not dismiss legitimate issues as personal attacks. Just because you did not hit issues, doesn't mean others didn't. My experience was quite negative: - Binary log files, which are also prone to corruption and crashes - Unnecessarily complicated and unfamiliar init script structure. I feel like I went from one that was arguably too verbose to one which is too vague. - The need for unnecessary things like dbus to be run at startup - Complication of some simple configuration tasks (in my experience on Arch at least, network configuration was a bitch) - udev has apparently been hijacked and may cause issues for those who don't want systemd All in all, it feels like change for the sake of change to me, I see no advantages which I desire, and several minor to moderate disadvantages, but learning and using it is pushed on me for no reason. Personally, I've moved to running FreeBSD, it's simple and stable, though I've been considering Debian/kFreeBSD, I'd be sad to see it go. But it's the farthest of the issues with systemd IMO. As far as your boot time improvement goes, that's great, but modernly, my systems are either always online or suspended to RAM or disk, rarely rebooted.

buster 12y ago
Sorry, but all your reasons are no bugs or technical problems. Frankly, it seems to me that this is your inability to accept change. Yes, sometimes we need to embrace new things and learn new things. That doesn't mean they are bad. And sorry, but i don't see how 99,9999% of Debian users should stay on sysv init just because you might or might not use Debian/kFreeBSD at some point in the future (instead of FreeBSD in the first place). If i remember correctly kFreeBSD even is in such a bad unmaintained state the the discontinuation of it is discussed. Yet, you bring it up as an argument against systemd. (FYI: As of February 2014, popcon registered 130 kFreeBSD, compared to 32 HURD users, and 165,821 Linux users. ) P.S.: I reboot my laptop everyday, i don't suspend.
- ultramancool 12y ago
  > Frankly, it seems to me that this is your inability to accept change. I'm more than willing to accept change if that change is at all beneficial. Systemd simply fails to offer any beneficial changes to me and several harmful ones. You're right, they're not so much technical issues or bugs as usability and system philosophy issues. But issues which should not be simply dismissed nonetheless. So, please, tell me, why should I accept change just for the sake of change? Especially when those changes seem to be against the philosophy of a simple, easy to understand system. EDIT: thought I should note this too > And sorry, but i don't see how 99,9999% of Debian users should stay on sysv init I'm not suggesting that they do. By all means, change the default if most users desire it. This post is simply about allowing for flexibility of init system. I don't see why you have such a problem with that.

monstermonster 12y ago

Not really a deep Linux user here but systemd brings the bad bits of windows to Linux: Abstract stateful configuration, black boxes and communications to do simple tasks. As someone who supports lots of software built on this approach (windows desktop) then I will assure you it's a pain in the butt big time. Sure it may work for you but if N machines have state A and P machines have state B then getting all N and P machines to state B is incredibly difficult. It looks easy until you do it. That's probably one of the largest and most common things we do when deploying more than a trivial single machine. To put it into perspective, everything becomes as much of a PITA as RPM packages without yum. That was immediately obvious to me when I installed CentOS 7 on a couple of test machines to replace our costly Riverbed appliances and timedatectl threw "failed to issue RPC" on one machine but not the other. Same steps to install. That's where we don't want to go. We are now running FreeBSD and nginx on a HyperV cluster.

sethrin 12y ago
Abstract stateful configuration might be a bad thing, but having a configuration file execute arbitrary, complicated code sounds like a much worse thing to me. I would be interested in differing opinions, but I think in another context the words "executable configuration file" would be a cause for deep concern.
- monstermonster 12y ago
  I don't know of any executable configuration files on any Unix derivatives. There are init scripts, but they are not configuration; they are instructions. There are scripts with metadata attached (rc.d items) which may be ambiguous but that is no different from a shared library containing an export table or a set of runtime linker dependencies.
  - sethrin 12y ago
    Systemd unit files, as far as I am aware, are functional replacements for init scripts. They do contain executable code, which is perhaps unavoidable. However, they are primarily what you would call a configuration file. Given that they are functionally equivalent to init scripts, init scripts must also handle configuration. You're making a semantic argument, not a technical one. Why is it a good thing that your init system consist entirely of executable scripts? Because to me that sort of arbitrary executable code would be something to minimize: abstract out common functionality, DRY, and have each component do as little as necessary. If you believe otherwise, please support that idea.

andmarios 12y ago

Since you switched to systemd on your laptop and everything is ok, I have to inform you that on Wednesday I switched my PC to systemd and nothing was ok to the point where I had to install another Linux distro and lose some good hours in the process.