Debian looks forward to 2038
The time_t rollover is still over 14 years away, so solving it might not appear to be an urgent problem. The fact that it does not affect most 64-bit systems may also encourage complacency. But there are affected 32-bit systems on the market now, and some of them are likely to still be operating in 2038; that is especially true of embedded systems, which might prove harder to fix as the date approaches. It would be far better if these systems were prepared for 2038 at deployment time; that means solving the problem as quickly as possible.
Work has been underway in the kernel for some years, and it is mostly free of year-2038 problems at this point. The GNU C Library (glibc) has also seen a considerable amount of work to allow it to handle both 32-bit and 64-bit time_t values, depending on how a program has been compiled. So the core of a Linux system is ready, but there is a lot more than that to the problem.
Steve Langasek recently posted a plan
for completing the year-2038 transition in Debian, in time for the upcoming
"Trixie" release, likely
to arrive in 2025. Rejecting the idea of completely rebuilding the
affected Debian ports with the new ABI ("this makes upgrades unreliable,
and doesn't help any ports for which we don’t do this work
"), the plan
calls for rebuilding every affected library to use 64-bit time_t,
thus creating a breaking ABI change for each. Simply finding all of the
affected libraries is a non-trivial task, and that is just the beginning:
Based on the analysis to date, we can say there is a lower bound of ~4900 source packages which will need to be rebuilt for the transition, and an upper bound of ~6200. I believe this is a manageable transition, and propose that we proceed with it at the start of the trixie release cycle.
The plan, in short, calls for rebuilding each library that includes time_t somewhere in its ABI, and renaming the library by adding t64 to its name (thus allowing the older library to stay in place initially). Once all packages have been rebuilt to use the new libraries, the old ones can be removed and the t64 suffix taken off again.
An LFS flashback
There is an interesting twist that shines a light on how hard these transitions can be; it's time for a brief historical digression. Originally on Linux, the off_t type used to express an offset within a file was a signed, 32-bit integer; on 32-bit systems, it might still be. As a result, no file on a Linux system could be larger than 2GB in size. Such files seemed reasonably large in the early 1990s; according to Wikipedia, 1990 saw the release of the gigantic IBM 0681 drive, with a capacity of 857MB. Now, of course, 2GB might hold a stripped-down "hello world" binary or a low-budget car-warranty spam email, but not much more.
Once money started pouring into Linux development, the file-size limit was recognized to be a problem and a focused effort was made to use 64-bit offsets ("loff_t") throughout the kernel; the result was part of the 2.4.0 kernel release at the beginning of 2001. As of that release, the kernel can handle file sizes so large that we will surely never run into limits again; problem solved.
Except, of course, for the little problem that user space needed to be updated to use 64-bit file offsets — a problem that should be looking familiar at this point. Glibc added an option to build with large file support (LFS), and applications could be built to use that support. Over time, distributions make the transition to LFS, and file-size limits have rarely been a problem.
Debian, it seems, has not completed that transition; LFS is still an open release goal.
As Guillem Jover put it:
"we are still not done with LFS, and I'm not seeing the end of
that
". LFS might not be relevant to the time transition, other than as
a historical precedent, except for one little detail: the glibc developers,
in an effort to reduce the number of combinations they must support, have
decreed that enabling 64-bit time support will also enable large-file
support. So any application that is to be made ready for post-2038
time_t values must also be made ready for post-2001 file sizes.
Langasek did not say how many packages would need to gain LFS support in this transition, but he did mention that there are about 80 packages that don't use time_t, but which would be broken by enabling LFS. To avoid forcing an LFS transition on those packages, a special build-system tweak would be added to allow them to remain in an era when drive sizes were measured in megabytes. In the discussion, Richard Laager suggested just forcing the LFS transition on those packages as a way to simplify the problem, but it's not clear that things will go that way.
Excepting i386
In general, there does not seem to be much disagreement over this plan,
with one exception relating to an exception within the plan itself. The
year-2038 transition is aimed at 32-bit Arm platforms; the i386 port,
instead, would be passed over. "Because i386 as an architecture is
primarily of interest for running legacy binaries which cannot be rebuilt
against a new ABI, changing the ABI on i386 would be
counterproductive
". Helmut Grohne wrote that
there was no consensus on that decision, and that making an exception of
i386 would create a divergence within the Debian project that would make
ongoing maintenance much harder:
Maintaining this kind of divergence has a non-trivial cost. Over time it becomes more and more difficult and less and less people are interested in doing it. As such, I see the addition of this kind of divergence as a way of killing i386.
He suggested that, perhaps, a general resolution to decide the fate of the i386 port would be the best way forward.
Simon McVittie responded that there were two fundamentally different use cases for the i386 port: as a fully featured architecture and as a way to run old binaries on current, 64-bit systems. The former case, he said, makes little sense at this point, while the latter remains important. People using the i386 port for old binaries are often running games, and those games will normally run just fine even if they do think it's 1970. They will not run, though, if libraries supporting 32-bit times are not available. Thus, he said, transitioning i386 to 64-bit time_t would actively harm its most important user base.
As a Steam developer, he could be expected to feel that way, especially
since the Steam client itself is one of those legacy binaries. Others,
though, agreed with him; Marco d'Itri said that
"an i386 port which cannot run old i386 binaries would be almost
useless
". Gunnar Wolf also agreed, and
suggested that a future i386 port could be pared down to the packages needed
to run those binaries. Paul Wise asked
whether the port could support both 32-bit and 64-bit times, noting that
glibc has that support. McVittie answered
that many other libraries, some of which are deprecated or "on
life-support
", would be difficult to support in this mode.
Langasek disagreed with Grohne, saying that the opposition to the i386 exception came mostly from people who are not Debian developers. Grohne eventually came around and changed his view on the plan and the community's sentiment:
I now see significantly more voices for the opinion:i386 primarily exists for running legacy binaries and binary compatibility with legacy executables is more important than correct representation of time beyond 2038.
There was some disagreement with this summary — this is Debian, after all —
with developers like Thorsten Glaser calling
for "a long-term commitment against electronic waste
" and
ongoing support for i386. There was some discussion over whether it is
better to replace old and inefficient hardware with modern systems or to
simply keep them running, but nothing resembling a groundswell of support
for transitioning i386 appeared. The fact that the project is not overrun
with developers volunteering their time to keep a fully supported i386 port
working also plays into this decision.
So it appears that the Debian project will proceed with the year-2038
transition plan as described by Langasek at the beginning of the
discussion. Most 32-bit platforms will be made safe for operation after
January 2038, while i386 will remain safe for game playing. The Debian
project is often not the first to get a task like this done, but its
developers do get there eventually.
Posted Jul 17, 2023 14:40 UTC (Mon)
by smcv (subscriber, #53363)
[Link]
Posted Jul 17, 2023 14:59 UTC (Mon)
by smcv (subscriber, #53363)
[Link] (20 responses)
For some quite broad classes of application and library, file-size limits have never been a problem even without LFS, and probably never will be: quite a lot of code will only ever open small text files (such as configuration) and is relatively unlikely to ever see a file size measured in gigabytes, or even in megabytes.
The bigger problem with non-LFS 32-bit binaries is that when the size of the off_t in struct stat was increased for LFS, kernel and glibc developers took the opportunity to also allocate more space for the inode number. On some modern filesystems, the inode number can be too large for a non-LFS struct stat, which will make stat() fail with EOVERFLOW when trying to inspect the file. Unlike the size, inode numbers are opaque values chosen by the filesystem, meaning there is no correlation between having "reasonably small" files and having "reasonably small" inode numbers.
For example, implementations of D-Bus are unlikely to need to access large files (the machine ID, dbus-daemon configuration and .service files are typically tens to hundreds of bytes), but they do need to access files that might have a large inode number, which is why libdbus has been built with large file support since 2016.
Posted Jul 17, 2023 15:15 UTC (Mon)
by sam_c (subscriber, #139836)
[Link] (18 responses)
Florian brought it up on the kernel MLs recently at https://lore.kernel.org/all/87cz0w1bd0.fsf@oldenburg.str.... for btrfs, but it of course happens with e.g. xfs as well.
Some games on Steam seem to even discourage use of anything with 64-bit inodes:
Posted Jul 17, 2023 16:14 UTC (Mon)
by smcv (subscriber, #53363)
[Link] (13 responses)
> For ABI reasons, we can't switch everything to 64-bit ino_t and LFS
Posted Jul 17, 2023 18:16 UTC (Mon)
by quotemstr (subscriber, #45331)
[Link] (12 responses)
Posted Jul 17, 2023 19:04 UTC (Mon)
by amarao (subscriber, #87073)
[Link] (1 responses)
Also, it's a good time to adjust timezones to accommodate Nepalian +2'15" into all timezones. And use daylight saving temperature adjustments twice a year.
Posted Jul 17, 2023 19:26 UTC (Mon)
by quotemstr (subscriber, #45331)
[Link]
Posted Jul 17, 2023 19:44 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link] (7 responses)
Posted Jul 17, 2023 20:35 UTC (Mon)
by willy (subscriber, #9762)
[Link] (6 responses)
Posted Jul 17, 2023 21:07 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link] (5 responses)
I've heard that they have just fixed it recently, so they won't have to do that again for 2030-s.
Posted Jul 18, 2023 7:43 UTC (Tue)
by taladar (subscriber, #68407)
[Link] (4 responses)
Posted Jul 18, 2023 23:21 UTC (Tue)
by NYKevin (subscriber, #129325)
[Link] (3 responses)
Unfortunately, most companies are various shades of incompetent, so that doesn't work out nearly as often as it should.
Posted Jul 19, 2023 0:40 UTC (Wed)
by pizza (subscriber, #46)
[Link] (2 responses)
...especially when the word "sharepoint" is involved, heh.
But it's actually worse than that; these days documentation is now routinely, intentionally, *destroyed*. In my experience this is due to two factors. First, maintaining old documentation is seen as a cost with only theoretical benefits. Secondly, and far more importantly, documentation you don't have can't be discovered in a lawsuit. [1]
[1] And as long as it's automatically destroyed according to your "retention" policy, you can't be accused of intentionally destroying evidence after the fact.
Posted Jul 19, 2023 18:00 UTC (Wed)
by Lennie (subscriber, #49641)
[Link] (1 responses)
Unless of course you are the kind of business which deals with those lawsuits.
Posted Jul 20, 2023 5:59 UTC (Thu)
by nilsmeyer (guest, #122604)
[Link]
Also prevents you ever hitting any file size limits if you keep deleting useful documentation ;)
Posted Jul 24, 2023 23:12 UTC (Mon)
by DemiMarie (subscriber, #164188)
[Link] (1 responses)
This is why i386 is such a special case: except for some microcontrollers that I believe cannot run Linux, I believe there has not been new 32-bit-only x86 hardware since 2004. The only purpose of i386 is for compatibility with legacy or proprietary binaries that cannot be recompiled. I strongly suspect that virtually all such programs are not receiving security patches, which means they should not be connected to the Internet. Therefore, such programs most likely do not need to know the actual time and can use faketime or a similar solution.
Posted Jul 25, 2023 9:56 UTC (Tue)
by james (subscriber, #1325)
[Link]
Intel's (pretty pointless) Quark embedded processors had Linux support (PDF). They were discontinued in 2019.
The Vortex86 line of 32-bit embedded controllers (based on the old Rise CPU family from the late 1990s) are still on sale and certainly could run Linux, although support for them has bit-rotted.
Posted Jul 18, 2023 7:59 UTC (Tue)
by dezgeg (subscriber, #92243)
[Link] (3 responses)
Posted Jul 21, 2023 10:26 UTC (Fri)
by make (subscriber, #62794)
[Link] (2 responses)
Posted Jul 21, 2023 19:50 UTC (Fri)
by dezgeg (subscriber, #92243)
[Link] (1 responses)
Posted Jul 27, 2023 8:35 UTC (Thu)
by Vorpal (guest, #136011)
[Link]
Posted Jul 18, 2023 18:42 UTC (Tue)
by meyert (subscriber, #32097)
[Link]
Posted Jul 17, 2023 15:13 UTC (Mon)
by sam_c (subscriber, #139836)
[Link] (1 responses)
First, the need for cross-distro coordination on this. We want 32-bit arm binaries built on Debian to be compatible with e.g. Gentoo. That's going to likely involve picking a new CHOST (transform at least, even if not the same CHOST value itself) and doing it roughly around the same time.
Secondly, that this isn't properly solved in glibc itself.
Our notes on the matter are at https://wiki.gentoo.org/wiki/Project:Toolchain/time64_mig...
There remain open questions about how to handle this in glibc itself, and nobody seems very motivated to figure out how to solve them:
(With regard to LFS: while yes, glibc did decide to tie the two together, it was somewhat unavoidable anyway given some structures involve both off_t and time_t.)
Posted Jul 17, 2023 15:17 UTC (Mon)
by sam_c (subscriber, #139836)
[Link]
Posted Jul 17, 2023 15:36 UTC (Mon)
by quotemstr (subscriber, #45331)
[Link] (19 responses)
Posted Jul 17, 2023 16:37 UTC (Mon)
by smcv (subscriber, #53363)
[Link] (17 responses)
If there's enough interest in an incompatible "modern i386" port, then yes, it would be possible to have the existing i386-linux-gnu port for legacy binaries, combined with a new port with multiarch tuple i386-linux-gnut64 (or something) to be able to run a modern OS on old hardware (and in fact that was proposed elsewhere in the debian-devel thread).
If we want to do that, then we'll need a new dpkg architecture, i386t64 or something, because the i386 dpkg architecture is defined to be the i386-linux-gnu multiarch tuple as a matter of permanent ABI.
We'll also need a new combination of ELF flags to mark binaries as compatible or incompatible, because the whole point of this exercise is to avoid crashing when an i386 executable loads an i386t64 library (or vice versa) and they disagree on how much stack space is needed for struct stat. Using the multiarch library directories for co-installability is not enough, because things like LD_PRELOAD, LD_LIBRARY_PATH and RPATHs exist, and in any case the dynamic linker neither knows nor cares about Debian-style multiarch - all it sees is a sequence of possible library directories, containing libraries which are a mixture of compatible and incompatible with the current process.
By default, ELF class (word size) ELFCLASS32 combined with machine EM_386 is the old i386-linux-gnu ABI, and that can't change without breaking legacy binaries. ELFCLASS64 with EM_X86_64 is already taken (for x32) so we can't use that either.
There might be scope for adding flags in e_flags to distinguish between the "legacy" and "new" ABIs, similar to EF_ARM_OLD_ABI and EF_ARM_NEW_ABI, or EF_ARM_ABI_FLOAT_SOFT and EF_ARM_ABI_FLOAT_HARD; with the glibc dynamic linker taught to only load objects whose e_flags are compatible with the current executable? But as far as I'm aware, that work has not yet been done in glibc, and it will only be done if someone cares enough about i386 use-cases that are not "I want to continue to run this legacy binary".
(I'm using i386 as my example because it's probably the architecture with the most legacy binaries, but all of this would apply equally to any pre-existing architecture with 32-bit time_t.)
Posted Jul 17, 2023 17:18 UTC (Mon)
by quotemstr (subscriber, #45331)
[Link] (9 responses)
Posted Jul 17, 2023 17:51 UTC (Mon)
by mjg59 (subscriber, #23239)
[Link]
Posted Jul 17, 2023 18:18 UTC (Mon)
by MarcB (subscriber, #101804)
[Link] (7 responses)
As far as I can tell, the dominant use case for the i386 ABI - by a very large margin - is running legacy applications that cannot be recompiled. And if you can recompile, then why use a new ABI in the first place? Just compile everything with a 64 bit time_t and ensure everything uses the *time64 syscalls.
Posted Jul 17, 2023 18:34 UTC (Mon)
by quotemstr (subscriber, #45331)
[Link] (6 responses)
Posted Jul 17, 2023 21:52 UTC (Mon)
by smcv (subscriber, #53363)
[Link]
Posted Jul 18, 2023 13:59 UTC (Tue)
by MarcB (subscriber, #101804)
[Link] (4 responses)
Arguably, Linux i386 is a purely historic architecture, while 32-Bit ARM is still alive (as is Windows i386, for whatever reasons). So, for i386 the plan IMHO must be "don't break existing applications, no matter what".
For ARM the approach might very well be different Here, we can assume that we can recompile applications or that binary-only application are still supported.
Posted Jul 19, 2023 8:54 UTC (Wed)
by knewt (subscriber, #32124)
[Link] (1 responses)
Without doing any in-depth investigation, my first thought about Windows i386 would be ancient legacy 16-bit applications. 64-bit Windows only supports 64-bit and 32-bit applications, while 32-bit Windows supports 32-bit and 16-bit applications.
Now, how many legacy 16-bit applications are still being run, who knows. A larger issue though is that a fair number of 32-bit applications happened to use a 16-bit installer :)
Posted Jul 20, 2023 15:41 UTC (Thu)
by MarcB (subscriber, #101804)
[Link]
I meant 32 bit applications running on 64 bit Windows. New 32 bit Windows applications are still appearing all the time. I don't really know why.
Posted Jul 20, 2023 10:47 UTC (Thu)
by hkario (subscriber, #94864)
[Link] (1 responses)
Posted Jul 20, 2023 13:04 UTC (Thu)
by dtlin (subscriber, #36537)
[Link]
Posted Aug 6, 2023 0:13 UTC (Sun)
by Kamilion (subscriber, #42576)
[Link] (1 responses)
No silly suffixes or prefixes, no refactoring of legacy scripts, and i686-linux-gnu is already used in several places; while i786-linux-gnu is currently completely absent.
It almost perfectly encapsulates "I am an i686 with extended non-optional 64bit support"
Double worth if qemu and kvm start treating it like the google Goldfish m68k virtual platform, as a 'hard' virtual target instead of i440bx/ich9. "If you have the appropriate signed drivers, and you assume paravirtualization is mandatory, all the better."
There's no reason for the ich9/440bx code to go away; it has it's specific niche of reusing existing drivers, signed or freestanding. We already have dosbox for SB16/Win3.1 with VESA extensions.
There are "still good reasons" with which people compile against 32bit targets, most typically to save immense amounts of runtime memory, but with the implicit tradeoff of only 1GB of usable userspace without PAE. And even with it, there's remapping shenanigans afoot.
<s>
And, since I've got someone in the thread who's been working on the steam runtime; please, I'm begging you to keep the xen paravirtualization drivers enabled in the builds.
All the better if we could come up with a simplified paravirtualized graphics adapter that can handle 3D acceleration and audio.
I believe one of the major things preventing steam and friends from taking over is fundamentally in the support of graphics and sound.
I'd really love the AMD engineers working on ROCm to pop in with a modern paravirtualized unified "Human Interface Console" device class that implicitly handled most of the problems we've historically had with multiseat.
Take AMD's "Promonitory" chipset, ostensibly an ASMedia PCIe switch with AHCI and EHCI controllers.
Now spin that same concept with a 2CU AMDGPU 'framebuffer', EHCI and Alpine Ridge Thunderbolt3 / USB4 endpoint, and the ubiquitous "HDMI Audio" adapter that rides along with most of their GPUs.
A PCIe switch with a vulkan-capable "minimal" GPU which can be coherently written into by other GPUs, latency-synched audio, and USB ports that do not share a root-port with the host system.
A single paravirtualized endpoint designed around virtual and physical hardware could resolve most of this legacy insanity, compartmentalize the legacy aspects, and encapsulate them for safe reuse in modern containers.
(Side note: Since 2015, I've been working on trying to pack a steam-like interface directly into the platform firmware by leveraging Xen. The missing pieces are, of course, accelerated graphics and sound synchronization/latency-control. Off the shelf motherboard, rammed a 256MB SPI NAND device next to the existing 32MB SPI NOR device. Since they use different JEDEC commands, they don't fight. TORAM=Yes is my savior.)
Posted Aug 6, 2023 0:59 UTC (Sun)
by Kamilion (subscriber, #42576)
[Link]
When I say this, I meant that the character count was equal and most software uses i?86 and doesn't particularly care about the distinction between 3, 4, 5, and 6. (or in this hypothetical case, 7.)
This can be sort of important for natural alignment reasons, and keeping runtime structures the same size to prevent silly unexpected buffer overflows from happening, or runtime offsets wandering off. (Ahem, some people happen to use Cheat Engine, which relies on cheat tables that either use specific offsets in the simple case, or run lua scripts to discover offsets at runtime in the complex case. There is more 'not to break' here than many may realize...!)
Even further; due to a lot of legacy software "living through" the days of incrementing CPU numerals, I suspect many of them would look at 786, 886, or 986, shrug, blindly accept it and carry on. "yeah, that's higher than my minimum of 4, we're good."
Posted Aug 17, 2023 7:53 UTC (Thu)
by daenzer (subscriber, #7050)
[Link] (4 responses)
Posted Aug 17, 2023 8:46 UTC (Thu)
by mathstuf (subscriber, #69389)
[Link] (3 responses)
Posted Aug 17, 2023 8:52 UTC (Thu)
by daenzer (subscriber, #7050)
[Link] (2 responses)
Posted Aug 17, 2023 9:25 UTC (Thu)
by mathstuf (subscriber, #69389)
[Link] (1 responses)
So, AFAICT, we either have massive compiler infrastructure to work on (per compiler!), un-upstreamable patches to sources to manually do the splitting, or a flag day. None sound easy…but I can see why "flag day" is preferred (considering that ABI is already broken anyways).
Posted Aug 17, 2023 9:31 UTC (Thu)
by daenzer (subscriber, #7050)
[Link]
Posted Jul 17, 2023 16:46 UTC (Mon)
by NYKevin (subscriber, #129325)
[Link]
Posted Jul 17, 2023 16:07 UTC (Mon)
by scottlaird (subscriber, #96306)
[Link] (12 responses)
Second, it sounds like a bunch of these use cases overlook SSL. Broken time_t will completely break SSL cert validation, because certs are only good between the issue and expiration dates listed in the cert. So, post 2038, any binary without working 64-bit time_t support is going to completely lose the ability to talk to anything encrypted on the Internet unless ugly hacks are added to each SSL library. Planning on having Debian *default* to being broken seems odd, as it'd completely break many other parts of the system, including system updates. Is the plan for 386 Linux to be *purely* for retrocomputing, without any updates? If so, why not just use a snapshot of bookworm (or something even older) forever?
Posted Jul 17, 2023 16:50 UTC (Mon)
by smcv (subscriber, #53363)
[Link]
If the timestamp checks are done internally to the SSL library, then it could use a 64-bit timestamp internally, only converting to the operating system's time_t (possibly 32-bit) at the API boundary for functions that mention it - and we'll have to hope that nobody actually calls those deprecated functions, because their results are likely to be nonsense, either reduced modulo 2**32, or using saturating arithmetic:
int to_legacy_time(int64 real_time) {
Obviously nonsense results are never good, but when there's nothing better we can do within their existing ABI, all we can do is pick the least-bad answer. That's how for example GLib has been dealing with its legacy 32-bit-time ABIs.
If the timestamp checks are done by the caller, then yes, it's doomed; but arguably legacy 32-bit binaries are unlikely to be safe for use on the modern, hostile Internet anyway.
This is one of the reasons I think it's a helpful simplification to limit existing 32-bit ABIs like i386-linux-gnu to be a "second class citizen" architecture used to run legacy binaries on an otherwise 64-bit system, rather than trying to support fully-32-bit bootable systems where system processes like apt, dpkg and init need to be 32-bit.
Posted Jul 17, 2023 16:53 UTC (Mon)
by NYKevin (subscriber, #129325)
[Link] (6 responses)
Games using SSL is not entirely out of the question, as Steam does include a web browser, and uses it to support an online shopping interface (so you can't just fall back to HTTP - the payment processors will throw a fit if you do that, because it is hilariously insecure). They will have to figure something out between now and 2038, which will probably involve recompiling to x86_64 and/or telling people to move to Arch like they did for the Steam Deck.
Posted Jul 17, 2023 17:30 UTC (Mon)
by smcv (subscriber, #53363)
[Link] (5 responses)
Arch has the same problem as Debian here: they have a subset of 32-bit libraries (lib32-glib2 and so on), and they are going to have to choose what to do with those libraries. If they rebuild with 64-bit time_t, then they become incompatible with existing legacy binaries, defeating the purpose of having those libraries; if they don't, then the current time becomes non-representable in early 2038.
The only way Arch has it easier than Debian is that Arch already doesn't support a fully 32-bit installation (with a 32-bit systemd, package manager, graphical desktop and so on), only a 32-bit library subset on an otherwise 64-bit installation; so they don't have to choose between the two use-cases for i386 that I described, because they already made that choice.
Posted Jul 17, 2023 18:56 UTC (Mon)
by NYKevin (subscriber, #129325)
[Link] (3 responses)
But, on the other hand, those games are also mostly not compiled against Linux in the first place. They're compiled against win32, and if the developers want them to continue working on win32, they will necessarily have to use a win32 API that is capable of post-2038 dates. To my understanding, win32 doesn't even use Unix time in the first place, so this part should already be solved, I think, but if not, the developers will presumably do it of their own accord. Then, the remaining work would be "port Wine/Proton/etc. to use a 64-bit time_t, and provide the equivalent timestamp to the game through the win32 API." So my question is, can they reasonably do that, if the game is 32-bit and Wine/Proton/etc. are running in the same process? Or would you need some kind of 64-bit time daemon?
Posted Jul 17, 2023 21:21 UTC (Mon)
by excors (subscriber, #95769)
[Link] (2 responses)
WoW is actively updated, and dropped 32-bit support in 2018. I believe WoW Classic is 64-bit-only too - that was released in 2019 and recreated the game as it was in 2006 but with a modern implementation.
For a more obsolete example: Ultima Online was released in 1997 and is still playable today (with an optional $12/month subscription). As far as I can tell the client is 32-bit-only, but it still gets minor patches every so often, so they should be able to fix it if it became entirely unplayable.
When a game doesn't have subscriptions that fund ongoing development, it seems rare for servers to stay up for more than maybe 15 years or so - they need porting to new hardware and new security standards etc, but everyone who understood the code has left the company, and eventually the publisher decides it's not worth the effort. E.g. Ubisoft recently shut down servers for a dozen 2009-2013 games, because the technology was obsolete and they didn't want to keep maintaining it. (They also included Anno 2070 (from 2011) in the list, but there was still a team working on the Anno series who decided to save it by porting it to new online services and to 64-bit. The other games must have not found anyone who cared about them enough.)
Last year the servers for Dark Souls 1/2/3 were shut down because someone started publicly exploiting a security vulnerability. It took 7 months to restore DS3, 9 months to restore DS2, 10 months to restore an older edition of DS2, and they gave up on the original DS1 entirely ("due to an aging system"). That's a case where they evidently wanted to keep the servers up, but it required a non-trivial amount of effort.
So... I think it's very unlikely that there will be a 32-bit game which is not actively maintained but its official servers are still operational in 2038, so that the timestamp overflow gets to be the thing that kills it. If it's not maintained then it will be dead already.
Posted Jul 17, 2023 23:25 UTC (Mon)
by NYKevin (subscriber, #129325)
[Link] (1 responses)
Posted Jul 17, 2023 23:31 UTC (Mon)
by NYKevin (subscriber, #129325)
[Link]
Posted Jul 18, 2023 14:36 UTC (Tue)
by smurf (subscriber, #17840)
[Link]
However, we can probably assume that the set of older 32-bit Steam games which can no longer be recompiled is not empty.
Posted Jul 17, 2023 16:55 UTC (Mon)
by jtaylor (subscriber, #91739)
[Link] (1 responses)
This is basically the crux of the debated issue, have i386 be a fully usable system or have i386 available only for the old stuff to run alongside the base system. The latter will may leave i386 tls in the dust but most legacy stuff probably doesn't use it anyway in a way where certificate expiration is relevant.
Posted Jul 18, 2023 22:36 UTC (Tue)
by ballombe (subscriber, #9523)
[Link]
Posted Jul 19, 2023 13:13 UTC (Wed)
by mathstuf (subscriber, #69389)
[Link]
Posted Jul 21, 2023 15:07 UTC (Fri)
by jond (subscriber, #37669)
[Link]
I'm *fairly* sure that Debian system updates do not rely on SSL. You fetch GPG-signed packages from HTTP mirrors (or you can). GPG might be affected by the 2038 issue too, I haven't checked.
Posted Jul 17, 2023 16:07 UTC (Mon)
by mb (subscriber, #50428)
[Link] (2 responses)
Won't it rather become negative and therefore return to a much earlier negative date? Or is the sign bit ignored?
Posted Jul 17, 2023 16:17 UTC (Mon)
by corbet (editor, #1)
[Link] (1 responses)
Posted Jul 17, 2023 16:24 UTC (Mon)
by mb (subscriber, #50428)
[Link]
Posted Jul 17, 2023 20:06 UTC (Mon)
by flussence (subscriber, #85566)
[Link] (1 responses)
Posted Jul 17, 2023 21:51 UTC (Mon)
by smcv (subscriber, #53363)
[Link]
Posted Jul 18, 2023 4:12 UTC (Tue)
by ibukanov (subscriber, #3942)
[Link] (32 responses)
Posted Jul 18, 2023 5:03 UTC (Tue)
by mjg59 (subscriber, #23239)
[Link] (9 responses)
Posted Jul 18, 2023 13:11 UTC (Tue)
by pizza (subscriber, #46)
[Link] (2 responses)
Even beyond "the current date" I'm sure there are many, many applications that use the numerical raw time_t value internally for date/time comparison purposes, expecting the numerical value to monotonically increase.
Playing games with the raw time_t value will just break things, arguably worse than just wrapping around.
Hate to say it, but old binaries are going to have to live with broken dates.
Posted Jul 19, 2023 15:18 UTC (Wed)
by apoelstra (subscriber, #75205)
[Link] (1 responses)
(This was a serious comment when I started typing it, though after a few seconds' thought I realized it would cause no end of bizarre problems. By the time I finished typing I found it funny enough to post anyway.)
Posted Jul 19, 2023 15:34 UTC (Wed)
by mb (subscriber, #50428)
[Link]
Posted Jul 18, 2023 18:45 UTC (Tue)
by NYKevin (subscriber, #129325)
[Link] (5 responses)
Posted Jul 20, 2023 8:03 UTC (Thu)
by matthias (subscriber, #94967)
[Link] (4 responses)
Unfortunately there are probably many applications out there that rely on implementation specific behavior and will translate time_t based on the assumption that epoch is 1970. Such software will indeed not be able to represent correct dates. Change epoch to 1998 or 2026 and the only thing that is wrong is the year. Day of week and leap years should still work.
Posted Jul 20, 2023 11:02 UTC (Thu)
by Wol (subscriber, #4433)
[Link]
Cheers,
Posted Jul 21, 2023 15:48 UTC (Fri)
by jwilk (subscriber, #63328)
[Link] (1 responses)
It does: https://pubs.opengroup.org/onlinepubs/9699919799/basedefs...
Posted Jul 24, 2023 8:09 UTC (Mon)
by matthias (subscriber, #94967)
[Link]
Posted Jul 22, 2023 1:10 UTC (Sat)
by zblaxell (subscriber, #26385)
[Link]
Posted Jul 18, 2023 5:19 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link] (21 responses)
Posted Jul 18, 2023 8:28 UTC (Tue)
by ibukanov (subscriber, #3942)
[Link] (3 responses)
If a network connectivity is required, then the old binaries will not work due to changes in network protocols especially regarding security. But then one can do a proxy for the binaries that will make the app work with particular servers and disable network connectivity for anything else. And it is easier to do it properly for a VM than for application. Then one does not need security updates again.
Posted Jul 18, 2023 17:30 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link] (2 responses)
TLS 1.1 is still supported by some software, and it's nearly 20 years old. TLS 1.2/1.2 will likely be supported for even longer.
There are also other concerns. For example, OpenGL works through user-level libraries (Mesa3D in Linux) that handle shader compilation and interfacing with the kernel. Both sides can change, you'll need userspace support for new devices (the shader compiler), and the kernel interface might evolve incompatibly.
Posted Jul 19, 2023 7:08 UTC (Wed)
by taladar (subscriber, #68407)
[Link] (1 responses)
Posted Jul 19, 2023 7:26 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link]
TLS 1.2 simply removes some problematic functionality from TLS 1.1 and mandates support for primitives that are harder to misuse (GCM modes, primarily).
And TLS 1.3 is basically an entirely new protocol.
TLS 1.2 and 1.3 will absolutely survive way past 2038, barring some serious quantum-computing breakthroughs. And even then, they can just switch to post-quantum key agreement algorithms.
Posted Jul 23, 2023 13:34 UTC (Sun)
by manfre (guest, #165400)
[Link] (16 responses)
Posted Jul 23, 2023 16:17 UTC (Sun)
by pizza (subscriber, #46)
[Link] (1 responses)
It's rarely "won't update", but *CAN'T* update. Usually due to not having the source code.
> The engineering effort to continue supporting these frozen applications seems ridiculous to me and the burden should be put on those wanting to use these old applications. If an old application is critical to a business and can't be recompiled, they'll rewrite/replace it.e old applications.
I think you vastly underestimate the cost of replacing this old stuff. A decade ago I was working at a contract electronics manufacturer which had two parts of their production line running on DOS. The _newest_ bit of equipment ran NT4. Replacing those three pieces of hardware would have literally cost millions of dollars, and the only real alternative to that was to spend a couple hundred thousand to reverse-engineer the hardware/drivers so they could be controlled by something newer.
Posted Jul 25, 2023 16:56 UTC (Tue)
by DemiMarie (subscriber, #164188)
[Link]
Posted Jul 23, 2023 16:18 UTC (Sun)
by Wol (subscriber, #4433)
[Link] (12 responses)
And you're missing a third use case as well. Would you want to dump your old (maybe *5*) year old car, that runs perfectly, just because the software is out of date? And how much *industrial* software was written for DOS, the software house has gone bust and the code is long lost, and replacing it means spending $xM on new hardware ... ?
Back in the old days, hardware was expensive and engineers were cheap. There are plenty of areas where that has NOT changed.
Cheers,
Posted Jul 23, 2023 18:58 UTC (Sun)
by amacater (subscriber, #790)
[Link] (2 responses)
Keeping a full distro suite - to include large/complex packages like libreoffice / firefox / chromium - becomes a cost/benefit calculation. If (to pull an example from the air) you can no longer build Firefox quickly on 32 bit because it takes too much memory / relies on Rust being there - do you make i386 different by removing Firefox from only i386?
For businesses/foundries running DOS, 16/32 bit Windows binaries and expensive machinery - if machinery replacement costs haven't featured in your lives in the last 15 years, they MUST feature in the next 15 years. If not, then the younger folk who will then be able to help you will at that point be in their 70s (and the younger hardware will be almost 60 at that point.)
Posted Jul 23, 2023 19:39 UTC (Sun)
by Wol (subscriber, #4433)
[Link] (1 responses)
This is where YOU HOPE the hardware is documented (or you pay someone to reverse engineer the control sequence), and you also pay someone to write a new driver. But as I told a boss a good few years ago, "let me use my choice of tools (linux), and if I fail it's my fault. Tell me to use Windows, and if I say I can't do it it's your fault."
Cheers,
Posted Jul 24, 2023 0:43 UTC (Mon)
by anselm (subscriber, #2796)
[Link]
That is all well and good but if that boss was like most other bosses it would still have been your fault in the end.
Posted Jul 23, 2023 22:59 UTC (Sun)
by manfre (guest, #165400)
[Link] (8 responses)
Posted Jul 23, 2023 23:42 UTC (Sun)
by Wol (subscriber, #4433)
[Link] (7 responses)
What did you, or your company, actually GAIN from those forced uplifts? Anything?
Take my preferred desktop. KDE3 was fine. KDE4 was a disaster. Plasma has given me nothing I particularly want. Pretty much ALL the software I love belongs in tickover/maintenance mode, because it was properly designed, it works great, and just needs a little bit of keeping up to date. But instead, I'm under massive pressure to throw it out and replace it with stuff that doesn't work ...
Pretty much every software developer doesn't want to maintain that functional, working, old code, they want to write new fancy stuff full of bugs that's overly complex and a nightmare for users.
Don't blame the victims - guys who want old software to just "keep working", Blame the newbies who equate "old" with "out-of-date" and think all software should come with a "sell-by" date before they've finished getting it to work properly.
Cheers,
Posted Jul 24, 2023 8:39 UTC (Mon)
by joib (subscriber, #8541)
[Link] (6 responses)
Like you, I think KDE3 was fine, and KDE4 horrible. But the universe doesn't owe me maintenance of KDE3 in perpetuity. If nobody wants to shoulder the burden of maintaining KDE3, well, that's my problem and not the problem of the (former) KDE3 maintainers.
Posted Jul 24, 2023 12:18 UTC (Mon)
by Wol (subscriber, #4433)
[Link] (5 responses)
But was the upgrade from KDE3 to 4 value-for-money? And no I do NOT buy the argument "but it's free".
This is another aspect of the problem I have with the FSF's "everything should be free" attitude. The Linux Kernel works very well, because the majority of developers are paid to work on it as a job, and are paid to make it work.
Programmers' tools likewise, tend to work well. because "a bad worker blames his tools" - the community of users and developers are the same people.
Office productivity stuff, on the other hand, struggles, because the people who *could* do the work aren't the people who *use* the tools, so have little interest in *doing* the work (and those who are paid, are paid to write proprietary stuff).
And things like KDE, Clementine (my audio player of choice), Picasa (my preferred photo editor) etc all fall in the "Attention Deficit Teenager" category. They come out of nowhere, gain a big following, and vanish because the people writing them can't make money and lose interest. And that is both *expensive* and *painful* for the user community as a whole. The trouble is also the amount of commercial software that follows the same pattern - companies drop products, the company goes bust or gets bought, the product suffers from featuritis, etc etc. All at considerable COST to the end user :-(
And all this stuff about security and stuff only highlights this problem. The software involved falls firmly in the *last* category, but because it's (old versions of) linux, people here (and elsewhere) assume it should fall in the *first* category.
At the end of the day, someone's got to pay for it, and this is where RHEL's real value proposition lies - you can still get fixes for a ten-year-old (or more) distro, if you're prepared to pay for it.
THIS is the problem. Upgrading comes at considerable cost - probably at much greater cost than maintaining the long tail! But the cost is less visible because it's spread over more people, and in smaller chunks.
Cheers,
Posted Jul 24, 2023 14:35 UTC (Mon)
by joib (subscriber, #8541)
[Link] (4 responses)
Note that nowhere in my comment did I mention money or cost. I'm also a bit unsure what you're trying to say, your two sentences above seem to be in conflict with each other. First you mention value-for-money, that is, how much value you get out of it (however you measure that) vs. how much you paid for it. Then in the second sentence you say we cannot talk about how much it cost.
> At the end of the day, someone's got to pay for it, and this is where RHEL's real value proposition lies - you can still get fixes for a ten-year-old (or more) distro, if you're prepared to pay for it.
I certainly agree RHEL has a value proposition, but note that even RHEL doesn't ultimately free you from the upgrade treadmill. RHEL doesn't promise to maintain KDE3 in perpetuity either. It only gives you the choice to upgrade every 10 years (giver or take) vs. more often with most other distros. Whether bigger changes more seldom ultimately causes more or less wasted effort for the end user vs. smaller changes more often I don't have any particular opinion on, I guess it depends.
> THIS is the problem. Upgrading comes at considerable cost - probably at much greater cost than maintaining the long tail! But the cost is less visible because it's spread over more people, and in smaller chunks.
Unless you have some plan to motivate, or monetarily compensate, people to maintain that long tail, this is firmly in old-man-yelling-at-cloud territory. And of course, it's not only in software, it's everywhere in the world.
Posted Jul 24, 2023 17:03 UTC (Mon)
by Wol (subscriber, #4433)
[Link] (3 responses)
Do we have a language problem? "value for money" doesn't actually mean you spent currency ... if I spend half an hour of my time on make-work that achieves nothing, that's poor value for money. What BENEFIT did you gain from that upgrade? Was it WORTH the effort? And if the answer is "no", why did you do it?
> Unless you have some plan to motivate, or monetarily compensate, people to maintain that long tail, this is firmly in old-man-yelling-at-cloud territory. And of course, it's not only in software, it's everywhere in the world.
I know. But it seems to be an affliction of the young that they think "ooh, shiny, new" without realising that's not necessarily a good thing. This whole thread started with "why don't people upgrade", and loads of people are objecting to "the cost isn't worth the candle" as a response.
People don't do things unless either it's in their interest, or they're forced to.
> It only gives you the choice to upgrade every 10 years (giver or take)
Which, from Pizza's example is way too soon. As I said above, would you be happy to be forced to throw your car away after ten years, because the software couldn't be upgraded? Despite the fact it's 100% functional and working fine?
Cheers,
Posted Jul 29, 2023 9:08 UTC (Sat)
by tuna (guest, #44480)
[Link] (2 responses)
If it is free software you or others can maintain it themselves. You never have to trow it away.
Posted Jul 29, 2023 10:20 UTC (Sat)
by Wol (subscriber, #4433)
[Link] (1 responses)
You're missing the point. For MOST people, they can't pay someone else (they don't have the money). They can't do it themselves (they don't have the time/skills). The "value for money" deal is a slam-dunk "throw it away", despite the fact that when you add up all those individual costs, it's way more expensive than "paying someone else".
THAT is why commercial software still thrives - where the user and developer communities are disjoint, "throwaway" commercial software despite its faults is the most cost-effective option.
Could YOU maintain your car management software? Do you know anyone who could? Could you afford to pay some random Joe on the internet to do it for you?
Cheers,
Posted Jul 29, 2023 11:03 UTC (Sat)
by mikebenden (guest, #74702)
[Link]
If my car's management software came with sources and access to the toolchain required to build it from source, I could at least *try* and find out!
And if *one* of us succeeded, *all* of us could benefit. I'm constantly amazed at how this point always gets lost in the weeds while we bicker about other, less relevant stuff... :)
Posted Jul 25, 2023 4:59 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link]
> If an old application is critical to a business and can't be recompiled, they'll rewrite/replace it. If it's an old game that doesn't care about time being current/accurate, boot an appropriately old image.
The problem is that some applications need specialized hardware (e.g. RPi) that only runs 32-bit code. Some of it likely will still exist in 2038. This is doubly true in the industrial space.
Burdening Debian with this is indeed unfair, and a specialized commercial distribution (built on top of Debian) might be a good solution.
Posted Jul 18, 2023 7:38 UTC (Tue)
by wtarreau (subscriber, #51152)
[Link] (1 responses)
So either we consider that negative time_t are finally a thing and we gain 68 new years. There's the special case of -1 which is an error (which could likely be covered by a leap second) and the bigger concern that many applications just check for <0 as an error. Or we consider that the sign never changes and that we roll on bit 30 while keeping 31 always zero: values 0-1073741823 which used to represent 1970/01/01 - 2004/01/10 would now represent 2038/01/19 - 2072/01/28. Then at mid point between these two (in 2055) they'll just flip the upper bound to cover 2072-2106 etc.
It's "just" a matter of changing the definition within the lib itself (and man pages) and applying a 31-bit mask to returned values, nothing less, nothing more. For sure, applications that make their own computations on the date value will have a problem, but these ones are unfixable in binary form anyway. And I'm a bit saddened to see that we had 68 years to be able to make everyone agree on a rolling date and it was still not possible to do so after 53 years, while the human population does for all dates all the time : nobody repeats the assumed known parts of the date, you say it's 9h33, not it's "9h33 on tuesday 18th of july 2023". We used to say COVID19, not COVID2019. And for now when we speak about the seventies, it's still those of 1900. So everywhere we assume a sliding window that covers contemporary time.
I've always anticipated that this one will be much more troubling than Y2K because it was not a matter of human-facing date that users could quickly verify, but of a technical limitation affecting internal processing. And I'm almost certain we'll see breakage even in 64-bit apps using time_t, just because of some hand-written calculations dating from the era where the libc wasn't of great help on all this stuff. Interesting times ahead...
Posted Jul 18, 2023 10:01 UTC (Tue)
by Wol (subscriber, #4433)
[Link]
Well, Pick had the "Day 10K" problem, and that wasn't too bad. Although at least there the problem wasn't fundamental to Pick, it was just a load of badly written user code, where people expected that 10K would never come and used "day 9999" as "the unimaginable future". Until it arrived (about 1997 iirc). We're now about day 20K :-)
(The problem basically was either the use of 9999, or the related assumption that the day number would always be four decimal digits. Of course, we're going to have day 100K, but that's about 2 1/2 centuries away ...)
Cheers,
Debian looks forward to 2038
Debian looks forward to 2038
Debian looks forward to 2038
- https://old.reddit.com/r/linux_gaming/comments/8qqidb/wha...
- https://steamcommunity.com/app/221410/discussions/0/62069...
Debian looks forward to 2038
> interfaces. (If we could recompile, we wouldn't still be using 32-bit
> software.)
Debian looks forward to 2038
Debian looks forward to 2038
Debian looks forward to 2038
Debian looks forward to 2038
Debian looks forward to 2038
Debian looks forward to 2038
Debian looks forward to 2038
Debian looks forward to 2038
Debian looks forward to 2038
Debian looks forward to 2038
Debian looks forward to 2038
If you can recompile, you would build a 64-bit program (not a 32-bit one) and so this whole problem would not impact you.
Future of i386
The Core line of Intel processors only gained 64-bit compatibility with the Core 2 in 2006. Unfortunately, Intel then used 64-bit support for market segmentation, especially in the Atom range of CPUs.
Future of i386
Debian looks forward to 2038
Debian looks forward to 2038
Debian looks forward to 2038
Debian looks forward to 2038
Debian looks forward to 2038
But a reason to install mksh... not sure :-)
Debian looks forward to 2038
- https://inbox.sourceware.org/libc-alpha/A6582515-25ED-4F7...
- https://inbox.sourceware.org/libc-alpha/10857996.18pcnM70...
Debian looks forward to 2038
Debian looks forward to 2038
Debian looks forward to 2038
Debian looks forward to 2038
Debian looks forward to 2038
Debian looks forward to 2038
Debian looks forward to 2038
Debian looks forward to 2038
Debian looks forward to 2038
I also fully expect to see hacks like time offsetting and overlay filesystems that map inodes to a 32-Bit space to appear, just to keep old applications running.
Debian looks forward to 2038
Debian looks forward to 2038
Debian looks forward to 2038
Not necessarily. In the most recent major release: WINE 8.0 released [LWN.net]
Debian looks forward to 2038
Other changes include WoW64 support (allowing 32-bit modules to call into 64-bit libraries)
- WoW64 thunks are implemented for essentially all Unix libraries, enabling a
32-bit PE module to call a 64-bit Unix library. Once the remaining direct
PE/Unix calls have been removed, this will make it fully possible to run
32-bit Windows applications without any 32-bit Unix library.
Debian looks forward to 2038
i786 seems appropriate. "It's not like it's ancestors, yet it's not like it's siblings either."
as well as "I may not be formally compatible with all physical 32-bit hardware".
Leave i386 alone!! Or you'll break my xevil binary from redhat 4.2. I would be very saddened if I had to resort to using the newer version 2.0.2 currently packaged everywhere.
</s>
Debian looks forward to 2038
Debian looks forward to 2038
Debian looks forward to 2038
Debian looks forward to 2038
Debian looks forward to 2038
Debian looks forward to 2038
Debian looks forward to 2038
Debian looks forward to 2038
Debian looks forward to 2038
if (real_time < INT_MIN)
return INT_MIN; /* times before 1901 clamp to 1901 */
if (real_time > INT_MAX)
return INT_MAX; /* times after 2038 clamp to 2038 */
return (int) real_time;
}
Debian looks forward to 2038
Debian looks forward to 2038
Debian looks forward to 2038
Debian looks forward to 2038
Debian looks forward to 2038
Debian looks forward to 2038
Debian looks forward to 2038
Debian looks forward to 2038
Debian looks forward to 2038
Debian looks forward to 2038
Debian looks forward to 2038
Debian looks forward to 2038
Yes, as others have pointed out, I had a silly brain misfire there. The article has been corrected, apologies for the confusion.
Debian looks forward to 2038
Debian looks forward to 2038
Debian looks forward to 2038
Debian looks forward to 2038
Debian looks forward to 2038
Debian looks forward to 2038
Debian looks forward to 2038
Debian looks forward to 2038
Debian looks forward to 2038
Debian looks forward to 2038
Debian looks forward to 2038
Debian looks forward to 2038
Wol
Debian looks forward to 2038
Debian looks forward to 2038
Debian looks forward to 2038
Debian looks forward to 2038
Debian looks forward to 2038
Debian looks forward to 2038
Debian looks forward to 2038
Debian looks forward to 2038
Debian looks forward to 2038
Debian looks forward to 2038
Stuff that cannot be upgraded
Debian looks forward to 2038
Wol
Debian looks forward to 2038
Debian looks forward to 2038
Wol
Debian looks forward to 2038
But as I told a boss a good few years ago, "let me use my choice of tools (linux), and if I fail it's my fault. Tell me to use Windows, and if I say I can't do it it's your fault."
Debian looks forward to 2038
Debian looks forward to 2038
Wol
Debian looks forward to 2038
Debian looks forward to 2038
Wol
Debian looks forward to 2038
Debian looks forward to 2038
Wol
Debian looks forward to 2038
Debian looks forward to 2038
Wol
Debian looks forward to 2038
Debian looks forward to 2038
Debian looks forward to 2038
Debian looks forward to 2038
Wol