Az Oracle a dtrace esetében dobta a CDDL-t és GPLv2-re váltott

 ( trey | 2018. február 14., szerda - 21:26 )

Részletek itt.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Esetleg ZFS-nél nem terveznek hasonlót?
Sok problémát megoldana.


Normális HUP-ot használok!

Inkább az OpenZFS-nek tenne jót.

Nem értem, bármilyen kavarás miért is hozna bármi fejlődést a zfs körül.

Ahogy én látom a ZFS (aka. OpenZFS), köszöni jól van és fejlődik.

Az Oracle meg fogta a saját forkját, bezárta és saját magán kívül senki mással nem kompatibilis, de legalább a projektet is kinyírta.

Két eset lehetséges:

#1. kiadja a sajátját is cddl alatt, és beolvasztásra kerül az openzfs-be az a pár extra feature (ahonnan meg aztán dkml / akármin keresztül a linuxokba is up to date verzió marad elérhető) . Már ha egyáltalán kompatibilisé tehető az ő megoldásuk az openzfs-ben bevezetett feature flags-el.

#2. szép sorban az Oracle által hozzáadott érték, tőlük függetlenül is implementálásra kerül az OpenZFS-ben, és az Oracle úgy jár a saját "munkájával", mint ahogyan az OpenOffice-al is járt. Van még, csak már a kutya nem használta addigra, mire lemondott róla az Apache foundation javára, mert mindenki elment LibreOffice-ra.

DTrace kicsit más tészta. Azt gyanítom nem lehetett csak simán külön kernel modullal megoldani, végig kellett tolni pár változtatást a kernel komolyabb alrendszerein, amihez pedig gpl-kompatibilissé kellett tegyék a kódbázist. Viszont, ha meg nem teszik, akkor az Oracle Linux azt a hangyányi előnyét is elveszítette volna, ami miatt egyáltalán bárki fontolóra vette a használatát.
Ettől még a szememben nem fog az Oracle kevésbé kártékonynak tűnni. Ügyes stratéga? Igen! De attól még a Sun-tól átvett IP-k segítségével nekem még mindig úgy tűnik, hogy erősen csak bomlasztásra, rombolásra használta az így szerzett előnyt.

Az OpenZFS-t sokkal többen tudnák használni, és több fejlesztője lenne, ha Linux mainline-ba kerülne. Ennek a CDDL a legfőbb akadálya tudtommal. Az egy dolog, hogy a forrásbólkernelmodulépítős installerrel is elmegyeget, de azért ez elég gáz.

Szerintem nem ezen múlik. Azon múlik, hogy nagy disztrókészítő beáll-e mögé.

A canonical már beállt.

A redhat meg... nem tudom, hogy btrfs-re vagy valami linux-natív-ra várnak-e, de én úgy érzem, hogy ha akarnának valami ütőset, akkor már betették volna a zfs-t.

Kicsit a másik feléről nézve: Egyszerűen, ha "klasszikus" storage kell, akkor nem linuxból fogod építeni. Több okból sem. Sem nfs szervernek nem való, sem iscsi-nak, sem arra, hogy valami ütős hba alá tegyen targeteket + lun-okat.
Én a magam részéről ilyenhez illumos és freebsd alapú megoldásokban gondolkodom: ne a gombhoz keressük a kabátot!

Ha meg valami elosztott és redundáns storage-t építesz (ceph, gluster, ...), akkor meg már akár egy sima nyers block dev is lehet backendje, fölösleges azalá még fs-t tenni. Persze ez csak az elmélet. Az hogy a gyakorlatban ezen fs-ek tudnak-e adatterületnek nyers blokdev-et használni, azt passzolom.

> A redhat meg... nem tudom, hogy btrfs-re vagy valami linux-natív-ra várnak-e:

A brtfsre biztos nem: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/7.4_release_notes/technology_previews_file_systems

"Btrfs file system
The Btrfs (B-Tree) file system is available as a Technology Preview in Red Hat Enterprise Linux 7.
Red Hat Enterprise Linux 7.4 introduces the last planned update to this feature. Btrfs has been deprecated, which means Red Hat will not be moving Btrfs to a fully supported feature and it will be removed in a future major release of Red Hat Enterprise Linux. (BZ#1477977)"

És mit fognak támogatni helyette? ext4? xfs? Vagy ők is beadják a derekukat zfs-re?

Fogalmam sincs, annyira nem szoktam követni a filerendszer mizériákat. Pont azért maradt meg az emlékezetemben, mert felhúztam a szemöldököm rá, mivel eddig én kb úgy interpretáltam, hogy a brtfs lesz a következő standard linuxos fs, szép lassan, amolyan ext*-os tempóban megérkeznek bele a dolgok, a zfs a ccdl miatt sose lesz az igazi, az ext vonal meg nem akar okosabb lenni, és furcsa volt, hogy az RH kihátrál belőle.

Ha tippelnem kellene, akkor:
- megnézném, hogy mit erőltetnek az oVirtben (Red Hat virtualizationban), jó eséllyel az lesz az, mert még ott kellhet leginkább.
- XFS szerintem elég nekik, nem hiszem, hogy nagyon akarják az iszonyatosan fancy storage featureöket
- zfs szerintem nem, szívás a logisztika

"ne a gombhoz keressük a kabátot!"

EZ.
+1

Ne felejtsd el, hogy abban az Amerikában ahol jogerősen szerzői jog védi az api-kat a fentebb részletezett fordítós kellemetlenségek mellett a jogbiztonság is problémás.
A Canonicalra nem tekint erős konkurenciaként vagy pénzeszsák fejősgépként az Oracle. De a Google kezdené saját termékeibe beépíteni, például újra árulnának szervereket cégeknek házon belüli keresésekre és azokon OpenZFS lenne nagyon esélyes lenne egy újabb Oracle per.


Normális HUP-ot használok!

És ahhoz mi köze van az Oraclenak?

Semmi. Vagy talán a copyright egy része még az övék, nem tudom. De nem az eredeti cikkre válaszoltam.

Ezt szerintem bő 15 éve kellett volna megtenniük. Van még ennek értelme? strace sysdig, systemtap mellett van még ezt értelme?

HN top comment:

brendangregg 19 hours ago [-]

Unfortunately for DTrace, this is too late. Oracle should have done this years ago. Now Linux has a more powerful tracer builtin, eBPF, and it would be a backwards step to switch the kernel code to DTrace (assuming the DTrace port is completed, which it is not). I'm sure this will not be lost on the maintainers, who have the ultimate say as to what is included in Linux mainline.
The only hope for DTrace is to have the frontend emit BPF bytecode. The bulk of this GPL DTrace code is no longer needed, only the user-level front end.

...

Bonusz olvasnivalo: http://www.brendangregg.com/blog/2016-10-27/dtrace-for-linux-2016.html