Az Oracle Linux töltheti majd be a CentOS után maradó űrt?

Címkék

Az Oracle Linux online felületein megpróbálja meglovagolni, hogy az elmúlt napokban a CentOS jövője körül kétségek merültek fel. Legújabb, "Need a stable, RHEL-compatible alternative to CentOS? Three reasons to consider Oracle Linux" blogbejegyzésében három okot is említ a termékigazgatójuk, amiért szerinte érdemes az Oracle Linuxot CentOS alternatívaként számba venni:

  • Free to download, use, and distribute—for more than 14 years
  • Compatible and enhanced
  • Designed for all workloads

A blogbejegyés itt olvasható.

Hozzászólások

Már bocs, de a CentOS, amiben szerzett némi befolyást a Red Hat, amit felvásárolt az IBM volt az az entitás amely a CentOS kasztrálása mellett döntött. Előtte még valamivel a Scientific Linux úgy döntött, hogy felggeszeszti önállóságát és a jövőben CentOS-re vált. Nyilván csak véletlen egybeesés. Az Oracle sem most kezdte a saját Linux disztribúcióját RHEL alapon. Szimpinek én sem nevezném az Oraclet de momentán jó, hogy létezik ingyen egy ilyen CentOS alternatíva ahova migrálni menekülni lehet. 

Ha nem tetszik ne használd, fordíts magadnak a rhel forrásokból egy saját disztribúciót. Hajrá! :) 

Vicces megjegyzés volt...Smile is jelezte, hogy milyen rendezvényre szól a jegy... Ahogy lentebb már taglalták többen is... tök jó, hogy van ingyen valami... még... ingyen...

 

De amúgy megfontolom, hogy áttérek rá. Viszont CentOS 7-et használok...az meg 4 évig nem kér kenyeret ilyen szempontból.

Szerkesztve: 2020. 12. 13., v – 12:04

Nem a szívem csücske az ORCL, de különösebb kivetnivalót nem látok ebben a próbálkozásban. Adódott egy lehetőség, nem tűnik törvénytelennek, sem pedig etikailag gusztustalannak, hát megpróbálják. Aligha hiszem, hogy túl sok eredményt érnek el vele, de ez már más tészta.

Ha hülye vagyok, akkor így járok. (no persze ez leegyszerűsítés volt)

[EDIT]: Ez a téma egyébként minden egyes Oracle-topicban felmerül, és nem értem, miért annyira fajsúlyos. Tudjuk, hogy a piaci tevékenységük az esetek egy jelentős hányadában minimum kérdőjeles, szóval nem érhet meglepetésként. Ha mégis hagyod magad megvezetni és rábaszol (nem feltétlenül mint ember, sokkal inkább mint cég vagy department), akkor meg miért reklamálsz? Ha azt választod, hogy befürödj valamivel, és tényleg megtörténik, akkor végülis azt kaptad, amit kértél, nem?

Jah. Csak most éppen az is baj, hogy az IBM(RH) is adott valamit ajándékba, amit 1 év múlva már csak pénzért kapsz meg. Tehát ebből a szempontól egy kutya.

Az más kérdés, hogy pont ennél a terméknél az Ora felállás jobb nekünk. És nekik is, mert ha véletlenül szüksége lesz azt end-usernek supportra, azt már igen nagy valószínűséggel az Oracle-től szerzi be és nem megy vissza a RH-hez. Szóval __ebből a szempontból__ ez ön tökön lövés volt a RH részéről.

No-no, a Red Hat ebből a szempontból teljesen korrekt volt. Az IBM meg ugyanaz a porszívóügynök mentalitású, mint az Oracle, hogy bedobnak egy marék száraz lószart, ha kinyitod az ajtót és eladják a porszívót, amivel fel tudod takarítani, csak egy kicsit régebb óta művelik mesteri szinten és szebben csomagolják.

Szóval __ebből a szempontból__ ez ön tökön lövés volt a RH részéről.

Ez szerintem nem a Red Hat ötlete, hanem a IBM ötlete. Öntökönlövésnek viszont öntökönlövés a javából.

mert ha véletlenül szüksége lesz azt end-usernek supportra, azt már igen nagy valószínűséggel az Oracle-től szerzi be

Te még nem láttál Oracle supportot közelről, bakter :D

