Oracle, SUSE en CIQ beginnen Open Enterprise Linux Association na RHEL-paywall

Oracle, SUSE en CIQ, het team achter Rocky Linux, starten samen de Open Enterprise Linux Association. De drie bedrijven gaan met OpenELA gezamenlijk 'de ontwikkeling van RHEL-compatibele Linux-distro's aanmoedigen' door broncode aan te bieden.

Oracle, SUSE en CIQ kondigen hun samenwerking aan in een persbericht. OpenELA wordt volgens de drie deelnemers een samenwerkingsverband om de ontwikkeling van Linux-distributies die compatibel zijn met Red Hat Enterprise Linux 'aan te moedigen'. De drie bedrijven gaan daarom open en vrije Enterprise Linux-broncode beschikbaar stellen.

OpenELA gaat later dit jaar de sources leveren 'die nodig zijn voor het bestaan van downstreams die compatibel zijn met RHEL'. De stichting richt zich in eerste instantie op RHEL-versie 8, 9 en mogelijk 7. De materialen komen vrij beschikbaar en mogen door iedereen geherdistribueerd worden. De drie bedrijven nodigen andere organisaties en leden uit de Linux-community uit om zich bij OpenELA te voegen.

De oprichting van OpenELA komt voort uit 'de recente wijzigingen van Red Hat aan de beschikbaarheid van RHEL broncode', schrijft OpenELA. "In reactie hierop werken CIQ, Oracle en SUSE samen om broncode, tools en systemen via OpenELA aan te bieden aan de gemeenschap." Alle deelnemers blijven daarnaast werken aan hun eigen Linux-distributies.

Red Hat zei in juni dat de RHEL-broncode niet meer algemeen openbaar beschikbaar komt, maar alleen nog aanbiedt aan Red Hat Enterprise-klanten. Daarmee is CentOS Stream, de ontwikkelbranche van RHEL, nog de enige publiek beschikbare repository waar de broncode wordt gepubliceerd. Dat maakt het moeilijker voor andere partijen om RHEL-compatibele distro's te ontwikkelen en onderhouden.

Verschillende alternatieve Linux-distributies maken gebruik van RHEL, waaronder Rocky Linux van OpenELA-deelnemer CIQ. Hoewel distro-ontwikkelaars de broncode nog kunnen bemachtigen met een Red Hat-licentie, wordt herdistributie onder die licentie beperkt. Het team achter Rocky Linux zei eerder dat het de wijziging waarschijnlijk geen grote gevolgen voor de distro gaat hebben, omdat het team de broncode via andere methodes kan verkrijgen. Oracle leverde in juni kritiek op de wijzigingen van Red Hat. SUSE zei vorige maand dat het een eigen RHEL-fork gaat onderhouden en vrij beschikbaar gaat stellen.

Bron: SUSE

Reacties (71)

[xilanaz]

Oracle en CiQ begrijp ik, hebben immers distro's gebaseerd op redhat maar ik kan niet helemaal de reden van Suse plaatsen. Ze hebben niets wat gebaseerd is op redhat voor zover ik weet en of ze dit nu echt in de markt brengt voor service en support op redhat gebaseerde distro's betwijfel ik.

(Zelf tumbleweed user)

[4tro]

Veel van de basis van Suse is gebaseerd op oudere Red Hat Linux versies, pre RHEL,

Zie het lijntje van Red Hat naar suse helemaal in het begin hier https://upload.wikimedia....Distribution_Timeline.svg

Dat is onder andere de rpm package manager, maar ook een enorm deel van hoe en waar packages hun config enzo neerzetten. Dat maakt dat suse een redelijke red Hat feel heeft under the hood.

Zelf vertrouw ik de motieven van Oracle niet in deze. Ze leechen al jaren van RHEL via Oracle Enterprise Linux, en geven niks, nakkes, nadat terug. Sterker, het online kernel patchen van ksplice hebben ze opgekocht en er een Oracle exclusive van gemaakt destijds.

[Reactie gewijzigd door 4tro op 22 juli 2024 23:47]

[TheekAzzaBreek]

Zelf vertrouw ik de motieven van Oracle niet in deze. Ze leechen al jaren van RHEL via Oracle Enterprise Linux, en geven niks, nakkes, nadat terug. Sterker, het online kernel patchen van ksplice hebben ze opgekocht en er een Oracle exclusive van gemaakt destijds.

Dat Oracle niets teruggeeft is gewoon niet waar. btrfs en XFS online repair zijn voorbeelden. Dat ze minder teruggeven dan ze nemen zou kunnen, maar je overdrijft.

Wat overigens niet betekent dat ik de motieven van Oracle wel vertrouw,

