Vlákno názorů ke zprávičce Dočasné řešení problému ZFS a Linuxu 5.0 od Rhinox - Cim dal tim vice se ukazuje, ze ZFS...

zajimavy by byl myslenkovy experiment kdyby gnu/linux byl zalozen na bsd licenci kde bychom nyni byli ?

nemam pocit ze by si vyvojari *bsd distribuci nejak moc stezovali na vykradani a zpenezovani jejich prace ...

Takže se nebavíte o OSS, ale o software, který je pod GPL3. To jste si to dost upravil (CLANG není OSS?, BSD/MIT/Apache není OSS? tvůrci sw si nemohoui svobodně vybrat licenci?).

A já jsem vás upozornil, že kdybyste se obtěžoval podívat na licenci linuxového jádra, věděl byste, že taková úvaha je už od základu nesmyslná, protože tato možnost je tam od začátku jednoznačně a výslovně vyloučena.

Asi se mi nedaří vysvětlit, že jsem to myslel jako upozornění na myšlenkový posun u autorů. O to, že by userspace nešel, o to samozřejmě strach nemám. (Ale před pár lety jsem neměl strach ani z toho, že by se nesměly používat některé funkce.)

doufám, že nechcete tvrdit, že se tehdy vymezoval vůči ZFS. Sun zvolil (mnohem později) při zveřejnění svého kódu, který je základem "ZFS on Linux", licenci CDDL

Proboha, proč to pořád stavíte tak, že se někdo proti někomu musí vymezovat? To nemohou oba svobodně zvolit licenci, a přesto hledat cestu spolupráce?

To, že je něco snadno technicky proveditelné, a dokonce ani to, že mne za to nikdo nezažaluje, neznamená automaticky, že je to v pořádku. Kdybych měl tu situaci k něčemu přirovnat, tak třeba k tomu, že jestli mám na vstupních dveřích do domu korálkový závěs, normální dveře s FABkou nebo nějaké superbezpečnostní s devítibodovým zámkem a alarmem, je jen technické opatření odrážející to, jak moc mi záleží na tom, aby se dovnitř nedostal někdo, kdo tam nemá co dělat.

Souhlasím. Mimochodem, zmínil jste, jaký je výklad Linuse. A teď jsme možná tak trochu u jádra pudla. Předpis nebo dohodu si může vyložit v detailech každý jinak. Jediným, kdo může v praxi rozhodnout, jak se má dané právo uplatnit, je soud. Jenže: 1. jaká je místní příslušnost takového soudu? V Evropě pravděpodobně všude podle obvodu žalovaného. Co mimo Evropu, v USA a dalších zemích? 2. Jak se OSS vypořádá s tím, že jednotlivé příslušné soudy budou rozhodovat jinak a v každé době jinak? U korporací na to existují obrovská odělení Legal a Compliance, jenže u OSS to nikdo nedělá.

V praxi vidíme, že GPL vykládají úzkostlivě spíš jednotlivci. Velcí hráči na to tak trochu prdí. Buďto vůbec licenci nedodrží (kde není žalobce, není ani soudce). Nebo nejprve zkusí svět změnit po dobrém (Google, RedHat, ...), a teprve když to nejde pomocí PR, pak zatlačí silou.

Mně současná situace nepřijde šťastná a proto se mi ani nelíbí postoje, že se někdo musí vymezovat proti někomu. Tohle přeci nemusí být souboj!

To není zřejmě myšlenkový posun, oni to dělají zcela bezmyšlenkovitě. Mimoto, již pod minulým článkem bylo řečeno, že SFLC tam žádný licenční problém nevidí; narozdíl od potrhlého militantního hulákání GKH to ovšem mají podložené argumenty.

Jenže 1. ne každý chce jít do právní nejistoty, 2. v praxi by to znamenalo přetahovanou o patche do jádra. (Abychom se ještě nedočkali forku Linuxu).

Asi se mi nedaří vysvětlit, že jsem to myslel jako upozornění na myšlenkový posun u autorů.

Ten můj příměr s domem měl naznačit, že já tam myšlenkový posun nevidím. Tedy aspoň ne v té základní otázce, zda je non-GPL modul v pořádku, a že je-li nějaký posun, tak spíš v tom, že některým vývojářům začíná tak trochu docházet trpělivost. GPL2 je pořád stejná (GPL3 a různé další nové verze jsou jiná kapitola, ale to se Linuxu naštěstí netýká) a základní licence je pořád GPL2 (with syscall note). Mění-li se v něčem situace a vedou-li se o něco spory, tak je to spíš to, jak agresivně se má dodržování pravidel vynucovat. Tedy jazykem toho příměru "přidávání zámků", ne změna pohledu na to, zda je přípustné vlézt cizímu člověku do domu.

