Advertisement · 728 × 90
#
Hashtag
#Y2038
Advertisement · 728 × 90
Original post on det.social

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?

https://y2k38.ch/y2k38-open-source-suendenbock

#y2k38 […]

1 0 0 0
Preview
Le bug de l'an 2038 Le 19 janvier 2038 à 3 h 14 min et 7 s UTC, un bug pire que celui de l’an 2000 menace de faire planter des milliards d’équipements dans le monde – trains, IRM, implants, télécoms, distributeurs… Le...

Although we didn’t make it into the final article, we appreciate being referenced in the sources. The article on #Y2k38 is well worth reading:

www.epsiloon.com/tous-les-num...
www.epsiloon.com

#Y2038 #y2038bug #DasJahr2038Problem #ScienceNews #journalismus

0 0 0 0
Preview
Le bug de l'an 2038 Le 19 janvier 2038 à 3 h 14 min et 7 s UTC, un bug pire que celui de l’an 2000 menace de faire planter des milliards d’équipements dans le monde – trains, IRM, implants, télécoms, distributeurs… Le...

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:

www.epsiloon.com/tous-les-numeros/n57/le_...

#Y2038 #y2038bug #DasJahr2038Problem #ScienceNews #journalismus

0 1 0 0
Preview
FOSDEM 2026 - Pulling 32-bit time_t Asbestos out of the Open Source Ecosystem: Mapping, Triaging, and Coordinating 2038-class Rollover Remediation

Our recommendation for #fosdem

fosdem.org/2026/schedul...

☝️"Pulling 32-bit time_t Asbestos out of the Open Source Ecosystem"

Say hello to treyka if you’re there.

#y2k38 #Y2038 #fosdem26 #fosdem2026

1 0 0 0
Preview
FOSDEM 2026 - Pulling 32-bit time_t Asbestos out of the Open Source Ecosystem: Mapping, Triaging, and Coordinating 2038-class Rollover Remediation

Our recommendation for #fosdem

fosdem.org/2026/schedule/event/KTFE...

☝️"Pulling 32-bit time_t Asbestos out of the Open Source Ecosystem"

Say hello to treyka if you’re there.

#y2k38 #Y2038 #fosdem26 #fosdem2026

0 0 0 0

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

y2k38.ch/digitale-ung...