[dmantione]

Chris Mason, de ontwerper van BTRFS werkte oorspronkelijk bij SuSE, tegenwoordig Oracle. Je kunt zeggen dat de cirkel hiermee weer rond is.

[dmantione]

Ik denk dat de reden dat SuSE zeer compatibel is met Red Hat veel meer te maken heeft met commerciële software, dan met de oorsprong (en SuSE begon ooit als fork van Slackware). Omdat Red Hat in de bedrijfswereld veel meer gebruikt wordt dan SuSE Linux Enterprise, is Red Hat Linux de standaard wat veel commerciële pakketten ondersteunen. Ook SuSE ondersteunen is voor de betreffende leveranciers alleen een optie als het niet teveel werk is.

Resultaat is dat SuSE zeer compatibel is met Red Hat, vaak compatibeler dan Red Hat zelf: Het is geen automatisme dat een rpm voor Red Hat 7 gecompileerd ook installeert op Red Hat 8. SuSE lust doorgaans rpms ongeacht de Red Hat-versie waar ze voor gemaakt zijn, geen probleem.

Helaas heeft het ook tot gevolg gehad dat SuSE veel eigen ontwikkelingen heeft moeten afzweren. SuSE had ooit zijn eigen hotplugsysteem, tegenwoordig gebruikt het udev en systemd net als de rest. SuSE had ooit zijn eigen ramdisk-bouwsysteem, nu Dracut net als bij Red Hat. EVMS?? Red Hat wilde LVM, dus exit EVMS bij SuSE en LVM erin. En zo verder.

[kozue]

Ach, al die distros met hun eigen incompatible subsystemen wordt je ook niet blij van. Dat levert alleen versplintering op. Dat heeft niet zo veel met invloed van Red Hat te maken maar met standaardisatie. Bij Ubuntu zie je exact hetzelfde. Grote ambitieuze projecten als Upstart, Mir en Unity hebben allemaal het veld moeten ruimen voor alternatieven die door de rest van de linux gemeenschap omarmd werden. En daar was iedereen blij mee, behalve wellicht Canonical zelf, die graag hun stempel op de ontwikkeling van Linux had gedrukt. Nu Snap nog weg en dan ben ik ook weer blij (wat een flut systeem zeg).

[zordaz]

Wat veel mensen niet weten is dat Upstart nog steeds gebruikt wordt in Android en ChromeOS.

[kozue]

Dat wist ik inderdaad niet, en verbaast me eigenlijk wel. Upstart is al sinds 2014 EOL en in 2023 nog vertrouwen op een project wat al 9 jaar dood is lijkt me niet zo handig. Of heeft Google plannen om het na al die tijd nog over te nemen?

[zordaz]

Ik kan mijn oorspronkelijke bronnen helaas niet meer terugvinden. Mogelijk zijn ze inmiddels toch overgestapt naar iets anders.

[Reactie gewijzigd door zordaz op 22 juli 2024 23:47]

[kozue]

Ik had het van tevoren na gezocht (ik neem niet blind zomaar iets aan uit een comment), maar het staat ook op wikipedia. Maar dat kan ook verouderd zijn. Ik heb geen Android apparaten om het zelf te verifiëren…

[MainframeX]

Mwa, het is opensource he. Je kan er redelijkerwijs wel vanuit gaan dat als men een kopie van de broncode gebruikt in Android dat deze ook wel door de Android/Google maintainers onderhouden wordt zodra er iets stuk gaat of een veiligheidslek is. Als een bedrijf maar enige competentie en/of schaal heeft is een upstream niet hoofdzakelijk nodig.

[goarilla]

Ook in veel embedded systemen zie je vaak upstart. Of het nu ondersteund wordt of niet maar
sommige van die systemen zitten nog op 2.6.x kernels of slik 2.2.x en 2.4.x kernels.

[bossanova]

Zelf vertrouw ik de motieven van Oracle niet in deze. Ze leechen al jaren van RHEL via Oracle Enterprise Linux, en geven niks, nakkes, nadat terug. Sterker, het online kernel patchen van ksplice hebben ze opgekocht en er een Oracle exclusive van gemaakt destijds.

De stap van Oracle in 2009 om Sun op te kopen was puur uit zelfbehoud. Sinds het bestaan van de commerciele RHEL is er al een overlevingsstrijd gaande tussen Oracle en Red Hat die enkele produkten hebben die met elkaar concurreren. Het opkopen van KSplice was ook zo'n overlevingsstrategie.

