Vlákno názorů k článku
Oracle k dění kolem RHEL: vývojáři mohou přejít k nám od MarSik - SUSE už se také ozvalo s dalším forkem...

Rolling distro znamena predevsim to, ze se cokoliv muze zmenit hned, jak je to dostupne - a samozrejme to nejde nijak dopredu predikovat, kdy to bude a ani co to rozbije - zatimco tradicni model je o tom, ze mate nejaky uceleny release jednou za cas, ktery muzete jako celek taky otestovat a nepodstupovat tuhle cinnost fakt pred kazdym update. To prvnim na produkcnim systemu uplne clovek proste nechce - a ano, kdyz to nechce delat RedHat, nabizi se dalsi klony, bez ohledu na to jak moc ten trn picha Redhat do oka ;-) Ono duvod jejich existence je zjevny, stejne jako neduvera uzivatelu v pojeti Streamu... a ocividne si to v RedHatu uvedomuji, kdyz je tak zere existence tech klonu, co zachovavaji ten model, ktery RedHat sam pohrbil.

Každý update, který se objeví v CentOS Stream, prochází interním testováním jako update pro RHEL (protože to je pro RHEL). Jediný rozdíl je v tom, že ho dostanete dřív. Pokud by se v update objevila chyba, je možné že ji dostanete a že dostanete i opravu.[1] Jenže pokud máte RHEL a objeví se chyba, tak s ní budete žít minimálně do další desetinné verze.

[1] Nikdo vám nebrání dělat jen bezpečnostní aktualizace a větší update CentOS Stream provést až po vydání další desetinné verze RHEL:

dnf update --security

Pokud chcete vývoji pomoct, nahlásíte problém do Bugzilly pro CentOS Stream a výsledek i záhy uvidíte (protože po interním testování se k aktualizaci normálně dostanete). Tak to pokládám za správné a tak to i dělám.

Jako obhajoba Streamu pekny, ale bezte to rict lidem, co sahaji radeji po alternativach typu Alma, Rocky ci te od Oraclu ;-) Ja uz spoustu let radeji saham po Debianu a vlastne uz pred temi mnoha lety, kdy jeste frcelo Potato a rodil se Woody to byla prave politika RedHatu, co me primela ke zmene preferenci. A deni kolem RH v poslednich tydnech me jen utvrdilo v tom, jak skvele jsem se rozhodl ;-)

"Jediný rozdíl je v tom, že ho dostanete dřív"

Coz, jak tu potvrdili i zamestnanci RH neni pravda.

Pravda to není jen u embargovaných CVE. Tam to totiž nejde. U žádného distra.

Tak to jste psal jinde, ze to vase reseni je vlastne tak trosku nestastne... kdy u RHELu hrozi, ze se publikace opravy realne muze spise zpozdit. Coz rozhodne neni smyslem onoho embarga, ze? ;-) To je spise znamka nevhodne nastaveneho procesu.

To jste jen špatně pochopil a asi jsem to trošku nešťastně napsal. CVE opravy se do RHELu dostanou hned po embargu, o chvíli dříve než do streamu.

Ostatní patche jdou nejdříve do streamu a je možné, že těsně minou okno pro RHEL minor release.

No napsal jste to tak blbe, ze to jinak interpretovat ani neslo :-) Ano, znelo to nelogicky - ale do firemnich procesu vam nevidim.

To je ovsem spis pravidlo nez vyjimka. Jeste porad mam u jednoho zakaznika uz pomerne letitou instanci zalohovace, ktery bezi na tuxovi (je to centos), a vylozene je tam receno, ze se system jako takovy nesmi vubec patchovat, jinak dodavatel neruci za funkcnost. A stalo to sedmimistnou cifru (ten SW).

Maji v tom mimo jine nejak samorobo opatchovany kernel.

