Choose your side on the Linux divide

[Joel Rees]

On Sat, Aug 30, 2014 at 3:05 AM, AW <debian.list.tracker at 1024bits.com> wrote:
> On Sat, 30 Aug 2014 02:10:28 +0900
> Joel Rees <joel.rees at gmail.com> wrote:
>
>  > "think system"
>
> Off topic... on topic... and unthinking...
>
> systemd has already won.  Fork sysvinit or don't.  End of comment. Forever. For
> me... and leaving behind this useless mailing list -- too much spam.
>
> Take it as you like.  However, I'm out.  I need to attend to other things than
> responding to children.

For real.

I tried to send him something like the following off-list, but the
account has been deleted at 1024bits.com . That's too bad, and it
means I feel obligated to post this as a sort of open letter to people
who see themselves as technical advocates:

-------------------------------------------------------------------
To those who want to advocate systemd
(and those who advocate against should consider this, as well),

About your advocacy, you've picked the wrong thing to advocate.

There are good things to advocate.

Take, for instance, the argument of vi vs. emacs. That was a matter of
the facts that

  * some people work more easily with modal interfaces
  * and some work more readily with modeless,
  * and some peoplework more effectively with memorizing commands
    and options,
  * and some are more efficient with memorizing semi-mnemonic
    control-key combinations.

Emacs vs. vi was a good debate to use to get to know people by, although
MacWrite effectively won that war for most people.

Gnome vs. XFCE vs. fwm, etc.? That's a debate that is still live, and
still a valid topic to discuss preferences that go beyond reason on.

Needing to be able to check dependencies in boot order? That's a
given, no need to argue for or against it. But it's not a show-stopper bug,
and the present solutions all seem to be trying to do things that don't
lead to determinate solution.

The ways to check? That's a topic that should be open for discussion.
In fact, that is the topic that is central to the problem here. But Lennart
Poettering wants to control the conversation, and we can't talk about
approaches that could work.

And the problem still is not a show-stopper bug, because Android is
either a separate distro or a wrapper that should work on any distro,
and it is done all wrong relative to free and open engineering principles
(so much for Google's "Do no evil." mantra).

The existence of Android does not raise the importance of the daemon
interdependency bug any more than the LIMO blasphemy or any of the
other so-called phone-centric (but really power-hungry TELCO-centric)
OSses.

There is definitely no reason to emulate the control-all attitude of the
current crop of TELCO-wannabees. (Bell, as a corporation, sort of
understood the responsibility that comes with control, up until the
break-up.)

That's the primary problem with systemd. It is trying to control too much.
Not in any idealistic sense, but in a technical sense. The solutions to
the problems of control that have to be used when they try that all lead
to non-deterministic results.

And there is a way to handle the dependency graphs and the monitoring
problems and so forth, that use small, independent, replaceable parts
that work well and that can be restrained to deterministic execution paths
with a little care on the system administrator's part.

And there is no way to avoid requiring the system administrator or owner
of the machine to make some decisions, even though those decisions
can be helped along. Not helped by the pid 1 process, but helped external
tools that can run in userland.

People who want to advocate anything technical in the Linux community
need to have a good grasp of logic. That includes such things as
understanding the basic fallacies of argumentation, avoiding them, and
especially refraining from projecting your own errors of logic on others'
arguments.

Otherwise, your attempts to advocate turn themselves upside down and
you just end up poisoning the conversation. Not just poisoning the well,
but the entire conversation.

Common fallacies, for those who need pointers:

  * jumping to conclusions,
  * arguing by false hypothesis,
  * inferring false parallels,
  * inverting logical implications,
  * poisoning the well,
  * etc.

As for your topic of advocacy, choose well.

If you want to advocate systemd, do not follow the lead of the project
leaders. They argue logic against itself, hoping that their arrogance
will be mistaken for hubris. And they don't understand the real
processes that have made their baby the darling of RedHat, et. al.

Or if they have figured it out, they prefer the false logic of money to
the true pride of owning up to their mistakes. At least, I can't figure out
any other reason for some of the bad engineering and bad engineering
management I've seen in evidence here.

Speaking of which, they seem to prefer to have the conversation itself
poisoned. That is, they don't seem to care whether the means they use
to win their war have any good results at all. And they don't seem to
care who they use up and throw away in the process.

You may think you just want FOSS software that "works", for some
definition of works that hasn't worked very well for you in the past. You
may think there is some defense in a common cause, but there is no
defense in a bad cause.

Freedom is fine, but don't forget that freedom and responsibility
cannot be divorced. There's a lot more leeway to move than the
ideologues want us to believe, but the duality remains.

And any solution to a problem has to keep that balance.

About the almost-offer of a drink, thanks, but I'd refuse. I don't drink.

Drinking rarely solves any problems. It sometimes loosens a few bolts
that we get screwed down too tight to  let an important axle turn, or in
some similar ways helps us move away from something keeping us
from solving a problem, but there are better ways.

Drinking tends to loosen too many screws at once.

And there's no particular reason to stay away from debian-user, if you are
willing to take it a little easy on the advocacy, and try to do it in a way that
fosters conversation in directions that lead to solutions.
-------------------------------------------------------------------

--
Joel Rees

Computer storage is just fancy paper,
the CPU just a fancy pen.
All is text, flowing forever from the past into the future.
And the universe is not a context-free grammar, but an unrestricted one.