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