Eida.cz - S Kapitánem u kormidla

S Kapitánem u kormidla

26. června 2016, 18:06 Eida

V Apple se dě­jí hroz­né vě­ci. Ob­čas se nenápadně kousnu do sli­nivky a ptám se, ko­likrát se Steve mu­sí ob­ra­cet v hro­bě z to­ho, co všechno just not works. A vyb­li­tá nos­talgie a ne­mocná sen­ti­men­ta­li­ta, co mi hra­jí v hlavě ja­ko v lé­tě 2008, mi asi už nik­dy ne­dovo­lí změnit název z Mac OS X na coko­liv ji­ného. Je to stav mys­li a sto­jí za něj bo­jovat až do hořkého kon­ce; sto­jí za to bo­jovat za bo­je­schopný sys­tém, ja­ko to­mu bylo dřív na G4.

Ko­lem El Capi­tanu panuje spous­tu po­mluv, lží, po­lopravd, po­chyb a chyb. Asi ja­ko do větši­ny záh­ad na té­to plane­tě je nasna­dě poku­sit se vložit do to­ho tro­chu myšl­enku a když už se ně­co pokazí, vž­d­ycky je způ­s­o­bu, kte­rý všechno po­staví do la­tě. Teď je to asi o ta­kový půlrok dál od prvního poku­su o je­ho kro­cení a nutno zpětně pozna­menat, že spous­tu je­ho novi­nek má svá opod­statnění, mi­ni­málně ale­spoň pro BFU. Pro­ble­ma­tika výs­tav­by OS vž­d­ycky totiž vi­sí a hlavně pa­dá pře­devším na je­ho kon­covém uživa­te­li. Ja­kýko­liv sys­tém je shodnou měr­ou zni­či­telný a na­padnu­telný, pokud dá­me lai­kovi su­pe­r­uživa­tel­ská práva. Ostatně kaž­dý ta­kový ve svém pro­hlíže­či na­ko­nec odklepne va­rování o chybném cer­tifiká­tu, po­tvr­dí UAC di­alog ve Win­dows a bez ja­kýchko­liv okol­ků vy­plní hes­lo, když si o něj něj­a­ké okno v OS X ne­bo vy­leš­těném Gno­me řekne. To byl ta­ky teď ne­dávno případ ja­kého­si červu na Ai­ru paní A, co silně stylem svého šíř­ení připo­mínal mul­tiplatformní va­ri­a­ce Len­či­na loňského lé­ta, ako­rát s konkrét­ním míř­ením na OS X. Po­tvo­ra se zkrátka něj­ak do po­čít­a­če po­prvé na­táh­la, vy­tvo­ři­la si z vestavěného crack­lib slovníku vlast­ní kopii a od­po­ví­da­jí­cí uživa­tel­ské úč­ty se skry­tý­mi uid 4xx spo­lu se spouš­tě­c­í­mi po­pi­sova­či pro laun­chd a následně si z BSD pac­ketfil­te­ru vy­ro­bi­la ja­ký­si re­di­rek­tor. Od­stranit ně­co ta­kového z We­e­du bylo ne­o­by­čejně ob­tížné, a tak zůstává v to­mhle ohle­du po­chvá­lit nápad kapi­tán­ské Sys­tem In­tegri­ty Pro­tec­ti­on platfor­my, kte­rá kro­mě znesnad­ňování in­stala­ce vlast­ního soft­wa­re po­sky­tuje ochranu právě před ta­kový­mi­to poku­sy a ro­otki­ty.

Ale to po­řád není ta zás­adní věc. Sa­mozřejmě ale hle­dání a sestře­lování po­tvor a příše­rek dává možnost po­drobně­ji prozkou­mat nuan­ce mezi jednot­livý­mi verze­mi OS X, takže něk­de ta­dy by bylo na mís­tě při­jít na onu zás­adní myšl­enku. Vzpo­mínám si na pře­c­hod Mac­Bo­oku na We­ed, následně i na Kapi­tá­na. Ne­by­la to žád­ná sláva - kaž­dá první verze je i po mo­hutných be­tách zás­adně nesta­bilní a navíc se mo­hou ob­jevit ješ­tě další, těžko po­chopi­telné nešva­ry. Jedním ta­kovým evergre­enem je náh­lé ne­smy­slné vy­těž­ování CPU a přeh­řívání stro­je vláknem jád­ra. Při go­oglení exis­tuje zhru­ba go­ri­li­on výsled­ků na té­ma kernel_task CPU apod., vž­d­ycky s po­divnou disku­sí a ješ­tě po­divnějším ro­zuz­lením (pokud vůb­ec něj­a­ké je). V kost­ce jde o to, že sys­tém po ur­či­té, zdán­livě náh­odné ak­ci, začne chr­lit ve svém ja­derném vlákně něj­a­ké ne­smys­ly a se­be­re větši­nu ča­su buď jedno­ho, ne­bo všech pro­ce­so­rových jedno­tek. Li­di pak straš­l­ivě bre­čí, že jim to na­plno oca­sí do ob­li­če­je a ne­dá se to pou­žívat. Na­ivní ře­šení, kte­ré je ta­ky popsané naš­těs­tí v uvo­zov­kách, za­hrnuje smazání konkrét­ního řízení ACPI pro daný po­čít­ač.

