Linux Mint 20 blokkeert ongevraagde installatie van Ubuntu's Snap - update

Het aankomende Linux Mint 20 gaat de installatie van Ubuntu's Snap via APT-packages blokkeren. Snap zou zichzelf sinds Ubuntu 20.04 installeren via de Chromium-package, zonder toestemming van gebruikers. Gebruikers kunnen Snap nog wel handmatig installeren.

Snap is een alternatieve manier om Linux-applicaties te installeren. Het is ontwikkeld door Canonical, het bedrijf achter Ubuntu. Het ontwikkelteam van Linux Mint maakt de beslissing kenbaar in een blogpost. De Linux-distributie werd al niet geleverd met voorgeïnstalleerde Snap-packages, maar in de aankomende Linux Mint 20-release neemt het team enkele extra maatregelen. Zo kunnen APT-packages niet zonder toestemming Snap installeren op de systemen van gebruikers.

De hoofdontwikkelaar van Linux Mint, Clement Lefebvre, sprak in juli 2019 al zijn zorgen uit over Snap. Canonical zou van plan zijn geweest om het Google Chromium-pakket in de package-base van Ubuntu te verwisselen met een leeg pakket, dat op zijn beurt de Snap-versie van de webbrowser installeert. Hiermee zou Snap een vereiste worden voor gebruikers, en zou het zichzelf installeren zonder dat gebruikers daar toestemming voor geven, schrijft de ontwikkelaar. Ook gebruikers die Chromium al geïnstalleerd hebben op hun systeem, zouden op die manier worden overgezet naar de Snap-variant wanneer de applicatie wordt geüpdatet. "Dit breekt een belofte van de Snap-developers dat het nooit APT zou vervangen."

In de package-base van Ubuntu 20.04 heeft Canonical dan ook de Chromium-package in kwestie vervangen, meldt Lefebvre. "Het Chromium-pakket is inderdaad leeg, en fungeert nu als een backdoor door computers zonder toestemming te verbinden met de Ubuntu Store." Gebruikers kunnen de geïnstalleerde Snap-pakketten daarnaast ook 'niet controleren, vasthouden of aanpassen', schrijft Lefebvre. Volgens hem is Snap hiermee vergelijkbaar met commerciële, gesloten oplossingen.

Mede om deze redenen heeft het ontwikkelteam van Mint naar eigen zeggen besloten om maatregelen te nemen. Zo zal Chromium volgens de ontwikkelaar geen leeg pakket zijn dat de Snap-daemon installeert. In plaats daarvan vervangt het team deze package met een 'leeg pakket dat gebruikers vertelt waarom het leeg is, en instructies bieden voor het installeren van Chromium'. Ook kunnen APT-packages standaard niet de Snap-daemon installeren. Gebruikers kunnen er wel voor kiezen om Snap handmatig te installeren.

Canonical zelf heeft in oktober een blogpost opgesteld waarin het bedrijf de reden geeft voor de transitie van Chromium naar Snap. Zo noemt de ontwikkelaar onder andere als reden dat het 'onderhouden van een enkele release erg veel tijd vergt', omdat 'reguliere' packages voor iedere afzonderlijke Ubuntu-release moeten worden opgebouwd, waaronder LTS- en niet-LTS-releases. Een Snap-package werkt echter met alle verschillende releases. Daarnaast stelt het bedrijf dat de impact van de transitie minder groot is, omdat Chromium niet de standaardbrowser voor Ubuntu is.

Update, 17:18: Canonical heeft eerder een blogpost geschreven waarin het bedrijf redenen geeft voor de transitie van de Chromium-package naar Snap. Deze is toegevoegd aan het artikel.

De Cinnamon-versie van Linux Mint 19.3. Afbeelding via Linux Mint

Reacties (214)

[NotHere]

Wat ik persoonlijk erg irritant vindt aan snap, naast dit rare gedoe van Canonical, is dat snap packages in een of andere soort van sandboxed omgeving runnen waarbij het volledig onmogelijk is om zaken zoals generieke window manager styling settings door te geven aan een snap-applicatie.

Dit valt voor mij het meeste op in mijn Xubuntu installatie met Chromium. Ik gebruik in Xubuntu de default muiscursor, maar zodra ik mijn cursor op een Chromium window zet verandert hij van stijl naar iets wat ik erg lelijk vindt (zeker het handje als je over een link hovert).

Zolang applicaties user-settings negeren gebruik ik ze liever niet, maar wat betreft Chromium heb ik met Xubuntu 20.04 ineens geen keus meer.

[Bux666]

Waarom gebruik je niet Firefox? Zit standaard bij Ubuntu en Mint en is behoorlijk aanpasbaar.

[NotHere]

Ik gebruik beide, dat vind ik makkelijker dan een Firefox-multiprofile setup.

[84hannes]

offtopic:
Er zijn redenen om Chromium te gebruiken, helaas. Veel websites worden alleen op Chromium's varianten getest. Maar het opzetten van verschillende containers is echt makkelijker dan twee verschillende browsers gebruiken: je kunt een website met twee klikken in een andere container openen. Bijvoorbeeld, als blijkt dat ik voor een website in moet loggen met mijn google-account dan open ik die bewuste website in mijn Google-account-container en ben direct ingelogd. Het is ook veel schaalbaarder dan verschillende browsers gebruiken.

[NotHere]

Goede tip, ik was nog niet bekend met die containers.

[84hannes]

Ze zijn geweldig. Er is ook een container-plug-in specifiek voor Facebook, maar het is natuurlijk naïef te denken dat Facebook de enige onbetrouwbare IT-grootmacht is. Eigenlijk zou ik voor elke website waar ik kom een eigen container willen om cookies te isoleren en tracking waardeloos te maken, maar dat is me teveel werk. In elk geval krijg ik tegenwoordig steeds vaker reclame voor sport of zweverige cursussen dus ik ben er vrij zeker van dat ze alle grip op mijn interesses kwijt zijn 😀

[Conjacq]

Ik merk die sandboxomgeving ook in Thunderbird. Als ik een attachment in een ander programma wil openen, dan geeft hij niet het standaard programma. Een simpele PDF openen is dan al erg omslachtig.

[woutervb2]

Je mist denk ik, dat dit feitelijk applicatie virtualalisatie is.
Misschien niet volmaakt mbt theming, maar noem me een andere werkende poging die op alle distributies werkt zonder problemen.

Op Windows met appv e.d. is het trouwens niet veel beter, tenminste de laatste keer dat ik keek.

[killerdemon]

Is er geen Linux Mint .deb welke op ubuntu te installeren is?

[Dubbeldrank]

Ik snap de ophef niet zo, prima dat ze het doen, dat kan met open source. Snap is verder niet schadelijk, en het lost een aantal problemen op die zich voor kunnen doen. Niets mis met een eigen kijk op zaken, dat hebben wel meer mensen in open sourceland. Maar de reacties hier vind ik nogal overtrokken voor hetgeen waar het over gaat.

Verder steun ik bedrijven als Canonical, zij proberen dingen. Niet altijd met evenveel succes, dan draaien ze het weer terug of stappen ergens anders op over. Maar het feit dat ze het doen is positief in mijn ogen, als de innovativiteit er niet meer is dan sterft het. En ja ik weet dat ze ook discutabele beslissingen hebben genomen wat betreft Amazon in Unity, maar dat vind ik niet vergelijkbaar met dit.

[Eonfge]

Snap is verder niet schadelijk

Snap is helaas wel schadelijk voor het Linux ecosysteem. Snap is namelijk gecentraliseerd.

Theoretisch kan elke Linux machine Snap draaien, maar er kan maar een partij Snaps verspreiden: Canonical. Dit geeft Canonical ongezond veel macht en dit gaat in tegen alle decentrale en gedistribueerde ideeën waar Linux voor staat. Nu is de schade nog te overzien... maar zodra commerciële partijen en overheden alleen nog maar Snap ondersteunen, dan kan Canonical op elk moment bepalen (of gedwongen worden) om bijvoorbeeld torrent-clients weg te halen, of VPN ondersteuning. Ook voor bedrijven niet leuk... want straks kan Canonical gewoon doodleuk 30% vragen van jouw software omzet.

Vergezocht? Echt niet. Apple en Google hebben hier bijvoorbeeld veel mee te maken. Torrent clients zijn verboden in Apple's walled garden, en VPN's zijn ook verboden als je op de verkeerde plek bent geboren. Snap is het gevaar van de Google and Apple walled gardens, voor Linux.

Ik ben sinds een jaar betrokken bij Flatpak en ik draag er aan bij om software te distribueren. Ik heb gekozen om Flatpak te steunen juist als beweging tegen Canonicals acties. Flatpak is de concurrerende technologie welke gefederaliseerd is. Iedereen kan zijn eigen Flatpak server opzetten en deze kunnen naast elkaar werken.

[Dubbeldrank]

Dit is een behoorlijk theoretisch verhaal waarin jij behoorlijk biased bent. Dat geeft niet, iedereen mag zijn of haar kijk op zaken hebben en dat kan gelukkig ook. Maar ik vind het nogal wat beschuldiging van iets dat in zijn totaliteit nog niet voor is gekomen vanuit Canonical. Daarnaast zeg je dat iedereen zijn eigen Flatpakserver kan opzetten, daar schuilt natuurlijk ook wel een gevaar in.

[Xacky]

@Eonfge beschuldigd niemand ergens van, de persoon stelt slechts dat het een mogelijkheid creëert voor machthebbende partijen om een store te censureren. Dat is geen beschuldiging dat is slecht een vaststelling van een feit.

De tegenwerping is dat gedecentraliseerde oplossing deze mogelijkheid niet of of mindere mate hebben. Iets wat inherent aan het Flatpaksysteem is.

[MrFax]

Ja Canoncial wil maar al te graag een nieuwe App Store of Play Store worden, dat is ook allemaal vanuit 1 partij. Waarom mag Canoncial het dan niet?

[woutervb2]

Op welke feiten baseer je dit? Volgens mij is het niet zo dat ze dit afdwingen en de snap cliënt staat gewoon op github (ook een centrale tool) dus het staat iedereen vrij om hier of toevoeging aan te leveren die andere stores mogelijk maakt, of te forken

[i-chat]

op de feiten dat cononical langzaamaan en stilletjes essentiële onderdelen van het OS naar snaps verplaatst .... dat is het bewijs van 'afdwingen' vervolgens zeg je: de snapclient staat op git (hub) en daar ga je met jouw opmerking vreselijk de fout in.

zeggen dat iets op github staat is wezenlijk fout ... het staat in essentie in GIT op Github..
het verschil. git kun je zelf (intern of extern) hosten en github repo's kun je clonen (of pullen) naar je eigen server zonder verlies van informatie. en daarmee is github dus juist géén centraal systeem het is simpelweg het meest gebruikte platform binnen één systeem.

[woutervb2]

Welke onderdelen bedoel je dan precies?
Los van ubuntu core dan, want dat is expliciet gemaakt rondom snaps.

Daarnaast staat het ieder vrij om eigen snaps te publiceren en te installen. Dan heeft een ieder ook controle over het moment van installeren.

Ook kan de refresh van snapd naar 30 dagen gezet worden. Dus dat betekend dat er tijdens die periode niets geupdate wordt, tenzij een gebruiker zelf hiervoor kiest.

[MrFax]

Alleen heeft forken geen nut: Dat zegt niet dat Canoncial hier gebruik van gaat makken. Ook pull requests zijn nog steeds aan Canoncial om ze te committen of niet. Dat is hetzelfde probleem met Chromium van Google en waarom de megahoge marketshare een probleem is.

[84hannes]

Die andere twee zouden het ook niet moeten hebben. Gecentraliseerde oplossingen zijn op de lange termijn nooit een goed idee: het legt heel veel macht in handen van één partij.

[Verwijderd]

Ieder moet altijd zelf nog wel dan die gevaarlijke Flatpakserver toevoegen aan zijn lijst met bronnen, net als met een standaard package manager. Die keuze heb je, met de passende waarschuwingen.
Als je er van uit gaat dat mensen zomaar nieuwe bronnen/repo's toevoegen, zijn er wel grotere gevaren dan een kwaadwillende applicatie in een flatpak.

[Daoka]

Aan de andere kant zullen mensen ook gewaarschuwd hebben voor dingen zoals dat Google te groot zo worden voordat Google echt groot was. Die hebben nu gelijk gehad. Dus echt biased of gewoon geleerd van het verleden? En uiteraard onschuldig tot schuld is bewezen. Maar aan de andere kant dingen ongevraagd installeren is wel een stap in de verkeerde richting.

P.s. Ik ben geen linux gebruiker. Ik was gewoon nieuwsgierig waar de artikel over ging. Vooral omdat ik altijd hoor van in Linux heb je altijd alles zelf in de hand.

[caipirinha]

Flatpak mag dan een niet gecentraliseerd alternatief zijn maar het is wat mij betreft net zo'n gedrocht.
Voorbeeld: een tooltje van 16kB installeerde ooit 5 GB aan bagger gewoon met apt-get zonder waarschuwing.
Dat was echt een WTF momentje voor me en ik heb de hele flatpak infrastructuur van mijn mint machine gegooid. Flatpak komt er hier niet meer in. En snap ook niet want dat ljkt me vergelijkbare rommel.

[Verwijderd]

Dat lijkt mij meer een Ubuntu of Mint probleempje dan Flatpak. Ja Flatpak installeert een gedrocht aan dependencies dubbel t.o.v. een echte package, maar dat zou je eigen keus moeten zijn. Onder Debian (Devuan om specifiek te zijn) heb ik nog nooit gezien dat apt een flatpak gaat installeren.
Daarnaast lijkt mij dit stiekeme ook helemaal niet de bedoeling van de Flatpak-ontwikkelaars, maar het geklooi van Canonical. Als ik Chromium in apt op Debian opzoek heeft deze geen dependency op flatpak en wel op een waslijst aan native libraries.

[Eonfge]

Dat is omdat een 16kb programma gebruikt maakt aan 500 MB aan bagger dependencies. Je hebt die 500 MB al eens eerder gedownload, tijdens de installatie van jouw basis systeem.

Flatpak werkt met runtimes, waarbij je eenmalig de runtime voor bijvoorbeeld GNOME of KDE download, en deze vervolgens kunt delen met andere applicaties. Dit betekend dat je inderdaad eenmaal alle GNOME of KDE libraries nodig hebt die het programma gebruikt. Daarna is het niet meer nodig en dan hoef je alleen nog maar de applicatie te downloaden.

Als je eenmaal over de eerste download heen bent, dan is Flatpak ongeveer even efficiënt als apt. Die waarschuwing is overigens niet aanwezig in de UI maar via de CLI zou je die wel moeten krijgen. Kwestie van gebruikersgemak voor de minder ervaren gebruikers.

[Reactie gewijzigd door Eonfge op 22 juli 2024 15:56]

[Hydranet]

Ik ben ook van mening dat de snap store opensource zou moeten zijn, maar ik kwam dit interview tegen was beste interessant om het is van de andere kant te zien.

[Eonfge]

Het is ook vanuit een bedrijf interessant om niet open source te zijn. De grootste monopolies in de IT wereld zijn van hele agressieve, closed source, software boeren. De Apples, Microsofts, Googles en Adobes willen alle macht en controle houden, want dat betaald lekker.

Daarom is het de taak van onze als kritische gebruikers om alert te zijn en om ons technische leven niet te laten gijzelen door enkele leveranciers die elk moment de spelregels kunnen aanpassen.

[woutervb2]

Wat is het verschil met github? Dat is toch ook gecentraliseerd en tools als travis dwingen je om een github account te gebruiken, wat gewoon geaccepteerd wordt door iedereen

[smitae]

Ja en nee, snap voelt voor mij zeer onhandig. Ik heb eigenlijk geen controle meer over de installatie, dat is mogelijk handig als je minder ervaring hebt met Linux. Maar ik wil toch echt zelf bepalen hoe en waar ik het installeer. Desnoods build van source-code.

Ben op zich wel blij met Ubuntu, maar zit toch hevig te denken om maar weer terug te gaan naar Centos of opzoek te gaan naar een andere debian based Linux smaak. Thuis heb ik liever 1 smaak, op de Pi is het raspberian of plain ubuntu. Dus gebruik van Ubuntu op mijn server en desktop leek mij wel handig.

Keuzes keuzes... Dat maakt Linux juist zo leuk

Maar snap gebruik ik niet meer was het helemaal zat.

[dutchnltweaker]

Je hebt ook nog Pop OS dat Ubuntu/Debian based, peppermint OS en alle andere Debian based distros of zelfs gewoon Debian.
Dus why stick with Ubuntu? Genoeg smaken.

[tvtech]

Ik had Plex server via snap geïnstalleerd. Werkte maar al mijn films staan op een externe schijf die ik gemount had en gewoon kon benaderen. Maar Plex kon er niet bij. Een paar keer van alles geprobeerd met rechten ed. maar ik kreeg het niet aan de praat. Toen de installer gedownload en via terminal geïnstalleerd waarna het wel werkte. Nu ben ik een beginner op Linux gebied dus gedeeltelijk zal het aan mij liggen, maar dit maakte wel dat ik niet direct het voordeel van snap zie.

[Blubkens]

Snap zorgde bij mij voor problemen door automatisch de snap van docker te installeren. Docker had ik al draaien en na een update van ubuntu had ik ook de snap Docker draaien. Vervolgens lopen er 2 apps dezelfde command te draaien en kan bij niet starten.

Dus snap kan wel degelijk schadelijk zijn.

Link

[Reactie gewijzigd door Blubkens op 22 juli 2024 15:56]

[UPPERKEES]

De Snap backend is niet open-source.

https://techtudor.blogspo...aps-are-anti-pattern.html

[GhostShinigami]

Snap heeft ook nog als 'leuk' probleem dat het in je boot word ingeladen.. en bij mij, terwijl ik het al niet meer gebruikte (had slack via snap) meerdere snap pakketen die niet gede-installeerd waren. Dus ookal gebruikte ik nog 0 van de applicaties, werd de snap chain on boot ingeladen, en zorde voor meerdere seconden aan extra boot tijd (ja met ssd.....) echt absurd. Snap komt er bij mij tegenwoordig ook niet meer in, het idee is leuk, uitvoering er van in mijn ogen erg slecht. stap 1 bij een nieuwe install: remove snap voor mij.

[sig69]

Wat is Snap en waarom is dit blijkbaar een probleem?

[boudewijnrempt]

Een manier om, net zoals met flatpak en appimage, de applicatie met alle dependencies te verpakken en te distribueren. Het kan een probleem zijn omdat als je veel applicaties als snap (of flatpak, of appimage) installeert je gauw uit de harde schijf kan groeien. Snap komt uit Ubuntu's mobile phone os dagen, flatpak bestaat omdat Redhat wat last heeft van NIH en appimage is een grassroots ding dat door geen enkel bedrijf ontwikkeld wordt, maar gewoon door free software volunteers.

Zelf distribueer ik mijn Linux applicatie, Krita, als appimage, en dat bevalt goed; ik weet precies wat erin zit, kan waar nodig mijn dependencies patchen, en het draait overal zonder runtimes nodig te hebben.

Flatpak en snap hebben runtimes en kunnen die delen, zodat twee snaps of flatpaks samen maar een runtime geinstalleerd hebben. Ook hebben ze sandbox-achtige features, zodat sommige dingen soms niet werken, zoals drag&drop -- je moet als package maintainer daar dan rechten voor inbouwen. Flatpak en snap worden voor Krita door volunteers onderhouden en zijn niet officieel.

Het einde van het liedje is dat je vroeger iemand met een probleem moest vragen of ze de distributie package gebruiken of zelf Krita hadden gebouwd; nu vraag je ook naar was 't een snap, een appimage of een flatpak?

[delphium]

Maar dit verneukt toch het hele idee van shared libraries op een systeem? Straks heb je vijftien versies van GTK3 op je systeem, elk gebruikt voor slechts één programma. Het doet me denken aan de manier van software installeren op een Mac. Klik en sleep en het werkt. Een hele app met alle dependancies in één mapje. Deïnstalleren is mapje weggooien. Of heb ik het bij het verkeerde eind nu?

[boudewijnrempt]

Ja, maar dat is niet onverdeeld goed of slecht; soms is het nodig en nuttig.

Shared libraries besparen schijfruimte en als de distributie z'n werk doet worden veiligheidslekken verholpen door een update. Maar aan de andere kant, als een library patches nodig heeft om met een bepaald programma goed te werken, patches die niet upstream geaccepteerd worden (of nog niet, dat kan een kwestie van heel lange adem zijn), is het praktischer om de library met de applicatie te verpakken.

En omdat alles behalve libc en zo in de appimage zit weet ik wat mijn gebruikers draaien; het gebeurt een paar keer per week dat ik een bug report kan sluiten als resolved/downstream omdat de appimage werkt, en de distributie package niet.

Maar goed, er zijn argumenten voor en tegen; mijn ervaring is dat als ik geen appimages zou maken, Linux gebruikers meer bugs zouden ervaren en oudere versies van Krita zouden gebruiken. En hoewel de meeste Krita gebruikers (een paar miljoen) nu op Windows zitten, gebruiken alle developers nog steeds bij voorkeur Linux, dat is onze thuishaven :-)

[delphium]

Ja, ik snap de voordelen voor de developer. Aan de andere kant kies ik als gebruiker heel bewust voor een bepaalde omgeving; Debian stable. Niet in de laatste plaats, omdat ik Debian vertrouw in hun patchbeleid. Als distro testen zij alles zeer uitvoerig inclusief de packages die ze aanbieden via hun repositories. Als dat betekent dat ik Krita 4.1.x moet draaien i.pv. 4.2.x, dan heb ik daar vrede mee. Ik heb echt zelden meegemaakt dat packages uit Debian stable kuren vertoonden.

Maar eigenlijk geef ik zelf al het antwoord op de vraag die ik wilde stellen: "gebruik ik op Debian nu ook de appimage versie van Krita"? Nee dus, als ik het goed begrijp ;-)

mijn ervaring is dat als ik geen appimages zou maken, Linux gebruikers meer bugs zouden ervaren en oudere versies van Krita zouden gebruiken

.

Maar is dat erg dan? Cutting edge distro gebruikers (Gentoo, Fedora, Arch) weten toch waar ze aan beginnen? Ik ben heel erg blij met de super stabiele Krita 4.1.7.101 op Debian stable. Ik kan er voor kiezen om Krita als package te pinnen op testing, of mijn hele systeem op testing te zetten, als ik per se de laatste versie van elk package wil draaien. Maar dat is toch helemaal niet belangrijk?

Anyway, heel erg bedankt voor het prachtige programma dat jullie open source aanbieden. Ik vind het echt geweldig! Diep respect daarvoor . Het zou fijn zijn als meer mensen zouden beseffen wat de werkelijke waarde van open source is.

[boudewijnrempt]

Dank je :-). Het enige probleem voor mensen die oudere versies gebruiken is dat ze geen bugs kunnen rapporteren.

[delphium]

Tuurlijk wel ;-) Ik zoek gewoon even of een bugin een nieuwere versie is verholpen. Zo niet meld ik het bij jou, zo wel meld ik het bij Debian.

[mbbs1024]

Ik heb de indruk dat .deb packages niet meer up to date gehouden worden, waardoor je in een aantal gevallen, als je nieuwe features wil gebruiken, wel verplicht bent om naar all in one package formaten over te gaan.
Musescore is daar een voorbeeld van, in de normale repositories zit enkel een stokoude versie, en als je een recente versie wil moet je ofwel zelf gaan compileren, of een all in one pack gebruiken.

[boudewijnrempt]

Pino zorg t er in ieder geval nog wel voor dat Krita redelijk up to date is: https://packages.debian.org/sid/graphics/krita -- 4.2.9, volgende week pas komt 4.3.0 uit.

[Verwijderd]

Ik draai Fedora en gebruik Flatpaks waar mogelijk, maar ik zie ook de voordelen van AppImages. Wat ik alleen erg mis is automatische updates. Wat denk jij hierover?

[boudewijnrempt]

https://invent.kde.org/graphics/krita/-/merge_requests/123 :-) -- appimages kunnen ook automatisch geupdate worden. Aan de andere kant is ook heel handig om tien verschillende versies voor handen te hebben, tenminste voor de mensen die helpen met bug triaging en zo.

[mjl]

Ik vroeg het me ook af, uit het artikel is het niet te halen.. is het een Chrome browser plugin of AppStore?

Als niet linux gebruiker kom ik er niet uit zonder externe bronnen na te gaan.

[Sjah]

Ja, het doet mij als redelijk nieuwe linux man, afschrikken door de traaaagheid van opstarten van een programma dat als snap is binnengekomen op mijn systeem.
Dan heb ik het echt over 3 tot 7x zo langzaam opstarten, ik constateerde dit bijv bij VLC en Chromium. Terwijl je linux kiest voor de snelle slanke prestaties (onder andere).

Dat het marktmacht creert voor canonical interesseert mij persoonlijk weinig tot niet. Canonical deed/doet een goeie job door linux toegankelijk/optie te maken voor de desktop.

[mjl]

Ja Google kan iedereen gebruiken maar een korte uitleg in het artikel is wel nodig.

[AverageNL]

Ik dacht tijdens het schrijven van het artikel dat dat uit context duidelijk zou zijn, maar nu ik het achteraf teruglees snap ik de verwarring inderdaad. Ik heb in de eerste alinea na de lead een zin met korte uitleg toegevoegd, hopelijk is het zo iets duidelijker.

cc: @sig69

[sig69]

Dat was mijn bedoeling inderdaad, thanks

[Finraziel]

Als niet Linux kenner moest ik eerlijk gezegd nog googlen wat de relatie tussen mint en canonical was... Als ik het goed begrijp is mint dus gebaseerd op ubuntu. Vroeg me tijdens het lezen van het artikel echt af wat al die partijen nou met elkaar te maken hadden, aangezien ik mint en canonical gewoon zag als aparte distro makers en chromium volgens mij toch ook gewoon weer door andere mensen uitgebracht wordt?

Maar goed, dit artikel en de reacties er op illustreren voor mij sowieso wel weer waarom ik ver bij Linux weg blijf

[terabyte]

En dit beste Tweakers, is waarom ik gelukkig ben met het bestaan van open source/vrije software.
Een bedrijf (Canonical) haalt potentieel gekkigheid uit, en je hebt de ultieme vrijheid om er niet in te stikken of het te moeten slikken.

[ApexAlpha]

Tja, leuk hoor al die keuze. Maar het feit dat de open source OS wereld bij elke minieme beslissing weer fragmenteert omdat een aantal mensen het niet eens is met keuze X of Y.

Hoe moet een developer ooit een applicatie schrijven voor Linux? Doe je dat voor Gnome of KDE? Snap, flatpack of apt? of yum? Test je op ubuntu of debian? Of Arch?

Al die fragmentatie is enorm slecht voor het ecosysteem. Het enige minieme voordeel van fragmentatie is voor hobbyisten die om wat voor reden dan ook een soort religie van distro's hebben gemaakt en zich in discussies ingraven tegen alles wat niet per sé hun distro is.

Persoonlijk erg zonde. Ik gebruik continu snaps op het werk, het scheelt enorm met die domme dependancy hell en werkt gewoon altijd. Jammer dat zoveel mensen de hakken in het zand zetten.

[Reactie gewijzigd door ApexAlpha op 22 juli 2024 15:56]

[sfranken]

Van de andere kant helpt het ook niet echt dat een groot bedrijf als Canonical wederom zijn hakken in het zand zet en, bijna als een kleuter, roept 'neeeehehehehheheeeeee we doen het zelf wel, maar dan anders en veel beter!!!!!' en Snap lanceert, in plaats van mee te gaan met de rest van de spreekwoordelijke klas met Flatpak. Ja, Canonical houd vol dat ze in het begin gekeken hebben naar Flatpak en zoveel fouten hebben gevonden dat ze niet anders konden, maar dat is in mijn ogen bullshit en/of marketingpraat.

Het releasen voor Linux is niet complex. De meeste developers bieden 3 dingen aan:

1) Een RPM voor RHEL en die familie
2) Een DEB voor Debian en die familie
3) Een source.tar(.gz), voor de rest.

Met 3 is het namelijk zo dat elke pakketbeheerder van elke andere distro dan zelf een package kan bouwen voor hun distro, vanaf je source.

Doe je dat voor Gnome of KDE?

Niet van toepassing, aangezien je GNOME applicaties prima kan draaien op KDE en andersom.

[ApexAlpha]

Volgens mij was Canonical eerder bezig met Snap dan dat Flatpack uitkwam. Of het zat dichtbij. Daarnaast hebben snap er voordelen hoor. Zo werken ze ook voor server apps en is het niet gek dat Canonical een eigen oplossing wil voor bij hun eigen OS. Niet?

Verder is RPM en DEB geen oplossing natuurlijk. Hoe update je je software dan? Hoe fix je dependancies? Het feit dat je de source code als optie geeft dat is al slecht... dat gaat nooit werken als je Linux aan een breder publiek wil krijgen.

Wel van toepassing als je Gnome plugins of KDE plugins ondersteund. Dat is nou nét dat ene randje afwerking die een applicatie op Windows of Mac wel het gevoel geven goed uit te zien.

Verder is 'die kleuter', jouw woorden, het ene bedrijf dat al jaren Linux aan de desktop probeert te krijgen. Die ene distro waar bijna alle andere distro's op gebaseerd zijn voor Desktop gebruikers...

[Reactie gewijzigd door ApexAlpha op 22 juli 2024 15:56]

[RJG-223]

Verder is RPM en DEB geen oplossing natuurlijk.

O? Geen oplossing waarvoor ? Leg uit...

RPM en DEB zijn juist prima oplossingen voor alle problemen die jij vermeldt. Dat zijn namelijk precies de problemen waarvoor ze zijn ontworpen om ze op te lossen.

Hoe update je je software dan?

Wat dacht je van 'apt update; apt upgrade' bijvoorbeeld ?

En als dat niet is wat je bedoelt, leg dan uit wat je wel bedoelt. Anders lijkt het meer alsof je ongeïnformeerd ergens tegenaanschopt wat je niet begrijpt. Iets met 'klok' en 'klepel' misschien ?

Hoe fix je dependancies?

Die hoeven niet gefixt te worden. Elk pakket specificeert zijn dependencies. En dan worden ze automatisch geïnstalleerd. Of bedoel je iets heel anders ? Leg dan uit wat je bedoelt, in plaats van vage claims van problemen die niet bestaan, of die zo algemeen zijn dat het voor een lezer onduidelijk is wat je bedoelt.

Het feit dat je de source code als optie geeft dat is al slecht... dat gaat nooit werken als je Linux aan een breder publiek wil krijgen.

Volgens mij haal jij hier twee zaken door elkaar: de moeite die eindgebruikers moeten doen., en de moeite die ontwikkelaars moeten doen. De bestaande package-managers (DEB, PRM) doen hun werk perfect voor de eindgebruiker. Geen sources nodig, geen dependency-problemen. Gewoon bijvoorbeeld 'apt install pakket' en pakket wordt volledig geïnstalleerd inclusief alle dependencies. Niets zelf zoeken en downloaden, geen kans om iets vergeten te zijn. Alles gaat vanzelf. Het enige wat je hoeft te doen is koffie te gaan drinken (als er héél veel geïnstalleerd moet worden). En het bespaart ook nog eens geheugen en harddiskruimte (vanwege shared libraries).

