Re: Release plans

[Alan Mackenzie]

Morning, Stephen!

On Mon, Aug 18, 2008 at 09:01:54AM +0900, Stephen J. Turnbull wrote:
> Alan Mackenzie writes:

>  > I wasn't talking about a scientific process for which evidence can
>  > be weighed up.

> Shouldn't you be?  Surely you know it is possible to quantify risk,
> and analyze it scientifically?

OK, but it is like the blowing up of a nuclear reactor, not a plane
crash.  You don't say "hey, no reactors of type XYZ have blown up,
therefore it's safe"; instead, you analyse the way it's made and run, and
probe for potential chains of failures.  With a plane crash, on the other
hand, you can say "a plane of type UVW only crashes every 100,000,000
flight hours, so you'll be OK.".

> Why do you ask that we on your nightmares, or Richard's, to guide
> policy?

I don't ask anyone to we on my nightmares.  ;-)  I think you missed a
word out.

[ .... ]

> Are you beginning to see how untenable your position is?

No.  It may well be that, after more rigorous analysis, loadable binaries
in Emacs might not be a problem.  But being wrong is a long way from
being untenable.

> In fact the only thing it has going for it is

>  > Richard is a master of nasty deviousness, so the fact that he sees a
>  > problem is reason in itself to take it seriously.  ;-)

> but that's genuinely ad hominem.

Yes, but it's not an a.h. attack.  It's an a.h. compliment.

>  > The essential point is that if an un-free Emacs became established
>  > through the mechanism of loading binary libraries, we could not
>  > easily reverse it.

> Huh?  All you have to do is write the patch and announce a release.
> Richard has done that before (the security patch a couple years ago).

"Huh?"?  Such a patch would do nothing to disestablish an established
un-free version.

> A couple of corrections:

>  > I think you said recently that there's an obscure patch around
>  > which

> The patch is to Emacs, and it's obscure only because it has been
> refused inclusion in Emacs with extreme firmness, so that its
> proponents gave up about five years ago.  In XEmacs 21.4 and later,
> it's as simple as ./configure --with-modules. ....

>  > That's very different from something being a core feature,
>  > encouraged by the prime maintainers.

> Well, in XEmacs, the module loader *is* a core feature encouraged by
> the maintainers.  It's not configured by default because demand is so
> far low.

Those two sentences seem to contradict eachother.  I can't find any
documentation for it in either of the manuals (XEmacs 21.4.17) or NEWS.
I even know it exists, and I've even got a solid search term ("loader"),
but I still can't find it.  That's hardly encouragement.

How much use has been made of this module loader in XEmacs?  What's it
been used for?

> In SXEmacs, FFI is configured by many users because packages
> are downloaded not by EFS as in XEmacs, but via a FFI interface to
> libcurl implemented entire in Lisp.

I've just had a look at the SXEmacs home page, having not previously been
aware of it.  I can't really see any reason for SXEmacs's existence.

-- 
Alan Mackenzie (Nuremberg, Germany).