Colin Watson wrote: > (Now, I've been working with Upstart's model for years, and it's now a > pretty fundamental way of how I think of system operation; so if people > who are new to *both* models rather than partisans of one side or the > other consistently tell me that the systemd model is easier to grasp, > then I'll listen.)
I'd like to respond to this point, since I have a clear memory of dealing with both upstart's model and systemd's model for the first time. I also work professionally with a system (ChromeOS) that uses upstart, and I've dealt with systemd quite a bit as well. For the sake of full disclosure, my position is that I'd prefer systemd over upstart; I'd be OK with upstart if and only if systemd remained a viable alternative (in other words, packages maintaining both upstart jobs and systemd units but not necessarily maintaining init scripts seems pretty reasonable). So, at this point I'm squarely in the systemd camp, but not for any particular reasons of partisanship; I simply find the technology and model better. I started out dealing with the sysvinit model, pre-startpar; I dealt quite frequently with the magic ordering numbers (S20, K80, etc). My first exposure to dependencies was through startpar and LSB, and they made sense, though I was never a fan of the magic 'S' runlevel. I fairly quickly saw that mapping those dependencies to script ordering numbers was a hack, albeit a nicely done hack for compatibility; using the dependencies natively made a lot more sense, though. I read about upstart when it was first announced, and I dove into the event model quite extensively, thinking that it might help improve things. I never found it particularly intuitive, and in particular the whole "start on starting", "start on stopping" etc model never really made much sense to me; it didn't seem like a natural mapping of how the system worked. I also, from the beginning, disliked the model of starting everything that was possible to start, though I did not at the time see what the alternative would be; it simply never really seemed like the right model for booting quickly. (This was reinforced when I started paying attention to boot time, inspired by the original "boot in 5 seconds" presentation; upstart's model seemed entirely unsuited for that exercise.) I also found the requirement to know how many times your daemon forked quite obnoxious (even more so the failure mode if you get it wrong on even one daemon). These days, dealing with upstart professionally, it still seems entirely too easy to get upstart confused and in a difficult to recover state via a single incorrect upstart job, and I find it one of the most annoying subsystems to deal with; there's a general feeling of "oh, joy, that's probably an upstart issue" every time any issue relating to booting comes up. By contrast, my initial exposure to systemd (via the "systemd for system administrators" blog series and the systemd documentation) was actually via socket activation, with the dependency mechanism coming later. The socket activation model, as a replacement for dependencies, was one of those rare ideas that seemed immediately obvious in hindsight. My introduction to systemd's dependencies was more along the lines of "and explicit dependencies exist for when you can't fix your daemon and unit file to do things the *right* way". Similarly, the use of autofs and other techniques to allow starting things in parallel even when dependencies exist made immediate sense. And the entire model, including its handling of asynchronous events (notably the integration with udev), simply felt like a closer fit to how the kernel works and how reality works. Finally, the concept of factoring out common elements from daemons seemed quite nice, having dealt with quite a bit of ugly boilerplate code. In both cases, I had no particular reason to like or dislike either model; in each case I very much *wanted* them to work out, since my exposure to sysvinit versus startpar gave me a very early reason to want something better than sysvinit. I had no other reason to prefer one model over the other. I'm not attached to either init system, nor do I have any particular bias or reason to favor one over the other for any reason other than superior technology or a model I find clearer and more natural. So, in summary, upon initial introduction, I found systemd's model far more intuitive, both innately (in its use of socket activation and similar mechanisms to *avoid* dependencies) and as a more natural mapping to how the system, kernel, and hardware work. I hope this writeup of my first impressions of both systems proves useful in some way. - Josh Triplett -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