0 0 0 0
Preview
Digitale Ungleichheit und Y2K38 werden häufig isoliert betrachtet, obwohl sie eng miteinander verknüpft sind. Das Jahr-2038-Problem wirkt noch weit weg. Genau das ist Teil des Problems: Solange 2038 „später“ ist, bleibt vieles liegen. Betroffene Systeme laufen weiterhin im produktiven Betrieb, eine vollständige Erfassung existiert selten und verbindliche Migrationspläne fehlen. Mit jedem Jahr schrumpft das Zeitfenster für saubere Migrationen und damit steigt die Wahrscheinlichkeit, dass am Ende keine elegante Lösung mehr übrig bleibt. Denn Patches und Workarounds funktionieren nur so lange, wie die zugrunde liegende Technik überhaupt noch gepflegt wird. Je näher 2038 rückt, desto öfter wird sich die „Lösung“ auf das reduzieren, was Organisationen am schnellsten durchsetzen können: ersetzen. **Nicht reparieren, nicht modernisieren, sondern austauschen.** Diese Logik ist nicht neu. Sie passt auffällig gut zu dem, was grosse Technologieanbieter ohnehin praktizieren: kurze Produktzyklen, harte Support-Enden, Gerätegenerationen, die sich nicht mehr sinnvoll aktualisieren lassen. In unserem Blog zu Android und Apple haben wir genau diese Mechanik beschrieben – eine Form von geplanter bzw. vorsätzlicher Obsoleszenz, bei der der Austausch zur Standardantwort wird, weil Support oder Updates den Weiterbetrieb wirtschaftlich unattraktiv machen. Damit stellt sich eine Frage, die in der Y2K38-Debatte bislang kaum gestellt wird: **Wohin geht die ausgemusterte Technik?** Erfahrungsgemäss wird sie weiterverkauft, weitergereicht oder exportiert. Das technische Problem wird nicht beseitigt, sondern verlagert – zusammen mit den zeitlichen Grenzen, die in diesen Systemen eingebaut sind. Für Entwicklungs- und viele Schwellenländer ist ein grossflächiger Austausch keine realistische Option. Dort wird Infrastruktur länger genutzt, Updates enden früher, Ersatzteile fehlen, Budgets sind knapp. Wenn die globale Nachfrage nach neuer, 2038-tauglicher Technik steigt, werden diese Länder nicht am Anfang der Lieferkette stehen. Wer heute schon mit Altlasten arbeitet, wird sie auch morgen weiter betreiben müssen. Das Jahr-2038-Problem ist damit mehr als ein Bug. Es ist ein Test dafür, wie wir mit technologischen Altlasten umgehen – und ob wir akzeptieren, dass Risiken dorthin wandern, wo sie am wenigsten abgefedert werden können. ## Y2K38 als strukturelles Altlastenproblem Heutzutage werden Software‑ oder Hardwaresysteme schnell als „Altlast“ bzw. „Legacy-System“ bezeichnet. Doch der Begriff ist unscharf. In der Praxis meint „Legacy“ nicht einfach „alt“, sondern eine Kombination aus technischen, organisatorischen und wirtschaftlichen Merkmalen. Ein System wird selten allein wegen seines Alters zur Altlast. In den meisten Fällen ist es das Ergebnis einer Schwäche oder einer bewussten wirtschaftlichen Entscheidung. Solange ein System funktioniert, wird sein Weiterbetrieb gegenüber einer aufwendigen Migration bevorzugt. Der Austausch gilt als riskant, teuer oder organisatorisch schwer durchsetzbar, während die laufenden Kosten kalkulierbar erscheinen. „Legacy“ beschreibt damit weniger einen technischen Zustand als einen betrieblichen Kompromiss. Es ist die Entscheidung, bekannte Risiken zu akzeptieren, um kurzfristig Stabilität zu wahren. Problematisch wird diese Strategie, wenn externe Grenzen erreicht werden – etwa durch Support-Enden, regulatorische Anforderungen oder feste technische Limits wie im Fall von Y2K38. Dann zeigt sich, dass die vermeintlich rationale Entscheidung zum Weiterbetrieb langfristig neue Abhängigkeiten und Risiken geschaffen hat. Y2K38 unterscheidet sich dabei von vielen anderen Altlasten. Sicherheitslücken, steigende Wartungskosten oder Leistungsprobleme lassen sich priorisieren, absichern oder über längere Zeit akzeptieren. Die Zeitgrenze von 2038 hingegen ist nicht verhandelbar. Sie markiert keinen graduellen Verfall, sondern einen funktionalen Bruch – Die Epochalypse! Systeme liefern ab dem 19. Januar 2038 um 03:14:07 UTC potenziell falsche Zustände oder versagen vollständig. Damit wird aus einer bislang kalkulierten betrieblichen Entscheidung ein strukturelles Risiko, das sich nicht mehr durch Weiterbetrieb oder organisatorische Kompromisse abfedern lässt. **Das Rad der Zeit lässt sich nicht aufhalten!** ## Die Digitale Ungleichheit in Zahlen Internationale Erhebungen von ITU, Weltbank und Marktanalysen zeigen ein konsistentes Bild: Je niedriger das Einkommensniveau eines Landes, desto länger bleiben ältere Technologien im Einsatz – sowohl bei Endgeräten als auch bei Betriebssystemen und Netzinfrastruktur. Um dieses Ausmass greifbar zu machen, lohnt ein Blick auf Länder des sogenannten globalen Südens, in denen sich diese Muster besonders deutlich zeigen. ### Globale Nutzung von Betriebssystemen 2025 Schauen wir auf die weltweit am häufigsten genutzten Android-Versionen nach Ländern, wie sie in der Weltkarte dargestellt sind, wird das Muster deutlich. In vielen Ländern des globalen Südens dominieren Android-Versionen, die bereits mehrere Jahre alt sind. Dazu zählen grosse Teile Afrikas, Südasiens sowie Regionen in Lateinamerika und Südostasien. Dort verteilen sich die Marktanteile auf ältere Hauptversionen, während aktuelle Releases nur eine untergeordnete Rolle spielen. In Industrieländern zeigt sich ein anderes Bild. In Europa, Nordamerika und Teilen Ostasiens konzentriert sich die Nutzung stärker auf neuere Android-Versionen. Der Wechsel auf aktuelle Releases erfolgt dort schneller, ältere Versionen verlieren rascher an Bedeutung. Die Verteilung der Android-Versionen zeigt deutlich unterschiedliche Erneuerungszyklen zwischen Industrie- und Entwicklungsländern. (Quelle: Statcounter) Schauen wir uns die Zahlen für Afrika genauer an, zeigt sich ein deutlich fragmentiertes Bild. Die jeweils neueste Android-Version erreicht dort keinen dominanten Marktanteil, sondern liegt – je nach Release-Stand – nur im Mittelfeld der Verteilung. Mehrere ältere Hauptversionen werden parallel genutzt und erreichen zusammen deutlich höhere Anteile. Auffällig ist vor allem der grosse Anteil älterer Android-Versionen. Versionen unterhalb von Android 13 kommen zusammengenommen auf rund 40 bis 45 Prozent der genutzten Geräte. Für diese Releases stellt Google keine regulären Sicherheits- und Plattform-Updates mehr bereit. Das bedeutet nicht, dass diese Geräte unmittelbar unbrauchbar wären. Es zeigt jedoch, dass ein erheblicher Teil der Android-Basis in Afrika auf Softwareständen arbeitet, deren Weiterentwicklung faktisch beendet ist. Die Verteilung der Android-Versionen in Afrika. Die neuste Version ist nur auf Platz 5 (Quelle: Statcounter) Ein ähnliches Muster zeigt sich bei Windows von Microsoft. Die StatCounter-Weltkarte (Stand: Dezember 2025) weist für viele Entwicklungs- und Schwellenländer weiterhin Windows 10 als dominierende Version aus. In Ländern mit höherer Kaufkraft und kürzeren Erneuerungszyklen setzt sich dagegen zunehmend Windows 11 durch. Relevant ist dabei, dass Windows 10 seit dem 14. Oktober 2025 keinen regulären Support mehr erhält. Die weiterhin hohe Nutzung im globalen Süden zeigt, dass Betriebssystemwechsel dort langsamer erfolgen und bestehende Systeme länger im Einsatz bleiben müssen. Der Unterschied ist weniger technischer Natur als strukturell bedingt – durch Kosten, Hardwareanforderungen und begrenzte Möglichkeiten zum Austausch. Während Windows 11 sich vor allem in wohlhabenden Ländern durchsetzt, bleibt Windows 10 im globalen Süden weit verbreitet. (Quelle: Statcounter) ### Digitale Kluft im Mobile Technologie-Mix Um digitale Ungleichheit noch greifbarer zu machen, lohnt ein Blick auf die Zahlen aus „The Mobile Economy Africa 2025“ von GSMA Intelligence. Der Bericht zeigt die verwendeten Mobilfunktechnologien im Jahr 2025 und erlaubt einen direkten Vergleich zwischen Europa und Afrika. Während in Europa mobile Kommunikation überwiegend über 4G- und zunehmend 5G-Netze abgewickelt wird, spielen in Afrika 2G- und 3G-Netze weiterhin eine zentrale Rolle. Ein erheblicher Teil der Verbindungen basiert dort noch auf älteren Netzgenerationen, die in Europa bereits abgeschaltet werden oder nur noch eine untergeordnete Rolle spielen. Der technologische Abstand zeigt sich damit nicht nur bei Endgeräten oder Betriebssystemen, sondern auf der Ebene der grundlegenden Netzinfrastruktur. ## Afrika (2025) % 5G % 4G % 3G % 2G ## Europa (2025) % 5G % 4G % 3G % 2G Nicht wesentlich optimistischer fällt der Ausblick auf das Jahr 2030 aus, den derselbe GSMA-Report wagt. Zwar geht GSMA von einem weiteren Ausbau moderner Mobilfunknetze in Afrika aus, zugleich zeigt die Prognose jedoch, dass ältere Netzgenerationen auch langfristig nicht vollständig verschwinden. Selbst in den 2030er-Jahren sollen 2G- und 3G-Verbindungen weiterhin eine Rolle spielen, wenn auch mit sinkendem Anteil. ## Afrika (2030) % 5G % 4G % 3G % 2G ## Europa (2030) % 5G % 4G % 3G % 2G Für den laufenden Betrieb bedeutet das, dass Legacy-Hardware und -Software weiterhin erforderlich bleiben. Netze, Endgeräte und darauf aufbauende Dienste müssen über lange Zeiträume parallel auf unterschiedlichen technologischen Ebenen funktionieren. ## Der Export technologischer Altlasten Jährlich gelangen hunderttausende Tonnen gebrauchter Elektronikgeräte aus Industrieländern in Entwicklungsländer. Diese funktionsfähigen Altgeräte – etwa Computer, Monitore, Mobiltelefone oder Unterhaltungselektronik – werden häufig als Second-Hand-Ware exportiert, sei es aus kommerziellen Gründen (Nachfrage nach günstiger Elektronik) oder als Spenden. Eine genaue Quantifizierung ist schwierig, da Handelsstatistiken neue und gebrauchte Geräte nicht unterscheiden. Trotzdem lassen Studien und Schätzungen das Ausmass erkennen: * Europäische Union: Im Jahr 2020 wurden rund 0,6 Millionen Tonnen gebrauchte Elektrogeräte aus der EU legal zum Wiedergebrauch exportiert. Zusätzlich gingen ca. 0,5 Mio. Tonnen als illegale Elektroaltgeräte ins Ausland und weitere 1,5 Mio. Tonnen Altgeräte blieben „unverbleibt“, was häufig als Second-Hand deklariert exportiert wurde. Insgesamt könnten also bis zu 2,6 Mio. Tonnen Altgeräte (etwa ein Viertel des EU-Elektroschrottaufkommens) pro Jahr die EU verlassen (Quelle: _European Environmental Bureau (EEB)_) * Vereinigte Staaten: Nach Recherchen des Basel Action Network (BAN) exportieren die USA monatlich etwa 2.000 Container mit ausrangierter Elektronik – das entspricht ca. 32.947 Tonnen pro Monat (hochgerechnet fast 400.000 Tonnen pro Jahr) – an Empfängerländer, die meist Entwicklungsländer in Asien sind. Dieser Exportstrom hat einen geschätzten Wert von einer Milliarde US-Dollar und umfasst v.a. gebrauchte Computer, Monitore und andere Geräte. * Weltweit nach Afrika: Schätzungen zufolge gelangen mindestens 250.000 Tonnen Alt-Elektronik (EEE) pro Jahr nach Afrika Ein grosser Teil davon geht nach Westafrika, insbesondere in Länder wie Nigeria und Ghana, oft aus Europa. (Quelle: Wikipedia) Diese Zahlen zeigen, dass der Export gebrauchter Elektronik beträchtliche Grössenordnungen erreicht hat. Mit steigendem Geräteverbrauch (die Zahl neuer Elektronikgeräte in der EU hat sich 2013–2022 fast verdoppelt)) und immer kürzeren Nutzungszyklen wächst auch das Aufkommen an Second-Hand-Exporten stetig. ## Second-Hand-Elektronik: gut gemeint, aber nicht gut genug Um digitale Ungleichheit zu verringern, engagieren sich zahlreiche Hilfsorganisationen und Programme gezielt im Bereich der Wiederverwendung von IT-Geräten. Organisationen wie Computer Aid stellen gebrauchte Computer und andere Elektronik Bildungseinrichtungen, Verwaltungen oder gemeinnützigen Projekten im globalen Süden zur Verfügung. Diese Initiativen schaffen kurzfristig Zugang zu Technik und leisten einen wichtigen Beitrag zur digitalen Grundversorgung. Gleichzeitig zeigen sie die Grenzen eines Ansatzes, der sich vor allem auf Hardwarebereitstellung konzentriert. Der langfristige Nutzen gebrauchter Geräte hängt nicht allein davon ab, ob sie zum Zeitpunkt der Übergabe funktionsfähig sind, sondern davon, ob sie dauerhaft betreibbar bleiben. Genau hier entstehen strukturelle Probleme: Software-Support ist häufig bereits eingeschränkt oder endet kurz nach der Weitergabe, Sicherheitsupdates laufen aus, und klare Migrationspfade fehlen. Second-Hand-Programme verlängern damit nicht nur die Lebensdauer von Hardware, sondern auch den Einsatz von Betriebssystemen und Softwareständen, deren Weiterentwicklung faktisch abgeschlossen ist. In vielen Fällen werden Geräte in Umgebungen eingesetzt, in denen sie über Jahre oder sogar Jahrzehnte betrieben werden müssen – deutlich länger, als ursprünglich vorgesehen. Wartung, Ersatzteile und technisches Know-how sind dabei oft nur begrenzt verfügbar. Im Kontext von Y2K38 wird diese Schwäche besonders sichtbar. Die Weitergabe gebrauchter Geräte verschiebt nicht nur ein kurzfristiges Versorgungsproblem, sondern verlängert den Betrieb von Systemen mit festen zeitlichen Grenzen. Ohne begleitende Massnahmen wie regelmässige Updates und rechtzeitige Migrationsstrategien bleibt das Risiko bestehen – unabhängig davon, wie gut die ursprüngliche Absicht war. ## Y2K38: Für Afrika rückt das Jahr 2038 schneller näher 2038 ist für Afrika näher als für Europa oder Nordamerika, nicht weil die Zeit dort anders vergeht, sondern weil die technologischen Voraussetzungen andere sind. Die digitale Kluft äussert sich nicht nur im Zugang zu Technik, sondern vor allem in deren Alter, Wartbarkeit und Erneuerungsfähigkeit. Systeme werden länger betrieben, Softwarestände bleiben über Jahre unverändert, und der Austausch ganzer Infrastrukturen ist deutlich schwieriger. Während in wohlhabenden Ländern Y2K38 zunehmend durch Migration und Austausch adressiert wird, bleibt in vielen afrikanischen Staaten ein grosser Teil der digitalen Infrastruktur auf Legacy-Technik angewiesen. Betriebssysteme ohne Support, ältere Netzgenerationen und Second-Hand-Hardware prägen den Alltag. Damit rückt eine feste technische Grenze wie das Jahr 2038 faktisch näher – nicht kalendarisch, sondern strukturell. Bemühungen, digitale Ungleichheit durch Second-Hand-Spenden zu mindern, sind grundsätzlich sinnvoll und oft gut gemeint. Sie schaffen kurzfristig Zugang zu Technik und schliessen akute Versorgungslücken. Gleichzeitig stossen sie dort an ihre Grenzen, wo Hardware ohne langfristige Softwarepflege weitergegeben wird. Im Kontext von Y2K38 wird diese Schwäche besonders sichtbar. Werden Geräte und Systeme weitergegeben, ohne dass zeitkompatible Softwarestände, Bugfixes oder klare Upgradepfade mitgeliefert werden, verlängert sich der Betrieb von Technik, deren Weiterentwicklung faktisch abgeschlossen ist. In diesem Fall entsteht kein nachhaltiger Nutzen, sondern ein absehbares Risiko. Ohne entsprechende Massnahmen ist die Grenze zwischen Second-Hand-Nutzung und zukünftiger Elektronikabfallproblematik fliessend. Aus Sicht der BEOZ Association stehen insbesondere grosse Technologieunternehmen in der Verantwortung, ihre Altlasten nicht einfach weiterzureichen. Wer durch kurze Produktzyklen, harte Support-Enden und proprietäre Abhängigkeiten den Austausch erzwingt, kann sich nicht darauf beschränken, ausgemusterte Systeme weiterzugeben. Verantwortung endet nicht mit dem Verkauf oder der Spende von Hardware, sondern umfasst auch die **Betriebsfähigkeit über den gesamten Lebenszyklus** – einschliesslich Updates, Sicherheitsfixes und der Behebung zeitkritischer Fehler wie Y2K38. Eigentlich müssten wir weiter sein. Die technischen Zusammenhänge sind seit Jahren bekannt, die betroffenen Systeme identifizierbar. Dass dennoch vor allem die ärmsten Regionen die Folgen tragen, ist kein technisches Versagen, sondern eine bewusste Unterlassung. **Y2K38 wird dieses Versagen offenlegen – sofern wir nicht handeln.**

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

