Ubuntu komt bij volgende LTS-release in immutable variant

Canonical brengt zijn desktopversie van Ubuntu bij de volgende LTS-release volgend jaar uit in een immutable Snap-variant. Daarbij is de rootdirectory read-only. Die Snap-variant wordt een optie en niet de standaard.

De reguliere desktopversie blijft bestaan, zegt een ontwikkelaar van Ubuntu Core volgens OMGUbuntu. Ubuntu Core is al sinds 2015 immutable. Daardoor worden veranderingen aan het besturingssysteem na een herstart teruggedraaid, wat doorgaans een stuk veiliger en makkelijker te beheren is. Dergelijke systemen zijn doorgaans ook consistenter en stabieler.

Canonical heeft verder nog geen details gedeeld over de release. De komst van een Snap-onlyvariant van Ubuntu is geen verrassing. Het hoofd Desktop van Canonical zei vorig jaar nog in een interview met Tweakers dat hij graag een immutable versie wilde. De recentste versie van Ubuntu is 23.04, een versie die onlangs door Tweakers is gereviewd.

Reacties (83)

[GhostShinigami]

hmm de vraag is hoe lang gaat het duren voordat snap verplicht word in Ubuntu (ik strip het er nu nog uit in me installs) het heeft nog steeds zo veel nadelen (bergen aan extra mounts in het mount commando, tragere boot tijden (door al die mounts), tragere start tijden van snap applicaties vs 'native' (firefox zit echt nog niet op het zelfde niveau als native, hoe veel ze ook zeggen van wel, het is een dag en nacht verschil in snappyness (no pun intended) enz...) die totaal niet opwegen tegen de 'voordelen'. klinkt alsof we dus nog wel even hebben voordat snap echt verplicht word, maar het lijkt mij dat het er wel echt aan zit te komen, waar je geen OS meer hebt zonder snap.. Gelukkig zijn er dan altijd nog 300 miljoen andere distro's en komen er waarschijnlijk nog 200 uit de grond tegen die tijd. ik snap nogsteeds niet helemaal waarom Conocical de hakken zo diep in de grond zet met snap, als er ook al alternatieven zijn (flatpak) die al breeder door de community worden gebruikt, en over meerdere distros werken. Waarschijnlijk een controle dingetje die ze natuurlijk niet hebben bij Flatpak.

[marktweakt]

Het probleem met snap is dat Cannonical het alleenrecht op de snap store heeft en wil houden. De reden hiervoor is hoogstwaarschijnlijk commercieel ingegeven anders hadden ze net zo goed Flatpak of een ander "standaard" app formaat kunnen omarmen.

Daarnaast dwingen ze gebruikers om Snap te gebruiken door het steeds meer te integreren in Ubuntu. Het is nu al zo ver dat het bijna onmogelijk is om Snap uit te schakelen en bijvoorbeeld Firefox of Chromium als native applicatie te installeren (met automatische updates en zo).

Dit alles is de reden waarom de community Ubuntu de rug aan het toekeren is.

Ik ben zelf al lang een Ubuntu LTS gebruiker (sinds versie 8 ) maar ben bij de laatste versie upgrade overgestapt naar Mint door dat Snap gedoe. Had ik al veel eerder moeten doen want Mint bevalt mij prima.

[Reactie gewijzigd door marktweakt op 25 juli 2024 08:39]

[Ariejan]

Inderdaad. het is zelfs zo erg dat een `apt install firefox` niet het package, maar de snap installeert. Sinds kort over op Arch en dat bevalt reuze goed :-)

[mbbs1024]

Idem hier, maar naar Manjaro overgestapt, = Arch zonder het omslachtige installatieproces.
Bij Manjaro kan je optioneel ook AUR, snap en flatpack aktiveren in de package manager.
Op die manier heb je nog extra mogelijkheden, als je iets niet in de standaard repositories vindt.
Je kan zelfs de debian package manager installeren en gebruiken heb ik onlangs ontdekt, als ik het installatiescript uitvoerde van een printer driver van Brother, die tijdens de installatie vroeg om die te installeren om de installatie te voltooien.

[GekkePrutser]

En daarvoor was dat ook al zo met Chromium trouwens

Ik heb Arch ook geprobeerd maar ben uiteindelijk naar BSD gegaan (met KDE wat ook enorm verfrissend was)

[Ariejan]

Welke BSD is hip tegenwoordig? Ik zou naar FreeBSD grijpen denk ik. Verdorie, nou moet ik BSD gaan proberen.... :shakes_angry_fist:

[sdziscool]

Nouja, niet echt een ubuntu probleem: je zegt het zelf al "Flatpak of een ander standaard".
Iedere grote linux distributie heeft hedendaags zijn eigen appimage, flatpak, snap of wat zal het dan ook. Allemaal eigen voor en nadelen natuurlijk en allemaal beter dan de andere standaarden (zoals altijd). Linux is gewoon een grote cluster aan nauwlijks overzichtbare prullaria die men erop heeft gebouwd.
Als men dit zou streamlinen en centraliseren zou linux opeens veel bruikbaarder/stabieler/aantrekkelijker zijn, maar dit staat regelrecht op alles waar linux op zichzelf voor staat. Een onoplosbaar probleem.

[RobTweaks]

Als Windows-gebruiker zit je met problemen waar je vrijwel niet onder uit komt. 'Gestreamlined', ja. Gecentraliseerd, ja ook. Maar op een aantal fronten voor mij niet fijn in gebruik. Keuze heb je echter niet.

Zo hebben beide platforms voor- en nadelen. Persoonlijk blijf ik nog even bij Windows voor dagelijks/professioneel gebruik en Linux (Mint) om daar ook wat gewenning op te bouwen. Als MS het echt te bont maakt (en ze zijn hard op weg ) dan wegen de nadelen van dat gecentraliseerde concept zwaarder dan de nadelen die Linux met haar gemeenschap en werkwijze heeft.

[Hatseflats]

Klopt, maar dat mes snijdt aan 2 kanten.

Hierdoor ben je ook verlost van vendor lock in-achtige praktijken.

Er zal vast wel een fork komen die dit standaard niet heeft, als het de juiste mensen begint te irriteren. Vraag het anders aan linux Mint t.o.v. Ubuntu Desktop.

Om maar met Johan te spreken: "Elk nadeel heeft heb ook weer zijn voordeel."

[Reactie gewijzigd door Hatseflats op 25 juli 2024 08:39]

[Jittikmieger]

Tja, ik gebruikte Ubuntu LTS al sinds ergens sinds het begin van deze eeuw... (We worden oud! ) Sinds Warty Warthog volgens mij. Ik heb het ook nog gebruikt op mijn Asus EEEPCtje (totdat ie de geest gaf) en dat zal ergens 2008 - '09 geweest zijn. Door die al Snap zooi ben ik zo'n 1.5 jaar geleden overgegaan naar Fedora - na een rondje of wat distro testen. Ik ben bij Fedora blijven hangen en dat voldoet mij nog steeds goed. Ook met de standaard Gnome desktop kan ik prima uit de voeten en het draait als ook een zonnetje op mijn 11 jaar oude Macbook Air 8GB met 128GB SSD.

Edit: ik heb de recentere versie nog wel eens even geprobeerd, maar ik kan er niet aan wennen. Ze kunnen zeggen wat ze willen, maar zoiets als Firefox in 'snapvorm' duurt mij veel te lang met opstarten. Een ergernis!

[Reactie gewijzigd door Jittikmieger op 25 juli 2024 08:39]

[Exirion]

Ik ben ooit met Slackware begonnen en naar Debian overgestapt. Een jaar of 20 geleden werd het Ubuntu en na jaren Mint heb ik weer gewoon good old Debian met de MATE desktop. Voordeel is dat die er ook voor ARM64 is en prima draait met QEMU als hypervisor op een Apple M1. Verder gewoon weer een fijne slanke distributie.

[Dr. Horrible]

Ik snap je punt en het is vanuit een puur technische en snelheidsperspectief natuurlijk geen winst. Maar het is wel een winst voor de niet technische gebruiker (waar ubuntu tochv ooral op mikt).

De technische problemen van Snap zullen niet binnenkort opgelost worden denk ik, de eerste keer een snap opstarten heeft meer voeten in de aarde dan een native applicatie omdat de runtime voor die applicatie geinitialiseerd moet worden. Als er applicaties opstarten met boot zal dus ook de boot trager worden.

Het grote voordeel is wel dat het allemaal gesandboxed is en je theoretisch geen problemen kan krijgen in je Firefox als je iets raars hebt geinstalleerd: die app kan immers niet bij de firefox runtime. Dit heeft immens veel voordelen die bijvoorbeeld ook al zo zijn op je telefoon. Ik denk dat de grote vraag gaat zijn hoe goed de sandboxing gaat zijn en of er genoeg beschikbaar komt in snap.

[Sando]

Maar het is wel een winst voor de niet technische gebruiker (...).

Het is een vendor lock-in met gesloten app store, en dat is nooit goed voor de gebruiker (en al helemaal niet in de geest van Linux), al wordt het zo aantrekkelijk mogelijk gemaakt voor gebruikers om er afhankelijk van te worden. Flatpak is de open-source en niet-vendor lock-in variant van Snapcraft. De meeste Ubuntu-derivaten die een afweging kunnen maken die echt in het belang van de gebruiker is, zoals Linux Mint, Pop!_OS en Ubuntu MATE, kiezen allemaal om Snap standaard te vervangen door Flatpak. Zie bijvoorbeeld de statement van Linux Mint in 2019:

As long as snap is a solution to a problem, it’s great. [When] it starts replacing packages for no good reason though, when it starts harming our interaction with upstream projects and software vendors and reducing our choice, it becomes a threat.

A Fedora user shouldn’t be told about Ubuntu and Ubuntu One when downloading software. His browser shouldn’t have bookmarks pointing to another distribution. His software shouldn’t be designed and tested primarily with another desktop environment and distribution in mind, and when he looks at screenshots he shouldn’t see Ubuntu everywhere.

[It’s] wrong for any vendor to think that such a store can be the only store for all Linux users. For this to work it would need to be governed by us all, with clear goals, without bias and without conflict of interest.

When Flatpak came out it immediately allowed anyone to create stores. The Flatpak client can talk to multiple stores. Spotify is on Flathub and they can push towards it. If tomorrow they have an argument with Flathub they can create their own store and the very same Flatpak client will still work with it. [The Snap] server was behind closed doors and the client couldn’t talk to multiple servers. We’ve been worried about this since then, but it was OK [because] it could provide software we didn’t have access to, and a payment platform to purchase commercial software. It’s doing much more than that though, it could reduce access to free (as in beer) software and free (as in freedom) software [by locking] us into a single store. [I] don’t think the points we’re raising here are well understood by the community.

Eén van de ex-Canonical-werknemers die aan Snapcraft heeft gewerkt adviseert ook Flatpak, en heeft zelfs een tool "unsnap" gemaakt om je Snap portfolio om te zetten naar een Flatpak portfolio.

Het grote voordeel is wel dat het allemaal gesandboxed is en je theoretisch geen problemen kan krijgen in je Firefox als je iets raars hebt geinstalleerd: die app kan immers niet bij de firefox runtime. Dit heeft immens veel voordelen die bijvoorbeeld ook al zo zijn op je telefoon.

Android heeft ook een "immutable root" doet inderdaad ook aan sandboxing en je ziet aan de lijst CVCs hoe weinig moeite hackers hebben om toch in je telefoon te breken. Er zijn zelfs zero-click exploits die na jaren aan Android-updates nog steeds zonder actie van de gebruiker een smartphone kunnen overnemen. De Nederlandse overheid heeft deze exploitkit ook gekocht.

[BeosBeing]

Flatpak is de open-source en niet-vendor lock-in variant van Snapcraft. De meeste Ubuntu-derivaten die een afweging kunnen maken die echt in het belang van de gebruiker is, zoals Linux Mint, Pop!_OS en Ubuntu MATE, kiezen allemaal om Snap standaard te vervangen door Flatpak.

Uiteindelijk zullen die dus allemaal moeten gaan overstappen op Debian, Devuan, AntiX o.i.d. als ze niet willen versmelten met Snap.

[Reactie gewijzigd door BeosBeing op 25 juli 2024 08:39]

[wica]

De reden, dat wij als hoster in 2010 overstapte van Debian naar Ubuntu. Was het "eeuwige" gezeur over bin drivers met onze HW.
Vandaag de dag is het meeste virtueel, waardoor je geen last meer hebt van driver. En het valt mij dan ook best wel op, dat veel containers als basis Debian gebruiken i.p.v. Ubuntu.

Ik juich de stap naar Debian wel toe

[BeosBeing]

De reden, dat wij als hoster in 2010 overstapte van Debian naar Ubuntu. Was het "eeuwige" gezeur over bin drivers met onze HW.

Afhankelijkheid van beschikbaarheid van drivers is lang een ding geweest omdat veel HW-makers enkel naar Windows en MacOS caterden, Inmiddels begint het omgekeerd te worden, HW-makers laten oudere versies van Windows vallen terwijl de community heel snel een port kan maken omdat er vaak nauwelijks iets veranderd hoeft te worden voordat er opnieuw gecompileerd kan worden.

Vandaag de dag is het meeste virtueel, waardoor je geen last meer hebt van driver.

Voor gevirtualiseerde servers is dat inderdaad zo. De drivers zijn dan het domein van de bare metal hypervisor. Voor de individuele gebruiker, die alleen een laptop of werkstation gebruikt, privé of zakelijk (meestal dan wel weer in een Windows-domein-omgeving) kan dat nog wel een issue zijn.

En het valt mij dan ook best wel op, dat veel containers als basis Debian gebruiken i.p.v. Ubuntu.

