Hlavní navigace

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

Sdílet

Jan Fikar 17. 1. 2019
Puzzle ZFS Linux

Kernel 5.0 přestal exportovat dvě FPU funkce, což znemožňuje kompilaci ZFS on Linux (ZOL). Dočasné řešení navrhl Tony Hutter. Pokud je použito jádro 5.0, nelze použít SIMD (SSE a AVX) instrukce ke kontrolním součtům. Vektorové instrukce budou v takovém případě zakázány. To se samozřejmě podepíše na výkonu, otázkou je jak moc.

(zdroj: phoronix)

Našli jste v článku chybu?
  • Aktualita je stará, nové názory již nelze přidávat.
  • 17. 1. 2019 19:29

    RDa

    A to nemuze ZOL vyuzivat akcelerovane funkce jadra pro vypocet hashu? Vzdyt je tam kazda standardni (kdyz se zapne). Prijde mi ze ZFS vynaleza kolo stejne jako Reiser..

  • 17. 1. 2019 20:16

    Rhinox (neregistrovaný) 88.151.74.---

    Cim dal tim vice se ukazuje, ze ZFS nemuze byt "tim pravym" next-gen filesystemem pro Linux. Tenhle licencni zmatek nejde nijak rozseknout, proto je lepsi se na to vys*at a hledat nekde jinde. Priznejme si konecne, ze ZFS je z hlediska Linuxu slepa vetev vyvoje.

    Proc plytvat zdroje na ZoL, kdyz to zjevne nikam nevede, jen porad k dalsim problemum? Radsi dovest do stabilniho stavu btrfs/bcachef­s/stratis, nebo nakej jinej fs...

  • 17. 1. 2019 20:44

    Miroslav Šilhavý

    Ono spíš podivně vypadá blokování funkcí (exportu symbolů) pod podmínkou GPL. Je to určitý typ naschválu, poměrně zbytečný. ZFS (a jiné projekty) se nikdy nestanou integrální součástí jádra, právě kvůli licenci. Proč je ale potřeba to "osolit" ještě tím, že nepůjdou používat ani externě, těmi, kteří chtějí?

    Dále můžeme uvažovat o tom, že by jednoho dne mohl Linux vůbec začít vyžadovat, aby i v userspace běžely pouze GPL binárky. Mělo by to tu samou logiku: proč by mělo GPL jádro podporovat běh něčeho s jinou licencí?

    EXPORT_SYMBOL_GPL si ve výsledku moc nezadá s hojně kritizovanými DRM systémy. Ty také slouží k tomu, aby si "ten druhý" ani neškrtl.

    Linuxu tento přístup nesluší.

  • 17. 1. 2019 21:15

    RDa

    Souhlasim. Ale ono cele GPL je takove "rakovinove". Clovek aby se bal napsat pomalu jakykoli kod, protoze ho obvini z toho ze to ukrad z GPL, byt se jenom treb inspiroval. By me zajimalo zda je prevzati algoritmu poruseni licence, nebo se za to povazuje jenom copy+paste. Je prevzati seznamu #defines poruseni gpl, kdyz tyhle defines popisuji napr. adresy periferii ci registru v ramci nejakeho zarizeni?

  • 17. 1. 2019 21:25

    Miroslav Šilhavý

    Otázky, které píšete, jsou právě docela nejasné.

    Když půjdete do historie, tak u literárního díla nesmělo docházet k opisům statí (byť i s obměnami), které nesly "náboj" původního díla. Nicméně, námět obšlehnout lze - viz např. převyprávění Defoeova Robinsona Crusoe J. V. Plevou nebo F. Novotným.

    U hudebního díla se ustálila zvyklost na určitém počtu taktů nebo délce v sekundách. Ale ani to neplatí úplně. Např. Madonna ve své Hung Up použila opravdu kratičký sample z ABBA Gimme! Gimme! Gimme! (A Man After Midnight), přesto k tomu měla výslovné svolení. Protože ten motiv je na tolik výrazný, že je nutné ho považovat za samostatné autorské dílo.

    Přepsat kód lze. Jsou elementární funkce, které se nedají přepsat moc jinak, než je originál. Ale zde platí pravidlo, že takto elementární "díla" nelze autosky chránit (nelze chránit funkci na součet, násobení, ...). Osobně si myslím, že FPU funkce spadají spíš do této kategorie a nemělo by se snažit o jejich licenční ochranu.

    Pak jsou ale větší softwarové celky. Ty můžete obšlehnout co do vstupů a co do výsledku. Pokud ale zvolíte stejný postup (spád programu) jako původní autor, bude to porušení autorských práv i v případě, pokud to přepíšete. Např. tak jednoduchý program jako kalkulačka, nebo, abychom byli ještě skromnější, řekněme "bc" - to už jsou programy, které se dají přepsat od základu a každý programátor je přepíše jinak, i když navenek budou fungovat stejně.

  • 17. 1. 2019 21:30

    PetebLazar (neregistrovaný) 2a00:1268:1f:----:----:----:----:----

    Ty value možná ne (ty budou nejspíš vycházet ze specifikací), ale ty CNAME (vytvořené autorem kódu?) již asi budou předmětem licence.

  • 17. 1. 2019 22:17

    Lol Phirae (neregistrovaný) 2001:470:6f:----:----:----:----:----

    Ale ono cele GPL je takove "rakovinove"

    Tak stále ještě to bude méně rakovinové než SSPL, které je tak rakovinové, že postižený software rovnou vyhodili z Debianu, z Fedory a RHEL.

    Nic nepotěší víc, než když se někdo pořádně střelí do nohy. :-D U těchhle NoSQL frikulínů se jedná asi o nějakou epidemii nebo soutěž o největší demenci, viz Redis a jejich Commons Clause, revoluce "překvapivě" ani zde úspěchem neskončila.

  • 18. 1. 2019 7:00

    Milan Juřík (neregistrovaný) ---.net.upcbroadband.cz

    Je zajímavé, jak dorůstají nové generace nepamatující si počítačový středověk. GPL je cíleně takto sestavená, tak, aby tlačila svět k otevřenosti. Jen GPL2 nepočítala s tím, že v rámci obrany otevřenosti může existovat otevřená licence požadující něco navíc.

  • 18. 1. 2019 7:18

    Miroslav Šilhavý

    Je zajímavé, jak dorůstají nové generace nepamatující si počítačový středověk. GPL je cíleně takto sestavená, tak, aby tlačila svět k otevřenosti. Jen GPL2 nepočítala s tím, že v rámci obrany otevřenosti může existovat otevřená licence požadující něco navíc.

    Středověké zákony už neplatí. Společnost se vyvíjí, a jakmile se dosáhne určitého cíle, zákony se mění a chrání hodnoty, které je potřeba chránit v nové době. Hezkým příkladem je např. Zákoník práce. Pod jeho zněním z minulých dob by už nikdo pracovat nechtěl. Občanský zákoník taktéž - za posledních 100 let máme už čtvrtou rekodifikaci.

    GPL byla ve své době naprosto nenahraditelná a odvedla přesně takovou práci, jakou si předsevzala. Bez GPL bychom dnes neměli Open Source tak, jak ho vnímáme. Na druhou stranu, možná už je právě doba, kdy je na čase si říct: Open Source už není v ohrožení, ale stojí před námi nové výzvy.

    Novými výzvami myslím např. toto. Před dvaceti lety byl Open Source postaven antagonisticky proti zájmům korporací, OSS s nimi soupeřil. Korporace dlouho neuměli OSS konkurovat (snažily se, ale zjistili, že OSS je založený na jiných hodnotách). Jaká je situace dnes? Korporace si Open Source ochočily. Google zkrotil velkou část Linuxu, Microsoft kombinuje sílu svých a OSS systémů, Apple svůj systém vystavěl z výsledků práce OSS. Tj. vidím tu posun znovu zpět ve prospěch korporací. S trochou nadsázky: "OSS idealisté" dělají marketing a vyvýjejí s přesvědčením pro dobro světa. Korporace, i přes GPL, z toho umějí vydělat dolar.

    GPL, či obecně OSS licence by se měly zaměřovat na aktuální výzvy a ne pouze bezmyšlenkovitě trvat na dogmatech platících před několika dekádami.

  • 18. 1. 2019 12:34

    ja. (neregistrovaný) 195.12.136.---

    Nepovedal by som, ze korporacie si OSS skrotili.

    Apple ignoruje GPL: ma stary bash (pred zmenou na GPL3), sambu nahradili svojim serverom a klientom, gcc nahradzaju clangom.

    Microsoft, podobne ako Apple, preferuje BSD/MIT/Apache, GPL ignoruje.

    Google GPL neignoruje, pri poskytovani sluzieb to nie je problem (to az AGPL), a vacsina Androidovych vendorov porusuje GPL. Tych zopar, co ju neporusuju, symbolicky vyhodia niekam na ftp zdrojaky jadra, ktore su aj tak nepouzitelne, pretoze im chybaju drivery a zariadenia su tivoizovane, co zase riesi az GPL3 a Torvalds ju specificky nechce.

  • 18. 1. 2019 12:39

    Lojza

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

  • 18. 1. 2019 13:52

    ja. (neregistrovaný) 195.12.136.---

    Tak by bol Linux tak pozadu, a riesil rovnake problemy ako napr. OpenBSD, namiesto toho, aby ich mal vyriesene uz 10-15 rokov.

    Plus by sme mali niekolko rozlicnych forkov... rovnako ako ma BSD.

  • 18. 1. 2019 12:40

    ivoszz

    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?).

  • 18. 1. 2019 13:51

    ja. (neregistrovaný) 195.12.136.---

    To si upravil uz predrecnik - zacal o GPL, potom plynulo presiel na OSS.

    Moja pointa bola, ze pre korporacie predstavuje GPL rovnaky problem, ako pred 20 rokmi, a ziadne skrotenie sa nekona.

  • 17. 1. 2019 22:19

    Michal Kubeček

    Dále můžeme uvažovat o tom, že by jednoho dne mohl Linux vůbec začít vyžadovat, aby i v userspace běžely pouze GPL binárky. Mělo by to tu samou logiku: proč by mělo GPL jádro podporovat běh něčeho s jinou licencí?

    Než začnete vyvozovat podobné závěry, udělejte si malý domácí úkol: podívejte se, jaký SPDX identifikátor mají hlavičkové soubory v include/uapi a dohledejte si, co znamená část " WITH Linux-syscall-note". Nebo se rovnou ve zdrojácích jádra podívejte do souboru COPYING a souborů, na které se odkazuje, a to zejména LICENSES/excep­tions/Linux-syscall-note .

  • 18. 1. 2019 7:10

    Miroslav Šilhavý

    Než začnete vyvozovat podobné závěry, udělejte si malý domácí úkol:

    Dobrý den,
    asi jsem se vyjádřil nesrozumitelně. Já vůbec nezpochybňuji právo autora na určení licence, ani to, jaká ta licence je. Rozumím i důvodům.

    Moje úvaha byla spíš o tom, jakou filozofii linux vyznává. EXPORT_SYMBOL_GPL je z mého pohledu určitá forma naschválismu. Vím, že vyplývá ze situace, přesto si myslím, že současný důsledek (že nelze z externího kódu zavolat FPU funkce) nebyl zamýšlený účel těch, kteří svobodné licence vymýšlejí a prosazují.

    Moje úvaha o omezení v userspace byla tedy jen jakýmsi příměrem, kam by až mohly podobné směry zajít. Tj. jakási redukce ad absurdum, upozornění na to, jakým směrem se výklad licence ubírá.

    EXPORT_SYMBOL_GPL vidím jako určité DRM v rámci OSS. Je to prostředek na ochranu práv autorů, aby bylo splněno to, co vyznávají. Potud to vidím jako správné.

    Na druhou stranu vedu protiúvahu, jestli už nejsme od prapůvodní myšlenky GPL možná až moc daleko. Jestli toto opatření fakticky chrání nějaké hodnoty, nebo jestli se jedná přeformalizované uplatnění GPL. Jak to vypadá, když se nějaký předpis vykládá příliš formalisticky vidíme často u české finanční správy.

    ZoL by měl existovat. ZFS je používaný filesystem. Sebrat uživatelům Linuxu možnost připojit ZFS mi nepřijde jako obohacení. Myslím, že Linux se vymezil dostatečně tím, že ZFS se nikdy nestane součástí jádra. ZoL nezbyde, než aby si chybějící funkce do jádra doplnila v rámci svých patchů. Budeme mít zdvojený kód, zdvojené riziko bugů. Jen kvůli neochotě najít kompromis na tom, co smí non-GPL projekt z jádra volat.

  • 18. 1. 2019 8:04

    Michal Kubeček

    Moje úvaha o omezení v userspace byla tedy jen jakýmsi příměrem, kam by až mohly podobné směry zajít. Tj. jakási redukce ad absurdum, upozornění na to, jakým směrem se výklad licence ubírá.

    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. Tím je dán naprosto zásadní rozdíl mezi userspace programem používajícím syscally (a případně další rozhraní jako netlink, proc nebo sysfs) a modulem, který je v linuxovém pojetí přímo součástí jádra. Vztah jádra a modulů spíš odpovídá tomu, jak v userspace fungují PAM nebo NSS moduly, případně moduly např. u PHP nebo dalších aplikací. (Tam ovšem nikdo nezpochybňuje, že modul musí mít licenci kompatibilní s hlavním programem nebo knihovnou.)

    Myslím, že Linux se vymezil dostatečně tím, že ZFS se nikdy nestane součástí jádra.

    Ne Linux ale Sun (dnes Oracle). Linus zvolil licenci Linuxu někdy v roce 1991 nebo 1992 a 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, která není s GPL kompatibilní, přičemž je úplně jedno, jestli opravdu byla záměrně navržená za tím účelem nebo je to jen vedlejší efekt. Výsledek prostě je takový jaký je a u Sunu to moc dobře věděli. Jaké k tomu měli důvody, to je jejich starost, ale tvrdit, že je to "Linux", kdo brání využití tohot kódu k implementaci ZFS v Linuxu, je hrubé zkreslování skutečnosti.

    Jen kvůli neochotě najít kompromis na tom, co smí non-GPL projekt z jádra volat.

    Jak už jsem upozornil v minulé diskusi, už sama přípustnost šíření modulů jádra pod non-GPL licencí (přesněji: sadou licencí neobsahující GPL 2.0) je diskutabilní. Linus se sice v minulosti vyjádřil ve smyslu, že mu to nevadí, ale jednak to není totéž jako říct, že je to licenčně v pořádku, jednak zdaleka ne všichni tento názor sdílejí. Ruku na srdce: kdybych měl zdůvodnit, proč je v pořádku non-GPL jaderný modul, ale ne userspace "modul", tj. *.so linkovaný za běhu pomocí dlopen(), asi bych se brzy přistihl, že jsem nucen používat vykonstruované argumenty, které neznějí přesvědčivě ani mně samotnému.

    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. Ale nemění to nic na tom, že ani v jednom případě nemá nikdo cizí právo vlézt dovnitř bez mého svolení (pomineme-li speciální případy typu policie s povolením k domovní prohlídce nebo hasiče při požáru).

  • 18. 1. 2019 8:19

    Miroslav Šilhavý

    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!

  • 18. 1. 2019 8:47

    Lol Phirae (neregistrovaný) 2001:470:6f:----:----:----:----:----

    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.

  • 18. 1. 2019 8:49

    Miroslav Šilhavý

    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).

  • 18. 1. 2019 9:05

    Michal Kubeček

    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.

  • 18. 1. 2019 9:19

    Miroslav Šilhavý

    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.

  • 18. 1. 2019 10:08

    Michal Kubeček

    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.

  • 18. 1. 2019 11:08

    Miroslav Šilhavý

    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.

  • 18. 1. 2019 11:38

    Michal Kubeček

    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.

  • 18. 1. 2019 11:48

    Miroslav Šilhavý

    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ší.

  • 18. 1. 2019 13:52

    Michal Kubeček

    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.

  • 18. 1. 2019 12:36

    ivoszz

    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.

  • 18. 1. 2019 13:50

    Johanka (neregistrovaný) 2a01:430:30:----:----:----:----:----

    A který že z těch jedenácti stejně odsazených příspěvků podepisujete? :-)

  • 18. 1. 2019 13:47

    Michal Kubeček

    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.

  • 18. 1. 2019 14:11

    Miroslav Šilhavý

    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ě.

  • 18. 1. 2019 14:54

    Michal Kubeček

    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.

  • 18. 1. 2019 15:00

    Michal Kubeček

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

  • 18. 1. 2019 16:11

    jdsulin2 (neregistrovaný) 213.155.226.---

    Protoze jaderni vyvojari na OOT modely mohou zvysoka ****. Je to dobre, neni to dobre, netusim, ale binarni bloby a drivery jsou proste pro linuxove jadro problem. U ZOL, protoze to resi FS, ktery je vice spjaty s jadrem, nez jine moduly to je problem. A rekl bych, ze doslo k nasledujicimu:
    Situace pred:
    EXPORT_SYMBOL(__ker­nel_fpu_begin)
    EXPORT_SYMBOL_GPL(ker­nel_fpu_begin)
    Situace po:
    EXPORT_SYMBOL_GPL(ker­nel_fpu_begin)

    Proste zrusili EXPORT_SYMBOL(__ker­nel_fpu_begin), protoze to nikdo v jadre uz nepouzival. A takove veci se proste deji.

    A vubec nechapu ty vykriky tady - pokud mas kompatibilni licenci, tak nemas problem. Pouzijes BSD licenci a wrapper na proprietarni cast a v klidu si EXPORT_SYMBOL_GPL pouzivas. V tomto stojim 100% za linuxem - Sun proste nechtel licenci kompatibilni (o tom taky muzeme vest spory), tak pouzil CDDL. Proc by mu meli jit jaderni vyvojari naproti. Podpora proprietarnich modulu znamena uzavrenost, nekompatibilni zarizeni, ktere nikdo nerozjede, atd. je to proste kratkozrake. Nic nestoji v ceste tomu, aby nastupce Sunu - Oracle zmenil licenci na kompatibilni s GPL a bylo by po problemu, coz neudela. Ale vy tady radsi budete nadavat na linuxove vyvojare. Jasne kdyz se jedna o neco takoveho jako je ZFS, kde teoreticky muze oproti BSD se ZFS ujizdet vlak, ale to je cesta do pekel. BSD se sice muze ohanet tim, jak Apple a PS jejich kernel pouzivaji, ale videl nekdo zdrojaky od jejich driveru ? Jste se zblaznili ?

  • 18. 1. 2019 16:20

    Lol Phirae (neregistrovaný) 2001:470:6f:----:----:----:----:----

    No, není nad to u zcela open-source kódu blábolit o binárních blobech, proprietárních modulech a uzavřenosti. To jsou opravdu myšlenkově konsistentní a silné argumenty. :-P

  • 18. 1. 2019 23:28

    Mr. Cidermaster (neregistrovaný) ---.dyn6.twc.com

    Laskavě si ráčej zapsat za uši, že Apple v macOS žádný BSD kernel nepoužívá, tudíž se BSD nemá čím ohánět.

  • 20. 1. 2019 7:20

    Pepik (neregistrovaný) 2a00:1aac:632:----:----:----:----:----

    ZFS a binární blob? Nejdřív si o tématu něco zjistěte. :P

  • 18. 1. 2019 8:09

    madloki (neregistrovaný) ---.cust.vodafone.cz

    Asi proto, ze nic srovnatelneho v linuxu proste neni. Uprimne, zfs je duvod, proc vyrobci diskovych poli nepouzivaji linux.

    Umyslne blokovani behu software na opensource OS je poprenim principu opensource.

    Chapu, ze firmy typu redhat by linux rady uzavrely a jsou pro to ochotny udelat hodne (systemd), ale je to uz pres caru. Bud nabidni srovnatelnou alternativu, nebo neprud.

    Zfs jako kladny a systemd jako zaporny argument by mne uz davno odvedli k opensolaris, kdyby byla jeho budoucnost jistejsi a vyvoj dynamictejsi. Ale ten system pro desktop ani masivni serverove nasazeni zatim pouzitelny neni.

  • 20. 1. 2019 13:12

    Ivan (neregistrovaný) ---.nat.epc.tmcz.cz

    ZFS i btrfs financuje(finan­coval) Oracle. Slepa vetev je spise Solaris nez nejaky kontretni FS. Tuhle situaci mohou "vyresit" pravnici z Oracle, ti se ale ted snazni monetarizovat investici do SUNu - viz. licence na podporu JDK.

    Oracle je firma, ktera stoji za ZFS, brtfs, OCFS, avdFs, ACFS. Oni porad nevedi jaky je jejich vztah k Linuxu, ale maji velice jasno v tom jaky je jejich vztah k penezum. Dokud RHEL neprijde s necim vlastnim, tak to pode porad ZFS vs brtfs.

  • 20. 1. 2019 14:15

    neregistrovany (neregistrovaný) 2001:470:5aa9:----:----:----:----:----

    RH v prvom rade nema ludi, ktori by v btrfs (bTRfs, nie bRTfs; mnemonicka pomocka: "better fs", ano som si vedomy ironie) boli doma. Zatial akurat vyhadzovali peniaze na backbort aktualnej verzie do kernelu 3.10. tak sa na to pred casom vykaslali.

    Zato ale maju ludi, ktori stali pri xfs od jeho vzniku. Preto tlacia xfs. Ruku na srdce, niektore veci, ktore su sucastou zfs a btrfs by fakt mali byt sucastou volume managera a nie suboroveho systemu.

  • 21. 1. 2019 8:03

    Petr Neni (neregistrovaný) 31.216.239.---

    Ruku na srdce, evidentne nerozumis duvodum proc to neni oddelene. U 1 disku doma je to fuk, u storage s xxxTB to neni fuk.

  • 20. 1. 2019 17:00

    Ivan (neregistrovaný) ---.nat.epc.tmcz.cz

    Jeste dodam, ze Oracle prodava vlastni storage Pillar Axiom a IMHO budoucnost ZFS zavisi i na tom jak se jim bude darit v tomhle odvetvi. NetApp si taky drzi kontrolu nad WAFL. Tim nechci obhajovat Oracle nelibi se mi jak se ta firma chova, ale na druhou stranu v open-source neexistuje neco jako pravo/narok na nejaky lepsi filesystem.

  • 18. 1. 2019 8:52

    Vykook

    V kernelu se nevyznám, ale patch co by vypnul tuhle pošahanou kontrolu, by moc nemusel bejt moc velkej zásah, ne? Samozřejmě by si člověk pak musel sestavit vlastní jádro, ale to zas takový problém není...

  • 18. 1. 2019 8:50

    L. (neregistrovaný) 91.219.246.---

    Já nechápu, v čem je problém. Linuxový kernel je přece open source, tak není problém si do něj udělat patch, který export těch funkcí zase přidá. Vždyť k tomu tu přece open source je, aby si uživatel mohl program upravovat a nebyl rukojmím vydavatele SW, ne?

  • 18. 1. 2019 8:58

    Miroslav Šilhavý

    To je docela zásadní problém. Buďto se ten symbol nesmí exportovat kvůli licenci, a pak by takový patch byl protiprávní. Nebo to protiprávní není, ale pak zase pomíjí důvod pro používání EXPORT_SYMBOL_GPL.

  • 18. 1. 2019 9:10

    L. (neregistrovaný) 91.219.246.---

    Pokud si stáhnu zdrojáky Linuxu a zdrojáky ZFS, Linux opatchuju, ZFS si na opatchovaném Linuxu zkompiluji a používám (tedy patch ani ZFS nijak nešířím), tak nevidím, co by na tom mělo být protiprávního.

    Jiná věc by byla, pokud bych takto zkompilovaný ZFS modul / patch do Linuxu šířil, tam si netroufám soudit. Ale jak bylo zmíněno výše, jsou názory, že je to OK. Takže by to asi musel rozhodnout soud (?)

  • 18. 1. 2019 9:13

    Vykook

    Nechápu, proč by měla být úprava GPL kódu GPL kódem protiprávní. Kor když si to patchnu na lokálním stroji a celek s tím zfs nebudu dál šířit.

  • 18. 1. 2019 9:26

    Miroslav Šilhavý

    Nechápu, proč by měla být úprava GPL kódu GPL kódem protiprávní. Kor když si to patchnu na lokálním stroji a celek s tím zfs nebudu dál šířit.

    Protože autor dal jasně najevo, že považuje použití tohoto symbolu mimo GPL kód za protiprávní. V podstatě obcházíte technické opatření, které si autor výslovně přeje. Patrně tím spácháte trestný čin podle § 270 trestního zákoníku (https://www.zakonyprolidi.cz/cs/2009-40#p270). Trestný je samotný zásah do chráněného díla, při dalším šíření je jen vyšší maximální sazba.

  • 18. 1. 2019 9:36

    Vykook

    Jestli to dal najevo někde v nějakém mailing listu, je šumák. Rozhodující je imho licence a ta pochybuji, že něco podobného tvrdí.

  • 18. 1. 2019 9:59

    Miroslav Šilhavý

    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.

  • 18. 1. 2019 12:17

    me (neregistrovaný) ---.64.broadband2.iol.cz

    To je takove garazove reseni, ktere je uplne k nicemu... Reseni pro hracicky. Leda ze by jste vlastnil datove centrum a v nem treba nabizel verejne sluzby, pak by melo smysl energii investovat timto smerem...

  • 18. 1. 2019 12:59

    ja. (neregistrovaný) 195.12.136.---

    Urobit to pre seba mozes, akurat to nemozes distribuovat.

    GPL nema problem s tym, co si urobis pre seba; dokonca to podporuje, ze v svojom sukromi si s danym sw mozes robit co chces. Problem nastava az pri distribucii, tam musis dodrzat podmienky GPL, inak nemas pravo distribuovat povodne ani odvodene dielo vobec.

  • 18. 1. 2019 14:15

    Miroslav Šilhavý

    Urobit to pre seba mozes, akurat to nemozes distribuovat.

    GPL nema problem s tym, co si urobis pre seba; dokonca to podporuje, ze v svojom sukromi si s danym sw mozes robit co chces.

    To není pravda. Nesmíte porušit licenční ochranu (v tomto případě GPL). Pokud autoři usoudili, že některý symbol musí být chráněný pomocí EXPORT_SYMBOL_GPL, pak odstraněním této ochrany porušujete licenci GPL. To nesmíte ani pro vlastní použití.

  • 18. 1. 2019 15:38

    ja. (neregistrovaný) 195.12.136.---

    Ked to matlam u seba v sukromi, tak GPL este nenastupuje a nic neporusujem. Ta nastupuje az s distribuciou.

    GPL sa neda porusit, pokial nic nedistribujete dalej.

  • 18. 1. 2019 19:12

    Honzucha

    Přibližně před rokem jsem mluvil s člověkem co měl nastarosti interní SW development a infrastrukturu v poměrně velké společnosti. A o GPL řekl, že aby mohl člověk používat GPL sw při vývoji, tak si musí najmout bandu právníků. Takže společnost dala ban na používání GPL knihoven při vývoji a radši tyto funkcionality píšou od začátku když nenajdou BSD/MIT alternativu, než aby řešili GPL naschvály (citace). Jako vedlejší produkt tohoto rozhodnutí byla migrace z Linux na FreeBSD/OpenBSD a nevypadá to, že by se to mohlo někdy zvrátit.

  • 18. 1. 2019 19:32

    Petr Neni (neregistrovaný) 89.248.140.---

    Jj, takovych firem znam nekolik. Vsechny nad 10k zamestnancu. V nadseni pred x lety z GPL zacali pouzivat ruzne knihovny pod gpl. Pak se zakaznici zacali vice ptat na licence a ted tech x firem ma projekty k tomu aby se tech gpl knihoven zbavovali. Gpl mela ve sve dobe smysl, dostala do povedomi firem a lidi OSS. Ale diky ruznym omezenim ktere jsou v real world tezko akceptovatelne se vsichni zacinaji vecem pod gpl vyhybat.

  • 18. 1. 2019 19:53

    Honzucha

    Tak nějak, tato tedy má do 1.5k zaměstnanců. Nicméně tam není problém v penězích, ty je k OSS netahly. Ale prostě GPL pro ně znamená více potíží než positiv. A mám takové tušení, že tento přístup bude Linux jednou bolet. Nejvíce mě baví komentáře, že to není problém Linux, ale ZoL, že má změnit licenci. Pamatuji si debaty v PostgreSQL ohledně GPL a výsledek je v jejich FAQ:
    People often ask why PostgreSQL is not released under the GNU General Public License. The simple answer is: we like our license and do not want to change it!

    Mě celkem leze na nervy ta arogance, jako že GPL je ta jediná správná, ne není. Jestliže někdo svým pohledem na svobodu omezuje mou svobodu, tak není kámoš ;) A mimochodem je to přesně ten důvod proč už několik let, tam kde můžu používám BSD.

  • 18. 1. 2019 22:37

    Michal Kubeček

    The simple answer is: we like our license and do not want to change it!

    Čistě ze zvědavosti: uvědomujete si, že vlastně Linux kritizujete za úplně přesně stejný postoj, který vám u PostgreSQL tak imponuje? (Pokud tedy pomineme, že v případě Linuxu by ta změna stejně ani nebyla prakticky proveditelná.)

  • 18. 1. 2019 23:43

    Honzucha

    Omyl, já jen kritizují GPL která vlastně není vubec svobodná tak marketingově povídá. A export_gpl_symbol je fundamentálně pochybený koncept a můj názor na něj nikdo nezmění. A přesně na to linux dojede, dejte na má slova, a to Linux používám od půlky 90. let

  • 19. 1. 2019 0:41

    Miroslav Šilhavý

    Čistě ze zvědavosti: uvědomujete si, že vlastně Linux kritizujete za úplně přesně stejný postoj, který vám u PostgreSQL tak imponuje?

    Tady přeci vůbec nejde o postoj! Ten má každý autor stejný: vybírá si licenci, která se JEMU líbí. To tu nikdo nekritizuje.

    Co se tu přepírá je to, že GPL je považovaná a adorovaná jako svobodná licence, ale ve skutečnosti má mnoho těžko pochopitelných omezení. V praxi tato omezení znamenají, že GPL software není zdaleka tak atraktivní, jak si mnoho příznivců GPL / OSS obecně myslí nebo přeje.

    Osobně si myslím, že kdyby se udělal průzkum u autorů, tak by jen málo z nich tíhla k GPL z přesvědčení. Větší část GPL využívá ze setrvačnosti (co jednou GPL pohltí, už nikdy nevydá), menší část kvůli tomu, že při vývoji svého OSS prostě nechce dělat rešerši X licencí, a tak sáhne po té nejbližší (a na Linuxu je GPL opravdu nejbližší). Část vývojářů menších projektů dost možná ani nemá zkušenost z firemní sféry, aby v GPL viděli nějaký problém (já v GPL také dlouhé roky žádný problém neviděl).

    Nemělo by se ale ignorovat, že nezanedbatelná část důležitých Open Source programů zvolila některou ze svobodnějších (volnějších) licencí. Je opravdu dost dobře možné, že např. na servech bude brzy BSD atraktivnější, než Linux. Já už mám víc serverů na FreeBSD, než na Linuxu. U mě to není ale kvůli licenci, spíš kvůli tomu, že Linuxové distribuce každá razí svoji cestu a čert aby to usledoval.

  • 19. 1. 2019 7:55

    Honzucha

    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).

  • 19. 1. 2019 8:57

    Miroslav Šilhavý

    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.

  • 19. 1. 2019 10:18

    Honzucha

    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í.

  • 19. 1. 2019 10:07

    Michal Kubeček

    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.

  • 19. 1. 2019 10:48

    Miroslav Šilhavý

    @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.

  • 19. 1. 2019 11:00

    Michal Kubeček

    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.

  • 19. 1. 2019 11:03

    Michal Kubeček

    ...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". :-)

  • 19. 1. 2019 12:52

    Petr Neni (neregistrovaný) 89.248.140.---

    Ja ti nevim, ale nasadil jsem 10gbit na freebsd a ze bych nedosahoval rychlosti, nebo ze by se mi neco nekam zasekavalo nepozoruji. Co vim tak od roku 2000 se ve freebsd soustredili na upravy pro smp, threading a locking u site, tudiz bych neocekaval nejake vazne problemy. Ale treba se pletu, mam malo stroju na to abych to dokazal srovnat s nasazenim rhel na x tisic serverech co mame.

  • 19. 1. 2019 13:30

    Michal Kubeček

    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.)

  • 19. 1. 2019 10:48

    Michal Kubeček

    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.

  • 19. 1. 2019 11:07

    Miroslav Šilhavý

    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é.

  • 19. 1. 2019 11:28

    Michal Kubeček

    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.

  • 19. 1. 2019 11:47

    Honzucha

    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.

  • 19. 1. 2019 13:23

    Michal Kubeček

    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.

  • 19. 1. 2019 15:39

    Miroslav Šilhavý

    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é.

  • 19. 1. 2019 20:05

    Michal Kubeček

    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á.

  • 20. 1. 2019 0:18

    neregistrovany (neregistrovaný) 2001:470:5aa9:----:----:----:----:----

    Pani, do vasej diskusie vstupim s dalsim kuskom mozaiky:

    V tomto videu - https://www.youtube.com/watch?v=-zRN7XLCRhc&t=1375 - Bryan Cantrill tvrdi:

    Contrary to public claims of some ex-Sun employees, this was not done to be deliberately GPL incompatible!

    Na toto tvrdenie zareagovala v komentaroch Danese Cooper:

    Lovely except it really was decided to explicitly make OpenSolaris incompatible with GPL. That was one of the design points of the CDDL. I was in that room, Bryan and you were not, but I know its fun to re-write history to suit your current politics. I pleaded with Sun to use a BSD family license or the GPL itself and they would consider neither *because* that would have allowed D-Trace to end up in Linux. You can claim otherwise all you want...this was the truth in 2005.

    Takze ano, licencia ZFS bola naschval vytvorena tak, aby nebol pouzitelny v Linuxe.

  • 20. 1. 2019 1:33

    null null (neregistrovaný) ---.212.broadband18.iol.cz

    @neregistrovany

    Tak a už jenom vyřešit kdo to věděl takto ... ;-) :-D

  • 20. 1. 2019 5:57

    Miroslav Šilhavý

    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.

  • 20. 1. 2019 8:26

    Honzucha

    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ě ;)

  • 20. 1. 2019 9:00

    Ondra Satai Nekola

    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á.)

  • 20. 1. 2019 12:21

    neregistrovany (neregistrovaný) ---.dynamic.orange.sk

    > masivně komerčně používaný i v korporátní sféře (narozdíl od BRTFS)

    To zase nie je celkom tak pravda. Vsetky servery facebooku bezia na btrfs (nie brtfs) a dovolim si tvrdit, ze to bude sumarne vyssie cislo, ako vsetkych ZoL instalacii spolu.

    Nie som si vedomy podobne masivneho nasadenia ZoL.

  • 21. 1. 2019 8:06

    Petr Neni (neregistrovaný) 31.216.239.---

    Jsou firmy kde se bezi na FAT a kvuli tomu budeme tvrdit, ze se masivne pouziva? Je par korporatu kde btrfs opravdu nasadili, ale naprosta vetsina korporatu v produkci btrfs nema.

  • 21. 1. 2019 10:26

    Honzucha

    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

  • 21. 1. 2019 13:34

    Johanka (neregistrovaný) 2a01:430:30:----:----:----:----:----

    Fakt je nutné na vás vytahovat miliony NASů od Synology? :-)

  • 21. 1. 2019 13:37

    Johanka (neregistrovaný) 2a01:430:30:----:----:----:----:----

    PS: To Synology bylo na Honzuchu z 10:26. Zase mi při odesílání nedošlo, že se to tady v určité úrovni zanoření nepozná.

  • 21. 1. 2019 15:23

    Honzucha

    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.

  • 21. 1. 2019 17:46

    Johanka (neregistrovaný) 2a01:430:30:----:----:----:----:----

    Pardon, myslela jsem, že se nebavíte o ZFS, nýbrž o ZoL. Samozřejmě postavení ZFS na Solarisu bude jiné. Stejně jako třeba NTFS na Windows.

  • 21. 1. 2019 17:54

    Michal Kubeček

    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.

  • 22. 1. 2019 7:44

    Honzucha

    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?

  • 22. 1. 2019 13:42

    Michal Kubeček

    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.

  • 22. 1. 2019 13:59

    Honzucha

    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.

  • 22. 1. 2019 18:22

    Johanka (neregistrovaný) 2a01:430:30:----:----:----:----:----

    RAID5 není u BTRFS stabilní. Oficiálně. Takže argument Synology+RAID je poněkud mimo. Synology samozřejmě není sebevrah, aby používalo vlastnost se statusem "unstable". Zkuste něco jiného.
    https://btrfs.wiki.kernel.org/index.php/Status

  • 22. 1. 2019 18:27

    Johanka (neregistrovaný) ---.client.rionet.cz

    PS: Jinak já si tu s váma fakt nemám potřebu poměřovat pindíka (při mém pohlaví zvlášť). Jen jsem si dovolila upozornit, že BTRFS opravdu je běžně používané i v komerční sféře, ačkoli si očividně myslíte něco jiného.

  • 20. 1. 2019 14:21

    Michal Kubeček

    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.

  • 20. 1. 2019 16:43

    Miroslav Šilhavý

    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í.