Dočasné řešení problému ZFS a Linuxu 5.0

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ů..."

Dal to najevo použitím EXPORT_SYMBOL_GPL, kteréžto má svůj jasně popsaný význam.

ZoL by samozřejmě mohl do svých patchů zahrnout i obejití, přesně jak píšete. Ale myslím si, že to spíš neudělají, bylo by to dost necivilizované ještě víc prohlubovat problém. No a z toho ale také plyne, že pokud má projekt ZoL pokračovat, musí autoři najít jinou cestu, jak s Linuxem nebojovat a zároveň splnit to, co si předsevzali.

Neviděl bych to tak černě, v roce 2015 vyšla statistika, používání licencí na GitHub a GPL2/3 dohromady měli okolo 22% zatímco MIT 44%.

Jinak nechápu tu slávu mínusu pod mým komentářem, já jsem jen popsal situaci z firemní sféry (záměrně nepíší korporátní, protože mám obdobné zkušenosti i z malých firem).

S mínusy si tu nedělejte hlavu. Dávají se za kacířství, ne za kvalitu myšlenky či sdělení. Lidé jsou veskrze idealisti a neradi čtou o tom, že něco v OSS nefunguje ideálně. Podle mě mají pocit, že neúspěch té či oné věci je daný námi, kteří napíšeme kritiku. To je takový podvědomý dozvuk osvědčeného modelu ve světských i v církevních záležitostech: v první řadě je potřeba opozici umlčet, v druhé řadě už není potřeba nic zlepšovat.

Miroslave, mate pravdu. Jenže ten idealismus právě dělá tento stav. Linux kernel potřebuje stabilní driver ABI. Celá ta teorie, že veškerý driver je třeba tlačit in-tree je prostě zcestna myšlenka, jednak nejsou toto schopni dělat dostatečně rychle, jednak to dělají jen pro mainstream hw. Tento přístup nikdy nebude fungovat pro jejich slovy obskurní hw (mými specializovaný). A i kdyby se podařilo ten driver rychle dostat do in-tree tak ten kernel se tak rychle nedostane do distra. A to si výrobce takového HW nemůže dovolit, takže začínám vidět stav, kdy na systémech je Win Server ačkoliv by tam vůbec nemusel být. A argument máte přece FUSE fakt nekupuju. Jinak já také kde můžu dávám FreeBSD ale ne z licenčního duvodu, ale protože někdy okolo 2006 si mě získalo díky Jails. Teď ještě aby vyladili bhyve a nevidím jediný důvod k používání Linuxu z mé strany. Naštěstí teď dostává i podporu od velkých korporací.

Je opravdu dost dobře možné, že např. na servech bude brzy BSD atraktivnější, než Linux.

Jak už jsem se vám snažil vysvětlit minule, tohle je reálné nanejvýš na nějakých malých systémech pro domácí použití. To je zase ten pohled běžného desktopového uživatele "můj hardware je tam podporovaný, takže je všechno v pořádku". Není. Pokud se dnes bavíme o serverech pro enterprise použití, je řeč minimálně o desítkách procesorů, u větších o stovkách, ve speciálních případech o tisících. Proto máme TCP lockless listener, proto se v hot path všechno, co jen trochu jde, přepisuje na RCU nebo úplně lockless algoritmy, a řeší se i to, jak přerovnat data, aby se minimalizovaly cache misses, proto je takovým hitem XDP (a také proto, že 40Gb/s ethernet je dnes běžná praxe a začíná se prosazovat 100Gb/s).

A pak se pro kontrast podívejte sem, jaké problémy řeší síťový stack OpenBSD. V zápisku ze srpna 2017 se jen tak mimochodem zmíní "Yes, the stack is still mostly single-threaded.". V prosinci 2018 vychází nová verze, která odstraňuje KERNEL_LOCK z podstatné části syscallů pro příjem a odeslání paketů. V Linuxu BKL neexistuje někdy od 2.6.38 vůbec a ve srovnatelných částech síťového stacku byste ho v gitu nenašel vůbec, protože ten začíná až od 2.6.12-rc2 (duben 2015).

Tím nechci říct, že jsou vývojáři BSD systémů neschopní nebo že dělají něco špatně. Ale je jich prostě mnohem méně a někde se to projevit musí. Ta představa, že BSD je takovou o něco méně známou, ale jinak v podstatě srovnatelnou alternativou k Linuxu, je prostě úplně mimo realitu.

@Michal Kubeček:

Rozumím, souhlasím s Vámi, že jsou použití, kde je Linux na míle leaderem. Vámi popisovaná použití se podle mě týkají < 0,01 % případů, možná ještě méně, přesto je v nich Linux nenahraditelný.

Můj pohled je ale trochu jiný. Já zase nejčastěji řeším malé servery do nižších desítek jader, dost často virtualizované. Tam všude se technologie, které zmiňujete, vlastně neuplatní. Pro mě Linux představuje určitou zbytečnou nestabilitu (nemyslím nestabilní běh, ale že co verze, tak se spousta věcí změní) a přínosy z toho jsou jen okrajové.

Monžá jsme narazili na dost často zmiňovanou bolest Linuxu, že cílí na všechno a zároveň na nic. Na desktopu se Linux právě proto neuchytil (resp. toto není věc Linuxu, ale desktopů, ale bolest je to stejná).

Těžko říct, kolik procent uživatelů Linuxu ocení lockless tcp listener vs. FreeBSD AIO. Já jednoznačně víc oceňuji rozvážnější vývoj. FreeBSD pro mě implementuje víc vlastností, které mě zajímají, byť se zpoždením. Méně mě otravuje s výstřelky a většími změnami. Správu na něm provedu levněji a spolehlivěji, než na Linuxu. 40 / 100 GbE zatím neocením, ale také zatím mám historickou zkušenost, že až na to přijde doba, a bude to potřeba, tak to bude mít i FreeBSD zpracované a bez kotrmelců při vývoji.

Proto se tu střetávají dva pohledy, Váš, kterému rozumím, že by Linux bez určitých pravidel a obětí nemohl být tak progresivní. Můj, kdy nechci být zrnko mezi mlýnskými kameny.

Vámi popisovaná použití se podle mě týkají < 0,01 % případů, možná ještě méně,

A jsme zase zpátky u procent počítaných podle počtu desktopů a domácích routříků. To je skoro jako to "na hranici měřitelnosti" v minulé diskusi. Když to nevidím a nemůžu si na to sáhnout, tak to neexistuje. Jenže to je strašně krátkozraký pohled - a právě na těch systémech, které vidět nejsou, Linux už dávno dominuje.

...byste ho v gitu nenašel vůbec, protože ten začíná až od 2.6.12-rc2 (duben 2015).

Oops... tady samozřejmě mělo být "duben 2005". :-)

Já jsem ale mluvil o 40Gb/s a 100Gb/s. 10Gb/s by neměl být problém, ten se mi s dostatečně silným procesorem v rámci experimentování podařilo téměř nasytit i při vypnutí TSO, GSO, GRO a LRO a defaultní MTU 1500. Ale zkuste si přidat do hry connection tracking s trochu rozsáhlejší sadou pravidel a k tomu třeba vxlan, tam už to začne být zajímavé. (To není nějaký hypotetický scénář, to je situace, se kterou se zákazníci řešení založených na openstacku potkávají každou chvíli.)

Ještě k tomu zbytku vašeho komentáře. Celkem vás chápu, já také mám vůči GPL výhrady, které jsou v mnoha ohledech dost podobné vašim. Pokud bych psal něco od nuly, tak bych také použil nějakou volnější licenci. Většinou ale spíš pracuji (ať už v práci nebo ve volném čase) na existujících projektech, takže tam je licence daná.

