Tuxedo OS schrapt Ubuntu als basis en stapt over op Debian

Tuxedo OS, de Linux-distributie van laptopfabrikant Tuxedo Computers, gaat Ubuntu niet meer als zijn basis gebruiken. De ontwikkelaars doen dat vanwege de 'strategische koers' van Ubuntu-eigenaar Canonical. Het bedrijf stapt permanent over op Debian.

Dit nieuws in het kort

• Tuxedo Computers, een Duitse fabrikant van Linux-laptops, schrapt Ubuntu als basis van zijn eigen Linux-distributie.
• De fabrikant doet dat vanwege de beslissingen van Ubuntu-maker Canonical, dat omstreden Snap-apps pusht en AI-functies wil introduceren.
• Het bedrijf stapt over op Debian. De eerste testversie verschijnt 'in de komende weken'.

Tuxedo is een Duitse fabrikant die Linux-laptops en -pc's verkoopt. Het bedrijf ontwikkelt daarvoor een eigen Linux-distributie: Tuxedo OS.

Er werd al gespeculeerd over de toekomst van Tuxedo OS, zo schrijven ook de makers in een blogpost. Tuxedo brengt al maandenlang minder updates uit en zegt nu waarom: het werkte de afgelopen maanden stiekem aan een overstap naar versie 13 van Debian Testing.

Tuxedo noemt die overstap logisch. Ubuntu is namelijk óók gebaseerd op Debian. De stap was daarom relatief makkelijk, maar geeft de ontwikkelaars meer flexibiliteit en vrijheid om hun distributie zelf in te richten.

Opvallend genoeg blijft het bedrijf de testversie van Debian gebruiken, ook wanneer Debian 14 verschijnt. Volgens Tuxedo is de testversie beter geschikt voor zijn OS, omdat het een 'hybride releasemodel' volgt met regelmatige updates voor de kernel en (gpu-)drivers.

Beeld: Tuxedo Computers

De strategische koers van Canonical

Tuxedo heeft verschillende redenen voor de overstap. Het bedrijf heeft bijvoorbeeld moeite met het onderhouden van software. Tuxedo OS gebruikt Ubuntu LTS als basis. Dat is een extra stabiele versie van Ubuntu, die eens in de twee jaar een grote upgrade krijgt. Naar mate zo'n LTS-versie ouder wordt, wordt het steeds lastiger om nieuwe drivers en kernels te backporten.

Ook wordt het steeds lastiger om Snap-packages te weren: steeds meer standaardapps in Ubuntu worden alleen nog maar geleverd als Snap, schrijft Tuxedo. Snaps zijn 'universele' apps, die in theorie dus werken op alle Linux-distributies. Dat is handig voor ontwikkelaars: ze hoeven met Snap maar één Linux-versie van hun apps te onderhouden.

Toch is Snap een beetje omstreden. Snap-apps in de praktijk alleen te vinden in de Snap Store van Canonical: een gesloten en gecentraliseerd platform. Veel gebruikers vinden dat Snaps daarom tegen de kernwaarden van Linux ingaan.

Ook Canonicals plannen rondom AI zijn reden om weg te gaan van Ubuntu, schrijft Tuxedo. Canonical wil AI-functies in zijn distro bouwen, maar volgens Tuxedo is de roadmap daarvoor 'ontransparant'.

Testfase 'in de komende weken'

Volgens Tuxedo zullen gebruikers op termijn weinig merken van de overstap. Omdat Ubuntu ook Debian als onderlaag gebruikt, blijven zaken als de welbekende apt-packagemanager hetzelfde.

In de komende weken begint het bedrijf met een 'uitgebreide bètafase'. Iedereen kan de Debian-versie van Tuxedo OS dan uitproberen, al raadt het bedrijf aan om dat alleen te doen op niet-kritieke systemen. Gebruikers kunnen ook niet upgraden van de Ubuntu-versie naar de nieuwe Debian-release. In plaats daarvan moeten ze het OS helemaal opnieuw installeren.

