ZFS on Linux (ZOL) má menší problém s novým jádrem 5.0-rc1. Nové jádro přestalo exportovat funkce __kernel_fpu_{begin,end} a exportuje je jen v EXPORT_SYMBOL_GPL, což nejde v ZOL kvůli licenci použít.
Řešení zatím není známé, Greg Kroah-Hartman však není ZOL velmi nakloněn:
My tolerance for ZFS is pretty non-existant. Sun explicitly did not want their code to work on Linux, so why would we do extra work to get their code to work properly?
(zdroj: phoronix)
Ono to nie je problem, ak clovek realne pouziva linux tych 20 rokov, za ten cas stihol vystriedat vela FS a kedze kazdy FS obsahuje chyby, tak pravedpodobnost, ze na nejaku narazi, je vysoka. Mne zozrali data XFS, EXT2, EXT3 aj EXT4 (samozrejme aj FAT a NTFS). Jediny FS, ktory mi nikdy nezozral data, je Reiser3, ale ten som pouzival len velmi kratko. Takze tie pribehy o zozrani dat nie su nic prekvapive a viacmenej s tym treba pocitat.
Ja som napríklad prišiel o dáta pod ZFS asi v roku 2010, boli tam okrem fotiek a iných dát aj relatívne zaujímvé zdrojáky, ale vtedy bolo ZFS on Linux ešte v plienkach. Samozrejme že som mal zálohy, ale nebolo tam všetko. Odvtedy používam ZFS pod FreeBSD a tam som nemal nikdy problém. Teraz je ZFS on Linux na tom tak dobre, že ich kód chcú využívať aj vo FreeBSD.
Dnes mám ZFS opäť aj pod Linuxom na desktope, no keďže kernel 4.19 je LTS, myslím, že pokiaľ budem prechádzať na novší, problém sa vyrieši.
Pokiaľ viem tak BTRFS dostal nejaké patche pre RAID5/6, niekde okolo kernelov 4.12-4.14 ale stabilný v nich zatiaľ nie je, preto na BTRFS používam RAID1. BTRFS má zas výhodu v tom, že dokážem pridať disk, odobrať disk, zmeniť dáta zo SINGLE na hocijaký RAID, čo ZFS nedokáže, alebo jedine veľkou okľukou.
Tak ono ZFS bylo navrzeno pro potreby enterprise, tudiz nikoho nezajima jak udelat z 1 disku nejaky raid. Obvykle planujete storage drive nez ho nastavujete, tudiz use case s odebiranim disku je v enterprise nezajimavy. Jinak i zfs umoznuje odebrat disk, za urcitych podminek. BTRFS je urcite zajimavy pro siroke spektrum nasazeni, skoda ze nevychytali jeste nedokonalosti.
RAID5/6 v Btrfs má pořád write hole, resilver po výměně disku je opravený, takže pokud vám nevypadne proud… :)
Změna RAIDu není reálně tak moc zajímavá jako možnost mít pro různé subvolume různý RAID (např. /usr v RAID6, /var v RAID10 a /var/tmp bez RAIDu). To ale (s výjimkou data/metadata) bohužel zatím nebylo implementováno. Stejně tak je škoda, že se do Btrfs zatím nedostal kód pro RAID s více než dvěma paritami. Btrfs má o hodně větší potenciál oproti ZFS, které o tomhle kvůli svému návrhu ani nemůže uvažovat, ale zatím ho moc nevyužívá.
Linux, resp. GPL je svobodné jen odtud potud...
Podle mě GPL historicky vykonala velkou práci, bez ní by open source nebyl tím, čím je.
Na druhou stranu, myslím si, že její radikálnost je už dnes na překážku. Open source už není v ohrožení (už nezanikne snahami komerčních firem), a možná by dalšímu rozvoji pomohlo politiku přeformulovat.
Kromě GPL existují i další svobodné licence, a je už jasné, že jsou také životaschopné.
ZOL je tragickým příkladem toho, jak takto primitivní nesnášenlivost a hašteření jen škodí.
Sun, kdyz privedl ZFS na svet, explicitne _nechtel_, aby se ZFS pouzilo v linux kernelu a podle toho licencoval. Tady neni co resit.
Ja nejsem fanda GPL, ale jednou ten kod v kernelu je GPL a nemuzes ho jen tak vzit a prelicencovat, aby se mohlo pridat ZFS. Navic ocividne pro takovehle znarodnovani nejsou ani ti, co na kernelu odvadeji nejvic prace.
Máš pravdu, tuhle část jsem si pamatoval špatně. Licence byla vyrobena nekompatibilní, ale nikdy se veřejně neříkalo proč.
ten kod v kernelu je GPL a nemuzes ho jen tak vzit a prelicencovat, aby se mohlo pridat ZFS
Ale to vůbec nebylo potřeba přelicencovat, ani to nikdo nechtěl... Ono prostě stačí nerozkopávat si bezdůvodně nebo dokonce jako naschvál bábovičky na pískovišti.
Opak je bohužel pravdou. Běžní uživatelé dneska pracují většinou s webovými nebo mobilními aplikacemi. A tyto aplikace nejenže jsou často proprietární, ale navíc běží mimo dosah uživatele a uživatel nemá pod kontrolou ani data. A smutné na tom je, že tyto proprietární aplikace z velké části staví na svobodném softwaru – ovšem k uživateli se tato svoboda již nedostane a uživatel dostává proprietární software – což umožňují právě ne-copyleftové licence jako BSD/MIT.
Tady vidite proc je BSD lepsi. Tyhle problemy tam nevznikaji.
Jednak chcete aby 3rd party psali drivery pro linux a negarantujete jim ani stabilni API pro drivery natoz ABI. Proto se do toho nikdo nehrne a dela to jen ten kdo opravdu ale opravdu musi. Neni tu totiz vubec zarucena bezpecnost do investice potrebne k zafinancovani vyvoje driveru pro linux.
> Furt je to lepší oproti win, kdy se vždy překope
> všechno po půl roce a nebo po roce. Pro
> programátora/vývojáře je to peklo. Něco dopíšeš,
> proběhne změna a můžeš začít znova.
Zrovna Windows kernel má API stabilní již od dob cca Windows 2000. Nestává se, že by nějaký export jen tak zmizel. Ano, může být označen jako deprecated, ale pořád zůstsává z důvodu zpětné kompatibility (jen v dokumentaci k němu se nachází pouze informace, že se místo něho má používat něco jiného).
Windows podporují podstatně méně platforem a konfigurací než Linux a udržet tam rozumně stabilní rozhraní bude asi jednodušší. Uživatelské WinAPI skutečně stabilní je, ale to má Linux kernel, X11 nebo třeba Qt taky. S jaderným API už to tuším až tak úžasné není. Pokud vím, tak třeba grafické ovladače se se zavedením WDDM musely pro Vistu a dále značně překopat, jak moc se změnila situace s nástupem Win10 nemám zdání...
> Pokud vím, tak třeba grafické ovladače se se
> zavedením WDDM musely pro Vistu a dále značně
> překopat, jak moc se změnila situace s nástupem
> Win10 nemám zdání..
Je pravda, že přibývají nová rozhraní, která si kladou za cíl nahradit ta stará. Nemůžu mluvit za grafiku, protože jsem grafické ovladače nikdy nepsal (viděl jsem jen část API), ale obvykle i stará rozhraní zůstávají nějakou dobu (pár verzí Windows) funkční s tím, že je doporučovaný přechod na novější, takže je teoreticky spousta času.
Třeba TDI, rozhraní pro síťovou komunikaci (včetně filtrování provozu) je deprecated již od Windows Vista (narazeno WFP a WSK), ale minimálně na Windows 8.1 stále funguje (nevím, zda všechna funkcionalita, ale část určitě ano, protože přes ni funguje implementace WinSock).
Přímo v "Qt-Version-Compatibility" se píše "Major releases may break backwards binary and source compatibility, although source compatibility may be maintained". To je ale jen jedna stránka mince, protože např. upgrade překladače nebo standardní knihovny [C++] někdy znamená nutnost překompilovat. Obecně C++ a binární kompatibilita je problém z dlouhodobého hlediska, proto je systémové API většinou v C.
"Major release" se rozumí Qt 4, Qt 5, Qt 6 atp. Pětková řada Qt existuje už 6 let a 5.12 LTS bude podporována minimálně do roku 2021. I v C++ se dá kompatibilní ABI udržet a třeba Qt i KDE Frameworks ukazují, že to není až tak neschůdné, jak se tvrdí. Qt není systémová knihovna ale velmi bohatý toolkit určený hlavně pro tvorbu uživatelských aplikací. Napsat něco takového v čistém C není dost dobře možné.
Vždyť Qt tu kompatibilitu i přes striktní pravidla nedokáže dlouhodobě udržet (sorry ale 6 let je nic v porovnáním např. s WinAPI, FreeType, Cairo, atd..). V C++ už jen vynucení standardu může to ABI rozbít (např. noexcept v C++11 vs C++17). Dále např. std::string (nebo jakýkoliv stl container) v public API znamená _žádné ABI_, protože jak má ten std::string vypadat už nikde garantované není (a zrovna tyto detaily se mění celkem často). Takže prosím příště psát k tématu a ne vysvětlovat co je major verze nebo co se dá nebo nedá napsat v C (o tom to fakt není).
Vždyť Qt tu kompatibilitu i přes striktní pravidla nedokáže dlouhodobě udržet
Přiznám se, že nechápu, co tahle věta znamená. Vývojáři Qt jasně deklarují, jakou míru binární kompatibility lze očekávat a ta je skutečně dodržována. Možnosti Qt se např. od řady 3 po řadu 5 masivně posunuly, takže rozbití kompatibility major verzí je rozumný kompromis mezi stabilitou a rozšiřováním funkcionality. I dnes není problém napsat program tak, aby šel bez problému přeložit vůči Qt4 i Qt5, kdyby to snad někdo potřeboval. WinAPI je po pětadvaceti letech vývoje masivní chaos a žádné nové aplikace v něm dnes už nepíší. Cairo i libfreetype jsou proti Qt hloupoučké jednoúčelové knihovny, které nikdo neměl potřebu výrazně rozvíjet, takže se podařilo ABI udržet.
V C++ už jen vynucení standardu může to ABI rozbít (např. noexcept v C++11 vs C++17)
Pokud jsem takový dement, že si Qtčka schválně přeložím tak, abych to ABI rozbil, těžko se mohu zlobit na vývojáře, že mi v tom nezabránili. Zrovna noexcept v C++17 je problém na úrovni jazyka a ne Qt a proti podobným problémům není imunní ani C, akorát je tam méně možností, jak to rozbít.
Dále např. std::string (nebo jakýkoliv stl container) v public API znamená _žádné ABI_,
Vždycky platí, že z knihoven smím exportovat jen ty datové typy, které mám plně pod kontrolou. Qt4 STL nepotřebovaly vůbec, Qt5 závisí na STL algorithms, rozhodně ale neexportují žádné datové typy kromě svých vlastních.
Takže prosím příště psát k tématu a ne vysvětlovat co je major verze nebo co se dá nebo nedá napsat v C (o tom to fakt není).
WTF? Moudra o tom, že systémové knihovny se píší v C apod. jsi začal diskutovat ty.
Asi bych k tomu dodal jen to, že pokud děláš v C++ a prohlašuješ, že binární kompatibilita v C++ není problém, tak neděláš v C++ dostatečně dlouho. Citově zabarvené výrazivo si klidně používej, jen mi to celkem jedno, jen většinou nemám moc náladu diskutovat s někým pro koho jsou tyto výraziva důležitější než pochopit toho druhého.
Kompatibilita ABI v C++ není problém, pokud jste si přečetl (a pochopil) dokumentaci ABI vašeho překladače. Nevím, jak je to u MSVC++ (ani bych se nedivil, kdyby to bylo s každou verzí jinak), ale Clang i GCC používají roky stabilní Itanium ABI, kde není tak těžké držet zpětnou kompatibilitu.
Binární kompatibilita v C++ problém není, akorát dá více práce ji udržet. Při troše šikovnosti lze napsat i takové rozhraní, které bude kompatibilní mezi různými kompilátory - možnosti takto exportovaných C++ objektů jsou sice poněkud omezené ale pořád je to lepší než syrové Cčkové funkce. Diskutovaná Qtčka nejsou API/ABI kompatibilní mezi major verzemi ne proto, že by se v C++ nedalo udržet ale proto, že se vývojáři rozhodli pro nějaký kompromis mezi vývojem a stabilitou.
Docela chapu, z jakeho pohledu to beres a pro me jako cloveka pouzivajici Qt je jejich rozhodovani ohledne kompatibility docela rozumne. Ale tady se bavime uplne o jinych rezimech kompatibility. Kdyz to zjednodusim - jaderne ABI proste rozbijet nesmis. Na urovni aplikace <-> kernel v zasade nikdy. Na urovni kernel <-> driver, tedy jaderny interface bys to taky delat nemel, ale deje se to, protoze jediny komu to vadi jsou binarni bloby. API bys menit nemel, protoze to pak vsichni musi prepsat a deje se to mene, nez ABI, ale deje se to. Binarni bloby to vetsinou resi necim uprostred co splnuje GPL a pri zmene ABI / API se zmeni jenom ta cast. Problem je, ze ZFS je souborovy system a pokud nechces pouzit FUSE (coz nechces), tak to musis nejak poslepovat dohromady. Windows zpetnou kompatibilitu naopak resi a stare funkce podporuje, obcas neco zmeni, ale obecne chce, aby starsi bloby fungovaly na novejsich Windowsech.
> Ve svete Win (driveru) to s tou "stabilitou" tak
> slavne taky nebude - mrkni nekdy na stranky
> libovolneho vyrobce HW. V lepsim pripade existuji
> drivery od W98 dodnes, nekdy ale chybi drivery pro
> novejsi Win a nekdy zase pro starsi.
Novější Windows obvykle přinášejí nové možnosti pro ovladače. Pokud jich výrobce využije, je logické, že na starších verzích mu to fungovat nebude a musí použít jiný mechanismus (obvykle o dost náročnější), pokud se rozhodne investovat čas a prostředky.
Co se týče opačného případu, jedním z důvodů může být využití nějaké nedokumentované či napůl dokumentované vlastnosti, jejíž implementace se na novějších Windows změní (dokumentace není perfektní a někdy jde i o její špatný výklad). Některá tvrzení výrobce navíc nemusí být zcela pravdivá. U mého notebooku byl dodáván ovladač síťovky max. pro Windows 8, ale funguje dobře i na Windows 8.1; jen bylo třeba přesvědčit instalátor...
Win 10 má změny v api každou větší aktulizaci. viz teď ten nový přechod. A rozdíl je tam, díky tomu byli opět samozřejmě chyby. K těmto api změnám má každý výrobce přístup a podle toho může upravit ovladač. (develop win10)
A od W2000 bych se stebou do krve hádal, todle nemůžeš myslet vážně. API XP vs Vista/7 je k***va velkej rozdíl.
Když vycházelo W10 tak API ještě bylo dost podobné k 7, ale teď již nikoliv.
> Když vycházelo W10 tak API ještě bylo dost
> podobné k 7, ale teď již nikoliv.
Já se pohybuji hlavně v oblasti systémového programování (obvykle kompatibilního i se staršími verzemi) a tam se se změnami moc nesetkávám. Jistě, přibývají nové funkce, což usnadní život, ale ty staré stále fungují.
Tím neříkám, že bych chtěl programovat něco, co bude kompatibilní s W2000. Nechtěl, protože tam spousta mých oblíbených API chybí či má určité nevýhody (ale ty co tam jsou, fungují stále).
Pokud jde o nové API v jednotlivých verzích Windows 10, tam se změny dějí (naštěstí jsem je v práci ještě nemusel řešit) a nejsem za ně rád. Kdyby byl cyklus vydávání nových major verzí ponechán na 2-3 letech (či i více), byl by čas si pořádně rozmyslet, které API mají a nemají smysl.
Kdyžtak dejte příklad nějakých takových změn, rád se poučím.
Sice Win32 jsou mnohem stabilenjsi nez API/ABI Linuxu, ale je zcela bezne, ze chovani Win32 API se mezi verzemi naprosto diametralne lisi. Dabel byva vetsinou ukryt v detailech, jeden priklad treba u GUI veci jak a kde se pocita DPI. Zcela nekonzistentni mezi verzemi.
Druha vec je ze stabilni A PROMYSLENE se mi zda pouze API prevzate odnekud z WinNT, resp. Win16. Vetsina dalsich veci je uz jenom zmatek.
Jednak chcete aby 3rd party psali drivery pro linux a negarantujete jim ani stabilni API pro drivery natoz ABI.
Opravdu chceme? Co jsem si všiml, mezi maintainery a vývojáři jádra je spíš zjevná snaha odradit lidi a firmy od toho, aby si dlouhodobě bastlili své out of tree drivery, které nemají v úmyslu nikdy dostat do upstreamu. Že to někteří přesto dělají, to je jejich problém.
Opravdu chceme? Co jsem si všiml, mezi maintainery a vývojáři jádra je spíš zjevná snaha odradit lidi a firmy od toho, aby si dlouhodobě bastlili své out of tree drivery, které nemají v úmyslu nikdy dostat do upstreamu.
Pokud si mám představit pojem "svoboda" a "svobodný software", tak k tomu pojmu patří i svoboda rozhodnout se právě k tomu, že např. část svých zdrojových kódů nechci poskytnout. Vynucená svoboda je oxymóron.
O tom jsem ale vůbec nemluvil. Jen jsem zpochybnil Alexovo tvrzení, že je (ze strany maintainerů a vývojářů jádra - kdo jiný by mohl garantovat stabilní API/ABI pro drivery) zájem o to, aby vznikaly out of tree drivery (API) nebo dokonce closed source out of tree drivery (ABI), které nikdy nikdo do mainline dostat neplánuje.
Jen jsem zpochybnil Alexovo tvrzení, že je (ze strany maintainerů a vývojářů jádra - kdo jiný by mohl garantovat stabilní API/ABI pro drivery) zájem o to, aby vznikaly out of tree drivery (API) nebo dokonce closed source out of tree drivery (ABI), které nikdy nikdo do mainline dostat neplánuje.
Ano, ale to je podle mě dost smutné a přízemní hašteření. Stabilní API i dokonce ABI patří ke stavovské slušnosti. Mně to spíš přijde, že nejsou schopni API/ABI udržet, tak z nouze udělali ctnost.
Především jádro stabilní API/ABI vůči userspace má a jeho stabilita (ve smyslu zpětné kompatibility) je vyžadována velmi přísně (viz Linusovo pověstné "don't break userspace"). Co není garantováno je stabilita interního API/ABI a důvod je velmi jednoduchý: při způsobu, jakým je Linux vyvíjen, to prostě není reálně proveditelné. Doporučuji přečíst si Documentation/process/stable-api-nonsense.rst, kde jsou některé důvody rozebrány.
Mám tu smůlu, že mám docela dobrou představu, co by taková stabilita API/ABI obnášela, protože u distribučního jádra v omezené míře stabilitu kABI garantujeme (právě kvůli closed source 3rd party modulům). Asi byste se divil, jak ošklivé triky je kvůli tomu potřeba dělat a jak se tím v některých případech zneefektivní kód. Některé chyby nejde bez rozbití kABI opravit vůbec a to ani nemluvím o tom nových featurách. Pokud bychom se omezili na API (tj. jen open source moduly, které by bylo potřeba přebuildit), bude to o chloupek lepší, ale ne o moc.
Znovu podotýkám, že se vůbec nebavím o GPL (vůči které mám osobně řadu výhrad) nebo dokonce konceptu EXPORT_SYMBOL_GPL (který považuji za principiálně pochybený).
@Michal Kubeček
Děkuju za trpělivé vysvětlení. Můj názor na to je, že by tuto strategii měl Linux přehodnotit, posunulo by ho to dál. Možná by mu to dalo šanci i na větší rozšíření. Vývojář modulu / driveru bohužel nemá vždy neomezený rozpočet, aby udržoval X verzí, pro každé jádro jednu. Dost často nemá ani na to, aby udržoval modul zahrnutý do jádra. Takových je bezpočet. Chtějí vyvinout (zaplatit si vývoj) jednoho driveru (modulu) a ten pak léta distribuovat, víceméně beze změn. To Linux bohužel neumožňuje, je to proti jeho strategii.
Ad GPL: Ok.
No treba kdyz si vezmu Reaper DAW. Ten je komercni soft a pro linux je ale k cemu vsechna ta namaha s porovani Mac to Linuxu kdyz nejsou drivery pro:
1. zvukove IO karty.
2. Multi port MIDI karty.
3. MIDI klavesnice a MIDI nastroje kterym nestaci universal USB MIDI.
4. Software pro programovani DSP efektu na kartach.
Proste pro Linux nikdo tohle nedela a tak je zbytecne portovat DAW.
Tak teď ještě ukázat, že nejsou kvůli nemožnosti psát out-of-tree kernelové drivery.
To je bohužel příklad nabubřelosti linuxové komunity. Systém, který má zastoupení na hranici měřitelnosti by se měl snažit hledat cestu, jak výrobce nalákat. Nikoliv vykřikovat: "dokažte mi, (proč jsem tak neúspěšný)".
Linux žije kvůli serverům, SOHO routerům a Androidu. Na serverech a routerech má dost rovnocennou konkurenci v BSD systémech.
Android leží jen v rukou Googlu a Google už koketuje s vlastním, novým, nezávislým OS pro mobilní zařízení.
Je zde reálné riziko, že Google Linux opustí. Pak z Linuxu zůstane v podstatě jen platforma pro servery (kde má plnohodnotné konkurenty) a malá zařízení (kde konkurenci, až na SOHO routery nemá).
Nepřijde Vám to škoda? Mně jo, já bych Linuxu přál víc (znám linux aktivně od 1994).
Systém, který má zastoupení na hranici měřitelnosti
Tohle opravdu napíšete v roce 2019 a myslíte to vážně? Svět OS nejsou jen desktopy - naopak, právě tenhle trh je stále méně a méně perspektivní. Proč myslíte, že se MS už zdaleka tolik nesoustředí na Windows, úplně změnil jejich vývojový a obchodní model a daleko více se koncentruje na Azure a související produkty a služby? Proč MS najednou intenzivně přispívá do linuxového jádra a některé své produkty portuje na Linux (někdy dokonce i jako open source), když má Linux - podle vás - "zastoupení na hranici měřitelnosti"?
Na serverech a routerech má dost rovnocennou konkurenci v BSD systémech.
Možná na nějakých nenáročných pro domácí použití. Zrovna tady jsem nedávno viděl článek, ve kterém mne překvapila informace, že nové OpenBSD odstranilo KERNEL_LOCK() ze základních recv*() a send*() syscallů. Tak jsem trochu hledal a zjistil, že i v mnoha dalších podstatných ohledech dnes vývojáři síťového stacku OpenBSD řeší problémy, které jsou v Linuxu vyřešené 10-15 let.
Je zde reálné riziko, že Google Linux opustí.
To se zřejmě pozná podle toho, že Google platí tolik kernelových vývojářů a že jich stále přibývá.
Systém, který má zastoupení na hranici měřitelnosti by se měl snažit hledat cestu, jak výrobce nalákat. Nikoliv vykřikovat: "dokažte mi, (proč jsem tak neúspěšný)".
Prvním krokem při "hledání cesty" je položit si otázku, zda je to či ono skutečným řešením problému. Různé systémy s BSD licencí totiž ukazuji, že je to spíše Linux, který to dělá celou dobu lépe. Např. FreeBSD má - aspoň dle údajů firmy Sony - skoro 92 milionů uživatelů, protože OS v PlayStationu 4 je forknuté FreeBSD 9. Palubní multimediální systém vozu nejmenované značky, kterého se celosvětově prodalo přes 3,5 milionu kusů, je zase založený na NetBSD. I přesto je stav grafického stacku ve FreeBSD v porovnání s Linuxem poněkud úsměvný a podpora Bluetooth na NetBSD téměř neexistující.
Nestabilní vnitrojaderné API je dobrou motivací pro vývojáře dostat svůj kód do upstreamu. Třeba Windows se svým vysoce stabilním a zpětně kompatibilním API podporuje vývojový styl "fire and forget". To je pro vývojáře sice sympatické ale popravdě, kdo jste kdy neproseděl celé odpoledne s čínským notebookem na kolenou, zkoušeje deset verzí ovladače zvukovky, abyste našli ten jediný, se kterým to na dané mašině s danou verzí Windows hrálo?
Ještě názornějším příkladem je IMHO Minix, o kterém se nedávno náhodou zjistilo, že nějakou jeho variantu používá Intel ve svých IME. Na jednu stranu to sice umožnilo Andrew Tanenbaumovi ironicky konstatovat, že je díky Intelu Minix možná nejrozšířenějším operačním systémem, ale na druhou stranu je to z praktického hlediska úplně k ničemu. Nebo snad Intel posílá do Minixu patche opravující chyby, vylepšující funkcionalitu nebo implementující featury? Do Linuxu ano (a ne málo)...
Tuhle diskuzi by si mel precist CEO Microsoftu a dat ji do novin, aby zvysil cenu firemnich akcii. Smutna pravda o Linuxove komunite je ze jsou to fanatici, co si hraji na svem pisecku, okolni svet jakoby neexistoval a maji dokonce problem se dohodnout sami mezi sebou a pak diky roztristenosti ekosystemu, co sami stvorili, neni Linux rozsireny tak, jak by odpovidalo jeho potencialu.
Tenhle krásně naivní přístup vede k tomu, že Sony vydělá miliardy USD prodejem PlayStationu 3 a 4, jejichž OS je forknuté FreeBSD, vyfakuje uživatele odstraněním volby OtherOS , má tu drzost zažalovat své zákazníky, kteří si tu PS3 hacknuli a naflashovali si tam vlastní firmware a do FreeBSD samozřejmě nepřispěje ani řádkem kódu.
Idea svobodného softwaru staví na tom, že ten software budeme tvořit všichni společně a ne že skupina ochotníků něco pracně vyvine, aby se na tom ostatní zadarmo napakovali. Softwarové licence jsou tu právě od toho, aby se dalo vykořisťování svobodného softwaru předcházet. Situace ZoL vs. Linux je dost nešťastným důsledkem této snahy...
Nevšiml jsem si, že by cílem projektu ZoL bylo "nandat" to Oracle, až už by ta nandavárna měla mít jakoukoliv formu. Zajímavější je, že ten ošklivý Oracle, kterému to prý chceme tak nandat přispěl za rok 2017 do jádra 1402 patchi, pro porovnání Google 2477, AMD 2215, Canonical třeba jen 805. Na to, že Oracle by snad nejradši neopensourceoval vůbec nic mi to nepřijde vůbec špatné.
Nechápeš? Tak ti to tedy vysvětlím. Odtušil jsem, že se ti nelíbí prosazování GPL licence technickými prostředky, fajn. Já argumentuji, že je to právě tohle striktní trvání na GPL-licencovaném kódu, které přimělo i monstrkorporáty jako Broadcom, Oracle či nVidii přispívat do jádra. Čísla z posledního kernel reportu to ukazují. Nikdo nerozporuje, že je to dvojsečná zbraň ale když se podíváš na stav všemožných BSD, MINIXů, Hurdů a podobných hraček pro idealisty, zdá se, že ta občasná střelba do vlastních řad za to ve finále stála...
Oraclu je celý ZoL předpokládám fest ukradený. Nejspíš se stane to, že vývojáři ZoL si po deseti letech všimnou, že na používání FPU v jaderných modulech má kernel tohle API, které restrikci na GPL kód zdá se nemá a měli ho používat už dávno. Ve finále to bude daleko produktivnější než handrkování se nad plusy a minusy GPL licence...
Linuxové moduly sdělují jádru licenci, pod kterou jsou šířené makrem MODULE_LICENSE. Jádro exportuje svá API makry EXPORT_SYMBOL. Kromě toho existuje i makro EXPORT_SYMBOL_GPL, které umožňuje přístup k takto exportovaným API funkcím jen těm modulům, které jsou šířené pod GPL licencí. ZoL má licenci CDDL, takže se k části jaderného API nedostane a dvě z funkcí, na kterých ZoL závisí jsou od jádra 5.0 exportované jen pro GPL-licencované moduly. Za zmínku možná stojí ještě skutečnost, že ty dvě funkce pro uložení a obnovení stavu FPU jednotky byly označeny za zastaralé už v době, kdy projekt ZoL vznikl...
Proč by kód ZFS nově nemohl zavolat jinak pojmenované funkce jádra?
Protože je nevidí. https://marc.info/?l=linux-kernel&m=154722999728768&w=2
Nejde o použití písmen, jde o to, že aby modul mohl příslušný symbol použít, musel by deklarovat, že jeho licence je GPL. A to "ZFS on Linux" nemůže, protože je postaven na kódu od Sunu s licencí CDDL, která je formulovaná tak, že použití v GPL projektech vylučuje (což ale platí i obráceně).
Pro úplnost bych ještě upozornil, že část vývojářů je přesvědčena, že už samo šíření jaderného modulu s jinou licencí než GPL (přesněji: sadou licencí neobsahující GPL) je v rozporu s licencí linuxového jádra.
Každý kto tu nadáva na GPL nech si dá facku, lebo nechápe že si píli konár pod sebou (ohovára licenciu pred tími ktorí nevedia o tej licencii nič alebo málo).
Áno GPL neni zárukou za kvalitu kódu. Pretože "Kadre riešia všetko".
Ale uvediem príklad kedy je výhodný aj pre programátora.
Programátor programuje. Prestane sa tým živiť ale ďalej používa GPL kód zadarmo. Aj keď GPL nieje hlavne "o zadarmo alebo za peniaze".
A GPL kód sa nedá uzavrieť ako BSD.
Pod to se klidně podepíšu - GPL licence je sice v mnohém omezující, kdyby nebyla, tak by neměla smysl, ale jako jedna z mála zaručuje férovou hru. Korporacím se vyplatí investovat do Linuxu, protože vědí, že chca nechca ostatní musí do něj investovat také, a jejich práci se konkurence nemůže jednoduše svést. BSD licence takovou férovost nezaručuje, a je vidět, jak málo se do BSD vrací (zpětně investuje). Úspěch Linuxu je podmíněný GPL licencí, a tím, že se skutečně vynucuje.
Jenomze on je problem v tom, ze kdysi Sun licencoval ZFS tak, jak ho licencoval. Takze technicke kvality stranou... na linuxu mame smulu.
