Vlákno názorů k článku
Ubuntu uzavřelo bug číslo 1 od anon - Pokaždé, když slyším jméno Shuttleworth, chce se mi...

WP mají například vyšší user satisfaction rate než Android. MS samozřejmě s WM ujel vlak, a prosadit novou platformu WP na trhu bude dost trvat.

Tvoja user satisfaction rate je velmi zavadzajuce cislo.

Treba si uvedomit, ze WP je rozsireny akurat tak na par mobiloch Nokie, zatial co Android na stovkach typov mobilnych telefonov, ktore su HW lepsie ale aj horsie a nespokojnost s Androidom je casto vinou HW a nie systemu samotneho.

Taktiez si treba uvedomit, ze pocet ludi, ktori Android pouzivaju v nasobkoch desiatok prekracuje pocet uzivatelov WP... A pri takom pocte sa lahsie dosahuje vysledok aky chceme ;)

WP běží na telefonech od Nokie, HTC, Samsungu, Dellu, LG, Fujitsu Toshiba, ZTE, a ASUSu. Nokia má pravda většinu uživatelů.

Problémem Androidu je samozřejmě i kvalita implementace. Většinou to není problém samotného HW, ale spíš driverů, nadstaveb UI apod. Tady má MS výhodu, protože svoje partnery nutí nabízet kvalitní zařízení (což nutně neznamená vysokou cenu). Naopak Android může do svých výrobků cpát každá čínská fabrika, která je schopná poskládat plošňák a nějaký kryt, bez jakékoliv záruky kvality.
Nicméně problémem Androidu je i HW náročnost (WP ve srovnání s ním lítají i na slabém HW) a existence spousty malwaru v oficiálním Google Play.

Tohle mě celkem pobavilo, zvlášť v poslední třetině.
http://www.youtube.com/watch?v=XW-boe_-M4U

To bude tím, že na těch pár admin tasků ve Windows nepotřebují admini znát stovky příkazů, jejich syntaxi, umístění logů, bash, regexpy, vi, Perl a Cčko :)

Tohle mi příjde jako Laelovina z opačného konce spektra. Na desktopu používám win7 už x let, aniž by mi něco zpomalovaly, nebo bych musel odklikávat nějaké otravné dialogy. Kde na to člověče chodíte? Jediný dialog, který musím potvrdit, je při instalaci softu, nebo pokud chci něco spustit jako admin, a to na linuxu musím taky, pokud nedělám pod rootem.

Momentálně pro názornost: 109 běžících procesů, mimo jiné FF, Chrome, Eclipse, 2x virtuál, VPN, Jabber, SIP, Thunderbird, LO Calc, TC... zabrané paměti 3,55 G, CPU mezi 3 a 15 %
Pustil jsem k tomu všemu full HD (22 GB) z NAS, CPU mezi 20 a 30 %, RAM 3,75 G
Přidal jsem kopírování souboru z NAS, CPU kolem 50 %, rychlost kopírování 85 MB/s

Podle mě si win7 vedou skvěle.

BTW už se na Linuxu podařilo nějakému přehrávači něco udělat s tou věčnou neplynulostí videa? Nemám na mysli škubání (prostě nesmí běžet na pozadí nic co vytěžuje CPU nebo disk - nejsou to holt Windows), ale to nepřirozené zrychlování a zpomalování, které působí velmi rušivě ve scénách s plynulým pohybem.

Instalace Windows 7 i 8 je velmi rychlá. Aktualizace samozřejmě trvají, ale můžete to zkrátit instalací z média s integrovaným SP.

Ale no tak, instalace windows trvá ani ne půl hodiny. Když to přeženu, tak hodinu s instalací ovladačů místo těch základních, co jsou ve windows.

Tak abychom nevařili z vody, udělal jsem pokus. Instalace Win7 x64 na virtuál, vyhrazeno 1 jádro CPU + 1 GM RAM. Čistá instalace od bootu do 1. zobrazení funkčního desktopu 15 minut! Instalace ovladačů nemůže zabrat víc, než 30 minut, a to fakt nevím, co bych tu půlhodinu dělal.

