Hacker News Reader

> - 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.

So does FreeBSD's rc system with rc.subr and it's far simpler IMO.

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.

sysvinit does not handle cron jobs. A cron daemon does. Nothing stops you from using for example cronie with systemd.

So then you have two places to look to figure out where a scheduled task is running?

And in crond you have three places to look. So?

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).

Good comment. I think part of the problem is that some systemd proponents are pushing using it for far too many things. Such as replacing cron or configuring network interfaces. Here's why I was complaining about the network configuration thing on Arch:

https://wiki.archlinux.org/index.php/Network_configuration#P...

in addition, systemd can also execute timer units periodically. This is functionality that sysv init lacks.

You present this as if this makes sysvinit somehow lesser because of it lacks the ability to execute timer units. Sysvinit doesn't have that because that capability is completely unrelated to what sysvinit does. Although one could argue that the system as a whole provides that functionality through cron anyway, so there'd be no need to have sysvinit do it.

I have in my mind CoreOS which does not provide a cron daemon nor any way to install one. So using systemd timers is the only way to get cron functionality.

And replace them with something sprawling, tangled, unauditable and 5x the size.

FreeBSD removed the "crud" by standardizing all of the tasks people want to do into rc.subr. As a result you get some pretty clean and easy to understand rc/init scripts except in extreme circumstances.

> 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.

> (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.

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#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?

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.

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 And/or have your IPs configured by a DHCP server.

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.

> 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.

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.

> 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.