y2k38.ch/digitale-ungleichheit-y2...

0 1 0 0
Preview
Herstellerhaftung Jahr-2038-Problem: Urteil zum Y2K38-Bug Das Jahr-2038-Problem erreicht die Gerichte: Ein Urteil zum Y2K38-Bug klärt die Herstellerhaftung bei Softwarefehlern in kritischen Systemen.

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 #y2038bug

y2k38.ch/herstellerha...

2 0 0 0
Original post on det.social

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 #y2038bug […]

1 3 0 0
Preview
**13. Mai 2006, kurz nach Mitternacht UTC.** Einige Webserver rund um den Globus beginnen plötzlich zu stolpern. Prozesse frieren ein, geplante Tasks bleiben hängen, manche Maschinen wirken, als seien sie in einer Zeitschleife gefangen. Kein Angriff, kein Stromausfall – sondern etwas viel Grundsätzlicheres: Die Zeit selbst gerät aus dem Takt. Für die meisten Administratoren war es ein Rätsel. Für AOLserver, den damals weitverbreiteten Open-Source-Webserver, markierte dieser Moment das Ende von „Nie“ – oder, poetischer gesagt: das Ende der Ewigkeit. Aus einem unscheinbaren Timeout-Wert wurde an diesem Tag ein Stück Computergeschichte: die Geburtsstunde des Y2K38-Bugs. ## The Edge of Time – Das Ende der Ewigkeit Die Zeit, wie Computer sie verstehen, ist keine mystische Größe. Sie beginnt an einem klar definierten Punkt: dem 1. Januar 1970, 00:00:00 UTC. Seit diesem Moment zählt ein einfacher Zahlenwert jede vergangene Sekunde – die sogenannte Unixzeit. Sie ist das Fundament nahezu aller modernen Betriebssysteme: von Linux und macOS bis zu Android und zahllosen eingebetteten Geräten. Doch dieser scheinbar endlose Zähler hat eine Grenze. In klassischen 32-Bit-Systemen kann die Unixzeit nur bis 2 147 483 647 Sekunden reichen. Danach „läuft sie über“. Dieser Moment wird am 19. Januar 2038 um 03:14:07 UTC eintreten – der Zeitpunkt, an dem alle Programme, die mit einer signierten 32-Bit-Zeit arbeiten, plötzlich in die Vergangenheit springen: in das Jahr 1901. Wir von der BEOZ Association bezeichnen diesen Moment als **„The Edge of Time“** – die rechnerische Kante der digitalen Gegenwart. Andere sprechen von der **„Epochalypse“** , in Anlehnung an die „Unix Epoch“, also den Beginn dieser Zeitrechnung. Was nach Science-Fiction klingt, ist ein sehr reales technisches Problem: Zahlreiche Systeme – von älteren Datenbanken über IoT-Geräte bis hin zu industriellen Steuerungen – speichern Zeitwerte noch immer in diesem 32-Bit-Format. Wenn sich die interne Uhr einem Wert nähert, den sie nicht mehr darstellen kann, entstehen Überläufe: Berechnungen liefern negative Ergebnisse, Timer laufen sofort ab, Protokolle springen in die Vergangenheit. Das Jahr 2038 markiert somit keine symbolische Grenze, sondern eine technische Singularität, an der sich zeigt, wie eng Mathematik und Realität in der Informatik verknüpft sind. Und während für viele Systeme diese Grenze noch bevorsteht, traf sie eines schon früher – im Mai 2006, als der Webserver AOLserver mit einer „unendlichen“ Zahl über die Kante der Zeit hinausrechnete. ## Wenn ‚Nie‘ zu Ende geht – AOLserver-Timeout deckt Jahr 2038 Problem auf Im Frühjahr 2006 traten bei mehreren Installationen des Open-Source-Webservers AOLserver unerklärliche Ausfälle auf. Geplante Aufgaben liefen nicht mehr, Datenbankverbindungen blieben hängen, einzelne Prozesse froren scheinbar ohne Grund ein. Die Systeme waren stabil, die Netzwerke gesund – und doch geriet der Server ins Straucheln. Die Spur führte zu einer unauffälligen Stelle in der Konfiguration: MaxOpen = 1000000000 MaxIdle = 1000000000 Diese Werte, in Sekunden angegeben, sollten sicherstellen, dass Verbindungen zu Datenbanken niemals automatisch geschlossen werden. „Eine Milliarde Sekunden“ – etwa 31,7 Jahre – erschien lang genug, um als „ewig“ zu gelten. Doch diese scheinbar harmlose Zahl brachte den Server aus dem Gleichgewicht. Am 13. Mai 2006 erreichte die aktuelle Zeit den Punkt, an dem „jetzt + 1 000 000 000 Sekunden“ erstmals über die 32-Bit-Zeitgrenze von 2 147 483 647 Sekunden hinausführte. Aus einem zukünftigen Zeitpunkt wurde – rechnerisch – ein Datum in der Vergangenheit. AOLserver interpretierte die betroffenen Zeitstempel als längst abgelaufen: Verbindungen wurden sofort beendet, Timer sprangen auf null, Scheduler blockierten. In der Entwickler-Mailingliste identifizierte Dossy Shiobara, der damalige Maintainer, die Ursache: > „For those who are curious, here’s the explanation as to what was going on back in May 2006 when AOLserver installations started mysteriously «hanging». > > It turns out that the default MaxOpen and MaxIdle values in some OpenACS sample configuration files are set to 1000000000 (1 billion) seconds, which works out to about 31.7 years. When these values are added to the current system time (now), the resulting timeout value overflows the signed 32-bit integer that represents Unix time. > > This causes the calculated timeout to be negative, so connections appear to have already expired, or the server simply hangs waiting for an impossible timeout in the past. > > So, yes — this is basically a manifestation of the Year 2038 problem, it just happened early because of the configuration.» > > _„Für alle, die es interessiert, hier die Erklärung, was im Mai 2006 passierte, als AOLserver-Installationen plötzlich auf mysteriöse Weise „einfrieren“ begannen._ > > _Es stellte sich heraus, dass in einigen Beispiel-Konfigurationsdateien von OpenACS die Standardwerte für MaxOpen und MaxIdle auf 1 000 000 000 Sekunden (eine Milliarde Sekunden) gesetzt sind, was etwa 31,7 Jahren entspricht. > Wenn diese Werte zur aktuellen Systemzeit (now) addiert werden, überläuft das Ergebnis den signierten 32-Bit-Integer, der die Unixzeit darstellt._ > > _Dadurch wird der berechnete Timeout-Wert negativ, sodass Verbindungen so erscheinen, als wären sie bereits abgelaufen – oder der Server hängt sich einfach auf, weil er auf einen unmöglichen Timeout in der Vergangenheit wartet._ > > _Ja, das ist im Grunde eine Ausprägung des Jahr-2038-Problems – sie trat nur früher auf, weil sie durch die Konfiguration ausgelöst wurde.“_ > > – Dossy Shiobara (2006) Das Problem war also kein klassischer Programmierfehler, sondern ein Grenzfall der Zeitdarstellung. Die Unixzeit, seit 1970 als fortlaufende Zahl von Sekunden gezählt, war für diese Berechnung schlicht zu klein. Was als praktische Abkürzung für „niemals“ gedacht war, wurde zur ungewollten Zeitbombe. Shiobara empfahl, die Werte durch realistische Limits zu ersetzen – zum Beispiel 3600 Sekunden (eine Stunde) oder 0 für „deaktiviert“. Betroffen waren vor allem Konfigurationen, die auf Empfehlungen aus dem OpenACS-Projekt basierten. Auf Solaris-Systemen führte der Überlauf zu Fehlermeldungen (_EINVAL_ bei _pthread_cond_timedwai_ t), während Linux-Systeme sich einfach „aufhängten“. Der Vorfall machte erstmals deutlich, dass das Jahr-2038-Problem keine ferne Theorie war, sondern eine konkrete, messbare Schwachstelle in realen Anwendungen. Eine falsche Annahme über Zeit – und das Vertrauen, dass „ewig“ auch im Code ewig bleibt – reichten aus, um produktive Systeme lahmzulegen. In einem späteren Blog-Post brachte es Dossy Shiobara, Maintainer des AOLservers, prägnant auf den Punkt: > «You could call this the first “Y2038” bug» > > _„Man könnte dies den ersten ‚Y2038‘-Fehler nennen“_ > > – Dossy Shiobara (2006)

