Re: Y2038 - best way forward in Debian?
Hey Simon,
Simon McVittie wrote:
>On Tue, 04 Feb 2020 at 13:14:10 +0000, Steve McIntyre wrote:
>> Arnd scanned the library packages in the Debian archive and identified
>> that about one third of our library packages would need rebuilding
>> (and tracking) to make a (recursive) transition.
>
>Is a list of affected/unaffected packages available? (I know they'll
>be long lists.) Depending on how high up the stack they are, the right
>approach might change.
I don't have the list, I'm afraid. Arnd?
>Thinking about i386 specifically, since the tradeoffs for that architecture
>are likely to be a little different due to the prevalence of proprietary
>binaries, the use-cases I am aware of are:
>
>- Old hardware that doesn't implement amd64.
> Breaking ABI would help here, but equally, this use-case seems likely
> to go away "naturally" in the next 10? years (and for example Ubuntu is
> already relegating i386 to a second-class-citizen status as a multiarch
> library stack on amd64 systems, with no kernel or full bootable OS).
>
>- amd64-capable machines that have inherited a legacy i386 installation
> because their owner doesn't want to reinstall or sidegrade to amd64.
> Breaking the i386 ABI seems like it would be counterproductive here:
> they'll still need to reinstall or sidegrade, and sidegrading from
> i386 to i386t would probably be very crash-prone, since those will
> presumably both have to be represented by ELF32 x86 binaries?
>
>- 32-bit Wine (to run 32-bit Windows programs).
> On the Unix side, breaking ABI would maybe help. On the Windows side,
> Wine needs to match whatever Microsoft does to solve this problem
> (apparently time_t already defaults to 64-bit on Windows, but older
> binaries will presumably use 32-bit time_t forever).
Hmmm. I didn't think Microsoft used *time_t* as such, but had their
own 64-bit format based on an epoch in ~1600?
>- Running old proprietary or otherwise sourceless binaries (e.g. games).
> Breaking ABI is counterproductive: we can't recompile the games anyway.
> Some solutions for running these (e.g. the Steam Runtime used by Steam)
> rely on host libraries being approximately ABI-compatible with the ones
> the binaries were compiled against, because they need to fetch graphics
> drivers and their dependencies from the host system, otherwise they
> could not work on recent GPUs (although by 2038, with faster CPUs, we'll
> hopefully be able to run 2010s games at acceptable performance with
> software rendering like llvmpipe, which would sidestep this issue).
> (See the slides/video from my recent FOSDEM talk for more details)
ACK. I'm in agreement here. I also personally don't see the same
benefit to doing a 64-bit time_t transition for i386, using any of the
models we've suggested. It's a legacy ABI that we should explicitly
warn people will break. Have the Steam folks considered this issue at
all yet, OOC?
armhf is a different kettle of fish, without the same set of legacy
binaries. There are *many* legacy proprietary binaries for the
architecture, but the only ones that really matter are on other
platforms (Android or iOS) and really not our problem here. :-)
--
Steve McIntyre, Cambridge, UK. steve@einval.com
Armed with "Valor": "Centurion" represents quality of Discipline,
Honor, Integrity and Loyalty. Now you don't have to be a Caesar to
concord the digital world while feeling safe and proud.
Reply to: