RedPatch - visszaszúrt az Oracle a Red Hat-nek

Címkék

2011 elején volt szó arról, hogy a Red Hat megnehezíti a külsős kernelfejlesztők dolgát azzal, hogy a Red Hat Enterprise Linux 6 kernelforrását egy darab nagy tarball képében szállítja ahelyett, hogy szállítaná az upstream kernelforrást és amellé tenné az egyes, általa készített patcheket külön-külön. Egyesek szerint azért, hogy megnehezítse a konkurencia, főként az Oracle dolgát, amely újracsomagolja a Red Hat forrását az Unbreakable Linux termékéhez. Amikor a Red Hat-nél rákérdeztek erre a dologra, a vállalat hivatalos válasza "no comment" volt.

Most az Oracle virtuálisan beintett a Red Hat-nek. A Ksplice blogban tegnap bejelentette, hogy a Ksplice csapat nyilvánosan is elérhetővé tette RedPatch nevű git tárolóját. Benne a Red Hat által a saját kerneléhez készített összes változtatás forrása megtalálható "egy változtatás, egy commit" alapon. A RedPatch nyitva áll bárki számára. Használható git-tel, böngészhető gitweb felületen, a benne található patchek pedig a GPL feltételei szerint terjeszthetők.

A részletek a bejelentésben.

Hozzászólások

> Mikor a fagyi visszanyal...

Az a baj a fagyival, hogy idővel elolvad ...

Komolyra fordítva a szót, nekem erről inkább az jut eszembe, hogy ezzel támogatást nyer a RedHat-en belül egy saját "live patch" megoldás kifejlesztése. [ Hol lehet itthon RedHat részvényt venni? ]

Ugyan már! A nyílt forrás természetéből adódik, hogy nem engedi, hogy egy cég betartson a többieknek ilyen szánalmas trükkel!
Ha az Oracle nem teszi meg, megcsinálta volna más RedHat variációt gyártó társaság.
Ráadásul a Linus féle kernel és a RedHat nagy tarball forrás megléte esetén a folyamat valószínűleg jól szkriptelhető a különbség kinyerésére. Persze szép dolog az Oracle-től, hogy megcsinálta!
--
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

Jol scriptelheto??? :D

Most nincs kedvem kifejteni (valoszinu masok megteszik helyettem) de, hogy minel elobb kijavitsak egy boszmeseget nehogy elhiggye valaki: ha van egy kernel.tgz-d meg egy redhat_kernel.tgz-d akkor azokbol kozel lehetetlen scriptel kinyerni az egyes RedHat patch-eket.

Tenyleg?! Neked script-et kell irni ket konyvtar kozotti kulombseg kinyeresehez? Szoval akkor az Oracle sracok csinaltak egy git tarolot 1 db patch file miatt es erre ez a nagy felhajtas? Es amugy mi ertelme is lenne egyben a kulombsegnek?

Nem, itt fogalmatlansagrol volt szo, ami annyira kemeny, hogy meg en sem (ertsd: hozzaszolasaim nagy resze segitseg nyujtas es nem felesleges "te vagy a hulye mert igy gondolod" hsz) tudtam elmenni mellette es ezert elnezest is kerek.

En itt reszemrol befejeztem ezt a thread-et.

Hát én ezzel nem feltétlenül értek egyet... Egy fájlrendszer patch nem csak a fs/fajlrendszer/valami.c fájlt érinthet, hanem hatással lehet más programkódra, ami miatt egy harmadik fájlrendszerbe is kell illeszteni kódot... Meg nem mondom mikor, találkoztam olyan GFS2 javítással, ami miatt más kódba is be kellett 2-3 plusz sort, mert változott a könyvtárszerkezet felolvasásánál esetlegesen előforduló hibák kezelése... nem véletlenül izzadtak az Oracle fejlesztők.
Megjegyzem az Oracle megengedhetné magának, hogy fizessen valamennyi licencet az upstream fejlesztésért, persze a gplnek ez a lényege, hogy akár megteheti, hogy nem teszi (meg a BSD-nek is, ott meg még a különbséget sem látod, ha nem akarják), de talán érdemes lenne eltartani a sok kernel fejlesztőt a redhatnél. Jó példa erre a Zentyal, akik korrekt módon megállapodtak az Ubuntuval, ha valaki fizet a Zentyalnak, az kap Ubuntu támogatást is, mivel az Ubuntu részesül a bevételből. Ezt nevezik üzleti korrektségnek.

Számomra azért nem árukapcsolás, mert általában az egy negatív dolog szokott lenni. Itt nem az, mert nem kapsz olyat, ami nem kell. Itt az Ubuntu alap, mert azon alapul a Zentyal. És Ignacio - a Zentyal vezetője - teljesen jól felismerte, hogy ha függsz valamitől, akkor nem árt, ha mondjuk biztosítod azt, hogy az alapok jók legyenek, biztos legyen a háttér, csorgass vissza valamennyit. Természetesen a Canonical jól megvan aká Zentyal nélkül is, de mondjuk egy idő után elmennek fejlesztők jobb lehetőségekért, akkor az visszaüt a Zentyalra. Plusz, még további módon is jól jár, mert innentől, hogy onnan is jön pénz, a Canonicalnak érdeke, hogy a Zentyal számára fontos dolgok jól működjenek, fejlődjenek. És ezzel mindenki jól jár.
Számomra ez pozitív, míg az árukapcsolás negatív. Természetesen egyéni okokból mindenki láthatja másként. Remélem sikerült rávilágítanom a különbségre.

De, te valasztod meg a cascot a hitelnel, sot van hiteles auto casco nelkul is. (vettem fel igy is ugy is.) De bevallom 500 Ft-tal (12300-at fizetek 11800 helyett) fizetek tobbet a hiteles cascoert mint amit a szabadon valasztottert fizettem volna. Ellenben amikor 3,5 millios karom volt a kocsin nekem 50 rugoba fajt ;o) Thx casco ;o)