Jakkoli nevývojáři může ten rozdíl připadat malicherný, upozornil bych i na to, že tady je naprosto zřejmé, že ta změna v 5.0-rc1 byl naprosto standardní úklid a že vůbec nebyla motivována nějakým děláním naschválů ZFS. (Stejně jako nikdo (kdo je trochu v obraze] neobviňuje vývojáře z úmyslného házení klacků pod nohy VMware kvůli třem jiným změnám, které rozbily jejich out of tree moduly.) Neochota k revertu je také primárně dána tím, že tohle rozhraní bylo viditelné spíš jen omylem a že všeobecný úzus je, že funkce, kterou nikdo ve stromě nevolá, nemá v jádře co dělat (přičemž se za argument proti nepovažuje ani "náš out-of-tree modul ji používá" ani "chystáme se přidat in-tree kód, který ji bude používat").

Proboha, proč to pořád stavíte tak, že se někdo proti někomu musí vymezovat?

Já to tak stavím? Podívetjte se o kousek výš. kdo jako první začal mluvit o "vymezování se" a obvinil "Linux" z toho, že se vymezil vůči ZFS. Já u toho příspěvku vidím jméno "Miroslav Šilhavý".

V praxi vidíme, že GPL vykládají úzkostlivě spíš jednotlivci. Velcí hráči na to tak trochu prdí. Buďto vůbec licenci nedodrží (kde není žalobce, není ani soudce). Nebo nejprve zkusí svět změnit po dobrém (Google, RedHat, ...), a teprve když to nejde pomocí PR, pak zatlačí silou.

A právě proto jsem připomínal, že to, že určité chování je dlouhodobě tolerováno, neznamená automaticky, že je v pořádku. A také že neřešíme situaci, kdy by linuxoví vývojáři nějak stíhali vývojáře "ZFS on Linux". Naopak, jsou to vývojáři "ZFS on Linux", kteří se z nějakého důvodu domnívají, že mají právo požadovat, aby jim vývojáři Linuxu vycházeli vstříc a usnadňovali jim jejiích práci. A to je naprosté nepochopení situace; vývojáři Linuxu od začátku dávali jasně najevo, že bastlit si dlouhodobě out of tree modul (bez jasného plánu na začlenění do upstreamu) je špatný vývojový model, a že každý, kdo se k němu z jakéhokoli důvodu rozhodne, musí počítat s tím, že to přináší problémy a že se nikdo nepřetrhne, aby je za něj řešil.

A právě proto jsem připomínal, že to, že určité chování je dlouhodobě tolerováno, neznamená automaticky, že je v pořádku.

Přesně naopak! Nejprve je potřeba si všímat toho, jak věci fungují a pak teprve kodifikovat a naposledy s větší či menší silou vynucovat. Příkladem z běžného života budiž např. auto s nefungujícími směrovými blikači. Takové auto je nezpůsobilé provozu a nemělo by se s ním jezdit. Přesto ale existují pokyny, jak signalizovat změnu směru s nefunkčními blikači (doleva upažením z okna, doprava zdvižením ruky z okna). Protože zákonodárce si je vědom toho, že ne vždy je možné do puntíku dodržet pravidlo č. 1 - tedy odstavit okamžitě vozidlo z provozu.

Další vývoj je např. v autorském právu, kdy AutZ v době vzniku ani dlouho poté nepočítal s fenoménem internetu. U internetového díla je problematické posuzování místní příslušnosti (odkud je v případě CDN dílo poskytováno?), nebo i otázka toho, v jaké zemi bylo dílo uvedeno poprvé? (Když se ve stejný okamžik objeví všude?). Zde je také uplatňována jakási zdrženlivost, protože dbát na doslovném výkladu by nic nepřineslo.

Pokud tedy praxe ukazuje, že toto tolerování je přínosné, je na místě hledat způsob, jak to zachovat. Nikoliv, jak to zrušit a odůvodnit.