Oracle is voor zijn inkomsten logischerwijs nog steeds erg afhankelijk van zijn databaseprodukten en in de werkelijkheid draaien die alleen op Linux. Door het overnemen van de RHEL kernel en het finetunen daarvan in Oracle Enterprise Linux, de opkoop van SUN produkten en het opkopen van BEA Systems (WebLogic), is het bedrijf heer en meester op de database markt en die databases zijn nou eenmaal de belangrijkste entiteit in het hele IT-universum. Zonder een database heeft de meeste IT gewoon geen toepassing. Oracle maakt daardoor al decennia meer omzet dan Microsoft en het bevreemd mij dat zij nooit bij The Big Five worden gerekend (Microsoft, Apple, Google, Amazon, Meta).

Zoals gezegd was de opkoop van KSplice gewoon overlevingsstrategie omdat bij kritieke bedrijfssystemen zo'n concept leidend kan gaan worden in marktaandeel en Oracle dan haar leidende positie kwijt zou raken. Alles staat bij Oracle in dienst van haar cash cow, de database en ook Oracle Enterprise Linux is daar onderdeel van. De licentiekosten voor OEL zijn daardoor vele malen lager dan die voor RHEL.

Red Hat heeft dan weer haar Satellite systeem dat meer OS-focussed is. Red Hat blijft daarmee een 'OS-boer' en Oracle een 'database-boer' maar op de raakvlakken kiezen de bedrijven de voor hun belangrijkste produkten, juiste of markttechnisch gezien prevalente onderdelen.

[shades]

omg - dit is iets wat ik echt nooit heb geweten. Eerste gedachte is "Wat een bende - dat het uberhaupt nog redekijk met elkaar compatible is.."

[Ozymandias]

Vroeger was de scheidslijn simpel. Unix was er voor de grote bedrijven en Linux voor de kleinere bedrijven en de hobbyist. Microsoft even buiten beschouwing gelaten, ik heb zelf nog eens gehoord dat iemand de lachers op zijn hand kreeg door tijdens een Microsoft presentatie op de HCC-dagen van 1997 het waagde te suggereren dat Linux een alternatief zou kunnen zijn voor Windows NT. Nu Linux ook op enterprise niveau belangrijk is geworden zie je dat de grote Linuxbedrijven dezelfde trekjes beginnen te vertonen als de oude Unix vendors van weleer en alles zoveel mogelijk dicht proberen te timmeren, precies de reden waarom Richard Stallman en Linus Torvalds destijds zoveel succes oogstten met hun hobbyprojectjes. Dat Oracle zich nu opwerpt als kampioen van een open Linux zou je me nog geen tien jaar geleden niet wijs hebben kunnen maken. Het blijft boeiend, die IT wereld.

[goarilla]

Het blijft boeiend, die IT wereld.

Boeiend ... dan heb Ik boeiend fatigue. De hoeveelheid drama voor drama's sake is
echt belachelijk. De keuzes die bedrijven en communities om de haverklap maken,
waardoor iedereen dowstream weer mag scrambelen, springen, investeren, upskillen
is uitputtend.

[Ozymandias]

Ik werk niet meer in de IT. Misschien is dat maar beter dan, ik ben ook een stukje ouder geworden.

[beerse]

Vroeger was de scheidslijn ook niet simpel. In de jaren '90 had je tussen de commerciële unix varianten ook al meerdere stromingen. Zoals bijvoorbeeld unix-system-V en BSD en posix en dergelijke die overigens ook aardig door elkaar heen liepen. Volgens mij is Sun ooit met SunOS tussen versie 4 en 5 gewisseld van of naar BSD. In die tijd was ik actief op HP-UX, SunOS, Solaris, en Vax-Ultrix (de unix naast Vax-VMS). Om dat allemaal bij elkaar te krijgen werd gretig gebruik gemaakt van de gnu toolset.

De voornaamste reden om de gnu toolset te gebruiken is omdat het voor al deze systemen beschikbaar was en binnen de gnu set source-compatibel. En die zelfde toolset is vanaf het begin ook gebruikt om met de linux kernel een gnu-linux systeem op te zetten.

Naar mijn idee is gnu-linux ook/mede groot geworden in de enterprise omgeving omdat gnu dat ook al was op de andere unix kernels. En omdat de linux kernel al heel snel ook beschikbaar was op zo ongeveer alle toen beschikbare hardware.

Vanuit de gnu-wereld gezien is de linux kernel gewoon op het beste moment boven komen drijven. De gnu-wereld had de basis tools al lang afgedekt en ze waren ook daar bezig met een kernel (namen als 'hurd' en 'amuba' komen boven drijven).

[JeroenED]

