[sanderjd]

I think the newer alternatives are more standard, easier to understand, easier to write for my own services, and less error prone than sysvinit scripts. You may disagree with all of those points, but it really isn't a "you're an old fart and this is how we're doing it today" explanation. By all means, argue against the specific reasoning, but claiming there is none and it is just progress for its own sake is spurious.

[VLM]

"the newer alternatives are more standard"

This statement doesn't seem to match the actual controversy, unless it was sarcasm.

[eropple]

I believe he meant "more standardized". I find that working with systemd is more predictable than with sysvinit and things that I expect to be able to do work as I expect them to work.

[VLM]

Ahhh like "more formally defined". Interesting. I've not run in that particular problem with svsvinit in the last couple decades, so I didn't see the synonym.

[bkor]

Loads of sysvinit scripts are distribution specific. With systemd, these are now shipped upstream. No clue what your problem is, but there are loads of benefits to systemd, suggest to try it out (and then recent version, not some old Fedora).

[crististm]

If the startup scripts are upstreamed and standard then the init system should be standard. Systemd is not standard because it relies on Linux kernel specific semantics.

BSD or any other kernels are left with no updated userland because they don't implement the same semantics.

[bkor]

You realistically expect BSD to ever use a GPL licensed init system? I don't see the point of systemd being able to run under BSD. BSD wants to get rid of every GPL licensed software, including GCC. You really expect them to consider switching their init system.

Aside from this, standard has nothing to do with Linux only or not. E.g. Microsoft Office is a de facto standard, it only runs on Windows and a not exactly the same version is available on Mac OS. Not on Linux, not on BSD. The file format is a standard.

[eropple]

Sure. Don't get me wrong, I can write scripts to work with sysvinit too, but there's a lot more reading and cookbooking involved. I haven't had the same issue with systemd or upstart.

[sanderjd]

Ah, yeah, sorry, that totally wasn't clear. Perhaps a better word would have been "consistent".

[crististm]

> argue against the specific reasoning

What's with the /usr that should be mounted at start? What was wrong with /? And why should initd depend on the kernel?

[Jasper_]

/usr should be mounted at the start since there's various things that are necessary during bootup, like udev rules.

See http://freedesktop.org/wiki/Software/systemd/separate-usr-is... for a more complete explanation.

There's no equivalent for /usr/share, which some programs depend on. You could make /share, or you could just use /usr for everything and have it available at early boot. Putting everything "system" in /usr/ also lets you make backups more efficiently instead of having to blacklist /home/, /sys/, /proc/, etc.

The initd needs to depend on the kernel. POSIX semantics aren't enough. Even Upstart and SysV init change their behavior based on the kernel.

Furthermore, it makes sense for the responsibility of services to be delegated to one place, otherwise you end up in this situation where programs are started differently from cron than they are from /usr/bin/service than they are from init. It makes sense to delegate all the complex service management and watchdog stuff to one location, and that requires kernel-level semantics. For instance, systemd's use of cgroups allows CGI that it forks off to be killed when it tries to stop Apache.

[VLM]

I may be misreading you, but I think you're trying to ask why the survey was making technical decision justifications based on purely subjective opinions rather than a survey based on objective facts, balancing the cost to humanity of the few remaining /usr splitters having to reconfigure, vs the slightly increased effort of the very small number of people who write initscripts having to continue to use the old system plus or minus the increased effort by the existing stock of programmers having to learn systemd which the other distros having switched has been forced on everyone anyway. I think both sides of the balance have pretty small numbers.

A la the famous Landley rant from about 4 years ago, I had a NFS mounted /usr... back in 97 as an experiment which I rapidly terminated. Shared and RO /usr is an interesting hack, but probably not worth holding init development back, especially since so many other boot time things demand /usr anyway now (like the pulseaudio, like the networkmanager thing)

If you were aiming more at why systemd needs different stuff, you can google for Landley's email around 2010 on the topic and on the other side google for read only /usr and NFS /usr. Also google for cgroups, especially systemd and cgroups.

[crististm]

I'm saying that just because a bunch of people say they have a new shine thing, I should not be _forced_ to use it. They are free to do whatever they want as long as they don't force me on their bandwagon.

BSD should not have to implement Linux semantics just to start the userland.

[Shish2k]

You will never be forced to use systemd. You may have to stick with running debian 7 forever and backport your own bugfixes though :P

Unless you're suggesting that developers forcing users to upgrade is bad; users forcing developers to continue providing support for deprecated software forever is good?

> BSD should not have to implement Linux semantics just to start the userland.

If neither BSD nor Linux supported files, and then Linux added support for files, would you suggest that we refrain from making file-based software, and continue giving all apps raw disk access for sake of compatibility?

Using cgroups for service management is that kind of fundamental good idea - the BSDs don't have to copy the linux API, but they should really provide something similar

[jeltz]

systemd does NOT require /usr to be mounted at start. That is just a myth.

http://freedesktop.org/wiki/Software/systemd/separate-usr-is...