Všimněte si ale jedné podstatné věci. Píšete, že firmám se licenčně víc líbí BSD systémy a mnohé jim dávají přednost. Jenže to se bavíme o firmách, které ty systémy chtějí používat. Pokud se ale podíváte, jak je to s ochotou podílet se na (upstreamovém) vývoji a přispívat do těch systémů, zjistíte, že tam je situace přesně opačná - a že je to rozdíl spíš v řádech než v násobcích. Samozřejmě si nedělám iluze, že je to výsledek nějakého nezištného altruismu; Intel, AMD, Mellanox, Broadcom a další potřebují co nejlepší podporu svého hardware, Google a Facebook síťový stack, který by zvládal enormní provoz jejich služeb, Microsoft potřebuje, aby linuxové guesty běžely pod HyperV srovnatelně dobře s řešeními od konkurence atd.

Na rozdíl od mnoha jiných nejsem přesvědčen, že je to výhradně zásluha GPL, ale nemůžu nevidět, že svou roli to hraje. Jedna věc je, že BSD systémy vám umožní distribuovat upravený nebo na BSD založený systém, aniž byste dal své změny k dispozici, jiná věc je, že pokud svá vylepšení pošlete do upstreamu, tak je okamžitě může použít vaše konkurence ve svých closed source produktech, aniž byste z toho něco měl. V případě Linuxu to konkurence v closed source nepoužije (nebo by aspoň neměla) a to, čím přispějí oni, budete mít zase k dispozici vy.

Co se týká právníků, to je kapitola sama pro sebe a jejich obavy a zákazy bych nepovažoval za úplně směrodatné. Vím třeba o firmě, která spravuje v linuxovém jádře jeden modul, ale právní oddělení zakázalo jejím zaměstnancům přispívat do jádra kamkoli jinam než do toho modulu - kvůli jakýmsi mlhavým obavám ohledně intelektuálního vlastnictví (ani ten člověk, od kterého jsem to slyšel, to nebyl schopen pořádně vysvětlit, protože mu to nedávalo smysl). A také vím o nejméně jednom schopném vývojáři, pro něhož to byl jeden z hlavních důvodů k odchodu z firmy.

Pokud se ale podíváte, jak je to s ochotou podílet se na (upstreamovém) vývoji a přispívat do těch systémů, zjistíte, že tam je situace přesně opačná - a že je to rozdíl spíš v řádech než v násobcích.

Toto už nerozklíčujeme. Tam má svoji zásluhu GPL, tam má svoji zásluhu to, že Linux už je hodnotná "značka", do které se i ostatním vyplatí investovat. Docela chápu, že se dá obhájit přispívaní do Linuxu, protože ti, kteří schvalují financování přecijen pojem "Linux" slyšeli pravděpodobněji, než ostatní jména OS.

edna věc je, že BSD systémy vám umožní distribuovat upravený nebo na BSD založený systém, aniž byste dal své změny k dispozici, jiná věc je, že pokud svá vylepšení pošlete do upstreamu, tak je okamžitě může použít vaše konkurence ve svých closed source produktech, aniž byste z toho něco měl. V případě Linuxu to konkurence v closed source nepoužije (nebo by aspoň neměla) a to, čím přispějí oni, budete mít zase k dispozici vy.

Já se obávám, že toto v praxi nepředstavuje výhodu / překážku. Pokud chci něco ukradnout, tak to udělám i za cenu toho, že převezmu rámec a přepíšu si to. Pod GPL to nemusí být jiné. Podívám se na to, co jse přispěl, doplním si to a nezveřejním. Situace je ve skutečnosti stejná jako u BSD licence.

Co se týká právníků, to je kapitola sama pro sebe a jejich obavy a zákazy bych nepovažoval za úplně směrodatné. Vím třeba o firmě, která spravuje v linuxovém jádře jeden modul, ale právní oddělení zakázalo jejím zaměstnancům přispívat do jádra kamkoli jinam než do toho modulu

To je čistě věc řízení rizik. Firma ví, že prozkoumat právní problematiku v rozsahu jednoho modulu sice bude něco stát, ale pak ví svá rizika, práva a cenu za právní pomoc. Rozhodnutí je pak o tom, že čistě z opatrnosti není povoleno dělat nic, na co nebyla zpracovaná právní analýza. Zrovna toto mi přijde velmi logické.