Suse gebruikt RPM packages. Ze zijn dus daardoor ook "gepakt" door Red Hat. Mochten ze dit niet doen moeten ze hun eigen RPM fork maken wat compatibiliteit niet ten goede zal komen. Weet niet hoe het momenteel zit met RHEL packages op Suse, maar de zet van red hat maakt het in ieder geval niet properder.

[ichnaton]

Nee, het rpm packageformaat op zich doet het niet. De package manager yast2 van suse is al decennia van veel hoger niveau dan de pogingen van red hat. Maar het ding is wel monolithisch, hij ramt alle configs er telkens weer door. Grundlich.

Zoals anderen al aangaven gaat het om de keuzes voor pakketten en dan, waar zet je de config, en die info staat in de srpm's ofwel de source rpm's. Daar gaat het allemaal over

[Verwijderd]

Oké..ik ben misschien te lang weg geweest uit Linux land maar wat betekent precies met RHEL compatibel? Ik dacht dat alle distros compatibel met elkaar. Als voorbeeld, vroeger gebruikte ik nog apt en rpm naast elkaar op suse linux, gewoon omdat het kan.

[satya]

Compatibel als in dat de code 100% hetzelfde is, alleen ontdaan van alle RH kenmerken. Een gewitte distributie noemen ze het ook wel eens. Rocky heeft wel een paar eigen optimalisaties, net als Oracle waardoor hun databes op zo'n systeem meteen als een speer gaat.

rpm kan misschien nog gebruikt worden maar werd eerst Yum en inmiddels dnf.

[sspiff]

dnf en yum gebruiken onderhuids nog gewoon rpm. Ze bieden er gewoon een laag bovenop.

[satya]

Klopt, in de meeste gevallen heeft Yum een alias naar dnf op nieuwere distros of versies.

[oktoberpaard]

Ik denk niet dat het een 100% kloon gaat worden, want dat is juist waar RHEL onlangs een stokje voor gestoken heeft. Compatible betekent in ieder geval dat software gebouwd en verpakt voor RHEL ook zonder aanpassingen op dit systeem kan worden geïnstalleerd en dat dit systeem zoveel mogelijk gelijk is en zich gelijk gedraagt aan RHEL. Ze zullen daarbij denk ik onder andere CentOS Stream volgen, maar ze kunnen geen patches die uniek zijn voor RHEL een op een overnemen uit de RHEL broncode. Ik denk dus dat ze het niet als doel stellen een bug voor bug kloon te zijn.

[satya]

Rocky is juist ontstaan omdat gebruikers niet met de Stream versie van CentOS te maken willen hebben, maar een betrouwbare versie willen draaien in productie en daarmee RHEL 8, 9 etc volgen.

De binaries zijn 100% compatible met RHEL, net als bij Oracle Linux, maar die gooit zijn eigen tuning over het OS heen tbv performance.

[oktoberpaard]

Dat klopt inderdaad, maar ik neem aan dat je het nieuws hebt gevolgd rondom de broncode van RHEL. AlmaLinux heeft in eerste instantie aangegeven een RHEL kloon te gaan reconstrueren met behulp van onder andere CentOS Stream (waarbij ze de software versies van RHEL aanhouden), omdat ze de RHEL-specifieke patches niet meer mogen herdistribueren volgens de nieuwe voorwaarden. Uiteindelijk hebben ze besloten het doel van een bug-for-bug kloon volledig te laten varen en in plaats daarvan een binary compatible OS te maken.

Rocky Linux, daarentegen, heeft in eerste instantie aangegeven andere methodes te gebruiken (zoals de cloud image) om aan de RHEL broncode te komen en daarmee dus de nieuwe voorwaarden van RHEL te omzeilen. Ik geloof er nooit in dat Oracle en SUSE daaraan mee gaan doen. Ik denk daarom dat ze gaan voor een 100% binary compatible clone, net als AlmaLinux, maar dan met meer gewicht erachter. Daarmee laten ze het doel een bug-for-bug kloon te maken varen. Ze hopen natuurlijk dat het de gouden standaard wordt in plaats van RHEL, wat ik toe zou juichen.

[Frame164]

Was het maar zo mooi. Veel apps zullen best wel werken op meerdere distributies, maar zodra het iets specialistischer wordt dan is dat niet gegarandeerd. Om die reden leverden wij op het werk de software alleen compleet met OS zodat we zeker weten dat het werkt. Met containers is het iets beter geworden maar je moet nog altijd testen op ieder platform wat klanten willen gebruiken.

[rob12424]

Niet helemaal. Ik denk dat je in de war bent met de Linux standard base.

https://en.m.wikipedia.org/wiki/Linux_Standard_Base

[Verwijderd]

