Re: Emacs vista build failures

[Alan Mackenzie <acm@muc.de>]

Hi, Lennart!

On Sun, Jul 13, 2008 at 11:48:43PM +0200, Lennart Borgman (gmail) wrote:
> Alan Mackenzie wrote:
> >For example, it took more than a day to get printing working (a
> >standard Linux-supported Samsung Laser printer on the parallel port).
> >It involved delving into the printing-HOWTO, and the kernel
> >documentation, enabling the port support, rebuilding the kernel,
> >struggling through the undocumented garbage that is (?was) CUPS,
> >discarding that for a documented printing system, selecting a printing
> >(formatting) driver by trial and error, .....

> >This was typical of most things - a long hard slog, fixing problem
> >after problem after problem, a typical problem taking between 2 and 6
> >hours to resolve.

> >And yes, at the end of that month GNU/Linux did indeed work
> >fantastically.

> From what you and others have written it looks like the weak point when
> installing GNU/Linux is the hardware.

Partly.  Partly it's the fragmentation of documentation.  Partly free
software authors are a long way behind proprietary companies in making
installation low-pain.  Very little free software is documented anywhere
near as well as Emacs.

> I wonder if this still is the case with Ubuntu?

I tried Ubuntu.  It's an arrogant and patronising distribution - they try
to pretend that there's no such thing as the root user, and they try to
stop you finding out.  They have their own idiosyncratic init program
with a fragmented, undocumented configuration system.  The response of my
request for this documentation was "hey, why don't _you_ contribute it?". 

Still, if you can cope with that sort of attitude, Ubuntu seems to work
relatively well.  However, it was business as usual (2 - 6 hours per
issue) when I got to installing framebuffer on my Ubuntu.  It took me ~2
hours to get my Emacs to find my site-start.el - Debian (and thus Ubuntu
too) puts a content-free site-start.el somewhere in /etc which blocks out
your own real one.  I keep meaning to complain about this.

> In that case, should not investigating hardware be something that is 
> done as earlier as possible in the installation process - with a 
> possibility for the user to just back off if the installation process 
> finds hardware it does not recognize.

Yes.  I think a bigger problem is that each distribution tries to
"encapsulate" the problem in its own way, but they end up just wrapping
the problem in yet one more layer of undocumented complexity.  Sometimes
I think it would be better if the instructions just said "fill in these
configuration files as follows, using your favourite text editor" rather
than obfuscating the process with layers of scripts and GUI
"friendliness".

> I think that such a scheme could make GNU/Linux reputation in this 
> regard much better.

Perhaps.  Maybe the problem is intractable, due to the intrinsic
complexity of GNU/Linux.  Maybe Alfred's distribution is OK.  It's
something I'd far rather not have to bother about - I'd much rather just
hack Emacs!

-- 
Alan Mackenzie (Nuremberg, Germany).