A SUSE bejelentette, hogy 10 millió dollárt költ arra, hogy forkolja a RHEL-t

openSUSE, SUSE, SLES

A SUSE vezérigazgatója, D.P. van Leeuwen a Twitteren bejelentette, hogy cége teljes mértékben elkötelezett egy Red Hat Eenterprise Linux-kompatibilis disztribúció létrehozásában. Olyannyira, hogy több mint 10 millió dollárt szán a projektre, amelynek célja egy kompatibilis RHEL fork létrehozása a publikus RHEL forráskódok felhasználásával.

Teljes bejelentés itt olvasható.

( trey | 2023. 07. 11., k – 12:41 )

Na igen ... látom ám, mi folyik itt! 🧐 A SUSE most meglovagolja a bizonytalanságot.

Csak, hát ha fork lesz valóban, azzal az a baj, hogy ... fork. Vagyis egy ponton történő elágazás. Hogy lesz az rendre bug-for-bug kompatibilis a későbbi RHEL kiadásokkal? 🤔

trey @ gépház

mit tudom én... nen nagyon ismerem a Fedora-t. :)
Bár most hogy a Centos is egy rolling release lett(vagy nem?) úgy látom nem sok külömbség van a Fedora és a Centos között, abból a szempontból, ha eredeti RHEL licenszelést akar megspórolni vele az ember.

A Leap a SLES kiadási ciklusát követi, binárisan kompatibilis a SLES-el, tök egyszerűen konvertálható is SLES-é.
Így szerintem felhasználási szempontból a régi CentOS-hoz áll közelebb.

A Tumbleweed rolling release, így használati szempontból az akttuális rolling release  RHEL alapú disztrókkal játszik egy pályán.

CentOS Streamet használok self-hostinghoz, és annyival egészíteném ki, hogy nem rolling release. Ez vállaltan egy hibás kommunikáció volt kezdetben, azóta már nem is hivatkoznak így rá. A Streamnek vannak major verziói és más stable release disztrókhoz hasonlóan manuálisan kell upgradelni egyikről a másikra. A rolling alatt arra hivatkoztak, hogy az aktuális releasen belül érkeznek frissítések, és nem minor verziókra van bontva, mint RHEL esetén, ahol ugye van lehetőség adott minor verzión maradni, míg az támogatott. A CentOS Stream viszont olyan frissítési modellt használ, mint a legtöbb disztró, például a Debian. Ez RHEL-hez viszonyítva rolling, de hagyományos értelemben nem.

A rolling alatt arra hivatkoztak, hogy az aktuális releasen belül érkeznek frissítések, és nem minor verziókra van bontva, mint RHEL esetén, ahol ugye van lehetőség adott minor verzión maradni, míg az támogatott

Nekem, "született gentoosnak", magyarázzátok már el, hogy hogyan is kell a RHEL-féle minor verziók lényegét elképzelni:

Felrakok egy RHEL 8.5-öt. Kérem a latest apache csomagot. Ugyanazt kapom-e, mint bármilyen más RHEL 8.x-ről elindulva? Én eddig azt hittem, hogy igen. Azaz a latest fogalom egy 8.x major szérián belül ugyanazt takarja, az, hogy konkrétan melyik minorról beszélünk, az csak az első "frissítsd nekem az összes csomagot" parancs lefutásáig számít, utána már latest RHEL 8.x-en lesz a gépem.

Mit értettem félre?

Példánál maradva, minden minor verziónál meg van határozva, hogy melyik Apache verzió támogatott. Ha 8.x-ről frissítgeted a rendszert 8.5-ig, akkor az azon támogatott Apache-ot kapod meg, pont úgy, mint aki eleve 8.5-öt telepített. Ha ez nem tetszik, akkor adott a lehetőség korábbi minor verzión maradni és addig kapod az Apache-odhoz a patcheket míg az támogatott. Ez a minor verzió pinning soha nem volt támogatott RHEL klónokon, elvileg lehet valamit gányolni, de normális módon csak a Red Hat subscription-managerével működik.

A 8.5 az EOL, nem biztos, hogy érdemes felrakni :) de ha megtetted és frissited, akkor kapsz egy 8.8-at.

Az apache nem a legjobb példa, mert minor RHEL verzióval nem változik, szóval ugyanazt kapod.

A minor verziókon maradásnak akkor van értelme, ha fizetsz extended update supportért, ami 2 év minor verzió supportot jelent, ha ez nincs, akkor félévente megy az updattel a legfrissebbre, ezalatt kapsz pl patcheket a kernelhez és egyéb minor verzió függő csomagokhoz.

minor verzión maradáshoz: subscription-manager set-release 8.6

