Hi Patrick, On Mon, May 7, 2012 at 3:30 PM, Patrick Lauer <patrick@xxxxxxxxxx> wrote: > People have thrown "event based" and such words around, but no one has > dared to clarify or properly define what they mean by it. Thus I can't > understand if there's anything missing in OpenRC or people are just > throwing words around because it feels good. I assumed anyone working with init systems had a firm grasp of the main selling-points of the competition, but let me try to explain what I have in mind (by no means take this as authorative, there is plenty of writing on this both by the upstart guys and the systemd guys who know it better than me). I guess it is best explained in terms of an example, let's take storage: Traditionally we would wait for all the storage devices to be enumerated, then fsck all of them, then mount all of them, then start the daemons which might require something from say /var. This no longer works well with modern hardware and a modern kernel. The reason is that we don't know when the kernel has finished enumerating all the devices (sometimes we do, but not always, it depends on the device), and we certainly don't know in case the user has not yet plugged in all the devices at boot, or some of them are network devices that may or may not appear depending on what network we are currently connecting to. An event-driven init system would turn this on its head, and never wait for "all the things to be ready", rather start things on-demand and whenever their dependencies are satisfied. This leads to a much simpler system (from the admin/system daemon developers point of view), but it requires the init system to keep closer control over the state of the system, listen to events, etc. This means that there is no difference between "boot time" and any other time. If you plug in your network cable, or your external hard drive a week after switching on your computer they will be mounted (if that's what you configured in your /etc/fstab) in exactly the same way as if they were connected when you started your computer. >> On Thu, Apr 26, 2012 at 1:27 AM, Patrick Lauer <patrick@xxxxxxxxxx> wrote: >>> About modules and bloat - for systemd you're going from a few hundred >>> lines of shell to a few hundred thousand lines of mandatory >>> dependencies. >> I have no idea where you get these numbers from, or why they should matter. > These numbers come from comparing the code that is involved in system > startup. If you get really fancy you use something like "sloccount", or > if you're lazy like me you just use wc -l. I know how to measure the number of lines of code, and I do acknowledge that if you can do the same job with less code that's nice. My question was: what are you counting as "mandatory dependencies" for systemd. I know of libdbus (the daemon is not mandatory) and, contrary to what it says on the openrc website, glib2 is not a mandatory dependency. What do I do when things don't work? Use the awesome debugging tools that systemd provides. Makes my life a hell of a lot easier compared to when debugging initscripts. On Mon, May 7, 2012 at 3:54 PM, Patrick Lauer <patrick@xxxxxxxxxx> wrote: > Already udev lost features and got wrongly renamed, and we haven't even > had a proper release yet. Udev got slimmed down a bit, but this was the right thing to do even without systemd. One tool for one job, right? It no longer creates device nodes, instead it says that that is the job of the kernel (mostly) or (for the few exceptions the kernel can't deal with) some separate user-space tool that is called during boot. systemd ships one such tool, which you could easily copy, or you could make your own. It would be about three lines of bash ;-) >> What's wrong with WantedBy? You don't like the term, or do you have a >> technical problem with it? > It's very difficult to handle properly - you have to check all init > scripts / unit files / znargfruzzles every time to see if their > dependencies changes, and if they have any WantedBys. I'm struggling to follow your line of thought... "every time" what? WantedBy are simply used when you enable a service. Typically you'll either have WantedBy=multi-user.target or WantedBy=graphical.target, to tell systemd which "runlevel" the service should start in, I don't see why this, of all things, would cause such huge problems. > And you should ask > people that had to debug threaded INTERCAL why it's not as awesome as it > sounds at first glance ... I didn't know what INTERCAL was: "INTERCAL is an esoteric programming language that was created as a parody by [...] two Princeton University students, in 1972. It satirizes aspects of the various programming languages at the time, as well as the proliferation of proposed language constructs and notations in the 1960s." Doesn't seem very relevant to the current discussion... > "Not possible" is not a valid response to my problem-removal-needs. > SystemD is too big and too undocumented for me to trust my skills, I > wouldn't want to have to rely on a system that I mutilated like that > just to fix a rare corner case that "shouldn't be there" (yeah, great, > thanks, it *is* there. Do you want to make it go away?) I think some of the point of systemd is that once you find a weird corner-case that does not work you can bring it to the attention of the dozens of talented hackers from all distros/formfactor/architectures/... and someone will be able to fix it (hopefully without any unwanted side-effects). > You have no idea how much it bothers me to have to repeat myself, again, > for the last time I hope ... but ... > What do people actually *mean* by event driven? If you had given people a chance to reply to your first email, you would not have needed to ask twice ;-) On Mon, May 7, 2012 at 4:25 PM, Patrick Lauer <patrick@xxxxxxxxxx> wrote (in reply to Nicolas Sebrecht): > So all in all you just managed to upset some greybeards and turned a > technical discussion into random ad hominems. Nice :) No he didn't. He was quite right in pointing out that distribution maintainers are not necessarily great developers, which probably has lead to lots of bad shell scripts over the years spread around in different distributions. You are the only one attacking people (in particular one of the systemd maintainers, who is not even involved in this discussion). It is really making the OpenRC community look bad. On a somewhat related note, I was reminded to check your website again to see if you corrected your table of features. I thought I might let you know of the errors I found (making these kind of blunders makes it look like you don't really know the competition): * systemd is portable to non-x86 (as far as I know, it is tested on a wide range of architectures and aims to work on anything that works with the Linux kernel) * systemd definitely separates code and config, as far as the admin/user is concerned s/he only has to deal with /etc/systemd/ which contain declarative .desktop-style configuration files. No code. * systemd is very extensible, you can easily add in your own .service files to do whatever you want (I imagine you could even use systemd as your init and only run openrc as your only service file and it should just work). * friendly upstream: no comment. * complex init scripts: don't know what you mean, but you can use whatever initsrcipts you want in systemd * i'd be interested in reading more about how you automatically calculate dependencies to a greater extent than systemd. do you have a link, or could you elaborate? * systemd integrates into virtualization (more so in the next release) * the architecture is definitely modular, just look at the sourctree, most of those subfolders correspond to separate tools that can be disabled or exchanged for something else. * lots and lots and lots of verbose debugging available if you chose to enable it. Both from systemd itself and from whatever your daemons spits out to stderr. Cheers, Tom
