V Apple se dějí hrozné věci. Občas se nenápadně kousnu do slinivky a ptám se, kolikrát se Steve musí obracet v hrobě z toho, co všechno just not works. A vyblitá nostalgie a nemocná sentimentalita, co mi hrají v hlavě jako v létě 2008, mi asi už nikdy nedovolí změnit název z Mac OS X na cokoliv jiného. Je to stav mysli a stojí za něj bojovat až do hořkého konce; stojí za to bojovat za bojeschopný systém, jako tomu bylo dřív na G4.
Kolem El Capitanu panuje spoustu pomluv, lží, polopravd, pochyb a chyb. Asi jako do většiny záhad na této planetě je nasnadě pokusit se vložit do toho trochu myšlenku a když už se něco pokazí, vždycky je způsobu, který všechno postaví do latě. Teď je to asi o takový půlrok dál od prvního pokusu o jeho krocení a nutno zpětně poznamenat, že spoustu jeho novinek má svá opodstatnění, minimálně alespoň pro BFU. Problematika výstavby OS vždycky totiž visí a hlavně padá především na jeho koncovém uživateli. Jakýkoliv systém je shodnou měrou zničitelný a napadnutelný, pokud dáme laikovi superuživatelská práva. Ostatně každý takový ve svém prohlížeči nakonec odklepne varování o chybném certifikátu, potvrdí UAC dialog ve Windows a bez jakýchkoliv okolků vyplní heslo, když si o něj nějaké okno v OS X nebo vyleštěném Gnome řekne. To byl taky teď nedávno případ jakéhosi červu na Airu paní A, co silně stylem svého šíření připomínal multiplatformní variace Lenčina loňského léta, akorát s konkrétním mířením na OS X. Potvora se zkrátka nějak do počítače poprvé natáhla, vytvořila si z vestavěného cracklib slovníku vlastní kopii a odpovídající uživatelské účty se skrytými uid 4xx spolu se spouštěcími popisovači pro launchd a následně si z BSD packetfilteru vyrobila jakýsi redirektor. Odstranit něco takového z Weedu bylo neobyčejně obtížné, a tak zůstává v tomhle ohledu pochválit nápad kapitánské System Integrity Protection platformy, která kromě znesnadňování instalace vlastního software poskytuje ochranu právě před takovýmito pokusy a rootkity.
Ale to pořád není ta zásadní věc. Samozřejmě ale hledání a sestřelování potvor a příšerek dává možnost podrobněji prozkoumat nuance mezi jednotlivými verzemi OS X, takže někde tady by bylo na místě přijít na onu zásadní myšlenku. Vzpomínám si na přechod MacBooku na Weed, následně i na Kapitána. Nebyla to žádná sláva - každá první verze je i po mohutných betách zásadně nestabilní a navíc se mohou objevit ještě další, těžko pochopitelné nešvary. Jedním takovým evergreenem je náhlé nesmyslné vytěžování CPU a přehřívání stroje vláknem jádra. Při googlení existuje zhruba gorilion výsledků na téma kernel_task CPU apod., vždycky s podivnou diskusí a ještě podivnějším rozuzlením (pokud vůbec nějaké je). V kostce jde o to, že systém po určité, zdánlivě náhodné akci, začne chrlit ve svém jaderném vlákně nějaké nesmysly a sebere většinu času buď jednoho, nebo všech procesorových jednotek. Lidi pak strašlivě brečí, že jim to naplno ocasí do obličeje a nedá se to používat. Naivní řešení, které je taky popsané naštěstí v uvozovkách, zahrnuje smazání konkrétního řízení ACPI pro daný počítač.
Rozeberme si to. Vlákno jádra (pid 0) samozřejmě není žádný běžný proces, zpracovává veškerou hardwarovou komunikaci a přidělování času, takže se nedá mluvit o tom, že by bylo něco vyloženě v nepořádku. Tyhle mikro a hybrido-kernely jsou zkrátka navržené tak, aby vše zajišťovaly správně a byly de facto nedotknutelné pády špatně napsaných programů vyšších vrstev. ACPI je zjednodušeně platforma pro práci se samotným hardwarem a jeho stavem a zdravím, včetně řízení otáček ventilátorů, blikání něčeho, komunikace s napájením a všemi ostatními částmi. V rámci think different přístupu, a to vyloženě čistě NeXTstepového přístupu, vymysleli čiperníci mechanismus pro vylepšení řízení přehřívání takovým způsobem, že když nějaký proces nebo špička začne přetěžovat celý počítač a už to začne vypadat jako neuchladitelné, jakási prázdná volání v rámci jádra odsají nadbytečný výkon procesoru, takže celková teplota klesne za cenu mírného zpomalení práce. No a výše zmíněný postup smazání souboru s popisem tohoto chování samozřejmě vyřadí celý tento proces, takže po smazání kextové mezipaměti celkem logicky vyletí ventilátory permanentně na plné otáčky a k žádnému low-level softwarovému odsávání už nebude docházet.
Až do včil to celé zní logicky. Otázkou je, proč vlastně dochází u některých počítačů k tomuto odsávání vlastně nepřetržitě, po zdánlivě náhodných akcích. Jenže ony nejsou tak úplně náhodné, ukazuje se totiž, že se vždy jedná o souběžnou detekci změny stavu hardwaru po nebo při nějaké akci, která si vyžádala zvýšený výkon - například vykreslování webkitem, přehrávání a ukončování přehrávání videa a vůbec cokoliv, co vyžaduje více energie. Po každé takovéto akci je testována a detekována změna, což znamená, že dochází k jadernému volání a jednotlivé moduly musí odpovědět v přiděleném čase. Nepřítulná situace ovšem nastane ve chvíli, kdy v tom čase zkrátka neodpoví. Pak se toho volání provede znovu. A znovu. A znovu a klidně i desetitisíckrát za sekundu. Ovšem problém to dokázat na konkrétním modulu? ASLR. Zvláštní je, co všechno mají po internetu kolující případy společné - jedná se o počítače, co používají o více jak několik verzí upgradovaný OS X. Takové zamyšlení… když mi MacBook Pro 15” mid-2010 přišel s 10.6 Snow Leopardem, co v té době frčelo a dneska už ne? Grafické ovladače pracující s přepínáním integrované a dedikované nVidie.
Aktualizace ovladačů je něco, čím se uživatelé Maců běžně nijak nezabývají, neboť se všechno, a to včetně upgradů firmware a EFI, děje skrytě nebo otevřeně systémovým démonem aktualizací, který je dnes schovaný pod AppStore. Průšvih je, že jakmile se něco osvědčí a stabilizuje, už se neplýtvá časem na další vývoj, vždycky dostanou přednost nové technologie. Navíc není úplně jasné, kde by normální člověk našel “ovladač” na svoji grafickou kartu v Macu. Na oficiálním webu nVidia se to děje šibalsky, kompletní balík všech ovladačů je označen jako Quadro & GeForce Mac OS X Driver Release XXX.YY.ZZ a bývá pro odpovídající verzi OS X k dispozici jen jako podepsaná beta. Po její instalaci v systému zůstane původní ovladač od Apple a aktivovaný bude tento nový, včetně možnosti automatických aktualizací. V ovládacím panelu by měla být bez problému rozpoznána jakákoliv grafická karta nVida vydaná v intelových Macích za celou dobu. V tuhle chvíli to bude asi více než týden od intenzivního testování a zatím nedošlo k žádným dříve pozorovaným potížím při přepínání GPU nebo špičkového zvyšování a snižování výkonu. Na tomto místě by se ještě hodilo dodat, že notifikace o aktualizacích jsou zobrazovány v bezelovém rozhraní. Na tom by asi nebylo nic podivného, kdyby ovšem onen bezel nebyl zablurovaný! Další věc k zamyšlení, třeba by bylo možné vypnout to nesmyslné a dost zlomyslné blurování celosystémově.
Není to ovšem všechno. Postupnému odhalení všech těchto záhad předcházela ještě série nekonečných pádů a selhání. Ono jde o to, že skálopevný UNIX nikdy nemůže selhat jenom tak sám od sebe. Ale všechny UNIXové a zvlášť mikrokernelové systémy jsou neobyčejně náchylné na chyby v RAM, to často kvůli chybným nebo nečistým paměťovým modulům padají jablka jako hrušky. Za běhu není možné jakoukoliv miniaturní chybu úplně přesně odhalit, navíc MacBooky nikdy neměly ECC. Offline odhalení spočívá ve fyzickém pročištění jednotlivých pinů na modulech a následném dost důsledném otestování. K tomu lze, nebo spíše je nutné, použít memtest, ideálně s EFI bootem a pak se modlit. Ukázalo se, že po nějaké době v jednom 4GB modulu Patriot odešla druhá nejvyšší adresa. Tragédie.
Nahradit DDR3 SODIMM paměti by bylo zbytečně složité a zbytečně nákladné, nebýt odložených Corsair modulů z Mini, který ještě celkem nedávno dostal upgrade. Samozřejme Mini 2011 používá 1333MHz DDR3, zatímco MBP 2010 si jede na 1066 MHz. A pak je tu otázka, co přesně znamená u výrobce nebo obchodníka označení, že jsou modely určené pro Mac. Vzhledem k tomu, že nikde nejsou k dispozici detailní výkresy desek, lze se jen domnívat, že to má spíš než s časováním co dělat s JEDEC standardem pro napájení modulů, resp. rozdílem mezi použitím 1.5 a 1.35 V. Spíš než o energetickou náročnost by mohlo jít o nějaké opotřebení, čímž by se dalo vysvětlit poškození Patriotů ještě v záruční době. Kdo ví, asi to zas ukáže jen čas. Na rozdílných frekvencích je zajímavý ještě jeden fakt, a to, že ačkoliv 1333MHz moduly nemohou pochopitelně pracovat na 1333 MHz, při 1066 MHz mají téměř o celý gigabajt vyšší propustnost, než 1066MHz Patrioty. Ale co už. Důležité je, že to všechno funguje - takový ten pocit zadostiučinění být znovu s Kapitánem u kormidla a plout jako za časů k velkolepým zítřkům a plánům pro taputukanské strojnictví.