Szóval ha az end-usernek bármi köze van az IT-hoz, akkor eszébe sem jut, hogy az Oracle-től bármilyen supportot akarjon beszerezni.

Hát, néha még annyit sem tud a support, hogy hol az ls parancs.

 

Egyszer volt egy köröm az IBM support-al, valami Sun szervern futó, MQ Series ügyben, és  küldtem nekik konfigot és logot.

A hibabejentésemre a hivatalos válasz az volt, hogy a "SunOS 5.9 nem támogatott oprendszer,  támogatott oprendszerek listája: ..Solaris 8  Solaris 9, ..

Látszott a levél előzményeiben, hogy megjárta a teljes 2nd level supportot, és a mérnökök tanácstalanul vonogatták a vállukat, hogy nem tudják mi az a SunOS, de tuti nem supportált....

(hint:  Solaris-ban az uname parancs SunOS 5.X -ként írta ki régebben a kernel verziót. Lehet, hogy még most is, de egy ideje már nem követem.)

Legközelebb "Supporttal" (-val/-vel és a teljes hasonulás esete), ha lehet kétrni, mert irgalmatlanul bánja a szemet. Az, hogy slowaris terén nem voltak top-on :-) az nem azt jelenti, hogy a támogatott szoftverekben ne lenne komoly tudásuk. Egyébként SunOS-nek a SunOS4-ig nevezték a rendszert, ha jól emlékszem, utána már Solaris volt a hivatalos elnevezés (SunOS4 ~ Solaris 1). Ahogy Linuxon az uname a kernel verzióját írja ki, nem pedig a disztribúció nevét és verzióját, úgy slowaris-on is hasonló a helyzet :-)

Nem solaris támogatáért fordultunk hozzájuk, hanem a  méregdrága szoftverük hibája miatt.
Saját termékük, saját scriptje által begyűjtött konfig infó alapján nem ismerték fel azt az operációs rendszert amin a termékük támogatott volt. Ez facepalm kategória bármilyen cég esetében.

A kernelt még a 10-es solarisban is SunOs5.10-nek írta ki, szerintem az aktuális verzióban sincs ez másképp.

Volt egy másik is: Informix adatbázist kellett  TSM-el archiválni (mindkettő IBM termék)  és nem úgy működött , úgy  ahogy a doku. leírta. Konkrétan egy bizonyos opciónak nem volt semmi hatása.
Kb 2-3 support kör volt, mindíg csak a dokumentációból kapott copy-paste sablon volt a válasz, hogy már pedig azt így kell csinálni.

 proof-of concept kódod, írtam az API dokumentációjuk alapján, és beküldtem, hogy szerintem hol van fixen beégetve az érintett library-ba annak a bizonyos opciónak az egyik lehetséges értéke.
A support válasza csak annyi volt, hogy valóban az a gond, majd egyszer implementálják a javítást, de per pillanat az nem prioritás.(soha nem implementálták-legalábbis addig amíg érdekelt.)

Jakérem, globalizáció van, úgy kell hibajegyet lejelenteni, hogy azt az európai központ kapja meg. Ha indiai kapja, akkor add be inkább újra. Ha USA, akkor is, mert onnan kiszervezik Indiába. Bár szerintem már lassan az európai support is oda küldi automatikusan.

Az opeárciós rendszer az Solaris, a kernel SunOS, ha így jobban tetszik. És ha azt írod, hoyg SunOS az oprendszer, akkor elhajtanak, mert SunOS nevő operációs rendszer az marha nagyon régen volt.

Szerintem van itt olyan, aki a te esetednél cifrábbat is tudna mesélni (hivatalosan nem létező hacmp verzió például...), de megnyugtatlak, bármelyik cégre lehet ilyen sztorikat keríteni - kedvencem a tükrözött rendszerdiszk dögledező merevlemezének a cseréje a'la hápé - amíg nem nyúltak hozzá, csak warningolt a cucc, a rendszermérnöki beavatkozás vége egy komplett újratelepítés lett... De láttam Sun-os környéken olyat, hogy kolléga a külső diszkdobozon lévő peremkerekes kapcsoló vezetékét nem dugta rá a dobozba rakott diszkre, aki meg rádugta a gépre, az nem csekkolta le, hogy van-e scsi-id ütközés. Volt. Egy négy diszkes stripe-olt kötet egyik lemezével...

