A Red Hat elismerte, hogy versenytársak miatt változtatott a kernelforrások közzétételével kapcsolatos gyakorlatán

AlmaLinux, CentOS, Fedora, Red Hat, Rocky Linux

Nemrég volt arról szó, hogy a Linux kernel közösség egyes tagjai azt állították, hogy a Red Hat elkezdte titkolni azt, hogy milyen változtatásokat eszközöl azon az upstream kernelforráson, amelyet RHEL6 termékéhez használ fel. Ez abban nyilvánult meg, hogy a Red Hat Enterprise Linux 6 kernelforrását korábbi gyakorlatától eltérően nem az upstream kernelforrás-csomag + patchek, hanem egy már patchelt kernelforrás-csomag képében tette elérhetővé.

Azok, akik felhívták a figyelmet erre a gyakorlatra, azt gyanították, hogy a Red Hat így próbálja megnehezíteni a termékét klónozó, arra építő versenytársai dolgát.

A tipp helyesnek bizonyult, hiszen a vállalat műszaki igazgatója, Brian Stevens elismerte, hogy ez áll a dolog mögött:

When we released RHEL 6 approximately four months ago, we changed the release of the kernel package to have all our patches pre-applied. Why did we make this change? To speak bluntly, the competitive landscape has changed. Our competitors in the Enterprise Linux market have changed their commercial approach from building and competing on their own customized Linux distributions, to one where they directly approach our customers offering to support RHEL.

Az okok elolvashatók a Commitment to Open blogbejegyzésben.

ha azt veszem, hogyan bánt az Oracle az OpenSolarissal különösen érthető a Red6 lépése. kíváncsi vagyok mit csinált volna az Ora, ha a Red6 hasonló copy/paste/recompile módon ad ki saját enterprise Solaris változatot?
kár, hogy a CentOS közösség is megszívja ezt, pedig nem miattuk van az, ami van.

A CentOS miért szívná meg? Egy-az-egyben kiadják a RH forrásból azt, ami ott kijön. Szerintem az összes többi csomaggal is pont ezt teszik.

Aki ezen bukik, az az, aki szeretne szelektálni a RH által berakott patchek közül.

De elnézést: ha valaki nem hajlandó azt a kurva sok melót beleölni, ami a fixek/feature-ök sok évvel ezelőtti (stabilnak kikiáltott) kernelbe backportolásához kell, és nem hajlandó ezért fizetni sem, az vagy ne akarjon szelektálni, vagy használja a bleeding-edge, Linus-féle release-t.

De elnézést: ha valaki nem hajlandó azt a kurva sok melót beleölni, ami a fixek/feature-ök sok évvel ezelőtti (stabilnak kikiáltott) kernelbe backportolásához kell, és nem hajlandó ezért fizetni sem, az vagy ne akarjon szelektálni, vagy használja a bleeding-edge, Linus-féle release-t.

Már nem először látom ezt. Hol nyilatkozta azt a RH, hogy aki fizet érte, az megkapja a szeperált patcheket?

azert, mert az elofizetoknek szolo oldalak (meg a mogottuk levo informacio) hasznalatat egy Terms of Use szabalyozza, ami explicite megtilt bizonyos dolgokat. pl. a 6. pont a RH Content terjeszthetoseget korlatozza, de kivetelkent kijelenti, hogy konfliktus eseten az adott Content licensze a mervado, nem a 6. pont. eppen ezert butasag a RHEL kernel patcheket csak ott terjeszteni, mert azok GPL ala esnek es emiatt barki onnan leszedheti es elerhetove teheti oket.

Beperelte volna szabadalomsértésért, gondolom.

Másrészt ez egy logikus lehetőség, ill. a fejlesztő számára probléma a supportból élő nyílt forrású fejlesztéseknél, hogy supportot más is tud adni, és olcsóbb, mert fejlesztenie nem kell. Kérdés persze, hogy nem megbízhatóbb-e, ha az supportálja, aki csinálta.

