pondělí, dubna 03, 2006

Malinkatá chybička

Příspěvek How would you solve this compatibility problem: Network interoperability (Old New Thing) si určitě přečtěte. Je zajímavé, jak takový vcelku banální problém dokáže přesně rozdělit lidi na dvě poloviny. A je zajímavé, kolik se toho o lidech dovíte z toho, na kterou stranu se přikloní.

O co jde?

Raymond Chen z Microsoftu se táže svých čtenářů, jak by řešili tento problém: file serveru se lze na seznam souborů zeptat pomalu nebo rychle. Pomalu se ptaly WindowsXP, Windows Vista se ptají rychle. Ovšem někteří betatesteři reportují podivnou chybu, kdy s některými file servery (nakonec byla v diskusi identifikována jako provinilec Samba, včetně odkazu do bugzilly) není načten celý seznam souborů, ale jen prvních 128 položek. Chyba v sambě byla zkraje roku opravena, nicméně jistě stále zůstává dost neupgradovaných instalací, při kontaktu se kterými by se Vista jevily jako pochybný operační systém, který ani nedokáže vylistovat soubory. (Poznamejme ještě, že nejde jen o problém s Windows Explorerem, ale se všemi aplikacemi, které používají API shellu k vylistování obsahu adresáře.) Čili se Chen ptá, jak mají Vista s touto chybou (která není jejich chybou, ale chybou kopírovačů, kteří Microsoft a jeho produkty tak nenávidí, až je pod hlavičkou open source kopírují) naložit.

Mají Vista chybu detekovat, zapsat informaci o ní do logu, a API vrátit chybový kód? Nebo se ji mají snažit detekovat, a před uživatelem skrýt? A tady se právě lidé rozdělují na dva neslučitelné tábory: jedni (ke kterým patří třeba BVer) se domnívají, že jediným řešením je chybu ohlásit a nechat uživatele/administrátory ať si nainstalují novou verzi Samby. Druzí (do této skupiny patřím já) si myslí, že je nepředstavitelné, aby operační systém, který používá zhruba 500 miliónů lidí, najednou přestal fungovat tak, jak tito lidé očekávají.

BVer mi v naší vášnivé diskusi na toto téma vysvětloval, že podobné workaroundy jsou cestou do pekel, a že jakékoliv jiné řešení než to "čisté" zalogování a vrácení chyby, je projevem opravdového zla. Já si na druhou stranu myslím, že pro Microsoft, který už tak všichni upřímně nesnáší, je nepřijatelné to, že za drahé peníze vnutí svým zákazníkům nový operační systém (kvůli kterému budou muset upgradovat hardware, přistoupit na licenční podmínky, které určitě budou výhodnější než ty současné -- výhodnější pro Microsoft, atd.), a ten pak nebude fungovat.

BVer dštil oheň a síru na snahu Microsoftu "vypadat dobře", a že z uživatelů dělá blbce. Já tomu ale rozumím: když nějaká firma utratí řekněme půl milionu dolarů za upgrade na Vistu, má za své peníze určitá očekávání. Jedním z nich je, že to co fungovalo, bude fungovat bez problémů dál.

Vidím tu ten propastný rozdíl mezi uvažováním lidí od Linuxu a lidí od Windows: Linux nemá zákazníky a není zákaznicky orientovaným softwarem. Windows naproti tomu jsou komerční produkt, který se musí prodávat, aby obhájil svou existenci.

Militantní Linuxáři vám řeknou: Pokud ti Linux příjde složitý, jsi debil, který si ho stejně nezaslouží. Podlézavý Microsoft vám nabídne slevu (kterou samozřejmě nechce zadarmo).

Linuxáři hají svou svatou pravdu s otevřeným kódem. Microsoft chce všechny peníze, které jste mu schopni dát.

Co mají oba tábory společné, je ta zarputilá tvrdohlavost, se kterou jdou za svým...

