| |||||||||||||
|
| |||||||||||||
The road forward for systemdThe road forward for systemdPosted Jun 1, 2010 16:18 UTC (Tue) by __alex (subscriber, #38036)In reply to: The road forward for systemd by SEMW Parent article: The road forward for systemd
I don't have a problem with it. It just seems that discussing it's technical merits is a bit philosophical when there's no published data on exactly the sort of thing people will be expecting it to improve.
(Log in to post comments)
The road forward for systemd Posted Jun 1, 2010 17:55 UTC (Tue) by anselm (subscriber, #2796) [Link] I don't worry about the boot times a great deal – even with the traditional init my machine boots a lot quicker these days than it used to. So never mind the benchmarks; if systemd merely does the other things it is said to do, at upstart's or even Sys-V init's speed, that will be just fine by me, and I'd be happy to just skip over upstart, thank you very much.
The road forward for systemd Posted Jun 3, 2010 21:37 UTC (Thu) by oak (guest, #2786) [Link]
I think the largest Upstart issue is that its dependencies don't solve the issue that just starting the service is not enough for the clients. The server's socket needs to be available too, otherwise the clients can abort.
With Upstart one needs to modify the servers and have some extra code to communicate with these mods from the Upstart or its scripts. Or to have some trivial utility waiting & polling the server's socket availability before Upstart can fire the "started" event. If you don't have these with Upstart, your bootup process is fragile to timings issues.
That's the problem that systemd seems to be nicely solving. Doing the dependencies _correctly_ (based on server's service, not execution) with minimal modifications & complications required.
|
|
||||||||||||