Reuters: SUSE gaat mogelijk in de verkoop voor ruim 5 miljard euro

EQT wil opensourcebedrijf SUSE verkopen, meldt Reuters. Het investeringsfonds zou de verkoop van het opensourcesoftwarebedrijf onderzoeken. Naar verluidt mikt EQT op een waardering van 6 miljard dollar, omgerekend ruim 5 miljard euro.

EQT heeft volgens Reuters de investeringsbank Arma Partners ingeschakeld om een groep investeerders te benaderen over een mogelijke verkoop van SUSE. De gesprekken bevinden zich op dit moment nog in een vroeg stadium, waardoor het niet zeker is dat het ook daadwerkelijk tot een verkoop komt.

EQT nam SUSE in 2018 over en bracht het bedrijf in 2021 naar de beurs in Frankfurt. In 2023 besloot het Zweedse investeringsfonds SUSE weer van de beurs te halen. Destijds waardeerde EQT het bedrijf op ongeveer 2,7 miljard euro. Nu hoopt de eigenaar de softwaremaker dus voor bijna het dubbele te verkopen. Op zijn hoogtepunt had SUSE een waarde van ruim 6,7 miljard euro.

SUSE boekt volgens Reuters een jaarlijkse omzet van 800 miljoen dollar. De bedrijfswinst zou meer dan 250 miljoen dollar per jaar bedragen. Het bedrijf levert opensourceoplossingen aan bedrijven. Onder meer Ericsson Microsoft en BMW zijn volgens de website van het bedrijf klant van SUSE.

Bron: SOPA Images/LightRocket/Getty Images

Reacties (81)

[arithcoder]

SUSE is al een keer of vijf verkocht geweest, Red Hat maar één keer aan IBM. Ik begrijp dit niet, waarom kan SUSE niet als zelfstandig bedrijf functioneren?

[Oon]

Waar moeten ze geld aan verdienen? Ze hebben wel SLES, maar ik ken geen enkele systeembeheerder die voor SUSE zou kiezen als OS. Rancher is een leuke tool, maar ook niet iets waar je 5 miljard uit haalt lijkt mij.

Vraag me dan vooral af hoe SUSE het überhaupt zo lang heeft overleefd

[register]

ik ken geen enkele systeembeheerder die voor SUSE zou kiezen als OS

Wel, bij systeembeheerders van heel grote of kritische systemen ligt dat toch wat anders.

Neem bijvoorbeeld de TOP500 van supercomputers, https://top500.org/statistics/list/ Kies category 'Operating System'. Sorteer naar keuze op aantal Cores, of op Rmax, of op Rpeak. Altijd bovenaan: HPE Cray OS. Dat is eigenlijk SLES met een HPE sausje over.

Neem een ERP van een groot bedrijf. In veel gevallen is dat SAP. Dat is mission critical: als dat ERP plat gaat, dan kan heel het bedrijf geen facturen meer sturen, niet meer betalen, weet het niet meer waar zijn voorraden zitten, wat klanten besteld hebben, enzoverder, kortom, heel het bedrijf ligt plat. Je kan dat natuurlijk als SaaS afnemen, maar stel dat je dat nog on premises wil draaien. Op welk OS ga je zo'n mission critical systeem zetten? Misschien best op één van de door de vendor aanbevolen OSen? SLES of RHEL?

[HollowGamer]

SUSE staat toch juist bovenaan? Volgens distrobox staat OpenSUSE vrij hoog. De meeste developers kiezen voor dat op hun (dev-)systemen, en dan DEB, RHEL of SUSE op hun Enterprise omgeving.

Zo dacht ik het tenminste? Zelf ben ik meer een RHEL iemand, vind alles van SUSE verwarrend en vaak 'okay, waarom precies zo?'.

[Robin Pfeiffer]

Volgens distrobox staat OpenSUSE vrij hoog.

Dat zegt verder niet heel veel, alleen dat er op DistroWatch meer clicks op zijn geweest binnen een bepaalde periode. Leuk om te zien wat op dat moment Linux nerds bezighoudt, maar over echt dagelijks gebruik en marktaandeel zegt het weinig.

DistroWatch zegt er ook zelf het volgende over:

The DistroWatch Page Hit Ranking statistics are a light-hearted way of measuring interest in Linux distributions and other free operating systems among the visitors of this website. They correlate neither to usage nor to quality and should not be used to measure the market share of distributions. They simply show the number of times a distribution page on DistroWatch was accessed each day, nothing more.

[BeosBeing]

Dat zegt verder niet heel veel, alleen dat er op DistroWatch meer clicks op zijn geweest

Klopt als een bus.

