9 ms·
Debian switches to 64-bit time for everything
- snvzz 1y ago>for everything Except x86.
- pilif 1y ago"everything" for those values of "everything" that do not include one of the most (if not the most) widely used 32 bit architectures. (snark aside: I understand the arguments for and against making the change of i386 and I think they did the right thing. It's just that I take slight issue with the headline)
- pantalaimon 1y agoI doubt that i386 is still widely used. You are more likely to find embedded ARM32 devices running Linux, for x86 this is only the case in the retro computing community.
- Ekaros 1y agoIntel Core 2 starting their 64bit CPUs is 20 years old next year. Athlon 64 is over 20 years old... I wonder truly how many real computers and not just VMs there is left.
- pantalaimon 1y agoThe later Prescott Pentium 4 was already supporting 64 bit, but Pentium M / first generation Atom did not.
- pilif 1y agoI wasn't discounting VMs with my initial statement. I can totally imagine quite a few VMs still being around, either migrated from physical hardware or even set up fresh to conserve resources. Plus, keeping i386 the same also means any still available support for running 32 bit binaries on 64 bit machines. All of these cases (especially the installable 32 bit support) must be as big or bigger than the amount of ARM machines out there.
- bobmcnamara 1y agoOpt in numbers here: https://popcon.debian.org/ https://popcon.debian.org/
- pilif 1y agothat tells me my snark about i386 being the most commonly used 32 bit architecture wasn't too far off reality, doesn't it?
- bobmcnamara 1y agoIndeed - i386 is certainly the most common 32-bit Debian platform. Note also that the numbers are log-scale, so while it looks like Arm64 is a close third over all bitwidths, it isn't.
- School-Cotton 1y agoI'm actually amazed by this, I would have bet a lot on aarch64 being second.
- bobmcnamara 1y agoDebian doesn't support Arm64 Mac...
- School-Cotton 1y agoYou can run whatever distro you want in a VM, though. My daily driver is GuixSD in an aarch64 VM on a Mac. I wouldn’t recommend guixsd if you don’t love tinkering and troubleshooting, but otherwise the setup works fine.
- axus 1y agoIn the Linux binary context, do i386 and i686 mean the same thing? i686 seems relatively modern in comparison, even if it's 32-bit.
- jart 1y ago8.8 percent of Firefox users have 32-bit systems. It's probably mostly people with a 32-bit install of Windows 7 rather than people who actually have an old 32-bit Intel chip like Prescott. Intel also sold 32-bit chips like Intel Quark inside Intel Galileo boards up until about 2020. https://data.firefox.com/dashboard/hardware https://data.firefox.com/dashboard/hardware People still buy 16-bit i8086 and i80186 microprocessors too. Particularly for applications like defense, aerospace, and other critical systems where they need predictable timing, radiation hardening, and don't have the resources to get new designs verified. https://www.digikey.at/en/products/detail/rochester-electronics-llc/N80186/12122323 https://www.digikey.at/en/products/detail/rochester-electron...
- wongarsu 1y agoOn windows, encountering 32 bit software isn't all that rare. Running on 64 bit hardware on a 64bit OS, but that doesn't change that the 32bit software uses 32bit libraries and 32bit OS interfaces. Linux is a lot more uniform in its software, but when emulating windows software you can't discount i386
- pm215 1y agoIt's actually still pretty heavily used in some niches, which mostly amount to "running legacy binaries on an x86-64 kernel". LWN had an article recently about the Fedora discussion on whether to drop i386 support (they decided to keep it): https://lwn.net/Articles/1026917/ https://lwn.net/Articles/1026917/ One notable use case is Steam and running games under Wine -- there are apparently a lot of 32 bit games, including still some relatively recent releases. Of course if your main use case for the architecture is "run legacy binaries" then an ABI change is probably inducing more pain than it seeks to solve, hence the exception of it from Debian's transition here.
- deleted 1y ago[deleted]
- zokier 1y agoi386 is not really properly supported arch for trixie anymore: > From trixie, i386 is no longer supported as a regular architecture: there is no official kernel and no Debian installer for i386 systems. > Users running i386 systems should not upgrade to trixie. Instead, Debian recommends either reinstalling them as amd64, where possible, or retiring the hardware. https://www.debian.org/releases/trixie/release-notes/issues.en.html#reduced-support-for-i386 https://www.debian.org/releases/trixie/release-notes/issues....
- pavon 1y agoMost production use of 32-bit x86, like industrial equipment controllers, and embedded boards support i686 these days, which is getting 64-bit time.
- amelius 1y agoCan we also switch to unlimited/dynamic command line length? I'm tired of "argument list too long" on my 96GB system.
- loloquwowndueo 1y agoEver heard of xargs?
- amelius 1y agoSure. But it's not the same thing (instead of invoking the command once it invokes a command multiple times) and a workaround at best. And ergonomics are not great. Especially if you first type the command without xargs, and then find out the argument list is too long and you'll have to reformulate it but now with xargs.
- jcelerier 1y agoHow does that help with a GCC command line?
- tomsmeding 1y agoYou may already know this, but GCC supports option files: see "@file" at the bottom of this page https://gcc.gnu.org/onlinedocs/gcc/Overall-Options.html https://gcc.gnu.org/onlinedocs/gcc/Overall-Options.html . This does not detract from the point that having to use this is inconvenient, but it's there as a workaround.
- styanax 1y agoThe ARGS_MAX (`getconf ARGS_MAX`) is defined at the OS level (glibc maybe? haven't looked); xargs will also be subject to it's limitation like all other processes. One can use: xargs --show-limits --no-run-if-empty </dev/null ...to see a nicely formatted output include the -2048 POSIX recommendation on a separate line.
- jeroenhd 1y agoYou can recompile your kernel to work around the 100k-ish command line length limit: https://stackoverflow.com/questions/33051108/how-to-get-around-the-linux-too-many-arguments-limit https://stackoverflow.com/questions/33051108/how-to-get-arou... However, that sounds like solving the wrong end of the problem to me. I don't really know what a 4k JPEG worth of command line arguments is even supposed to be used for.
- ta1243 1y agoDisappointing, I was hoping for a nice consulting gig to ease into retirement for a few years about 2035, can't be doing with all this proactive stuff. Was too young to benefit from Y2K
- rini17 1y agoPlenty of embedded stuff deployed today will be there in 15 years, even with proactive push. Which is not yet done, only planned in few years mind you. Buying devkits for most popular architectures could prove good investment, if you are serious.
- wongarsu 1y agoCan confirm, worked on embedded stuff over a decade ago that's still being sold and will still be running in factories all over the world in 2038. And yes, it does have (not safety critical) y2k38 bugs. The project lead chose not to spend resources on fixing them since he will be retired by then
- nottorp 1y agoKeep your Yocto skills fresh :) All those 32 bit arm boards that got soldered into anything that needed some smarts won't have a Debian available. Say, what's the default way to store time in an ESP32 runtime? Haven't worked so much with those.
- bobmcnamara 1y ago64-bit on IDF5+, 32-bit before then
- delichon 1y agoI wasn't. A fellow programmer bought the doomsday scenario and went full prepper on us. To stock up his underground bunker he bought thousands of dollars worth of MREs. After 2k came and went with nary a blip, he started bringing MREs for lunch every day. I tried one and liked it. Two years later when I moved on he was still eating them.
- rini17 1y ago> Debian is confident it is now complete and tested enough that the move will be made after the release of Debian 13 "Trixie" – at least for most hardware. This means Trixie won't have it?
- zokier 1y agoRelease notes say it's in trixie: https://www.debian.org/releases/trixie/release-notes/whats-new.en.html#bit-time-t-abi-transition https://www.debian.org/releases/trixie/release-notes/whats-n...
- wongarsu 1y ago"All architectures other than i386 ..." So Trixie does not have 64-bit time for everything. Granted, the article, subtitle and your link all point out that this is intentional and won't be fixed. But in the strictest sense that GP was likely going for Trixie does not have what the headline of this article announces
- cbmuser 1y agoIt's not planned for i386 to avoid breaking existing i386 binaries of which there are a lot of them.
- TacticalCoder 1y ago[dead]
- efitz 1y agoThey’re just kicking the can down the road. What will people do on December 4, 292277026596, at 15:30:07 UTC?
- Ekaros 1y agoHopefully by them we have moved to better calendar... Not that it will change the timestamp issue.
- GoblinSlayer 1y agoBy that time we will have technology to spin Earth to keep calendar intact.
- freehorse 1y agoAnd also modify earth's orbit to get rid of the annoying leap seconds.
- saalweachter 1y ago"To account for calendar drift, we will be firing the L4 thrusters for six hours Tuesday. Be sure not to look directly at the thrusters when firing, to avoid having your retinas melt." "... still better than leap seconds."
- zokier 1y agorotation, not orbit.
- b3lvedere 1y agoStar Trek stardates?
- mrlonglong 1y agoToday, right now it's -358519.48
- lambdaone 1y agoNot all solutions are going with just 64 bits worth of seconds, although 64 bit time_t will certainly sort out the Epochalypse. ext4 moved some time ago to 30 bits of fractional resolution (on the order of nanoseconds) and 34 bits of seconds resolution. It punts the problem 400 years or so into the future. I'm sure we will eventually settle on 128-bit timestamps with 64 bits of seconds and 64 bits of fractional resolution, and that should sort things for forseeable human history.
- jmclnx 1y agoThanks, I was wondering about ext4 and time stamps. I wonder what the zfs/btrfs type file systems do. I am a bit lazy to check but I expect btrfs is using 64 bit. zfs, I would not be surprised if it matches zfs (edit meant ext4 here).
- XorNot 1y agoA quick glance at ZFS shows it uses a uint64_t time field in nanoseconds in some places. So 580 years or so till problems (but probably patchable ones? I believe the on disk format is already 2x uint64s, this is just the gethrtime() function I saw).
- RedShift1 1y agoWhat is the use of such high precision file timestamps?
- zokier 1y agonanoseconds is just common sub-second unit that is used. notably it is used internally in linux kernel and exposed via clock_gettime (and related functions) via timespec struct https://man7.org/linux/man-pages/man3/timespec.3type.html https://man7.org/linux/man-pages/man3/timespec.3type.html it is convenient unit because 10^9 fits neatly into 32 bit integer, and it is unlikely that anyone would need more precision than that for any general purpose use.
- 1y ago
- lioeters 1y ago> Debian's maintainers found the relevant variable, time_t, "all over the place," Nit: time_t is a data type, not a variable.
- scottlamb 1y agoThis is a reporter paraphrase of the Debian wiki page, which says: "time_t appears all over the place. 6,429 of Debian's 35,960 packages have time_t in the source. Packages which expose structs in their ABI which contain time_t will change their ABI and all such libraries need to migrate together, as is the case for any library ABI change." A couple significant things I found much clearer in the wiki page than in the article: * "For everything" means "on armel, armhf, hppa, m68k, powerpc and sh4 but not i386". I guess they've decided i386 doesn't have much of a future and its primary utility is running existing binaries (including dynamically-linked ones), so they don't want to break compatibility. * "the move will be made after the release of Debian 13 'Trixie'" means "this change is included in Trixie".
- panzi 1y agoThe problem is not time_t. If that is used the switch to 64 bit is trivial. The problem is when devs used int for stupid reasons. Then all those instances have to be found and changed to time_t.
- monkeyelite 1y agoIt is more difficult to evaluate what happens when sizeof(time_t) changes then to replace `int` with `time_t`, so I don't think that's the issue.
- qcnguy 1y agoIt's not very trivial. They have broken the userspace ABI for lots of libraries again. So all the package names change; it's annoying if you're distributing debs to users. They obviously have some ideological belief that nobody should do so but they're wrong.
- Denvercoder9 1y ago> They have broken the userspace ABI for lots of libraries again. If the old ABI used a 32-bit time_t, breaking the ABI was inevitable. Changing the package name prevents problems by signaling the incompatibility proactively, instead of resulting in hard-to-debug crashes due to structure/parameter mismatches.
- scottlamb 1y agoAll true, but qcnguy's point is valid. If you are distributing .deb files externally from their repo, on the affected architectures you need to have a pre-Trixie version and a Trixie-onward version.
- Denvercoder9 1y agoShipping separate debs is usually the easiest, but not the only solution. It's totally possible to build something that's compatible with both ABIs.
- thesuitonym 1y ago> Y2K38 bug – also known as the Unix Epochalypse Is it also known as that? It's a cute name but I've never seen anyone say it before this article. I guess it's kind of fetch though.
- Liftyee 1y ago> I guess it's kind of fetch though Do I spot a Mean Girls reference?!
- boomboomsubban 1y agohttps://en.wikipedia.org/wiki/Year_2038_problem https://en.wikipedia.org/wiki/Year_2038_problem >The year 2038 problem (also known as Y2038, Y2K38, Y2K38 superbug, or the Epochalypse) So yeah, but only since 2017 and as a joke.
- kittoes 1y agohttps://epochalypse-project.org/ https://epochalypse-project.org/
- ChrisArchitect 1y agoEpochalypse countdown: ~12 years, 5 months, 22 days, 13 hours, 22 minutes.....
- notepad0x90 1y agoI honestly think there won't be any big bugs/outages by 2038. Partly because I have a naive optimism that any important system will not only have the OS/stdlibs support 64bit time, but that important systems that need accurate time probably use NTP/network time, and that means their test/dev/qa equivalent deployments can be hooked up to use a test network time server that will simulate post-2038 times to see what crashes. 12 years+ is a long time to prepare for this. Normally I wouldn't have much faith in test/dev systems, network time being setup properly,etc...but it's a long time. Even if none of my assumptions are true, in a decade we couldn't at least identify where 32bit time is being used and plan for contingencies? that's unlikely. But hey, let me know when Python starts supporting nano-second precision time :'( https://stackoverflow.com/a/10612166 https://stackoverflow.com/a/10612166 Although, it's been a while since I checked to see they support it. In Windows-land at least, everything system-side uses 64bit/nsec precision, as far as I've had to deal with it at least.
- zbendefy 1y agoits 12 years not 22. An embedded device bought today may be easily in use 12 years from now.
- notepad0x90 1y agooops. fixed that.
- 0cf8612b2e1e 1y agoSoftware today has to be able to model future times. Mortgages are 30 years long. This is already a problem today which has been impacting software.
- mrweasel 1y agoMy concern is that this is happening 12 years to late. A bunch of embedded stuff will not be replaced in 12 years. We have a lot more tiny devices running all sorts of system, many more than we did 25 years ago. These are frequently in hard to reach places, manufacturers have gone out of business, no updates will be available and no one is going to 2038 validate those devices and their output. Many of the device going into production now won't have 64bit time, they'll still run version of Linux that was certified, or randomly worked, in 2015. I hope you're right, but in any case it will be worse than Y2K.
- joeyh 1y agoSteve Langasek decided to work on this problem in the last few years of his life and was a significant driver of progress on it. He will be missed, and I'll always think of him when I see a 64 bit time_t.
- AceJohnny2 1y agoThanks for the reminder, Joey. He is missed. Are you still involved in Debian?
- misja111 1y agoWhy would anyone want to store time in signed integer? Or in any signed numerical type?
- lorenzohess 1y agoSo that my Arch Linux box can still work when we get time travel.
- FlyingAvatar 1y agoI have wondered this as well and my best guess is so two times can be diffed without converting them to an signed type. With 64-bit especially, the extra bit isn't buying you anything useful.
- benmmurphy 1y agoYou can have an epoch and now you can measure times before the epoch. In terms of the range of values you can represent it transposes to just having the epoch further in the past and using an unsigned type. So signed/unsigned it should not really matter except maybe for particular languages things work better if the type is either signed or unsigned. For example if you try to calculate the difference between two times maybe its better if the time type is signed to match the result type which is signed as well (not that it solves the problems with overflow).
- LegionMammal978 1y agoSo that people can represent times that occurred before 1970? You could try adjusting the epoch to the estimated age of the universe, but then you run into calendar issues (proleptic Gregorian?), have huge constants in the common case (Julian Days are not fun to work with), and still end up with issues if the estimate is ever revised upward.
- bhaney 1y agoSome things happened before 1970
- toast0 1y ago
- godshatter 1y agoDon't 32-bit systems have 64-bit types? C has long long types and iirc a uint_least64_t or something similar. Is there a reason time_t must fit in a dword?
- poly2it 1y agoYes, 32-bit systemes have 64-bit types. time_t as a u32 is a remnant.
- wahern 1y ago> Don't 32-bit systems have 64-bit types? The "long long" standard integer type was only standardized with C99, long after Linux established it's 32-bit ABI. IIRC long long originated with GCC, or at least GCC supported it many years before C99. And glibc had some support for it, too. But suffice it to say that time_t had already been entrenched as "long" in the kernel, glibc, and elsewhere (often times literally--using long instead of time_t for (struct timeval).tv_sec). This could have been fixed decades ago, but the transition required working through alot of pain. I think OpenBSD was the first to make the 32-bit ABI switch (~2014); they broke backward binary compatibility, but induced alot of patching in various open source projects to fix time_t assumptions. The final pieces required for glibc and musl-libc to make the transition happened several years later (~2020-2021). In the case of glibc it was made opt-in (in a binary backward compatible manner if desired, like the old 64-bit off_t transition), and Debian is only now opting in.
- mojo-ponderer 1y agoWill this create significant issues and extra work to support Debian specifically right now? Not saying that we shouldn't bite the bullet, just curious how much libraries have been implicitly depending on the time type to be 32-bit.
- toast0 1y agoProbably less extra work right now than ten or twenty years ago. For one, OpenBSD (and others?) did this a while ago. If it breaks software when Debian does it, it was probably mostly broken. For another, most people are using 64-bit os and 64-bit userland. These have been running 64-bit time_t forever (or at least a long time), so it's no change there. Also, someone upthread said no change for i386 in Trixie... I don't follow Debian to know when they're planning to stop i386 releases in general, but it might not be that far away?
- zdw 1y agoOnly 11 years after OpenBSD 5.5 did the same change: https://www.openbsd.org/55.html https://www.openbsd.org/55.html
- keysdev 1y agoA bit off topic, but its time like this that really make me wanting to swap out the public facing server from Linx to OpenBSD
- mardifoufs 1y agoOpenBSD doesn't have to care about compatibility as much, and has orders of magnitude less users. Which also means that changes are less likely to cause bugs from obscure edge cases.
- zdw 1y agoOpenBSD (and most other BSDs) are willing to make changes that break binary backwards compatibility, because they maintain and ship both the kernel and userland together as a release and can thus "steer the whole ship", rather than the kernel being it's own separate component developed like with Linux.
- mardifoufs 1y agoSure, that's usually true, but Debian also has that ability in this case ( they can fix, patch, or update everything in the repository). The issue is mostly with all software that isn't part of the distribution and the official repositories. Which is a lot of software especially for Debian. OpenBSD doesn't have that issue, breaking the ABI won't cause tens of thousands of user applications to break. But I agree that Debian is still too slow to move forward with critical changes even with that in mind. I just don't think that OpenBSD is the best comparison point.
- anthk 1y agoGuess where OpenSSH comes from.
- nsksl 1y agoWhat solutions are there for programs that can’t be recompiled because the source code is not available? Think for example of old games.
- deleted 1y ago[deleted]
- zelphirkalt 1y agoProbably changing the system time, or faking the system time, so that these programs do not run into issues.
- Joel_Mckay 1y agoOr party like its epoch time. =3
- CodesInChaos 1y agoProbably a backwards compatible runtime that uses 32-bit timestamps which fills in a fake time after 2038 (e.g 1938). For example steam ships different runtimes, as does flatpak.
- Dwedit 1y agoIf anyone is serializing 32-bit times as a 32-bit integer, the file format won't match anymore. If anyone has a huge list of programs that are affected, you've solved the 2038 problem.
- kstrauser 1y agoKragen, get in here and comment. This is your shine to time.
- larrik 1y ago> Readers of a certain vintage will remember well the "Y2K problem," caused by retrospectively shortsighted attempts to save a couple of bytes by using two-digit years – meaning that "2000" is represented as "00" and assumed to be "1900." This seems overly harsh/demeaning. 1. those 2 bytes were VERY expensive on some systems or usages, even into the mid-to-late 90's 2. software was moving so fast in the 70s/80's/90's that you just didn't expect it to still be in use in 5 years, much less all the way to the mythical "year 2000"
- cogman10 1y agoThis is a case where "premature optimization" would have been a good thing. They could have represented dates as a simple int value 0ed at 1900. The math to convert a day number to a day/month/year is pretty trivial even for 70s computers and the end result would have been saving more than just a couple of bytes. 3 bytes could represent days from 1900->~44,000 (unsigned). Even 2 bytes would have bought ~1900->2070
- School-Cotton 1y agoThere were plenty of people born in 1899 who were still alive in 1970, so you couldn't e.g. use your system to store people's birth dates.
- Y_Y 1y agoI think GP meant uint, but by my book int should have a sign bit, so that grampa isn't born in the future.
- tremon 1y agoThe only reason why a system can only represent the range from 1900-1999 is when the system uses characters (ascii decimal digits) or BCD encoded digits. It would have been very unlikely for any integer-based encoding system to have had a cutoff date at 1999 (e.g. int8 would need an epoch at 1872 to rollover after 1999), so I don't think signed vs unsigned makes a difference here.
- cbmuser 1y ago»Venerable Linux distribution Debian is side-stepping the Y2K38 bug – also known as the Unix Epochalypse – by switching to 64-bit time for everything but the oldest of supported hardware, starting with the upcoming Debian 13 "Trixie" release.« That's inaccurate. We actually switched over all 32-bit ports except i386 because we wanted to keep compatibility for this architecture with existing binaries. All other 32-bit ports use time64_t, even m68k ;-). I did the switch for m68k, powerpc, sh4 and partially hppa.
- ldng 1y agoSince your nitpicking, I can't resist myself ^^ I would say that it's not inaccurate but, eventually, less precise. And wouldn't you say that i386 IS the oldest arch ? ;-)
- stefantalpalaru 1y ago[dead]
- burnt-resistor 1y agoSettle it once and for all: C and POSIX should adopt the TAI64NA format for time_t with attosecond precision.[0] And no leap seconds.[1] ;@) 0. https://cr.yp.to/libtai/tai64.html https://cr.yp.to/libtai/tai64.html 1. https://cr.yp.to/proto/utctai.html https://cr.yp.to/proto/utctai.html
- Paianni 1y agoJust in time to drop 32-bit x86.
- LoveMortuus 1y agoI don't quite understand this, does it mean that Debian will no longer support 32-bit computers or is this something different?