Ehm, já ten nakřáplý ovladač nVidie řešil 3 hodiny, než se mi podařilo dát to do kupy. Rychlejší by asi fakt byl čistý reinstall.

Se starým HW se obraťte na výrobce, stejně jako v případě linuxu.

Mě se nepřirozeně zrychlovalo a zpomalovalo. Když jsem to ukazoval dvěma fanouškům Linuxu, ani jeden to nejprve neviděl. Oni často nepostřehnou ani ten tearing, asi jsou zvyklí. Chybějící deinterlacing zpravidla poznají, když člověk obraz zastaví :)

Že je problém starý několik let? No a co? I ten OOM Killer a terminálové sekvence jsou na Linuxu dodnes. Problém většinou neodejde sám s časem, a nezmizí tím že o něm nebudete mluvit.

LOL :-D

Neuveritelne, mne sklbe video na W7. Este ze na videa nemam cas.

Srovnával jsem a srovnávám dodnes. Proč myslíte, že používám na desktopu windows? Ať už je MS, jaký chce, fanaticky odsuzovat jejich systém prostě proto, že je od MS, je krátkozraké až hloupé.

Když už tedy chcete srovnání, tak proč na linuxu nelze v mnoha případech přehrávat video plynule v rychlejších scénách (nefunguje v-sync), proč Pulse Audio při startu přehrávání "kliká", proč mi kopírování většího souboru umí vytížit systém tak, že přepnutí okna trvá sekundy?

XFCE4 jistě není špatný WM, ale přijde mi jak z minulého tisíciletí. Z win7 jsem zvyklý na jistý komfort ovládání a třeba taková blbost, jako nemožnost zvolit myší aplikaci z tasklistu (okno při alt+tab), mě dokáže znechutit. Alespoň po letech přidali možnost se po ikonách pohybovat pomocí klávesnice, hurá pokrok. O nastavení vzhledu raději taktně pomlčím.

"Krome toho nemam nervy na OS, ktery se instaluje pul dne a pak se jeste dva dny aktulizuje. Za tu dobu udelam nekolik Debianu."

Jasně, pokud máte štěstí a systém po instalaci jede bez větších problémů (bavíme se doufám o desktopu s GUI?) :-) Já jsem win7 instaloval 2x, jednou při upgrade z XP a podruhé při změně HDD za SSD. Pravda, byly doby, kdy systém náhodně zamrzal při probuzení grafiky, ale za to mohl ovladač nVidie. Není to tak dávno, co mi Ubuntu po automatické instalaci driveru grafiky už nenajelo a muselo se opravovat a instalovat ručně, nebo reinstalace. Vážně úžasná věc něco řešit v konzoli bez přístupu na net.

Já si užil dost a dost s oběma systémy a ani jeden z nich si nemá vůči tomu druhému co vyčítat. Nicméně musím říct, že win7 je stabilní systém vhodný pro profesionální práci. Výše uvedené výsledky jsou z mého stařičkého NTB, Core2Duo 2,2 Ghz, 4 GB RAM, tedy žádné "dělo". Na systém. disku zabráno 23,7 GB (systém + aplikace + nějaké hry) po 8 měsících provozu (reinstal kvůli SSD).

Tearing u přehrávání videa je na linuxu věčný problém, netýká se jen fullHD, viz třeba http://askubuntu.com/questions/125245/how-do-i-stop-video-tearing-nvidia-prop-driver-non-compositing-window-manager

Já se místo odinstalování PA a instalování bůhvíčeho, aby mi to jelo, na to vys... a používám windows, kde takové věci prostě řešit nemusím.

Já u PC sedím každý den x hodin a vítám proto cokoliv, co mi ten čas zpříjemní. Stejně tak jako kdybych byl profi řidič, nejezdil bych felinou na plyn, ale koupil bych si pořádné, pohodlné a bezpečné auto. A že by mi systém žral moc prostředků jsem nějak nezaznamenal (viz výsledky výše). Pokud PC používám jako profesionál k obživě a nemám na to, abych si pořídil HW alespoň jakž takž poplatný době (několik let starý z bazaru), tak bych měl jít dělat něco jiného.

Všechny ty řeči o nepoužitelnosti widlí, reinstalech, vytěžování systému a podobně jsou dávno pasé. Zrovna tak strašení s bezpečností. Dnes se bezpečnost na desktopu týká zejména prohlížečů a jejich doplňků. Pokud nebudu instalovat desítky kdejakých bůhvíodkud stáhnutých aplikací, nebudu mít s pezpečností vážnější problémy, jako jsem je neměl už bůhvíkolik let.

Počítám, že stejně blbě. A o to tu jde. Řeči, že linux je na desktop nejlepší, protože blabla a problémy neexistují a windows jsou nejhorší, protože blabla a před 10 lety tu byly XP se špatnou správou paměti a před 15 Me, které padaly, mě točí. Na server bych windows nepustil (i když i tady se najdou výjimky), jedině linux nebo BSD, ale o desktopu tohle prostě neplatí. Co stroj, to originál, na dvou naprosto identických strojích se může chovat OS odlišně. Obecně ovšem v dnešní době platí, že windows pojedou spolehlivě na mnohem větší skupině PC, než linux. A, přiznejme si, není to jen o těch ovládačích.

Tohle samozřejmě bude jedna z možností. Ani v tomto případě však generalizace linux rulez widle sux platit nebudou.

Mezi námi, modlím se, aby vývojáře na linuxu osvítil svatý duch, přestali s těmi věčnými změnami a forky všeho a věnovali se řešení problémů toho, co jakž takž funguje, protože to, co MS předvedl se svým nejnovějším výtvorem, jsem fakt nečekal. A jestli do doby, než skončí podpora win7, nepřijde ani jedna strana s pro mě přijatelným řešením, fakt nevím, kam se vrtnu. A to nás chraň pámbu před experimenty s OS v cloudu.

Nestandardní prasárny na straně Linuxu byly důvodem, proč Linux ničil karty Intel e1000e (chyba v ftrace), vypalovačky LG (prasácká detekce zapisovací mechaniky) a bricknul notebooky Samsung (použití nedokumentovaného interface BIOSu, který při EFI bootu není k dispozici). A to jsou jen ty tři případy, kdy prasárny v Linuxu vedly k poškození HW. Kolik dalších příšerností vaše distro s HW provádí, ale náhodou to zrovna neodpálí žádný HW, to asi nikdo neví.

Fakt nevidíte v těchto případech žádný problém u Linuxu, který je krásně čistý a "spoléhá na standardy"? :) Tak se pojďme podívat.

Stručně o bricknutím notebooků Samsung. Problém je v driveru samsung-laptop, který používá nesprávný interface (nedokumentovaný interface BIOSu, navíc při EFI bootu kde ty funkce nejsou k dispozici), a nebyl nikdy testovaný na dané konfiguraci. To je neomluvitelná chyba, a spoléhání na nedokumentované vlastnosti konkrétní implementace - nevidím žádné spoléhání na standardy. A vede to ke crash dumpu, který způsobí přeplnění UEFI storage space (další chyba - do EFI Storage se zapisuje příliš dat). To pak vede k přeplnění NVRAM a notebook se brickne, což je už zase chyba Samsungu. Ve Windows se problém pochopitelně neprojevuje, protože tam kód driveru podobné příšernosti neprovádí. Lze samozřejmě napsat kód, kterým admin může UEFI storage space také přeplnit (se stejným výsledkem). U Linuxu naopak stačí k bricknutí jen zabootovat. Obecnějším důvodem je nevhodný vývojový model Linuxu a nedostatečné testování.
http://www.root.cz/zpravicky/notebooky-samsung-s-uefi-je-mozne-znicit-i-z-windows/448027/

Pokud vás zajímají detaily toho bricknutí CD-ROM mechanik LG, tak tam problém také nebyl primárně u výrobce. Linux "chytře" rozeznával mezi CD-ROM a CD-R/CD-RW mechanikou tak, že provedl pokus o zápis. Většina mechanik vrátila chybu, pokud zapisovat neuměly. U CD-ROM mechanik LG ovšem byl tenhle příkaz použit pro flash firmware, což technicky není nic proti ničemu. Je to sice dost nevhodné, ale odpověď čtecí mechaniky na daný příkaz prostě není popsaná. Root cause problému je ten, že Linux používal prasáckou metodu k rozeznání CD-ROM a CD-R/RW mechanik. Rozeznávat čtecí mechaniku tak, že jí zkusíte nacpat nějaké příkazy které na tomto HW nemají definované chování, a budete sledovat jejich výsledek, mi se spoléháním na standardy (nebo na zdravý rozum) nějak nesedí. Asi to někomu doma přišlo jako dobrý nápad, na nějakém HW to zafungovalo, a tak předpokládal, že to funguje všude.
http://en.wikipedia.org/wiki/Killer_poke#LG_CD-ROM_drives

Pokud vás zajímá bricknutí intel e1000e, tak tak šlo o chybu v ftrace, která vedla k přepsání NVRAM. Opět prasácký kód, a opět nedostatek testování.
http://ostatic.com/blog/likely-cause-of-intel-e1000e-bug-discovered

Zastánci Linuxu mohou hodiny mluvit o tom, že Linux je sice technicky zastaralý (monolitický kernel, threading naroubovaný otřesným způsobem a po mnoha letech), ale že jde o "osvědčený" přístup. Pak přijdou tři takovéhle chyby, a je jasné, že kvalita implementace je *mimořádně* nízká. Takových věcí totiž nejspíš uvnitř kernelu vyhnívají tuny, jenom zrovna nezpůsobují bricknutí HW.

1. Firmware se dnes naprosto běžně aktualizuje bez zásahu do HW. Pokud může nějaká utilita přepsat firmware, může to celkem logicky udělat i jiný SW.
2. V kódu byly zjevně špatné postupy: používání nepodporovaného interface, volání interface v situaci kdy nemůže být k dispozici, detekce typu zařízení zkoušením nepodporovaných příkazů. Pokud to vede k bricknutí HW (což bylo vidět ve všech třech případech), tak je ten SW napsaný špatně. Ve všech třech případech nemůže být řečo nějakém "spoléháním na standardy". Všude šlo o špinavé hacky, které se prostě nevyplatily. Náhodou ty špinavé hacky nevedly "jen" k neprobuzení stroje ze spánku, nefunkčnosti zařízení nebo pádu systému, a strefily se do něčeho, čím HW brickly.
3. Ani jeden z těch případů nebyl jen chybou výrobce, i když ten HW mohl být lépe chráněný před chybami autorů kódu. Kdyby se Linux opravdu držel specifikací a "standardních" postupů, ani k jednomu z těch problémů by nedošlo. Kdyby byl kód testovaný s cílovými zařízeními, také by k problému nedošlo. A kdyby byl vývojový model Linuxu lepší, nebyl by ten kód takhle zprasený.

Takže trvám na tom, že mluvit o Linuxu a "spoléhání na standardy" je velká iluze. A opakuji, že podobného zahnívajícího kódu bude v Linuxu nejspíš daleko víc, jenom nezpůsobí zrovna bricknutí HW.

Aktualizace firmwaru bez zásahu do HW je běžná u spousty HW, od řídících jednotek automobilů až po mikrokód CPU.

BTW to je váš jediný argument? Fakt nevidíte ten kontrast mezi vaším "Linux ocekava chovani podle standardu" a těmi špinavými hacky v kódu, které se žádným standardem nemají nic společného?

Vy byste mě rozesmál. Když dokáže přepnout možnost flashování BIOS, jak to asi udělá? Zřejmě nějakým kódem. A když to může udělat v kódu BIOS, může to udělat i jiný kód, třeba driver nebo kernelový modul. Samozřejmě možnost natáhnout defaults bez zásahu do HW je fajn, většina klasických BIOSů to uměla při detekci nějaké klávesy při zapnutí počítače.

U Samsungu špinavé hacky v Linuxu vedly k aktivaci chyby firmware, která se jinde neprojevovala (byť je jí samozřejmě možné cíleně vyvolat). Jinak Windows samozřejmě log píšou, pokud vím, tak na výhradně na disk. To přeplnění UFI storage klidně mohlo být i na více než 100%, protože nevíme v jakém formátu se ta data ukládají, ani kolik jich tam je před těmi zápisy. Samozřejmě je to bug.

Zkuste pochopit hlavně něco jiného. Linux nespoléhá na standardy, ale na spoustu špinavých hacků, které navíc často ani nejsou vyzkoušené na HW, na kterém se snaží fungovat. Výsledkem pak může být cokoliv - od toho že věc funguje, přes různé drobné problémy nebo zamrzání, až po bricknutí HW.

Mimo svět Linuxu většinou píšou drivery lidé s mozkem, drží se specifikací, a nepouštějí driver na HW pro který nebyl stavěný. "Extrémní programování" se ve světě driverů prostě nenosí.
Navíc autoři OS mají HW do značné míry daný. Na otevřené platformě, jakou je PC, neexistuje možnost někomu zakázat produkovat špatně navržený HW, nebo se držet nějakých zavedených postupů. Proto MS vynakládá tolik úsilí na psaní Device Driver Kitu, dokumentaci a příklady, komunikaci s výrobci HW, certifikaci HW apod.

Na Linuxu je situace ohledně driverů prostě tristní. V kódu jsou nesprávné předpoklady, jsou používány nepodporované interfacy, drivery neberou v potaz specifika konkrétní HW implementace, netestuje se na reálném HW. HW samozřejmě občas obsahuje prasárny, ale Linux je na tom podobně, možná hůř. Když dělá prasárny HW i SW, těžko můžete čekat, že bude výsledek fungovat.

Takže když to shrnu: Linux nespoléhá na standardy, ale na sadu špinavých hacků, které mohou způsobit různé problémy, a to včetně bricknutí HW.

Už jsem samozřejmě viděl i mizerné drivery pro Windows. Na Linuxu je to ale spíš pravidlo než výjimka. Navíc člověk nikdy neví, jestli koupený HW bude opravdu fungovat, protože program certifikace HW je naprosto nedostatečný (a navíc většinou specifický pro jedno distro).

Jedno zajímavou zkušenost jsem tu už několikrát popisoval, ale klidně to udělám znovu. Kupoval jsem WiFi PC card do notebooku. Našel jsem kousek certifikovaný pro Windows, a v nějaké wiki jsem dohledal, že Frantovi a Lojzovi funguje i na Linuxu. Ve Windows fungovala bezvadně. Na Linuxu ji to nenašlo, a musel jsem stáhnout madwifi. Původně stabilní verzi, ale s tou to nešlo. Takže zdroják devel verze, s nějakými závislostmi, a zkompilovat ho. Jenže jednou ze závislostí byla novější verze glibc, kvůli které bych musel upgradovat na novější Ubuntu, což by HW asi nerozdýchal. Nakonec mi to kamarád staticky zkompiloval na svém poči. Z command line to nakonec nějak fungovalo. Bohužel nešlo to GUI pro WiFi, které je součástí Ubuntu. Bohužel se počítač při natahování modulu i při každém připojování k WiFi na pár vteřin seknul. Bohužel to neumělo WPA2-PSK. Bohužel to občas bez zjevného důvodu vytuhlo celý poč. Strávil jsem na tom dobu, za kterou bych vydělal na licenci Windows a další WiFi kartu k tomu.

Chcete jinou příhodu? Dovolil jsem si připojit k domácímu desktopu druhý monitor, resp. projektor. Ve Windows to samozřejmě fungovalo. Bohužel v Linuxu ty skvělé open source nVidia drivery po bootu zobrazily naprosto rozpadlý obraz, a nepodařilo se mi to dát dohromady. A protože moje distro nemělo vestavěné nVidia drivery, musel jsem je stáhnout, dotahat zdrojáky kernelu a ještě něčeho, a nechat instalátor provést kompilaci. Pak jen párkrát prozkoumat logy X11, abych zjistil proč to nenabíhá, udělat pár změn, nadefinovat rozlišení monitoru v konfiguráku (DDI nefungovalo), a bylo skoro hotovo. Kurzor myši se bohužel zobrazoval na jiném monitoru než obraz, i když klikal správně. K přepínání monitorů a rozlišení za běhu ani aktivaci 3D akcelerace (tak aby jel alespoň TuxRacer) jsem se nedostal. Podobných příhod bych mohl samozřejmě dodat víc, včetně rozpadávajícího se SW RAID5, problémů s 16 partitions na RAIDu apod.

Samozřejmě někdo podobné příhody považuje za příjemně strávený čas, u kterého se naučil něco o fungování počítače. Jenže já to vidím jako ztracený čas, ve kterém jsem se naučil nejvýš něco o obcházení bugů Linuxu.

MadWiFi je naopak dobrý příklad. Atheros? Umíme, je na to projekt. Jenže ten projekt je, jak to tak bývá, mizerně implementovaná slepenina různých hacků. Hardware Compatibility List? Máme, dělá ho "komunita". Jo, ale bez jakéhokoliv ověřování výsledků a bez důkladného testování. Takže fanoušek Linuxu může s klidem říci, že je to celé vlastně OK; akorát je to celé úplně na p**u. Podobně na Linuxu "jde" a "funguje" v podstatě všechno.

Můžete si všimnout, že pro MS výrobci také nechtěli psát drivery. A co udělal MS? Spoustu driverů napsal sám - pro Windows 3.x, 9x i řadu NT. A kupodivu ty drivery neničily HW, nerozhazovaly obraz, ani neprováděly jiné příšernosti, a naopak byly velmi stabilní. Tak proč to nejde na Linuxu? Že by za tím byl nedostatek zdrojů plynoucí z toho, že uživatelé za SW neplatí? Co myslíte?

HW se postupně komplikuje, a psát drivery je pochopitelně také komplikovanější. Nicméně autorům Linuxu nikdo nebrání se dohodnout s výrobci HW. Třeba přijít s pytlem bankovek a říct "chceme specifikaci". Nebo výrobce přesvědčit ke psaní driverů (nakonec nVidii není potřeba přesvědčovat, drivery píše). Jenže komunita kolem Linuxu na to jde jinak. Nejprve nahází výrobcům klacky pod nohy absencí ABI, pak rozdrobením Linuxu na tisíc dister, častými změnami interface kernelu, k tomu začnou vývojáři mluvit o nutnosti drivery uvolňovat pod GPL, a nakonec Linus zvedá prostředník. Na výrobce to zjevně neudělalo velký dojem.

Já souhlasím s JardouP. Chyba je zásadně na straně výrobců, stejně tak jako u zprasených BIOSů, ACPI a dalších podobných lahůdek.

Je zvláštní, že když člověk používá Linux, tak to výrazně mění úhel pohledu. Zkoušet typ zařízení tak že ho krmím příkazy které nemají definovaný výsledek - to je přece "standardní". Používat nedokumentovaný interface BIOSu, a to i při ACPI bootu, kdy ten interface nemůže být k dispozici, a samozřejmě bez zkoušení na cílovém HW - jo jo, tak se to přece má dělat. Napsat kód tak "kvalitně" jako ftrace, takže se spoléhá že se nevyskytnou v paměti nějaké hodnoty - jasně, skvělé. Nikde žádný problém, Linux je nejlepší. Máte to fakt jednoduché.

Samsung neomlouvám, jeho implementace EFI má zjevně bug. Jenže na rozdíl od vás vidím i opakovaně popsané problémy s driverem samsubg-laptop na Linuxu: použití nedokumentovaného interface BIOSu, jeho použití při EFI bootu kdy není k dispozici, a použití toho driveru na HW se kterým nebyl nikdy testovaný. Vy jste naopak tvrdil, že Linux je v tom nevinně, protože spoléhá na "standardy". To se ukazuje jako velký nesmysl.

To říkejte zákazníkům, kterým na tom HW bez problému běžely Windows, a boot Linuxu z liveCD jim bricknul HW :)

BTW pořád nevidím ani slovo o těch příšernostech v kódu Linuxu. Ještě máte šupiny na očích a trváte na tom, že Linux spoléhá na standardy?