Maar hoe ga je de verkoop meten zonder officiële cijfers, laat staan het daadwerkelijk gebruik. De enige cijfers die we ten aanzien van dat laatste hebben zijn pagehits op webpagina's. Een systeem dat als server draait zal zelf geen webpages opvragen.

De populariteit op Distrowatch zal voornamelijk zijn onder individuele gebruikers, dus als iemand zich via die site oriënteert om te kiezen voor een distributie voor zijn serverpark, zal dat ook maar één hit opleveren, net zoveel als iemand die de pagina leest voor de keuze van een desktop-distributie. Vooral die eerste zal uiteraard ook wel wat uitgebreidere informatie opvragen maar ook daar zul je weinig tot niets van in statistieken tegenkomen.

[R_Zwart]

Bijna al onze producten draaien op SLES omdat dat meer geschikt is kritische applicaties als andere distributies.

[c-nan]

Oprechte vraag daar ik weinig ervaring heb met SLES. Waarom is SLES meer geschikt dan bijvoorbeeld RHEL?

[dmantione]

In mijn ervaring is SLES veruit superieur in binaire compatibiliteit. Red Hat heeft de vervelende eigenschap dat binaries voor Red Hat 7 vaak niet op 8 draaien en 8 weer niet op 9. Mijn ervaring is dat een rpm voor Red Hat 7 meestal zonder problemen installeert op de allernieuwste SLES. Het zorgt dat je veel minder gevangen zit op een oudere versie van het besturingssysteem en gewoon kunt upgraden.

[UPPERKEES]

Dat heeft met dependencies te maken. Waarom zou je RHEL packages van andere releases willen mixen?

[dmantione]

Er ontstaat naar verloop van tijd altijd druk op een systeem waarbij bepaalde software van oude packages afhankelijk is en gebruikers tegelijkertijd nieuwe softwareversies van bepaalde pakketten willen gebruiken. Vooral zodra je externe rpm's betrekt wordt het vaak lastig: Die zijn vaak lang niet voor iedere RHEL-versie beschikbaar. Met SuSE geen probleem, ze zijn gewoon te installeren en je kan het systeem redelijk actueel houden i.p.v. dat je vast blijft plakken in een oude versie.

[UPPERKEES]

Ik vind het maar een raar verhaal. SuSE heeft geen speciale magic. Het heeft te maken met de dependencies die aangegeven staan in de spec file. Wanneer je het punt bereikt dat je je software niet meer normaal in je distro kan installeren dan gaat er iets heel goed fout. Dan moet je of gewoon meegaan met nieuwe packages, of je hebt de verkeerde distro die je software niet ondersteund. Maar oude RPMs handmatig installeren is gewoon fout. Geen security updates en het is ook niet op elkaar afgestemd.

[dmantione]

Dealen met oude software hoort nu eenmaal bij het leven van het beheren van een computer. Vooral als een om een commercieel pakket gaat dat je niet even hercompileert.

Om je een voorbeeld te geven, veel software is gelinkt tegen OpenSSL. En libopenssl is niet binary compatibel met vorige versies, je moet daadwerkelijk de oude versie installeren. In SuSE zijn héél veel versies van libopenssl aanwezig:

commandchair:~ # zypper search libopenssl
S | Name | Summary | Type
---+------------------------------+------------------------------------------------------------------------------+-------
| libopenssl-1_0_0-devel | Ontwikkellingsbestanden voor OpenSSL | pakket
| libopenssl-1_0_0-devel-32bit | Ontwikkellingsbestanden voor OpenSSL | pakket
i | libopenssl-1_1-devel | Ontwikkellingsbestanden voor OpenSSL | pakket
| libopenssl-1_1-devel-32bit | Ontwikkellingsbestanden voor OpenSSL | pakket
| libopenssl-3-devel | Ontwikkellingsbestanden voor OpenSSL | pakket
| libopenssl-3-devel-32bit | Ontwikkellingsbestanden voor OpenSSL | pakket
i | libopenssl-devel | Include Files and Libraries mandatory for Development | pakket
i | libopenssl0_9_8-32bit | Secure Sockets and Transport Layer Security | pakket
i+ | libopenssl1_0_0 | Secure Sockets and Transport Layer Security | pakket
i+ | libopenssl1_0_0-32bit | Secure Sockets and Transport Layer Security | pakket
| libopenssl1_0_0-hmac | HMAC files for FIPS-140-2 integrity checking of the openssl shared libraries | pakket
| libopenssl1_0_0-hmac-32bit | HMAC files for FIPS-140-2 integrity checking of the openssl shared libraries | pakket
i+ | libopenssl1_0_0-steam | Secure Sockets and Transport Layer Security for steam | pakket
i+ | libopenssl1_0_0-steam-32bit | Secure Sockets and Transport Layer Security for steam | pakket
i | libopenssl1_1 | Secure Sockets and Transport Layer Security | pakket
i | libopenssl1_1-32bit | Secure Sockets and Transport Layer Security | pakket
| libopenssl1_1-hmac | HMAC files for FIPS-140-2 integrity checking of the openssl shared libraries | pakket
| libopenssl1_1-hmac-32bit | HMAC files for FIPS-140-2 integrity checking of the openssl shared libraries | pakket
| libopenssl3 | Secure Sockets and Transport Layer Security | pakket
| libopenssl3-32bit | Secure Sockets and Transport Layer Security | pakket
| libopenssl10 | Secure Sockets and Transport Layer Security | pakket


