7 ms·

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:

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.
- vezzy-fnord 12y ago
  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. It's not, that was a lie. You're free to join #debian-kbsd on OFTC to see that development is ongoing and active, and that there's more than just one maintainer. They've switched to the 10.1 kernel and they frequently commit to Git.
- DanBC 12y ago
  > And sorry, but i don't see how 99,9999% of Debian users should stay on sysv init No one is asking anyone to stay on a particular init system. They are asking for choice, and systemd has some "features" that restrict choice.
nodata 12y ago
> - Unnecessarily complicated and unfamiliar init script structure. Unfamiliar, yes. Complicated? You have to be kidding me. systemd "scripts" remove the crud and hacks that the old init system built up over years.
- ultramancool 12y ago
  So does FreeBSD's rc system with rc.subr and it's far simpler IMO.
- andmarios 12y ago
  Run a cron job on sysvinit; add one line to /etc/crontab. Run a cron job on systemd; create two files: one timer unit (about 5-7 lines) and one service unit (about 5-7 lines) that you have to name identically (minus the extension) with the timer unit.
  - dnlrn 12y ago
    sysvinit does not handle cron jobs. A cron daemon does. Nothing stops you from using for example cronie with systemd.
    - devicenull 12y ago
      So then you have two places to look to figure out where a scheduled task is running?
      - nodata 12y ago
        And in crond you have three places to look. So?
  - JeremyNT 12y ago
    sysv init can launch a cron daemon which itself can run cron jobs. systemd can launch a cron daemon which itself can run cron jobs. in addition, systemd can also execute timer units periodically. This is functionality that sysv init lacks. If you select the same cron daemon, the configuration of cron jobs may be performed in an identical manner, regardless of which init system has launched that daemon. Are you complaining that the optional systemd timer functionality is difficult to use and that you would prefer to run cron jobs via a dedicated cron daemon? That may be a valid criticism, but I am a systemd user and I have never tried this functionality, so I cannot comment on it. I personally continue to use a cron daemon since this is what I am familiar with. Do you have a philosophical objection to the init system providing such capabilities? Maybe there is a valid reason to have such an objection, but I do not hold this perspective personally. Regardless, your comparison here is not valid, since you are comparing the process of configuring optional functionality in systemd (which has no equivalent with sysv) to the process of configuring a cron daemon (which you could just as easily be using with either init system).
deleted 12y ago
[deleted]
antihero 12y ago
> (in my experience on Arch at least, network configuration was a bitch) What exactly about this was hard? I have one config file - /etc/wpa_supplicant/wpa_supplicant-wlan0.conf - which you can add to simply with wpa_passphrase "MySSID" "MyKey" > /etc/wpa_supplicant/wpa_supplicant-wlan0.conf Then I ran a couple commands once: systemctl enable wpa_supplicant@wlan0 systemctl enable dhcpcd@wlan0 And now it happily connects to any of the wireless networks I've set up in the config file. If I want to control it or switch networks or reload my config, I can use wpa_cli to do this easily. Totally minimal, no need for NetworkManager or netctl or anything, and works flawlessly. Obviously if your net setup is more complex, this could require a better tool, but most of weird stuff would be done with iproute2 or whatever.
- ultramancool 12y ago
  I had a personal dev server running arch with a simple static IP. I had tutorials on arch telling me to manually create and edit systemd scripts to start and stop the interface, then add and enable them. To configure a simple static IP, which should be an extremely trivial task. Now compare with FreeBSD, just add 1 single line to /etc/rc.conf and I'm done, 2 if I want a default gateway too. Here's a link to what I was dealing with: https://wiki.archlinux.org/index.php/Network_configuration#Persistent_configuration_on_boot_using_systemd https://wiki.archlinux.org/index.php/Network_configuration#P... 20+ lines vs 2. You tell me which is simpler. Also, our of curiosity, do you know what systemctl enable does? What files does it modify and how would you do it on a remote system (ie: one you'd mounted)? Would you need to chroot?
  - dnlrn 12y ago
    You are comparing apples and oranges. Network management in Arch was replaced by netctl. It’s very easy to set up your static network that way (you just have to edit 1 line). systemctl actually tells you what it does as output. It symlinks a service file from one directory to another. You can always do that by hand.
- antihero 12y ago
  Frankly, that's a poor way to do it. A much better way would be to simply run `systemctl enable dhcpcd@eth0` and then edit the dhcpcd config. https://wiki.archlinux.org/index.php/Dhcpcd#Running https://wiki.archlinux.org/index.php/Dhcpcd#Running And/or have your IPs configured by a DHCP server.
dnlrn 12y ago
> Binary log files, which are also prone to corruption and crashes Why are they more prone to corruption? Software bugs aside they should actually be less prone to corruption, because they allow you to verify if corruption has happened. syslog has no such mechanism. > 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. Yeah, right... > The need for unnecessary things like dbus to be run at startup Why is dbus unnecessary? It’s a great way to do IPC. So great that it will be implemented in the kernel as kdbus. > Complication of some simple configuration tasks (in my experience on Arch at least, network configuration was a bitch) The init system was never responsible for setting up your network. Even before systemd, Arch recommended netcfg/netctl instead of setting it up in /etc/rc.conf.
- deleted 12y ago
  [deleted]