Der erste dokumentierte #Y2k38-Bug – 32 Jahre vor 2038.

The Edge of Time - Die Ewigkeit endet 2038.

https://y2k38.ch/aolserver-2038-problem-y2k38-bug/

#Y2038 #AOLserver

0 1 0 0

Bitcoin und das Jahr-2038-Problem: gelöst – schon 2010.
Satoshi Nakamoto kannte das Problem.
2038 kein Risiko, aber 2106 bleibt die Deadline.
👉 y2k38.ch/bitcoin-und-das-jahr-203...

#y2k38 #Bitcoin #satoshi #y2038

0 0 0 0
Preview
Bitcoin und das Jahr-2038-Problem – Weitsicht von Satoshi Nakamato Bitcoin und das Jahr-2038-Problem: Satoshi Nakamoto sicherte Bitcoin schon 2010 ab – Zeitstempel, Unsigned-Int und 2106 bleiben entscheidend.

Bitcoin und das Jahr-2038-Problem: gelöst – schon 2010.
Satoshi Nakamoto baute Zeitrobustheit direkt ins Protokoll.
2038 kein Risiko, aber 2106 bleibt die Deadline.
👉 y2k38.ch/bitcoin-und-...
#Bitcoin #Y2038 #Satoshi

2 0 0 0
03 - BruCON 0x11 - Epochalypse Now The Coming Collapse of Time Integrity Trey Darley  Pedro Umbelino
03 - BruCON 0x11 - Epochalypse Now The Coming Collapse of Time Integrity Trey Darley Pedro Umbelino YouTube video by BruCON Security Conference

