Re: systemd stance

[Swift Griggs <swiftgriggs%gmail.com@localhost>]

On Sat, 14 Nov 2015, Riccardo Mottola wrote:
> I think they are mostly justified rants and debian got ruined.

I wouldn't call them rants. I'd call them completely justified points that 
left a huge polarizing division between those who wanted to seem 
"progressive" or "on board" with the proposed changes and those who saw 
systemd for what it was: a half-baked set of "ideas" that got wrapped up 
in a nasty implementation by a god-awful coder (author of Pulseaudio, need 
I say more?) in an unfriendly, un-Unixy, and divisive way...

> An occasion to "stand up" against that Borg-like startup system, 
> de-unixifying, full of bloat and dependencies.

At least they tried having a reasonable discussion, unlike what happened 
on the LKML. However, Debian is definitely ruined for me now. I already 
wanted off the Linux train after a few toxic feints in the systemd 
direction with udev, Pulseaudio, and other flubs. *shrug* It wasn't going 
good places anyway.

> I see two issues here: 1) what do do about stuff that depends on systemd 
> (e.g. gnome and related apps). This was actually one of the reasons why 
> Debian brought systemd in.

  Stubs for systemd are already in the works. The Gnome/KDE folks may do 
make it harder, who knows. What the desktop environment folks do is of a 
lot more concern for Linux users versus BSD. Most of the BSD users I know 
aren't attached to Gnome or KDE.  However, I'd imagine that few open 
source software authors & maintainers are just going to ditch their system 
V init support and simply embrace systemd, deprecating all others. I 
haven't seen any evidence for that. All systemd's appearance did was give 
them another target to have to maintain ("thanks" fellas). Personally, I'd 
drop support for anything that required systemd. Let the author know they 
won't be making an appearance in pkgsrc or whatever anymore due to their 
exclusiveness. I haven't seen any software worth using that required 
systemd anyway (yet).

If Gnome and KDE were to become Linux-only enviroments due to systemd, I 
couldn't be bothered to care. If someone started hand-waving about all the 
desktop users we'd lose they'd see my finger firmly pointed at the door 
anyway. Let Linux have them: "Buh-bye, now" *waves*. I'll just keep using 
the console or fluxbox, or a million other WM's and friends...

> 2) You may not like systemd approach, but a more modern startup system 
> can be done: better dependencies, delayed/background starts, 
> parallelism, etc etc.

The same points and arguments still apply. The problem with systemd wasn't 
that it had terrible ideas from the start, it was the implementation of 
those ideas and the politics of the cheerleaders that tried to stuff the 
system down everyone's throat. Parallel startup could be easily achieved 
with NetBSD's current init. So can background starts and all the rest. Of 
course the crontab, udev, socket activation, and other features in systemd 
are either already implemented just fine elsewhere. The binary logging 
mechanisms can simply be dismissed as bad form. Even if one wanted to wrap 
"unit file" support into an existing init, it'd be more possible/sensible 
to wrap that into init rather than designing some kind of world-eating 
daemon to rule-them-all. Bottom line is that the good ideas (parallelism) 
can be achieved (fairly easily) by simply extending the existing code 
base.

I also have to just scratch my head over this debate sometimes. Is 
parallel startup THAT big of deal to folks ? I get that it matters in 
certain situations (like embedded device startup times etc..) but my 
question is just "Really? That's the most important thing to fix/upgrade 
right now?" I'm not so certain this init/systemd debate isn't mostly about 
"my laptop starts faster than yours" at some level...

> based up on simple text files (plists? not big XML stuff which then 
> needs dependencies), easy to configure, small, portable.

It wouldn't hurt to add some kind of easy textual programmatic format like 
"unit files" (which are really just INI files) or some kind of YAML or 
YAML-like thing. However, as a server admin who doesn't really care if his 
system reboots in 30 seconds or 45 seconds, I really don't see the problem 
with most folks using shell scripts. If someone wants to add a unit-file 
type startup mechanism to init, what's stopping them?

> The question is of course if certain software will *require* systemd.

Like I said, we use stubs. If the stubs don't work *shrug* it's too much 
trouble - drop support for the software. The busybox guys had it right, if 
you ask me. Stop compromising with people who intentionally cause problems 
for silly reasons and refuse to cooperate with others. This is 
open-source, volunteer supported software. You can't just go urinate on 
folks and expect them to continually acclimate and "adapt" to your games 
(working for free) while the systemd folks condescend to dictate terms. 
Folks write open source to scratch an itch, not to conform to Lennarts' 
whims about how init should be completely discarded.

-Swift