Já se obávám, že toto v praxi nepředstavuje výhodu / překážku. Pokud chci něco ukradnout, tak to udělám i za cenu toho, že převezmu rámec a přepíšu si to. Pod GPL to nemusí být jiné. Podívám se na to, co jse přispěl, doplním si to a nezveřejním. Situace je ve skutečnosti stejná jako u BSD licence.

Já přeci jen vidím dost podstatný rozdíl v tom, že v případě BSD licence dotyčný nemusí přepisovat nic a jeho počínání bude zcela legální a v souladu s literou i duchem té licence. U GPL je to jednoznačně proti duchu a i to přepsání může být právně diskutabilní, pokud to od základu znovu nenapíše někdo, kdo neviděl původní verzi.

Já jsem věděl, že s vámi najdu společnou řeč. Jenže toto není problém právníků, ale GPL licence samotné, vždyť i samotní tvůrci ji podle mě nejsou schopni konsistentně interpretovat. Je mě naprosto jasné, že nelze prelicencovat, ale tak to samé přece nelze chtít po ZoL. Co nechápu je ta změna v 5.0 kernelu, byl to úklid kódu a proč tak pozdě. Nejsem jaderný developer, ale vede odtud nějaká cesta? Jako například vlastní implementace zmíněných funkcí?
PS: nejvtipnější na tom je, že FreeBSD zvažuje přechod na ZoL, by se ten projekt mohl přejmenovat ne? ... Trocha ironie na odlehčenou.

Je mě naprosto jasné, že nelze prelicencovat, ale tak to samé přece nelze chtít po ZoL.

Podle mne je ta otázka zcela legitimní. V době, kdy Sun zvolil při zveřejnění licenci CDDL, tu už Linux dávno byl, byl to už dlouho jeden z nejvýznamnějších OS a IMHO i nejvýznamnější open source OS. Pokud tedy Sun zvolil CDDL, dal tím jasně najevo, že o ZFS v Linuxu nestojí. Takže je IMHO zcela logický úhel pohledu, že je věcí Oracle, jestli dál sdílí tehdejší postoj Sunu, tím spíš, že Oracle sám má na Linuxu založenou nezanedbatelnou část svého businessu.

Co nechápu je ta změna v 5.0 kernelu, byl to úklid kódu a proč tak pozdě.

To není pozdě, podobné "úklidové práce" se provádějí prakticky pořád, jen si většiny z nich nikdo nevšimne a není kolem toho takový poprask. Je celkem běžné, že někdo nevědomky odstraní poslední volání nějaké funkce a pokud není static, nemusí si toho nikdo všimnout třeba i pár let.

vede odtud nějaká cesta? Jako například vlastní implementace zmíněných funkcí?

Možnosti jsou různé, jednou je např. ta, o které mluví tato zprávička (která zmiňuje, že se vlastně ani neví, jestli tam je výkonový propad a jak velký).

Spíš bych upozornil na dva detaily, o kterých se moc nemluví. Za prvé, bez ohledu na _GPL, každý, kdo se ve zdrojácích jádra trochu orientuje, ví, že úzus je takový, že symboly začínající dvěma podtržítky jsou typicky interní helpery, a nelze je obecně považovat za externí API a už vůbec ne stabilní API. Za druhé, rozdíl mezi __kernel_fpu_be­gin() a kernel_fpu_be­gin() je jen v zakázání preempce, takže přijmeme-li Gregův výklad EXPORT_SYMBOL_GPL(), nedávalo moc smysl, aby jedna z těch funkcí byla exportovaná bez _GPL a druhá s ním. Přesto nevím o tom, že by se někdo zkusil zeptat Ingo Molnara (který tam to _GPL dal), jestli by souhlasil s opravou na EXPORT_SYMBOL() nebo že by někdo poslal patch, který by to změnil (což se už několikrát stalo v podobných případech v minulosti). Místo toho se nepochopitelně pokusili revertovat ten cleanup, což pochopitelně narazilo na odpor, a spustil se humbuk po fórech, který také ničemu neprospěje.