Ellenben Pl bubuntu alig csorgat vissza debianba noha sz@rni sem tud nelkule szoval ez egyoldalu az ubuntunal is... Vagy ha fuggetlenul csinaljak a csomagokat akkor vegyek mar le a debian flag-eket pl a mysqldump-rol illetve a syslinux-rol ;o) Itt csak az motivalta a bubuntut hogy kell neki a patch...

Jól értem-e, hogy a következő történik:
- Van a RedHatnek egy fizetős ügyfele, az Oracle (vagy valami leánycége)
- Ezek megkapják darabonként a peccseket
- Mivel GPL, ezért kirakhatják ezeket a peccseket a netre ingyé (sőt, pénzt is kérhetnek érte)

?

Röviden: Nem

A Redhat odaadja a teljes kernel forrást (ami a redhat rendszer alapja) a partnerekenek de tarball formában, így a partnernek fogalma nincs hol keletkezett változás. Oracle-nek se tetszett ez, és ráállítottak egy csapatot, hogy gobozza ki a szálakat és nézzék össze, hogy a main kernel és a Redhat kernel között mi a különbség. Megtették, az összefüggő kódrészeket pedig külön patchekbe csomagolták, így elvileg megnézhető, hogy mely patch pontosan mit is módosít, és mely C file-okat érintett.
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

A lényeg, hogy ez nem beintés a red hat felé. Ugyanis a red hat továbbra is 1 nagy tarballban fogja publikálni a forrást, vagyis az oracle továbbra is kénytelen melózni vele, ha patchenként szeretné azt látni. Ez legfeljebb a red hat többi partnerének jó, mert ezt a melót elvégzi helyettük az oracle. Viszont nekem úgy tűnt, másokat nem zavarta annyira, hogy 1 nagy tarballban kapták meg a forrást, és valószínűleg a red hat-et sem zavarja, hogy a többi partner is láthatja, hogy milyen patcheked adtak hozzá a forráshoz.

Lehet, valamit benezek ezzel kapcsolatban, de diff-rol meg nem hallottak?

Nagyon benézed. 1 diff nem egyenlő az összes változás külön kezelésével. Olvasd el a fenti szálakat. Fontos tudni az összefüggéseket, ha te is hozzá akarsz nyúlni a kernelhez. A RH ezt a lehetőséget vette el az Oracletől, legalábbis, hogy könnyen menjen. Mivel az Oracle csak felhasználja a RH dolgait, egy az egyben majdnem, és ezt saját termékként adja el.
Ez nem olyan, mint, hogy a redhates kernel patchet egyébként használja a vanilla kernelben, mikor visszakerül a többi disztrib, hanem azt csinálják, mint a CentOS vagy a Scientific Linux, csak ők még megpróbálják a RedHat ügyfeleket, akik fizetnek a szoftverért, magukhoz csábítani, gyakorlatilag a RH termékével 99%-ban megegyező dologgal. Megjegyzem, a licenc lehetőség megengedi nekik. De még nem látom az Oracle Linuxra áttérő tömegeket.

Mondjuk mi is pont azért fizetünk linux-ért, hogy normális támogatást kapjunk hozzá, ne pedig
majd egyszer megcsinálja valaki, illetve a vasak amit használunk certified-olva vannak, így biztos, hogy minden
műxik ahogy annak működnie kell, ha meg nem, akkor meg van hova fordulni.

údenagybeintés... ez már akkor is vihar a biliben volt.

A centoses srácok például egy vállrándítással intézték el.

>>: sys-admin.hu :<<

Ez nem a készítésről szól hanem a supportról. Akinek csak az kell, hogy működjön a dolog (SL, CentOS) az semmit sem veszített vele. Azonban az Oracle, akik tulajdonképpen a Red Hat munkáján keresnek, jól megszívja vele, mert nehezebb rájönniük, hogy mit változtattak és ezzel megnehezítik a rendes supportot.
Lehet persze mondani, hogy a Red Hat szemét mert ezt csinálja, de ugyan úgy lehet azt is mondani, hogy az Oracle az. A valóság viszont az, hogy mind a ketten betartják a "játékszabályokat" (GPL) miközben védik a saját érdekeiket.

jol ertem hogy a redhat a vanilla+patch1+patch2+..+patchN-t egy tarban tettek kozre, viszont az oraclenek ez nem tetszett (mert mondjuk egyik patch nekik nemkellett, es vissza akartak vonni), ezert raalitottak egy csapatot aki a tar-bol visszaallitotta a patchX-eket?

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Ugyanakkor ezt elég kivitelezhetetlennek tartom, hogy korrekten megcsinálják. Tegyük fel csinálok 10 változást 3 file-ban, minden patch változtat valamit egy adott file-on. Elég reménytelennek tűnik pontosan visszafejteni, hogy melyik patch-nek melyik változás volt a része, és hogy egyáltalán hány patchnek kéne lennie.

Ez a legjobb esetben is tippelés, és semmi nem garantálja, hogy a végeredmény, a szétbontott patch-ek működőképesek önmagukban, és hogy ugyanolyan sok darab van belőlük, mint eredetileg (szinte biztos, hogy kevesebb részre tudják csak felszabdalni).

azert a redhat sem sajat modositasokat gyart, hanem innen-onnan vadasszak ossze a patcheket. meg kiidulasi alapnak ottvolt a "meg kulonallo patchekbol allo csomag" is. szal csak a megfelelo commitokat kellett osszevadaszni a megfelelo sorrendben. nem konnyu feladat, de nem is lehetetlen...

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!