Beeld: Tuxedo Computers

Reacties (40)

[jschreuder]

Misschien goed om ook te benoemen dat Snaps mede omstreden zijn omdat veel meer distro's flatpaks ondersteunen en Canonical dat juist niet doet op Ubuntu. Door hun eigen systeem op te zetten bereiken ze juist het tegenovergestelde van wat een distro-agnostisch packaging systeem zou kunnen bereiken.

[cdwave]

Wat echt mis is met "snap" is dat het indruist tegen het hele ecosysteem van het OS.

Het idee is dat programma's allerlei libraries en resources kunnen delen. Dat houdt de memory load lekker laag, de veelgebruikte "libc" staat maar een keer in het geheugen en alle processen delen die.

Een "snap" package doet dat helemaal niet, die neemt een eigen kopie van zo'n beetje het hele rootfs mee. Elk snap programma laadt dus een eigen versie van libraries in die eigenlijk gemeengoed hadden moeten zijn. Dan had je het hele programma veel beter statisch kunnen linken, dan was het tenminste nog een compact geheel geworden, met van elke library alleen maar precies wat het programma ook echt gebruikt. Maar ja, da's dan blijkbaar weer te moeilijk ofzo, dus krijg je zo'n Frankenstein oplossing.

De crux van het maken van een "distro" is nou juist dat je applicaties en libraries bijeen sprokkelt tot een samenwerkend geheel. En als applicatie A nou versie X wil hebben van een library, en applicatie B wil versie Y, dan is de Open Source oplossing dat je applicatie A aanpast zodat die ook met versie Y overweg kan. Bijvoorbeeld. Als je in plaats daarvan eromheen gaat knutselen en iedere applicatie een eigen "view" op de libraries gaat geven, dan ben je dus alleen maar bezig met de korte termijn, en juist weg aan het koersen van die open source gedachte.

[GertMenkel]

Al die versies van libraries is precies wat Windows doet en het werkt op zich prima.

Daarnaast is het probleem natuurlijk dat de meeste mensen geen applicaties maken voor TuxedoOS. Ze maken applicaties voor Ubuntu/Debian/Arch en misschien nog een keer SUSE ofzo, maar als je iets als SteamOS draait, heb je gewoon dikke pech.

Flatpak, Snap, AppImage, Docker, noem het maar op, iedere cross-distro-applicatiedistributiemethode doet allemaal hetzelfde, namelijk de binaries bundelen die je nodig hebt.

Op Ubuntu is het een bekend fenomeen dat beginners die maar wat van askubuntu kopieplakken eindigen met allerlei PPA's die bij de eerstvolgende dist-upgrade het hele systeem kapot maken, omdat ze per se openssl 1.1 nodig hebben.

Statisch compileren is nog een heel gezeik zodra je programmeertalen gaat mixen. Het kan allemaal in theorie, maar zelfs pure C-applicaties kunnen een heel gedoe geven als je probeert om een GUI-framework volledig in de applicatie te linken.

Het idee om applicaties allemaal bibliotheken te laten delen is een nobel streven, maar het werkt enkel en alleen voor applicaties die dezelfde versie van een distro targeten. Valve heeft dat op Linux geprobeerd door Ubuntu 12.04 als een stabiel target aan game-developer te geven, maar ook die zijn overgestapt op alles binnen Proton draaien onderhand. De praktijk laat helaas zien dat wat werkte voor mainframes en workstations in de jaren '90 niet werken op een moderne Linux-distro.

[Llopigat]

Het werkt anders prima voor distributies als Debian. Ik gebruik ook helemaal geen containerised apps.

Overigens, buiten het slimmere delen van het geheugen door dezelfde libraries is het ook veiliger. Als er een fout wordt ontdekt in openssl hoeft die maar 1x gefixt te worden en gelijk is elke app die hem gebruikt veilig.