Als het onder Debian werkt, werkt het normaliter ook onder Ubuntu en diens derivaten. Meestal werkt het zelfs met Devuan, AntiX e.d. ondanks dat daar geen systemd in zit.

Ik juich de stap naar Debian wel toe

Debian is meestal wel goed, al heb ik ook wel gehad dat zowel een oude laptop van iemand, en mijn HP Proliant ML prima installeerde maar daarna opstartte met een zwart scherm. Ook de Debian-derivaten die ik probeerde, zoals Snowlinux en SolydX hadden dit probleem, Ubuntu Studio (toen met XFCE) niet.

[Palm_freemium]

Het grote nadeel van Snap is dat het traag is, in vergelijking met een native of flatpak applicatie. Snap en flatpak zijn ook ontwikkeld voor verschillende doeleinde.
- Flatpak is meer gericht op desktop applicaties
- Snapd kan applicaties draaien, maar ook server componenten. Hiervoor is o.a. integratie met systemd.

Beide oplossingen sandboxen de applicaties. Snap heeft dan het nadeel dat voor veilig gebruik ook AppArmor nodig is, er zijn ook artikelen die suggereren dat snap op iets anders dan Ubuntu onveilig is.

Canonical zal de snapiness van Snap niet snel fiksen omdat het geen prioriteit heeft voor ze en meeste desktop gebruikers zullen eerder Flatpak kiezen omdat het meer voelt als een native applicatie.

Ik ben zelf bijna 2 jaar terug over gegaan naar Fedora, Canonical is heel erg bezig om Ubuntu te commercialiseren. Toen heb ik ook al even Silverblue geprobeerd, Immutable OS+Flatpak, maar dat beviel toch niet. Een hoop applicaties die ik nodig had moesten toch native worden geïnstalleerd en dan is het voordeel een beetje weg. Als ik weer eens moet herinstalleren zal ik nog een poging doen.

[blinchik]

Gaat dan eerder over de server versies maar als admin vind ik het ook beangstigend dat als je je OS up-to-date houdt en verplicht security patches uitrolt, de developer van een snap of docker package gewoon met oudere vulnerable versies kan blijven verder werken. Met officiele snap of docker images (zoals bv apache ofzo) waar een groot team achter zit, zal je wel safe zitten, die gebruiken watchtower en builden hun images ook regelmatig, maar dat is met zeker niet alle projecten het geval, met kleinere projectjes (of zelfs soms interne projecten). Ik ken zelfs developers die zeggen, "dan ben ik niet gebonden aan updates en blijft het tenminste werken als het OS geüpdatet wordt". En dan passen we het later ooit wel eens aan....

Allemaal leuk, maar ik heb liever een service die down gaat of niet goed meer werkt tegenover je service / server die gehacked wordt.

[youridv1]

hmm de vraag is hoe lang gaat het duren voordat snap verplicht word in Ubuntu

Bij dit soort harde beslissingen verschijnt er meestal binnen een paar maanden een fork die weinig anders is dan het strippen van de snap verplichting in dit geval

je gebruikers dingen verplichten boot niet echt met de openheid van linux. zeker omdat je userbase niet bang is om gewoon van jouw distro af te stappen

[Reactie gewijzigd door youridv1 op 25 juli 2024 08:39]

[Hansie9999]

Ik heb op Ubuntu server ook een probleem gehad , bij installatie docker meteen ook gekozen,
en achteraf gebleken dat de docker versie die snap installeert nog extra in een soort sandbox draait, ok das extra veilig, maar mijn docker containers moeten wel echt uit de zandbak raken

heb ik de snap versie moeten verwijderen en gewoon de standaard docker geïnstalleerd (via apt-get) en dan werkte alles zoals het hoort.

Sindsdien vermijd ik gewoon alles van de snap store om geen extra problemen te hebben.

[Thijzer]

Ik zou graag een immutable OS draaien maar ik had laatst veel problemen met Docker tijdens een Fedora SilverBue installatie. Jammer want voor mij is dit wel de stap vooruit. Steam Deck gebruikt ook een immutable OS met A / B root partities en hierdoor worden hun upgrades betrouwbaar en eenvoudiger.

[eaxebx]

Welke problemen heb jij precies dan? Ik draai ook Fedora SilverBlue en gebruik docker dagelijks.

Enige waar ik tegenaan loop is SELinux in combinatie met bind mounts, maar dat los je op door “:z” achter elke volume te plakken in bijvoorbeeld je docker-compose.yml bestand.

Ik vind zo’n immutable OS echt fantastisch.

[Thijzer]

Geweldig! Ik denk dat ik idd bijna tot daar was geraakt via een tutorial maar niet lokaal werkende kreeg en dus maar opgegeven..

[eaxebx]

Zeker nog een poging waard dus.

