oh... my. there is too much <expletive deleted> to respond properly so i'll try touch a couple [several] things ... ... why the resistance at all? let me reiterate this niiiice and slow: SYSVINIT HAS NO POWER, NO FUNCTIONALITY, AND ABSOLUTELY ZERO USEFULNESS ON IT'S OWN. the "unix philosophy" (debatable in itself...) of doing one thing doesn't usually translate to LITERALLY DOING ONE THING. please please please, please, read that several times until it sinks in nice and deep; every single argument about sysvinit's "simplicity", "maturity", blah blah, woka woka, etc etc, and anything else related to it's stability is complete nonsense because ... YOUR BOOT PROCESS IS A MEGAMATRON SHELL SCRIPT, AND HAS PEANUTS TO DO WITH INIT; IN FACT, INIT IS NOT EVEN NEEDED. capisce? good. now we can move on and give up this pointless cling to something that provides us nothing WHATSOEVER. systemd is superior in every single way imaginable. that is the pure and simple truth; it's not even an arguable point. many of the "concerns" here are already answered/clarified higher up in the thread, or are nothing more than FUD and personal grudges against a guy who seems to SIMPLY WANTS TO IMPROVE THINGS AND DOESN'T CARE IF YOU WANT TO USE SYSVINIT FOR 60 MORE YEARS. systemd solves real user/business problems, and whether or not you/me/us make personal use of every single possible feature is irrelevant. these sentiments are echoed throughout most of community. systemd has <whatever number> binaries?? yeah, and? so what? take a hard look at the precious sysvinit "suite"; you'll find 1700 external calls to grep, sed, awk, cut, ..., ... even if it mattered one tiny little bit, i'm pretty sure you'll exceed systemd's count in the first file or two. i've been thru the init scripts several times and ramfs init; i know. just believe me. why should init do "do almost nothing"?? how many other applications do we slick developers write where the goal is to do a whole 'lotta nothing? come on. systemd doesn't step out of scope one bit; it's job is to reliably start, stop, and babysit processes with the parameters, environment, and constraints WE DEFINE. that's it; feels pretty dang simple/kiss to me. actually take a look at your boot process someday... then come back and drone on about how slick systemd is. so what if systemd requires the latest <insert here>? that's what we run around here. nobody cares about a server running <insert deity> knows whatever version; just use sysvinit like usual... wait, what's the argument again? ... really, drop everything about pulseaudio. there are many many people involved with both projects. this has to be the single dumbest argument imaginable. i'd link to a list of fallacies again but it's already been; do a search, then come back with real concerns. nobody cares about how complex systemd might look to a user who has neither read/understood the code nor even looked at the VERY COMPLETE man pages. this quite possibly rings in as the second dumbest argument. take a look at your kernel, what are we at, like 12 million SLOC? look at any decent software your using RIGHT NOW... what do you find? yup, code. *gasp* CK/PK are (AFAIK) advancements that let various CLI/GUI/UI/automated tools perform dangerous tasks with high levels of control; fine grained permissions. very few business problems are solved by coarse unix permissions on the FS. btw, introducing arguments with "i don't know what X is, understand why it exists, nor have i even attempted to realize why it might be useful, but it's total garbage because ... " effectively destroys yourself before you've started. developers write software to solve problems, not chase pixies. well it's time for a recess. i'm am at a serious loss of words for most of this; i fail to understand how one can competently arrive to the conclusion that sysvinit is even close to the same skillset as systemd... sysvinit is a fckn bench-warming waterboy whose only on the team because he never graduated and his dad invented the sport 40 years ago. so, look beyond the "boot", and read about systemd and the incredible flexibility it provides before looking for the nearest rock to throw. i suggest here again: http://0pointer.de/public/systemd-man/systemd.exec.html http://0pointer.de/public/systemd-man/systemd.unit.html http://0pointer.de/public/systemd-man/systemd.service.html http://0pointer.de/public/systemd-man/systemd.socket.html http://0pointer.de/public/systemd-man/systemd.mount.html now, tell me how sysvinit provides even 5% of that functionality? some of that i don't even know how to accomplish MANUALLY, and others i don't even know WTF they do. holy frustration batman. C Anthony
