Canonical haalt Ubuntu Pro uit bètafase

Canonical heeft het bètalabel verwijderd van Ubuntu Pro, zijn abonnementsdienst voor langere ondersteuning van Ubuntu-systemen. Ubuntu Pro is beschikbaar voor iedere LTS-distro vanaf 16.04.

Betalende klanten van Pro krijgen onder meer als enige de beschikking over live kernel patching, zo blijkt op de pagina van Ubuntu Pro. Ook kunnen zij 24/7-ondersteuning krijgen. Het belangrijkste element van Ubuntu Pro is de langere ondersteuning: desktops en servers krijgen tien jaar beveiligingsupdates, in plaats van de standaard vijf jaar.

Een gratis versie voor het midden- en kleinbedrijf kwam al vorig jaar uit. De dienst is beveiligd tegen bekende CVE-geregistreerde kwetsbaarheden, niet alleen in het OS zelf maar ook in externe packages en applicaties zoals phpMyAdmin, Apache of Rust. Daarvoor werkt Ubuntu samen met bedrijven die scannen op zulke CVE's. Daarnaast voldoet Ubuntu Pro aan compliance- en certificeringseisen zoals FIPS 140-2 of PCI-DSS.

Ubuntu Pro

Reacties (31)

[Htbaa]

Gezien Red Hat EL / AlmaLinux / Rocky Linux en al die andere afgeleiden gewoon 9 jaar lang updates uitbrengen moest Canonical denk ik ook wel met iets beters komen dan slechts 5 jaar support op een LTS server release. Het is voor mij de reden geweest om over te stappen naar CentOS 8 destijds (wat overigens ontzettend in mijn gezicht ontplofte toen ze daar de stekker uit trokken, gelukkig zijn er alternatieven gekomen :-)). Er was natuurlijk al Ubuntu ESM, de voorloper van Ubuntu Pro. Daar had je één gratis key (voor privé gebruik) en betaalde je $ 75,- per key voor een server. Nu krijg je gratis 5 keys en daarna betaal je per server $ 500,-. Dat is nogal een verschil wat mij betreft.

[sfranken]

CentOS 8.x is prima om te zetten naar CentOS 8.x Stream (en dan naar 9). Daar is documentatie voor op de website van CentOS. Wat veel mensen over het hoofd lijken te zien is dat er met die overstap niet zo super veel veranderd. Wil je Red Hat? Dat kan, hun "developer" licenties mag je tot 16 machines mee deployen. Is in dat opzicht gewoon RHEL (ik draai dat op meerdere servers hier nu)

[Marve79]

9 is toch ook nog stream? Dat ga je toch niet in productie draaien.

[rbr320]

Vanaf versie 8 is CentOS altijd "Stream" inderdaad en daarmee de upstream van RHEL. In CentOS Streamm krijg je updates iets eerder dan in RHEL, maar deze packages zijn al weer uitvoerig getest in Fedora en intern bij Red Hat. Het zijn dus geen beta updates of iets dergelijks, wat iedereen lijkt te denken. Als je vindt dat je servers zonder OS support in productie kunt draaien is CentOS Stream nog steeds prima stabiel, net zoals CentOS 7 dat was. Zo niet, dan zou je CentOS helemaal nooit in productie moeten draaien maar alleen op je dev, je test en eventueel je acc omgeving.

[Marve79]

Op dev en test draai ik wat zo dicht mogelijk productie benadert. Dus ik ga niet op dev Stream draaien en dan op productie ineens RHEL.

Ik geloof best dat het stabiel is maar ik zie geen reden om Stream te kiezen boven bijv AlmaLinux waar de code wel exact gelijk is aan RHEL. Dus als je wilt besparen op licenties zou ik Alma draaien in dev/test en op prod gewoon RHEL.

[stefklep]

Hier alle omgevingen overgezet naar AlmaLinux... werkt perfect en geen Stream, dit ging ook enorm goed vanuit Centos 8 ( Stream )

https://github.com/AlmaLinux/almalinux-deploy

Zeker een aanrader inderdaad.

[Htbaa]