PS: Kauza pokračuje (a Chen vysvětluje, proč BVerův scénář s donucením k updatu není úplně realizovatelný). Doporučuji sledovat...

1 komentář:

BVer řekl(a)...

Jsa vhozen do jedné škatule k militantním linuxářům, nemám jinou možnost než na tento emocemi nabitý post odpovědět. Konečně, Festivalu už by po čase prospěl nějaký slušný flamewar, tak rád plním jIRImu jeho nevyslovené přání :-)

Předně: v dané kauze vystupuje všemi dlouho očekávaný operační systém od dominantní firmy na jedné straně a souborový server, jenž je k dispozici zdarma se zdrojovými kódy, na straně druhé. Dále je třeba zmínit, že oné dominantní firmě už samotná existence serverového projektu vadí -- tento software umožňuje běžným uživatelům přistupovat ze stanic vybavených operačním systémem dominantní firmy k souborům uloženým na jiných systémech (zvláště pak k souborům těch operačních systémů, které dominantní firma považuje za svoji hrozbu). Daný souborový server tím podstatně zvyšuje použitelnost a užitnou hodnotu konkurenčních systémů a dovoluje tak vzájemné soužití různých OS na jedné lokální síti a tím původně dokonalou dominanci firmy narušuje. Pro úplnost je ještě třeba zmínit, že dominantní firma detaily svých síťových protokolů původně nezveřejnila, takže serverový projekt vznikl na základě zpětného inženýrství a neúplných informací o chování a analýzou síťového provozu klientů dominantního výrobce.
Řekl bych, že toto uspořádání věcí situaci značně komplikuje, protože původně ryze technický problém je posouván do roviny obchodní, filozofické, až nábožensky fundamentalistické.

Pokusím se od vyšších rovin oprostit a hodnotit otázku na ryze systémové úrovni:
Každá jednotlivá komponenta tak komplikované věci, jakou je (jakýkoliv) operační systém, by měla dělat svoji práci v rámci celku čistě, jednoduše, logicky a bez zbytečných vedlejších předpokladů. Pokud tomu tak není, je její chování komplikované, pro ostatní komponenty obtížně předvídatelné a hůře abstrahovatelné -- bezprostřední okolí, které s komponentou komunikuje, se musí jejímu chování přizpůsobovat a to vede ke zbytečným složitostem a dalším nadbytečným předpokladům. Každá složitost pak zvyšuje šance zákeřných chyb a zhoršuje efektivitu (rychlost a paměťovou náročnost). Snahou architektů je tak samozřejmě udržet systém na všech úrovních co nejjednodušší. Proto například jedno z navrhovaných řešení "systém se postará sám o chybové hlášení k směrem k uživateli a zobrazí dialog s varováním" je vadné -- síťový subsystém by tak musel mít těsné vazby na nějaký zobrazovač událostí (jenž je zodpovědný za zobrazování GUI hlášek v daném rozlišení, barvách, jazyce, atd...) a tato vazba může být zdrojem komplikací, protože cílem síťového subsystému je být efektivní a cílem zobrazovacího subsystému je být komfortní. Je evidentní, že síťová komponenta OS má problém detekovat, obejít, hlásit a zaznamenat tuto událost co nejjednodušším zůsobem (např. návratovou hodnotou volání, zápisem do systémového logu, atd.), je pak pouze a jen věcí aplikace, jestli a jakým způsobem varování prezentuje. Tedy: model toho, jak se zachovat, je plně v kompetenci softwarové vrstvy NAD síťovou komponentou OS, tedy konkrétně souborového prohlížeče. (Poznámka na okraj: Je smutné, že se i technicky orientovaní lidé už dnes nedokážou rozlišovat mezi operačním systémem a jeho aplikacemi -- slíbil jsem ale, že se nyní budu držet ryze technických aspektů, takže nechci toto téma rozvíjet.)