Naopak, jsou to vývojáři "ZFS on Linux", kteří se z nějakého důvodu domnívají, že mají právo požadovat, aby jim vývojáři Linuxu vycházeli vstříc a usnadňovali jim jejiích práci. A to je naprosté nepochopení situace; vývojáři Linuxu od začátku dávali jasně najevo, že bastlit si dlouhodobě out of tree modul (bez jasného plánu na začlenění do upstreamu) je špatný vývojový model, a že každý, kdo se k němu z jakéhokoli důvodu rozhodne, musí počítat s tím, že to přináší problémy a že se nikdo nepřetrhne, aby je za něj řešil.

Zde si dovoluji mít odlišný názor. Myslím si, že mít ohled na významné projekty (zmíněné vmware, zmíněný ZFS i další), je také v pořádku. Je jasné, že nelze vyhovět všem. Ale jsou oblasti, kde i externí, licenčně nekompatibilní projekt je tak významný, vydobyl si postavení u uživatelů, že je na místě ho tolerovat nebo dokonce i trochu pomáhat.

Nejprve je potřeba si všímat toho, jak věci fungují a pak teprve kodifikovat

Takže se mělo nejdřív dostatečně dlouho počkat, kdo a jak bude Linux chtít používat a kdo a jak na něm bude chtít stavět další projekty, a pak teprve stanovit jeho licenci? To si dost dobře nedokážu představit.

Protože zákonodárce si je vědom toho, že ne vždy je možné do puntíku dodržet pravidlo č. 1 - tedy odstavit okamžitě vozidlo z provozu.

To ale nemění nic na tom, že vyložíte-li si to jako záminku jezdit s technicky nezpůsobilým vozidlem mimo situace, kdy je to přípustné (např. pokud by to okamžité odstavení znamenalo ještě větší riziko), vystavujete se riziku postihu a pokud dokonce způsobíte nehodu, bude to přitěžující okolností.

Myslím si, že mít ohled na významné projekty (zmíněné vmware, zmíněný ZFS i další), je také v pořádku.

V pořádku to je, pokud se tak vývojáři svobodně rozhodnou. Pokud ne, je třeba to respektovat jako jejich rozhodnutí. Bohužel to v diskusích na fórech vypadá, jako kdyby snad na to byl nějaký nárok jen proto, že oni mají ten modul rádi. (Tím nemyslím osobně vás, vy jste jeden z těch kulturnějších, ale zkuste se podívat na tuhle i minulou diskusi, co tam padalo za výrazy - a to nemluvím třeba o Phoronixu.) Podobně byli před lety někteří agresivní členové reiserfs fanclubu přesvědčeni, že jen proto, že jim se ten filesystém líbí, mají nárok na to, aby byl co nejrychleji začleněn bez ohledu na technické výhrady maintainerů.

Ale jsou oblasti, kde i externí, licenčně nekompatibilní projekt je tak významný, vydobyl si postavení u uživatelů, že je na místě ho tolerovat nebo dokonce i trochu pomáhat.

Pohled z druhé strany: před nějakými 6-7 lety bylo pro VMware Workstation/Player host potřeba pět out-of-tree modulů. Dnes zbyly dva, u ostatních už si u VMware dali práci, aby je vyčistili, přepracovali v souladu s logikou a zvyklostmi příslušných subsystémů a dostali do mainline. Jeden z nich (vsock) je dokonce využíván nejen pro VMware VMCI, ale i pro virtio. A když později Microsoft submitnul svou vlastní verzi socketů pro přímou komunikaci s HyperV, byli vyzváni, aby neduplikovali funkcionalitu a postavili to také na vsock. Myslíte si, že by se to stalo, kdyby ze strany vývojářů jádra fungovala ta vstřícnost vůči out of tree modulům (aspoň těm "významným"), kterou považujiete za užitečnou a žádoucí? Já jsem přesvědčen, že je mnohem pravděpodobnější, že by v takovém případě těch modulů bylo těch out of tree modulů pořád pět. A to není zdaleka jediný příklad.

Takže se mělo nejdřív dostatečně dlouho počkat, kdo a jak bude Linux chtít používat a kdo a jak na něm bude chtít stavět další projekty, a pak teprve stanovit jeho licenci? To si dost dobře nedokážu představit.

Neříkám, že tyto situace musíme vyvolávat. Ale když už nastanou - což je tento případ, je podle mě lepší se nad tím zamyslet s odstupem, neházet argumenty jako ve školce "já to viděl první" / "ale já to první sebral ze země" / "ale já si s tím hrál už včera".

V pořádku to je, pokud se tak vývojáři svobodně rozhodnou. Pokud ne, je třeba to respektovat jako jejich rozhodnutí. Bohužel to v diskusích na fórech vypadá, jako kdyby snad na to byl nějaký nárok jen proto, že oni mají ten modul rádi.