Good topic here that Paul vixie shared on LinkedIn. In summary some analysis show how the #y2038 problem might show up. In short, everywhere including certificates and your TV. Our dependencies on TIME are a much bigger problem than in 1999.

youtu.be/L9m9lhx25Gg?...

0 0 0 0

Good topic here that Paul vixie shared on LinkedIn. In summary some analysis on how the #y2038 problem might show up. In short, everywhere including certificates and your TV.

https://youtu.be/L9m9lhx25Gg?si=dlS4w2rlQjku0ex2

0 0 0 0
Original post on det.social

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 […]

1 0 0 0
Preview
time_t Cast Away: Y2K38 Bug durch Bits über Bord Direct time_t Casts werfen Bits über Bord – und holen den Y2K38 Bug zurück. Warum 64-Bit-time_t allein die Epochalypse nicht verhindert.

👉 Neuer Blog:

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.

🔗 y2k38.ch/time-t-cast-...

#Y2K38 #time_t #CProgramming #Year2038Problem #Y2038 #2038Problem #CastAway

1 0 0 0
Original post on det.social

👉 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 ☺️ […]

0 0 0 0

#Overview HN chat on Y2038 #EpochalypseProject. Debates severity, Y2K parallels, challenges updating embedded systems, & balancing awareness vs. alarm. A future tech hurdle? #Y2038 1/5

