[conspire] What's wrong with MEPIS

[Rick Moen]

Quoting David Fox (dfox94085 at gmail.com):

[Warren Woodford and MEPIS:]

> Who knows, but it's quite possible that Warren will be around for a
> while - but even if he is, running a distro that's basically one guy's
> idea of which packages should be culled from testing and which from
> unstable, and how often to release is going to be problematic.  But
> it's not without precedent.  Along with the two other distros
> mentioned, I believe PC Linux OS (also a very popular distro) is
> mainly maintained by someone called "TexStar" who, back when I ran
> Mandrake, and kept up with that distro's various releases (mostly
> following Cooker, analogous to Sid), his rpms were considered by many
> people to be worth using.

It's possible you didn't quite get my full meaning:  The problem is not
_just_ that Woodford's attempting to maintain and release the distribution
single-handedly, but also that he keeps making poor choices of
foundation for his distribution that are obviously going to be difficult
and arduous to maintain.  That is a very bad combination.  And there
have already been numerous signs that Woodford hasn't been keeping up.

Moreover, the likelihood of a distro going defunct isn't just an
imponderable risk borne by everyone equally; it's a serious problem
that's much more likely for some distros than others, and can be to some
degree foreseen.  I'll get back to that point.


Some years ago, I found out that my friend Michael E. Jennings was still
keeping alive the "Red Hat with VA Linux Enhancements" distribution (a
variant of RHL with meaningful QA) under the name "Vermillion", for
years and years after VA $WHATEVER had laid off him and nearly all the
other software engineers, in their (doomed) quest to convert themselves
to a proprietary Java house.[1]  Jennings was able to carry off this task
single-handed courtesy of (1) a nice little tool he'd developed called
Mezzanine, but also (2) care in deciding what battles were worth
fighting.  

Mind you, I hastened to introduce him to the CentOS guys, and get them
to join forces _there_ rather than Jennings continue to produce Yet
Another Obscure Red Hat Fork -- but the point is, the Vermillion project 
_was_ working.  

> But I (after some months) basically turned it in to a Debian (at that
> time, it was more or less a mixture of then-testing and then-unstable,
> with a few extra packages thrown in) through a series of upgrades.

Well, all I can say it, that does _not_ match what the MEPIS
announcements archive at distrowatch.org claims that Woodford's packaging
policy is (or has been).  What I posted earlier is what the maintainer's 
own words claim has applied, including the changes over time that I
listed.

> But that left me still running a mixed system, which from a Debian
> perspective, is really not a good thing to do. So I opted to go with
> straight testing (this was testing before Etch went stable) and just
> rode that branch, which I still do.

There are a lot of misconceptions on this matter.  Many people think
that a mixed testing/unstable system is "not a good thing to do"; but,
it _is_ a good thing.  Others persist in the calamitous error of
thinking adding "testing" sources.list lines to a "stable" system is a
good idea; it is in fact a really bad one.

Those points aside, which I'll return to in a moment, you've basically
converged your MEPIS system onto Debian-testing -- which is fine, except
that it's no longer really going to be a MEPIS system at that point, and 
also all the odd little cherry-picked inclusions Woodford threw into the
mix from various odd corners of multiple Debian tracks' sundry source
and binary packages (and Ubuntu packages before that) are very likely to
cause you bobbles before everything smooths out.

Anyhow, about the Debian (functional-name) development tracks:  I have
an ASCII-graphical metaphor I tend to fall back on -- with the problem
that the metaphor breaks down in a number of places.  The metaphor has
you (your system) in figurative Wile E. Coyote guise at some horizontal
spot relative to a cliff edge.  Signs at several points from, and just
over, the cliff edge indicate Debian tracks.  The sheer drop to the
desert floor is, metaphorically, instability and system failure.
Distance further to the left is greater stability and reliability of the
constituent software versions packaged in each track at any given time:


stable                                     testing  unstable    experimental
-----------------------------------------------------------|
                                                           |
                                                           |
                                                           |

A system hypothetically nailed to "experimental" would be staring in
goggle-eyed cartoon-character panic through the theatrical fourth wall
at the audience, having just realised it was about to take a Wile E. Coyote
plunge -- because "experimental" is _not_ a functional distribution, but
rather a parking lot for potentially wacky stuff that's just not
guaranteed to work at all.  A system tied to "stable" is boringly
functional but way, way off from the cutting edge of available software
-- the latter of which is, at any given time, found near that dangerous
edge.

"testing" and "unstable" are right next to each other, which is no
accident and no exaggeration -- since testing _is_ just the unstable
branch's set of packages, net of a quality-quarantining script.  Thus,
they are highly compatible; you get negligible "version sheer" between
libs/packages by combining the two.

The main place the metaphor fails is when you move it forward through
time:  Unlike real cliffs that erode and fall back, this cliff grows out
to the right and solidifies, as newer software versions are tested,
bug-fixed, and harmonised with other software.  Metaphorical attendants
are therefore continuously picking up the "testing", "unstable", and
"experimental" signs and plunking them down further to the right, at
appropriate distances from the cutting edge (cliff).

A somewhat more lazy attendant moves the "stable" sign to the right only 
one a year on average -- or, at his worst, once in four years.  You
might refer to him as the Debian Release Manager.  ;->  That is, it
alone is a periodically (well, occasionally) released track; the others
are continuously rolling tracks.

>  And that seems to indicate that Warren is going back to the old model
>  of Mepis, which based packages from Debian testing/unstable rather
>  than Ubuntu - which is a minor point, and perhaps a moot one, since
>  Ubuntu packages are culled from Debian.

Again, this is _not_ what Woodford's announcements archived on
Distrowatch claim he's intending to do.  I'd have to go back and re-read
those announcements to get an accurate history, but I recall that _none_
of his various choices over time about what to use as his base made a
lot of sense from a cost/benefit and maintainability standpoint, given
that his aim was a stable but cutting-edge KDE live CD.

(At the risk of repeating myself, I have a lot more respect for Sidux,
in that area.)


Part of the problem, in these discussions, is that the general
experience of LUGs _and_ a decade's worth of bad and misleading distro
reviews predisposes people to judge distros almost solely by the
experience of installing them and by the immediate, surface-level
end-result of that installation.  However, for someone who actually
_uses_ Linux, as opposed to just installing it over and over, the OS
installer and immediate experiental aftermath are ephemera.

What one _really_ cares about is how liveable the system is and remains,
as you maintain and change and adjust it over time.  Does the system get
bug- and security-fixes in a timely manner without hassle or downtime?  
Does it smoothly upgrade, ditto?  Can it be incrementally expanded
without problems?  Does the distro have a credible future including
people willing and able to step in and keep it going?

About all that can be said for MEPIS in those areas is that you can
(usually) cut it over to Debian testing and/or unstable without _too_
many bobbles -- better than Knoppix in that area, but worse than, not
to put too fine a point on it, Sidux.


> a minor point, and perhaps a moot one, since Ubuntu packages are
> culled from Debian.

It's _very_ important to note that Ubuntu (binary) packages tend towards
strong binary-incompatibility with Debian (binary) ones -- something
Shuttleworth once wrote a widely-quoted blog piece about, and was
interviewed concerning.  The source packages are largely but not
infallibly compatible.  (Quite often, they're maintained by the same
people.)