Met die snaps en flatpaks ben je van van elke ontwikkelaar afhankelijk om dat apart te updaten. Veel zullen die moeite niet zo snel nemen

[Reactie gewijzigd door Llopigat op 7 juli 2026 20:53]

[supersnathan94]

Al die versies van libraries is precies wat Windows doet en het werkt op zich prima.

Het enige wat hier echt positief aan is, is dat het legacy ontkoppelt.

Het nadeel is dat je langer met legacy kunt blijven slepen want je hoeft niet mee.

Beiden hebben zo zijn voors en tegens, maar met development is het “shared lib” principe soms een wel een vervelende. En soms is het andersom.

Maar je moet wel een lijn trekken. Of je doet alles shared of je doet het niet. Canonical lijkt het nu allebei half te doen?

[GertMenkel]

Snaps kunnen prima bibliotheken delen, het zijn de makers van die dingen die het niet doen: https://snapcraft.io/docs...rfaces/content-interface/ Dat probleem speelt overigens ook bij Flatpak, en bij statisch gecompileerde programma's.

Eerlijk gezegd kan ik me er niet heel druk over maken. De tijd dat we 100MB aan DLL's een probleem vonden, is lang geleden.

Ik zie niet waarom je per se de code moet delen. Het is handig en efficiënt om het te doen, maar het is aan de applicatiemaker om daar een beslissing over te maken. Soms is het delen van die code zwaar irritant (bijvoorbeeld als je software niet door Debian/Fedora/Canonical wordt verspreid en je dus niet uit kunt gaan van een specifieke versie) en als oude software niet meer wordt bijgewerkt, is het een gedoe om die werkend te houden op moderne distributies.

Het is gereedschap dat je moet gebruiken wanneer het handig is.

Daarnaast hebben Snaps andere voordelen tegenover ouderwetse pakketten. De sandbox waar ze in draaien schermt je data mooi af en beperkt de impact die een virus kan hebben mocht je getroffen worden door een exploit. Mijn huidige mailprogramma en chatclient kunnen mijn browsergeschiedenis lezen, en ik zie eigenlijk niet waar dat voor nodig is. Helemaal QubesOS gaan vind ik te veel moeite, maar ik ben wel voorstander van het afscheiden van applicaties zoals Snap en Flatpak dat doen.

[Llopigat]

Dat afscheiden kan je ook op andere manieren oplossen. Selinux of apparmor bijvoorbeeld.

[R_Zwart]

In de praktijk heb je toch vaak dat applicaties verschillende versies van libraries nodig hebben. Als je uit moet gaan vanwelke libraries er geïnstalleerd staan op het doelsysteem, dan kan je als softwareleverancier veel problemen op je hals halen.

[henk717]

Niet alleen dat, toen ik nog ubuntu gebruiken waren al die snaps mount points wat weer erg vervuilde in sommige software. Heb het nooit een prettige architectuur gevonden en het centrale aspect vond ik ook helemaal niets.

Ben op mijn servers ook al jaren over op Debian om dezelfde redenen. En toen ik mijn eigen thin client distributie maakte wilde ik niet dat de thin client zou worden vervuild met snaps. Dus ook dat werdt debian.

[Cambionn]

Dat is een rede, maar verre van de enige. Van de technische implementatie tot aan de performance zijn er kritiekpunten over. Denk dat je een heel achtergrondverhaal kan schrijven over waarom snaps omstreden zijn .

[GertMenkel]

Ergens snap ik het wel. Als je in de applicatiewinkel zoekt naar "Firefox" wil je het liefste een enkel resultaat zien. Ik heb zelf Flatpak op mijn PC draaien en als ik gewoon even wat wil installeren vanuit Discover is het best irritant om te moeten kiezen tussen Firefoxᶠˡᵃᵗᵖᵃᵏ en Firefoxᴬᵁᴿ. Als daar ook nog eens Firefoxˢⁿᵃᵖ bij komt zijn helemaal de rapen gaar, en dan heb ik nog niet eens https://www.appimagehub.com/ gekoppeld.

