Debian To Replace SysVinit, Switch To Systemd Or Upstart

An anonymous reader writes "Debian has been one of the last holdouts using SysVinit over a modern init system, but now after much discussion amongst Debian developers, they are deciding whether to support systemd or Upstart as their default init system. The Debian technical committee has been asked to vote on which init system to use, which could swing in favor of using Upstart due to the Canonical bias present on the committee."

Comments

Ugh

[ArchieBunker]

I fucking hate this new system. Its a mess of scripts that call on more scripts. Its such a pain in the ass now if you want to have a program run when the system starts. Gone are the days of just adding a line to /etc/rc.local

Re:Ugh

[icebike]

I fucking hate this new system. Its a mess of scripts that call on more scripts. Its such a pain in the ass now if you want to have a program run when the system starts. Gone are the days of just adding a line to /etc/rc.local

Half of that is because either SystemD or upstart is really only about half implemented, and the half that is implemented is often trying to replicate sysv just to keep the conversion and learning task to something approaching manageable. Its kind of a mess right now in many distros.

As more of the system targets are properly implemented, and users start to let go of the concept of run levels, and get used to dealing with target files and the concept of units, it will be every bit as tailor-able as run levels were, and a whole lot faster.

I didn't find run levels and rc.d all that intuitive at first (many long years ago) and the scripts were more complex.

Why keep making simple things complicated?

[Arker]

Init would have been my pick, but I still hope this works out well for them.

Upstart

[intangible]

So upstart has some things that need to be fixed (mostly the clean shutdown thing)...
Systemd is a monster that gets to infect more of you packages over time, plus you get the benefit of binary log files!

I hope they choose upstart and just fix it up a bit.

OpenRC has been proposed by some too, which seems like a nice sysvinit replacement, but event driven startup and shutdown of services (think laptops and hotswap stuff) is more important than just a fast startup time.

Re:Canonical might suck...

[heson]

Upstars solves some problems with sysv, but includes a whole array of new ones. Systemd solves almost all problems with few new ones, except for all the parts that is not implemented yet. Systemd is a mess for novices to use and understand, the helper tools are not as good as they should be.

Re:Canonical might suck...

[icebike]

This is very true.

Like much in the linux world these days, systemd was rushed into production before it was half completed by too many distros.
At least you have to give Debian the credit for waiting until most of it is working, and all the necessary patches have been identified.

(The less charitable way of viewing it is that Debian sat back and let others do the heavy lifting).

Probably the worst case would be for them to choose upstart when the rest of the industry decides on systemd. That kind of divergence
makes for much more work patching everything that needs to be patched.

Re:Canonical might suck...

[Junta]

So one prominent example is a push to discard syslog, but at the same time rejecting any suggestion that perhaps it might be nice if the same plain text that journalctl can produce be produced as a matter of course without syslog assistance.

Yes, journalctl has more readily accessible nice filters and faster performance. The issue is that the vast majority of people didn't ever need them and made due with grep and friends. Yes it's not good stuff to build a high-end solution out of, but by the same token journalctl power is more complicated to use.

Getting early boot messages would have been a straightforward thing to do in syslog land, it was just that no one bothered. It was a good thing to add, but generally either things work fine and you don't really care much about the early boot logs, or it fails to get root fs going in which case the logs from that time won't make it to the root fs hosted journal anyway.

I don't like the linux distros of today because they are largely reimplementing much of what people ridiculed microsoft for in the 90s (binary configuration, binary logs, more complex messaging model). While it is true that generally the details of the implementation are defensibly better than microsoft did, the differences are largely academic to the vast majority of system administrators. Vast majority sees opaque binary blob that is useless without a very close match in distribution to provide tools to analyze. Even when things are humming along fine, things like dbus provide capability in a nearly impossible to explore manner. Even with all this complexity, my linux server experience is no more useful than it was 10 years ago from a managability standpoint, but I've had to jump through hoops to try to track the complexity as it emerged bit by bit without a lot of nice capability to come along for the ride.