Re: [Gnu-arch-users] Re: Re: community spirit

[Thomas Lord]

    > From: Jacob Gorm Hansen <address@hidden>


    > But back to the problem with scripting languages in the base system, see
    > http://perlmonks.thepen.com/165833.html , about an effort to remove Perl
    > from FreeBSD, in order to save 20MB on the base install.

hehe.  that sounds like a fun exercise.

    > Five years ago, Perl was hot and everybody loved it, nobody would argue
    > against relying on it for a base system. Today, better structured
    > languages like Python and Ruby are taking over, and soon, nobody will
    > argue against relying on Python 'which everyone has installed anyway'.
    > People said the same thing about Java a few years back.

    > So five years from now when X is the new cool scripting language, some
    > poor guy will have to fight to remove python-dependencies everywhere,
    > and most likely we give up, so we end up relying bash, perl, python,
    > ruby, lua, php, mono, and probably a few more, to get anything running
    > at all.  Funny thing, inside the box there is still an Intel chip, so
    > all this is bloat sits there just for the memory of some programmer who
    > had read on Slashdot that language X was cool this year.

GNU/* system integrators (e.g., Debian, Red Hat, etc.) don't have much
of an impressive record in displaying what some of us would call
"taste" wrt to managing dependencies.  

20 years ago, it was a point of pride among unix folks how their
systems could be boostrapped from minimal core components and how,
even as these systems were extended with new functionality, the
dependency graph was kept light and simple.   Please, if you are
curious, go look at the oldest implementations (perferablly from old
BSD or SysV) of core utilities --- stunning exercises in simplicity,
every one of them.

The value of that good taste plays out over decades, not months or
years, and that is, I think, the root of the problem.  For example, my
BSD-based boxes are very valuable to me precisely because all the core
services are provided so cleanly and, frankly, based on so little
code.   In contrast, every time I've installed linux, I've quickly
found myself relying on a software stack of super-human proportions,
full of bugs.   Administering my BSD box today feels a lot like
administring a BSD box 15 years ago, althought the available range of
functionality has increased.   Administring a linux box is like
walking on thin-ice, by comparison.

And that's part of the problem --- that these distinctions in approach
play out over a decade or two rather than over a few months: a bad
designer of a popular linux distro can, pretty much, sustain his bad
designs for an amount of time which amounts to enough of his career
that he can retire.   There isn't, at the highest (check-signing)
levels, enough attention to whether or not the work of these designers
makes sense beyond the lifetime of their personal employment at a
particular corporation.   The PHB's, as a rule, are clueless about
software -- and that's sufficient explanation enough for the quality
of so much of what they produce.


    > The only clear winner here is Dell. And perhaps Microsoft, who can
    > afford to do proper software engineering.

Nah.   Projects like hackerlab and arch are irrefutable proof that
something has gone badly wrong with the engineering practices in the
(mostly commercial) GNU/Linux world.   It's noteworthy and should be
alarming to many that I have been able to do so much with so little
code.   It should be compared and contrasted with the results and
costs of results demonstrated by projects which are less concerned
with undisciplined dependencies (and other ugly habits).

So: I think that while, yes, if nothing changes, Dell and Microsoft
are the most likely winners --- at the same time, look at what's
happening here: we're talking about the issue, you and I, right here
right now.  That's cause for optimism.  Perhaps your own behavior will
change a little, perhaps mine will.  Perhaps other readers will begin
to learn a new attitude.

And what if we (or I) can produce the /next/ "big" thing?  Not just
arch but the next step beyond it, having in common mostly an attitude
towards software design?  I think that means the demonstration will
become both more convincing, and harder to ignore (because more users
will be demanding it).

In other words: that the "majority opposing faction" in software
design is f'ing up isn't the end of the world.  Ultimately, they can
wind up just making little more than a nice contrasting image against
which the "minority (ultimately) winning faction" can state their
case.

"Fucking right I'm replacing libc.",
-t