Nee… niet helemaal. Het gaat mij om de term “RHEL compatibel”. In mijn ervaring, kun je vrijwel alle programma’s compileren op elke distro. Ene distro hebben misschien meer workaround nodig dan de ander maar in de basis vrijwel alles is te compileren op elke distro. Het is niet zo dat bijv. glibc is enkel te compileren op RHEL systemen dus daarom snap ik niet precies wat wordt bedoeld met RHEL compatibel. Maar zoals @satya hierboven heeft uitgelegd, daar kan ik mij iets bij voorstellen.

[rob12424]

Ja en nee, Rhel compatibel was vroeger gewoon RPM compatibel.

Tegenwoordig ondersteunt bijvoorbeeld RPM wel . Deb pakketten.

Je kunt pakketen dus omzetten met bijvoorbeeld alien.

https://wiki.debian.org/Alien

Dat bestond al voor de LSB. Maar was toen een ramp en werkte vaak niet. Er was amper compatibiliteit.

Besef dat een RPM pakket vaak dingen bevat die anders zijn bij de ene distro en weer anders bij de andere distro.

De LSB werkte goed in veel dingen totdat de ene distro bijvoorbeeld upstart ging gebruiken de ander nog bij init zat en weer een ander wat anders gebruikte.

Een mooi voorbeeld heden ten dage is bijvoorbeeld Alsa op de ene distro, pulse audio op de ander en pipewire wat er door Red hat nu doorheen wordt gedrukt met alle ruzies van dien.

Veel dingen zijn dan wel compatibel maar als Suse bij pulse audio blijft en redhat Pipewire neemt hang je al. Net als dat Ubuntu destijds geen Wayland wilde en zijn eigen grafische omgeving ging maken.

En bijvoorbeeld Linux Mint en Arch Mate hadden en de rest Gnome 3 met Gnome shell.

Al die verwijzingen en dingen staan dus in .RpM pakketten in veel gevallen.

[oktoberpaard]

Compatible betekent hier dat je geen workarounds nodig zal hebben en niet opnieuw hoeft te compileren of een nieuwe rpm hoeft te bouwen. Ik vermoed dat het geen een op een kloon gaat worden zoals Rocky dat wel (ongeveer) was, gezien de regels voor het gebruik van de RHEL broncode zijn veranderd. Dat is nou juist de hele reden dat dit wordt opgezet.

[HollowGamer]

Gaat SUSE dan nu (weer) stoppen met hun eigen fork?

Verder kan ik het als gebruiker niet zo meer volgen. Bij wie moet ik straks een bug melden? Snap bij de distro, maar wat als het upstream is?

[Frame164]

Lijkt me niet dat ze stoppen met hun eigen fork. Daar zullen een hoop klanten niet blij van worden.

[dmantione]

SLES en OpenSuSE gaan nergens heen, dat zijn degelijke systemen en op veel punten beter dan Red Hat/Fedora.

Red Hat is in de bedrijfswereld evenwel populair en SuSE verdient veel van zijn centen niet met het maken van distributies, maar met servicecontracten aan grote bedrijven. Ook SuSE zit met het probleem dat er nu geen CentOS meer is waar op teruggevallen kan worden als Red Hat nodig is. In dat licht moet je dit zien.

[i-chat]

Geniaal dat oracle hierbij zit die zijn in het verleden niet bepaald vies gebleken van dickmoves in linux land de weigering om openoffice aan de community terug te geven na hun aankoop van sun was zeker geen schone zet

Maar goed 2 wrongs dont make a right laten we maar zeggen

[Teun!]

Inderdaad. Ik zal ze niet vertrouwen om "te vechten voor opensource freedom". Laat ze eerst ZFS maar eens GPL-en dan. Naast openoffice inderdaad. Voor mijn gevoel is dit puur om mensen over te laten stappen naar Oracle Linux.
De open letter van Oracle was wel echt hilarisch, kon mijn lachen niet inhouden.

[divvid]

OpenOffice is min of meet dood. Ik echt niemand die dat nog wil aanraken ipv LibreOffice. Voor ZFS is het andere koek, maar geef het een jaartje en er is een OSS alternatief

[Teun!]

Ik zou beargumenteren dat dat juist door Oracle komt. En ik neem dat je met een jaartje een andere office variant bedoeld, niet een ZFS competitor. Tenminste, dat zie ik niet gebeuren op zon korte termijn.

[mba13188]

Dat OSS alternatief van ZFS is er al zo'n 10 jaar, zie https://en.wikipedia.org/wiki/OpenZFS

[anvil]

Dat is geen alternatief, maar een fork
En dankzij de CDDL license is het een gedoe het in een distro mee te verpakken, wat voor bredere adoptie nodig is.

[GekkePrutser]

