On Jun 13, 2015, at 17:51 03, David Klann <dxkl...@gmail.com> wrote: > But Fred, I take exception to your claim that the systemd "unit file" > is more complex than the old init.d scripts. Why do you say that? On > the laptop where I'm typing this the graphical display startup file > for systemd is much simpler: 25 non-comment lines of "code", the > equivalent script in the old init.d world is 193 non-comment lines of > code. What am I missing about the complexity of systemd unit files?
I should have been more precise. I agree that in terms of number of lines of code, the typical systemd script is significantly smaller that its corresponding init.d cousin. Where it becomes much more complex (at least in my experience) is in the development process needed to arrive at that script. There are no tools available to give a developer transparency into what the boot system is doing and (crucially) in what order. You have ‘events’, but no decent ontology of what events are emitted by what. And what if the particular service that you must have running before you can run your widget has no event that it emits? (All too common a situation in my experience). In short, systemd (and its cousin Upstart) lacks what Eric Raymond has called “discoverability”, the ability of a system not only to run well but to be *seen* to run well [http://www.catb.org/esr/writings/taoup/html/ch01s06.html#id2878054]. OTOH, every init script on a RHEL system is defined with a set of runlevels on which it will run, along with a specific ordinal number in the chkconfig header that determines the precise sequence it will be started in relation to all of the other boot services. It’s quite easy to see by looking at the first few lines of any init script precisely when it will be executed. It’s even possible to read the entire set of init scripts programmatically and generate a neat list of the precise sequence of the boot order. The individual scripts are larger, but the global transparency of the system is such that it becomes much easier to see how it works (and hence, how to extend it to do what you need it to do). That’s discoverability. Now it’s certainly possible that, in some contexts, the admittedly faster boot times achievable with one of these event-driven boot systems is worth the tradeoff in terms of developer time and frustration. My basic contention is that a Rivendell system is *not* one of those contexts; traditional init.d is a much better fit there. Cheers! |----------------------------------------------------------------------| | Frederick F. Gleason, Jr. | Chief Developer | | | Paravel Systems | |----------------------------------------------------------------------| | A room without books is like a body without a soul. | | -- Cicero | |----------------------------------------------------------------------| _______________________________________________ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
