SUSE už se také ozvalo s dalším forkem (a vlastní nadací) RHELu.
https://www.suse.com/news/SUSE-Preserves-Choice-in-Enterprise-Linux/
Jen teda jejich slíbené financování 10 milionů $$$ během několika let je dost možná tak na zaplacení 20 lidí bez techniky.
Pořád akorát nechápu, co jim vadí na CentOS Stream. Co už chápu je, že o něm nikdo nemluví, protože by to výrazně změnilo dopad podobných PR zpráv.
A co presne na tom nechapete? Rolling distribuce se fakt nehodi vsude - i kdyz ocividne v RH maji nekteri borci pocit, ze neni problem to nacpat asi kamkoliv :-) Zatimco ocividne v Oracle i SUSE to holt chapou, ze to neni uplne nejstastnejsi napad, tvarit se e Stream vsechno spasi...
11. 7. 2023, 15:00 editováno autorem komentáře
Rolling s tím nemá nic společného. CentOS byl totiž rolling taky a nikdo s tím neměl zásadní problém. Možná to nebylo úplně vidět, ale CentOS oficiálně nepodporoval starší minor verze:
http://web.archive.org/web/20190928084313/https://wiki.centos.org/Download
"The CentOS project does not offer any of the various approaches to extended life for an earlier point release which its upstream occasionally does for its subscribing clientèle. Once a new point release is issued (say: 6.3, following 6.2), no further source packages (from which updates can be built) are released for the earlier version and therefore CentOS is no longer able to produce security or other updates."
To samé tady:
Vždy jste tudíž byl jen na posledním release + updaty. Takže to možný byl pomalý rolling, ale stejně rolling.
Snapshot repozitáře si můžete udělat a otestovat sám. Kdykoliv. Stejně jako to dělal ten CentOS.
Co nechápeme jsou vyjádření těch firem, jak budou open source, tvořit komunitu a všichni pracovat na společném díle a přitom ignorují CentOS Stream, který přesně kvůli tomuto vznikl.
Nicméně komunita kolem Red Hat projektů se do konkurenčních PR zpráv nehodí no.
Ehm, centos samozrejme roling nikdy nebyl. Pro povyseni verze bylo nutne udelat upgrade, stejne jako u rhelu/debianu/...
Centos stream roling je, proto ho nikdo nechce pouzivat.
U roling dister se zadny upgrade nedela, protoze proste baliky padaji na nove verze prubezne.
Stream vzniknul vyhradne proto, ze RH chtel zariznout centos, kterej se pouzival jako free verze rhelu.
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 ;-)
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.
Jako ano, technicky máte samozřejmě pravdu s původním CentOSem - pokud jste třeba automaticky spouštěl automatické aktualizace, tak vám to samo poskočilo mezi minor verzemi distribuce.
Ale samozřejmě to kopírovalo ten release cyklus minor verzí RHEL, a vždycky tam šel první nový balíček centos-release, což byl v podstatě takový bumper. To už si mužete ohlídat (buď ručně nebo třeba nějakým regexem při synchronizaci do svého lokálního repozitáře pro aktualizace). Jinak se samozřejmě dají přidat, nebo natvrdo upravit repo soubory a nahradit $releasever konkrétní desetinovou verzí v url a pak udělat nějaké koordinované updaty, kdy ručně povolujete repozitáře.
Jinak ještě obecně, protože to tu myslím v těch předchozích debatách úplně nezaznělo. Jeden z nejsilnějších důvodů, proč používat RHEL anebo klony je, že to je/byl pro komerční vendory - TEN Linux :) Týká se to binárních ovladačů, out of tree kernel modulů, klientů pro sdílené filesystémy (StorNext, IBM GPFS). Totéž pak některé databáze, software pro 2D/3D grafiku, specifické serverové aplikace atp.
Ve většině případů je konkrétní software nebo driver kit testován a uvolněn pro specifickou verzi RHEL - třeba 8.6 (a třeba ještě SLES s konkrétními service packy od SUSE). V posledních letech byl u některých vendoru brán CentOS i oficiálně jako plnohodnotná alternativa k RHEL "stejné" verze.
Jestli pak nějaký uzavřený software nebo ovladače chodí i na jiných minor verzích distribuce je samozřejmě jiná otázka - někdy ano, někdy ne. Někdy to je úplně v pohodě. Jindy ne a může tam být něco banálního natvrdo zadrátované do build skriptu, co se volá z DKMS nebo když se kompiluje kmod, a dá se to třeba s trochou vůle opravit než vendor vydá další verzi. Jindy to vyloženě naráží na backportované změny v novějších jádrech RHEL (třeba kód out-of-tree modulu volá nějaké deprecated funkce, co se v novější verzi vyhodí) a neobejde se to bez zásahu do kódu toho modulu.
Finálně jde i o to, že občas potřebujete třeba nahlásit vendorovi nějakou chybu té aplikace, hardware - jste si téměř na 100 % jistý, že nesouvisí s operačním systémem. Logicky jdete přes L1 support, první co musíte dodat je nějaký výstup z gather toolu, který zataruje nahromadu všechny možné logy. Pán/paní na druhé straně jede podle check-listu, v těch logách zaregistruje nepodporovanou verzi OS a nepustí to dál :) finálně se můžete točit týdny v kruhu i když třeba reportujete problém, co se třeba objevil na SAS backplane.
Takže ano, samozřejmě pokud někdo používá pouze opensource aplikace (nevím virtuály s nginx nebo Postgresem), má to třeba nadoma nebo pro vývoj - CentOS stream je fajn. Sám jsem měl doma dva roky Stream-8 a teď Stream-9. S občasnými bugy v balíčcích si poradím, nahlásím :) Ale není to odpověď na všechno ("Stream je vlastně to, co byl starý CentOS") - a teď nemyslím jen to, že RHEL s plným předplatným má support, na který se můžete obrátit. Také někdy nejsou úplně prioritní ani co nejrychlejší aktualizace, jede to v nějaké segmentované síti a musíte zařídit, aby spolu všechny komponenty systému a verze software šlapaly.
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.
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.
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/driveru,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.
Jakozto primarne uzivatel a spravce Gentoo naopak velmi dobre chapu, co komu vadi na rolujicim distru. Kazdych par tydnu se ti prakticky zmeni vsechny verze uplne vseho, a nejde zdaleka jen o nejake security patche, meni se primarni verze (treba verze pythonu, at sme konkretni). Coz typicky znamena, ze musis zmenit a nebo minimalne prekompilovat i vse, co s tim jakkoli souvisi.
A je dost mozny, ze ti neco prestane fungovat. Specielne pokud v tom systemu mas nejakou aplikaci dodavanou treti stranou, non GPL, bez zdrojaku, coz je typickej pripad lidi, kteri pouzivaji rhel/centos/... takze chteji, aby ten system byl co nejdele binarne kompatabilni.
Ony se ty systemy totiz typicky neprovozuji proto aby se provozoval system.
Jenomže Centos si na domácí počítač nikdo neinstaloval. Končilo to ve firmách a hlavně proto, protože dodavatel nějakého řešení uvedl, že to na tom poběží.
Z patra mě napadá třeba Abra. Účetní program v menších firmách. Přidali podporu Ubuntu Server.
HCL Domino/Notes. Dřív podporovali i Centos, teď už jen RHEL. Po skončení podpory Centos zákazník nekoupil RHEL, koupil Windows Server.
Kdyby měl RH i nějaký cenově dostupný produkt, tak mi to je jedno, ale RHEL prostě u našich zákazníků prodat nedokážu. To jsou proti Windows Serveru násobně vyšší ceny.
Ale Stream nema problem rozbit ABI, lebo f-you, that's why.
Toto zasiahlo aj mna: https://old.reddit.com/r/CentOS/comments/kq6agw/geospatial_workloads_broken_epel/
Povodcom tohto problemu nebol EPEL, ale poppler. V normalnom CentOSe alebo v RHEL by update poppleru cakal minimalne do dalsieho minor release, v Streame bol vypusteny medzi ludi. Rozbilo to aplikacie, v RH sa tvaria, ze ved sa nic nedeje.
A **presne preto** Stream nie je vhodny.
Jenže tohle není chyba Streamu. To je chyba EPELu a klidně mohla nastat i na RHELu. EPEL není oficiálně podporovaný Red Hatem. A navíc ne všechny balíky v RHELu mají garantované všechno: https://access.redhat.com/articles/rhel9-abi-compatibility#Scope
A jak říkám, nemusíte aktualizovat všechno okamžitě. Ty balíky mají changelog. Zákazníci to dělají i na RHELu.
A kde ma uzivatel jistotu, ze se za tyden v RedHatu nevyspite jinak a nerozhodnete, ze to stylem Gentoo pojmete? ;-) Oznaceni rolling distribuce pouzivate sami. Jste technik, vyjadrujte se presne. Ten termin ma svuj vyznam - tak bud jej v RedHatu pouzivate nespravne, nebo uzivatelum ted nechcete rikat celou pravdu ;-)
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...
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.
Imo to RedHat Streamu dost zavařil tím že to původně jako Rolling prezentoval, protože si pod tím všichni představili spíš něco jako Fedoru Rawhide, než normální Centos s trochu čerstvějšími balíky. Já kvůli tomu se změnou soukromého serveru na Stream taky dost váhala, a až asi měsíc zpátky jsem si všimla jak to funguje, když jsem se divila proč mám nějaké balíky starší než poslední RHEL.
API a ABI je v rámci jedné major verze RHEL/CentOS stabilní pro běžné knihovny, core knihovny dokonce po tři major verze. Výjimky u ABI jsou jen na bezpečnostní incidenty, když to jinak nejde. Jádro je v tomto trochu specifické, grafické prostředí na kompatibilitu nedbá. Více viz: https://access.redhat.com/articles/rhel-abi-compatibility
CentOS Stream obsahuje balíčky, které míří do RHEL, takže API/ABI je zajištěno (resp. porušení by bylo podstatnou chybou).
Ovšem klony RHEL nikdy neměly stejné build prostředí jako RHEL, dělají se self-hosting (kompilují samy sebe), takže tam mohou být (i průběžné) odlišnosti. Navíc neudržují desetinné verze, takže...
Nikdo vám nebrání instalovat pouze security aktualizace, pokud se chcete držet minimálních změn:
dnf update --security
To nie je pravda, vyssie linkujem pripad, ked update poppleru rozbilo ABI:
> RHEL plans to rebase poppler from 0.66.0 to 20.11.0 in 8.4. This change has already shown up in CS8. This involves a soname bump, so EPEL packages that link against it (a total of three including gdal) need to be rebuilt to link against the new soname.
V RHEL to cakalo na 8.4, v Streame to bolo vypustene ako bezny update.
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.
Ano, ale Poppler taky není na seznamu komponent s garantovanou ABI kompatibilitou. RHEL fakt není během svého života zmrzlá distribuce jako Debian. Naopak prvních 5 let se do něj dostává dost nových vlastností a změn. Vždyť my jsme v RHEL 7 několikrát rebasovali celé GNOME.
Mimochodem ve starém CentOSu tyhle změny taky přicházely jako běžné updaty, protože žádné minor verze neměl.
Správcuju servery s Gentoo cca 1/4 století.
Hlavní výhodu v Gentoo vidím v možnosti si řadu věcí optimalizovat podle potřeby, a zároveň, proti takovému Linux from scratch, věnovat nadstandardní pozornost tomu, co si chci/potřebuji ladit.
Dnes, kdy už jsou distribuce vyladěné a vyprofilované o dost lépe než bývaly, a výkon HW se posunul kosmickou rychlostí dál, už tyhle výhody Gentoo nejsou tak zásadní. Takže někde už jedu hodně i Ubuntu server, občas Debian, někdy sáhnu i po exotice typu Tiny Core Linux.
Upřímně, tenhle krok SUSE jsem taky moc nepochopil, ale třeba mě to někdo vysvětlí.
SUSE teď bude překompilovávat a distribuovat balíky získané z hlavního produktu od největšího konkurenta..?
Nezdá se mi, že by se z toho dalo získat moc nových zákazníků na placený SLES.
Ekvivalent původního CentOSu od SUSE by, podle mě, bylo něco jako OpenSUSE Long Leap se stejně dlouhou dobou aktualizací jako SLES (s LTSS). Ale tím by logicky přímo konkurovali svým komerční poduktům.
Jakože třeba spojí síly s Almou, Rockym a budou teď všichni společně dolovat v těch RHEL OCI kontejnerech ;)
To sice asi jo, ale z té jejich tiskové zprávy mi to nějak přímo nevyplývá, že by přímo SUSE mělo poskytovat placenou podporu na fork "cizího" systému, kde nemají žádný vlastní vývoj a z principu nemůžou nic změnit. Samozřejmě to můžou řešit nějak přes CIQ, ale ten už má Rocky a tohle prostě má být jen další bug-for-bug klon (možná s jiným logem - třeba chameleonem v klobouku :)), jestli jsem to dobře pochopil.
Proč nevzali 10mio a neposlali to do Rocky foundation.. k čemu bude třetí "fork" po Rocky a Almě? Nebo jen všichni tři založí další společnou foundation jen pro dolování z těch kontejnerů... a anonymní zakládání RHEL účtů na žádosti o zdrojáky :)
Navíc podle mě dává smysl i ten argument RH, že tím, že je to jednosměrný - bug for bug rebuild, tak se samozřejmě nedá jednoduše přispívat zpátky a z principu tam cokoliv měnit.
Proto jsem zmiňoval to, že kdyby udělalo OpenSUSE "long leap", tak bych řekl - klobouk dolů pánové, tohle je alternativa. Plus by to podle mě přineslo i další uživatele SLES s podporou, kteří by místo přechodu z RHEL+CentOS an RHEL+Centos Stream přešli třeba na SLES+OpenSuse "Long Leap".
Jinak, co psal pán bez přezdívky - že to v podstatě udělali jen jako renonc Red Hatu, a přisypali písek do stoje, se mi nějak moc nezdá..
Ale uvidíme :)
V principu to samozejme menit muzou. Ono pod na prvni pohled nepeknym oznacenim bug compatible se ve skutecnosti skryva neco, cemu se drive mene hanlive rikalo zpetna kompabilita. A ta opravdu neimplikuje, ze musite zamrznout az tak, ze nezmenite nikde nic. Pouze je treba zachovat chovani v urcitych specifickych situacich - a to se da osetrit ruzne. Ale to fakt neznamena, ze tam nemuzete nic nikdy zmenit nebo opravit... tohoto strasaka zamerne vypousti spise lidi z RedHatu, aby vytvorili dojem sve nepostradatelnosti ci co ;-)
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.
Bozinku ... jim je jedno co tim ziskaji, pro ne je vyhodny, kdyz tim RH poskodi, a to se zcela jiste povede. A RH si za to muze sam. Tohle je defakto marketing zcela zadarmo. Protoze dat verejne ke stazeni par GB dat nestoji zhola nic, coz v RH nejak prestali chapat. Takze jim to naschval udelaji ostatni. A dobre jim tak.
Pricemz pokud budu ja resit nejaky akce na tema placeny support, je pro me v tento okamzik RH naprosto nogo zona. Na forever, tohle uz u me nevyzehlej. Takze budu pripadne hledat jinde, a ten cim bude nekdo transparanetnesi, tim ma v mych ocich vetsi sance. Proc? Protoze ja osobne vzdy premejslim nad tim, komu to predam, az me vytocej. Takze hratky na tema tohle nesmis, tamto nesmis, tuto je neverejny a tajny ... = nezajem. Tohel je totiz naprosto jednoznacna indikace toho, ze dodavatel je podvodnik, slibujici huj a dodavajici hnuj.
Problém je v absurdní vlně emocionální nenávisti vůči RH, která se nezakládá na logice, ale na totálním nepochopení (či neochotou pochopit). A též absolutním popírání konceptu koexistence a výhodné symbióze opensource a na něm založených komerčních projektů jako je RHEL (kdy vydělávající reinvestuje do opensource).
Pokud bude většina chtít loupit (tj. vydělávat na klonech aniž by přispěli k vývoji RHEL), tak to povede k tomu, že masivní finanční podpora opensource půjde k šípku. Tím myslím to, jak RH/RHEL přispěl k přesunu Linuxu do enterprise podoby, protože jeho tým za ty vybrané peníze RHEL skutečně buduje. Změní se to na stav, kdy všichni budou chtít vydělávat jen na tom, co už někdo udělal, což jistě chápete, že je slepá ulička.
Pokud nechcete rozumět tomu, že CentOS Stream není horší než RHEL, resp. že CentOS Stream je více RHEL než jakýkoliv klon, pak nezbývá než vás nechat být a doufat, že nenaděláte příliš škody.
RH nemá nejmenší důvod prohlašovat CentOS Stream za kompatibilní s RHEL, protože je to nesmyslný požadavek. Asi jako prohlášení, že zmrzlina vyrobená blíž k Opočnu chutná víc jako zmrzlina z Opočna (mluvím o značce zmrzliny). CentOS Stream code becomes the next minor release of Red Hat Enterprise Linux. Co chcete víc vědět?
Psal jsem to kousek jinde, nikdo nikomu nebrání v tom, aby instaloval pouze bezpečnostní aktualizace a větší update provedl až po vydání desetinné verze RHEL:
dnf update --security
ok, tedy na zacatek trochu odbocim do osobni roviny. Kdysi, je to snad 30 let, co tady v CZ nejaky Kersleger vykonal prukopnickou praci a zasadnim zpusobem se pricinil o rizsireni linuxu. Za to mu patri dik cele komunity.
Jestlize se tedy nejedna o nejakou shodu jmen, tak musim rici, ze jsem minimalne prekvapen, ze na zaklade Vasich zkusenosti patrne nechapete, ze problem je nekde uplne jinde.
I rada dalsich diskuteru se zde zaobira vecmi jako jsou desetinne a jine verze, kdy se co updatuje nebi upgraduje, a kdy se aplikuji u toho ci jineho uzivatele nejake patche.
Myslite si skutecne , ze se vice jak 5% zainterosovanych o podobne veci zajima? Neni tomu tak.
Jedine co na tech klonech zajima je ta jedina skutecnost - jakasi binarni kompatibilita s nejakym mainstream produktem. Jestli tato binarni kompatibilita vubec existuje je uplne vedlejsi - proboha lidi vzpamatujte se - ta hra na tu kompatibilitu je vubec ten duvod, proc ty klony existuji a proc je RHEL tak rozsiren.
Jeste jednou - nejde o nejake technicke detaily - jde o trzni politiku - zrovna tak, jako zadneho managera jeste nevyhodili, protoze rozhodl koupit SAP a nebo nejakou silene predrazenou Oracle-databazi. Jestli byl nekdy CentOS nejak kompatibilni a kdy vlastne nebyl a kdy CentOS Stream vlastne je, je absolutne nezajimave. Dulezite je to razitko.
Coz vzhledem k historickym udalostem bude primo heroicky vykon :) Ale nekdy fakt plati, ze kdyz se dva perou (v tomto pripade RH versus Rocky/Alma), treti se smeje...
Ne, tohle neustale opakovane straseni stylem ze bez penez RH by nebylo opensource ci jak se to cele bez nich zhrouti je vazne komicky. A misty to zavani strasenim, ktere zkousi nahnedli politici.... nikdo nechce upirat RH zasluhy, ale tenhle jejich kult nenahraditelnosti je tak trosku tragikomicky.
O nenahraditelnosti jsem nikde nic nepsal. Jde o významný přínos, který je využíván (pochopitelně, o tom žádná), ovšem bezostyšně očerňován (nelogicky) právě těmi, kteří z něj těží a nepřipouštějí si, že by měli také vracet alespoň minimum (místo toho vášnivě plivou na toho, kdo jim dává úplně všechno na stříbrném podnose). A to nemluvím o tom, že zatímco RHEL poskytuje k dispozici vše (pomocí čehož se klon dá vytvořit), zatímco ti co se RH vozí, buď nic takového nedělají, případně na tom klonu jedou svůj byznys a nechtějí (u)dělat ani to malé prd.
To, co mi na tom opravdu vadí, je tlačení názoru (nikoliv faktického), že klon je něco víc (než CentOS Stream), případně že je více identický s RHEL. Jistě – přiznání opaku by jejich byznys model poněkud zdestruovalo. Ovšem pokud na téhle ideologické vlně jedou setrvale i pisálci, pak je to na pováženou (protože fakta tady už několikrát zazněla a stejně si jedou svoji RH-fóbní litanii). A opakuji – klidně si tomu věřte, ale nechte si tu nesmyslnou ideologickou nálepkovací nenávist někam jinam.
12. 7. 2023, 00:51 editováno autorem komentáře
A ted jen prebirate argumentaci z RehHatu - ale ten jejich blabol o tom, ze by clenove alternativnich projektu nic nevraceli byl take vyvracen. Ono to s tim ocernovanim taky az tak jednoznacny neni... resp. i RedHat ma v tomto smeru maslo na hlave :-) Ten spor zazehli oni a ta argumentace, kterou pouzivaj ferova uplne taky neni.
Ty projekty, kvuli kterym to zaclo jsou komunitne rizeny, ty samotny alternativni distribuce delaji neziskovky a ty zdrojaky samozrejme najdete volne v jejich repozitarich. A existuji proto, ze je tu nejaka potreba na strane koncovych uzivatelu, kterou RedHat neumi a nebo nechce uspokojit. Ale kdokoliv ma moznost do tech repozitaru nahlednout a treba neco i pouzit. Argument, ze ven nic nedavaji proste nicim podlozen neni. Ze si z toho RedHat nic nevezme je jejich volba... a treba i vezme, ale jejich ego jim jen nedovoli to priznat, kdo vi... ;-)
A vsimnete si, ze RedHat zustal v te sve argumentaci o parazitech defacto osamocen, dokonce i v Oracle a SUSE se na jejich stranu nepridali. A o nich fakt nikdo nemuze rict, ze by se jen vezli...
Oracle mohutně vytěžuje RHEL, vlastní vývoj jako RH nedělá, resp. nepodílí se (na vlastním "produktu", ale minimálně ze slušnosti by měl). SUSE nedává k dispozici nic pro to, abyste mohl vytvořit klon. Oba mají máslo nikoliv na hlavě, ale jsou hluboce zanořeni a "nic jiného jim nezbývá", než si plivnout na RH, protože jinak by se museli chytnout za nos.
Změna v CentOS Stream otevírá (!OTEVÍRÁ!) možnost, jak může Oracle a ostatní klony přispívat rovnou do projektu, ze kterého těží. Jenže se jim to nelíbí, protože doteď to nedělali a evidentně dělat nechtějí. Bugzilly všech klonů řeší skutečně pouze repacking, nikoliv systémové věci. Teď by se mohli připojit do CentOS Stream, resp. nějak spolupráci nastavit, jenže nechtějí a výmluvy jsou falešné (několikrát zde bylo vysvětleno).
Tvrdit, že klony primárně vznikají pro blaho komunity je úsměvné :-) a vysvětluje, kde se ta nevraživost bere. Taky se to tady probíralo. Opravdu vedete ideologickou nenávist, nikoliv faktický pohled.
Tak a je to tu zas - kecy o tom, jak jen RedHat tahne tu karku a vsichni okolo se vezou :-) Vzdyt tu ideologickou nenavist tlacite taky, jen stojite na jine strane barikady. Prohlasit, ze Oracle ani SUSE nic pro vyvoj nedelaji je fakt chucpe. Spise jen vzdy neskacou tak, jak z RedHatu piskaji. Ale i o tom vyvoj opensource je - pokud se vam nejaka cesta nelibi, muzete se vydat po ceste vlastni. A tech, co se rozhodlo jit svou cestou je spousta.
A vyhodnotit (ne)prinosnost je prace na hodne dlouho a s obrovskym balikem dat, protoze to mimo jine musite vzit vsechen v distribuci pouzity software a projit ho i v upstreamech, jestli tam nahodou nejsou od dotycnych nejake kontribuce. Fakt to nejde posuzovat jen podle toho, co se nareportuje primo do RedHatu. Jenze tuhle mravenci praci z kategorie neskutecne otrociny nikdo nikdy neudelal, ze? ;-) Ta tvrzeni, ze klony se jen vezou nejsou nicim podlozena.
ale ten jejich blabol o tom, ze by clenove alternativnich projektu nic nevraceli byl take vyvracen.
Když napíšete nějaký nesmysl jednou, dá se to pochopit. Ale když vám to někdo vyvrátí a vy to přesto znovu zopakujete, je už to vědomá lež. Už jsem vám vysvětloval, že nemůžete srovnávat příspěvky komunity a příspěvky zaměstnanců.
A vsimnete si, ze RedHat zustal v te sve argumentaci o parazitech defacto osamocen, dokonce i v Oracle a SUSE se na jejich stranu nepridali. A o nich fakt nikdo nemuze rict, ze by se jen vezli...
OpenSUSE asi nemá ten problém, že by někdo vydělával na supportu poskytovaném OpenSUSE. U Oracle je to složitější, protože Oracle Linux se veze stejně jako Alma Linux nebo RockyLinux. Na druhou stranu, jestli je RHEL oficiálně podporovaná platforma pro produkty Oracle (databáze, WebLogic a další), bude to mít pro RedHat přínos. Takže tam je asi mnohem složitější zjistit, jaká je vzájemná bilance. Navíc o Oraclu se říká, že má mnohem víc právníků než inženýrů. Takže je pochopitelné, proč se RedHat vyhnul tomu namířit to i proti Oraclu. Na druhou stranu nelze čekat od Oraclu, že by se v tomhle postavil na stranu RedHatu, když dělá to samé, co Alma nebo Rocky.
Nesmysly pisete soustavne predevsim Vy a diskuze s vami je fakt jen ztrata casu ;-) Vy snad mate tvrda data dokazujici Vase tvrzeni nebo nas tu jen obstastnujete svoji dojmologii? ;-)
Už jsem vám vysvětloval, že nemůžete srovnávat příspěvky komunity a příspěvky zaměstnanců.
Tohle tvrzení mi nepřijde jako správné. Takže vlastně podle tohohle pohledu lidé okolo Debianu, kteří nejsou za své příspěvky přímo placeny nějakou komerční firmou se nepočítají? Nebo jsou příspěvky lidí co to dělají ve svém volnu méněcenné než těch co jsou za to placeni. Je třeba si uvědomit, že né každý dělá všechno pro peníze (a že to zrovna musím zmiňovat zde mě tedy dost zaráží). Takže kdyby nebyla Alma a nebyla komunita, tak by ten člověk ani nepřispěl, protože by nebylo kam. Zrovna model vývoje, který je tažený komunitou a ne přímo nějakou komerční firmou je ve světě open source celkem běžný.
Jenže ti komunitní přispěvatelé, kterými se Alma chlubí, přispívali do upstreamu. A to mohli dělat i z Archu (přímo jeden z těch případů, o kterých Alma mluví).
Proto neplatí:
> Takže kdyby nebyla Alma a nebyla komunita, tak by ten člověk ani nepřispěl, protože by nebylo kam.
Celý ten problém je, že Alma nepřispívá jako organizace a ani nijak jinak se nepodílí na nákladech pro sestavení RHELu, ze kterého potom čerpá. Nic ji k tomu nenutí, ale bylo by to slušné a "komunitní".
Ta současná změna v distribuci zdrojáků má dvě roviny:
- Neveřejný proces sestavení RHELu přímo závisí na veřejném CentOS Streamu. Tak se primárně zveřejňují zdroje tam.
- Pošťouchnutí Almy, Rocky a Oraclu k tomu, aby začali spolupracovat s autory distribuce... no očividně nemají zájem.
I to Ubuntu od začátku přispívalo do svého rodiče Debianu. Ale ti měli jiné cíle.
Nic z toho, co tu popisujete ve skutecnosti zadny problem neni. Zamerne vytrhavate cleny nejake organizace jen proto, ze je ta organizace ja jejich cinnost neplati. To je jak prohlasovat, ze vedouci skautskeho oddilu se na vychove deti nepodili, protoze tu praci ve skautu prece dela dobrovolne a jedinej, kdo deti vychovava jsou skoly s placenymi pedagogy...
Z cizich prispevku do upstremu zijete i vy, tak nevim na co si furt stezujete :-)
Nic vyvráceno nebylo. Celá argumentace Almy je "Members of the AlmaLinux community created in this way contribute to numerous projects".
Dokonce šli až tak daleko, že ukazovali na konkrétní uživatele. Jenže uživatelé je nestojí peníze! Oni se jako firma nebo nadace zatím nijak nepodílí na nákladech. Využívají k sebe-propagaci práci svých obdivovatelů, ne tu svoji.
Zatím je to klasická socializace nákladů a kapitalizace zisku. A komunita jim ještě tleská.
Vas argument opreny o kdo komu posila vyplatu fakt neni validni ;-) Jasne, kazdej z neceho zijeme a potrebujeme zit... ale zpusob financovani ala RedHat opravdu neni jediny zpusob, jak se opensource da delat a realne i dela. Ne vsichni lidi delaji veci jen pro prachy.
A netvrdte, ze RedHat naklady taky nesocializuje a nesnazi se o kapitalizaci zisku. I kdyz tam mate hromadu ruznych kontribuci, tak porad sami stavite i na vecech, ktere vytvoril nekdo jiny.
> Vas argument opreny o kdo komu posila vyplatu fakt neni validni ;-)
Jistě, že je. Alma bere placenou práci Red Hatu (distribuci a její testování) a nevrací nic zpět. A pak za ni má příjmy. S minimem práce.
A část komunity ještě ostatním tvrdí, že ta práce RH vlastně není důležitá, uměl by to každý a Red Hat si tudíž nezaslouží za to dostávat zaplaceno.
Proč by se nám to mělo líbit?
> Ne vsichni lidi delaji veci jen pro prachy.
Spousta kolegů (včetně mě) posílá patche do ne-RH projektů i po pracovní době. Můžeme si to dovolit, protože díky práci v RH nouzí netrpíme. RH nám to dokonce umožňuje dělat i v pracovní době (v rozumné míře). Protože z toho těží všichni.
Ale realitou je, že většinu vývoje v linuxu táhnou dnes komerční firmy a jde o velké peníze.
> A netvrdte, ze RedHat naklady taky nesocializuje a nesnazi se o kapitalizaci zisku. I kdyz tam mate hromadu ruznych kontribuci, tak porad sami stavite i na vecech, ktere vytvoril nekdo jiny.
Samozřejmě. My spolupracujeme s autory od kterých bereme obsah (se všemi to nejde, ale zase podporujeme komunity jako celek).
To samé ovšem očekáváme od ostatních a dokonce jsme jim k tomu dali možnost na té distribuční úrovni. Ten CentOS Stream Git Lab je veřejný a přijímá příspěvky!
Jenže ti někteří, o kterých je tu řeč, tuto možnost nevyužívají. Nijak. Jejich přínos pro společné dílo (distribuci!) je skoro čistá nula.
Jejich přímý přínos (nadšence a sympatizanty fakt počítat nemůžete) v upstreamu je také neviditelný.
To není chování komunity. RH kroky nejsou populární, ale ti ostatní se etikou svého chování nikdy nedostali ani na úroveň toho RH. Jsou populární, protože "bohatým" berou a chudým dávají.
Kritizujete neco, co je samotnou podstatou GPL software a vec, kterou sami take castecne delate. Ale i tu vasi praci na nem muze kdokoliv vzit a vydelavat na tom kolik uzna za vhodne. Kdyz vam to vadi, tak jste si meli v roce 1994 osedlat jineho kone, ktery by lepe monetizoval praci vasich lidi. Kone muzete vymenit i dnes, vemte si AIX od IBMky a stavte si byznys na nem ;-) Nebyval to zas tak spatny system, co si tak pamatuju z doby pred 15+ lety. Stavet byznys na GPL software ma sve vyhody (ktere sami cerpate), ale obcas i nevyhody... se kterymi se zda se neumite smirit a popasovat.
Ano, vyvoj Linuxu tahnou i komercni firmy, ale take spousta non-profit organizaci. Spousta firem a ruznymi zpusoby - ale vydelava se predevsim na realnych sluzbach okolo s meritelnou pridanou hodnotou. A vy namisto zamysleni se nad tim, proc lidi radeji sahaji po klonech vymyslite krecovite knuuu o parazitech. Ale meli byste premyslet primarne o tom, proc lide jdou radeji k te konkurenci... a neposlou ty prachy k vam.
A znovu - prinos se fakt neda merit jen podle toho, co se se objevi ve vasem Gitlabu. Ale chapu, ze prolejzani gitu&spol u vsech upstreamu, ze kterych cerpate je neskutecne velky oser... ale prosim netvrdte, ze nikdo okolo neprispiva a jen vy tahnete tu karku... :-)
Kňů tady nedělá RH, ale vy. RH dělal (a platil) práci navíc, která umožnila a ulehčovala sestavení klonu jejich distribuce. Teď ji už nechtějí dělat "to navíc" (jinak vše zachovávají). Dělají to protože pro ně je to takhle jednodušší a navíc to odblokovalo obtížnou možnost spolupráce tvůrců klonů na RHEL. A co udělali ti tvůrci? Zlobí se, že mají "víc práce" a pomoct svému chlebodárci nechtějí. Navíc to nedělají zhusta nezištně ale kvůli zisku...
Čili se tady nadává chlebodárci, že ten chleba už není v plátýnku, jak byli zvyklí. Že je pořád stejně chutný a plátýnko si můžete přinést? Nene, nadává se: Hanba! Chlebodárce náš šidí! Ať nám dává stále chleba a k tomu i plátýnko!
Hrozný.
Az na to, ze oni s tim zas tak moc prace mit nebudou a dostanou co chteji/potrebuji. A podle popisu s tim zas tak moc prace neni. A zautomatizovat to zvladne i maly decko. Aneb redhati "hahaha, vyzrali jsme na vas" se nekona, ze? :-)
S jakou verzí RHELu přesně by to mělo být binárně kompatibilní? S posledním minor releasem se všemi aktualizacemi, nebo jen s těmi bezpečnostními, nebo s předchozím minor releasem, který je stále podporovaný v rámci EUS a dostává jen kritické a bezpečnostní aktualizace, nebo ještě s tím předchozím, který je taky stále v rámci EUS podporovaný?
Těch podporovaných variant RHELu, kterých si můžete v rámci jednoho major releasu vybrat, je hodně. Všechny mají jedno společné: jsou kompatibilní do zdokumentované úrovně, kterou Red Hat garantuje pro celé velké vydání RHELu. A tahle kompatibilita platí i pro CentOS Stream, protože pokud ji držíme pro celý major release, musíme ji držet i pro nadcházející minor release v rámci toho major releasu.
Zdravím,
musím reagovat nezlobte se ale Centos není 1:1 k Redhatu. RHEL chce abychom tu měli mishmas nějaké technologie, ve kterém se vyzná jenom on.
Mohu říci že východisko z této situace je pořídit si základní RHEL licenci a nabídnout ji Alma/Rocky Linuxu. Toto je správná cesta.
Co vy ostatní v ČR obětujete pár korun pro opensource za jeden rok?
Přesně tak jak požaduje Rocky Linux a znemožníme rhel odkud se zdrojáky vezmou?
> musím reagovat nezlobte se ale Centos není 1:1 k Redhatu
Já musím reagovat taky.
Není 1:1, ale je zatraceně blízko a obsahuje kompletní zdroje.
> Mohu říci že východisko z této situace je pořídit si základní RHEL licenci a nabídnout ji Alma/Rocky Linuxu. Toto je správná cesta.
Myslíte podepsat smlouvu s úmyslem ji rovnou porušit? To je v českém právním řádu klasifikováno jako trestný čin podvodu.
A i kdybychom se oprostili od právní roviny, tak eticky je to neskutečná prasárna. Na RHELu pracuje přímo a nepřímo několik tisíc lidí. Které je třeba zaplatit. Když nebudou, svět se nezhroutí, ale rozhodně byste to poznal. A je naivní tvrdit, že ne. (Minimálně by pak SUSE, Oracle, Alma a Rocky museli dávat poněkud více peněz na testování a vlastní vývoj - a to řádově více).
Proč věnujete tolik energie pokusům klonovat RHEL a nepřispějete spíš k jeho vývoji? Nelíbí se Vám něco na Streamu? Tak pošlete patch. Nebo rozjeďte testovací prostředí. Možnost už máte (narozdíl od původního CentOSu).
Místo toho zakládáte nové a nové "komunity", které ovšem na tom produktu přímo nic nevylepšují.
Patch do upstreamu totiž mohli poslat i z Ubuntum Fedory nebo třeba Archu a do RHELu (Debianu, SUSE i ostatních) by se dostal tak jako tak.
Pises o tom trestne cinu podvodu a porusovani licence, ktery pacha RH? Tak to jo, vzhledem k rozsahu tyhle cinbosti je to na zruseni firmy.
Kdyz ty lidi nebude platit RH neznamena, ze je nebude platit nekdo jiny, coz je neco, co v RH nejak nedokazou pobrat. Pricemz tech lidi kteri vytvari to, co RH prohlasuje za sve, jsou statisice. A RH je rozhodne neplati.
V dobe virtualizace a kontejnerizace si ten R-HELL i s CentDost muzou .... vystavit. Osobne mne nejvic nakrklo, kdyz jsem u jednoho "enter price" IBM java software pro zprovozneni (instalaci) na Debianu musel ofejkovat nejake priblble RH init functions, pritom instalator byl self extracting shell archive, spoustel java instalator, v nem java based ksh - a nakonec to jeste vyzadovalo 32bit knihovny kvuli nejakemu zpizdenemu proprietarnimu prehistorickemu jvm. S cs_cz locales to padalo, s sk fungovalo... holt tatari od IBM a nekonecne strace orgie.
Za mne jedine dobre, kdyz RHEL kvuli IBM a jejich pristupu k CentOS skonci, 3-rd party vendori pak doufam zacnou vice podporovat Debian (nebo alespon Ubuntu).
Tak jinak poruším licenci gpl když začnu zveřejňovat zdrojové kódy pro RHEL els6,7,8,9? Klidně si koupím jednu licenci. Jak to vidíte vy ne RHEL zaměstnanci? Nebo se může připojit každý z nás aby RHEL nepoznal od koho je?
Toto může nabídnout kdokoliv a pomoci... Opravdu chce Redhat aby to zašlo až to této roviny?
Opravdu chcete tak moc kousat ruku, která ty klony krmí?
To je nějaký pokus zbavit se té zlé korporace, která z RHELu udělala to, co chcete a zároveň si ponechat ten RHEL?
A bude to pak ještě pořád ta samá distribuce? Nejsou ty zavedené procesy vývoje, důraz na stabilitu a pověst lidí ten důvod, proč ji vlastně tak moc chcete?
Tak povest jste si ted zrovna moc nevylepsili ;-) A tvarit se tak, ze bez ty vasi ruky nastane konec sveta je proste divny. Ono nahraditelni jsme vsichni - neco mozna muze byt bolestivejsi, ale nikoliv nemozne... jen jestli vy nahodou nemate strach z toho, ze by ty alternativy mohly byt mozna i lepsi nez original... :D
Jsem slepej, nebo do zpravy Jezek vubec nedal odkaz na puvodni Oracle zdroj?
https://www.oracle.com/news/announcement/blog/keep-linux-open-and-free-2023-07-10/
Ja zas telemtriu ako vyvjar chapem, pretoze ak chces produkt posuvat spravnym smerom a nemas nekonecny budget, tak chces vediet, ktore jeho casti su problemove, ktore sum asivne pouzivane a ktore zas nepouziva nik. A tiez viem, ze ludia ti toto nenahlasia ale budu frflat na nejakej FB odveci diskusii.
No aj ta telemtria ide spravit lepsie a ide spravit horsie.
Chudaci kernelovi vyvojari, jak ti muzou bez telemetrie jen prezit :-) Chudaci vyvojari Debianu, jak ti muzou se svym opt-in systemem fungovat... a tak muzeme pokracovat. Ne, to jen u RedHatu si pseudo-zduvodnuji, proc reseni postavena na opt-in jsou spatna a tlaci opt-out... tam je ten zakopany pes.
Chudaci kernelovi vyvojari, jak ti muzou bez telemetrie jen prezit.
Což o to, přežívají... ale informace, jestli určitý driver, featuru nebo architekturu ještě vůbec někdo používá, by se občas zatraceně hodila. Třeba rozhodnutí, který kus archaického a neudržovaného kódu už je na čase vyhodit, by se pak nemusela dělat naslepo na základě osobních dojmů.
Chudaci kernelovi vyvojari, jak ti muzou bez telemetrie jen prezit
Možná vás to překvapí, ale i kernel vývojáři používají telemetrii. Náš ABRT, což je svým způsobem taky telemetrie, kromě pádů sbírá také kernel oops, což pak našim vývojářům dává informace o tom, které problémy se v kernelu v praxi nejvíc projevují. A neděláme to zdaleka jen my, ale i další distribuce.
Chudaci vyvojari Debianu, jak ti muzou se svym opt-in systemem fungovat
Nebude to taky tím, že Debian reálně upstreamový vývoj nedělá? Tahle telemetrie se dělá kvůli desktopovému vývoji, nevšiml jsem si, že by se třeba v GNOME objevovali ve větší míře vývojáři Debianu a implementovali tam věci, které potřebují pro své uživatele. Spíš pasivně přebírá, s čím přijde upstream. To neberte jako kritiku Debianu. Je to tak naprosto v pořádku. Je to distribuční projekt a drží se svého účelu, ale je trochu chucpe předhazovat někomu, kdo ten upstreamový vývoj dělá a chce pro to mít informace, že někdo jiný, kdo ten vývoj nedělá, ty informace nepotřebuje.
proc reseni postavena na opt-in jsou spatna a tlaci opt-out... tam je ten zakopany pes
Tak on to nikdy nebyl čistý opt-out. Podle toho návrhu ta telemetrie by default nikdy neměla být zapnutá. Ano, na té obrazovce, kde si to měl uživatel nastavit, ta volba byla zatrhnutá, ale i to bylo po zpětné vazbě od komunity změněné a teď to je čistý opt-in. Jestli to bude dávat užitečné výsledky, je věc druhá.
Ano, ty nastroje poskytujici automaticke reporty ma kdekdo, ale i tam je ten opt-in. Nastroj muzete pouzit, nemusite. A pokud se i u Fedory pod natlakem uzivatelu chovani te sve telemetrie nakonec prehodnotilo, tak jedine dobre. Ale formalne vzato defaultne zatrhnuta volba je opt-out... a takove lehce prasacke reseni postavene na tom, ze lidi moc nectou a odklikaji default.
Nepůsobím v oblastech, kde by využili Red Hatí distribuce a podporu, což nic neubírá tomu, že beru RH jako významného hráče. Přínos RH sahá mnohem dál, než jen k RHEL. Za stejně důležitou věc považuji i to, že dokázali spojit skupinu podobně naladěných lidí napříč celým světem a tuhle skupinu i zaplatit (Rozuměj, vytvořit jim takové podmínky, aby nemuseli, to co je baví a co umí, dělat jen jako bokovku po práci).
Také se s obavami dívám na události, jako koupě od IBM, i pro to, že si živě pamatuji koupi SUNu Oraclem, byť vstupní parametry nejsou stejné, pořád to nese značné riziko, že se něco "pokazí".
V tomhle sporu o CentOS a defacto kompatibilní klony k RHEL vidím několik nešťastně zvolených komunikačních linek, jakým jsou kroky RH obhajovány.
Například obhajování změn důvodem, že se strany klonů nebyl přínos v reportování a opravách chyb.
Jaký to mělo důvod, že k tomu nedocházelo?
Jaké další možnosti mohl RH využít, aby podpořil reportování a opravy chyb?
Každopádně fandím nám všem, abychom tenhle "mini-rozkol" dokázali zvládnout a našli, když ne skvělé, tak aspoň uspokojivé, řešení.
> Jaký to mělo důvod, že k tomu nedocházelo?
Nešlo to. Technicky ani procesně. CentOS byl přímo rebuild SRPM a nebyl tam žádný náhled na zdroje a žádný rozumný kanál pro patche (krom emailu).
> Jaké další možnosti mohl RH využít, aby podpořil reportování a opravy chyb?
Veřejný GitLab, CentOS Stream, .. je toho právě dost co se udělalo, aby ta technická i procesní bariéra padla.
Já ty konflikty považuji za přínosné aby člověk co o tom nemá přehled, neumí anglicky atd. se dozvěděl co jak ve světě svobodného softwaru funguje :-)
Pochopil jsem že hlavní problém s vendor lock in a kompatibilitou se týká
api a abi pro to aby fungovali propietalni bloby nebo proprietární sw (předpokládám že ten svobodný by nebylo problém překompilovat, možná i to je drahé nebo nemusí být snadné?).
Řeší tento problém do budoucna
flatpaky, Nixpkgs nebo něčeho vhodného aby šlo garantovat nebo předpokládat funkčnost nezávisle na distribuci?
Jaké distribuce dávají informace o tom jak a na čem a s čím je jejich software poskládaný tak aby šlo udělat klon 1:1 ?
To by mohlo být také pro někoho jako kritérium výběru jak zabránit vendor lock in..
> Jaké distribuce dávají informace o tom jak a na čem a s čím je jejich software poskládaný tak aby šlo udělat klon 1:1 ?
Je několik typů distribucí:
- sestavované ze zdrojáků u uživatele - Linux From Scratch, Gentoo - jelikož umožnují i bootstrap, tak to asi splňují komplet (ale bacha - *).
- komunitní typu Debian, Fedora, Arch - teoreticky to jde, prakticky není úplně jednoduché postavit stejný build systém. Tj, máte zdrojáky, ale není snadné z nich opravdu udělat bootstrap stejným způsobem jako ta distribuce.
- komerční jako SUSE, RHEL, Oracle - i když máte zdrojáky, tak build systém neznáte a může mít interní kroky, které nezreprodukujete. Nikdy. Například systém pro kontrolu exportních pravidel (šifry a jiné technologie), elektronické podpisy komponent a balíků, dělení do repozitářů podle zákazníka nebo produktu atd.
- commitové distribuce jako Fedora Silverblue, NixOS atd toto také neřeší, umožňují vám ovlivnit instalaci konkrétních verzí, ale build systém je pořád mimo vaši kontrolu.
(*) Ani Gentoo ovšem nezaručuje reproducible buildy (myšleno binárně identické). Různě po komunitách se na tom pracuje, ale překladač a programy jsou pořád ještě ovlivněny časem (timestampy v souborech) a použitým hardware (optimalizace).
> NixOS atd toto také neřeší, umožňují vám ovlivnit instalaci konkrétních verzí, ale build systém je pořád mimo vaši kontrolu.
What. NixOS naopak umožňuje detailně ovlivnit build jakéhokoliv balíku, a reproducible buildy jsou v podstatě #1 priorita. Moje dva pracovní stroje jsou binárně zcela identické (tedy, tam kde to aplikace umožňuje), i s tím že mám v některých balíkách upravené build flagy a některý software si buildím sama.
12. 7. 2023, 10:51 editováno autorem komentáře
Jenže ne všechen software to umožňuje. https://github.com/NixOS/nixpkgs/issues?q=is%3Aopen+is%3Aissue+label%3A%226.topic%3A+reproducible+builds%22
Je to svatý grál, ale není snadné ho dosáhnout.
A btw, build jednoho balíku je něco jiného než bootstrap celé distribuce. Nicméně ok, máte pravdu, že u NixOS je to snazší než jinde a je to jejich cílem.
Tam je spíš problém v definici toho co je vlastně distribuce, protože NixOS je dost stavebnice. Každopádně bych ho v tom seznamu řadila spíš k Gentoo než k Fedoře. Protože snadný bootstrap je jedna z jeho hlavních vlastností a co není v build cache se sestavuje přímo na koncovém zařízení.
12. 7. 2023, 11:22 editováno autorem komentáře
Ano, byla jsem uživatelka Silverblue před přechodem na Nix, a tak nějak tam nevidím žádnou paralelu, zvlášť ne v možnosti bootstrapu distribuce. Jediné co je podobné je možnost rollbacku, ale to má i třeba Arch s nastavenými snapshoty.
"build systém je pořád mimo vaši kontrolu" je naprosto mimo.
12. 7. 2023, 14:22 editováno autorem komentáře
Já to chápu jako takový arch (na rozdíl od gentoo se distribuuji binarky, ale můžou i návody na sestavení kódu třeba na git repo, je snadné tam se kompilovat i automatizovaně a měnit nastavení kompilace) a běží to v kontejnerech.
Tedy silverblue a Suse micro (údajně to jde přepnout u všech ale nezkoušel jsem).
Ale nevím proč by zase nešlo v silverlue nebo suse také kompilovat s vlastním nastavením a přenášet to jinam jako image který by měl fungovat na jiném sestavení distra bez toho aby to rozbilo něco jiného
Tedy jakou má výhodu vlastně nix oproti silverlue nebo suse?
Také vlastně nevím proč by někdo měl na server nebo desktop používat stream nebo Rh.. Co má za výhody?
Jediné co mě napadá SELinux? Nevím jak má dobré přednastavené konfigurace třeba to suse micro..
Zajímavé je že suse nabízí podporu i pro produkty redhatu už delší dobu.
Strojový překlad
Nulové výpadky, úplná kompatibilita
Se systémem SUSE Liberty Linux si můžete být jisti, že všechny opravy údržby a zabezpečení jsou plně testovány tak, aby byly plně kompatibilní s RHEL a CentOS, od zdrojového kódu a binárních souborů až po integritu binárního rozhraní aplikace jádra. Pravidelně vydávané binárně kompatibilní bezpečnostní záplaty a údržbové aktualizace zajišťují, že celá vaše smíšená linuxová aktiva jsou aktuální a bezpečná, což zajišťuje vysokou dostupnost, odolné úložiště a neprůstřelné vyrovnávání zatížení.
https://www.suse.com/products/suse-liberty-linux/
12. 7. 2023, 14:48 editováno autorem komentáře
Tedy dlouho.. min 31.1. 2022
https://www.root.cz/clanky/suse-liberty-linux-nabizi-podporu-pro-dalsi-distribuce-ubuntu-zrusi-repozitare-partneru/
Distribuují se ne binárky, ale návody na sestavení balíků včetně závislostí. NixOS ani nemá binární balíky v pravém slova smyslu, má binární cache. Při instalaci se vyhodnotí hash pro build instrukce (derivace), podívá se jestli je ten hash v jedné z nastavených cachí, a pokud ano, stáhne si cachovaný build. Při vypnutí cache se buildí všechno.
Rozhodně to pak neběží v kontejnerech. Věci instalované v nix store sice zahrnují všechny své závislosti (podobně jako třeba Flatpak), ale není to kontejner (nemají vlastní namespace) - ostatně ani nemůže, nix jako balíčkovací systém plně funguje i na MacOS.
... OMG
"Také vlastně nevím proč by někdo měl ... používat ... Rh"
Protoze jeho dodavatel dodavajici nejaky SW ten SW podporuje prave a treba i pouze na RH. A pokud budes resit, ze neco nefunguje, pricemz se zjisti, ze to nefunguje na cemkoli jinem, tak ti dodavatel rekne, ze kdyz si to provozujes na necem jinem, tak si to taky sprav.
A tenhle stav nastaval mimo jine prave proto, ze tu existovala jak placena tak neplacena varianta (centos) tudiz dodavatel takoveho SW typicky v zavislosti na pozadavcich/infrastrukture/rozsahu ... dodal jedno nebo druhe.
No vysledek tehle komedie je,.ze postgresql.org neni podporovany na Centos Stream a TimescaleDB extenze je testovana a doporucovana prave pro postgresql.org baliky.
Potrebujes postgres s timeseries? No tak to na Centos Stream zapomen.
Ted zase saskarna s "parazity", at se drzim RH terminologie.
To bude lepci rovnou se zdekovat na Ubuntu.
Spis to vidim tak, ze oni z toho rolling chteli, a ted se z toho snazi vsemozne vycouvat, ze to zas tak roling nebude, a ze oni tim mysli neco jinyho nez vsichni ostatni.
Jenze uz jim nikdo neveri ani nos mezi ocima. Ty bys nekam nasazoval system, u kteryho ti zitra zrusi support?
13. 7. 2023, 08:27 editováno autorem komentáře
> Spis to vidim tak, ze oni z toho rolling chteli
A k čemu by nám byl? To myslíte, že nám nestačí Fedora Rawhide?
> ze to zas tak roling nebude, a ze oni tim mysli neco jinyho nez vsichni ostatni.
Ale on to rolling je, jen pro Stream 8 a Stream 9 nezávisle. To rolling se vztahuje na frekvenci a způsob aktualizací. Dostáváte balíky hned.
Wikipedia se mnou souhlasí:
"Rolling release, also known as rolling update or continuous delivery, is a concept in software development of frequently delivering updates to applications.[1][2][3] This is in contrast to a standard or point release development model which uses software versions that must be reinstalled over the previous version."
To, že Arch a ostatní notoricky známé případy jsou zároveň i bleeding edge distribuce je naprosto nesouvisející atribut.
CentOS Stream je rolling release (tj. nemá minor vydání), ale je stabilní == není bleeding edge.
Jedna věc je formální definice, jiná věc je jak tomu výrazu rozumí drtivá většina komunity. Existuje vůbec nějaké jiné distro které se takhle označuje a je vydávané stejným způsobem jako Stream?
Nazvat to "Rolling updates" distribucí byl prostě totální PR průšvih, který Centos Stream pro spoustu lidí pohřbil dřív než mu stihli dát šanci.
chápu správně, že jste zařízli CentOS 8, abyste udělali CentOS Stream (v té době tam ještě ta 8 nebyla), nazvali to rolling release distro (btw, minor vydání neměl nikdy), řekli, že to bude na půl cestě mezi Fedorou a RHEL, nechali jste zákazníky zmigrovat na OL, abyste dnes tvrdili, že vlastně to nic není a jediná změna je, že minor patche nejdou pohromadě, ale průběžně?
To vypadá jako pěkná groteska.
Vždyť v době zaříznutí CentOS 8 jste ani českým velkým zákazníkům nebyly schopní říct jak to bude a nechali je v nejistotě, na containery, CI a jiné úlohy jste žádné řešení nenabídli. Ti nečekali a místo placení spousty RHEL si dnes platí ještě víc OL za znatelně nižší cenu.
Pokud skutečnému stavu nerozumíme pořádně ani my, kteří ty systémy navrhují, těžko můžete chtít, aby tomu rozuměli platící zákazníci.
chápu správně, že jste zařízli CentOS 8, abyste udělali CentOS Stream (v té době tam ještě ta 8 nebyla), nazvali to rolling release distro (btw, minor vydání neměl nikdy), řekli, že to bude na půl cestě mezi Fedorou a RHEL, nechali jste zákazníky zmigrovat na OL, abyste dnes tvrdili, že vlastně to nic není a jediná změna je, že minor patche nejdou pohromadě, ale průběžně?
Popis toho, co CentOS Stream je a jak se liší od starého CentOSu, byl od začátku stejný a od té doby se nijak nezměnil. Stačí si přečíst můj 2,5 roku starý článek tady na Rootu, kde už tenkrát to bylo jasně vysvětlené a ani dnes na něm nemám potřebu nic měnit.
Krasne jste si tam popsal duvod, proc se do Streamu asi moc lidi nehrnou.
Pakliže na tradičním CentOSu bylo možné v jediný den aktualizace otestovat a poté aplikovat na produkčních systémech, kdy s trochou štěstí nebyla v daném časovém okně vydána žádná errata, u Streamu už to bude o něco těžší trefit, protože aktualizace přicházejí častěji.
Uzivatele maji dve moznosti - bud pouzit ten vas "workaround" s lokalni kopii repozitare a sr*nim navic... a nebo se poohlednout po nejakych alternativach. Po tech dvou a pul letech ocividne asi vyhrala spise druha moznost, coz vas ale zaclo stvat... soude dle soucasne reakce na tema klony ;-) Aspon ze priznavate nestastnost onoho oznaceni, ale ani to jste za ty dva a pul roku zmenit taky nezvladli...
Jenom perlicka.
Jeste pred tremi lety byl prakticky kazdy linuxovy tutorial postaveny na RHEL klonu.
Ted defacto vsecko na Ubuntu.
Treba TimescaleDB instalace, pred nedavnem uodatovana stranka, Ubuntu je uz vychozi, navod pro RHEL je dostupny po prekliknuti jako alternativa.
Zrovna jsem si otevrel kubernetes crash course a RHEL variantu ze.soucasne doby jsem vůbec nenasel.
12. 7. 2023, 22:30 editováno autorem komentáře
Asi to bude nepopulární, ale poslední dobou, co sledují RPM-based distra. Tak mi je... no jak to říci, je mi opravdu hodně smutno a jsem znechucen.
Je to už jedno jestli Oracle Linux, RHEL, OpenSUSE, Fedora, Nobara atd. Každý ukazuje na druhého prstem, nic není o nadšené spolupráci a konečně umlčet Microsoft s jejich odpadem jménem Windows. Tímto tempem prohrajem všichni, skrz MacOS i Windows.
Vidím to tak, že na server Debian. Ubuntu ne... máme to u nás... no je to strašné, Canonical s jejich snapem, nebudu komentovat, škoda slov.
Už jsem tak hluboko v zoufalství, že snad začnu zastávat názor "Arch Linux i na server" a dát si trochu práce a hlídat si to sám, starat se o to. Přemýšlím, že to u nás v malém prostředí fakt zkusím.
Red Hat a Oracle mají výrazně odlišnou pozici.
Red Hat prodává subscription svého OS (je to cca 90% jeho tržeb), který nahrazuje klasické Unixy. Zákazník kupuje to, že jeho HW a SW je podporovaný na RHEL. Tedy nikoliv "ten RAID možná bude fungovat, prostě to zkuste, a ono to třeba něco udělá", ale "tenhle RAID je testovaný, certifikovaný a podporovaný". U aplikací pak například "SAP S/4HANA běží na RHEL a SLES, cokoliv jiného je nepodporované". Pro korporátní zákazníky je pak Red Hat jasnou volbou. Kde je problém? V tom, že klony jako CentOS jsou funkčně shodné s RHEL, ale jsou zdarma. Kde není podpora opravdu nutná, tak je lze použít, a Red Hatu to užírá z tržeb. Takže je pro Red Hat žádoucí zabránit zabránit fungování klonů RHEL, a samozřejmě také používání RHEL bez předplatného.
Oracle - mimochodem 10x větší než RedHat - je na tom úplně jinak. Jejich primární business je cloud, včetně aplikací (Enterprise Resource Planning, Supply Chain Management, Human Capital Management a další) a industry solutions (Communications, Financial Services, Consumer Goods, High Tech and Manufacturing, Higher Education, Hospitality, Utilities). Sekundární business jsou licence aplikací, včetně RDBMS, E-Business Suite atd. OS je pro Oracle jen nutnou platformou, na které běží jeho aplikace. Je strategicky výhodné mít vlastní platformu, a nebýt závislý na HP-UX, AIXu, Windows a dalších. Ten luxus vlastní platformy pak stojí jen pár dolarů z těch hromad peněz, vydělaných na prodeji closed source software, tedy nic zásadního. Oracle není závislý na tržbách z OS, a proto je mu celkem jedno, jestli existují klony jeho Oracle Enterprise Linuxu.
Širší kontext je takový, že živit se ve světě open source není jednoduché, a to ani pro Red Hat, který má veškerou motivaci ten open source zavírat do krabice s nápisem "před použitím musíte zaplatit". Oracle se živí closed source softwarem, a open source financuje jako "hobby".
... cim jako myslis ze se zivi nejmene 1/2 tech lidi, kteri sem chodi? Zivit se ve svete OS naopak jednoduche je, jen musis dodavat to, co zakaznici realne chteji a tak, ze nemaji pocit, ze je okradas a nic jim nedodavas, coz je presne to, co dela RH.
Co vlastne dostanu za svy prachy, kdyz jim zaplatim? V 99% ... zhola nic. Kdyz koupim widle, budu na tom lip - jsou radove levnejsi. Support dostanu stejny = zadny.
Probiralo se to tu opakovane ... kdyz si zaplatim support na HW a neco se podela, tak v nejakym definovanym case dorazi pikolik a vymeni to. A je uplne jedno ze mam jedinej kus. Kdyz si zaplatim support na rhel a neco mi nebude fungovat tak ... dopadnu stejne jako s tema widlema. Vyres si sam.
OK, upřesním. Není lehké platit vývoj open source. Je k tomu zpravidla nutné ten open source nějak uzavřít, například formou nepovinně-povinných closed source modulů, nebo ho živit z nějaké jiné aktivity, například z closed source produktů, konzultačních služeb, prodeje HW apod. Pokud jde o možnost živit se ve světě open source, tak souhlas, že například na službách se do jisté míry uživit dá.
Podporu Red Hatu jsem nezkoušel. Akorát vím, že u RHED je support v rámci licence formou self-supportu, tedy přístupu k knowledge base. U MS jsem několikrát viděl, jak support například sbíral dumpy na produkci, a zjišťoval z nich příčiny problémů. Pochopitelně to není v ceně desktopové licence Windows :), ani té serverové. Premier Support (dneska tuším Microsoft Unified Support) se připlácí.
Myslím že problém byl hlavně v komunikaci.
Ale to co jsem se pak díky těmto problémům dozvěděl v komentářích mi pomohlo v tom se dozvědět spoustu nových zajímavých informací které bych nevěděl..
Technicky důvod proč používat na server rhel (16 licencí je pro mě dostatečných) nebo centos stream co Fedoru když nepotřebuju stabilní api, abi, certifikáty, nejsme korporace atd atd.. bych mohl možná chtít z důvodu dobře funkčního SELinux, který nevím jestli má přednastavené a vyladěné profily i v suse.
U centos stream se dají dělat jen security updaty, takže z toho může být dost stable distro..
Původní centos nebo teď současné klony jsou na tom byl možná z tohodle pohledu hůř (méně oprav, nemožnost přispívat a dělat změny, opožděně updaty).
Zároveň Jeslti chápu dobře tak security patche chodí do centos stream o něco později než do Rhel, takže by byl lepší. Ale je tam podmínka vyplnit otravný formulář.. Takže by mi to muselo stát za ten SELinux.
Zároveň jsem zvyklý používat LXDE (na serveru bych asi mohl klidně používat terminál) který spravuje komunita kolem redhatu dost mizerně oproti jiným distribucím..
SELinux navíc má větší režii na výkon než AppArmor nebo nic.. :,-)
Takže z mého pohledu k čemu vlastně Fedoru, rhel nebo klony?
Když tu je spoustu jiných distribucí..
Co se týče firem, tak teoreticky si můžou pořídit 16 licencí rhel zadarmo ale používat jich víc, protože kdo nebo co jim v tom zabrání? Leda kompilace při placeném supportu (teoreticky by mohli třeba založit další firmy v daňových rájích a využívat je jako dodavatele software redhad?).
Nevím já nikdy nepodnikal tak nevím jak se dělá minimax (minimalizace nákladů, maximalizace zisku).
Pokud zase nemusí dělat nějaké optimalizace tohoto druhu tak můžou platit redhatu a ten zaplatí vývojáře které budou přispívat celému světu kódem skrze upstream..
Je jasné že se nějakým způsobem ohledně používání rhelu jedná o vendor lock in..
Řešení je tedy se takovým věcem vyhnout tím že budou používat takový software a technologie aby nebyly závislý na jednom dodavateli..
Vlastně to ukazuje že Linux do velké míry fungují díky korporacím které využívají vendor lock in ale je to hlavně problém a chyba dodavatelů resp jejich zákazníků že si kupují tohle zamykání...
Něco jakože si vlastně raději koupíme čínský telefon s malware od činy a USA s krátkou software podporou a pomalými updaty kvůli tomu že má lepší parametry a nižší cenu, než svobodný hardware a software do telefonu protože je noc drahý...