Nem túl közismert, de a Suse már most is árul supportot RHEL-hez, (lásd Liberty Linux) és  pl. a Suse Manager nevű linuxos menedzsment rendszerükben is van lehetőség a SUSE által "csomagolt" RHEL patchek terítésére.
A Suse-nak is van némi bevétele az RHEL vonalból, mert saját termékeket és szolgáltatásokat épített rá, akárcsak az Oracle, és ezek sorsa vált bizonytalanná az RHEL (IBM) húzása miatt.

Egyébként saját linux distro feljesztésében is van némi tapasztalatuk, illetve a két disztribúcióban a userland is jelentős részben azonos programokból áll. Elég sok az átfedés az RHEL és SLES kódbázisában, szólva nem teljesen duplikált az erődeszítés,  az más kérdés, hogy mi értelme van két, egymástól azért elég nagy mértékben eltérő distro fenntartására és fejlesztésére.

A kompatibilitás úgy is megoldható, hogy az Oracle, Suse, egyéb downstream disztrók összefognak, és közösen csinálnak egy forkot, aminek van egy olyan lendülete, és ereje, hogy az eredeti RHEL-t egy idő után elsorvad, és ez az új valami lesz a de-facto első számú enterprise linux, amit majd a Red Hat cég újrabuildelhet saját néven.

Na, ez nekem teljesen új. Elég hihetetlen. Nem az, hogy meglovagolják a helyzetet, de hogy nem a saját ökoszisztémájukat adják el, hanem a konkurencia termékébe ölnének ennyi pénzt hirtelen. Ez kicsit olyasminek hangzik, mintha az Intel AMD procival akarna kereskedni. Morbid.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Ez nagyobb részt lesz jogászkodás szvsz.

Copyleft licencű szoftvereket bármilyen extra megállapodást is kell aláírni a RH-tel, továbbra is nyugodtan lehet publikálni, újrafordítani és a binárisokat publikálni. Azaz GPL, LGPL ezekből v2, v3 és társaik. Ezzel semmit sem tud kezdeni a RH. Jó régen próbálkozott már szolgáltatás-trükkel kibújni a copyleft licencek alól egy sokkal kisebb kalandor cég, akkor sem jött be. A megengedő licenceket mint BSD, MIT, Apache viszont bármikor megváltoztathatja a RH legálisan kereskedelmi licencre. Arra már nem lenne legális kerülőmegoldás. Szintén szvsz, de ezt nem fogja meglépni a RH a bizalomvesztés miatt. A vastag pénztárcájú RH fizetős ügyfelek pont a vendor lock-in elkerülése miatt váltottak RHEL-ra, jellemzően valamilyen kereskedelmi Unixról. 

Szóval egyik megoldás, hogy elkapják a CentOS Streamen elérhető forrást az új RH release pillanatában, amikor megegyezik a két rendszer forráskódja. Azt követő updatekre azonban már nem ad megoldást a CentOS Stream. 

Másik megoldás, hogy akár free userként RH ügyfelekké válnak az érdekeltek. Gyakori tévedés, hogy free szoftver bárkinek free. Még a copyleft GPL licenc is csak az ügyfelek számára biztosítja a jogot forráskódhoz és annak továbbpublikálásához.  Erre épít a RH is, de az ügyfeleiknek már oda kell adnia a forráskódokat. Pontosabban copyleft licencűek kötelező odaadnia a RH-nek, a megengedő licencűeket de jure nem muszáj de jelenleg azokat is adja. Az előfizetői szerződés ugyan tiltja ezeknek a kódoknak a továbbpublikálását forrásként, illetve továbbpublikálását lefordított binárisként, de az előfizetői szerződés sokkal gyengébb jogvédelemmel rendelkezik mint az érintett szoftverek eredeti licence az eredeti copyright birtokosától ami nagyon sok esetben persze nem a RH. Tehát Almások, Rockysok, vagy a most csatlakozó Suse előfizet, leszarja a RH előfizetői szerződést és élnek a licencek biztosította jogukkal és folytatják ami korábban. Annyit tehet a RH, hogy törli az előfizetői státuszukat, többet nem. Majd újra előfizetnek, bevetik a kajmán-szigeteki cégeket, John Doet, homelesseket stb, free  accountoknál mindegy is. A RH természetesen megszűntetheti a free developer accountokat, de ennek is lenne következménye. Új regisztrációt lehet egy nagyobb összeghez kötni de ez is negatívan hatna a RH üzletére. Szóval lehet itt egymás faszát csalánnal csapkodni, meg az Oracle is megszűntetheti a RHEL hivatalos támogatását viszontválaszként, jöhet akár a Unix wars 21. századi felvonása. De ha túltolja a biciklit a RH csak az lesz a vége, hogy egy  nagy enterspájz linux helyett lesz majd kettő, miután a többi ebben érdekelt összefog a közös cél érdekében. A problémakörnek a nemzetközi vonzatait még akkor nem is vizsgáltuk. Valamelyik Oracle doksiban láttam, hogy támogatott platformok között van a kínai NeoKylin ami kínai akadémiai meg nemzetvédelmi nagy nemzeti rendszer arrafelé. Eredetileg Freebsd alapú volt, a NeoKylin óta már Linux. 

