Problem roku 2038 - co stanie się z komputerami? (film, 8 minut)
Kanał 0xLOUISDEV przedstawia poważny problem, który czeka nas w przyszłości, zwany problemem roku 2038. Zdarzenie to ma miejsce 19 stycznia 2038 roku, dokładnie o 3:14:07. Problem ten wynika z długoterminowego sposobu przechowywania i obsługi czasu w oprogramowaniu. Przykładowo, w prezentacji pokazano prosty program na serwerze Linux, który co sekundę wyświetla bieżący czas systemowy. Gdy ustawiono czas systemowy na kilka sekund przed tym tajemniczym momentem, program zamarł, a po restarcie data systemowa została ustawiona na grudzień 1901 roku. Tak drastyczna zmiana wymaga wyjaśnienia, a kluczem do zrozumienia tego zjawiska jest sposób, w jaki komputery liczą czas.
Komputery liczą czas, przechowując ilość sekund, które upłynęły od 1 stycznia 1970 roku, znanego także jako stempel czasowy Unix. W większości przypadków ten stempel czasowy przechowywany jest jako tzw. signed 32-bit integer, co oznacza, że ma on na stałe ustaloną wielkość 32-bitów. Maksymalna wartość tego zmiennego formatu, dzielona przez 2 minus 1, prowadzi do daty 19 stycznia 2038 roku. Gdy zmienna, która co sekundę zwiększa się, osiąga maksymalną wartość, wraca do swojego minimalnego poziomu, co prowadzi do resetu data systemu na 1901 rok. Tak samo stało się w przypadku zaprezentowanego programu, który zawiesił się na skutek powrotu do daty początkowej.
W filmie przewidziano również, że te problemy nie ograniczają się tylko do komputerów. Stary sprzęt, który nie może być aktualizowany, wciąż jest szeroko rozprzestrzeniony. Ma to poważne konsekwencje w kontekście infrastruktury społecznej, obejmującej transport publiczny, urządzenia medyczne, czy finansowe. Jak zauważono, problemy mogą pojawić się nawet w nowoczesnych samochodach, których oprogramowanie nie zawsze można aktualizować zdalnie. Nie każdy producent potrafi w sposób elastyczny dostosować swoje systemy. Ta sytuacja przypomina, jak małe zaniedbania w projektowaniu technologii mogą prowadzić do dalszych i rozległych konsekwencji.
Film podkreśla również, jak ważne jest myślenie o przyszłości i utrzymywaniu technologii, na których obecnie polegamy. W obliczu postępu w dziedzinie sztucznej inteligencji i zaawansowanej technologii, kluczowe staje się zapewnienie, że ustawione teraz standardy techniczne będą miały długofalowy pozytywny wpływ. Każdy z nas powinien zastanowić się nad tym, jak nasze obecne wybory technologiczne mogą wpłynąć na przyszłe pokolenia. Nawiasem mówiąc, problem roku 2038 zbliża się do nas szybciej, niż można się spodziewać; jesteśmy bliżej 2038 niż roku 2000.
Na koniec warto wspomnieć o statystykach dotyczących tego wideo. Na moment pisania tego artykułu film był obejrzany 3890 razy i zdobył 142 polubienia. Zachęcamy do dalszego śledzenia kanału 0xLOUISDEV, aby być na bieżąco z ważnymi tematami technologii i ich przyszłością.
Toggle timeline summary
-
Wprowadzenie do problemu roku 2038 i jego znaczenia.
-
Szczegóły dotyczące wpływu na urządzenia elektroniczne.
-
Wyjaśnienie historycznego kontekstu obsługi czasu w oprogramowaniu.
-
Demonstracja na serwerze Linuxa pokazująca program wyprowadzający czas systemowy.
-
Symulacja wydarzenia zaplanowanego na 19 stycznia 2038 roku.
-
Wyjaśnienie, jak komputery śledzą czas od 1 stycznia 1970 roku.
-
Przegląd ograniczenia 32-bitowych liczb całkowitych w przechowywaniu znaczników czasowych.
-
Dyskusja na temat przepełnienia liczb całkowitych i jego konsekwencji.
-
Zrozumienie zresetowania systemu do 1901 roku z powodu przepełnienia znacznika czasowego.
-
Odniesienie do wcześniejszego, głośnego przypadku przepełnienia liczb całkowitych z YouTube.
-
Proponowane rozwiązanie polegające na konwersji na 64-bitowe liczby całkowite, aby uniknąć przyszłych problemów.
-
Dyskusja na temat znaczenia przygotowania i modernizacji sprzętu.
-
Obawy dotyczące przestarzałych systemów i głęboko osadzonej technologii.
-
Wpływ problemu na oprogramowanie samochodowe i świadomość producentów.
-
Refleksja na temat technologicznego niedopatrzenia i jego długoterminowych konsekwencji.
-
Zachęta do rozważenia przyszłych implikacji obecnych standardów technologicznych.
-
Podsumowanie i zaproszenie do obejrzenia dodatkowych treści.
Transcription
On January 19th, 2038, at exactly 14 minutes and 7 seconds past 3 a.m., something predictable yet unforeseen will happen in the software of many computers. And the thing is, we don't even know the full scope of that future incident and how bad electronic devices of any kind including for example cars will be affected. It is called the year 2038 problem and the result of a long ago chosen way of storing and handling time in software code. Let me demonstrate it to you with a basic Linux server. I wrote a simple program which will output the current system time every second. But before we execute it, let's set the system time to a few seconds before that mysterious date so we can simulate the event. Look what happens when we hit the 7th second. The program freezes, no response. So I manually restarted and suddenly the system date is set to December 1901. How did that happen? To understand why this happened and why that exact second of that date in 2038 plays such a significant role, we have to understand how time works in computer software. Computers count time by storing how many seconds have passed since January 1st 1970. That exact date is a set standard which every programmer uses. A more precise format which works in that exact same way is to count the milliseconds from that date on, but we will only focus on the seconds. This timestamp will in many cases be saved in the software code as a so-called signed 32-bit integer, which is basically a slot in the computer memory with a fixed size of 32-bit which will be assigned to our code when we need it. We can read and write data from it, in this case a number, the seconds passed since 1970. This unique time format might seem a bit weird at first, but it makes it really easy for programmers to handle time in code. You for example want to measure how long it took to execute a specific part of a code? Just save the current Unix timestamp at the start and subtract it from the timestamp at the finish time. Then you get the seconds passed between those two events. But like I said, this type of variable, which is used to store their timestamp, has a fixed size. The maximum value it can contain is 2 to the power of 32 divided by 2 minus 1, which translates into January 19th, 2038, 3 hours, 14 minutes and 8 seconds UTC time zone. You now might already see the problem here. What happens to a computer when a timestamp variable which increments every second reaches its maximum value? When signed integers reach their limit, they will wrap around to their minimum value. It's basically the computer equivalent of trying to count to 6 on one hand. You just can't. And that is what happens in 2038. This also explains why in our demonstration, our system time was suddenly set to 1901. Our Unix timestamp started counting at 0 and subtracting 2,147,483,647 seconds from January 1st, 1970, our zero reference point, will bring us to exactly that date and time in 1901. In our simulation, the Linux server itself did not crash. It just reset its time accordingly to 1901. But some code can't handle those kind of negative values at all and will just freeze or crash, like my program which printed the system time every second. Another well-known integer overflow incident was caused by the Gangnam Style YouTube video. In 2014, the amount of viewers exceeded the 32-bit integer limit which forced YouTube to change the variable to a 64-bit integer. And that's in general also the most established fix for this problem. The currently used 32-bits can only represent up to 70 years. By updating to 64-bits, we can suddenly store more time than the estimated lifespan of the universe. So as you can see, the solution is technically not even difficult. So what makes that event such a big deal? What can we expect to happen? With enough preparation, the most critical parts of our society's technical infrastructure will be safe. We already made first fixes by upgrading to 64-bit hardware. However, the memory size problem is not restricted to hardware. There also has to be made according changes in the software, too. Any system that can be remotely updated will most likely be fine. The most concerning will be old computers which are still in use at that day and software that is not being maintained anymore. But outdated systems are up to this day still widely deployed more than you might think. We will also have serious issues with deeply embedded systems such as all public transportation and airplane hardware, financial systems, medical devices, digital cameras, digital watches, network routers, and maybe even systems like satellite computers. You see, this problem affects even more devices than you might think. And the list could go on even further. We may end up with a significant amount of cars that could experience serious issues in their embedded software. Of course, car manufacturers are aware of the potential impact Of course, car manufacturers are aware of the potential impact on their vehicles, but not every car can be remotely updated and patched. The consequences could range from minor inconveniences to serious safety issues with the vehicles. The year 2038 problem reminds us that seemingly small oversights when developing and establishing new technologies can have massive and far-reaching consequences that impact our entire infrastructure. Moreover, this problem brings up the question of how we can maintain and sustain our technological infrastructure over time. As our world becomes increasingly reliant on technology, it's important that we think critically about how we can create systems that are resilient and able to adapt to changes over time. Especially in the development peak of AI which we currently experience, we have to keep in mind that deeply embedded technical standards which we set now can and will have a massive impact in the future. We are closer to 2038 than to the year 2000. 2038 is in only 15 years from now. Thanks for watching, I hope you enjoyed this video. If so, you might also be interested in one of those two videos I made.