[arch-general] When will Arch switch to Systemd

[Yaro Kasear]

On Friday, January 21, 2011 11:53:22 am C Anthony Risinger wrote:
> 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:
> 

Because it's completely unnecessary.

> 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.
> 

Some form of init is still needed even if the initscripts are glorified shell 
scripts. What do you think has to RUN those shell scripts for them to be of 
any use at all?

Hell, even without a single initscript, an init system STILL needs to be in 
place. That's just how UNIX works

SysV Init is simple, which is what Arch is all about.

> capisce?  good.  now we can move on and give up this pointless cling
> to something that provides us nothing WHATSOEVER.

It provides us with a solid reliable way to boot our system and manage what 
runs at boot time. Anything more than that is luxury and unnecessary.

> 
> systemd is superior in every single way imaginable.

This is a matter of opinion. Not fact.

> that is the pure
> and simple truth; it's not even an arguable point. 

I am arguing it, therefore it is arguable.

> 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.

I doubt that. Again, to use Pulse Audio as an exabmple, he's stated he wanted 
it to take ALSA's place many times. He may not have said it about systemd, but 
there's no reason, none, to believe he doesn't expect it to replace SysV init 
on most Linux distributions.

> systemd solves real
> user/business problems, and whether or not you/me/us make personal use
> of every single possible feature is irrelevant.

And those problems are...? So far even those further up in this thread haven't 
described any real problems aside from certain inconvient things about the 
Arch Initscripts, which are fixable without introduce a needlessly complex 
init replacement.

> 
> these sentiments are echoed throughout most of community.

Are they? Please back up this assertion with facts instead of unsubstantiated 
rants.

> 
> 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, ..., ... 

Those are core utilities, not the sysvinit suite. They're gonna be there 
whether or not we use SysV Init. And I bet even systemd would end up using 
them too in its units. 

> even if it mattered one tiny
> little bit, i'm pretty sure you'll exceed systemd's count in the first
> file or two.

Again, they're core utilities you'll find in ANY POSIX system. Just because 
SysV Init's scripts uses them is misleading and irrelevant and pointing this 
out is a blatant red herring.

> i've been thru the init scripts several times and ramfs
> init; i know.  just believe me.
> 

So am I. Your point has absolutely no value at all, as those utilities are not 
there for init's sake, but to make scripting at all useful. Switching to 
systemd wouldn't fix that one bit.

> why should init do "do almost nothing"??

Init decides what is run in what circumstances. That's ALL it needs to be. 
This is not a problem that needs to be fixed. Your argument is invalid.

> 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;

Yes it does. Almost every one of systemd's features are completely unneeded 
for a fully functional boot process. Nothing systemd offers isn't already done 
with SysV Init and simple bootscripts.

> it's
> job is to reliably start, stop, and babysit processes with the
> parameters, environment, and constraints WE DEFINE. 

SysV Init does that too. Or have you not noticed the existence of 
/etc/inittab, /etc/rc.conf, or /etc.rc.local. Those three files alone already 
grant a finer amount of control over how Arch's boot process than systemd 
does. Let's not even touch on the "magical" things you can do with mkinitcpio.

Your rant stinks of someone who doesn't understand the first thing of how the 
Arch boot process actually works.

> 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.

It's not KISS at all. It does things an init system plain doesn't need to.

> 
> 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?

That systed fixes no problems and it only looks like its being looked at for 
"newness" sake? That it introduces completely unneseccary complexity to the 
boot process? 

> 
> ... 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.
> 

Your entire argument here was riddled with fallacies of its own. Whereas 
arguing about a developer's track record is not a logical failing, but 
completely relevant to the issue at hand.

> 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.

Plenty of Arch users care. Otherwise this thread wouldn't be going the way it 
has. Systemd is pretty much against the Arch Way, and the KISS principles of 
UNIX. Trying to claim the average arch user doesn't care is incorrect.

> 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*

That's not even close to the argument I or others are arguing and you know it. 
Enough with the red herrings already.

> 
> CK/PK are (AFAIK) advancements that let various CLI/GUI/UI/automated
> tools perform dangerous tasks with high levels of control;  fine
> grained permissions.

Made possible in no small part through things like hal and udev, who by 
themselves can actually fulfill that role with CK or PK.

> 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.

Did anyone make that logical fallacy anywhere in this discussion? I looked 
into how systemd works, I also looked into who made it and his track record 
for making overtly complex software that solves problems that don't exist.

> 
> 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.

I could reiterate the problems with your argument. But I won't, I already 
covered it earlier

> 
> 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:

Beyond the boot I don't want the init system to be anything more than the root 
parent. That's what init is for: Bring the system up/down and parenting itself 
to other processes. Anything else is just gravy and NOT NECESSARY.

> 
> 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.

SysV doesn't need to. We have udev and hal to do those things, and they likely 
to it in a more clearcut and reliable way than systemd ever would.

> 
> holy frustration batman.
> 
> C Anthony