From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Solaris dldump Date: Mon, 19 Aug 2024 14:18:38 +0300 Message-ID: <86le0syd4h.fsf@gnu.org> References: <878qwuitbu.fsf@yahoo.com> <6b0199db-60e3-4a41-8481-414688db0e18@emvision.com> <87ttfihbbn.fsf@yahoo.com> <87h6bhgzc2.fsf@yahoo.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27126"; mail-complaints-to="usenet@ciao.gmane.io" Cc: stefankangas@gmail.com, ali_gnu2@emvision.com, emacs-devel@gnu.org To: Po Lu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Aug 19 13:19:35 2024 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1sg0QA-0006tg-Sd for ged-emacs-devel@m.gmane-mx.org; Mon, 19 Aug 2024 13:19:35 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sg0PM-0001tN-RK; Mon, 19 Aug 2024 07:18:44 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sg0PK-0001sv-BB for emacs-devel@gnu.org; Mon, 19 Aug 2024 07:18:42 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sg0PJ-0005dw-NN; Mon, 19 Aug 2024 07:18:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=AoorQopu/h5kj5izYtXx+Ao81T1Ac3uTgicPQjjKB98=; b=PR3jHGWoro8v +O0AN9+e4yTKwf1WAq1yKWrXBW+gjEzI+22OgTX/9Mt+kwoCeuybmO2O3XPvHOucv6raY7ylxYyuP eh+MJKUrm4V4RUpApDKEDUK2J5DX8BT+OAYgxZaj7CxJVHdph16Q9s9eyZ46lvRhILuCQZ0o1skKd edAvpLnfwVjwXmLFvMXysXgCkF36gPpH1SGtFDfgzsHTDR1+3lkgEUCPlBmYvYJC6ab0CxNS6uuJT kFX/1kjOb0jQDmOYEBfvg39d9f/sskfkd82L3DUNX/WCqfCzMODWhQOU2e2OIZgQgA3BQv9Um+Tog pm7EYIZePkvY73DFaAb9cw==; In-Reply-To: <87h6bhgzc2.fsf@yahoo.com> (message from Po Lu on Mon, 19 Aug 2024 07:56:13 +0800) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:322910 Archived-At: > From: Po Lu > Cc: ali_gnu2@emvision.com, emacs-devel@gnu.org > Date: Mon, 19 Aug 2024 07:56:13 +0800 > > Stefan Kangas writes: > > > Thank you for sharing your informed opinion. I also can't see why we > > should consider the 20 year old Solaris 10 a blocker for removing the > > unexec build in Emacs 31. > > > > For example, even according to current Oracle communications, it will > > reach EOL in around two years. > > "Even" implies that it will reach EOL sooner, but by all indications the > EOL date will be as stated, if it is not postponed any further, and > Oracle and related organizations will continue to support the operating > system at a reduced intensity indefinitely. Why do you suppose this is, > if otherwise than because the operating system is abundantly used? > > Fedora 40's remaining support period is shorter; should we not cease to > support it any longer, in view of the one or two crashes in the PGTK > configuration that can only be reproduced with the distribution > packages, and which continue to languish on the bug tracker? These aspects are almost unrelated to the issue at hand: we don't make our decisions of dropping support of some platform or feature because it is EOLed by its vendor or developers. Instead, we make our own decisions, and in general try not to drop any feature/platform if we don't have to. In this case, keeping the support of unexec longer becomes a maintenance burden (just look at the #ifdef mess it requires), and that is the reason why we think we should drop those platforms that don't currently support pdumper. The fact that all those platforms are either very old or have better alternatives is just a supporting consideration, not the main reason. > It's a waste of my time (and my organization's) that would be totally > needless if you were not so trigger-happy with old and proven features. We are very far from being "trigger-happy" in these matters. In fact, we are often accused in the opposite. E.g., Gnulib dropped support for some of these platforms long ago, and couldn't be convinced to reconsider, even when told that Emacs needs that continued support. So what you say above is completely uncalled-for and unfair. > It's a-ok to retain pure space to avoid burdening someone with very > hypothetical additional labor, but it's not possible to take a far less > radical measure to conserve my time. In any event, I promised to devote > some of it to this issue after Emacs 30 is released. If you intend to work on modifying the unexec code to not use pure space, don't waste your time: I will object to any serious development of the unexec code. The only way forward for the platforms that currently need unexec is to start using pdumper. > > If there is interest in that very old proprietary system, and there is > > some problem with using pdumper there, then users should report bugs and > > volunteers should step up to fix them. > > According to Microsoft, Windows XP reached EOL in 2014, and yet its > users are none the less inclined to the latest releases of Emacs (nor > has it been prevented from retaining 0.38% of Windows's aggregate market > share, in excess of Windows 8's 0.24): > > https://gs.statcounter.com/os-version-market-share/windows/desktop/worldwide. Once again, it is immaterial when a platform was EOLed. That is not the reason why we want to drop unexec.