Gentoo Archives: gentoo-amd64

From: Duncan <1i5t5.duncan@×××.net>
To: gentoo-amd64@l.g.o
Subject: [gentoo-amd64] Re: Systemd migration: opinion and questions
Date: Thu, 21 May 2015 09:36:58
Message-Id: pan$e8522$5818ae60$54dea596$5b77fc3a@cox.net
In Reply to: Re: [gentoo-amd64] Re: Systemd migration: opinion and questions by Rich Freeman
1 Rich Freeman posted on Wed, 20 May 2015 07:22:39 -0400 as excerpted:
2
3 > I don't think systemd has any kind of stable release strategy, and I
4 > think that is going to become a problem. There are a lot of cases where
5 > there are dramatic behavior changes or big feature changes, and they're
6 > mixed in with fixes.
7
8 You are AFAIK correct, and I believe it's deliberate, as it is known to
9 be with the binary journal format, for instance.
10
11 That bothered me too, so much so that I had originally thought that while
12 I'd eventually switch to systemd, I'd sit out until the featuritis slowed
13 down and the product stabilized to some degree... tho as some would argue
14 happened to pulse-audio (I'm on the sidelines on that one as I've never
15 had it installed, here, as I've simply never found I needed it strongly
16 enough to do the research necessary to be comfortable installing and
17 properly configuring it), that may not happen until Lenart loses interest
18 and finds some other project to disrupt the Linux ecosystem with.
19
20 But at some point I realized that I was on live-git openrc-9999 in
21 ordered to properly follow individual git commits (I had problems earlier
22 when I had been on standard ~arch, because the changelog wasn't detailed
23 enough to properly trace any problems I had and it was thus much more
24 work than it should have been, and than it was once I switched to live-
25 git openrc), and regardless of how unstable systemd's releases turned out
26 to be, at least they were releases... and if I had to do so for similar
27 reasons, I could go live-git systemd-9999 as well.
28
29 Between that (#1), and once I started experimenting (when I had both
30 installed for a time and could switch between them from grub2 with init=
31 on the kernel commandline), (2) being /very/ impressed with the level of
32 documentation systemd has in general, (3) being /very/ impressed with
33 what it did to boot times, even compared to openrc's parallel-init
34 option, and (4) finding once I actually got into it that I actually liked
35 systemd's declarative style config default, in part because despite a
36 declarative config style default, there was still the flexibility to call
37 scripts from a unit if it was actually found to be necessary, I decided
38 to keep systemd, and ultimately, to unmerge openrc, as I was simply no
39 longer keeping up with its config, such that even if I /did/ find I
40 needed it, I'd be afraid to run it for fear of what running untested
41 updates would now do to the system. (And anyway, I can always boot to
42 the emergency or rescue targets directly, just as one would previously
43 boot to initlevel 1/single, and failing that, I could still boot
44 init=/bin/bash, which in fact I have a grub2 menu entry for.)
45
46 So while systemd's failure to have a decent stable/unstable releases
47 policy, as well as the continued featuritis, continues to bother me,
48 because gentoo /does/ keep older versions around for awhile (and because
49 being gentoo, if old versions are removed from the tree, I can always
50 dredge the old version from the installed package database or from my
51 binpkgs, and put it in my overlay), it's not the problem it might
52 otherwise be. In fact, this whole incident actually supports that...
53 because it's gentoo, I actually /have/ 218 (and older versions) still
54 available to me, despite the fact that 219 is current-latest ~arch.
55
56 So in reality systemd hasn't been any worse than openrc was for me, and
57 in a number of ways (including documented config, real speed, cross-
58 distro standardization so google's more effective, /and/ not signficantly
59 more and possibly less show-stopping bugs than openrc), it has actually
60 been better, /despite/ the lack of a coherent stable/unstable release
61 plan.
62
63 Which doesn't mean it wouldn't be better still, if they'd adopt such a
64 coherent stable/unstable release plan... nor does it mean I won't at some
65 point decide I need to be on live-git to get better commit-level
66 granularity on bugs when I see 'em, the better to track them down and
67 exterminate them, just as I was for openrc.
68
69 There are, however, two other concerns I have about systemd, one in a
70 purely practical openrc context, one in a much more general "system
71 knowledge bootstrapping ability" context:
72
73 1) (openrc context): Given my experience running live-git openrc, and
74 the fact that judging from the bugs filed against it, at least during
75 part of the time I ran it, I was the only one (beyond the openrc devs
76 themselves) doing so, or at least the only one doing so and filing
77 bugs... my having switched to systemd certainly could not have had a good
78 effect on openrc pre-release live-git testing and thus bug squashing
79 before they ever hit a release at all.
80
81 Oh, well... it's an "SEP", "somebody else's problem", now... (And to be
82 fair, it /did/ appear that toward the end, there was an uptick in openrc
83 live-git bugs filed by others too, so others were evidently running it by
84 the time I quit. But still, it was only a handful, say five or so, in
85 which case a loss of just one is a loss of 20% of your pre-release
86 testing coverage!)
87
88 2) (larger philosophical/practical context): Back in 2001/2002 when I
89 got serious about and switched to Linux, I read a couple books, but I
90 actually got my practical hands-on shell experience by rewriting several
91 of the Mandrake init-scripts, including the core sysinitrc (or whatever
92 it was called, that was nearly a decade and a half again, after all!).
93
94 I can't believe I was the only one.
95
96 As a result, one of the nagging fears I have about systemd, despite all
97 the improvements I believe it does bring, is that this early gateway to
98 practical shell knowledge and experience is literally disappearing before
99 our eyes, and people trying to become Linux CLI/shell literate today are
100 going to have a much harder time than people of my Linux generation did,
101 because there's far less shell scripting actually available for them to
102 work on, and it's far less prominently placed, making it much harder to
103 simply stumble upon, as I basically did.
104
105 Between that, and the transparency of a shell-based system init that
106 they're losing as well, today's newbies may well find it far harder to
107 get in as deeply, as quickly, as I did, and the wonders of system bootup
108 may as a result remain as practically opaque to them as an MS Windows
109 boot.
110
111 That would be, and is, a sad thing. But of course I know the Linux boot
112 process pretty well now, the more so since I now have the experience of a
113 sysv/shell-script-based init from multiple distros, AND the far different
114 systemd-based init, too. And sad philosophical/practical concern or not,
115 being in the knowledge clase now, it's not going to keep me away from the
116 faster and more efficiently configured systemd boot. =:^\
117
118 (Meanwhile, FWIW, back in the day I knew my way around an MS Windows boot
119 too, and in the day hacked solutions to a couple MS Windows driver
120 issues, etc. But never in the decade I was on MS, both DOS and Windows,
121 did I know its boot process to the degree that I knew that of Mandrake
122 Linux, just a year after switching, and that too was just scratching the
123 surface, compared to what I knew six months after installing Gentoo from
124 stage-1, tho of course in the decade since I've learned far more still.)
125
126 --
127 Duncan - List replies preferred. No HTML msgs.
128 "Every nonfree program has a lord, a master --
129 and if you use the program, he is your master." Richard Stallman

Replies