Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.devel > #107899 > unrolled thread
| Started by | Steve Langasek <vorlon@debian.org> |
|---|---|
| First post | 2023-05-17 06:20 +0200 |
| Last post | 2023-06-09 13:30 +0200 |
| Articles | 20 on this page of 144 — 52 participants |
Back to article view | Back to linux.debian.devel
64-bit time_t transition for 32-bit archs: a proposal Steve Langasek <vorlon@debian.org> - 2023-05-17 06:20 +0200
Re: 64-bit time_t transition for 32-bit archs: a proposal Russ Allbery <rra@debian.org> - 2023-05-17 06:40 +0200
Re: 64-bit time_t transition for 32-bit archs: a proposal YunQiang Su <wzssyqa@gmail.com> - 2023-05-17 07:50 +0200
Re: 64-bit time_t transition for 32-bit archs: a proposal Steve Langasek <vorlon@debian.org> - 2023-05-18 22:10 +0200
Re: 64-bit time_t transition for 32-bit archs: a proposal Florian Lohoff <f@zz.de> - 2023-05-22 10:30 +0200
Re: 64-bit time_t transition for 32-bit archs: a proposal Steve Langasek <vorlon@debian.org> - 2023-05-18 07:10 +0200
Re: 64-bit time_t transition for 32-bit archs: a proposal Marco d'Itri <md@Linux.IT> - 2023-05-18 12:10 +0200
Re: 64-bit time_t transition for 32-bit archs: a proposal Russ Allbery <rra@debian.org> - 2023-05-18 16:50 +0200
Re: 64-bit time_t transition for 32-bit archs: a proposal Wookey <wookey@wookware.org> - 2023-05-18 18:20 +0200
Re: 64-bit time_t transition for 32-bit archs: a proposal Olaf Titz <olaf@bigred.inka.de> - 2023-06-26 20:50 +0200
Re: 64-bit time_t transition for 32-bit archs: a proposal Russ Allbery <rra@debian.org> - 2023-05-18 16:50 +0200
Re: 64-bit time_t transition for 32-bit archs: a proposal Christoph Biedl <debian.axhn@manchmal.in-ulm.de> - 2023-05-18 21:20 +0200
Re: 64-bit time_t transition for 32-bit archs: a proposal Russ Allbery <rra@debian.org> - 2023-05-18 21:40 +0200
Re: 64-bit time_t transition for 32-bit archs: a proposal Helmut Grohne <helmut@subdivi.de> - 2023-05-17 11:40 +0200
Re: 64-bit time_t transition for 32-bit archs: a proposal Steve Langasek <vorlon@debian.org> - 2023-05-18 07:40 +0200
Re: 64-bit time_t transition for 32-bit archs: a proposal Helmut Grohne <helmut@subdivi.de> - 2023-05-28 21:20 +0200
Re: 64-bit time_t transition for 32-bit archs: a proposal Craig Small <csmall@debian.org> - 2023-05-17 14:30 +0200
Re: 64-bit time_t transition for 32-bit archs: a proposal Steve Langasek <vorlon@debian.org> - 2023-05-17 17:50 +0200
Re: 64-bit time_t transition for 32-bit archs: a proposal Guillem Jover <guillem@debian.org> - 2023-05-18 03:10 +0200
Re: 64-bit time_t transition for 32-bit archs: a proposal Steve Langasek <vorlon@debian.org> - 2023-05-18 21:10 +0200
Re: 64-bit time_t transition for 32-bit archs: a proposal Guillem Jover <guillem@debian.org> - 2023-05-19 05:40 +0200
i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal) Steve McIntyre <steve@einval.com> - 2023-05-19 13:50 +0200
Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal) Luca Boccassi <bluca@debian.org> - 2023-05-19 14:40 +0200
Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal) Steve McIntyre <steve@einval.com> - 2023-05-19 16:10 +0200
Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal) "G. Branden Robinson" <g.branden.robinson@gmail.com> - 2023-05-19 16:30 +0200
Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal) Colin Watson <cjwatson@debian.org> - 2023-05-19 16:40 +0200
Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal) "G. Branden Robinson" <g.branden.robinson@gmail.com> - 2023-05-19 17:10 +0200
Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal) Steve McIntyre <steve@einval.com> - 2023-05-19 19:40 +0200
Re: i386 in the future Ivan Shmakov <ivan@siamics.net> - 2023-05-25 13:30 +0200
Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal) Simon McVittie <smcv@debian.org> - 2023-05-19 17:40 +0200
Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal) Steve Langasek <vorlon@debian.org> - 2023-05-19 18:00 +0200
partial support for i386 (Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)) Michael Biebl <biebl@debian.org> - 2023-05-19 19:50 +0200
Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal) Jonathan Carter <jcc@debian.org> - 2023-05-22 12:30 +0200
Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal) Johannes Schauer Marin Rodrigues <josch@debian.org> - 2023-05-19 17:40 +0200
Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal) Steve Langasek <vorlon@debian.org> - 2023-05-19 18:00 +0200
Bug#1036358: release-notes: Debian 12 expected to be last release w/ installer for i386 Ansgar <ansgar@43-1.org> - 2023-05-19 17:40 +0200
Re: Bug#1036358: release-notes: Debian 12 expected to be last release w/ installer for i386 Michael Biebl <biebl@debian.org> - 2023-05-19 19:40 +0200
Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal) "Andrew M.A. Cater" <amacater@einval.com> - 2023-05-19 19:10 +0200
Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal) Cyril Brulebois <kibi@debian.org> - 2023-05-19 19:30 +0200
Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal) Michael Biebl <biebl@debian.org> - 2023-05-19 20:30 +0200
Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal) Steve McIntyre <steve@einval.com> - 2023-05-19 19:40 +0200
Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal) Bjørn Mork <bjorn@mork.no> - 2023-05-19 21:30 +0200
Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal) Ansgar <ansgar@43-1.org> - 2023-05-19 22:00 +0200
Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal) Bjørn Mork <bjorn@mork.no> - 2023-05-19 22:40 +0200
Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal) Cyril Brulebois <kibi@debian.org> - 2023-05-20 07:10 +0200
Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal) James Addison <jay@jp-hosting.net> - 2023-05-20 14:00 +0200
Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal) Diederik de Haas <didi.debian@cknow.org> - 2023-05-31 01:00 +0200
Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal) Steve Langasek <vorlon@debian.org> - 2023-05-31 06:00 +0200
Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal) John Goerzen <jgoerzen@complete.org> - 2023-05-31 14:40 +0200
Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal) Sven Hoexter <sven@stormbind.net> - 2023-05-31 16:20 +0200
Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal) Gunnar Wolf <gwolf@debian.org> - 2023-05-31 18:40 +0200
Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal) Wookey <wookey@wookware.org> - 2023-05-31 20:50 +0200
Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal) Ansgar <ansgar@43-1.org> - 2023-05-31 21:30 +0200
Re: Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal) Johannes Schauer Marin Rodrigues <josch@debian.org> - 2023-05-31 07:00 +0200
Re: Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal) James Addison <jay@jp-hosting.net> - 2023-05-31 10:30 +0200
Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal) Wouter Verhelst <wouter@debian.org> - 2023-05-31 12:50 +0200
Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal) Alexandre Detiste <alexandre.detiste@gmail.com> - 2023-05-31 13:10 +0200
Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal) Sven Hoexter <sven@stormbind.net> - 2023-05-31 16:10 +0200
Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal) Gunnar Wolf <gwolf@debian.org> - 2023-05-31 18:30 +0200
Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal) Diederik de Haas <didi.debian@cknow.org> - 2023-05-31 23:30 +0200
Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal) "Andrew M.A. Cater" <amacater@einval.com> - 2023-06-01 00:20 +0200
Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal) Adam Borowski <kilobyte@angband.pl> - 2023-06-01 15:20 +0200
Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal) nick black <dankamongmen@gmail.com> - 2023-06-02 19:00 +0200
Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal) Wouter Verhelst <wouter@debian.org> - 2023-06-02 21:10 +0200
Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal) Diederik de Haas <didi.debian@cknow.org> - 2023-06-02 23:40 +0200
Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal) Paul Wise <pabs@debian.org> - 2023-06-01 03:40 +0200
Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal) "Theodore Ts'o" <tytso@mit.edu> - 2023-06-01 14:20 +0200
Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal) Lisandro Damián Nicanor Pérez Meyer <perezmeyer@gmail.com> - 2023-06-08 02:20 +0200
Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal) Steve Langasek <vorlon@debian.org> - 2023-05-19 17:50 +0200
Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal) Steve McIntyre <steve@einval.com> - 2023-05-19 19:50 +0200
Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal) Guillem Jover <guillem@debian.org> - 2023-05-19 20:10 +0200
Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal) James Addison <jay@jp-hosting.net> - 2023-05-19 20:50 +0200
Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal) Ansgar <ansgar@43-1.org> - 2023-05-20 00:00 +0200
Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal) James Addison <jay@jp-hosting.net> - 2023-05-21 08:00 +0200
Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal) Roger Lynn <Roger@rilynn.me.uk> - 2023-05-26 01:30 +0200
Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal) James Addison <jay@jp-hosting.net> - 2023-05-26 06:50 +0200
Using i386 by mistake on 64-bit hardware [was Re: i386 in the future 32-bit archs: a proposal)] Josh Triplett <josh@joshtriplett.org> - 2023-05-20 09:20 +0200
Re: Using i386 by mistake on 64-bit hardware [was Re: i386 in the future 32-bit archs: a proposal)] Simon Richter <sjr@debian.org> - 2023-05-20 11:30 +0200
Re: Using i386 by mistake on 64-bit hardware [was Re: i386 in the future 32-bit archs: a proposal)] Adam Borowski <kilobyte@angband.pl> - 2023-05-20 18:50 +0200
Re: Using i386 by mistake on 64-bit hardware [was Re: i386 in the future 32-bit archs: a proposal)] Stephen Kitt <skitt@debian.org> - 2023-05-21 20:00 +0200
Re: Using i386 by mistake on 64-bit hardware [was Re: i386 in the future 32-bit archs: a proposal)] James Addison <jay@jp-hosting.net> - 2023-05-22 14:30 +0200
Re: i386 in the future Wookey <wookey@wookware.org> - 2023-05-20 05:30 +0200
Re: i386 in the future Ansgar <ansgar@43-1.org> - 2023-05-20 10:00 +0200
Re: 64-bit time_t transition for 32-bit archs: a proposal Steve Langasek <vorlon@debian.org> - 2023-05-23 03:20 +0200
Re: 64-bit time_t transition for 32-bit archs: a proposal Guillem Jover <guillem@debian.org> - 2023-06-08 04:10 +0200
Re: 64-bit time_t transition for 32-bit archs: a proposal Steve Langasek <vorlon@debian.org> - 2023-06-14 06:50 +0200
Re: 64-bit time_t transition for 32-bit archs: a proposal Guillem Jover <guillem@debian.org> - 2023-06-17 17:50 +0200
Re: 64-bit time_t transition for 32-bit archs: a proposal Steve Langasek <vorlon@debian.org> - 2023-05-18 08:40 +0200
Re: 64-bit time_t transition for 32-bit archs: a proposal Steve Langasek <vorlon@debian.org> - 2023-05-20 02:30 +0200
Re: 64-bit time_t transition for 32-bit archs: a proposal Wookey <wookey@wookware.org> - 2023-05-20 13:30 +0200
Re: 64-bit time_t transition for 32-bit archs: a proposal Andreas Metzler <ametzler@bebt.de> - 2023-05-20 17:50 +0200
Re: 64-bit time_t transition for 32-bit archs: a proposal Steve Langasek <vorlon@debian.org> - 2023-05-23 03:30 +0200
Re: 64-bit time_t transition for 32-bit archs: a proposal Steve Langasek <vorlon@debian.org> - 2023-05-23 03:30 +0200
Re: 64-bit time_t transition for 32-bit archs: a proposal Helmut Grohne <helmut@subdivi.de> - 2023-06-06 09:40 +0200
Re: 64-bit time_t transition for 32-bit archs: a proposal Simon McVittie <smcv@debian.org> - 2023-06-06 12:50 +0200
Re: 64-bit time_t transition for 32-bit archs: a proposal Luca Boccassi <bluca@debian.org> - 2023-06-06 13:10 +0200
Re: 64-bit time_t transition for 32-bit archs: a proposal Marco d'Itri <md@Linux.IT> - 2023-06-06 17:30 +0200
Re: 64-bit time_t transition for 32-bit archs: a proposal Gunnar Wolf <gwolf@debian.org> - 2023-06-06 20:30 +0200
Re: 64-bit time_t transition for 32-bit archs: a proposal Simon McVittie <smcv@debian.org> - 2023-06-06 21:50 +0200
Re: 64-bit time_t transition for 32-bit archs: a proposal Alexis Murzeau <amubtdx@gmail.com> - 2023-06-06 21:50 +0200
Re: 64-bit time_t transition for 32-bit archs: a proposal Simon McVittie <smcv@debian.org> - 2023-06-08 21:10 +0200
Re: 64-bit time_t transition for 32-bit archs: a proposal Paul Wise <pabs@debian.org> - 2023-06-07 06:40 +0200
Re: 64-bit time_t transition for 32-bit archs: a proposal Andreas Metzler <ametzler@bebt.de> - 2023-06-08 07:10 +0200
Re: 64-bit time_t transition for 32-bit archs: a proposal Simon McVittie <smcv@debian.org> - 2023-06-08 21:20 +0200
Re: 64-bit time_t transition for 32-bit archs: a proposal Paul Wise <pabs@debian.org> - 2023-06-08 07:40 +0200
Re: 64-bit time_t transition for 32-bit archs: a proposal Bastien ROUCARIES <roucaries.bastien@gmail.com> - 2023-06-08 08:40 +0200
Re: 64-bit time_t transition for 32-bit archs: a proposal Hakan Bayındır <hakan@bayindir.org> - 2023-06-08 10:50 +0200
Re: 64-bit time_t transition for 32-bit archs: a proposal Holger Levsen <holger@layer-acht.org> - 2023-06-08 11:00 +0200
Re: 64-bit time_t transition for 32-bit archs: a proposal Paul Wise <pabs@debian.org> - 2023-06-09 06:00 +0200
Re: 64-bit time_t transition for 32-bit archs: a proposal Holger Levsen <holger@layer-acht.org> - 2023-06-09 11:30 +0200
Re: 64-bit time_t transition for 32-bit archs: a proposal Ansgar <ansgar@43-1.org> - 2023-06-09 11:40 +0200
Re: 64-bit time_t transition for 32-bit archs: a proposal Bastian Blank <waldi@debian.org> - 2023-06-08 11:40 +0200
Re: 64-bit time_t transition for 32-bit archs: a proposal Simon McVittie <smcv@debian.org> - 2023-06-08 11:40 +0200
Re: 64-bit time_t transition for 32-bit archs: a proposal Gunnar Wolf <gwolf@debian.org> - 2023-06-08 17:10 +0200
Re: 64-bit time_t transition for 32-bit archs: a proposal nick black <dankamongmen@gmail.com> - 2023-06-09 01:30 +0200
Re: multiarch vs. multilib Simon McVittie <smcv@debian.org> - 2023-06-09 11:00 +0200
Re: multiarch vs. multilib nick black <dankamongmen@gmail.com> - 2023-06-11 10:00 +0200
Re: 64-bit time_t transition for 32-bit archs: a proposal Paul Wise <pabs@debian.org> - 2023-06-09 05:20 +0200
Re: 64-bit time_t transition for 32-bit archs: a proposal Simon McVittie <smcv@debian.org> - 2023-06-09 11:30 +0200
Re: 64-bit time_t transition for 32-bit archs: a proposal Paul Wise <pabs@debian.org> - 2023-06-09 06:30 +0200
Re: 64-bit time_t transition for 32-bit archs: a proposal Bastian Blank <waldi@debian.org> - 2023-06-09 08:00 +0200
Re: 64-bit time_t transition for 32-bit archs: a proposal Wookey <wookey@wookware.org> - 2023-07-05 18:30 +0200
Re: 64-bit time_t transition for 32-bit archs: a proposal Steve Langasek <vorlon@debian.org> - 2023-06-06 21:50 +0200
Re: 64-bit time_t transition for 32-bit archs: a proposal Paul Wise <pabs@debian.org> - 2023-06-07 06:40 +0200
Re: 64-bit time_t transition for 32-bit archs: a proposal Helmut Grohne <helmut@subdivi.de> - 2023-06-08 19:20 +0200
Re: 64-bit time_t transition for 32-bit archs: a proposal Holger Levsen <holger@layer-acht.org> - 2023-06-08 20:00 +0200
Re: 64-bit time_t transition for 32-bit archs: a proposal Steve Langasek <vorlon@debian.org> - 2023-06-08 21:00 +0200
Re: 64-bit time_t transition for 32-bit archs: a proposal Thorsten Glaser <tg@debian.org> - 2023-06-09 19:00 +0200
Re: 64-bit time_t transition for 32-bit archs: a proposal Aurelien Jarno <aurel32@debian.org> - 2023-06-26 21:40 +0200
Re: 64-bit time_t transition for 32-bit archs: a proposal James Addison <jay@jp-hosting.net> - 2023-06-27 10:20 +0200
Re: 64-bit time_t transition for 32-bit archs: a proposal Simon McVittie <smcv@debian.org> - 2023-07-06 11:40 +0200
Re: 64-bit time_t transition for 32-bit archs: a proposal Thorsten Glaser <tg@debian.org> - 2023-07-06 18:50 +0200
Re: 64-bit time_t transition for 32-bit archs: a proposal Simon McVittie <smcv@debian.org> - 2023-07-06 23:40 +0200
Re: 64-bit time_t transition for 32-bit archs: a proposal Thorsten Glaser <tg@debian.org> - 2023-07-07 01:40 +0200
Re: 64-bit time_t transition for 32-bit archs: a proposal Sam Hartman <hartmans@debian.org> - 2023-07-06 22:50 +0200
Re: 64-bit time_t transition for 32-bit archs: a proposal Paul Wise <pabs@debian.org> - 2023-06-07 06:40 +0200
Re: 64-bit time_t transition for 32-bit archs: a proposal Sune Vuorela <nospam@vuorela.dk> - 2023-06-07 09:30 +0200
Re: 64-bit time_t transition for 32-bit archs: a proposal "Peter Van Eynde" <pvaneynd@debian.org> - 2023-06-07 10:30 +0200
Re: 64-bit time_t transition for 32-bit archs: a proposal Simon McVittie <smcv@debian.org> - 2023-06-07 12:50 +0200
Re: 64-bit time_t transition for 32-bit archs: a proposal The Wanderer <wanderer@fastmail.fm> - 2023-06-07 13:10 +0200
Re: 64-bit time_t transition for 32-bit archs: a proposal Thorsten Glaser <tg@debian.org> - 2023-07-06 19:00 +0200
Re: 64-bit time_t transition for 32-bit archs: a proposal Steve Langasek <vorlon@debian.org> - 2023-07-06 19:20 +0200
[i386] adlibtracker2 and fp-units-i386 Ivan Shmakov <ivan@siamics.net> - 2023-06-07 15:40 +0200
Constructive contributions (was: Re: 64-bit time_t transition for 32-bit archs: a proposal) Jonathan Carter <jcc@debian.org> - 2023-06-09 13:30 +0200
Page 4 of 8 — ← Prev page 1 2 3 [4] 5 6 7 8 Next page →
| From | "Andrew M.A. Cater" <amacater@einval.com> |
|---|---|
| Date | 2023-06-01 00:20 +0200 |
| Subject | Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal) |
| Message-ID | <GBCkF-cMze-1@gated-at.bofh.it> |
| In reply to | #108069 |
On Wed, May 31, 2023 at 11:24:15PM +0200, Diederik de Haas wrote: > On Wed May 31, 2023 at 12:44 PM CEST, Wouter Verhelst wrote: > > On Wed, May 31, 2023 at 12:51:06AM +0200, Diederik de Haas wrote: > My point is: what about people who don't have the option to *buy* > anything (new or used), for financial, logistical or other reasons? > > I've been keeping an eye on developments in the upstream linux kernel > and saw there was a 'spring cleaning' (i.e. removal of old HW support). > Reading through the commit messages, I noticed 2 criteria for removal: > - Code has (effectively) been unmaintained for MANY years > - The maintainers have not seen any indication for several years that > ANYONE is actually using that hardware. > > I think those are very reasonable criteria. > In my initial reply I quoted someone who EXPLICITLY said there were > people who actually used those i386 devices. > > On the kernel team I've an actual valid argument why supporting i386 > hardware is *difficult* as they don't have the HW (themselves) to > reproduce an i386-specific issue or to test a potential fix for that. > > In the responses here, I've mostly seen the *assumption* that those old > devices must be power hungry. While I'm quite sure modern hardware is > more power *efficient*, that doesn't mean old hardware is thus power > hungry. > But most of all, I'm flabbergasted/annoyed that someone who made explicit and > clear what they need, namely keeping support for i386, a bunch of people feel > the need to respond like "Well, actually, you need this (other thing)". > I find that extremely condescending. > > Maybe it's an option to answer the ACTUAL question? > (and that answer could be 'no') > > > I don't think "but old hardware is still used" is a very good argument > > for keeping i386 around. > > I think that's actually an excellent reason. > > I've likely missed prior discussions around this subject, but I haven't > seen and can't think of the reasons why so many people seem so adament > to get rid of i386 ASAP. I think I raised this some months ago and was told that it was too late to make a decision to stop for bookworm but that this was something that should be decided early in a release cycle and not at the end when deciding which architectures wouldn't actually make the cut for release. It is already hard to test i386 on i686 hardware: as others have said, most of the tests would be on >> 10 year old hardware. It does become a law of diminishing returns: if i386 programs had to be pulled for security or unmaintainability reasons in the course of bookworm, nobody would be surprised. > > Assuming there are indeed valid reasons to get rid of i386, I think it > would be a far better plan to announce that **Trixie** will be the last > release that will support i386. No: announce it at the start of bookworm release and have the Trixie release team immediately drop it for Trixie - that way you have five years of support to transition off it. Otherwise, you've just added _another_ five years of lessening support to an architecture that won't have been produced for >15 years. > That way people who care about i386 have a full development cycle to > make i386 the best it can be for as long as they can still use that HW. > Maybe they can also make arrangements with CIP to designate the Trixie > kernel as a Super Long Term Support kernel release. > > But tackling on the release notes at the very last moment that Bookworm > will be the last supported release, seems not so 'nice' IMO. > As someone who owned and happily used an Asus eePC several years ago: very nice, silent - it also had a flash disk from the earliest days of flash disks. If the person who has them still has them all running in another five years, he will have got an excpetional lifespan out of them. There comes a time when ports and architectures have to die through lack of hardware or maintenance: we've seen that for alpha, varieties of mips and sparc, effectively, and the maintainers behind the Debian bsd ports have just suggested that it should end. The same arguments that I would now apply to the i386 port I'd also apply to early AMD64 hardware - whoever had my first machine with it, it should now be long gone as power inefficient beyond words and 15 years old. > Cheers, > Diederik With best wishes, as ever, Andy Cater
[toc] | [prev] | [next] | [standalone]
| From | Adam Borowski <kilobyte@angband.pl> |
|---|---|
| Date | 2023-06-01 15:20 +0200 |
| Subject | Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal) |
| Message-ID | <GBQnD-cVwN-1@gated-at.bofh.it> |
| In reply to | #108070 |
On Wed, May 31, 2023 at 10:10:56PM +0000, Andrew M.A. Cater wrote: > As someone who owned and happily used an Asus eePC several years ago: very > nice, silent - it also had a flash disk from the earliest days of flash disks. Instead of RasPis as suggested by many in this thread, I'd instead suggest whatever is the current model of Odroid-H2+: * x86 * no moving parts * either my meter is broken or it's 4.6W under full load (specs say 14W?!?) * fat i/o * 2×2.5Gbe > The same arguments that I would now apply to the i386 port I'd also > apply to early AMD64 hardware - whoever had my first machine with it, > it should now be long gone as power inefficient beyond words and > 15 years old. At that time the concept of a daily driver capable machine taking low power was in its infancy, they just can't come close to newer designs. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋⠀ An imaginary friend squared is a real enemy. ⠈⠳⣄⠀⠀⠀⠀
[toc] | [prev] | [next] | [standalone]
| From | nick black <dankamongmen@gmail.com> |
|---|---|
| Date | 2023-06-02 19:00 +0200 |
| Subject | Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal) |
| Message-ID | <GCgi5-dbkw-3@gated-at.bofh.it> |
| In reply to | #108078 |
[Multipart message — attachments visible in raw view] — view raw
Adam Borowski left as an exercise for the reader: > Instead of RasPis as suggested by many in this thread, I'd instead suggest > whatever is the current model of Odroid-H2+: I was intrigued, but https://ameridroid.com/products/odroid-h2 suggests it's been out of stock since 2021? -- nick black -=- https://www.nick-black.com to make an apple pie from scratch, you need first invent a universe.
[toc] | [prev] | [next] | [standalone]
| From | Wouter Verhelst <wouter@debian.org> |
|---|---|
| Date | 2023-06-02 21:10 +0200 |
| Subject | Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal) |
| Message-ID | <GCijU-dcJE-31@gated-at.bofh.it> |
| In reply to | #108069 |
On Wed, May 31, 2023 at 11:24:15PM +0200, Diederik de Haas wrote:
> On Wed May 31, 2023 at 12:44 PM CEST, Wouter Verhelst wrote:
[...]
> > 20+ year old machines are typically more power hungry, more expensive,
> > less performant, and less reliable than an up-to-date raspberry pi. If
> > you want to support people who can't afford shiny new hardware, I think
> > pointing them to raspberry pi-class hardware is a better idea than
[...]
> In the responses here, I've mostly seen the *assumption* that those old
> devices must be power hungry. While I'm quite sure modern hardware is
> more power *efficient*, that doesn't mean old hardware is thus power
> hungry.
> But most of all, I'm flabbergasted/annoyed that someone who made explicit and
> clear what they need, namely keeping support for i386, a bunch of people feel
> the need to respond like "Well, actually, you need this (other thing)".
> I find that extremely condescending.
That's actually a bit of a misrepresentation of what I said.
I do believe there are still people using i386 hardware. I know for a
fact that there are still people using m68k hardware, too.
My argument is that "it is still used" is an argument that, due to the
very fact that retrocomputing exists, will never be a wrong statement.
To name an extreme example, there exist a handful of apple I devices
that are in working order today, but nobody would reasonably suggest
that it is a platform that still matters today.
Since it is always possible to come up with an example of someone still
using some old piece of hardware, I therefore think that it is not a
very compelling argument, in and of itself.
I also specifically said that older systems *typically* require more
power for less performance (etc). Of course there are exceptions, but
those are much more rare than the more common case of 20 year old
desktop-class hardware.
As an ex contributor to the m68k port who was active on the port when
our buildd hosts were still running on actual m68k hardware, I can tell
you that 20 year old hardware is not reliable *at all*. I have forgotten
how many times we've had to scrounge for older hard drives to replace
ones that died, wiggle RAM modules around, or do various types of
insane hardware maintenance that on modern hardware just isn't
necessary (I ...<censored>... remember the one time where the one host
had to be moved because it was in a hot attic and the cooling system
had Opinions on having been run 24/7 for over a decade). As such, if
your choice is between a 20 year old piece of hardware or a brand new
one that has similar performance, your better choice is almost always
going to be the latter.
Note again how I said "almost always" here. Exceptions exist.
In my opinion, the question we should be asking ourselves is therefore
not "can we still find valid use cases for the port", because the answer
to that is always "yes" and therefore not interesting, but rather, "how
much effort will it cost us to keep the old port running".
Note that the answer to that very valid question will be influenced by
"who is interested in keeping the port available". If there is a strong
feeling that the i386 port needs to go, and there is a bunch of people
with the skills required and the interest in changing that, then there
is a fairly straightforward thing they can do to avoid the port being
binned. It requires you do lot of work, but "complain on -devel" is not
part of the job.
I was part of the team that kept doing the necessary work for years, and
we saved the port from being removed from Debian several times. If you
want to do the same for i386, the path is clear...
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
I will have a Tin-Actinium-Potassium mixture, thanks.
[toc] | [prev] | [next] | [standalone]
| From | Diederik de Haas <didi.debian@cknow.org> |
|---|---|
| Date | 2023-06-02 23:40 +0200 |
| Subject | Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal) |
| Message-ID | <GCkF3-ddYM-3@gated-at.bofh.it> |
| In reply to | #108083 |
[Multipart message — attachments visible in raw view] — view raw
On Friday, 2 June 2023 20:59:27 CEST Wouter Verhelst wrote: > "complain on -devel" is not part of the job That wasn't my intend, but I obviously horribly failed at that. Won't happen again o/
[toc] | [prev] | [next] | [standalone]
| From | Paul Wise <pabs@debian.org> |
|---|---|
| Date | 2023-06-01 03:40 +0200 |
| Subject | Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal) |
| Message-ID | <GBFsd-cOvD-3@gated-at.bofh.it> |
| In reply to | #108048 |
[Multipart message — attachments visible in raw view] — view raw
On Wed, 2023-05-31 at 00:51 +0200, Diederik de Haas wrote: > I would be VERY disappointed if Debian would abandon people who do NOT have > the means to just buy new equipment whenever they feel like it. There are Debian contributors who are in this position (although perhaps not with i386 hardware) and would likely appreciate hardware donations to upgrade to more modern hardware. At the same time we have contributors who regularly buy, stop using and discard old hardware. It would be great if our more fortunate contributors would be willing to donate hardware to less fortunate contributors and could register their available hardware on the wiki page for this. Perhaps this could be extended to users of i386 hardware too. https://wiki.debian.org/Hardware/Wanted#Donations -- bye, pabs https://wiki.debian.org/PaulWise
[toc] | [prev] | [next] | [standalone]
| From | "Theodore Ts'o" <tytso@mit.edu> |
|---|---|
| Date | 2023-06-01 14:20 +0200 |
| Subject | Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal) |
| Message-ID | <GBPrz-cUZc-3@gated-at.bofh.it> |
| In reply to | #108048 |
On Wed, May 31, 2023 at 12:51:06AM +0200, Diederik de Haas wrote: > > I would be VERY disappointed if Debian would abandon people who do NOT have > the means to just buy new equipment whenever they feel like it. Debian is a Do-ocracy. Which is to say, it's a volunteer project. People work on what they feel like working on. Trying to guilt-trip people into working on something because they *should* often doesn't work well. If you'd like to make sure that i386 isn't abandoned, why don't you roll up your sleeves, step forward, and volunteer to help? Cheers, - Ted
[toc] | [prev] | [next] | [standalone]
| From | Lisandro Damián Nicanor Pérez Meyer <perezmeyer@gmail.com> |
|---|---|
| Date | 2023-06-08 02:20 +0200 |
| Subject | Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal) |
| Message-ID | <GEbxD-eo7R-1@gated-at.bofh.it> |
| In reply to | #108048 |
Hi, late on the thread, but... On Tue, 30 May 2023 at 19:51, Diederik de Haas <didi.debian@cknow.org> wrote: > > [Please CC me in replies as I'm not subscribed to this list] > > I hope I'm not too late for this discussion ... > > Steve McIntyre <steve@einval.com> wrote: > > Luca Boccassi wrote: > > >On Fri, 19 May 2023 at 12:42, Steve McIntyre <steve@einval.com> wrote: > > >> I'm planning on stopping publishing installer images for i386 > > >> soon. Why? We should be strongly encouraging users to move away from > > >> If they're still running i386 *hardware*, then they should be replacing > > >> that hardware with more modern, more capable, more *efficient* stuff. > > >> > > >+1 for stopping publishing installers for i386, it has been mentioned > > >many times but it's always worth repeating: electricity costs to keep > > >running i386 hardware are already way higher than what it costs to buy > > >a cheap, low-power replacement like a raspberry pi, that also provides > > >better performance. > > > > Exactly. > > ... > > If people have strong opinions about that plan, let us know please. > > I have *strong* opinions about this. > > https://lists.debian.org/debian-kernel/2023/01/msg00372.html was a message/ > plea to not forget about supporting OLD systems. > > While it may be a no-brainer for a person with a $/€ 1000 a month residual > income to just buy new hardware whenever they feel like it, that is not the > case for everyone. > > To quote (a part) of that email: > > I happen to know of a few derivative projects that have been using > > Debian technology that have brought new life to some really aging equipment > > and some people in either Third World countries or in communities with low > > incomes and either limited or non-existent access to modern equipment. One > > such effort, the antiX distribution, has been effective in reaching poor > > communities in Brazil recently, and has long been able to reach people with > > scaled down Debian technology all over the world. > > > > I'm wondering if there is some way to provide a "hook" or a way for some of > > these ten to twenty year old systems to remain functional for those who may > > not otherwise have a way, other than to run insecure, out of date systems. > > If there is a way, even a "side project", I hope that the Debian community > > can help a few of these derivative distributions assist people worldwide to > > have access to modern technology, > > even from systems that are barely "modern" any more. > > Besides people in 'third world countries' (I actually don't like such > qualifications at all), there are also people in the '1st world' who work their > asses off just to put food on the table, and thus also don't have the money to > buy new equipment. But if you want to interact with your own government, you > highly likely will need to have some PC (type) equipment. > It could also provide a way to learn/develop new skills. > > It's absolutely true that modern machines are more energy efficient. What is > also true is that the production of new devices has a big environmental > impact. Well, I do consider myself someone living in a third world country, possibly already a four world by now. Some years ago I would have certainly totally concurred with your observation. Nowadays? No. amd64 systems are old enough that you can find them in old machines too. My PoV is that we reached the point at which we can safely say there are replacements. Ecologically it is better to refurbish old amd64 systems rather than trying to keep the i386 alive. My personal PoV, but... -- Lisandro Damián Nicanor Pérez Meyer https://perezmeyer.com.ar/
[toc] | [prev] | [next] | [standalone]
| From | Steve Langasek <vorlon@debian.org> |
|---|---|
| Date | 2023-05-19 17:50 +0200 |
| Subject | Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal) |
| Message-ID | <GxawF-a1fp-1@gated-at.bofh.it> |
| In reply to | #107939 |
[Multipart message — attachments visible in raw view] — view raw
On Fri, May 19, 2023 at 12:42:32PM +0100, Steve McIntyre wrote: > >If the main reason is to support non-free binaries, at least to me > >that does not seem like a very compelling reason. And people can > >always use old chroots or similar I guess? > i386 is in a really awkward situation here, I think. Nobody is working > on it explicitly any more (AFAICS?), but its history as by far the > most common architecture means that: > * we still have a (very!) long tail of installations using it > * there are *massively* more old binaries available for it, free, > proprietary *and* locally-built FTR this includes wine, and 30 years of 32-bit Windows executables that people want to be able to run, including games. (for which inaccurate times are not going to be hugely important, in general.) And some of those games are going to require e.g. library packages for 3d acceleration that are in sync with kernel drivers (nvidia). This was ultimately what made "just use an older version in a chroot/container" untenable for Ubuntu and led to keeping i386 as a partial port. So one may not think that support for legacy, proprietary programs is a compelling reason to keep binary-compatibility on i386. But I counter that unless you care about this, there's no reason to keep i386 as an architecture *at all*. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slangasek@ubuntu.com vorlon@debian.org
[toc] | [prev] | [next] | [standalone]
| From | Steve McIntyre <steve@einval.com> |
|---|---|
| Date | 2023-05-19 19:50 +0200 |
| Subject | Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal) |
| Message-ID | <GxcoN-a2mr-3@gated-at.bofh.it> |
| In reply to | #107948 |
Steve Langasek wrote:
>
>On Fri, May 19, 2023 at 12:42:32PM +0100, Steve McIntyre wrote:
>> >If the main reason is to support non-free binaries, at least to me
>> >that does not seem like a very compelling reason. And people can
>> >always use old chroots or similar I guess?
>
>> i386 is in a really awkward situation here, I think. Nobody is working
>> on it explicitly any more (AFAICS?), but its history as by far the
>> most common architecture means that:
>
>> * we still have a (very!) long tail of installations using it
>> * there are *massively* more old binaries available for it, free,
>> proprietary *and* locally-built
>
>FTR this includes wine, and 30 years of 32-bit Windows executables that
>people want to be able to run, including games. (for which inaccurate times
>are not going to be hugely important, in general.) And some of those games
>are going to require e.g. library packages for 3d acceleration that are in
>sync with kernel drivers (nvidia). This was ultimately what made "just use
>an older version in a chroot/container" untenable for Ubuntu and led to
>keeping i386 as a partial port.
ACK!
>So one may not think that support for legacy, proprietary programs is a
>compelling reason to keep binary-compatibility on i386. But I counter that
>unless you care about this, there's no reason to keep i386 as an
>architecture *at all*.
That's exactly my reasoning, yup!
--
Steve McIntyre, Cambridge, UK. steve@einval.com
< sladen> I actually stayed in a hotel and arrived to find a post-it
note stuck to the mini-bar saying "Paul: This fridge and
fittings are the correct way around and do not need altering"
[toc] | [prev] | [next] | [standalone]
| From | Guillem Jover <guillem@debian.org> |
|---|---|
| Date | 2023-05-19 20:10 +0200 |
| Subject | Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal) |
| Message-ID | <GxcI9-a2Ix-23@gated-at.bofh.it> |
| In reply to | #107939 |
Hi!
On Fri, 2023-05-19 at 12:42:32 +0100, Steve McIntyre wrote:
> Guillem Jover wrote:
> >On Thu, 2023-05-18 at 12:01:40 -0700, Steve Langasek wrote:
> >> > […], I'm also dubious about this, and introduces a special case
> >> > and complexity that does not seem warranted TBH. If this was the case it
> >> > would seem to me it would disallow SOVERSION bumps for example, which we
> >> > have never been concerned with.
Err, sorry the SOVERSION example does not make sense here, precisely
because in those cases the dependency system works for the user and
(in general) should let the old versions of those shared libraries
even if now obsolete packages be co-installed along the new versions.
> >The problem with obsolete packages is also shared by all other arches,
> >and for those and for local packages the dependency system works for
> >the user and should let them know whether they can upgrade or they
> >would need to remove such packages. For other local FOSS packages
> >they might just be able to rebuild them.
> >
> >Excluding i386 from this transition seems to me will pretty much
> >sentence it, and would also make it rather hard to perform that
> >transition cleanly going forward if people want to keep it alive. And
> >while Debian might eventually remove it from its official ports, we
> >have multiple old ports that are still maintained and used.
> >
> >If the main reason is to support non-free binaries, at least to me
> >that does not seem like a very compelling reason. And people can
> >always use old chroots or similar I guess?
>
> i386 is in a really awkward situation here, I think. Nobody is working
> on it explicitly any more (AFAICS?),
I assume because it seems to "work" and people might have not seen the
need to jump in, compared to say if it was in ports.d.o, but I might be
wrong.
> but its history as by far the
> most common architecture means that:
>
> * we still have a (very!) long tail of installations using it
> * there are *massively* more old binaries available for it, free,
> proprietary *and* locally-built
>
> Moving forwards, we need to make a call on what we want i386 for. I
> was hoping to wait until after bookworm is released to have the meat
> of that discussion, but...
> […]
> As and when we switch i386 to a secondary status like this (however we
> label it!), then I think we should *only* consider it as a
> compatibility layer for older software. People *could* just use old
> chroots or similar, but the need is likely to be around for a
> while.
> There's a tension here: I think it's important to keep the old ABI
> around for those old binaries, and I genuinely don't see a use case
> for a new incompatible ABI on a mostly-dead architecture that won't
> support those binaries. *But* I think we'll also need to keep the port
> going with security fixes - it's still likely to be quite common and
> we need to keep users safe.
> People are even likely to want to keep old software running beyond
> 2038, in which case I envisage clock hacks coming to keep things
> limping on. :-/
So I guess my concern is three fold:
a) There's the part that I mentioned where excluding it means it is
destined to die in exchange for that backwards binary compat,
although it's not clear for how long this all will be supported
by Debian (and where I consider I've registered my concern here,
but if people in general think the backwards compat trumps other
stuff I'm fine with that).
b) I still keep at least one 32-bit Athlon system around mostly to
be able to support 3Dfx hardware, which I'll have to stop
supporting either when the machine, the port or time dies. OTOH
I've been pondering stopping the support in the future anyway so
it's not such a great concern for me.
c) And then there's the port support long term in dpkg, where my
expectation is that when and if Debian does not officially support
it, people that might still want to use that port on vintage
hardware will most probably request to flip the switch, and then
me and/or the ports.d.o maintainers might need to decide between
users that have expected such backwards compat and porters that
might want to be able to continue using the port. :/
(I also keep that Athlon around as I need to recover data from a bunch
of 3.5" floppy disks! But that should stop being relevant once I sit down
through the drudge of changing the piles of disks every few minutes. :)
Thanks,
Guillem
[toc] | [prev] | [next] | [standalone]
| From | James Addison <jay@jp-hosting.net> |
|---|---|
| Date | 2023-05-19 20:50 +0200 |
| Subject | Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal) |
| Message-ID | <GxdkR-a2XU-5@gated-at.bofh.it> |
| In reply to | #107939 |
On Fri, 19 May 2023 at 12:42, Steve McIntyre <steve@einval.com> wrote: > > I'm planning on stopping publishing installer images for i386 > soon. Why? We should be strongly encouraging users to move away from > it as a main architecture. If they're still installing i386 on 64-bit > hardware, then that's a horrible mistake. If they're still running > i386 *hardware*, then they should be replacing that hardware with more > modern, more capable, more *efficient* stuff. Do we know how often the i386 installer is downloaded compared to amd64, and could/should we start with updated messaging where those are provided before removing users' ability to install on their systems? (i386 remains the second-most-popular architecture behind amd64 today going by popcon[1] stats - perhaps a lot of that is people using i386 as a compatibility architecture only, but it'd be nice to be reasonably confident about that) [1] - https://popcon.debian.org/
[toc] | [prev] | [next] | [standalone]
| From | Ansgar <ansgar@43-1.org> |
|---|---|
| Date | 2023-05-20 00:00 +0200 |
| Subject | Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal) |
| Message-ID | <GxgiJ-a4FE-1@gated-at.bofh.it> |
| In reply to | #107960 |
On Fri, 2023-05-19 at 19:40 +0100, James Addison wrote: > Do we know how often the i386 installer is downloaded compared to > amd64, and could/should we start with updated messaging where those > are provided before removing users' ability to install on their > systems? > > (i386 remains the second-most-popular architecture behind amd64 today > going by popcon[1] stats - perhaps a lot of that is people using i386 > as a compatibility architecture only, but it'd be nice to be > reasonably confident about that) One of the problems with popcon is that it draws too much attention to old releases which isn't really interesting when talking about future developments. If one looks at arch usage per release (as reported to popcon) one gets this table: | Architecture | jessie | stretch | buster | bullseye | bookworm/sid | |----------------+--------+---------+--------+----------+--------------| | alpha | 1 | | | | 4 | | amd64 | 9090 | 17156 | 41137 | 108145 | 14800 | | arm64 | | 1 | 93 | 937 | 203 | | armel | 21 | 47 | 67 | 68 | 10 | | armhf | 7 | 18 | 216 | 429 | 49 | | hppa | | | | | 8 | | hurd-i386 | | | | 4 | 6 | | i386 | 1318 | 1231 | 1495 | 3042 | 168 | | ia64 | | | | | 3 | | kfreebsd-amd64 | 2 | | | | | | m68k | | 1 | | | 4 | | mips | 2 | | 6 | | | | mips64el | | | 6 | 4 | | | mipsel | 2 | 1 | 7 | | | | powerpc | 13 | 1 | 1 | 1 | 18 | | ppc64 | | | | 1 | 28 | | ppc64el | | 5 | 16 | | 12 | | riscv64 | | | | | 15 | | s390x | | | | 8 | 3 | | sh4 | | | | | 1 | | sparc64 | | | | | 11 | | x32 | | | | | 2 | |----------------+--------+---------+--------+----------+--------------| | ∑ | 10456 | 18461 | 43044 | 112639 | 15345 | #+TBLFM: @>$2..@>$>=vsum(@I..II) where i386 has dropped from 13% to 7% to 3% to 3% and finally to 1%. Also interesting is that arm64 has taken over i386 on bookwork/sid. We don't know how many people downloaded i386 instead of amd64 as they have an Intel CPU. What is also not clear is the bias of systems having popcon enabled at all (it seems to be mostly desktop systems) and how it looks on the total population. Ansgar
[toc] | [prev] | [next] | [standalone]
| From | James Addison <jay@jp-hosting.net> |
|---|---|
| Date | 2023-05-21 08:00 +0200 |
| Subject | Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal) |
| Message-ID | <GxKgN-anTn-1@gated-at.bofh.it> |
| In reply to | #107964 |
On Fri, 19 May 2023 at 22:58, Ansgar <ansgar@43-1.org> wrote: > > On Fri, 2023-05-19 at 19:40 +0100, James Addison wrote: > > Do we know how often the i386 installer is downloaded compared to > > amd64, and could/should we start with updated messaging where those > > are provided before removing users' ability to install on their > > systems? > > > > (i386 remains the second-most-popular architecture behind amd64 today > > going by popcon[1] stats - perhaps a lot of that is people using i386 > > as a compatibility architecture only, but it'd be nice to be > > reasonably confident about that) > > One of the problems with popcon is that it draws too much attention to > old releases which isn't really interesting when talking about future > developments. If one looks at arch usage per release (as reported to > popcon) one gets this table: > > | Architecture | jessie | stretch | buster | bullseye | bookworm/sid | > |----------------+--------+---------+--------+----------+--------------| > | alpha | 1 | | | | 4 | > | amd64 | 9090 | 17156 | 41137 | 108145 | 14800 | > | arm64 | | 1 | 93 | 937 | 203 | > | armel | 21 | 47 | 67 | 68 | 10 | > | armhf | 7 | 18 | 216 | 429 | 49 | > | hppa | | | | | 8 | > | hurd-i386 | | | | 4 | 6 | > | i386 | 1318 | 1231 | 1495 | 3042 | 168 | > | ia64 | | | | | 3 | > | kfreebsd-amd64 | 2 | | | | | > | m68k | | 1 | | | 4 | > | mips | 2 | | 6 | | | > | mips64el | | | 6 | 4 | | > | mipsel | 2 | 1 | 7 | | | > | powerpc | 13 | 1 | 1 | 1 | 18 | > | ppc64 | | | | 1 | 28 | > | ppc64el | | 5 | 16 | | 12 | > | riscv64 | | | | | 15 | > | s390x | | | | 8 | 3 | > | sh4 | | | | | 1 | > | sparc64 | | | | | 11 | > | x32 | | | | | 2 | > |----------------+--------+---------+--------+----------+--------------| > | ∑ | 10456 | 18461 | 43044 | 112639 | 15345 | > #+TBLFM: @>$2..@>$>=vsum(@I..II) > > where i386 has dropped from 13% to 7% to 3% to 3% and finally to 1%. > Also interesting is that arm64 has taken over i386 on bookwork/sid. > > We don't know how many people downloaded i386 instead of amd64 as they > have an Intel CPU. > > What is also not clear is the bias of systems having popcon enabled at > all (it seems to be mostly desktop systems) and how it looks on the > total population. Thanks, those are better statistics (and good notes about their limitations). I may be playing devil's advocate, but I do also read from those that the i386 install-base, even dwindled as it has to ~1%, remains more popular than many other architectures (within whatever dimension of users enable popcon) where we do provide install images, and then that those users tend to upgrade to the latest i386 release of Debian that they can -- and/or that despite the percentage-of-total trend reducing, the absolute population of those i386 users is growing (I guess the former is the larger contributing factor, but it's hard to determine from the numbers only). Meanwhile my understanding is that most of the i386 installer package -- although I referred to it as a binary package in another thread, using the source/binary package naming terminology -- is mostly shell scripting and architecture-independent logic. So I guess I will ask: is there a technical reason we want to drop d-i images on i386, or is it primarily about trying to reduce our anticipated support burden for one architecture? (and if people clamoured for an i386 installer to download, would we reverse the decision?)
[toc] | [prev] | [next] | [standalone]
| From | Roger Lynn <Roger@rilynn.me.uk> |
|---|---|
| Date | 2023-05-26 01:30 +0200 |
| Subject | Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal) |
| Message-ID | <Gzsz7-br35-3@gated-at.bofh.it> |
| In reply to | #107981 |
On 21/05/2023 07:00, James Addison wrote: > On Fri, 19 May 2023 at 22:58, Ansgar <ansgar@43-1.org> wrote: >> One of the problems with popcon is that it draws too much attention to >> old releases which isn't really interesting when talking about future >> developments. If one looks at arch usage per release (as reported to >> popcon) one gets this table: >> >> | Architecture | jessie | stretch | buster | bullseye | bookworm/sid | >> |----------------+--------+---------+--------+----------+--------------| >> | alpha | 1 | | | | 4 | >> | amd64 | 9090 | 17156 | 41137 | 108145 | 14800 | >> | arm64 | | 1 | 93 | 937 | 203 | >> | armel | 21 | 47 | 67 | 68 | 10 | >> | armhf | 7 | 18 | 216 | 429 | 49 | >> | hppa | | | | | 8 | >> | hurd-i386 | | | | 4 | 6 | >> | i386 | 1318 | 1231 | 1495 | 3042 | 168 | >> | ia64 | | | | | 3 | >> | kfreebsd-amd64 | 2 | | | | | >> | m68k | | 1 | | | 4 | >> | mips | 2 | | 6 | | | >> | mips64el | | | 6 | 4 | | >> | mipsel | 2 | 1 | 7 | | | >> | powerpc | 13 | 1 | 1 | 1 | 18 | >> | ppc64 | | | | 1 | 28 | >> | ppc64el | | 5 | 16 | | 12 | >> | riscv64 | | | | | 15 | >> | s390x | | | | 8 | 3 | >> | sh4 | | | | | 1 | >> | sparc64 | | | | | 11 | >> | x32 | | | | | 2 | >> |----------------+--------+---------+--------+----------+--------------| >> | ∑ | 10456 | 18461 | 43044 | 112639 | 15345 | >> #+TBLFM: @>$2..@>$>=vsum(@I..II) >> >> where i386 has dropped from 13% to 7% to 3% to 3% and finally to 1%. >> Also interesting is that arm64 has taken over i386 on bookwork/sid. >> >> We don't know how many people downloaded i386 instead of amd64 as they >> have an Intel CPU. >> >> What is also not clear is the bias of systems having popcon enabled at >> all (it seems to be mostly desktop systems) and how it looks on the >> total population. > > Thanks, those are better statistics (and good notes about their limitations). > > I may be playing devil's advocate, but I do also read from those that > the i386 install-base, even dwindled as it has to ~1%, remains more > popular than many other architectures (within whatever dimension of > users enable popcon) where we do provide install images, and then that > those users tend to upgrade to the latest i386 release of Debian that > they can -- and/or that despite the percentage-of-total trend > reducing, the absolute population of those i386 users is growing (I > guess the former is the larger contributing factor, but it's hard to > determine from the numbers only). The popcon graphs clearly show that the absolute number (not proportion) of i386 reports flattened off in 2008 at about 65000, when AMD64 became popular. The number of i386 reports has been falling since 2014, and is now about 10000, most of which are from old releases (oldstable or older). It seems likely that the number of i386 reports from stable will be overtaken by ARM64 during the period of Bookworm. Roger
[toc] | [prev] | [next] | [standalone]
| From | James Addison <jay@jp-hosting.net> |
|---|---|
| Date | 2023-05-26 06:50 +0200 |
| Subject | Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal) |
| Message-ID | <GzxyN-burY-1@gated-at.bofh.it> |
| In reply to | #108009 |
On Fri, 26 May 2023 at 00:27, Roger Lynn <Roger@rilynn.me.uk> wrote: > > On 21/05/2023 07:00, James Addison wrote: > > On Fri, 19 May 2023 at 22:58, Ansgar <ansgar@43-1.org> wrote: > >> One of the problems with popcon is that it draws too much attention to > >> old releases which isn't really interesting when talking about future > >> developments. If one looks at arch usage per release (as reported to > >> popcon) one gets this table: > >> > >> | Architecture | jessie | stretch | buster | bullseye | bookworm/sid | > >> |----------------+--------+---------+--------+----------+--------------| > >> | alpha | 1 | | | | 4 | > >> | amd64 | 9090 | 17156 | 41137 | 108145 | 14800 | > >> | arm64 | | 1 | 93 | 937 | 203 | > >> | armel | 21 | 47 | 67 | 68 | 10 | > >> | armhf | 7 | 18 | 216 | 429 | 49 | > >> | hppa | | | | | 8 | > >> | hurd-i386 | | | | 4 | 6 | > >> | i386 | 1318 | 1231 | 1495 | 3042 | 168 | > >> | ia64 | | | | | 3 | > >> | kfreebsd-amd64 | 2 | | | | | > >> | m68k | | 1 | | | 4 | > >> | mips | 2 | | 6 | | | > >> | mips64el | | | 6 | 4 | | > >> | mipsel | 2 | 1 | 7 | | | > >> | powerpc | 13 | 1 | 1 | 1 | 18 | > >> | ppc64 | | | | 1 | 28 | > >> | ppc64el | | 5 | 16 | | 12 | > >> | riscv64 | | | | | 15 | > >> | s390x | | | | 8 | 3 | > >> | sh4 | | | | | 1 | > >> | sparc64 | | | | | 11 | > >> | x32 | | | | | 2 | > >> |----------------+--------+---------+--------+----------+--------------| > >> | ∑ | 10456 | 18461 | 43044 | 112639 | 15345 | > >> #+TBLFM: @>$2..@>$>=vsum(@I..II) > >> > >> where i386 has dropped from 13% to 7% to 3% to 3% and finally to 1%. > >> Also interesting is that arm64 has taken over i386 on bookwork/sid. > >> > >> We don't know how many people downloaded i386 instead of amd64 as they > >> have an Intel CPU. > >> > >> What is also not clear is the bias of systems having popcon enabled at > >> all (it seems to be mostly desktop systems) and how it looks on the > >> total population. > > > > Thanks, those are better statistics (and good notes about their limitations). > > > > I may be playing devil's advocate, but I do also read from those that > > the i386 install-base, even dwindled as it has to ~1%, remains more > > popular than many other architectures (within whatever dimension of > > users enable popcon) where we do provide install images, and then that > > those users tend to upgrade to the latest i386 release of Debian that > > they can -- and/or that despite the percentage-of-total trend > > reducing, the absolute population of those i386 users is growing (I > > guess the former is the larger contributing factor, but it's hard to > > determine from the numbers only). > > The popcon graphs clearly show that the absolute number (not proportion) of > i386 reports flattened off in 2008 at about 65000, when AMD64 became > popular. The number of i386 reports has been falling since 2014, and is now > about 10000, most of which are from old releases (oldstable or older). It > seems likely that the number of i386 reports from stable will be overtaken > by ARM64 during the period of Bookworm. Thanks Roger. I concede that the absolute number of i386 popcon reports has been falling; this graph makes that clear[1]: https://web.archive.org/web/20221223090933/https://popcon.debian.org/stat/sub-i386.png Also, yep, it does seem possible that i386's position in terms of total popcon reports could fall into third place behind AMD64 and ARM64 over the next two years or so. Is an architecture's ranking position within popcon reports a significant factor in whether it should be installer-supported? Or is it perhaps only a secondary indicator and there are other considerations that are more important? (for example, whether we have volunteers keen to support it..) An aside: the trend for ARM64 reports appears to include a few steep increments followed by pauses. I'm left wondering whether those correspond to additional hardware support, arrival of popular packages in the ARM64 archive, or other factors[2]: https://web.archive.org/web/20221223090903/https://popcon.debian.org/stat/sub-arm64.png (the reason I mention that is that the absence of a continuous-ish, linear-ish trend makes it more difficult for me to predict when ARM64 will overtake i386 - I get the sense that there are probably real-world trends that I'm missing that aren't immediately apparent in a graph) [1] - A graph titled "Number of submissions for i386", containing two trendlines: "i386" in maroon, and "all submissions" in green. The x-axis is a time range from Y2004 to Y2023, the left y-axis is from zero to 80k (for i386) and the right y-axis is from zero to 250k (for all submissions). Very approximately, the green line traces a 45-degree angle from bottom-left to top-right, leveling out slightly around 2018. Both trendlines show a large increase around Y2007, up to a plateau (or near-plateau, in the case of the then-increasing-again green line) -- 65k for i386 as Roger mentions, and approximately 75k across all submissions. Around 2014, the red i386 trendline begins a descent, intersecting the green line momentarily after (although to be honest, that is something of a visual distraction, because intersection of lines on a chart where the y-axes are different is difficult to reason about). The descent of the red i386 trendline from Y2014 is fairly steep - perhaps a 55 degree angle - although it begins to level out gradually, nearing perhaps 30 or 35 degrees towards the end of Y2022. At the end of the chart, around October of Y2022, i386 has a value slightly above 10k and the total across all submissions is perhaps 210k or so. [2] - A graph titled "Number of submissions for arm64", containing two trendlines: "arm64" in maroon, and "all submissions" in green. The y-axis for the red trendline is from zero to 1200. Data for the red arm64 trendline begins around Y2014, yet by Y2020 it shows gradual and slow linear growth, remaining below a value of 200. In Y2020, something happens and by early Y2021, the value has jumped to 400 or so, where it fluctuates briefly up/down by 10 points or so a few times. After a momentary drop in August of Y2021, the red trendline then makes four ascents: 200, 150, 50, 200 - arriving at perhaps slightly above 1000 in October of Y2022 where the graph ends.
[toc] | [prev] | [next] | [standalone]
| From | Josh Triplett <josh@joshtriplett.org> |
|---|---|
| Date | 2023-05-20 09:20 +0200 |
| Subject | Using i386 by mistake on 64-bit hardware [was Re: i386 in the future 32-bit archs: a proposal)] |
| Message-ID | <Gxp2F-aaFK-3@gated-at.bofh.it> |
| In reply to | #107960 |
James Addison wrote: > Do we know how often the i386 installer is downloaded compared to > amd64, and could/should we start with updated messaging where those > are provided before removing users' ability to install on their > systems? How easily could we add 64-bit system detection to the i386 installer, and a message saying something like: "You're installing the i386 architecture on a 64-bit system. While this will work, this is the last release it'll be supported. We recommend installing the 64-bit amd64 architecture instead. On amd64 you can still subsequently install i386 packages and run 32-bit binaries. Are you sure you want to proceed with a 32-bit-only install?" That might help reduce the number of actual installations of i386 by people who don't realize they could be and should be using amd64. (I realize that this is fairly late to be making *any* changes to the installer, let alone changes that require translations. Also, if we already have some detection like that, my apologies for missing it.) - Josh Triplett
[toc] | [prev] | [next] | [standalone]
| From | Simon Richter <sjr@debian.org> |
|---|---|
| Date | 2023-05-20 11:30 +0200 |
| Subject | Re: Using i386 by mistake on 64-bit hardware [was Re: i386 in the future 32-bit archs: a proposal)] |
| Message-ID | <Gxr4t-abRW-5@gated-at.bofh.it> |
| In reply to | #107969 |
[Multipart message — attachments visible in raw view] — view raw
Hi,
On 20.05.23 16:15, Josh Triplett wrote:
> That might help reduce the number of actual installations of i386 by
> people who don't realize they could be and should be using amd64.
Crossgrades are probably broken with systemd, but it might be possible
to hack something that diverts /sbin/init and performs the crossgrade
after a reboot, that might also help a few people leave i386 behind.
Simon
[toc] | [prev] | [next] | [standalone]
| From | Adam Borowski <kilobyte@angband.pl> |
|---|---|
| Date | 2023-05-20 18:50 +0200 |
| Subject | Re: Using i386 by mistake on 64-bit hardware [was Re: i386 in the future 32-bit archs: a proposal)] |
| Message-ID | <GxxWh-afSr-7@gated-at.bofh.it> |
| In reply to | #107969 |
On Sat, May 20, 2023 at 09:15:00AM +0200, Josh Triplett wrote: > How easily could we add 64-bit system detection to the i386 installer, > and a message saying something like: > > "You're installing the i386 architecture on a 64-bit system. While this > will work, this is the last release it'll be supported. We recommend > installing the 64-bit amd64 architecture instead. This is not a valid use for i386. Running the i386 kernel on _modern_ hardware is insecure, slower (esp. if you have a non-tiny amount of memory), etc. We should put a big fat warnings for _that_. On the other hand, it's okayish to run 32-bit userland -- in fact, in some cases it might be quite a bit faster¹, as long as you use the appropriate kernel. Which is 32-bit for ancient hardware (including some first 64-bit-capable models), and 64-bit today. Meow! [¹]. Sometimes amd64 wins by a lot due to more wider registers and SSE, sometimes i386 win hugely due to halved pointers and better code density, which allows using a higher-tier cache. We could have been using x32 to get both, but oh well... -- ⢀⣴⠾⠻⢶⣦⠀ The ill-thought conversion to time64_t will make us suffer from ⣾⠁⢠⠒⠀⣿⡁ the Y292B problem. So let's move the Epoch by 435451400064000000 ⢿⡄⠘⠷⠚⠋⠀ (plus a safety margin in case of bad physicists) and make it ⠈⠳⣄⠀⠀⠀⠀ unsigned -- that'll almost double the range.
[toc] | [prev] | [next] | [standalone]
| From | Stephen Kitt <skitt@debian.org> |
|---|---|
| Date | 2023-05-21 20:00 +0200 |
| Subject | Re: Using i386 by mistake on 64-bit hardware [was Re: i386 in the future 32-bit archs: a proposal)] |
| Message-ID | <GxVvz-auub-1@gated-at.bofh.it> |
| In reply to | #107977 |
[Multipart message — attachments visible in raw view] — view raw
On Sat, 20 May 2023 18:14:52 +0200, Adam Borowski <kilobyte@angband.pl> wrote: > On Sat, May 20, 2023 at 09:15:00AM +0200, Josh Triplett wrote: > > How easily could we add 64-bit system detection to the i386 installer, > > and a message saying something like: > > > > "You're installing the i386 architecture on a 64-bit system. While this > > will work, this is the last release it'll be supported. We recommend > > installing the 64-bit amd64 architecture instead. > > This is not a valid use for i386. Running the i386 kernel on _modern_ > hardware is insecure, slower (esp. if you have a non-tiny amount of > memory), etc. We should put a big fat warnings for _that_. And future modern hardware is likely to make it impossible: https://www.intel.com/content/www/us/en/developer/articles/technical/envisioning-future-simplified-architecture.html which means it will become increasingly difficult to reliably test i386 kernels on sensible hardware; not on a timescale relevant for Trixie, but still, worth bearing in mind. VMs and/or emulation will end up being the only possible ways of running legacy software on modern hardware. Regards, Stephen
[toc] | [prev] | [next] | [standalone]
Page 4 of 8 — ← Prev page 1 2 3 [4] 5 6 7 8 Next page →
Back to top | Article view | linux.debian.devel
csiph-web