Ro­ze­ber­me si to. Vlákno jád­ra (pid 0) sa­mozřejmě není žád­ný běžný pro­ces, zpra­covává veške­rou har­d­wa­rovou ko­munika­ci a při­děl­ování ča­su, takže se ne­dá mlu­vit o tom, že by bylo ně­co vy­loženě v ne­po­řád­ku. Tyhle mik­ro a hyb­ri­do-kerne­ly jsou zkrátka navržené tak, aby vše za­jišť­ovaly správně a byly de fac­to ne­dotknu­telné pá­dy špatně na­psaných pro­gra­mů vyšš­ích vrs­tev. ACPI je zjedno­du­šeně platfor­ma pro prá­ci se sa­motným har­d­wa­rem a je­ho stavem a zdravím, včetně řízení otá­ček ven­ti­lá­to­rů, blikání ně­če­ho, ko­munika­ce s na­páj­ením a vše­mi ostat­ní­mi část­mi. V rám­ci think diffe­rent přístu­pu, a to vy­loženě čis­tě NeXT­s­te­po­vého přístu­pu, vy­mys­le­li čiperní­ci me­chanis­mus pro vy­lepšení řízení přeh­řívání ta­kovým způ­s­o­bem, že když něj­a­ký pro­ces ne­bo špička začne pře­t­ěž­ovat ce­lý po­čít­ač a už to začne vy­pa­dat ja­ko ne­uchla­di­telné, ja­ká­si prázdná vo­lání v rám­ci jád­ra od­sa­jí nad­by­tečný výkon pro­ce­so­ru, takže cel­ková teplo­ta kles­ne za cenu mír­ného zpo­malení prá­ce. No a výše zmíněný po­stup smazání sou­bo­ru s po­pi­sem to­ho­to chování sa­mozřejmě vy­řa­dí ce­lý ten­to pro­ces, takže po smazání kex­tové mezipamě­ti celkem lo­gicky vy­le­tí ven­ti­lá­to­ry per­manentně na plné otáčky a k žád­né­mu low-level soft­wa­rové­mu od­sávání už ne­bu­de do­cházet.

Až do včil to ce­lé zní lo­gicky. Otázk­ou je, proč vlastně do­chází u něk­te­rých po­čít­a­čů k to­mu­to od­sávání vlastně ne­pře­t­rži­tě, po zdán­livě náh­odných ak­cích. Jenže ony nej­sou tak úplně náh­odné, ukazuje se totiž, že se vž­dy jedná o souběžnou de­tek­ci změ­ny stavu har­d­wa­ru po ne­bo při něj­a­ké ak­ci, kte­rá si vy­žá­d­a­la zvýšený výkon - na­příklad vy­kres­lování webki­tem, pře­hrávání a ukon­čování pře­hrávání vi­dea a vůb­ec coko­liv, co vy­ža­d­uje ví­ce energie. Po kaž­dé ta­kové­to ak­ci je tes­tová­na a de­te­ková­na změ­na, což zna­mená, že do­chází k ja­derné­mu vo­lání a jednot­livé mo­duly mu­sí od­po­vě­dět v při­děl­eném ča­se. Ne­přít­ulná si­tua­ce ovšem nastane ve chví­li, kdy v tom ča­se zkrátka ne­od­po­ví. Pak se to­ho vo­lání pro­ve­de znovu. A znovu. A znovu a klidně i de­se­ti­ti­síckrát za se­kun­du.  Ovšem pro­blém to dokázat na konkrét­ním mo­dulu? ASLR. Zvlášt­ní je, co všechno ma­jí po in­terne­tu ko­lu­jí­cí přípa­dy spo­lečné - jedná se o po­čít­a­če, co pou­žíva­jí o ví­ce jak něko­lik verzí upgra­dovaný OS X. Ta­kové za­myšl­ení… když mi Mac­Bo­ok Pro 15” mid-2010 při­šel s 10.6 Snow Le­opar­dem, co v té do­bě fr­če­lo a dneska už ne? Grafické ovla­da­če pracu­jí­cí s přep­ínáním in­tegrované a de­di­kované nVi­die.