Snap heeft enkele voordelen, zoals de mogelijkheid om vroeg in het bootproces te draaien. Het gebruik van "echte" mounts in plaats van de trucerijen die andere soortgelijke system uithalen heeft wat mij betreft ook wel wat, al zijn applicaties die een lijstje uit mount pakken en dat als een soort schijfletters gebruiken wel extreem irritant te gebruiken (maar dat waren ze zonder Snap ook al wel).

De allergrootste ergernis die ik aan het geheel overhoud is de map in mijn thuismap genaamd "snap" (zonder hoofdletter) en de vertraging bij het opstarten terwijl de mounts worden ingeladen. De manier waarop ze mensen dwingen om van apt naar snap te gaan vond ik ook niet heel chique van Canonical.

Toch vind ik Snap een prima systeem vanuit een technisch oogpunt. Ik snap best waarom Canonical het heeft gemaakt, het is alleen zo jammer dat ze de broncode van hun Snap store gesloten houden.

[Louw Post]

Ik vind Ubuntu een fijne distributie, maar die stap naar Snaps vind ik ook maar minder. Het heeft natuurlijk z'n voor- en nadelen, maar de nadelen wegen voor mij zwaarder dan de voordelen. Eén groot nadeel is dat het soms totaal niet te zien of een Snap van de officiële ontwikkelaar is van de applicatie. Ik heb geen idee in hoeverre dat gecontroleerd wordt?

Als je bijvoorbeeld naar Proton "publisher" gaat in de store, zijn sommige van die Snaps niet eens door Proton zelf uitgegeven, maar wrappers door anderen gemaakt.

https://snapcraft.io/publisher/proton-ag

[CH4OS]

Als je bijvoorbeeld naar Proton "publisher" gaat in de store, zijn sommige van die Snaps niet eens door Proton zelf uitgegeven, maar wrappers door anderen gemaakt.

Dit probleem is er met Flatpaks net zo goed, trouwens.

[Reactie gewijzigd door CH4OS op 7 juli 2026 19:31]

[GertMenkel]

Als je Flathub gebruikt, hoeft dat geen probleem te zijn, mits de flatpak zelf goed in elkaar is gezet: https://docs.flathub.org/docs/for-app-authors/verification

Als je andere repositories gebruikt, ben je afhankelijk van hun verificatiemethoden natuurlijk.

[GertMenkel]

Die vier snaps van Proton zijn juist wel door Proton gepubliceerd.

De snaps van Snapcrafters zijn dan wel weer verwarrend: https://snapcraft.io/search?q=publisher%3Asnapcrafters

Snaps hebben in dat opzicht iets betere verificatie dan bijvoorbeeld de AUR, de meeste Docker repositories, en natuurlijk PPA's/repositories van derden.

[The Zep Man]

Opvallend genoeg blijft het bedrijf de testversie van Debian gebruiken, ook wanneer Debian 14 verschijnt.

De testversie van Debian is niet zoals testversies van andere software. Bij Debian is dat alsnog best wel stabiel en een goede basis voor andere distributies.

[CH4OS]

Dat niet alleen, maar ook als straks Debian 14 wel uit is, gaat Testing gewoon door voor Debian 15. Het is dan dus veel meer een rolling OS.

[JayPe]

Oh, zoals ook bij Slackware, 15 is stable, maar current is de cutting edge rolling release ;-)

[CH4OS]

Ook weer niet helemaal, want bij Debian heb je ook nog unstable, ook dat is een rolling release, maar nog altijd geen cutting edge.

[Q]

Voor mij was er ook een aanvullende reden om Ubuntu de deur uit te doen en 'terug' te gaan naar Debian.

Ubuntu heeft de 'preseed' installer vervangen door 'autoinstall' en die wijziging gaf voor mij problemen omdat ik mijn hele PXE preseed install moest gaan ombouwen, zonder enig verder voordeel.

