Re: Devuan

Quoting Ivan Sergio Borgonovo ([email protected]):

> That's why I find valuable that the work made by devuan will get
> integrated into Debian and that's why I really don't think what happened
> can't be changed and deserve a flamewar.

Nor did it merit a fork, IMO.  But the freedom to fork is, of course,
the foundation of open source, so it's quintessentially their choice.
(I wrote a widely read essay about that in 1999:
http://linuxmafia.com/faq/Licensing_and_Law/forking.html )


> I agree with the shades of grey. But shades of grey don't come as 
> isolated spectral lines.

Quite.  I would never adopt local software maintenance work without good
cause or past the degree of involvement necessary, because Larry Wall is
my Jedi master (in the 'laziness is a virtue' area, anyway).

> In most of my time I'm not that different from Greg K-H's daughter, 
> sometimes I am.

Sure.

The key is, as I said, always to find what gives best results for least
ongoing effort.  In software, some local tweaks remain vastly more
fiddly than others.  Some are fix once, stays fixed thereafter.

> Most of the time is cheaper to be suboptimal and the cost of taking care 
> of small details to be optimal adds up.

But that leaves the ones that matter, that are important, and especially
those you can solve using mostly other people's work.

As I said, http://linuxmafia.com/faq/Debian/openrc-conversion.html owes
_so_ much to laziness on this part that I didn't even write the shell
instructions (the 'Recipe') that the page concerns:  I copied them, with
credit, from elsewhere and merely verified in a VM that they work as
intended.  All I did otherwise, up to that point, was (figuratively)
take dictation.

And, as Josef Grosch also confirmed, it works exactly as I said it does.
(I tested it.  Being an annoyingly consistent and literal-minded
Scandihoovian, when I say 'I tested it', that means 'I tested it.' ;-> )

Most of the _real_ work, such as it was, was documenting systemd-derived
dependency trees using apt-cache.  Which was more bureaucracy than
actual thinking -- and, once having been done and fed through my Python
script to turn that information into HTML, is done documentation:  Fix
once, stays fixed thereafter.

> The time to be Leonardo Da Vinci is over and there is no chance to 
> escape complexity.

To the contrary, improved system simplicity is the only hope.

I'm invoking here by reference my standard 'This is the Age of Snowden' 
speech.  Avoidable system complexity, not to mention core components with
huge code churn and unsettled software interfaces (all the
Freedesktop.org stuff we server sysadmins used to ignore because it was
just a desktop-computing nightmare for GNOME victims, e.g., PolKit,
udisks2, systemd-logind, and like that) are the enemy of security and
reliability -- and of deterministic behaviour and understanding one's
own systems.

You do not 'manage' that by crowdsourcing it.  

> If you get out of the herd and not enough people follow you, you're
> doomed.

Nope.

Let me tell you a story about mej (Michael E. Jennings).

We both worked at VA Linux Systems, but unlike me, mej is a real
software engineer.  Long before I was let go in the gradual collapse of
the firm, mej was laid off with pretty nearly the entire Software
Engineering department.

Several years later, I realised with some astonishment that one of the
crown jewels of VA Linux Systems, the firm's signature preload Linux
distribution, Red Hat with VA Linux Enhancements (dubbed RH-VALE) still
existed.  I think the last company release of RH-VALE, probably around
2002 or 2003, was loosely based on Red Hat Linux 8.0 or 9.0.  

Years and years later, mej was still maintaining and releasing new ISOs
of RH-VALE, which he'd renamed to Vermillion to avoid any trademark
problems.  He'd written a bit of software-management scaffolding (loose
metaphor because I don't know much about it) named Mezzanine that
semi-automated some of the patching and building process, he said -- and
he was doing 100% of the maintenance work by himself.

I got mej in touch with a friend named Greg Kurtzner (sp?) who was
maintaining a different RHL derivative for Lawrence Berkeley National
Lab, and said they needed to join forces.  I am reasonably certain that
that was part of the foundation (or at least rise to prominence) of
CentOS, thereafter, because that's what then emerged.

A little thing like throwing away udev on a Debian headless server (no
X11) and substituting mdev or a static /dev tree -- for example -- is 
so much less work that it's hardly worth mentioning by comparison, and 
'people following me' plus $2.25 will, as the old saying goes, get you a
ride on San Francisco Muni, i.e., isn't actually worth anything.



> Once upon a time "specialized" distribution had a larger share....

I come from a community that rejects appeals to the allegedly vital
importance of market share.  You may have heard of us.  We're called the
Linux community.  ;->



> Meanwhile I had an exchange of emails with nextime (Franco Lanza) who 
> said that some of the modification they made are percolating to upstream 
> (not Debian but up-upstream).
> He said the civil war is not completely over so they are not sending bug 
> reports to Debian, but I insisted it could be a good idea.
> He said the first Devuan stable will be in September and we will see if 
> this is going to help integration of the work they made in Debian.

That would be constructive. 

The whole forking thing seemed like gratuitous drama, really.  Just my
opinion.

-- 
Cheers,                                       "My opinions may have changed, 
Rick Moen                                     but not the fact that I'm right."
rick-IyCrq+X4Fdq2oZ/[email protected]                                       -- Ashleigh Brilliant
McQ! (4x80)