Názory k článku
Některé nové notebooky od Samsungu nepřežijí instalaci Linuxu
-
Lael Ophir (neregistrovaný)
Vidím že je tu po mě poptávka :). Dnes není tak velký problém dát dohromady OS, který bude kompilovat, a dokonce bootovat. Problém je v tom obrovském rozsahu HW, na kterém musí běžet. Komunitní tvorba SW bohužel nemá klasické QA, takže je výsledek vždycky sázkou do loterie. Drivery se píšou podle specifikací chipsetů a metodou reverse engineeringu, a často bez testování na HW, na kterém nakonec běží. Někdy to zafunguje, a někdy prostě ne. Zastánci open source vždycky tvrdí, že mají ten SW zdarma, a testováním SW je právě jeho používání. V tomto případě to "trochu" nevyšlo.
Zajímavé komentáře na LaunchPadu:
https://bugs.launchpad.net/ubuntu-cdimage/+bug/1040557?comments=all
#55 José popisuje popisuje, jak svůj Linuxem bricknutý notebook reklamoval s tím, že mu ho rozbil Windows Update :)
#83 Použití efibootmgr přepisuje položku pro vstup do BIOS Setupu.Zajímavý je i komentář autora kódu:
https://plus.google.com/111049168280159033135/posts/h7FjkQKZHKTDalší podobné problémy:
- lm-sensors během detekce zařízení prováděly zápis do jejich NVRAM. Výsledkem byla CRC chyba NVRAM, díky které ThinkPady nebootovaly.
http://www.lm-sensors.org/browser/lm-sensors/branches/lm-sensors-2.10/README.thinkpad
- Chyba v ftrace vedla k nechtěnému zápisu do paměti karet Intel e1000e, což je odstavilo.
https://lwn.net/Articles/304105/Z krátkodobého hlediska je řešení jasné: nepoužívat modul samsung-laptop. Zřejmě se ukáže, že kód (opět) zapisuje do VNRAM, kam zapisovat nemá. Z dlouhodobého hlediska to ale vypadá, že vývoj Linuxu jako platformy má problém. OS se nedá vyvíjet stylem "kompiluje to, dokonce to běhá na mém HW, tak to musí být OK". OS nemůže být sada špinavých hacků. Drivery je potřeba psát pro specifická zařízení, dát dohromady testovací framework, certifikovat HW, komunikovat s výrobci. Jenže to znamená spoustu práce. Je to jako rozdíl mezi smontováním motoru s podvozkem v garáži, a výrobou moderního automobilu, který chrání posádku, zastaví sám před překážkou atd. Ale kdo to celé úsilí vedoucí k profesionalizaci Linuxu zaplatí, když koncoví uživatelé mají distra zadarmo?
-
oxymoron (neregistrovaný)
A v čem ten problém vývoje Linuxu jako platformy tkví? Ono, pokud hardware obsahuje nějaké nedokumentované vlastnosti, tak se pro něj vyvíjí cokoliv také těžko, neboť nikdo nemůže zaručit, že nedojde díky nějaké chybě k vyvolání té nedokumentované vlastnosti.
Kdo to zaplatí? No, jestli jsi si nevšiml, tak existuje několik společností zabývající se Linuxem, které z Linuxu prosperují. Čili, pokud tyto firmy vydělávají i přesto, že mají koncoví uživatelé distra zdarma, znamená to, že existují i finance na úsilí k profesionalizaci Linuxu.
-
Lael Ophir (neregistrovaný)
Pokud například v NVRAM nastavíte špatné časování pamětí, můžete lehko stroj odstavit. Notebook pak v lepším případě musíte rozebrat, abyste zresetoval CMOS. V horším případě máte smůlu. Obecně když jde něco nastavit se SW, může to nastavit i driver.
Řešení je myslím zjevné. Používat dokumentovaný interface, a ne dělat se zařízeními psí kusy s nadějí že si to nějak sedne. I když nějaký nedokumentovaný interface funguje na jednom modelu HW, na jiném může způsobit nejrůznější problémy, nebo ho bricknout. Taková funkcionalita prostě musí být vázaná na konkrétní model HW. Jinak můžete provést místo dotazu zápis, přepsat něco úplně jiného než zamýšlíte apod. Pochopitelně je dobré mít dokumentaci, a *samozřejmě* je nezbytné testovat s konkrétními modely HW.
A proč by třeba Red Hat, který prodává primárně SW pro *servery* s poměrně dobře popsaným HW, měl platit testování té přehršle modelů nového spotřebitelského HW, která každý rok vychází? Z funkčního řízení otáček ventilátorů nebo fungující hibernace na nějakém notebooku neplatícího zákazníka nemá RH vůbec nic. Fedora je pro ně beta testem jejich technologií, kterou uživatelé provedou zdarma, a při troše štěstí i zdarma napíšou něco, co se pak dá prodat za peníze.
-
Lael Ophir (neregistrovaný)
Drivery může psát výrobce OS, a MS si je velmi dlouho psal skoro sám. Samozřejmě je mohou psát i výrobci HW. Jenže když jde o Linux, tak s tím mají spoustu problémů:
- Tisíce dister a časté nové verze. To prodražuje testování, a při 1% uživatelů se to prostě nevrátí.
- Chybějící ABI, tedy nutnost překladu pro konkrétní build kernelu. To hází výrobcům klacky pod nohy.
- Podle autorů kernelu je třeba drivery, coby odvozená díla, uvolňovat pod GPL. To výrobci z více důvodů nechtějí.
- Chaos ve vývoji platformy. Například USB stack byl několikrát přepisovaný. Obecně se vývojáři driverů mění zdroják pod rukama. To zvyšuje náklady.
- Absence firemní politiky - žádné pevné procedury, žádné smlouvy, nulová vymahatelnost závazků. Firemní sféra prostě funguje jinak než linuxová komunita.
- Problematická podpora uživatelů velkého počtu dister a jejich verzí.
- Špatná podpora výrobcům HW. Komerční OS budují infrastrukturu pro vývojáře (architekturu driverů), mají kvalitní dokumentaci, příklady a tutoriály, nástroje pro testování atd. Linus umí na výrobce leda zdvihnout prostředník, přestože tahá za kratší konec provazu.Navíc když necháte výrobce HW bez dozoru napsat driver (i pro Windows), často spatlají zabugovanou příšernost. MS to řeší certifikačním programem, který pro něj má náklady. Výrobci zase vědí, že HW bez certifikace je špatně prodejný, takže se snaží.
-
ATI se s tím poprala tak, že vydává drivery pro některé distribuce. Dá nějaký blob a k tomu trošku kódu, který se proti tomu blobu zkompiluje a slinkuje. Není problém s tisíci dister, není problém s ABI a není problém s GPL.
A jak je to v menšinových distribucích (Gentoo, Archlinux)? Balíčkátoři to přebalí a ATI se o to nestará.
-
Lael Ophir (neregistrovaný)
ATI se s tím pere tak, že podporuje dvě komerční distra (RHEL a SLES). Pak ATI opravdu nemá problém s tisíci dister; problém mají jejich uživatelé. Trable s GPL zůstává, protože podle autorů kernelu jsou například i drivery nVidia odvozeným dílem, a jsou pouze tolerovány. Pánům totiž asi došlo, že když budou tlačit moc, tak budou bez grafických driverů.
-
muf (neregistrovaný)
Byl jste na školení?
Je hned vidět to nabuzení a čerstvé síly....Asi by bylo zbytečné tady vyjmenovávat problémy, které jsme museli v různých firmách řešit třeba s "kvalitními" ovladači pro Windows. Ne, ty nebyly vyvíjené komunitně. Zmatlal je často nějaký "otrok" v Indii, který snad originální hardware ani nikdy neviděl.
Fakt mě nemusíte poučovat o tom, jak "kvalitně" dnes probíhá tolik módní nízkonákladový vývoj. Zlatá komunita plná zapálených lidí... -
Lael Ophir (neregistrovaný)
Mějme binární driver a warpper, který ho lepí ke kernelu. Ten wrapper je odvozeným dílem kernelu, tedy musí být pod GPL. Ten binární modul by také měl být pod GPL, protože linkuje GPL wrapper. Takhle to opakovaně a nahlas tvrdili autoři kernelu. A to do té doby, než jim došlo, že místo uvolnění driveru pod GPL dosáhnou spíš stažení toho driveru (což by při tehdejší absenci alternativního nVidia ovladače byla katastrofa). Pak to začali "tolerovat".
-
Duff (neregistrovaný)
Počty dister? Od toho je ten Linux (jádro). Více méně stejné na všech distribucích a architekturách.
To, že jsou někteří výrobci hw hovada, co neposkytují dokumentaci komunikačního rozhraní, aby ty ovladače mohl někdo napsat, když to neudělá výrobce, nebo se nedrží zavedených standardů není problém vytvořený Linuxem, ale linuxoví vývojáři to potom musí řešit různě a někdy i těmi hnusnými hacky. -
Lael Ophir (neregistrovaný)
To myslíte vážně? Neexistuje stabilní ABI, distra se liší verzí kernelu, použitým překladačem, konfiguračními volbami kernelu, dodatečnými moduly a servisními aplikacemi, startovacími skripty, konfigurací (/dev/hda3 vs /dev/sda3), a kdo ví čím ještě. Fakt se vám nikdy nestala příhoda toho typu, že na jednom distru naběhne zvukovka sama od sebe a WiFi není vidět, a po instalaci jiného distra funguje WiFi, ale není vidět zvukovka? :)
Například v případě ničení karet Intel e1000 šlo o hrubou programátorskou chybu autorů ftrace, což jsem už linkoval, a s dokumentací to nesouviselo.
Na případu lm_sensors je vidět, jak to nefunguje. Lm_sensors mají získat označení modelu zařízení, podle něj z interní databáze vytáhnout ověřenou konfiguraci senzorů daného zařízení, a s těmi komunikovat. Tu DB můžete získat od výrobců, vlastní silou, od dobrovolníků - to nehraje roli. Je ale naprosto špatně, když nevíte nic o modelu ani jeho senzorech, a začnete střílet na slepo. Při troše smůly totiž sestřelíte celý ThinkPad, nebo způsobíte jiné trable.Výrobci samozřejmě mohou poskytnout dokumentaci nebo drivery, ale většinou to udělají, jen pokud se jim to nějak zaplatí. Navíc i když je dokumentace k dispozici, dopadá implementace mnohdy tak šíleně, jako v případě MadWifi, lm_sensors apod.
Zkusme si přirovnání. Při psaní driveru tiskárny pro Windows, prostudujete dokumentaci, implementuje vše potřebné, důkladně vyzkoušíte driver i jeho kompatibilitu v pár aplikacích, a výsledný driver se bude používat jen pro daný model tiskárny.
Když jde o Linux, spíchnete se řekněme generický PCL driver, a nějak to funguje. Bohužel jste mnohé modely tiskáren nikdy neviděl a nic o nich nevíte. Když vám přijdou stížnosti, že u jistého typu tiskárny není vidět třetí zásobník papíru, dopíše do driveru auto-detekci, která vám doma funguje. Bohužel na té cílové tiskárně driver místo toho třeba adresuje výběr výstupního zásobníku a sešívačku papírů. V horším případě zvýší zapékací teplotu a vznikne požár. -
retard (neregistrovaný)
Ten o tlaciariach bol pekny. Nefunguje instalacie ovladacov, padajuci spooler, nefungujuce presmerovanie tlace pri RDP (matchovanie strigov mohol fakt vymysliet len nafetovany dusevny mrzak v Microsofte), zbastlene 500 mb nefungujuce hrozy zasierajuce cely system. Fakt skvely priklad. :D
-
multi (neregistrovaný)
vyrobci HW maji nekolik moznosti:
-poskytnout dokumentaci
-poskytnou hw
-zamestnat vyvojare linuxu
-napsat ovladac sami a pak ho dat komunite k dispozici a ona se uz postara
a dalsi...kolik vyrobcu to vyuziva a jak?
asi jen parkdyz si vemete kolik usili nekteri vlozi do reverzniho inzenyrstvi, tak mit podporu vyrobcu, tak se ti lide mohou zabyvat uplne necim jinym
ostane na windows to taky neni zazrak, tam je jen rozdil v tom, ze se to s windous vyzkousi a kdyz zjisti, ze ten HW zprasili, tak udelaj nejakou zaplatu do ovladace, pritom kdyby ten hw dodrzel standarty, tak by fungoval bez problemu a vsude
-
Lael Ophir (neregistrovaný)
Výrobcům se hlavně podpora Linuxu finančně nevyplatí. Dokumentaci by možná dali, ale pod NDA, které nechtějí vývojáři podepisovat. Zaměstnat vývojáře Linuxu není tak triviální, protože mají i svou práci, a vy od nich potřebujete podepsat NDA, dostat záruky (implementace podpory nového modelu zařízení do X dní), poskytovat support, dělat údržbu kódu (protože zdroják kernelu se vývojáři mění pod rukama) atd. Proč všechno to úsilí? Abyste nakonec měl nabídku počítačů s Linuxem, které prakticky nikdo nekoupí?
V oblasti HW existuje standardů minimum (když mluvíte o standartách, tam je to jiné, ale vlajka HW moc nepomůže). Existují spíše obvyklé a méně obvyklé postupy.
-
Tak zejména výrobcům pevných disků a CPU se podpora Linuxu vyplatí hodně, protože téměř 100% internetových serverů dnes už tak či onak jede na Linuxu :-)
Dá se tedy debatovat, že "výrobcům desktopových PC a notebooků se podpora Linuxu finančně nevyplatí". Zde je to opravdu složité - protože pochopitelně jsou ve hře jednoznačné ekonomické tlaky, které výrobcům velí mít pod kontrolou inovační cyklus - a řídit tempo zastarávání (např. starých grafických karet, driverů a jejich ovladačů).
Základní problém je (už snad od začátku) v tom, že "výrobcům grafických karet se nevyplatí podporovat standardizaci" - standardizace by je nutila do daleko větší vzájemné konkurence, protože by jejich výrobky byly plně nahraditelné mezi sebou. Není to tedy otázka podpory Linuxu nebo jiného OS: je to otázka "ochoty být kompatibilní".
Linux reprezentuje v podstatě koncovými uživateli hardware tlak na standardizaci a kompatibilitu. Konečným důsledkem takovéto standardizace by byl vzájemný konkurenční boj mezi výrobci, stlačující ceny naprosto k nule. Pochopitelně: výrobci mají zájem na pravém opaku - a sice kontrolovat, jakou bude mít výrobek životnost faktickou i "mravní", jak dlouho bude kompatibilní, za jak dlouho si zákazník bude muset koupit náhradu, apod.
To, že Linux nehájí zájmy výrobců ještě neznamená, že naprosto legitimně nehájí zájmy spotřebitelů/uživatelů: celá debata je o tom, jestli bylo dřív vejce nebo slepice: jestli uživatelé jsou tu kvůli výrobcům, nebo výrobci kvůli uživatelům, jestli tu ještě máme volný trh - nebo jestli je výroba hardwaru prostě o tom, co nadiktujeme uživatelům, že mají dělat... (je to asi podobné, jako když díky postupné monopolizaci těžkého průmysl tenhle dorostl do velikosti, že nejvýhodnější pro něj bylo vyrýbět za státní peníze ničivé zbraně... mluvím o trendu, který se naplno rozjel na konci 19. století...)
-
Duff (neregistrovaný)
Jen ve krátkosti:
HP linuxové certifikace
http://h71028.www7.hp.com/enterprise/cache/569891-0-0-0-121.html
http://h18004.www1.hp.com/products/servers/linux/hplinuxcert.htmlJeště nějaké připomínky?
-
Lael Ophir (neregistrovaný)
Skvělé, takhle to má vypadat. Když uživatel notebooku zaplatí USD 50 ročně (tj. víc než uživatel Windows), najednou to jde. Certifikační kit, spolupráce mezi autorem distra a výrobcem HW, testování... To je ta síla peněz :)
Má to ale jisté mouchy:
- Žádný z těch modelů EliteBook, ProBook a Mini z linkované stránky už není v prodeji.
- Certifikace se týká pouze produktu SuSE Linux Enterprise Desktop. Distra se bohužel liší verzí kernelu, konfigurací, výběrem zahrnutých patchů a modulů, tahají si různé systémové aplikace atd. Proto je vypovídací hodnota pro uživatele jiných dister nízká až nulová. -
Duff (neregistrovaný)
To byla ukázka, na které šlo prokliknout na jiná distra a novější modely v prodeji.
Mezi patchemi jádra, které nepatři do vanilla, budou převládat backpory, nebo se spláchnou zpět do vanilla až bude začleňovací okno.
Pokud bude fungonvt jedna distribuce dost možná budou fungovat i jiné a novější verze.
50 dolarů je cca 1000 kč. To je víc, než za licenci Windows? Jen do oem licence se ta částka vleze minimálně 3x a zahrnuje veškerou podporu. A v tom může člověk přecházet na novější verze. Nebo si nainstalovat neplacenou verzi (SLES -> OpenSuse, RHEL -> Fedora atd). -
Lael Ophir (neregistrovaný)
Samozřejmě Novell YES Bulletin jsem našel. A našel jsem na něm také gigabitové karty od Intelu, které ničila chyba v ftrace. Na SLED to tedy asi nebyl problém. Mezi distry jsou prostě rozdíly.
Mezi patchi můžete najít experimentální FS, nejrůznější drivery atd. A mezi konfiguračními volbami kernelu najdete například CONFIG_PREEMPT, který vám ze systému udělá něco dost odlišného. Zahrnutí nebo nezahrnutí lm_sensors do distra bylo zase svého času rozdílem mezi živým a bricknutým ThinkPadem. Takže ne, výsledky testování z jednoho distra nelze automaticky uplatňovat na jiné distro. "Dost možná" mohlo fungovat i Ubuntu na těch nových noteboocích značky Samsung. Zjevně "dost možná" nestačí.
Za Red Hat Enterprise Desktop zaplatíte 50 USD *ročně*, a je u toho poznámka Only available in self support. Windows koupíte jednou za 100 USD (v ceně systému i levněji), a můžete je používat mnoho let.
https://www.redhat.com/apps/store/desktop/Neplacené verze komerčních dister (OpenSuSE, Fedora) jsou beta verzí těch komerčních, a dost výrazně se liší (vizte výše o rozdílech mezi distry).
-
Pavel 'TIGER' Růžička (neregistrovaný)
Jenže dnes se stroje nežhaví, netestují, prostě se nasadí a problémy se budou řešit za provozu a to ještě jen po nějaký krátký čas, kdy je stroj v prodeji a možná i chvilku po tom. Výrobci se zbavují problémů a vše háží na zákazníka, koupil sis to, tak se starej!
-
Naopak, HW, ktery se da bricknout, se vydava dnes. Drive nic takoveho neexistovalo a zacalo to, kdyz se PROM BIOSu nahradilo prepsateknymi pametmi, ktere v lepsim pripade byly proti zapisu chraneni jumperem nebo polozkou v BIOSu, ale obvykle nicim. Pak se objevil CIH a bylo, nicmene vyrobcum to jeste nedoslo. Zkuste si bricknout i486. Takove mobo snad nikdy neexistovalo.
-
Tohle je ale o necem jinem. Tam slo o prekroceni specifikaci analogoveho zarizeni, kde to soucastky nestihaly a vydoutnaly. Neslo o pouziti nejake instrukce, ktera by byla poslana monitoru a ten zarval hlasem velikym, idealne za exploze obrazovky v oblaku jisker, jak v americkem filmu pro obzvlaste retardovane. Insrukce byla zadana pocitaci.
BTW, komunisticke kopie procesoru 8080 se pry daly odprazit preklapenim nejakeho priznakoveho bitu v cyklu, az se tranzistory upreklapely k smrti a zarvaly na prehrati.
-
Lael Ophir (neregistrovaný)
Například v tomhle případě v kurzu programování jistě učili, že je potřeba ověřovat návratové hodnoty volání.
http://www.root.cz/zpravicky/nektere-nove-notebooky-od-samsungu-nepreziji-instalaci-linuxu/447369/Navíc podobných problémů existuje dlouhá řada. Například:
Instalátor při dual bootové instalaci s Windows zapíše položky určené pro BIOS/mbr namísto UEFI/gpt, a tím odstaví bootování do Windows.
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1024383
Funkce efi_enabled() nevrací 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.
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=83e68189745ad931c2afd45d8ee3303929233e7f -
Lael Ophir (neregistrovaný)
Windows podporují bootování jiných verzí Windows, DOSu, a dají se samozřejmě přemluvit i k bootování dalších OS. Co by ale Windows měly podporovat? Tisíce dister, které vycházejí každých pár měsíců v nových verzích, a které se mění pod rukama jako plastelína? Není snad řádově snazší, aby těch tisíc dister podporovalo tři poslední verze Windows? A jak jsem linkoval, tak ani to občas nezvládnou :/
-
tomfi (neregistrovaný)
Mě napadá spíše že, když ty notebooky lze teoreticky po zaslání patřičného příkazu "zablokovat" a dostat do nepoužitelného stavu, jestli to není jenom nedokumentovaná bezpečnostní vlastnost toho HW.
Takovou věc, pokud není extrémně sofistikovaně implementovaná, se bude výrobce snažit skrýt (což by objasnilo i postoj Samsungu: "Nechte to být"). -
Karel (neregistrovaný)
To je cena za to, že už nemusíte měnit jumpery na deskách a flash BIOSu nemusíte provádět vyjmutím EPROM a absolvovnáním kolečka s UV lampou a programátorem. Někteří výrobci to ještě dnes řeší tím, že HW má vlastně všechno dvakrát (EEPROM, případně Flash) a má nějaké tlačítko, kterým se dá vnutit "boot do továrního nastavení". Jenže spotřebitelé tlačí na cenu a tak kolikrát na luxus "mám v tom BIOS/Firmware/OS dvakrát" nejsou prostředky. Takže naopak množství "bricknutelného" HW se rok od roku zvyšuje. Před 20 lety ho bylo minimum, vyjmutí baterky a následný reset CMOS obvykle stačil. A když zhavaroval flash BIOSu, tak se vyndala ta EEPROM a u někoho z IT kroužku nebo ve škole se nechala přepsat.
-
failer (neregistrovaný)
Pravděpodobná příčina a řešení: http://www.jakobheinemann.de/en/blog.html
První soud pro z takovéhoto důvodu zamítnutou reklamaci by Samsung jistě prohrál. -
Lael Ophir (neregistrovaný)
To vypadá spíš na problém se ztrácejícím se BIOS/EFI setup menu. Samsung sice odpoví chybnou na údajně validní dotaz, ale autor v kódu jaksi zapomněl ošetřit chybové stavy. Když nastane chyba, přesto pokračuje v modifikaci, což je velká chyba. Ale samozřejmě s klidem řekne, že za to může Samsung. Na co ošetřovat chyby? :/
-
Lael Ophir (neregistrovaný)
Toho jsem si v linku nevšiml. Zdroj?
Linkovaný článek rozebírá situaci, kdy po instalaci Linuxu na Samsungu nejde vstoupit do BIOS Setupu pomocí F2. U Samsungu EFI volání GetNextVariableName() selže, pokud velikost předaného bufferu není 128 bytů, což je dokumentované v EFI 1.0, ale nemělo by to být třeba u EFI 2.0. Bohužel modul efivars.c definuje délku názvu proměnné i hodnoty jako 1024 (struct efi_variable), což u Samsungu neprojde. Až sem to možná bude chyba Samsungu (pokud je specifikace opravdu jednoznačná). Funkce virt_efi_get_next_variable() z efi.c se chová správně, a vrátí chybu. Bohužel ale instalátor chybu neošetří; přitom by se měl zastavit a nahlásit chybu, pokud dostane cokoliv mimo EFI_SUCCESS (položka načtena) nebo EFI_NOT_FOUND (konec seznamu). Místo toho se instalátor chová, jako kdyby byla tabulka prázdná. Díky tomu pak s klidem přepíše položku zavaděče, která normálně implementuje BIOS Setup.
Takže čí je to vina? Samsung si od Phoenix Technologies koupil EFI Runtime Services, které činí nesprávný předpoklad u nějakého parametru (vychází chybně z EFI 1.0). Nicméně instalátor neošetřuje chyby, a po chybě naprosto nesprávně přebuší tabulku boot entries. Můj verdikt? Mohou za to obě strany, a autor instalátoru výrazně víc.
Co s tím? Takové věci se stávají odjakživa, a lze je vychytat jen při důkladném testování. To bohužel u Linuxu chybí. Při tom množství dister a tempu vydávání nových verzí se testuje špatně. Navíc když za distra uživatelé neplatí, nejsou na to peníze.
-
Mimochodem, toto je nevýhoda řízení chyb návratovou hodnotou. Při použití výjimek by se to mohlo stát jen při nedodržení transakčnosti.
Zastávám názor, že chyba, kterou programátor neošetřil, se mu má buď otlouct o hlavu při kompilaci (řízené výjimky), nebo při běhu ukončit program. Ne pokračovat dál. Podobné problémy mohou být i u setuid/setgid (např. RageAgainstTheCage pro Android).
-
Lael Ophir (neregistrovaný)
Ano, návratovou hodnotu je potřeba vždy ověřovat, ale autoři kódu to mnohdy nedělají, protože je to pakárna. S výjimkami se programuje lépe, a chybu "omlátí o hlavu", místo aby někde v hloubi aplikace vyhnila. Jenže podpora výjimek na straně jazyků není zrovna dokonalá: v C je nulová, a v C++ nebyla podpora povinná. Implementace na straně OS také není úplně triviální, zvlášť pokud chcete API exportovat i pro kód psaný v C. Pak tu samozřejmě byly problémy s výkonem u starších implementací.
Budoucnost je zřejmě jasná. Výjimky najdete ve Win32 (počínaje SEH někdy před 18 lety), v .NETu, Javě, C++/CX, a v podstatě všude jinde. Jenže to jde pomalu. Nakonec na rootu často oslavovaný kernel Linuxu je téměř 1:1 přepis kódu ze začátku osmdesátých let.
RageAgainstTheCage jsem neznal, děkuji za tip.
-
Neviditelný (neregistrovaný)
http://www.codon.org.uk/~mjg59/scratch/brick_samsung.txt (autorem je Matthew Garrett)
Jak mohly ty notebooky dostat "Windows 8 ready" certifikaci bych doopravdy rád věděl.