2 0 1 0
Y2038: utmp, wtmp and lastlog
Y2038: utmp, wtmp and lastlog YouTube video by openSUSE

#Y2038 isn’t just a 32-bit issue! On bi-arch systems, the Year 2038 bug still lurks in places like utmp, wtmp, btmp, and lastlog. Watch how #openSUSE tackles it. youtu.be/4biGLiBBIds?...

7 2 0 0
Gee, devant un tableau indiquant des prononciations : « Integer qui se prononce “ine-té-DJEUR” et non “ine-té-GUEUR” comme on l'entend trop souvent*.  Tiens, c'est rigolo, c'est exactement comme pour mon pseudo.  Je rappelle que le prochain qui m'appelle “Gui” au lieu de “Dji”, j'lui pète la jeule.

Gee, devant un tableau indiquant des prononciations : « Integer qui se prononce “ine-té-DJEUR” et non “ine-té-GUEUR” comme on l'entend trop souvent*. Tiens, c'est rigolo, c'est exactement comme pour mon pseudo. Je rappelle que le prochain qui m'appelle “Gui” au lieu de “Dji”, j'lui pète la jeule.

[Archive — 2016] Le bug de l'an 2038

Vous avez aimé le bug de l'an 2000 ? Celui-là sera pas mal non plus. L'occasion de rappeler la *vraie* prononciation de « integer ».

