Samozrejme ze prejde, jen tu panove z RH ruzne mlzi kolem.
Jinak to totiz ani fungovat nemuze. To by museli udrzovat nejmin 3 ruzne verze. A to by si tudiz nijak nepomohli proti centosu.
Jednoduse ti nova verze padne do streamu, a az se odladi, tak nejaka verze +X se objevi v dalsi verzi RH. A presne takhle ti tam budou padat ruzne verze ruznych veci. Jednou nekdo rekne krles ... a vznikne snap pro novou verzi RH.
Totez plati pro patchovani, kde oni budou backportovat patche do tech verzi v RH, ale ne do streamu, tam dostanes novou verzi. Uz proto, ze tam budes mit tak jako tak jine, novejsi verze nez v RH. Takze by to museli backportovat 2x = 2x vic prace nez s puvodnim centosem, protoze tam to delali 1x, pro jednu stejnou verzi.
Nejen, že Stream prostě nepřejde na další verzi, ale podle mě není ani oficiální cesta, jak 8 aktualizovat na 9. Proč by to mělo být jiné s 10? Prostě máš CentOS Stream X, který půjde pomalu dopředu, ale pořád v mantinelech toho, co nakonec skončí v RHELu stejné major verze. Na X+1 se automaticky nepřepne. Nedělá to ani Fedora, která je v těch updatech mnohem drsnější a má k rolling release, jak ho asi chápeš ty, mnohem blíž než Stream.
> Samozrejme ze prejde, jen tu panove z RH ruzne mlzi kolem.
Šíříte tu FUD.
> Jinak to totiz ani fungovat nemuze. To by museli udrzovat nejmin 3 ruzne verze. A to by si tudiz nijak nepomohli proti centosu.
No a to se přesně děje.. Red Hat udržuje několik různých verzí.
https://gitlab.com/redhat/centos-stream/rpms/kernel/-/branches
No a to se přesně děje.. Red Hat udržuje několik různých verzí.
https://gitlab.com/redhat/centos-stream/rpms/kernel/-/branches
Ono se stačí jen podívat na oficiální stránku CentOS Streamu, kde velkým svítí ke stažení dvě verze - 8 a 9. Pěkně to ilustruje, s jakou informovaností o tématu někteří do diskusí chodí. O to zapáleněji ale pak diskutují. :)
FUD tu siris leda ty a ostatni obhajovaci RH a neni to jen FUD, jsou to vylozene lzi.
v8 neni stream. Je to pozustatek minulosti, prejmenovany, predatovany ale porad pozustatek. Potom co vznikl velky rev s ukoncenim 8cky centosu ze? Pristi rok to konci.
https://www.centos.org/centos-stream/#centos-stream-8
End-of-life May 31st, 2024
Takze laskave neblabol.
17. 7. 2023, 21:40 editováno autorem komentáře
Svoji neznalost opravdu nenahradíte agresivitou.
CentOS 8 měl ukončenou podporu 31.12.2021.
CentOS Stream 8 není přejmenovaný starý CentOS, ale nově vzniklá distribuce předsazená před RHEL 8, je dál podporovaný a EOL bude v květnu 2024, tedy 5 let po vydání RHEL 8 přesně v souladu s oznámenou délkou podpory. Není to žádný dojezd starého CentOSu.
Vy tady tvrdíte, že CentOS Stream je jeden velký rolling release napříč velkými verzemi a bude se automaticky přepínat z 8 na 9 atd., což se, kulantně řečeno, neshoduje s realitou.
Vzhledem k tomu, že RHEL vychází cca každé tři roky a podpora CentOS Streamu je pět let, budou vedle sebe fungovat paralelně dvě verze po většinu času. Po konci osmičky se velmi brzy objeví desítka atd. A až vyjde desítka, tak uživatelé na devítce ji budou moct i nadále používat, nepřejdou automaticky na aktualizace z desítky stejně jako nyní můžou uživatelé dál používat osmičku, i když už je rok k dispozici devítka.
Taky nechápu to vaše zdůvodnění, že bychom si jinak nijak nepomohli oproti starému CentOSu. Tohle přece nikdy nebylo o nějaké redukci streamů. Vždyť my ty patche pro RHEL musíme dělat tak jako tak a pro mnohem větší počet streamů. Momentálně jich máme podporovaných myslím 9 a v budoucnu budeme mít až 16.
Podpora Centos 8 ale měla být mnohem delší. RedHat to sliboval a pak se na ten slib vykašlal (Vím, že existuje článek, který se v diskuzích na toto téma linkuje. Je to snůška výmluv. V moci RedHatu bylo ten slib dodržet, ale neudělali to). Stejně tak tvrdili, že ta změna centosu nic neznamená, že zdrojáky budou i nadále dostupné. Další nesplněný slib.
Takhle se důvěryhodná firma nechová.
Což je ale prostě furt rolling. Provozoval jsem dva roky Stream-8, teď někde Stream-9. Svoje osobní desktopy, pár virtuálů a starý server na pokusy (i na testování nových balíčků a toho, co přijde do RHEL, což je vlastně asi i ten primární účel).
Sice se vám to systém automaticky neaktualizuje na vyšší major verzi, ale za dobu aktivního vývoje té distribuce, tzn. plánovaných prvních 5 let od vydání, je tam fakt poměrně hodně práce, změn a různých backportů. Hlavně v jádře, některých knihovnách kolem, třeba u libvirt/QEMU atp. a logicky se dost hýbou i ty čistě Red Hatí věci jako Cockpit.
Někde tohle vadit nemusí, jinde ano a může vám to přidělat spousty starostí, samozřejmě záleží na konkrétním použití.
Víceméně minimum problémů je to v případě těch virtuálů a čistě open source aplikací. Problematičtější to pak je v případě 3rd party modulů do jádra (síťovky - Mellanox a spol, některé SAS/RAID controllery, proprietární ovladače pro grafiky a přidružené knihovny, zvukovky.. filesystémy s externími moduly do jádra jako Paragon, různé nativní klienty pro distribuované filesystémy). Ve všech zmíněných případech jsem něco řešil.
Pro tyhle situace se prostě hodí to klasické verzování - např. RHEL 7.8 ~ CentOS 7.8, SLES 15 SP 3 ~ OpenSUSE Leap 15.3. A pokud to výrobci/programátoři nebudou vydávat nové verze otestované vůči nějakému konkrétnímu datu nebo číslu commitu ve Streamu, o čemž silně pochybuju, nepůjde to bez laborování.
Jak do tohoto spadne verzování Almy je samozřejmě otázka, třeba tenhle aspekt vůbec nemají tendenci řešit a koncentrují se primárně na virtuály a cloud (jakože hlavní firma za Almou je CloudLinux, jestli se nepletu).
17. 7. 2023, 15:30 editováno autorem komentáře
Vím o tomhle a chápu, ty změny jsou tam nakonec taky, nezávisle na tom, že je to vydávání rozčleněno na nějaké minor verze.
Ještě jeden aspekt je ten, že RHEL, nebo starý CentOS/klon :) mají daleko lepší dostupnost starších balíčku v repozitářích oproti Streamu.
Ne, že bych si v tom liboval a je to samozřejmě třeba otestovat, ale někdy je prostě nutné oželet určité aktualizace a stvořit Frankensteina, abyste měl třeba poslední distribuční balíčky na Sambu a nějaké knihovny, kvůli CVEčku nebo bugfixu, ale zachoval funkčnost se starším jádrem, protože některé moduly proti novějšímu nejdou nainstalovat/sestavit.
U Streamu je prvotně potřeba dohledat korespondující verzi balíčku s jádrem, co odpovídá minor verzi RHEL, kterou specifikoval vendor modulu a chodí (např. pro RHEL 9.1 - jádro 5.14.0-162..). Pokud už to na konkrétním stroji nainstalováno, tak fajn a podržíte to nějakými excludy. V opačném případě, když zaváháte, nebo máte třeba čerstvou instalaci, tak jste bez vlastních záloh/snapshotu starších verzí repozitáře docela namydlený. S rychlostí vydávání balíčku Streamu je okno 5 verzí v repozitáři tak na 2 měsíce zpátky a o žádném veřejném archivu nevím.
Jinak já tohle vše nepíšu jako nějaký obecný hejt na Stream, naopak. Beru to, jak to je a myslím, že pro mnoho použití je fajn (nejen jako předjezdec RHEL :) . Jen jsem chtěl zmínit situace, kdy to, podle mých zkušeností, může drhnout.
U Almy jsem zvědav, jakou strategii vydávání a verzování zvolí.
Což je přesně ten aspekt, na který jsem zvědav.
Stream 8 má oficiální konec 31.5.2024
https://blog.centos.org/2023/04/end-dates-are-coming-for-centos-stream-8-and-centos-linux-7/
Není mi úplně jasné, jestli to znamená jen konec buildování binárek, nebo přepnutí Gitlab repozitáře Streamu-8 do read-only. V druhém případě by následná podpora na 5 let (bezpečnostní patche na všech balíčcích) byla kompletně na vývojářích Almy, jestliže budou downstream distribucí.
Možná se ještě někde objeví upřesnění.
Docela by me zajimalo jak budou resit podporu, az pristi rok v dubnu RedHat ukonci vydavani updatu pro Centos Stream 8. Najmou tym vyvojaru a budou dublovat praci RedHatu? To asi tezko, takze bud doufaji, ze se to do te doby "nejak" vyresi a nebo budou nekde v sede zone GPL ziskavat aktualizace z RedHatu. No a potom je jeste moznost, ze je to podle vzoru: slibem nezarmoutis ;-)
p.s. Prechod z Rocky 8 na Stream 8 je bez problemu a za soucasne situace vazne nevidim zadny duvod proc nepouzit Stream. Proste budu delat "dnf update --security" a jednou za cas udelam regulerni update celeho OS.