Tuxedo OS verruilt Ubuntu voor Debian vanwege Snap en AI-koers van Canonical

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. Naarmate 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 zijn 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 (129)

[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.

[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.

[Xander2]

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.

Security & maintenance. Je krijgt gratis bugfixes als de shared libraries een beetje API standaarden volgen, i.e. een beetje volwassen libraries. Verder zal een containerstructuur extra code en lagen toevoegen wat kwetsbaarheid toevoegt, vgl. NodeJS.

Vervelend voor de developer, robuuster voor het eindproduct en ik snap de noodzaak en use-case voor commerciële proprietaire software maar voor opensource (Firefox blegh) zie ik geen reden waarom je een eigen tree moet onderhouden die alleen de developer controleert.

Ik zie dan meer in een systeem met permissies als Android zonder extreme isolatie (proces geheugen is al geïsoleerd) via SELinux o.i.d.

[tpeeters]

Het Snap package systeem begon ooit als 'Click' packages voor Ubuntu Phone, wat weer was afgekeken van de Android apps waarbij alle dependencies met de applicatie worden bijgeleverd.

Als ontwikkelaar wil je juist de hele tree van dependencies onderhouden, zodat je applicatie voorspelbaar draait, en niet afhankelijk is van de toevallige versie van libraries die op een systeem draaien. In een ideale wereld zullen minor/micro releases van de libs je je gebruikt inderdaad nog steeds blijven werken met jouw app. Helaas is dat in de praktijk heel vaak niet het geval, daarom is het het veiligst om precies te weten welke versie van de libs je app gebruikt. Daardoor voorkom je dat bij een systeem update in the libs jij als app developer meteen een update moet uitbrengen om te zorgen dat jouw app blijft werken.

Natuurlijk heeft alles zijn voor- en nadelen. Als je een supersnel lean systeem wil hebben is het vaak beter om inderdaad dynamisch gelinkte apps te leveren. Maar als je een desktop applicatie levert voor niet-technische gebruikers, dan is een snap/flatpack/android app handiger.

[delphium]

Als ontwikkelaar wil je juist....

Als ontwikkelaar heb jij helemaal niets te willen. Ik gebruik distro A en jij zult als ontwikkelaar genoeg credits moeten verzamelen om in de repositories van distro A te komen.

Lukt jou dat niet, dan hoef ik als gebruiker van distro A jouw software simpelweg niet. Als ik dat toch zou willen, dan download ik jouw source-code wel, maar anders moet je gewoon je plaats kennen als ontwikkelaar van software die kennelijk niemand interessant vindt.

[L0g0ff]

Mis je met die mindset niet heel veel mooie software?

[tpeeters]

Haha. Als ik als hobby open source software schrijf, waarom zou ik dan niet schrijven wat ik wil?

En als het als standaard in een distro komt is dat alleen maar mooi.

[GertMenkel]

Voor security geef ik je gelijk als het op de snelheid van patchen aankomt, maar voor maintenance is het echt een drama om iedere applicatie te moeten backporten naar oude versies. Zodra ik de nieuwe OpenSSL uit de repositories haalde, compileerde de helft van de programma's niet meer omdat ze per se OpenSSL 1 vereisten. Het duurt maanden voordat de repositories een beetje bij zijn, en lang niet iedere bibliotheek stopt moeite in het onderhouden van oude versies.

Aan de andere kant komt het nog wel voor dat Redhat er een week of wat over doet om hun backports te testen terwijl de applicaties van Flatpak op de dag dat er een patch is al bijgewerkt zijn. Het ligt er maar net aan wie er eerder patcht. Gelukkig is Canonical daar redelijk snel in. Debian wat minder, Arch is een beetje met de dobbelstenen rollen, SUSE en dergelijke durf ik niet zo te zeggen.

Android gebruikt hetzelfde model als Flatpak en Snap, namelijk dat iedere app zijn eigen bibliotheek meeneemt. Als je een toestel met root hebt, moet je eens in de /data/app map zoeken naar ELF-bestanden; de meeste apps hebben hun eigen binaries (al dan niet statisch gecompileerd waardoor je de versies niet makkelijk ziet).

De standaardbibliotheek van Snap is wat karig, maar de bibliotheek van FreeDesktop, die zo'n beetje elke GUI-flatpak gebruikt, is aardig met die van Android te vergelijken. GUI-API's, netwerk-API's, noem maar op, het zit allemaal in gedeelde pakketten.

Ik zie dan meer in een systeem met permissies als Android zonder extreme isolatie (proces geheugen is al geïsoleerd) via SELinux o.i.d.

Dat, gecombineerd met namespaces (wat Android ook doet tot zekere hoogte), is praktisch hoe deze technologie ook op Linux werkt. De sandboxing-API's waar deze technologie mee werkt is niet bijster anders dan die van Android, alhoewel Android een zelfingericht model gebruikt dat wat verder afwijkt van de norm.

Juist omdat Android weinig speciaal doet (behalve twee kerneldrivers gebruiken voor IPC die vaak standaard worden weggelaten voor beveiligings- en stabiliteitsredenen), kun je via Anbox en vrienden zonder virtuele machine Android-applicaties op Linux draaien. Helaas werken veel apps echter niet zomaar: je moet wel de juiste platformversie van de APK hebben, want de ARM-libraries die op je telefoon draaien, doen het niet zomaar op je amd64-computer.

[HollowGamer]

Met Android heb je precies hetzelfde probleem, want je target een bepaalde SDK versie als minimum.

Containers zijn heel anders. Daar wil je juist echt controle over de versies, aangezien je die normaal bouwt met een actie en dan tests laat runnen bij elke package upgrade.

[Llopigat]

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

[GertMenkel]

Snap confinement werkt op basis van AppArmor, seccomp, en namespaces. Flatpak gebruikt Bubblewrap in plaats van AppArmor maar is niet heel anders.

Je kunt je programma's zelf in Bubblewrap of een ander runtime verpakken als je de isolatie wil hebben, maar als je losse profielen met schrijfbare tijdelijke ruimte wilt configureren, zit je effectief Flatpak of Snap na te bouwen om hetzelfde te bereiken.

[HollowGamer]

Dat is geen sandboxing. Flatpak en snap doen dit wel.

[Llopigat]

Nee ik weet het maar het effect is hetzelfde. Je kan afschermen wat een applicatie kan doen. Welke bestanden het bij kan en welke processen.

[HollowGamer]

Dat is dus geen sandboxing. Verder moet je als SELinux rules hebben en ben je afhankelijk van labels. Die hebben overhead en kunnen net zo goed overal bij als die regels niet worden bijgehouden.

Een sandbox is echt meer dicht. Sterker nog, je kunt nog niet eens zien dat er andere apps zijn. Voor permissies is dit ook eenvoudiger, want je werkt dan met een portal.

Voor beide is iets te zeggen, en beide hebben ook elkaar nodig.

[cdwave]

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.

Disk en RAM gebruik is maar een aspect van het kunnen delen van code. Naarmate je meer code kunt delen wordt onder andere de CPU cache efficiënter. Ook de MMU heeft het veel makkelijker als er meer gedeeld wordt.

Zo zal bijvoorbeeld de malloc() routine in zo'n beetje alle processen dezelfde zijn (uit glibc.so ofzo). Dat betekent dat ook na diverse context switches de malloc() routine zich nog wel in de instructie cache van de CPU zal bevinden, en dus veel sneller kan worden uitgevoerd. En dat geldt voor heel veel gemeenschappelijke routines.

[GertMenkel]

Dankzij side channel attacks is het een risico om je cache tussen processen te delen, dus ik vraag me af of je met context switching veel bespaard door bibliotheken te delen.

Qua RAM-gebruik heb je wel gelijk, maar als de hoeveelheid shared objects uitmaken op het RAM-gebruik van je systeem, dan ben je al behoorlijk ver heen.

[BleghBlarg]

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.

Scheelt ook in geheugen gebruik, vandaag juist weer relevant. Ben het wel met je eens dat als je moet zorgen dat je applicatie al die versies ondersteund dat je winst al snel kwijt bent. Vooral omdat sommige software elke major alles overhoop gooit.

[delphium]

Wat je eigenlijk zegt is dat Flatpak, Snap, AppImage, vooral heel erg makkelijk is voor developers die binaries opleveren. Dus developers die software bouwen, die niet in de officiele distro repositories staat.

De kracht van distro's als Debian is juist dat alle software van hetzelfde team komt en je dus zeker weet dat het werkt, snel gepatchd wordt en geen troep bevat. Zoals @cdwave ook al aangeeft, is dat hoe opensource moet werken. Dat dit er soms voor zorgt dat je een iets oudere versie dan de nieuwste gebruikt op een distro, hoort daar ook bij.

Persoonlijk zal ik nooit, maar dan ook echt nooit software uit Flatpacks of andere containerformaten vertrouwen op mijn systeem. Wil jij graag dat ik jouw software gebruik, dan lever je maar de source-code. Dan compileer ik het zelf wel tegen mijn (zelf gekozen en gecompileerde) systeembibliotheken.

De praktijk laat helaas zien dat wat werkte voor mainframes en workstations in de jaren '90 niet werken op een moderne Linux-distro.

Nou, nee hoor. Gedeelde bibliotheken werken nog steeds prima, ook voor moderne Linux-distro's. Het enige probleem dat Flatpacks oplossen is dus dat het lekker makkelijk is voor developers en dat ze voor meer distros hun software kunnen verspreiden. Dat is leuk voor distro's die erop gericht zijn een zo groot mogelijk publiek aan te spreken (Linux gaat Windows verslaan op de desktop!), maar dat zijn niet de distro's die open-source-liefhebbers willen draaien.

Ik vind het echt enorm jammer dat steeds meer mensen vallen voor oplossingen die keihard indruisen tegen de oorspronkelijke gedachte achter open-source. Vrijheid om code te gebruiken, maar dus ook aan te kunnen passen en te begrijpen wat het doet. Ik vind het derhalve begrijpelijk dat Tuxedo overstapt op juist die distro, die die kernwaarden al decennia heel hoog in het vaandel heeft.

[GertMenkel]

Gedeelde bibliotheken werken prima voor Debian omdat het doel van Debian anders is dan dat van Canonical. Caonical wil enigszins recente software aanbieden aan hun distro's om de overhead van het bijhouden van zes verschillende versies te minimaliseren, Debian wil hun drie tot vier versies zelf patchen (al duurt het daarom soms een paar weken/maanden voor alle versies de security-updates hebben).

Canonical onderhoudt momenteel een gigantische hoeveelheid pakketten voor hun 16.04, 18.04, 20.04, 22.04, 24.04 en 26.04 branches, met selecte software die zelfs op 14.04 nog wordt bijgewerkt. Het lijkt me logisch dat ze dat makkelijk proberen te houden.

Dit heeft helemaal niets met "het idee van open source" te maken. De DLL-structuur wordt net zo goed in Windows gebruikt en zo'n beetje elke Snap en Flatpak heeft zijn broncode op internet staan. Je kunt en mag iedere regel code zelf compileren. Sterker nog, doordat deze tools de compiler doorgaans zelf in een container-achtig systeem leveren, is het juist makkelijker om je eigen wijzigingen aan te brengen: het bespaart je de tijd om specifieke versies van gcc/llvm/rustc/golang te configureren, je kunt heel eenvoudig specifiek de dingen veranderen die jij wilt veranderen.

Je kunt argumenteren dat het outsourcen van alle broncodecompilatie door een klein clubje mensen bij Debian/Canonical/Red Hat juist tegen de principes van open source in gaat, want nu ben je overgeleverd aan hun keuzes voor bibliotheekversies en patches. De echte open-source-ontwikkelaars die hun broncode publiceren, zitten bij de grote distro's verstopt achter een muur van maintainers die bepalen of je software wel de moeite waard is, welke versies goed genoeg zijn, en wanneer de updates nou echt uitkomen. De bug trackers van KDE/Gnome staan dan ook vol met bugs voor versies die niet meer worden bijgehouden en bugs die al lang opgelost zijn omdat de tussenlaag ze nog niet heeft toegepast voor hun eindgebruikers.

Welke upstream Tuxedo neemt, is aan hun natuurlijk. Ik vind in dit geval Canonical's standpunten over slopcode een stuk relevanter dan of hun open source binaries in een .deb of een Snap worden geleverd.

[delphium]

Gedeelde bibliotheken werken prima voor Debian omdat het doel van Debian anders is dan dat van Canonical. Caonical wil enigszins recente software aanbieden aan hun distro's om de overhead van het bijhouden van zes verschillende versies te minimaliseren, Debian wil hun drie tot vier versies zelf patchen (al duurt het daarom soms een paar weken/maanden voor alle versies de security-updates hebben).

Hoe verklaar je dan dat een distro als Arch, wel de meest recente versies aanbiedt? Arch werk ook met shared libraries en hoeft geen zes versies van hun aangeboden software aan te bieden. Het klopt gewoon niet wat je zegt. De reden dat Canonical Snaps aanbiedt, is dat ze graag de Linux-Desktop groot willen maken en dan vooraan in de rij willen staan.

Debian is altijd rete snel met beveiligingsupdates, alleen doen ze dat via backports. Dus ondanks dat je een oudere versie draait, is er wel degelijk een patch uitgerold.

Dit heeft helemaal niets met "het idee van open source" te maken. De DLL-structuur wordt net zo goed in Windows gebruikt en zo'n beetje elke Snap en Flatpak heeft zijn broncode op internet staan.

Ja, dat heeft het wel, want in jouw Flatpak zit ook heel veel software van derden, waarvan jij (als aanbieder) niet kunt aantonen dat jouw binaries de broncode bevatten van de officiële source. Distro als Dedian en Arch kunnen dat wel. Ik begrijp ook niet waarom je Windows aanhaalt, want dat heeft werkelijk niets met FOSS te maken.

Je kunt en mag iedere regel code zelf compileren. Sterker nog, doordat deze tools de compiler doorgaans zelf in een container-achtig systeem leveren, is het juist makkelijker om je eigen wijzigingen aan te brengen: het bespaart je de tijd om specifieke versies van gcc/llvm/rustc/golang te configureren, je kunt heel eenvoudig specifiek de dingen veranderen die jij wilt veranderen.

Met als gevolg, dat je zelfs de compiler niet meer kunt vertrouwen. Waarom biedt je als developer niet gewoon alleen je broncode aan dan? De enige reden daarvoor is dat jij (ik bedoel niet letterlijk jij, Gert Menkel) als developer, je software makkelijker kunt verspreiden en niet hoeft te wachten tot een distro het als relevant aanmerkt.

Je kunt argumenteren dat het outsourcen van alle broncodecompilatie door een klein clubje mensen bij Debian/Canonical/Red Hat juist tegen de principes van open source in gaat, want nu ben je overgeleverd aan hun keuzes voor bibliotheekversies en patches.

Nee, natuurlijk niet. Dat geldt alleen voor de meegeleverde software en in de keuze voor een distro ben je nog altijd vrij. Het is toch logisch dat Debian (dat ik steeds als voorbeeld gebruik), controle wil houden over welke softwareversies ze uitbrengen? Anders wordt hun systeem instabiel. Als iets niet in de repositories staat, dan kun je de broncode downloaden en het zelf compileren.

De echte open-source-ontwikkelaars die hun broncode publiceren, zitten bij de grote distro's verstopt achter een muur van maintainers die bepalen of je software wel de moeite waard is, welke versies goed genoeg zijn, en wanneer de updates nou echt uitkomen.

Dat heeft alles te maken met een compleet systeem dat stabiel moet zijn. Het heeft ook te maken met keuzes die een bepaalde distro heeft gemaakt. Keuzes die ook bij de distro moeten liggen en vooral niet bij de developers!

Ik vind in dit geval Canonical's standpunten over slopcode een stuk relevanter dan of hun open source binaries in een .deb of een Snap worden geleverd.

Ik weet niet wat je bedoelt met "slopcode", maar als Canonical aantoonbaar controleert wat er in hun Snaps terecht komt, geeft ik je gelijk op dit punt. Dat neemt nog steeds niet weg dat het een rommelig en inefficiënt systeem oplevert. Dat is dan ook de reden dat ik zelf kies voor een zorgvuldig zelf samengesteld en extreem stabiel systeem op basis van Gentoo.

[GertMenkel]

Hoe verklaar je dan dat een distro als Arch, wel de meest recente versies aanbiedt? Arch werk ook met shared libraries en hoeft geen zes versies van hun aangeboden software aan te bieden. Het klopt gewoon niet wat je zegt. De reden dat Canonical Snaps aanbiedt, is dat ze graag de Linux-Desktop groot willen maken en dan vooraan in de rij willen staan.

Arch biedt een hele kleine set pakketten aan en laat regelmatig ononderhouden software vallen.

Debian is altijd rete snel met beveiligingsupdates, alleen doen ze dat via backports. Dus ondanks dat je een oudere versie draait, is er wel degelijk een patch uitgerold.

Dat ligt enorm aan de software. Chromium-pakketten hebben nogal de neiging om enorm achter te lopen omdat het backporten van securityfixes voor een browser gigantisch veel tijd kost. Debian kan natuurlijk niet eventjes een nieuwere versie van Chromium in de oude releases stoppen om de fixes gratis mee te krijgen, dus niet alles patches komen in dit soort gigapakketten en het duurt vaak een tijd om ze te krijgen als de backports wel worden gemaakt.

want in jouw Flatpak zit ook heel veel software van derden

Dat hoeft helemaal niet? Als je de basis van FreeDesktop pakt, heb je amper nog libraries nodig.

waarvan jij (als aanbieder) niet kunt aantonen dat jouw binaries de broncode bevatten van de officiële source

Dat kan wel; met reproducible builds kun je de inhoud verifiëren (of geen software installeren die dat niet doet). Vaak worden gewoon de pakketten van een distro als Debian gepakt als basis, en Debian heeft reproducible builds al (bijna) voor elkaar.

Ik begrijp ook niet waarom je Windows aanhaalt, want dat heeft werkelijk niets met FOSS te maken.

Dat is mijn punt natuurlijk, dynamic link libraries (Windows) en shared objects (Linux+BSD) zijn exact hetzelfde ding met een andere extensie. Je kunt open source zijn zonder DLL's te gebruiken, of closed source zijn en al je functionaliteit uit DLL's halen. De twee concepten zijn niet met elkaar verbonden.

Met als gevolg, dat je zelfs de compiler niet meer kunt vertrouwen.

Dat kun je nooit, tenzij je hem zelf vanuit handgeschreven assembly boostrapt, en zelfs dan moet je maar vertrouwen dat het bestandssysteem bevat wat je OS claimt dat het bevat.
De compilers komen van het Flatpak project van FreeDesktop. Mocht je die niet vertrouwen, kun je zelf de broncode nagaan en de boel zelf bouwen natuurlijk, met de compilers van Debian die je mogelijk wel vertrouwt.

Waarom biedt je als developer niet gewoon alleen je broncode aan dan?

Dat doen ze ook? Ik heb nog geen closed-source Flatpak gezien, al is het theoretisch mogelijk. Maar goed, iedere .deb kan dat in theorie natuurlijk ook.

Het is toch logisch dat Debian (dat ik steeds als voorbeeld gebruik), controle wil houden over welke softwareversies ze uitbrengen?

100%, maar je geeft wel controle uit handen, zoals je ook doet wanneer je een Snap of Flatpak downloadt.

Als iets niet in de repositories staat, dan kun je de broncode downloaden en het zelf compileren.

Ik durf met zekerheid te stellen dat 99% van de mensen dat niet kan. Het overgrote deel van de SteamOS-mensen ook niet, en ik betwijfel dat het merendeel van de Ubuntu-gebruikers zover komt.
Als je het kunt is dat natuurlijk een optie, maar je kunt ook gewoon de binary downloaden.

Keuzes die ook bij de distro moeten liggen en vooral niet bij de developers!

Keuzes die de distro 100% moet maken, zeker. Maar als eindgebruiker die een stuk software wil downloaden dat ik op Github heb gevonden, is het onhandig als die keuzes niet met mijn doelen overeenkomen.

Ik weet niet wat je bedoelt met "slopcode"

Ik heb het over dingen als dit: https://discourse.ubuntu....ure-of-ai-in-ubuntu/81130
Ubuntu omarmt AI en dat is niet een hele populaire mening in de open-source-wereld.

Dat neemt nog steeds niet weg dat het een rommelig en inefficiënt systeem oplevert.

Qua efficiëntie geef ik je gelijk, al vraag ik me af of het nog een probleem is tegenwoordig. Qua rommeligheid vind ik het juist fijn dat ik in één keer een applicatie van mijn systeem kan donderen en niet hoef uit te zoeken welke (build) dependencies er achterblijven in mijn /usr/lib-map. Ik zit op mijn thuis-PC op een /usr-map die groter is dan een schone Windows-installatie en zoveel API's heb ik voor zover ik weet ook niet geïnstalleerd.

[delphium]

Mijn hele punt is dat vanuit een architectuurperspectief, shared libraries een veel beter concept is dan Flatpaks, of Snaps. Natuurlijk zijn er situaties te bedenken waarin een flatpak uitkomst biedt, maar vrijwel altijd is er dan ook een alternatieve oplossing beschikbaar waarin je wel je shared libraries handhaaft (virtualisatie).

In theorie heb je vast gelijk dat ook met een Flatpak makkelijk te achterhalen is of de binaries kloppen en dat aanpassingen makkelijk te doen zijn, maar in de praktijk worden die bestanden lukraak gedownload en gedubbelklikt. Het hele systeem is namelijk bedoeld voor onervaren eindgebruikers.

Claimen dat het shared libraries-systeem verouderd is en niet meer van deze tijd, is gewoon kneiterharde onzin. En als je dan een binary-based distro gebruikt, tja dan zit je vast aan wat zij aanbieden. Het staat je vrij om over te stappen naar een source-based distro die wel toestaat om zelf pakketten te compileren. Weet je niet hoe dat moet, of vind je het te veel gedoe, dan kies je voor Windows of Mac.

Mijn beleid is dat ik nimmer flatpaks, Snaps of AppImages op mijn systeem zal toelaten. Onder geen beding en volgens mij heb ik dat goed onderbouwd. Ik blijf bij mijn Gentoo-systemen, waarvan sommigen al jaren (+ twaalf jaar!) stabiel hebben gedraaid, zonder ook maar enig probleem. En het is niet dat ik nooit experimenteer. Ik weet wel waar ik mee bezig ben.

[GertMenkel]

Shared libraries zijn een beter concept, dat ben ik met je eens, maar de wereld is helaas imperfect.

Ik zeg niet dat het shared-library-systeem niet meer van deze tijd is, alleen dat de eisen waar die uit voort zijn gekomen niet meer van deze tijd zijn. Toen men de UNIXen en eerste Linuxen in elkaar aan het zetten was, was het te overzien om iedere regel code nog een keer zelf te compileren. Dat kan met Gentoo nog steeds natuurlijk, maar in de praktijk is het niet meer zo eenvoudig als dat het vroeger was, juist doordat software (helemaal open source) tegenwoordig zo uitgebreid is.

Weet je niet hoe dat moet, of vind je het te veel gedoe, dan kies je voor Windows of Mac.

Deze mentaliteit is precies waarom Linux zo'n gedrocht is. Android, ChromeOS, en SteamOS laat zien dat je normale mensen prima Linux kunt geven. Ik vind het frustrerend hoe hard sommige mensen vrije software uit de handen van normaal volk willen houden omdat die niet willen klooien met compilers.

Je moet vooral bij Gentoo blijven als je daar goed zit en ik zeg ook niet dat jij van Gentoo af moet. De grote voordelen van open source voor mij (ondanks dat ik prima Gentoo zou kunnen draaien) en vele anderen is juist dat jouw eisen niet de mijne zijn. Canonical richt zich dan ook niet op de Gentoo-gebruiker, evenmin als Debian of zelfs Arch dat doen.

[tpeeters]

Hoe zijn de apps op je telefoon gepackaged dan?

[Donny K.]

Sorry, maar ik ben het niet met je eens. Hoe mooi het idee ook is (ik was vroeger zelf een groot voorstander van die aanpak), in de praktijk blijkt het toch veel haken en ogen te hebben.

Ik gebruik Linux al sinds de late 90's en heb door de jaren heen een aantal leuke applicaties en games verzameld die ik nog steeds graag gebruik. Een mooi voorbeeld is de Zod Engine, een open-source multiplayer-remake van de strategiegame Z. Die zou ik graag nog op moderne systemen spelen, maar op een schone, actuele Linux-installatie krijg je de oorspronkelijke Linux-versie niet meer zonder veel handmatig werk aan de praat.

De binary is onder andere afhankelijk van libmysqlclient.so.16 en libwx_gtk2u_richtext-2.8.so.0, libraries die al jaren uit de repositories van moderne distributies zijn verdwenen. Daarnaast loopt de launcher tegen fouten aan zoals een verkeerde ELF class omdat een 32-bit library wordt verwacht terwijl alleen een 64-bit variant aanwezig is.

Het handmatig installeren van nieuwere libraries helpt meestal ook niet. Een binary is immers gelinkt tegen een specifieke ABI. Zodra die ABI incompatibel is gewijzigd, is een nieuwere versie geen drop-in vervanging meer. Vervolgens kom je al snel in de klassieke dependency-hel terecht: Je moet plug-ins installeren, libraries vervangen en soms een hoop programma's installeren die je eigenlijk niet nodig hebt, maar je moet wel omdat er een specifieke dependency wordt meegeleverd. Met een beetje pech hebben deze programma's weer andere dependencies nodig die ook weer niet bestaan op moderde systemen en voor je het weet navigeer je door een doolhof van tools, plug-ins en libraries die je nodig hebt om de vereiste libraries te kunnen installeren (en die tools hebben ook weer hun eigen dependencies die niet compatibel zijn of niet te vinden zijn voor je moderne systeem).

Ik heb voor de grap eens geprobeerd om de game toch werkend te krijgen op een moderne Ubuntu-installatie. Dat is uiteindelijk gelukt, maar daarvoor moest ik oude libraries naast moderne versies installeren, symlinks aanpassen en delen van het systeem buiten het pakketbeheer om wijzigen. De game werkt nu, maar veel andere applicaties werken op dat systeem nu slecht of niet. Dit is precies het soort dependency-hel waar AppImage, Flatpak en Snap voor bedoeld zijn. Niet omdat ontwikkelaars te lui zijn om pakketten te maken, maar omdat distributies nu eenmaal oude libraries en ABI's opruimen. Dat is begrijpelijk vanuit onderhoud en beveiliging, maar het betekent ook dat oudere binaries na verloop van tijd niet meer werken. Door de benodigde afhankelijkheden mee te leveren blijven applicaties ook over vijf of tien jaar nog gewoon starten.

Om te voorkomen dat ik (en anderen) in de toekomst weer tegen hetzelfde probleem aanlopen, heb ik uiteindelijk alle benodigde libraries, plug-ins en losse .so-bestanden verzameld en er zelf een AppImage van gebakken. Dat was een tergende klus ( probeer de tools om een AppImage te bouwen maar eens aan de praat te krijgen op een systeem dat je eerst hebt moeten verbouwen om de game überhaupt werkend te krijgen). En ja, het klopt, het eindresultaat is inderdaad bijna vier keer zo groot, maar daar staat tegenover dat de game nu met één dubbelklik draait op vrijwel iedere moderne Linux-distributie waarop ik hem heb getest.

Dus ja, gedeelde systeembibliotheken werken prima... zolang de benodigde ABI's beschikbaar blijven. Maar juist dat blijkt in de praktijk vaak niet het geval. Voor software die jarenlang mee moet gaan, zijn containerformaten wat mij betreft geen stap achteruit, maar juist een praktische oplossing voor een probleem waar Linux al decennia tegenaan loopt.

Mocht je de game trouwens willen proberen, je kunt hem hier downloaden.

[delphium]

Jouw voorbeeld is toch helemaal niet representatief? Je hebt het over een zwaar verouderde game, die jij als individu graag aan de praat wil krijgen op een goed werkend en stabiel Linux-systeem. Dat is niet waar mensen dagelijks tegen aanlopen en bovendien zijn daar andere opties voor zoals virtualisatie.

Het hele concept "dependency hell" bestaat al decennia niet meer op moderne linux-systemen, tenzij je het over jezelf afroept natuurlijk.

Anyway, Snap of Flatpak aanprijzen als oplossing voor een niet bestaand probleem, vind ik ronduit dubieus.

[Donny K.]

Zod engine was slechts een voorbeeld dat ik aanhaalde omdat ik er toevallig onlangs zelf tegen aanliep. Je hebt gelijk dat de klassieke dependency hell uit de jaren '90 grotendeels verdwenen is dankzij moderne package managers. Ik weet dat moderne package managers dit soort problemen met modernere apps een stuk beter oplossen dan toen. Maar ik doel op binaire compatibiliteit op de lange termijn. Wie zegt dat moderne applicaties over vijf jaar niet dezelfde problemen krijgen die ik had met Zod? Zodra een applicatie afhankelijk is van libraries of ABI's die een distributie niet langer levert, houdt die binary op met werken. Virtualisatie lost dat inderdaad op, maar Flatpak, Snap en AppImage lossen hetzelfde probleem op met veel minder overhead. Mijn punt is dus niet dat package managers slecht zijn, maar dat containerformaten een praktisch antwoord zijn op een compatibiliteitsprobleem dat package managers simpelweg niet kunnen oplossen zodra de benodigde libraries uit de distributie zijn verdwenen.

Maar goed, ik wil best een modern voorbeeld pakken: Davinchi Resolve. Toen Ubuntu overstapte van OpenSSL 1.1 naar OpenSSL 3 ontstonden problemen omdat Resolve (en diverse plug-ins) nog libssl.so.1.1 verwachtten terwijl Ubuntu alleen nog libssl.so.3 levert. De binary is dus gebouwd tegen een andere ABI. De community-oplossingen bestaan vervolgens uit het toevoegen van oude repositories, het handmatig installeren van verouderde libraries of het maken van symlinks.

[delphium]

In mijn ogen is het koste wat het kost willen draaien van bepaalde software, een heel specifiek probleem van verstokte Windowsgebruikers.

Normaalgesproken evalueer je als gebruiker mee met je systeem (of andersom ;-). Als bepaalde software wordt verstoten van een distro, is daar meestal een goede reden voor. Wil je toch, om wat voor reden dan ook, oude software blijven draaien, dan gebruik je een virtual machine of een container.

Container-formaten gebruiken op een productie-systeem (desktop of server) is vanuit architectonisch perspectief, gewoon een heel slecht idee. En daar laat ik het even bij.

[Donny K.]

Een complete virtuele machine draaien voor software als DaVinci Resolve lijkt mij nogal disproportioneel. Resolve leunt zwaar op GPU-acceleratie, videodecoders, OpenCL/CUDA en een lage I/O-latency. Dat kun je met GPU passthrough wel werkend krijgen, maar dat is voor de gemiddelde desktopgebruiker (in een productieomgeving) aanzienlijk complexer dan een Flatpak of AppImage starten. Dan heb je het niet meer over een praktische oplossing, maar over een workaround. En natuurlijk, Flatpak en AppImage zijn in feite ook containers. Het verschil is alleen de granulariteit. Jij stelt voor om een compleet besturingssysteem in een container of VM te draaien om één applicatie te kunnen gebruiken. Flatpak en AppImage verpakken alleen de applicatie met de afhankelijkheden die ze nodig heeft. Dat lijkt mij juist een veel lichtere en efficiëntere oplossing.

Je noemt containerformaten architectonisch een slecht idee. Waar baseer je dat op? Want een behoorlijk deel van het Linux-ecosysteem (van Fedora Silverblue tot GNOME en Canonical) zet juist steeds meer in op gecontaineriseerde desktopapplicaties. Ik ben heel benieuwd welk concreet architectonisch bezwaar jij zwaarder vindt wegen dan de voordelen op het gebied van compatibiliteit, distributie en isolatie. Maar goed, je hebt al aangegeven dat je het hierbij laat, geen probleem. Let's agree to disagree.

[delphium]

Een complete virtuele machine draaien voor software als DaVinci Resolve lijkt mij nogal disproportioneel.

Daar heb ik het toch niet over? DaVinci Resolve is op vrijwel alle moderne distro's gewoon verkrijgbaar.

Het verschil tussen een virtual machine en een Flatpak is dat je in het geval van de virtual machine absoluut zeker bent dat jouw systeem integer blijft. En Flatpaks draaien theoretisch ook in een sandbox, maar dan wel eentje die je hebt gedownload van Internet.

Je noemt containerformaten architectonisch een slecht idee. Waar baseer je dat op? Want een behoorlijk deel van het Linux-ecosysteem (van Fedora Silverblue tot GNOME en Canonical) zet juist steeds meer in op gecontaineriseerde desktopapplicaties.

Containerformaten zijn een "oplossing" voor het probleem dat steeds meer nitwits Linux gebruiken en graag altijd alle software willen kunnen installeren en dan ook nog eens de laatste versie.

Vanuit de architectuur wil je juist een systeem dat ultiem betrouwbaar is en waarvan je te allen tijde weet welke exacte versie van bepaalde software draait. Ook wil je dat aanvalsvectoren geminimaliseerd zijn. Dat betekent dat één versie van GLIBC draaien veruit de voorkeur heeft boven tien versies.

Dit is precies hoe distro's als Debian, Arch, maar ook Gentoo ontworpen zijn. Centraal beheer en van daaruit volledige informatie en controle. Containerformaten breken dat model, met als enige voordeel dat gebruiker ff-152 draait in plaats van ff-150. Qua beveiliging heeft dit geen enkel voordeel, omdat patches vaak worden gebackport (ff-150 op Debian, heeft alle patches die ff-152 Flatpak, of de originele binary ook heeft).

Daarnaast, ik noemde het al even, is centraal beheer belangrijk. Je wilt vanuit je package manager inzicht hebben in je gehele systeem. Dat kan alleen maar als je apps gezamenlijk gebruikmaken van je systeemlibs.

Maar ter afsluiting nogmaals: Wat lost Flatpak/Snap nu precies op? Wat is het probleem waar je tegenaan loopt en waarvan je denkt: nu wil ik echt een flatpak hebben, want dat is veruit de beste oplossing. Ik ben die situatie nog nooit tegengekomen.

[Donny K.]

Volgens mij kijken we inderdaad vanuit twee verschillende perspectieven naar hetzelfde probleem. Jij kijkt vooral vanuit de distributie, ik meer vanuit de applicatieontwikkelaar en de eindgebruiker.

Vanuit de distributie ben ik het grotendeels met je eens. Centraal pakketbeheer, één versie van een library en securitypatches backporten zijn sterke eigenschappen van Linux. Voor systeemcomponenten zou ik dat ook absoluut zo willen houden. Alleen lost dat een ander probleem op dan waar Flatpak of AppImage voor bedoeld zijn.

Je vraagt welk probleem ze oplossen. Voor mij is dat niet "ik wil Firefox 152 in plaats van 150". Het probleem is dat een ontwikkelaar onmogelijk iedere combinatie van distributie, libraryversies en ABI's kan ondersteunen. (Het maakt het voor ontwikkelaars in ieder geval veel eenvoudiger om één build voor meerdere distributies te onderhouden.)

Ik haalde DaVinci Resolve aan omdat dat een mooi en typisch voorbeeld is. Je zegt dat DaVinchi op vrijwel alle moderne distro's gewoon beschikbaar is, maar Blackmagic ondersteunt officieel maar een beperkt aantal distributies. Op Ubuntu, Debian, Fedora of Arch is de community regelmatig aangewezen op installatiescripts, patches of andere workarounds om Resolve goed werkend te krijgen. Dat is niet omdat apt of dnf slecht zijn, maar omdat Resolve uitgaat van een specifieke userspace en specifieke versies van bepaalde libraries. Een vaste runtime voorkomt precies dat soort problemen.

Daarom zie ik Flatpak of AppImage ook niet als vervanging van het pakketbeheer van een distributie, in tegendeel, maar als aanvulling daarop. Voor software die nauw verweven is met het systeem gebruik ik liever native packages (daarom ben ik ook niet blij met de SNAP richting die Ubuntu opgaat). Voor complexe desktopapplicaties vind ik een voorspelbare runtime juist een voordeel.

Ik denk dus niet dat containerformaten zijn ontstaan omdat gebruikers "altijd de nieuwste versie" willen. Ze zijn ontstaan omdat het Linux-ecosysteem ontzettend divers is geworden. Een ontwikkelaar wil kunnen zeggen: "Dit is de omgeving waartegen ik getest heb en daarin weet ik zeker dat mijn software werkt." Dat is wat een runtime biedt. Ze lossen geen pakketbeheerprobleem op, maar een compatibiliteitsprobleem. Voor mij is dat de echte meerwaarde van Flatpak en AppImage.

[delphium]

Wat mij stoort, is dat er weer een groepje mensen is opgestaan dat een al decennia goed functionerend ecosysteem wil aanpassen ten behoeve van commercie. Want dat is wat ook jij beschrijft:

Jij gaat uit van gemak voor de ontwikkelaar:

Het probleem is dat een ontwikkelaar onmogelijk iedere combinatie van distributie, libraryversies en ABI's kan ondersteunen. (Het maakt het voor ontwikkelaars in ieder geval veel eenvoudiger om één build voor meerdere distributies te onderhouden.)

Het juiste uitgangspunt zou moeten zijn: de gebruiker wil pakket A of B en de distro voorziet daarin. Ik heb echt schijt aan al die (veelal bijzonder slechte) ontwikkelaars, die mij hun pakket door de strot willen duwen. Zeker als die ontwikkelaars ook nog eens mijn zorgvuldig geconfigureerde systeembibliotheken gaan negeren en hun eigen versie meeleveren.

Een ontwikkelaar wil kunnen zeggen: "Dit is de omgeving waartegen ik getest heb en daarin weet ik zeker dat mijn software werkt." Dat is wat een runtime biedt.

Daarmee leg je de controle bij individuele ontwikkelaars. Dat is echt zo extreem onwenselijk! De controle moet altijd liggen bij de distro. Dat jij als developer een plekje wilt in de repositories van de distro, daar zul je hard voor moeten werken.

Dus nogmaals, containerimages zijn in de meeste gevallen gewoon zeer onwenselijk. Het zorgt er ook voor dat de Linux-jeugd een totaal verkeerd signaal krijgt.

[tpeeters]

De enige distro die ik ken die zo werkt is MS Windows.

Maar even serieus: Elke Linux distro is afhankelijk van de ontwikkelaars van de software en libraries waaruit hun distro is opgebouwd. Je kunt wel vanalles gaan eisen zoals jij voorstelt, maar dan houd je geen apps meer over.

Misschien dat OpenBSD een beetje in die richting gaat, maar die hebben dan ook beperktere keuze uit welke software dat in hun distro gaat. Ze hebben wel een Ports systeem, maar dat is dan weer onderhouden door een grote groep vrijwilligers, dus de controle daarvan ligt niet 'bij de distro'.

[Reactie gewijzigd door tpeeters op 8 juli 2026 21:39]

[RogerWilco2]

Apple gebruikt een flatpak/Snap-achtige oplossing sinds de eerste versie van OSX/MacOS. (Mogelijk daarvoor NeXT ook?) Het maakt installeren en verwijderen zoveel makkelijker. Gooi de .app op je systeem en je kunt het gebruiken, gooi de .app weg en het is weer verwijderd. Geen package management, niks compileren/source/makefile aanpassen, geen (de-)installatie wizards, etc. Alleen spul dat hardware/kernel drivers moet installeren/verwijderen is wat lastiger, maar dat zijn maar weinig.

Dit is ook het model dat iOS en Android volgens mij gebruiken voor "apps", Android weet ik niet zo goed.

het kost iets meer RAM en diskspace, maar als dat in 1999 al niet echt een probleem was, en op smartphones ook niet, dan zou het op de meeste desktops ook geen probleem moeten zijn.

[delphium]

Dat is in mijn ogen niet vergelijkbaar, omdat Apple ook strikte controle uitoefent op de AppStore. Dan weet je in elk geval (min of meer) zeker dat de software betrouwbaar is.

Maar om terug te komen op het concept: het biedt zeker gemakken, maar als hardcore Linux-gebruiker (niet specifiek Delphium, maar een analogie) zit ik echt helemaal niet te wachten op het gemak dat ik een app in mijn prullenbakje kan gooien en dat dan alles verwijderd is. Fuck dat.

Als hardcore Linux-gebruiker weet ik exact, maar dan ook echt exact, wat er op mijn systeem geïnstalleerd is. Ik doe alles het liefst via de command-line en ik wil dus ook graag exact weten van welke versie van cURL gebruik wordt gemaakt, of welke versie van GCC ik gebruik en welke kernel ik heb, met welke opties.

Kortom, jouw argumenten zijn misschien geldig voor mensen die streven naar een Linux-desktop voor iedereen, maar het leeuwendeel van de FOSS-community zit daar helemaal niet op te wachten. Dat is de reden dat de FOSS-community Ubuntu niet zo lief vindt.

Ubuntu is net als WSL overigens een entiteit, die de open-source-gedachte zeer veel kwaad doet. Dat heeft niet zozeer met conservatisme (van mijn kant) te maken, maar met het respecteren van de kernwaarden van open source.

Je kunt niet, nooit, op geen enkele manier, open-source waarderen en tegelijkertijd commerciële belangen nastreven. Dat is waar Canonical, Microsoft, maar ook Apple de fout ingaan. Ze nemen wel, maar geven te weinig of niet.

En dan gaan we weer de discussie krijgen dat MS juist heel veel heeft bijgedragen aan de Linux-kernel, maar welbeschouwd is dat allemaal ten behoeve van MS-belangen.

[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]

[GertMenkel]

Debian heeft het geluk dat de meeste bedrijven binaries maken voor Debian (in elk geval voor amd64). Dat lukt je op andere distro's niet zo snel.

Qua individuele updates heb je gelijk, maar dat geldt ook voor de applicaties zelf. Als een ontwikkelaar zijn applicatie niet op tijd updatet, kun je veilig zijn tegen een OpenSSL-lek, maar ben je nog steeds kwetsbaar voor lekken in de applicatie zelf die niet worden opgelost.

Overigens zijn in mijn ervaring de meeste binaries die voor Debian worden vrijgegeven statisch gecompileerd of komt met hun eigen libraries (want ze zijn bedoeld voor Debian + Ubuntu + Mint + afgeleiden en Arch pakt ze vaak ook mee via de AUR), dus die vlieger gaat vaak alleen maar op voor de software die je uit de repository van je distro haalt. Zo is de .deb van VS Code bijvoorbeeld gevuld met, libEGL, libffmpeg, libvulkan, en een binary van 200MiB die het grootste gedeelte van Chromium bevat. De copyright notice bevat nog veel meer items, die zullen wel statisch worden gecompileerd.

Het idee van shared libraries is heel mooi, maar het werkt alleen voor projecten als Debian, Ubuntu, Fedora/Red Hat, en openSUSE. Als losstaande ontwikkelaar die geen zin heeft om zes versies te onderhouden (aannemende dat je alleen de laatste LTS wilt ondersteunen), moet je een andere oplossing zoeken.

[Llopigat]

Qua individuele updates heb je gelijk, maar dat geldt ook voor de applicaties zelf. Als een ontwikkelaar zijn applicatie niet op tijd updatet, kun je veilig zijn tegen een OpenSSL-lek, maar ben je nog steeds kwetsbaar voor lekken in de applicatie zelf die niet worden opgelost.

Ja maar die ontwikkelaars zullen dat meer als hun verantwoordelijkheid zien dan libraries die ze meeleveren. En vaak verouderd omdat ze gebruik maken van zulke sandboxing technieken waardoor ze niet hun code hoeven up te daten naar nieuwere versies.

Het idee van shared libraries is heel mooi, maar het werkt alleen voor projecten als Debian, Ubuntu, Fedora/Red Hat, en openSUSE. Als losstaande ontwikkelaar die geen zin heeft om zes versies te onderhouden (aannemende dat je alleen de laatste LTS wilt ondersteunen), moet je een andere oplossing zoeken.

Maar de meeste ontwikkelaars onderhouden helemaal geen packages. Dat doen de maintainers van de distro's.

Zelfs op FreeBSD heb je alles gewoon en dat is veel meer werk dan op Linux omdat er serieuze verschillen zijn die in de apps gepatcht moeten worden. Dat doen alle port maintainers. De meeste applicaties ondersteunen helemaal niet eens BSD. Dat wordt er bij geknutseld door die maintainers.

En zo doen de meeste distro's dat. Eigenlijk allemaal. De ontwikkelaars publiceren hun code gewoon op github. En de distro's packagen dat zelf.

Pakketten die alleen als binary gedistribueerd worden gebruik ik sowieso niet, ik gebruik altijd codium plaats van vscode. En chromium ipv chrome (al gebruik ik in de praktijk alleen firefox natuurlijk, chrome heb ik alleen voor 2 sites die een bug hebben met firefox)

[Reactie gewijzigd door Llopigat op 7 juli 2026 23:23]

[delphium]

Debian heeft het geluk dat de meeste bedrijven binaries maken voor Debian (in elk geval voor amd64). Dat lukt je op andere distro's niet zo snel.

Nee, developers hebben geluk dat er populaire distro's als Debian, RedHat en Arch bestaan. Als je pakketten bouwt voor die drie distro's weet je zeker dat je een groot publiek bereikt.

Het werkelijke probleem is dat developers geen zin hebben om voor meerdere distro's hun software uit te brengen en dus kiezen voor een lompe oplossing als Flatpak.

Zoals @Llopigat al aangeeft, is veiligheid wel degelijk een probleem. Software uit de repositories van je distro, zijn ondertekend en veilig. In een FlatPak kan een developer alles hebben gestopt. Maar zelfs als de developer niet kwaadaardig is, kunnen Flatpaks nog altijd gecompromitteerd zijn. Er is geen enkele centrale controle die garandeert dat die FlatPaks veilig zijn. Dat is zoals je zelf al eerder schreef, hoe Windows werkt en vanuit beveiligingsoogpunt een bijzonder slecht idee.

[Dat_Doen_We_FF]

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

Tjah, en niet iedereen wil een tweede SSD alleen om de OS te kunnen installeren, 30 GB voor een rauw OS waar niets opstaat is toch van de zotte? Een rauwe Debian install is ongeveer 1 GB....

En verder, dat delen van libs e.d. dat werkt op iedere distro al een aantal decenia, dus waarom dat nu ineens niet meer werkt?

En proton / wine is natuurlijk gewoon een translatie laag om windows systemcalls om te zetten naar iets wat de kernel begrijpt, geen idee waarom dat een voorbeeld zou moeten zijn waarom bibliotheken (zoals proton / wine) niet werken?

Je voorbeelden met PPAs komen ook wel een beetje uit 2006 ofzo, het is inmiddels 20 jaar later.

[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.

[Wim Cossement]

Bwah, dat kan toch perfect? Het is nu niet dat die verschillende library's zo veel ruimte innemen, maar het besturingssysteem moet er ondersteuning voor bieden...

Ik weet nog goed dat je bij Gentoo met slots kon werken, verschillende versies van hetzelfde pakket/bibliotheek, en als iedereen zich aan de nomenclatuur houdt via symlinks met de versieloze bestandsnamen en die met de versie erin zou je toch al ergens moeten geraken?

[humbug]

Het hergebruiken van libraries door verschillende applicaties heeft voor en nadelen. Met name het feit dat de ene applicatie bv versie 1.01 nodig heeft en de andere applicatie versie 1.2 zorgt er ook dat het vaak extreem lastig is om een set van applicaties gezamenlijk werkend te krijgen op een versie van een library waar ze allemaal mee overweg kunnen. In praktijk is het gebruik van oplossingen waarmee iedere applicatie zijn eigen dependencies mee neemt vaak een zege. Ja, het kost geheugen maar zelfs met de huidige geheugen prijzen is dat goed te verantwoorden doordat je niet uren/dagen bezig bent om applicaties werkend te krijgen.

[SilentLucidity]

Helemaal mee eens. Maar ik weet niet of je wel eens de Tweakers podcast luistert, maar daar grappen ze heel vaak over het jaar van Linux op de desktop. De push naar snap of flat is voor dat doel niet gek: niet de uberlinux ervaring met lage loads, maar veel regelen om zaken werkend te krijgen, maar 'het werkt gewoon'.

[Xander2]

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.

Dan wordt dynamisch inladen van optionele libraries een probleem en o.a. glibc kan niet statisch worden meegelinkt.

[HollowGamer]

Flatpaks doen dit gewoon hoor. Sowieso hebben ze SDKs en gebruiken ze ostree om dups te voorkomen.

[jabwd]

statisch linken is een stuk lastiger dan je denkt, en voor veel software is het zelfs niet eens een optie (zoals games). Probeer je statisch en dynamisch, nou dat kan dus niet want de dynamic linker van linux zit... yep, in glibc, maar niet in de static variant. Ga je zelf aan de slag met dynamic linking dan is de kans op memory corruption dankzij glbic ook weer heel hoog.

Het stukje gedeelde memory kan, maar niet echt op Linux. Daarom is het hele verhaal over memory delen ook niet zo heel relevant. Hebben flatpaks dezelfde runtime dan delen ze dat gewoon alsnog. In principe eigenlijk niet eens echt anders dan het zooitje dat glibc voor elkaar gekregen heeft.

wat eigelijk best wel vaag is, op Linux is de kernel verschrikkelijk stable en kan je er stabiel op leunen ( op NT en XNU gaat je dat niet lukken, heb je ntdll en libSystem voor nodig). Het is zo verschrikkelijk jammer dat portable software voor Linux z'n hellscape is.

[Reactie gewijzigd door jabwd op 7 juli 2026 23:26]

[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.

[Guru Evi]

Zowel snaps als flatpaks kunnen mij gestolen worden. Ik zou liever een degelijke TCP/IP integratie zoals X11 zien met de 'moderne' DMs zodat dingen in 'standaard' containers gestoken en oudere OS (hoeveel software zit niet vast aan RHEL7, 8 etc) kan gedraaid worden of zelfs op afstand/andere hardware gedraaid. Tot dan zal ik verplicht worden om xfwm4 te draaien.

Zoiets als https://distrobox.it/ is voor mij de ideale oplossing.

[jurriaan]

Als gebruikers van een vrij nieuwe Tuxedo laptop met het OS voel ik me ergens toch wel een beetje bedrogen. Niet dat ik de stap afkeur, maar ik heb blijkbaar de afgelopen minder updates gekregen dan gebruikelijk. Dat en ik heb - na overgestapt te zijn van een dell xps met ubuntu - net mijn laptop nu weer helemaal ingericht hoe ik het wilde. Nu moet ik weer een nieuwe installatie uitvoeren of achter gaan lopen met updates. Dat hadden ze wat beter kunnen aanpakken, bijvoorbeeld door het allemaal niet achter de schermen te doen. Dan had ik in ieder geval keuzes kunnen maken

[Uruk-Hai]

Voordat ik mijn huidige zelfbouw pc als losse onderdelen in huis haalde en in gebruik nam, heb ik ook overwogen om een kant en klare pc van Tuxedo te bestellen. Dat werd mij hier op tweakers.net om meerdere redenen afgeraden, want:

1. Wat Tuxedo kan, kan een beetje tweaker zelf ook wel.
2. Een Tuxedo computer is honderden euro's duurder dan zelfbouw.
3. Tuxedo is meer een kwestie van marketing dan dat het technisch echt verschil maakt.

Ik heb gewoon standaard pc onderdelen besteld, vrij nieuw nog en daar de allerlaatste versie van Linux Mint op geïnstalleerd. Ik ben geen enkel probleem tegen gekomen.

Ik installeer voor Laptop Revive regelmatig Linux Mint op willekeurige oude Windows laptops. Het is me nog nooit niet gelukt om dat goed werkend te krijgen.

Nu ik jouw reactie zo lees ben ik des te blijer dat ik destijds even de moeite heb genomen om hier op tweakers.net GoT te vragen of het wel zo slim om zo'n kant en klaar Linux systeem te kopen.

[jurriaan]

Het was mijn werklaptop en het heeft voordelen om een bedrijf te kunnen aanspreken als er iets mis is. Zij zorgen op zich ook dat alles iig werkt met hun hardware. En ik ben erg tevreden over de laptop en de prestaties (ook al is het inderdaad een aangepaste XMG EVO 15). Maar inmiddels heb ik de laptop overgenomen en zou ik de keuze nu niet meer maken. En inderdaad, dit komt daar nog eens bovenop

[Uruk-Hai]

Ik zie dat de XMG EVO 15 een ultrabook is. Ik heb zelf nu een zwaarder stoeptegel model van HP. Maar daar valt mee te leven. Er zijn ergere dingen in het leven.

Hoeveel issues heb jij met je Tuxedo laptop gehad waar je zelf niet uit had kunnen komen?

En hoe tevreden ben je met helpdesk van Tuxedo qua reactiesnelheid en tijd en aandacht die ze aan je besteden?

[Reactie gewijzigd door Uruk-Hai op 8 juli 2026 01:24]

[jurriaan]

Tot nu toe geen echte issues gehad. 1 keer een vraag gesteld op hun reddit, daar toen geen antwoord op gekregen, maar er uiteindelijk zelf uitgekomen. Dat was echter maar een kleine issue. Via de reddit ervaar ik dat men wisselend over hun klantenservice denkt, niet altijd positief. Maar er zijn daar iig wel mensen van tuxedo vrij actief aanwezig.

[HollowGamer]

Je gaat nu juist sneller updates krijgen. Misschien vind je een andere distro interessanter? De meeste hebben dacht ik hun tools in de repos.

[jurriaan]

Ja.. als ik dus overga naar de nieuwe versie, wat komt als een nare verrassing. Zoals te lezen in het artikel hebben ze de laatste tijd dus minder updates uitgebracht omdat ze druk waren met het ombouwen.

[HollowGamer]

Dat zal reuze meevallen, aangezien Ubuntu vrijwel Debian volgt in updates. Enkel voor hun eigen major packages waren uitzonderingen.

[Mark de Vaal]

maar ik heb blijkbaar de afgelopen minder updates gekregen dan gebruikelijk.

Gewoon een vraag. Waarom is dat verkeerd?

Ik heb Arch gedraaid en werd gek van die update meldingen. Ik heb dit uit gezet en 1 keer in de week ging ik een update draaien.

[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.

[Louw Post]

Bij 2 van die Snaps staat het volgende:

"NOTE: This is a wrapper of the official package, but it is not verified, affiliated with, or supported by Proton AG."

Dat voelt wat onbetrouwbaar.

[Llopigat]

Dat klinkt eng, maar de meeste gewone pakketten op linux distributies worden ook niet gemaakt door de ontwikkelaars van de software zelf.

[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..

[tpeeters]

bron?

[Oudecomputer]

Op reddit was het al een jaar geleden gemeld.

Maar lunduke heeft er nu een video over gemaakt omdat developers het nu gaan pushen

Ubuntu developer doet rust zwaar pushen

[tpeeters]

Dit gaat niet over een Ubuntu developer, maar Director of Engineering @ Mozilla. Daarnaast is hij lead van uutils en Debian dev, en in die hoedanigheid heeft hij ook geholpen met de adoptie van uutils in Ubuntu. Zoek anders zijn eigen LinkedIn ff op, in plaats van een politiek verhaaltje over Ubuntu te verzinnen wanneer de bedenkers van Rust (Mozilla) de taal zo veel mogelijk willen verspreiden

[Oudecomputer]

Het is een politieke/ religieuze beweging die rust doet verspreiden! En mensen bij Ubuntu pushen actief deze gare uutils . De zelfde uutils die laatst gigantische security check list faalde maar wel in de bèta en nightly builds zaten en bijna alle testen niet door kwamen met compatibiliteit of security. En het maar blijven pushen dat andere distributies deze uutils ook standaard gebruik terwijl ze zelf niet eens hun eigen distro mee kunnen compileren!!!!! Deze persoon werkt voor Mozilla maar ook voor Ubuntu en Debian en pushed de gare rust uutils en mensen luisteren naar die bagger onzin . Want ze zijn niet klaar en hij kan niet tegen tegen spraak . Vindt hij te confronterend. Met rust taal is niets mis maar de nieuwe core uutils zijn nog niet klaar! Bij lange na niet! Die ze pas pushen als de oude tils niet mee voldoen of dat de compatibiliteit goed genoeg is en dat is het bij lange na niet!

[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.

[tpeeters]

X11 uitfaseren is geen Ubuntu beslissing. Ubuntu gebruikt standaard de Gnome desktop, en Gnome ondersteunt geen X11 meer.

[Oudecomputer]

X11 support totaal uitfaseren dat het niet meer kan werken is wel degelijk een keuze. Je geeft je gebruikers geen keuze meer.

Ik zelf draai mint cinamon mate gnome 2 en xfce Want ik heb oude computers en remote logins onder walyland is …

[tpeeters]

X11 support is uit upstream Gnome verwijderd.

Als je een andere desktopomgeving zoals XFCE in Ubuntu draait dan werkt dat gewoon met X11.

[FlyBock]

Ook na het lezen van het artikel hierover op de site van Tuxedo Computers begijp ik deze keuze niet. Dat ze van Ubuntu weg willen, dat snap ik wel, maar om dan voor Debian Testing te gaan, dat is, nou ja, onverwacht. Testing heeft bijvoorbeeld periodes van package freezes waarin geen security updates uitkomen, en er zijn ook andere quircks.

“Compared to stable and unstable, next-stable testing has the worst security update speed. Don't prefer testing if security is a concern.”

Van: https://wiki.debian.org/DebianTesting

Als je nou kijkt waar de trends liggen, dan zie je dat Arch-based distributies opkomen -CachyOS, KDE Linux, Steam OS- en ook Immutable is steeds meer in. Door te rebasen naar Debian kijk je naar het verleden ipv de toekomst.

[Llopigat]

Als je nou kijkt waar de trends liggen, dan zie je dat Arch-based distributies opkomen -CachyOS, KDE Linux, Steam OS- en ook Immutable is steeds meer in. Door te rebasen naar Debian kijk je naar het verleden ipv de toekomst.

Maar dat is ook de kracht van het ecosysteem van Linux. Voor iedereen wat wils.

Sommigen willen het modernste wat er is met immutable enzo. Anderen zoals ik blijven liever zoals het is als het werkt. Ik vind het al irritant genoeg dat er bijna geen distro's zonder systemd meer zijn.

Nieuwer is niet per se beter, en Ubuntu heeft er een handje van om dingen zonder goede reden te veranderen. Ik ben er zelf ook al jaren weg.

[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.

[Mortov Molotov]

Net dat bedoel ik: security fixes

[Llopigat]

Die krijgt de LTS versie gewoon. Daar is het juist LTS voor.

Nou zou ik liever ook de nieuwste versie willen hoor, daar niet van. Maar daar heb je mozilla's PPA voor.

[Reactie gewijzigd door Llopigat op 8 juli 2026 06:20]

[Mortov Molotov]

Klopt.

En hoe zit het met de versioning van Mesa gpu drivers?

[Llopigat]

Als je echt per se de nieuwste drivers nodig hebt dan zit je idd niet goed met een LTS release model. Maar dat gelft niet voor iedereen natuurlijk.

[Reactie gewijzigd door Llopigat op 8 juli 2026 08:29]

[Woefdramcx]

Die wordt tegenwoordig redelijk bijgehouden in Debian, maar omdat er online steeds strenger gecontroleerd wordt of je wel de allerlaatste nieuwe versie draait, haal ik m'n browser direct op bij Firefox zelf en laat ik de Debian-packages voor wat ze zijn.

[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.
Toen 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.

[Reactie gewijzigd door zalazar op 7 juli 2026 22:31]