Quoting Enrico Weigelt, metux IT consult ([email protected]): > 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 <[email protected]> To: [email protected] Subject: Re: [DNG] F1 and special usernames on the login screen Quoting Arnt Gulbrandsen ([email protected]): > 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 <[email protected]> To: [email protected] Subject: Re: [DNG] F1 and special usernames on the login screen Quoting Steve Litt ([email protected]): > 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 <[email protected]> To: [email protected] Subject: Re: [sf-lug] SF-LUG met on Sun 2016-05-01 (Several distros on MayDay) uoting Daniel Gimpelevich ([email protected]): > 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? _______________________________________________ Dng mailing list [email protected] https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