Ak­tua­liza­ce ovla­da­čů je ně­co, čím se uživa­te­lé Ma­ců běžně ni­jak ne­zabýva­jí, ne­boť se všechno, a to včetně upgra­dů fir­m­wa­re a EFI, děje skry­tě ne­bo otevřeně sys­té­m­ovým dé­m­o­nem ak­tua­liza­cí, kte­rý je dnes schovaný pod AppS­to­re. Průšvih je, že jak­mi­le se ně­co osvěd­čí a sta­bi­lizuje, už se nep­lýtvá ča­sem na další vývoj, vž­d­ycky do­stanou přednost nové techno­logie. Navíc není úplně jasné, kde by nor­mální člověk na­šel “ovla­dač” na svo­ji grafickou kar­tu v Macu. Na ofi­ci­álním we­bu nVi­dia se to děje ši­bal­sky, komplet­ní ba­lík všech ovla­da­čů je ozna­čen ja­ko Quadro & GeFor­ce Mac OS X Driver Re­le­a­se XXX.YY.ZZ a bývá pro od­po­ví­da­jí­cí verzi OS X k dispo­zi­ci jen ja­ko po­de­psaná be­ta. Po je­jí in­stala­ci v sys­té­mu zůstane pův­odní ovla­dač od Apple a ak­tivovaný bu­de ten­to nový, včetně možnos­ti au­to­ma­tických ak­tua­liza­cí. V ovlá­d­a­cím pane­lu by mě­la být bez pro­blé­mu rozpozná­na ja­káko­liv grafická kar­ta nVi­da vy­daná v in­te­lových Ma­cích za ce­lou do­bu. V tuhle chví­li to bu­de asi ví­ce než tý­d­en od in­tenzivního tes­tování a za­tím ne­došlo k žád­ným dříve po­zo­rovaným po­tížím při přep­ínání GPU ne­bo špič­k­ového zvy­šování a sni­žování výko­nu. Na tom­to mís­tě by se ješ­tě ho­di­lo do­dat, že no­tifika­ce o ak­tua­liza­cích jsou zob­razová­ny v be­ze­lovém roz­hraní. Na tom by asi ne­bylo nic po­divného, kdy­by ovšem onen be­zel ne­byl za­blu­rovaný! Další věc k za­myšl­ení, tře­ba by bylo možné vypnout to ne­smy­slné a dost zlo­my­slné blu­rování ce­lo­sys­té­m­ově.

Není to ovšem všechno. Po­stupné­mu od­halení všech těch­to záh­ad před­cháze­la ješ­tě série ne­ko­nečných pá­dů a selhání. Ono jde o to, že skál­opevný UNIX nik­dy ne­může selhat jenom tak sám od se­be. Ale všech­ny UNI­Xové a zvlášť mik­rokerne­lové sys­témy jsou ne­o­by­čejně ná­chylné na chy­by v RAM, to čas­to kvů­li chybným ne­bo ne­čis­tým paměť­ovým mo­du­lům pa­da­jí ja­blka ja­ko hrušky. Za běhu není možné ja­kou­ko­liv mi­ni­a­turní chybu úplně přesně od­ha­lit, navíc Mac­Bo­oky nik­dy ne­měly ECC. Off­li­ne od­halení spo­čívá ve fyzickém pro­čiš­tění jednot­livých pi­nů na mo­dulech a následném dost důsledném otes­tování. K to­mu lze, ne­bo spíše je nutné, pou­žít mem­test, ide­álně s EFI bo­o­tem a pak se mod­lit. Ukázalo se, že po něj­a­ké do­bě v jednom 4GB mo­dulu Pa­tri­ot odeš­la druhá nej­vyšší ad­re­sa. Tragé­d­ie.

Na­hra­dit DDR3 SO­DI­MM pamě­ti by bylo zby­tečně složi­té a zby­tečně nákladné, ne­být od­ložených Cor­sair mo­du­lů z Mi­ni, kte­rý ješ­tě celkem ne­dávno do­stal upgra­de. Sa­mozřej­me Mi­ni 2011 pou­žívá 1333MHz DDR3, za­tím­co MBP 2010 si je­de na 1066 MHz. A pak je tu otáz­ka, co přesně zna­mená u výr­ob­ce ne­bo ob­chodníka ozna­čení, že jsou mo­de­ly ur­čené pro Mac. Vzhle­dem k to­mu, že nik­de nej­sou k dispo­zi­ci de­tailní výkre­sy de­sek, lze se jen domnívat, že to má spíš než s ča­sováním co děl­at s JE­DEC stan­dar­dem pro na­páj­ení mo­du­lů, resp. roz­díl­em mezi použi­tím 1.5 a 1.35 V. Spíš než o energe­tickou nár­očnost by moh­lo jít o něj­a­ké opotře­bení, čímž by se dalo vy­svět­l­it poško­zení Pa­tri­o­tů ješ­tě v zár­uční do­bě. Kdo ví, asi to zas ukáže jen čas. Na roz­díl­ných frek­ven­cích je za­jí­mavý ješ­tě je­den fakt, a to, že ačk­o­liv 1333MHz mo­duly ne­mo­hou po­chopi­telně pra­covat na 1333 MHz, při 1066 MHz ma­jí téměř o ce­lý gigabajt vyšší pro­pustnost, než 1066MHz Pa­tri­o­ty. Ale co už. Důl­eži­té je, že to všechno funguje - ta­kový ten po­cit za­do­s­tiu­či­nění být znovu s Kapi­tánem u kor­mi­d­la a plout ja­ko za ča­sů k velko­lepým zítřkům a plánům pro taputukan­ské strojnic­tví.

Eida
Tento článek přečetlo již 81 čtenářů (0 dnes).

Komentáře

Nový komentář