Znovu, ta emoce by neměla zastínit meritum věci. Mohou sice argumentovat emotivně "máme rádi", ale i fakticky to může být pravda.

A když později Microsoft submitnul svou vlastní verzi socketů pro přímou komunikaci s HyperV, byli vyzváni, aby neduplikovali funkcionalitu a postavili to také na vsock. Myslíte si, že by se to stalo, kdyby ze strany vývojářů jádra fungovala ta vstřícnost vůči out of tree modulům (aspoň těm "významným"), kterou považujiete za užitečnou a žádoucí? Já jsem přesvědčen, že je mnohem pravděpodobnější, že by v takovém případě těch modulů bylo těch out of tree modulů pořád pět.

Záleží případ od případu. Někdy jsou souběžné moduly zdravé, protože začne fungovat soutěž. Stačí si vzpomenout na moduly síťovek, které byly mnohdy ve dvou paralelních verzích, o podpoře zvuku (i historicky) nemluvě. Mnohdy ten později přicházející dokáže dodat vývoji nový náboj a pohnout s tím víc dopředu - stalo se to už mockrát.

Neříkám, že tyto situace musíme vyvolávat. Ale když už nastanou - což je tento případ, je podle mě lepší se nad tím zamyslet s odstupem, neházet argumenty jako ve školce "já to viděl první" / "ale já to první sebral ze země" / "ale já si s tím hrál už včera".

Jak konkrétně byste si to představoval? Licence jádra je GPL2, je to tak už přes čtvrt století a i kdyby byla vůle to změnit (jako že není), nebylo by to technicky proveditelné. Dokonce ani kdyby se Linus spolu se všemi aktuálními významnými mintainery a přispěvateli dohodli, že chtějí licenci změnit, tak by to nestačilo. Nemám tušení, jak je to s licencí ZFS, jestli je i tam technický problém nebo jestli je to prostě jen neochota. U XFS to šlo, u JFS to šlo. Oba se do jádra dostaly v době, kdy Linux ještě nebyl zdaleka tak významný jako dnes a za oběma také stály hodně velké firmy.

Někdy jsou souběžné moduly zdravé, protože začne fungovat soutěž. Stačí si vzpomenout na moduly síťovek, které byly mnohdy ve dvou paralelních verzích, o podpoře zvuku (i historicky) nemluvě.

Zrovna drivery síťových karet bych viděl jako argument proti. Dodnes je řada (naštěstí většinou těch méně významných) výrobců, kteří si spokojeně bastlí svůj out of tree driver (u driverů zařízení je to jednodušší než u filesystému) a in-tree buď neexistuje nebo je zoufale pozadu (mnohdy bez jakékoli podpory ze strany výrobce). To není žádoucí stav, tím spíš že i ty out-of-tree drivery jsou sice (celkem) aktuální, ale často neuvěřitelně zprasené. Nedělám si iluze, že u zvukových karet je to lepší, spíš bych čekal, že je to ještě o dost horší. A už vůbec si nemyslím, že větší vstřícnost vůči out-of-tree modulům by situaci zlepšila - přesně naopak.

Jak konkrétně byste si to představoval? Licence jádra je GPL2, je to tak už přes čtvrt století a i kdyby byla vůle to změnit (jako že není), nebylo by to technicky proveditelné.

To si právě uvědomuji a proto říkám, že v některých ohledech se GPL neosvědčila či přežila.

Zrovna drivery síťových karet bych viděl jako argument proti. Dodnes je řada (naštěstí většinou těch méně významných) výrobců, kteří si spokojeně bastlí svůj out of tree driver (u driverů zařízení je to jednodušší než u filesystému) a in-tree buď neexistuje nebo je zoufale pozadu (mnohdy bez jakékoli podpory ze strany výrobce).

Já mluvím o době, kdy in-tree byly paralelně dva moduly pro 3com nebo Intel síťovky. O době, kdy in-tree byly dva různé soundsystémy, a v rámci nich někdy i dva navzájem se stínující drivery. Na konec vyhrál ten lepší - udržovanější.

Já mluvím o době, kdy in-tree byly paralelně dva moduly pro 3com nebo Intel síťovky. O době, kdy in-tree byly dva různé soundsystémy, a v rámci nich někdy i dva navzájem se stínující drivery. Na konec vyhrál ten lepší - udržovanější.

