Re: Emacs vista build failures

[Thomas Lord]

re much discussion around the general theme of:

Alan Mackenzie wrote:
> 'Evening, Richard!
>
> On Mon, Jul 14, 2008 at 01:38:28PM -0400, Richard M Stallman wrote:
>   
> >     Richard, you're perhaps the brightest guy around, here.  How long
> >     did it take you to get your first GNU/Linux installation installed
> >     and _fully_ working (i.e. all peripherals, networking, X-Windows,
> >     email, web-browsing, ....  all satisfactory)?


All of user-space needs to be done over.

The root problem with install difficulties, network config difficulties,
and divergent opinions about how to lay out an emacs install is simply
that unix user space and unix "best" practices for source management
haven't much improved for almost two decades.   People are using
tools closely related to those meant to manage *one* or *fifteen* of
100,000 unix installs (way back when) to now manage 100s of
millions of installs, often enough 10s of millions
at a time.  Nobody has successfully bothered to revisit the
fundamentals.

The GNU project as originally conceived by some close to it
involved fairly radical surgery to rationalize the "complete system"
source tree and to rationalize user-space by homogenizing around
a lispish approach.    For example, what should a default "load path"
be?  Well, that's not just an Emacs question -- it's generic for many
apps (e.g., a C compiler).   It merits a generic solution which is then
adopted as a coding / configuration / & source management standard.

It is a failure of the GNU project and of the free software movement
that there is so much emphasis on monolithic distributions and binary
package distributions.   It is a failure of the GNU project and the free
software movement that one so often encounters distros that offer to
not install source trees and even offer to not install development
environments.  These developments systematically and by design
deprive users of incentive to actually *exercise* their software freedom
as individuals.   These developments encourage a *de facto* (even
if not licensing-based) ceding of software freedom to distribution
projects like Debian or any of the commercial distros.

It is a failure of the GNU project and the free software movement
that there is such a large technical gap between "upstream" projects
and installed systems that massive "distribution projects" (commercial
or Debian) need to exist in between.   *Vetting services* should
exist between upstream and end-users  -- not "distribution vendors".
Vetting services should be in the business of publishing links
to source and checksums, not binaries.

The most important thing in such a large effort as a complete system
is the standards:  standards for coding, for documentation, for
source code management, for configuration, build, install, patching and
rebuild/reinstall, and uninstall.   Have you noticed that these are exactly
the weak areas that cause nearly all of the friction people are 
kvetching about
in this thread?  (Some HW vendors keep secrets and that amplifies the
problem -- but they are not the root of the problem.)

Yes, some binaries are needed to bootstrap from a raw box running
a (hopefully free) BIOS but those should be minimal -- not the
state we see today where you pick your distro.   *My* mentor,
20 years ago, was having fun debating with his peers whether
the number of programs a set of bootstrap binaries required for
a complete unix was closer 10 or closer to 20.   Let's see, you'd
want /bin/sh, for sure.  and /usr/bin/cc.   There's "awk" and "make"
but maybe there's a sweeter spot that slices that a bit differently.....

And in that view a "package" was a version controlled source
bundle with facilities for patching and a very clean, flexible,
configure/build/install procedure that was *standardized*.  Not
at the anemic level of the "GNU Coding Standards" -- but, rather,
usefully standardized.  Where today we have factional camps around
RPM and other package systems -- those shouldn't be afterthought.
Where we have "autoconf" and friends -- those should be central, not
the obscure, resented power-grab of a few.

Instead, we neglected all that grunt work and thus gave rise
to Debian and all of the commercial vendors and all of the problems
those "mid-stream" players create as they dominate the entire economics
of our efforts to create software freedom.

So, now, as a result: we've "succeeded" to the extent that most GNU/Linux
users don't possess most of the source for what they run;  can't rebuild 
from
source; are "locked in" to one distribution vendor or another -- like RMS
hisself, apparently.   And all needlessly so because we failed to put 
forward
good standards for source code management for a couple of decades.

It's amazing, pathetic, and embarrassing to be associated with.


-t