[sf-lug] SF-LUG met on Sun 2016-05-01 (Several distros on MayDay)

[Rick Moen]

Quoting Daniel Gimpelevich (daniel at gimpelevich.san-francisco.ca.us):

> They are _the_ upstream maintainers of vdev, LoginKit, and a long list
> of other bits of code otherwise missing from a theoretical non-systemd
> GNU/Linux OS.

Cool.  Of course, 'is the upstream maintainer of' doesn't preclude other 
distros packaging those things, though I don't find vdev in packages.debian.org, 
for example.

Jude C. Nelson's vdev is one of the several interesting alternatives to
udev, though personally I still find it overly Rube Goldberg-ian for use
on server systems, where the emphasis should be on minimal feature sets
and avoidance of the brass-band philosophy common in 'desktop'
computing.  I mean, let's face it:  One of the reasons people look for
simpler udev replacements is that the danger of some Freedesktop.org
desktop-coder kiddie accidentally blowing system security and stability
to add some feature to udev / systemd is a real threat -- not to
mention Lennart Poettering telling people that henceforth udev and Linux
kernels will need to just always be upgraded in lockstep with each
other, and just get used to it.

http://judecnelson.blogspot.com/2015/01/introducing-vdev.html

As Nelson says, other common options include mdev, smdev, and nldev.
And there's also eudev, though it seems quixotic to me.  Personally, I'm
lastingly fond of Rob Landley's mdev, as it's _really_ minimal, and
doesn't succumb to the desire to satisfy every possible feature request
that I still see in vdev.  (Not that I'm in any way less than admiring
of the project generally.  I just don't need all of what it does.)

https://git.busybox.net/busybox/tree/docs/mdev.txt
https://wiki.gentoo.org/wiki/Mdev

Quoting the latter:

  Will mdev work on my system?

  The mdev application is definitely suitable as long as the system does
  not use a full-fledged desktop environment. Note that a desktop
  environment is not required to run AbiWord, Firefox, GIMP, Gnumeric,
  etc. However, KOffice applications like KMail seem to pull in most of
  KDE as a dependency. In general, when using KDE or GNOME, mdev is not
  suitable. Also using LVM might be troublesome.

Seems to hit my use-cases perfectly, as I don't care whether DEs have
indigestion, or whether the worst DE-related apps (like KMail) do.  For
perspective, you get mdev for free if you have Busybox, so that'll give
you some idea how small and simple it is.

One early sign of trouble in the developer community was when the
systemd & udev developers passive-aggressively refused to answer Rob
Landley's polite queries about some undocumented aspects of udev
behaviour, when he was developing mdev.  And, to the extent they
answered at all, they basically said udev was intentionally a black box
that they wanted to reserve the right to change at will, therefore they
were reluctant to document its operation.  Really, guys?


> I urge people who think the issue is just that simple to
> read this thread:
> http://www.linuxquestions.org/questions/linux-from-scratch-13/more-systemd-creep-and-a-script-to-spot-it-4175540203/

The dependency deathmarch blamed on systemd is 99% felated to Desktop
Environments, primarily GNOME and Xfce4, and with a few bad signs from
KDE4.  

That was that whole bit of ugliness started about five years ago by
ConsoleKit getting orphaned (as Freedesktop.org projects tend to be at
the drop of a hat), whereupon the GNOME and Xfce4 guys, who'd relied on
ConsoleKit for their 'multi-seat' functionality -- that I have no use
for whatsoever -- suddenly said well, if that's gone, then GNOME is
going to need systemd-login instead, which means GNOME depends on
systemd-login, which depends on systemd, which swallowed up and
incorporated udev, whereupon a bunch of people woke up and said, 'Wait,
what?  What do you mean there's a mandatory dependency tree that
requires me to change to a different init and start depending on a 
stinking pile of buggy, fragile, and ever-changing Freedesktop.org
code?'

Whereas, I looked at that, and my takeaway was different.  It was:
'GNOME guys just alerted us to their baroque and excessive "multi-seat"
login code having developed brittle dependencies, and Xfce4 caught the
disease from them on account of shared code.  But that's easy to fix:
Stop needing GNOME and Xfce4.'

LoginKit, ConsoleKit2, and systemd-shim are heroic efforts to prop up
the fragile and wrong-headed GNOME / Xfce4 dependencies.  Which I guess
is great if you are chained to GNOME or Xfce4 and cannot escape.
Personally, I find the 'Don't use GNOME or Xfce4' solution simpler.
Which implies also MATE / Cinnamon / Unity, of course.

(I might be wrong about Xfce4 still suffering that breakage.  At least
for a while, it was caught up in that hapless tangle.)

As a server guy, I'm not really impressed by Poettering's attempts to
strongarm everyone by threatening to drop udev's ability to process
syscalls from the kernel's netlink socket, in order to force everyone to
use kdbus instead of D-Bus.  For one thing, I really have no use at all 
for D-Bus in the first place.  That's interprocess communication (IPC)
for Freedesktop.org DE code.  Which I can live without.

One of the reasons Torvalds rejected the earlier attempt to cram kdbus
down everyone's throats is that he could clearly see that the desktop
software people (Poettering, Kay Sievers, etc.) claimed they needed to
move IPC into kernelspace because userspace IPC was a drag on
performance:  Torvalds took a good look at their excessive and wasteful
use of IPC and reacted (paraphrasing):  'No, you are not going to move
all that bullshit into my kernel just because you cannot figure out how
to write application code that works without absurd amounts of message
traffic.'

As I keep trying to say to the anti-systemd people, the problem isn't
actually systemd.[1]  That was just the flashpoint that caused people to
say 'Wait, what?'  The problem was and is the entire stack of badly
written, quickly EOLed, fragile, dependency-ridden Freedesktop.org
components:  udev, systemd, D-Bus, NetworkManager, PulseAudio, BlueZ,
Polkit, udisks, upower, PackageKit, and probably some I'm forgetting.
It's all one big code hairball in practice -- with the list changing
frequently as they EOL their projects and introduce mandatory
replacement projects.  I say, take off and nuke the whole suite from
orbit.  It's the only way to be sure.


[1] Although, dear God, some days these people seem like just a Persian
cat and a monocle away from coming across as Bond villains wanting to
take over the world.  Just noticed this in Wikipedia's article on
systemd:  'In August 2015, systemd now provides a login shell, callable
via machinectl shell.'  Wow, has it's own login shell.  When's it going to
replace emacs, play Tower of Hanoi, and send and receive e-mail?