Re: Preview: portable dumper

[Daniel Colascione <dancol@dancol.org>]

On Sun, Dec 04 2016, Eli Zaretskii wrote:
>> From: Richard Stallman <rms@gnu.org>
>> CC: kfogel@red-bean.com, emacs-devel@gnu.org
>> Date: Sat, 03 Dec 2016 16:28:58 -0500
>> 
>> You have explained a possible drawback of the portable dumper:
>> it could make maintenance more difficult some years from now.
>> 
>> No one can doubt that this is a possibility.  People do disagree about
>> how much of a problem it is likely to be.  Many of us don't expect it
>> will make a big difference.  You forecast that it could.
>
> Thank you for acknowledging that this is a possibility.  I was under
> the impression that my opponents didn't agree.

You're misinterpreting this "agreement". Nobody else agrees that a a
significant maintenance burden is likely.  This is how FUD starts.

>> But you've got to admit that it is uncertain.  We're all making
>> guesstimates about probabilities.
>
> IMO, dangerous outcomes should be taken seriously even if their
> probability is low, as long as it's non-zero.

The people who moved humanity forward were not the ones huddling in
caves afraid of the mammoths outside.

We're talking about software. Anything we do, we can undo.  (And please,
stop suggesting that we have some kind of duty to keep master absolutely
stable because someone, somewhere might make a master snapshot tarball
available for something.  Why do we even have releases?)

> "Taken seriously" means
> we should do something to try to avoid the danger.  That is what I'm
> trying to do: find a solution for the problem that will avoid the
> danger.

You keep saying that you'd prefer a "solution" that "avoids" the
"danger".  There *is* no solution that avoids the "danger" you've
highlighted, which is the mere addition of C code.  (No other free
software project views C code as a "danger" to be avoided at all costs.)

Your preferred approach, a magically faster lread, *will* *also*
*involve* *C* *code*.  It will *also* require knowledge of Lisp layout,
since what lread does is transform text into Lisp objects.  It will
*also* need touchups when we add new lisp objects.

The idea that your preferred fast lread (which, again, does not actually
exist) would be a fine, but that the portable dumper is a "danger" ---
it makes no sense.  Your arguments against the portable dumper apply
also to lread.

Please don't tell me that lread is qualitatively different because it's
existing functionality or something: you're talking about complex,
disruptive additions to lread code, and that these additions would go
into a C file that already exists instead of one that doesn't
is immaterial.

>> So if we install the portable dumper, please don't treat it as a
>> certain disaster.
>
> The "disaster" is not the installation of the dumper.  The disaster I
> alluded to would be not to try to find a solution that minimizes the
> above danger.  If we have tried our best and failed, then it's not a
> disaster, it's life: after all, we can only make the best use of the
> cards we've been dealt.

We've known about unexec problems for years and nobody's come up with a
workable alternative.  Please stop obstructing progress because you wish
it weren't so.  The biggest danger here is that you get your way, block
progress, and that we're stuck with unexec and fragile hacks for many
more years.