V každém případě nevidím moc optimisticky dlouhodobé udržování tak komplikovaného filesystému jako ZFS ve formě out-of-tree modulu. Takovéhle - a závažnější - problémy prostě budou průběžně přicházet a ne vždy je půjde triviálně a bez ztrát obejít Takže pokud Oracle nezmění svůj postoj, je IMHO na místě otázka, nakolik je hojně rozšířené přesvědčení, že ZFS je něco, co v Linuxu bezpodmínečně potřebujeme, založeno na technických argumentech a nakolik je spíš odrazem fandovství, stejně jako to kdysi bylo třeba s reiserfs 4. Samozřejmě by také bylo žádoucí, aby si veřejnost konečně uvědomila, že tím, kdo dal použití ZFS v Linuxu do cesty největší překážku, byl Sun, nebyl to ani Sebastian Siewior, ani Ingo Molnar, ani Greg KH, ani vývojáři linuxového VFS.

V době, kdy Sun zvolil při zveřejnění licenci CDDL, tu už Linux dávno byl, byl to už dlouho jeden z nejvýznamnějších OS a IMHO i nejvýznamnější open source OS. Pokud tedy Sun zvolil CDDL, dal tím jasně najevo, že o ZFS v Linuxu nestojí.

Tohle je argument Aničky a Pepíčka na pískovišti, kdo viděl dřív bábovičku. ZFS tu také bylo, a také významné. Já ale pořád nějak nechápu větu "ZFS o Linux nestojí". Do háje, přeci tady nejde o to, jestli Oracle stojí o Linux, ale o to, že uživatelé Linuxu by si ZFS přáli.

Přesto nevím o tom, že by se někdo zkusil zeptat Ingo Molnara (který tam to _GPL dal), jestli by souhlasil s opravou na EXPORT_SYMBOL() nebo že by někdo poslal patch, který by to změnil (což se už několikrát stalo v podobných případech v minulosti). Místo toho se nepochopitelně pokusili revertovat ten cleanup, což pochopitelně narazilo na odpor, a spustil se humbuk po fórech, který také ničemu neprospěje.

Takže Pepíček přesně ví, o co jde. Anička totiž nechce bábovičku, ale potřebuje se natáhnout pro lopatičku. Jenže Pepíček, protože mu Anička do bábovičky kopla, tak jí lopatičku nedá a ještě Aničku udeří.

Pane kolego, tohle je fakt pod úroveň. Mně např. přijde logické v prvním kroku revertovat patch, upozornit na side-effecty, a nechat autorovi "cleanupu", aby se vyjádřil (např. jestli to nechá v původním stavu, nebo vymyslí další patch, co to vrátí zpět). Jestli je důvodem celé kauzy uražené ego, je to smutné.

ZFS tu také bylo, a také významné.

Byl - a jeho zdrojáky nebyly k dispozici, takže linuxoví uživatelé, kteří "by si ho přáli" měli smůlu. Pak byl zveřejněn, ale záměrně a vědomě pod licencí nekompatibilní s linuxovým jádrem, takže se až tak moc nezměnilo. A to je celá podstata problému. Sun sice zveřejnil zdrojáky, ale takovým způsobem, aby ZFS do linuxového jádra začlenit nešel. Když SGI zveřejnili XFS a když IBM zveřejnili JFS, tak takové obstrukce nedělali a oba filesystémy se celkem rychle do jádra dostaly. Opravdu nevidíte ten zásadní rozdíl?

Z nějakého záhadného důvodu ale ty zástupy ukřivděných diskutérů, kteří "by si přáli", neviní ze vzniklé situace Sun (dnes Oracle) a nepožadují nápravu po nich, ale viní linuxové vývojáře a maintainery a nápravu požadují po nich. A z ještě záhadnějšího důvodu jsou přesvědčeni, že jen proto, že se někdo rozhodl přes ten základní a zásadní problém naroubovat ZFS na Linux ve formě out-of-tree modulu, jsou maintaineři povini zapomenout na všechno ostatní a od teď až na věky věků opatrně našlapovat, aby náhodou ten domeček z karet někde nepoškodili. Mohu vás totiž ujistit, že tohle není zdaleka poslední problém se "ZFS on Linux" a že přijdou další a některé z nich budou mnohem hůře řešitelné (jen tak z hlavy vím třeba o plánech umožnit, aby se při exportování souboru omezila viditelnost toho exportu jen na konkrétní moduly).

