Quoting Enrico Weigelt, metux IT consult (enrico.weigelt@???):

> Could anyone please enlighten me, what all these "seat" and "session"
> stuff is really about ? What is the underlying problem to solve here ?

Below are a couple of things I've written on the subject here and
elsewhere.



Date: Tue, 19 Jul 2016 01:29:23 -0700
From: Rick Moen <rick@???>
To: dng@???
Subject: Re: [DNG] F1 and special usernames on the login screen

Quoting Arnt Gulbrandsen (arnt@???):

> Multiseat is unimportant, barely significant. The price of computers
> has dropped enough that the ones with UIs are now personal devices.

Might be obvious, but just mentioning: 'Multiseat' (GNOME/system
implementation of which proximately caused the systemd-logind
omnishambles of several years ago) needs to be distinguished from
multiuser.

Unix has been inherently, by design, _multiuser_ since its beginning,
and I for one would be quite sad if my Linux servers were suddenly
'personal devices': E.g., a Web / SMTPd / ftpd / sshd / rsyncd / NTPd
server like the one in my garage suddenly failing to serve remote users
would be a misfortune.

I have to confess that I personally didn't understand how multiseat
differs from multiuser on Linux until quite recently. Pro bono publico:
It concerns simultaneous _local_ users. The Linux kernel[1] can,
unaided, make _only one_ (local) virtual terminal active at a time. Sure,
you can (e.g.) have one X11 server attached to /dev/tty7 and another to
/dev/tty8, but it turns out that any time one's active, the other can't
be -- even if two physical sets of console hardware are attached.
So, multiseat is, in short, a system software elaboration to fix that.

This missing kernel functionality isn't important to either you, Simon
Walter, or me, but it's a genuine limitation nonetheless, and there's
nothing wrong _per se_ with offering ways around that limitation. Note
that systemd-consoled is not the only candidate: kmscon preceded it,
albeit development is currently stalled.
https://en.wikipedia.org/wiki/Kmscon
https://en.wikipedia.org/wiki/Multiseat_configuration#GNU.2FLinux also
mentions several other current implementations.

So, multiseat is _not_ a systemd invention, nor a systemd monopoly.

Latter page mentions 'Multiseat setups are great for schools, libraries,
and family computers.' Arguably true, _maybe_. Depends on the economics
of additional consoles versus extra complete computers, I guess. I
enjoyed using minicomputers during high school: A modern revival of that
computing model using Linux might make money sense or might not, depending.
Otherwise, I wouldn't say today that it'll necessarily be 'unimportant' in
years to come.

[1] Some other *ixes such as SunOS and Irix allegedly (per Wikipedia)
had multiseat capability since early days, though I have no further
details.




Date: Tue, 19 Jul 2016 10:59:26 -0700
From: Rick Moen <rick@???>
To: dng@???
Subject: Re: [DNG] F1 and special usernames on the login screen

Quoting Steve Litt (slitt@???):

> Yes. What would be the advantage of LTSP over kmscon or systemd? What
> would be the disadvantage? How would one choose between LTSP and kmscon
> (I'm assuming nobody on this list would choose systemd)?

Well, LTSP (and variations thereon) is a very attractive option if your
consoles have motherboards, adequate CPUs, adequate RAM, and the ability
to run Linux. Technically, they don't need local mass storage, because
they can netboot.

LTSP (and variations thereon) is _outside_ the realm of possibility if
your consoles are just consoles and don't each include a Linux-capable
computer.

People looking fond of multiseat capability wish to bring about a
renaissance of non-autonomous console computing. I'm not among them,
but consoles did make economic sense decades ago when I was in high
school and when minicomputers were in their heyday, and maybe they will
again. Or not.




Date: Mon, 2 May 2016 16:51:46 -0700
From: Rick Moen <rick@???>
To: sf-lug@???
Subject: Re: [sf-lug] SF-LUG met on Sun 2016-05-01 (Several distros on
MayDay)

uoting Daniel Gimpelevich (daniel@???):

> 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% related 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
strong-arm 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 its own login shell. When's it going to
replace emacs, play Tower of Hanoi, and send and receive e-mail?