Ondřej Caletka: Odkud se berou IP adresy?
Co se dozvíte v článku
IP adresa je číslo z omezeného rozsahu, které slouží zároveň jako identifikátor a lokátor. Identifikátor je třeba telefonní číslo. Můžete se přestěhovat nebo změnit operátora a můžete si číslo nechat.
Proti tomu lokátor je něco jako poštovní adresa, která slouží k tomu, aby vás někdo našel. Když se přestěhujete, nemůžete si nechat původní poštovní adresu.
IP adresy tedy nemůžeme přidělovat náhodně.
Aby IP adresa fungovala jako identifikátor, musí být unikátní. Jak zařídit takovou unikátnost? Jedině nějakým centrálním registrem.
Ten původně tvořil jen jediný člověk, John Postel, který měl velký sešit, do kterého si zapisoval jednotlivé příděly adres. Po jeho smrti tato funkce přešla do mezinárodní korporace ICANN, která provozuje registr IANA. Ten dříve přímo přiděloval bloky adres jednotlivým organizacím po celém světě.
Jak internet rostl, přestal tento způsob škálovat, protože se jednotlivé bloky přidělovaly náhodně různým organizacím, které byly sice geograficky blízké, ale jejich adresy byly náhodně vzdálené. Nefungovalo to tedy jako lokátor a bylo potřeba vymyslet nový hierarchický systém.
Vzniklo proto pět regionálních registrů, což jsou neziskové organizace financované členskými příspěvky a řízené internetovou komunitou. Jsou to neutrální, nestranné, otevřené a transparentní organizace.
Jsou vlastně monopolní a v Evropě není možné chtít adresy z registru v Jižní Americe. Musejí umožnit všem provozovat internet.
RIPE je otevřené fórum založené v roce 1989, kdy internetové sítě přišly do Evropy. Akademici se rozhodli, že by bylo vhodné založit otevřené fórum, aby bylo možné určovat pravidla přidělování adres.
Původní skupina dobrovolníků ale přestala brzy stačit a v roce 1992 byla založena nizozemská servisní organizace RIPE NCC, která už má vlastní kanceláře a zaměstnance a která vyžaduje členství. Ta nyní implementuje pravidla vymyšlená komunitou a přerozděluje IP adresy a čísla AS.
RIPE NCC tedy provozuje registr internetových číselných zdrojů, zajišťuje sekretariát pro komunitu RIPE a zároveň je zdrojem informací a znalostí.
Na vrcholu hierarchie pro rozdělování IP adres je IANA, která dělí prostor na velké bloky, které pak předává pěti regionálním registrů. Ty pak přidělují takzvané alokace jednotlivým LIR, tedy místním internetovým registrům. Typicky je to poskytovatel připojení k internetu a také musí být členem RIPE NCC.
Tyto společnosti pak své příděly kouskují a přidělují koncovým uživatelům. Typicky to nejsou jednotliví uživatelé, ale spíše celé firmy nebo třeba univerzity.
Používají se tu pojmy alokace a příděl, které znamenají něco jiného. Když peníze alokujete, tak je neutrácíte, jen je vyhradíte ke konkrétnímu účelu.
Alokovaný blok také ještě není využitý, ale můžeme jej přidělit konkrétnímu zákazníkovi. Teprve přidělené adresy jsou doopravdy použité.
Alokovaný blok je možné využít ke konkrétním účelům stanovených pravidly. Alokace není vaše, jen ji můžete využívat.
Existují dva typy alokací: PA a PI. PA znamená Provider-Aggregatable, což jsou adresy přidělené z alokace poskytovatele (LIR). Pokud je používají stovky klientů, stále vystupují v internetu jako jeden blok. Když zákazník změní poskytovatele, musí zároveň změnit adresy.
Adresy jsou stále součástí bloku, které jsou pořád součástí nadřazené entity. To vytváří závislost na poskytovateli připojení, protože vám přidělil nějaké adresy a změna může být velmi nákladná.
Proti tomu PI znamená Provider-Independent, což je režim, který porušuje hierarchický princip. Adresy jsou přímo z RIPE NCC přidělovány koncovým uživatelům, kteří pak vystupují jako samostatná síť a je možné měnit poskytovatele nebo jich mít víc.
Proč tedy nejsou všechny adresy nezávislé, když je to výhodné? Nezávislé adresy totiž nejsou hierarchické a každý blok má pak samostatná záznam v globální směrovací tabulce. Aktuálně je v ní asi milion bloků IPv4 a 240 tisíc bloků IPv6.
Ochrana proti neomezenému růstu tabulky spočívá v tom, že operátoři filtrují velmi malé bloky.
RIPE NCC distribuuje také takzvaná čísla autonomního systému (ASN), která slouží k identifikaci samostatných entit v protokolu BGP. To je čistě plochá struktura bez hierarchie.
Dříve šlo o 16bitové číslo a existoval prostor jen pro 65 tisíc sítí, dnes používáme 32bitové číslo, kde je možné přidělit 4 miliardy identifikátorů. Číslo autonomního systému dostane jen ten, kdo ho potřebuje. Buď jste samostatný poskytovatel propojený s více sítěmi, nebo jste koncová síť s nezávislými adresami, která chce být připojena prostřednictvím více poskytovatelů zároveň.
Podmínky získání IP adres se liší podle toho, zda jste poskytovatelem nebo koncovým uživatelem. Poskytovatel se musí stát členem RIPE NCC a platit členské poplatky, což je aktuálně 1800 eur bez daně ročně. Pro získání IPv6 adres stačí prohlásit, že máte plán nasazení IPv6 v následujících dvou letech.
Získání první IPv6 alokace rozsahu /32 až /29 je tedy velmi snadné, ale pro získání dalších adres je nutné prokázat, že jste předchozí adresy už využili.
Pokud jste koncový uživatel, nemusíte být členem RIPE NCC, ale musíte uzavřít smlouvu se sponzoring LIR, což může být libovolný člen, který bude vašim zástupcem při komunikaci s RIPE NCC. Není nutné, aby to byl váš poskytovatel připojení, ale je to nejběžnější varianta.
Následně je možné získat příděl o velikosti /48, což je standardní příděl v IPv6. Platí se za to regulační poplatek ve výši 75 eur ročně.
V IPv4 je situace složitější, protože adresy došly. Členové platící poplatek o ně ale mohou přesto požádat. Žádné adresy už nemáme a musíte se zapsat na čekací listinu.
To ale jen v případě, že jste ještě žádné IPv4 adresy dříve nezískali. Další alokace je možné převést od jiného LIR. V případě koncových uživatelů už není možné od roku 2012 žádné PI adresy přidělit, ale opět lze převést PI adresy dříve přidělené někomu jinému.
V současné době čeká ve frontě asi 900 členů a čeká se přibližně dva roky. Nedáváme žádné garance, nemáme žádný tajný zdroj IPv4 adres. Můžeme přidělovat jen adresy, které se nám vrátí.
Nelze ale říct, jestli se opravdu do dvou let dostatečný počet adres objeví a čekající bude uspokojen.
Hlavní činnost RIPE NCC dnes spočívá v provádění převodů adres. Provozujeme registr, něco jako katastr nemovitostí. Všechny převody tedy musejí probíhat přes nás, na základě smlouvy.
Lze převádět adresy IPv4 i IPv6 a také čísla autonomních systému. Pro IPv6 a ASN musí příjemce splnit podmínky potřeby.
Alokaci lze provádět pouze mezi LIRy a pro IPv4 platí minimální doba držení dva roky. To je opatření proti spekulativním prodejům, které úplně dobře nefunguje.
Jako poskytovatel musíte platit členské poplatky, udržovat svá data aktuální a registrovat všechny příděly ze svých alokací v RIPE Databázi. Musíte zveřejňovat v databázi informace o tom, k jakému účelu přidělujete tu kterou část alokace.
Pokud máte adresy přidělené jako koncový uživatel, nesmíte provádět pod-přidělení, tedy přerozdělovat adresy třetím stranám.
Všechny alokace a přidělení se objevují v RIPE Databázi, která slouží ke kontaktování správné osoby v případě problémů. Informace lze najít ve výstupu příkazu whois a slouží také jako Internet Routing Registry. RIPE NCC databázi spravuje, ale negarantuje správnost všech dat. Dokáže zajistit jen správnost dat, která přímo udržuje.
Pravidla vynucuje RIPE NCC, ale vytváří je RIPE – otevřené fórum evropských sítí postavených na protokolu IP. Neexistuje tu členství a nehlasuje se, ale změny se činí na základě hrubého konsensu.
To neznamená, že musejí všichni souhlasit, ale že jsou všechny nesouhlasné připomínky vypořádány. Fórum pracuje v pracovních skupinách a návrhy změn jsou předloženy příslušné pracovní skupině.
Následně se návrh připomínkuje, zpracuje se analýza vlivu, vypořádají se připomínky a pak se návrh případně přijme nebo vrátí.
RIPE NCC ale není jen registr, ale také provozuje kořenový DNS server k.root-servers.net, provozuje systémy RIS, RIPEstat a RIPE Atlas a také vyjednává s vládami, regulátory a OČTŘ. Podporujeme také lokální komunity, v Česku a na Slovensku je to CSNOG.
Michal Koutný: Hodné, zlé a ošklivé syscally
Syscall je přechod mezi procesem a jádrem. Jsou implementované jako funkce ve standardní knihovně, které do procesorových registrů vloží informace o daném volání a poté se v registrech objeví návratová hodnota. Při zavolání syscallu se pak přepne kontext procesoru a skočí se z procesu do jádra a zpět.
Každý syscall má také své číslo, které jej jednoznačně identifikuje.
Syscally v průběhu času přibývají a jejich počet závisí na použité architektuře. Když sečteme 32bitové a 64bitové, najdeme jich v současném jádře více než čtyři stovky. Historicky měla řada syscallů chyby, které nikdo neopravoval, ale byly uvedeny v manuálové stránce.
Například sync má za úkol uložit data na disk, ale v některých verzích jádra se volání vrátí dříve, než je zápis dokončen.
Některé syscally se v průběhu času proměňují a vznikají jejich nové varianty. Například v roce 2006 bylo umožněno referencovat adresář nejen jeho cestou, ale také jeho deskriptorem, což je perzistentní ukazatel, který se v průběhu práce nezmění.
V roce 2009 došlo k přejmenování syscallu, což není problém, protože jeho číslo zůstalo stejné. Staré zkompilované programy v sobě mají původní číslo, takže fungují dál.
Nově kompilované programy použijí nové jméno, které se přeloží na stejné číslo a fungují také. Přejmenování syscallu tedy vůbec nepředstavuje žádný problém.
Existuji i syscally, které byly odebrány. Obvykle proto, že nepřešly z 32bitového režimu do 64bitového. Které syscally máme zrovna k dispozici můžeme zjistit v dokumentaci, zdrojovém kódu jádra nebo v sysfs. Některé z nich jsou opravdu ošklivé a umožňují útoky postranním kanálem, ale historicky byly zavedeny a musejí být podporovány.
Jan Tomášek: Kubernetes pro dinosaury
Sdílení výpočetních prostředků prošlo v průběhu let zásadním vývojem. Nejprve jsme provozovali všechen software přímo na hardwaru, poté přišla klasická plnohodnotná virtualizace. Dříve to bylo velmi pomalé a připomínalo to spíše demo. Později to ale naštěstí dospělo.
Poté přišla doba kontejnerizace celých operačních systémů, která se vyvinula v kontejnerizaci jednotlivých aplikací. Nejznámější je Docker, který ale provede v systému spoustu změn. Používám proto raději Podman, který se chová trochu slušněji.
Výhodou kontejnerů je, že se dostanete brzy k aktuální verzi aplikace a jsou oddělena data a program samotný. Kontejner obsahuje jen aplikaci a chybí v něm spousta komponent, které by mohly znamenat bezpečnostní riziko.
Nejrozšířenějším orchestrátorem kontejnerů je Kubernetes, který je možné provozovat u různých cloudových poskytovatelů nebo na vlastním serveru pomocí OpenShift, Rancher nebo K3s. Z pohledu administrátora je potřeba znát základy sítí, Linuxu, kontejnerů a ideálně také YAML. Podle některých je nutné znát také nějaký verzovací systém.
Základní kontejner je vlastně minimální souborový systém s Debianem, který se vytvoří pomocí nástroje debootstrap. Automaticky je možné vše vytvořit pomocí založení takzvaného Dockerfile, který může obsahovat jen tři kroky a vytvoří to základní spustitelný kontejner. Podman je myšlen jako náhrada za Docker, takže většinu věcí používáte stejně, jen používáte jiný příkaz.
Poté je možné obraz doplnit o instalaci nějakého balíčku a tím doplnit nějakou funkci. Pak můžu upravit entry point, tedy příkaz, který je po startu spuštěn.
Poté je možné obraz znovu sestavit a po spuštění začne aplikace fungovat. Perzistenci je nutné ukládat do odděleného úložiště.
Takto není potřeba skládat obraz od úplného začátku, je vhodnější začít už připravenými obrazy, které je možné stáhnout z DockerHubu nebo z repozitáře Bitnami. Ty jsou bohužel postupně omezovány a můžete narazit na limity, po kterých je už potřeba platit.
Pro ovládání Kubernetes je potřeba znát formát YAML, pomocí kterého se definuje nová služba. Obrazy se pak nahrávají do Artefact Registry. Tomu bychom dříve říkali repozitář s balíčky, ale v tomhle světě vznikla spousta nových názvů.
Nasazení pak probíhá pomocí utility kubectl, která komunikuje s API serverem.
Nejmenší spustitelná jednotka je pod, který odpovídá spuštěnému kontejneru a může běžet ve více instancích. Mohou mít různá úložiště, ale sdílejí síťový jmenný prostor, takže spolu takto mohou komunikovat.
Jedním z typů objektů je Secret, který slouží k uložení citlivých informací. Pro uložení dat je možné si od clusteru objednat persistentní úložiště, které může být nezávislé na podech a umí využívat různé typy úložišť.
Jednou ze služeb clusteru je také Ingress, který se stará o zpracování požadavků zvenčí. Může být implementován různým způsobem, například pomocí webového serveru Nginx. Ten se může starat také o TLS a zajistit šifrování komunikace.
Má také nastaveno, co má dělat s daným typem dotazu a kdo se postará o zpracování.
Každý kontejner má svůj standardní výstup, do kterého se vypisují záznamy určené do logu. Logy jsou spojené s podem a když je pod ukončen, zmizí i logy.
Proto je potřeba použít nějakého logovacího agenta jako Filebeat a Logstash, které sbírají logy a odesílají je do centrálního úložiště.
Jakub Onderka: Postkvantová kryptografie prakticky: rok poté
Už v současné době existují kvantové počítače, ale zatím mají nejvýše 200 qubitů. Zatím to jsou spíš kalkulačky, takové experimenty, na kterých se zkoumá, co se s tím dá udělat.
Dostatečný výkon pro louskání klasických kryptografických algoritmů přinesou až kvantové počítače obsahující asi 4000 qubitů.
Kdy tedy budeme takto výkonné kvantové počítače mít? Pravděpodobně takový počítač jednou k dispozici bude. Někdo tvrdí, že už existuje, ale je to vysoce nepravděpodobné.
Experti odhadují, že s poloviční pravděpodobností to nastane už v roce 2031. U umělé inteligence jsme viděli naprosto skokový nárůst, podobná věc se může stát i u kvantového počítače.
Současné symetrické šifry jako AES nebo ChaCha20 by měly zůstat stále bezpečné, možná bude potřeba navýšit délku klíčů na 256 bitů. To je něco, co už se teď běžně používá, takže to vůbec není problém.
Horší je to u asymetrických algoritmů, které bude potřeba vyměnit. Kvantově zranitelné jsou všechny běžně používané algoritmy jako DSA, RSA, ECDSA a podobně.
Nejčastěji se používají v protokolu TLS, kde hrají zásadní roli při ověření identity serveru a dohodě o šifrovacím klíči, poté už probíhá šifrování obsahu pomocí symetrických šifer. Nejvíc nás to trápí u ověřování identity, tam budeme muset udělat změnu co nejdříve.
Současný problém tkví v tom, že už nyní může někdo zaznamenávat zašifrovaná data a čeká, až bude dostatečně výkonný kvantový počítač k dispozici. Poté bude moci celou komunikaci rozšifrovat a přečíst si ji, jako by nikdy žádné šifrování použito nebylo.
Některé takto získané informace mohou být relevantní i po desítkách let.
Proto už kryptologové přišli s tím, že potřebují nový algoritmus, který nebude možné ani později pomocí kvantového počítače rozlousknout. Americká standardizační organizace NIST proto vyhlásila soutěž o tento nový algoritmus a z ní vyšel ML-KEM. Kryptologové zatím ještě nemají k takto novému algoritmu důvěru, proto se zatím implementují hybridní varianty.
Takto se zkombinuje X25519 a MLKEM768 do X25519MLKEM768. Značí to delší klíče a vyšší výpočetní náročnost, ale není to tak zásadní, aby to běžný uživatel zaznamenal. Společnost Google uvádí, že se latence zvýší asi o čtyři procenta.
V současné době nový algoritmus podporují všechny důležité prohlížeče: Chrome od verze 131, Firefox od verze 132 a Safari od macOS nebo iOS verze 26.
Podpora v knihovnách je implementována v knihovně BoringSSL, pro OpenSSL řady 3 je k dispozici rozšíření oqsprovider a v Go je k dispozici ve verzi 1.24. Vyšlo také OpenSSL 3.5, která už přidala podporu postkvantových kryptografických algoritmů.
U operačních systémů je podpora v Debianu Trixie nebo v Alpine Linuxu. Red Hat začíná podporu také zavádět, ale je potřeba ji manuálně zapnout. Windows 11 by měl nové algoritmy implementovat v průběhu letošního roku.
Ze 100 tisíc nejnavštěvovanějších domén už 28 % nové algoritmy používá, ale drtivá většina z nich díky Cloudflare. Takhle to ale vypadá z internetu, ale už nevíme, jaké algoritmy se používají pro spojení mezi Cloudflarem a původním webovým serverem.
Neoficiální informace z Cloudflare tvrdí, že je zastoupení okolo jednoho procenta.
Z hlediska obsahu provozu je situace velmi pozitivní, klienti se rychle aktualizují a čím dál častěji algoritmy používají. Zatímco před rokem se poměr provozu s postkvantovými algoritmy pohyboval okolo deseti procent, dnes jsme už zhruba u padesáti. Nástup je velmi rychlý, rychlejší, než jsem si myslel.
Na veřejném Portále NÚKIB se už poměr přes padesát procent přehoupl, v interním portálu přesáhl 91 %. Tam už by bylo možné jiné algoritmy zakázat a donutit tak uživatele přejít na aktuální klienty.
V případě protokolu SSH také dochází k vývoji, OpenSSH od verze 9.9 ze září 2024 také používá pro dohodu na klíči stejný algoritmus. Od OpenSSH 10.1 se budeme setkávat s novou hláškou, která znamená, že server nepodporuje postkvantovou kryptografii.
To má informovat uživatele a podpořit ho v aktualizaci. Servery GitHub i GitLab už podporu nových algoritmů zavedly.
Podporu algoritmů umí zjistit nástroj ssh-audit, který se umí připojit na SSH server a následně vypsat informace o stavu jednotlivých algoritmů a případně doplnit i podrobnosti o doporučovaných opatřeních.
Evropská unie představila svůj plán, jak by měly jednotlivé státy podporovat a provádět přechod na nové algoritmy. Do konce roku 2026 by měly mít stát připravený plán zavádění a měly by začít s pilotními projekty. Pro vysoce rizikové případy by mělo být zavedeno do roku 2030.
Dokončení migrace by mělo proběhnout do konce roku 2035.
Rok 2025 je rokem zavádění podpory pro postkvantovou dohodu nad klíči. Je možné, že zavedení bude povinné pro systémy regulované dle zákona o kybernetické bezpečností.
Ale je velmi pravděpodobné, že prohlížeče zavedou podporu mnohem dřív. Typicky jsou prohlížeče místem, kde se vynucují nové algoritmy a ruší se ty staré.
Pokud se prohlížeče rozhodnou, budou muset správci jednat, jinak přijdou o uživatele.
Měli bychom se začít připravovat co nejdříve. Čím déle budete čekat, tím bude složitější a dražší.
Ještě zbývá podpora u certifikátů, která zatím není vůbec dořešena. Není to tak jednoduché jako vyměnit algoritmus v TLS, zatím se vymýšlí rozumná cesta.
Je možné, že vznikne nějaké hybridní prostředí, které bude využívat více různých algoritmů.
NÚKIB se snaží postkvantovou kryptografii podporovat a vydal k tomu dokumenty, které detailně popisují požadavky na nové algoritmy a jejich praktické nasazení. Snažíme se říkat, jak vypadají rizika a jaké útoky nám hrozí.
Česko se může stát leaderem v této oblasti, kromě NÚKIB se na podpoře podílí také VUT a máme tu hodně firem, které se tomu věnují: OpenSSL Corporation, Red Hat, Wiltra nebo Monet Plus.
Vojtěch Pavlík: Vliv planetární plasticity na závody koní
Měření času je problém, který lidstvo trápí od nepaměti. Většinou řešíme dvě rozdílné věci: absolutní čas a relativní čas. Tedy jaká část dne právě je a jak dlouho něco trvá.
Poprvé se slušně změřil čas zvaný pasážník, což je dalekohled, který se pohybuje v jedné ose. Astronom je pak schopen sledovat konkrétní hvězdy a zaznamenat čas jejich průchodu určitým bodem na obloze. Podle toho je možné seřizovat fyzické hodiny.
Původně se používaly kyvadlové hodiny, přičemž nejpřesnější je takzvaný Shorttův synchronom. Ten je umístěn do válce, ve kterém je vyčerpaný vzduch. Největší problém kyvadlových hodin je totiž v tom, že se kyvadlo pohybuje v proměnlivé atmosféře.
Postupně se takto vylepšovaly hodiny i sledování hvězd, ale pořád to ještě nebylo ideální.
Kyvadlové hodiny nemohou být dokonale přesné, protože doba kyvu závisí na délce kyvadla a gravitačním zrychlení. To se ale v čase mění, protože kolem Země obíhá Měsíc.
Nejsme naštěstí závislí jen na kyvadlových hodinách, ale můžeme použít atomové hodiny. Těmi se dosáhlo řádového zpřesnění měření času, což způsobilo potíže.
Už přesně víme, jak dlouhá je sekunda a kolik jich má být v jednom dni. Jen se ukazuje, že Země nespolupracuje.
Rozdíl není zanedbatelný, jde o milisekundy každý den.
Nejdůležitějším důvodem jsou slapové síly, které deformují planetu. Deformace samotné planety i jejich moří způsobují průběžné zpomalení rotace Země a zrychlení oběhu Měsíce.
Díky tomuto jevu se jednou stane to, že se Měsíc dostane na vysokou orbitu a poté ulétne do vesmíru. Na to je ale ještě čas.
Naopak postglaciální isostatická elevace rotaci Země zrychluje, díky zachování momentu hybnosti při změně momentu setrvačnosti. Země se postupně roztahuje na pólech a smršťuje na rovníku.
Tyto dva jevy jdou proti sobě, vzájemně se ovlivňují a není možné to rozumně předpovědět.
V roce 1972 bylo zjištěno, že se hodiny rozcházejí se skutečným časem už o deset sekund. Jako řešení byla zavedena přestupná sekunda, která se přidává přesně o půlnoci buď 1. ledna nebo 1. července. Když ITU vyhlásí přestupnou sekundu, musí se o tom všichni dozvědět. Na rozdíl od přestupných dnů to nelze předpovědět předem.
Komise se musí dohodnout, že je čas přestupnou sekundu přidat.
Informace o tom je součástí protokolu NTP, aby se zpráva rozšířila dostatečně předem a všichni mohli ve správnou chvíli zareagovat. V roce 2008 v tom byl chaos a rozsynchronizoval se celý internet. V roce 2012 to bylo o hodně lepší, ale pořád to nebylo stoprocentní.
V roce 2015 už se situace hodně zlepšila a většina internetu už přestupnou sekundu zvládla zavést správně.
Na platformě x86 se pro časovače původně používal čip PIT, konkrétně Intel 8253, který běžel na 1,19 MHz – odvozené od snímkovací frekvence používané v americkém standardu NTSC. Jeho největší nevýhodou je, že počítá do nějakého maxima a poté se vyresetuje.
Proto Linux původně nastavil frekvenci PIT na konstantní frekvenci 100, 250 nebo 1000 Hz. Veškeré softwarové časovače se spouštěly jen v těchto intervalech, když přišlo přerušení od PIT.
PIT se stal ale časem zastaralým a nepraktickým a postupně se objevily další časovače: PM Timer, TSC, LAPIC a nakonec HPET. Ten běží typicky na 14,3 MHz, je konečně 64bitový a má konečně několik komparátorů a přerušení.
Bylo proto přepsáno celé časování v linuxovém jádře a vznikl subsystém HRTIMER, který umožňoval dynamicky plánovat akce jádra. Tenhle systém ale nebyl napojený na přesné měření času.
Linuxové jádro mělo v roce 2012 jednu malou chybu ve zpracování přestupné sekundy.
Při příchodu přestupné sekundy se pak sice čas jádra správně posunul, ale zapomnělo se právě na HRTIMER. Od tohoto okamžiku byly o sekundu od sebe.
Přidání sekundy způsobilo, že všechny časovače se zkrátily o tuto sekundu. Spoustu programů má ovšem naplánované akce v řádu milisekund a ty se zkrátily na nulu.
Spousta byznysových aplikací napsaných v Javě má až desítky tisíc vláken. Centrální smyčka pak čeká na událost nebo timeout, který je ovšem po změně kratší než jedna sekunda.
Při chybě s přestupnou sekundou najednou všechna vlákna začnou bojovat o procesor. Systém pak nedělá nic užitečného až do rebootu.
To shodí mnoho systémů na světě a je to potenciálně horší než známý problém Y2K.
Například systémy společnosti Amadeus zpracovávají přes 50 % všech leteckých odbavení na světě. Jejich systémy jsou napsané v Javě a Cobolu. V Austrálii se půl hodiny nedaly odbavit žádné lety.
Servery se ale podařilo během půl hodiny restartovat a vše začalo fungovat.
Hong Kong Jockey Club je jedna z nejbohatších společností v Hong Kongu. Přímo v centru města má závodiště v hodnotě miliard dolarů.
Potíž je, že hlavní závod sezóny probíhá 1. července v osm hodin ráno a Hong Kong je v časové zóně UTC+8. Naštěstí je to bohatá společnost, která má hodně předimenzované servery, které to zvládly.
Chyba postihla mnoho dalších společností, nejznámější je asi Reddit. Dopad byl větší než známý Y2K.
Oprava spočívala v doplnění dvou řádků do jádra. Byl to problém všech linuxových distribucí na celém světě, ale už se naštěstí nikdy neopakoval.
Podobné problémy se objevují pořád, řada softwarů neřeší přestupnou sekundu správně. Různé družicové navigační systémy například vycházejí z různých měření času a hodiny se mezi nimi rozcházejí o desítky sekund. Je potřeba to složitě přepočítávat a dělají se v tom chyby.
Mnoho systémů přešlo na postupné roztažení sekundy na mnoho hodin během dne. Každý to ale dělá jinak. V roce 2022 bylo rozhodnuto, že přestupná sekunda bude v roce 2035 zrušena. Hodiny se budou rozcházet, ale nám to už nebude vadit.
Tomáš Tichý: Programujeme autobus
Ve vozech MHD je dnes celý informační systém, který zahrnuje označovače jízdenek, různé typy displejů, palubní počítač a třeba i hlásiče. Vše je propojeno sběrnicí IBIS, pro jejíž ovládání existují volně stažitelné utility. Těmi je možné nastavovat všechny informace na displejích včetně zobrazeného času nebo tarifního pásma.
Při použití vhodných utilit je možné připravit vlastní obsah na displejích. Ten se skládá z jednotlivých znaků, které jsou ale také editovatelné. Například dlouhý obrázek autobusu je složen z několika „znaků“, které obsahují vždy kus celého výsledného obrázku. Během celého víkendu stál před budovou Tomášův autobus, na kterém svítil nápis LinuxDays.
(Autory obrázků jsou Petr Krčmář a Gabriel Seidl.)