Jj. takových systémů taky pár znám - většinou nějaké jednoúčelové servery "appliance" dodané na klíč. RHEL nebo starší CentOS, přesně jak píšete - typicky bez updatů mimo akualizací s hlavním programem (který s sebou občas nese zabalíčkovaný třeba novější kernel nebo třeba glibc), jakákoliv jiná změna zakázána, resp. nepodporována.
Občas je to fakt peklo, ty custom kernely bývají často problematické a samozřejmě bezpečnost, byť i v segmentované síti. Nedávno jsem zkoušel řešit video servery s CentOSem 5.5 - lahůdka. Deprecated šifry všude, SMB 2/3 zapomeň :) Udělal jsem na to aspoň své balíčky se statickým dropbearem, OpenSSL a poslední Sambou 3. Hnout s tím nejde, jsou tam proprietární karty a všechen sw a ovladače jen jako binárky.
Tomuhle se bohužel člověk úplně nevyhne, zvlášť když zabrousí do servisu oborů, kde to není jen čisté IT, ty celé systémy jsou relativně komplexní a použitý operační systém na jednom ze serveru je prostě jen jeden, ne úplně prioritní, faktor při výběru toho celého systému. Jsou tam různé jiné faktory, které mají často vyšší váhu při výběru.

Ale to peklo, co jsem teď popisoval, je fakt spíš výjimkou. Právě s tím vyšším rozšířením CentOSu se to subjektivně zlepšilo. Dá se to udělat i docela dobře - třeba jeden dodavatel měl vyloženě svůj spravovaný mirror systémových CentOS repozitářů s aktualizacemi plus samostatné repozitáře pro svůj sw, proprietární ovladače a firmwarové updaty (které jsou třeba dostupné jen pro OEM partnery). Bylo to přístupné jen přes SSH tunel, každý zákazník měl vygenerovaný privátní klíč, takže měli zároveň centrální kontrolu nad autorizací a přístupem do těch repozitářů.

Jeden takovy system prodavany za tezke penize delaji shodou okolnosti taky v Brne... asi osm kilometru od sidla RedHatu :-) A dotahli to k takove dokonalosti, ze update baliky jsou distribuovane stylem "tady je jednou za cas jedno velky tgz, tam je vse co jsme uznali za vhodne teda laskave aktualizovat".

Jeden takovy zabetonovany system s proprietarnimi kartami ridil tranzitni plynovod. Lahudka kupovat uz na Sunem nepodporovane zelezo HW srot na ebayi aby to vubec jelo. Pak shaneli nejakeho dobraka kdo by jim udelal reverzni engineering reseni vc tech karet.
Jisty mnohem mensi pruser tohoto typu na rizeni provozu tramvaji ma na hrbu velky dopravni podnik jisteho mesta. Doufam ze na ten pruser prisli pri posledni cistce.

Na tom je nejhorsi ze nemuzete hnat k zodpovednosti manazera ktery to vybiral. Protoze pro jiste obory je ta vec jenom "part number". A mate dve reseni z nichz jedno updaty neresi vubec a druhe jen premaznutim celeho systemu.
Manazer to vidi asi jako : Funguje? Bude tedy fungovat i 30 let. Pro nej optikou jeho oboru na tom nic spatne neni. Jsou obory prumyslu ktere jsou na hony vzdalene od best practices ktere mame v IT.
Uvidime jestli s tim nezamava (H)NIS smernice - jako ze si myslim ze spis ne.

;D ... proto mam doma krabici a v te krabici je hromadka HW, treba ruzne karty do ISA, ruzne ramky, ... proste takovy krabicovy muzeum, ze kteryho cas od casu neco vytahnu a nekomu tim vytrhnu poradny trn z paty. Asi bych z toho umel poskladat i nekolik kompletnich PC z ruznych udobi dejin ...

A cas od casu do te krabice neco doplnim. Nedavno jsem ziskal dve kompletni a fukcni sestavy s pentiem 3.

