Názory k článku
Kdo bude šéfovat Microsoftu? Podívejte se na kandidáty

nestihal jsem sledovat vsechny nazory na prevzeti mobilni divize pod M$, ale me prijde mozna varianta, ze Elop byla jen figurka v dopredu rizene smrti divize mobilu po vzoru Siemnes do Benq, akorat s trochu lepsim PR.

Jaké procento zákazníků by si koupilo Nokii na Androidu, když mohou dostat Android od hromady jiných výrobců? A prodělávala by Nokia stejně jako Motorola vlastněná Googlem, nebo jako HTC a řada dalších výrobců? Jak jsem psal, 95% zisků z telefonů s Androidem shrábne Samsung. Jít na takový trh není žádá sranda.

Myslím si, že nejmíň půlka z těch 65 % trhu, které měla Nokia přes Windows Mobile. Teď má kolik? ;-)

To se pletete. Symbian měl ještě v roce 2006 73% trhu. Jenže v roce 2010 měl už jen 37.6%, a navíc ho společnosti Motorola, Samsung, LG a Sony Ericsson opustily. Před příchodem partnerství Nokia-Microsoft tržní podíl Symbianu padal volným pádem, bez jakékoliv perspektivy zlepšení. Platforma byla technicky zastaralá, fragmentovaná, defaultní browser byl nepoužitelný, N97 byla plná bugů. Vývoj SW v Nokii byl dlouhý, neefektivní a výsledky byly nepřesvědčivé. Nechápu proč si někteří myslí, že Nokia mohla prostě pokračovat v takovém kurzu.

Jistě. Koupili by si (vyberte Nokii, Sony Ericsson, Motorolu, HTC, BlackBerry nebo Apple), protoze by predpokladali, ze dostanou kvalitu, jaka je od tohoto výrobce obvykla.

To jsem ve svém okolí nepozoroval. Nokie tady v okolí byla považována za levný telefon s přijatelnými funkcemi. Za Rols Royce byly považovány Motoroly a Ericsony.

A to je přesně ten důvod, proč mají Windows Phone oproti Androidu tak vysoký satisfaction rate. Kde je malé očekávání, bývá také vysoká spokojenost :-)

Lumii si podle všeho zákazníci kupují nejčastěji proto, že je to za rozumné peníze pěkný telefon s odladěným, snadno ovladatelným a spolehlivým systémem. iPhone má špatný poměr cena/výkon, a Android je většinou slušně implementovaný jen na high-endových strojích, které pravidelně stojí víc než kompletní stolní počítač.

To s tou alergiou na Windows je 100% pravda

