10 ms·

Debian 64-bit-time transition

157 points by okl 2y ago

bitwize 2y ago
An old Jargon entry that nicely captures the scope of the problem: http://www.catb.org/jargon/html/R/recompile-the-world.html http://www.catb.org/jargon/html/R/recompile-the-world.html
- anthk 2y ago
  Less than a problem with ccache, and OpenBSD solved the time_t issue long ago. But sometimes I envy common lispers, you livepatch any crap like nothing. Also, 9front: megafast system recompilation so the worst of the issue would be rebooting a machine.
  - knorker 2y ago
    > OpenBSD solved the time_t issue long ago. It's amazing how quickly you can solve problems when you're fine breaking user space between releases. Not that Linux has a perfect record, but it's much harder when you actually try.
    - anthk 2y ago
      Upgrading is not an issue, now you have vmd and a lot of mirrors still have both the old TGZ sets, ramdisks, kernels and packages to be able to virtualize old machines just in case.
      - knorker 2y ago
        I agree that it's a fine use case. I'm just saying it's simpler if you allow yourself a fresh start. Won't work well for games and other stuff you can't just recompile on your own. Going mainframe mode and virtualizing the previous generation has problems in that the older releases don't get security fixes, and may not work as well with tuning and monitoring. I would not want to run a 10 year old OpenBSD, virtual or not. E.g. the speculative execution patches would be nontrivial to backport. But it has valid use cases.
        anthk 2y ago
        Most games can be either recompilable or able to being run with xnaify or similar Mono/C# wrappers.
        knorker 2y ago
        Sure, they're recompilable. If whoever has the source recompiles them. Well, turns out ABI stability was not enough to make gamers use Linux, but it's an example. A better example would maybe be the Oracle database. You could maybe see them building for OpenBSD. But not if that means they'd sign up for rebuilding every six months the ABI has potentially broken in the new release. I would not say that this is the reason OpenBSD hasn't yet been the OS of choice for the Oracle sales team, of course.
    - sillywalk 2y ago
      I'd prefer to refer to it as 'changing userspace', as opposed to breaking it. The ABI is changed, and userspace/ports are updated to use the new ABI. Users just upgrade as usual, and don't see any 'breakage'. It wouldn't work for Linux, because the kernel and glibc + the rest of userspace are developed separately. Slides on OpenBSD's transition to 64-bit time_t https://www.openbsd.org/papers/eurobsdcon_2013_time_t/index.html https://www.openbsd.org/papers/eurobsdcon_2013_time_t/index.... "I have altered the ABI. Pray I do not alter it further." -- Theo de Raadt https://marc.info/?l=openbsd-tech&m=157489277318829&w=2 https://marc.info/?l=openbsd-tech&m=157489277318829&w=2
      - knorker 2y ago
        Linux could probably do it despite glibc, just more carefully. But OpenBSD also broke Go binaries, with some recent changes, right? Breaking ABI towards userspace, or breaking user space? What's the difference? Binaries that used to work no longer do. If you only run packages and ports, then shrug. If all you have is packages, ports, and source, then just upgrade and recompile everything. I'm not saying it's wrong to break userspace, but it's not inaccurate to call it such. C.f. Google's monorepo, to not need to maintain an ABI. ABIs may or may not be overrated, but dropping that requirement sure make things easier.
        HumanProtractor 2y ago
        Go wasn't properly behaved, the OpenBSD people actually fixed it so it works properly now. It's not broken.
        knorker 2y ago
        That's Hyrum's law for you. Actually that's not even fair to Go. I'm as annoyed as anyone about the many suboptimal technical choices of the Go team, but I would say that Theo saying "I have altered the ABI. Pray I do not alter it further" is quite accurate. Go in this case made a choice based on one "promise", and OpenBSD changed the deal. Even Hyrum's law is more about "as implemented". Go actually went with "as designed, in the last, what, four decades?". Syscalls actually did use to be the API, and statically linked libc really did use to be "ok". OpenBSD let security be done though the heavens fall, and that's fine. But it's MUCH easier than the alternative. So obviously much easier to make progress on.
