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 |