From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Skipping unexec via a big .elc file Date: Mon, 24 Oct 2016 19:52:03 +0300 Message-ID: <83y41d3d1o.fsf@gnu.org> References: <87eg51ng4r.fsf_-_@users.sourceforge.net> <87k2djwumn.fsf@users.sourceforge.net> <83h98nidvd.fsf@gnu.org> <87eg3rvtsf.fsf@users.sourceforge.net> <83k2dihpm9.fsf@gnu.org> <8760p2wzgj.fsf@users.sourceforge.net> <838ttyhhzu.fsf@gnu.org> <871szqwu51.fsf@users.sourceforge.net> <831szqhbc2.fsf@gnu.org> <87d1itt79z.fsf_-_@users.sourceforge.net> <7baa18d4-2b09-caa8-005e-29008a383ad1@cs.ucla.edu> <83mvhwrgd5.fsf@gnu.org> <8539f38f-9a11-44c3-4de7-bb974c96206c@cs.ucla.edu> <8360ojpndr.fsf@gnu.org> <83shrnm0k1.fsf@gnu.org> <83insi5jy9.fsf@gnu.org> <83mvht50qb.fsf@gnu.org> <8c085c3e-361d-7d10-6f34-07c387eb3b43@dancol.org> <83a8dt4u3a.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1477329455 397 195.159.176.226 (24 Oct 2016 17:17:35 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 24 Oct 2016 17:17:35 +0000 (UTC) Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 24 19:17:31 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1byisF-0006w5-9y for ged-emacs-devel@m.gmane.org; Mon, 24 Oct 2016 19:17:23 +0200 Original-Received: from localhost ([::1]:48375 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1byisH-0007n6-Bw for ged-emacs-devel@m.gmane.org; Mon, 24 Oct 2016 13:17:25 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47689) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1byiTv-0007hE-Dy for emacs-devel@gnu.org; Mon, 24 Oct 2016 12:52:16 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1byiTr-0007o4-Dp for emacs-devel@gnu.org; Mon, 24 Oct 2016 12:52:15 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:52010) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1byiTr-0007np-A2; Mon, 24 Oct 2016 12:52:11 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3276 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1byiTp-0001fI-TU; Mon, 24 Oct 2016 12:52:11 -0400 In-reply-to: (message from Daniel Colascione on Mon, 24 Oct 2016 09:17:14 -0700) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:208731 Archived-At: > Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org > From: Daniel Colascione > 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.