Zachovejte klid. Článek je trošinku zavádějící, pokusím se to vysvětlit.
Za prvé, nové funkce se přidávají do RHELu už léta. Platí pravidlo, že pokud nějaká novinka nerozbije stávající funkčnost, může se do RHELu přidat a děje se tak poměrně často (např. v 8.1 to byl eBPF). Některé kanály (například optional nebo desktop) dokonce podléhají tzv. "rebase" - nová verze programu (např. chrony, tuned v 8.1, nástroj pcp v 8.3 atd). Dokonce se některá funkčnost může odebrat, pakliže se jedná o Tech Preview (brtfs). Podle mého názoru je "zatímco RHEL v desetinkových verzích opravuje jen bezpečnostní a kritické technické chyby" nepřesné tvrzení stejně jako "Budou v něm tedy průběžně přibývat funkce a mohou se i měnit verze komponent" (tučně). Už se tak děje léta. Ano, většina věcí jsou opravy chyb ale nová funkcionalita se přidává, a to i do linuxového jádra. Pokud však dojde k jakékoli regresi, je to bug a musí se to opravit. A tohle se prosím v CentOS Stream nemění.
Za druhé, není to tak, že by se z CentOS Streamu stala Fedora. Ve článku je sice poznamenáno že CentOS Stream bude někde mezi Fedorou a RHELem, ale pak je uvedeno že se jedná o "testovací platforma". To je zavádějící, CentOS Stream bude daleko blíže RHELu a hodně vzdálen Fedoře. V odkazovaných materiálech je doslova napsáno že CentOS Stream "nebude BETA testovací" platformou RHELu. Jedná se spíše o upravu workflow, toho jak vývojáři pracují, než že by to výrazně pocítil uživatel. Když se opraví chyba, nejprve to bude provedeno v CentOS Stream, a teprve pak to zamíří do RHELu. Ale to neznamená, že se CentOS Stream "rozkope" do stavu kdy bude nepoužitelný. Chyby a vlastnosti, které jsou předmětem prací, jsou velmi pečlivě zvažovány a vybírány, a to se nemění.
A za třetí, ve článku není uvedena důležitá poznámka z Red Hat blogu (*): firma v první polovině příštího roku nabídne nový program předplatného (levněji nebo zdarma) pro open-source projekty a komunity. To by mohl být velmi zajímavý program vzhledem k tomu že doba podpory RHELu vždy byla a je delší než u CentOSu který dodržoval jen základní pětiletý cyklus: https://access.redhat.com/support/policy/updates/errata
Proto radím, nepanikařte, počkejte a vyzkoušejte si to. CentOS byla, je a bude kvalitní distribuce nejen pro server a nemyslím si že by tomu mělo být jinak.
(*) https://www.redhat.com/en/blog/centos-stream-building-innovative-future-enterprise-linux
Stále ale podle mě platí, že CentOS ztratí hlavní výhodu - kompatibilitu s RHEL. Ano, jasně, když vyvýjím pro RHEL, mám testovat na RHELu, ale nějak se zapomíná na komunitu okolo CentOS. Častokrát jsem spíše našel "How to do X in CentOS" než "How to do X in RHEL".
K tomu, že CentOS Stream nemá být Betou RHELu. Co tedy je když je před nejbližším patchem RHELu a pak je z něj RHEL? CentOS Stream se podlě mě stal tím, čemu se dlouhá léta šklebili posměváčci u Fedory :/ Uvidíme, jak se to vyvine...
Kompatibilita s RHELem se nijak neztrácí, alespoň pokud je myšlena binární kompatibilita.
> Častokrát jsem spíše našel "How to do X in CentOS" než "How to do X in RHEL".
Ano, protože obrovské množství obsahu je za "paywallem" access.redhat.com. Dá se tam ale dostat zřízením vývojářského účtu, který je (už dnes) zcela zdarma.
Ale no tak, vážně myslíte že nasrat komunitu je dobrej nápad? Chápu že lidi z RHELu budou tvrdit něco jiného než z těch zpráv vyplívá. Neb koho chleba jíš toho píseň zpívej.
Nás čekal přechod z centos 7/Rhel7 na osmičkové verze, Po těchto šílenostech se nejspíš začne řešit přechod na suse. Centos u nás slouží jako QA/UAT prostředí a na produkci která není kritycká. Jinak je na prod RHEL.. Tahle šílenost prostě dřív nebo později tohle celé rozkopne.
Takže to co se z toho IBM snaží vytřískat ( víc peněz z subscription), bude spíš kontra produktivní.
RHEL 8 jako první v historii obsahuje podporovaný upgrade (7->8), jsou tam omezení, ale žádná jiná verze to neměla zdokumentované a otestované. Dost dobře nechápu, co se snažíte říct. Každý major upgrade je bolestivý, co si budeme nalhávat, spíš bych doporučil reinstalaci a naplánování deploymentů tak, aby se maximáně využila dlouhá doba podpory.
Ano, pracuju pro Red Hat, ale to neznamená že moje názory nejsou objektivní. Kde přesně se dopouštím nějakých nepřesností? Já osobně vnímám změnu modelu k lepšímu protože většina mých CentOS serverů jsou testovací nebo nekritické instance, ale chápu že někomu může lépe vyhovovat starý model kdy CentOS vychází dlouhou dobu po RHELu, tím může být vnímán jako stabilnější.
K tomu "nasrat komunitu" asi není co říct, každá změna někoho asi "nasere". Jen jsem pár věcí upřesnil, každý ať si z toho vybere co chce.
Tak to že pracuješ pro Red Hat jsi měl dát hned do prvního příspěvku.
Tímhle krokem prostě IBM/Red Hat nasral spoustu lidí a jde proti původní myšlence CentOS. A hlavně, hlavní motivace toho kroku jsou peníze pro vlastníka RHEL.
Je to ukázková strategie "embrace, extend, and extinguish", kterou linuxový uživatelé přisuzovali hlavně Microsoftu, aby s ní nakonec přišel sám Red Hat.
Je třeba se smířit s tím, že si tímhle Red Hat pokazil jméno a již nebude tak cool někde vykřikovat že pro něj pracuješ.
FactChecker: To je blbost (ačkoliv to tak může vypadat). Kdyby šlo (jen) o vytřískání peněz, tak to mohli udělat už dávno a nečekat takovou dobu. Jde o změnu modelu z jiných důvodů, viz to co tu psal lzap, ačkoliv jinak úplně souhlasím s tím, že bohužel to komunita opravdu jako hezké gesto vnímat nebude :-/. Možná to jen chtělo lepší komunikaci směrem ke komunitě plus dotáhnout podporu CentOSu 8 až do konce, paralelně s RHEL 8.
"zatímco RHEL v desetinkových verzích opravuje jen bezpečnostní a kritické technické chyby"
Tímto jsou, myslím, myšleny opravy v rámci desetinkových verzí, tedy v z-streamu a tam se opravdu opravují jen zásadní a bezpečnostní chyby. Funkce se nepřidávají, verze se nemění. V rámci desetinkové verze tak má zákazník velmi stabilní a předvídatelný systém.
Mezi desetinkovými verzemi můžou být větší změny, přidávání nových funkcí, rebasy celých komponent.
CentOS má AFAIK Y-stream (změny mezi desetinkovými verzemi) a Z-stream spojený do jednoho aktualizačního streamu, takže jak vyjde nová desetinková verze RHELu a CentOS ty změny převezme, dostanou je uživatelé CentOSu automaticky v aktualizacích, takže ten velmi stabilní a předvídatelný systém mají jen po dobu mezi desetinkovými verzemi (6-9 měsíců), zatímco zákazníci jej můžou mít i několik let (desetinkové verze jsou podporované paralelně), nicméně v CentOS Streamu jim tam ty změny můžou přistávat kdykoliv, ne v těchto cyklech, což si myslím, že může být dokonce výhoda na desktopu (rychlejší přístup k novým ovladačům), ale chápu, že admini kritických serverů jsou při té představě nervózní.
Souhlasím, že je asi brzo dělat nějaké závěry. "Rolling release" hodně lidí vyděsí, protože si pod ním představí věcí jako Rawhide, ale CentOS Stream bude hodně testovaný a s malou deltou oproti stabilními RHELu. Navíc CentOS už je svým způsobem rolling release teď tím spojením Y a Z streamu, jen ty změny byly dávkované.
> desetinkových
Ano, máš pravdu že fakticky to má Petr napsané správně, ale já bych si dovolil to rozvést protože to není tak černobílé:
U RHELu se lze pro určité verze přihlásit ke streamu kde dojde ke "zmrazení", například je to 8.2. Mělo to různá marketingová jména a dneska se to tuším jmenuje EUS a SAP updates, ale technicky jde o to, že už mi půjdou delší dobu 8.2.z updaty takže bude celkově méně upgradů po dobu živostnosti serveru, což se hodí na drahé deploymenty kde upgrade něco stojí.
Toto CentOS nikdy neměl, bylo by to pro komunitu moc pracné. Takže ačkoli je tvrzení fakticky správně, uživatel CentOS se daných rebasů dočkal vždy (pakliže nevypnul updaty).
> CentOS má AFAIK Y-stream
Aha tak tady to přesně popisuješ. Jo, tohle jsem chtěl říct.
> "Rolling release" hodně lidí vyděsí
Souhlasím že tohle je marketingově trošku nezvládnuté. Pod tím pojmem si mnoho lidí představí Gentoo nebo Arch. A to je prosím naprosto jiná káva, živě si pamatuju rozbitý produkční emailový server na Gentoo který jsem po drobném upgrade opravoval týden. :-)
Možná tady lidi uklidňujete, ale ten způsob, jakým to bylo vyhlášeno v https://centos.org/distro-faq/ je jeden velký prostředníček ukázaný směrem k uživatelům, vývojářům i dobrovolníkům, cituji:
Q8: I need to build/test my packages for EPEL locally which I used CentOS for. CentOS Stream will have different ABI/API at times so my builds won’t work with that.
A: EPEL is part of the Fedora Project. We know they are looking into the cases where this happens and are working on a solution. Initial testing showed that only a few packages are affected. We encourage you to get involved there. The CentOS Project cannot and does not speak for Fedora: We encourage you to engage with the EPEL community instead.
(Přeloženo z korporátštiny: Je nám to jedno...)
Q9. EPEL 8 needs access to packages which are not shipped by RHEL but were made available by CentOS. How is this going to be solved?
A: EPEL is part of the Fedora Project. We know they are looking into the cases where this happens and are working on a solution. Initial testing showed that only a few packages are affected. We encourage you to get involved there.The CentOS Project cannot and does not speak for Fedora: you should instead engage with the EPEL community.
(Přeloženo z korporátštiny: Fakt je nám to jedno...)
Q12: I used CentOS for CI because I could not use RHEL developer licenses for this. CentOS Stream is aimed at the next generation when I need the last/current one. What is my alternative?
A: Red Hat is aware of these concerns and we encourage you to talk to them. If you’re testing for RHEL, RHEL is the best operating system to use. We also think that CentOS Stream has a place in your CI testing to help you be ready for the next RHEL.
(Přeloženo z korporátštiny: Kupte si RHEL...)
Q14: Can the CentOS community continue to develop/rebuild CentOS linux?
A: We will not be putting hardware, resources, or asking for volunteers to work towards that effort, nor will we allow the CentOS brand to be used for such a project, as we feel that it dilutes what we are trying to do with the refocus on CentOS Stream. That said, the code is open source and we wouldn’t try to stop anyone from choosing to use it or build their own packages from the code.
(Přeloženo z korporátštiny: Víš, co Sašo...)
Možná to nebude tak horké, jak to vypadá, ale ten způsob, jaký to bylo ohlášeno má teplotu zemského jádra.
kadence aktualizací skončí freezem repa, takže se tím zvedne okno před opravou CVE. Jak to bude vypadat v praxi se uvidí, z prvotních informací spíše přemýšlím o přechodu než riskování jak se bude Stream chovat při aktualizacích.
Red Hat nasedl očividně na vlnu SaaS a poskytovat SW na on-premise není už jeho gró.
Pokud to dobře chápu, tak bezpečnostní chyby budou opravovány v normálním režimu, pokud není embargo. A drtivá většina CVE jsou normálně zveřejněné, nejedná se o tak závažné problémy (ale přesto by měly být trackovány a opraveny). Tudíž si troufám tvrdit, že tím že vývojáři Red Hatu dají opravy nejdřív do CentOSu a pak do RHELu se tím okno naopak průměrně zkrátí.
Stream lze zkoušet už dnes, byl představen před nedávnem: https://www.centos.org/centos-stream/ ale uvidíme jak budou nastaveny ty procesy.
Já bych to rozhodně tak horké neviděl. Ano, CentOS Stream bude obsahovat nějaké změny a nebudou jenom jednou za půl roku nebo rok. A to je tak asi celý rozdíl.
CentOS Stream bude obsahovat změny o něco dřív. Red Hat si je nebude schovávat pod pokličkou půl roku, ale budou uvolněny, jakmile na nich proběhne testování a vypadají ok. Ano, výjimečně bude možné, že se mezitím najde chyba, která se opraví dřív, než přistane v RHELu. Prakticky takových chyb má být minimum a cílem je zlepšit existující testování, aby nastávaly minimálně. Jedním z cílů je umožnit komunitě i zlepšení testování.
Jinak na CI se pořád dá Steam použít úplně v pohodě. Pokud to máte pro vlastní produkty, můžete být díky tomu připravení na nový RHEL, ještě, než vyjde. Navíc můžete jako komunita ne jenom kafrat, ale taky přispět do budoucího obrazu RHEL. Až to Red Hat vydá, je na diskuzi obvykle pozdě.
A EPEL prostě není RHEL. To znamená, že buď to má být v RHELu, nebo EPELu. To, že to není v RHEL ale je to v CentOS je speciální případ. Které se mají vyřešit systémově a přesunout buď do jednoho nebo do druhého. Určitě to neznamená polibte si šoš.
RHEL má jenom minimum balíků, které mění API. Neprovozuji to v produkci, ale mělo by vcelku jednoduše aktualizovat jenom security updaty, bez obyčejných bugfixů. Ano, jsou vyjímky, jednou je třeba bind9, kde ABI kompatibilita není garantována. Není jich moc.
Teplotu jádra mají často komentáře, které ne úplně správně chápou, jak to vlastně má být. Uznávám, ti, kdo chtěli přesnou kopii enterprise linuxu zdarma se cítí podvedeni. Vzhledem k tomu, že nenabízeli ani zpětnou vazbu ani peníze, asi se dají oželet.
> Jinak na CI se pořád dá Steam použít úplně v pohodě.
Jsou tam jisté aspekty, které je třeba vyřešit. Například SELinux a kompilace balíků s politikami, což je problém který bude několik projektů muset řešit včetně toho našeho. Ale nic s čím bychom si neporadili.
> RHEL má jenom minimum balíků, které mění API. Neprovozuji to v produkci, ale mělo by vcelku jednoduše aktualizovat jenom security updaty, bez obyčejných bugfixů.
Nesouhlasím s "celkem jednoduše", CentOS erraty nezveřejňuje jako yum metadata. Ale s nějakým extra úsilím to jde.
> Teplotu jádra mají často komentáře...
Ondra má pravdu. Já bych to zbytečně nerozdmýchával, jakkoli můžeme chápat určité souvislosti a dobrý úmysl které nejsou veřejné, celkový obraz té zprávy, blogpostu a FAQ dokumentu je aktuálně špatný. Lze jen doufat, že to zodpovědní lidé upřesní a doplní další informace.