| |||||||||||||
Poettering: The Biggest MythsPoettering: The Biggest MythsPosted Jan 27, 2013 4:25 UTC (Sun) by rgmoore (✭ supporter ✭, #75)In reply to: Poettering: The Biggest Myths by mgb Parent article: Poettering: The Biggest Myths
UNIX and Linux are evolving tool sets. Yes, and part of that evolution is replacement of components of the system with new components as the demands of the system change. It seems to me that the people screaming that it's unnecessary to replace a 30 year old component that is obviously crufty and full of hacks are the ones standing in the way of Unix and Linux evolution, not the ones who are proposing a replacement.
(Log in to post comments)
Poettering: The Biggest Myths Posted Jan 27, 2013 4:39 UTC (Sun) by prometheanfire (subscriber, #65683) [Link]
It is not that the old system should not be overhauled (see openrc for a better init system imo). It's more that systemd aims to do too much, I want an init system and that's it, init...
Poettering: The Biggest Myths Posted Jan 27, 2013 5:48 UTC (Sun) by rgmoore (✭ supporter ✭, #75) [Link] I want an init system and that's it, init... I guess I understand the motivation, but it doesn't seem that it's necessarily a definitive answer. Yes, I understand the desire to keep traditionally separate components separate, but I also think that it's important to challenge assumptions about the way things ought to be from time to time. Replacing individual components can improve those individual components, but it can't fix design flaws about how the jobs were divided between components. That can only be fixed by changing the underlying architecture to divide the task differently. Bigger changes give the potential for bigger rewards. I won't claim to be a guru, but the explanations Mr. Poettering has given for his architectural changes seem reasonable to me. The changes he is making seem to be adding valuable functionality that is not available when components are kept separate. Given that he has plausible arguments for why he's breaking down traditional boundaries, I'd like to see counter-arguments that focus on the technical points he's making, e.g. how the new functionality he's adding could be produced with traditional modular tools and/or why it's insufficiently important to justify the changes he's making. Instead, I see a lot of criticism of his judgment and motivation but very little that directly challenges his technical decisions.
Poettering: The Biggest Myths Posted Jan 27, 2013 6:15 UTC (Sun) by prometheanfire (subscriber, #65683) [Link]
I see the personal attacks as a bad thing too. Forgot to add to my previous comment, but I am also interested in cross OS support, which is one thing that he stated not to support (which is too bad).
Poettering: The Biggest Myths Posted Jan 27, 2013 6:47 UTC (Sun) by raven667 (subscriber, #5198) [Link]
systemd isn't the largest body of code out there, if you wanted its features on another platform it would probably be best to use it as a guidepost and then re-implement it using your preferred OS native APIs for doing so.
Poettering: The Biggest Myths Posted Jan 27, 2013 6:57 UTC (Sun) by prometheanfire (subscriber, #65683) [Link]
I somehow doubt upstream would be receptive to that type of code (see eudev...)
Poettering: The Biggest Myths Posted Jan 27, 2013 7:08 UTC (Sun) by raven667 (subscriber, #5198) [Link]
That was my point, make a new project, say 'startupd', for your favorite OS using systemd as a design guide but not necessarily re-using code from it. Then you too can support your favorite OS security and container frameworks as well as process information, like/usr/bin/top which is different on every OS.
Poettering: The Biggest Myths Posted Jan 27, 2013 7:11 UTC (Sun) by prometheanfire (subscriber, #65683) [Link]
passive aggressiveness?
Poettering: The Biggest Myths Posted Jan 27, 2013 12:35 UTC (Sun) by smurf (subscriber, #17840) [Link]
What's "passive aggressive" about this?
Why should systemd eschew a whole lot of features of Linux which are simply not available elsewhere? More so if he cannot do half the ob he set out to do without them?
If you think he's wrong, and if you think something like systemd would be way cool to have on *BSD, write it yourself. I doubt that it'd be possible without kernel changes; systemd wasn't either.
NB: eudev is a rather bad example. I still fail to see which problem the eudev fork is supposed to solve.
Poettering: The Biggest Myths Posted Jan 27, 2013 23:17 UTC (Sun) by ewan (subscriber, #5533) [Link]
Indeed, some ideas in systemd are similar to things done in Apple's launchd - you don't need cross platform code or a friendly 'upstream' to be able to nick good ideas from where ever you find them.
Poettering: The Biggest Myths Posted Jan 28, 2013 5:21 UTC (Mon) by rsidd (subscriber, #2582) [Link] Actually, launchd is under the Apache licence -- why didn't Red Hat just take it? (There are claims that Ubuntu considered launchd in 2006 and rejected it because of its licence -- APSL at that time. Apple subsequently relicensed it.) Interestingly, one complaint about launchd I see from a Unix-loving mac user sounds exactly like some of the systemd complaints here: Reasonable people can argue the technical merits of launchd, and I think a case can be made for improving the original init system. However, I have a deeper philosophical problem with all the functionality that has been rolled into it: One of the core principles of Unix programing is do one thing and do it well. Another is keep things as simple as possible. From that perspective, launchd tries to do too many things, creating needless risk and complexity. Apple sees launchd as a natural improvement to traditional Unix; I view it as an anti-Unix monolith.
Poettering: The Biggest Myths Posted Jan 28, 2013 5:40 UTC (Mon) by raven667 (subscriber, #5198) [Link]
In a way they did take it, not the implementation but certainly the good ideas. They did research other systems including Solaris SMF and launchd as well as Upstart before picking out the best of all of them before implementing it the Linux way.
Poettering: The Biggest Myths Posted Jan 28, 2013 19:34 UTC (Mon) by k8to (subscriber, #15413) [Link]
Mentioning launchd is a good way to make me feel better about systemd. At least systemd has some kind of useful documentation. launchd leaves many aspects and values of its baroque xml completely undefined.
Poettering: The Biggest Myths Posted Jan 27, 2013 10:39 UTC (Sun) by ovitters (subscriber, #27950) [Link]
The entire boot process between distributions was already largely different. I've used Mandriva and now Mageia. The initscripts and more is often taken from Fedora, then adjusted. Somehow sysvinit has the reputation of being the same and portable. But in practice loads of things were different between distributions. The way Mandriva+Mageia booted was already hugely different than Fedora, despite that large parts were taken from Fedora.
Practical thing I'd like to do on a server is ensure via Puppet that the timezone is in UTC (not just the current timezone, also the one for all services, some of which have been started already). Now if you have servers running RHEL, Ubuntu, Debian, Cent OS and Fedora, you'll discover that the only easy way to do this is to rely on Google+hope someone had the same problem.
systemd more and more makes unneeded differences between distributions go away.
Poettering: The Biggest Myths Posted Jan 27, 2013 10:48 UTC (Sun) by prometheanfire (subscriber, #65683) [Link]
That's true, but when I say cross OS, I mean the bsds as well :D
Poettering: The Biggest Myths Posted Jan 27, 2013 13:00 UTC (Sun) by ovitters (subscriber, #27950) [Link]
That would be nice, but systemd uses lots of (kernel) features that are not available on *BSD. I also don't see *BSD using software that is not BSD licensed. At least that is what I understood from that OpenBSD developer who complained about GNU tools being different and that standards are updated to include those GNU features. If something like 'sed' is a problem, I doubt that relying on a non-GPL init system is acceptable.
Poettering: The Biggest Myths Posted Jan 27, 2013 16:40 UTC (Sun) by smurf (subscriber, #17840) [Link]
Perhaps those features just make sense, and they complain because they didn't think of them first?
Anyway, nothing prevents them from implementing what's missing on their side.
In related news, *bsd came up with strlcpy(). Do we go to them and complain that it's non-standard? No, we go to our libc maintainer and complain that he doesn't want to include that in the standard library.
I see a fundamental asymmetry here. Which might just be part of the reason there are >=3 BSDs out there, but just one single Linux. :-P
Poettering: The Biggest Myths Posted Jan 28, 2013 1:05 UTC (Mon) by mezcalero (subscriber, #45103) [Link]
Actually, I find the discussion around strlcpy() interesting, because I can actually understand the points Drepper makes about it, and I think I side with him on it on the opinion that it doesn't really lead to better code... (I know for sure at least that I never needed a call like that when hacking on systemd.)
The thing is simply that strlcpy() leads people to use fixed size arrays to store possibly much longer data in it, so they want the truncation. But if you do this, then you tend to hide a problem with it, and instead you should have the checked the length of the argument in the first place and returned an error (after all the general rule is to always check your input!). Implicit truncation without error condition is almost never a good idea. And if you didn't check explicitly for the overly long string, then you should handle that string in its entirety properly, which generally means dynamically allocated memory of the correct size, which still not requires strlcpy().
I do see a valid usecase for some ways to call strncpy() (to fill in fixed size strings in structs where you usually want to zero out the rest of the string), and there's a very useful usecase for strdup() -- but strlcpy(), not so sure.
But, then again, given how trivial the call is, and how many people want it, if I was glibc hacker I'd still merge it... This shouldn't be fought with the fervour that people fight it with.
Poettering: The Biggest Myths Posted Jan 28, 2013 10:50 UTC (Mon) by smurf (subscriber, #17840) [Link]
It's in libbsd, so if you want it it's there.
Anyway, strlcpy was intended to be an example of the different styles of handling NIH situations in Linux vs. *BSD land. I didn't exactly intend to trigger yet another strlcpy sub-discussion. ;-)
Poettering: The Biggest Myths Posted Jan 28, 2013 15:59 UTC (Mon) by epa (subscriber, #39769) [Link]
Unfortunately the kind of programmers who use fixed size arrays will do so with or without strlcpy() being in the standard library. Given that, you might as well provide the tools to do so safely rather than push people towards the more dangerous strcpy(). And there is no harm in a belt-and-braces approach, where you check the length of every input string and return a sensible failure message, but then use strlcpy() and other safe functions *just in case* you accidentally missed a check somewhere. Silently truncating is bad, but it's much the lesser evil compared to a buffer overrun.
Poettering: The Biggest Myths Posted Jan 28, 2013 19:42 UTC (Mon) by k8to (subscriber, #15413) [Link]
I work on various code written in various styles.
Sometimes I work on code that is assembling various things into buffers in order to generate a representation out-of-program, like on disk or on the wire. These things often work with fixed sized buffers into which they are assembling data, because the data representation has a fixed size.
In this case, changing codepaths to use strlcopy gives SIGNIFICANT improvements in safety. strncpy is not acceptable in these cases because it will incur large performance penalties with the null padding. Yes, we try to have sane and well placed logic to enforce the sizing, but putting the logic in each callsite is just begging for overruns which can be unacceptable in some use cases, so strlcpy gives us some safeguard, despite being careful in the logic.
Poettering: The Biggest Myths Posted Jan 27, 2013 13:43 UTC (Sun) by man_ls (subscriber, #15091) [Link] Now if you have servers running RHEL, Ubuntu, Debian, Cent OS and Fedora [...] systemd more and more makes unneeded differences between distributions go away.In fact the problems are exactly the same, since neither Ubuntu or Debian have systemd and the others are a monoculture. Even if Debian accepts systemd as an alternative it will not be the default. As many people have said before, it would be different if Red Hat (or Fedora) had adopted Upstart which was already available, perhaps improving on it along the way. As it is, you will need two or three sets of init scripts -- the best shot seems to be a single tweaked SysV init script. Which is sad.
Poettering: The Biggest Myths Posted Jan 27, 2013 13:58 UTC (Sun) by pizza (subscriber, #46) [Link]
Have you actually tried to maintain a meaningful cross-distro init script? Judging by your comments (ie "a single tweaked SysV init script") I'd say you haven't.
Those "tweaks" are where nearly all of your pain comes from. Hell, even in the same distro, one release to the next can require different tweaks. And of course they all have to be simultaneously supported.
Myths not debunked but confirmed Posted Jan 27, 2013 15:22 UTC (Sun) by man_ls (subscriber, #15091) [Link] No, I haven't had that bad luck.I have recently used Upstart and I have to say that it is very nice; I cannot see why Poettering et al couldn't work with Ubuntu despite what the article says. Dependency management? Surely that could have been solved differently and deprecated with time. Contributor agreement is a problem for six full time Red Hat developers? Sounds like NIH in disguise: leaving a strategic component in the hands of a rival. Having Upstart transform the face of Linux init would have been great. Even a fork of Upstart might have been tolerable. As it is, they have created the infamous (n+1)th standard -- and are even proud of it. Just for that they should be ostracized by the community.
Myths not debunked but confirmed Posted Jan 27, 2013 15:42 UTC (Sun) by cortana (subscriber, #24596) [Link]
I dunno, their (n+1)th standard has been adopted by several distributions, which I assume previously all had their own home grown startup scripts and config files. I think the post-systemd world has fewer standards than before.
Myths not debunked but confirmed Posted Jan 27, 2013 15:55 UTC (Sun) by niner (subscriber, #26151) [Link]
If Upstart is so great, why is it only used by Ubuntu and a few small others while systemd got adopted by openSUSE, Mageia, Arch, Fedora and others. Except for Fedora, NIH cannot explain any of these. Noone at openSUSE was enthusiastic about including Upstart, probably simply because Upstart doesn't solve any problem. SUSE already had parallel startup for a decade. systemd on the other hand solves real problems and helps getting rid of a really overcomplicated and fragile part of the system.
Myths not debunked but confirmed Posted Jan 27, 2013 16:10 UTC (Sun) by man_ls (subscriber, #15091) [Link] So apparently Fedora, Red Hat (plus all derivatives), Debian, Maemo, ChromeOS, NixOS, WebOS are just "a few small others"; while OpenSuse Mageia, Arch are "major ones"?Allow me to reverse your argument: if Upstart was so lousy, why was it adopted by Fedora, Red Hat, Debian and Ubuntu at all?
Myths not debunked but confirmed Posted Jan 27, 2013 16:26 UTC (Sun) by niner (subscriber, #26151) [Link]
Please read the article these comments are about. They used it, because it seemed to be better than what they had, but it was not good enough to be the solution they were really looking for.
Fedora does not use Upstart anymore. Red Hat will follow. AFAIK Debian still uses SysV init.
Myths not debunked but confirmed Posted Jan 27, 2013 18:30 UTC (Sun) by smurf (subscriber, #17840) [Link]
Debian has all three of them. They think about switching to systemd and auto-generate the others' config files (which requires limiting the alowed stanzas to some subset). After the Wheezy release. Whenever *that* is.
Good idea if you ask me.
Myths not debunked but confirmed Posted Jan 28, 2013 20:25 UTC (Mon) by drag (subscriber, #31333) [Link]
No.
It's a _TERRIBLE_ idea.
If Systemd is such a burden, then why the hell is maintaining no less then three different init systems better?!
Between sticking with sysvinit, going upstart, or going systemd, Debian has choosen the worst possible outcome. I mean this is just mind boggling terrible decision making on the part of Debian. Choosing to do _anything_ else would of been a better move. A drunk hobo rolling dice would of done a better job.
And this is really sad thing for me to say, because Debian is one of the few distros that I actually like using.
Init systems in Debian Posted Jan 28, 2013 21:23 UTC (Mon) by man_ls (subscriber, #15091) [Link] Well, if things work well you will not feel the burden of maintenance, any more than with the myriad of desktop environments that Debian supports. You may argue that it is a waste since (GNOME|KDE|XFCE|...) provides anything that a grown adult may desire, but proponents of the others will not agree.And before you say that an init system is a core component... Debian maintains three different kernels, and one of them is not even widely used. Users familiar with one of the init systems will appreciate its existence. Interested users will be able to compare init systems side by side. The rest will be grateful for being able to migrate at their own pace. That for me is enough reason to have all three.
Init systems in Debian Posted Jan 28, 2013 21:42 UTC (Mon) by drag (subscriber, #31333) [Link]
I'd rather just have a system that actually works. I don't care about the implementation details as long as I don't have to deal with the implementation details.
By not choosing Debian has more then tripled the amount of workload they have to deal with to make the system function properly. This not only increases their workload, it exponentially increases the amount of bugs a person is likely to run into. It makes it harder to write software for the system because now you have at least 3 different operating systems personalities you have to deal with.
Throwing scripts at it to try to automate the creation of other scripts for upstart and sysinv just means that now instead of just supporting 3 different init systems they have to support 3 different init systems and a bunch of new scripts.
To put it another way:
* It makes the workload they have to deal with much higher. This is Debian's developers problem. Maybe they prefer to play around with init systems rather then having a working OS. I can't fault them for how they want to spend their time, but... if their goal is to have a stable working OS with lots of software and third party support it's not something that is going to help them any meaningful respect in that regard.
* It increases the burden of third parties writing and maintaining services much harder. This is something that anybody trying to use or support Debian is now forced to deal with.
* It exponentially increases the amounts of bugs any person is likely to run into with Debian init's system. This is something that will bite end users and will likely contribute to issues for people that try to use Debian in production.
This is why it's a bad decision. It makes the OS worse, not better. Maintaining different kernels is very silly also if your goal is to have anything other then a toy OS, but at least the non-linux-kernel-debian folks can be marginalized by the fact that nobody actually uses that stuff. Unlike KFreeBSD I expect that they will have users that actually expect that sysvinit, systemd and/or upstart works.
And what is the benefit? So I can compare init systems side by side? Doesn't seem like much of a return of on investment.
Init systems in Debian Posted Jan 28, 2013 22:05 UTC (Mon) by smurf (subscriber, #17840) [Link]
Debian didn't decide. Or rather, they discovered that any attempt to force a decision would fail, so they decided not to decide.
In any case, I am fairly optimistic that post-Wheezy the "best practice" way to start a service in Debian will be a native systemd script, with auto-generated SysV-ish shell scripts and/or upstart-esque config files, whenever there are no special requirements.
How much time will elapse until then, I have no idea and refuse to speculate about. This is Debian, after all. :-/
Init systems in Debian Posted Jan 28, 2013 22:08 UTC (Mon) by man_ls (subscriber, #15091) [Link] As stated above, the same argument could be made for desktop environments, text editors, graphical editors, spreadsheets and every other redundant set of programs; not only for kernels. Perhaps you are interested in a distribution that offers just one set of integrated, polished components. That is not Debian in my experience. And that is its strength, despite the burden of development.As to that burden, I expect that it will not be so difficult to develop for three init systems given that both Upstart and systemd claim to be SysV init-compatible. Even if the script automation script does not work out. I have had to customize init scripts every once in a while, this should not be too different.
Init systems in Debian Posted Jan 28, 2013 23:00 UTC (Mon) by ovitters (subscriber, #27950) [Link]
Various components have support for systemd. Some still fall back to other methods at runtime, some do not. This does add a lot of complexity, potential bugs, etc. I noticed this when Mageia switched to fully systemd in the development version. That just took a few days, because quite easy if the goal is systemd only. If you want to support all, I guess you might need to write some code because not every component (package) compiled with systemd support has that support as a runtime extra feature.
Init systems in Debian Posted Jan 29, 2013 16:51 UTC (Tue) by drag (subscriber, #31333) [Link]
The goal of the operating system is to make it easier to write and run applications/services. Anything that is done to make those activities more difficult then necessary is full of fail.
Myths not debunked but confirmed Posted Jan 29, 2013 0:01 UTC (Tue) by rahvin (subscriber, #16953) [Link]
As long as I've been using Debian there has been a default set of install options, but ultimately it was possible to replace nearly everything with "non-standard" components using the Debian archives.
In other words, even though they pick a "default" they understand that every user will have different preferences and where there is developer support for it they provide the options. Honestly if they had more volunteers they'd provide even more options. Hell, they even have a hurd port and no one has a hurd port.
That's the beauty of Debian, they don't pick sides, they pick a default for a base install then allow the user to rip out and replaces with options fairly painlessly. That's the Debian way I'm familiar with, not the Debian way you are advocating.
Myths not debunked but confirmed Posted Jan 29, 2013 17:56 UTC (Tue) by Wol (guest, #4433) [Link]
Going systemd is not an option. It only works on a subset of the systems supported by Debian.
Dunno about upstart - that may have the same problem.
So the only thing that will actually work across ALL supported platforms is SysV. But you've got to give people the OPTION of the others.
Cheers,
Myths not debunked but confirmed Posted Jan 30, 2013 8:36 UTC (Wed) by micka (subscriber, #38720) [Link]
Different systems could have a different default init system. After all, they already have a different default kernel.
Myths not debunked but confirmed Posted Jan 27, 2013 19:13 UTC (Sun) by man_ls (subscriber, #15091) [Link] I read the fine article, thanks. If Upstart was not good enough, why not improve upon it instead of building their own init system? The explanation in the "debunking" is not good enough; manual dependencies might be substituted with automatic dependencies, I don't see any technical hurdles there. The general ideas behind Upstart are still good. At the same time I don't see Upstart gaining all the "features" going on to span through 69 binaries.Debian has Upstart in testing right now, though not as the default.
Myths not debunked but confirmed Posted Jan 27, 2013 20:03 UTC (Sun) by Jonno (subscriber, #49613) [Link]
> If Upstart was not good enough, why not improve upon it instead of building their own init system?
They did for a few years, until they realised actually fixing some of their issues would have meant rewriting upstart from scratch, breaking compatibility with the original upstart in subtle ways. That would have been systemd in all but name anyway...
> Debian has Upstart in testing right now, though not as the default.
Myths not debunked but confirmed Posted Jan 27, 2013 23:39 UTC (Sun) by anselm (subscriber, #2796) [Link]
Systemd : Upstart : SysV-Init = Git : Subversion : CVS.
Myths not debunked but confirmed Posted Jan 28, 2013 9:45 UTC (Mon) by danpb (subscriber, #4831) [Link]
Couldn't agree more, i've frequently used this analogy myself when talking about SystemD to people. Just like GIT there's a bit of a learning curve because of the new concepts involved, but once you're past that, you'll never want to go back to the old ways.
Myths not debunked but confirmed Posted Jan 28, 2013 18:10 UTC (Mon) by ThinkRob (subscriber, #64513) [Link]
This would be a better analogy if CVS and Subversion were portable and Git was not, and the standard response to complaints about the complete inattention to portability were "yeah, well just use Linux because I don't want to hold Git back by making it run on obsolete OSs -- besides, you can always just keep using SVN".
Myths not debunked but confirmed Posted Jan 28, 2013 18:44 UTC (Mon) by apoelstra (subscriber, #75205) [Link]
> This would be a better analogy if CVS and Subversion were portable and Git was not, and the standard response to complaints about the complete inattention to portability were "yeah, well just use Linux because I don't want to hold Git back by making it run on obsolete OSs -- besides, you can always just keep using SVN".
Git technically works on non-POSIX systems, but it's painfully slow. CVS and Subversion were equal-opportunity crap.
Myths not debunked but confirmed Posted Jan 28, 2013 20:30 UTC (Mon) by drag (subscriber, #31333) [Link]
> This would be a better analogy if CVS and Subversion were portable and Git was not,
Sysvinit scripts are _NOT_ portable.
Myths not debunked but confirmed Posted Jan 28, 2013 20:39 UTC (Mon) by HelloWorld (guest, #56129) [Link]
Making systemd portable is essentially impossible (myth 16) and if it weren't, it'd be pointless (myth 13). So will you *please* stop bringing up this nonsense?
Myths not debunked but confirmed Posted Jan 28, 2013 12:13 UTC (Mon) by dgm (subscriber, #49227) [Link]
Well, I'm not so sure the analogy is correct. Git is build on a very simple core, with cleverly simple data structures, even if the porcelain is complex. Could it be more like:
SystemD : Upstart : SysV-Init =? Emacs : Vim : ed
Myths not debunked but confirmed Posted Jan 28, 2013 13:38 UTC (Mon) by anselm (subscriber, #2796) [Link] The main point of the analogy is that, just as Subversion is basically CVS with the most glaring problems papered over, Upstart is basically SysV-Init with the most glaring problems papered over. On the other hand, like Git, systemd represents a completely different way of attacking the problem at hand.
Myths not debunked but confirmed Posted Feb 2, 2013 10:04 UTC (Sat) by Kwpolska (guest, #89145) [Link] Vim is better than Emacs, but Upstart is worse than systemd.
systemd/upstart adoption Posted Jan 27, 2013 18:18 UTC (Sun) by HelloWorld (guest, #56129) [Link]
Maemo and WebOS are dead, Red Hat will switch to systemd with RHEL 7, Fedora already did, as did NixOS just days ago (http://www.mail-archive.com/nix-dev@lists.science.uu.nl/m...). Debian offers systemd in its unstable branch (they also have to ship sysvinit for the time being because of kFreeBSD). What does that leave? ChromeOS, because Scott James Remnant works there. Surprise, surprise...
systemd/upstart adoption Posted Jan 29, 2013 11:53 UTC (Tue) by oak (subscriber, #2786) [Link]
Systemd wasn't an option for Maemo because Systemd came after Maemo.
systemd/upstart adoption Posted Feb 5, 2013 0:55 UTC (Tue) by sonnyrao (subscriber, #11351) [Link]
I think that's pretty unfair to ChromeOS. Scott doesn't even really work on the system initialization part of ChromeOS, he's been working on Bluetooth support for quite a while. I think the reason systemd hasn't been investigated is more likely because the current system works and making system services boot faster hasn't been one of the most pressing problems for the project.
systemd/upstart adoption Posted Feb 5, 2013 19:00 UTC (Tue) by khim (subscriber, #9252) [Link] Fast boot is one of the important goals of ChromeOS. Systemd was not investigated because it will needs fine-tuning to work faster then the existing optimized boot and nobody have done the required work.
Myths not debunked but confirmed Posted Jan 27, 2013 21:10 UTC (Sun) by misc (subscriber, #73730) [Link]
Upstart is not bad, but not great. There is some design issues.
For one, the way it track process is by using ptrace. That's not a bad idea, but this doesn't work great for some kind of software. There is 2 bugs opened since 4 years about that ( https://bugs.launchpad.net/upstart/+bug/406397 and https://bugs.launchpad.net/upstart/+bug/703800 ).
Then upstart do not permit to have a daemon installed but not started. The state and the config file are conflated. See http://utcc.utoronto.ca/~cks/space/blog/linux/UpstartCoup... on the details.
On the same type of issue, there is this http://utcc.utoronto.ca/~cks/space/blog/linux/UpstartDepe... , ie, upstart config are just script, so that's the same problem.
The root cause is something solved by systemd, with the .include and the new directory system ( ie, using /etc/system/foo.unit.d/foo ).
Upstart config file are also harder to parse ( ie, this is a full blown DSL ), which doesn't help to create a tool to audit or modify them. While auditing is not something I ever seen, I know that some organisations requires this, so every roadblock that can be removed is better. And as someone involved into automated package checking, having a parsable format is better.
One last issue is the whole copyright assignation to Canonical, that AFAIK is always annoying since company exec tend to avoid letting people work on such projects ( and IMHO for good reasons ).
RHEL and Fedora did used Upstart for a time, Opensuse and Debian also looked at it at the same time. So if they collectively decided to not switch or to use something else, there is likely a technical reason.
Perhaps a myth after all Posted Jan 28, 2013 0:00 UTC (Mon) by man_ls (subscriber, #15091) [Link] Thanks for a very civil and informative answer. It makes me think that myth #9 is perhaps a myth after all.
Myths not debunked but confirmed Posted Jan 28, 2013 1:25 UTC (Mon) by mezcalero (subscriber, #45103) [Link]
To underline this, I think the sources of Upstart are really nice. It's very readable, well documented, has many tests. In many ways it's exemplary.
We didn't have any problems with the quality of code or anything. Heck, we have so much more bad code in our stack, Upstart totally stands out in quality. So, the implementation is fine, however the overall design was not, in our eyes, and that's very hard to fix without resulting in well, basically a pretty complete rewrite, and that's what we then did, after much consideration.
Myths not debunked but confirmed Posted Jan 28, 2013 10:23 UTC (Mon) by dmitrij.ledkov (subscriber, #63320) [Link]
In upstart, there is now support for /etc/init/foo.override file.
It's an overlay which can shadow any part of the job. E.g. echo "manual" >> /etc/init/foo.override will make sure that foo is never automatically started, only manually when a user does it explicitly.
For the NFS related dependency problem you outlined, sounds like you need a couple .overrides with modified "start on" conditions.
Myths not debunked but confirmed Posted Jan 28, 2013 10:15 UTC (Mon) by regala (subscriber, #15745) [Link]
you don't seem to even remotely know what you are talking about... Fedora, upstart ? Debian, upstart ? mmmm, 2013, man, 2013.
Myths not debunked but confirmed Posted Jan 27, 2013 20:44 UTC (Sun) by jubal (subscriber, #67202) [Link]
Upstart is used in ChromeOS too.
Nonsense. Posted Jan 27, 2013 16:28 UTC (Sun) by HelloWorld (guest, #56129) [Link]
> I cannot see why Poettering et al couldn't work with Ubuntu despite what the article says.
Then you probably you don't want to.
> Dependency management? Surely that could have been solved differently and deprecated with time.
> Contributor agreement is a problem for six full time Red Hat developers?
> Sounds like NIH in disguise: leaving a strategic component in the hands of a rival.
> Having Upstart transform the face of Linux init would have been great. Even a fork of Upstart might have been tolerable. As it is, they have created the infamous (n+1)th standard -- and are even proud of it.
Nonsense. Posted Jan 28, 2013 1:29 UTC (Mon) by mezcalero (subscriber, #45103) [Link]
Actually, don't blame Scott here, he's not involved since quite some time, and some things you attribute to him are probably things that came after his departure.
Myths not debunked but confirmed Posted Jan 27, 2013 18:20 UTC (Sun) by raven667 (subscriber, #5198) [Link]
They did work with Upstart, did all the work to integrate it with Fedora and RHEL, and have commented that they thought Upstart was very professionally written and reliable. The problem they found after implementing it is that its event based framework is fragile and doesn't solve the right problem. When they started looking around at other systems, such as launchd which runs the BSD-based Mac OS X, the found that using socket activation to allow services to be implicitly ordered automatically without needing admin intervention was a superior paradigm to the event framework that Upstart has. I believe they even looked at what it would take to modify Upstart to do auto-dependency resolution by socket activation and found that it would be too invasive and different and would break compatibility.
You can see the rationale yourself by reading blog entries by the creators or looking at recorded conference presentations on YouTube. systemd wasn't created on a whim, Lennart et. al. thought long and hard about creating N+1 init systems before tackling this problem.
Myths not debunked but confirmed Posted Jan 27, 2013 21:15 UTC (Sun) by misc (subscriber, #73730) [Link]
Having a list of such conference and articles would be helpful IMHO, only for documenting the past once for all.
Myths not debunked but confirmed Posted Jan 28, 2013 1:31 UTC (Mon) by mezcalero (subscriber, #45103) [Link]
Humm, we did not work on the integration of Upstart into Fedora. Neither Kay nor me should take credit for that work.
Myths not debunked but confirmed Posted Jan 28, 2013 4:57 UTC (Mon) by raven667 (subscriber, #5198) [Link]
My mistake, I misread and assumed.
I have seen recordings of some of your presentations, I'm not sure which one where you mentioned looking at Upstart, and praising its code quality, it may have been Pushing Big Changes at foss.in 2012. There are several conference videos on YouTube but I'm not going to re-watch them all just to get proper attribution.
I was skeptical about the Journal until I saw the practical demonstration video from T-DOSE 2012 on YouTube. It might be worthwhile to include links to these various conference videos on your blog in addition to the wonderful "systemd for Administrators" series, maybe the personal presentation will slow the tide of Internet hatemail, so much is lost when your only interaction is the written word.
Myths not debunked but confirmed Posted Jan 28, 2013 0:43 UTC (Mon) by alan (subscriber, #4018) [Link]
Creating an alternative design should never be ostracized. You happen to like Upstart. I happen to like systemd. We should have reasoned discussion about the pros and cons, which we will probably also see differently. Since when is diversity something to be criticized?
Myths not debunked but confirmed Posted Jan 28, 2013 2:21 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]
actually, very few people are saying that systemd should not exist.
What they are upset about is the push to make systemd mandatory (as we saw by the statements about how ubuntu is fragmenting linux by not switching to systemd)
RHEL is the 800 pound gorilla distro, if it does something, it impacts all other distros.
At this point we don't _know_ that RHEL is going to switch to systemd in the next release but the fact that systemd is being pushed by RedHat employees says that it's a real possibility.
I think it's a mistake to do so, RHEL customers have lots of sysadmins with lots of experience with sysV init, and many of those customers have lots of non-linux systems. They also have lots of old RHEL systems (many of them are still running RHEL4 and older)
Making the new RHEL systems have a completely different init system than the rest of the systems they run is not going to lead to happy admins, and taking the attitude that any admins who don't embrace having to re-learn the init system (in addition to all the other things they have to be learning to keep up) are fools who should loose their jobs is not going to improve things.
Many of these admins are working way over 40 hours/week as it is, and have a list of things they want to do (including many that are really rather important) that they don't have time to do that's months, if not years long.
it's not that they aren't willing to learn, it's that they don't see the value of disrupting this particular core piece and having to track multiple ways of doing the same thing, and remember to check which way the box they are logged into at the moment does things.
In many ways, this parallels the Gnome complaints. It really doesn't matter if the new way is better, the fact that it's so different, and therefor disruptive is a large part of the problem
Myths not debunked but confirmed Posted Jan 28, 2013 2:39 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link]
As you been informed with authoritative sources several times, we do know that RHEL is going to switch to systemd and btw, the switch is not from sys v but from upstart and both of them have sysv init compatibility and that weakens your arguments drastically.
Myths not debunked but confirmed Posted Jan 28, 2013 12:37 UTC (Mon) by HelloWorld (guest, #56129) [Link]
systemd offers a high degree of backward compatibility. If you want to use SysV style init scripts, nothing will stop you. The service(8) utility still works the way it always did on RHEL, as does /dev/initctl. And even if you use these legacy tools and interfaces, you still get new features such as service management with cgroups. If this isn't enough for the people you describe, then I indeed think that they should get another job. Preferably one where they get paid for pointless whining.
Myths not debunked but confirmed Posted Jan 28, 2013 19:51 UTC (Mon) by k8to (subscriber, #15413) [Link]
Prophecy of blaming the victim is fulfilled.
Myths not debunked but confirmed Posted Jan 28, 2013 20:34 UTC (Mon) by HelloWorld (guest, #56129) [Link]
Speaking of victims, have you stopped beating your wife yet?
Myths not debunked but confirmed Posted Jan 29, 2013 8:13 UTC (Tue) by k8to (subscriber, #15413) [Link]
Always raising the bar, aren't you.
Myths not debunked but confirmed Posted Jan 29, 2013 12:05 UTC (Tue) by HelloWorld (guest, #56129) [Link]
OK, since you obviously didn't get it: I don't actually think you're beating your wife. I was merely trying to point out that the kind of loaded language you use isn't helpful (specifically, the use of the word "victim" when there's nothing to be a victim of).
Myths not debunked but confirmed Posted Jan 29, 2013 20:37 UTC (Tue) by k8to (subscriber, #15413) [Link]
No, I got it. You were making a false accusation using rude language.
The victims here are sysadmins who have to deal with a variety of systems who a new thing dumped on them.
Pro: systemd might be better for the subset of systems that use it
Con: most systems don't use it
Sysadmins have many things to learn and accomplish and not welcoming this relatively useless (to them) change is not a sign of incompetence but rather sanity.
That doesn't mean that they should get to dictate how the systems are architected, but they are the ones who get dumped on by this particular set of changes.
So yes, you were blaming the victims. Don't do that.
Myths not debunked but confirmed Posted Jan 29, 2013 21:38 UTC (Tue) by ovitters (subscriber, #27950) [Link]
Why complain about wording and also say sysadmins are victims? I'm looking forward to RHEL7!
Myths not debunked but confirmed Posted Jan 29, 2013 22:12 UTC (Tue) by HelloWorld (guest, #56129) [Link]
As evidenced by many comments here and elsewhere, systemd is *not* a relatively useless change, most people welcome it because it's easier to configure, more reliable and more featureful than what came before it. So please stop spreading this kind of FUD. Systemd makes life easier for most people, not harder, which is why most significant distros adopted it by now.
And besides, most systems don't use SysVinit either, and even those who do often bear no resemblance to each other as pretty much everything is done by system-specific scripts. The introduction of systemd actually led to an *increase* in uniformity as distros share most of the configuration files.
Myths not debunked but confirmed Posted Jan 30, 2013 4:56 UTC (Wed) by k8to (subscriber, #15413) [Link]
So now you chop and change as well.
Every response has been an exercise in mischaracterization.
Myths not debunked but confirmed Posted Jan 29, 2013 22:15 UTC (Tue) by smurf (subscriber, #17840) [Link]
>> Sysadmins have many things to learn and accomplish and not welcoming
>> this relatively useless (to them) change is not a sign of >> incompetence but rather sanity.
If you truly think systemd is "relatively useless" for sysadmins, you should re-read this discussion.
Sysadmins need to be able to correctly and efficiently deal with failure situations. Once you use "systemctl status" and see instantly what the problem is, as opposed to grepping through heaps of ps and syslog output, you will not want to go back.
A more obscure, yet incredibly useful, feature of systemd is to start services in a consistent environment. No root login whose strange environment settings can contaminate the daemon and render its messages useless. No tty which can randomly block or vanish. No job control that can block your program or send it strange signals. And so on.
Myths not debunked but confirmed Posted Jan 30, 2013 4:57 UTC (Wed) by k8to (subscriber, #15413) [Link]
If you're a sysadmin of a monoculture, sure it will eventually be useful.
AFAICT, those people are now called "devops", and they may love it.
Myths not debunked but confirmed Posted Jan 30, 2013 7:19 UTC (Wed) by smurf (subscriber, #17840) [Link]
Translation: "Incremental progress is bad."
You seem not to notice that you contradict yourself.
Oh well.
Myths not debunked but confirmed Posted Jan 30, 2013 12:16 UTC (Wed) by mgb (guest, #3226) [Link] @smurf - The words which k8to wrote have no need of your "translation". Incremental progress is good. systemd is bad because its poor design and premature optimization create unnecessary coupling which inhibits incremental progress across a critical mass of system software. Nevertheless it appears that the systemd problem has been solved. Fedora and Redhat and some other distros have been borged but Debian and Ubuntu and many other distros have stood firm. FLOSS will simply evolve to leave the systemd-limited distros behind. Debian and Ubuntu and other distros will offer parallel boot options and cgroups options to their users without compromising FLOSS evolution.
Myths not debunked but confirmed Posted Jan 30, 2013 13:28 UTC (Wed) by anselm (subscriber, #2796) [Link] FLOSS will simply evolve to leave the systemd-limited distros behind. I think that, given time, the problem will take care of itself since nobody will be able to come up with anything that is both enough of a significant improvement on System V init to get System V init anywhere near what systemd does even today, compatible with tradition enough so the die-hard System V init fans won't complain, and gets traction in enough distributions so people will actually be interested. (The ones which have subscribed to systemd already aren't going back unless whatever the System V init camp has to propose is really a lot better than systemd, which would be quite surprising.) This is very unlikely to actually happen since historically the distributions didn't even seem to be able to agree on a standard for init scripts, let alone all of System V init or indeed an evolutionarily improved System V init. In the meantime, systemd will improve even further and, with the major Linux distributions behind it, will become even more compelling. In effect, System V init will leave systemd behind in exactly the way that CVS left Git behind. Feel free to prove me wrong.
Myths not debunked but confirmed Posted Jan 30, 2013 14:47 UTC (Wed) by mpr22 (subscriber, #60784) [Link] Somehow, "FLOSS will simply evolve to leave the systemd-limited distros behind." makes me think "What, like XFree86 evolved to leave the X.org-limited distros behind?"
Myths not debunked but confirmed Posted Jan 29, 2013 20:42 UTC (Tue) by k8to (subscriber, #15413) [Link]
Nevermind that the whole IDEA of loaded questions is that you ask a question and presuppose the framing is accurate in a weasely way. There was no *question* so the linguistic trick of a loaded question cannot even apply.
I made a statement which linguistically a clear thing which can be accepted or rejected by the reader. So your attempt to imply such underhanded tactics is itself underhanded. Which, if you didn't realize, is why you were being unreasonably rude.
Poettering: The Biggest Myths Posted Jan 27, 2013 16:20 UTC (Sun) by dskoll (subscriber, #1630) [Link] Have you actually tried to maintain a meaningful cross-distro init script? Why, yes. Yes, I have. Our (commercial) product runs on all flavors of Linux as well as any UNIX-like system (the BSDs, Solaris, etc.) I did the rather heretical thing of writing our init script in Perl. Our product requires Perl anyway, so we know that Perl is going to be available on the system. And it was quite easy. I'm not against systemd. I think it has some very nice features and probably is the way of the future; I just wanted to point out that writing portable init scripts is not that daunting.
Poettering: The Biggest Myths Posted Jan 27, 2013 20:59 UTC (Sun) by pizza (subscriber, #46) [Link]
>>Have you actually tried to maintain a meaningful cross-distro init script?
>Why, yes. Yes, I have. Our (commercial) product runs on all flavors of Linux as well as any UNIX-like system (the BSDs, Solaris, etc.)
Yay!
>I did the rather heretical thing of writing our init script in Perl. Our product requires Perl anyway, so we know that Perl is going to be available on the system. And it was quite easy.
Perl makes some things easier (if nothing else, it has real data structures!) but it doesn't simplify integrating into the rest of the system.
Indeed, I couldn't even rely on having *bash* because among the targets for aforementioned init scripts were embedded systems with 4MB flash -- certainly no room for perl either)
In my case I had to integrate into/with distro networking layers, which was about as insane as things could get.
Poettering: The Biggest Myths Posted Jan 27, 2013 17:37 UTC (Sun) by HelloWorld (guest, #56129) [Link]
> As many people have said before, it would be different if Red Hat (or Fedora) had adopted Upstart which was already available,
Fedora *did* adopt Upstart, and it sucked so hard and fundamentally that they decided to drop it at the first viable oppotunity.
Poettering: The Biggest Myths Posted Jan 27, 2013 23:49 UTC (Sun) by shmerl (guest, #65921) [Link]
I'm running systemd on my Debian testing.
systemd on debian Posted Jan 28, 2013 10:45 UTC (Mon) by smurf (subscriber, #17840) [Link]
So am I. The main problem is that it's an ancient version; re-packaging dbus is unlikely to happen before the Wheezy release.
Poettering: The Biggest Myths Posted Jan 27, 2013 21:16 UTC (Sun) by misc (subscriber, #73730) [Link]
timezone is the wrong example, because posix kinda mandate to have /etc/localtime to be the timezone information.
I do manage with puppet several server on various distributions and I do it like this.
Poettering: The Biggest Myths Posted Jan 27, 2013 23:03 UTC (Sun) by ovitters (subscriber, #27950) [Link]
That is what I initially did, change that file. But then some distributions reverted that change sometimes (IIRC). You had to change the config which they looked at, otherwise you'd start the server with one timezone. Then once puppet service did its thing, /etc/localtime would change. However, all started services are still running under the different timezone.
I gave this example due to experience I had. You expect at least this to be easy, in practice it was not.
Poettering: The Biggest Myths Posted Jan 27, 2013 13:04 UTC (Sun) by robert_s (subscriber, #42402) [Link]
> but I am also interested in cross OS support
Why?
Why should we all be stuck using a lowest common denominator feature set?
Poettering: The Biggest Myths Posted Jan 28, 2013 16:18 UTC (Mon) by misc (subscriber, #73730) [Link]
It is kinda important to have it running on windows, they have a rather huge market share. Unless when people say "cross os support", they mean "except windows" :)
Openrc a better init system? Posted Jan 28, 2013 10:51 UTC (Mon) by Wol (guest, #4433) [Link]
Well, I'm seriously considering converting my gentoo system from openrc to systemd. I'm just worried what I'm going to break.
On the other hand, however, what I would GAIN from converting to systemd is obvious - a proper, working, multihead system.
At the moment, my X server is configured to enable remote login, from my ancient 2nd PC and via Cygwin from the Win7 laptop. And using it is dire :-( I'd much rather just plug in my 2nd monitor and keyboard, and have a proper, working, multi-user system, just like Unix used to be :-)
Cheers,
|
|||||||||||||