Dat met die gratis RHEL licenties kwam zoals ik het me kan herinneren ver nadat AlmaLinux en Rocky Linux al beschikbaar waren. Toen het voor mij speelde was 9 nog niet uit. Gelukkig bleek het doemscenario van de vervroegde EOL van 8 mee te vallen.

[Berlinetta]

Nee

[fifnih]

Er verandert weinig behalve het kostenplaatje.

Ubuntu Advantage wordt Ubuntu Pro.
10 jaar support is er al een paar jaar:
- 5 jaar support op Long Term Support versies,
- + 5 jaar ESM als je Advantage had / Pro hebt.

Bij Advantage had je 3 opties, de goedkoopste was $ 75,- (volgens mij was dat ook infra only, zonder phone en ticket support) en die is er kennelijk niet meer.
De goedkoopste Pro variant lijkt nu $225,- (infra only zonder phone en ticket support).

[Sando]

Zou in theorie iemand niet die backports van Ubuntu gratis kunnen verspreiden, zoals CentOS ook een legale "ripoff" van het commerciële RHEL was?

[rbr320]

... en AlmaLinux en Rocky Linux nog steeds zijn.

Om je vraag te beantwoorden: ja natuurlijk kan dat. De code is gewoon open source (valt waarschijnlijk onder de GPL) dus het enige wat het je kost is moeite. Dat is dan ook precies waar je voor betaald als je een subscription afneemt bij Canonical of Red Hat, het gemak van toegang tot hun repositories met binary packages die je direct kunt installeren, met daar bovenop het recht om hun supportafdeling aan te schrijven. Als jij zelf je eigen homebrew RHEL clone wilt maken dan is de broncode daarvoor gewoon beschikbaar bij Red Hat, minus hun branding en dergelijke. Maar dat is meer gedoe dan het je oplevert.

[Reactie gewijzigd door rbr320 op 23 juli 2024 19:03]

[Sando]

ja natuurlijk kan dat. De code is gewoon open source dus het enige wat het je kost is moeite. [De] broncode [is] gewoon beschikbaar bij Red Hat, minus hun branding en dergelijke. Maar dat is gewoon meer gedoe dan het je oplevert.

Voor mij persoonlijk is het misschien teveel gedoe, maar je had/hebt dus CentOS, Scientific Linux, AlmaLinux, Rocky Linux en dat is allemaal gewoon rebranded RHEL. Blijkbaar zijn de belangen om dit gratis aan te bieden groot genoeg, en in die zin vraag ik me af of dit plan Canonical financieel gaat helpen. We hebben het hier immers om backports tegen betaling, niet zo zeer om installatiesupport. Ubuntu blijft een fork van Debian Unstable/Testing waar bedrijven ook kunnen kiezen voor Debian Stable. Er is wel een use case (voor security backports naar oude systemen), maar die lijkt me kleiner dan het verdienmodel (premium support bij het optimaliseren en onderhouden van nieuwe installaties) van RHEL.

[rbr320]

Uiteraard is er vraag naar gratis, en omdat het open source is heb je gelukkig die mogelijkheid ook. Maar bedrijven moeten toch geld verdienen. Canonical en Red Hat doen dit beiden door het leveren van ondersteuning op contractbasis, want de software geven ze nog steeds gratis weg.

Ook is het creëren van open source software niet gratis, ontwikkelaars hebben graag en dak boven hun hoofd en iets te eten op hun bord. Dus natuurlijk is het prachtig dat wij met z'n allen gratis gebruik kunnen maken van dit alles, maar uiteindelijk volgt er ergens een rekening. Daarom vind ik het altijd jammer als ik reacties lees van werknemers van commerciële bedrijven die vertellen dat ze niet willen betalen voor het OS waar ze productiesystemen op draaien.

[Sando]

Daarom vind ik het altijd jammer als [commerciële bedrijven] niet willen betalen voor het OS waar ze productiesystemen op draaien.

Alleen doen deze bedrijven niets fout. Dat is hun expliciet recht dat wordt gegarandeerd door open source licenties.

Soms hoef je - naast dat je niet hoeft te betalen - niet eens je afgeleide werk te delen. Dat expliciete recht staat in "permissive free software licenses" als MIT, LGPL, Apache, BSD etc. Denk bijvoorbeeld aan Apple's macOS en iOS, gebaseerd op NeXTSTEP van Steve Jobs, die basically een compleet open source UNIX systeem - geschreven door honderden vrijwilligers in decennia - (legaal) heeft gekopieerd en closed source heeft gemaakt. Deze mensen zijn ook nooit betaald door NeXT of Apple, en de waardevolle verbeteringen aan de code zijn nooit teruggegeven aan de community. Overigens is de code van NeXTSTEP een kleine 30 jaar later alsnog uitgelekt.

Als iemand dan een businessmodel opzet waarbij ze bedrijven proberen aan te spreken op hun morele schuldgevoel om hun basisrechten en -vrijheden die ze in licentie hebben genomen te negeren om toch te betalen, dan weet ik niet of ik het ook jammer vind als bedrijven hun recht aanhouden en dat niet doen. Dat gezegd hebbende, Red Hat doet het heel erg goed, omdat de code die ze schrijven niet hun dienst is, maar in het verlengde staat van hun dienstverlening. Onlangs zijn ze overgenomen door IBM voor 34 miljard dollar. Ook als de code vrij beschikbaar is, heeft de dienstverlening nog steeds waarde. Dat is een aardig verschil met Canonical, waarbij het schrijven (backporten) van code hoofdzakelijk de dienst lijkt te zijn. Als deze backports vrij beschikbaar komen, wat is dan de meerwaarde van de dienst?

Ik vind het heel goed dat Canonical zoekt naar een financieel houdbaar of zelfs winstgevend model en ik gun het ze van harte. Ik betwijfel alleen dat dit, na de geflopte commerciële cloud "Ubuntu One", na de geflopte commerciële telefoon Ubuntu Edge met Ubuntu Touch, na de geflopte deal met Amazon, wel een succes gaat zijn.

[Reactie gewijzigd door Sando op 23 juli 2024 19:03]

[John Multiplex]

En terecht!

[AvWijk]

En, is dat snap gedoe er dan ook uit? Denk helaas van niet, omdat canonical zich er stevig in vastbijt

[Sando]

Maar niet alleen Canonical. Het zijn ook de onafhankelijke developers zelf die hier steeds om vragen. Recent voorbeeldje: De Telegram developers willen dat hun .deb wordt vervangen door een SNAP, omdat de .deb maintainers vaak extreem traag zijn met het packagen van nieuwere versies.

Ze kunnen natuurlijk ook hun eigen .deb compileren en hosten op een PPA oid, maar steeds meer developers kiezen uit gemakzucht voor Snapcraft en Flatpak. Het is aantoonbaar een beetje tot veel trager, en vanwege de sandboxing moet je vaak je complete videodrivers en themes ook als Flat of Snap hebben waardoor je twee keer zoveel ssd-ruimte nodig hebt. Maar de developers hoeven geen extra stappen aan hun build pipeline toe te voegen.

[pmeter]

(...) vanwege de sandboxing moet je vaak je complete videodrivers en themes ook als Flat of Snap hebben waardoor je twee keer zoveel ssd-ruimte nodig hebt.

Kun je dit toelichten? Moet iedere met snap verpakte app ook alle themes bevatten? Zo nee dan is 1x toch genoeg?

[Sando]

Kun je dit toelichten?

Flatpak en Snapcraft zijn "sandboxed". Dat wil zeggen: Ze kunnen niet bij je systeembestanden komen. Maar veel programma's hebben wel je thema en je videodrivers nodig voor functionaliteit. Daarom moeten deze systeembestanden, drivers en themes ook een gesandboxedte kopie hebben, en dat kan veel ruimte in beslag nemen.

Moet iedere met snap verpakte app ook alle themes bevatten? Zo nee dan is 1x toch genoeg?

Nee, dat gebeurt door dependencies. Dan is 1x inderdaad genoeg. Je ziet vaak dat je allerlei Snaps of Flatpaks moet updaten die je niet zelf hebt geïnstalleerd. Als je bijvoorbeeld een Flatpak van een programma installeert dat ook video kan afspelen, zoals Telegram, dan krijg je vaak ook een dependency mee van de "core" van het besturingssysteem, een package van je Thema, een (hele grote) package van je video driver, en als deze video driver toevallig NVIDIA is, dan heb je door deze nog steeds niet opgeloste bug een pakket van elke geüpdatete videodriver ooit, die allemaal vaak ook weer backport updates krijgen.

Kortom, dan heb je Telegram met letterlijk gigabytes aan support files en maandelijkse updates. Je kunt je afvragen in hoeverre dat een probleem is. Gebruik je 20 Flatpaks, dan zal het je niet zoveel uitmaken. Maar als je aan het overwegen bent om je éérste Flatpak of Snap te installeren, dan is het een behoorlijke barrière. If you want to sandbox this banana, you first need to recreate the universe.

Ook zijn Flatpaks en Snaps onhandiger op ultra-mobile personal computers (UMPC's) die vaak maar beperkte storage hebben. Je gaat niet snel 2 GB opofferen om Telegram of Firefox te installeren. UMPC's zijn zo snel, ze zijn prima in staat om Ubuntu of Fedora te draaien. Maar Ubuntu, met hun Snapificatie van voorheen .deb apps, lijkt zichzelf van UMPC's te willen uitsluiten. Of ze focussen zich alleen op het duurdere segment en UMPC's van de toekomst waar zeer veel ruimte in zit. Wat op zich jammer is, omdat Ubuntu zich juist vaak uitstekend leende om iets oudere hardware een snelheidsboost te geven wanneer Windows na vele updates te langzaam was geworden voor die hardware.

[Katsunami]

kiezen uit gemakzucht voor Snapcraft en Flatpak.

Logisch ook, voor user-facing applicaties die constant de laatste versie moeten zijn. Torvalds heeft hier in DebConf 2014 een rant van een half uur ofzo over gehouden, dan hij voor zijn eigen duik-app geen binaries voor Linux maakt. "We have binaries for Windows, and for Apple, but not for Linux, because it is a pain in the ass." En de reden is dat je je programma moet packagen voor "six versions of Fedora, two versions of Debian, and RHEL from 20 years ago." (Hij zegt in elk geval iets in die trant.)

Het komt erop neer dat je een binary moet maken voor elke specifieke Linux-versie.

En nog steeds zijn er mensen die zeggen: "Bullshit; die worden wel gemaakt door de maintainers van de distro's." Ja, tuurlijk, die distro-maintainers kunnen uiteraard zonder issues een steeds grotere en grotere repository onderhouden...

Ik denk dat we over 10 jaar op een Linux zitten die enkel het base system, achtergrondprocessen (servers, etc, zoals Samba en Apache) en de desktop bevatten, en dat alle gebruikersapplicaties of Flatpak, of Snap, of AppImage zijn.

Daarna moeten we nog af van die debiele "nieuwe hardware = nieuwe kernel (en in geval van grafische kaarten, Mesa) = nieuwe distributie"-situatie, en dan hebben we een besturingssysteem waar je ook als een normaal mens mee kunt werken.

En ja, ik gebruik ondertussen ruim 20 jaar Linux, en draai het ook nu 2 jaar full-time op mijn eigen desktop. En ja; ik draai Debian Stable, bouw computers die precies passen bij een Debian-versie die erop ga installeren, en dan installeer ik de meeste user-facing programma's (GIMP, LibreOffice, etc, etc) via Flatpak. Dat ga ik binnenkort ook weer doen, want ik heb na 7.5 jaar een nieuwe computer gepland met Debian 12.

[Sando]

Ik denk dat je gelijk hebt: Dat de grootste distro's over 10 jaar een steeds kleinere base krijgen, en dat steeds meer applicaties in een distro-onafhankelijk(er) package komen. Ik draai inmiddels ook alweer 25 jaar Linux (begonnen toen RHEL nog gewoon RHL was), waarvan de laatste 10 jaar exclusief.

Maar verder deel ik jouw acceptatie (nog) niet. Ten eerste zijn voor mij de bijbel en de uitspraken van Linus Torvalds overrated. Ten tweede vind ik deze ontwikkeling niet fijn. Snaps zijn haast universeel gehaat vanwege hun traagheid, en worden vaak geboycot vanwege de centralisatie. Flatpaks zijn geliefd bij voornamelijk Windows developers die ook "even" Linux willen ondersteunen. Maar eindgebruikers zijn zeer kritisch. Voor hen zijn er geen voordelen, behalve de artificieel gecreëerde voordelen wanneer developers geen distro-specifieke packages meer willen bouwen, wat overigens volledig geautomatiseerd kan gebeuren in de build pipeline, en als je je aan de richtlijnen van de distro houdt, vaak ook op gratis infrastructuur gehost kan worden. Toen Linux Mint ("Ubuntu how it should be") actief een standpunt tegen Snap aanhield en de ondersteuning hiervoor verwijderde, deed ik een donatie. Je stemt voor of tegen keuzes door ergens wel of niet voor te betalen/doneren.

In de computers die ik bouw en installeer ga ik juist Flatpaks en Snapcraft uit de weg. Ik zoek naar oplossingen om toch een package of een binary te installeren. Ik kies voor alternatieven als deze niet langer beschikbaar zijn, net zoals ik 10 jaar geleden ook voor Linux zonder multiboot koos ook al had Windows een enorme voorsprong op het gebied van game support en marktaandeel. Je stemt voor of tegen keuzes door iets wel of niet te gebruiken.

Het komt erop neer dat je een binary moet maken voor elke specifieke Linux-versie.

Dat is grotendeels onjuist. Voor zwaar gecompliceerde en Windows-georiënteerde software die achteraf een Linux-implementatie krijgen als Davinci Resolve klopt het wat je zegt. Maar veel van de apps die je nu naar flatpakworld overstappen zijn gewoon simpele electron-apps of iets soortgelijks. Telegram-desktop bijvoorbeeld stapt over van .deb op flatpak en snap, maar ze distribueren nog steeds een tarball met één binary die op vrijwel alle distro's draait. Wellicht een beter voorbeeld is de zwaar gecompliceerde maar Linux-georiënteerde 3d software Blender. Dat is ook één tarball met een binary die op vrijwel alle distro's draait. This is the way.

En nog steeds zijn er mensen die zeggen: "die worden wel gemaakt door de maintainers van de distro's." Ja, tuurlijk, die distro-maintainers kunnen uiteraard zonder issues een steeds grotere en grotere repository onderhouden...

Ik volg deze redenatie niet helemaal. Canonical vervangt steeds meer compacte .deb packages door veel grotere snap packages. Zo maken ze toch juist een steeds grotere repository? En verder heb je toch juist veel community repositories waar vrijwilligers packages gaan hosten omdat distro repo's ze niet meer willen hosten? Toen ik nog Red Hat gebruikte installeerde je vaak EPEL en RPM Fusion. Op Ubuntu had je bijvoorbeeld GetDeb. En veel software, bijvoorbeeld die waar ik zelf aan bijdraag, die bouwen en hosten hun eigen deb/rpm packages. Dan staan ze niet in een repository, maar bijvoorbeeld gratis op Gitlab of Github. De software download zelf de nieuwe versie als het beschikbaar is. Dat is naar mijn mening nog altijd beter dan een Flatpak of Snap. Als een softwarepakket geen .debs bouwt of host, dan draag ik er niet aan bij. Je stemt voor of tegen keuzes door ergens wel of niet aan bij te dragen.

Naar mijn persoonlijke mening is de enige echte goede usecase voor Snaps de distributie en licentie van commerciële closed source software op Linux.

[Reactie gewijzigd door Sando op 23 juli 2024 19:03]

[GekkePrutser]

Helaas niet... Ik baal er ook van. Ze blijven maar proberen hun eigen wiel uit te vinden. Eerst UpStart, Unity, Mir, nu dit weer... Deze is wel het langst meegegaan van al hun proefballonnetjes inmiddels.

[Katsunami]

Daarom draai je het best ook gewoon Debian Stable. Die installeer je gewoon 1x vanaf scratch zoals je die zelf wil hebben, en dan kijk je er twee jaar niet meer naar om behalve voor de updates. 1x per 2 jaar doe je een upgrade, en dan draait je computer zonder problemen jaar na jaar totdat die fysiek uit elkaar valt.

Dat is in elk geval precies wat ik ga doen met mijn volgende workstation. En, applicaties die daadwerkelijk de laatste nieuwe versie moeten zijn, installeer ik wel via Flatpak.

Ik ben nooit fan geweest van afgeleide distributies; en al helemaal niet van afgeleiden van afgeleiden. Ik snap dus ook totaal niet waarom er zoveel distributies zijn die afgeleid zijn van Ubuntu en dan proberen om die te ont-Ubuntu-en. Begin dan gewoon met Debian. (En dan heb je ook nog veel meer packages.)

[RoestVrijStaal]

Ergens heb ik het te doen met de ontwikkelaars van Canonical die voor Ubuntu Pro moeten werken. Nog 3 jaar backports maken van externe software voor Xenial uit 2016. Zij liever dan ik

[Reactie gewijzigd door RoestVrijStaal op 23 juli 2024 19:03]

[kozue]

Nou, anders al die backports wel voor fixes die puur gemaakt worden om een of andere certificering tevreden houden. Succes met openssl 3 backporten naar 16.04, en alle software die tegen openssl 2 gelinked is, wanneer ze besluiten dat openssl2 niet veilig genoeg meer is...

Maar goed, daar betaal je dan ook voor. Ik zou het zelf niet gebruiken (ben zelf Linux admin, dus red me prima met alleen een LTS), maar ik wens ze veel succes hiermee. Ik kan me best voorstellen dat hiervoor betalen soms een betere optie is dan iedere 2 jaar naar de laatste LTS upgraden,

[DeadMetal]

Zitten er nadelen aan dit eens in de 4 jaar doen, dus steeds een LTS overslaan?

[kozue]

Je kunt niet van de ene LTS naar een andere zonder eerst te upgraden naar de tussenliggende releases. Als je er een overslaat heb je dus meer werk bij de volgende.
Wat je wel zou kunnen doen is een compleet nieuwe setup inrichten naast de oude. Dan maakt het niet meer uit hoeveel releases je overslaat. Maar afhankelijk van je installatie kost dat mogelijk ook een hoop extra werk om alles weer from scratch in te richten. Tenzij je iets als puppet, ansibel of chef gebruikt die alles automatisch voor je doet

[GekkePrutser]

Je krijgt wel nog steeds 5 Ubuntu Pro installaties gratis als je je registreert als privegebruiker.

Wel jammer dat je je hele doopceel op moet geven voor die livepatching. Ik snap dat ze geld binnen willen halen maar ik snap niet dat er geen kloon distro is die het gewoon weer toevoegt (a la CentOS vroeger).

[Reactie gewijzigd door GekkePrutser op 23 juli 2024 19:03]

[Sando]

Ja, ik dacht precies het zelfde. De componenten zijn open source. De backports zijn open source. De kernels zijn GPL. Het eerste grote bedrijf dat hier gebruik van wil maken kan gewoon één licentie afnemen, en het dan gratis verspreiden naar hun gehele serverpark, het online zetten, verspreiden naar iedereen die het maar wil, en donaties ontvangen voor de infra. Precies zoals CentOS ook gewoon een gratis uitgave van het commerciële RHEL was.

Of zie ik iets over het hoofd?

[TrekVogel]

Ja natuurlijk kan dat, maar daar gaat het niet om. De hele reden dat je betaalt voor support is toch dat je geen rare fratsen hoeft uit te halen.

[Sando]

Ja natuurlijk kan dat, maar daar gaat het niet om.

Nou, daar gaat het uiteindelijk toch wel om? Als het belangrijkste USP van Ubuntu Pro de langere ondersteuning (backports) is, dan bestaat de dienstverlening hoofdzakelijk uit het verkopen van code met een licentie die je het expliciete recht geeft om deze code gratis ter beschikking te stellen. Ik zal niet mijn hele rationaal dubbelposten, maar ik betwijfel dat dit, na de geflopte commerciële cloud "Ubuntu One", na de geflopte telefoon Ubuntu Edge met Ubuntu Touch, na de geflopte deal met Amazon, wel een succes gaat zijn.