Twintig jaar later maakt de Y2K-bug een comeback

Op 03:14:08 Greenwich Mean Time (GMT, aka Coordinated Universal Time) 19 januari 2038 (dat is een dinsdag), eindigt de wereld. Wel, niet in de bijbelse zin van het Boek der Openbaringen. Maar, wat er zal gebeuren is dat de waarde voor tijd in 32-bit gebaseerde Unix-gebaseerde besturingssystemen, zoals Linux en oudere versies van macOS, zonder getallen komt te zitten en de tijd gaat tellen met negatieve getallen. Dat is niet goed. We kunnen verwachten dat 32-bit computers waarop deze besturingssystemen draaien, stuipen krijgen. Gelukkig hadden de ontwikkelaars van Linux al een oplossing klaar liggen.

Het probleem begint met hoe Unix de tijd aangeeft. Unix, en zijn verwanten — Linux, macOS, en andere POSIX-compatibele besturingssystemen — dateren het begin van de tijd vanaf de Epoch: 00:00:00 GMT op 1 januari 1970. De Unix familie meet tijd door het aantal seconden sinds de Epoch.

Zo ver, zo goed. Maar, omdat Unix en de Unix familie begonnen als 32-bit besturingssystemen, wordt de waarde van de tijd bijgehouden als een enkel ondertekend 32-bit integer getal. Dat zijn een heleboel seconden, maar net als de Y2K bug in de vorige eeuw, is het niet genoeg.

Linux ontwikkelaars hebben dit al tientallen jaren zien aankomen. Dus hebben Linux-kernelontwikkelaar Arnd Bergmann en anderen gewerkt aan een reparatie. Deze correcties zitten nu in de aankomende Linux 5.6 kernel. Bergmann legde uit: “Linux-5.6, of mijn backport van de patches naar 5.4, zou de eerste release moeten zijn die kan dienen als basis voor een 32-bits systeem dat is ontworpen om na het jaar 2038 te draaien.”

Er zijn enkele voorbehouden:

  • Alle gebruikersruimte moet worden gecompileerd met een 64-bits time_t, die zal worden ondersteund in de komende musl-1.2 en glibc-2.32 releases, samen met geïnstalleerde kernel headers van Linux-5.6 of hoger.
  • Applicaties die de system call interfaces direct gebruiken, moeten worden geport om de time64 syscalls te gebruiken die in Linux-5.1 zijn toegevoegd in plaats van de bestaande system calls.
  • Toepassingen die een eigen kopie van kernel uapi header-bestanden of de inhoud daarvan gebruiken, moeten mogelijk worden bijgewerkt naar de Linux-5.6 versie.
  • Een paar resterende interfaces kunnen niet worden gewijzigd om een 64-bit time_t op een compatibele manier door te geven, dus ze moeten worden geconfigureerd om CLOCK_MONOTONIC tijden te gebruiken.
  • Alle Epoch-problemen die op 64-bit machines voorkomen, gelden ook voor 32-bit machines. In het bijzonder heeft dit invloed op bestandssystemen met on-disk tijdstempels die ondertekende 32-bits seconden gebruiken: ext4 met ext3-stijl kleine inodes, ext2, xfs (wordt binnenkort gerepareerd) en ufs.

Kortom, er is nog veel opruimwerk te doen, zelfs nadat het kernprobleem is opgelost.

MacOS is al meer dan tien jaar bezig af te stappen van 32-bit software. Maar het was pas in de late 2019-release van macOS Catalina, dat Apple 32-bits apps de boot gaf.

Nu, je vraagt je misschien af — aangezien we tegenwoordig allemaal 64-bits computers gebruiken — waarom is dit zelfs een probleem. Nou, het zit zo. Ten eerste draaien veel embedded systemen en Internet of Things (IoT) -apparaten nog steeds 32-bits besturingssystemen. Sterker nog, in 2038 zullen er waarschijnlijk nog steeds nieuwe 32-bits apparaten op de markt komen.

We weten ook, dankzij de millenniumbug die in 2020 weer de kop opsteekt, dat systemen waarvan je zou denken dat ze over 18 jaar op de vuilnisbelt belanden, nog steeds springlevend zullen zijn — en zich ernstig zullen misdragen als de tijdperken komen.

Maar bekijk het zo: Nadat we dit hebben opgelost, hoeven we ons geen zorgen te maken dat 64-bit Linux geen seconden meer heeft tot 15:30:08 GMT zondag 4 december, 29.227.702.659. Persoonlijk maak ik me daar geen zorgen over.

Gerelateerde verhalen:

  • De Y2K bug is terug, veroorzaakt weer hoofdpijn voor ontwikkelaars
  • Zuid-Korea’s overheid verkent overstap van Windows naar Linux desktop
  • Nastige Linux, macOS sudo bug gevonden en opgelost

admin

Geef een antwoord

Het e-mailadres wordt niet gepubliceerd.

lg