Hacker News Reader

Comment by mcclung | Hacker News Reader

It's getting harder and harder to find a distro where systemd isn't a hard requirement. I am hoping Debian will keep the choice of sysvinit available.

View on HN

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.

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

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

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

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

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

"the newer alternatives are more standard"

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

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.

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.

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

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.

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.

Firstly, SystemD is licensed under the LGPL so it's not as viral. Secondly, they've already changed project licenses before in 2012. Should the need arise to switch over to a more permissive license, they could ask again and strip out the code the can't get permission to change.

systemd upstream flat out said they don't care about != Linux. That is highly unlikely to change.

Perhaps it's for the same reason there would be no (FOSS) Intel or Radeon support, due to the FreeBSD kernel lacking features needed by those drivers. However in FB9 they did get around to supporting KMS and are in the process of porting the latter over with the former already working.

My only concern would be if the developers flat out said no about going with a more permissive license, although I don't really see why they would do so as it is a program with limited applications outside of its intended role.

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

> I failed to see a reason behind this movement

sysvinit -> systemd = IE5 -> Chrome.

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.

Slackware.

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

Reply on news.ycombinator.com