- deleted 12y ago
  [deleted]

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.
vezzy-fnord 12y ago
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. It's not, that was a lie. You're free to join #debian-kbsd on OFTC to see that development is ongoing and active, and that there's more than just one maintainer. They've switched to the 10.1 kernel and they frequently commit to Git.
DanBC 12y ago
> And sorry, but i don't see how 99,9999% of Debian users should stay on sysv init No one is asking anyone to stay on a particular init system. They are asking for choice, and systemd has some "features" that restrict choice.

nodata 12y ago

> - Unnecessarily complicated and unfamiliar init script structure. Unfamiliar, yes. Complicated? You have to be kidding me. systemd "scripts" remove the crud and hacks that the old init system built up over years.

ultramancool 12y ago
So does FreeBSD's rc system with rc.subr and it's far simpler IMO.
andmarios 12y ago
Run a cron job on sysvinit; add one line to /etc/crontab. Run a cron job on systemd; create two files: one timer unit (about 5-7 lines) and one service unit (about 5-7 lines) that you have to name identically (minus the extension) with the timer unit.
- dnlrn 12y ago
  sysvinit does not handle cron jobs. A cron daemon does. Nothing stops you from using for example cronie with systemd.
  - devicenull 12y ago
    So then you have two places to look to figure out where a scheduled task is running?
    - nodata 12y ago
      And in crond you have three places to look. So?
- JeremyNT 12y ago
  sysv init can launch a cron daemon which itself can run cron jobs. systemd can launch a cron daemon which itself can run cron jobs. in addition, systemd can also execute timer units periodically. This is functionality that sysv init lacks. If you select the same cron daemon, the configuration of cron jobs may be performed in an identical manner, regardless of which init system has launched that daemon. Are you complaining that the optional systemd timer functionality is difficult to use and that you would prefer to run cron jobs via a dedicated cron daemon? That may be a valid criticism, but I am a systemd user and I have never tried this functionality, so I cannot comment on it. I personally continue to use a cron daemon since this is what I am familiar with. Do you have a philosophical objection to the init system providing such capabilities? Maybe there is a valid reason to have such an objection, but I do not hold this perspective personally. Regardless, your comparison here is not valid, since you are comparing the process of configuring optional functionality in systemd (which has no equivalent with sysv) to the process of configuring a cron daemon (which you could just as easily be using with either init system).

deleted 12y ago

[deleted]

antihero 12y ago

> (in my experience on Arch at least, network configuration was a bitch) What exactly about this was hard? I have one config file - /etc/wpa_supplicant/wpa_supplicant-wlan0.conf - which you can add to simply with wpa_passphrase "MySSID" "MyKey" > /etc/wpa_supplicant/wpa_supplicant-wlan0.conf Then I ran a couple commands once: systemctl enable wpa_supplicant@wlan0 systemctl enable dhcpcd@wlan0 And now it happily connects to any of the wireless networks I've set up in the config file. If I want to control it or switch networks or reload my config, I can use wpa_cli to do this easily. Totally minimal, no need for NetworkManager or netctl or anything, and works flawlessly. Obviously if your net setup is more complex, this could require a better tool, but most of weird stuff would be done with iproute2 or whatever.

ultramancool 12y ago
I had a personal dev server running arch with a simple static IP. I had tutorials on arch telling me to manually create and edit systemd scripts to start and stop the interface, then add and enable them. To configure a simple static IP, which should be an extremely trivial task. Now compare with FreeBSD, just add 1 single line to /etc/rc.conf and I'm done, 2 if I want a default gateway too. Here's a link to what I was dealing with: https://wiki.archlinux.org/index.php/Network_configuration#Persistent_configuration_on_boot_using_systemd https://wiki.archlinux.org/index.php/Network_configuration#P... 20+ lines vs 2. You tell me which is simpler. Also, our of curiosity, do you know what systemctl enable does? What files does it modify and how would you do it on a remote system (ie: one you'd mounted)? Would you need to chroot?
- dnlrn 12y ago
  You are comparing apples and oranges. Network management in Arch was replaced by netctl. It’s very easy to set up your static network that way (you just have to edit 1 line). systemctl actually tells you what it does as output. It symlinks a service file from one directory to another. You can always do that by hand.
antihero 12y ago
Frankly, that's a poor way to do it. A much better way would be to simply run `systemctl enable dhcpcd@eth0` and then edit the dhcpcd config. https://wiki.archlinux.org/index.php/Dhcpcd#Running https://wiki.archlinux.org/index.php/Dhcpcd#Running And/or have your IPs configured by a DHCP server.

dnlrn 12y ago

> Binary log files, which are also prone to corruption and crashes Why are they more prone to corruption? Software bugs aside they should actually be less prone to corruption, because they allow you to verify if corruption has happened. syslog has no such mechanism. > 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. Yeah, right... > The need for unnecessary things like dbus to be run at startup Why is dbus unnecessary? It’s a great way to do IPC. So great that it will be implemented in the kernel as kdbus. > Complication of some simple configuration tasks (in my experience on Arch at least, network configuration was a bitch) The init system was never responsible for setting up your network. Even before systemd, Arch recommended netcfg/netctl instead of setting it up in /etc/rc.conf.

deleted 12y ago
[deleted]
deleted 12y ago
[deleted]