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 m...@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? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAAr43iOQ41XeyLUiwF1P5wuJXWbbm=jsqucw+-7zbootrlt...@mail.gmail.com