A hacmp az nem is olyan nagy durranás. ;) Végülis a kereskedő egy adatbázis alapján eladott egy oprendszerrel inkompatibilis szoftvert a 100 Milkás gépekre. A fejlesztőknél meg volt olyan verzió, ami működött. ÉS a support egyik tagja priviben ismerte a fejlesztőket. Sima ügy!

Az már bonyolultabb volt, amikor a Fakezű szervizes letépte az egyik gép ajtaját. Az adatbázisban ugyanez az alkatrész 3 FRU-ra szakadt, ezért marha nehezen tudta megrendelni. ;)

Ide tartozik az i8080 mikroprocesszor helyzete is, amelyet a mérnökök rajzszám, az anyagosok (NEM AZOK AZ ANYAGOSOK!) anyagszám alapján azonosítottak. Az adatbázis pedig tudta róla: dióda.

Igy aztán a vak is láthassa, hogy mindenki jól csinálja. Kivétel az adatbázis, akire a vízágyú és a neutronbomba megfelelő arányú keverékével kellene lőni.! :-D

:-) Saját hardveres sztori: 1U-s szerver, alaplapot kell benne cserélni, mert olyan hibája van, amit csak így tudnak megoldani. Oké, megbeszélt időpontban érkezik a garanciáls szerverhez a szerelő, hozza a gép sorozatszáma alapján bele való alaplapot. Egy CPU-slottal, miközben a gépben két CPU volt... Megnézte kétszer, rákérdezett telefonon: bizony valahol félrement a nyalvántartásuk, mert az adott sorozatszámú gép náluk egy cpu-val rendelkezett... Hát Pont nem jól tudták...

Egyszer régen egy kolléga elnyerte házon belül a "Backplane Reccsentő Kolléga (tm)" büszke címet.

Adott volt egy atomdrága, sok cpu (talán 64? már nem is emlékszem) befogadására alkalmas szerver, ami backplane + system board architektúrára épült: system boardonként cpu-k, memóriamodulok, és némi I/O interfész volt, és a backplane kötötte össze hatalmas sávszélességgel a system boardokat - egy system board telerakva 20-25 milla volt listaáron, egy értelmes induló konfiguráció 100+ millió (1-2 system boardnyi cpu sokkal kisebb és olcsóbb gépekbe is belefért). A szervízmérnök kolléga kint járt az ügyfélnél, és az egyik system boardot ki kellett szedni a gépből, hogy elvégezze a szükséges beavatkozást. Aztán amikor rakta volna vissza, valahogy sikerült félredugnia, és attól sem zavartatta magát, hogy kicsi akadva ment a helyére, illetve a végén teljesen elakadt: "ami nem megy könnyedén, azt oldjuk erővel" címszóval megpróbálta brute force-jelleggel helyretolni a system boardot. Eredmény: a backplane és a system board csatlakozója megsérült. A system boardot cserélte a cég zokszó nélkül (végülis a cpu meg a memória volt drága rajta, azt meg át lehetett menteni), a backplane viszont annyira tetves drága komponens a gépben (valami 15 milla körüli internal costra emlékszem - cca 20 évvel ezelőttről), hogy itt csak egy ígéretet kapott az ügyfél, hogy ha valaha televenné system boardokkal a gépet, akkor majd kicserélik, addig meg azt a slotot szépen üresen hagyja.

Szerkesztve: 2020. 12. 13., v – 12:08

Bár nagyon szereném ha lenne utódja a CentOS-nek, de nézzük csak:

- Sun

- MySQL

- OpenOffice

- ...

14 éve hasznosítják újra az RHEL forrásokat, ők erre építenek, nem holnap fogják abbahagyni. A mostani eset és a forkok pontosan megmutatták mennyi értelme lenne csak azért átcsábítani erre a vonalra júzereket, hogy aztán ők is pénzt kérjenek a binárisért. De van még idő, majd kiderül.

Ez a lista így nem konzekvens. 

Sun alatt nem tudom mi értesz, ha Solarist, hát az tényleg ment a levesbe. Sparc hát annak sem jósolnék nagy jövőt. 