Volgens mij is het enige probleem wat snap oplost, dat het ontwikkelaars minder moeite kost, omdat ze alles bij elkaar ineen kunnen verpakken, en dan draait het (hopelijk ?) op alle versies van alle linux distributies (dat is het idee). Dat heet 'luiheid'. Daarvoor in de plaats krijgt de gebruiker oude (buggy) versies van libraries (omdat de ontwikkelaar geen zin/tijd/geld heeft om de nieuwere versie te gaan gebruiken), daarvoor krijgt de gebruiker (veel) hoger geheugengebruik en harddiskgebruik, omdat elke snap z'n eigen kopie heeft van allemaal dezelfde libraries, maar allemaal net ietsje anders, zodat ze niet gedeeld kunnen worden, en, zo begrijp ik (zie boven), ook inconsistente user-interfaces, omdat elke snap daarvan blijkbaar ook weer z'n eigen versies en configuratie-files heeft.

[kidde]

Deze reactie, hoewel er goede punten inzitten, is zeer eenzijdig en gaat volledig voorbij aan het belangrijkste probleem dat sommige ontwikkelaars m.i. met Debian hebben:

-Het is de gecentraliseerde Debian-kliek die bepaalt welke versie van jou applicatie in de megafreeze van de distributie komt;
-Er wordt vanuit de gecentraliseerde Debian-kliek iemand toegewezen om de Debian-versie van jouw sofware te gaan beheren,
-Vanuit de Debian-kliek wordt jouw software soms aangepast
-Als er ergens in dit geheel iets misgaat; of de beheerder van de package in Debian maakt niet bijtijds een nieuwe versie aan; dan krijgt de ontwikkelaar mogelijk de schuld.
-Als jou licentie de Debian-kliek niet aanstaat, dan wordt jouw applicatie gewoon genadeloos door hun gewijzigd (Iceweasel), of het wordt een gruwelijk onhandige omweg om jouw pakket te installeren (Java dus ook OpenOffice vroeger).

Ja, het is gedocumenteerd hoe je zelf een repository kan opzetten. Maar hoeveel ontwikkelaars doen dat, om te zorgen dat hun gebruikers altijd de door de ontwikkelaar gekozen versie van de applicatie krijgen, en niet degene die Debian in hun megafreeze wenste te stoppen? Punt is, dat op een schaal van 1 tot 10, het hele .deb en repository-verhaal nog steeds behoorlijk gecentraliseerd is. En de ontwikkelaar is afhankelijk van degenen die pakketjes maken voor de distributies.

Zaken als Klik, opvolger AppImage, Flatpak en Snap kan men ook uit een ander perspectief bekijken: Het overhevelen van de macht; terug van de 30 verschillende pakket-beheerders van 30 verschillende distro's terug naar de ontwikkelaar zelf.

Daarvoor in de plaats krijgt de gebruiker oude (buggy) versies van libraries (omdat de ontwikkelaar geen zin/tijd/geld heeft om de nieuwere versie te gaan gebruiken),

Dat klopt, maar in Debian gebeurt het vaak zat dat je een oude, buggy versie van een applicatie krijgt voorgeschoteld. Omdat die buggy versie toevallig de nieuwste versie was, toen Debian hun pakketjes voor hun nieuwe release bij elkaar sprokkelden. En de Debian pakket-beheerpersoon een maand na de "release" misschien te lui was (of geen tijd had?) om jouw nieuwe versie in een .deb-pakket te stoppen en te distribueren.

Het is jammer, maar deze hele discussie tussen APT / RPM en Snap vs Flatpak is m.i. niet veel meer dan een ordinaire machtsdiscussie.

Waar ik me zelf altijd mateloos aan irritteer:

Vanuit een LEAN-perspectief, is het eigenlijk ook merkwaardig dat er 30 pakket-beheer personen allemaal 1 uur stoppen in het maken van 30 verschillende packages voor 30 verschillende distro's. Dat kost ze 30 man-uur en Terabytes aan hardeschijfruimte, omdat ze allemaal ook jou software in hun formaat op hun eigen server en 30 mirrors willen zetten. Stel dat de ontwikkelaar zelf gewoon 1 pakket maakt dat werkt; dan kunnen die 30 meestal competente personen voortaan nuttig werk gaan doen.

Als een vestiging van een supermarkt graag 30 redundante magazijnen in de wijk van die vestiging gaat oprichten en alle boodschappen worden daardoor 20% duurder, wil de klant daar dan voor betalen ? Nou snap ik (pun not intended) dat veel pakket-beheer-figuren hun werk vrijwillig doen, maar dat wil natuurlijk niet zeggen dat hun werk geen verspilling is.

Dus ja, een Snap zal vast meer ruimte innemen; maar daarvoor in de plaats komen er elders weer Terabytes aan redundante en overbodige "repository-mirrors" vrij. Het is verplaatsen van de overhead.

[delphium]

Deze reactie, hoewel er goede punten inzitten, is zeer eenzijdig en gaat volledig voorbij aan het belangrijkste probleem dat veel distro's met sommige ontwikkelaars hebben:

• De eigenwijze developer die zonder het grote plaatje te zien, kiest voor libraries die nog niet goed getest zijn, of zelfs bewezen onstabiel in combinatie met andere software
• De eigenwijze developer die niet kan accepteren dat zijn nieuwste versie eerst uitgebreid getest moet worden voor dat deze in een stabiele distro kan veschijnen.
• De eigenwijze developer die niet begrijpt dat de door hem gekozen licentie niet past in de al decenniaoude filosofie van een distro.
• De eigenwijze developer die niet begrijpt dat als je open source software maakt, dat deze dan inderdaad gewijzigd kan worden.

Debian is niet voor niets al jaren een van de meest stabiele distro's die er zijn. Dat komt doordat ze software extreem uitgebreid testen en ja, daardoor heb je als Debian stable gebruiker niet altijd de allerlaatste versie. Dat betekent overigens niet dat kwetsbaarheden niet verholpen worden. Die worden netjes gebackport als dat nodig is.

Mocht je als Debian gebruiker overigens wel graag de laatste versies van software willen gebruiken, dat kan dat gewoon door "testing" te gebruiken, voor je hele systeem, of voor een enkel pakket.

Zaken als Klik, AppImage, Flatpak en Snap leggen inderdaad deels de "macht" bij de developers en laat ik dat nou net-niet willen! Ik kies voor Debian stable, omdat ik dan zeker weet dat alles uitermate goed getest is met elkaar en dat niet een of andere ongeduldige developer al je dependancies om zeep helpt, omdat hij zo nodig de laatste versie van een library wil gebruiken. Of zoals @RJG-223 terecht zegt, juist een brakke lekke oude library, omdat zijn app niet met de gefixte nieuwe versie werkt. Bovendien, als heel je systeem vol staat met zestien verschillende versies van een library, komt dat de veiligheid ook niet ten goede.

Waar ik me zelf altijd mateloos aan irritteer:...

(iets irriteert je of je ergert je aan iets, maar dat terzijde)

Dat er erg veel distro's zijn en dat je door de bomen het bos niet meer ziet, dat snap ik, maar je vergelijking met supermarkten, gaat volledig mank. Elke distro heeft zo zijn doel/filosofie/uitgangspunten. Zo zijn Fedora en Ubuntu redelijk cutting edge en zet Ubuntu bovendien in op gebruikersgemak. Gentoo en Arch zijn van het zelf compileren en lekker ingewikkeld doen op de commandline en zet Debian in op stabiliteit en veiligheid. Die keuzes hebben consequenties, namelijk dat je bij Ubuntu allerhande proprietary meuk krijgt meegeleverd (want lekker makkelijk) en bij Debian vaak wat oudere versies van software krijgt (want veilig en stabiel) en bovendien standaard alleen vrije software! Het zijn dus compleet andere producten met vaak een heel ander doel.

Dus nee, voor mij geen kant en klaar pakketjes en de macht bij de developer. Ik wacht wel tot een pakket in Debian stable verschijnt, of ik maak een uitzondering voor een enkel speciaal pakket door deze te pinnen op testing.

[kidde]

Uw punt was reeds genoemd in de reactie vóór mij. Dus als een persoon de ene kant van de weegschaal volstopt en ik de andere om het uit te balanceren, was het al niet eenzijdig meer en heeft het weinig zin om nog extra gewicht in een van de twee reeds gevulde bakjes te stoppen.

Het gaat me hier niet om meningen-pingpong en gelijk hebben, het gaat erom te realiseren dat er verschillende referentie-kaders zijn, en het is niet noodzakelijk dat één goed is en de ander fout. Zoals u zelf aangeeft, maakt u een keuze waar u het meest vertrouwen in heeft.

Veiligheidsrisico's kunnen ontstaan door de ontwikkelaar die een "verkeerde" library gebruikt, maar net zo goed omdat de machthebbenden bij de distributies gewoon heel traag zijn met het bijwerken van een applicatie met een veiligheidsrisico; die door de ontwikkelaar reeds opgelost is. Het een sluit het ander niet uit. Het gebeurt allebei.

[RJG-223]

Het is jammer, maar deze hele discussie tussen APT / RPM en Snap vs Flatpak is m.i. niet veel meer dan een ordinaire machtsdiscussie

Ja, en mensen als jij verwachten blijkbaar dat ze onbeperkte macht kunnen hebben, en dat ze met niets en niemendal rekening hoeven te houden. Misschien wordt het tijd dat je eens leert samen te werken, en compromissen te sluiten. Dat je leert je te conformeren aan de regels van de gemeenschap waar je deel van uitmaakt, of waar je deel van uit wilt maken, of waar je misschien deels tegen je zin deel van uit moet maken, omdat dat uiteindelijk toch makkelijker is dan alles zelf te doen. En vergeet niet: de gemeenschap is véél groter dan jij. Jij bent (net als ik, en als ieder individu) een onbetekenend radartje in 't geheel. De gemeenschap gaat zich echt niet richten naar jouw wensen. Dat doet het de stad waar je woont niet, dat doet het land waar je woont niet, en dat doet, enkele uitzonderingen misschien daargelaten, geen enkele gemeenschap waar je deel van uitmaakt. Zelfs niet als je er de president van zou zijn.

Wat mij betreft: de distributie die ik gebruik, die heeft bepaalde regels over wat ze van software verwachten. En ik gebruik die distributie, omdat die wensen voldoende overeenkomen met de mijne. Dat is dus een impliciete afspraak, en ik verwacht van mijn distributie dat ze zich aan die afspraak houden, en niet direkt te buigen voor elke willekeurige developer die het daar niet helemaal mee eens is. Dat doen ze namens mij, en daar ben ik blij mee. Of die distributie nu Debian is, zoals in het voorbeeld boven, of Redhat, Fedora, Suse, Gentoo, of wat dan ook. En dat is geen kliek. Dat zijn vertegenwoordigers van mijn wensen, en/of de wensen van alle mensen die die distributie gebruiken.

[kidde]

"Jij, jij, jij": Hoezo gaat u ervanuit dat dit mijn mening is? En dat u weet waar ik vanuit ga?

Hoezo moet u deze hele discussie zo persoonlijk opvatten? U komt nogal getergd over.

U vraagt goede redenen voor snaps, ik noem er een paar die mogelijk niet van mijzelf afkomstig zijn, en nog onderbelicht waren. Elders hier zie ik ervaren mensen, die aangeven dat wat ik hier noem in de praktijk soms een issue is Maar dat hele jij-jij-jij toontje duidt er volgens mij op, dat u daar toch niet voor openstaat, uw mening toch al gevormd heeft. En de mensen die niet in"uw kamp" zitten bericht u gelijk maar van niet willen samenwerken, hoe ironisch. Dus waarom vraagt u anderen dan in 's hemelsnaam naar hun mening? Of wilde u uw waarheid als feit presenteren en was de vraag retorisch?

Als ik vind dat 1+1 gelijk is aan 2, ga ik mensen toch ook niet om hun mening vragen? Dat is verspilling van de moeite van de mensen die erop zouden reageren, dus laat dat dan gewoon weten dan stop ik mijn tijd hier te verkwanselen aan dovemansoren.

[RJG-223]

"Jij, jij, jij": Hoezo gaat u ervanuit dat dit mijn mening is? En dat u weet waar ik vanuit ga?

Jouw ongezouten mening staat er duidelijk. Je hebt het met zoveel nadruk over 'jouw' applicatie, dat dat zeer bezitterig, en persoonlijk gemeend overkomt, ondanks het feit dat het 2e persoon is. En het herhaald gebruik van de term 'debian-kliek' is ook al niet echt objectief en/of vrij van stemmingmakerij. Dat kan door de lezer niet anders opgevat worden dan een persoonlijke mening. Sommigen zouden het zelfs interpreteren als een (onverdiende) aanval op de debian ontwikkelaars (voor alle duidelijkheid: ik ben géén debian maintainer, en al evenmin voor een andere distributie)

Wellicht is dat allemaal geen persoonlijke mening, maar die indruk heb je wél zeer duidelijk weten te wekken.

Hoezo moet u deze hele discussie zo persoonlijk opvatten? U komt nogal getergd over.

Ik ben niet getergd hoor. Ik reageer enkel op jouw ongezouten post, zo vol emotie en stemming-makerij dat het het eerder flame-bait is dan een constructieve bijdrage aan een discussie. En daarop reageer ik.

Jouw hele reactie komt op mij over als van een getergd iemand, die zich 'mateloos irriteert' (jouw eigen woorden) en gaat uitsluitend uit van de belangen van één bepaalde persoon of groep: de ontwikkelaar(s). En gezien de inhoud van jouw reactie voel jij je daarmee zeer verbonden. Nogmaals: ik vind dat geen constructieve bijdrage aan een discussie.

U vraagt goede redenen voor snaps, ik noem er een paar die mogelijk niet van mijzelf afkomstig zijn, en nog onderbelicht waren.

En in plaats van een afgewogen presentatie van die redenen, die, zover die niet van jouwzelf komen, zo te horen toch jouw devote sympathie hebben, zit jouw post vol van de emotie en van zeer eenzijdige ongenuanceerde argumenten. En demoniseer je een grote en zeer diverse groep hardwerkende mensen. En dan beschuldig je mij van 'jij-jij-jij' en van 'niet open staan', etc ??

Als dat alles niet je bedoeling was, sorry dan dat ik het zo interpreteerde. Probeer in dat geval de volgende keer jouw bijdragen aan een discussie iets neutraler te formuleren, want de lezer kan enkel afgaan op jouw woorden, en als die extreem, ongezouten, en/of emotioneel overkomen, dan is dát hetgene waarop gereageerd wordt.

Als ik vind dat 1+1 gelijk is aan 2, ga ik mensen toch ook niet om hun mening vragen?

??? 1+1=2 is géén mening. Dan vind je niet, dat is zo. Dat is een feit. Terwijl heel veel aspecten van déze discussie afhangen van het standpunt van de persoon, en dus meningen zijn. Onvergelijkbaar dus. En als jij dan, mijns inziens emotioneel, en eenzijdig jouw (inderdaad: jouw) mening ventileert, en mensen aanvalt omdat ze tot een bepaalde groep behoren (debian-kliek), dan nodig je uit tot een weerwoord. Dan vráág je om een (tegen)mening. Mijn mening over jouw reactie, en hoe die overkomt, heb ik je dus gegeven. En die mening ging niet over snap vs. RPM, of DEB, of wat dan ook. Die ging over de manier waarop jij deelneemt aan deze discussie.

[Reactie gewijzigd door RJG-223 op 22 juli 2024 15:56]

[kidde]

