Názory k článku
ZFS on Linux má menší zádrhel s kernelem 5.0

Synology používá Btrfs nad MD RAID. To ale Btrfs trošku ztrácí význam.

Také jsem přesvědčený, že se to zanedlouho vyřeší a až na strojích se ZFS poli přijde čas na upgrade kernelu > 5, bude již podporovaný.

Odebírání disků není zajímavé, ale přidání disků do pole nebo migrace na nové pole rozhodně zajímavé jsou. ZFS umožňuje jen přidáním nového pole, což je hodně limitující.

odoberanie diskov mozno nepodporuje ZFS on Linux.. ale som si isty ze ho podporuje ZFS ;)

Nebude to spíš tím, že s BSD licencí je kompatibilní kde co včetně EULA Windows?

To jako fakt? Qt4 i Qt5 API i ABI je dopředně kompatibilní. Aplikace napsaná a zkompilovaná proti Qt 5.0 by se měla bez problémů spustit i proti Qt 5.12. Osobně to mám vyzkoušené jen v rozsahu Qt 5.6 - Qt 5.12 na Windows i Linuxu a funguje to.

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.

Nechce se mi reagovat na "hloupoučké", "dement", a "wtf", asi jsem na jiné úrovni :)

Rozumím správně, že použití zcela běžného citově zabarveného výraziva, které nemá žádný dopad na faktický obsah mého příspěvku vám brání formulovat věcnou odpověď? Nu, jak chcete...

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.

a pri ktorych driveroch by to konkretne pomohlo rozsireniu linuxu ? dakujem

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.

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?

Uffff, opravdu nechápu návaznost reakce. Já mluvím o tom, že tímhle počinem si akorát linuxová komunita sere do vlastního hnízda. Ale tak hlavně, že si zas můžem poplkat o ušlechtilých ideálech za GPL-like licencemi, a že nás nebude ten zlý Oracle vykořisťovat.

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

Aha, tak to jooo... Oracle určitě to ZFS přelicencuje. Rozhodně...

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