On 04/29/12 23:22, Tom Gundersen wrote: > On Sun, Apr 29, 2012 at 6:51 AM, Patrick Lauer <patrick@xxxxxxxxxx> wrote: >> The sysvinit code is so "boring" that there are still typos in the >> comments because not enough people even look at it to notice ... > The lack of maintenance of sysvinit is a bit worrying, isn't it? Au contraire ... it's so boring-stable that no one *needs* to even look at it. That's how I like my software best, so boring that most people don't even notice it exists :) > >>> i write a lot of shell code, and have literally read the bash man page >>> enough times to be able to jump to any point for reference ... shell >>> code is anything but secure and rather fragile. it's just not meant >>> to do as much as we make it. you are probably right about the >>> firewall case, maybe it wouldn't be needed. but my guess is that you >>> could actually make the firewall much more fault tolerant and >>> intelligent by using such a powerful supervisor as systemd. for the >>> most part though, most systems *do* require intricate and complex >>> relationships between services, and systemd fills that need >>> splendidly, *because* it does more that "fire and forget" [initialize] >>> processes. >> Worse than OpenRC, especially as it has insane nuggets like "WantedBy" >> (hello threaded Intercal!) > 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. And you should ask people that had to debug threaded INTERCAL why it's not as awesome as it sounds at first glance ... > >> In my opinion, if I have to start hacking random C to add or adapt >> features (which happens as soon as the builtins do the wrong things - >> that's about twice a year for me) it'll be a lot more crashy than a >> simple shell script where I add one line of code. > By "builtins" do you mean PID1? If so, this is not something an admin > should be hacking on (just like an admin would not hack on sysvinit's > /sbin/init). Have you actually looked at the code? Yes, I have read a good chunk of systemd (and upstart). My liver doesn't appreciate that much. And "should be hacking on" - yeah, that's the theory. But I usually hit that point once or twice a year where the given structure is either buggy or incomplete and I *need* to mangle such internals. "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?) > >> So the only weak argument in favour of systemd is dependency handling, >> which has been around for a decade. Oh, and if you have stateful init >> scripts (yeah, radical, I know) you can just check if all services you >> wanted to start are started and still alive. (running "rc-status" and >> "rc" with openrc does exactly that) > As has been mentioned by several people in this thread, and also on > the other lists where you sent your proposal: the main reason people > are interested in systemd is due to its event-driven design (similar > to upstart, but unlike sysvinit and, as far as I can tell, OpenRC). > 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? Would be useful to define it well enough so we can evaluate how OpenRC (or the current init) doesn't do what you want, and maybe fix it until next week. Have a nice day, Patrick