Het is teleurstellend hoe u uw eigen advies niet ter harte neemt, niet snapt wat het verschil is tussen een mening over een kliek en jij-bakken, maar OK, het is schattig hoe u het voor de Debian kliek opneemt en dat waardeer ik. Er zitten vast ook goede mensen tussen.

Wat is er gebeurd?

Stel, u loopt op FOSDEM 2005 of 2006, ULB. U maakt in de grote collegezaal Janson na de keynote een praatje met Kurt Pfeifle, oprichter van Klik; voorloper van AppImage. Hij is getergd, maar u hebt een gesprekje met hem, het misverstand is de wereld uit en alles is weer goed. Hij begint het gesprek met jij, jij, jij maar u weet het kundig bij te sturen. Het probleem is immers niet de persoon, maar het onderwerp, en hij snapt dat echt wel uiteindelijk.

U wandelt naar binnen bij Fedora, CentOS, RepRap, Postgresql, DragonflyBSD: Noem maar op. Bij Exherbo vertelt iemand hoe je ontwikkelaars benadert over bugs op een manier dat de ontwikkelaars niet getergd zijn. Veel positivisme, constructiviteit. Hier wordt u wel blij van, en optimistisch beseft u zich dat deze mensen enorm veel kunnen bereiken: Een goed gevoel. De boekenstand van O'Reilly loopt lekker, u haalt buiten een frietje aan het hoofdpad bij dertien graden onder nul, steekt over naar het andere gebouw en maakt dan een grote fout.

U wandelt nietsvermoedend, positief gestemd na deze mooie zaterdag een lokaal naar binnen, maar er is iets grondig mis. En omdat u een empathisch persoon bent die kan samenwerken, voelt u gelijk dat er iets heel, heel erg mis is. De moed zakt u in de schoenen.

Binnen zit men in het bedompte lokaal met rood aangelopen hoofden, zwijgzaam elkaar vooral niet aan te kijken. Er is kennelijk een ideologische koude oorlog aan de gang, en u zit er middenin. Hier zitten een stel ideologische ego's die op geen enkele manier willen of kunnen samenwerken. De spanning is om te snijden. Het liefste loopt u snel weg, maar uit respect voor deze bekwame mensen (en nieuwsgierigheid?) blijft u toch; met frisse tegenzin zich afvragend waarom dit lokaal een goed idee was als er >20 lokalen zijn. Misschien komt het nog goed?

Maar nee, geen van de kampen beweegt een millimeter of is bereid afstand te nemen: Deze personen hebben hun ziel vereenzelvigd met hun mening. Een aanval op hun mening is een aanval op hun ziel.

Na de volle 45 minuten in uw zelfgekozen opsluiting in dit lokaal te zijn verbleven, bent u weer blij dat u buiten het lokaal bent, waar de frisse winterlucht u door de open voordeur van het vervallen maar statige gebouw tegemoet waait. Nooit was koude lucht zo welkom. Nog nooit zat u tussen zo'n vooringenomen kliek ego's. Rechts van u een presentatie over iets met Java of zo; niet uw ding maar alles beter dan waar u vandaan komt.

Dan weet u: Zojuist heeft u een getergde club mensen gezien, die bekwaam zijn en heel veel zouden kunnen bereiken. Als ze elkaar het licht in de ogen zouden gunnen en wilden samenwerken. En dat, dat is frustrerend. 15 jaar later nog.

[Reactie gewijzigd door kidde op 22 juli 2024 15:56]

[HakanX]

Het kost idd meer resources, maar tegenwoordig is dat te veroorloven. Microsoft heeft met Windows daar ook uiteindelijk voor gekozen toch. Geen shared dlls meer, maar 20 verschillende versies waar nodig. Nadeel resources. Voordeel geen blauwe schermen en crashes doordat een dll geupdate is maar alle programma's die die dll gebruiken nog niet (soms nooit niet).
Ubuntu kiest ervoor om die kant op te gaan. Een no nonsense OS. Ik vind het positief dat iemand daarvoor kiest. Dat moet ook bestaan voor de mensen die dat willen. Het andere blijft ook bestaan.

Ik heb toevallig gisteren voor het eerst Snap gebruikt. Ik wilde Nextcloud uittesten hoe het werkt in de browser en op mn mobiel ook icm Nextcloud Talk. Ipv een complete LAMP omgeving te installeren en alles één voor één te configureren, was ik klaar met een paar kliks. Geweldig en dat is wat het grote publiek met alle programma's nodig heeft.
Ben redelijk tevreden met wat ik heb gezien en ga nu wel mijn tijd steken in het handmatig installeren van Nextcloud, want ik wil natuurlijk niet 20x Apache en MariaDB op mijn systeem draaien voor elke package. Dus het was leuk om te testen en als je eventueel maar 1 ding wilt draaien op je server en geen omkijken naar wilt en ook voor minder ingewikkelde apps die niet complete gangbare servers dubbel moeten installeren.

Ik zal het zeker vaker gebruiken, maar in mijn geval voor het testen of als ik iets snel even nodig heb. Verder ben ik een controlfreak dus wil ik wel alles in eigen controle.

[Reactie gewijzigd door HakanX op 22 juli 2024 15:56]

[RJG-223]

Het kost idd meer resources, maar tegenwoordig is dat te veroorloven. Microsoft heeft met Windows daar ook uiteindelijk voor gekozen toch. Geen shared dlls meer, maar 20 verschillende versies waar nodig.

Wat je hier beschrijft, dat is in een Linux omgeving nooit anders geweest. Behalve dat distributies het zo organiseren dat het aantal nodige versies van een library zeer beperkt is. Dat heeft helemaal niets met snaps te maken.

Het probleem van snaps is, dat er 20 versies van exact dezelfde libraries (ook exact dezelfde versie !) op het systeem kunnen staan, omdat elke snap zijn eigen volkomen identieke kopieën heeft, of bijna identieke kopieën, eventueel met verschillende combinaties van (essentiële) security fixes bijvoorbeeld. En die gebruiken dan ook allemaal hun eigen geheugen. En dan zal het ongetwijfeld ook nog zo zijn dat verschillende snaps exact dezelfde versie van dezelfde library hebben, maar dan onnodig gecompileerd met net iets andere opties, of met een andere compiler, zodat het zelfs onmogelijk is om te proberen die te dedupliceren - want de binaire code is daardoor op triviale punten niet niet gelijk.,

Ubuntu kiest ervoor om die kant op te gaan. Een no nonsense OS. Ik vind het positief dat iemand daarvoor kiest. Dat moet ook bestaan voor de mensen die dat willen. Het andere blijft ook bestaan.

Nee dus. Dat was altijd al zo. Linux is geen Windows. Zoals gezegd: Linux heeft nooit het DLL probleem van windows gehad. Door voor snaps te kiezen gooien ze hier juist op een aantal verschillende manieren (*) het kind met het badwater weg, en introduceren ze een hele serie nieuwe problemen.

(*) geheugengebruik, harddiskgebruik, automatische security patches en bugfixes van (shared) libraries, en waarschijnlijk meer.

[Willaaam]

Goede punten. Besef wel dat snaps automatisch updaten, ook voor server software. Je hebt dus geen keuze in wanneer en naar welke versie je upgrade.

Wat mij betreft is dit echt het grootste nadeel aan snap op dit moment.

[Verwijderd]

Volgens mij was Canonical eerder bezig met Snap dan dat Flatpack uitkwam. Of het zat dichtbij. Daarnaast hebben snap er voordelen hoor. Zo werken ze ook voor server apps en is het niet gek dat Canonical een eigen oplossing wil voor bij hun eigen OS. Niet?

Snaps was inderdaad eerder gelanceerd dan Flaptaks, maar flatpak is wel een volledig open source systeem terwijl de backend van snaps closed source is. Persoonlijk vindt ik het slecht dat Ubuntu zo hardt die snaps probeert te pushen.

Verder is RPM en DEB geen oplossing natuurlijk. Hoe update je je software dan? Hoe fix je dependancies? Het feit dat je de source code als optie geeft dat is al slecht... dat gaat nooit werken als je Linux aan een breder publiek wil krijgen.

Als je alles goed doet, dan kan heb je geen dependencies issues met DEB en RPM. En met DEB en RPM kunt ge eigen repositories in zetten om zo automatische updates te regelen als je dat wil.

Wel van toepassing als je Gnome plugins of KDE plugins ondersteund. Dat is nou nét dat ene randje afwerking die een applicatie op Windows of Mac wel het gevoel geven goed uit te zien.

Als ge plugins maakt voor specifiek gnome of KDE dan is dat inderdaad logisch dat dat niet werkt bij de andere. Algemeen dingen zoals de system tray enzo zitten in de meeste Desktop enviroments. De system tray moet wel met een extension bij gnome (die Ubuntu standaard installeerd).

[mzziol]

De "backend" van snap is een simpele HTTP server. Als distros het willen kunnen ze makkelijk hun eigen store hosten.

[markg85]

Nou even verder lezen dan alleen een google hit en doorklikken en je ziet dat het inmiddels toch niet meer zo makkelijk is. De github repo die het als voorbeeld had is er ook mee gestopt omdat het anders is geworden.

Hint: lees geen artikelen uit 2016 in 2020 voor een techniek die hard in ontwikkeling is.

[mzziol]

Hint: lees geen artikelen uit 2016 in 2020 voor een techniek die hard in ontwikkeling is.

Hint: Snarky doen is een goede manier om mensen je mening naar de prullenmand te verwijzen.

[sfranken]

Verder is RPM en DEB geen oplossing natuurlijk. Hoe update je je software dan? Hoe fix je dependancies? Het feit dat je de source code als optie geeft dat is al slecht... dat gaat nooit werken als je Linux aan een breder publiek wil krijgen.

Hiermee toon je dat je geen Linux gebruikt. Zowel rpm als deb hebben dependancies controles, en de pakketbeheerders installeren de benodigde dependancies ook netjes mee als je iets installeert.

Je source code vrijgeven is, in mijn ogen, alleen maar normaal. Vooral omdat de meeste libraries die je in Linux land gebruikt dit ook zijn, is het 'good netizenship' om dit zelfde te doen. Een andere pro, welke ik in mijn post waar je op reageert beter had kunnen benoemen (anders had je dit punt niet zo naar boven gebracht) is zodat je andere distro's waar jij als ontwikkelaar geen rekening mee houd, toch de kans geeft je software te bundelen.

Stel dat ik software schrijf, en ik kies ervoor om dit alleen voor Fedora / RHEL uit te geven. Ik publiceer de source via GitLab (en tarballs via daar). Dit zorgt er dan voor dat ze bij Ubuntu, en Debian, en Arch, en elke andere distro OOK mijn software kunnen aanbieden mocht er vraag naar zijn. Is wel zo netjes, niet?

Het is immers niet altijd mogelijk om alle distros te ondersteunen als ontwikkelaar. Soms brengt iemand iets uit waarvan hij of zij denkt 'dit gaat niemand verder gebruiken behalve ik en Y vrienden, allemaal op distro Z'. Die persoon packaged dus alleen voor die distro. En wie weet word de software in kwestie gigantisch populair bij Ubuntu gebruikers. Vandaar de source tarballs.

[mekkieboek]

Er zijn anders legio end-user facing Linux applicaties die niets met snap doen en toch een behoorlijke mate van complexiteit en features kennen. Ik noem en een paar:

• PyCharm (en Python zelf niet te vergeten)
• Bitwig Studio, (een DAW, behoorlijk complex maar werkt als een trein, kost wel geld)
• Darktable foto editor
• Krita paint
• Alle bekende webbrowsers en enkele Linux-specifieke
• X-Plane

Hoe doen die ontwikkelaars dat? Mss zijn ze onnodig veel energie/tijd kwijt om dependency plooien glad te strijken maar het lijkt ze te lukken. Zonder Snap.

[boudewijnrempt]

Voor Krita gebruiken we sinds 2015 appimage. De flatpak en de snap worden onderhouden door liefhebbers van flatpak en snap; en er is een vrijwilliger die een Ubuntu ppa onderhoudt.

Maar we zijn nooit in staat geweest om distributie packages te maken, en dat was een groot probleem, want de meeste distributies liepen altijd achter. Dat lijkt nu een stuk beter te gaan, misschien omdat we wat bekender zijn dan vroeger, misschien omdat flatpak/snap/appimage altijd de nieuwste versie aanbieden en dus serieus concurrentie bieden.

Het is zo fijn dat we tegenwoordig nightly builds van zowel de stable als de unstable branch kunnen aanbieden die bijna iedere Linux gebruiker kan testen en waarvan we precies weten wat erin zit:

* https://binary-factory.kd...a_Nightly_Appimage_Build/
* https://binary-factory.kd...ta_Stable_Appimage_Build/

[mbb]

Hebben jullie wel hardware support en connecties met andere programma's in de appimage?
Ik heb zelf geen Linux, maar zag deze issues voorbij komen in de bugtracker van OpenShot. Ik ben nieuwsgierig of het aan de implementatie ligt of een beperking is van AppImage.
(Zelfde beperking geld overigens voor de Microsoft Store versie)

[boudewijnrempt]

dbus werkt gewoon, maar we hebben wat problemen met gstreamer, zodat de appimages geen support hebben voor audio (voor animaties).

[terabyte]

Ah, de steeds terugkerende "Er zijn teveel distro's" non-argument. En hop, +2
"Er zijn teveel automerken" "Er zijn teveel politieke partijen" etc.

Ik heb er al vaak genoeg een weerwoord op gegeven, dus dan maar linkjes:

https://fossforce.com/2013/07/the-too-many-distros-theory/

Ik ontwikkel voor Linux en die zogenaamde fragmentatie waar jij het over hebt, heb ik geen last van. Een soort niet-bestaand probleem waar steeds naar verwezen wordt door niet-Linux gebruikers.

Tja, leuk hoor al die keuze

Anyway, met jouw opmerking laat je vooral zien dat je geen behoefte hebt aan de voordelen van de vrijheid die open source biedt. Dat is jouw goed recht, maar laat anderen die daar wel behoefte aan hebben wel van die vrijheid genieten. Dus als ik morgen mijn eigen terabyte-distro wil uitbrengen (ook al ben ik dan de enige gebruiker) - dat is mijn vrijheid en mijn goed recht.

[Reactie gewijzigd door terabyte op 22 juli 2024 15:56]

[ApexAlpha]

Tja, in je opiniestuk dat je linkt wordt aangekaart (in 2013...) dat het belangrijkste is dat OEM een OS meeleveren. Laat Ubuntu dat nou net proberen met o.a. Dell.

Verder vraag ik mij af hoe jij als ontwikkelaar voor Linux desktop apps geen last kan hebben van de fragmentatie. Welk OS is je target dan? Welk framework gebruik je? Hoe distribueer je je app? Raar dat de paar mensen die ik ken die UI en Desktop apps voor Linux maken continu klagen over 1000 verschillende setups die mensen hebben. Vraag me af wat jouw magische oplossing is.

[rob12424]

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

Dit is je antwoord. Op sommige dingen na is het bijna allemaal hetzelfde sinds dit.

[Spatienazi]

https://nl.wikipedia.org/wiki/Linux_Standard_Base

Hier is de desktopversie van je link. Als een mobile gebruiker een desktoplink bezoekt, worden ze automatisch doorgestuurd naar de mobiele site. Andersom is dat niet het geval. Het is dus altijd een goed idee om de standaard desktop-link te posten door die '.m' weg te halen, dan heeft iedereen de beste ervaring.

[rob12424]

Okey bedankt!

[dec0de]

Je gebruikt flatpak. Opensource, decentraal, met de populaire flathub als simpele plug&play.

Gtk+, word door zowat alles onderstuend. Daarbij bestaan dependency trees met een reden

[Verwijderd]

Ik ontwikkel pas recent voor en op Linux.