Nu is dit misschien niet zo relevant voor desktop Linux, maar ook met die snaps enzo, ik was er klaar mee.

[Oudecomputer]

Nou dan kom je bedrogen uit, want Debian gaat de rust core utils shipping omdat devs van Ubuntu ook voor Debian werken. En gaan huilen als je ze tegen doet spreken over wat een monster F up de rust utils zijn. Je hoort het niet hier maar ze zijn zo F@%^^# dat de devs ze bij Ubuntu niet eens kunnen gebruiken om de distro te compilen. Boven op het fujt dat vele features missen en het een grote security risk is.... ik zit zelf op mint die ook een Debian based versie hebben. Maar die snap en rust troep komt er bij mij niet in. Heb veel legacy systemen met 2 of 4 GB geheugen , die krijgen een beroerte als ik het over van snap heb..

[Xthemes.us]

Tjah, als je een basisversie kiest lijkt Ubuntu mij zo'n beetje de slechtste optie?
Die drukken vaak er dingen door waar de rest van de community het er niet mee eens is.

Lijkt me handiger om je eigen werk op een minder geopinieerde distro te baseren.

(Voor eindgebruikers snap ik het wel, Ubuntu is de meest gebruikte distro en dan is de kans dat je tegen eigenaardigheden aanloopt kleiner en de support groter)

[jbhc]

Ubuntu heeft kennelijk ook wel voordelen. Ondanks dat er LMDE is (Linux Mint Debian Edition) Is de basis distro van Mint nog steeds gebaseerd op Ubuntu. (Waar ze dan weer dingen als snaps uit gesloopt hebben)

[Oudecomputer]

En dat is maar goed ook, want snaps is niet het grootste probleem maar de core utils met rust! Of X11 totaal uitfaseren . Ik heb zelf diverse versies van mint en die werken prima. Ook in combinatie met X11 libre en gnome 2.

[Woefdramcx]

Logische keuze, vind ik.

Nooit fan geweest van Snap en Flatpack, en ingebouwde AI in m'n desktop of server zou ik ook niet moeten.

Ik gebruik Debian al dik 20 jaar, en heb in die tijd de nodige andere distro's geprobeerd. Een paar jaar geleden besloot ik Ubuntu maar eens te proberen, dat zou op een desktop de meest ideale distro zijn.

Na een weekje werken met Ubuntu, realiseerde ik me dat ik steeds bezig was om 't aan mijn smaak aan te passen... door het zo te maken als in Debian.

Toen dus maar weer teruggegaan naar Debian. Sindsdien niet meer omgekeken naar andere distro's.

[Mortov Molotov]

Loop je dan niet tegen het probleem aan dat bv je browser niet up-to-date is?

[ray0755]

Waarom zou een browser niet up-to-date zijn? Even Firefox als voorbeeld nemende, Debian levert niet de nieuwste versies, maar de laatste LTS-versie die gewoon updates krijgt.

[Hydranet]

Mijn werkstation op het werk heb ik een jaar geleden om dezelfde reden ook maar opnieuw geïnstalleerd met Debian en daarvoor eerst jaren Ubuntu erop heb gedraaid. Snaps had ik zelf al wel uitgeschakeld maar je moet dan ook nog eerst zelfs sources gaan toevoegen on normaal Firefox of Chromium te kunnen installeren. Heb al helemaal geen vertrouwen meer in gezien de kant Canonical aan het op gaan is, dus heb dan liever zekerheid met Debian als werkstation.

[GertMenkel]

Voor Debian moet je toch ook een repository toevoegen voor Firefox? Dat is in elk geval wel wat Mozilla aanraadt: https://support.mozilla.o...distributions-recommended

Ik vind juist de aanpassingen die Debian-ontwikkelaars doen redelijk ver gaan vergeleken met Ubuntu. Neem bijvoorbeeld het gedoe met Xscreensaver waar de auteur zoveel bugreports kreeg van Debian-gebruikers met een oude versie dat hij een melding had toegevoegd die na verloop van tijd een melding gaf om te upgraden, die er vervolgens vrolijk door de Debian-mensen uit werd gepatcht.

Dat Debian zelf backports doet en bugs repareert in oude versies is logisch, maar actief broncode weghalen vanwege een meningsverschil vind ik wel heel ver gaan.

[Hydranet]

Voor Debian moet je toch ook een repository toevoegen voor Firefox? Dat is in elk geval wel wat Mozilla aanraadt: [url="https://support.mozilla.o...distributions-recommended"]https://support.mozilla.o...distributions-recommended[/url]

Ik heb met welke distributie ik ook gebruik gewoon altijd Firefox uit repos van de distributie geïnstalleerd. Ik gebruik ook Firefox niet als mijn dagelijks web-browser dus het zal niet zo'n heel groot probleem zijn. Ben wel benieuwd wat de versie verschillen zijn tussen die en uit de Debian repos, anders kan ik 'm ook nog wel van Flathub halen want heb wel Flatpaks actief voor een applicatie waar geen normale Deb package voor is. Maar nu ik zo even terug denk dit is waarschijnlijk hoe ik 'm toen op Ubuntu geïnstalleerd heb, nadat ik Snaps helemaal verwijderd en geblokkeerd had.

[zalazar]

Een tijd terug was er een enterprise software leverancier die had bedacht dat een goed idee was om zijn software via Snap-packages te leveren.
Ik gaf al direct aan niet blij te zijn met Snap op een server maar dat werd niet direct begrepen.
Totdat we de software wilde installeren en bleek dat de Snap/Snapcraft Store down was.
Het duurde meer dan 4 uur voordat deze weer online was
Het was waarschijnlijk een incident maar je ziet direct dat je geen controle hebt.
Ook moet je veel moeite doen om automatische updates te voorkomen.
Flatpak is de betere keuze mede ook omdat je hiermee via een eigen repository kunt installeren.

[Grimm]

Hier staat uitstekend uitgelegd wat er nu precies mis is met Ubuntu's snap:

https://linuxmint-user-guide.readthedocs.io/en/latest/snap.html

[Bathing Aap]

Tijd om over te stappen op een fatsoenlijk read-only/immutable OS distributie (ala Android), zoals eentje uit de Universal Blue – Powered by the future, delivered today familie! Doei Debian!

[Luchtbakker]

Tijd om over te stappen op een fatsoenlijk read-only/immutable OS distributie (ala Android), zoals eentje uit de Universal Blue – Powered by the future, delivered today familie! Doei Debian!

Het is mooi, en tegelijk vind ik dit het allergrootste nadeel aan het gehele Linux omgeving. Er zijn serieus veel distro's waar je uit kunt kiezen met ieder zijn eigen voordelen. Maar zo maak je Linux nooit een échte killer naast Windows.

Waarom niet de krachten bundelen en 1 -2 waanzinnig goede distro's maken?

[InflatableMouse]

Dat doen ze all. 99% van de code base van Linux komt van dezelfde source en dus van dezelfde ontwikkelaars. Verschillen in distro's zijn relatief klein. Package manager, andere default config, desktop environment. Is allemaal niet zo spannend eerlijk gezegd. Versies verschillen natuurlijk, sommige leveren oudere packages onder het mom van stabiliteit, andere lopen meer voor. Sommige doen staged releases andere rolling releases maar veranderen zelf maar relatief weinig aan de code zelf.

En wat de grotere distributies echt zelf ontwikkelen vind in verreweg de meeste gevallen de weg terug naar upstream, en komt dan (vaak / deels) weer in de rest van de distro's terecht.

Universal blue is ook "gewoon" Fedora Silverblue of Kinoite, waar ze hun eigen sausje overheen hebben gegoten. Weinig bijzonders aan, eerlijk gezegd.