[gentoo-amd64] Re: Systemd migration: opinion and questions

[Duncan <1i5t5.duncan@cox.net>]

Rich Freeman posted on Wed, 20 May 2015 07:22:39 -0400 as excerpted:

> I don't think systemd has any kind of stable release strategy, and I
> think that is going to become a problem.  There are a lot of cases where
> there are dramatic behavior changes or big feature changes, and they're
> mixed in with fixes.

You are AFAIK correct, and I believe it's deliberate, as it is known to 
be with the binary journal format, for instance.

That bothered me too, so much so that I had originally thought that while 
I'd eventually switch to systemd, I'd sit out until the featuritis slowed 
down and the product stabilized to some degree... tho as some would argue 
happened to pulse-audio (I'm on the sidelines on that one as I've never 
had it installed, here, as I've simply never found I needed it strongly 
enough to do the research necessary to be comfortable installing and 
properly configuring it), that may not happen until Lenart loses interest 
and finds some other project to disrupt the Linux ecosystem with.

But at some point I realized that I was on live-git openrc-9999 in 
ordered to properly follow individual git commits (I had problems earlier 
when I had been on standard ~arch, because the changelog wasn't detailed 
enough to properly trace any problems I had and it was thus much more 
work than it should have been, and than it was once I switched to live-
git openrc), and regardless of how unstable systemd's releases turned out 
to be, at least they were releases... and if I had to do so for similar 
reasons, I could go live-git systemd-9999 as well.

Between that (#1), and once I started experimenting (when I had both 
installed for a time and could switch between them from grub2 with init= 
on the kernel commandline), (2) being /very/ impressed with the level of 
documentation systemd has in general, (3) being /very/ impressed with 
what it did to boot times, even compared to openrc's parallel-init 
option, and (4) finding once I actually got into it that I actually liked 
systemd's declarative style config default, in part because despite a 
declarative config style default, there was still the flexibility to call 
scripts from a unit if it was actually found to be necessary, I decided 
to keep systemd, and ultimately, to unmerge openrc, as I was simply no 
longer keeping up with its config, such that even if I /did/ find I 
needed it, I'd be afraid to run it for fear of what running untested 
updates would now do to the system.  (And anyway, I can always boot to 
the emergency or rescue targets directly, just as one would previously 
boot to initlevel 1/single, and failing that, I could still boot
init=/bin/bash, which in fact I have a grub2 menu entry for.)

So while systemd's failure to have a decent stable/unstable releases 
policy, as well as the continued featuritis, continues to bother me, 
because gentoo /does/ keep older versions around for awhile (and because 
being gentoo, if old versions are removed from the tree, I can always 
dredge the old version from the installed package database or from my 
binpkgs, and put it in my overlay), it's not the problem it might 
otherwise be.  In fact, this whole incident actually supports that... 
because it's gentoo, I actually /have/ 218 (and older versions) still 
available to me, despite the fact that 219 is current-latest ~arch.

So in reality systemd hasn't been any worse than openrc was for me, and 
in a number of ways (including documented config, real speed, cross-
distro standardization so google's more effective, /and/ not signficantly 
more and possibly less show-stopping bugs than openrc), it has actually 
been better, /despite/ the lack of a coherent stable/unstable release 
plan.

Which doesn't mean it wouldn't be better still, if they'd adopt such a 
coherent stable/unstable release plan... nor does it mean I won't at some 
point decide I need to be on live-git to get better commit-level 
granularity on bugs when I see 'em, the better to track them down and 
exterminate them, just as I was for openrc.

There are, however, two other concerns I have about systemd, one in a 
purely practical openrc context, one in a much more general "system 
knowledge bootstrapping ability" context:

1) (openrc context):  Given my experience running live-git openrc, and 
the fact that judging from the bugs filed against it, at least during 
part of the time I ran it, I was the only one (beyond the openrc devs 
themselves) doing so, or at least the only one doing so and filing 
bugs... my having switched to systemd certainly could not have had a good 
effect on openrc pre-release live-git testing and thus bug squashing 
before they ever hit a release at all.

Oh, well...  it's an "SEP", "somebody else's problem", now...  (And to be 
fair, it /did/ appear that toward the end, there was an uptick in openrc 
live-git bugs filed by others too, so others were evidently running it by 
the time I quit.  But still, it was only a handful, say five or so, in 
which case a loss of just one is a loss of 20% of your pre-release 
testing coverage!)

2) (larger philosophical/practical context):  Back in 2001/2002 when I 
got serious about and switched to Linux, I read a couple books, but I 
actually got my practical hands-on shell experience by rewriting several 
of the Mandrake init-scripts, including the core sysinitrc (or whatever 
it was called, that was nearly a decade and a half again, after all!).

I can't believe I was the only one.

As a result, one of the nagging fears I have about systemd, despite all 
the improvements I believe it does bring, is that this early gateway to 
practical shell knowledge and experience is literally disappearing before 
our eyes, and people trying to become Linux CLI/shell literate today are 
going to have a much harder time than people of my Linux generation did, 
because there's far less shell scripting actually available for them to 
work on, and it's far less prominently placed, making it much harder to 
simply stumble upon, as I basically did.

Between that, and the transparency of a shell-based system init that 
they're losing as well, today's newbies may well find it far harder to 
get in as deeply, as quickly, as I did, and the wonders of system bootup 
may as a result remain as practically opaque to them as an MS Windows 
boot.

That would be, and is, a sad thing.  But of course I know the Linux boot 
process pretty well now, the more so since I now have the experience of a 
sysv/shell-script-based init from multiple distros, AND the far different 
systemd-based init, too.  And sad philosophical/practical concern or not, 
being in the knowledge clase now, it's not going to keep me away from the 
faster and more efficiently configured systemd boot. =:^\

(Meanwhile, FWIW, back in the day I knew my way around an MS Windows boot 
too, and in the day hacked solutions to a couple MS Windows driver 
issues, etc.  But never in the decade I was on MS, both DOS and Windows, 
did I know its boot process to the degree that I knew that of Mandrake 
Linux, just a year after switching, and that too was just scratching the 
surface, compared to what I knew six months after installing Gentoo from 
stage-1, tho of course in the decade since I've learned far more still.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman