Já bych poukázal ještě na jednu věc: absence driverů pro Linux často ukazuje na budoucí problémy i s windows. Už jsem vyhazoval spoustu fungujících a jen pár let starých tiskáren, scannerů a občas i jiných zařízení, které fungovaly v kanceláři o pěti lidech dobře, dokud měli všichni XP, ale přestaly vyhovovat, když se koupil vedoucímu nový počítač s novými Windows a drivery nejsou.
Tohle je věc, kterou jsem na podpoře uživatelů nenáviděl: "Jsi tady placený od toho, aby to fungovalo, tak se starej a když to neumíš rozchodit ty, tak někomu zavolej."
Takže moje doporučení: Dívejte se po podpoře Linuxu i u zařízení, která k Linuxu připojená nebudou. Zvyšuje to pravděpodobnost, že se zařízení vyhodí, až když se rozpadne. Za poškrábané sklo na scanneru nebo strhané plastové kolečka v tiskárně se po vás nikdo vozit nebude. Odnesou to imaginární "oni": "Jak mohou chtít za opravu plastového kolečka za pětikačku víc, než za novou tiskárnu?!"
A proc M$ neni schopen zaridit, aby ten ovladac fungoval dal? Proc nekterej HW na widlich nefunguje "z principu"? Konkretne? Trebas na win vista+ nerozchodis gameport. Reknes, ze to je historie, ze dneska je kazdej joy/volant/... do USB? Nj, pravda, ale MIDI port == gameport. Tudiz pokud mas (i trebas nakladnejsi) vybavu na muzicirovani v podobe nejakych klaves/bicich/... tak si musis zase porizovat extra krabici s prevodnikama, a to presto, ze to tvuj HW vlastne umi.
Apropos ... " pokud je ovladac v jadre, tak tam bude tak dlouho, dokud to bude nekdo pouzivat." ... lol.
Ani nahodou, bude tam jen tak dlouho, dokud se nekomu neznelibi. Klidne se vyrazujou zcela funkcni moduly s tim, ze "je nikdo neudrzuje" - proc by mel, kdyz to proste funguje. Ostatne, vali se mi doma v supleti karta, kterou uz hodne dlouho nepouzivam a asi ani nikdy nebudu, ale i v dobe, kdy sem ji jeste pouzival, sem kvuli ni musel mit kernel 2.4, protoze v 2.6 uz prislusna funcionalita nebyla. Bylo to totiz prohlaseno za "hnusny hack" - uplne stejne jako podpora fakeraid 5 (od 2.6.18+). Co na tom ze to nekdo pouziva ...
Drivery ve Windows jsou obecně použitelné i na novějších verzích systému, protože základní interface se nemění. Ale:
- Na 64-bitových systémech nelze použít 32-bitové drivery.
- Občas se mění driver model. Například Windows 2000 proti NT zavedly driver sběrnice USB, a driver konkrétního zařízení se musel navázat na něj, což driver psaný pro NT4 pochopitelně neuměl. Podobně se měnilo třeba rozhraní pro implementaci firewallu, rozhraní pro power management zařízení atd. Proto někdy starší drivery fungují, ale jindy je o prostě technicky nelze použít. Nicméně životní cyklus Windows je tak dlouhý, že by to nemělo představovat problém.
Blbe googlis ... hledej raid45 module (ten jaksi neni, a s raid456 kterej jaksi je ... se to samo nebavi, pro par vyssich kernelu se jeste da splasit patch, ale pro ty soucasny bys ho uz musel celej prekopat)
Karta byla wifina na preskocich. Vic takhle zhlavy nedam, musel bych ji vyhrabat.
Zrovna ty drivery tiskáren nejsou takový problém, protože jde zpravidla o knihovny parametrů k univerzálnímu PCL driveru od Microsoftu. U scannerů je to pravda horší - k jednomu z těch mých jsem našel na webu výrobce jen oficiálně nepodporovaný driver (naštěstí funguje, a nemá tunu bloatwaru).
Otázka: jak zjistíte podporu HW na Linuxu? Pokud jsem si všiml, tak různá distra (a v různých verzích) podporují různý HW. Existují sice různé DB zkušeností uživatelů, ale ty nejsou výsledkem žádného metodického testování. Prostě Franta doma zjistil, že mu řekněme WiFi karta funguje. Ovšem už neví, že při připojování k AP počítač vždy na chvíli vytuhne, že občas díky driveru zmrzne celý poč, a že nefunguje WPA2. Plus že distra X a Y nemají funkční GUI pro nastavení toho WiFi, takže se člověk musí hrabat v konfiguráku.
"jak zjistíte podporu HW na Linuxu?"
Pro ty wifi karty treba tady:
http://en.wikipedia.org/wiki/Comparison_of_open_source_wireless_drivers
Ty popisovane problemy se predpokladam tykaly uzavrenych ovladacu.
Popisované problémy se týkaly driveru MadWifi. Ale to není podstatné. Podstatné je to, že se na Linuxu používají převážně generické drivery psané podle dokumentace (případně pomocí reverse engineeringu), často používají různé nedokumentované postupy a špinavé hacky, a většinou nebyly testované na cílovém HW. Výsledky pak mohou být velmi zajímavé:
http://www.root.cz/zpravicky/nektere-nove-notebooky-od-samsungu-nepreziji-instalaci-linuxu/
1) HW, který lze zničit softwarovou chybou, si nic jiného nezaslouží.
2) Ve zprávičce je napsáno:
"Kód původně pochází od Samsungu"
a dále
"Samsung ani v době, kdy už byl opravný patch k dispozici, nezahrnul opravu v aktualizacích některých jeho zařízení"
Takže ten HW neničí linux, ale sám jeho výrobce.
SW chybou se dá zničit spusta věcí. Kód driveru údajně pocházel od Samsungu, ale vztahoval se k úplně jiné verzi HW, používal nedokumentovnaý interface, a pracoval s pamětí BIOSu, nikoliv s UEFI. Jinými slovy driver byl určený pro jiný HW, jiný firmware, a nebyl vůbec testovaný na cílovém HW. Samozřejmě jinak je v tom Tux naprosto nevinně :D
1) Flash firmware může být přerušen i u zcela normálního procesu jeho update. Některý HW s tímto počítá a proto má jednak zálohu firmware a také má další failsafe mód v případě zničení obou kopií.
Tedy, pokud výrobce počítá s tím, že flash firmware nemusí projít, tak se sw chybou nedá zničit.
2) Přenastavit časování paměti a dalších parametrů má jít pouze na validní hodnoty. Pokud ne, opět to vypovídá o kvalitách výrobce SW.
"Většinou se HW nezničí, ale pro laického uživatele zůstane nepoužitelný."
Aha, takže vlákno začalo tím, jak tux ničí hw, nakonec to nebyl tux ale sám výrobce a nakonec ten hw vlastně není zničen. Zajímavý myšlenkový postup.
1. Aha. A proto při každém flashi zařízení vidím varování, že flash nemám přerušovat, protože jinak může dojít k poškození zařízení. Na desktopu mám náhodou desku se záložním BIOSem, ale to je velká výjimka.
2. Zkuste si otevřít pokročilá nastavení BIOSu, a tam například změnit napájecí napětí pamětí na příliš nízké nebo vysoké. Klidně to můžete udělat. V prvním případě vám stroj asi nenajede, v druhém případě bych čekal, že ty paměti navíc můžete po nějaké době usmažit.
Tomu "zničení HW" se říká "to brick (something)". Bohužel neznám žádný dobrý český překlad. Jinak oba výše popsané příklady nejsou o tom, že HW může poškodit výrobce, ale o tom, že ho obecně může poškodit špatně napsaný SW.
1) Takových varování jsou všude tuny a ano, je zajisté lepší, pokud potenciálně nebezpečená operace proběhne za ideálních podmínek, než aby došlo na poslední záchranou síť.
2) V prvním případě vám stroj asi nenajede, v druhém případě bych čekal, že ty paměti navíc můžete po nějaké době usmažit.
Není pravda. Pokud nastavení neumožní běh cpu, tak ho bios vrátí do defaultu.
"Jinak oba výše popsané příklady nejsou o tom, že HW může poškodit výrobce, ale o tom, že ho obecně může poškodit špatně napsaný SW."
Opakuji, HW, který lze poškodit softwarovou chybou si nic lepšího nezaslouží. Nevím, jestli o tom víte, ale dnešní CPU mohou běžet i bez chladiče. Ne, že by se to doporučovalo nebo dělalo, ale i chladič může selhat a moderní procesory při vysoké teplotě umí toho udělat hodně, od podtaktování, snížení napětí, vypnutí části cpu až po nějaké ty suspend stavy. Ten procesor se prostě zničit nenechá.
Ad usmažené paměti a zcela off topic:
Víte jaký je (mimo jiné) rozdíl v deskách pro desktop a pro servery? Desky pro desktop mají paměti umístěné tak, aby bránily proudění vzduchu (jednak kolem pamětí ale i kolem cpu). Zatímco serverové desky je mají tak, že vzduch kolem nich proudí, chladí ram i cpu. I takové klacíky hází výrobci HW pod nohy. A to nemluvím o (ne)povolených technologiích v CPU jistého výrobce.
Flash firware muze zpusobit, ze bude HW nefunkcni, ale nemuze zpusobit zniceni HW. Neni pak nic snazsiho nez pripojit programator a flash opakovat.
Zmena casovani pameti nemuze pamet znicit, maximalne bude pamet nestabilni a bude vykazovat provozni chyby.
Pokud je moznost neco flashovat soucasti uzivatelskeho rozhrani (=vsechny PC MB trebas), tak je i nepovedeny flash a nestartujici deska ciste vina vyrobce, kterej to zmrvil.
LOL. Jak budete připojovat programátor například k základní desce, síťové kartě nebo kabelovému modemu? V některých případech můžete vyloupnout čip a vrazit ho do externího programátoru (a pak shánět naprogramovaný chip z jiného kusu stejného HW). Ve většině případů ten chip ale najdete připájený na desce, samozřejmě technologií SMT, takže ho nedostanete ven bez poškození spousty věcí kolem.
Fakta jsou taková, že HW lze těžce ublížit pomocí SW. Může se vám to nelíbit, ale to je tak všechno, co s tím můžete dělat. Podstata diskuse ale byla v něčem jiném. Pokud SW neúmyslně ten HW zničí, protože s ním provádí něco co nemá provádět, tak je zjevně *SW* vadný.
Ještě zjednodušené přirovnání. Pokud lze flashnout firmware telefonu náhodnou binárkou a tím ho odstavit, můžete klidně tvrdit, že je to chyba telefonu. Pokud vám ale takhle díky nějakému bugu odpraví telefon instalace Tetrisu nebo launcheru na telefonu s Androidem, těžko budete tvrdit, že je ten Tetris nebo launcher v pořádku.
V dnešní době se používá technologie ISP (In System Programming) - vetšina čipů ho podporuje.
Je to řešeno tak, že na desce jsou vyvedeny headery (piny, kontaktní plošky), ke kterým se připojí programátor (JTAG nebo novější SWD, používá se i UART aj.).
Programovaní čipů přímo v zařízení je levnější pro výrobce, nemusí čipy nejdřív programovat a pak osazovat, ale rovnou se na lince vyrobí celé zařízení, které se pak jednoduše naprogramuje a otestuje. Eliminací zbytečných kroků se výroba zlevní a chybovost při výrobě se sníží. Navíc výrobce dál může vyvíjet a upravovat firmware pro zařízení i při/po jeho výrobě bez nutnosti mít prototyp. Čili další eliminace zbytečné redundance.
Proto programovací kontakty najdeme dnes skoro ve všem.
Doba kdy bylo potřeba čip vyndat a strčit ho do programátoru skončila někdy koncem minulého století.
Jinak samozřejmě souhlasím s tím, že hardware který se nechá odpálit uživatelským softwarem si nic jiného nezaslouží.
Původně byla řeč o noteboocích Samsung, které bylo možné odstavit zabootováním Linuxu. Na vině byl kernelový modul, který nebyl testovaný s cílovým HW, používá nedokumentovaný interface BIOSu (který kdysi fungoval někomu na nějakém předpotopním Samsungu), a díky bordelu v kernelu byl aktivovaný i při UEFI bootu. Ten kód nenapsal Samsung.
Podobně v případě odstavení CD-ROM mechanik nepsal kód ATA driveru výrobce LG. Autoři kernelu si usmysleli, že budou rozeznávat CD-ROM a CD-R mechaniky tak, že pošlou požadavek na zápis, a pokud to nevyhodí chybu, tak je to CD-R mechanika. Je to prasárna, protože detekce měla být prováděna standardně přes capability bits.
Podobně ničení síťových karet Intel e1000e nebylo způsobené kódem výrobce. Příčinou byl ftrace, který nebezpečně implementoval modifikaci živého kódu, a špatně koukal, kam zapisuje.
Jde o tři případy poškození HW různými bugy Linuxu. Otázkou je, kolik podobných špinavých hacků, nesprávných předpokladů, netestování driverů s cílovým HW a nesprávných zápisů do paměti zařízení v kódu Linuxu vyhnívá, a jenom šťastnou náhodou nezpůsobily zrovna k poškození HW.
ATA nedefinuje chování CD-ROM mechaniky v odpovědi na příkaz k zápisu. Driver CD-ROM mechanice takový příkaz vůbec nemá poslat, natož aby ho používal jako způsob detekce typu zařízení. Jenže jde o Linux, takže autoři driveru použili špinavý hack - a dopadlo to špatně.
Volba příkazu pro flash firmware byla možná nešťastná. ATA samozřejmě nepopisuje příkaz pro flash firmwaru, a výrobce ho nějak implementovat musí. Otázkou je, jestli daný příkaz vybrali před standardizací příkazů pro práci s CD-R, nebo až po ní. Každopádně to ake nic nemění na tom, že ten driver byl zprasený, a díky tomu došlo k odstavení HW.
A opět tu máme názor experta :). Pokud hovoříme o té samé věci, tak poškození karet s driverem e1000e způsobovala zmršená implementace ftrace. Byla použitá nebezpečná technika modifikace živého kódu, a navíc díky budu docházelo k modifikaci paměti na nesprávném místě. Otázkou je, kolik podobných problémů v kernelu Linuxu vyhnívá, a jen shodou okolností nepoškodily žádný HW.
http://lwn.net/Articles/304105/
Jinak děkuji za technologický update. Problém je v tom, že když uživateli SW například omylem přepíše firmware, tak je pro něj zařízení nepoužitelné, a musí do servisu. Jestli servis vymění board, vyjme čip a přeprogramuje ho, nebo zařízení rozebere a připojí externí programátor, to je už v podstatě detail.
Navíc HW lze zničit i řadou dalších postupů. Například řadu CTR monitorů bylo možné odpálit nastavením nesprávných obnovovacích frekvencí. U HDD zcela jistě snížíte životnost non-stop seekováním, a s "vhodným" firmwarem jistě nebude problém opakovaně zaparkovat hlavy na médiu a tím ho poškodit. Robot na pásky nebo optická média jistě vhodným SW opotřebujete, v řadě případů i rychle mechanicky poškodíte - například umlátíte rameno o zarážku. Podobně u skenerů. Dále můžete různé komponenty uvařit manipulací s chlazením, případně v kombinaci s vytížením nějaké části čipu, zvýšením napětí apod.
jj, nekompatibilita win driverů, to jsem přesně dnes řešil, když jsem se snažil ve škole rozchodit jeden mikroskop. Spustil jsem instalaci na win (sp3) a jen mi to vyhodilo chybu s tím, že před instalací driverů je nutné systém zaktualizovat na sp2. Tiskárny jsou docela v pohodě, ale u vědeckého vybavení za pár mega je to jiný kafe.
Mám opačnou zkušenost. Měl jsem print server od nejmenované východní firmy, psali na tom, že podporuje CUPS a že jde použít v tučňákem. Tak jsem to hodil ke svojí SX110 od Epsona. Výsledek? Konfigurace proprietálním softem jenm z widlí a pro podporu CUPS zašedlý check box, takže nešla zapnoout. A tučňák to neviděl. Při hlubším bádání to furt lhalo, že tiskárna nepodporuje tamto či ono... A největší sranda, po píchnutí tiskárny do NTB s Fedorou všechno jelo - tisk i skenování. A ani to nehledalo ovladače. Tak holt chodím "pro papíry" o chvíli dřív a s noťasem a OvisLink jsem si zařadil po bok ZyXelu - nesmí mě do baráku.