To je ale úplně jiná situace, než o které se tady bavíme. Se "ZFS on Linux" to nemá vůbec nic společného, to je out-of-tree modul, který se do mainline v žádném případě dostat nemůže, pokud ho Oracle nepřelicencuje. Jistě, pokud bychom v jádře měli ext4, XFS, BtrFS a ZFS, mohli bychom se bavit o tom, čemu uživatelé a firmy nasazující linuxová řešení dají přednost, co se prosadí a co zahyne nebo bude skomírat na okraji zájmu. Ale taková situace tu není a pokud Oracle nezmění svůj postoj, ani nebude - a těžko z toho vinit vývojáře jádra.

Je zajímavé vidět argumenty na obhajobu obou stran. Bohužel i já vidím v chování některých vývojářů jádra naschvály. Argumenty Michala Kubečka sice dávají smysl, ale.

1. Pokud se vrátíme ke kořenům, smyslem GPL bylo vynutit při distribuci upravené verze programu i dostupnost jeho upravených zdrojových kódů. Toto CDDL beze zbytky splňuje (skoro by se chtělo říct, že je svobodnější, než samotná GPL). Vše ostatní jsou už jen technikálie a trvání na splnění formálních detailů.

2. Grafika v Linuxu jde úplně mimo mne, takže doufám, že se nemýlím, ale z toho co se ke mně doneslo mám pocit, že vývojáři jádra nejsou tak militantní, pokud se jedná o proprietární grafické drivery. V tom případě jejich chování vypadá značně pokrytecky.

3. Organizace Linux Foundation (která stojí za Linuxem a ochranou jeho práv) nemá velký zájem bojovat proti zjevným porušením licenčních práv (kauza VMware), pokud za nimi stojí významné společnosti a nechá v tom vykoupat jednotlivce. O dodržování jakých licenčních práv se potom bavíme.

Ano, pokud se týká litery licence, má Michal Kubeček bezpochyby pravdu. Ale je to značně farizejský přístup.

Zdá se, že podstata toho, co se tu celou dobu snažím vysvětlit, není dostatečně jasná. Mně nejde primárně o GPL nebo Stallmanův svatý boj za ideovou čistotu (není to koneckonců tak dlouho, co jsem byl na ABCLinuxu obviněn, že "nenávidím GPL"). Co se tu celou dobu (včetně minulé diskuse na toto téma) snažím vysvětlit, je, že z pohledu "Linuxu", ať už tím myslíme maintainery, vývojáře a nebo koneckonců i uživatele, nejsou out-of-tree drivery žádná velká výhra. Chápu, že pohledem člověka, který je z Windows zvyklý shánět si drivery ke každému kousku hardware po webech výrobců, to může být těžko pochopitelné, ale to je prostě jiný svět.

Podporovat out-of-tree drivery bez ohledu na licenci znamená směřovat ke stavu, kdy spousta hardware nebude vanilla jádrem podporována, kdy bude potřeba shánět drivery pochybné kvality po všech čertech. Znamená to podporovat přístup "fire and forget", kdy výrobce přestane podporovat starší verzi hardware, jakmile vydá novou. To není malování čerta na zeď, to je extrapolace z existujících out-of-tree driverů.

Je také velký rozdíl, jestli je driver out-of-tree proto, že je to novinka ve stádiu vývoje, kdy ještě není ve stavu zralém na přijetí do mainline, nebo jestli je to driver, který autoři nikdy do jádra dostat ani nechtějí, ať už proto, že jediným cílem je odškrtnout "Linux driver... done", nebo proto, že je to pro ně jednodušší a pohodlnější. Non-GPL moduly, to je ještě další krůček dál: to jsou drivery, které se bez přelicencování do jádra ani dostat ani nemohou, takže tam je předem jasné, jak na tom jsme. (Úplně nejnižší úroveň jsou pak closed source drivery.)

Je mi jasné, že z pohledu uživatele, který si koupil konkrétní hardware (aniž by si ověřil, jak je to s podporou) nebo chce z nějakého důvodu používat reiser4 nebo ZFS, to všechno může vypadat malicherně, protože pro něj je out-of-tree driver super řešení a ti zlí vývojáři mu ho chtějí rozbít. Přesto se snažím vysvětlit, že podpora vzniku dalších a dalších out-of-tree driverů bez jasného plánu (nebo vůbec vůle) dostat je někdy do upstreamu není ve skutečnosti vůbec v zájmu Linuxu a jeho použitelnosti.

