| |||||||||||||
Myths not debunked but confirmedMyths not debunked but confirmedPosted Jan 27, 2013 15:55 UTC (Sun) by niner (subscriber, #26151)In reply to: Myths not debunked but confirmed by man_ls Parent article: Poettering: The Biggest Myths
If Upstart is so great, why is it only used by Ubuntu and a few small others while systemd got adopted by openSUSE, Mageia, Arch, Fedora and others. Except for Fedora, NIH cannot explain any of these. Noone at openSUSE was enthusiastic about including Upstart, probably simply because Upstart doesn't solve any problem. SUSE already had parallel startup for a decade. systemd on the other hand solves real problems and helps getting rid of a really overcomplicated and fragile part of the system.
(Log in to post comments)
Myths not debunked but confirmed Posted Jan 27, 2013 16:10 UTC (Sun) by man_ls (subscriber, #15091) [Link] So apparently Fedora, Red Hat (plus all derivatives), Debian, Maemo, ChromeOS, NixOS, WebOS are just "a few small others"; while OpenSuse Mageia, Arch are "major ones"?Allow me to reverse your argument: if Upstart was so lousy, why was it adopted by Fedora, Red Hat, Debian and Ubuntu at all?
Myths not debunked but confirmed Posted Jan 27, 2013 16:26 UTC (Sun) by niner (subscriber, #26151) [Link]
Please read the article these comments are about. They used it, because it seemed to be better than what they had, but it was not good enough to be the solution they were really looking for.
Fedora does not use Upstart anymore. Red Hat will follow. AFAIK Debian still uses SysV init.
Myths not debunked but confirmed Posted Jan 27, 2013 18:30 UTC (Sun) by smurf (subscriber, #17840) [Link]
Debian has all three of them. They think about switching to systemd and auto-generate the others' config files (which requires limiting the alowed stanzas to some subset). After the Wheezy release. Whenever *that* is.
Good idea if you ask me.
Myths not debunked but confirmed Posted Jan 28, 2013 20:25 UTC (Mon) by drag (subscriber, #31333) [Link]
No.
It's a _TERRIBLE_ idea.
If Systemd is such a burden, then why the hell is maintaining no less then three different init systems better?!
Between sticking with sysvinit, going upstart, or going systemd, Debian has choosen the worst possible outcome. I mean this is just mind boggling terrible decision making on the part of Debian. Choosing to do _anything_ else would of been a better move. A drunk hobo rolling dice would of done a better job.
And this is really sad thing for me to say, because Debian is one of the few distros that I actually like using.
Init systems in Debian Posted Jan 28, 2013 21:23 UTC (Mon) by man_ls (subscriber, #15091) [Link] Well, if things work well you will not feel the burden of maintenance, any more than with the myriad of desktop environments that Debian supports. You may argue that it is a waste since (GNOME|KDE|XFCE|...) provides anything that a grown adult may desire, but proponents of the others will not agree.And before you say that an init system is a core component... Debian maintains three different kernels, and one of them is not even widely used. Users familiar with one of the init systems will appreciate its existence. Interested users will be able to compare init systems side by side. The rest will be grateful for being able to migrate at their own pace. That for me is enough reason to have all three.
Init systems in Debian Posted Jan 28, 2013 21:42 UTC (Mon) by drag (subscriber, #31333) [Link]
I'd rather just have a system that actually works. I don't care about the implementation details as long as I don't have to deal with the implementation details.
By not choosing Debian has more then tripled the amount of workload they have to deal with to make the system function properly. This not only increases their workload, it exponentially increases the amount of bugs a person is likely to run into. It makes it harder to write software for the system because now you have at least 3 different operating systems personalities you have to deal with.
Throwing scripts at it to try to automate the creation of other scripts for upstart and sysinv just means that now instead of just supporting 3 different init systems they have to support 3 different init systems and a bunch of new scripts.
To put it another way:
* It makes the workload they have to deal with much higher. This is Debian's developers problem. Maybe they prefer to play around with init systems rather then having a working OS. I can't fault them for how they want to spend their time, but... if their goal is to have a stable working OS with lots of software and third party support it's not something that is going to help them any meaningful respect in that regard.
* It increases the burden of third parties writing and maintaining services much harder. This is something that anybody trying to use or support Debian is now forced to deal with.
* It exponentially increases the amounts of bugs any person is likely to run into with Debian init's system. This is something that will bite end users and will likely contribute to issues for people that try to use Debian in production.
This is why it's a bad decision. It makes the OS worse, not better. Maintaining different kernels is very silly also if your goal is to have anything other then a toy OS, but at least the non-linux-kernel-debian folks can be marginalized by the fact that nobody actually uses that stuff. Unlike KFreeBSD I expect that they will have users that actually expect that sysvinit, systemd and/or upstart works.
And what is the benefit? So I can compare init systems side by side? Doesn't seem like much of a return of on investment.
Init systems in Debian Posted Jan 28, 2013 22:05 UTC (Mon) by smurf (subscriber, #17840) [Link]
Debian didn't decide. Or rather, they discovered that any attempt to force a decision would fail, so they decided not to decide.
In any case, I am fairly optimistic that post-Wheezy the "best practice" way to start a service in Debian will be a native systemd script, with auto-generated SysV-ish shell scripts and/or upstart-esque config files, whenever there are no special requirements.
How much time will elapse until then, I have no idea and refuse to speculate about. This is Debian, after all. :-/
Init systems in Debian Posted Jan 28, 2013 22:08 UTC (Mon) by man_ls (subscriber, #15091) [Link] As stated above, the same argument could be made for desktop environments, text editors, graphical editors, spreadsheets and every other redundant set of programs; not only for kernels. Perhaps you are interested in a distribution that offers just one set of integrated, polished components. That is not Debian in my experience. And that is its strength, despite the burden of development.As to that burden, I expect that it will not be so difficult to develop for three init systems given that both Upstart and systemd claim to be SysV init-compatible. Even if the script automation script does not work out. I have had to customize init scripts every once in a while, this should not be too different.
Init systems in Debian Posted Jan 28, 2013 23:00 UTC (Mon) by ovitters (subscriber, #27950) [Link]
Various components have support for systemd. Some still fall back to other methods at runtime, some do not. This does add a lot of complexity, potential bugs, etc. I noticed this when Mageia switched to fully systemd in the development version. That just took a few days, because quite easy if the goal is systemd only. If you want to support all, I guess you might need to write some code because not every component (package) compiled with systemd support has that support as a runtime extra feature.
Init systems in Debian Posted Jan 29, 2013 16:51 UTC (Tue) by drag (subscriber, #31333) [Link]
The goal of the operating system is to make it easier to write and run applications/services. Anything that is done to make those activities more difficult then necessary is full of fail.
Myths not debunked but confirmed Posted Jan 29, 2013 0:01 UTC (Tue) by rahvin (subscriber, #16953) [Link]
As long as I've been using Debian there has been a default set of install options, but ultimately it was possible to replace nearly everything with "non-standard" components using the Debian archives.
In other words, even though they pick a "default" they understand that every user will have different preferences and where there is developer support for it they provide the options. Honestly if they had more volunteers they'd provide even more options. Hell, they even have a hurd port and no one has a hurd port.
That's the beauty of Debian, they don't pick sides, they pick a default for a base install then allow the user to rip out and replaces with options fairly painlessly. That's the Debian way I'm familiar with, not the Debian way you are advocating.
Myths not debunked but confirmed Posted Jan 29, 2013 17:56 UTC (Tue) by Wol (guest, #4433) [Link]
Going systemd is not an option. It only works on a subset of the systems supported by Debian.
Dunno about upstart - that may have the same problem.
So the only thing that will actually work across ALL supported platforms is SysV. But you've got to give people the OPTION of the others.
Cheers,
Myths not debunked but confirmed Posted Jan 30, 2013 8:36 UTC (Wed) by micka (subscriber, #38720) [Link]
Different systems could have a different default init system. After all, they already have a different default kernel.
Myths not debunked but confirmed Posted Jan 27, 2013 19:13 UTC (Sun) by man_ls (subscriber, #15091) [Link] I read the fine article, thanks. If Upstart was not good enough, why not improve upon it instead of building their own init system? The explanation in the "debunking" is not good enough; manual dependencies might be substituted with automatic dependencies, I don't see any technical hurdles there. The general ideas behind Upstart are still good. At the same time I don't see Upstart gaining all the "features" going on to span through 69 binaries.Debian has Upstart in testing right now, though not as the default.
Myths not debunked but confirmed Posted Jan 27, 2013 20:03 UTC (Sun) by Jonno (subscriber, #49613) [Link]
> If Upstart was not good enough, why not improve upon it instead of building their own init system?
They did for a few years, until they realised actually fixing some of their issues would have meant rewriting upstart from scratch, breaking compatibility with the original upstart in subtle ways. That would have been systemd in all but name anyway...
> Debian has Upstart in testing right now, though not as the default.
Myths not debunked but confirmed Posted Jan 27, 2013 23:39 UTC (Sun) by anselm (subscriber, #2796) [Link]
Systemd : Upstart : SysV-Init = Git : Subversion : CVS.
Myths not debunked but confirmed Posted Jan 28, 2013 9:45 UTC (Mon) by danpb (subscriber, #4831) [Link]
Couldn't agree more, i've frequently used this analogy myself when talking about SystemD to people. Just like GIT there's a bit of a learning curve because of the new concepts involved, but once you're past that, you'll never want to go back to the old ways.
Myths not debunked but confirmed Posted Jan 28, 2013 18:10 UTC (Mon) by ThinkRob (subscriber, #64513) [Link]
This would be a better analogy if CVS and Subversion were portable and Git was not, and the standard response to complaints about the complete inattention to portability were "yeah, well just use Linux because I don't want to hold Git back by making it run on obsolete OSs -- besides, you can always just keep using SVN".
Myths not debunked but confirmed Posted Jan 28, 2013 18:44 UTC (Mon) by apoelstra (subscriber, #75205) [Link]
> This would be a better analogy if CVS and Subversion were portable and Git was not, and the standard response to complaints about the complete inattention to portability were "yeah, well just use Linux because I don't want to hold Git back by making it run on obsolete OSs -- besides, you can always just keep using SVN".
Git technically works on non-POSIX systems, but it's painfully slow. CVS and Subversion were equal-opportunity crap.
Myths not debunked but confirmed Posted Jan 28, 2013 20:30 UTC (Mon) by drag (subscriber, #31333) [Link]
> This would be a better analogy if CVS and Subversion were portable and Git was not,
Sysvinit scripts are _NOT_ portable.
Myths not debunked but confirmed Posted Jan 28, 2013 20:39 UTC (Mon) by HelloWorld (guest, #56129) [Link]
Making systemd portable is essentially impossible (myth 16) and if it weren't, it'd be pointless (myth 13). So will you *please* stop bringing up this nonsense?
Myths not debunked but confirmed Posted Jan 28, 2013 12:13 UTC (Mon) by dgm (subscriber, #49227) [Link]
Well, I'm not so sure the analogy is correct. Git is build on a very simple core, with cleverly simple data structures, even if the porcelain is complex. Could it be more like:
SystemD : Upstart : SysV-Init =? Emacs : Vim : ed
Myths not debunked but confirmed Posted Jan 28, 2013 13:38 UTC (Mon) by anselm (subscriber, #2796) [Link] The main point of the analogy is that, just as Subversion is basically CVS with the most glaring problems papered over, Upstart is basically SysV-Init with the most glaring problems papered over. On the other hand, like Git, systemd represents a completely different way of attacking the problem at hand.
Myths not debunked but confirmed Posted Feb 2, 2013 10:04 UTC (Sat) by Kwpolska (guest, #89145) [Link] Vim is better than Emacs, but Upstart is worse than systemd.
systemd/upstart adoption Posted Jan 27, 2013 18:18 UTC (Sun) by HelloWorld (guest, #56129) [Link]
Maemo and WebOS are dead, Red Hat will switch to systemd with RHEL 7, Fedora already did, as did NixOS just days ago (http://www.mail-archive.com/nix-dev@lists.science.uu.nl/m...). Debian offers systemd in its unstable branch (they also have to ship sysvinit for the time being because of kFreeBSD). What does that leave? ChromeOS, because Scott James Remnant works there. Surprise, surprise...
systemd/upstart adoption Posted Jan 29, 2013 11:53 UTC (Tue) by oak (subscriber, #2786) [Link]
Systemd wasn't an option for Maemo because Systemd came after Maemo.
systemd/upstart adoption Posted Feb 5, 2013 0:55 UTC (Tue) by sonnyrao (subscriber, #11351) [Link]
I think that's pretty unfair to ChromeOS. Scott doesn't even really work on the system initialization part of ChromeOS, he's been working on Bluetooth support for quite a while. I think the reason systemd hasn't been investigated is more likely because the current system works and making system services boot faster hasn't been one of the most pressing problems for the project.
systemd/upstart adoption Posted Feb 5, 2013 19:00 UTC (Tue) by khim (subscriber, #9252) [Link] Fast boot is one of the important goals of ChromeOS. Systemd was not investigated because it will needs fine-tuning to work faster then the existing optimized boot and nobody have done the required work.
Myths not debunked but confirmed Posted Jan 27, 2013 21:10 UTC (Sun) by misc (subscriber, #73730) [Link]
Upstart is not bad, but not great. There is some design issues.
For one, the way it track process is by using ptrace. That's not a bad idea, but this doesn't work great for some kind of software. There is 2 bugs opened since 4 years about that ( https://bugs.launchpad.net/upstart/+bug/406397 and https://bugs.launchpad.net/upstart/+bug/703800 ).
Then upstart do not permit to have a daemon installed but not started. The state and the config file are conflated. See http://utcc.utoronto.ca/~cks/space/blog/linux/UpstartCoup... on the details.
On the same type of issue, there is this http://utcc.utoronto.ca/~cks/space/blog/linux/UpstartDepe... , ie, upstart config are just script, so that's the same problem.
The root cause is something solved by systemd, with the .include and the new directory system ( ie, using /etc/system/foo.unit.d/foo ).
Upstart config file are also harder to parse ( ie, this is a full blown DSL ), which doesn't help to create a tool to audit or modify them. While auditing is not something I ever seen, I know that some organisations requires this, so every roadblock that can be removed is better. And as someone involved into automated package checking, having a parsable format is better.
One last issue is the whole copyright assignation to Canonical, that AFAIK is always annoying since company exec tend to avoid letting people work on such projects ( and IMHO for good reasons ).
RHEL and Fedora did used Upstart for a time, Opensuse and Debian also looked at it at the same time. So if they collectively decided to not switch or to use something else, there is likely a technical reason.
Perhaps a myth after all Posted Jan 28, 2013 0:00 UTC (Mon) by man_ls (subscriber, #15091) [Link] Thanks for a very civil and informative answer. It makes me think that myth #9 is perhaps a myth after all.
Myths not debunked but confirmed Posted Jan 28, 2013 1:25 UTC (Mon) by mezcalero (subscriber, #45103) [Link]
To underline this, I think the sources of Upstart are really nice. It's very readable, well documented, has many tests. In many ways it's exemplary.
We didn't have any problems with the quality of code or anything. Heck, we have so much more bad code in our stack, Upstart totally stands out in quality. So, the implementation is fine, however the overall design was not, in our eyes, and that's very hard to fix without resulting in well, basically a pretty complete rewrite, and that's what we then did, after much consideration.
Myths not debunked but confirmed Posted Jan 28, 2013 10:23 UTC (Mon) by dmitrij.ledkov (subscriber, #63320) [Link]
In upstart, there is now support for /etc/init/foo.override file.
It's an overlay which can shadow any part of the job. E.g. echo "manual" >> /etc/init/foo.override will make sure that foo is never automatically started, only manually when a user does it explicitly.
For the NFS related dependency problem you outlined, sounds like you need a couple .overrides with modified "start on" conditions.
Myths not debunked but confirmed Posted Jan 28, 2013 10:15 UTC (Mon) by regala (subscriber, #15745) [Link]
you don't seem to even remotely know what you are talking about... Fedora, upstart ? Debian, upstart ? mmmm, 2013, man, 2013.
Myths not debunked but confirmed Posted Jan 27, 2013 20:44 UTC (Sun) by jubal (subscriber, #67202) [Link]
Upstart is used in ChromeOS too.
|
|||||||||||||