Ik was hier vooraf erg huiverig voor, van het 'Uniforme' Windows en het .net framework naar Linux en c++.

Die fragmentatie bleek een comlpeet non issue te zijn. Op elke distro kan je met een simpel script of van source met make install installeren naar /usr/local of /opt en het werkt. Hoeveel er ook verschilt, hiermee ben ik niet tegen problemen aan gelopen. Ik ga bij voorkeur voor opt en installeer mijn dependencies mee, dus als een distro bij een oude versie is gebleven of omgekeerd heb ik dara geen last. So what dat een lib dan twee keer aanwezig is, alles is self contained i.t.t tot de DLL hel op Windows. Een rmdir en kleine edit van het path en het programma is 100% weg, probeer dat eens op Windows.

Overigens snap ik de aversie tegen snap niet, het is niet anders dan een package die niet anders doet dan wat veel software inclusief het mijne onder /opt doet, maar dan op een uniforme manier met een mooie infrastructuur er omheen.

[latka]

De belangrijkste reden: security. Spotify is een snap-app. Die heeft allerlei libraries erbij. Je moet maar hopen dat Spotify op tijd alle lekken dicht en dan moet je niet alleen spotify maar ook alle andere snaps die dezelfde library gebruiken upgraden. Dat is iets wat met een goede package manager niet gebeurt: library lek? Upgrade library. Nieuwe versie publiceren en iedereen heeft de laatste versie. Het voordeel van Snap is dat je als ontwikkelaar maar wat aan kunt rommelen en alles lijkt te werken (het 'runs on my machine' syndroom) en er geen controle meer is of er lekke oude rommel in je snap zit.

[Verwijderd]

Die hoor ik heel vaak en 25 jaar geleden had ik daar misschien in geloofd.

Om te beginnen zijn er bergen met statische gelinkte libs die net zo goed lekken kunnen bevatten. Met deze redenatie zou je dus geen enkel programma meer kunnen gebruiken zonder dat je de volledige source code hebt en installeert vanuit source packages. Yay, Gentoo! (Alhoewel, ik begrijp dat die sinds ik het voor het laatst gebruikte ook op binary package voor iig het basis systeem zijn overgestapt).

Ten tweede zowel onder Windows als Linux zag en zie ik nog steeds programma's voorbij komen die een keiharde dependency op een versie van en library hebben. Dus package manager installeert nieuwe lib, maar oude lib blijft gewoon op het systeem vanwege een harde dependency en je hebt geen enkel voordeel.

Ten derde al heel veel gevallen gezien waarin een library wordt geupdate en 3 van de 4 programma's werkt prima met de nieuwe lib, maar die laatste werkt niet meer. Helaas duurt de update voor die laatste wat langer en is bedrijfskritisch. Kan je terecht kritiek op hebben, maar het is de praktijk.

Als de ontwikkelaar maar wat aanrommelt dan maakt het voor security geen zak uit of het een snap is of niet, dan kan je de software sowieso niet vertrouwen. En een ontwikkelaar die security serieus wel neemt en zijn software als snap verspreid zal ook bij het maken van zijn snap zorgvuldig zijn.

En aangezien je dus - snap of geen snap - niet kan garanderen dat deze problemen niet optreden wil je hier maatregelen voor nemen om het risico te mitigeren. Wat is 1 van de beste maatregelen om zo'n risico te mitigeren? Sandboxen ... laat snap (en flatpak) dat nu net standaard doen!

[latka]

Ik gebruik voornamelijk Debian/Linux voor systeemonwikkelwerk, dus vanuit die optiek: er zitten geen statische binaries in de base distributie. Dus daar speelt het niet. Wellicht dat er (commerciele) software is die statisch gelinkt is. Dat installeer ik niet. Onder linux valt het reuze mee met dependencies: meestal op een major versie, soms op een minor. Eigenlijk nooit op precies 1 versie (tenzij je het weer hebt over 3rd party rommel met een supportcontract).
Ik doe dit soort dingen al zo'n 20 jaar, dus ik praat ook op echte ervaring. Maar wat ik wel gemerkt heb is dat als je commerciele Linux software erbij betrekt het landschap flink betrekt en je inderdaad statische zooi vind (en initscripts die het soms doen, files buiten de standaard directories etc.).

Ik zeg niet dat apt of rpm rommel voorkomt, wat ik wel zie is dat het een probleem wat er niet was erbij maakt: 2 kanalen van updates. Voor je het weet zit je met 30 cron-jobs die allemaal gaan checken of er updates zijn en kun je net zo goed windows installeren

[Verwijderd]

Vanuit jouw optiek snap ik het. Ik maak (en gebruik ook veel) closed source software, dat is waar ik voor betaald wordt. En dan loop je tegen veel statisch gelinkte libraries of keiharde dependencies op versie nummers aan. Geen probleem, gewoon meerdere versies aanhouden, maar wel een argument tegen snaps/flatpaks wat niet op gaat.

Of nog vervelender een keiharde eis aan de layout van het filesystem, niet ieder distor houdt zich aan FHS, maar ook niet alle software verwacht FHS, vooral als de ontwikkelaar primair een niet FHS platform target. Waar het library 'probleem' wat redundantie en mogelijk security issues oplevert, die vaak ook wel weer op te lossen zijn op een andere wijze, verander je niet zomaar even de layout van je filesystem. Dan werkt het dus gewoon niet of mag je zwaar gaan zitten klooien met links.

Ik zie op zich overigens geen enkel probleem met twee update systemen, één voor het basis OS en één voor de applicaties die je erop draait.

Wel ben ik het met je eens dat het verre van ideaal is als je opeens voor applicaties moet gaan bedenken of je de .deb, de snap of de flatpak gaat installeren. Bij elke applicatie uitzoeken wat het primaire platform voor de ontwikkelaar is zodat je het snelst de updates binnen hebt is niet wat je wil.

Met wat cron jobs om te zoeken naar updates heb ik dan weer weinig moeite. Het voordeel van computers, je voegt het regeltje toe en het gebeurt. Hert maakt de computer echt niet uit of het er 1, 2 of 30 zijn.

[PureTryOut]

Overigens snap ik de aversie tegen snap niet, het is niet anders dan een package die niet anders doet dan wat veel software inclusief het mijne onder /opt doet, maar dan op een uniforme manier met een mooie infrastructuur er omheen.

Maar veel mensen willen niet hun software onder /opt. Die willen niet dubbele libraries van verschillende versies waarvan je maar moet hopen dat ze op tijd geupdate worden.

Maar het grootste probleem met Snap is dat het een gecentraliseerde proprietary backend van Canonical gebruikt. Kijk eens naar Flatpak, zelfde idee, maar geen proprietary componenten aanwezig en ondersteunt meerdere repositories ipv maar één.

[RoestVrijStaal]

[...]


Maar veel mensen willen niet hun software onder /opt. Die willen niet dubbele libraries van verschillende versies waarvan je maar moet hopen dat ze op tijd geupdate worden.

Dat is toch hun probleem waarover ze vallen? De simpelste oplossing voor hen is "gebruik de software niet, los je probleem maar zelf op".

[desalniettemin]

Start langzaam op de eerste keer en ook qua theming schijnt het nog niet helemaal goed te zijn en sommige vinden ook dat het nogal geforceerd wordt lees en hoor ik op verschillende live streams en artikelen over snaps.

[Reactie gewijzigd door desalniettemin op 22 juli 2024 15:56]

[WhiteDog]

Dus als jij je dependencies niet bijwerkt werkt je software misschien een keer niet na een OS update of bevat je software een beveiligingsrisico.

Bij Windows kan je ook "gewoon" een dll bij je eigen software zetten of in je EXE mee compileren (mijn favoriet, ik hou van single-exe applicaties).

Het ligt meer aan de mentaliteit van de ontwikkelaar. Dat Microsoft zelf 10 soorten installers door elkaar gebruikt helpt ook wel niet

[Verwijderd]

Ik was zelf ook al snel van alle dependencies in de eigen installatie folder, niet zozeer fan van een enkele grote exe.

Je komt van de opleiding met al die mooie idealen van componenten, uitwisselbare modules/libraries en alles apart te updaten. Dan komt de praktijk en ben je snel genezen...

Alleen werk ik niet alleen met eigen software en loop je dus toch tegen die problemen aan.

[Eonfge]

Ah, de steeds terugkerende "Er zijn teveel distro's" non-argument. En hop, +2
"Er zijn teveel automerken" "Er zijn teveel politieke partijen" etc.

Onee, er is een vrije keuze aan auto leveranciers, waardoor fabrikanten moeten concurreren! Was het maar zoals de software industrie, waarin 1 bedrijf 90% van de markt heeft. Dan zouden we allemaal gewoon de zelfde Ford hebben, enkele alternatievelingen daar gelaten met hun Tesla.

[MrFax]

Zelfs Linus Torvalds heeft gezegd dat Linux als desktop (niet als de kernel zelf, maar als een distro) er voor gezorgd heeft dat het nooit goed van de grond is gekomen.

[latka]

Ik gebruik meestal Debian ipv. Ubuntu, maar wat is die "dependency hell" waar je last van hebt? Ik merk er in de praktijk helemaal niets van. Integendeel: als ik iets wil installeren wat conflicteerd met de rest dan meld apt dat netjes. Ik weet niet wat voor een software jij er allemaal bij installeert dat het een probleem wordt, maar ik vermoed dat die niet uit de Ubuntu/Debian repo komen maar uit wazige bronnen van derden.

[Zobat]

volgens mij is dependency hell een uitdrukking uit de vroege jaren van redhat. Totaal niet meer van toepassing volgens mij. In elk geval niet in debian based distros.

[latka]

Ik ken de uitdrukking uit Windows waar iedereen allerlei DLLs rondslingert. Onder Debian iig. nog nooit last van gehad. Onder Redhat was het probleem dat men aan file-versioning deed ipv. package versioning zodat je je de touwtandjes zocht naar waar het conflict zat.

[sfranken]

De windows versie van die uitdrukking is DLL hell. Komt op hetzelfde neer, dat wel.

Onder Redhat was het probleem dat men aan file-versioning deed ipv. package versioning zodat je je de touwtandjes zocht naar waar het conflict zat.

Dat was vroeger. Inmiddels is het pakketformat (rpm) aangepast dat je niet meer zo makkelijk dit soort issues hebt. En, maar 100% zeker weten doe ik dat niet, volgens mij zijn ook de namen aangepast qua versies. Zolang ik me echter kan herinneren (Sinds Fedora 14) is dit niet meer van toepassing.

[RJG-223]

Persoonlijk erg zonde. Ik gebruik continu snaps op het werk, het scheelt enorm met die domme dependancy hell en werkt gewoon altijd. Jammer dat zoveel mensen de hakken in het zand zetten.

Kun je dat uitleggen ? Ik begrijp niet welke 'dependency hell' jij bedoelt. Als ik een pakket installeer, dan worden automatisch alle dependencies geïnstalleerd. Altijd. Niks hell. Werkt gewoon altijd.

Ik snap niet waarom mensen iets anders nodig hebben, dat meer geheugen vreet, en meer harddiskruimte (vanwege alle (drie, vier, ...)-dubbele libraries: voor elke snap een eigen exemplaar), en waar de ontwikkelaars ook nog zonder probleem oude buggy versies van libraries in kunnen laten zitten, zodat ik zonder het te weten met allerlei bekende kwetsbaarheden op mijn systeem zit, ondanks dat het voorzien is van de allerlaatste updates.

[Blokker_1999]

Ik vermoed van zodra je extra repos begint toe te voegen. Klein voorbeeldje. Heb recent mijn homeservers moeten rebuilden. De oude was Debian 10, de nieuwe is ook Debian 10. 1 van de functies is het draaien van de unifi controller. Zou zo eenvoudig moeten zijn als de repo van ubiquiti toe te voegen en je kan via apt gewoon unifi installeren. Alleen werkt dat niet meer omdat unifi afhankelijk is van een pakket genaamt mongodb-server wat door mongodb niet meer gemaakt wordt voor Debian 10. Je hebt dus een dependency die je niet zomaar kunt voldoen.

[latka]

Tsja, dit klinkt een beetje als mijn scannerdriver doet het niet onder windows 10, dus ik installeer Windows 7 in een VM zodat ik de driver kan blijven gebruiken. Wat ook gewoon kan is een supportcall doen naar Unifi dat ze hun package upgraden. Ik dacht dat namelijk het verschil was tussen opensource en commerciele aanbieders ;-)

[mjz2cool]

Heel simpel: je hebt in principe rpm en deb, daarmee heb je de meeste populaire distro's al. KDE of Gnome, of welke desktopomgeving dan ook maakt niets uit, als je een deb package hebt, werkt die gewoon op elke Debian based distro, ongeacht je desktopomgeving.

[Weaszel]

Is het niet juist de bedoeling dat die vrijheid er is. Ik bedoel is dat niet de opzet van heel Linux. Vrijheid creëren en keuzes geven. Die fragmentatie zie ik ook niet zo.

[PureTryOut]

Persoonlijk erg zonde. Ik gebruik continu snaps op het werk, het scheelt enorm met die domme dependancy hell en werkt gewoon altijd. Jammer dat zoveel mensen de hakken in het zand zetten.

Ze zetten ook de hakken in het zand omdat Snap een gecentraliseerd proprietary backend gebruikt beheerd door Canonical. Kijk eens naar Flatpak, zelfde idee als Snap maar geen proprietary componenten aanwezig en iedereen kan zijn eigen repository opzetten.

[Eonfge]

Al die fragmentatie is enorm slecht voor het ecosysteem. Het enige minieme voordeel van fragmentatie is voor hobbyisten die om wat voor reden dan ook een soort religie van distro's hebben gemaakt en zich in discussies ingraven tegen alles wat niet per sé hun distro is.

Het logische gevolg van een vrije markt werking welke concurrentie aanmoedigt.

[caipirinha]

Die "dependency hell" wordt voornamelijk veroorzaakt door incompetente programmeurs met obscure shortcuts, vage libraries etc.
Of die te bang zijn om compileerbare sourcecode te distribueren.

[DigitalExorcist]

Dat is niet de verdienste van- of exclusief voor opensource.... dat zou een commerciële partij ook prima kunnen.

Denk aan Microsoft die met Windows S komt of met een Server Core installatie.

Eigenlijk zou Windows 10 ook zo moeten zijn. Standaard een Core installatie en een -bij wijze van spreken- autoexec.bat met wat standaard opties die je daarna wil hebben. Wil je een GUI? Optie 1. Wil je Edge of Chrome of weet ik wat? Optie 3. Of je gebruikers ‘gewoon’ wat Powershell leren...

[walterg]

Ik zou al blij zijn als ik bij Windows 10 standaard geen Candy Crush in mijn start menu te zien krijg.

Nog blijer als er een (duurder) betaalde telemetry/datamining vrije versie zou zijn.

[Weaszel]

+1 waar kan ik die reserveren

Heb zelf 1 keer de core versie geprobeerd zonder alle extra meuk. Maar Microsoft lijkt je daar in sommige opzichten compleet tegen te werken. Dan wordt je bijna weer geforceerd naar een normale Windows versie.

[desalniettemin]

Dan moet je volgens mij W10 Enterprise hebben of misschien W10 Pro?

[icepickle]

Nee, ook de Pro installeert programma's zoals het wilt, zet die vervelende spellen terug na iedere major update, en komt met een hoop dingen die je niet kunt wissen.

Op de Home heb je natuurlijk nog minder keuze, je kan niet met remote desktop op een windows 10 home pc inloggen, je kan er maar bepaalde versies van .net op installeren, je kan er geen IIS op installeren, en je hebt nog minder keuze

[Loggedinasroot]

Windows is denk ik een erg slecht voorbeeld met alle crap die ze je forceren.