Nejhorší je, že začínám mít i alergii na Nokiu :( Poslední dva šmejdy od nich byly sice hardwarově v pohodě, ale firmware těžce nedotestovaný a děr jak v D1 :( A nevěřím, že to widle můžou nějak změnit, protože testování se plánuje v rámci projektu a čas na ně určují manažeři...

Přitom výhodou Windows Phone ve srovnání s Androidem je právě spolehlivost, to že telefon "just works".

Jenže většina lidí si nekupuje smartphone jen proto, aby tam psala SMSky a přijímala hovory. Na všechno ostatní je totiž Windows Phone dost k ničemu.

Fakt? A jak to, že na WP zcela spokojeně používám email a kalendář se synchronizací na MS Exchange, mapy a navigaci, geocaching, hry, automatické překlady (BTW včetně překladu z kamery s použitím OCR), přehrávání multimédií, čtení a úpravu souborů MS Office, připojuji se přes Remote Desktop, hraju hry a dělám řadu dalších věcí? Není to spíš tím, že jste WP neviděl ani z rychlíku?

Ja si myslim, ze je to tym, ze si Microsoftom plateny a tak ti neostava nic ine, nez pisat tieto veci. Kto vie ci naozaj pouzivas WP phone aj vo svojom volnom case. :)

Já jsem u toho psal, že player na WP používám, a tagy mi chodí bez jediného problému.

A to já bych nevyužil.
- Maily v mobilu jsou docela nesmysl. většinou se tam nedá ani pracovat s přílohou. Na to je displej moc malý.
- Souborům Office se vyhybám, jak to jenom jde. Nejenom, že na to neexistuje standard, ale ono je to nekompatibilní i mezi jednotlivýma verzema. Když už vypotím nebo získám potřebný data, chci mít jistotu, že je otevřu i po příštím update...
- On někdo používá Exchange?
- Kalendář v mobilu nepoužívám, i když tam je. Pokud si akci nepamatuju, není tak důležitá, aby stála za pozornost. Výborně to trénuje paměť.
- Hry v mobilu? Na to nějak není čas. Možná na WC, ale tam netrávím půl pracovní doby a soft navíc znamená kód navíc a chyby navíc. A jenom to zabírá paměť, takže ten plevel jsem už dávno vyházel.
- Automatický překlad ještě není na takové úrovni, aby se při jeho použití člověk neschodil a stejně ten jazyk musí ovládat. Třeba tail může být konec zprávy, ale i... Takže se rozhodně vyplatí ten jazyk umět a občas procvičit. Takže použití OCR s překladem jenom ukazuje na lenost/hloupost majitele zařízení.
- S přehráváním videa je u mě takový malý problém, vzhledem k problémům s očima a bolestem hlavy. Takže to je taky nanic.
- Remote desktop z mobilu musí být pěkný masochismus, ono to dost dobře nefungovalo ani z jednoho PC na druhý, pokud bylo jiný rozlišení obrazovky (nevím, jestli to furt platí, roky jseem to nepoužil). Ale buďto skrolovat s výřezem nebo mít všechno tak miniaturní, že to není vidět, asi nebude žádná výhra.

No a fčíl mudruj, co je na tom tak skvělýho... Tohle smartfounový šílenství jenm dělá z lidí ještě zdechlejší a hloupější jedince. Hlava se musí trénovat nepoužíváním zakrní a pak s člověk ani neuvědomí, že je otrokem nějaké plastové krabičky...

On nic z toho nepouziva. Len vychvaluje co (udajne) WP dokaze.

Zdroj? :)
BTW na rootu píšou, že WP jsou v ČR druhý nejrozšířenější mobilní systém. Od více přátel jsem slyšel, že po zamrzání a náhodných restartech přešli z Androidu na WP, a jsou spokojení.
http://www.root.cz/zpravicky/idc-windows-phone-je-v-cr-druhy-nejrozsirenejsi-mobilni-system/

• Maily v mobilu jsou dobré pro přehled, co se děje. Na práci to ale skutečně není.
• Souhlas, navíc mobilní office se kvůli malinkému displeji a nepřesnosti dotykového ovládání hodně špatně používá
• Ano, Lael Ophir a Radek Hulán. Pokud to tedy nejsou jedna a ta samá osoba :-)
• Kalendář používám, hodí se na události více v budoucnosti, ale na to existuje standard CalDAV (Podporuje jej a CardDAV Windows Phone nebo se zase uzavírá jen na Exchange?)
• Nějaké oddechovky jsou docela fajn, ale na složitější hry to není
• Souhlas, navíc zrovna překlady od Bingu jsou proslulé svojí „kvalitou“. Google Translate se asi na Windows Phone použít nedá, co?
• Mě na přehrávání videí přijde mobil docela dobré zařízení, ve spojení s HDMI úplně parádní přenosný přehrávač, ale chápu, že mnoho lidí dá přednost třeba sudoku na Kindlu :-)
• Remote Desktop je na tak malém displeji bez kurzoru a s klávesnicí zabírající půlku displeje opravdu masochismus. Zlatý SSHčko.