Ik zal je voor RHEL8 de volledige uitvoer van "dnf search openssl" besparen, want daar zit heel veel ruis tussen, maar de relevante regels uit de uitvoer daarvan zijn:

openssl-libs.i686 : A general purpose cryptography library with TLS implementation
openssl-libs.x86_64 : A general purpose cryptography library with TLS implementation
openssl3.x86_64 : Utilities from the general purpose cryptography library with TLS implementation
openssl3-libs.x86_64 : A general purpose cryptography library with TLS implementation

OpenSSL is geen uitzondering, dit geldt voor heel veel bibliotheken. ... en daarmee is de kans dat een applicatie de benodigde dependencies vindt een stuk hoger op SuSE. Dit naast het rare iets dat RHEL met de dynamic linker doet, wat ook voor een hoop problemen zorgt bij de uitwisselbaarheid van software tussen versies.

Je noemt het argument "security updates" maar dat juist een probleem bij RHEL: Daar blijf ik vaak plakken op een oude versie en ga er met veel kunst-en-vliegwerk nieuwe software in klussen om de gebruikers tegemoet te komen. Er blijft dus lange tijd een oud systeem draaien en dat is vanwege updates minder gewenst. Nu wordt RHEL wel lang ondersteund, maar ideaal is het nog niet. Bij SuSE kan ik het systeem zonder veel problemen upgraden naar fonkelende nieuwe software en het probleem van oude software isoleren tot een paar rpm's, waarvan je individueel de veiligheidsaspecten kan beoordelen.

[Reactie gewijzigd door dmantione op 12 maart 2026 09:27]

[UPPERKEES]

Commerciële software hoort gewoon support te geven. Dan heb je gewoon een repo van hun, die supported is voor je distro. Handmatig RPMs installeren is totaal niet wat een enterprise omgeving ooit zou willen of overwegen.

RHEL en andere distro's zouden nooit end of life packages aanbieden, het is niet voor niks end of life. Het is dan gewoon tijd om over te gaan naar nieuwe software. Die Frankenstein backported packages van end of life stuff moet je echt niet willen. Dan moet je een goed gesprek gaan hebben met die leverancier waar je royalties voor neerlegt.

Dealen met oude software hoort nu eenmaal bij het leven van het beheren van een computer

Ik heb dit nog nooit iemand horen zeggen in mijn carrière. Behalve dan van de mensen die uiteindelijk hun baan verliezen omdat ze inderdaad nog CentOS 6 blijven gebruiken en gehacked worden.

[Reactie gewijzigd door UPPERKEES op 13 maart 2026 17:23]

[dmantione]

Commerciële software hoort gewoon support te geven. Dan heb je gewoon een repo van hun, die supported is voor je distro. Handmatig RPMs installeren is totaal niet wat een enterprise omgeving ooit zou willen of overwegen.

Leuke theorie. Ik heb een paar maanden geleden nog een code voor nucleaire simulaties met veel handwerk moeten overzetten omdat de klant daarmee vast zat op RHEL7 en dat onhoudbaar was geworden. Daar kwam programmeerwerk bij kijken en mij bij de code laten was ook een heel gedoe, bij nucleaire software is streng geregeld wie daar bij mag, dus daar moest speciale toestemming voor aangevraagd worden.

[UPPERKEES]

Wat voor commerciële software is dat dan? Je koopt het, maar er is totaal geen support of system requirements? Blijft een vaag verhaal.

[dmantione]

Het probleem is dat je broncode koopt, die door de gebruikers die ermee werken aangepast wordt aan de lokale situatie. De originele auteurs ontwikkelen de software wel verder, maar dat gebeurt maar beperkt bij de lokale fork, want zo lang het systeem RHEL7 draait, is er geen nood de boel te actualiseren.

