Systemd vs. Docker

Posted Mar 6, 2016 0:30 UTC (Sun) by anselm (subscriber, #2796)
In reply to: Systemd vs. Docker by raven667
Parent article: Systemd vs. Docker

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.)

Systemd vs. Docker

Posted Mar 6, 2016 3:43 UTC (Sun) by raven667 (subscriber, #5198) [Link] (9 responses)

>Upstart was basically dead in the water since nobody seemed eager to take on the work

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.

Systemd vs. Docker

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.

Systemd vs. Docker

Posted Mar 6, 2016 7:04 UTC (Sun) by smurf (subscriber, #17840) [Link] (7 responses)

That re-architecture could have been done somewhat-incrementally, and IIRC Lennart & Co. even looked into that, but with the copyright assignment requirement this wouldn't have worked. Too many people refuse to sign the stuff.

Systemd vs. Docker

Posted Mar 6, 2016 15:17 UTC (Sun) by vonbrand (subscriber, #4458) [Link] (4 responses)

Reachitecture and incrementally. The mind boggles.

Systemd vs. Docker

Posted Mar 6, 2016 15:34 UTC (Sun) by reedstrm (guest, #8467) [Link] (1 responses)

Yes, it usually is very mind boggling, and requires thinking about upgrade paths while doing the actual development. It's not something you can bolt on after, and is the source of the classic tension between developers and admins.

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.

Systemd vs. Docker

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.

Systemd vs. Docker

Posted Mar 6, 2016 22:50 UTC (Sun) by smurf (subscriber, #17840) [Link] (1 responses)

Sure, if you have a reasonably complete set of test cases refactoring is easy. ;-)

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.

Systemd vs. Docker

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.

Systemd vs. Docker

Posted Mar 8, 2016 5:58 UTC (Tue) by dberkholz (guest, #23346) [Link] (1 responses)

This isn't a real restriction, if you fork prior to rearchitecture.

Systemd vs. Docker

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.