Debian To Replace SysVinit, Switch To Systemd Or Upstart 362
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."
Ugh (Score:5, Insightful)
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
Why keep making simple things complicated? (Score:5, Insightful)
sysvinit is dead; long live sysvinit!!! (Score:3, Insightful)
Tell me I'm not the only one still clinging to sysvinit?
The new "replacements" (alternatives) are ghey++ and will no doubt be replaced in due time.
I dno't want to hear about a few seconds faster boot time. I want my *nix startup to be configurable, scripted, and simple. sysvinit takes the cake;.It's documented, and sysvinit is so simple it doesn't really require documentation, anyway.
"the Canonical bias present on the committee" (Score:4, Insightful)
Upstart (Score:4, Insightful)
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... (Score:5, Insightful)
Re:Canonical might suck... (Score:5, Insightful)
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... (Score:4, Insightful)
It's the fact that Upstart sucks which means that Upstart sucks.
At least from an embedded perspective (which is the majority of linux systems) the system should start only that which is necessary rather than everything that is possible. It also suffers from the classic stampede mistake when it becomes possible to start a whole load of new services after a shared dependency is started.
Re:Ugh (Score:5, Insightful)
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.
Re:Lennart Poettering explains why Upstartd is bad (Score:4, Insightful)
Wow, with such a superior, arrogant and manipulative attitude, I think it is time for Debian to write their own, or continue with what they have. I would have nothing to do with someone who has so little respect for anyone else's efforts, using FUD against other projects, and who is so obviously trying to lure people into his self-serving spider-web trap. Perhaps his vision is that systemd will be the one process to rule them all, my precioussssss... and then finally Linux will be all his. Run away!!!
Startup times are important (Score:4, Insightful)
I agree that complexity is evil. I have no experience with systemd nor with upstart, so I cannot comment on them. However, dependency graph and parallel execution should not be THAT difficult or complex
--Coder
Troll much? (Score:2, Insightful)
It's a well thought out post.
Control groups of course are at the center of what a modern server needs to do. Resource management of services is one of the major parts (if not the biggest) of service management, and if you want to stay relevant on the server you must have something in this area.
-systemd apparently does this?
-upstart does not.
For me, this is exactly the right direction, but I'm biased to server applications. ...The kernel folks want userspace to have a single arbitrator component for cgroups...
-systemd has this
-upstart apparently does not. He has grave doubts about upstart being able to do it.
I don't understand what he wrote.
ether you take the path where you use the stuff that the folks doing most of the Linux core OS development work on (regardless if they work at Red Hat, Intel, Suse, Samsung or wherever else) or you use the stuff Canonical is working on (which in case it isn't obvious is well... "limited").
It's an accurate assessment. How is that FUD?
Re:Canonical might suck... (Score:5, Insightful)
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.
Re:Canonical might suck... (Score:4, Insightful)
Why not just make the journal in a standardized format, that can be read by any other system? If I need to look inside a .zip or .tar.gz file, I don't need tools on a specific computer to do that; I can copy those files to any computer and look at them with zip/unzip or tar/gzip. Why should it be any different with systemd logfiles? You shouldn't need to use the computer that generated those files to read the files, just the same tool on another computer. If that's a problem, then there's a serious failure in implementation.