No problem als je BSD gebruikt GPL is niet het enige onder de zon.

[anvil]

Maar Linux is wel vrij dominant in de server en HPC markt tov BSD.

[GekkePrutser]

Ja maar who cares. Het werkt beiden uitstekend. Als ZFS echt een productie ding moet wezen dan zou ik zeker BSD pakken.

[anvil]

Jaren tevreden ZFS+BeeGFS als HPC storage gedraaid , zonder enig issue in productie. Alleen de setup had zoveel eenvoudiger gekund...

[niqck]

Je praat alsof de CDDL license het probleem is. Misschien is GPL wel het probleem. Zo'n beetje: jouw licentie is niet compatibel met de onze en dat is jouw fout.

[anvil]

Hetzelfde is in het verleden door Oracle ook reeds gedaan met GlassFish en Netbeans ... dat dat gebeurd is zegt al genoeg over de issues rondom CDDL in het huidige software landschap.

[niqck]

Zowel ZFS, NetBeans als Glassfish waren SUN Microsystems producten al van voor de overname door Oracle. SUN had zijn eigen licentie (CDDL) die ze voor Open Source producten toepaste. CDDL is een 'zwakke' copyleft licentie terwijl GPL een sterke copyleft licentie is. Volgens sommigen is deze incompatible met GPL, volgens anderen dan weer niet... feit blijft dat door deze twijfel er voorzichtig mee omgesprongen wordt.

Jij denkt er misschien anders over maar ik ben er nog altijd van overtuigd dat de ontwikkelaar zijn eigen licentie mag kiezen. De weinige dingen die ik ontwikkeld heb (stelt weinig voor want ik ben geen ontwikkelaar) waren onder de BSD licentie (als in, trek er uw plan mee, doe er mee wat je wil). Dat was MIJN keuze en geen enkele OSS zealot zou me ooit kunnen overtuigen dat ik voor GPL moet kiezen.

Je zegt dat er issues zijn rondom CDDL in het 'huidige' software landschap waarmee je natuurlijk bedoelt het GPL landschap dat misschien door zijn/haar keuzes die problemen creeert. Jij beschouwt GPL als het hoogste goed... ik niet...

[anvil]

Ik beschouw GPL niet als het hoogste goed maar in de omgevingen waar ik werk en heb gewerkt (enkel Linux, geen BSD) wel de standaard.

Natuurlijk mag een ontwikkelaar zijn eigen licentie kiezen, dat bestrijd ik ook nergens. Alleen is de CDDL wel een aparte (wat verouderde) licentie die met de nodige beperkingen komt. Feit is dat sinds het opstellen van de CDDL er het nodige veranderd is. Bij GPL zie je daarom ook dat tegenwoordig steeds meer geen GPL 2 maar GPL 3 is, mede omdat het software landschap en de business er om heen ook verandert.

Ik stel enkel dat de huidige CDDL licentie een bredere adoptatie van ZFS nogal in de weg staat en dat , zeker nu Oracle samen met Suse en CIQ een pact gesloten heeft voor een Open Enterprise Linux standaard , het mooi zou zijn als ze daar een serieus stukje commitment tonen door bijvoorbeeld de licentie van ZFS aan te passen naar iets wat compatible is met GPL om zo die bredere adoptatie te bewerkstelligen. Want er is op dit moment geen enkel ander filesystem wat in de buurt komt van de features en tegelijk stabiliteit van wat ZFS biedt.

[niqck]

Je moet ZFS zeker niet aan mij proberen te verkopen, draai het al jaren op FreeNAS/TrueNAS en had voordien heel veel ervaring vanuit mijn SUN-dagen.
Bij BSD is er blijkbaar geen probleem met de CDDL licentie hoewel ik dacht dat zelfs TrueNAS core (BSD versie) ook overgeschakeld is op of minstens plant om over te schakelen op OpenZFS.

Zelf ben ik niet echt een fan van GPL. Je creeert een licentie die heel beperkend kan zijn en gaat dat klagen dat die beperkingen incompatible zijn met software van een andere licentie. En de fout ligt dan bij hen... En alles wat GPL/OSS is is goed maar closed software is evil. Sorry, jaren ervaring met Solaris (van SunOS 4 tot Solaris 11) gehad en er zijn nog steeds veel dingen waar Linux en consoorten iets van zouden kunnen leren... maar closed software is slecht en daar zijn zeker geen goede ideeen te vinden. 1 van de mooiste voorbeelden zat in SunSSH. Daar had je de mogelijkheid om te zien welke de originating user was die ingelogd was. Deze user werd doorgegeven aan de server waarop je inlogde. Dus als user alice op server A een ssh deed als user bob op server B wist je op server B dat de user op A alice was. SUN heeft deze code bij mijn weten terug gegeven aan OpenSSH (daarop was SunSSH gebaseerd) maar deze code werd nooit opgenomen (want vermoedelijk was het voor Theo, komende van een commercieel bedrijf, puur evil).

