From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: [OFFTOPIC] Re: Represent NTP's origin time Date: Sat, 17 Apr 2021 12:54:59 -0400 Message-ID: References: <87o8efcqfh.fsf@Rainer.invalid> <8735vpyqir.fsf@Rainer.invalid> <20210417140951.GB726@tuxteam.de> <87tuo5x8od.fsf@Rainer.invalid> <20210417152736.GA3748@tuxteam.de> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1626"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Achim Gratz , emacs-devel@gnu.org To: Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Apr 17 19:02:12 2021 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 1lXoKi-0000Ly-Mu for ged-emacs-devel@m.gmane-mx.org; Sat, 17 Apr 2021 19:02:12 +0200 Original-Received: from localhost ([::1]:50096 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lXoKd-0004P5-4R for ged-emacs-devel@m.gmane-mx.org; Sat, 17 Apr 2021 13:02:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58986) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lXoDy-0002D3-Qn for emacs-devel@gnu.org; Sat, 17 Apr 2021 12:55:16 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:55360) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lXoDr-000355-NF for emacs-devel@gnu.org; Sat, 17 Apr 2021 12:55:10 -0400 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 957D280967; Sat, 17 Apr 2021 12:55:03 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id A54AA8055F; Sat, 17 Apr 2021 12:55:01 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1618678501; bh=GzjgUd7er7jZTlNa00+IHdfsylubv97PdqLncMqJk+c=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=pBQ/BKgvYZ6pFVKeXIOnIq1AqcKlWWabksiFZeCe6oosGmjgciZ2SpFzLk3PdOMoc 2poFvgSUq1wa/sUCPOHS8y6voQ+pfKgYuWU+VgHiaSYBx6l+JrjGpDZeZ85vbfNM39 t1EAz88uoPFB7eV501OY1Uj9fe0HZOf4gdZ/z1aHfLLumlxP5Uq6u+nwgvU/zCqE0r 1RvWfKL/pRiMGsi1yn8CkuRI2C7gz5dVGaVmDXWTGA/p/8LOjFjX11xa5tfYZcBRVS jqH+Ujm7NFJSiltPJP0zbyYr9xUX5s9CboiBkfcH80Zrg/EtFXVKOzYnjzLmNOXAkp 9VN+USFBMsxXQ== Original-Received: from alfajor (104-222-126-84.cpe.teksavvy.com [104.222.126.84]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 6B51B120210; Sat, 17 Apr 2021 12:55:01 -0400 (EDT) In-Reply-To: <20210417152736.GA3748@tuxteam.de> (tomas@tuxteam.de's message of "Sat, 17 Apr 2021 17:27:36 +0200") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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" Xref: news.gmane.io gmane.emacs.devel:268133 Archived-At: >> The support for 64bit time_t on 32bit platforms is quite old by now >> actually, but it hasn't seen as much uptake as initially envisioned for >> whatever reasons. So in effect those platforms have announced their EOL >> and you should move off them. IIUC the issue is that the ripple effects of the change are non-trivial: lots and lots of APIs include a time_t somewhere (where recompilation leads to an incompatible ABI). So changing time_t ends up requiring recompiling (or, from the users's PoV upgrading) lots and lots of packages, plus a lot of work to figure out which packages need recompiling and which don't. So the alternative of making a completely new port is not much worse (implies more recompilation, admittedly, but completely avoids the need to figure out which packages need recompilation). [ IIUC for i386 the plan for Debian is indeed to hope that the port will die before the 32bit limit becomes really unbearable. Not sure what will happen with the ports for smaller systems where the move from 32bit to 64bit is much younger (e.g. armhf). ] >> > The *BSDs and Linux (beyond kernel 5.6ish) do support 64 bit time_t >> > in their 32 bit variants: perhaps this is an orientation. >> I have no 32bit system left that can run a modern enough Linux kernel >> and doesn't also support 64bit, so once I update those will not be 32bit >> anymore. FWIW, I use an amd64 kernel with a i386 Debian install on most of my machines. > (I'd bet that Stefan's hardware is still 32 bit :) I do still own several machines with a 32bit-only CPU: - two armhf SBCs (both using the Allwinner A20 CPU) which I use as always-on servers. - my old Thinkpad X30, which I use as "PDF to VGA adapter" when I teach. - an old Thinkpad X60 which was supposed to replace the X30 but which I end up not using because the X30 still works well enough. - my DSL modem/router (running a `mips` port of OpenWRT; a rare big-endian machine ;-) - my smartphone - my tablet Admittedly, I don't use Debian on the last 3. I also own 3 more machines which had a 32bit-only CPU (Core Duo) originally but in which I retrofitted Core 2 Duos. I tried using an amd64 Debian install on those machines that are limited to 3GB of RAM and found that the increased memory pressure was sufficiently noticeable that I decided to stick to i386. > So basically it reduces to whether the Emacs project wants to > support 32 bit systems (currently, the answer seems to be "yes") Quite. > and what to do about time_t when yes. I don't think there's any need for Emacs to make any special effort in this respect. Stefan