Ad 2: Je přirozené, že různí maintaineři mohou mít různé představy o tom, co je správné a co je žádoucí. Ale že by u grafiky byla patrná snaha za každou cenu vyhovět NVidii a ulehčit jí to, jak si s Linuxem vytírá zadek, to se mi moc nezdá.

Ad 3: Linux Foundation sice má v názvu "Linux" a platí Linuse, Grega a možná pár dalších, ale rozhodně to není tak, že by nějakým způsobem reprezentovala vývojáře a že by její postoj byl směrodatný. Naopak znám významné vývojáře, kteří o LF zřídka promluví v dobrém.

Chápu, že pohledem člověka, který je z Windows zvyklý shánět si drivery ke každému kousku hardware po webech výrobců, to může být těžko pochopitelné, ale to je prostě jiný svět.

To je trochu zkreslená představa. Už dlouho platí, že na současném hardwaru není potřeba nic instalovat, výrobci mají drivery přímo ve firmwaru, ... Takže Windows většinou fungují "seamlessly". Ano, problém bývá, když chce někdo rozchodit starší hardware (k tomu se dostanu dále).

Podporovat out-of-tree drivery bez ohledu na licenci znamená směřovat ke stavu, kdy spousta hardware nebude vanilla jádrem podporována, kdy bude potřeba shánět drivery pochybné kvality po všech čertech.

To si nemyslím. Myslím si, že není úplně nutné podporovat kdejaký historický hardware in-tree jen kvůli tomu, že existuje mantainer (který mnohdy vyvíjí sám pro sebe a pár desítek jednotlivců). Naopak by mi dávalo smysl jádro zjednodušovat, poskytovat drivery jen na opravdu smysluplný hardware. Tento přístup funguje např. u BSD systémů, nemají povětšinou problém s kompatibilitou. Mně přijde, že snad nejvíc diskutovaným problémem jsou drivery určené pro desktopové použití, ale to je zrovna oblast, kde si Linux vede mizerně. Na serveru, naopak, nepotřebuju podporu tisíců kravin.

Dál je potřeba zamyslet se, jak vypadá životní cyklus hardwaru a cena hardwaru vůči průměrné mzdě. V devadesátých letech bylo PC neskutečně drahé pro Čecha, ale nebylo zanedbatelné ani pro Němce. Hardware se využíval roky, přepojoval se od starší sestavy k novější, ... Dnes je cyklus úplně jiný. Z průměrné mzdy nakoupíte hned několik počítačů. Lidé hardware koupí, pár měsíců používají a mnohdy (periferie) hodí klidně do koše.

Přístup maintainerů Linuxu mi připadá, jako kdyby byli tak trochu zastydlí v těch devadesátých letech.

Přesto se snažím vysvětlit, že podpora vzniku dalších a dalších out-of-tree driverů bez jasného plánu (nebo vůbec vůle) dostat je někdy do upstreamu není ve skutečnosti vůbec v zájmu Linuxu a jeho použitelnosti.

To je podle mě odvážné tvrzení. Víme, že i opačný přístup vede k úspěchu, takže dovozovat, že toto je v zájmu Linuxu mi přijde hodně nekritické.

GPL je hodně omezující a dá se říct, že je málo svobodná. Vynucená svoboda není už svoboda, to je protimluv. EXPORT_SYMBOL_GPL je něco hodně na kraji výkladu a podle mě by měli maintaineři Linuxu volit spíš zdrženlivý přístup ke kontroverzním výkladům, než do nich jít po hlavě.

Abych to stručně shrnul: názorně jste vysvětlil, že vaše kritéria kvality a úspěšnosti operačního systému jsou diametrálně odlišná od kritérií maintainerů linuxového jádra. Jakkoli souhlasím, že měřeno těmi vašimi metrikami by bylo žádoucí co nejvíce podporovat vznik a (ne)vývoj out-of-tree driverů bez ohledu na jejich licenci a (ne)budoucnost, musím konstatovat, že váš pohled a vaše preference nesdílím - a tudíž ani závěry, které z nich plynou.

Záleží případ od případu. Někdy jsou souběžné moduly zdravé, protože začne fungovat soutěž.

Dodatečně mi došlo, že tady asi došlo k nedorozumění. Věta "Myslíte, že by se to stalo..." se nevztahovala k bezprostředně předcházející větě, ale k celému textu toho odstavce, tj. "Myslíte, že by si VMware dal práci s upstreamováním tří z pěti těch out-of-tree modulů..."