Steve Litt on 22 Oct 2015 13:48:45 -0700

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: [PLUG] Void Linux tips

What Keith said, with one modification:

> Systemd is simply the new way to do things we have been doing for
> years.

:s/the new way/one of the new ways/


On Thu, 22 Oct 2015 16:40:12 -0400 (EDT)
"Keith C. Perry" <> wrote:

> Linux distros are very much about personality. That's why there are
> so many of them. Additionally, as a community we need to be careful
> about rallying behind any one something and saying it is the way to
> do a thing. The truth is, it isn't. 
> Systemd is simply the new way to do things we have been doing for
> years. There are things like about it and things I like about it but
> it's hardly the deciding factor nor is it the thing that defines the
> personality of a distro. 
> The core requirement of a system is to be able to provide reliable
> service and truth be told the vast majority of distros do that. 
> ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ 
> Keith C. Perry, MS E.E. 
> Owner, DAO Technologies LLC 
> (O) +1.215.525.4165 x2033 
> (M) +1.215.432.5167 
> From: "Steve Litt" <> 
> To: 
> Sent: Thursday, October 22, 2015 4:08:38 PM 
> Subject: Re: [PLUG] Void Linux tips 
> On Thu, 22 Oct 2015 00:17:10 -0400 
> brent timothy saner <> wrote: 
> Hash: SHA512 
> On 10/21/2015 11:45 PM, Steve Litt wrote: 
> > 
> > For me, the elephant in the room was systemd, which Arch embraces 
> > enthusiastically, and which Void formerly used as its init before 
> > dumping it for runit. 
> not liking systemd is certainly a right and prerogative someone has, 
> but what you've presented here is largely a preference rather than 
> any sort of objective reasoning. 
> That's absolutely true. Based on my use case, and my personality, and 
> my strengths and weaknesses, I choose to forego systemd. It's a 
> preference. 
> there is a lot of FUD around systemd, however, which i discuss in 
> S0E8[0] of my podcast (starting at 39m20s). 
> I'd suggest everyone on the list listen to this podcast, at 
>, go down to the one 
> numbered S0E8, and listen from 39m20s to the end. Brent, I'd like to 
> congratulate you on not trotting out all the old character 
> assassinations that people not wanting systemd are "neckbeards", 
> "against innovation", "afraid to try something new", "demotivating", 
> etc. Your choosing not to go down those roads already puts you in the 
> upper 20% of class within the systemd debate. 
> I wouldn't characterize all the positions your podcast discusses as 
> "FUD". We've all seen anti-systemd FUD: Firefox crashes and it's 
> automatically systemd's fault. That's FUD. 
> What you're discussing are assertions. People choosing to avoid
> systemd assert that systemd ties together huge chunks of
> functionality. Your podcast waves off this assertion by mentioning
> that netcat includes a lot of functionality, but this comparison of
> systemd's inclusion with netcat's is breathtakingly asymmetrical. I
> suggest you find a better way of framing your response, although I
> have no idea what better (and accurate) way that would be. 
> Roughly five times your podcast compared systemd favorably to
> sysvinit. This is kind of like saying "I'm smarter than Mike Tyson
> and stronger than Stephen Hawking." Saying something is superior to
> sysvinit is no complement at all: There are many better alternatives. 
> Truth be told, I personally would prefer even sysvinit to systemd,
> but that's not the issue and heck, just to proceed forward I'll
> stipulate that systemd is better than sysvinit. But there are at
> least four init systems I vastly prefer to sysvinit: Epoch, s6,
> runit, and even suckless init plus daemontools-encore plus LittKit.
> Not a one of these have "init scripts" of the size and complexity of
> those of sysvinit and OpenRC. Comparing systemd to sysvinit is a very
> restricted partial truth, so I'd suggest you frame the discussion
> over the wider range of init systems. 
> Toward the end of the podcast your buddy says that things would be 
> better if if everyone who is trying to fork debian would work to 
> integrate systemd. That's not how Open Source or Free Software works. 
> And you mention something to the effect that people forking Debian
> are "causing a problem." I'd suggest you jetison that line of
> thinking right along with the "neckbeard" assertions that you refused
> to engage in. 
> Last but not least is, I'm not sure if it's my inference or your 
> implication, that one init system fits all use cases. Absent is 
> recognition that a person's use case drives his/her software choice. 
> Use case is everything in software choice. 
> For instance, if I had 99.9999% uptime guarantees, I'd for sure pay a 
> large bill, in money or in added complexity, for systemd's 1 second 
> boot. 
> But my use case is a Daily Driver Desktop, that boots at the most
> once every couple days, usually weeks between boot. 1 second, 10
> seconds, 30 seconds, makes no difference to me. My Daily Driver
> Desktop runs my 1 man business, meaning I'm the guy who has to fix
> it. I'm the guy who has to customize it. If you count debugging my
> own and other peoples' code as repair, I repaired things, for a
> living for 26 years before becoming a trainer and author. Never
> during that 26 years did I see added complexity that didn't make
> repair more difficult. You mention in your podcast that journald
> replaces (or is like) logrotate plus rsyslog. Well, I already have
> logrotate and rsyslog, and all the other tools Linux gives me, so I
> don't need the extra systemd layer that I need to pierce if I get a
> problem not fixable on the systemctl level. All other things being
> equal, I prioritize simple. And in my use case, all other things
> *are* equal: I don't need fast boots, I don't need the edge case
> benefits bestowed by socket activation, and I don't need logs
> covering my initramfs. Void's nine second runit init covers all my
> needs, without the systemd layer. 
> The reason I know it's a layer is, first of all, because of what 
> Lennart says here: 
> Lennart also says it when he describes the architecture in various 
> parts of his hard to research Pid Eins blog, although I can't find
> the exact pages. 
> I also know from personal experience that systemd is a layer, and a 
> hard layer to pierce. I learned about that while replacing systemd
> with Epoch and/or runit on Centos and Manjaro. Replacing any ordinary
> init system with Epoch or runit is a straightforward clean swap.
> Replacing systemd, you need to tweak many details in many programs
> and config files. And then there's the software dependency issues,
> which are too big to get into here. 
> Systemd is a thick layer with tenticles into a lot of software, my
> use case doesn't require that layer, so I won't use that layer. 
> i find a lot of it comes from individuals who have never actually
> used systemd in a production or regular environment (or a *proper*
> systemd implementation- such as Arch's- and have instead used a
> half-cocked hybridized implementation such as debian, ubuntu, centos
> to a lesser degree, etc.) 
> The preceding paragraph seems to imply that if you want to use
> systemd the right way you go with Arch. I'm going to assume that's
> not what you meant, because that would be a potent anti-systemd
> argument. 
> I used Manjaro with systemd on a notebook for a few months. It was 
> OK. It was fine. I had no problem with it. I use simple setups 
> everywhere I go, so systemctl was easily capable of controlling the 
> notebook, and if it hadn't been, re-installation would have been 
> trivial. But with my Daily Driver Desktop that runs my business,
> which I must keep functional all the time and mold to my exact usage,
> I want the simplest possible construction with the fewest abstraction
> layers, and that means no systemd. 
> i'd invite you to look a bit deeper into systemd and use it a little 
> bit before criticizing it. 
> :-) 
> If you knew how much I've looked into systemd, you'd be
> flabbergasted. 
> But seriously, it's about use case. We don't all use the same init 
> system for the same reason that we don't all drive the same kind of
> car. 
> SteveT 
> Steve Litt 
> October 2015 featured book: Thriving in Tough Times 
Philadelphia Linux Users Group         --
Announcements -
General Discussion  --