[Dennism]

Ik denk dat Windows eigenlijk een prima voorbeeld is omdat je een zeer minimale core variant hebt aan de ene kant en een volledige variant waar in bepaalde mate voor de consument wordt gedacht en alles daartussen in.

[Damic]

Windows Server heeft meerdere varianten waaronder een Core variant en dan zou dit nog wel eens goed kunnen zijn.

[Dennism]

Dat bedoel ik inderdaad, je hebt alles van Core tot versie's als Windows 10 S/X/Home

[DigitalExorcist]

Welke crap forceren ze je precies met de S versie of met de Server Core versie die ik benoem?

En welk deel van "eigenlijk zou Windows 10 ook zo moeten zijn" is onduidelijk precies? Dan kan ik daar volgende keer rekening mee houden en dat nóg iets meer benadrukken.

[Reactie gewijzigd door DigitalExorcist op 22 juli 2024 15:56]

[Bliksem B]

Kan ook wel via een grafische user interface...
Voor de rest een goed voorstel.

[dasiro]

da's niet de user-experience die het merendeel van de gebruikers wil. Je mag al blij zijn dat ze weten wat een browser is, laat staan dat ze weten wat een GUI is of kunnen lezen (no joke)

[N8w8]

Als bedrijf A hun closed-source product verandert op een onwenselijke manier, dan kan alleen A daar wat aan doen. In dit geval doet A iets (volgens velen blijkbaar) stoms, en kan B daar wat aan doen.
Wat je al zegt, eigenlijk zou Windows zo moeten zijn. Nou dan verander je dat zelf toch gewoon? Of betaalt een developer/bedrijf dat voor je te doen? Oh nee kan niet want closed source.

[Reactie gewijzigd door N8w8 op 22 juli 2024 15:56]

[delphium]

Dat is niet de verdienste van- of exclusief voor opensource.... dat zou een commerciële partij ook prima kunnen.

Denk aan Microsoft die met Windows S komt of met een Server Core installatie.

Nee, want dat is geen vrije software! Ik blijf het erg jammer vinden dat veel mensen de werkelijke waarde van open source / vrije software niet inzien. Het gaat niet om "gratis" of "keuzevrijheid". Het gaat om kennisdeling (open source) en de vrijheid / mogelijkheid om met die bestaande kennis iets nieuws te maken (vrijheid) en dat dus weer opnieuw te delen met anderen.

Wat Microsoft doet, druist daar volledig tegen in doordat ze hun eigen kennis grotendeels niet delen. Canonical verneukt ook het hele concept van open source door standaard closed source troep mee te leveren omdat dat zo lekker makkelijk is. Bovendien pushen ze vaak hun eigen meuk die weliswaar open source is, maar niet gedragen door de community (niet vrij!)

Freedom comes with a price. In het geval van open source, is dat een heel klein prijsje in de vorm van (gratis en vrije) kennis moeten opdoen van de techniek waarmee je werkt. Soms is dat frustrerend, als bijvoorbeeld je hardware niet doet wat je wilt en je uren bezig bent om een oplossing te vinden, maar hey! Die oplossing vind je uiteindelijk juist doordat andere mensen hun kennis delen met jou.

De reden om voor open source te kiezen zou veel meer moeten voortkomen uit het besef dat gesloten software echt heel erg onwenselijk is! Soms maakt dat je dag wat lastiger, maar heel vaak ook een stuk makkelijker ;-) Raak gerust eens onder de indruk van het feit dat er zo'n gigantische hoeveelheid mensen bereid is om hun kennis met jou te delen en jou de vrijheid te geven met die kennis weer iets nieuws / mooiers te maken.

[DigitalExorcist]

Vrije software is leuk maar ik ben geen programmeur en kan de code dus niet overzien. En jijzelf hebt ook niet alle broncode van alle Linuxkernels die er zijn gelezen en nagelopen.

We gaan er allemaal maar van uit dat anderen dat wel zullen doen... en er is niemand eindverantwoordelijk voor het resultaat.

Open source is leuk maar geen garantie voor veiligheid.

[delphium]

Ik heb het toch helemaal niet over veiligheid? Ik heb het over kennis (in de vorm van software) vrij beschikbaar stellen.

We gaan er allemaal maar van uit dat anderen dat wel zullen doen... en er is niemand eindverantwoordelijk voor het resultaat.

Dat is wel een eerste klas dooddoener! Hoezo is er niemand eindverantwoordelijk voor het resultaat? Als een OSS-project actief wordt ontwikkeld, zijn bug-fixes meestal heel snel en die worden wel degelijk ook door de community gecontroleerd.

En het omgekeerde is net zo waar:
"Closed source is leuk maar geen garantie voor veiligheid".

[DigitalExorcist]

Dat is zo, maar als er een fout in een closed source pakket zit weet je wie je daarop moet aanspreken. Bij open source is het altijd maar de vraag waar je terecht kunt. Ja, bij "de community" ... maar daar wordt je ook niet wijzer van.

[delphium]

Dat is echt de grootste misvatting ever! Heb jij wel eens geprobeerd als consument aan te kloppen bij Microsoft? Nou veel succes! Zelfs als Microsoft Gold partner moet je nog hemel en aarde bewegen om iets voor elkaar te krijgen. Juist bij open source weet je vaak precies wie de ontwikkelaar is en kun je die persoon rechtstreeks benaderen met vragen/opmerkingen.

Het zijn de standaard argumenten van mensen die alleen maar Windows gewend zijn en wel eens lezen over bugs in open source software.

[DigitalExorcist]

Als er bij Microsoft iets stuk gaat heb je een gigantische bak aan betaalde support die hemel en aarde voor je bewegen om het opgelost te krijgen is m’n (praktijk!)ervaring. Dus tsja.... gewoon aankloppen bij degene die het stukgemaakt heeft.

[delphium]

Ik zou hier graag uitgebreid je persoonlijke ervaring met support van Microsoft willen zien. Mijn ervaring vanuit een MS-Gold partner bedrijf als lead-developer was namelijk echt uitermate teleurstellend. Niet één keer, maar tot wel drie keer toe. Sterker nog. Juist dat is de reden geweest dat ik weer vol overtuiging ben teruggekeerd naar OSS. Die community's hebben me echt nog nooit in de steek gelaten.

[DigitalExorcist]

Mijn persoonlijke ervaring:

Maandagochtend support ticket ingediend, na 30 minuten gebeld met de vraag extra info omtrent de AF en infra aan te leveren, uur later teruggebeld door een engineer die mee kon praten alsof die al weken in-house had gezeten en het probleem snel opgelost kreeg (iets met site to site replication en AD sync naar Azure)

[mbbs1024]

Inderdaad, ik heb indertijd hemel en aarde moeten bewegen om een bug in Windows opgelost te krijgen.
Na maanden proberen om MS support in beweging te krijgen, is het uiteindelijk gelukt omdat zowel de CEO van mijn werkgever (Nationale Telecom operator) Bill Gates persoonlijk kende, en hem daarover opgebeld heeft, en dat er tegelijk druk naar MS was van de eindklant (Belgische multinational), en van de fabrikant van de telefooncentrale (France multinational).
Eens deze horde genomen, kreeg ik wel een ontwikkelaar te spreken, die de zaak opgelost heeft, en de patch na uitgebreid testen aan onze zijde, toegevoegd heeft aan de volgende update cyclus.

[Verwijderd]

Omdat een GUI-loze Core variant van Windows 10 geen enkel doel heeft. Als je dat wilt, dan is er Windows Server. 99.999% van de gebruikers kan niks met een kale Windows 10 die in een cmd-venster boot. Heck, het merendeel van Windows Server "beheerders" is al verdwaald als ze geen clickyclick kunnen doen door het OS heen.

[DigitalExorcist]

“Either learn Powershell or learn ‘would you like fries with that’”

[Verwijderd]

Helaas zijn er nog genoeg bedrijven waar mensen aan de bak kunnen als systeembeheerder/engineer zonder een regel Bash/Powershell/Python te kunnen schrijven.

[rene_fb]

Ik zie hier vooral in dat open source ook geen heilige graal is.
Ook in open source packages kunnen ze blijkbaar gekkigheid uithalen.

[Verwijderd]

Dit heeft niks te maken met open source of niet. Ubuntu word door een bedrijf gemaakt en onderhouden, die kunnen doen wat ze willen. Doordat het open source is kan een groep zoals mint daar een eigen draai aan geven. Dus open source zorgt hier alleen maar voor een alternatief van mensen die niet van gekkigheid houden, linux mint.

Als windows open source was hadden we nu windows mint, waar je zelf kan kiezen welke updates je installeert, ze oneindig kan uitstellen, je geen ads in je OS te zien krijgt, en je niet de windows store door je strot geduwd krijgt. Maar helaas

[TweetCu]

Er is LTSC als je meer afgestript wilt, alleen kan je hier niet zo makkelijk een licentie voor krijgen en is dit bedoeld voor productie systemen die zo min mogelijk feature updates mogen krijgen, alleen beveiliging.

Het is wel mogelijk om een LTSC 2019 ISO te pakken te krijgen en dan een activator te gebruiken, is alleen niet legaal.

Voor Windows 10 kan (Althans Pro, weet niet of Home dit ook heeft), kan je Updates uitstellen tot paar maanden tegenwoordig.

[Reactie gewijzigd door TweetCu op 22 juli 2024 15:56]

[DigitalExorcist]

Voor Windows LTSB zelfs tot 10 jaar...

[sam_vde]

Polariseren is de dood van open source. Linux Mint had misschien kunnen aanbieden het deb package te onderhouden voor Canonical, dan hadden ze eens iets bijgedragen.

De redenen zijn immers onderhoudbaarheid, zoals inmiddels tot in den treure herhaald werd: https://snapcraft.io/blog...tu-deb-to-snap-transition .

Al de rest zijn intentieprocessen en daar hou ik niet van maar goed. Niets aan te doen.

[GekkePrutser]

Polariseren is de dood van open source. Linux Mint had misschien kunnen aanbieden het deb package te onderhouden voor Canonical, dan hadden ze eens iets bijgedragen.

Hadden ze kunnen doen maar Ubuntu pusht snap meer uit commerciele overwegingen. Er zijn heel veel kleine tooltjes waar het totaal geen zin heeft. Ze willen gewoon de de facto standaard worden ipv appimage of flatpak. Gaat niet lukken want de store is niet open, maar ze proberen het toch weer.

Ze hebben het met Mir, Unity en Upstart ook geprobeerd en nu dit weer.

[Reactie gewijzigd door GekkePrutser op 22 juli 2024 15:56]

[sam_vde]

Ik ga niet herbeginnen nu, over al die dingen zijn rationele zaken te zeggen .

Haters will hate. Gebruik wat anders, iedereen happy.

[GekkePrutser]

Ik haat Ubuntu helemaal niet, ik gebruik het zelfs nog steeds (en al sinds 2008). Ik kan toch best kritisch zijn over de ontwikkeling?

Canonical is bovendien bezig zich hard voor te bereiden op een overname (er gaan zelfs geruchten dat Microsoft dit gaat doen) en een sterk intellectual property is hierbij een grote plus natuurlijk.

[Reactie gewijzigd door GekkePrutser op 22 juli 2024 15:56]

[sam_vde]

Mint rekent nog veel meer op Ubuntu en doet toch ook gewoon mee aan die desinformatie.

De geruchten zijn al jaaaaaaren wat ze zijn, maar Canonical werkt wel degelijk aan een IPO en dat is niet hetzelfde. De rest zullen we wel vanzelf zien maar voor het geld zullen de grote jongens het niet moeten laten denk ik.

[zordaz]

Hoewel niet constructief geloof ik niet dat polariseren 'de dood van open source' is. Er zijn sinds de jaren 90 zo vaak verhitte discussies in de OSS hoek geweest die uiteindelijk altijd wel kalmeerden. Dit is er gewoon weer eentje van. Denk bijv. ook aan: XFree86 vs Xorg, OpenOffice vs LibreOffice, GCC vs EGCS (lang geleden!), Systemd, QT vs GTK (lang geleden!).

Het staat Canonical vrij om te doen wat ze wil, gelukkig is er keuzevrijheid. Ik ben geen fan van Snap wegens het gecentraliseerde karakter en de performance, maar vind wel dat het een probleem oplost. Dus gebruik ik alternatieven als Flatpak en AppImage op mijn Xubuntu installaties als dat nodig is.

[Reactie gewijzigd door zordaz op 22 juli 2024 15:56]

[sam_vde]

Akkoord, heb getwijfeld om het te laten staan.

[robkorv]

Een snap is toch gewoon een yml bestand dat is in te zien? Ik vind de opmerking 'niet controleren, vasthouden of aanpassen' vreemd overkomen.

[Blokker_1999]

Zoals ik het lees is Snap in Ubuntu in essentie een vervanger aan het worden voor APT waarbij pakketten in een store worden aangeboden. Deze zijn platformonafhankelijk (bevatten dus alle benodigde libraries wat voor- en nadelen heeft) en zouden dus op elk platform kunnen werken. Maar ik lees ook dat je bijvoorbeeld automatische updates niet kunt uitschakelen (wat voor problemen kan zorgen als services herstart moeten worden of wanneer pakketten niet goed getest zijn en fouten bevatten). Je kan een pakket dus niet eerst in een testomgeving installeren om te controleren en je kan dus ook niet even zeggen: ik wil nog niet updaten.

Verder lees ik dat de server kant van snap closed source is en beheerd wordt door Canonical. Je hebt dus ook niet de optie om je eigen store op te zetten met je eigen pakketten waarin je de versies kunt zetten die jij wenst of met aanpassingen die jij wenst.

[Jorick]

Je kunt zelf bepalen wanneer snaps updaten, zie https://snapcraft.io/docs...ding--controlling-updates. Als een update niet bevalt kun je altijd weer terug naar de vorige revisie m.b.v. snap revert.

Overigens bieden de meeste pakketten meerdere kanalen aan dus als je geen zin hebt om verrast te worden door een update dan kun je het beste gewoon de stable channel van een snap gebruiken. Een andere optie is om zelf een Snap Store Proxy op te zetten zodat je updates eerst kunt testen voordat je ze uitrolt naar andere systemen.

[robkorv]

Ik denk niet dat snap gebruikt gaat worden voor server applicaties. Het voornamelijk handig voor desktop software. Ik vind het bijv erg fijn voor discord, obs-studio, Spotify en ffmpeg. Obs en ffmpeg heeft alle nvenc en nvdec beschikbaar. Dit scheelt zoveel gedoe met zelf moeten compileren en alle problemen die je kan tegenkomen met versies van dependencies die niet beschikbaar zijn voor de distributie die je draait. Ik zie overigens dat alles van snap opensource is. Het staat allemaal op GitHub.

[PureTryOut]

Ik zie overigens dat alles van snap opensource is. Het staat allemaal op GitHub.

Maar het server component niet. Kijk in plaats daarvan eens naar Flatpak. Zelfde idee, maar geen proprietary componenten aanwezig.

[robkorv]

Het staat toch echt allemaal op github
https://github.com/snapcore/snapd
https://github.com/snapcore/snapweb
https://github.com/snapcore/snapcraft
https://github.com/canonical-web-and-design/snapcraft.io

Wat mis ik?

[Blokker_1999]

De server, je weet wel, dat ding waarmee snap gaat verbinden om pakketten te kunnen downloaden en installeren. Dat staat niet op github, is closed source en enkel Canonical kent de ins en outs van dat ding.

[sam_vde]

Het zou zeker goed zijn als Canonical die code zouden publiceren. Maar er zijn ook andere kanten aan Flatpak en overwegingen voor a of b te kiezen. Ik was origineel gestandaardiseerd op Flatpak maar heb er slechte ervaringen mee gehad en ben er voorlopig vanaf gestapt.