- Kalendář ve WP podporuje otevřený EAS protokol, který implementuje většina serverů (včetně Google Calendar, než jeho podporu Google odstřelil). CalDAV/CardDAV je také podporovaný.
- Mobily jsou samozřejmě na oddechové hry, ne na ty složitější.
- Samozřejmě na WP můžete použít Google Translate. Existuje vícero aplikací, které k němu poskytují interface. Srovnání kvality Microsoft Translatoru a Google Translate vyznívá lépe jednou pro jeden, jindy pro druhý (používám oba). Na překlady do češtiny zapomeňte s oběma - je to nepoužitelné.
- Upřímně SSH na mobilu, tedy se SW klávesnicí, je masochismus úplně stejně jako Remote Desktop.

- Maily v mobilu jsou pro mě naopak zcela zásadní.
- Formáty MS Office naopak mají ISO/EMCA standard, a dokonce je MS Office podle toho standardu i píše (na rozdíl od OOo, který píše spoustu věcí, které ve standardu nejsou nijak popsané). A kompatibilita samozřejmě funguje.
- Ano, Exchange používá například většina firem.
- Super, trénujte paměť. Já dávám přednost kalendáři. Nad nějaký počet událostí se to špatně pamatuje. BTW telefonní seznam v mobilu je nesmysl - trénujte paměť :D
- Hry v mobilu jsou prostě na zabití volného času. Hraje je spousta lidí, já spíš výjimečně.
- Pokud jste tak pilný, že umíte italsky, španělsky, portugalsky, čínsky, japonsky, thajsky, khmérsky a pár dalšími jazyky, jistě se vám cestuje snadno. Většina lidí ale umí nejvýše pár evropských jazyků, a to často prostě nestačí. Když před sebou máte jídelní lístek v čínštině, ten OCR překlad se celkem hodí.
- Vy možná máte s přehráváním videa problém - většina lidí ne.
- Pokud si na desktopu v Remote Desktop klientu neumíte nastavit rozlišení obrazovky, moc bych se tím nechlubil. Na mobilu je samozřejmě Remote Desktop nouzovka - display mobilu je prostě malý.

Mohl jste si ale všimnout, že diskuse nebyla o tom, jestli vám ta či ona věc vyhovuje. Odpovídal jsem na Stena, který tvrdil, že WP jsou vyjma SMS a volání "dost k ničemu".

Jste s Radkem Hulánem dvě výjimky, zatím jsem osobně viděl jediného uživatele Windows Phone, který vůbec věděl, co je Exchange nebo Remote Desktop. Ale ten měl Lumii jen proto, že ji dostal zadarmo k tarifu (a používal ji pouze na SMSky a volání), o její koupi by jinak ani neuvažoval.

Mimochodem na Androidu tohle všechno funguje samozřejmě taky a za Angry Birds ani nemusíte platit ;-)

Firemní uživatelé by to vědět mohli a měli.

Neříkám že tyhle věci na Androidu nefungují. Říkám že WP nejsou vyjma SMS a telefonování "dost k ničemu". Vyjma toho se také snadno používají, jsou přehledné, rychlé, nemrznou a nevyskytují se samovolné restarty. A lidem se z nich nedělá fyzicky špatně, jako z iPhonu :)
http://www.youtube.com/watch?v=ehMhITBRdvQ

telefon "just works".

Just LOL... :-))))))))

Spolehlivost? Tohle slovo asi M$ chápe jinak než ostatní. Aby to nebylo jak u šéfa. Koupil si ultrabook s Win 7. tři dny ho používal, pak to zamrzlo. Tlačítko RESET tam nebylo, baterka vyndat nešla,... Musel ho nechat potupně chcípnout na vybitou baterku. Navíc představa, že by se to stalo při práci a člověk by místo řešení urgentního průšvihu pro zákazníka něklik hodin seděl v kantýně a čekal na reset... Nebo naopak samovolný reset, když to člověk nečeká a když to nejmíň potřebuje... Ne, dík.

A oblíbený fígl, který je známý z PC a NTB bez tlačítka Reset - podržet tlačítko Power cca 6 sekund, aby došlo k vypnutí zařízení - ten nefunguje?

