Re: Skipping unexec via a big .elc file

[Eli Zaretskii]

> Cc: address@hidden, address@hidden
> From: Daniel Colascione <address@hidden>
> Date: Mon, 24 Oct 2016 09:17:14 -0700
> 
> > I very much disagree with this: the unexec maintenance situation is
> > actually so fragile that it could break at any moment, in the sense
> > that we could very easily get into having no people on board who know
> > enough about unexec to solve the next problem that will break it.  The
> > number of people who do know gets smaller and smaller with each year.
> > That is not healthy at all for the future of the project.
> 
> In both this discussion and the one about insdel, you've expressed the 
> sentiment that we need to optimize for a world in which very few people 
> have time to maintain Emacs internals. I have a more optimistic view: 
> people are generally good at figuring things out, and if learning about 
> unexec or other esoteric facilities is that prevents a developer from 
> porting Emacs to a new platform or fixing an important bug, that 
> developer will put time into learning about these mechanisms.

Even if you are right, such "figuring out" will take time, and will
delay Emacs development if not stall it.  With enough bad luck, we
could start people abandoning ship.  Like I said, Emacs already cannot
be built on a system with ASLR; how soon do you think this and similar
problems will be considered fatal flaws?

Yes, I'm a pessimist about these aspects of Emacs development.  My
reasons are what I see before my eyes almost every day: some problems
in Emacs are not touched until one of the few who know enough do it.
Look at the last installment of this saga, with ralloc-induced
problems: the same usual suspects are involved in solving it.  If all
of those few were run over by a bus, how fast these problems would be
identified and solved?  And this problem is by far simpler than the
unexec subtleties.  It's no accident that no one (perhaps except Paul)
is seriously working on the unexec replacement.  Why would you believe
that this could change in the future, when most our contributors lack
proficiency working on this level?

So yes, I think your optimism is misplaced.  But that doesn't matter,
because no solution for unexec that is not good enough,
performance-wise and otherwise, will be accepted by the crowd, no
matter how grave is the current situation.  So you should not be
worried about this.  What _is_ important, IMO, is that if and when we
do need to drop unexec, we will have _some_ solution, however
imperfect, to start with and get it up to speed.  Because whatever the
solution, making it happen is a lot of work, and we had better done
most of it by then.