Mně např. přijde logické v prvním kroku revertovat patch

Já na tom vůbec nic logického nevidím. Commit, který funkci volanou v celém jádře jen z jednoho jediného místa přesune do stejného souboru a deklaruje ji jako static je ve všech ohledech naprosto v pořádku a není sebemenší důvod ho revertovat. Pokud se dodatečně zjistí, že tu funkci volal nějaký out-of-tree modul, je to zcela nezávislý problém, který by se měl také zcela nezávisle řešit; tím spíš pokud se ukáže, že ta funkce nebyla nikdy určena k tomu, aby ji volaly out-of-tree moduly a že i tenhle ji vlastně volal z důvodu, který značně zapáchá.

Pane kolego, tohle je fakt pod úroveň.

To je a jsem moc rád, že si to uvědomujete, jen nerozumím tomu, proč jste ty bláboly o Aničkách, Pepíčcích a pískovištích psal, když si uvědomujete, jak moc to je "pod úroveň". Jestli se tu totiž někdo chová jako Pepíček na pískovišti, tak spíš ten, kdo (v duchu vašeho příměru) kolem sebe plácá ručičkama a vykřikuje "Já chci! Já chci!" a odmítá si nechat vysvětlit, že některé věci jsou holt trochu složitější, než mu to s jeho úrovní informovanosti připadá.

Byl - a jeho zdrojáky nebyly k dispozici, takže linuxoví uživatelé, kteří "by si ho přáli" měli smůlu. Pak byl zveřejněn, ale záměrně a vědomě pod licencí nekompatibilní s linuxovým jádrem, takže se až tak moc nezměnilo.

To je pořád dokola ta písnička o tom hodném a zlém. Na to bych se vykašlal a hledal bych cestu jak umožnit ZFS žít. Jestli tomu dobře rozumím, ZoL nechce nic jiného, než mít přístup k nějaké poměrně elementární funkci, ale na druhé straně není ochota. Bohužel, víc to vypadá, že je to "na oplátku", než že by to bylo neřešitelné.

Pokud se dodatečně zjistí, že tu funkci volal nějaký out-of-tree modul, je to zcela nezávislý problém, který by se měl také zcela nezávisle řešit; tím spíš pokud se ukáže, že ta funkce nebyla nikdy určena k tomu, aby ji volaly out-of-tree moduly a že i tenhle ji vlastně volal z důvodu, který značně zapáchá.

Chápu Vás, ale přijde mi to opravdu zbytečně formalisticky pojaté. ZoL je významný projekt a minimálně to slovo navíc, nebo posečkání, než se vyjasní situace, by si zasloužit mohl, nikoho by to nezabilo.

Jestli se tu totiž někdo chová jako Pepíček na pískovišti, tak spíš ten, kdo (v duchu vašeho příměru) kolem sebe plácá ručičkama a vykřikuje "Já chci! Já chci!" a odmítá si nechat vysvětlit, že některé věci jsou holt trochu složitější, než mu to s jeho úrovní informovanosti připadá.

Ale jo, však já jsem psal, že i Anička má svůj díl viny, šla bezohledně za lopatičkou a rozkopla Pepíčkovi bábovičku.

Popravdě řečeno, mě už to přestává bavit. Zaprvé tyhle žabomyší války nikomu neprospějí.
ZoL není mrtvý a nebude, minimálně v nějaké formě přežije v BSD, i za cenu toho že by se měli vývojáři přesunout k BSD. Filesystém je to robustní, masivně komerčně používaný i v korporátní sféře (narozdíl od BRTFS)
Zadruhé viděl jsem také debatu mezi právníky, a hodně z nich se se shoduje, že jsou nekompatibilní v doslovné liteře zákona, nikoliv v principu (takže by to s největší pravděpodobností soud připustil). Myslím že v OSS je by mělo být důležité šíření zdrojového kódu a to obě licence umožňují beze sporu. Debata vždy bohužel skončí na pro mě militantním postoji GPL.
Take by bylo dobré zmínit, že CDDL ne vlastně ucesana MPL, která až do verze 2.0 byla také nekompatibilní s GPL. Nutné podotknout, že CDDL je kompatibilní s Apache a BSD licencemi. Takže z mé strany je problém s GPL, která je dnes už zbytečně omezující. Ale to je jen můj názor, tak do mě ;)