Ani to prý nereagovalo... :(

Ještě že mě tyhle problémy netrápí...

Pokud notebook vytuhne, je to dost špatně. Ale neříká to nic o MS. Notebook dodává výrobce, a vyjma samotných Windows tam dodává vlastních spoustu driverů a software. Když počítač vytuhne, většinou za tím bývají právě drivery.

V návodu notebooku se nejspíš dočtete, že vypnutí natvrdo provedete dlouhým přidržením tlačítka Power. Pokud uživatel nečte návod a "strká psa do mikrovlnky", tak je to těžké. Ještě těžší to je, pokud člověk pracující v IT neví, že se notebooky vypínají právě tímhle způsobem.

A nemaju byt drivery dodavane vyrobcom certifikovane? Tak cisto naahodou

Mohou být a nemusí, záleží na výrobci. A samozřejmě ani certifikace neřeší problém způsobený dodatečně instalovanými necertifikovanými drivery.

Ophire, máš sice pěkný nick ale jinak máš v hlavě nasráno. V případě ultrabooku (cca 20 000 kč) není moc velká šance mít libovolný kritický driver necertifikovaný (to by byla celkem hanba u ultrabooku). To za prvé. A za druhé, není tajemstvím že mrkvosoft produkuje šmejdskej software a svalovat to na výrobce je fakt hodný metálu. OS by se měl přizpůsobit HW a ne naopak (inu, pak to značí neschopnost lidí jež daný OS tvoří). Já vím, si další z tuny idiotů kteří vystudovali rádoby "prestižní" ajtý školy (jo jo jednorožec) kde do vás lili mrkvosoftí sračky horem dolem takže za své vypatlané lpění na woknech nemůžeš ...

Kdybyste nevěděl jak vyplnit formulář příspěvku, je pod ním návod. Doporučuji se kouknout na body 1 a 2.

Kdybyste absolvoval alespoň nějakou rádoby "prestižní" ajtý školu, věděl byste, že Windows (a mimochodem i Linux) používají pro spoustu věcí kernelové drivery. Kernelové drivery se nedělí na kritické a nekritické. Každý z nich má potenciál systém shodit. A možná byste i věděl, že drivery jsou odpovědné za cca 85% pádů Windows. Jenom drivery nVidia byly v roce 2007 odpovědné za 28.8% BSOD ve Windows Vista, které byly hlášeny přes reporting vestavěný ve Windows.

Ale naštěstí nemusíte na Windows lpět. Vždycky je tu totiž alternativa :)
http://www.root.cz/zpravicky/nektere-nove-notebooky-od-samsungu-nepreziji-instalaci-linuxu/
http://www.root.cz/clanky/vazna-chyba-v-jadre-poskozuje-sitove-karty/
http://www.root.cz/zpravicky/vazny-bezpecnostni-problem-s-openssl-v-debianu/

Samsung vyrábí aušusy? No, je to největší výrobce mobilů s Androidem... ;)

V případě těch notebooků má samozřejmě částečně máslo na hlavě Samsung. Nicméně je to také pěkná ukázka kvality driverů na Linuxu. Jak už se probíralo, Linux používal na ACPI HW driver který vůbec se neměl natahovat, a který prováděl nedokumentované zápisy do paměti, na modelu pro který nebyl určený a na kterém nebyl zkoušený. Pokud nevidíte problém, tak máte šupiny na očích.

V případě síťových karet od Intelu šlo o zmršenou implementaci ftrace, která přepisovala co neměla, a náhodou se strefila zrovna do EEPROM paměti síťovky. Mimochodem velkou spoustu HW lze odrovnat SW: klasické CRT monitory často p nějaké době nerozdýchají nesprávné obnovovací frekvence, můžete zapsat do VNRAM BIOSu nesmyslná nastavení se kterými systém neprojde ani POST atd.