▶️ Lire cette BD : grisebouille.net/le-bug-de-la...

#archive #BD #GriseBouille #humour #bug #bug2038 #Y2038 #date

0 1 0 0

Zum 85. Geburtstag: "Chuck Norris kann das Jahr 2038 Problem lösen"

#Y2038 #y2k38 #chucknorris

1 0 0 0
Preview
Fedora 43 and RPM 6.0, JPEG-XL wallpapers, and more… While Fedora 42 is still in works, which is expected to release in April, Fedora 43 has been planned for major changes, such as adding support for RPM 6.0, wallpapers that are in the JPEG-XL format, and much more to come. Fedora 43 will feature the following big changes: Fedora 43, starting from that version, will use RPM 6.0 package manager, which will improve security across many aspects by introducing enforced signature checking for packages, OpenPGP key handling improvements, support for multiple signatures per package, automatic packag signing at build time, and signing with Sequoia-sq as an alternative to GnuPG.

Fedora 43 will provide improved user experience!

#Fedora #FedoraLinux #Linux #TechNews #TechUpdates #Computers #Fedora43 #Year2038 #Y2038 #Y2038Problem #Year2038Problem

0 0 0 0
Preview
FreeBSD 13.5 Overcomes UFS Y2038 Problem To Push It Out To Year 2106 Following last week's FreeBSD 13.5 Beta 1 release to kick off this next FreeBSD 13 point release that will also end the series, FreeBSD 13.5 Beta 2 is out this weekend for testing.

