[arch-general] When will Arch switch to Systemd

[C Anthony Risinger]

bravo, sir.  i'll throw you one last bone, because your track record
in this conversation is one of severe inability to comprehend any
information presented.

On Fri, Jan 21, 2011 at 12:15 PM, Yaro Kasear <yaro at marupa.net> wrote:
> 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.

of course; i don't know why anyone would want the only process capable
of babysitting to actually babysit. hmmmmm......

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

ehm... you can just point `init=/some/shell/script` and have that
shell script source the normal rc.* files; make it `trap` the INT and
PWR signals and.... ZOMFG!!!! you have a complete "sysvinit" in bash
in about 15 lines.

take a look at how the ramfs boot works, because it does exactly this.

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

the kernel just needs something to run.  and it actually pretty much
always runs /init... the initramfs later on passes the `init`
parameter within /proc/cmdline to switch_root for exec'ing.

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

i'm sorry but your incredibly wrong.  again, for the 700th time,
sysvinit does nothing.  all functionality is in shell scripts.  please
stop chanting this because i'm about 95% sure that the kinds of people
who are capable of actually writing these scripts would agree, if this
thread is any indication of that.

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

there is nothing solid or incredibly reliable about bash; read a
comprehensive doc detailing all the things that affect it's execution.
 and... uhm.... manage??  at what point does init do this again?
ooooh, you mean rc.d scripts?  did i just say scripts?  yes, scripts.

so, not init.  bash.  custom.  share-nothing.

>> systemd is superior in every single way imaginable.
>
> This is a matter of opinion. Not fact.

right, if your braindead.  like sysvinit :-)

>> that is the pure
>> and simple truth; it's not even an arguable point.
>
> I am arguing it, therefore it is arguable.

well that's circular reasoning if i dun ever saw'ed it.  nice.

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

as it should.  sysvinit is next to worthless.  recognize this.
computers should do more for us as time goes on; it's not exactly a
novel idea.

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

@#$@#$!!!!.... please see the numerous links in the first post that
you most certainly have not visited.

>> these sentiments are echoed throughout most of community.
>
> Are they? Please back up this assertion with facts instead of unsubstantiated
> rants.

read: consistency/reliability/transparency/control

this is what the community wants.  sysvinit does not provide.  see the
many good posts by Tom.

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

ya, so what?  does that mean a good process manager should be parsing
unpredictable text and making decisions on that? let me think about
that, no.

i apologize, but have you ever wrote a real application?

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

whether these "core" apps already exist is what's irrelevant.  i am
referring to the need to use umpteen external; processes just to do
trivial things like string manipulation.  if you really think making
1700 calls to external processes adds stability then your really ...
... :-)

read the links; you will learn several good things, i promise!

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

you are missing the point by ~100 lightyears.

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

no, it doesn't.  it does ONE thing, ONE time.  it can respond to
SIGINT and SIGPWR, that's all.  soooo.... try again next time.

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

sure, if you don't actually care about your system after boot, or
enjoy wasting time setting up the same "features" in more fragile
ways.  i, for one, have better things to do, and systemd is on a great
path to helping me manage all the servers in my data centers.

init has SUPERVISORY POWERS GRANTED BY THE KERNEL.  use it.

> Nothing systemd offers isn't already done
> with SysV Init and simple bootscripts.

ah hahahahahahaha.  ah man that's rich.  thanks for that.

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

same.  nice try though.

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

kk :-)

'cept i've read it line by line several times and have implemented
multiple mkinitcpio hooks.  do you have anything of value to add yet?
because you've submitted 10+ msgs now and i cant find anything of
worth.

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

please see the first post.

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

you just don't get it chief.  READ.  THE.  LINKS.

:-)

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

except for the fact that code speaks for itself, and it's very much a
collaborative effort at this point.

what do you do for a living that endows you with such valuable
insights as to the competence of others?

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

im sorry, but im not sure the average arch user matters.  if you look
at the thread closely, you will see that the more prominent members of
the community are usually in agreeance with what Tom, myself, and
others who don't mind learning something new, have outlined and
suggested.  why you ask?  because it's less work for those doing the
work.

"Simplicity of implementation, code-elegance, and minimalism shall
always remain the reigning priorities of Arch development."

hmmm, where does systemd NOT fit into that, and oodles of bash scripts
fit better?

"Complexity without complication."

and how are adhoc rc.d scripts simpler than clearly defined
unit/service/socket/target files?

"Code-correctness over convenience."

bash is one giant convenience.  and dont forget this:

" 'Simple' is defined from a technical standpoint, not a usability
standpoint. It is better to be technically elegant with a higher
learning curve, than to be easy to use and technically [inferior]."

need i say more?  because in this context, sysvinit is the pinnacle of inferior.

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

ok... peeeerhaps; but don't pretend to evaluate systemd, then proceed
to make wild assumptions, when you clearly have no real understanding
of it at any level whatsoever.  it doesn't help those who are truly
interested.

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

i'm starting to think you don't know how udev works or what it is.

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

try again... this time look "closely-er" :-)

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

haha what, no sense of humor either?  man, tough crowd tonight.

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

hmm, let it be the root supervisory parent, but do't let it do
anything.  why didn't we think of that before?  it's genius!  oh
wait...

yet. again.  sysvinit. doesnt. do. anything. at. all. for. you.  bash.
scripts. handle. everything.

get it right.

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

now i know you don't understand udev.

goto: line 'ahaha...'

im sorry man, very rarely am i this abrasive, but you are hopelessly
misinformed.  please try some of the links provided; Lennart actually
does a very good job of laying it out.

and to Tom and others who have put in the work, thanks.  default or
not, it will be a great improvement to Arch.

C Anthony