Větší ... než vzít kód Oracle, protože je možná kompatibilní s duchem licence jsem dnes neviděl a to jsem i kouknul na Twitter Svobodných. Oracle!

(A ano ZFS je skvělý. A ano, GPL není moc povedená.)

ale naprosta vetsina korporatu v produkci btrfs nema

A přesně totéž platí i pro ZFS. :-)

Tak na ten Facebook bych argumentoval CERN který používá ZFS v úložišti dat, dále například IBM Sequoia (supercomputer), jehož paralel storage system Lustre používá ZFS pro cílové ukládání na disk. Co se týče korporací můžeme zmínit OVH, Proxmox, iXsystems, atd... Samozřejmě nesmíme zapomenout na Oracle.

Ještě se vrátím k tomu Facebooku, pokud vím, tak Facebook BRTFS nepoužívá k data storage, ale jako snapshot storage pro containery.

Nechapejte mě špatně, já mám v celku i rád BRTFS, ale ještě má prostě daleko k tomu abych mu věřil a popravdě řečeno to už více věřím NTFS jako data storage, na kterém mame několik desítek TB mssql, nicméně primární data máme v Oracle, Informix a Teradata

Synology ok, tak já ale zas mohu vytáhnout QNAP a iXsystems. Koukněte pokud neznáte ;) ale když se podíváte podrobněji, tak adopce ZFS je přece jenom dále i diky Solaris. Mimochodem v RHEL 7.4 release notes je Btrfs označeno jako deprecated a bude odstraněno v následující major verzi. Což určitě bude mít dopad na pouziti Btrfs v korporátní sféře.

Proč by to mělo mít dopad? Red Hat AFAIK nikdy btrfs jako plně podporovaný filesystém nenabízel, pouze jako technology preview, takže nasazovat btrfs na RHEL v produkčním nasazení by byl holý nerozum. Na SLESu je samozřejmě situace jiná, ale tam se žádný ústup od btrfs neplánuje, přesně naopak.

No když v podstatě nejvýznamnější developer enterprise Linuxu ho ani nehodlá nasadit do produkce, tak to tak trochu dělá dojem, že Btrfs je hobby FS. Takže toto rozhodnutí rozšíření Btrfs tak trochu brání, nemyslíte?

To rozšíření by samozřejmě mohlo být větší, kdyby se Red Hat rozhodl jinak, ale to, že se rozhodli, jak se rozhodli, vůbec neznamená, že je btrfs nějak méněcenný nebo nepoužitelný. U enterprise distribucí je zvykem filosofie "one tool per task" a Red Hat se rozhodl preferovat jiné řešení. Je snad KDE k ničemu jen proto, že RHEL podporuje jen Gnome? Stejně tak není potřeba se obávat, že by se vývojáři btrfs zaměstnaní v Red Hatu museli začít zabývat něčím jiným, protože od roku 2012 tam stejně v podstatě žádní nebyli.

Už se tu ejdnku řešilo jak je Btrfs plnohodnotný a jak je hrozně rozšířený díky Synology. Tak si pojďme nalít čistého vína, samotné Synology Btrfs RAID věří natolik, že ho radši nepoužívá a a běží nad Btrfs Linux RAID. Ten filesystém jednou možná bude použitelný, ale rozhodně ne nebude v příštím desetiletí. Kromě Suse mu chybí podpora velkých hráčů a obecně převažuje nedůvěra. Ani Suse si netroufne ho jako detaily nasadit na datová partitions a mají ho jen na root.

To je pořád dokola ta písnička o tom hodném a zlém.