Můžete si o tom myslet co chcete. Faktem zůstává, že v těchto dvou případech šlo o zmršenou implementaci na straně Linuxu; nakonec v tom třetím také. Přijde mi ale vtipné, když předřečník tvrdí o Windows, že "OS by se měl přizpůsobit HW a ne naopak", a přehlíží takové katastrofy na Linuxu.

Samsung

Ten ovladač byl od Samsungu, a když linuxovým vývojářům přišel ten kód podivný, tak Samsung jim zaslal prohlášení, že je to tak správně. Ale může za to určitě Linux :-)

Intel

Hlavní původ problému byl, že instrukce cmpxchg na hardwarových registrech mapovaných do paměti přeskočí porovnávání a rovnou zapíše. Tohle mi přijde jako poměrně zásadní chyba v implementaci instrukční sady. Ve spojení s tím, že ty karty měly ve výchozím stavu odemčenou EEPROM (takže šly snadno zničit i bez načtení ovladače!), to takhle dopadlo.

OpenSSL v Debianu

Tohle byl skutečně problém. Na druhou stranu, když se na něj přišlo, všude se řešilo, jak je nutné vyměnit klíče, a OpenSSH automaticky regerovalo postižené klíče po aktualizaci a šlo nastavit, aby odmítalo postižené uživatelské klíče. MS-CHAPv2 je naproti tomu už dlouho prolomený (čtrnáct let na superpočítačích a přes rok už i pomocí běžného počítače) a MS mlčí a klidně jej používá dál.

Teď nevím jestli máte špatné informace, nebo záměrně šíříte bludy.

Samsung - autorem modulu samsung-laptop není Samsung, ale Greg Kroah-Hartman. Ten kdysi dostal od Samsungu nějaký kus zdrojáku, podle něj implementoval vlastní driver, a ten od té doby používal - i na strojích se kterými nebyl testovaný. Jenže interface BIOSu, který používal, není k dispozici při bootu přes UEFI. Kroah-Hartman sice testoval jestli běží na EFI, jenže funkce efi_enabled() tehdy nevracela zda systém bootoval pomocí EFI, ale zda zabootoval z EFI se stejnou bitovou šířkou (x64 kernel na x64 EFI). V důsledku toho drivery mohou například zkoušet zapisovat do paměti BIOSu, i když bylo bootováno z EFI.
V kódu tedy byly závažné bugy, které způsobovaly zápisy na paměťová místa, na které se vůbec nemělo sahat. Fakt vám tohle připadá jako problém Samsungu?
https://plus.google.com/111049168280159033135/posts/h7FjkQKZHKT
http://www.theregister.co.uk/2013/03/22/uefi_boot_memory_full/
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/platform/x86/samsung-laptop.c
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=83e68189745ad931c2afd45d8ee3303929233e7f

Intel - příčinou problému byly bugy v implementaci ftrace. Kód každé funkce začínal kvůli profilingu voláním mcount(). Aby nedošlo ke ztrátě výkonu když profiling nepoužíváte, prováděl se runtime patching: při volání mcount() si ftrace zapamatoval adresu ze které byl volán, a později asynchronně instrukce volání mcount() v paměti přepsal za NOP. Když byl modul volající mcount() odstraněn z paměti ještě než ftrace stačil přepsat volání mcount() za NOP, mělo proběhnout odstranění té adresy z tabulky, podle které se runtime patching prováděl. Jenže v kódu byl bug, takže se runtime patching provedl i pokud byl modul v mezičase ostraněn z paměti.
Jako poslední záchrana tam byla instrukce cmpxchg, která měla zjistit, jestli se na cílovém místě opravdu nachází volání mcount(). Tahle záchrana většinou fungovala, a asi si díky tomu nikdo nevšiml výše popsaného bugu. Bohužel v tomhle případě nezafungovala, protože výsledek instrukce cmpxchg nad device memory je nedefinovaný. A protože na dané adrese byla zrovna náhodou paměť síťovky, tak došlo k zápisu do její NVRAM.
Jak vidíte, tak kódu byly minimálně dva zásadní bugy, plus byla použita naprosto nevhodná technika. Ftrace byl poté výrazně přepracován.
https://lwn.net/Articles/304105/
http://lwn.net/Articles/303390/

