Új Linux kernel komponensek és eszközök kódnyitásáról blogolt a Facebook mérnöki csoportja

 ( trey | 2018. november 1., csütörtök - 10:11 )

A Facebook mérnöki csoportja azokról a Linux kernel komponensekről és eszközökről blogolt a minap, amelyek nélkülözhetetlenek a közösségi hálózat alatt dolgozó rendszer működtetéséhez. Ilyenek például a BPF, a btrfs, Netconsd stb.

Részletek itt és 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ő.

Szóval akkor mégis használják valahol a btrfs-t otthoni kísérletezéseken kívül is. :-)


Normális HUP-ot használok!

A changelog-ban is látszik, hogy folyamatos a fejlődés, csak jól titkolják.

Ehhez képest az RHEL-ből kidobták.
Most már csak az a kérdés, hogy a RH vagy az IBM dobta e...

Elég érdekes, mivel tudtommal nincs alternatívája a btrfs-nek illetve a zfs-nek. Vajon az lvm2-őt képesek lennének ilyen szintre felfejleszteni?

SLES/SLED viszont köszöni szépen, jól el van vele default fájlrendszerként :)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

https://news.ycombinator.com/item?id=14907771

volt már erről szó, nem technikai okok vannak az rhel btrfs hiánya mögött, úgy tűnik

Gondolom nem tudták visszaportolni a Noé idejéből származó kerneljükhöz...
---
http://plazmauniverzum.hu <> A látható anyag 99.999%-a plazma <>

De még milyen jól titkolják!
Az biztos, hogy a btrfs fejlesztők között nincs egy Snowden sem. :-)


Normális HUP-ot használok!

Btrfs is now in production on hundreds of thousands of machines at Facebook. - azért ez nem rossz teszt környezet :)

Csak azt a nyomorult block szintű titkosítást belenyomhatnák már - kíváncsi vagyok mennyi plusz réteget tesznek alá hogy titkosítsanak. Vagy ha megcsinálták, akkor tolják vissza a közösségnek.

Nem titkosítanak ilyen rétegben. Meg amúgyis, mindek?

Még akkor az is kiderül a végén, hogy lehet törölni a Facebook szerverein.
Google File System by design nem tud törölni. Az viszont teljesen saját fejlesztés. Cserébe valóban baromi gyors.


Normális HUP-ot használok!

Ja, pl. Synology NAS-okon.

Össze vagyok zavarodva. A btrfs bináris blob, nem nyílt forrású kód? Valamint a vanilla kernel tartalmaz bináris állományokat? Jó, lehetnek firmware-ek, microcode, de ezektől eltekintve.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

> A btrfs bináris blob, nem nyílt forrású kód

Ezt hol látod? Itt csak annyi látszik, hogy a forrása módosul, a pull requestekben sem szerepelnek bináris fájlok:
https://patchwork.kernel.org/project/linux-btrfs/list/

Akkor mit értünk kódnyitás alatt?


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Szerintem ez nem egy egyszeri kódnyitás, hanem folyamatosan commitolnak a forrásba, csak ritkábban foglalják össze a lényeges fejlesztéseket a sajtó számára.

Gondolom házon belül patch-ekre értik, amiket nem tettek eddig közzé.

Így már értem. Az nem volt világos, hogy forkolták, s közel voltak a GPL-sertéshez. :)


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Mitől lenne GPL-sértés, ha saját célra forkolok valamit a linux kernelből, és nem adom közre sem a binárist, sem a forrást?

Zöldséget beszéltem, hiszen csak akkor kell a forrást is elérhetővé tenni, ha eladják a binárist például egy készülékkel.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Jaja, lentebb en is beneztem kb ugyanezt :D

ha eladják a binárist

Ha bármilyen módon terjesztik az eredményt, akár pénzért, akár ingyen.

És erre a problémára jött létre az AGPL :D

Igen, ezt már tényleg így értettem. A terjesztik a megfelelő szó. Amúgy az AGPL-nek mi a zanzásított lényege? Hadd ne kelljen elolvasnom.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Akkor is át kell adnod a változtatásaidat, ha nem adod oda a felhasználónak magát a szoftvert, csak szolgálatástásként teszed számára elérhetővé.
Magyarul nem tudod a GPL-t "megkerülni" azzal, hogy nem terjeszted a szoftvert, csak online felületet adsz, és csak a saját szervereiden fut valójában.

Ezt annyiban túlzásnak érzem, hogy a software-t módosító úttörő becsületszavára van bízva a dolog szerintem, hiszen honnan tudná azt bárki megítélni, hogy valamit módosítottak a software-en, amellyel szolgáltatnak.

A GPL annyiban logikus, hogy a nyílt software maradjon továbbra is nyílt, s ha valakinek van kedve, affinitása, tovább hekkelhesse a termékét, pl. a TV-jét, ha abban nyílt software fut.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Biztosítani kell egy forráskód-letöltő szolgáltatást. Onnantól mindenki ellenőrizni tudja maga, hogy azonos szolgáltatás kap-e ha saját szerverén indítja el. Nyilván funkciókat nem érintő optimalizációval lehet trükközni. Viszont fontos, hogy még AGPLv3 licencnél sem kötelező mindenkivel a világon megosztani a forráskódot. Csak a hálózati szolgáltatást valóban használó userek számára kell biztosítani a forráskód elérhetőségét.


Normális HUP-ot használok!

Forkoltak es megnyitottak a forraskodjat az altaluk hasznalt de at nem nevezett forknak (lasd meg mysql-bol a facebook fele ami ugyanugy mysql neven fut felejuk).

Tehat ami tortent a cikk szerint az igy illeszkedik bele a valosagba.

Nyilt forrasu volt a btrfs
Forkolta a Facebook es lett "sajat btrfs"-e
Meg kellett volna ezt nyitni mar egy ideje licenc okokbol
Jofejek voltak, mert lehet, hogy a kod megnyitasahoz meg ugyvedi felszolitasig se kellett eljutni

Update: eszrevettem, hogy GPLv2-es, nem 3-as, lehet nem is volt kotelezo megnyitniuk

GPLv3 licencű kód forrását sem kötelező publikálni ha csak saját szervereiden használod.
Ilyen kötelezettség csak AGPLv3 licencű kódoknál illetve ennek előd licencénél van.


Normális HUP-ot használok!

Meglepett, hogy BPF-hez LLVM kell.

Nem feltétlen, lehet bájtkódot kézzel is írni :-) Engem is zavar, hogy GCC-hez nincs még most sem BPF target, máshoz meg nem használok clang-et, emiatt van fent a gépen.

Az is szép, amikor kernelben helperek vannak ami küldő LLVM-et hív, ha kellene BPF-hez: https://elixir.bootlin.com/linux/latest/source/tools/perf/util/llvm-utils.h

Nemide