Tolik tedy k tomu, proč "podobné workaroundy jsou cestou do pekel, a že jakékoliv jiné řešení než to "čisté" zalogování a vrácení chyby, je projevem opravdového zla", doufám, že je jasné, proč a z jakých důvodů hájím toto stanovisko.

Nyní k vyšším úrovním problému: Operační systém je v konečném důsledku komerční produkt a jako takový vzniká díky značnému úsilí technického, a obchodního týmu. Obchodníci stanovují priority, celkové zaměření, look´n´feel celého produktu, měli by dobře znát cílovou skupinu zákazníků, atd. V reálném světě jsou pak požadavky dané obchodním týmem často v rozporu s prioritami technickými -- v daném případě je obchodním požadavkem zpětná kompatibilita: síťové aplikace musí fungovat úplně stejně jako na předchozí verzi operačního systému, jenž je ale zcela technicky odlišný od vyvíjeného systému. Podobný požadavek, je-li prosazen, vede k tomu, že v nenarozeném dítěti vzniká slepé střevo (bug v serverovém projektu byl už odstraněn a za několik měsíců bude workaround v OS úplně nepotřebný, zatímco OS bude udržován dlouhou řadu let, je mylné předpokládat, že uživatelé budou vadnou verzi serveru používat dlouhodobě třeba kvůli firmware v ROM). Stručně řečeno, má být odstraněna jen původní chyba a na místě, kde vznikla.

Vybalancování technických a obchodních požadavků je nelehkým úkolem hlavních šéfů -- jen oni rozhodují o tom, zda je důležitější mít technicky dokonalý OS s drobným nekomfortem, jenž časem donuti určité procento správců serverů k upgradu, nebo to, aby současní zákazníci měli snadný přechod na operační systém, jenž je vnitřně zaneřáděn od samého začátku.
Celková politika dominantní firmy je dlouhodobě zvýhodňovat obchodní priority před technickými -- jen tak dosáhla své dominance. Tato jistě úspěšná strategie nicméně vysvětluje i fakt, proč technické parametry produktů, API a protokolů oné dominantní firmy jsou vždy podřízeny momentálním krátkodobým trendům, proč jsou výrobky uváděny na trh se zpožděním a proč je jejich údržba často problematická.

Tímto se dostávám k předposlednímu argumentu (pokrytectví a "dělání blbců" z uživatelů): každá úspěšná firma musí pracovat s modelem zákazníka. Obchodníci operují s tvrzeními typu "tohle uživatel snese, tohle už ne", "tohle je intuitivní, tohle už ne", "tohle vypadá jako naše chyba, to není přípustné", apod. Myslím si, že model uživatele, s nímž pracuje dominantní firma, je (zbytečně) vychýlen směrem k podprůměrnému uživateli s nižším IQ. Je to logické -- lidé, kteří konktaktují uživatelskou podporu, většinou k této skupině patří a je tak výhodné ušetřit náklady, pokud jich bude co nejméně. Ona podceňovaná "mlčící většina" je ale v průměru mnohem šikovnější a schopnější, než by dominantní firma byla ochotna připustit. Což je mimo jiné i důvod, proč vůbec vznikají a jsou velmi populární projekty jako je síťový souborový systém postavený na protokolech dominantní firmy.

Tak.
Doufám, že jsem aspoň částečně vysvětlil své "svaté pravdy", které byly autorem vyjmuty z kontextu naší dlouhotrvající diskuse a lehce osprejovány narudo.

A teď si neodpustím ti tu trošku demagogie, jIRI, vrátit. Jen dál, časem si snad opravdu nainstaluješ nějakou šikovnou linuxovou distribuci, staneš se jejím spokojeným a nakonec i pokročilým uživatelem a budeš tak schopen posuzovat a hodnotit věci "zevnitř".
Kdyby totiž platil tvůj omyl, že "Linux nemá zákazníky", neuvažoval by technický tým Visty o podpoře staré verze Samby, nebo snad ano?