MySQL valóban úgy tűnt, hogy vége és a jövő a MariaDB és semmi más. De tavaly minden előzetes nélkül csak kijött az Oracle a MySQL új verziójával, ami maradt továbbra is opensource és ingyenes (persze vásárolhatsz kereskedelmi licencet is pont mint korábban) és hát nem csak a verziószám ugrott. Egyértelműen MariaDB elé került képességekben a friss MySQL. 

OpenOffice, ja hát az ment az Apace szoftvertemetőbe. 

Sun alatt nem tudom mi értesz

Szerintem úgy en bloc mindent, amit a Sunnal vett az Oracle. A zöme a cuccoknak ment a levesbe, szinte válogatás nélkül. A Java, a MySQL, és a VirtualBox maradt meg kb. az egészből. És ezeknél is rendszeresen kiesik a szar a zsákból, mert mindig kitalálnak valamit, amivel rosszabb lehet a hírnevük a közösségben.

Hát aki önként használ bármit, ami elé Oracle van írva, az meg is érdemli. Ennél csak a Google Linuxot használnám szívesebben, ha lenne.

Senkinek nincs köze világod belsejéhez, neked sincs közöd mások életéhez, csak az Irgalom útján van közöd, Istenektől rendelt kötelességed.

1-2 projektnél használtam már. Valamint jelenleg számomra is ez tűnik majd alternatívának.

Az rendben van, hogy most bejelentettek egy pár forkot, de sajna ez kevés. 2029 még messze van, addig minimum ki kéne tartaniuk.

Valamint a meglévő CentOS 8 asokat se nehéz OL8-ra alalkitani.

Fedora 38, Thinkpad x280

már félve gondolok openJDK -ra azt is Red Hat Inc. "támogatja" - IBM -nek is van java JVM-e csak nehogy ötletet kapjon az ibm olló...

For Whites Only meeting room!

Azért az OpenJDK-t támogatja még pár más cég is, mint pl. Amazon, Azul (ez utóbbi egy JDK vendor, pár open-source cuccokban is aktív emberkével a vezetőségben).

Gyanítom, hogy ha az RedHat-os OpenJDK felé kacsintgatna az az olló, felállna az egész Java-s divízió és csinálna egy saját céget vagy tárt karokkal várnák őket jó pár más helyen.

Arról nem is beszélve, hogy az IBM J9-nevű cucca az OpenJDK-ba illeszkedő komponensként van fejlesztve... tehát anélkül kicsit nehezen áll meg a saját lábán.

Bár pont most néztünk meg egy öntökönlövést tőlük...

Most még mindenkinek nagy a szája, de mi lesz, amikor a redhat a stream-hez igazítja a forrás megosztását? Onnantól a forrásból készített disztribúció stream klón lesz, nem rhel. 

Mi az a forráskód, amit a RHEL-ből nem kell kiadnia a piroskalapos kék rózsának? A CentOS Stream-ból megy aforrás a RHEL-be majd a tervek szerint, legalábbis nekem úgy tűnik - azaz az Oracle-nek is "csak" annyit kell csinálnia, hogy a Stream forrásait szépen átnézi, teszteli(i), és ha megfelelőnek tartja, akkor kitolja a release-be. De akár javíthat/módosíthat is rajta - ahogy pl. kernelből sem a CentOS/RHEL kernlet adja. Mivel nekem jelenleg OracleDB futkorászik CentOS7-en, így ott nem kérdés, hogy vállalható-e az Oracle Linux - a RHEL-es DB-szerverek mást futtatnak (mondjuk ott is támogatott az Oracle Linux _is_), ott az a kérdés, hogy a RHEL7 életciklusának a végén merre megyünk tovább - szerencsére az még messze van :-) a platfom (x86-64) az viszont fix :-/

Mi az a forráskód, amit a RHEL-ből nem kell kiadnia a piroskalapos kék rózsának?

Minden, ami nem GPL alatt van. Például a *BSD licencelésű cuccok illetve a kereskedelmi licencelésű cuccok. A GPL-nél pedig nincs olyan megkötés, hogy ne lehessen megnehezíteni a kiadott forrás felhasználását, mint ahogy a RH ezt meg is tette, amíg át nem vette a CentOS-t.

