Portál AbcLinuxu, 4. května 2025 22:27
Willy Tarreau vydal Linux 2.6.32.70 (LKML) a potvrdil ukončení upstream podpory Linuxu 2.6.32. Toto ukončení souvisí s ukončením podpory Debianu 6.0 Squeeze. Ta měla být ukončena v roce 2014, byla ale prodloužena (zprávička) do 6. února 2016, tedy pět let od jeho vydání. Únorem začíná LTS podpora Debianu 7 Wheezy (Wikipedie).
Tiskni
Sdílej:
1.2.2016 00:22
pavlix | skóre: 54
| blog: pavlix
)
Distribuce si pochopitelně udržují své vlastní jádro, a to i v případech, kdy je založeno na nějaké verzi, která má upstream stable, kdyby nic jiného, tak už proto, že potřebují patche, které se do upstream stable větví nehodí (třeba backporty driverů). Pro představu: momentálně má např. SLES11 SP4 20504 patchů oproti stable 3.0 a SLES12 SP1 9828 patchů oproti stable 3.12. Enterprise verze také mívají podporu podstatně delší, než se udržují upstream stable větve.
Verze 2.6.32 je svou délkou podpory dost výjimečná, ale IIRC už byla její podpora jednou ukončena a teprve po nějaké době se Willy Tarreau rozhodl ji oživit.
To se nedá srovnat s Debianem/Ubuntu, který po vydání dodává hlavně bezpečnostní opravy a jen minimum funkčních změn. To je vtipný, jak enterprise distribuce dodávají skoro rolling release kernel
Vaše představa je sice možná vtipná, ale moc se neslučuje s realitou. Běžné maintenance updaty opravdu jen opravují chyby a featury se přidávají jen zcela výjimečně (a i tak jde jen drobnosti). Něco jiného je service pack (SLES) resp. point release (RHEL), ale těch je za celou dobu života produktu (což v současnosti znamená 10-13 let) čtyři až pět, takže mluvit o "skoro rolling release" je hodně přehnané.
Asi by bylo dobré dodat těm číslům nějaké měřítko. Takže třeba zmíněných 20504 patchů aktuálního SLES 11 SP4 (z nichž tam navíc 2769 bylo už v okamžiku vydání prvního SLESu s jádrem 3.0) je méně, než jich v mainline přibylo mezi verzemi 3.0 a 3.2; celkem jich v mainline od verze 3.0 do dneška bylo 293898. Ve druhém případě z těch 9828 patchů aktuálního SLES 12 SP1 více než polovina (konkrétně 4988) byla už v prvním jádře SLES 12, takže jich od té doby přibylo jen 4840; pro srovnání, v mainline jen mezi 3.12 a 3.13 bylo 12127 commitů.
Ubuntu je v tomhle lepší, když starý kernel drží jen bezpečnostní opravy
Tím chcete říct, že chyby, které nejsou klasifikované jako bezpečnostní, se neopravují? To bych za moc velkou výhru nepovažoval (kdybych vám věřil).
Podival jsem se na ty zmeny jak uvedeno ve zpravicce a tam jsou napr. malickosti ohledne USB. Jak se tyhle zmeny dostanou do distribucniho jadra(distribucnich jader)?
Většinou je to tak, že dokud je příslušná stable větev udržovaná, přebírají distribuční jádra průběžně opravy z ní (kromě těch, u kterých to z nějakého důvodu nejde). Jednak je ale obvykle životnost upstreamových stable větví výrazně kratší než délka podpory enterprise distribucí, jednak i během života stable větve tvoří patche z ní jen menšinu všech distribučních patchů. Jak už jsem ale psal, 2.6.32 je specifická tím, že došlo k přerušení kontinuity, takže i když ji Willy Tarreau posléze oživil, distribuce mezitím přešly do řežimu "we are on our own".
Mimochodem, v poslední době je celkem běžné, že správu stable větve převezme někdo od distribuce, která na ní má postavené své jádro (3.2 - Ben Hutchings - Debian, 3.12 - Jiří Slabý - SUSE, 3.18 a 4.1 - Sasha Levin - Oracle).
A obracene, jsou vsechny znemy vsech distribuci v tom zakladnim jadre?
Úplně všechny pochopitelně ne, existují změny, které jsou z principu specifické pro konkrétní distribuci (namátkou třeba přidání taint flagu pro evidenci toho, že byl natažen nepodporovaný modul). Někdy může také distribuce po zralém uvážení zařadit i patche, které upstream z nějakého důvodu odmítl (u nás třeba stack unwinder, který poskytoval podstatně použitelnější a smysluplnější stack trace). Nebo se může stát, že backport nějakého patche způsobí chybu, která v mainline neexistuje. Naprostá většina ale jsou backporty patchů z mainline; i když jde o opravu chyby nalezené v distribuci nebo featuru potřebnou pro distribuci, je snaha dostat příslušné patche i do mainline (právě proto, aby se množství distribučně specifických patchů udrželo v rozumných mezích).
Kdo koordinuje , aby se cely ten vyvoj nerozebehl ruznymi smery?
Žádný centrální koordinátor neexistuje, ale je to především v zájmu samotných vývojářů. Udržovat dlouhodobě out-of-tree patch, driver nebo dokonce rozsáhlejší sadu změn je dost náročné a není to nic příjemného. Kdo používá třeba VMware nebo VirtualBox na strojích s aktuálním jádrem, ví o tom své.
Richard Brown uvádí, že těch backportů je velmi velké množství a že 3.12 ani moc není 3.12: "While me and others have fought hard explaining that SUSE do a lot of work adding hardware enablement in the SLE Kernel, and the version number is not a good reflection of it's capabilities, this hasn't sent those concerns away" (http://lists.opensuse.org/opensuse-kernel/2015-07/msg00007.html).
Souhlasím s tím, že updatovat technologie je třeba, ale po té, co jsem si zkusil RHEL (zkušební originál, žádný centos) s 2.6.32, se kterou jsem měl dobrou zkušenost na jiných distribucích a na RHEL mi zasekávala notebook (obyčejný notebook, opensource Intel ovladače, nebyl RedHat certifikovaný), tak už z tohohle modelu "stejný název, jiný obsah", nadšený nejsem.
Richard Brown uvádí, že těch backportů je velmi velké množství a že 3.12 ani moc není 3.12
To "velké množství" je relativní, jak už jsem se pokoušel naznačit v předchozích příspěvcích. Zdůraznil bych termín "hardware enablement", nejvíc patchů pochází opravdu z backportů novějších driverů zařízení (síťové karty, storage, …), je tam ale třeba i novější bonding (v podstatě backport verze ze 3.14) nebo rozsáhlý backport btrfs. Tedy ucelené backporty relativně samostatných částí jádra.
A jak už jsem psal, tohle jsou věci, které tam buď jsou hned od začátku, nebo přicházejí s novým service packem (point release), tj. ne že by se vám najednou rozsáhlý backport objevil po běžném "zypper update".
po té, co jsem si zkusil RHEL (zkušební originál, žádný centos) s 2.6.32, se kterou jsem měl dobrou zkušenost na jiných distribucích a na RHEL mi zasekávala notebook
To je věc, která se může stát kdekoli, vy jste měl zrovna smůlu, že se vám to stalo s RHEL. Chyby se při nejlepší vůli mohou vyskytnout v každém software a je na vývojářích, aby je opravili. Koneckonců, zákazníci, kteří si "koupí RHEL/SLES", ve skutečnosti nekupují nějakou licenci, oni si platí support - a je známo, že i u velké části closed source enterprise software tvoří příjmy z prodeje licencí čím dál menší procento celkových příjmů.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.