#FreeBSD 13.5 Overcomes UFS #Y2038 Problem To Push It Out To Year 2106 - Phoronix

www.phoronix.com/news/FreeBSD...

4 0 0 0

For those of us in charge of IT back then, who worked around the clock (pun intended) to ensure you could all call it a nothingburger, you’re welcome. Next up is #Y2038… time to #hugageek again

1 0 0 0
Surviving 19 Jan 2038 on 32 Bit Platforms: Lessons Learned and Common Problems - Alexander Kanav...
Surviving 19 Jan 2038 on 32 Bit Platforms: Lessons Learned and Common Problems - Alexander Kanav... YouTube video by The Linux Foundation

Are you confident to travel or stay in a hospital on 19. January 2038? Do you have a wood heated cabin to stay in?"...gute Frage 🤔

#y2k38 #y2038 Das Jahr 2038 Problem Thema an der #linuxcon @ #opensourcesummit
Ein Talk von Alexander Kanavin,Linutronix hier zum nachschauen
youtu.be/eaOHJHFMobw?...

0 0 0 0
Original post on det.social

"Are you confident to travel or stay in a hospital on 19. January 2038? Do you have a wood heated cabin to stay in?"...gute Frage 🤔

#y2k38 #y2038 Das Jahr 2038 Problem Thema an der #linuxcon @ #opensourcesummit

Ein Talk von Alexander Kanavin,Linutronix hier zum nachschauen […]

0 0 0 0
Preview
Y2038: utmp, wtmp and lastlog The year 2038 problem (also known as Y2038) is a time formatting bug on Unix systems with representing times after 03:14:07 UTC on 19 January 2038. This happens with a 32bit time_t, not with a 64bit time_t. The general statement so far has always been that on 64bit systems with a 64bit time_t you are safe with respect to the Y2038 problem. But this isn't correct: on bi-arch systems like x86-64 (so which can execute 64bit and 32bit binaries) glibc defines __WORDSIZE_TIME64_COMPAT32, which leads to the fact, that struct utmp (used for utmp, wtmp and btmp) and struct lastlog uses int32_t instead of time_t. So we have a Y2038 problem, which is not easy fixable, as this would require ABI and on disk format changes. In this talk I will speak about the background, which tools are affected and how we solved that in openSUSE by dropping utmp, wtmp, btmp and lastlog completely and make use of systemd-logind and other tools instead.

🕒 Solve the #Y2038 problem with #openSUSE! 64-bit systems with 32-bit compatibility still face issues due to specific #data structures. See how we are ensuring systems are future-proof. #oSC2024 #Y2038 events.opensuse.org/conferences/...

0 0 0 0

Happy 1,700,000,000 seconds since the UNIX #epoch!

Only 447,483,648 seconds (under 14.2 years) to go until #y2038!

Blog post from a few years back: www.akamai.com/blog/perform...

2 0 1 0