Systemd vs. Docker
Systemd vs. Docker
Posted Mar 3, 2016 20:14 UTC (Thu) by davidstrauss (guest, #85867)In reply to: Systemd vs. Docker by jcc1
Parent article: Systemd vs. Docker
This view seems made up to me, and I can speak to why personally. My company runs runs hundreds of servers on Fedora, and I am a systemd committer. Both have been true since about Fedora 18. I have also worked with the primary systemd developers on key issues affecting server infrastructure, including being invited to present on remaining issues at systemd's latest conference [1]. And, in case you're wondering, those remaining issues relate to optimizations at scale, not fundamental design issues with what systemd does.
Moreover, there has been substantial use on the server side by plenty of other people. Some early adopters were shoehorning it into CentOS 6 to use systemd's tools for their own services; one of those companies posted publicly to the Debian mailing list during the init discussions to publicly support moving to systemd. I've also been asked to speak at Facebook on best practices for running services within systemd, which I'm doing later this month [2].
> In short, there was a mass exodus around that time, caused not only by systemd, but also other needlessly disruptive dumb ideas, like mandated TmpfsOnTmp, and the UsrMove.
Mostly false, at least for the cause/effect you're suggesting. Fedora lost substantial users over the F15-F20 period, but it has more than recovered them since (F21 and F22) [3] without reversing those decisions. If those were the decisions rationally driving users away, they would have stayed away. Also, other distributions adopting systemd have not seen any "mass exodus" at the point of their decision, either. So, your claim fails doubly: (1) reversal of effect without alteration of the supposed cause and (2) lack of effect when applying the supposed cause elsewhere.
> Instead, the Freedesktop.org crowd (i.e., the "systemd cabal") prioritized features they wanted on their laptop over any problems for server users.
I'm not even sure how to disprove that systemd developers are in some kind of FreeDesktop.org crowd/cabal.
> Many thought systemd would be similarly handled -- present if you wanted to use the new hotness as a service manager, but otherwise operationally invisible.
Likewise here. You're not providing testable criteria, just other statements that are "not even wrong." [4] How could I falsify your view here? What tests could show that systemd is "operationally invisible" to most users running distributions with it?
[1] https://systemd.events/systemdconf-2015/sessions/challeng...
[2] http://www.meetup.com/South-Bay-Site-Reliability-Engineer...
[3] https://youtu.be/qJ3CozFrEvg?t=29m9s
[4] https://en.wikipedia.org/wiki/Not_even_wrong
Posted Mar 3, 2016 23:04 UTC (Thu)
by jcc1 (guest, #107291)
[Link] (16 responses)
Posted Mar 4, 2016 21:17 UTC (Fri)
by mathstuf (subscriber, #69389)
[Link] (2 responses)
Not sure this is a fair comparison. The switch to upstart didn't make anything worse, but I also never noticed anything getting better with it either. With systemd, on the other hand, I've seen bugs, but also *vast* improvements in various places, across the board. Certainly, for me, worth the issues I've hit.
Posted Mar 4, 2016 22:30 UTC (Fri)
by johannbg (guest, #65743)
[Link] (1 responses)
If they would have, it most certainly would never have been ""operationally invisible".
Posted Mar 10, 2016 2:17 UTC (Thu)
by mathstuf (subscriber, #69389)
[Link]
Posted Mar 5, 2016 6:48 UTC (Sat)
by seyman (subscriber, #1172)
[Link] (12 responses)
Did anyone actually move to upstart? Even Ubuntu never used native upstart job files for the vast majority of their services in their distribution, preferring to run them using upstart's compatibility mode.
Posted Mar 5, 2016 20:47 UTC (Sat)
by raven667 (subscriber, #5198)
[Link] (11 responses)
I don't think so, there were some high hopes that upstart would be the next gen init system but clearly the native job files arent sufficient in practice and fixing the deficiencies was not possible without Canonical dropping the copyright assignment requirement, for-profit companies often don't like doing free consulting work for other for-profit companies, not even the original author was allowed to submit patches after taking a job working on ChromeOS.
Posted Mar 6, 2016 0:30 UTC (Sun)
by anselm (subscriber, #2796)
[Link] (10 responses)
The original author of Upstart (who is now working on different projects at Google) is on record as saying that it needed a massive redesign in order to cope with some nasty architectural deficiencies that were discovered in practice. At that point Upstart was basically dead in the water since nobody seemed eager to take on the work, and the Ubuntu people sensibly decided to go along with most other Linux distributions and adopt systemd.
(The fact that the Debian project had just decided to opt for systemd as the default init system on Linux also contributed to this, since if Debian had gone with Upstart then the Ubuntu people would have been able to rely on Debian developers doing much of the work adapting existing packages to native Upstart, instead of having to do all of the work by themselves.)
Posted Mar 6, 2016 3:43 UTC (Sun)
by raven667 (subscriber, #5198)
[Link] (9 responses)
Right, I was just pointing out my opinion on what the largest factor which made it difficult to pick up the maintainership of Upstart was Canonical's insistence on copyright ownership. Many strong developers (or their employers) insist on owning their own copyrights, with few exceptions like for the FSF. If a strong maintainer had stepped forward and had been effective in getting the restructuring done there never would be a systemd. Even if systemd were written in a world with a non-broken Upstart, it wouldn't gain any traction because it wouldn't be enough better to justify the cost of transition.
Posted Mar 6, 2016 3:51 UTC (Sun)
by vonbrand (subscriber, #4458)
[Link] (8 responses)
Check out the systemd documents on why it's development started. You'll see that the upstart problems were severe enough to require a complete rearchitecture, not just some bug fixes. The whole basic model (define some "events", and trigger them) is fundamentally impossible to scale, you can't decouple things enough. That is a good part of the reason why no native upstart configurations ever materialized. The "refurbished upstart" might just look an awfully lot like systemd. In a sense, systemd is upstart's better replacement.
Posted Mar 6, 2016 7:04 UTC (Sun)
by smurf (subscriber, #17840)
[Link] (7 responses)
Posted Mar 6, 2016 15:17 UTC (Sun)
by vonbrand (subscriber, #4458)
[Link] (4 responses)
Reachitecture and incrementally. The mind boggles.
Posted Mar 6, 2016 15:34 UTC (Sun)
by reedstrm (guest, #8467)
[Link] (1 responses)
There almost always is a way to do it, if you're willing to spend the resources (time as much as money). Unfortunately, actual rearchitecting (as opposed to new feature development) requires someone with a deep understanding of both the old and new systems, to develop the path forward. And patience to complete, as well as put up with any less than perfect intermediate states along the way. Usually a hard sell in today's go go go faster faster world.
Posted Mar 6, 2016 17:13 UTC (Sun)
by vonbrand (subscriber, #4458)
[Link]
In this case, the path forward was from SysVinit to something new. Upstart never got any significant hold except as a SysVinit lookalike. And systemd also offers SysVinit compatibility, but the switchover to native systemd was surprisingly fast and smooth, something I believe shows they got it right. Many distribution's users fought it nail and tooth in the ubiquitous flamefests, while their developers just moved over silently.
Posted Mar 6, 2016 22:50 UTC (Sun)
by smurf (subscriber, #17840)
[Link] (1 responses)
In this case, about half of Upstart's events translate reasonably cleanly to dependencies (i.e. instead of job B's start being triggered by "A has started", let B simply depend on A). Deprecate the other events aggressively. Now you can hook dependent jobs to states instead of state transitions without changing anything. Next step, add stuff you couldn't even think about in Upstart ("let D run as soon as both B and C are up", B and C being independent of each other). At last you're in a position to add targets. QED.
That being said, I'd guesstimate that doing this requires at least three times the amount of work on the core system, compared to starting from scratch, and a work-in-progress that's definitely worse than Upstart. Thus, one might reasonably conclude that Upstart's copyright assignment policy was a Good Thing in this case because it prevented the systemd people from getting mired in a prolonged Upstart refactoring that may or may not have succeeded.
Posted Mar 7, 2016 2:22 UTC (Mon)
by vonbrand (subscriber, #4458)
[Link]
Upstart style events need to be quite a bit more abstract than "A started" to be useful in case the functionality offered by A can be obtained in different ways... and there it breaks down.
Posted Mar 8, 2016 5:58 UTC (Tue)
by dberkholz (guest, #23346)
[Link] (1 responses)
Posted Mar 8, 2016 10:23 UTC (Tue)
by vonbrand (subscriber, #4458)
[Link]
Fork and scrap was the way forward here, why fork? Besides, upstart in practice was only used as a SysVinit drop-in replacement.
Systemd vs. Docker
This view seems made up to me, and I can speak to why personally.
It's quite possible that we run in different circles, but the view is definitely not "made up". Every EL shop I know of is being more cautious with EL7 than with previous transitions.
Mostly false, at least for the cause/effect you're suggesting. Fedora lost substantial users over the F15-F20 period, but it has more than recovered them since (F21 and F22) [3] without reversing those decisions. If those were the decisions rationally driving users away, they would have stayed away.
Although numbers have recovered, that doesn't really speak to whether the then-users stayed away or not. As focus changes, so does audience. I'd suggest that Fedora users who didn't agree with direction things were going went with EL, or perhaps Debian. e.g., from this wonderful thread: https://lists.fedoraproject.org/pipermail/devel/2011-June/152636.html
What tests could show that systemd is "operationally invisible" to most users running distributions with it?
Well, perhaps we're equivocating on "user" here, a not-uncommon issue. For some distributions, "users" are people relying on the distribution to control apps. For others, "users" are the system administrators who are deeply involved in reliability engineering and may or may not have specific ways of setting up systems for their company's needs.
I'd submit that neither the systemd-as-init nor the systemd-as-collection-of-tools aspects have been anywhere near as "operationally invisible" to sysadmins as the move to upstart was. Depending on the needs of non-sysadmin users who don't know what the /etc/fstab file is, it may have been more "operationally invisible", except for the opportunity cost of all the other people having to deal with systemd bugs over the years.
Systemd vs. Docker
Systemd vs. Docker
Systemd vs. Docker
Systemd vs. Docker
Systemd vs. Docker
Systemd vs. Docker
Systemd vs. Docker
Systemd vs. Docker
Systemd vs. Docker
Systemd vs. Docker
Systemd vs. Docker
Systemd vs. Docker
Systemd vs. Docker
Systemd vs. Docker
Systemd vs. Docker
Systemd vs. Docker