Co mi pak pamet slouzi, asi tak nejstarsi PC ktere je stale v provozu je 486, ktera ridi pomoci nekolika zakazkovych karet vyrobni linku. Dotycny ITk ma podobnou krabici jako ja, jen ve firemnim skladu. A v ni ma nekolik kompletnich 486, protoze jinak by museli leda *kompletne vymenit tu linku = nejaka ta stovka Mio.

*Oni ve skutecnosti resili i nejakou predelavku na neco novejsiho, jenze to by je vyslo vlastne jeste draz, protoze by to znamenalo, ze by nekdo musel zreverzovat jak co funguje, vyrobit prislusnej HW, napojit ho na nejakej soudobej system, a napsat prislusnej SW, pricemz ta linka by kvuliva ladeni a testovani minimalne nekolik mesicu stala.

A ted si predstavte, ze spoustu veci kolem nas neridi v tomto smeru relativne moderni 486tka, ale stale logika poskladana jeste z relatek... :-) A ano, nahradit to je taky o ne uplne malych investicich.

Transporta :-))) Nebo nektere covky ke kterym neni dokumentace.

To je jeste v pohode protoze je to relativne standartni PC. Narozdil od tech Sunu kde karty byly jeste na SBusu.

Chapu ze u emulace by asi haproval presny timing na tech ISA/EISA sbernicich. Nepredpokladam ze je to predpentiova 486 s PCI.

Neco takoveho mi vypravel otec kde linka delala nejake kaucukove vyrobky. Hadice, tesneni nebo pneu ci co to bylo za prisery. Vyroba tesne po revoluci. Na nove CNC se podarilo ukecat. Na novou linku na ty vyrobky uz ne a beha to dodnes. Puvodni ridici system byla prumyslova jednodeskova 486 s vyvedenou isa sbernici.

Az budes ten SW vymenovat, tak pudes opet do rhelu? ... chmm

Chápu, asi bude záležet na konkrétní aplikaci, jestli to poběží a možná by se to dalo vylaborovat - ale samozřejmě i kdyby to běželo na Streamu, tak prostě může rozhodnout dodavatel té aplikace, když řekne, že od toho dá ruce pryč - byť by to bylo třeba řešení nějakého problému, co nesouvisí s operačním systémem.

Jinak aby to nebylo blbě pochopeno, já osobně to nemám tak, že bych byl en bloc proti všem placeným licencím na linuxové OS, nebo Red Hatu (Fedora, CentOS/Rocky teď, RHEL jsou pořád moje preferované distribuce a nikdy jsem nezpochybňoval velký vklad RH do mnoha OSS produktů).
Jsou projekty a použití, kdy mi ty oficiální předplatné dávají smysl, nebo si to vynutí dodavatelé, příp. nějaké certifikace.
Stejně jako jsem už předtím tady někdy zmiňoval hybrid, kdy máte třeba hlavní servery a stanice na RHEL, ale nějaké pomocné virtuály nebo výpočetní nody už třeba na klonech. S tou výhodou, že pokud pokud jsou tam korespondující verze, tak můžete sdílet testování, sestavování vlastních balíčků, nebo třeba nějaké playbooky. Ale při použití RHEL+CentOS Stream se to takhle jednoduše říct nedá, plus samozřejmě ta kompatibilita hw ovladačů a komerčního sw se Streamem.

Jistě by mohl někdo namítnout, že by se teď tedy všude měly koupit předplatné na RHEL, ale to se obávám, že pro spoustu projektů tenhle nárůst provozních nákladů jednoduše nebude průchozí.. a jsou situace, kdy je to hodně nevýhodné (velké množství fyz. serverů), zvlášť pokud jsou to třeba nějaké izolované segmenty, kdy se v podstatě zřídkakdy aktualizuje systém.

V pripade nekterych neaktualizovanych komponent jako dodavatel posilame i velke zakazniky s tim ze X bylo vyreseno dle changelogu uz pred 5ti lety at jdou k sipku a updatnou si. Ty nejvetsi pochopitelne ne. Tam se delaji i custom patche treba do kernelu/drive­ru,appek aby to nejak jelo. Ale to jsou jine financni dimenze. Coz samozrejme zabetonuje system s nejakymi restrikcemi na podporu aby na tom firma neprodelala troje gate.
Bezny zakos jiz neni poslan k sipku ale vylozene do haje s tim at si updatne system, komponentu a laskave otravuje az po tom. Nas HW vendor a vyrobce s nami taky nejedna v rukavickach.

Takze uzavrene systemy odsud podsud. Ony ty uzavrene segmenty maji treba sporadicke chyby ktere se spatne debuguji a chcipne to treba jen 2x do roka(treba kvuli presunu casu, leap second nebo chybejici tzdata zmene). A reste si toto jen pres emaily ktere musi mezitim nekdo schvalovat. A to prosim neresim zelene trenyrky.

Lenze to bola chyba Streamu a nie EPEL-u.

Stream rozbil poppler, nie EPEL. Ten v EPEL-e nie je, tam sa to prejavilo, pretoze gdal z EPEL-u bol zlinkovany voci povodnemu soname poppleru.

Z Chodova, na Solarisu... nebylo to v Ceske pojistovne?? ;-)

Pro ten dum hruzy jsem nikdy nepracoval. A kdokoliv z mych kolegu ma instrukce zmlatit mne tlustym kabelem pokud by mne to kdy napadlo.
Na druhou stranu jsem pracoval pro jiny dum hruzy...

Nebudte slusnej, reknete jmeno :)

(ja se priznam - delal jsem kdysi pro jednu odnoz CD, ted je to tedy jakoby samostatna a jakoby IT firma. No, zkusenosti zajimavy, nedaji se skoro popsat normalnimu cloveku)

Sun Microsystems byl moji silenou vzpominkou na poppler.
Jinak co se tyce domu hruzy byl to Wincor-Nixdorf( mozna tehdy siemens-nixdorf) . Tady jsem jako mlade ucho ztratil veskere iluze. Ale rika se ze prvni prace je vzdy mizerna.

Muze byt. Ale uz od dob, kdy jste pohrbili "klasicky" CentOS 8 driv nez 7 jste prokazali, ze je lepsi neverit :-) A o tom, ze to "rolling" se tyka jen major verzi neni v te (ehm, vasi) wiki ani carka, ze? ;-) Neucte me znat, jak to obcas chodi... si to v rozporu s vasim dnesnim tvrzenim zmenite a lidi odbudete tim, ze prece v dokumentaci to meli napsane...

"Je to rolling release v rámci major verze."

Vazne? A to tvrdi kdo? RH rozhodne ne. A v minule a predminule diskusi tu i zamestnanci potvrdili, ze to presne takto neni. Objevi se tam totiz klidne i nova major verze, s tim, ze bude (po dalsim patchovani) v dalsi verzi Rhelu.

V další X.y minor verzi RHELu X. Ten CentOS stream je totiž verzovaný jestli jste si nevšiml. CentOS Stream 8 a CentOS Stream 9 jsou oddělené.

Tak si to rozebereme: RHEL má major verze - 7, 8, 9... ty jsou vydávané cca 3 roky od sebe. Pak každá z nich má minor verze 9.1, 9.2... které vycházejí cca co půl roku. Tyhle malé verze přinášejí nejen nové vlastnosti (backportované ovladače do kernelu, nové balíčky...), ale klidně i upgrady komponent. Jak už jsem tu jednou psal, v RHEL 7 jsme několikrát upgradovali celé GNOME. Pokud chcete pouze opravy, musíte se držet konkrétní minor verze, což zákazníci můžou, protože v rámci EUS minor verze podporujeme několik let, i když jsou venku další.

CentOS ale tyhle EUS streamy nikdy neměl. Pokud se tedy objevila v RHELu nová minor verze s hromadou nových věcí včetně nového GNOME, CentOS to rebuildoval a nasypal vám to do běžných updatů. Akorát vám dal v erratě warning, že to je změna, která může něco rozbít. Pro uživatele CentOSu nebyla možnost držet se konkrétní minor verze a dostávat jen opravy. Pokud budeme brát rolling release jako něco, co přináší nové vlastnosti včetně zcela nových verzí komponent (protože těch definicí rolling releasu je víc), tak CentOS toto určitě splňoval, jen ty změny přicházely dávkově podle toho, jak vycházely minor verze RHELu.

A mimochodem. poppler má kompatibility level 4 - nic negarantujeme.

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html-single/package_manifest/index

8.4 bola este daleko:

* RHEL 8.3 vysiel 2020-10-29,
* oznamenie, ze CentOS 8 je mrtvy a CentOS Stream je novy kral vyslo 2020-12-08. V ten isty den bol oznameny CentOS 8.3,
* tento problem nastal zaciatkom januara 2021,
* RHEL 8.4 vysiel 2021-05-18.

EPEL este nemal byt preco pripraveny na 8.4; zacal sa riesit EPEL-next.

Minor verzie mal, len fungovali trocha inac ako v RHEL. Starsie minor verzie neboli udrziavane, ale vydanie novej minor verzie malo release notes s breaking changes.

Máme někde dokumentaci pro tyhle "specifické situace"?

Ta debata je sama o sobe abstraktni (vc. argumentace panu z RH, kteri to pouzivaji jako soucast sveho hejtu na klony), takze vas odkazu na abstraktni clanek ve wikipedii :-)

Ta debata je o tom, co po vás požadují klienti. Pokud požadují RHEL, tak jim vágní slib bug to bug kompatibility ve vašem podání zpětné kompatibility stačit nebude.

Taky si všimněte, že Alma vůbec o bug-to-bug kompatibilitě nemluví. Slibují přímo "binární kompatibilitu". Tj až na úroveň linkeru.

Co když mají zákazníci skript, který čte /etc/redhat-release?

Může být Alma vůbec sama v souladu s GPL, když slibuje binární kompatibilitu a přitom RH má od GPL explicitně povolené ochranné známky:

You may supplement the terms... e) Declining to grant rights under trademark law for use of some trade names, trademarks, or service marks;

Podle mě nemohou splnit oba sliby zároveň. A to je jen jeden z příkladů celého problému klonů.

Pokud se dobre divam, tak to je jen symlink na almalinux-release... a jestli mate v RH pocit, ze pojmenovanim nejakeho souboru se porusuje nejaky vas trademark, proc jste to uz davno nedali k soudu? ;-) Ono ten odstavec v GPL rika, ze tim trademarkem nesmite pojmenovat produkt - a to Alma jaksi splnuje. Ono se to jmenuje Alma Linux, ze? :-) To je stejne, jako s jinymi forky... treba MariaDB versus MySQL... atd, ze...? Takovych forku najdete mraky, kdy se produkt prejmenuje, ale nazvy souboru zustanou... ;-)

Jde o obsah toho souboru. Protože binární kompatibilita.

A zákon o ochranných známkách toho říká mnohem víc. CentOS odstraňoval všechny zmínky o Red Hatu.

Mimochodem, taková BSD je tady ještě tvrdší než GPL:

The name of the <copyright holder> may not be used to endorse or promote products derived from this software without specific prior written permission.

Apache to samé, i když trošku mírněji:

6. Trademarks. This License does not grant permission to use the trade names, trademarks, service marks, or product names of the Licensor, except as required for reasonable and customary use in describing the origin of the Work and reproducing the content of the NOTICE file.

Tak znovu, kdyz je to tak jak se tu snazite tvrdit, proc uz to davno neresi soud? ;-) Pokud by byl vas trademark zneuzit jak tvrdite, tak ten spor je prece uz davno vyhrany, ne? Zrovna tohle jsou veci, co maji rozhodovat opravdu soudy a ne internetove diskuze.