MESSAGE
| DATE | 2016-12-19 |
| FROM | Rick Moen
|
| SUBJECT | Re: [Hangout-NYLXS] the issues with SystemD: why are they doing
|
Quoting mayer ilovitz (pmamayeri-at-gmail.com):
> I have not been following the development of SystemD, and so may be
> completely wrong, but from what little I've read, I get the
> impression it was developed (and adopted) by people who came over
> from the MS-type world and were new/unfamiliar to the UNIX
> traditions and there were insufficient people to stand against it.
The key problem, IMO, has been people being passively carried along by
excessive package dependencies, and failing to say 'Whoa, this is
madness' and gracefully moving sideways away from the mess.
The mess got started, as many messes have, inside the GNOME Desktop
Environment, which showed an early bland acceptance of package
dependency tangles that has only gotten worse over time. GNOME people
started writing low-level service libraries that started having
interlocking dependencies on each other, and writing infrstructure
in parallel to standard Unix infrastructure. E.g., you think privilege
is conveyed by EUIDs, groups, ownerships, permissions, sudo? All of
that is deemed obsolete and to be managed by GNOME DE plumbing. Some of
the pieces of software in question: PolKit, udisks2, upower,
PackageKit, udev, D-Bus, ConsoleKit. Most, possibly all, of these
pieces of software infrastructure were/are developed at umbrella site
Freedesktop.org, so in a sense you can call them 'Freedesktop.org
plumbing'.
One of the observed characteristics of Freedesktop.org plumbing is that
its codebases get frequently orphaned and replaced by from-scratch
rewrites -- a trait presumably taken their GNOME antecedents. One of
these was ConsoleKit: Around five years ago, the Freedesktop.org
coders (many but not all of whom are now Red Hat employees) put the
world on notice that ConsoleKit would no longer be maintained, and that
the only functional replacement would be part of the new systemd suite,
systemd-logind.
And why did this matter, you ask? Because GNOME and some other DEs
(KDE, Xfce4, GNOME variants such a MATE / Cinnamon / Unity) had
been allowed to become dependent on a special type of login
functionality called 'seats' that necessitated special complex
libraries, that were furnished only by Freedesktop.org's ConsoleKit
libs.
The newer X11 X Display Managers -- current revisions of gdm, kdm,
LightDM, etc. -- all have package dependency on libs supporting 'seat'
functionality at login. Here's an article explaining 'seats':
https://dvdhrm.wordpress.com/2013/08/24/session-management-on-linux/
A seat is a virtual object that describe a physical interface to a
system. The combination of a monitor plus keyboard and mouse form a
usual seat. One user can interact with the system through this seat.
If you attach another monitor plus keyboard and mouse, another user
can interact with the system in parallel via this new seat (eg.,
called seat1). It is important to note that these seats are
independent of each other. The pictures you get on the monitors
are different and keyboard input from one seat doesn't affect the other.
Any device connected to your system can be attached to a seat, but
only to one seat at a time! If a device is attached to seat, it
cannot be used by processes running on another seat. Obviously,
input devices, sound-devices and monitors are usually attached
to a seat. Network-interfaces, for example, can be left unattached
so all seats can share an internet-connection. It is up to the
system-administrator to decide which devices to attach to which
seat, or whether to leave them as global devices that can be shared.
There is nothing wrong with this idea, for the very few installations
that actually would need and use it, and I wish them the best of
fortune with developing and deploying what amounts to a 21st C.
reinvention of the minicomputer. _However_, this use-case is
utterly irrelevant to the overwhelming majority of Linux installaations,
which have each a single monitor/keyboaard/pointer set, and where most
concurrent user access is over _networks_
But, getting back our story, those of us who don't really give a damn
about DEs had been blissfully ignoring GNOME/Freedesktop.org foolishness
as Someone Else's Problem until crisis got launched by the orphaning of
ConsoleKit.
The many distributions that foolishly had chosen one of the afflicted
DEs as a 'standard desktop', such as Debian Project had with GNOME,
suddenly had a problem: GNOME required seats, seats had required
ConsoleKit and now would require systemd-logind. systemd-logind
required a forced changeover from preferred init systems to systemd.
While the other Freedesktop.org plumbing had been getting into systems
via package dependency trees, the systemd developers had been deciding
that their new event-driven init system, systemd, ought to become a
great deal more than just an init system, and started a still-ongoing
process of building into systemd replacements for more and more standard
Unix software. They merged into systemd the udev codebase, and from
that point on have refused to accept patches permitting udev to be built
without the rest of systemd. They also resist documenting and
stabilising the interfaces the various components of systemd use to talk
to each other, to other Freedesktop.org plumbing, and to the kernel,
considering it not worth their time, and, besides, they want to remain
free to orphan their creations at any time and write from-scratch
replacements.
IMO, the resulting big-picture problem is _not_ systemd. It's the
interlocking package dependency hairball among _all_ of the
Freedesktop.org desktop-software pieces. IMO, fixing the problem
requires saying no to _all_ such software lacking reasonable scope of
functionality per package, software lacking documented interfaces
permitting use of best-of-breed choice of software, and software with
absurdly excessive dependencies.
There are reasonably good ideas within systemd's init system, a point
made dramatically by a proof-of-concept rewrite called 'uselessd',
which properly refactored the init system portion of the systemd init
system and made it available without ridiculous dependency trees or
intrusion into a great deal of existing system software. (The author
wrote it merely to make that point. It has not been maintained.)
My http://linuxmafia.com/faq/Debian/openrc-conversion.html page
illustrates how to do this with Debian 8 'Jessie'. It requires saying
'no' to certain dependency-hairball sets of packages, including the
Debian metapackages for GNOME, MATE, Cinnamon, KDE, and Razor-qt.
The page is limited to what can be done using simple package-manager
configuration, without resorting to third-party repositories, locally
built packages, etc. With those added, the choice of installable
software is wider.
Unfortunately, most of the 'opposition' to systemd has consisted solely
of individuals haranguing Linux distribution maintainers, which merely
created a great deal of noise and accomplished nothing. My page aims to
illustrate an alternative: Skip the angry advocacy postings, and just
figure out the best / least-effort ways to run your Linux systems
without the undesired packages.
I was repeatedly advised, for years before I created that page, that
the Debian Project was a lost cause because a bunch of angry people had
protested on the debian-user mailing list and been eventually ejected or
put on moderation. I smelled a non-sequitur, so I tried ignoring the
noisy and fruitless arguing, and instead just doing something with
software. And lo! It works fine. Imagine that.
_______________________________________________
hangout mailing list
hangout-at-nylxs.com
http://www.nylxs.com/
|
|