“Az ellenség keze betette a lábát”

Nem kellenek Kajmán-szigetek meg Kaya Ibrahim. Az Alma / Rocky valamelyike már megmondta, hogy hogy lesz ez: simán felbootolnak egy RHEL VPS-t valamelyik felhőszolgáltatónál, azzal jár a subscription, tehát automatizállt módon, implicit lépnek efemer szerződésbe a RH-val,  és onnan le tudják húzni az srpm-eket.

Az a Rocky volt, és azt is csak addig tudják játszani, míg a RH azt is meg nem tiltja, szépen megváltoztatja a supscription feltételeket, hogy felhős image-ben lévő forráskódot se terjesztheted, és vége is a trükközésnek. Az Alma kompletten feladta, ők nem csinálnak semmit, próbálnak RHEL-kompatibilisek maradni, de saját kódbázison, belátták, hogy nem tudnak küzdeni az RH ellen.

Egyébként az RH-et be kell perelni GPL jogsértés miatt, mivel a legtöbb csomag kódját nem zárhatják be. A GPL pont azért copyleft, mert a rá épülő munkáknak, extra kódnak, patcheknek is azonos licenc alatt kell kijönniük, ez alól nincs kibúvó senkinek. Az a baj, hogy az IBM, Red Hat, meg sok nagy cég a mai napig nem érti, hogy hogyan működik a FOSS világa, ők csak azt látják, hogy van egy csomó körszakállas, szandálos hobbibohóc, aki ingyen elvirtuózkodik kódokkal, és ki lehet őket használni profitért, meg ügyvédhaddal úgyis bármit ki lehet jogászkodni ellenük, mert komolytalanok, nem jogászok, csak egyéni fejlesztők.

Sokan félre is értik a FOSS-t meg a GNU-t, Linuxot, azt hiszik, hogy ezek jótékonysági szervezetek, akik azért dolgoznak, hogy Mari néni kiöregedett laptopjára legyen ingyenes Windows-pótlék, meg Afrikában az éhező gyerekeknek operációs rendszere. A nagy bránert. Ez is egy üzlet, csak itt nem pénzre megy ki a játék, hanem egy ökoszisztémát azért biztosítanak ingyen, azért adják oda a sok éves munkájukat bárkinek ingyen, hogy aztán mások is tovább ingyen építsék az ökoszisztémát, vagy ha nem is építik tovább, de ingyen tesztelik, lesz bugreport, meg szívességi alapon a közösség supportot nyújtson akárkinek. Ez egy kölcsönös függőségi játék, kapok-adok alapon megy. Igen, lehet használni ingyen, lehet forkolni, de be kell tartani a játékszabályokat, és a hozzátett munkát sem lehet kódügyileg bezárni. Ezzel tisztában kell lenni.

A RH ezzel elvágta maga alatt a fát egy életre, szépen mindenki el fog tőlük pártolni. Nagyon remélem, hogy pert fognak kapni a nyakukba emiatt.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

( DirtY_iCE | 2023. 07. 11., k – 12:58 )

Mennyi fork meg alternativa lett itt hirtelen, majd nezzunk ra 1-2 ev mulva, hogy mi marad meg.

I hate myself, because I'm not open-source.

( ggallo | 2023. 07. 11., k – 13:41 )

Én azt a részét nem értem, hogy hogyan lesz RHEL kompatibilis a forkolt rendszer, ha nem erik el/nem használhatják a jövőben az eredeti RHEL forráskódot? Reverse engineering megy majd folyamatosan, hogy ugyan mit változtattak, amit nekünk is meg kell lépni?

Vagy elég, ha a forkolás pillanatában kompatibilis, azzal átcsábul X felhasználó, majd megy az új projekt a saját útján onnantól?

Mondjuk én már azt sem értettem, hogy a CentOS helyére miért kellett mindjárt két utód (az Alma és a Rocky).

Persze ez nem csoda, mert én magát az RHEL ökoszisztéma imádást sem értem. Mit tudnak, amit a Debian (alapú disztrók) nem?

"Mit tudnak, amit a Debian (alapú disztrók) nem?"

10+2 év supportot. Rohadt sokat számít, ha valahol nem kell a legacy szart migrálni 3 évente új oprendszerre, mert 12 évig ki lehet pipálni a security riportban a "Supported OS" rubrikát.

"Mit tudnak, amit a Debian (alapú disztrók) nem?"

