| |||||||||||||
Some changes needed...Some changes needed...Posted Nov 26, 2012 22:59 UTC (Mon) by s0f4r (guest, #52284)Parent article: Langasek: Upstart in Debian
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.
(Log in to post comments)
Some changes needed... Posted Nov 27, 2012 0:49 UTC (Tue) by vorlon42 (subscriber, #28435) [Link]
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]
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]
>>- 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]
> (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]
"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.
>> a poorly architected replacement
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]
> 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]
>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.
>As an example, some of the features systemd provides expect something like the cgroups API to exist.
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]
> 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 (✭ supporter ✭, #313) [Link]
> 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]
> 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 (guest, #51576) [Link]
>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]
> 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.
Some changes needed... Posted Nov 28, 2012 11:01 UTC (Wed) by Wol (guest, #4433) [Link]
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,
Some changes needed... Posted Nov 28, 2012 11:28 UTC (Wed) by paulj (subscriber, #341) [Link]
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]
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 (guest, #51576) [Link]
>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]
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 (guest, #51576) [Link]
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]
> "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 19:06 UTC (Wed) by mathstuf (subscriber, #69389) [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?
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]
> 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".
> 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.
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,
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 (guest, #51576) [Link]
>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]
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 (guest, #51576) [Link]
>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 (subscriber, #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]
> 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 (subscriber, #27950) [Link]
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]
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 (subscriber, #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 (subscriber, #26151) [Link]
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]
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?
|
|||||||||||||