MESSAGE
| DATE | 2015-04-20 |
| FROM | Ruben Safir
|
| SUBJECT | Subject: [NYLXS - HANGOUT] sytemd crimes
|
http://www.troubleshooters.com/linux/init/manjaro_experiments.htm#is_that_all_there_is
Editorial: Is That All There Is?
So it's the afternoon of 12/29/2014. I'm putting the finishing touches on my Epoch Init System content. Between Epoch's simplicity and its excellent documentation, replacing your current init system with Epoch is a 2 hour job, no package manager necessary. And, using my runit documentation, replacing your current init with runit is probably a five hour job. Which brings up the obvious question:
Is that all there is?
The four month war on the Debian-User mailing list. The back and forth between press pundits. The alleged contract on Poettering's life and subsequent "Open Source is quite a sick place to be in" whine by Poettering. The shouts of "FUD" on LUG mailing lists and IRC channels every time someone discussed init system choice. All of this was solvable with less than a day's work by computer literate Linux users. When I finally found the solution, all I could think was:
Is that all there is?
Obviously, I need to take some responsibility for going over the top during the Debian-User systemd wars. Obviously, my fellow anti-systemd people need to take some responsibility too. However, I assign the lion's share of responsibility to the pro-systemd forces. Here's why...
Back in the spring, summer and fall of 2014, "just plain users" had little understanding of init systems. Why should they understand: Sysvinit had been a constant for ten years, sometimes augmented by Upstart, neither of which was especially controversial. To users, the init system was a black box that pretty much "just worked."
Now contemplate those who knew all about init systems:
The systemd developers
Red Hat
The "Debian Developers"
The Debian CTTE
If, before the 7/1/2014 escalation of the Debian-User systemd war, somebody from any of the preceding four entities had taken a couple days to write something like the document you're reading right now, the whole conflict would have been avoided. It took me over a month to do the research and experimentation to put this document together: Those guys had the init system knowledge to write this document pretty much in real time. Not only that, but a lot of those guys were paid for their Open Source work.
Such a document, written by such a paid, knowledgeable person, before July 1, 2014, would have given users an easy alternative to systemd on any distro. Most anti-systemd sentiment would have dissipated as users simply bolted a runit or Epoch init to their operating system, and went merrily on their way. If just one person from the "systemd cabal", Red Hat, or the Debian Developers, had written and publicized a page like this one in a timely fashion, they could have prevented the whole conflict.
But that's not their style.
They knew every technical fact on this page. They had the time and the money and the manpower to create and publicize this page, heck, a better page, in a timely manner, thus avoiding the four month conflict. They chose not to.
Instead, they spewed FUD contrary to the facts. They said the only init systems "ready for prime time" were systemd, Upstart and sysvinit, implying that the likes of runit, Epoch, s6, nosh, and OpenRC were rickety junk. That's nonsense. They said we needed parallel startup of services, so boot didn't take five minutes. For the vast majority of us, server and desktop alike, who were not booting up fifty services, that's nonsense. They flat out implied that were three classes of init systems: systemd, Upstart, and all the rest, as if runit, s6, nosh and Epoch have anything in common with the hopelessly opaque, inefficent and antiquated sysvinit. They said we needed more reliable init systems. How you can get more reliable than Epoch, or runit with very simple service dependency aware start scripts, is beyond me. Why the FUD? Why the FUD when the obvious impending result was civil war?
Why indeed? Think about it. What did they not want us to know?
Think about it long and hard. They knew the truth; they chose not to share it. In fact, they spread antitruths. You don't have to voice your opinion out loud: Nobody likes to be called a conspiracy theorist. Just think about it. What was their motive?
We're three days from 2015. The systemd wars are over, probably to everyone's delight. Like many wars, there's no clear winner. Red Hat succeeded in co-opting almost every distro, but spawned groups of technologists ready, willing and able to undo Red Hat's "technology". And Red Hat suffered serious damage to their brand, at least among many Linux users willing and able to use the command prompt and editors to do some light configuration, scripting, and maybe some coding.
Debian succeeded in making systemd the default init on their new Jessie version, and their "support" for other init systems is still being debated. But they lost developers, and they lost some great user talent, and I mean people who could code. Great talent lost to alternate distros, alternate inits, and even alternate operating systems.
Those of us not wanting systemd on our boxes obviously lost the war. We either became refugees living in FreeBSD and Gentoo land, or are busy building our own systemd-less Debian, or are creating ways to init with systems declared "not ready for prime time", but still using Red Hat's pet Udev, and soon to be using Red Hat's pet Wayland (we need to start gearing up for that battle right away).
But before the forces of systemd celebrate the vanquishment of the anti-systemd rebels, they should consider that we rebels are battle hardened, and we know far more about system software than 90% of the Linux populace knew pre-systemd. While they've been learning talking points, we've been learning tech. We're coding software and making documentation to make systemd optional. And we're a tad bit upset with the powers that be. We're strong, smart and motivated.
Concerning Devuan, #debianfork, the modular-debian mailing list, and the people currently reproducing the Manjaro Experiments, the systemd patriots have this to say:
Is that all there is?
It's exactly that kind of myopia that will lead to their downfall.
inotifywait -m -e CREATE,DELETE /dev/usb
So at about 3am the morning of December 31, 2014, a guy on the #debianfork IRC mentioned that the Debian Tech guys had limited the init selection to event driven inits.
Oops! I had forgotten that systemd and Upstart were event driven, rather than just good at handling process dependencies. I had to step back and think for a moment. And then I asked my usual question, "why?" I asked him why the Debian Tech guys felt event driven inits were necessary. The guy replied something to the effect "you want to be able to respond when someone plugs in a drive or the network changes."
Yeah, that's not just propaganda, it's the truth. Hoping there could be an alternative to ruling out good inits like runit and Epoch, I thought for a couple minutes. I understood the need, but is init the right place to put such event detection? Disgruntled, I just said that I'd rather poll dmesg every second than run an overly complex init. A couple guys agreed with me, and one of them stated he does a lot of polling.
Yes, polling is good enough for Steve Litt, and a minor polled operation once per second consumes negligible resources. But recommending polling is a tremendous propaganda victory for "the other side." I sat and thought of how such things could be interrupt driven.
And within a second, I remembered that Linux (and the Linux kernel alone) has a library that detects disk changes as interrupts. I had forgotten the name, had to websearch it. It's the inotify library. Twenty minutes I had this command watching my computer's USB system:
inotifywait -m -e CREATE,DELETE /dev/usb
When you run the preceding command, it prints /dev/usb/ CREATE hiddev1 every time I plugged in my USB mouse, and /dev/usb/ DELETE hiddev1 every time I unplugged it. The rest of the story doesn't take a lot of imagination...
I could pipe the inotifywait command into a program that, every time it gets "CREATE" on stdin, runs dmesg, parses its most recent output, and deduces the partitions on the newly plugged device. It can then write the device's information into a fifo going into a service which does the mounts.
Am I going to actually try to make this work? Doubtful, I don't need it at this point. Am I aware that I proved the concept of just one use case? Of course I am, but I did it in less than an hour, and I see no reason why this concept couldn't be used for anything one wants to be event driven. Do I agree it's a kludge because I'm duct taping together all these different processes instead of writing C code? That depends on which of the four definitions of "kludge" one subscribes to, but that doesn't matter: There's an inotify library, and most of what I just discussed could be done in C by a sufficiently motivated person who has the time.
I look at this whole thing, and see the following process:
FreeDesktop.Org, Redhat, or the systemd cabal put yet another complication into init.
Folks valuing simplicity object to the new addition.
The RedHatians say it's needed in order to achieve such and such.
A simplicity valuing person easily makes a solution to achieve such and such outside of init (and probably outside the kernel space too).
The Redhattians respond that the simple solution is just [insert negative characterization here].
Systemd fanboys parrot the negative characterization.
If the simple solution is documented halfway decently, the simplicity lovers start using it, and let others know that it works.
Lather, rinse, repeat.
You know what I think? I think the preceding process, iterated over time, will be the undoing of systemd and lead to a Renaissance in public participation in the coding, configuration and architecture of Linux. Because, in almost every case, there are many ways to accomplish something, and the kernel or init system is usually the wrong place to accomplish it.
So, one day when your curiosity is bigger than your workload, try the following command, plug and unplug USB devices, and contemplate the possibilities:
inotifywait -m -e CREATE,DELETE /dev/usb
The Four Definitions of Kludge
It's 8pm on 12/31/2014, and it's a little in doubt whether I'll finish this section before my wife and I go to a New Years party. But let me start, at least.
When somebody calls my solution a "kludge", I think that characterization means one of four things:
I fixed a symptom instead of the root cause.
I built something so rickety that a moderate use case change or environment change will break it.
My solution is functional but ugly.
My solution removes the justification for the software they wrote or are writing.
After I determine which of the four applies (and they're not necessarily mutually exclusive), I respond as follows:
I get in there and fix the root cause.
I find other software that does the job, or find ways to make my solution work without all sorts of nested ifs and other complications.
I know it's a matter of aesthetics, so I ask myself whether prettier would be worth the extra cost, and act accordingly.
I proudly wear the word "kludge" as a badge of honor.
Not all "kludges" are created equal.
Happy New Year
It's 2:10am on 1/1/2015. My wife and I just got back from our New Years Party. It was a great party, and everyone had fun.
Now I'd like to propose a toast to GNU/Linux users worldwide. Let's all raise our glasses and toast 2015: The year of simplicity and choice.
Happy New Year!
|
|
