All of a sudden everybody and his dog requires systemd or upstart or whatever flavor of rebranded and upgraded and extended and whatnot initd of the day.
I failed to see a reason behind this movement except of the "you're an old fart and this is how we're doing it today" explanation. And when BSD comes up and say this is not portable, everybody say we're on Linux and we don't care and you should jump the shark as we do. What?!
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.
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.
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.
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).
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.
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.
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.
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.
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
Sure, you can browse the web with IE5; if all your favourite sites work with it and they aren't changing, then you wouldn't see any reason to change either.
Meanwhile, a fairly significant number of people would like to be able to use the features in CSS3 / HTML5 - and while 75% of those features can be emulated in IE5 (with several megabytes of javascript libraries and terrible performance), life is easier and better all round if the users upgrade their foundations once in a while.
> BSD comes up and say this is not portable
systemd doesn't care about the kernel per se, only which features it provides. If they want to provide a cgroups-like API (which they should, because it's a great idea in and of itself), then I expect systemd will be ported to it fairly quickly.
Sticking to Gentoo for my personal systems (for many reasons, not just this issue). Slackware was my OS of choice once upon a time (there weren't many choices back then, though.)
I failed to see a reason behind this movement except of the "you're an old fart and this is how we're doing it today" explanation. And when BSD comes up and say this is not portable, everybody say we're on Linux and we don't care and you should jump the shark as we do. What?!