Navíc tohle není jediný podobný problém. Modul lm-sensors během detekce zařízení prováděl zápis do jejich NVRAM. Výsledkem byla CRC chyba NVRAM, díky které nebootovaly ThinkPady. Samozřejmě by bylo možné mít databázi modelů zařízení a jejich senzorů. Ale proč se s tím dělat, když je možné prostě osahat každé zařízení na SMBusu, zkusit s ním provést nějaké operace o kterých nikdo neví co na cílovém zařízení udělají, a ono to třeba nějak vyjde. A nebo nevyjde...
http://www.lm-sensors.org/browser/lm-sensors/branches/lm-sensors-2.10/README.thinkpad
Další starší problém: autoři kernelu se rozhodli, že budou rozeznávat CD-ROM a CD-RW zařízení nikoliv podle standardu ATAPI (IDENTIFY PACKET DEVICE, nejspíš word 0), ale tak, že zkusí zavolat funkci specifickou pro CD-RW. Bohužel CD-ROM mechaniky LG na to reagovaly přepsáním firmwaru. Důvodem zvoleného přístupu bylo zřejmě to, že se někteří výrobci CD-RW nedrželi specifikace, a tahle "detekce" přišla autorům jako dobrý nápad. Samozřejmě by se dala používat detekce podle ATAPI standardu a k tomu databáze zařízení, které se standardu nedrží. Ale co se patlat se standardy a výjimkami - zblastlíme to, ono to nějak dopadne. A nebo nedopadne...
http://en.wikipedia.org/wiki/Killer_poke#LG_CD-ROM_drives

Všechny tyhle problémy mají společné používání praseckých technik, které za daných okolností tak nějak fungují, ale později se vymstí a nadělají děsnou paseku. Otázka je, kolik podobných nebezpečných technik, nedokumentovaných interfaců a špinavých hacků ještě Linux používá, a jen náhodou nezpůsobily bricknutí HW, ale třeba jen nějaké to zamrznutí ve specifické konfiguraci.
Všimněte si, že místo přístupu "děláme se zařízením to co je popsané a vyzkoušené" se jedná o přístup "zkusíme střelit od boku, na testování kašleme, a při troše štěstí nám to projde". Je zajímavé pak slyšet, že by si výrobci měli lépe zabezpečit HW před... zpraseným kódem OS.

OpenSSL v Debianu - MS-CHAPv2 je prolomený za specifických okolností, navíc se ve Windows už 10 let používá Active Directory s Kerberem.

Samsung

Dobře, v tomto případě za to může špatná detekce EFI. Nic to ale neubírá na tom, že bez zpraseného hardware od Samsungu (s oficiální informací od Samsungu, že takhle se to používá) by se to nestalo.

Intel

Pokud cmpxchg neprošlo, tak to vyvolalo BUG. Ale předpokládalo se, že cmpxchg takové chyby zachytí, než se dynamic ftrace důkladně otestuje. Ftrace jasně uvádí „you will be offered the choice of using features or drivers that are currently considered to be in the alpha-test phase“ a je ve výchozím stavu vypnut, dynamic ftrace byl jedna z těch alpha věcí.

Já nevím, ale mě informace, že cmpxchg zapíše bez ohledu na hodnotu, nad kterou je spuštěný, přijde jako dost zásadní problém v instrukční sadě. I na menší problémy (třeba špatné zarovnání) se normálně vyvolávají hardwarové výjimky. Stejně jako mi přijde dost podezřelé, že ta síťovka je ve stavu povolujícím zápisy hned po nabootování (není ji potřeba odemknout). A ještě umožňuje zapsat do registrů hodnoty, které jsou vadné, a firmware se z toho neumí zotavit.

Dynamic ftrace nebyl kvůli tomuto kompletně přepsán. Byl upraven tak, že cmpxchg už nepoužívá, což znamenalo spoustu kódu a výkonnostních problémů. No co se dá dělat.

