RHEL je dostupný všem, nikoliv jen platícím, protože developerské licence jsou zdarma. Včera jsem to redakci psal...
Lze jít i přímo na adresu https://access.redhat.com/downloads/content/479/ver=/rhel---10/10.0/x86_64/product-software
15. 5. 2025, 10:45 editováno autorem komentáře
32bitová verze už neexistuje delší dobu, předchozí verze RHEL9 byla dokonce jen pro novější 64bitovou architekturu x86-64-v2. Škoda těch nepřesností.
RHEL nejde na 32bitovou architekturu nainstalovat už od RHEL 7, tedy 11 let, ale pořád byl k dispozici userspace zkompilovaný pro 32bitovou architekturu, což se právě s RHEL 10 mění, protože už není k dispozici ani ten.
A RHEL10 je len pre x86-64-v3.
Alma10 bude ponukat aj x86-64-v2 build, ale s upozornenim, ze aplikacie tretich stran (vratane EPEL) mozu vyzadovat x86-64-v3.
Existuje nejaka killer app (pro bezne uzivatele), ktera by jela dobre s/na RHEL ?
(nebo je to vse mireno na konzervativni korporatni sluzby?)
Treba BMD Resolve to neni, ti chteji CentOS / Rocky Linux ... (se divim ze necili i na Ubuntu, coz je spis jedno z vice user friendly voleb)
Resolve DaVinci mi celkovo pride taky divny: uz roky maju problem v dependencies, ktore pribaluju [1], ignoruju wayland[2] alebo H.264 len s Nvidiou (na inych systemoch toto obmedzenie nemaju).
Ubuntu neriesia asi preto, ze cielovka isla smerom IRIX -> RH -> CentOS -> Alma/Rocky.
[1] pouzivaju qt, ktore vyzaduje pango, ktory vyzaduje glib... qt a glib maju pribaleny, pango nie. Pango v novsich verziach importuje z glib symboly, ktore v bundlovanom glib nie su, takze resolve potichucky ani nenastartuje.
[2] co chce pracu naviac, kedze pouzivaju qt, ktory wayland podporuje
Jo, spousty věcí by šlo pořešit líp. Ta závislost na NVDEC a NVENC pro kodeky, chybějící AAC atp.
Podle mě je to pořád trochu záležitost toho, že ta linuxová verze byla vcelku minoritní a primárně určená na turnkey systémy, které se zkonfigurují (systém, hardware) přesně podle jejich požadavků a používá se placená varianta (Studio).
Ty knihovny to šlo určitě řešit i preloady (nemám to teď úplně po ruce, určitě jsem to takhle někomu rozběhl), ale jinak mi na SUSE většinou funguje jen smazat nebo přesunout ty bundlované..
Po aktualizaci spustím vždy jen svůj skript - fix-resolve.sh
#!/bin/bash cd /opt/resolve/libs for i in libglib-2.0.so* libgio-2.0.so* libgmodule-2.0.so* libgobject-2.0.so*; do mv -v "${i}" "${i}.bak" done
Nemyslim, ze u RHEL jde o killer app.
Ale pro nase zakazniky (ruzne velikosti, korporaty ale i mensi financni instituce) je to proste "razitko" na produkcnich serverech. Zaplatis 100k Kc na 3 roky (2-socket) a mas podporu (kterou stejne nikdy nevyuzijes), ale pro management, security atd. mas licencovany serverovy OS na x86 platforme za rozumnej peniz (oproti Windows). A u toho RHELu mas proste nejakou kontinuitu a ne jako s CentOS (vim, ze je to taky Red Hat, resp. IBM).
Na testy samo davas Alma/Rocky (po zmene u CentOS) a ses vysmatej, za malo penez spoustu skvele muziky.
To je právě ono, CentOS není a nikdy nebyl Red Hat nebo IBM.
CentOS byl (a nepřestal být) komunitní a Red Hat ho jen začal sponzorovat, jinak by už dávno úplně skončil. Lidi to bohužel tak nějak pochopili, že je to vlastně oficiální Red Hat distribuce zdarma a změna financování a směřování je pak naštvala.
Stejně jako Fedora není Red Hat. RH zaměstnává dost lidí, platí dost infrastruktury, ale FESCo je na RH poměrně dost nezávislé.
Lidi nenaštvala ani tak změna směřování jako spíš EOL CentOS 8 po 2 letech, oznámený rok po vydání. V některých nasazeních z toho bylo pěkné mrzení a tuny práce navíc, čemuž se dalo předejít tím, že by CentOS 8 vůbec nevyšel.
Což je ta změna směřování. CentOS Stream 8 fungoval až do loňska (= cca 5 let). CentOS není a nebyl enterprise distribuce s garancemi no.
Jako mně je to jasný (osobně ani od klonů nečekám garance, dokud si je neplatím), ale vydání a EOL po dvou letech část lidí považovala za podtržení koberce a asi se jim úplně divit nejde. Tohle byla fakt PR katastrofa.
Tak je to konzervativní standard se stabilním a definovaným API. Plus má obecně sane-defaults v nastavení a dobře konfigurovaný SELinux. Běžný uživatel asi spíš ocení Fedoru, co je též spolehlivá, ale má novější balíky (za cenu toho, že pak není stabilní) a nemusí se konfigurovat EPEL pro běžné balíky + ELRepo, pokud člověk koupí železo, co nemá podporu backportovanou do RH kernelu.
Osobně dělám vědecké výpočty a RHEL je fajn v tom, že je to stabilní platforma a definovaný standard, takže člověk nemusí řešit systém a pokud něco sestavuje, odkáže se na příslušnou verzi RHELu, kde to jelo. Fajn i pro kontejnery. Byť teda nejedu RHEL jako takový, ale ve formě klonu, konkrétně AlmaLinux. Většinou bývá snazší i troubleshooting, neb je dobrá šance, že s tím někdo na dané verzi RHELu už pracoval, u častěji aktualizovaných dister to někdy bývá větší ezoterie.
Jinak pokud se bavíme o RHEL vs. klony, pak výhoda RHELu oproti klonům je certifikace, dlouhá podpora desetinkových verzí a fakt, že pokud člověk chce něco 100% kompatibilního s RHELem, musí brát RHEL. Takže super na věci, co se fakt nesmí, nesmí rozdrbat. Na moje use-casy ale stačí API kompatibilita, co poskytují klony, případně CentOS Stream.
Běžný uživatel asi spíš ocení Fedoru, co je též spolehlivá, ale má novější balíky (za cenu toho, že pak není stabilní)
Mně Fedora přišla vždycky dost stabilní (Rawhide samozřejmě nepočítám, ale tam by kdovíjakou stabilitu snad nikdo soudný nečekal).
Spolehlivost =/= stabilita
Fedora je spolehlivý systém, ale balíkům se v rámci jedné verze Fedory může změnit major verze. Rovněž i verze jádra se mění. Tedy samotný systém není stabilní z pohledu balíků. RHEL (ale i třeba Debian) projde nějakým freezem, kdy po celý život dané major verze zůstávají balíky ve verzi, ve které byly v momentě vydání a portují se jen bezpečnostní aktualizace (+ backporty podpory HW). I proto je nákladné udržovat LTS distro - prakticky je nutné velkou část balíků forknout v dané verzi a udržovat nezávisle. Plus držet verzi kernelu a do ní backportovat podporu pro nový HW.
Paradoxně LTS distro může být méně spolehlivé, než klasické, ale vždycky bude stabilnější.
S vynimkou firefoxu a jadra, nie som si vedomy, ze by sa vo fedore menili major verzie balikov. To sa nechava do dalsieho release, s cim vo vseobecnosti nie je problem, kedze dalsi release je max. 6 mesiacov daleko.
Na rozdiel od RHEL alebo Debianu, jeden release je podporovany cca rok, nie ~10 ako RHEL alebo ~5 rokov ako Debian alebo Ubuntu LTS. Ani Ubuntu nebackportuje novy HW do stareho jadra; pre novy HW maju HWE jadra.
Ubuntu LTS je dokonca svojim sposobom tak trocha skodlive; ISV neriesia nove featury v novych distribuciach (wayland, pipewire, apod), ale ked to funguje na starych verziach v Ubuntu LTS, tak prehlasme, ze podporujeme Linux. A potom mame rozlicne Webexy, ktore dodnes nevedia zdielat obrazovku, lebo pipewire je prilis cutting edge.
Ve Fedoře se mění verze komponent v rámci jednoho vydání celkem často. Nevím, jak teď, ale dřív se třeba rebasovaly celé KDE, protože délka upstreamové podpory by nepokryla délku vydání Fedory. Já ve Fedoře spravuji několik desktopových aplikací a pokud nová verze není nějak radikálně jiná, jde sestavit a nejsou s ní problémy, tak ji dávám i do nejnovější stabilní Fedory. Kdyby to byla nějaká knihovna, na které závisí ostatní, tak to samozřejmě nedělám. Zatímco v RHELu to je jasně definované, ve Fedoře jsou nějaká základní pravidla, ale pak je to na úsudku balíčkáře a domluvě v komunitě.
Popravdě na tom nevidím nic špatného. Myslím si, že doba tuze zmrazených repozitářů ve stylu Debian Stable je pryč. Doba je dynamičtější, uživatelé chtějí mít novější software rychleji, distribuce jim v tom jdou naproti. Samozřejmě je pořád potřeba nějaká úroveň stability a kontinuity v rámci jednoho vydání. Naštěstí dnes ten software leze z upstreamu díky CI a automatickému testování v lepším stavu než před lety, takže ta potřeba všechno zmrazit a testovat a testovat už není taková.
No, to u RHELu platí jen v minor verzích, v rámci jedné velké se rebasuje docela často. My jsme třeba dřív rebasovali celé GNOME a to dokonce několikrát v rámci jednoho releasu. RHEL má balíky rozdělené do několika skupin podle garantované kompatibility. U těch základních komponent se rebasy vůbec nedělají, protože udržet tam veškeré garance kompatibility by bylo prakticky nemožné. No a pak jsou komponenty jako Firefox, kde naopak není prakticky možné zůstat na stejné verzi.
Samozřejmě i u těch rebasů se hodně řeší kontinuita, kompatibilita apod. V tomto je Fedora mnohem živelnější.
To je asi otázka, jak si kdo vykládá pojem "stabilita" bez nějakého dalšího přívlastku. Mě jako první napadne, to, že systém a aplikace na něm běží bez pádů, nutných restartů a podobně. Ale pokud jsou tím myšleny verze balíčků, pak samozřejmě Fedora tak stabilní není :-).
Tak už si od včerejška hraju doma s novou verzí :)
Byť tedy jen ve virtuálu a bez GUI, zkouším nějaké systémové i své balíčky, koukám co se změnilo a tak.
Bude to chtít ještě docela zkoušet, protože např. základní verze systémového OpenJDK je 21 (majoritně mi zatím většina věcí běží s 11), Python je 3.12 atp.
Také samozřejmě uvidíme, jaké balíčky pro RHEL 10 a v jakém časovém horizontu budou případně od proprietárních aplikací (MS, IBM, NVIDIA..).
Co jsem také zaznamenal, tak zmizely modulární balíčky (dnf module..) od RH, podobně jako to už před dvěma lety skončilo ve Fedoře. Respektive dnf to samozřejmě pořád podporuje a pořád to používají třetí strany (např. NVIDIA).
Mě to osobně přišlo docela fajn, třeba pro elegantní přehazování verzí Postgresu, PHP atp., ale beru, že s tím byla pro maintainery práce navíc. Uvidíme, jak pak budou fungovat aktualizace major verzí těch aplikací v normálním AppStreamu.
A asi se taky, doufám, časem objeví další informace o životním cyklu balíčku na webu RedHatu (aktuálně je to takový trochu "tichý" release, většina stránek ještě končí u RHEL9).
Vypadá to pro mě zatím jako vcelku příjemná evoluce.
Možná využiju i toho, že tu máme insidery - díky, pánové