Ten eerste is er amper curating van de store als het een keer misloopt. Ik ben hier tegenaan gelopen https://github.com/flathu...46#issuecomment-450434727 en het heeft toch 5 à 6 maanden geduurd om die oude versie uit Flathub te verwijderen zonder enige communicatie naar de gebruiker. Alex Larsson heeft me toen bovendien gemeld "dat Flathub geen deel is van Flatpak" alhoewel ze de repository aanraden op de flatpak website. Dat vond ik niet ok: een half jaar is gewoon veel te lang voor een mail client in de context van dit formaat en deze repository. Het is dan open source, maar heeft de doorsnee gebruiker iets gewonnen?

Dat de snap store werkt met geverifieerde publishers vind ik dan ook een pluspunt dat ik hierdoor ben gaan waarderen. Als de applicaties van upstream komen maakt de store me eigenlijk minder uit. Ik gebruik dus enkel snaps van upstream of canonical zelf voor toepassingen die ik graag "latest and greatest" heb en dan moeten ze me ook niet wandelen sturen als ik een probleem meld.

Ten tweede had ik meer platform en theme flatpaks als applicaties (in aantal en ook qua disk space). Storage is goedkoop hoor je dan zeggen, maar dat geldt niet voor elk type storage en ook niet voor alle toestellen (bv toestellen met eMMC storage in) en die GB neem je natuurlijk ook mee in je updates die via het web binnenkomen en ze komen ook terecht in je backups.

Daaruit blijkt ook dat die applicaties niet snel aangepast worden aan nieuwe versies van de platform flatpaks en dat geeft ook geen goed gevoel. Ik had al gauw 3 Gnome flatpaks, 2 KDE, en 2 Freedesktop en nog wat NVidia dingen en die waren (denk ik allemaal) >GB groot. Dat kan natuurlijk aan de applicatie gelegen zijn, maar voor snaps is dat beduidend minder. Lang verhaal kort: voor een 15 à 20-tal applicaties had ik 25GB nodig, waarvan meer dan de helft nodig was voor de platform flatpaks. Daarvan had ik er meer als applicaties (ergens rond de 20 denk ik).

Om een idee te geven: mijn lijst applicaties bestaat onder meer uit bitwarden, brave, vs code, gimp, inkscape, krita, libreoffice, opera, skype, slack, spotify, telegram en vlc. Niet bepaald exotische dingen. Ik heb ongeveer 8GB aan snaps nu. Libreoffice is de grootste app met 420MB, VLC neemt ook 300MB. De andere apps uit de lijst variëren zo tussen 150 en 200MB. Ik heb elke snap ook dubbel, zijnde de huidige en de vorige versie voor rollback. Dat is standaard zo en kan je denk ik niet uitschakelen. Daar verlies ik dus 4GB van de 8GB mee (ik heb eigenlijk geen nood aan die optie).

Ten derde vind ik het ook niet ok dat Flathub voor issues verwijst naar de upstream projecten als de packages niet door upstream aangeleverd worden (ElementaryOS heeft daar een keer op gereageerd, al gaan ze nu voor hun eigen OS ook op flatpak standaardiseren). Veel vragen zijn Flatpak specifiek en die eerstelijn zouden ze zelf moeten opnemen (dus verwijzen naar de flatpak github voor de specifieke applicatie in een eerstelijn), en al zeker als ze het upstream niet eens gevraagd hebben. Hoor je amper kritiek op, toch ook een ethische vraag denk ik. Die geverifieerde publishers in de snap store lost dat probleem vanzelf op.

Dustin Kirkland heeft tot slot jaren geleden eens een prototype gepubliceerd op zijn blog om zelf een snap store op te zetten. Niemand heeft het gedaan dus ik weet niet goed of er echt zoveel vraag is om dat te doen hoor. Uit principe wel, akkoord, maar dan vind ik die geverifieerd publishers persoonlijk toch interessanter, zeker in vergelijking met de andere dingen die ik hierboven aanhaal.

Edit: beetje disk space info meegegeven.
Edit 2: ik begruik ook enkele appimages als ze rechtstreeks van upstream komen, en daarvoor gebruik ik https://github.com/TheAssassin/AppImageLauncher om deze te integreren in je launcher etc.

[Reactie gewijzigd door sam_vde op 22 juli 2024 15:56]

[Blokker_1999]

Er zijn wel degelijk snaps te vinden van services en dat geeft soms slechte neveneffecten. Bijvoorbeeld https://forum.snapcraft.i...h-for-snap-from-store/707

[sfranken]

Met iets als APT pinning kun je aangeven dat, bijvoorbeeld Firefox, nooit hoger mag zijn dan versie 76 (om maar een dwarsstraat in te gaan). Zover ik kan zien is dat met een snap niet mogelijk, en zal deze dus updaten wanneer er een nieuwe versie beschikbaar komt in de snap store.

Toegegeven, ik heb zelf nog nooit een package moeten pinnen op Ubuntu, op Debian en niet op Fedora. Maar goed, dat is een samplesize van N=1, dus niet echt representatief natuurlijk.

Canonical is in mijn ogen verkeerd bezig met de agressieve manier waarop ze snaps aan het pushen zijn.

[dmantione]

In plaats daarvan vervangt het team deze package met een 'leeg pakket dat gebruikers vertelt waarom het leeg is, en instructies bieden voor het installeren van Chromium'.

Deze snap ik niet, waarom niet gewoon doen wat de gebruiker vraagt en Chromium installeren? Mint is toch geen Ubuntu.

[Blokker_1999]

Mint is gebasseerd op Ubuntu en neemt in de basis gewoon paketten over van Ubuntu met eigen patches eroverheen. Hier kiezen ze er bewust voor om apt nooit snapd te laten installeren als dependency zodat gebruikers er actief voor moeten kiezen. En als Canonical in de toekomst gaat kiezen om meer pakketten op deze manier te distribueren en dus in essentie apt wenst te vervangen met snap dan zou dat enorm veel werk betekenen voor een distributie als Mint en mogelijks het einde van die variant.

[N8w8]

Ubuntu is Debian met (o.a. dit soort) veranderingen.
Als die veranderingen problematisch worden, kunnen ze ook "gewoon" Debian als basis gebruiken.
Maar ja dat is dan wel het einde van de Mint variant gebaseerd op Ubuntu.
Er is (was?) ook al een Mint Debian variant, dus zo onvoorstelbaar is dat niet; vraag me wel af hoeveel dat verschilt/-de van Mint Ubuntu.

[Blokker_1999]

Die Debian editie bestaat inderdaad gewoon al, maar omdat Debian terughoudender is dan Canonical heb je daar dus oudere versies van vele programmas in zitten.

[desalniettemin]

Is Debian niet ook nogal ongeschikt voor gamen, omdat het nogal oudere programma's, pakketten gebruik en ook ongeschikter is voor nieuwere hardware, terwijl de standaard Mint dat wel is?

[Reactie gewijzigd door desalniettemin op 22 juli 2024 15:56]

[N8w8]

(mss ook @Blokker_1999)
Ubuntu is nieuwer dan Debian stable, omdat ze Debian testing/unstable gebruiken als basis.
Als ik hier kijk deed Mint Debian dat ook al.
Wat betreft gamen; SteamOS is/was ook gebaseerd op Debian.

Overigens draai ikzelf Debian stable, en merk weinig van die vaak genoemde ouderdom.
Ben je geen developer/enthousiasteling, maar "gewoon" een user die wilt dat zijn systeem blijft werken, is het geen ramp om 0-2 jaar oude software te draaien. Zo wereldschokkend revolutionair veel gebeurt er nou ook weer niet in zo'n korte tijd imo.
Nieuwe shiny foefjes kan je vaak nog krijgen via backports of een Ubuntu PPA, of desnoods zelf compilen. En anders hooguit 2 jaar ofzo wachten, maar als je bedenkt dat je het al je hele leven zonder hebt gered, is dat ook wel te overzien.
Maar goed, geen ervaring met gamen (behalve wat q3a), wellicht dat het dan nauwer komt.

[Reactie gewijzigd door N8w8 op 22 juli 2024 15:56]

[Blokker_1999]

SteamOS was initieel gebasseerd op Ubuntu maar is later overgeschakeld op Debian. Kan me het verhaal niet meer herinneren, maar dacht dat het daar ook te maken had met een zo breed mogelijke compatibiliteit te bekomen.

[desalniettemin]

Ik ben ook helemaal geen gamer. Boeit me totaal niet.

[CHBN]

Gelukkig leert men van de history, en heeft men op voorhand al een optie lopen.

LMDE
Its goal is to ensure Linux Mint would be able to continue to deliver the same user experience, and how much work would be involved, if Ubuntu was ever to disappear. LMDE is also one of our development targets, to guarantee the software we develop is compatible outside of Ubuntu.

LMDE aims to be as similar as possible to Linux Mint, but without using Ubuntu. The package base is provided by Debian instead.

[Reactie gewijzigd door CHBN op 22 juli 2024 15:56]

[desalniettemin]

Is het daardoor niet ongeschikter voor nieuwere hardware, omdat het de 4.19 kernel gebruikt?

[pasarica]

I see what you're doing... Peppermint

[sfranken]

Omdat ze geen base package hebben wat ze kunnen gebruiken. Mint IS Ubuntu onderhuids, dus als Canonical geen werkend (snap-loos) Chromium pakket voor 20.04+ levert kan Mint deze ook niet meeleveren, als ik het goed lees in ieder geval.

[Verwijderd]

Niet helemaal, Mint heeft ook een Debian only en heeft niets met Ubuntu te maken. Daarnaast snap ik het even niet. Als je snapd geïnstalleerd hebt dan kan je een sudo snap install chromium-browser doen en er wordt netjes een snap-package aangemaakt. Als je snapd niet geïnstalleerd hebt volstaat het om gewoon sudo apt install chromium-browser te doen en je krijgt de ouderwetste deb geïnstalleerd. Je hebt in Mint altijd al, dus ook voor 19.x als versie 20 gewoon de keus om snapd te installeren.

[sfranken]

Als je snapd geïnstalleerd hebt dan kan je een sudo snap install chromium-browser doen en er wordt netjes een snap-package aangemaakt. Als je snapd niet geïnstalleerd hebt volstaat het om gewoon sudo apt install chromium-browser te doen en je krijgt de ouderwetste deb geïnstalleerd.

Zoals ook in het artikel staat kan dat laatste met 20.04 dus niet meer. Als je 'apt install chromium-browser' doet installeert het systeem dus NIET de deb versie, maar het volgende:

1) snapd
2) de snap versie van Chromium

Edit:
Dat is Ubuntu. Als Mint meegaat met hun parent distro kan het in 20.x dus niet meer om 'apt install chromium-browser' te doen en dan de deb variant te krijgen.

[Reactie gewijzigd door sfranken op 22 juli 2024 15:56]

[Verwijderd]

Dat begrijp ik, maar dat is Ubuntu. Aangezien Mint snap niet standaard geïnstalleerd heeft zal er nooit automatisch in Mint een snap aangemaakt worden.

[sfranken]

Ik had mijn reactie aangepast. Het punt is dat Mint de pacakges van Ubuntu uitlevert (zie ook je sources list). Mint heeft, zover ik weet, geen eigen mirrors met alle packages die je kunt installeren, dat is nog steeds op basis van de infrastructuur van Canonical.

En dus, als je straks op Mint 20, een apt install chromium browser doet krijg je de snap variant + snapd geinstalleerd. Tenminste, als ze het 1:1 overnemen, wat volgens het artikel dus niet gaat gebeuren.

[Verwijderd]

Dus dan nog... dan verandert er niets In 19.x was er al een differentiatie tussen apt install en snapd install, ook met chromium-browser. In 20 wordt het dus gewoon gecontinueerd.

[sfranken]

Nee. Met 20.04 (en Mint 20 gebruikt de packages van Canonical, en de mirrors) is de deb Chromium browser een 'meta package' geworden naar de snap versie, om die terminologie maar te gebruiken. Hopelijk is het nu wel duidelijk, want ik heb een beetje het gevoel dat wat ik zeg niet tot je doordringt of dat ik het niet duidelijk uitleg.

Denk je dat Mint zelf al zijn eigen packages host? Dat is niet, het gros komt gewoon een op een van de Canonical mirrors af. Alleen het eigen spul wat Mint heeft (Cinnamon) word door hun zelf gehost en gepackaged. Zie ook je apt sources voor de bronnen welke je OS gebruikt. Mint, en veel distros die Ubuntu als ouder gebruiken maken zeer dankbaar gebruik van de servers van Canonical (en de mirrors) voor hun pacakges, omdat deze distros geen aanpassingen doen in 99% van de software welke je met apt kunt installeren.Veel van deze distros hebben een eigen server (of mirrors) voor hun eigen custom software, welke keurig als extra source in APT geconfigureerd is.

Als de developers van Mint niet deze actie hadden gedaan en gewoon de packages van Ubuntu 20.x hadden gebruikt voor Mint 20 had je met een apt install chromium-browser dus snapd + de snap versie van Chromium gehad. Chromium in Mint is nu dus een eigen package wat ze moeten pushen. Wie weet welke software Canonical in de toekomst nog meer zo gaat pushen.

[Reactie gewijzigd door sfranken op 22 juli 2024 15:56]

[Verwijderd]

Ik begrijp helemaal wat je zegt, ik ben ook een fervent Mint gebruiker. Maar zoveel wijzigt er niet helemaal, eigenlijk heel weinig. Wat Mint gedaan moet hebben is de packagelist blijven wijzen naar de 18.04 repository. Alles wat alleen in de 20.04 repository staat kan ik je bijna beloven dat deze niet bestaan in de 18.04. Het probleem is dat je met deze methode het probleem voor je uitschuift en het alleen maar erger maakt. Alle packages die omgebouwd worden door Canonical naar een snap-variant kan je naar fluiten. Als Canonical zijn beleid niet aanpast zal je of een eigen weg moeten gaan volgen en afscheid van elkaar moeten nemen of toch maar standaard de snapd-variant beschikbaar stellen.

[sam_vde]

Er zijn ook mensen die 14.04 hebben met Chromium en daar levert Canonical ook ondersteuning aan. 20.04+ is het probleem niet.

[Verwijderd]

? Snap even de context niet?

[sam_vde]

Als je snapd niet geïnstalleerd hebt volstaat het om gewoon sudo apt install chromium-browser te doen en je krijgt de ouderwetste deb geïnstalleerd.

Dat is niet langer algemeen toepasbaar. Maar idd past misschien niet helemaal als reactie op je post.

[Verwijderd]

In mint wel en zal de komende tijd niet wijzigen, ook met Mint 20.

[sam_vde]

Niet volgens https://community.linuxmi...are/view/chromium-browser ?

[Verwijderd]

Doen we toch een PPA? Ook weer opgelost

sudo add-apt-repository ppa:chromium-daily/stable

l[edit] Laat maar, de laatste update is van 2014 voor een Stanley release, dan wordt het idd een probleem. Dan maar de officiële Chrome installeren.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 15:56]

[sam_vde]

This PPA is dead. Don't expect updates here. ...

"Stable" is not an opinion of the quality of what's here. ...

This PPA will contain either outdated or broken Ubuntu packages 90% of the time. ...
The only reasons this might be ahead of Ubuntu is that the version here is untested or is too broken to accept.

Please use this for testing only.

Strak plan Maar hey, het is tenminste geen snap!

[Verwijderd]

Moment, zo snel ben ik niet in de hoek te slaan Laatste build op Github downloaden, compilen, runnen en klaar:
https://github.com/scheib/chromium-latest-linux

[sam_vde]

Ja daar heb ik wel afscheid van genomen een hele tijd geleden maar op zich niets tegen En ook build dependencies nodig.

