Recent Features
| |||||||||||||
Remarks about the benchmarkRemarks about the benchmarkPosted Nov 27, 2012 10:09 UTC (Tue) by man_ls (subscriber, #15091)Parent article: Langasek: Upstart in Debian 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.
(Log in to post comments)
Remarks about the benchmark Posted Nov 27, 2012 11:32 UTC (Tue) by jbglaw (subscriber, #10406) [Link]
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 (subscriber, #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]
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 (subscriber, #15091) [Link] 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]
> 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 (subscriber, #9631) [Link]
"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 (subscriber, #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.
Remarks about the benchmark Posted Nov 28, 2012 9:06 UTC (Wed) by oldtomas (guest, #72579) [Link]
> > [...] 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]
> 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]
> 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
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]
> 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 (✭ supporter ✭, #313) [Link]
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] 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]
> > 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
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]
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 (✭ supporter ✭, #313) [Link]
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]
> 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 (subscriber, #5501) [Link]
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]
> ... 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 (subscriber, #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]
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 (subscriber, #15091) [Link] 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]
> 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 (subscriber, #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] 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] 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]
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.
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.
|
|||||||||||||