Ook een aanrader om meteen distrobox erbij te installeren. Vind ik persoonlijk net wat fijner werken dan toolbox. Ik heb hierdoor altijd een Linux omgeving tot mijn beschikking waar ik apps op kan installeren die ik niet als een layered package wil hebben op Fedora Silverblue.

[Sando]

Enige waar ik tegenaan loop is SELinux in combinatie met bind mounts, maar dat los je op door “:z” achter elke volume te plakken

Wat doet \:z?

[Reactie gewijzigd door Sando op 25 juli 2024 08:39]

[stuiterveer]

Zorgt er voor dat je de mounts kunt delen met andere containers, bijvoorbeeld door vanuit een andere container op te geven dat je mounts wilt overnemen van die container.

Het ontgaat me alleen even op welke manier dit ervoor zorgt dat je om de "issues" van een immutable (of gaat het meer om SELinux?) systeem heen kunt werken, en wat voor issues dit dan precies zijn.

[Reactie gewijzigd door stuiterveer op 25 juli 2024 08:39]

[HollowGamer]

Het gaat meer om SELinux.

[HollowGamer]

Je hebt verschillende vlaggen, want liep hier recent ook tegenaan, dit is een klein stuk uit een docker-compose.yml (die ik opstart met podman-compose up):
volumes:
- redis:/data:rw,Z

De Z betekent dat alleen die container mag mappen. Zou ik een z geven, dan mag ik het volume hangen aan meerdere containers. Er is ook een U flag, doe je bijvoorbeeld aan user/group ID-binding (1000 in meeste gevallen), dan doet hij ook het filesysteem/volume chown'en.

[Shivs]

Op Fedora wordt Podman gepushed als standaard voor het draaien van containers. Mogelijk helpt het om dat te proberen?

[Thijzer]

Podman zou idd een oplossing kunnen zijn maar nog niet in mijn geval. De Images die ik gebruik hebben meerdere gebruikers in de containers, in podman moet je een soort pseudo gebruiker koppelen en niet de huidige gebruiker wat alles complex maakt in het geval je heel veel van dit soort containers moet draaien... Uiteindelijk wou ik gewoon Docker draaien als keuze dus wacht ik nog even.

[HollowGamer]

Ik heb geen enkel idee waar je het over hebt. Bedoel je met rootless containers? Podman draait dit niet standaard, maar het is wel aan te raden om rootless te draaien.

[djvdorp]

Lijkt mij een interessante ontwikkeling!

[Janspook]