Ik hoop maar betwijfel echter dat Oracle ook maar 1 euro geeft om de OSS gemeenschap. Bij Oracle draait het om 1 ding: zoveel mogelijk geld persen uit hun klanten. Ik heb ooit gehoord dat intern bij Oracle de grap ging over de functie van de CFO: berekenen hoeveel geld een klant over had om weg te migreren van Oracle, daar $5 af te trekken en dat als licentie-kost aanrekenen aan de klant...
Ik hoop dat ik verkeerd ben...

[divvid]

Ik denk niet dat de gemiddelde ZFS gebruiker begrijpt, dan wel er een stuiver om geeft, waarom CDDL en GNU(v3) incompatible zijn, als zelfs de auteurs GPLv3 het daar onderling niet over eens zijn.

[Kabouterplop01]

Ha inderdaad en buiten dat zijn ze ook niet zo secure als RHEL/ CENToS gebleken. Wat een meuk.
Door met deze groten te gaan samenwerken wordt het misschien nog eens wat.

[TijnC]

Er zijn enkele Red Hat Bonzen naar Suse getrokken, en die richten nu vol hun pijlen op hun ex-werkgever.

Suse gaat RHEL forken en nu dus ook samenwerken met Oracle en CIQ.

Je kan je dan ook afvragen hoe zwak Suse eigenlijk nog staat. In België hebben ze bijvoorbeeld geen enkele werknemer meer.

[ELD]

Je kan je dan ook afvragen hoe zwak Suse eigenlijk nog staat. In België hebben ze bijvoorbeeld geen enkele werknemer meer.

Op zich zegt dat niet zoveel, ik ken veel grotere software bedrijven die geen directe medewerkers meer hebben in België. SUSE is niet heel groot (2k medewerkers) maar zeker nog wel een belangrijke speler.

[Superstoned]

… en groei van 30% per jaar ofzo. Suse doet het goed, een aantal van mijn ex collega’s klaagt dat het te snel groeit en de cultuur naar de knoppen is. Nu was die cultuur sowieso niet fantastisch, Novell had al veel schade aangericht…

[ichnaton]

Een Duits bedrijf met een Engelstalig ecosysteem in een land dat twee talen heeft,(drie eigenlijk), die je elk toch al in een buurland hebt lopen. En dan thuiswerken. Gute morgen!

[TijnC]

Lokale sales aanwezigheid blijft belangrijk op de enterprise markt. Ook in 2023. Ter vergelijking: Red Hat groeide op 10 jaar van 6 naar 60 mensen in België. Die werken uiteraard ook vaak thuis. Gute morgen.

[Superstoned]

Misschien doen ze hun werk vanuit nl en Frankrijk? Suse heeft een sales kantoor in Utrecht.

[TijnC]

Zoals ik al zei: lokale sales aanwezigheid blijft belangrijk in de enterprise markt.

Overigens is hun marktaandeel stilaan ook verwaarloosbaar.

[Superstoned]

Hum? Naar ik begrijp is SUSE de snelst groeiende enterprise Linux… toen ik er nog werkte, 2014 ofzo, hadden ze ongeveer een kwart tot 1/3 van de enterprise markt, en het bedrijf is hard gegroeid, zeker 2-3x over de kop maar ik hoor van voormalige collega’s. Lijkt me sterk dat hun marktaandeel zo gedaald is, al kan ik ook nergens een bron vinden… misschien heb jij iets?

[TijnC]

Suse revenue: $653 in 2022. 17% groei YoY
Red Hat zit rond de 3.4 miljard $ met een groei van 11% YoY.

[Superstoned]

Wow, Dan is SUSE inderdaad flink gegroeid, die deden echt geen 150 mln toen ik er nog werkte. Netjes.

Red hat doet dan wel veel meer dan SUSE, dus de omzet zal niet makkelijk te vergelijken zijn. Maar als SUSE al jaren sneller groeit dan rh vraag ik me af hoe het marktaandeel eruit ziet… maar ja totale groei van rh zegt weinig over hun server business en natuurlijk was dit maar 1 jaar. In elk geval lijkt het me gezien de groei van SUSE over de laatste tien jaar sterk dat ze een lager marktaandeel hebben dan toen.

[TijnC]