Hogy felrakod, és addig megy, amíg ki nem rohad alóla a vas, vagy le nem váltják (nem mellesleg betonstabilan). Ez esetekben meg az aktuális verzióból lehet újat húzni, és újabb 8-10 év megvan.

"Sose a gép a hülye."

VDO az egyetlen opció ha tömörítésre van szükséged, BTRFS-t kivezette a Redhat, ZFS támogatás soha nem volt. VDO-val az a legnagyobb bajom hogy a fájlrendszer szintű deduppal ellentétben nem a fájlok mérete lesz kisebb azonos storage méret mellett, hanem a volume logikai méretének adhatsz meg nagyobbat, nagyjából hasraütve.
Emiatt megjósolhatatlan hogy a kérdéses adat elfog-e férni a logikai köteten, ha pedig a fizikai hely fogy el (akár úgy hogy a logikain még jócskán marad hely) a teljes vdo volume a kukába végezheti. Előnyök nélküli kockázatot jelent ez így.

Mindenkinek válaszolva az örökké plusz egy évig supportált RHEL származékokra, mint fő előnyre (és nem a Debian, vagy az én korlátosságom, pláne nem az RH védelmében):

- ha 10 év support kell, mert ki kell pipálni az enterprise checklist-en, akkor ott a fizetős cucc, vegye meg az enterprise

- ha "maszek" és/vagy nem akarnak pénzt költeni, akkor legyen elég 5 év (amit a legtöbb disztró tud alapból vagy LTS verzióval)

- általában óriási szívás 2-3 év frissítetlenség után is tovább lépni, még folyamatosan fejlesztett szoftverekkel is, nem még olyannal, amihez nem nyúltak, mondván a múmia disztrón megy. Pláne szívás lehet 10 év után

általában óriási szívás 2-3 év frissítetlenség után is tovább lépni, még folyamatosan fejlesztett szoftverekkel is, nem még olyannal, amihez nem nyúltak, mondván a múmia disztrón megy. Pláne szívás lehet 10 év után

2-3 évente jönnek ki új főverziók, akinek friss cucc kell, lépegethet, akinek régi kell, maradhat az utolsó pillanatig

Nem 2-3 év frissítetlenség. Rendszeresen updatelve van, jönnek hozzá a javítások, sőt, rengeteg dolgot backportolnak vissza, kernelbe és service-ekbe is (több fejlesztő volt már, aki nem értette, hogy hogy működik valami x.y verzióval, amikor mondjuk az adott feature elvileg z.w-vel jött [z.w>x.y]). Az előnye viszont, hogy ami egyszer megy, az garantáltan menni fog utána is.

- Nem ébredsz egyik reggel arra, hogy nem megy a software ami addig ment.

- Nem jó a konfig ami addig jó volt.

- Deprecated lett egy modul és eltávolították ami addig volt.

És nem, egyáltalán nem szopás lépni előre. Pl. pár hete kezdtem el foglalkozni a 9-essel, és annyira meglepően kevés és jelentéktelen dolog változott, hogy tök sima volt "supportáltá tenni" (automata telepítés, management eszközök, template-ek, scriptek, stb). (A 6->7 váltásnál a systemd, a 7->8 váltásnál a modulok sokkal nagyobb mértékű változás volt, de ezek is megugorhatók nagyobb gond nélkül).

"Sose a gép a hülye."

( dcsaba v | 2023. 07. 11., k – 23:10 )

Az árnál pár tizedes jobbra ment :DDD

Kötözni való bolondok :D

Mennyibe kerul egy emberev?

Mennyibe kerul egy termekvonal es verzioinak felallitasa, maintenance es support aktivitasai N even keresztul?

Mennyibe kerul a kulonfele tamogatott vas / virtualizacios reteg eves viszonylatban? Mennyibe kerul egy-egy labor felallitasa ezekhez?

Hany evre van ez a $10M elosztva?

 

Mennyi az LWF az adott cegnel?

( eyez00 | 2023. 07. 12., sze – 21:52 )

en csak egy kavet kerek.

apt-get update

apt-get install coffee

( lave | 2023. 07. 12., sze – 22:18 )

Szerkesztve: 2023. 07. 12., sze – 22:25

Szerintem itt két fontos tényező van.

1. A kódbázist azon a ponton forkolják, amely állapotra a felhasználók nagy részének workloadja certifikálva van.

2. A forkolt ág egy alapítvány fennhatósága alá kerül, amihez, ha akar és tud, akár a HUP felhasználók közössége is csatlakozhat, kontributálhat és esetleg beleszólása is lehet a döntésekbe.

( Raynes v | 2023. 07. 15., szo – 18:23 )

Szerkesztve: 2023. 07. 15., szo – 18:24

kiszerk.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”