#y2k38 — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #y2k38, aggregated by home.social.
-
Ein bemerkenswerter Artikel in der Schweizer Zeitung La Liberté über das Jahr-2038-Problem:
https://www.laliberte.ch/articles/monde/le-bug-de-2038-pourrait-tout-faire-planter-1411046
Besonders erfreulich: Er erwähnt XSTP.epoch, das im Juni von ITU-T SG17 in Genf verabschiedet wurde.
Und im Acknowledgement wird auch unsere Arbeit aus der FIRST Time SIG und der Epochalypse-Community gewürdigt. Ein kleiner, aber schöner Meilenstein.
#Y2K38 #XSTPepoch #y2038 #DasJahr2038Problem -
The Unix time for Sunday 19th July 2026, at 03:14:07 UTC is 1784430847, which will be 11 years and 6 months from the Y2K38 rollover 🙂
-
Unix zählt Sekunden.
GPS zählt Wochen.
DVB zählt Tage.Drei unterschiedliche Zeitmodelle.
Drei unterschiedliche Standards.
Und wieder taucht 2038 auf.Neuer kurzer Blog über den DVB-Zeit-Rollover und Modified Julian Date.
https://y2k38.ch/dvb-modified-julian-date-2038-problem-end-of-days
-
Vor 20 Jahren trat der erste bekannte Y2K38-Bug in Produktion auf.
Beim Open-Source-Webserver AOLserver führte „jetzt + 1 Milliarde Sekunden“ erstmals über die 32-Bit-Zeitgrenze hinaus. Verbindungen liefen sofort ab, Timer kippten, Scheduler blockierten.
Das Jahr-2038-Problem war damit nicht mehr theoretisch.
Und 20 Jahre später ist es noch immer nicht gelöst.
https://y2k38.ch/aolserver-2038-problem-y2k38-bug
Edit: Fixed Link
-
🕒 12 χρόνια απομένουν για το Epochalypse – και τα 32-bit συστήματα είναι η "ωρολογιακή βόμβα" του 2038.
Στις 19 Ιανουαρίου 2038, στις 03:14:07 UTC, τα συστήματα που χρησιμοποιούν signed 32-bit time_t θα υπερχειλίσουν. Το αποτέλεσμα; Ημερομηνίες του 1901, σφάλματα σε πιστοποιητικά, καταρρεύσεις εφαρμογών – και σε κρίσιμες υποδομές, πιθανή κατάρρευση λειτουργιών.
Δείτε πλήρη ανάλυση 👉 https://opensource.uom.gr/index.php/epochalypse-provlima-y2k38/
#Y2K38 #Epochalypse #Year2038 #Linux #CyberSecurity #IoT #DevOps #UnixTime #Tech
-
Kleine Umfrage zum Jahr-2038-Problem👇
Was meint ihr, wie werden die Auswirkungen sein?
Teilt die Umfrage gern weiter, bin gespannt auf eure Einschätzungen 🙂
Begründungen gerne in den Kommentaren.
-
Y2K38 kommt. Milliarden Systeme sind betroffen.
Open Source wird kritisiert – dabei entstehen die Lösungen oft genau dort.
Das Problem ist nicht der Code.
Das Problem ist, wie wir damit umgehen.👉 Wer zahlt am Ende die Rechnung?
-
Although we didn’t make it into the final article, we appreciate being referenced in the sources. The article of @murielvalin on #Y2k38 is well worth reading:
https://www.epsiloon.com/tous-les-numeros/n57/le_bug_de_l_an_2038/
#Y2038 #y2038bug #DasJahr2038Problem #ScienceNews #journalismus
-
@chip-CHIP_online @CHIP_online Gut, dass über das Jahr-2038-Problem berichtet wird. Positiv ist, dass unsere Recherche aufgegriffen wird. Schade allerdings, dass der Link mit nofollow versehen ist.
#Y2038 #Y2k38 #Journalismus -
Our recommendation for #fosdem
https://fosdem.org/2026/schedule/event/KTFEWJ-2038-rollover-open-source/
☝️"Pulling 32-bit time_t Asbestos out of the Open Source Ecosystem"
Say hello to @treyka if you’re there.
-
Alte Technik verschwindet nicht. Sie wird exportiert. Warum Y2K38 für Afrika schneller näher rückt – und was digitale Ungleichheit damit zu tun hat. #Y2K38 #Y2038 #DasJahr2038Problem
https://y2k38.ch/digitale-ungleichheit-y2k38-technologieexporte
-
2038 wird zur Rechtsfrage: Ein Pariser Gericht macht Alstom für den Y2K38-Bug haftbar. Acht Metro-Linien und die RER A könnten sonst ab 19.1.2038 ausfallen. Das Urteil ist ein Weckruf für die ganze Branche.
#y2k38 #y2038 #y2038bughttps://y2k38.ch/herstellerhaftung-jahr-2038-problem-urteil-zum-y2k38-bug/
-
Ist das der Startschuss? Ein Gerichtsurteil zwingt Alstom ihre Züge in Paris #y2k38 sicher zu machen. 1/3 der des Verkehrssystems würde komplett ausfallen. Alstom hat in den letzten 6 Jahren keine Lösung gefunden. Das ist nur die Soitze des Eisberges. y2k38 kein Problem?! Das sieht Alstom mittlerweile anders. Mehr werden folgen #Y2038 #jahr2038problem
https://www.leparisien.fr/info-paris-ile-de-france-oise/transports/un-bug-informatique-menace-de-bloquer-le-rer-a-et-huit-lignes-de-metro-en-2038-09-12-2025-AN63SZ64XFBYDFEXV3FTWNFI6A.php -
Time will simply reset and start again.
Nietzsche suffered from the same bug. -
Der erste dokumentierte #Y2k38-Bug – 32 Jahre vor 2038.
The Edge of Time - Die Ewigkeit endet 2038.
-
2038 ist näher, als man denkt – und diesmal tickt die Bombe im Silizium.
Ob Hardware-RTC, Mikrocontroller oder FPGA: Viele Chips haben nur 32 Bit Zeit übrig. Im Blog haben wir eine Übersicht erstellt: von Dallas RTCs bis zu STM32 und NXP LPC. -
👉 Neuer Blog: „time_t Cast Away: Bits über Bord und der Y2K38 Bug ist zurück“
Die Umstellung auf 64-Bit-time_t gilt als Lösung für das Year 2038 Problem. Doch Direct Casts machen den Fix schnell unwirksam – und schicken uns zurück ins Jahr 1901.
Auf das Wortspiel bin ich ein bisschen stolz ☺️
🔗 https://y2k38.ch/time-t-cast-y2k38-bug/
#Y2K38 #time_t #CProgramming #Year2038Problem #Y2038 #2038Problem #CastAway
-
It looks like my joy in testing #Gentoo #time64 migration was premature.
In my case, #Perl did fail because I've added an explicit time32 + time64 linking check. However, after removing that check, it turned out that Perl has its own detailed check for compatibility between the modules and the interpreters, so it fails anyway.
Well, I guess we can't do much about that…
-
Wygląda na to, że moja radość w kwestii testowania migracji #time64 dla #Gentoo była przedwczesna.
Owszem, w moim przypadku #Perl sypał się dlatego, że dołożyłem do systemu sprawdzanie, czy nie łączymy bibliotek time32 i time64. Niemniej, po usunięciu tego testu okazuje się, że Perl ma własny test, sprawdzający skrupulatnie zgodność modułów z interpreterem, więc sypie się i tak.
No cóż, z tym wiele nie zrobimy…
-
Za mną kolejna próbna migracja #Gentoo do #time64. Tym razem trafiłem na kilka problemów mieszania ABI:
• perl (świeżutka biblioteka z time64 poszła w LD_PRELOAD, konfliktowała z… GNU make, które było w wersji time32)
• List-MoreUtils (używało List-MoreUtils-XS, które nie zostało jeszcze przebudowane, na perlu z time64)
• pypy3.10 (test QA posypał się, bo pypy3_10-exe z time64 używało rozszerzeń z time32, z paczki pypy3_10)
• paczki używające help2man (przez Locale-gettext z time32)
• portage (używając modułu _whirlpool z time32, na Pythonie z time64)Moim zdaniem, to pomniejsze problemy, które nie powinny prowadzić do realnego posypania się systemu w produkcji. Czas na jeszcze jedną próbę, tym razem bez blokady mieszania ABI — czyli tak, jak będą to robić normalni użytkownicy.
-
Another #Gentoo #time64 test migration done. Hit a few ABI mixing errors throughout:
• perl (a freshly built time64 library built into LD_PRELOAD, conflicted with time32… GNU make)
• List-MoreUtils (used not-yet-rebuilt List-MoreUtils-XS on time64 perl)
• pypy3.10 itself (failing QA check due to using time64 pypy3.10 pypy3_10-exe with time32 extensions from pypy3_10)
• packages using help2man (due to using time32 Locale-gettext)
• portage (using time32 _whirlpool module on time64 Python)The way I see it, these are minor mismatches, unlikely to lead to any real-life problems. Now to do another try, this time without ABI mixing check — i.e. to see if anything would fail on a production system.
-
Kolejny istotny problem, na który natrafiłem testując migrację #Gentoo do #time64, to cykliczne zależności. Tak na przykład #systemd łączy się z bibliotekami z util-linux, podczas gdy te drugie (opcjonalnie) łączą się z bibliotekami z systemd.
Normalnie, menadżer pakietów wykrywa ten problem i odmawia operacji, sugerując tymczasową zmianę flag USE, by zlikwidować cykl. Niestety, w tej sytuacji to się nie dzieje, bo używamy opcji --emptytree — menadżer pakietów więc zbiera wszystkie paczki tak, jak gdyby żadna nie była zainstalowana, ale nadal traktuje je jak zainstalowane na potrzeby ustalenia, czy zależności są spełnione.
Mamy tu kilka możliwości. Możemy pogodzić się z tym, że kilka (może kilkanaście) paczek się posypie, i użytkownicy będą musieli na bieżąco naprawiać i obchodzić problemy z tymi paczkami. Możemy też dostarczyć kilka podpowiedzi, co przebudować wcześniej (np., żeby zrobić `USE="-systemd -udev" emerge -1v util-linux`). Jednakże nie uważam tego za dobre rozwiązanie.
Myślę, że bardziej praktycznie będzie zmodyfikować time32-prep tak, by domyślnie kopiowało biblioteki współdzielone zamiast przenosić je. W praktyce oznaczać to będzie pewne ryzyko, że programy tymczasowo będą korzystać z bibliotek o potencjalnie niezgodnym ABI, ale będzie to występowało w minimalnym stopniu, i oszczędzi użytkownikom sporego wysiłku walki z wieloma błędami przy przebudowywaniu systemu.
-
The next major issue in the #Gentoo #time64 transition testing I've been doing are cyclic dependencies. For example, #systemd links to util-linux, while util-linux (optionally) links to systemd.
Normally, the package manager detects the cyclic dependency and refuses to proceed, telling the user to temporarily modify USE flags in order to circumvent it. However, this doesn't work here as we're doing an --emptytree rebuild — which means that the package manager collects all packages for rebuild as if none were installed, but still considers them installed for the purpose of dependency satisfaction.
Well, one possibility here is to expect some build failures and actively work towards fixing and working around them. We could also provide some hints as to what to rebuild early (e.g. `USE="-systemd -udev" emerge -1v util-linux`). However, I don't think this is really a good solution for our users.
A far more practical approach would be have time32-prep copy shared libraries by default, rather than moving them. While this would still open some risk of packages temporarily using mixed-ABI libraries, ideally it would be only minimal and save users from having to tediously figure out multiple build failures.
-
Yesterday, while testing time64, I was wondering if we could switch #Python to 64-bit #time_t immediately and unconditionally, and get rid of some #y2k38 problems we're facing today already (these affecting Python packages). Unfortunately, no dice. While the public API of Python does not use time_t, Python itself uses #OpenSSL functions that take time_t parameters. So we can't switch Python until we switch OpenSSL, and that effectively means switching the whole system.
Well, unless we tried to manipulate the flags per extension…
-
Przy okazji testowania time64, wczoraj zastanawiałem się, czy możemy od razu i bezwarunkowo przełączyć Pythona na 64-bitowe #time_t i pozbyć się części z problemów #y2k38, z którymi spotykamy się już dziś (tych dotyczących paczek Pythona). Niestety, nic z tego — choć publiczne API Pythona nie używa time_t, to już Python używa funkcji z #OpenSSL, które mają argumenty typu time_t. Tak więc nie możemy przestawić Pythona, dopóki nie przestawimy OpenSSL — a to w praktyce oznacza przestawienie całego systemu.
Hmm, chociaż w sumie moglibyśmy spróbować wybiórczo manipulować flagami dla poszczególnych rozszerzeń…
-
Another post on the blog, though this time it's more of a quick note: "Testing the safe time64 transition path"
"""
Recently I've been elaborating on the perils of transition to 64-bit #time_t, following the debate within #Gentoo. Within these deliberations, I have also envisioned potential solutions to ensure that production systems could be migrated safely.My initial ideas involved treating #time64 as a completely new ABI, with a new libdir and forced incompatibility between binaries. This ambitious plan faced two disadvantages. Firstly, it required major modification to various toolchains, and secondly, it raised compatibility concerns between Gentoo (and other distributions that followed this plan) and distributions that switched before or were going to switch without making similar changes. Effectively, it would not only require a lot of effort from us, but also a lot of convincing other people, many of whom probably don't want to spend any more time on doing extra work for 32-bit architectures. This made me consider alternative ideas.
One of them was to limit the changes to the transition period — use a libt32 temporary library directory to prevent existing programs from breaking while rebuilds were performed, and then simply remove them, and be left with plain lib like other distributions that switched already. In this post, I'd like to elaborate how I went about testing the feasibility of this solution. Please note that this is not a migration guide — it includes steps that are meant to detect problems with the approach, and are not suitable for production systems.
"""https://blogs.gentoo.org/mgorny/2024/10/04/testing-the-safe-time64-transition-path/
-
The previous evening I was doing yet another experiment with safe transition from 32-bit to 64-bit #time_t in #Gentoo. This time I was trying a different approach — rather than changing libdir for the time64 ABI permanently, moving the time32 libraries into a temporary directory for the transition time.
The idea was that we move all old libraries to libt32, and we add RUNPATH to all old binaries to make them capable of finding these libraries. Then, as libraries were rebuilt, Portage would keep old copies in libt32 for as long as they were necessary (through preserved-libs), and then remove them as soon as all reverse dependencies were rebuilt. Unfortunately, even though I hacked hard, I wasn't able to convince Portage to stop treating time64 and time32 libraries as equivalent, and therefore remove the latter immediately after rebuilt.
I was close to thrashing the idea entirely, but near three o'clock in the morning I woke up with another idea — and one much simpler at that. Sure, add RUNPATH to binaries; sure, move the libraries — but without updating the vardb, leaving them out of Portage's control. As packages are rebuilt, Portage will not be removing anything from libt32, and newly built programs, no longer having the RUNPATH injected, would simply stop using libt32 libraries. And when all rebuilds are done, the user can just remove libt32 wholesale.
In the end, it's less work for me (no need to update vdb), and fewer moving parts. What remains is determining which binaries should have their RUNPATHs (already learned the hard way that you can't alter all of them), write a script to inject them and move the libraries, and then try another experiment.
-
Wczoraj wieczorem po raz kolejny eksperymentowałem z bezpieczną migracją z 32-bitowego na 64-bitowe #time_t w #Gentoo. Tym razem skupiałem się na alternatywnym podejściu, w którym nie zmieniamy na stałe katalogów dla nowego ABI time64, a zamiast tego tymczasowo przenosimy stare biblioteki na czas migracji.
Idea była taka, że stare biblioteki przeniesiemy do katalogu libt32, i dopiszemy RUNPATH we wszystkich starych binarkach, żeby je znajdowały. Następnie w miarę przebudowywania kolejnych bibliotek, Portage zachowywałby stare kopie w libt32 tak długo, jak byłyby potrzebne (w oparciu o preserved-libs), a następnie usuwał je po przebudowaniu wszystkich wstecznych zależności. Niestety, pomimo kombinowania jak koń pod górę, nie udało mi się zmusić Portage, by nie traktowało jednych i drugich bibliotek równoważnie, i nie usuwało tych z libt32 natychmiast.
Już byłem bliski porzucenia tego pomysłu, lecz przed trzecią nad ranem obudziłem się z kolejnym pomysłem — którego wielką zaletą jest to, że jest jeszcze prostszy. Owszem, dopisać RUNPATH w binarkach; owszem, przenieść biblioteki, ale bez aktualizacji vardb — czyli zupełnie poza kontrolą Portage. Oznacza to w praktyce, że w miarę przebudowywania paczek, Portage po prostu nie będzie niczego usuwać z libt32, a nowoskompilowane programy, pozbawione już RUNPATH, przestaną używać bibliotek z libt32. A jak już wszystko zostanie przebudowane, użytkownik może usunąć całe libt32 ręcznie.
Koniec końców, będzie z tym mniej roboty dla mnie (bo nie trzeba aktualizować vdb), a i mniej polegania na rozwiązaniach, które mogłyby źle zadziałać. Pozostaje mi ustalić dokładne kryteria aktualizacji RUNPATH (przekonałem się już, że nie wszystkie binarki można tykać), napisać skrypt do tej aktualizacji i przenoszenia bibliotek, a potem przeprowadzić próbę "na poważnie".
-
Today's one of these days when reading a mailing list discussion convinces me that I was right.
So, do people agree with me? No, not at all. In fact, I can't even start to comprehend how lightly #Debian folks are treating such issues as a sudden #ABI change. I'm talking about changing `#time_t` from 32 bits to 64 bits, on 32-bit platforms. They're like: YOLO, let's just change it and see what happens…
And what will happen? Well, if we have any program compiled with 32-bit time_t, that happens to link to a system library that now exposes 64-bit time_t in its ABI, then suddenly stuff's going to misalign. Like, we get all the fun C vulnerabilities — here function parameters will be misinterpreted, there we will be reading or writing to the wrong memory addresses…
Ok, I guess Debian has it easier than #Gentoo. They're using binary packages, so at least as far as the system packages are concerned, they can do the upgrade in a reasonably reliable way, in a short time. In Gentoo, we're talking about hours or even days of rebuilding. And during this time *production systems* will be starting program with a risk of ABI incompatibility, or in other words — we'd be running one huge vulnerability of a system. Not to mention that some rebuild could fail, and suddenly we'd be left with a half-rebuilt system…
-
Dziś jest kolejny z tych dni, w których czytanie dyskusji na temat przekonuje mnie, że miałem rację.
Znaczy uczestnicy się zgadzają ze mną? Nie, wręcz przeciwnie. Wręcz niepojęte jest dla mnie, jak lekkomyślnie ludzie od Debiana traktuje takie problemy jak nagłą zmianę #ABI. A mowa tu o zmianie wielkości typu `#time_t` z 32 bitów na 64 bity, na 32-bitowych platformach. Po prostu YOLO i zmieniamy, co będzie to będzie…
A co będzie? Otóż to, że jeżeli mamy jakikolwiek program skompilowany z 32-bitowym time_t, który dowiązany jest do biblioteki eksponującej 64-bitowe time_t w swoim ABI, to nagle cichaczem wszystko się rozjedzie. Znaczy, dostaniemy wszystkie nasze ulubione problemy bezpieczeństwa znane z C — tu się rozjadą argumenty do funkcji, tam będziemy czytać albo pisać po niewłaściwych adresach w pamięci…
No dobra, #Debian niewątpliwie ma łatwiej niż #Gentoo. Jadą na paczkach binarnych, więc przynajmniej wszystkie systemowe paczki mogą w miarę pewnie zaktualizować w krótkim czasie. W Gentoo z kolei mówimy o godzinach, może nawet dniach, kompilacji. A w tym czasie *systemy produkcyjne* uruchamiałyby programy z potencjalną niezgodnością ABI, a więc praktycznie rzecz biorąc, system stanowiłby jedną wielką dziurę bezpieczeństwa. Nie wspominając o ryzyku, że kompilacja którejś paczki się posypie i nagle zostaniemy z na wpół przebudowanym systemem…