dsr_ 2y ago
Since all of this is happening, properly, in the unstable and testing repos, stable is not affected. For some reason, a lot of people ignore the warnings https://wiki.debian.org/DebianUnstable https://wiki.debian.org/DebianUnstable about unstable and testing and are complaining that Debian is broken.
- bgribble 2y ago
  I have used unstable as my daily driver since they named it "unstable", which I don't even remember what that was but at least 20 years ago. I have never (yet!) gotten myself into any trouble, by following a very simple principle: if aptitude (dselect back in the day) wants to remove or hold more than a handful of packages, STOP. Undo what you just did, and instead of a bulk upgrade go through marking one package at a time for upgrade. When you hit one that needs major changes, if you can't find an upgrade alternative that is sensible, leave it un-upgraded and try again in a few days. This time upgrade has been one of the more challenging ones to track in unstable, but patience and actually reading the reasons that dpkg reports for why it wants to do something has gotten me through it.
  - neilv 2y ago
    Back when I was running Debian `unstable` (Sid?), I was always slightly nervous that an update could make the system unbootable, or otherwise ruin my day, when I had other things to do. So I wrote a lighthearted theme song for `unstable` updates. I don't recall most of it offhand, but it was to the tune of "Cat's in the Cradle": o/~ What I'd really like now is to update your libc. See you later, can you apt-get please? At some point, Linux software stopped improving so quickly, and Debian Stable seemed better. And I've been very happy with it, for most all startup and personal purposes.
    - Grimeton 2y ago
      (S)id (I)s (D)angerous
      - 2y ago
__s 2y ago
Note this only matters for 32 bit systems. Good to see tho > 64-bit architectures are not affected by the y2k38 problem, but they are affected by this transition. ^ surprised by this line. guess it also impacts lib32 packages on amd64 Little surprised it didn't happen sooner, but guess 64bit transition dampened urgency. Looks like it was waiting on changes in glibc etc. Unfortunately the remaining 32bit space is less likely to support upgrades
- Denvercoder9 2y ago
  > ^ surprised by this line. guess it also impacts lib32 packages on amd64 The reason for this is that in Debian, package name and ABI are coupled, as that allows you to coinstall multiple versions of libraries with different ABIs. This transition changes the ABI on 32-bit architectures, so the package name of impacted packages also has to change (they get a "t64" suffix). While it's technically possible to have different package names on different architectures, that's a PITA to deal with, so they opted to also change the package names on 64-bit architectures, where it's not strictly required.
juujian 2y ago
I just went through this transition in Debian testing, I suppose. I wasn't aware it was going to happen, and I didn't have a chance to install updates for two weeks prior, which I usually do every day. It wasn't gracefully. I don't know for sure if that's the transition is the cause, but I managed to break network- manager while updating. Had to load the Deb from my phone and transfer it over since I'm travelling. I managed to force the install but broke KDE in the process. I had to figure out how to connect to the internet from the console and reinstall KDE. That would have been much easier had I not been on the road.
- seba_dos1 2y ago
  The golden rule when using testing/unstable is: when apt wants to remove packages, double-check everything before proceeding. Really, it's that simple.
  - juujian 2y ago
    Yeah, reading comprehension is one of my weaknesses tbh.