Hodného a zlého do toho pletete jen vy, já jsem nic takového nepsal. Jen se snažím vysvětlit, že v době zveřejnění ZFS byla licence linuxového jádra dávno daná a dávno už byla situace taková, že i kdyby ji chtěl Linus změnit, stejně by to udělat nemohl, dokonce ani kdyby se k němu připojilo dvacet nejvýznamnějších maintainerů, tak by to nešlo. To není o žádném hodném a zlém, to je reálné zhodnocení situace: Linux svou licenci změnit nemůže, takže veškeré řeči o tom, jak je špatná, jsou úplně zbytečné. Ta licence tu prostě je a taková i zůstane.

Může-li někdo tu nešťastnou situaci opravdu vyřešit, je to Oracle. Proto tvrdím, že by se pozornost těch, kdo ZFS v Linuxu tak moc chtějí, měla zaměřit na něj. To není nic o hodném a zlém, to je o tom, kdo (1) tu situaci způsobil a (2) s ní může něco dělat.

ZoL je významný projekt

Z hlavy a bez velkého přemýšlení vám vyjmenuji nejméně pět přinejmenším stejně "významných" (ve smyslu, že jsou na linuxových systémech hojně používané) out-of-tree modulů: nvidia, vmware, virtualbox, DPDK, veritas, MPTCP, ... A to je jen to, co mi utkvělo v paměti natolik, že se mi to okamžitě vybavilo, ve skutečnosti by ten seznam byl mnohem delší. "ZFS on Linux" vůbec není tak unikátní a výjimečný, aby se z něho maintaineři Linuxu posadili na zadek a dávali pozor, jestli se v něm náhodou něco nerozbije. Pro člověka nahlížejícího optikou "je strašně super, já ho moc chci, nemůžu bez něj fungovat" je to obtížně stravitelné, ale tak to prostě je.

nebo posečkání, než se vyjasní situace

Nevidím důvod. Ještě nemáme ani rc3, 5.0 vyjde nejdříve za pět týdnů a dočasné řešení už navíc je k dispozi (o tom je ostatně tato zprávička). Tak proč honem revertovat commit, který je naprosto v pořádku? Jestli někdo používá out-of-tree moduly v kombinaci s rcX verzemi jádra (což třeba já zrovna na jednom počítači dělám), tak musí počítat s tím, že občas narazí na problémy, kteřé buď bude muset vyřešit sám nebo počkat, až to udělá někdo jiný (já s tím srozuměn jsem).

Tohle je prostě klasická situace typu "you have been warned". Ale ať to varování uděláte sebevýraznější, stejně se dříve či později najde někdo, kdo udělá to, o čem jste ho varovali, že to čas od času přestane fungovat, a pak bude vinit vás, že vy za to můžete.

Ale jo, však já jsem psal, že i Anička má svůj díl viny, šla bezohledně za lopatičkou a rozkopla Pepíčkovi bábovičku.

Nějak se v těch vašich infantilních přirovnáních ztrácím, takže si nejsem jistý, kdo má být Pepíček, kdo Anička, co je bábovička a co lopatka. Jazykem dospělých vývojáři Linuxu od začátku jasně deklarovali, že žádné stabilní API pro moduly jádra negarantují (spíš garantují, že stabilní nebude) a že na out-of-tree moduly brát ohledy nebudou; a teď je najednou (ne poprvé) strašný humbuk jen proto, že se chovají přesně podle toho, na co od začátku jasně a zřetelně upozorňovali.

vývojáři Linuxu od začátku jasně deklarovali, že žádné stabilní API pro moduly jádra negarantují (spíš garantují, že stabilní nebude) a že na out-of-tree moduly brát ohledy nebudou; a teď je najednou (ne poprvé) strašný humbuk jen proto, že se chovají přesně podle toho, na co od začátku jasně a zřetelně upozorňovali.

Už budu reagovat jen na tuto větu, ale i to už se opakuju: já neupírám vývojářům mí takový postoj a držet se ho. Jen si o takovém příliš upjatém postoji myslím své, z mého pohledu to zbytečně hrotí.