From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: Skipping unexec via a big .elc file Date: Mon, 24 Oct 2016 09:17:14 -0700 Message-ID: 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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1477326875 14297 195.159.176.226 (24 Oct 2016 16:34:35 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 24 Oct 2016 16:34:35 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 24 18:34: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 1byiCS-0001RH-Lu for ged-emacs-devel@m.gmane.org; Mon, 24 Oct 2016 18:34:12 +0200 Original-Received: from localhost ([::1]:48064 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1byiCU-00082r-Ti for ged-emacs-devel@m.gmane.org; Mon, 24 Oct 2016 12:34:14 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58790) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1byhwC-00030o-Dl for emacs-devel@gnu.org; Mon, 24 Oct 2016 12:17:25 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1byhw9-0006cG-9X for emacs-devel@gnu.org; Mon, 24 Oct 2016 12:17:24 -0400 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:38194) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1byhw8-0006aw-TU; Mon, 24 Oct 2016 12:17:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject; bh=pMhfUNwBLzHExaGcsZAOQm9iPeHy4/WUB9zoEwVATf8=; b=L4fjWcAlAXvZMd0+gFp1lhcMZNWQFyc+yTSlI/0mYsZ/Jpenk52UzUAJDZbvqcIETIovweh7EMJwC20h/YV5VAhy5P0hSJyEvpaHUV6aBEJUmNYM1ByPUSxJoDWgK5o5Lu4AE7OTljOopw1JTpp6lfzVfiSqnTLXGwZPezwSC5gfceXd//ehC8oaJjxQ25M+2bcezzJVYzli6Lpss9rNfSwZRAPPZj/ZP959GmM21+SDyEJxH4/CCZIoFqhLYrIcJJnT6jMggwnPASDSw+pffZZlWjAUMueFvfUXLDN1nSU9ab4FA2pEIxwGjW0IKMGjSbcWVj/TXyJMJ9jbu9KrwA==; Original-Received: from c-73-97-199-232.hsd1.wa.comcast.net ([73.97.199.232] helo=[192.168.1.173]) by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1byhw6-0004YB-IE; Mon, 24 Oct 2016 09:17:18 -0700 In-Reply-To: <83a8dt4u3a.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2600:3c01::f03c:91ff:fedf:adf3 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:208704 Archived-At: On 10/24/2016 08:58 AM, Eli Zaretskii wrote: >> Cc: emacs-devel@gnu.org >> From: Daniel Colascione >> Date: Mon, 24 Oct 2016 07:45:17 -0700 >> >>> In any case, I don't think it's right to throw out this idea without >>> trying very hard to make it work, because the benefits are so clear. >> >> I'm worried that it'll be deemed to "work" at a level of performance >> much worse than what we have today. > > Why would you worry that it'll be accepted then more easily than it's > accepted now? The same arguments will be voiced in the future if the > solution's performance turns out to be insufficient. > >> I don't see the unexec maintenance situation being desperate enough >> that we need to accept a big performance loss. > > 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. That is, we *could* get into a situation where "no people on board [] know enough about unexec to solve the next problem", but that situation will resolve itself when people learn about unexec.