A nagyszerű és fincsi *BSD licensz és a visszanyaló fagylalt esete, igen. A kereskedelmi licenszelésű (saját) motyók oké, kiperegnek. A GPL-es source felhasználhatóságának a nehezítése meg kétélű dolog egy Oracle-lel szemben: nagyon sok RHEL azért "van", mert Oracle fut rajta. És ezek alól olyan gyorsan kihúzhatja a support árazásával a szőnyeget az Oracle, hogy öröm nézni: elég egy competitive upgrade akciót tolni, vagy azt mondani, hogy az Oracle Linux-on futó Oracle RDBMS vagy más kiszolgálószoftver esetén az Oracle Linux suportdíja x USD/év (és itt x tetszőlegesen kicsi is lehet).

a redhat a stream-hez igazítja a forrás megosztását

Hát, amennyiben ezt úgy tudja csinálni, hogy közben a GPL-t is betartja, és a released RHEL binárisokhoz tartozó forráskód elérhető, akkor nem látom a problémát. Ha meg nem, akkor egy napon csöngetni fog a postás a keresetlevéllel. Meg persze lehet szopatni a közösséget apróbb szarságokkal is, csak utána nem kell meglepődni, ha ezt nem nyeli be a közösség.

Vagy ne adj' isten, lehetne debian/ubuntu-t hasznalni? Docker/kubernetes mellett meg mar kb. tokmindegy amugy is, hogy mi van alatta, ott tipikusan alpine vagy scratch az 'OS'.

Igen, valóban lehetne, csak nézd meg, hogy nagy gyártók fizetős termékei közül mi az, ami támogatott Buguntu-n futtatva. És onnantól kezdve, hogy a code alkalmazás/DB nem támogatott bubin/debilkén, máris el köll azon gondolkodni, hogy jó-e 2-3-n darab különböző OS-t üzemeltetni...

Na ja, csak epp ezert van a dozernek a mai napig komoly piaci reszesedese.

 

Ettol fuggetlenul, lehet debian/ubuntu host-on, es egy centos containerben futtatni a fizetos szart. Ez mar csak azert is fontos, mert ki tudja, mi van azokban a binaris blobokban.

 

Amugy meg hulyet kapok a "nagy gyartok fizetos termekei"-tol. Ez tipikusan egy szarul osszetakolt borzadaly, aminek csak a belovese es menedzselese kozel annyiba kerul, mint amennyiert egy custom megoldast fejlesztettek volna helyben, es akkor meg erre jon ra a licensz koltseg. Meg a $1000 / ora konzulensi dijak, hogy a szarjukat osszetakoljak elfogadhato szintre.

"Ez tipikusan egy szarul osszetakolt borzadaly, aminek csak a belovese es menedzselese kozel annyiba kerul, mint amennyiert egy custom megoldast fejlesztettek volna helyben," - Azért megnéznék egy helyben fejlesztett OracleDB-t, Siebel-t, vagy épp SAP-t - ez utóbbit DB-ve, tok-vonó...

A milliónyiból említs kérlek 3-4 olyat, ami legalább azt tudja management és fejlesztői szempontból, mint egy Oracle, ide értve a rendelkezésre álló menedzsment, monitoring illetve fejlesztői eszközkészletet. (És nem MSSQL)

Én sz@rul összetákoltat eddig még jellemzően mindenféle webes szutyokban láttam, bár néhány hossszú-hosszú évek óta fejlesztett vastagkliens app is igen előkelő helyet foglal el a tákolmányok és egyéb foskupacok listájában...

Ha nem haragszol, kicsit kiegészíteném a kissé hiányos ismereteidet. ;)

Amikor még volt Sun, akkor a "nagy adatbázisversenyeket" ketten vívták: Sun+Oracle és IBM+DB2.

Aztán már az IBM vívta önmagával, méghozzá feleannyi core felhasználása mellett. Ekkor az Oracle úgy állt bosszút, hogy bevezette a per core licencelést. Kivétel az IBM, mert ha valaki POWER-en futtatott Oracle-t, az kétszer annyit fizethetett magonként. :-D

A Sybase 96-ban még biztosan jó volt. Ha beletenyerelt az SAP, akkor nem is tudom.

Ha jól emlékszem a szükséges Oracle  licenszek számának megállapításához a cpu magok számát kellett egy architektúrára megállapított számmal megszorozni.