WirelessGigabit 2y ago
> 64-bit architectures are not affected by the y2k38 problem, but they are affected by this transition. I read the article with my limited knowledge and I couldn't find an explanation for this statement. Can someone elaborate?
- bun_terminator 2y ago
  (here stood something wrong because I've been working with 32bit code for too long recently)
  - CamperBob2 2y ago
    In Win32 builds, it's been necessary to request legacy 32-bit time_t structures explicitly with _USE_32BIT_TIME_T for many years, for what that's worth. 64-bit time_t has been the standard for a while.
    - bun_terminator 2y ago
      ow, a stark reminder that I've worked with out 32bit code for far too long
  - TonyTrapp 2y ago
    > but in general time_t is commonly an int32 type - doesn't matter what OS it compiles on Maybe 20 years ago, but these days you cannot make such a generalization. For example, VC++ uses a 64-bit time_t even in 32-bit builds unless you explicitly define _USE_32BIT_TIME_T. on 64-bit builds, a 32-bit time_t would be an illegal configuration that won't even build.
- zinekeller 2y ago
  I would initially assume that the problem is due to compatibility concerns (like NFS3 requiring 32-bit timestamps), but is instead a rather Debian-specific problem: Or we can do library transitions for the set of all libraries that reference time_t in their ABI; this is a bit more work for everyone in the short term because it will impact testing migration across all archs rather than being isolated to a single port, but it’s on the order of 500 library packages which is comparable to other ABI transitions we’ve done in the past (e.g. ldbl https://lists.debian.org/debian-devel/2007/05/msg01173.html).
blahgeek 2y ago
It bothers me that they are only doing the transition now. It should have been done 20 years ago. 2038 is less than 15 years away and I bet a significant portion of systems will not be upgraded during this period. (As a reference, Windows 7 was released 15 years ago and it's still on 3% usage share [1].) What's worse, compared to Y2K problem, in 2038, much more critical infrastructures will depend on computers (payment, self-driving cars, public transportation, security cameras, etc etc). We are doomed. [1] https://en.wikipedia.org/wiki/Template:Windows_usage_share https://en.wikipedia.org/wiki/Template:Windows_usage_share
- Denvercoder9 2y ago
  Note that for most systems this transition already happened with the transition to 64-bit architectures, in the 2000s. It's only 32-bit architectures to which the current transition applies. Debian couldn't have transitioned them 20 years ago, as kernel support for 64-bit time_t on a 32-bit architecture is fairly recent (Linux 5.6 in 2020).
  - asveikau 2y ago
    I remember OpenBSD working on this about 10 years ago. Also, strictly speaking transitioning with the CPU architecture is not enough -- having kernel APIs and ABIs have 64-bit time_t is not the only place it needs to change. Notably, it has to change in the filesystem too. And at that point millions of people will have on-disk structures with 32bit timestamps, so it needs to transition in a somewhat back compatible way.
  - phaedrus 2y ago
    Except some communication protocols have a 32 bit timestamp baked into the format.
- htjrjfjtktn 2y ago
  [flagged]
- tomxor 2y ago
  > 2038 is less than 15 years away and I bet a significant portion of systems will not be upgraded during this period. No, Linux distro releases are not like Windows, there is little reason to be holding back and running 15 year old systems. If you are running Debian 12 in 2038, lack of t64 will be the least of your issues. Debain 12 standard LTS ends in 2028 [0] and extended support (if you pay for it) ends in 2033 [1]. Beyond that you're on your own. If you're running servers, you'd be mad to be running any the current stable and old-stable releases by then. [0] https://wiki.debian.org/LTS https://wiki.debian.org/LTS [1] https://wiki.debian.org/LTS/Extended https://wiki.debian.org/LTS/Extended
dmd 2y ago
The 64-bit time transition ensures Unix time can be used far, far into the future, as described in Vernor Vinge's "A Deepness in the Sky": > Pham Nuwen spent years learning to program/explore. Programming went back to the beginning of time. It was a little like the midden out back of his father’s castle. Where the creek had worn that away, ten meters down, there were the crumpled hulks of machines—flying machines, the peasants said—from the great days of Canberra’s original colonial era. But the castle midden was clean and fresh compared to what lay within theReprise ’s local net. There were programs here that had been written five thousand years ago, before Humankind ever left Earth. The wonder of it—the horror of it, Sura said—was that unlike the useless wrecks of Canberra’s past, these programs still worked! And via a million million circuitous threads of inheritance, many of the oldest programs still ran in the bowels of the Qeng Ho system. Take the Traders’ method of timekeeping. The frame corrections were incredibly complex—and down at the very bottom of it was a little program that ran a counter. Second by second, the Qeng Ho counted from the instant that a human had first set foot on Old Earth’s moon. But if you looked at it still more closely. . .the starting instant was actually some hundred million seconds later, the 0-second of one of Humankind’s first computer operating systems. (Yes, Vinge made a slight error here - it's only about 14 megaseconds from Armstrong to the epoch, not 100.)
shmerl 2y ago
It got over most of the blockers it seems, but it's really monstrous in scope.
ComputerGuru 2y ago
Debian is one of the few distros still offering a tier-1, first-party i686 target in 2024. Even a lot of derivative distros (i.e. where it would be minimal effort to do the same) have dropped i686. Given the enormous scope of this transition, I have to wonder how many will be benefiting from this 15 years from now. I don’t question it will have utility, but I wonder about the ROI.
- agwa 2y ago
  Debian is not switching to 64-bit time_t on their x86 architecture, because they see it as a legacy architecture whose primary use is running legacy binaries. This transition is mainly to benefit 32-bit ARM since it's likely to be used in new systems for many more years.
  - pwdisswordfishc 2y ago
    Wow, so the multi-hour package conflict resolution I am going through RIGHT NOW on my 2004 laptop is completely pointless? Good to know.
    - snvzz 2y ago
      You'd be better off switching to a non-linux system on that hardware. Ideally something that uses 64bit offsets and time_t.
- deleted 2y ago
  [deleted]
- actionfromafar 2y ago
  Adjusted for coolness points the ROI is pretty good, though. :) Besides, maybe there will be some digital (ARM?) dust running 32-bit Debian in the future.
- pabs3 2y ago
  Debian is dropping i686 too. You won't be able to install it soon. Also, the t64 fixes are not happening on i386, since the ABI change that the t64 changes do would break proprietary binaries, and Debian cares more about that use case than about people with ancient i386 hardware, who should just upgrade to amd64 anyway.

157 points by okl 2y ago

An old Jargon entry that nicely captures the scope of the problem: http://www.catb.org/jargon/html/R/recompile-the-world.html http://www.catb.org/jargon/html/R/recompile-the-world.html

anthk 2y ago
Less than a problem with ccache, and OpenBSD solved the time_t issue long ago. But sometimes I envy common lispers, you livepatch any crap like nothing. Also, 9front: megafast system recompilation so the worst of the issue would be rebooting a machine.
- knorker 2y ago
  > OpenBSD solved the time_t issue long ago. It's amazing how quickly you can solve problems when you're fine breaking user space between releases. Not that Linux has a perfect record, but it's much harder when you actually try.
  - anthk 2y ago
    Upgrading is not an issue, now you have vmd and a lot of mirrors still have both the old TGZ sets, ramdisks, kernels and packages to be able to virtualize old machines just in case.
    - knorker 2y ago
      I agree that it's a fine use case. I'm just saying it's simpler if you allow yourself a fresh start. Won't work well for games and other stuff you can't just recompile on your own. Going mainframe mode and virtualizing the previous generation has problems in that the older releases don't get security fixes, and may not work as well with tuning and monitoring. I would not want to run a 10 year old OpenBSD, virtual or not. E.g. the speculative execution patches would be nontrivial to backport. But it has valid use cases.
      - anthk 2y ago
        Most games can be either recompilable or able to being run with xnaify or similar Mono/C# wrappers.
        knorker 2y ago
        Sure, they're recompilable. If whoever has the source recompiles them. Well, turns out ABI stability was not enough to make gamers use Linux, but it's an example. A better example would maybe be the Oracle database. You could maybe see them building for OpenBSD. But not if that means they'd sign up for rebuilding every six months the ABI has potentially broken in the new release. I would not say that this is the reason OpenBSD hasn't yet been the OS of choice for the Oracle sales team, of course.
  - sillywalk 2y ago
    I'd prefer to refer to it as 'changing userspace', as opposed to breaking it. The ABI is changed, and userspace/ports are updated to use the new ABI. Users just upgrade as usual, and don't see any 'breakage'. It wouldn't work for Linux, because the kernel and glibc + the rest of userspace are developed separately. Slides on OpenBSD's transition to 64-bit time_t https://www.openbsd.org/papers/eurobsdcon_2013_time_t/index.html https://www.openbsd.org/papers/eurobsdcon_2013_time_t/index.... "I have altered the ABI. Pray I do not alter it further." -- Theo de Raadt https://marc.info/?l=openbsd-tech&m=157489277318829&w=2 https://marc.info/?l=openbsd-tech&m=157489277318829&w=2
    - knorker 2y ago
      Linux could probably do it despite glibc, just more carefully. But OpenBSD also broke Go binaries, with some recent changes, right? Breaking ABI towards userspace, or breaking user space? What's the difference? Binaries that used to work no longer do. If you only run packages and ports, then shrug. If all you have is packages, ports, and source, then just upgrade and recompile everything. I'm not saying it's wrong to break userspace, but it's not inaccurate to call it such. C.f. Google's monorepo, to not need to maintain an ABI. ABIs may or may not be overrated, but dropping that requirement sure make things easier.
      - HumanProtractor 2y ago
        Go wasn't properly behaved, the OpenBSD people actually fixed it so it works properly now. It's not broken.
        knorker 2y ago
        That's Hyrum's law for you. Actually that's not even fair to Go. I'm as annoyed as anyone about the many suboptimal technical choices of the Go team, but I would say that Theo saying "I have altered the ABI. Pray I do not alter it further" is quite accurate. Go in this case made a choice based on one "promise", and OpenBSD changed the deal. Even Hyrum's law is more about "as implemented". Go actually went with "as designed, in the last, what, four decades?". Syscalls actually did use to be the API, and statically linked libc really did use to be "ok". OpenBSD let security be done though the heavens fall, and that's fine. But it's MUCH easier than the alternative. So obviously much easier to make progress on.

dsr_ 2y ago

Since all of this is happening, properly, in the unstable and testing repos, stable is not affected. For some reason, a lot of people ignore the warnings https://wiki.debian.org/DebianUnstable https://wiki.debian.org/DebianUnstable about unstable and testing and are complaining that Debian is broken.

bgribble 2y ago
I have used unstable as my daily driver since they named it "unstable", which I don't even remember what that was but at least 20 years ago. I have never (yet!) gotten myself into any trouble, by following a very simple principle: if aptitude (dselect back in the day) wants to remove or hold more than a handful of packages, STOP. Undo what you just did, and instead of a bulk upgrade go through marking one package at a time for upgrade. When you hit one that needs major changes, if you can't find an upgrade alternative that is sensible, leave it un-upgraded and try again in a few days. This time upgrade has been one of the more challenging ones to track in unstable, but patience and actually reading the reasons that dpkg reports for why it wants to do something has gotten me through it.
- neilv 2y ago
  Back when I was running Debian `unstable` (Sid?), I was always slightly nervous that an update could make the system unbootable, or otherwise ruin my day, when I had other things to do. So I wrote a lighthearted theme song for `unstable` updates. I don't recall most of it offhand, but it was to the tune of "Cat's in the Cradle": o/~ What I'd really like now is to update your libc. See you later, can you apt-get please? At some point, Linux software stopped improving so quickly, and Debian Stable seemed better. And I've been very happy with it, for most all startup and personal purposes.
  - Grimeton 2y ago
    (S)id (I)s (D)angerous
    - 2y ago

__s 2y ago

Note this only matters for 32 bit systems. Good to see tho > 64-bit architectures are not affected by the y2k38 problem, but they are affected by this transition. ^ surprised by this line. guess it also impacts lib32 packages on amd64 Little surprised it didn't happen sooner, but guess 64bit transition dampened urgency. Looks like it was waiting on changes in glibc etc. Unfortunately the remaining 32bit space is less likely to support upgrades

Denvercoder9 2y ago
> ^ surprised by this line. guess it also impacts lib32 packages on amd64 The reason for this is that in Debian, package name and ABI are coupled, as that allows you to coinstall multiple versions of libraries with different ABIs. This transition changes the ABI on 32-bit architectures, so the package name of impacted packages also has to change (they get a "t64" suffix). While it's technically possible to have different package names on different architectures, that's a PITA to deal with, so they opted to also change the package names on 64-bit architectures, where it's not strictly required.

juujian 2y ago

I just went through this transition in Debian testing, I suppose. I wasn't aware it was going to happen, and I didn't have a chance to install updates for two weeks prior, which I usually do every day. It wasn't gracefully. I don't know for sure if that's the transition is the cause, but I managed to break network- manager while updating. Had to load the Deb from my phone and transfer it over since I'm travelling. I managed to force the install but broke KDE in the process. I had to figure out how to connect to the internet from the console and reinstall KDE. That would have been much easier had I not been on the road.

seba_dos1 2y ago
The golden rule when using testing/unstable is: when apt wants to remove packages, double-check everything before proceeding. Really, it's that simple.
- juujian 2y ago
  Yeah, reading comprehension is one of my weaknesses tbh.

WirelessGigabit 2y ago

> 64-bit architectures are not affected by the y2k38 problem, but they are affected by this transition. I read the article with my limited knowledge and I couldn't find an explanation for this statement. Can someone elaborate?

bun_terminator 2y ago
(here stood something wrong because I've been working with 32bit code for too long recently)
- CamperBob2 2y ago
  In Win32 builds, it's been necessary to request legacy 32-bit time_t structures explicitly with _USE_32BIT_TIME_T for many years, for what that's worth. 64-bit time_t has been the standard for a while.
  - bun_terminator 2y ago
    ow, a stark reminder that I've worked with out 32bit code for far too long
- TonyTrapp 2y ago
  > but in general time_t is commonly an int32 type - doesn't matter what OS it compiles on Maybe 20 years ago, but these days you cannot make such a generalization. For example, VC++ uses a 64-bit time_t even in 32-bit builds unless you explicitly define _USE_32BIT_TIME_T. on 64-bit builds, a 32-bit time_t would be an illegal configuration that won't even build.
zinekeller 2y ago
I would initially assume that the problem is due to compatibility concerns (like NFS3 requiring 32-bit timestamps), but is instead a rather Debian-specific problem: Or we can do library transitions for the set of all libraries that reference time_t in their ABI; this is a bit more work for everyone in the short term because it will impact testing migration across all archs rather than being isolated to a single port, but it’s on the order of 500 library packages which is comparable to other ABI transitions we’ve done in the past (e.g. ldbl https://lists.debian.org/debian-devel/2007/05/msg01173.html).

blahgeek 2y ago

It bothers me that they are only doing the transition now. It should have been done 20 years ago. 2038 is less than 15 years away and I bet a significant portion of systems will not be upgraded during this period. (As a reference, Windows 7 was released 15 years ago and it's still on 3% usage share [1].) What's worse, compared to Y2K problem, in 2038, much more critical infrastructures will depend on computers (payment, self-driving cars, public transportation, security cameras, etc etc). We are doomed. [1] https://en.wikipedia.org/wiki/Template:Windows_usage_share https://en.wikipedia.org/wiki/Template:Windows_usage_share

Denvercoder9 2y ago
Note that for most systems this transition already happened with the transition to 64-bit architectures, in the 2000s. It's only 32-bit architectures to which the current transition applies. Debian couldn't have transitioned them 20 years ago, as kernel support for 64-bit time_t on a 32-bit architecture is fairly recent (Linux 5.6 in 2020).
- asveikau 2y ago
  I remember OpenBSD working on this about 10 years ago. Also, strictly speaking transitioning with the CPU architecture is not enough -- having kernel APIs and ABIs have 64-bit time_t is not the only place it needs to change. Notably, it has to change in the filesystem too. And at that point millions of people will have on-disk structures with 32bit timestamps, so it needs to transition in a somewhat back compatible way.
- phaedrus 2y ago
  Except some communication protocols have a 32 bit timestamp baked into the format.
htjrjfjtktn 2y ago
[flagged]
tomxor 2y ago
> 2038 is less than 15 years away and I bet a significant portion of systems will not be upgraded during this period. No, Linux distro releases are not like Windows, there is little reason to be holding back and running 15 year old systems. If you are running Debian 12 in 2038, lack of t64 will be the least of your issues. Debain 12 standard LTS ends in 2028 [0] and extended support (if you pay for it) ends in 2033 [1]. Beyond that you're on your own. If you're running servers, you'd be mad to be running any the current stable and old-stable releases by then. [0] https://wiki.debian.org/LTS https://wiki.debian.org/LTS [1] https://wiki.debian.org/LTS/Extended https://wiki.debian.org/LTS/Extended

dmd 2y ago

The 64-bit time transition ensures Unix time can be used far, far into the future, as described in Vernor Vinge's "A Deepness in the Sky": > Pham Nuwen spent years learning to program/explore. Programming went back to the beginning of time. It was a little like the midden out back of his father’s castle. Where the creek had worn that away, ten meters down, there were the crumpled hulks of machines—flying machines, the peasants said—from the great days of Canberra’s original colonial era. But the castle midden was clean and fresh compared to what lay within theReprise ’s local net. There were programs here that had been written five thousand years ago, before Humankind ever left Earth. The wonder of it—the horror of it, Sura said—was that unlike the useless wrecks of Canberra’s past, these programs still worked! And via a million million circuitous threads of inheritance, many of the oldest programs still ran in the bowels of the Qeng Ho system. Take the Traders’ method of timekeeping. The frame corrections were incredibly complex—and down at the very bottom of it was a little program that ran a counter. Second by second, the Qeng Ho counted from the instant that a human had first set foot on Old Earth’s moon. But if you looked at it still more closely. . .the starting instant was actually some hundred million seconds later, the 0-second of one of Humankind’s first computer operating systems. (Yes, Vinge made a slight error here - it's only about 14 megaseconds from Armstrong to the epoch, not 100.)

shmerl 2y ago

It got over most of the blockers it seems, but it's really monstrous in scope.

ComputerGuru 2y ago

Debian is one of the few distros still offering a tier-1, first-party i686 target in 2024. Even a lot of derivative distros (i.e. where it would be minimal effort to do the same) have dropped i686. Given the enormous scope of this transition, I have to wonder how many will be benefiting from this 15 years from now. I don’t question it will have utility, but I wonder about the ROI.

agwa 2y ago
Debian is not switching to 64-bit time_t on their x86 architecture, because they see it as a legacy architecture whose primary use is running legacy binaries. This transition is mainly to benefit 32-bit ARM since it's likely to be used in new systems for many more years.
- pwdisswordfishc 2y ago
  Wow, so the multi-hour package conflict resolution I am going through RIGHT NOW on my 2004 laptop is completely pointless? Good to know.
  - snvzz 2y ago
    You'd be better off switching to a non-linux system on that hardware. Ideally something that uses 64bit offsets and time_t.
deleted 2y ago
[deleted]
actionfromafar 2y ago
Adjusted for coolness points the ROI is pretty good, though. :) Besides, maybe there will be some digital (ARM?) dust running 32-bit Debian in the future.
pabs3 2y ago
Debian is dropping i686 too. You won't be able to install it soon. Also, the t64 fixes are not happening on i386, since the ABI change that the t64 changes do would break proprietary binaries, and Debian cares more about that use case than about people with ancient i386 hardware, who should just upgrade to amd64 anyway.