Věřte nebo ne, pro ty zákazníky je poměrně důležité, jestli jim boot liveCD brickne nebo nebrickne počítač. Kdyby autor driveru jak říkáte "spoléhal na standardy", nic takového by se nestalo. Kdyby používal nedokumentovaný interface BIOSu při bootu z BIOSu a ne z UEFI, také by se to nestalo. Kdyby se driver používal jen na HW pro který je určený, a byl na tom HW testovaný, také by se to nestalo. Jinými slovy tady byla porušena spousta základních pravidel.

Dokumentovaný interface buď neexistuje, nebo to bude něco přes ACPI. Autor kódu údajně dostal popis interního interface od někoho ze Samsungu, a to nejspíš pro úplně jiný model HW. Samozřejmě se ten interface dá použít jen v klasickém BIOS mode, nikoliv při UEFI bootu. Autor dokonce testoval, jestli se bootuje přes UEFI. Jenže funkce efi_enabled vracela něco úplně jiného. Jak vidíte, jde o špinavý hack, navíc jedna chyba za druhou.
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=83e68189745ad931c2afd45d8ee3303929233e7f

Pro detekci typu ATAPI zařízení se používá IDENTIFY PACKET DEVICE, nejspíš word 0. Pro komunikaci se zařízením se obecně používají příkazy které mají pro to zařízení popsané chování. Detekce typu zařízení vyzkoušením příkazu, který dané zařízení nepodporuje, je hrubě špatně. Výrobci HW musí někam umístit interní funkce, protože je standard nijak nepopisuje, a vy se do nich můžete při troše štěstí strefit. Těžko můžete třeba na SCSI sběrnici detekovat scanner tak, že každému zařízení - včetně HDD a optických mechanik - zkusíte zapnout lampu skeneru, a budete koukat jestli/jakou chybu to vrátí. Pokud to uděláte, dost možná se strefíte právě do upgradu firmware, nebo jiné nedokumentované funkce zařízení jiného typu. A když zkusíte třeba detekovat grafickou kartu nVidia tak že zkusíte zapsat do nějakého jejího registru, o kterém nevíte ani jestli na cílové adrese je, natož co to udělá (protože nevíte jestli tam máte kartu nVidia), možná místo úspěšné detekce grafické karty v dojde třeba k roztavení reaktoru :), protože jste hrábnul někam úplně špatně.

Dost mě překvapuje, že vám tohle není jasné.

Bug u Samsungu nepopírám. Co zdůrazňuji je ta sada špinavých hacků a chyb, které s sebou Linuxu naprosto prokazatelně vleče. Což je fakt, který vy s klidem přehlížíte.

Jenže tenhle příkaz na CD-ROM mechanikách definovaný není, a Linux ho používal, což je hrubá chyba. Zkoušet použít na CD-ROMu příkaz pro CD-RW, který mechanika nemá podporovat, je v principu totéž jako zkoušet rozsvítit lampu skeneru na pevném disku.

To jste dost špatně četl:
http://www.root.cz/zpravicky/ubuntu-uzavrelo-bug-cislo-1/459158/
http://www.root.cz/zpravicky/ubuntu-uzavrelo-bug-cislo-1/459242/
http://www.root.cz/zpravicky/ubuntu-uzavrelo-bug-cislo-1/459328/

Nicméně zatím co u Samsungu je to jeden bug, tak u Linuxu to ukazuje na sérii těžko omluvitelných selhání, o kterých jsem už psal.

Ano, už jsem také psal, že výběr toho příkazu pro update firmwaru sice nebyl nic proti ničemu, ale byl poněkud nešťastný. Nicméně rozeznávat mezi CD-R a CD-RW tímto způsobem, a navíc na zařízení které není CD-R ani CD-RW, je veliká prasárna.

Jinak abych udržel diskusi konstruktivní: s komentářem "Kristova noho, to snad neni mozny!" naprosto souhlasím :D

Jestli to je reakce na mě (asi jo), tak ta moje poznámka byla míněna jako vysvětlení mé argumentace, ne že se ti snažím něco podsouvat. Tohle nemám zapotřebí, na to jsou tu jiní experti :-)