Konec podpory Linuxu 2.6.32 a Debianu 6.0 (diskuse)

[pavlix]

Nostalgie.

[Michal Kubeček]

Jak pro koho… Až skončí poslední kontrakt na support RHEL 6 nebo SLES 11 SP1, pak teprve bude čas zamáčknout slzu. Ale to ještě pár let potrvá.

[Pavel Kozisek]

nejak se v tom nevyznam:

my mame v nasazeni jeste nekolik centos5 - tam je EOL 2017 a pritom to pouziva jadro 2.6.18. RHEL tedy dela vlastni podporu jadra a nebo co je to ten LKML? (ja vim, vsechno lze dohledat, ale treba to vi nekdo zpatra )

[Roman]

Jo, dělá.

[Michal Kubeček]

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.

[Leinad]

To je vtipný, jak enterprise distribuce dodávají skoro rolling release kernel a pak ho pojmenovávají pořád stejným číslem, aby se ho firmy nebály updatovat 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.

Ubuntu je v tomhle lepší, když starý kernel drží jen bezpečnostní opravy a pak vedle dodává regulérní nové kernely pro novou funkcionalitu.

[Michal Kubeček]

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).

[Pavel Kozisek]

to co napsal predrecnik me tak nejak taky napadlo a proto bych se konkretne rad zeptal:

centos 6 ma to jadro 2.6.32 o ktere tu jde. Aktualni je 2.6.32.573. Vyvojari z RHEL tedy silne na vlastnim distribucnim jadre zapracovali. 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)? A obracene, jsou vsechny znemy vsech distribuci v tom zakladnim jadre? Co kdyz provede distribuce nejakou vetsi zmenu v distribucnim jadre a neda to do mainstreamu. Kdo koordinuje , aby se cely ten vyvoj nerozebehl ruznymi smery?

[Michal Kubeček]

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é.

[Pavel Kozisek]

diky za ty obsahle informace.

jen tak na okraj, vsichni jsme tady ve stredni Evrope zacinali se SuSE, ale jak vidim u kolegu adminu, vetsina ted jede na Centos. Podle toho co se clovek dovi od lidi primo z distribuci (jako treba od Vas) je znat, co je za tim prace. Presto pouzivam Centos (nebo drive SuSE, do 9.3), protoze vlastne od supportu nic nemohu ocekavat. My musime do systemu nandat jeste tolik veci okolo, ze to krome nas vlastne nemuze nikdo supportovat. Proto je Centos idealni. Myslim si, ze u mensich firem je tohle standard. Takze mohu poprat dost tech vetsich zakazniku, kteri vas v Praze a i ty od konkurence v Brne plati

[Leinad]

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.

[Michal Kubeček]

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ů.