From: Po Lu <luangruo@yahoo.com>
To: Stefan Kangas <stefankangas@gmail.com>
Cc: ali_gnu2@emvision.com, emacs-devel@gnu.org
Subject: Re: Solaris dldump
Date: Mon, 19 Aug 2024 07:56:13 +0800 [thread overview]
Message-ID: <87h6bhgzc2.fsf@yahoo.com> (raw)
In-Reply-To: <CADwFkmka+NLiy_WY=BCx9CRjyFe8+uaCpRJ23qy+t3B_dN_Qiw@mail.gmail.com> (Stefan Kangas's message of "Sun, 18 Aug 2024 15:27:55 -0700")
Stefan Kangas <stefankangas@gmail.com> 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?
> This means that by the time we release Emacs 31, users will already be
> busy moving to Solaris 11
This is nonsense. It's impossible to upgrade installed Solaris 10
systems to Solaris 11, and being a robust system many users are content
to remain there till hell freezes over.
> If they aren't, they're fine on Emacs 30, or they can help us fix
> pdumper.
No one is ever "fine on" an outdated text editor. You agree that this
principle applies to operating systems, but when Emacs is in question,
the about-face comes very quickly.
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.
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 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.
next prev parent reply other threads:[~2024-08-18 23:56 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.39.1723910423.12184.emacs-devel@gnu.org>
2024-08-17 22:49 ` Emacs-devel Digest, Vol 246, Issue 17 ali_gnu2
2024-08-18 0:10 ` Po Lu
2024-08-18 0:19 ` Po Lu
2024-08-18 1:15 ` Solaris dldump (was: Pure space) ali_gnu2
2024-08-18 1:25 ` Solaris dldump Po Lu
2024-08-18 22:27 ` Stefan Kangas
2024-08-18 23:56 ` Po Lu [this message]
2024-08-19 11:18 ` Eli Zaretskii
2024-08-19 12:09 ` Po Lu
2024-08-19 12:50 ` Eli Zaretskii
2024-08-19 11:44 ` Pip Cet
2024-08-19 11:57 ` Po Lu
2024-08-19 12:10 ` Pip Cet
2024-08-19 12:55 ` Eli Zaretskii
2024-08-19 13:46 ` Pip Cet
2024-08-19 14:39 ` Eli Zaretskii
2024-08-19 15:26 ` Corwin Brust
2024-08-19 15:31 ` Corwin Brust
2024-08-19 20:51 ` Stefan Kangas
2024-08-19 20:35 ` Stefan Kangas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87h6bhgzc2.fsf@yahoo.com \
--to=luangruo@yahoo.com \
--cc=ali_gnu2@emvision.com \
--cc=emacs-devel@gnu.org \
--cc=stefankangas@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).