Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
- 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.
Disclaimer: I rewrote bootchart version and work on systemd user sessions.
Some changes needed...
Posted Nov 27, 2012 0:49 UTC (Tue) by vorlon42 (subscriber, #28435)
Posted Nov 27, 2012 4:22 UTC (Tue) by airlied (subscriber, #9104)
seems like a flaw in your own logic.
Posted Nov 27, 2012 4:37 UTC (Tue) by s0f4r (guest, #52284)
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)
Posted Nov 27, 2012 12:33 UTC (Tue) by vonbrand (subscriber, #4458)
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.
Posted Nov 27, 2012 15:55 UTC (Tue) by Zack (guest, #37335)
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.
Posted Nov 27, 2012 16:29 UTC (Tue) by mathstuf (subscriber, #69389)
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?
Posted Nov 27, 2012 18:24 UTC (Tue) by Zack (guest, #37335)
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.
Posted Nov 27, 2012 19:26 UTC (Tue) by mathstuf (subscriber, #69389)
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.
Posted Nov 27, 2012 22:34 UTC (Tue) by Zack (guest, #37335)
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.
Posted Nov 27, 2012 23:54 UTC (Tue) by Eckhart (guest, #74500)
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.
Posted Nov 28, 2012 0:02 UTC (Wed) by dlang (✭ supporter ✭, #313)
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.
Posted Nov 28, 2012 0:43 UTC (Wed) by mathstuf (subscriber, #69389)
> 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.
Posted Nov 28, 2012 2:02 UTC (Wed) by Eckhart (guest, #74500)
> 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.)
Posted Nov 28, 2012 16:50 UTC (Wed) by nye (guest, #51576)
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.
Posted Nov 28, 2012 19:15 UTC (Wed) by Eckhart (guest, #74500)
According to systemd developers "limited functionality mode" means "expect breakage" and "might allow you to compile a kernel with cgroups if you are lucky".
Posted Nov 28, 2012 14:31 UTC (Wed) by HelloWorld (guest, #56129)
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.
Posted Nov 27, 2012 20:31 UTC (Tue) by HelloWorld (guest, #56129)
> 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.
Posted Nov 28, 2012 11:01 UTC (Wed) by Wol (guest, #4433)
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.
Posted Nov 28, 2012 11:28 UTC (Wed) by paulj (subscriber, #341)
Posted Dec 3, 2012 13:50 UTC (Mon) by JanC_ (guest, #34940)
Yes, it is, and it applies to the internet (originally the TCP/IP protocol), not unix. (It is also often misunderstood...)
Posted Nov 28, 2012 14:06 UTC (Wed) by mathstuf (subscriber, #69389)
Well, okay, flat volumes suck, but that's been added to my dotfiles.
Posted Nov 28, 2012 16:24 UTC (Wed) by raven667 (subscriber, #5198)
Posted Nov 28, 2012 16:57 UTC (Wed) by nye (guest, #51576)
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.
Posted Nov 28, 2012 17:07 UTC (Wed) by Cyberax (✭ supporter ✭, #52523)
Posted Nov 28, 2012 17:50 UTC (Wed) by nye (guest, #51576)
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.)
Posted Nov 28, 2012 17:58 UTC (Wed) by mathstuf (subscriber, #69389)
Was this a package maintainer or upstream?
Posted Nov 28, 2012 18:52 UTC (Wed) by cortana (subscriber, #24596)
Posted Nov 28, 2012 19:06 UTC (Wed) by mathstuf (subscriber, #69389)
Posted Dec 1, 2012 15:05 UTC (Sat) by viiru (subscriber, #53129)
Yes there is, the Technical Committee (see http://www.debian.org/devel/tech-ctte ).
Posted Nov 28, 2012 22:24 UTC (Wed) by HelloWorld (guest, #56129)
Posted Nov 28, 2012 17:41 UTC (Wed) by HelloWorld (guest, #56129)
Posted Nov 28, 2012 12:35 UTC (Wed) by dgm (subscriber, #49227)
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?
Posted Nov 28, 2012 13:49 UTC (Wed) by Zack (guest, #37335)
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.
Posted Nov 28, 2012 14:13 UTC (Wed) by mathstuf (subscriber, #69389)
Posted Nov 28, 2012 17:31 UTC (Wed) by nye (guest, #51576)
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.
Posted Nov 28, 2012 17:56 UTC (Wed) by mathstuf (subscriber, #69389)
Posted Nov 28, 2012 19:18 UTC (Wed) by reedstrm (guest, #8467)
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.
Posted Nov 28, 2012 18:06 UTC (Wed) by nye (guest, #51576)
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.
Posted Nov 28, 2012 22:18 UTC (Wed) by louie (subscriber, #3285)
Posted Nov 29, 2012 14:42 UTC (Thu) by dgm (subscriber, #49227)
Posted Nov 28, 2012 4:48 UTC (Wed) by sorpigal (subscriber, #36106)
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?
Posted Nov 28, 2012 10:55 UTC (Wed) by ovitters (subscriber, #27950)
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.
Posted Nov 28, 2012 22:58 UTC (Wed) by sorpigal (subscriber, #36106)
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).
Posted Nov 28, 2012 23:39 UTC (Wed) by mathstuf (subscriber, #69389)
Posted Dec 3, 2012 2:36 UTC (Mon) by gfa (subscriber, #53331)
use LSB headers, supported on more distros than systemd or/and upstart
Posted Nov 27, 2012 16:59 UTC (Tue) by HelloWorld (guest, #56129)
Posted Nov 28, 2012 7:52 UTC (Wed) by niner (subscriber, #26151)
No, there's simply no way to teach this to sysvinit. It's a genuine advantage of having init use cgroups for managing deamons.
Posted Dec 3, 2012 14:09 UTC (Mon) by JanC_ (guest, #34940)
Posted Dec 6, 2012 15:56 UTC (Thu) by HelloWorld (guest, #56129)
Posted Dec 7, 2012 7:30 UTC (Fri) by mathstuf (subscriber, #69389)
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds