A jen bych doplnil, že se zdá, že Alma dostala rozum ohledně vlastního vývoje. Tato následující část je totiž přesně to, co z nich udělá normální distribuci:
"The most remarkable potential impact of the change is that we will no longer be held to the line of “bug-for-bug compatibility” with Red Hat, and that means that we can now accept bug fixes outside of Red Hat’s release cycle. While that means some AlmaLinux OS users may encounter bugs that are not in Red Hat, we may also accept patches for bugs that have not yet been accepted upstream, or shipped downstream."
Toto z nich udělá konkurenci CentOS Streamu a to je DOBRÁ věc.
Jsem rád, že se takto rozhodli a jestli to i dodrží, tak s nimi budu rád spolupracovat osobně i ze strany RH.
Upřímně na držák JARů nebo LAMP je to opravdu docela jedno a klidně bych používal třeba stávající Stream, nebo cokoli jiného.
Kde to, pro určitá použití začně kulhat, je kompatibilita s uzavřenými aplikacemi a 3rd-party ovladači HW a moduly do jádra. Ale to už jsem psal.
Pro mnoho uživatelů i těch komerčních vendorů stačilo, že to na klonech korespondující verze s RHEL chodilo, i když to samozřejmě podle vaší striktní, a formálně správné, definice nebylo 1:1. Pak už bylo víceméně na zákazníkovi, jestli chtěl, nebo nechtěl oficiální podporu pro OS.
Teď, přestože bude existovat X distribucí odvozených ze stejného zdroje, tak jakmile se rozjede verzování těch releasů a budou tam vzájemné nekompatibility, tak tahle věc samozřejmě padá.
U mnoha těch komerčních aplikací, které jsou multiplatformní, je to teď tak, že podporují Windows, jednu distribuci Linuxu (typ. RHEL/CentOS) a možná macOS v určitých případech. Nějaké širší testování a případně víc buildů těch aplikací pro různé distribuce se, podle mě, nedá úplně očekávat - zvlášť jestli se to ještě dál fragmentuje. Můj odhad je ten, že zákazníci teď začnou tlačit na dodavatele, aby tou podporovanou, a jejich primární vývojovou distribucí bylo Ubuntu. Někde už je to vidět a za poslední řekněme 2-3 roky se to tímhle způsobem posouvá.
Jinak ještě k Almě, jejich komparativní výhoda vůči čistému Streamu, by teoreticky mohla být podpora po pátém roce od vydání.. Ale vzhledem k tomu, že třeba Centos 8 stream prakticky končí příští květen, tak úplně netuším, jak by toho chtěli dosáhnout..
"We will continue to aim to produce an enterprise-grade, long-term distribution of Linux that is aligned and ABI compatible with RHEL"
Bohuzel tenhle pristup neni kompatibilni s korporatnim prostredim.
Existuji i dalsi firmy, ktere parazituji na RHEL a ty se zabivaji "bezpecnosti".
Maji lidi kteri prochazi errata RHEL RPM baliku na strankach RedHat, a udrzuji vazbu mezi verzi baliku a CVE. Jejich nastroj pak reportuje security problemy pokud nemate spravnou verzi RPM baliku.
Pokud se ta cisla verzi rozejdou anebo stejne cislo verze bude znamenat neco jineho tak budou mit tyhle security firmy problem a do korporatu takovou distribuci nedostanete.
PS: Kupodivu AIX mel pro neco takovyho reseni uz pred 25ti lety. Kazdy opatchovany balik obsahoval i seznam bugu, ktere resi.
Tak zrovna u tech baliku vim exaktni verzi, a tedy i to jake ev. patche tam proti upstreamu jsou. To zas tak obskurdni metoda z pohledu security assessmentu neni (narozdil od tech, co deravost software posuzuji vylucne podle hlavicek, ktere nekde vyskrabnou; a nejlepsi jsou borci, co pak zacnou na zaklade tech divnonastroju psat, ze tam mate nejakou zarucenou diru :D).
Jo to ma a celkem se da na to spolehnout, ale ten changelog je porad vice-mene textovy soubor. AIX ma databazi baliku a v te jsou i tabulky pro seznam bugu a seznam patchu. Takze pokud chcete vedet jestli v systemu mate balik, ktery obsahuje fix pro "CVE-1234", tak proste spustite prikaz kteremu zadate to CVE-1234 jako parametr.
Informce v RH errata jsou značně neúplné s ohledem na kompletní změny konkrétní aktualizace. Např. RHSA-2023:3837 systemd erratum zmiňuje CVE a bugfix.
Když se pak podíváte na to, co se změnilo, zjistíte, že je toho o dost víc.