Ez a szám Sparc T processzorok esetén 0,75  IBM power cpu-k esetén 1,5 vagy 2 volt.

es egy centos containerben futtatni a fizetos szart

2020-at írunk (még egy rövid ideig), és bizony ott tartunk, hogy már nem a kuncsaft az, aki ezt a containeresdit maga csinálja, hanem a vendor az. Az olyan behemót állatok, mint az IBM, már tolja ki magából a klasszikusnak számító alkalmazásainak a containerizált változatát. Ergó nem a kuncsaft problémája, hogy milyen oprendszer lesz a containerben, mert azt majd a vendor kitalálja - neki kell a saját szarjait támogatni úgyis.

(Azt nem mondom, hogy ettől ezek az akalmazások sokkal jobbak lesznek, de rosszabbak se nagyon.)

Akkor most jöhetne vissza a Scientific Linux. :)

Letoltottem mert egyébként is szembejött, itt ott feldobta a Google. Az Oracle download rendszer a regisztrációval egy kalap f0s, az meginkabb zavaró hogy yum.oracle.com címen simán letoltheto reg és installer nélkül. 

8.3 el sem indul virtualbox alatt (log-ban cpu error van, ami nem az i686 vs x64 szokásos dolog, inkább valami bug), de 8.2 igen.

Es tetszik is, hasonló a centos - hez, szerintem utódja lesz nálam. Mondjuk az vicces hogy a postgres elég régi verzióját tartalmazza a repo és nincs nagy hype hogy azt telepítsd.

a postgres elég régi verzióját tartalmazza a repo

Háttööö... figyelj, ez nem bug, hanem feature :D Az _egész_ RHEL/Centos arról szól, hogy elég régi verziókat tartalmaz a repó, de a felhasználók nem ennek ellenére, hanem pontosan ezért használják.

A hozzászólásokból valahogyan olyan érzületem támadt, mint amikor megszűnt a Windows XP. ;)

Szerkesztve: 2020. 12. 19., szo – 06:57

Off: nem sokat értek az egészből, de abban szívből reménykedem, hogy a systemd (meg a többi anti-unix csoda) nem látja ennek kárát.

Szerintem ebben a döntésben része lehet annak is, hogy az Oracle gyakorlatilag lenyúlja a RHEL-ot és kiad egy saját Enterprise Linuxot, aminél garantálja a RHEL bináris kompatibilitást, úgy, hogy szinte semmit nem tesz érte. Ezt azért teheti meg, mert a RedHat mindent idejében és megfelelő minőségben kipakol forrásként.

Ha a CentOS ezt már nem követeli meg, mivel más release modellre vált, lehet már a RedHat sem fogja olyan egyszerűen felhasználható módon kiadni a forrásait, tehát az Oracle sem fog tudni a RHEL tökéletesen megeggyező klónt kiadni.

Ha tényleg az a megfontolás van a dolgok hátterében, akkor ez a lépés nem csak a CentOS RHEL kompatibilitását szünteti meg, hanem az összes többi klónét is, beleértve az Oracle Linuxot.

"Oracle gyakorlatilag lenyúlja a RHEL-ot" - újrabuildeli, miután kiganézott belőle minden RedHat-only cuccot (ahogy a CentOS is készült eddig), kiganézta belőle a rehel-es kernelt (és kapcsolódó dolgokat), és belerakta a saját kernelét (és kapcsolódó motyókat).

A RedHat elvileg keresztbe tudna tenni az Oracle-nek, igen, viszont ne felejtsd el, hogy nagyon sok RHEL-en Oracle termékek futnak, nagyon sok RHEL-en RDBMS-ek futnak, amikre az Oracle simán mondhatja, hogy competitive upgrade keretében válts Oracle Linuxra, és onnantól kezdve a rajta futó Oracle termék licenszdíjával az alatta futó OS támogatását is megkapod. Vagy ha ez túl meredek,a kkor max. azt mondja, hogy az Oracle termékek alá rakott OracleLinux támogatása x USD, ahol x<<RHEL support költsége. És ezt a RedHat is nagyon jól tudja...