Linux from scratch, dat gaat het doen

[Kewne]

Chromium is een van de meest irritante pakketten om te packagen onder degelijke omstandigheden. Gewoon de binaries van Google herpackagen is een optie waar distros niet echt op zitten te wachten.

[synoniem]

Grootste probleem is dat op de manier Canonical Chromium wil installeren de distro maintainers kan passeren. Of zoals de hoofd developer Clement Lefebvre van Mint zegt "A self-installing Snap Store which overwrites part of our APT package base is a complete NO-NO."

[sam_vde]

Mint onderhoudt geen Chromium pakketten en als ze Chromium zelf zouden hosten (ze zouden dat misschien kunnen aanbieden, Chromium is community maintained in Ubuntu alleen neemt het desktop team die rol op) kunnen ze hun deb een hogere prioriteit geven.

[bvdli]

Dat is een beetje als zeggen " Ubuntu is toch geen Debian .... "

[sam_vde]

Voor context: https://pca.st/episode/4ddc0077-74b3-44f8-8f41-335fafb070aa

Jammer van de negativiteit en vooringenomenheid. Voor zover ik weet heeft niemand van de downstream distributeurs hulp aangeboden om de deb versie voor Ubuntu te ondersteunen. Klagen, dat wel.

[MadEgg]

Tja, ik heb nu debian mirrors toegevoegd en van daaruit Chromium geinstalleerd. (En overige debian packages uiteraars geblokkeerd). Werkt prima. Dus de .deb package is er. Dit is een vreemde poging van Canonical om Snap door te drukken. Komt er bij mij niet in.

[sam_vde]

Canonical ondersteunt 4 LTS releases (tot 14.04) en daar past die deb zomaar niet in. Daar is niets vreemd aan als je even de tijd neemt om je te informeren. https://readyspace.com.hk...tu-deb-to-snap-transition

Lees het eens en weet dat chromium niet eens deel uitmaakt van ubuntu main.

[MadEgg]

Dat weet ik. Debian ondersteunt minstens net zo veel. En die deb past hier gewoon in - bron: ik. Chromium uit Debian Stable past gewoon in zowel Ubuntu 19.10 als Ubuntu 20.04. Voor een oudere Ubuntu zul je een oudere Debian moeten nemen. Daarbij is het dacht ik zo dat die chromium-browser -> snap transitie vanaf 19.10 doorgevoerd is, niet van oudere versies van Ubuntu. Dus daarvoor helpt het ook weinig.

Daarnaast gebeurt het packagen van die pakketten in build farms, dus veel handwerk is er ook niet aan. Anders zouden er tienduizenden andere packages zijn waarvoor exact hetzelfde te zeggen is.

[Reactie gewijzigd door MadEgg op 22 juli 2024 15:56]

[sam_vde]

Lees de link. Je antwoordt naast de kwestie.

[MadEgg]

Ik antwoordt niet naast de kwestie. Dat verhaal heb ik al lang gelezen. Leest vooral als een promo-praatje voor Snaps. Zoals gezegd: De .debs zijn er, Debian onderhoudt ze. En die werken prima.

[sam_vde]

Graag een link naar een deb van de meest recente Chromium versie die werkt op LTS 14.04 dan?

[MadEgg]

Niet relevant, 14.04 is EOL sinds vorig jaar.

Voor 16.04 is ie gewoon bij Ubuntu beschikbaar: https://packages.ubuntu.com/xenial/chromium-browser

Voor 18.04 net zo. Daarna begint de snap-ellende, en daarvoor voldoet debian stable prima.

[sam_vde]

Je verwijst naar het werk dat Canonical zelf doet om je punt te maken maar gelooft hen niet als ze zeggen dat het te kostelijk is op deze manier. Mooi.

14.04 heeft ESM tot 2024. Relevant.
16.04 en 18.04 support vergemakkelijken is net de aanleiding. De deb installeert de snap om bestaande installaties niet te breken, dat weet je ongetwijfeld.

Het is allemaal zo makkelijk dat niemand buiten Canonical het doet blijkbaar. Volgens mij kan je niet eens een Chromium 80 deb vinden voor Debian Stretch.

[MadEgg]

De Debian build voor stretch is Chromium 73. En dus? Als je zo'n oude Ubuntu draait, waarom moet je dan wel per sé de nieuwste Chromium hebben? Security issues worden wel opgelost, dat is het belangrijkste.

Die automatische transitie is een gruwel. Het zou acceptabel zijn als de .deb package minder frequent geupdate werd en je de melding kreeg dat als je bleeding edge wilde gaan met Chromium, je moet omschakelen naar de beta PPA van Chromium zelf of snap moet gebruiken. Maar nu wordt een apt install commando sneaky omgezet in een snap commando. Totally uncalled for.

[sam_vde]

Canonical investeert resources en dus geld om de laatste versie van chromium aan haar gebruikers aan te bieden. Ik denk dat ze zelf die inschatting moeten maken.

Hoe ze dat aanpakken is hun keuze. Freedom, weetjewel. Zij zijn overgeschakeld op een snap om de onderhoudskost te drukken en ze hebben dat netjes gedocumenteerd en gecommuniceerd in publieke fora en op verschillende podcasts. Jij noemt dat soort dingen "een promotekstje voor snaps" maar je kan geen enkel technisch argument weerleggen.

Dat die automatische transitie een gruwel is is maar jouw mening. Dat Canonical een deb naar snap transitie doet om te vermijden dat duizenden mensen hun fora overdonderen met bug reports dat Chromium niet meer werkt begrijp ik zeer goed. Verder heb ik debs mscorefonts zien binnentrekken van internet, flash players, adobe libs, binaire nvidia drivers, etc. Geen hond die daarover valt. Maar een snap installeren, dan gaat Mint blokkeren. Dat kan niet. Het is bijna lachwekkend.

Ik vind dat je niets hebt aangebracht om te staven dat "Dit een vreemde poging van Canonical is om Snap door te drukken", wat Mint eigenlijk ook insinueert zonder enig bewijs of alternatief aan te bieden. Dat heet een intentieproces en dat vind ik erg problematisch. Mint had deze keuze ook kunnen maken zonder anderen van slechte bedoelingen te beschuldigen, zeker gezien de positie die Mint heeft tov Ubuntu.

Als Clem enige integriteit wil behouden moet hij alle Ubuntu gebaseerde releases van Mint per direct stoppen en verwijderen. Wie weet wat heeft Canonical nog verstopt in al die deb packages die Mint installeert. Clem moet maar consequent zijn dan.

[welmers]

Wat betreft technische argumenten is op Snap toch nog behoorlijk wat aan te merken:

- Alle snap packages zijn ontzettend traag met opstarten
- De sandboxing van apps zit ontzettend in de weg, je kan niet makkelijk bij je homedir om een file te uploaden of een gedownloade PDF file openen omdat dat allemaal afgeschermd zit. Drag en drop tussen apps werkt niet meer omdat apps niet bij /tmp kunnen. De security features schieten hier duidelijk hun doel voorbij.
- Het is niet-XDG-Basedir-compliant waardoor bv Spotify gigabytes aan cache data dumpt op een niet-standaard plek (niet ~/.cache) en ook nog steeds veranderende plek. Erg onhandig met synchroniseren/backuppen van homedirs.
- Je hebt geen controle over wanneer een snap package wordt geupdate, auto-updates is niet uit te zetten. Niet acceptabel om de redenen dat 1. ik niet wil dat als ik ergens belangrijk werk mee doe het onverwacht wordt geupdate en onverwacht stuk gaat 2. ik niet wil dat als ik achter een 4G abbo zit dat het ding zomaar van alles gaat downloaden. Basale controle waar ik waarde aan hecht in GNU/Linux wat nu ineens verdwijnt.
- De transitie van Chromium in Ubuntu ging inderdaad verre van vlekkeloos: op ons werk hebben we allemaal audio problemen gehad sinds de update naar Snap. Kwam slecht uit nu we allemaal intensief moesten videobellen.
- De compatability en samenwerking wat betreft Snap met andere distro's dan Ubuntu lijkt niet zo geweldig te zijn als Canonical doet beweren. Dat kom wellicht ook doordat ze een Collaboration Licence Agreement vereisen om verbeteringen van andere partijen te accepteren, iets wat voor bv Red Hat totaal niet interessant is om aan mee te werken. Ik denk dat de beslissing van Mint hier ook mee te maken heeft.
- Het server-gedeelte is closed source en het is onmogelijk om 3rd party repositories te draaien of toe te voegen aan de client. Zelfs het gebruiken van eigen caching/mirror servers is onmogelijk. Alles blijft volledig in control door Canonical. Ook dit maakt dat andere distro's niet echt zitten te springen om hier aan mee te werken.
- Als ontwikkelaar je software goed werkend krijgen als snap package, is door veel van deze genoemde problemen, ook al niet zo makkelijk als wordt geschetst.

Opvolgens van RPM/DEB zijn voor mij meer dan welkom, maar Snap is wat mij betreft toch een vrij slechte implementatie.

[Reactie gewijzigd door welmers op 22 juli 2024 15:56]

[sam_vde]

Veel van de dingen die je zegt kan ik onderschrijven. Mijn keuze was initieel flatpak->snaps->appimage. Nu is het snaps->appimage->flatpak. Die formaten vragen nog veel werk, ze zijn nog niet matuur.

Maar welk enkele tips.

- Opstarten valt hier relatief mee, vooral first run na installatie is traag. Maar is geweten en effectief een probleem. Ik start de meeste dingen bij het begin van de dag op maar als je veel start en sluit zeker een punt.
- Mountpoints was mijn grootste struikelblok ook. Als je je datasets mount onder /mnt kan je met de removable storage connector per snap aan je data. Dat werkt heel goed (ik heb /mnt/nfs /mnt/zfs /mnt/local oip die manier geimplementeerd).
- XDG is work in progress maar hoever dat staat weet ik ook niet. Ik merk daar als gebruiker niet zoveel van maar ik merk dat bv Firefox en Thunderbird cache ook doen in de profieldirectory houden ipv een .cache. Dat zijn de grootste verbruikers hier (spotify gebruik ik relatief weinig). Ik dacht ook dat XDG een grote rol zou kunnen spelen in een verfijnd permissiesysteem en dat zou me zeker wel interesseren.
- Je kan wel verfijnen wanneer de updates gebeuren en beperkt uitstellen zodat je die 2 punten alvast oplost, zie https://www.youtube.com/watch?v=gVZOBgTDJWc Dat dit niet onbeperkt kan is een interessante discussie. Finaal vind ik dat een gebruiker dat wel moet kunnen forceren als hij/zij daar een reden voor ziet.
- Dat geloof ik best. Ik heb ook gereageerd op die migratie hoor. Alleen maak ik er geen intentieproces van en begrijp ik ook wel dat ze op deze manier chromium makkelijk kunnen aanbieden tot gebruikers van 14.04 toe en dat je het soms niet verder moet gaan zoeken als dat. Chromium zit niet in base Ubuntu, in principe is dit community supported.
- Maar ook niet zo slecht als andere distro's beweren. Alan Pope heeft eens wat statistieken gegeven maar die video weet ik niet direkt meer terug te vinden. RedHat heeft ook een CLA. Soite, IANAL, dan kan dat een reden zijn er niet in mee te stappen - dat is keuze. Ubuntu maakt ook geen onderscheid tussen enterprise en consument qua produkt.
- Zie hierboven. Was ooit een demo voor gemaakt, niemand interesse in. Inderdaad een zwak punt, voor mij geen dealbreaker. Ik gebruik enkel snaps die van upstream komen, dat interesseert me vooral.
- Er zijn toch erg veel snaps. We zullen zien, de maturiteit is voor al die formaten nog niet perfect.

Bedankt voor je onderbouwde reactie.

Edit: ik geef nog even mee dat wij smartcardapplicaties bouwen en de nieuwe formaten daardoor ook niet kunnen ondersteunen voorlopig.

[Reactie gewijzigd door sam_vde op 22 juli 2024 15:56]

[AverageNL]

Dit is goed om nog te vermelden. Ik zal dit nog in de tekst verwerken, om zo beide kanten van het verhaal uit te lichten. Bedankt voor het melden!

Edit: De toevoeging is doorgevoerd, met 'update' in de titel om de wijziging kenbaar te maken.

[Reactie gewijzigd door AverageNL op 22 juli 2024 15:56]

[Blokker_1999]

Moet ik dit nu aanzien als een zoveelste poging van Canonical om zijn eigen tech erdoor proberen te duwen?

[- peter -]

Helaas wel, ik snap Canonical niet hoor. Unity is toch ook duidelijk een failure geweest, en toch doen ze t telkens weer opnieuw. Ik draai Ubuntu, maar hier word ik wel moe van.

[Blokker_1999]

En dan had je nog MIR. Het enige wat een beetje positief was, was Upstart, dat ze ondertussen vervangen hebben door systemd. Je zou denken dat ze leren van het verleden.

[JeroenED]

Jammer genoeg wel. Ubuntu blijft voor mij altijd het lelijke eendje in de linux vijver. Dat bedoel ik positief en negatief. Aan de ene kant hebben ze een base die voor mij superieur is, maar aan de andere kant zijn commercieel AF.

Ubuntu lostte bij mij 110 problemen out-of-the-box op en doen veel zaken op een 10x simpele manier. Aan de andere kant zitten ze snapd te pushen, hebben ze geprobeerd Mir te lanceren ipv mee te doen aan wayland, ik zit nu op PopOS vanwege gnome 3 die ik met bepaalde extensies makkelijker werken vind, maar zij zijn ook voornamelijk gericht op de eigen hardware. Is dus niet 100% best of both worlds maar komt vind ik best in de buurt. Mocht er een Linux Mint met Gnome 3 bestaan ben ik direct terug over.

[sfranken]

maar aan de andere kant zijn commercieel AF.

En wat is daar mis mee?

Mocht er een Linux Mint met Gnome 3 bestaan ben ik direct terug over.

Debian?

[sam_vde]

FUD.

Je MOET dan ook tegen systemd zijn trouwens. En budgie. En pipewire.

[sfranken]

Zo te zien wel. Zoals ik zelf zei in mijn reactie vind ik dat Canonical verkeerd bezig is met het zo agressief pushen van hun eigen spullen..

sfranken in 'nieuws: Linux Mint 20 blokkeert ongevraagde installatie van Ubun...

[Exirion]

Canonical is weer lekker bezig. Niet de eerste keer dat ze proberen gebruikers iets door de strot te duwen. Dat Linux Mint daar tegenin gaat kan ik alleen maar aanmoedigen. In de 22 jaar dat ik serieus met Linux werk heb ik Debian en de laatste jaren Linux Mint het langst gebruikt. Fijne distributie.

[sfranken]

Canonical is in mijn ogen verkeerd bezig met het zo agressief pushen van (wederom) een eigen bedachte "oplossing" voor een probleem, waar al een andere (objectieve betere) oplossing voor is. Hier heeft Canonical een handje van, denk aan Mir als vervanging voor Xorg, terwijl de rest van wereld (overdreven) werkt aan Wayland, Unity voor GNOME 3 en Upstart voor sysvinit / systemctl.

Dit soort geintjes kan van grote invloed zijn. Er komt een moment waarop gebruikers dit soort dingen zat zijn, en gaan kijken naar iets anders dan Ubuntu. Dat zag je met de migratie van Unity terug naar GNOME, toen in die periode zijn er veel mensen gaan kijken of overgestapt naar Mint, Fedora, Debian of Elementary. Ooit is er de rek uit, Canonical...

[raro007]

of linux comunitie zit weer te zeiken als ze het iets anders willen.
ziet het ook bij veel andere projecten.
ontwikkelaar maakt iets en komt een ander ontwikkelaar die het anders wil en staan er twee versie.