[ale] Origins of Linux, do we care?

[Solomon Peachy]

On Fri, Sep 18, 2015 at 03:19:15PM -0400, leam hall wrote:
> Ah, sorry, my lack of clarity. The init process is vastly technically
> superior to the Windows boot process.

I'm not sure you're really comparing apples to apples ("init" vs "boot") 
here, but okay.  

(FWIW, I have at least as much low-level visibility with systemd as I 
had prior to that with the old init scripts.  Compared to.. well, none 
with windows...)

> Because one cannot improve on one tool without breaking (into) the others.
> For example, the RH "chkconfig" and "system" commands integrated into the
> existing init scripts. You could choose to use them, or not. If someone
> came from another *nix flavor they would have a basic knowledge of the init
> system.

If you came over from some other unix or BSD system, Linux was already 
not portable with respect to init mechanisms or, fairly often, even the 
scripts themselves.  Heck, distro-to-distro differences meant that a 
script that worked on, say, RH might not work on, say, Debian.

chkconfig was unique to IRIX and RH, written because managing symlinks 
across runlevels by hand was a (let's be generous) PITA.  Incidentally, 
pre-systemd RH/Fedora used upstart, which largely did away with the 
notion of runlevels.  About all it shared with classic sysvinit were the 
basic scripts themselves.

Meanwhile.  chkconfig only worked with init symlinks, though later 
xinetd support was bolted on in an incompatible manner.  So right there 
you already had two or three different mechanisms to enable or disable 
services, plus different ways of actually starting/stopping them once 
enabled.

Perhaps a better example is the 'service' command, written to try and 
hide the differing locations to service invocation scripts.  If you were 
using 'service' to start/stop things, then nothing changed after the 
systemd migration.  Except that now everything (including socket 
activation) worked via that mechanism instead of the two (or three) 
before.

> Yes. Even though, as far as we know, the systemd folks haven't been nearly
> so legally wrong as others, they are being as demanding and unopen. "Our
> way or the highway."

> From
> http://www.pcworld.com/article/2841873/meet-systemd-the-controversial-project-taking-over-a-linux-distro-near-you.html

If you're going to ascribe behavior to the systemd devleopers, please 
directly quote them, not someone else's (incorrect) descriptions.  But 
I'll get to that in a moment.

Systemd has not forced anything on anyone.  Really.  Now your 
(formerly?) favorite linux distribution may have chosen to utilize 
systemd to replace a pile of home-grown, highly brittle and 
barely-working parts, but that was their choice to make, since they are 
the ones doing the work.  Each of those distro makers explicitly chose 
what parts of systemd to utilize; all but two components are completely, 
entirely optional -- the two required bits are systemd-as-pid1 and the 
journal.  Literally *every other part* is optional, and every component 
has an explicitly defined, public, and stable interface so it can be 
replaced with an alternative implementation of so desired.

...If that's not modularity, I don't know what is.

> "The systemd project also contains logind, a daemon that manages user
> logins, and journald, an event-logging system that controversially writes
> to binary files and not text ones. 

I concede that journald is a required component, but you can completely 
disable its writing things to disk and/or forward everything to a syslog 
daemon instead.  (in situations where there is truly obscene logging 
rates going on, this is suboptimal, but we're talking hundreds of 
thousands of logging events per second before this is a problem)

There are significant advantages to journald, but I'll not go into that 
those unless you'd like me to.

As for logind... systemd didn't force anyone to use it, but upstream 
projects (eg gnome) jumped because it provided a vastly superior user 
(and developer) experience to the half-broken-and-dead-upstream 
ConsoleKit backend -- in the sense that logind actually worked. It also 
provided a far cleaner API that proved to be easier to re-implement than 
the effort needed to fix the many problems with ConsoleKit.

(as an aside, logind was actually very easy to add to systemd, and a lot 
harder to reimplement elsewhere because systemd already had most of the 
underlying functionality necessary to implement it properly.  The last 
time I chacked, the other implementations of logind's API only handle 
basic, single-user-at-a-time use cases.)

> Systemd has also absorbed the udev project 
> <http://en.wikipedia.org/wiki/Udev> and its code, which handles the 
> management of virtual device files in the */dev/* directory and events 
> when devices are plugged in and unplugged.

Udev and systemd are developed in the same code repository, and systemd 
makes heavy use of udev.  However, udev itself can be installed and used 
without any part of systemd, and its developers treat any runtime 
dependency on systemd as a bug.

(It's not like there was a hostile takeover either; the udev folks were 
completely on board with this. Besides, there are alternatives to udev, 
including a pre-systemd fork called eudev, and busybox's tiny 
reimplementation.  I don't know how their functionality compares though)

> The list goes on and on: systemd also includes a cron 
> <http://en.wikipedia.org/wiki/Cron>-style task scheduler and networkd, 
> a daemon for managing network connections.

How many cron daemons does Debian include in their reposites? How many 
network connection managers?  How is including another any different?

FWIW I'm not aware of any mainstream distribution actually using either, 
although I am looking forward to the systemd's cron replacing 
traditional atd/crond with something that's aware of the rest of the 
system.  (eg having to hand-edit crontabs to disable things that don't 
apply because the daemon it depends on isn't running.  and re-enabling 
them when appropriate too..)
 
> More recently, systemd is gaining consoled, a user-mode console daemon that
> can be used when Linux’s virtual terminal code is stripped out of the
> kernel itself. The kernel developers seem happy to get this stuff out of
> the kernel and into user-space , but some people have to be thinking: Does
> systemd really have to take over this as well?"

Yeah, how dare systemd implement early support for an experimental 
kernel feature that has yet to be mainlined!

More seriously, console spawning is one of the few things still directly 
handled by classic sysvinit, and as such systemd has supported it from 
the beginning.  It's hard to argue that systemd shouldn't attempt to 
handle purely-in-userspace console spawning when it already has to 
implement the kernel-VT interfacing today.

Of course, others are free to implement userspace-VT management too..

> I consider the intrusiveness of systemd to be against what I understand
> about Linux. Which does not make me right and everyone else wrong.

Fair enough.  I suppose that last bit goes for me too!  :)

> The facts I refer to, and I'm open to being corrected, are that systemd
> replaces several functions previously unrelated and that it precludes using
> similar functionality in a side by side manner. Are you disagreeing with
> those points?

One of the core design principles of systemd is that a lot more stuff is 
actually related than is traditionally recognized.

Most of systemd's compoments are optional; there's nothing precluding 
using them in combination with something else that implements similar 
functionality.  (an example of this is that Fedora still uses its old 
'network' service or NetworkManager, not bothering with systemd-networkd 
as it's wholly inadequate for their needs)

There are two components in systemd that are required, and those by 
their very nature preclude being replaced with something else.  FWIW the 
highest-profile of those preclusions (systemd-as-pid1 taking over cgroup 
management) is due to decisions by kernel developers.

But other than that, I'm not aware of anything in systemd itself that 
precludes use of alternative compoments.  (Now your linux distro might 
not bother to support alternatives in any sort of integrated manner, but 
just look at Debian for the amount of pain trying to support 
"everything" will inevitably cause...)

But yes, I think I agree with you, though I believe the actual scope of 
preclusion is far smaller than what you think it is :)

> I understand the init system may not be the best solution for what is
> needed today. It meets my needs but it might not meet the needs of others.
> My own preference would have been for a new system that could stand
> alongside the existing and would let people move into it.

Speaking of Fedora here, the general end-user saw no difference pre- vs 
post-systemd, except perhaps faster bootup speeds.  What used to work 
still worked, and more stuff JustWorked(tm) automatically. That said, 
folks who tended to customize things found the transition rockier, 
depending on where they performed their customizations.

Systemd has been around for several years now, and even Fedora, the 
poster-child of systemd integration, migrated very slowly, only making 
use of the bits that they felt were useful, and retained compatibility 
with old config files/layouts/etc to this day.  Some of that 
compatibility is built into systemd (eg automatic support for /etc/fstab 
and classic /etc/init.d scripts with hooks in /etc/sysconfig) while 
other bits are fedora-specific.

It's unfortuate that there's no gradual migration path for the core 
systemd components, but.. those aren't something that are intended to be 
ripped out willy-nilly anyway.  If you changed something fundamental in 
the fedora core initscripts or bootup flow, you'd have likely ended up 
with an unbootable system.

But if you're trying to build your own distro, systemd's existance 
doesn't preclude anything else, and if anything gives you more choices 
than before.

 - Solomon
-- 
Solomon Peachy        		       pizza at shaftnet dot org
Delray Beach, FL                          ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum viditur.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 155 bytes
Desc: not available
URL: <http://mail.ale.org/pipermail/ale/attachments/20150918/eea990fa/attachment.sig>