The root problem with systemd (according to me, anyway).

I'm wasting too much time posting on this stuff, but I'm going to try to lay out my complaints against systemd and the way it has been induced into the Linux community.

This comes from an exchange on the debian lists, where a member of the community is asking people to help debug systemd in jessie before the release.

If I could afford the hardware to replace my netbook that is no longer portable, or even if my tablet were not locked down and legally driver-hidden, I would be dual booting and probing for bugs in my spare time between classes and while I'm on the train.
 
Not that I really have any spare time.
 
Someone asked me off-list if I were seeking absolution. I assume the question was relative to my claiming that I don't have the resources to help test.

And that seems to me to be an odd question. Why should I feel anything even approaching guilt or remorse for not wanting to jump onto this train?

But, really, why should I even want to test systemd?
That question still has not been sufficiently answered to justify Red Hat in their completely arbitrary decision to push their community (Fedora) onto this train.

I know that the fact that they did so puts the rest of the larger Linux community in an awkward position. That the debian developer community wouldn't try to find their way around pushing the entire debian community onto the same train is still a significant concern to me.

systemd is not just an init, and, as an init, it takes an architectural approach that is rather disruptive.

Disrupting the fluff end of a market is one thing, but this is not a superficial change like the ipod was in the consumer market. This goes deep to the core of the community of Linux users.

Arguments about whether the architectural changes will turn out to be justified in the end aside, the correct thing for any distribution with a broad user base should have been to make an internal fork, similar to the fork that is kfreebsd in the debian community.

Just dumping it into testing to be processed into the mainline was irresponsible behavior on the part of Red Hat management.

I know that in Fedora they have a policy of not doing forks like kfreebsd, but this was (and will continue to be) disruptive. So disruptive that, if they weren't willing to change policy and set up the separate test community infrastructure, they should have simply refused. They could have told Poettering and his friends, "No. We are not going to sponsor your shiny new vision of an OS, nor your plan to push a shim on top of Linux so you can slide Linux out and slip your re-implementation of VMS or Multics underneath."

You know, that's really not a bad idea, developing a way to get other OSses from a bit outside the Unix traditions underneath the userland applications that have sprung up around Linux. But proper engineering methods should be used in the process.

I personally think the burden should have been on the shoulders of the freedesktop.org group to set up their own distribution. And they should have accepted that burden and not been so anxious to obtain involuntary testers. And they should have been willing to listen to constructive criticism about the design of their software, even if it hurt a bit.

That was the sane way, and the friendly way. Lots of people have set up their own private spins of Linux. It's not that hard, just takes a weekend or two. There's even the Linux-from-Scratch group that will walk beginners through the steps, although we should assume Lennart Poettering, Kay Sievers, and their friends (Did they really call themselves a cabal or were they just being sarcastic?) would not need to be walked through it.

And this is really the core of the argument:

If Red Hat had been willing to do this up-front and set up a parallel distribution (maybe call it Fedora-d) where the engineering questions could be worked out and the shim they are calling an init could have been re-factored more freely when the inevitable design errors were discovered, there would have been grumbling and even a few flame wars. But there would have been nothing like the push-back we have now.

And debian would have been more at liberty to set up a debian-d similar to the way kfreebsd is set up.

And the engineering problems could have been solved with engineering solutions, not with politics.

So, why should I even want to test systemd, even though someone is attempting to push me onto that train?

If I just boot Debian Jessie, I would be testing systemd. Sure.

But I don't really know if I can boot it.

Available hardware? I have one notebook that I'm using for experimenting, an old thinkpad, 256MB total RAM, 32 bit processor, 20GB HD. It runs openbsd (XFCE) okay, although I'm still working out how to get one of the available IMEs to work. A five-year-old vine linux install was a little heavy, but it did work. It is is sitting on the borderline of the level recommended for Debian's current stable OS, Wheezy.

Is it going to be worth wasting the time to see if Jessie runs at all on that? Maybe, but I really don't want to wipe openbsd off of it to do so. I've got things I need to do with that.

Well, sure, it would be pushing systemd beyond certain limits, into functional regions where some of the bugs I expect will definitely show up, but would my bug reports get anything more than a "fix by upgrading hardware" response? Not from what I've seen so far.

One other option, I could load a stripped-down jessie on a 4G SD card and see how it runs on the old netbook with the broken screen, an almost reasonable processor, and 1G of RAM. But, again, wouldn't bug reports tend to get a "fix hardware" response?

It has been asserted time, and time again, on the debian list, that, if I am not finding bugs and reporting them, I'm at fault for the bugs that don't get fixed before the release.

If I add up the time it has taken for me to try to "comment" intelligently, and the time it will most likely continue to take, it would in fact be easier and take less time to just borrow the money to get a new netbook and start digging out the more serious flaws in systemd in my spare time, reporting them to the systemd community, and posting them elsewhere where they will be seen when the systemd community is too arrogant to deal with them (as they have been known to be in the past, see the systemd mailing list).

But why, exactly, is it supposed to be my responsibility to contribute, when I fundamentally disagree with the direction being taken?

There are some who say that, if systemd is as bad as I and others are guessing, the defects will be made obvious through testing in as many configurations as possible. And if the design itself is fatally flawed, fixing the bugs that are found should not be trivial.

(Many of the bugs so far have not been trivial. No surprise there.)

But, remember, that's what many of us said or thought about MS-DOS, and then about MS-Windows. That is precisely the attitude that allowed Microsoft to get its de-facto monopoly.

I am not saying testing is unnecessary to prove that systemd is fatally flawed, what I'm saying is, if you are not willing to look at and deal with the flaws, testing will not help.

Okay, for those who think you are not technically inclined, who have gotten to this point anyway, how do you learn how to find the flaws?

Learn how to program. 

Don't learn from Microsoft. They'll just teach you how to line up orders that you give to machines and people, as if giving orders and getting your way were all there is to programming.

(One of these days I'll get my Programming Is Fun sites up -- at present, on sourceforge.jp, and blogspot -- but right now there isn't much there.)

One of the primary things anyone should try to understand before trying to become involved with programming on a professional basis is that there are classes of problems for which programmed solutions are not appropriate, for both technical and ethical reasons, if not for reasons involving how we define ourselves as humans.