Vervolgens accepteert een nieuwere compiler de code niet meer en kernwetenschappers zijn geen informatici, dus slagen er niet zelfstandig in dat op te lossen.

[UPPERKEES]

RHEL 7 draaien lijkt mij wel een probleem, die is niet meer supported, tenzij je extra betaald. Raar contract heb je dan laten tekenen en ook een zeer unieke situatie. Ook kan je beter met containers werken lijkt mij als je zulke brakke software werkbaar moet houden op oude meuk. Je hoeft niet je hele OS mee te trekken in die gekkigheid.

[BeosBeing]

Dealen met oude software hoort nu eenmaal bij het leven van het beheren van een computer

Ik heb dit nog nooit iemand horen zeggen in mijn carrière. Behalve dan van de mensen die uiteindelijk hun baan verliezen omdat ze inderdaad nog CentOS 6 blijven gebruiken en gehacked worden.

Er zijn gigantisch veel bedrijven die op oude software draaien. Meestal voor de aansturing van een machine die meerdere miljoenen heeft gekost en dus ook niet zomaar vervangen kan worden. Indien mogelijk wordt zo'n systeem airgapped gebruikt maar als je klant de ontwerptekeningen aanlevert die vanuit een CAD-applicatie in de machine ingebracht moeten worden, dan wordt het toch behelpen.

[swhnld]

Je hebt in theorie helemaal gelijk, in de praktijk kun je nog steeds internet explorer aan de praat helpen op een Windows installatie doordat er nog steeds bedrijven zijn die het intern gebruiken voor bepaalde pakketten om maar een voorbeeld te geven. De kosten baten risico afweging voor bedrijven kijkt op een andere manier naar software dan je zou hopen.

[UPPERKEES]

Je kan Windows en Linux niet op die manier vergelijken. Software in Linux is integrated. In Windows is zo'n installer opzichzelfstaand. In een spec file staat letterlijk welke libs en en andere afhankelijkheden nodig zijn. Bij een major Linux release gaat dat allemaal overhoop. Want dat is gebruikelijk met major releases, dan mogen en gaan API en ABI changes voorkomen en breekt dat oude software.

[kdekker]

Ik herken dit niet. Als je op de laagste versie bouwt en zelf installeert (tar bal oid ipv een Linux smaak en soms versie afhankelijke package manager) en je aan de gedocumenteerde (in ons geval) C en C++ interfaces hield en geen kernel module bent, dan ging het eigenlijk bijna altijd goed. Het gros van de software pakketten zou hieraan moeten kunnen voldoen.

Andersom, dus bouwen op een hogere versie was wel een aardige garantie op problemen met runnen op een lagere versie. Meestal is er geen forward compatibiliteit, maar backwards wel. Iig dat is toch wel iets wat ik bij Linux (en ook UNIX) terugzag. Het is voor mij allemaal verleden tijd (tegenwoordig Windows only ).

[dmantione]

Red Hat doet iets raars met de dynamic linker: Die zorgt dat binaries een bepaalde afhankelijkheid hebben van de betreffende dynamic linker. Je kan op een RH7-systeem bijvoorbeeld ook niet de glibc rpm van RH8 installeren, het hele systeem is onmiddelijk kapoet, ondanks dat glibc perfect terugwaards compatibel is. Op SuSE kan dat wel zonder problemen.

[Reactie gewijzigd door dmantione op 11 maart 2026 23:04]

[_JGC_]

Met dergelijke acties maak je wel een vreselijk Frankenstein OS zonder enige support van de fabrikant. Dat is nou juist waarom men SLES of RHEL kiest.

[dmantione]

Klopt helemaal, het is ongewenst. Toch maak je soms rare sprongen om nieuwe software in een oud RHEL-systeem te klussen en vandaar dat ik door schade en schande kan vertellen dat deze truuk op RHEL niet werkt.

Tegenwoordig heb ik een ander paardemiddel ontwikkeld om nieuwe software op een oude RHEL te forceren, in situaties waar compileren vanuit broncode niet reëel is: OpenSuSE-rpm's in een subdirectory installeren en daarna met patchelf de dynamic-linker in de te installeren software naar die van SuSE laten wijzen. Dat is ook hackerwerk voor gevorderden, maar het is dan beperkt tot een individueel softwarepakket en je kunt het systeem redelijk ongerept en dus gesupport laten.

[kdekker]

Maar dat is toch logisch. Een next major versie rpm kun je niet op een lager versie van het OS installeren. Zowel Suse als RH doen na release geen breaking changes op glibc. Daarom zei ik ook: je bouwt op het laagste gesupporte is versie (dus rh 7) en die gebruik je ook op rh8. Pas als support vervalt, kun je omhoog, of je bouwt ook op rh8. Dan heb je twee varianten van je eigen software (wat niet fijn is).

En je houdt het probleem van defensieve klanten, die alleen upgraden als het moet en early adapters die voorop lopen. Dat is de prijs van 1 build op 1 release.

Ik ben al 5+ jaar weg uit het wereldje, dus ik denk dat rh7 en sles 12 mijn laatste ervaringen waren.

[dmantione]

Ik vind het niet logisch dat het hele systeem dan stuk is: glibc is backwards compatibel, dus daar is geen technische reden voor. Dat beide distributies de glibc binnen een versie niet actualiseren vind ik wel logisch, maar ook hier is er verschil: Red Hat zal glibc binnen een hele major-versie niet actualiseren. SuSE werkt met service-packs. Als je SLES15 bijvoorbeeld van SP6 naar SP7 actualiseert, krijg je een nieuwe glibc en is het weer makkelijker om software die de nieuwe glibc gebruikt te installeren.

[HollowGamer]

Waarom kies je niet voor containers en VMs?

[dmantione]

Omdat je dan nog steeds een verouderd RH7-systeem overhoudt waar weer geen nieuwe software op kan.

[engessa]

Bijna 25 jaar geleden kocht je een doos met Suse bij de V&D. Dat business model is nu wel een cht anders.

[justdaboo]

Ik heb nog zo’n doos ook bij de V&D gekocht idd!

[Sjah]

Dacht dat ik hem destijds heb gezien op de boekenafdeling Bijenkorf.

[HollowGamer]

Goed bewaren, er zijn collectors die er goed geld voor over hebben.

Daarnaast is het ook mooi voor jezelf. Ik mis die oude tijd ook wel, al denk ik meer dat het in je hoofd zit, CD/DVD was veeeel langzamer.

[kdekker]

Bij een vorige werkgever was RHEL voor de Amerikaanse markt en SLES voor de Duitse/Europese. Technisch zeer vergelijkbaar en bij Suse vaak lagere prijzen. Dit is weer heel wat jaren geleden.

In de praktijk hadden we 1 Linux build (doorgaans SUSE) die prima op beiden werkte (afgezien van een C++ ABI die 1x niet gelijktijdig doorgevoerd werd).

Hoe de marktaandelen van enterprise Linux versies nu liggen weet ik niet. Bedrijven willen nu eenmaal support en garantie op fixes indien nodig en verder geen sores. Toentertijd zag je geen 'pret' versies bij bedrijven. Overigens was de keuze vanuit de softwareleverancier ook een hele praktische om het bij twee te laten. Tenslotte moet wel alles getest/gevalideerd worden en support/reproductie systemen aanwezig zijn. Een Linux smaak erbij ondersteunen is dan hetzelfde als een ander platform erbij en is een kostbare zaak.

[Reactie gewijzigd door kdekker op 11 maart 2026 21:38]

[curkey]

De klant waar ik werk draait het SAP platform op SLES volgens mij, een dat is geen klein landschap.

[TheVivaldi]

Onder meer Ericsson, Microsoft en BMW zijn volgens de website van het bedrijf klant van SUSE.

Dat zijn toch geen kleine jongens…

[WargamingPlayer]

SUSE is ten eerste Europees (Distributie). Ten tweede heel erg stabiel. Heel terughoudend met nieuwste van het nieuwste. Ideaal dus.

Draai mijn Mail, Reverse Proxy op Suse

[Pjotr Pinda]

Gebruik van Rancher kan wel eens hard gaan groeien nu bedrijven minder afhankelijk willen worden van Amerikaanse bedrijven. En Rancher is werkelijk een prima containerplatform. Ik ken meerdere bedrijven die voor SUSE Rancher kiezen ipv RedHat OpenShift.

[downtime]

IBM is een echt IT-bedrijf met een lange geschiedenis in het bouwen van hardware en besturingssystemen. IBM kent z'n klanten en Red Hat ondersteunt de core business. Maar investeringsbedrijven gaan niet voor synergie maar willen (forse) groei zien. En als dat niet lukt wordt het bedrijf weer van de hand gedaan aan iemand die denkt dat ze het beter kunnen.

[R_Zwart]

Investeerders gaan niet alleen maar voor sterke groei, maar ook voor investeringen die een vaste inkomstenstroom opleveren. Focussen op sterke groei alleen is veel te riskant. Suse lijkt me echt zo'n investering die voor een vaste inkomstenstroom zorgt, maar als EQT daar al meer van heeft zullen ze de boel af en toe een beetje opschudden.

[downtime]

Is de vuistregel niet dat de waarde van een bedrijf ongeveer 10x de jaarlijkse winst is? Dan lijkt het me sterk dat SUSE 5 miljard waard kan zijn voor een investeerder die niet op groei rekent.

[kdekker]

Hardware is nu nog maar beperkt tot mainframe en AS/400. Het is veel meer een software en diensten club geworden, de afgelopen 20 jaar. En dan nog hebben ze voor software ook allerlei zaken weer uitbesteed.

[HollowGamer]

Ik had liever niet dat IBM - Red Hat had gekocht. IBM is vrijwel even erg Oracle, al hebben ze nog iets van development liefde. Gelukkig lijkt RHEL vrij zelfstandig te opereren.

SUSE wilde volgens mij ook flink groeien, maar dat lijkt niet echt te lukken. Ik heb geen idee wat hun nu zo uniek maakt. Bij RHEL kun je alle spins en gedurfde keuzes noemen, maar bij SUSE.. geen idee. Ze hadden Yast, maar die is ingeruild voor Cockpit. Ze hadden een developer platform, maar tegenwoordig kan dat ook met Flatpaks en containers.

Hun keuzes zijn ook echt heel gek. Eerst gingen ze helemaal voor het ene FS, daarna weer voor de andere. Ze doen het allemaal zo half (vind ik).

[TheVivaldi]

Sowieso moet je tegenwoordig niet meer met IBM/Red Hat in zee gaan, want Amerikaans, toch? SUSE is tenminste Europees.

[satya]

Hangt er vanaf waar de systemen die je wilt exporteren naar toe moeten. Een van onze leveranciers is er weg omdat hun spullen anders niet naar Hong Kong mochten.

Zijn over gegaan op Debian.

[BorgMan]

Waarschijnlijk omdat er niet genoeg winst in zit voor de investeerders. Die willen meer geld zien, terwijl IBM denk ik aan Red Hat "het product" meer heeft dan er geld uit halen.

[beerse]

Zakelijk gezien is SAP een grote drijfveer richting SuSE: Dat is de stanaard linux omgeving voor SAP onder linux..

Daarnaast begint SuSE zich aardig te roeren in container zaken waarmee het zakelijk ook een aardige basis krijgt.

Vanuit Europa is SuSE natuurlijk een Euopeese distributie, waar RedHat een Amerikaanse is, wat voor overheden een insteek kan zijn.

Naar mijn persoonlijke idee is de relatie tussen SLES (de zakelijke/betaalde variant) en OpenSuSE (de opensource variant) iets te los. Bij de RedHat varianten is dat iets strakker bij elkaar.

[Stijnvi]

Het feit dat een bedrijf gekocht en verkocht wordt betekent niet dat het niet zelfstandig kan functioneren. Als bedrijf A bedrijf B koopt betekent dat dat bedrijf A van mening is dat bedrijf B meer waard is dan wat ervoor wordt gevraagd. Wanneer bedrijf A bedrijf B vervolgens weer verkoopt betekent dat dat bedrijf A van mening is dat er betere investeringsmogelijkheden zijn voor het geld wat ze momenteel in bedrijf B hebben zitten en/of dat een andere partij meer wil bieden voor bedrijf B dan het waard is.

[MadMarky]

Omdat IBM een techbedrijf is die Redhat als aanvulling ziet in hun portfolio. Investeringsfondsen hebben doorgaans een heel ander doel voor ogen.

[maartenvdk]

Mooie start om dat in de EU binnen te houden. Ik heb altijd wat moeite met de reactie om een hele eigen tech stack vanuit de EU te bouwen, fragmenteren is niet de oplossing. Maar als de afhankelijkheid iets mee wederzijds wordt zou je mischien wel een grote tech markt kunnen hebben blijven we mischien iets gelijkwaardiger samenwenwerken...

[Baardmeester]

Je hoeft niet gelijk de hele stack in een keer te bouwen, maar juist op de goede momenten te investeren in Europese opties. Dit is zo'n moment dat je met, een op dit niveau, een kleine investering een officieel EU Enterprise OS kunt creëren. Net zoals je nog kunt investeren in Mistral voor een EU ai. Het zal wel weer het geval zijn dat dit niet wordt gedaan en het buiten Europese handen valt.

[Scriptkid]

waarom zou je dat van de grond af aan willen doen nu Azure en M365 local gelaunched zijn die volledig self hosted op eigen hardware disconnected van de cloud kunnen draaien,

Je krijgt hiermee een volledig product wat heel veel kan volledig soevereign en redelijk kant en klaar.

[voorstad]

Omdat je dan nog steeds niet soeverein bent. De Cloudact dwingt een Amerikaans bedrijf ook in die situatie in te grijpen:

https://www.ftm.nl/nieuwsbrieven/bij-microsoft-bladdert-de-soevereine-laklaag-van-de-cloud-er-snel-af

Het woord "soeverein" in combinatie met Microsoft, Google of AWS is puur marketing. Trap er niet in.

[daanb14]

Omdat het nog steeds Amerikaanse closed source software is, waarbij je voor onderhoud en patching afhankelijk bent van een Amerikaanse partij. Het mag dan wel lokaal draaien, maar het wordt een lastig verhaal als Microsoft onder politieke druk van een zeer onberekenbare regering gekke dingen gaat doen.

[Scriptkid]

En hoe werkt dat met open source etc, of bedrijven die nu EU zijn en opgekocht worden, dat risico wat jij nu beschrijven van de supply chain blijf je altijd houden, Wat als USA geen hardware meer toe staat , ga je dan chinese cpu inkopen?

Voor open source de owner moet zijn commit approven, kijk naar de Root module of de xyz hack, npu infections, allemaal challanges in linux of je moet van alles een eigen fork gaan starten maar dat is neit te maintainen.

Dan moet je echt vanaf 0 een nieuw OS en alles bouwen

Denk dat als USA een export verbod opzet naar NL dat we wel andere challanges hebben dan beetje IT,

[Reactie gewijzigd door Scriptkid op 12 maart 2026 11:03]

[daanb14]

Voor open source de owner moet zijn commit approven, kijk naar de Root module of de xyz hack, npu infections, allemaal challanges in linux of je moet van alles een eigen fork gaan starten maar dat is neit te maintainen.

Dit probleem is niet uniek voor open source. Het voorbeeld wat je noemt met xzutils kan ook prima gebeuren met closed source software. Alleen gaan we er in dat geval niet achter komen, omdat het closed source is en een vendor ons niet gaat vertellen dat er een backdoor in hun product zit. Open source biedt dan in ieder geval nog de mogelijkheid om er in het publiek achter te komen wat er aan de hand is. Veritasium had toevallig laatst nog een mooie video over dit onderwerp en waarom dit absoluut niet als een nadeel van open source moet worden gezien: YouTube: The Internet Was Weeks Away From Disaster and No One Knew

En hoe werkt dat met open source etc, of bedrijven die nu EU zijn en opgekocht worden, dat risico wat jij nu beschrijven van de supply chain blijf je altijd houden, Wat als USA geen hardware meer toe staat , ga je dan chinese cpu inkopen?

Je moet ergens beginnen. Dat op de softwarelaag focussen niet alle problemen oplost lijkt mij algemeen bekend mag ik hopen. Maar minder afhankelijkheid is een goed begin wat we uiteindelijk ook uit zouden moeten bouwen naar eigen chipfabrieken en als het nodig is ook hardwarefabrieken.

[Scriptkid]

Of juist niet , Als iedereen zijn eigen wiel uit wil vinden komen we nooit verder maar gaan we alleen verder van elkaar af.

We moeten werken aan 1 aarde niet aan een groot zooitje versplintering dat is een enorme waste van resources.

[daanb14]

In een ideale wereld zou het zo werken en verspilden we inderdaad geen waardevolle kennis aan allemaal hetzelfde doen, maar helaas hebben we als Europa te maken met een Amerika wat in een tech-olichargie is veranderd wat de Project 2025 agenda doorvoert en een assertief, autocratisch China wat ook niet gelijkstaat aan onze Europese waarden van vrijheid, mensenrechten en democratie.

[Scriptkid]

en daar gaat het al mis, europsese waarde moet je los laten, net als USA waarde en UAE waarde en china waarde,

Je moet gaan kijken naar humanity waarde en de common grounds gaan zoeken en gesprekken gaan voeren om dichter bij elkaar te komen,

Daarnaast moet je regerings beleid uit het volk zijn handen gaan halen en naar een wereld wijde structuur gaan migreren,

Als we dit nu niet in gaan zetten heeft het helal coloniseren project ook een hele uitdaging want van wie is mars en wie is authoritair op de maan etc.

Gezien we komende jaren al maanbasis etc willen bouwen is er geen tijd te verliezen. alleen de kwartjes vallen nog steeds niet bij veel wereld leiders laat staan bij het normale volk.

[Reactie gewijzigd door Scriptkid op 12 maart 2026 17:09]

[musiman]

Wat dacht je van een autonome Azure region? China heeft er al één, beheerd door 21Vianet. Dat zou Europa toch ook kunnen eisen?

[Scriptkid]

Dat hebben we gehad in duitsland en was een fiasco,

En is nu dus niet meer nodig, je kunt nu elke msp dit laten doen dus is een kwestie van grote hoster vinden zoals kpn etc die het gaat doen.

[musiman]

Jij doelt op Azure Stack Hub, toch?

[Scriptkid]

Overview of Microsoft 365 Local on Azure Local Infrastructure - Azure Local | Microsoft Learn

Azure Local Solutions | Microsoft

[musiman]

Ja, Azure Stack Hub dus.

[Enjoyer]

Misschien moet Nederland ergens een Eiland bouwen, funded door alle lidstaten. Vervolgens heeft dat eiland een stuk grond voor elk lidstaat. En dat wordt dan Silicon Island.

[Madshark]

De pompen van Markerwaard aanzetten,.en we hebben binnen een jaar een flink stuk grond erbij.

[Enjoyer]

Dat zou wel cool zijn maar ik denk dan toch aan een meer centraal gelegen eiland in een iets warmer gebied. Markerwaard ligt in principe nog altijd in Nederland. Het eiland zoals ik het voor mij zie, ligt meer in de mediterraanse zee, wellicht misschien nog met een vakantie oord erbij. Europese big Tech wil natuurlijk ook graag van de zon genieten

[zx9r_mario]

20 jaar geleden was Suse overgenomen door Novell meen ik.

[beerse]

https://en.wikipedia.org/wiki/SUSE_S.A.: SuSE: Novell (2003) -> Attachmate (2010) -> MicroFocus (2014) -> EQT (2018).

[Vaevictis_]

Lang geleden begonnen met suse na slackware in 1995 ofzo. Kon er niet echt aan wennen aan de aparte manier van configuren yast, zypper was destijds ook kleine community en veel zelf compileren.

Daarna nog eens open suse geprobeerd. Tegenwoordig desktop met cachyos en wil nooit meer iets anders.

[R_Zwart]

Suse maakt dan ook geen desktop software.

[TheVivaldi]

SUSE =! OpenSUSE.

[ocf81]

Net als dat Fedora geen RedHat is?

[DeTeraarist]

In 1995 had je nog geen OpenSuse. Ik zat toen ook een tijd op slackware, tot ik een cd-rommetje kreeg bij de PC Linux(dacht dat het zo heette, engels maandblad), met Red Hat. Fedora bestond toen ook nog niet.

[TheVivaldi]

Maar het ging niet om 1995. De persoon schreef eerst over SUSE in 1995 en daarna dat die “later nog eens openSUSE geprobeerd had”. Dat stukje reageerde ik op. Excuses als dat niet duidelijk was.

[BI-Forcer]

SLES4SAP dekt inmiddels een merendeel van alle SAP backends, RHEL en AIX(Power) zijn daar wel aanwezig en supported maar met een significant lagere adoptie.

[HollowGamer]

EU onderneming koop het op, en maak er een Fedora 2.0 ecosysteem van, maar dan Europees gericht.

[Pasteis]

SUSE boekt volgens Reuters een jaarlijkse omzet van 800 miljoen dollar. De bedrijfswinst zou meer dan 250 miljoen dollar per jaar bedragen.

Dit is toch een prima resultaat? Of liggen de resultaten hoger in deze markt?

Ik hoop niet dat het nu wederom door een Amerikaans techbedrijf gekocht wordt. Hopelijk wilt SAP of een andere Europese reus zich hier in mengen.

Lijkt me op het oog van Europese onafhankelijkheid juist een interessante belegging op termijn met alle politieke verschuivingen naar Europe first!

[JoWa]

(Open)Suse is en blijft mijn favoriete distributie.
Mijn eerste thuisserver eind jaren 90 was met Suse geconfigureerd. Door Yast was deze echt véél eenvoudiger te configureren dan met de andere distributies.
Toen Novell Suse overnam was ik toevallig alliance manager voor Novell vanuit mijn werkgever (een groot IT-bedrijf). Fijn samengewerkt en Suse werd goed gewaardeerd in de markt.
Later kwam de scheiding tussen SLES en OpenSuse.
Mijn thuisserver is al lang geleden vervangen door een Synology, maar ik heb nog steeds tenminste 1 pc met een recente versie van OpenSuse om een stabiele en goed configureerbare Linux omgeving te hebben. Yast was en is een verademing t.o.v. de andere beheertools.

[Maghiel]

Yast is deprecated

[JoWa]

Yast zit nog steeds in OpenSuse 15.6
Versie 16 kreeg ik op een van mijn test-pc's niet door de installatie heen, Ik kreeg een berg foutmeldingen bij het opstarten van de installatie (zowel off- als online).

Nu alleen nog uitzoeken hoe ik van 15.6 naar 16 kan gaan zonder in diezelfde installatieproblemen te komen.