Nem az újracsomagolók (CentOS, Scientific Linux, stb.) szempontjából bosszantó, hanem pl. a kernelfejlesztők és a más terjesztések készítőinek szempontjából bosszantó.
Most akkor a többi terjesztés is elkezdi majd dugdosni a patcheit?
A GPL nem arról szól, hogy mindenki végzi a dolgát és a keletkezett kódot megosztják? Én használom a többiek eredményét, és átadom a sajátomat. Nem méricskélünk, hogy ki mennyit tudott hozzáadni a végeredmény mindenki számára hozzáférhető.
--
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba és kész!

( iron v | 2011. 03. 06., v – 18:50 )

Sajnos így a kisebb disztribek elesnek olyan fixektől, amik nem kerültek be upstream-be. Vagy legalábbis sokkal nehezebb megtalálni egyes javítást vagy improvementet...

Nem csak a kicsik! Szinte mindenki Redhat patch-okat "lopkodott", ami ugye csak egy dolog, mert ez a nyílt forráskód lényege. Na de nem egyszer láttam olyan patch-ot ami minden bitre egyezett csak a header-ben volt más név írva. Na ez azért köcsögség volt....
-------------------------------------------------------------------------------------------
Mit használok? Na, na, na? Hát blackPanther OS v11.1-et * www.blackpanther.hu

( saxus | 2011. 03. 06., v – 18:51 )

Ilyen, amikor a "GPL szellemisége" találkozik egy profitorientált céggel :)

----------------
Lvl86 Troll

( lovas | 2011. 03. 07., h – 09:13 )

Ha tévednék, vagy mellénéztem valamit, akkor eleve elnézést. De nem arról volt szó, hogy a Red6 azt a gyakorlatot akarja megnehezíteni, miszerint az Oracle és a Novell konkrétan kigolyózza őket a RHEL supportból? Arról olvastam éppen, hogy ezek ketten úgy házalnak RHEL-t használó cégeknél, hogy nem kell semmit sem változtatniuk a rendszeren, de olcsóbban jönnek ki, ha majd inkább őket választják supporthoz, és nem a Red6-et.

Arról szüttyögtek, hogy az upstrem továbbra is a megszokott formában kapja a dolgokat, és a centos sem marad ki a jóból.

( artifex | 2011. 03. 07., h – 10:54 )

Ha a forrása megvan, akkor egy vanilla kernel forrás és a RHEL kernel forrásra nem lehet diff-et adni esetleg? Tudom, ez nem ugyanaz, mint ha minden egyes patch-et külön adnak, de szép feladat programozóknak, hogy kiszemezze a nagy diff-ből milyen kicsit vannak benne és ami marad, az a RedHat-é. :-)

Mondok jobbat. Fúrta az oldalam a kíváncsiság és megnéztem ezt:

ftp://ftp.redhat.com/pub/redhat/rhel/beta/6/source/SRPMS/kernel-2.6.32-…

Az URL alapján a 6-os kernel forrás rpm-je. Na szóval ebben bír lenni egy eredeti linux-2.6.32.tar.bz2 valamint 1240 darab patch állomány. Hol itt a rejtegetés?

A 2 HUF-os kérdés:
Mi a különbség a következő 2 parancs között :-)

$ rpm -qipl kernel-2.6.32-19.el6.src.rpm|grep patch|wc
warning: kernel-2.6.32-19.el6.src.rpm: Header V3 RSA/SHA256 Signature, key ID f21541eb: NOKEY
1240 1240 70116
$ rpm -qipl kernel-2.6.32-71.14.1.el6.src.rpm|grep patch|wc
warning: kernel-2.6.32-71.14.1.el6.src.rpm: Header V3 RSA/SHA256 Signature, key ID fd431d51: NOKEY
1 1 24

(Hint: beta vs. hivatalos, végleges RHES kernel)

Nincs véglegesem, nem tudom mi van benne, de igazatok van, figyelmetlen voltam, ezek szerint béta kernel, bár az ftp oldal először nem béta irányból indul.

De ezen a vonalon is egyszerűsödik a helyzet, hiszen nem a totál eredeti és a végleges RH kernel között kell keresni a különbségeket, mert így van már 1240 patch, amit tudunk és csak a többit kell megtalálni (beta vs végleges forrás diff). Feltételezve persze azt, hogy nem direkt szar és később nem használt patch-eket tesz a betába.