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
