Langasek: Upstart in Debian

[Posted November 26, 2012 by ris]

Steve Langasek has announced that upstart is available in Debian unstable. "One of the consequences is that it's now possible to do meaningful head-to-head comparisons of boot speed between sysvinit (with startpar), upstart, and systemd. At one time or another people have tested systemd vs. sysvinit when using bash as /bin/sh, and upstart vs. sysvinit, and systemd vs. sysvinit+startpar, and there are plenty of bootcharts floating around showing results of one init system or another on one distro or another, but I'm not aware of anyone having done a real, fair comparison of the three solutions, changing nothing but the init system."

to post comments

Some changes needed...

Posted Nov 26, 2012 22:59 UTC (Mon) by s0f4r (guest, #52284) [Link] (51 responses)

To do a fair comparison, some changes are needed:

- boot on real hardware, not qemu. SSD vs. HDD.

- boot to some real desktop environment - not just bash, preferably with user sessions (which upstart now even does, apparently).

- I'd prefer if my version of bootchart could be used instead of the old version (https://github.com/sofar/bootchart). It provides much more detailed information and doesn't hide information or data.

Auke

Disclaimer: I rewrote bootchart version and work on systemd user sessions.

Some changes needed...

Posted Nov 27, 2012 0:49 UTC (Tue) by vorlon42 (guest, #28435) [Link] (3 responses)

I have intentionally disclosed the limitations of my methodology. You are welcome to reproduce this test in a more rigorous environment - that's the point, after all, that it's now practical to do such tests :)

Some changes needed...

Posted Nov 27, 2012 4:22 UTC (Tue) by airlied (subscriber, #9104) [Link]

well you've tested both of them barely booting anything, found systemd to be faster, but then say its not because of the shells. But if you are only booting a bare minimum, surely the shell impact will grow as the more services you start.

seems like a flaw in your own logic.

Some changes needed...

Posted Nov 27, 2012 4:37 UTC (Tue) by s0f4r (guest, #52284) [Link] (1 responses)

I think it's important - you've done significant work towards a hypothesis (I assume you want to demonstrate that one of the inits is the better), but fail to make a complete case - and stopped point blank where things get interested.

I'm personally interested in the comparison, but working fulltime on enabling systemd user sessions, and developing my bootchart version, and not working on any debian-based distro - so it's unlikely I'll be able to spend time with your work myself.

Also, posting raw data (which what my bootchart version does implicitly, as the SVG files it creates contain the raw data) is an important step in posting results. This will allow others to compare, verify your results.

Was this really the point?

Posted Nov 27, 2012 9:50 UTC (Tue) by gevaerts (subscriber, #21521) [Link]

The way I read it, the main point was to tell the world that things now work, and although the part about benchmarking was longer I took it as being secondary, and mainly meant as a starting point for later work (presumably by other people), which is why the benchmarks being for a minimal system and the raw data missing didn't seem very important to me.

Some changes needed...

Posted Nov 27, 2012 12:33 UTC (Tue) by vonbrand (subscriber, #4458) [Link]

To be really fair, the service configurations have to be tailored to each init system (Fedora is getting there now, some 2 years after starting with systemd). Besides, systemd (and I presume upstart too) make some code in the daemon moot, it would have to be ripped out/restructured to do a complete comparison.

Besides, "boot speed" isn't all important. Managing services, how easy is it to handle security, does it simplify the task of writing daemons (factor out error-prone functionality) all should have a say here.

Some changes needed...

Posted Nov 27, 2012 15:55 UTC (Tue) by Zack (guest, #37335) [Link] (45 responses)

>>- boot to some real desktop environment

Why ? Why not add, "boot on different server platforms", then ?

The whole problem with systemd is that it seems to follow this "grand unifying vision" (and somehow I get the feeling this vision is all about finally getting there with "linux on the desktop"; as if it were a technical problem in the first place), and everything that is not part of that vision is discarded as unimportant or "toy".

I'm glad Debian at least makes an effort to provide some choice in this nonsense instead of just cheerleading what seems to be popular at the moment. Not every computer is used for personal computing; not every kernel is a linux, not every Unix is a GNU.

GNU/Linux got to be one of the most successful and important server operating system in history, all with "inadequate" old sysvinit. Somehow, it doesn't strike me as if having a swanky shiny init system is going to pave the way to sudden success because it turns out *that*'s what has been holding GNU/Linux on the desktop back all these years.

Yes, sysvinit can be improved upon/replaced. No, it's simply not important enough to replace it with a poorly architected replacement, fast and shiny though it may be.

Some changes needed...

Posted Nov 27, 2012 16:29 UTC (Tue) by mathstuf (subscriber, #69389) [Link] (39 responses)

> (and somehow I get the feeling this vision is all about finally getting there with "linux on the desktop"; as if it were a technical problem in the first place)

No, it will never completely be a technical problem, but there can be technical barriers to getting there. Say I'm a third party. I want to make sure that my application start at boot. Distros aren't going to ship it (and do the work themselves) if it's not FOSS. How do I do it? Ship several dozen solutions to cover all the bases? Support only one system/distribution? AIUI, systemd's goal is to create a platform upon which you can rely upon certain features existing such as a way to make sure your application starts at boot, during a user session, on socket activity, after the SQL server started, or whenever.

> Somehow, it doesn't strike me as if having a swanky shiny init system is going to pave the way to sudden success because it turns out *that*'s what has been holding GNU/Linux on the desktop back all these years.

No, a new init system isn't the (whole) solution. Just adding some sanity for cross-distro support is nice though. I'd be happy if I could convert a server from Fedora to Debian and system setup scripts still worked (modulo package names, but directories, commands, and so forth could be the same).

> a poorly architected replacement

Care to share examples or specifics?

Some changes needed...

Posted Nov 27, 2012 18:24 UTC (Tue) by Zack (guest, #37335) [Link] (33 responses)

"Linux on the desktop" has already arrived. In fact, it arrived many years ago. The only thing it lacks -- by most people's definition of it -- is ubiquity; a sizeable market percentage that is measured in natural numbers.

In my opinion the only way to ever reach such ubiquity is if one particular distribution gets Apple or MS size marketing behind it, and as such it would dwarf all the others into relative obscurity anyway, making any sort of incompatibilities moot, since whatever is in that distribution is what the proprietary ISPs will package for.

Technical excellence will only get an OS so far, and any tweaking in the margins -- by shaving yet another few seconds off booting or having a standardised init system -- isn't going to make a platform more popular.

That said, of course init could do with a replacement, and systemd seems (the init part anyway) to have some desirable features. But realistically, there's no hurry to push it as the next silver bullet that will finally make X happen with any distribution that doesn't adopt it going to be left behind.
It *certainly* isn't a good enough excuse to demand preempting other interesting software for.

>> a poorly architected replacement
>Care to share examples or specifics?

Well, if a main author of a project basically concedes there's no point in sending in patches concerning portability because the software is too specific already, that makes it cowboy-coding to me, irrespective of whether he is the best codeslinger in town.

If you're going to replace init, do it properly.

Some changes needed...

Posted Nov 27, 2012 19:26 UTC (Tue) by mathstuf (subscriber, #69389) [Link] (8 responses)

> In my opinion the only way to ever reach such ubiquity is if one particular distribution gets Apple or MS size marketing behind it, and as such it would dwarf all the others into relative obscurity anyway, making any sort of incompatibilities moot, since whatever is in that distribution is what the proprietary ISPs will package for.

And since only Google (and possibly Canonical, but their success isn't as apparent to most) is doing this so far and their direction doesn't really include my general computer use cases (AFAIK), we may as well work on things we can change (which tend to be the technical side of things).

> Technical excellence will only get an OS so far, and any tweaking in the margins -- by shaving yet another few seconds off booting or having a standardised init system -- isn't going to make a platform more popular.

Agreed. However, there's always the chicken-and-egg problem. Without a standard and reliable init system, we might not get the attention of third parties. Without the third parties, we lose potential users. *Something* needs to give somewhere for things to change. The faster boot is a nice side effect, but it certainly isn't the end goal.

> if a main author of a project basically concedes there's no point in sending in patches concerning portability because the software is too specific

As with anything, lines need to be drawn somewhere. Are you going to support Linux 2.4? FreeBSD 7? VAX? Windows? As an example, some of the features systemd provides expect something like the cgroups API to exist. What (existing) interface would you propose is used on BSD instead? Drop it and systemd isn't really portable anyways since it wouldn't be able to give the same guarantees about stopping services on BSD as it could on Linux. All that does is push the portability burden onto the services which expect it to exist. At this point, it might be easier to provide the cgroups API on BSD or to get something done which does things equivalently with an interface acceptable for BSD and then offer that on Linux as well.

Some changes needed...

Posted Nov 27, 2012 22:34 UTC (Tue) by Zack (guest, #37335) [Link] (7 responses)

>As with anything, lines need to be drawn somewhere. Are you going to support Linux 2.4? FreeBSD 7? VAX? Windows?

True, but "nothing but (current) linux, and all linux platforms should use this" is just drawing that line in a circle around yourself.
By my standards that's acceptable for a quickly thrown together proof-of-concept mailclient, but not really for the init system we're all to use.

>As an example, some of the features systemd provides expect something like the cgroups API to exist.
>What (existing) interface would you propose is used on BSD instead?

That would be up to the BSD developers, once they inescapably see the light. But up until that point it would be good form to just have systemd default to a bog standard portable init wherever its highly specialised features are not available so hackers everywhere can at least attempt to bring such glory to their system and meantime be able to boot.

>we may as well work on things we can change (which tend to be the technical side of things).

I guess that's as true as anything written in this thread. "Be the change you want to see in the world", or something like that.

Some changes needed...

Posted Nov 27, 2012 23:54 UTC (Tue) by Eckhart (guest, #74500) [Link] (5 responses)

> But up until that point it would be good form to just have systemd default to a bog standard portable init wherever its highly specialised features are not available so hackers everywhere can at least attempt to bring such glory to their system and meantime be able to boot.

Why is this so hard to understand? systemd fundamentally depends on concepts like cgroups, they are not just an afterthought. Just have a look at the code.

Or, as an analogy: a team of engineers are building a maglev train. You are telling them to add wheels and a diesel engine, so it can also run on conventional tracks. Sure, it might be possible to add this stuff: by increasing costs per unit, ruining the design and reducing the maximum speed the train is able to travel because of the weight of the diesel engine.

Some changes needed...

Posted Nov 28, 2012 0:02 UTC (Wed) by dlang (guest, #313) [Link] (4 responses)

> systemd fundamentally depends on concepts like cgroups

however when people complain about how systemd should not be considered to be the standard init because it requires cgroups, which impose a significant performance hit on current systems, the answer that we get is that cgroups are an optional feature, systemd will work without cgroups, just not as well.

you can't have it both ways, pick a story and stick with it.

Some changes needed...

Posted Nov 28, 2012 0:43 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

I think the specifics are that cgroups have to be available, but not fully enabled. From the README:

> with cgroups (but it's OK to disable all controllers)

I would assume that cgroups still offers the process grouping functionality, it just can't do per-group rlimits.

Some changes needed...

Posted Nov 28, 2012 2:02 UTC (Wed) by Eckhart (guest, #74500) [Link] (2 responses)

> however when people complain about how systemd should not be considered to be the standard init because it requires cgroups, which impose a significant performance hit on current systems, the answer that we get is that cgroups are an optional feature, systemd will work without cgroups, just not as well.

> you can't have it both ways, pick a story and stick with it.

Picked a story for you: http://0pointer.de/blog/projects/cgroups-vs-cgroups.html

(Hint: if you don't know how "systemd" and "cgroups" relate, googling for both terms might help.)

Some changes needed...

Posted Nov 28, 2012 16:50 UTC (Wed) by nye (subscriber, #51576) [Link] (1 responses)

>Picked a story for you: http://0pointer.de/blog/projects/cgroups-vs-cgroups.html

That document says "if you...disable the grouping feature entirely (A) then systemd will loudly complain at boot and proceed only reluctantly with a big warning and in a limited functionality mode". That sounds a lot like "a bog standard portable init wherever its highly specialised features are not available", which you claimed was impossible.

Some changes needed...

Posted Nov 28, 2012 19:15 UTC (Wed) by Eckhart (guest, #74500) [Link]

> That document says "if you...disable the grouping feature entirely (A) then systemd will loudly complain at boot and proceed only reluctantly with a big warning and in a limited functionality mode". That sounds a lot like "a bog standard portable init wherever its highly specialised features are not available", which you claimed was impossible.

According to systemd developers "limited functionality mode" means "expect breakage" and "might allow you to compile a kernel with cgroups if you are lucky".

Some changes needed...

Posted Nov 28, 2012 14:31 UTC (Wed) by HelloWorld (guest, #56129) [Link]

> True, but "nothing but (current) linux, and all linux platforms should use this" is just drawing that line in a circle around yourself.
I don't see a reason to make init portable. sysvinit is portable, but who actually uses it on anything but Linux? Nobody, because pretty much every other Unix out there has its own init, and they're certainly not all portable (cf. SMF on Solaris). And the BSD people won't adopt systemd anyway due to the license.

Also note that while systemd's implementation isn't portable, its interfaces are, so nothing stops a vendor from implementing a systemd clone for their OS.

Some changes needed...

Posted Nov 27, 2012 20:31 UTC (Tue) by HelloWorld (guest, #56129) [Link] (14 responses)

> Well, if a main author of a project basically concedes there's no point in sending in patches concerning portability because the software is too specific already, that makes it cowboy-coding to me, irrespective of whether he is the best codeslinger in town.
The reason isn't that systemd is "too specific already". It was a conscious decision done very early in the project to not make it portable, because that would have incurred a cost in maintainability (abstraction layers, ifdef-hell) that its authors were (and are) not prepared to pay.

> If you're going to replace init, do it properly.
It was done properly. systemd beats the pants off any other init system for linux.

Some changes needed...

Posted Nov 28, 2012 11:01 UTC (Wed) by Wol (subscriber, #4433) [Link] (13 responses)

And the programmer in question has a reputation for blaming other systems when it is their fault.

A lot of programs follow the unix philosophy of "be strict in what you send, and liberal in what you accept". Lennart doesn't do that. He does "be strict in everything you do". Which is why so many of his previous programs have been such a pain - he refused to work around bugs etc in other programs, and just complained and complained until they were fixed.

Unfortunately, in the meantime, things like Pulseaudio didn't work properly :-(

Hence the decision that systemd would assume the things it needed were there, I suppose. And then Lennart made sure that, in linux at least, they were. If other people want to port systemd, they need to make sure the things it needs are there.

Cheers,
Wol

Some changes needed...

Posted Nov 28, 2012 11:28 UTC (Wed) by paulj (subscriber, #341) [Link] (1 responses)

Aside: Isn't that more often referred to as the "Postel Principle", rather than the unix philosophy?

Some changes needed...

Posted Dec 3, 2012 13:50 UTC (Mon) by JanC_ (guest, #34940) [Link]

Yes, it is, and it applies to the internet (originally the TCP/IP protocol), not unix. (It is also often misunderstood...)

Some changes needed...

Posted Nov 28, 2012 14:06 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

Personally, I also try to get bugs fixed rather than work around them. Either everybody will need to do that workaround or those that really need it fixed can just bump the minimum version. Yes, things can suck until they are fixed, but I can't remember any sound issues since Fedora 10 or 11 (and I've had a Rawhide machine since 14 or so)[1]. Maybe its selective memory, but they've not been major enough to mention in passing (Fedora 9 Beta however...). And, FWIW, this is what GNOME tries to do. As long as those refusing to do workarounds help in some way with the bugs (fixing, testing, documenting it, etc.), I see no issue with the approach.

[1]Well, okay, flat volumes suck, but that's been added to my dotfiles.

Some changes needed...

Posted Nov 28, 2012 16:24 UTC (Wed) by raven667 (subscriber, #5198) [Link] (9 responses)

I'm not sure how demanding quality and working on building a robust infrastructure is supposed to be a bad trait ... I think if more developers were less tolerant of misbehaving infrastructure that the Linux software stack would be even better than it is now.

Some changes needed...

Posted Nov 28, 2012 16:57 UTC (Wed) by nye (subscriber, #51576) [Link] (8 responses)

>I'm not sure how demanding quality and working on building a robust infrastructure is supposed to be a bad trait ... I think if more developers were less tolerant of misbehaving infrastructure that the Linux software stack would be even better than it is now.

We tried that. It was called HURD. As you know, it's been a roaring success and now powers 87% of desktops around the world.

Some changes needed...

Posted Nov 28, 2012 17:07 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (6 responses)

I've actually tried HURD when it became available in Debian (I think it was about 5 years ago). It was a crappy PITA - nothing worked, daemons crashed, system was locking up all the time.

Some changes needed...

Posted Nov 28, 2012 17:50 UTC (Wed) by nye (subscriber, #51576) [Link] (5 responses)

And that's what actually happens in reality when you focus on theoretical elegance like being intolerant of misbehaving infrastructure, rather than focussing on making things that work in this world.

It's why 32-bit applications can't play sound out of the box on Debian wheezy (at least as of a couple of weeks ago), because both PulseAudio and Debian's multiarch implementation care more about 'technical excellence' than working software.

(I know, I should have filed a bug for my specific problem, or at least found out if there was one already, but I'd just spent ages trying to figure out why 32-bit applications can't use OpenGL on NVidia hardware only to discover that the bug was filed, the reason understood, a fix posted, and the maintainer intentionally didn't apply it because "if there's two things in the world I don't care about it's wine and the nvidia driver". I had no desire to head right back down that particular rabbit hole.)

Some changes needed...

Posted Nov 28, 2012 17:58 UTC (Wed) by mathstuf (subscriber, #69389) [Link] (3 responses)

> "if there's two things in the world I don't care about it's wine and the nvidia driver"

Was this a package maintainer or upstream?

Some changes needed...

Posted Nov 28, 2012 18:52 UTC (Wed) by cortana (subscriber, #24596) [Link] (2 responses)

Looks like http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=640499

Some changes needed...

Posted Nov 28, 2012 19:06 UTC (Wed) by mathstuf (subscriber, #69389) [Link] (1 responses)

That seems like something FESCo would handle in Fedora (conflict between packager of A and packager of B which depends on A). There's no way to elevate it in Debian?

Some changes needed...

Posted Dec 1, 2012 15:05 UTC (Sat) by viiru (subscriber, #53129) [Link]

> That seems like something FESCo would handle in Fedora (conflict between
> packager of A and packager of B which depends on A). There's no way to
> elevate it in Debian?

Yes there is, the Technical Committee (see http://www.debian.org/devel/tech-ctte ).

Some changes needed...

Posted Nov 28, 2012 22:24 UTC (Wed) by HelloWorld (guest, #56129) [Link]

It's interesting to see that other people had the same kind of issues with Debian maintainers that I did. It's one of the reasons why I switched away from Debian some time ago.

Some changes needed...

Posted Nov 28, 2012 17:41 UTC (Wed) by HelloWorld (guest, #56129) [Link]

> We tried that. It was called HURD.
Lennart doesn't call for some crazy new design that nobody is able to implement, he merely advocates fixing bugs instead of working around them. And he does succeed with that, most distros ship with PulseAudio, Avahi and systemd today.

Some changes needed...

Posted Nov 28, 2012 12:35 UTC (Wed) by dgm (subscriber, #49227) [Link] (8 responses)

> In my opinion the only way to ever reach such ubiquity is if one particular distribution gets Apple or MS size marketing behind it

Think about this again. Do you really believe that most people (the 99%, you know) could be convinced to _replace_ the OS that's already installed in their machines?

I believe that they cannot be bothered, as long as it keeps working, more or less (it's unbelievable how much pain users can endure before fixing stuff).

No, the only way is to convince device _sellers_ to preload Linux, and then provide them with a version that can do whatever they want to do, with a minimum of fuss. That implies technical excellence, of course.

Remember netbooks? The very first ones that sold with Linux? Some claimed they were being returned because they didn't run MS Office. Today I don't see anybody returning their iPads because they cannot run Office, so odds are that this was not the real problem. Maybe the reason was that the Linux inside those machines was not exactly "excellent".

Maybe, or maybe not. Picture yourself having a dual booting machine, say a laptop or a tablet. You could chose to boot Windows 8 in a couple of minutes or Linux almost instantly (say, less than 10 seconds). Which one would you boot more often?

Some changes needed...

Posted Nov 28, 2012 13:49 UTC (Wed) by Zack (guest, #37335) [Link]

>Think about this again. Do you really believe that most people (the 99%, you know) could be convinced to _replace_ the OS that's already installed in their machines?

I don't think we're disagreeing. When I mention "Apple or MS size marketing", I also include strongarming OEMs into shipping the OS, having "<manufacturer> recommends Deborah ME edition" advertised when buying machines online, having yound succesful people holding that life changing device and smiling at you from the poster at the busstop, the works. So,
>the only way is to convince device _sellers_ to preload Linux,
was implied. But I don't believe a "minimum of fuss" is any match for a "maximum of sales" in their eyes, which firmly plants systemd -- or any sort of technical improvement -- in the "neat to have on your system" category. Except I don't think it's neat to have, since it doesn't really do anything to improve non-linux systems with the aformentioned popularity as a result of unification as excuse.

Since we can't yet tend to the masses, we might as well tend to our own. I guess that's the only real point of contention: where some see linux-based systems as "our own", and some see the term in a different context.

Some changes needed...

Posted Nov 28, 2012 14:13 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

As a note, Windows 7 feels very fast at boot, shutdown, suspend (which I believe is always a hybrid suspend/hibernate), and resume. From what I read, Microsoft was working on improving that for 8. Granted, boot/login is sort of cheating since control is handed over before things are actually ready to use (though I remember KDE (< ~4.5) having similar behavior), but it's still a nice psychological effect.

Some changes needed...

Posted Nov 28, 2012 17:31 UTC (Wed) by nye (subscriber, #51576) [Link] (5 responses)

>Picture yourself having a dual booting machine, say a laptop or a tablet. >You could chose to boot Windows 8 in a couple of minutes or Linux almost >instantly (say, less than 10 seconds). Which one would you boot more often?

One of the things that really upsets me about LWN, and most Linux-related forums in general, is the obstinate refusal to consider minor points like 'facts', preferring to make up random nonsense trashing other platforms rather than ever bothering to make a fair comparison. It's like many people can't think of any ways in which Linux is *actually better*, so they have to make some up.

It's tiresome and childish, and it makes FOSS advocates look bad.

Some changes needed...

Posted Nov 28, 2012 17:56 UTC (Wed) by mathstuf (subscriber, #69389) [Link] (1 responses)

I think this falls to Hanlon's Razor (s/stupidity/extrapolated ignorance/). Windows before 7 *did* have horrible boot performance (ISTR Vista being particularly bad on my school laptop, but maybe that's memories of it souring over time). Once you're under 5–10 seconds, it's really in the "who cares?" realm. Hell, it takes 3 seconds for the cable box my family has to get the picture on the screen after switching channels at home and no one complains. Video game console starting animations can take longer. Five seconds from switch to useful would probably be generally accepted. Windows 7 is there on my work machines (modulo the limbo where services and such are starting up after I log in and whether updates need to be finished installing). CentOS 5 is not by any means. Fedora Rawhide is getting there with systemd (17 seconds from when journald starts logging to my user being logged in at a TTY with manual entry). The best I had seen on my machines before was a ~35 second internet to internet reboot (manual login and ifup wlan0) on an eee900 netbook (either Fedora 13 or 14?).

Some changes needed...

Posted Nov 28, 2012 19:18 UTC (Wed) by reedstrm (guest, #8467) [Link]

My laptop makes it from cold start to gdm login screen in 9~10 sec, running bog standard Ubuntu 12.04, by virtue of replacing the system disc w/ an SSD.

Add another 3-4 sec for initial login. Yes, even bloated desktop login is acceptable w/ faster disc IO.

Not that I find boot time that interesting anymore: sleep/resume has been solved, I almost never actually shut down anymore.

My biggest issue is NetworkManager taking its time to decide where I am and getting the appropriate WiFi up.

Some changes needed...

Posted Nov 28, 2012 18:06 UTC (Wed) by nye (subscriber, #51576) [Link] (2 responses)

>It's like many people can't think of any ways in which Linux is *actually better*, so they have to make some up.

NB. I'm not saying there aren't any, just that the most commonly quoted reasons which basically boil down to performance and stability are manifestly untrue in the majority of cases, like this boot time example.

Some changes needed...

Posted Nov 28, 2012 22:18 UTC (Wed) by louie (guest, #3285) [Link]

Lots of these examples (particularly with regards to stability/crashiness) are really about Windows 95/98/XP, which are the last versions of Windows that many Linux users ran/remember. My first Linux install was done immediately after Word crashed 10-12 times in a single *hour* during a paper I was writing at school. Now I use Word 8-10 hours a day and I can't recall 8-12 crashes in total in the past three *years.* It is really unfortunate that most of us don't realize what we're competing against - it is a very bad bubble to be living/thinking in.

Some changes needed...

Posted Nov 29, 2012 14:42 UTC (Thu) by dgm (subscriber, #49227) [Link]

It was just a supposition to make a point. Would you feel any better should I had mentioned OS X instead? What's all the fuss about?

Some changes needed...

Posted Nov 28, 2012 4:48 UTC (Wed) by sorpigal (subscriber, #36106) [Link] (3 responses)

> AIUI, systemd's goal is to create a platform upon which you can rely upon certain features existing such as a way to make sure your application starts at boot, during a user session, on socket activity, after the SQL server started, or whenever.
This is important because it describes the problem/disagreement: What systemd provides more than anything isn't a technical improvement over previous options but the promise of *uniformity*, which can also be read as a lack of choice. Its goal, or one of its goals, seems to be unapologetically saying "Distributions should not be free to be different in some ways because we know the best answers to some problems and deviation is not acceptable." Usually this level of uniformity is achieved only through standardization (e.g. posix) and consensus, but with systemd it's being attempted sideways: build a new system and push for adoption based on its other virtues, but get uniformity as a result.

It's ultimately not about better boot times, even though that's an oft-sited 'benefit' to systemd. It's also not about better service supervision, because that is a goal which can be achieved in a non-confrontational, evolutionary way, too. It's about *one* way of doing things, which 'presumably' is the best way, because if it isn't then what's the point of all of this?

Some changes needed...

Posted Nov 28, 2012 10:55 UTC (Wed) by ovitters (guest, #27950) [Link] (2 responses)

Lennart has explained various times in various amount of detail the functionality that systemd uses.

Not doing research and making summaries such as "POSIX should be enough" is a bit easy IMO. Especially as systemd is actually has a list of additional functionality which they want from the kernel.

Some changes needed...

Posted Nov 28, 2012 22:58 UTC (Wed) by sorpigal (subscriber, #36106) [Link] (1 responses)

I am not trying to say that POSIX should be enough (it was only an example).

To quote myself: "Usually this level of uniformity is achieved only through standardization and consensus," I'm trying to draw a contrast between how one-true-way things have become adopted and how the systemd-one-true-way things are being spread (i.e., not by standardization, not by first achieving a consensus).

Some changes needed...

Posted Nov 28, 2012 23:39 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

I'm fairly sure that the systemd developers had discussions with multiple distributions about how to go about things. Sure, maybe the niche distros weren't in the discussions, but going and talking to *every* distro maintainer would mean that we'd still be waiting on whether /run is viable.

Some changes needed...

Posted Dec 3, 2012 2:36 UTC (Mon) by gfa (guest, #53331) [Link]

> Say I'm a third party. I want to make sure that my application start at
> boot.

use LSB headers, supported on more distros than systemd or/and upstart

Some changes needed...

Posted Nov 27, 2012 16:59 UTC (Tue) by HelloWorld (guest, #56129) [Link]

> a poorly architected replacement
Oh come on. If you want to troll, please make it less obvious.

Some changes needed...

Posted Nov 28, 2012 7:52 UTC (Wed) by niner (guest, #26151) [Link] (3 responses)

Systemd is nice for the desktop, but I absolutely love it on the server. Finally there's a reliable way to shut down a deamon with all it's spawned sub processes. No more lost processes because they couldn't write their PID to a file and no more stragglers preventing the cluster manager from unmounting the file system and doing a failover.

No, there's simply no way to teach this to sysvinit. It's a genuine advantage of having init use cgroups for managing deamons.

Some changes needed...

Posted Dec 3, 2012 14:09 UTC (Mon) by JanC_ (guest, #34940) [Link] (2 responses)

It should be perfectly possible to teach "sysvinit" to do what you want; right now, it would just be more work to do so (it's not like systemd is the only application allowed to use cgroups).

Some changes needed...

Posted Dec 6, 2012 15:56 UTC (Thu) by HelloWorld (guest, #56129) [Link]

"We can do that" isn't what it's about. "We've done that" is what counts.

Some changes needed...

Posted Dec 7, 2012 7:30 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

Even if this were to happen, would distros update it quickly or is it yet another difference between all the init systems out there in the meantime? If it happens quickly, why would sysvinit get a pass on "must be stable and proven before adoption" arguments and systemd not?

Langasek: Upstart in Debian

Posted Nov 27, 2012 0:34 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

Erm. Upstart jobs work faster exactly because they can avoid unnecessary shells too.

Langasek: Upstart in Debian

Posted Nov 27, 2012 4:27 UTC (Tue) by s0f4r (guest, #52284) [Link] (1 responses)

The article doesn't claim otherwise. It does point out that upstart's sequence still executes an rcS script, but I suppose that's something that could be fixed.

Langasek: Upstart in Debian

Posted Dec 3, 2012 16:11 UTC (Mon) by JanC_ (guest, #34940) [Link]

The rcS script is part of the sysvinit compatibility, so you probably can't really remove it without removing sysvinit compatibility (at least, sysvinit as it is implemented in Debian).

The rcS job runs '/sbin/sulogin' to get you an emergency shell (and also contains an embeded script needed for sysvinit compatibility when you leave single user mode).

Now, all that is really only because of the support for runlevels and other sysvinit features desired by a distro like Ubuntu & Debian, of course. None of that is mandatory; so you could create a much simpler upstart setup if you don't need all that (e.g. for an embeded or other dedicated system like webOS).

Langasek: Upstart in Debian

Posted Nov 27, 2012 9:12 UTC (Tue) by djzort (guest, #57189) [Link]

im fairly sure this was prophesied as a herald of Armageddon. it is 2012 after all.

Langasek: Upstart in Debian

Posted Nov 27, 2012 9:42 UTC (Tue) by johannbg (guest, #65743) [Link]

Let's see how fair upstart and sysv init compares to all the plethora of features systemd has to offer after all speed is more of an side effect than an feature...

Remarks about the benchmark

Posted Nov 27, 2012 10:09 UTC (Tue) by man_ls (guest, #15091) [Link] (32 responses)

The benchmark published by Langasek is very interesting. We can draw a few preliminary conclusions from it.

All results are between 2.3 and 3.5 seconds: a remarkably small spread. As was discussed elsewhere, boot times in Debian are very fast even with the old SysV init system. This is consistent with my own experience on a more complete system -- but be sure to get an SSD.

The speed improvement in systemd alone is not worth the change. Perhaps its other virtues are so impressive that it justifies the change; but in that case upstart is still a valid contestant.

Also, different boot systems can be made compatible and exchanged at will. Debian does (and should always) support a few of them. This way you can test a few of them on your actual configuration.

Remarks about the benchmark

Posted Nov 27, 2012 11:32 UTC (Tue) by jbglaw (subscriber, #10406) [Link] (2 responses)

The change in speed is a nice side effect. But for systems that don't actually need a short boot-to-shell time (like anything except desktop or laptop installations), there is some more complexity during boot, especially with systemd.

Am I the only one who also considers ease-of-use a core feature? SysV init is quite easy to understand, and upstart is quite easy to use, too. But an admin actually needs to invest quite some time to fully understand all the systemd files...

Remarks about the benchmark

Posted Nov 27, 2012 11:36 UTC (Tue) by man_ls (guest, #15091) [Link]

That argument was made, and alternatively confirmed and refuted, in this previous thread. So your kilometrage may vary indeed.

Remarks about the benchmark

Posted Nov 27, 2012 16:37 UTC (Tue) by HelloWorld (guest, #56129) [Link]

Please name a single thing that is substantially easier to do with sysvinit than with systemd (or stop FUDing).

Remarks about the benchmark

Posted Nov 27, 2012 16:51 UTC (Tue) by cyanit (guest, #86671) [Link] (2 responses)

Going from 2.3 to 3.5 seconds is a dramatic change, not a small one.

It's a 50% increase, and it's even worse if it proportional in the sense that a sense booting in 23 seconds with systemd boots with 3.5 seconds with upstart.

Anyway, if they were using an SSD or ramdisk, those timings are still horrible, since boot ought to be instantaneous.

Remarks about the benchmark

Posted Nov 27, 2012 17:38 UTC (Tue) by man_ls (guest, #15091) [Link] (1 responses)

Proportions are meaningless since both start systems are doing a number of discrete tasks, not a continuous sequence. When Upstart went from 35 to 23 seconds it was a huge advantage; now that systemd uses just one less second, it is immaterial in practice.

Anyway, if they were using an SSD or ramdisk, those timings are still horrible, since boot ought to be instantaneous.

Really? Let us do some quick math: SATA III achieves 600 MB/sec. If your userspace is 1 GB (not unheard of), then it will take about two seconds just to load all that information from disk into memory. This is besides any hardware initialization tasks, computations and so on. I think that 2.5 seconds in real life is an impressive achievement, even for a modest userspace. It will never be "instantaneous" even with the fastest SSD money can buy, at least until SATA VII or so (just joking, at that point userspace will probably be about 8 GB). But for my particular needs we are well beyond the point of diminishing returns.

Remarks about the benchmark

Posted Nov 27, 2012 20:30 UTC (Tue) by cyanit (guest, #86671) [Link]

Due to existence of live CDs, the userspace needed to boot is clearly much smaller than 1 GB.

Also, you could cheat by having GRUB2 display the login screen and handle password input itself, loading the Linux kernel in background while the password is typed.

Remarks about the benchmark

Posted Nov 27, 2012 16:57 UTC (Tue) by HelloWorld (guest, #56129) [Link] (25 responses)

> Also, different boot systems can be made compatible and exchanged at will. Debian does (and should always) support a few of them.
I strongly disagree. Supporting multiple init systems leads to a pointless increase in complexity, which leads to more work and makes testing harder. Nobody wants three init systems that all sort of work, people just want one that works really well. Debian should pick a single init system, and it's obviously systemd given its technical superiority over all its contenders. kFreeBSD must obviously use sysvinit, as neither systemd nor upstart run on the FreeBSD kernel, but it should be used only on kFreeBSD. That way, eventual sysvinit breakage will be confined to users of that OS.

Remarks about the benchmark

Posted Nov 27, 2012 19:04 UTC (Tue) by xxiao (guest, #9631) [Link] (2 responses)

"it's obviously systemd given its technical superiority over all its contenders" , really? not everyone is buying this, esp when it's anti-unix.

Remarks about the benchmark

Posted Nov 27, 2012 20:28 UTC (Tue) by drag (guest, #31333) [Link]

> anti-unix.

Systemd is anti-Unix is the same what that Linux is anti-Unix. Which is to say "Everything and yet nothing at all".

I mean... were do people keep getting this sort of crap from?

It doesn't really matter what is technically superior here. If Debian picks a inferior choice all it means is that they are going to have to work harder to get to the same place that they would be at if they choose a good technical choice.

The worst thing Debian can possibly do is starting trying to force everybody to support 3 different init systems. It's insanity. This way they will NEVER reach the same level as if they choose poorly.

Remarks about the benchmark

Posted Nov 27, 2012 22:01 UTC (Tue) by HelloWorld (guest, #56129) [Link]

> not everyone is buying this,
That doesn't alter the fact. With systemd, you essentially don't have to configure service dependencies any longer due to socket/dbus activation autofs support, and it does a much better job at starting services when they're needed (i. e. launch bluetoothd when a USB bluetooth dongle is plugged in etc.). Its configuration file format is also very simple and amenable to manipulation with automated tools. And these are just a few random benefits, there are literally dozens of other things that systemd does better than the competition.

> esp when it's anti-unix.
I'm not even sure whether that's really true, but to be honest, I don't care either. The so-called unix philosophy is in large part a manifestation of the constraints of the seventies' and eighties' environments. People should move on and accept that many new and clever ideas about how to write software have emerged since then.

Remarks about the benchmark

Posted Nov 28, 2012 9:06 UTC (Wed) by oldtomas (guest, #72579) [Link] (17 responses)

> > [...] Debian does (and should always) support a few of them.
> Debian should pick a single init system, and it's obviously systemd [...]

IMHO what hurts systemd adoption most is this very attitude.

Remarks about the benchmark

Posted Nov 28, 2012 14:54 UTC (Wed) by HelloWorld (guest, #56129) [Link] (16 responses)

> IMHO what hurts systemd adoption most is this very attitude.
I don't think an opinion is a bad thing to have, but you're right in that some people don't seem to like that.

Now, given systemd's technical benefits (use of cgroups for service babysitting, much easier configuration, virtually no need for service dependency configuration, many different activation schemes instead of just static runlevels), could you please name a reason to use another init implementation for Debian GNU/Linux? Because otherwise I'll be inclined to think that my opinion is actually correct.

Remarks about the benchmark

Posted Nov 28, 2012 22:11 UTC (Wed) by oldtomas (guest, #72579) [Link] (15 responses)

> I don't think an opinion is a bad thing to have, but you're right in that > some people don't seem to like that.

Opinions are fine. Dicussing them is fine too. What "some people" dislike is to be forced into one (instead of, for example, being convinced).

> Now, given systemd's technical benefits (use of cgroups for service
> babysitting, [...]), could you please name a reason to use another init
> implementation for Debian GNU/Linux?

Because others might not share your opinion?

I won't go into the details of the discussion, they have been hashed out ad nauseam in other places.

I do appreciate Debian GNU/Linux because it goes to great lengths to enable multiple possibilities. As long as there are people willing to maintain other init systems, there should be other init systems. Your opinion is... your opinion, and is no better or worse than other people's opinion.

Trying to establish your opinion as The Truth (TM) isn't very helpful in a discussion. methinks.

Remarks about the benchmark

Posted Nov 28, 2012 23:45 UTC (Wed) by HelloWorld (guest, #56129) [Link] (14 responses)

> Because others might not share your opinion?
As long as they can't make a valid point as to why, they'll have a hard time to convince me.

It's really easy for users like man_ls to request choice, because they don't have to do the actual work to make that possible. And they invariably fail to see that there is a (complexity) cost involved, and that ultimately they are the ones to pay it.

Remarks about the benchmark

Posted Nov 29, 2012 0:38 UTC (Thu) by dlang (guest, #313) [Link] (13 responses)

if you define "not having a valid point" to be "not agreeing that when I say it's better, it's better" you will never meet anyone with a valid point.

There are a lot of people who don't like systemd, and they have expressed why. I believe that many have made valid points, you dismiss them all as being invalid.

and you wonder why people don't warm to systemd??? telling them that their concerns are all invalid and they just need to 'man up and get with the times' is not the way to change their mind.

Remarks about the benchmark

Posted Nov 29, 2012 15:14 UTC (Thu) by HelloWorld (guest, #56129) [Link] (12 responses)

if you define "not having a valid point" to be "not agreeing that when I say it's better, it's better"...

I don't.

There are a lot of people who don't like systemd, and they have expressed why. I believe that many have made valid points,

I guess this is where you and I are different. I've seen one thing that comes close to what I'd consider a valid argument in favour of sysvinit: init must never crash, and since sysvinit is smaller than systemd, there's a smaller chance for it to crash.

There are two problems with that. The first is that it's an entirely theoretical argument and lacks empirical evidence: systemd doesn't crash all the time, in fact I've never seen it crash. It is possible to make programs of that size (and much bigger ones, like the Linux kernel) reliable. The second is that it entirely ignores all the other ways in which systemd is more robust and secure than sysvinit: less need for service dependency configuration, service supervision with cgroups, predictable environments for service execution, fewer messy distro-specific shell scripts, syscall filtering, capability limitation, network isolation, SELinux support, on and on it goes.

So, if you think you or anyone else has a compelling argument to make against systemd, tell me, I'm listening. But I haven't heard one so far, and my opinion about what a sensible thing for the Debian GNU/Linux developers to spend time on would be reflects that.

Remarks about the benchmark

Posted Dec 2, 2012 16:20 UTC (Sun) by oldtomas (guest, #72579) [Link] (6 responses)

> > if you define "not having a valid point" to be "not agreeing that when I say it's better, it's better"...
>
> I don't.

Sigh. Quoting you upthread:

> "Debian should pick a single init system, and it's obviously systemd given
> its technical superiority over all its contenders"

You seem to be quite absolute about your standpoint. That's the one all should share.

You are of the strong opinion that systemd is (technically) superior. That's OK, but it's *your* opinion, not mine (besides, I value other, non-technical aspects too). Thus, it's fine Debian comes with the option of systemd (for you) and with other options (for me).

At least whenever there are enough folks willing to do maintenance. Right?

Remarks about the benchmark

Posted Dec 2, 2012 18:36 UTC (Sun) by HelloWorld (guest, #56129) [Link] (5 responses)

Why do you want me to repeat myself?? Once more: I'm entirely prepared to change my opinion on the matter, you just need to give me a good reason why anybody would prefer sysvinit or upstart to systemd.

Until you do, I'll maintain my position: supporting init implementations other than systemd on GNU/Linux is harmful due to the increase in complexity, need for testing and waste of developer time.

Remarks about the benchmark

Posted Dec 2, 2012 23:03 UTC (Sun) by dlang (guest, #313) [Link] (4 responses)

many people have listed problems, you don't consider any of them 'real' and just dismiss them, so you aren't worth arguing with.

Remarks about the benchmark

Posted Dec 2, 2012 23:36 UTC (Sun) by HelloWorld (guest, #56129) [Link] (3 responses)

> many people have listed problems, you don't consider any of them 'real' and just dismiss them, so you aren't worth arguing with.
I've been presenting arguments in favour of systemd again and again in this thread; you didn't refute any of them. I've been asking you and oldtomas over and over again to name technical arguments in favour of other init systems; you didn't name one.

And now YOU are accusing ME of ignoring other people's arguments? Sorry, you're ridiculous.

Remarks about the benchmark

Posted Dec 17, 2012 16:43 UTC (Mon) by wookey (guest, #5501) [Link] (2 responses)

You really don't get it do you?

Read what tuomas wrote again and see if you can understand why your forthright advocacy is not helping.

It no longer an entirely technical question.

In principle I don't care at all what my init system is, but currently, after reading many of these threads and comparing what the upstart people say in comparison to what the systemd people say, and especially the way some of them say it, it's looking as if upstart is the preferable init system for me. Compare your posts with vorlon's in this particular thread, for example (approx bout 6 of this particular fight).

Did you see that? it wasn't a technical argument. You will dismiss it along with all the previous ones. You still won't have got me on your side.

Remarks about the benchmark

Posted Dec 17, 2012 17:28 UTC (Mon) by raven667 (subscriber, #5198) [Link] (1 responses)

> ... comparison to what the systemd people say, and especially the way some of them say it, it's looking as if upstart is the preferable init system for me

I would just like to point out that regardless of what HelloWorld or oldthomas or you or I say it doesn't change the design and implementation of Upstart and systemd so there are real technical arguments and you can safely ignore partisans and fan-bois on either end.

For my part the systemd design of dependancy resolution for process startup, the process monitoring and watchdog that gets rid of the need for daemontools, the reliable process shutdown and ability to have multiple instances of a particular daemon without having to do brain surgery, the simple config file format with includes and clear overrides that allows one to repeatably set up the process runtime environment, the built-in support for all the Linux container and security and resource management features and on and on and on are reasons why I think systemd is the better tool.

It's kind of similar to the arguments around SVN and git replacing CVS, there are real technical reasons why so many distros who didn't find enough value to make the jump to Upstart are jumping to systemd.

Remarks about the benchmark

Posted Dec 17, 2012 18:03 UTC (Mon) by wookey (guest, #5501) [Link]

Right, but ultimately either of these init systems will clearly work fine for undemanding users, so I'm (currently) inclined to give my (rather limited) support to the inclusive one not the one with all the irritating w*ankers in tow. Ultimately I'm happy that changing my mind is a simple apt-get away anyway, as I'm a Debian user, and I appreciate that people have made the effort to give me that choice. I think that's important.

And relating to your analogy, I'm one of the people that much prefers SVN over git, so am clearly a hopeless luddite anyway. :-)

Remarks about the benchmark

Posted Dec 4, 2012 14:06 UTC (Tue) by nix (subscriber, #2304) [Link] (4 responses)

You missed a bit: it's not just that sysvinit is small, it's also that it's almost maintenance-dead. Thus, it is highly unlikely that it contains significant unknown crash bugs. systemd is relatively new and rapidly changing, so its probability of containing unknown crash bugs is much higher.

I treat init like filesystems, and don't use inits that are still changing a lot or only a few years old for anything important. systemd still falls into both categories. In time, it will emerge from them and become mature (i.e. closer to dead :) ) and thus safe to use for real work in the view of paranoid maniacs like me.

Stable software

Posted Dec 4, 2012 20:53 UTC (Tue) by man_ls (guest, #15091) [Link] (3 responses)

Not just for paranoid maniacs. "Stable" has two meanings: "robust" and "unchanging", and both are highly correlated: software that changes tends to be brittle. When clients say that they want software to be "stable" while it is changing I tend to think to myself "Well, don't change it then".

Stable software

Posted Dec 5, 2012 0:33 UTC (Wed) by nix (subscriber, #2304) [Link]

Oh yes. We want it stable! Give us $new_feature yesterday!

Stable software

Posted Dec 5, 2012 1:03 UTC (Wed) by HelloWorld (guest, #56129) [Link] (1 responses)

> Not just for paranoid maniacs. "Stable" has two meanings: "robust" and "unchanging", and both are highly correlated: software that changes tends to be brittle.
I don't buy that. There are dozens of projects that prove that it's perfectly possible to develop new features while not introducing regressions all the time, such as Apache httpd, Postfix, PostgreSQL and many others.

Robustness is primarily a result of good design, developer competence, care and good development practices, not of age and lack of changes. Sendmail has had much more time to mature than Postfix, yet the latter has had far fewer vulnerabilities. And BIND 8 was so broken that they decided to throw it away and start over, resulting in the much more robust BIND 9.

Stable software

Posted Dec 5, 2012 10:21 UTC (Wed) by man_ls (guest, #15091) [Link]

I agree; I should have specified "software that changes too fast". In my opinion, stability is a result of developing at the right speed and using good practices.

Is there a way to quantify the right speed? Allow me to link my own post about reversible software development. Rushed developments are highly irreversible and always result in instabilities.

Remarks about the benchmark

Posted Dec 3, 2012 16:44 UTC (Mon) by JanC_ (guest, #34940) [Link] (3 responses)

Debian should pick a single init system, and it's obviously systemd given its technical superiority over all its contenders. kFreeBSD must obviously use sysvinit, as neither systemd nor upstart run on the FreeBSD kernel, but it should be used only on kFreeBSD. That way, eventual sysvinit breakage will be confined to users of that OS.

Considering that kFreeBSD is a first class member of the Debian family, and they use the same source packages as linux, it should be obvious that there is only one way to do that: support (at least) two init systems in Debian. And if they would have to choose one and only one init system, then systemd would not be an option at all.

Another good reason to support multiple init systems might be that it allows competition, which in turn fosters innovation (why would you keep innovating something if you can sit on your lazy ass or do something else instead?).

Remarks about the benchmark

Posted Dec 3, 2012 16:49 UTC (Mon) by HelloWorld (guest, #56129) [Link] (2 responses)

Considering that kFreeBSD is a first class member of the Debian family, and they use the same source packages as linux, it should be obvious that there is only one way to do that: support (at least) two init systems in Debian.

No. There's no reason to support sysvinit on Debian GNU/Linux just because it's required on Debian GNU/kFreeBSD. There are already many packages that are supported on only one of the two.

Remarks about the benchmark

Posted Dec 3, 2012 18:36 UTC (Mon) by JanC_ (guest, #34940) [Link] (1 responses)

AFAIK those packages are kernel-specific tools or other applications that (for some reason) don't work on one or the other kernel (yet), but there is no reason why sysvinit would not work on linux (as long as somebody keeps maintaining it on linux).

The point is: once you add support for sysvinit to a package that runs on both kernels (which you have to do anyway, as Debian kFreeBSD requires it), you have already done the work to support two init systems, and there is no point in *removing* it again. (Maybe you could say that one init system is the default, and that others are supported on a best-efforts basis, but doing *extra work* to remove something that already works and doesn't break anything else is silly.)

Also, you didn't address my other point: if it were forbidden to add alternative init systems to Debian (and/or other distros), then right now systemd or upstart would likely not be in Debian at all.
And it would also not be possible for the actual users to compare which one works best in practice (taking into account a lot more real world use cases than any Debian maintainer or upstream developers can test).

Remarks about the benchmark

Posted Dec 3, 2012 19:14 UTC (Mon) by HelloWorld (guest, #56129) [Link]

The point is: once you add support for sysvinit to a package that runs on both kernels (which you have to do anyway, as Debian kFreeBSD requires it), you have already done the work to support two init systems, and there is no point in *removing* it again.

Good point, but I think you're missing something :)

If sysvinit is only supported on kFreeBSD, that allows you to use all kinds of FreeBSD craziness in your init scripts, such as jails or whatever else the FreeBSD kernel has to offer. It's like systemd's use of cgroups and whatnot, just the other way around.

Of course it's possible to check inside the init scripts what kernel you're running on, but this again increases complexity and need for testing, so the question is, why bother, when there's a better Linux alternative available anyway?

Also, you didn't address my other point: if it were forbidden to add alternative init systems to Debian (and/or other distros), then right now systemd or upstart would likely not be in Debian at all.

Why do you think that? Choices like these aren't set in stone. They can be revised when a better alternative comes along, just like Fedora dropped upstart when systemd showed up.

Langasek: Upstart in Debian

Posted Nov 27, 2012 12:39 UTC (Tue) by Eckhart (guest, #74500) [Link]

> Well, a quick look at the system shows one possible contributing factor: the rsyslog package in Debian has a systemd unit file, but not an upstart job file.

Actually, this shows a possible contributing factor why *systemd* is slow: it has to start both the journal and rsyslog.
The comparison is probably more balanced if you disable rsyslog for systemd boot and make journal logging persistent.

Langasek: Upstart in Debian

Posted Nov 27, 2012 15:46 UTC (Tue) by bronson (subscriber, #4806) [Link] (1 responses)

> I also noticed that having systemd installed would slow down booting with other init systems, because systemd installs udev rules which take a noticeable amount of time to run a helper command at boot even though the helper should be a no-op.

How odd. That sounds worthy of a bug report too.

Very nice work Steve. Objective science is always better than guessing and yelling!

Langasek: Upstart in Debian

Posted Nov 27, 2012 20:27 UTC (Tue) by mbiebl (subscriber, #41876) [Link]

A bug report would have been great.
That said, a fix has already been committed (to the Debian package, at least)

http://anonscm.debian.org/gitweb/?p=pkg-systemd/systemd.git;...

Langasek: Upstart in Debian

Posted Nov 27, 2012 17:06 UTC (Tue) by JEFFREY (guest, #79095) [Link] (7 responses)

I don't want to see a comparison on how many boot-time seconds may be saved by various inits for an operating system that is largely used on systems that are seldom booted (such that seldom <= 2 boots/day).

I want to see a chart that compares how *long* it takes a "System Administrator I" with 1 year of experience and no Internet access to troubleshoot init problems. The only documentation the sysadmin test subjects shall have are the man pages and /usr/share/docs.

Langasek: Upstart in Debian

Posted Nov 27, 2012 17:23 UTC (Tue) by HelloWorld (guest, #56129) [Link] (5 responses)

> The only documentation the sysadmin test subjects shall have are the man pages and /usr/share/docs.
What's the point of this artificial restriction?

Langasek: Upstart in Debian

Posted Nov 27, 2012 17:58 UTC (Tue) by cortana (subscriber, #24596) [Link] (4 responses)

Is it even much of a restriction? systemd's documentation is excellent.

I was at this point going to make a snide comment about sysvinit's documentation, but it's actually also gotten a lot better since I last read it (currently using 2.88 here).

Langasek: Upstart in Debian

Posted Nov 27, 2012 18:23 UTC (Tue) by HelloWorld (guest, #56129) [Link] (3 responses)

> Is it even much of a restriction?
No, I was just wondering why. One can almost always access the web in practice.

Langasek: Upstart in Debian

Posted Nov 27, 2012 22:10 UTC (Tue) by JEFFREY (guest, #79095) [Link] (2 responses)

There are several good reasons for this restriction.

Let's assume the only computer at-hand is the one with an init problem and no cell-phones are allowed on-site. If one of the services that will not start is "Network", then suddenly not having Internet access is a reality and the provided documentation becomes suddenly more important.

Also, this lends itself to be a good test of the documentation. When I evaluate software, documentation is also considered. I prefer a package with a few bugs and excellent documentation (excellent documentation might even include a list of known-issues or bugs) over a package with no known flaws but horrible documentation. As a sysadmin, I place great value on being able to trust the documentation, and, based on the documentation, to be able to predict how the software will run under various conditions.

Langasek: Upstart in Debian

Posted Nov 28, 2012 5:18 UTC (Wed) by sorpigal (subscriber, #36106) [Link]

Even if the network service starts it doesn't mean the internet is routable. I've had to work with plenty of systems which were not connected and never will be.

Langasek: Upstart in Debian

Posted Nov 28, 2012 6:01 UTC (Wed) by set (guest, #4788) [Link]

The init system is simply an automated system for doing all the things a capable sysadmin should be able to do manually. i.e. if the internet is available and you cannot connect to it, or a filesystem needs mounting and you cannot do that outside the aegis of the init system, there are worse problems at hand.

Personally, I recently upgraded a very outdated Arch system, and in the process changed over to systemd. The least of my problems was learning my way around systemd. It didnt seem that alien, compared to the sort of wrappers I am used to on Gentoo. I even tried out the journal logging. For my use case, it seems awkward and slow, but you can just use your old syslog daemon if you want to ignore that. I can see where it could be great for people who need to do automated forensics on logs via scripting and the like, though.

Langasek: Upstart in Debian

Posted Nov 27, 2012 17:24 UTC (Tue) by tuna (guest, #44480) [Link]

I want a pony.

Langasek: Upstart in Debian

Posted Nov 27, 2012 17:53 UTC (Tue) by jspaleta (subscriber, #50639) [Link]

One question. The original article did not list the average of for the SysV managed boot. Please correct me if I'm wrong but the original article only shows the max and min for the Sysinit.. not the mean.
Could I please have a clean listing of mean for all the implementations under test?

Here's my succinct summary of the benchmark data.
but based on what I read here's the summary
SysV best case: 3.37
upstart best case: 2.78 diff from SysV: -0.59
systemd best case: 2.32 diff from upstart: -0.56 diff from sysV: -1.05

SysV worst case: 3.42
upstart worst case: 3.03 diff from SysV: -0.39
systemd worst case: 2.85 diff from upstart: -0.18 diff from sysV: -0.57

SysV mean case: ?.??
upstart mean case: 2.92 diff from SysV: ??
systemd mean case: 2.48 diff from upstart: -0.44 diff from sysV: ??

I'd really like to see this test repeated under real world workloads to see how the performance scales into expected real world provisioning situations.

Much ado about init

Posted Nov 27, 2012 19:18 UTC (Tue) by mgb (guest, #3226) [Link] (7 responses)

I'm guess I'm getting old.

I've Unixed thirty years from Version 7 to Debian Sid. I've found lots of bugs and I've fixed a few. And I've never ever had a problem with init. Never.

Never had a daemon escape by double forking. Never had a user complain that boot was too slow. Not even once. Compared to the downtime for Windows upgrades and reinstalls, Linux availability is a blessed miracle.

But then I saw all those people queuing round the block for the latest and silliest Windows 8.

And I realized they would have picked Debian instead if only I could have assured them that systemd ruled Stable.

Much ado about init

Posted Nov 27, 2012 20:17 UTC (Tue) by vonbrand (subscriber, #4458) [Link]

Weird. I've got some 25 years of Unix experience, and I do remember lots of problems booting assorted machines, and starting up bog-standard services. Sure, nothing to blame directly on init (or sysvinit for Linux), but many, many times scratching head, reading cobbled together (probably written in the stone age and then "forward ported" innumerable times) scripts, trying to make sense of strange command arguments and pipelines. Suspecting that some code was there just because some experiment on a machine long turned to dust showed that that way it did miraculously work. No, definitely not fun. At least in Red Hat they did mostly rewrite the scripts from scratch, with some family resemblance among them. Before that, it was just hopeless.

Much ado about init

Posted Nov 28, 2012 5:03 UTC (Wed) by mjg59 (subscriber, #23239) [Link] (5 responses)

/etc/init.d/bind9 restart on Debian stable still sometimes leaves me with the old bind still running. Does Windows do better? I don't know, I've never run a DNS server on Windows. All I know is that Linux *can* do better, and if you took all the time I've wasted working out why I'm still getting wrong lookups and put it together I could have enjoyed a decent quantity of the fine things in life instead.

Much ado about init

Posted Nov 28, 2012 6:45 UTC (Wed) by mgb (guest, #3226) [Link] (3 responses)

I've never had such a problem restarting bind9. What was your bug number?

Of course bind9 restarts are relatively infrequent. One normally reloads.

Much ado about init

Posted Nov 28, 2012 6:56 UTC (Wed) by mjg59 (subscriber, #23239) [Link] (1 responses)

> What was your bug number?

Unfiled. Does that mean it didn't happen to me?

Much ado about init

Posted Nov 28, 2012 11:45 UTC (Wed) by debacle (subscriber, #7114) [Link]

It probably does mean, it was not relevant to you, at least not sufficiently relevant to file a bug ;~)

Well, I had a lot of problems with sysv-init, too (and never filed a bug about it).

Much ado about init

Posted Nov 28, 2012 14:47 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

Hah. You're lucky.

I had once to go to our datacenter at about 3am to power-cycle a server because freaking bind9 hanged during the restart after the sshd was killed. There was due to a bug which manifested only if dnssec signing and validation was enabled (which still is not usual) so maintainers missed it.

Much ado about init

Posted Nov 28, 2012 23:35 UTC (Wed) by marcH (subscriber, #57642) [Link]

> I could have enjoyed a decent quantity of the fine things in life instead.

Can't get enough of EFI, heh?

Langasek: Upstart in Debian

Posted Nov 27, 2012 20:35 UTC (Tue) by debacle (subscriber, #7114) [Link]

One remark from an upstart-on-Debian user:

In my company we use upstart on our product, an embedded system, mainly because at that time it was the most suitable init system on Debian: It starts and stops our daemons, it handles dependencies between them, it does restart crashed ones - that's what we needed. Boot times were not relevant in the decision at all.

Replacing sysv-init with upstart was easy and straightforward, so I assume we will stay with upstart when we in some distant day upgrade from Debian 6 to 7.

I'm saying nothing here against systemd, which at the time just was not available in Debian, if I remember correctly. We are totally agnostic in respect to the init system, as long as it does what we want, i.e. is not sysv-init.

Langasek: Upstart in Debian

Posted Nov 28, 2012 8:32 UTC (Wed) by marcH (subscriber, #57642) [Link]

Just found by accident that the default bootloader in my default openSUSE 12.2 install has the following menu available by default: systemd versus systemV versus even a few other choices I can't remember.

Tried these two and could not see any difference from far. No time for a closer look I'm afraid.