Wenn #dvb und damit das Fernsehen vom #time_t-Bug von der Bildfläche verschwinden würde, wäre das ein Zeichen der Hoffnung.
#time_t
👉 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
@minterpunct The classical unixes, yes.
Modern unixes (unixlikes if you will) have 64-bit time_t (#OpenBSD switched in their 5.5 release https://www.openbsd.org/55.html back in 2014, also see https://www.openbsd.org/papers/eurobsdcon_2013_time_t/index.html. Others were on the way then. #time_t #y2038 #unix #freebsd #netbsd #linux
[Перевод] Риски перехода на 64-битный time_t
Один из разделов статьи Overview of cross-architecture portability problems я посвятил проблемам, возникающим из-за использования 32-битного типа time_t. Это архитектурное решение, до сих пор влияющее на использующие glibc системы с Gentoo, приведут к тому, что у 32-битных приложений в 2038 году начнут возникать ужасные сбои: они будут получать ошибку -1 вместо текущего времени и не смогут выполнять stat() файлов. Одним словом, возникнет полный хаос. Считается, что решением будет переход на 64-битный тип time_t. Musl уже перешёл на него, а glibc поддерживает его как опцию. Многие другие дистрибутивы, например, Debian, совершили этот переход. К сожалению, дистрибутивам на основе исходников, например, Gentoo, сделать это не так просто. Поэтому мы по-прежнему обсуждаем эту проблему и экспериментируем, пытаясь понять, как пользователи максимально безопасно могли бы выполнить апгрейд. К сожалению, это совершенно нетривиально. Во-первых, мы говорим о переломном изменении ABI — ситуация «всё ли ничего». Если в API библиотеки используется time_t, то всё связанное с ней должно использовать ту же ширину типа. В этом посте я бы хотел подробно рассмотреть этот вопрос: почему это плохо и что мы можем сделать, чтобы повысить безопасность.
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".
I've updated my #time_t post a bit, adding a "correction". I've originally missed that the dynamic loader actually processes all library directories via `ld.so.conf`, and so we actually need a way for it to distinguish time32 binaries from time64 binaries.
And overall, the whole thing becomes so complex, so I'm proposing two alternatives: using RPATH instead of patching everything, or using a separate temporary libdir as a transitional measure rather than final ABI element.
https://blogs.gentoo.org/mgorny/2024/09/28/the-perils-of-transition-to-64-bit-time_t/#correction
64-bit time_t 的事情
看到「The perils of transition to 64-bit time_t (gentoo.org)」這篇，原文在「The perils of transition to 64-bit time_t」，Gentoo 的人在討論將 time_t 從 32-bit 換成 64-bit 遇到的困難。
這邊會想把 32-bit time_t 換到 64-bit time_t 的動力是 32-bit 的 time_t 會在 2038 年遇到 integer overflow，這是接下來的十幾年得想辦法的問題。
https://blog.gslin.org/archives/2024/09/30/12010/64-bit-time_t-%e7%9a%84%e4%ba%8b%e6%83%85/
#Computer #Murmuring #Programming #Software #2038 #32bit #64bit #date #int #integer #time #time_t #year
New on blog: "The perils of transition to 64-bit #time_t"
"""
In the "Overview of cross-architecture portability problems", I have dedicated a section to the problems resulting from use of #32-bit `time_t` type. This design decision, still affecting Gentoo systems using glibc, means that 32-bit applications will suddenly start failing in horrible ways in 2038: they will be getting `-1` error instead of the current time, they won't be able to `stat()` files. In one word: complete mayhem will emerge.
There is a general agreement that the way forward is to change `time_t` to a 64-bit type. Musl has already switched to that, glibc supports it as an option. A number of other distributions such as Debian have taken the leap and switched. Unfortunately, source-based distributions such as #Gentoo don't have it that easy. So we are still debating the issue and experimenting, trying to figure out a maximally safe upgrade path for our users.
Unfortunately, that's nowhere near trivial. Above all, we are talking about a breaking ABI change. It's all-or-nothing. If a library uses `time_t` in its API, everything linking to it needs to use the same type width. In this post, I'd like to explore the issue in detail — why is it so bad, and what we can do to make it safer.
"""
https://blogs.gentoo.org/mgorny/2024/09/28/the-perils-of-transition-to-64-bit-time_t/
Against all odds, and totally by accident, 32-bit #time_t helps us find another bug. This time, #LibArchive wasn't validating dates in ISO9660, and some garbage data was parsed as random dates.
Client Info
Server: https://mastodon.social
Version: 2025.07
Repository: https://github.com/cyevgeniy/lmst