lm-sensors

Tohle se týká pouze sensors-detect, což je (překvapení!) skript pro detekci senzorů. Proto také senzory detekuje a nenačítá z databáze. Ten skript při spuštění samozřejmě důrazně varuje, že je potenciálně nebezpečný, protože při detekci sahá všude možně.

ATAPI

Jistě není chyba LG, že použila ATAPI kód, který je vyhrazen na něco jiného, a to ještě na věc, která není nebezpečná, že? :-) No, jediné, čím se LG mohl hájit (a hájil), že Windows ten ATAPI kód nevolají ani u CD-RW mechanik.

Seznam výjimek má jednu zásadní vadu: nefunguje na nový hardware. Takže je trochu podivné slyšet tohle od člověka, který si zase na vedlejším fóru stěžuje nad občas problematickou podporou nového hardware v Linuxu. Myslíte, že by to vylepšilo?

MS-CHAPv2

MS-CHAPv2 je prolomen pro všechny případy. V MS Windows se MS-CHAPv2 stále používá pro PPTP. V oficiální dokumentaci není o problémech s MS-CHAPv2 ani slovo. Paráda.

Samsung - samozřejmě Samsung měl bug v implementaci UEFI. Nicméně to nic nemění na tom, že modul samsung-linux i funkce efi_enabled() byly v kernelu Linuxu implementované špatně.

Intel - to se předpokládalo špatně. Některé operace na memory mapped registers jsou undefined; tak Intel ty CPU navrhl. Na všech architekturách má řada operací nedefinovaný výsledek.
Ohledně vlastní síťovky: HW prostě není stavěný tak, že můžete někam náhodou ustřelit, a spoléhat na to, že se nic nestane. Jako triviální příklad bych uvedl Programmable Interval Timer Intel 8253, který byl v původních PC (a nejspíš je jeho obdoba součástí PC dodnes - HW už nedělám). Counter 0 se v OS používal jako rate generator nastavený na 18.2Hz; jeho interrupty (int 8h) se používaly k udržování RTC a provádění multitaskingu. Programování se provádělo zápisem dvou(!) hodnot na port 40h. Když jste zapsal jen jednu hodnotu, při příštím zápisu na port 40h OS brutálním způsobem rozhodil časovač, protože jste změnil byte order. Nevím co konkrétně pánové provedli síťovkám e1000e, protože nemám jejich dokumentaci, a upřímně nemám náladu ani čas problém reprodukovat.
BTW autoři ftrace mohli úplně stejně třeba způsobit vytuhnutí systému, nebo mršit data zapisovaná na disk; bylo jen věcí náhody, že se strefili zrovna do síťovky, a zrovna ji u toho odepsali, takže způsobený problém jaksi nešlo přehlédnout.
BTW2 CONFIG_DYNAMIC_FTRA­CE měl výchozí hodnotu "y". Nakonec jinak by ty karty neodcházely.
BTW3 používat runtime patching není dobrý nápad; když už ho člověk používá, tak by si to měl zatraceně dobře pohlídat.

lm-sensors - ano, problém se týkal detekce senzorů. Místo toho má lm-sensors obsahovat DB modelů a senzorů, aby nebylo nutné jejich hledání, které přináší takováhle rizika.

ATAPI - společnost LG vyrobila CD-ROM mechaniku, a u ní daný příkaz nemá definovaný výsledek. Bohužel jim přišlo jako dobrý nápad zrovna na tenhle kód pověsit flash firmwaru. Nicméně tím specifikaci nijak neporušili - CD-ROM mechanika nemusí odpovídat specifikaci CD-R mechaniky. A nedokumentované příkazy na na flash firmware používají naprosto běžně. Specifikace totiž typicky nemají (resp. za mých let neměly) příkazy pro update firmware, a někam to prostě pověsit musíte.
Samozřejmě seznam výjimek vyžaduje jeho udržování. Když přijde nový HW, který se nedrží specifikace, musíte ho do seznamu připsat. Nicméně to není nijak složité implementovat, a je to čisté - na rozdíl od posílání příkazů specifických pro CD-R mechaniky CD-ROMkám. Dirty hacks se totiž časem vymstí.