2014-ig a CentOS-nek semmi köze nem volt az RH-hoz. A pár fős független CentOS csapat 2004, az Oracle 2006 óta fordítja újra az RHEL forrásokat. Ha RH változtatni akarna a forráskódok kiadásán akkor ezt 2003 óta bármikor megtehette volna. Miért pont most tenné, 16 év "kód lenyúlás" után?

"ez nem járja" - mármint micsoda? Hogy a GPL alatt kiadott forrásból valaki buildel egy, RHEL jogokat nem sértő (RHEL-only contettől mentes) disztribet? Írtam már: Megtehetné az IBM, hogy keresztbetesz az Oracle-nek, de tótzicsi, hogy egy ilyen lépés után a RHEL-t ott csinálná ki az Oracle, ahol csak tudja. És elég sok Oracle ügyfél van, akinél _még_ van RHEL is. De egy jó ajánlattal, pláne, hogy indulásként bináris kompatibilitást kap, szerintem szemmel látható mértékű ügyfelet vesztenének piroskalapék...

Itt azt írja, az RH vezetőségnek a kezdetek óta nem tetszik a CentOS létezése, azt meg hogy a CentOS legyen inkább RHEL upstream 2014-ben találta ki egy olyan csávó aki azóta már a Microsoftnál dolgozik. RH szerint a forrásból újrafordított bináris az sosem volt RHEL csak egy másodosztályú másolat. És felsorol a cikkben egy rakás multit akik ahelyett hogy megvennék az RHEL-t, inkább ingyen használják az újfordított vackot ingyen mert rosszul hiszik, hogy az ugyanaz.

Tehát sírt a sales a vezetőségnek, hogy nem tudják eladni a Disneynek meg a Toyotának az RHEL-t mert azok elvannak a CentOS-el és erre nem a töketlen salest fejlesztették tovább vagy építették le, hanem a CentOS-t ölték meg. Az jövő év végig kiderül, hogy mi lesz akkor ha ezek a multik inkább az Oracle scriptjét futtatják le ahelyett, hogy rohannának RHEL-t venni.

Na de végül is mit tudnának variálni a forráskódokkal? Azt ki kell adniuk. A pont kiadásokat eddig is csak a megjelenés napján adták ki (sőt a stream miatt ezután már hamarabb is lesz kód), a frissített csomagok forrását is ki kell adniuk.

Itt a lényeg: "Oracle buys Sun: Solaris Unix, Sun servers/workstation, and MySQL went to /dev/null. IBM buys Red Hat: CentOS is going to >/dev/null. Note to self: If a big vendor such as Oracle, IBM, MS, and others buys your fav software, start the migration procedure ASAP."

Jó, de az alapvető kérdés fölött mindenki elsiklik: a Red Hatnek mi köze van a CentOS-hez? Az oké, hogy neki ez az egész semmilyen hasznos dolgot nem jelent - dehát nem is azért hozták létre az alapítói, hogy a Red Hatnek jó legyen! Hanem azért, hogy a felhasználóknak jó legyen. Szóval mit pofázik bele a RedHat az egészbe?

Én úgy látom, hogy kétféle cég van: akinek KELL a support, és aki ingyen akarja megoldani. Minden főnökömnél bepróbálkoztam eddig, hogy mi lenne, ha a dev/test/játszós szerverekre CentOS-t tennék, és a prodra menne a Red Hat. Minden alkalommal leállítottak, hogy ez a céges policy, ha Linux, akkor Red Hat.

Amelyik cég eddig is jól elvolt support nélküli CentOS-al, az vagy használja továbbra is, vagy keres egy forkot, vagy Oracle Linuxra vált, és akkor nem kell újra tanulni semmit. De a Fedorát nem tudom elképzelni szerver OS-nek, na nem a stabilitása miatt, hanem semmi kedvem fél, max évente disztrót upgradelni.

Az egyik általam üzemeltetett (nem céges) szerver CentOS 8, fél éve ugrottam fel CentOS 6-ról, tökre örültem, hogy 9 évig nem kell vele foglalkoznom, szóval kíváncsian várom, hogy mi fog kisülni belőle. Van vagy 7-8 év Oracle Linux tapasztalatom, nekem nincs vele semmi bajom, számomra az OEL az egyik befutó, ha lépni kell. De ha nem csesznek el semmit, akkor maradok, nem izgat, hogy már nem lesz Red Hat klón.