Re: Effectively criticizing decisions you disagree with in Debian
Let's say, for the sake of argument, that one of the developers
replied to me off-list something like the following, as if to help me
unpack some of what I wrote:
>
> On Mon, 22 Sep 2014, Joel Rees wrote:
> > What problem were you trying to solve when you decided there had to be a switch?
> >
> > -- you, as an individual, and you, the community of developers?
>
> The systemd position summarizes nicely why SysV isn't tenable:
In other words, you want me to accept the point of view of the systemd
developers?
> Sysvinit was never designed to cope with the dynamic/event-based
> architecture of the current Linux kernel. The only reason why we
> still use it today is the cost of a migration.
Dynamic/event-based?
Okay, that is a bug in the documentation. I suppose the solution is
for someone like me to write a yet another how-to describing a couple
of the easiest ways to handle "dynamic events" in a Unix-like system.
But such books already exist, probably better-written than I can
produce on a part-time/volunteer basis.
The real bug is that such how-tos and books have a limited
monetization potential.
Okay, that is kind of an overly concise explanation, so --
systemd, as a solution to this "problem" is a platform for
systemetizing one of the less flexible solutions to providing event
handling for people who want to use events (dynamically) without
understanding them.
Does that belong at pid 1?
I wouldn't mind a pared-down systemd (even without a name change)
sitting out there somewhere beyond pid 25 or so, as a
quick-and-easy-but-not-really-complete event framework for people who
really don't want to bother understanding events at even the most
basic level. And there would be no problem with using it there for,
say, a desktop environment, because desktop environments shouldn't
know about all the system events. That would be proper modularization,
where the current systemd is not.
I know I'm implicitly disparaging the current developers of certain
very prominent projects, let's ignore that for the moment. The current
developers are not the original ones.
No, I guess that leaves an incomplete response.
Any operating system that envisages itself as nothing but the
underpinnings of a desktop environment envisages itself as essentially
a replacement for the old ("Classic") Macintosh system. That's not a
step forward. A/UX was what, 1988 to 1995? If Apple had been willing
to release that for general users at the price they were then offering
the classic Macintosh, Microsoft would have died a quiet death, and
the world would have been spared some of the worst of the excesses of
the 1990s.
Okay, no, unless Apple had also been willing to go a lot farther with
the licensing program, of course Microsoft would have had a chance to
attract companies that didn't want to be subject to Apple's arcane
policies.
In full technical and historic context, the systemd position is, well,
lewd, untenable, and an insult to their audience.
Let me rephrase that one more time:
The various traditional init processes are nothing but event loops in
a pre-emptive multitasking environment. Events are inherently dynamic
if you treat them that way.
I will acknowledge that there are some things that we could do to
improve the current (sysv) init in debian.
* Get rid of run levels.
* Work with upstream for the various daemons to get everyone to use
more uniform methods for the most basic functions of starting,
stopping, and querying basic status. (Although it's not really that
bad at this point, thinking of runit.)
* Help projects that bring several daemons together to write small
daemons to manage their daemon groups. (No, we do not need cgroups to
do this, either. Just help people write good daemon manager daemons.)
* Maybe add some simple auxiliary daemons to provide quick-and-easy
events and paste-buffer type IPC for new projects that need basic
stuff to get started and don't want to take the time to learn it.
None of that requires anything like systemd, and, in fact, systemd
heads in the wrong direction. The only thing systemd gains here is
forcing the creation of daemon management tools that meet the systemd
paradigm. Whatever that paradigm happens to be today. (The paradigm
has to change, because daemons are not all made equal, and any single
paradigm is going to result in implementation bugs.)
Wait. Let me get that out of paranthesis: Daemons are not all created
equal. One single management paradigm is never going to be sufficient.
Anything like systemd that tries to provide a comprehensive management
framework is forever going to be refining itself in ways that break
things.
(I suppose the systemd contribution in regularizing daemon interfaces
might have some value, but that is not in systemd itself. It's a
side-effect, and, in some cases, it does have daemon being started and
stopped incorrectly.)
> Sysvinit is insufficient for desktops,
... ignoring the fact that gnome 2 worked pretty nicely, really, ...
> mostly because of missing
> features such as the D-Bus interfaces.
dbus. If we were on misc@openbsd.org, I'd say something really rude,
because in that group people say what they think. Here, I'll have to
be a little more explicit.
dbus is inter-process communication for people who really don't want
to be bothered by learning interprocess communication.
Yeah, we need more books and how-tos on interprocess communication.
Linux IPC could be improved, too, but dbus is not it.
dbus is (can't get around this, it's not an insult, it's an analysis)
like trying to force all interprocess communication through a
paste-buffer work-alike. Make a universal utility pole where everyone
hangs their notices. That means it needs its own permissions system
and other things that the dbus crew wanted the kernel folks to
provide, but the kernel folks knew better, of course, so (surprise,
suprise) systemd comes to the rescue.
systemd, cgroups, and dbus are a package. Not so much in the sense of
a debian package, rather in the sense of three components of a
social-engineering project. Get one in, and it needs the other, so of
course it has to come in, and then you have a functional group that
require each other and are each others' excuses. And they give the
impression of momentum, so busy project leaders think they can depend
on them.
> But the real problems arise
> on big server setups, where Debian is losing ground because of its
> antiquated init system.
Is debian really competing with someone here? If so, shouldn't someone
come forward and set up a debian enterprise corporation?
Who are the perceived competitors, anyway? Rad Hat? Canonical? IBM?
China? Oracle? Microsoft?
> On these systems, you need fine service
> management, process monitoring, reliable dependencies, complex
> device setups and proper event handling.
So it's not the init system, per se, but the lack of uniformity, and
the difficulty in making a pretty-face GUI for BOFH admins who are
scared of the shell and of the man command, so they can push buttons
and pretend to be working.
Sigh. I suppose I shouldn't leave that as it is, but, you see, I could
be working on one of the tools to provide the sort of mutual process
interface for daemons to talk to each other that would really solve
the problems that overworked sysadmins (not BOFH) are facing. Instead,
I'm trying to explain what I consider obvious to you and any other
developer willing to wade through this tirade.
> > I do hope you meant burgeoning there. ;-/
>
> No... I meant bludgeoning.
You do understand that the bludgeoning has been mutually exchanged?
Who was first? It doesn't matter. Administrators who see something
like systemd being pushed onto their systems tend to react violently
because their bottom line (that's their livelihood) is going to be
affected.
(I tried to post my concerns to Fedora's developers list. I admit, I
was even less coherent then than I am now. But I was quietly blocked
until they thought I had gone away and Lennart had a chance to work up
a reply that he thought made me look stupid. You can find the result
with a quick search on the Fedora developers's mail list, if you think
it's relevant.)
> > Why was that communication allowed to break down in the first place?
>
> No idea; people are humans, and this sort of things happens.
I'll tell you why.
There is a war over control of the Linux community, and people are stressed.
You guys are caught in the middle, sort of, and I sympathize. You are
generally volunteers, not formally trained in some aspects of computer
science, and not properly equipped to defend yourselves.
If you want to defend yourselves, you need to take the time (I know
you are busy, so am I.) to learn the relevant technology. Otherwise,
you are at the mercy of white-paper writers, and of ranting lunatics
like me.
--
Joel Rees
Computer storage is nothing more than fancy paper,
and the CPUs nothing more than fancy pens.
All is text, streaming from the past to the future
in patterns that some read for fate and others for fun.
Those who look for fate think they can manipulate fate
by manipulating that stream of text.
They make weapons of metal and semiconductor,
and weapons of grammar and vocabulary,
and fight for control.
Control of what?
To control oneself is to control the world, and why would one want a
weapon for that?
Reply to: