Thanks [LWN.net]

Thanks

Posted Nov 19, 2014 16:33 UTC (Wed) by seyman (subscriber, #1172)
In reply to: Thanks by tjc
Parent article: Today's Debian technical committee resignation: Ian Jackson

> there are still alternatives for those who don't care for systemd

There's also the possibility of forking an existing init system (or creating one from scratch) and making it better than systemd. It's a lot of work but it can be done.

to post comments

Thanks

Posted Nov 21, 2014 15:29 UTC (Fri) by tjc (guest, #137) [Link] (13 responses)

I guess if it comes to a fork, Upstart would be the most viable candidate. Canonical has a copyright on the name, so that would have to be changed, but the code is under the GPLv2. That might be better than starting over yet again, unless, of course, someone is just itching to write an init system. I'm all in favor of writing code for the sake of writing code; I have no delusions of world dominion. :)

Thanks

Posted Nov 21, 2014 15:59 UTC (Fri) by anselm (subscriber, #2796) [Link] (12 responses)

That might be better than starting over yet again, unless, of course, someone is just itching to write an init system.

The problem with Upstart is that it has severe shortcomings that – at least according to its original lead developer – would require a major redesign to overcome. So it seems that you would in effect have to be “itching to write an init system” in order to make Upstart a viable long-term proposition.

This would be especially ludicrous given that systemd is basically such a redesign already, and has both a fairly vibrant developer community and widespread buy-in from mainstream distributions, so is likely to stick around unless something radically better comes along, which at this point is unlikely. Given this, it would probably make much more sense to fork systemd rather than Upstart.

Thanks

Posted Nov 21, 2014 18:48 UTC (Fri) by tjc (guest, #137) [Link] (10 responses)

> The problem with Upstart is that it has severe shortcomings that – at least according to its original lead developer – would require a major redesign to overcome.

What are the shortcomings? I've been using Upstart for several years without incident, but I don't require much of an init system (other than to "init").

Thanks

Posted Nov 21, 2014 19:31 UTC (Fri) by mjg59 (subscriber, #23239) [Link] (6 responses)

https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/4... is an example.

Thanks

Posted Nov 22, 2014 16:10 UTC (Sat) by smurf (subscriber, #17840) [Link] (5 responses)

To summarize: While an event-based init system seemed like a good idea at the time, upstart quickly ran into a whole lot of corner cases which are basically unsolvable without adding job state as separate concepts. Upstart has tried working around this by adding even more events (like "starting to start" and "finished starting") but they don't help in general.

Given this fact, a dependency-based system which uses events just to change the units' state simplifies the whole system and affords easier debugging, as it's statically introspectable – meaning you don't need an event history to figure out what's wrong, just the current job states and the dependency graph.

Thanks

Posted Nov 22, 2014 21:14 UTC (Sat) by mgb (guest, #3226) [Link] (4 responses)

Forgy invented http://en.wikipedia.org/wiki/Rete_algorithm in the 70's and it was widely adopted in the early 80's.

Sad to see the wheel painfully being reinvented again.

Thanks

Posted Nov 22, 2014 21:46 UTC (Sat) by smurf (subscriber, #17840) [Link] (1 responses)

Dependency resolution in an init system doesn't need anything remotely this elaborate. We don't even need alternates (what for?).

Thanks

Posted Nov 22, 2014 22:08 UTC (Sat) by mgb (guest, #3226) [Link]

> Dependency resolution in an init system doesn't need anything remotely this elaborate.

Rete is not elaborate. It is a clean elegant modular algorithm.

> We don't even need alternates (what for?).

Alternate networks. Sometimes alternate data stores. Alternate entropy sources - you want sshd ASAP but maybe not until you have some entropy. "If I can't get any entropy bring up sshd only on the private LAN and if that doesn't work fall back to telnetd on the private LAN."

As the "new" init systems try to invade serious servers they will keep on running into problems and adding more keywords and reliving the 70's until they eventually relearn the lessons of the early 80's.

Thanks

Posted Nov 22, 2014 23:33 UTC (Sat) by mjg59 (subscriber, #23239) [Link] (1 responses)

How would you apply this to an event-based init system?

Thanks

Posted Nov 23, 2014 0:15 UTC (Sun) by mgb (guest, #3226) [Link]

> How would you apply this to an event-based init system?

Your own http://lwn.net/Articles/622742/ answers that.

If you want functionality beyond inittab, an event-based init system is even worse than an ad-hoc dependency-based init system that has to keep adding keywords like RequiresMountsFor.

Thanks

Posted Nov 21, 2014 20:14 UTC (Fri) by Felix (subscriber, #36445) [Link] (2 responses)

jspaleta also compiled an impressive list https://lwn.net/Articles/582585/

Thanks

Posted Nov 21, 2014 21:02 UTC (Fri) by jspaleta (subscriber, #50639) [Link] (1 responses)

One request...

If someone does fork upstart and fix all the deep deep design problems. Please rename it as a new project. What you end up building will be a very different animal.

I have a couple of humble name suggestions:
upyours, upset, upchuck

-jef

Thanks

Posted Nov 22, 2014 15:23 UTC (Sat) by zuki (subscriber, #41808) [Link]

Funny... but not quite funny enough. Please give it a rest.

Thanks

Posted Nov 21, 2014 22:31 UTC (Fri) by seyman (subscriber, #1172) [Link]

> Given this, it would probably make much more sense to fork systemd rather than Upstart.

I don't see how this will win over the people who are complaining (assuming anything can, at this point). OpenRC always seemed the better choice, imho.