Precieze cijfers vind ik niet meteen, maar Red Hat zit intussen aan ± 100 kwartalen op rij groei.
Het hangt wat van land tot land af uiteraard, maar Suse schijnt zijn pijlen nu vooral op APAC te richten. Een markt die Dirk-Peter van Leeuwen natuurlijk ook het beste kent.

[Superstoned]

Nou ja, ze groeien allebei, daar twijfel ik niet aan. Maar als de ene 1% groeit en de andere 5% dan is het gat wel kleiner geworden. Of groter ;-)

[kdekker]

Ik snap het doel, maar de naam Oracle i.c.m. dit doel laat toch je wenkbrauwen fronsen gezien Oracle's geschiedenis op dit vlak. Gekscherend werd weleens gezegd dat Oracle meer juristen in dienst had dan programmeurs. Of dat waar is weet ik niet, maar dat er zeer aggressieve benadering was bij innen licentiekosten al dan niet na vermeend misbruik, was vrij algemeen bekend (inmiddels meer dan 5 jaar geleden, mbt Java). Good old SUN was een heel ander soort club.

[jb044]

Ergens jammer dit hier. In het Nederlands hebben we immers 2 woorden: vrij en gratis. Die luxe hebben de Engelsen niet vandaar de verwarring

Volgens mij doet RedHat niets verkeerd, ja Big Blue heeft er geloof ik iets van 30 miljard voor neergeteld en zal daar inderdaad iets voor terug willen zien. Maar het is een groot misverstand dat er met opensource geen geld verdiend zou mogen worden. Juist wel zou ik zeggen, het is alleen lastiger om dat puur met licentie gelden op software te doen. Nou en, dat is sowieso een schimmige business of niet Oracle?

RedHat heeft juist omdat het een van de weinige ware opensource advocates is die daadwerkelijk winstgevend is, onzettend veel bijgedragen aan de community en doet dat nog steeds. Persoonlijk vind ik dat volstrekt logisch want de basis waarop zij bouwen is immers ook opensource, en voor hun weer gratis in broncode formaat af te nemen. Maar veel commercieele bedrijven hebben hier veel meer moeite mee en blijven hangen in hun verouderde business modellen. Zie Apple, Oracle en vele anderen. Pakken maar niet teruggegeven.

Het lullige is alleen dat je in principe je broncode vrij inzichtelijk kan maken in printbare vorm in een kluis die je tegen betaling kan betreden. IANAL maar volgens mij staat nergens dat je GPL software in downloadbare vorm op het net moet gooien.

Zelf gebruik ik met veel plezier AlmaLinux 9 en zij zijn de grote afwezige in dit hele verhaal. Zou het komen omdat die gewoon fatsoenlijke funding hebben EN niet evil zijn?

[eborn]

Ik ben wel eens benieuwd waarom mensen uberhaubt nog Redhat gebaseerde distros gebruiken? Is dat gewenning of omdat het in sommige gevallen nodig is voor bepaalde software c.q. bijbehorende support?

In onze zusterorganisatie gebruikte men ook primair CentOS en nu Rocky. Als Debian-man kijk ik daar naar en naar mijn machines die al sinds Debian 6 geupgrade zijn naar Bookworm en vraag me dan altijd af: why?

[Superstoned]

Honda the als serieus bedrijf serieuze enterprise software nodig hebt met goede support en ondersteuning van de fabrikanten van de software die je erop draait. Debian is leuk voor thuis gebruik en universiteiten of kleine bedrijfjes enzo maar als er iets mis gaat moet je googelen of hopen dat een vrijwilliger het fixed. Dat werkt niet hè.

[anboni]

Ze kunnen RHEL intussen beter hernoemen naar BBHEL - Big Blue Hat Enterprise Linux. Sinds IBM RH heeft overgenomen, gaat het best hard achteruit met de openheid. IBM's gonna IBM.

[djwice]

@AverageNL wellicht dit plaatje https://linuxiac.com/wp-c...-relationship-to-rhel.png van https://linuxiac.com/centos-stream/ toevoegen voor de nuance?

RedHat is downstream van CentOS Stream en sinds 2020 is IBM aan het aankondigen dat ze de focus gaan leggen op CentOS Stream, welke een upstream is voor RedHat.
En Fedora is dan weer een upstream van CentOS en de source is onder GPL licentie beschikbaar.

IBM lijkt dus het gat tussen de GPL versie en Enterprise versie van hun Linux distributies te willen verkleinen.
Features dus eerder beschikbaar in de Enterprise.

Wellicht is de concurrentie bang de versnelling van adoptie van nieuwe features in de Enterprise wereld niet bij te kunnen wonen en sturen ze daarom aan op "blijf bij het oude", "kom bij ons dan verandert er niets".

[Reactie gewijzigd door djwice op 22 juli 2024 23:47]