MS-CHAPv2 - hledal jste špatně: Microsoft cautions that any organizations that use MS-CHAP v2 without encapsulation in conjunction with PPTP tunnels for VPN connectivity are running in a potentially nonsecure configuration.
http://technet.microsoft.com/en-us/security/advisory/2743314
http://support.microsoft.com/kb/2744850

Když to shrnu, tak kvalita vývoje Linuxu má velké rezervy. Windows zdaleka nejsou dokonalé - nakonec je to SW :). Nicméně pokud se Linuxu podaří opakovaně způsobit díky chybám v kódu bricknutí HW, není to na pochvalu, ale naopak na vážné zamyšlení. Argumentovat že má být HW lépe zabezpečený proti špatnému OS je sice pěkné, ale neřeší to kvalitu kódu Linuxu.
Řešení se dá snadno popsat. Implementovat drivery podle dokumentace, důsledně testovat na reálném HW, používat drivery jen pro testované modely zařízení. Používat bezpečné techniky kódování, a hlavně nestřílet od boku. Bohužel asi oba chápeme, že když uživatelé za SW neplatí, tak na takový přístup k problematice prostě nejsou zdroje.

Ty notebooky šlo odstavit prostým zabootováním Linuxu, a na straně Linuxu zjevně byly zásadní chyby.

O čem měli soudruzi z LG informovat? Měli snad dát na mechaniku velkou nálepku "tohle je CD-ROM, nezkoušejte k němu přistupovat jako k CD-R, CD-RW, disku, scanneru, automatické pračce nebo řídící jednotce motoru"? :D Jejich CD-ROM mechanika fungovala podle specifikace pro CD-ROM. To že se někdo rozhodl k ní přistupovat nepodporovaným způsobem není chyba výrobce.

Windows 8 a další snad ani neumožňujjí nainstalovat necertifikované ovladače (WHQL), na druhou stranu Microsoft nemůže vytvářet ovladače sám o sobě, i přes to jaké má zisky, tak by to prostě nezvládl. TO za prvé. Za druhé - může se stát, že dojde ke konfliktům mezi dvěma ovladači na dvě různá zařízení (nedávno mi hodil systém BSOD kvůli tomu, že sem měl zaplý internet současně přes Wi-Fi a LAN port, samostatně s tím není problém). To Microsoft asi těžko ovlivní. Jinak je naprosta utopie tvrdit, že výrobce OS e má přizpůsobit HW. Uvědomujete si vůbec, že v oblasti IT existuje téměř nekonečno možnosti, jak sestavit počítač a dokonce i v rámci jednoho výrobce se může stát, že se použíji jiné "kondíky" na jinak dvě stejná zařízení (může to být například z finančních důvodů, nedostatku součástek a já nevím čeho všeho). Podle mě je umění vůbec vytvořit OS, tak aby fungoval na 80% všech HW konfigurací a zbylých 20% se muselo řešit nějak "manuálně" (jo ty čísla berte s rezervou :D ). Pokud chcete dobře fungující systém, od kterého očekáváte, to co ste psal (OS uzpůsobeny hardwaru) jděte do Applu. Do diskuze, který OS a na co se pouštět nebudu (věřte mi, nelíbí se mi, že na většině škol je prosazován MS, ale to nutně neznamená, že je špatný, řekl bych, že jeho provázanost mezi jednotlivými komponentami hlavně na serverové úrovní je něco, co Linuxu chybí, na druhou stranu takové věci jako firewall, Samba, iSCSI a spousta dalších se mi líbí daleko víc na Linucech, samozřejmě na tohle téma by se daly vést never-ending diskuze, ale nechci, aby se to strhlo v nějakou hádku)