sudo rm rf /* dan niet meer?
Altijd zoveel plezier mee gehad op school.

[rbr320]

Dat werkte eigenlijk al heel lang niet meer tenzij je de optie --no-preserve-root mee gaf, maar voor de discussie: een immutable root positie betekent simpelweg dat het root filesystem bij het opstarten read-only wordt gemount in plaats van read-write. Eventueel kun je dan nog dingen doen met een overlay filesystem dat wijzigingen tijdelijk bewaart totdat het systeem herstart wordt. Het gevolg is dat het systeem na een herstart altijd in een bekende staat is, dus zonder allerlei geïnstalleerde software die eventueel voor instabiliteit zorgt.

Updates worden atomair uitgevoerd, meestal door een geheel nieuw image weg te schrijven naar een tweede partitie en daarvan te starten. Mochten er problemen zijn kan je dan terugvallen op de oorspronkelijke partitie waarvan je weet dat die werkt.

[Reactie gewijzigd door rbr320 op 25 juli 2024 08:39]

[J_van_Ekris]

Dat werkte eigenlijk al heel lang niet meer tenzij je de optie --no-preserve-root mee gaf, maar voor de discussie: een immutable root positie betekent simpelweg dat het root filesystem bij het opstarten read-only wordt gemount in plaats van read-write. Eventueel kun je dan nog dingen doen met een overlay filesystem dat wijzigingen tijdelijk bewaart totdat het systeem herstart wordt. Het gevolg is dat het systeem na een herstart altijd in een bekende staat is, dus zonder allerlei geïnstalleerde software die eventueel voor instabiliteit zorgt.

Maar hoe configureer je dat OS dan, want je hebt zaken als netwerkconfiguratie die je toch moet vasthouden? Kun je dan de partititie tijdelijk als read/write mounten?

[davekok]

Zonder dat ik het precies weet. Waarschijnlijk door op /etc en /var en andere mappen die schrijfbaar moeten zijn. Iets schrijfbaars op te mounten. Een partitie of een bind-mount naar een schrijfbare directory. Of een overlay gebruiken. Zijn genoeg mogelijkheden.

[BCC]

Of al je services via Snap te draaien of Docker.

[youridv1]

in de meeste gevallen, of naja, wat ik gewend ben, is dat bepaalde directories wel writable zijn of dat die instellingen gescript staan en bij iedere boot weer goed gezet worden, maar dus strict genomen niet persistent zijn

[Reactie gewijzigd door youridv1 op 25 juli 2024 08:39]

[rbr320]

De partitie tijdelijk read-write mounten kan inderdaad, maar bij een volgende OS update krijg je een schoon image en ben je dus al je instellingen weer kwijt. Anderen hebben al gesuggereerd dat hiervoor bepaalde directories schrijfbaar worden gemaakt, bijvoorbeeld via OverlayFS of bind mounts, maar vaak is dat niet eens nodig. Op een desktop is DHCP voor het vaste netwerk meestal toch wat je wilt. WiFi instellingen kunnen per gebruiker in de homedirectory worden bewaard, die is natuurlijk wel schrijfbaar. Dat laatste geldt eigenlijk voor de meeste instellingen, die worden per gebruiker gedaan en opgeslagen in de homedirectory. Een immutable OS is dan ook iets dat je voornamelijk terug ziet op desktops of embedded devices die door gebruikers worden gebruikt. De Steam Deck is daar een voorbeeld van. Fedora Silverblue is ook een desktop OS en niets iets dat ik op een server zou installeren.

[Janspook]

Ah dat wist ik niet.
Is ook al een tijdje geleden.

[deadinspace]

> sudo rm -rf /*

Dat werkte eigenlijk al heel lang niet meer tenzij je de optie --no-preserve-root mee gaf,

Dat werkt gewoon hoor. --no-preserve-root beschermt alleen tegen het (recursief) proberen te verwijderen van de root, / dus. Janspook gebruikte /*, alle directories in de root dus. Die verwijdert hij doodleuk als je dat vraagt.

Sterker nog, rm -rf /* is zo'n beetje de gebruikelijke workaround voor als rm -rf / weigert.

[Reactie gewijzigd door deadinspace op 25 juli 2024 08:39]

[HollowGamer]

Ik wilde net zeggen.. het zal misschien niet alles verwijderen, zoals in use bestanden, maar het kan prima alles verwijderen wat niet in gebruik is. Verder maken iets als /home en /boot geen deel uit van het geheel, dat zijn losse mounts, die je dus ook 'gewoon' kunt leeggooien.

[deadinspace]

Bestanden die in gebruik zijn gooit Linux ook gewoon weg hoor

[HollowGamer]

Is dat zo? Ah, dat wist ik niet.
Maar goed, het is en blijft flauw, blijf gewoon van andere hun setup af.

[rbr320]

Als het de setup van een ander is heb je waarschijnlijk toch geen root/sudo rechten en is het hele verhaal alsnog onzin. @deadinspace corrigeert mij terecht dat /* alsnog werkt zonder --no-preserve-root, als je het commando zonder sudo uitvoert verwijder je dan recursief alleen bestanden waar je zelf toegang toe hebt, zoals de bestanden in je homedirectory en eventueel je mail spool file.

[RoestVrijStaal]

rm -rf ~ is toch veel "leuker"?

[Janspook]

AH ja die zocht ik hahaha.
Een keer onder examen Linux gedaan bij toen klasgenoot

[HollowGamer]

Waarom is het precies grappig? Iemand zijn werk verliezen (bijvoorbeeld een scriptie) is toch niet funny?

Het zal wel weer zo zijn dat ik geen humor heb, maar ik vind dit gewoon niet zo grappig. Dan moet JIJ ook maar voor die 'grap' opdraaien.

[RoestVrijStaal]

Met alle respect, maar als iemand die een examen Linux doet en dan zomaar een commando copy-paste-uitvoert zonder eerst goed na te gaan wat het commando doet, èn niets aan backup van zijn cruciale bestanden doet, dan mag die persoon "nog even doorleren" voordat die met zijn scriptie afstudeert.

[Reactie gewijzigd door RoestVrijStaal op 25 juli 2024 08:39]

[sfdfd]

Waarom zou je dit gebruiken als je gewoon Debian hebt??

[jozuf]

Waarom zou je Debian gebruiken als je gewoon Arch hebt
Voor elk beestje een distro.

[Baardmeester]

Inderdaad waarom zou je arch gebruiken als je opensuse tumbleweed hebt.

[sfdfd]

Omdat Debian de basis is! De rest is hier allemaal van afgeleid! Snap ie??

[pennywiser]

Alleen niet van Opensuse

[Verwijderd]

Behalve dan Red Hat, SuSE, Slackware, Arch, Gentoo, enz
Ik kan me nog wel herinneren dat Debian als nieuweling binnenkwam. Ik zat toen nog op Red Hat, ah goede oude tijd. Voor elke scheet je kernel recompilen op een Pentium 133.

[moredruid]

Debian’s 1e release was in 1993, die van RedHat in 1994. En Gentoo pas in 2002.

Ik snap jouw comment over Debian als nieuweling dus niet helemaal.

[The Zep Man]

Laten we dan maar Gentoo overslaan en meteen voor LFS gaan.

[Jochem]

Waarom zou je dit allemaal hebben geprobeerd? Terwijl je uiteindelijk weer terug naar Debian gaat.

[himlims_]

denk dat daar wel de kern zit zeker in begin jaren, veel os-hoppen, smaakjes proeven, gefrustreerd raken door een flag te missen bij gentoo of een bricked systeem met LFS [..] Om uiteindelijk weer terug bij Debian uit te komen Maar al dat distro hoppen heeft zo zijn voordeel; is een geweldig leer proces, en daarmee een aardige basis linux kennis opgedaan.

Voor mij is Debian het juiste smaakje. Echter voor mijn pa totaal niet; die draait al 'eeuwigheid' op een antieke OpenSuse build; voor hem prima. Schoonmoeder op een chromebook, voor haar prima. Ik vind linux een prachtig voorbeel van opensource en technieken; hoe divers en dynamisch dat toegepast wordt. Van embedded, tot mobiel, tot megaframes

[Alfa1970]

Eerlijk gezegd ik vind al die verschillen nogal frustrerend om software voor te schrijven.
Ze zijn allemaal net een beetje anders en hebben allemaal net een beetje andere code nodig.
Zeer frustrerend als je denkt dat je het gat eenmaal gedicht hebt om er dan achter te komen dat distributie xxx net weer dat beetje anders is en toch weer een stukje extra code nodig heeft.

[rbr320]

Ik ben geen developer maar een Linux beheerder, maar ik durf wel te zeggen dat als je tegen de subtiele verschillen in de diverse Linux distros aan loopt, dat je waarschijnlijk iets verkeerd doet. Voor de meeste dingen zijn abstractielagen. Je zou ook eens kunnen kijken of je jouw software niet beter als een Snap/Flatpak/AppImage kan distribueren zodat je helemaal geen "last" hebt van de quirks van het onderliggende OS.

[Alfa1970]

Het zijn geen substantiële verschillen, het zijn juist hele kleine dingetjes.
Maar het zijn wel dingetjes waar je goed hoofdpijn van kan krijgen.

Kijk naar APT.
De defacto standaard voor het distribueren van packages op zowel Debian (11) als Ubuntu (22.04).
Gegeven applicatie x die getest werkt op beide operating distributies.
Packages gemaakt op Debian met de toolchain die erbij hoort zijn uit te rollen op Ubuntu zonder problemen.
Maak je diezelfde packages op Ubuntu met dezelfde toolchain en exact dezelfde commando's zou je denken dat je dezelfde packages krijg. En toch werkt het niet en kun je niet naar Debian deployen.
Dat wordt gefixed in Debian 12. Maar voordat je daar achter bent ben je een paar uur graven verder.

En zo zijn er wel meer kleine dingen, die op papier hetzelfde zouden moeten zijn. En toch, net dat hele kleine beetje anders waardoor het toch nét niet werkt zoals je zou verwachten.

[Reactie gewijzigd door Alfa1970 op 25 juli 2024 08:39]

[rbr320]

Waarschijnlijk verschillen onze meningen en onze ervaringen met betrekking tot dit onderwerp. Dat een deb package gemaakt op Debian niet of niet goed functioneert op Ubuntu had ik verwacht. Ubuntu is dan misschien afgeleid van Debian en dan ook nog Testing en niet Stable, dus zijn ze vergelijkbaar maar niet gelijk. Dat het andersom wel werkt verbaast mij eigenlijk, dat klinkt meer als toeval dan dat het verwacht gedrag is.

Wat mij betreft is APT dan ook niet de juiste manier om je persoonlijke softwareprojecten te distribueren op Ubuntu of Debian. Gebruik maken van APT zou ik alleen doen als je goed in de materie zit en de complete toolchain goed hebt ingericht en geautomatiseerd, voor elke versie van Debian en Ubuntu afzonderlijk. Laat APT dus lekker aan de maintainers van de distributies en bied je eigen software aan via Snap, Flatpak, AppImage of simpelweg een tarball.

[DigitalExorcist]

Waarom zou je LFS gebruiken als je naar QubesOS kan

[Verwijderd]

Klinkt als 'Fedora Silverblue'. Idee is volgens mij dat je installatie minder verschilt per systeem (meer gestandaardiseerd), wat de kans verkleint op bugs. Na een reboot moet je core-systeem ook weer in de 'standaard' situatie verkeren.

Als het werkt zal het tzt ook wel in Debian verschijnen.

[teek2]

Ok, leuke stap, en dan daarna Ubuntu Declarative Donkey graag, de NixOS-achtige variant!

[AvWijk]

Ik kijk idd uit naar andere distros die net zo chill zijn te depoyen met een enkele configuratiefile! Revolutionair wat mij betreft.

[vDorst]

Ik zit er ook al naar te kijken, dat het een "known" state heeft bevalt me wel.
Lijkt me een mooie stap voorwaarts voor beveiliging.
Ik kon niet vinden of deze root-images ook al gesigneerd kunnen worden, zodat je measured boot kan uitvoeren.

[HollowGamer]

Ik weet niet of je dat bedoeld, maar ik dacht wel dat Fedora Silverblue met Secure Boot enabled, dus wel die signed.

[vDorst]

Secure Boot heb ik ook actief. Maar deze kijkt alleen maar of de "shim", grub en kernel gesigneerd zijn.
Wat je daarnaast nog zou willen is kijken of de root-image gemodificeerd is.

[MeMoRy]

Erg fijn voor embedded devices die van SDcards draaien lijkt me. Ubuntu had nogal de neiging de kaartjes te verslijten door continue writes.

[HollowGamer]

Dat verandert niet zo veel. Misschien schrijf je nu meer vanuit /home, maar het aantal acties blijft min-of-meer hetzelfde. Misschien wel meer, aangezien je buiten de os package-manager, ook andere nodig hebt zoals Flatpak (of snap in dit geval).

[MeMoRy]

Maar die kan je mounten op bijv een usb stick, right?

Hmm. Ik had verwacht dat dit nou juist om die reden zou zijn

[HollowGamer]

Ik weet niet wat je draait, maar het beste is alles zoveel mogelijk in het geheugen laden. Verder kan je bij bijvoorbeeld ext4 de commit rate bepalen.

Je kan je ook afvragen of het niet gewoon beter is om de zoveel tijd een nieuwe SD-kaart te halen.

[MeMoRy]

Rpi. Raspbian doet langer met een sd omdat dat ontworpen is om het aantal writes minimaal te houden.
Ubuntu is dat duidelijk niet.

Oude truc was om de sd read only te maken en de rest op usb te doen

[HollowGamer]

Voor de rPi heb je ook SSD behuizingen. Ik heb dit voor die van mij, al heb ik momenteel geen toepassing voor mijn pi4.

[MeMoRy]

Rpi3 heeft maar usb 2, dus daarvan booten is mijn inziens niet te doen. Trust me, I tried.

[Reactie gewijzigd door MeMoRy op 25 juli 2024 08:39]

[Jazco2nd]

Grappig dat MicroOS in de comments nog ontbreekt.
Lijkt me ideaal voor een Homeserver, zeker als je daar ook af en toe achter wil zitten als een soort workstation om door je collecties fotos en filmpjes heen te werken. Of om gewoon je server in een GUI te managen, achter je bureau.
Ik draai mn Homeserver met enorm veel gemak en nauwelijks ommekijk op Manjaro, heeft vooral met de default implementatie van BTRFS te maken (simpele rollbacks) wat je op andere distros helemaal handmatig zou moeten configureren. En de "App Store"-achtige ervaring zoals op een mobieltje. Geen gedoe met repositories, snap eigenaardigheden of weetikveel..

Maar als ik nu tijd had zou ik switchen naar MicroOS. Manjaro nog wel op de laptops (werkt zoveel makkelijker dan Windows). Klaar.
Ubuntu jaren mee gewerkt en verademing toen ik dat achter me liet (wist niet dat het veel makkelijker kon door een OS te kiezen die wat prettigere standaard keuzes heeft gemaakt).

[Reactie gewijzigd door Jazco2nd op 25 juli 2024 08:39]

[damouze]

Het hele gedrocht 'snap' is de reden dat ik inmiddels alweer een aantal jaren terug Ubuntu definitief de rug toegekeerd hebt. Dat en de steeds groter wordende afhankelijkheid van systemd.

Helaas wordt het steeds lastiger om onder systemd uit te komen...

[Verwijderd]

Ik heb de strijd tegen Sytemd en NetworkManager opgegeven, een distro draaien zonder Systemd leverde me meer problemen op dan dat Systemd deed. Ben nog steeds fel tegenstander tegen die monolystische applicaties, gaat ook volledig tegen de Unix filosofie in, maar goed, aan het end van de dag wil ik wel een OS waar ik op kan werken zonder de halve dag kwijt te zijn aan troubleshooting.

[damouze]

Idem hier.

Ik heb nog een paar devuan installaties rondslingeren, dat wel.