Linux-distributie Manjaro brengt immutable variant uit als testversie

Manjaro komt ook beschikbaar als een immutable besturingssysteem. Het team achter de Linux-distributie heeft een testversie van deze variant beschikbaar gesteld. Het is niet bekend wanneer het OS officieel beschikbaar komt.

De immutable versie van Manjaro is per direct beschikbaar om te testen, schrijft het team achter de Linux-distro in een forumbericht. De ontwikkelaars hopen daarmee feedback van de community te vergaren terwijl het deze variant doorontwikkelt. De variant is gemaakt met de Arkdep-toolkit, waarmee ontwikkelaars een immutable OS kunnen bouwen en onderhouden.

De testversie van Manjaro's immutable spin is te downloaden via de blogpost en vergt tenminste 32GB aan vrije opslagruimte, hoewel 64GB of meer wordt aangeraden. De distro is gebaseerd op de Gnome-desktopomgeving. De ontwikkelaars raden gebruikers voorlopig wel af om de testbuild te gebruiken als hun primaire OS, aangezien het een experimentele release is en de stabiliteit niet gegarandeerd kan worden.

Bij immutable besturingssystemen is de rootdirectory read-only. Veranderingen aan de kern van het OS worden daarmee teruggedraaid na een reboot. Dat moet bijdragen aan de veiligheid en stabiliteit van het besturingssysteem. Er zijn al verschillende immutable Linux-distributies, waaronder Fedora Silverblue en NixOS.

Manjaro Immutable
Bron: Manjaro

Door Daan van Monsjou

Nieuwsredacteur

06-08-2024 • 20:54

98

Submitter: Vanquish92

Reacties (98)

98
98
44
9
1
54
Wijzig sortering
Meh. Ik ben geen fan van immutable. Het is wellicht wat veiliger omdat het OS read-only is (al komt malware daar ook wel omheen) maar je zit vast aan de leverancier hun keuzes. En mogelijke fouten die je dan niet kan oplossen. Ik wil zelf alles kunnen bepalen.

Apple doet dit ook tegenwoordig op macOS met het Signed System Volume. Ik kon niet eens meer de sshd_config aanpassen om password login uit te zetten (alleen keys). Dan werd dat elke keer na een update heel passief-agressief op de desktop gemikt. Uiteindelijk helemaal vanaf gestapt (ook vanwege andere Apple keuzes die me niet lagen, met Apple heb je weinig in te brengen als gebruiker). Uiteindelijk op een fijne KDE desktop uitgekomen waar ik weer gewoon zelf keuzes kan maken en alles dat ik wil in kan stellen.

Misschien "gaat alles naar immutable toe" (Ubuntu beweegt ook die kant op met hun Core en apps in containers) maar ik doe alsnog niet mee. Er blijven altijd wel traditionele distributies.

Gelukkig is het hier maar een optie en kan je ook nog de gewone versie gebruiken.

[Reactie gewijzigd door Llopigat op 6 augustus 2024 21:22]

Hallo, ik ben de auteur van Manjaro Immutable.

De immutibiliteit brengt weinig qua beveiliging met zich mee. Infectie door traditionele malware zou hier inderaad mee kunnen worden voorkomen, maar als de malware of aanvaller immutable aware is dan is het triviaal om de read-only uit te schakelen. Zodra je root hebt is het een commando en het systeem staat voor je open.

Voor configuratie hebben wij een mooie overlay en een ingebouwde backup feature, daar kan je al je zooi in mikken en dan wordt dit simpelweg bovenop het nieuwe systeem gekopieerd wanneer je een deployment uitrolt.

Ik denk zeker dat immutable de toekomst is, het zal niet voor iedereen zijn, maar voor simpele thuisgebruikers en op de werkplek is het ideaal.

Ook op de server denk ik dat declarative systemen infra-as-code tools zoals Saltstack en Ansible uiteindelijk zullen verdrijven, omdat je alleen met een schone herinstallatie kan garanderen dat het systeem exact in de gewilde configuratie draait, en je kan garanderen dat je infra-as-code werkt omdat je deze voor iedere update gebruikt om het gehele systeem te herbouwen.

[Reactie gewijzigd door Omega op 6 augustus 2024 22:19]

Als het qua beveiliging weinig toevoegt, wat is dan wel de meerwaarde?

(Oprechte vraag, geen cynische opmerking ;))

[Reactie gewijzigd door sOid op 6 augustus 2024 21:41]

Wanneer het systeem locked is hebt je extra zekerheid dat er niks kan veranderen, door bugs in software, of door menselijke fout.

Het dient voornamelijk als een seintje aan de gebruiker dat ze geen handmatige veranderingen moeten doorvoeren op het systeem omdat deze een update niet overleven.

Al staan wij dit wel toe, je zou Pacman kunnen aanroepen dat dan zal aanbieden om het bestandssysteem te unlocken, waarna je eigenlijk gewoon een normale Manjaro hebt totdat je een update uitvoert met Arkdep, wat alles dan weer zal herinstalleren.

[Reactie gewijzigd door Omega op 6 augustus 2024 21:46]

Mooi werk ben je aan het bouwen, dit is echt aan de weg timmeren voor de toekomst.
Denk aan besturingssystemen voor industriele toepassingen.
Petje af voor deze weg.

Als er inderdaad meer aandacht komt voor security i.c.m. immutabillity dan heeft dat echt toekomst.
ik denk dan echt aan iets modulairs zodat je mocht er een issue zijn je de module uit je toepassing schroeft en je er een nieuwe verbeterde in doet zonder dat het systeem hoeft te stoppen.

anyway KUTGW
Dank voor de complimenten! Ik kan het zeker gebruiken, ik had een post gemaakt op Reddit over Manjaro Immutable enkele dagen geleden en werd bijna universeel uitgemaakt voor onnozele idioot die niet weet waar die het over heeft. Nogmaals dank!

Er zijn al soortgelijke systeem die voor embedded worden gebruikt, maar deze zijn allemaal minder bekend binnen de Linux gemeenschap, omdat ze complex in gebruik zijn of niet compatible zijn met normale distros. Android doet volgens mij ook iets dat hier heel erg op lijkt.

Het idee is om hier een zakelijk dienst omheen te bouwen gericht op de workstation. Het is puur een idee nu, maar stel je een soort MDM-achtige webapp voor waar men een eigen configuratie kan samenstellen en uitrollen, Iets dat geschikt is voor zowel kleine als grote organisaties.

Zover ik weet is er op dit moment geen goede MDM oplossing voor Linux machines, het zijn allemaal matige implementaties die weinig controle hebben over het systeem.

En alles wordt open source en self-hostable natuurlijk.

[Reactie gewijzigd door Omega op 6 augustus 2024 23:54]

ik had een post gemaakt op Reddit over Manjaro Immutable enkele dagen geleden en werd bijna universeel uitgemaakt voor onnozele idioot die niet weet waar die het over heeft
Ik heb die thread gelezen en grotendeels kwam die reactie omdat het... Nou ja, omdat het Manjaro is.

Jullie hebben door verschillende redenen een gigantische slechte reputatie opgebouwd als een distro en naar alles wat jullie doen word daardoor met argwanen gekeken. Ikzelf heb slechte ervaringen met jullie als een Linux mobile ontwikkelaar, de mensen waar ik interactie mee had waren (of leken in ieder geval) incompetent en dat zullen de meeste in die thread nog niet eens doorgehad hebben.
Veel zou bij jullie al verbeteren als die Philip de deur uit wordt gegooid, hij haalt het hele project neer.

Een slechte reputatie kom je niet zomaar vanaf, dat heeft jaren nodig om te herstellen. Het immutable pad op gaan helpt daar niet specifiek bij.
De community zelf legt de nadruk op een tweetal incidenten.

De eerste is dat Manjaro meerdere malen is vergeten hun SSL certificaten te vernieuwen. En dit wordt dan verdraait als een security issue, terwijl dit eigenlijk gewoon een proces probleem is. Maar het oogt zeer onprofessioneel, en daar ben ik het volledig mee eens.

Roman, bekkend van zijn werk aan graphics in KDE en Mesa, en ik gaan hier mee bezig, het doel is om de boel intern te professionaliseren en strakke processen te creëren zodat dit soort dingen niet meer fout kunnen gaan, en mocht het toch fout gaan dan moeten deze processen er voor zorgen dat er ook actief gehandeld wordt en eventuele probleem direct worden opgelost.

Het tweede zijn de AUR DDoS-incidenten, er heeft meermaals een bug in Pamac gezeten waardoor het de AUR heeft overrompeld met webverkeer. Manjaro beheert Pamac, en is dus eindverantwoordelijke, maar Manjaro is zeker niet de enige distributie die Pamac standaard aanlevert.

Dit probleem is netjes opgelost, Manjaro host die host de AUR index nu, het is maar een 8MB bestandje, maar als je tienduizenden gebruikers hebt van verschillende distros die tegelijkertijd en herhaaldelijk deze index binnenhalen, dan loopt dit toch op tot aanzienlijk wat gebruikte bandbreedte. En er is aan Pamac gesleuteld om deze functionaliteit te optimaliseren.

Ik ga niet ontkennen dat Phil Phil is, hij kan soms een beetje moeilijk zijn om mee te werken. Maar hij is wel de persoon die Manjaro de afgelopen 13 jaar als project lead heeft opgebouwd tot de (Naar schatting) 4de grootste Linux distributie op de desktop. Zonder Phil is er geen Manjaro, als hij weggaat dan overleeft het project dat niet, hij is een van de meest actieve contributors en de persoon die vrijwel alles in beheer heeft, hij besteedt tot 16 uur per dag aan Manjaro.

[Reactie gewijzigd door Omega op 7 augustus 2024 14:07]

Als een enkel iemand dit soort "macht" heeft, lijkt me dat Manjaro wel een groter probleem heeft gewoon qua bus factor...
Zelfs Linus' Linux heeft al jaren backup plannen voor moest Linus wegvallen.
Zonder Phil is er geen Manjaro, als hij weggaat dan overleeft het project dat niet, hij is een van de meest actieve contributors en de persoon die vrijwel alles in beheer heeft, hij besteedt tot 16 uur per dag aan Manjaro.
Dit lijkt mij een probleem en zou ik als ik jou was zeer zorgelijk vinden. Een project zoals een Linux distributie hoort niet afhankelijk te zijn van één persoon, die bus factor is veel en veel te groot. Het heet niet voor niets de "busfactor", als hij letterlijk onder een bus terechtkomt bij een ongeluk ligt dus het hele project op zijn gat? Dat lijkt mij echt nummer 1 probleem om op te lossen.

Die SSL certificaten waren een probleem maar vind ik opzich zo erg niet. Wat ik wel kwalijk vindt is dat Philip toendertijd als tijdelijke workaround aan iedereen geadviseerd had om hun systeem klok terug te zetten. Dat is wel een security probleem en had nooit gesuggereerd mogen worden.

Ik zit vooral in de mobile wereld en heb daar dus dingen meegemaakt. Bijvoorbeeld dat Manjaro standaard meegeleverd werd met de PinePhone (buiten de special edities om) met een Plasma Mobile image maar de hoofdaandacht van Manjaro overduidelijk bij Phosh lag. Philip heeft zelfs toegegeven dat hij niet echt wat om KDE gaf. Waarom leveren jullie het dan als de standaard interface, vooral als hij Manjaro is?! Op een gegeven moment was er een conflict met de enige KDE maintainer bij Manjaro (Strit) en is het zelfs helemaal een unmaintained image geweest. Ik vond Pine64's beslissing om over te stappen naar SailfishOS een vreemde maar dat ze überhaupt weg gingen was hard nodig.
En dan heb je nog https://dont-ship.it/, dat is letterlijk opgesteld omdat Manjaro constant work-in-progress patches verscheepte met alle gevolgen van dien. Iets recenter heeft Asahi Linux om diezelfde reden nog boos moeten zijn op Manjaro.

Ik neem aan dat jij arkane-linux bent op Reddit in welk geval ik jou niks kwalijk neem, je lijkt te weten waar je het over hebt en ik wens je het beste toe. Roman ken ik vanuit de KDE wereld en al vindt ik het jammer hoe hij daar raar vertrokken is vindt ik hem een aardige vent die zeker de benodigde technische kennis heeft. Waarom jullie in godsnaam met Manjaro gaan samenwerken snap ik echter niet. Zij hebben veel te veel "bruggen verbrand" en er zijn genoeg alternatieven die het wel kunnen.
Ik ben het volledig met je eens. Er zal wat tijd overheen gaan, maar we zullen dit zeker proberen op te lossen.

Verder kan ik enkel zeggen dat er geschiedenis achter zit waardoor dit beheersmatig zo in elkaar zit. Er zijn in het verleden dingen gebeurt waardoor dit soort toegang niet zomaar wordt verschaft aan teamleden.

Deze situatie is echter niet uniek, veel Linux distros hebben een glorious dictator for life, deze persoon houdt het project gefocust, maar dat betekend ook dat er inderdaad een enorme busfactor is.
Mwah je hebt natuurlijk het volk in specifieke reddit groepen en je hebt de mensen die het dagelijks gebruiken. Ik wil verder niks afdingen op jouw persoonlijke ervaring of dat er bij Manjaro geen fouten worden gemaakt maar immutable afschieten vanwege een vermeende reputatie lijkt me niet de juiste weg. Het een heeft werkelijk niks met het ander te maken.
Ik schiet immutable niet af, integendeel zelfs ik ben groot fan van het concept. Er zijn genoeg implementaties (openSUSE, Fedora, VanillaOS, Android) die aantonen dat het werkt en ik vindt het veel belovend en ik denk dat de meeste mensen in die Reddit thread dat ook vinden. Er is alleen geen hoop dat Manjaro het goed gaat doen door hun verleden.
Ah Reddit, de plek waar alle onnozele idioten die niet weten waar ze het over hebben bij elkaar komen. Gebrek aan zelfkennis en zelfreflectie liet ze vast denken dat je er bij hoorde ;)

Maar even serieus, ik ben het met @Kabouterplop01 eens dat dit een mooi project is. Immutable Linux distributies staan volgens mij nog een beetje in de kinderschoenen maar ik denk dat daar snel verandering in gaat komen. Er zijn veel plekken waar het gewenst is, van beheerde werkstations tot embedded devices en game consoles. Eigenlijk alle systemen waar de eindgebruiker niet ook zelf de beheerder is en dingen dus gewoon moeten blijven werken. Tegen eindgebruikers roepen dat ze moeten herstarten als hun systeem niet meer (goed) functioneert zijn we vanuit IT ondersteuning al jaren gewend, maar als het systeem immutable is kunnen we ze ook de garantie geven dat een herstart daadwerkelijk het probleem gaat oplossen.
Immutable Linux heeft inderdaad nog een enorme weg voor zich. Tot dusver heeft nog niemand de perfecte immutable weten te bouwen, en ik kan met zekerheid zeggen dat Manjaro Immutable dat ook niet zal zijn.

Ik weet ook niet of het überhaupt mogelijk is om de perfecte immutable te bouwen, of dat we voor altijd verschillende implementaties zullen hebben voor verschillende doelgroepen.
dat we voor altijd verschillende implementaties zullen hebben voor verschillende doelgroepen.
Zoals nu al het geval is met de diverse Linux distributies die er zijn. Ik denk dat de implementatie altijd samen zal hangen met het doel dat je voor ogen hebt. De een zal immutability willen gebruiken als een beveiligingsmaatregel, de ander als een snelle en zekere manier om weer in een "desired state" te komen zodat er snel weer verder gewerkt kan worden met een systeem dat op een of andere manier niet goed meer functioneerde. De techniek moet een middel zijn om een specifiek probleem op te lossen, geen doel op zich.

Daarom denk ik dat het goed is dat jullie bij Manjaro bezig zijn om hier zakelijke dienstverlening omheen te bouwen. Hopelijk krijgen jullie voldoende klanten die ook feedback geven, zodat je een beeld krijgt wat de markt wil van deze techniek.

[Reactie gewijzigd door rbr320 op 7 augustus 2024 00:01]

Ik gebruik al sinds eind jaren 90 Linux. En de afgelopen 15 jaar als daily driver. Wel een andere distro. Nu vroeger moest ik misschien manueel nog wel eens wat aanpassen ofzo, maar de laatste keer dat ik onder de /root dir wat heb moet aanpassen kan ik mij niet meer herinneren. Nu ik snap best het idee en ben er zeker niet tegen, van mij mag dit gewoon standaard zo zijn bij elke linux distro.

Zelf gebruik ik dus al jaren Linux mint. Terwijl ik liever een rolling release zou gebruiken. En de enige reden is eigenlijk tijdsgebrek en secure boot. Ik ben verplicht door mijn verzekering om secure boot hebben aan te staan. Ik heb hun die legale dienst en de verzekeraar zelf al dikwijls proberen uit te leggen dat dit geen nut heeft als je linux gebruikt ! Echter heb ik dus een dual boot ... ja ik wil nog wel eens COD spelen. Dus het is een keuze, en bij linux mint is installeren, vscode overhalen en nog een paar dingen, en na een uurtje ben ik up & running op een nieuwe pc. Enzo koop ik ook om de 4 jaar een nieuwe pc. Als de nieuwste LTS versie er is et voila. Ik heb manjaro wel al eens getest en ook arch. Kon ik mij zeker in vinden.

Maar ik snap dus echt niet dat mensen hier tegen zouden zijn en dat je een hele hoop bagger over je heen krijgt voor een positief ding. De doorwinterde linux gebruiker weet normaliter wel waar hij mee bezig is, maar de "nieuwere" die zal al ergens eens lezen ... hey dit moet je zo doen en het werkt. Er zijn ook genoeg mensen die sudo voor alles op een commandline gebruiken. Ik ben zeker pro immutable. Want als je heel eerlijk bent tegen jezelf: hoe dikwijls moet je iets aanpassen onder /root. En als dit alles gewoon veiliger maakt, dan is dat toch gewoon een plus. Ik snap best het argument: ja maar ik weet wat ik doen, ik heb dat niet nodig. Vroeger kon je op Windows ook alles gewoon aanpassen nu is er al eens de elevated prompt zodat je alsnog quasi alles kan aanpassen. Gewoon toetimmeren die handel. Zou veel problemen verhelpen. En ik heb het helemaal eens met het idee: als je reboot zal het terug werken. Zo zou het moeten zijn
Eigenlijk dus gewoon chromeos (is gentoo based) , (die doet namelijk al jaren dit trukje... ) Maar hopelijk kun je daar goed naar kijken. Want een opensource alternatief wat even goed en eenvoudig te managen is (via een (onsite) website) ! zou een goede toevoeging zijn.
Naast wat Omega al zei is het natuurlijk ook nuttig om een rollback te kunnen doen van je OS update.
Dat kan met snapshots op je file system ook, maar het lijkt me handig om het zo out-of-the-box en puur voor je OS te kunnen doen.
Dat is een goed punt. Bij Apple ging het wel met name om de beveiliging, je kan daar ook met root niet omheen komen en ze hebben een hele keten aan secure boot verificaties opgezet (de signed system volume is ook echt signed en veranderingen maken het unbootable). Ze maken Mac steeds meer als iOS waarbij de gebruiker meer 'te gast' is op het systeem dan echt de eigenaar. Je kan het nog wel uitzetten (moet je wel in een speciale mode booten om dat te doen) maar dan zet je ook meteen alle beveiliging compleet uit, je kan niet gewoon met je eigen signing key veranderingen aanbrengen zoals met iets als SELinux wel kan.

Maar het gaat allemaal steeds meer de kant van mobieltjes op en dat wil ik niet. Ik vind het ook helemaal niet prettig dat ik op de mobiel niet overal bij kan (en vaak is dat niet alleen in mijn voordeel maar ook om bijv. DRM op apps en content te garanderen)
Voor configuratie hebben wij een mooie overlay en een ingebouwde backup feature, daar kan je al je zooi in mikken en dan wordt dit simpelweg bovenop het nieuwe systeem gekopieerd wanneer je een deployment uitrolt.
Ja dat kan ik me wel voorstellen, vooral met veel systemen die vergelijkbaar zijn en je in groten getale wil uitrollen kan dat handig zijn.

En ja voor servers helemaal, daar zie ik er ook zeker wel plaats voor. En voor de 'gewone' gebruiker ook, waar jullie je waarschijnlijk ook op richten. Maar als technische gebruiker wil ik zelf overal bij moeten kunnen. Uiteraard kan ik het dan ook met een foutje stukmaken maar dan fix ik het ook zelf dus dat is helemaal geen probleem.

[Reactie gewijzigd door Llopigat op 6 augustus 2024 22:17]

Voor de server is het idee dat jij zelf de images bouwt en dus niet afhankelijk bent van een image provider.

Arkdep is specifiek gebouwd om het bouwen van images voor persoonlijk gebruik zo makkelijk mogelijk te maken. Al is dit specifiek gericht op de desktop, wij leveren generieke images aan waar dan machine specifieke configuratie op wordt aangebracht, zoals de fstab.

Op de server zou je dit rechtstreeks in de image zelf kunnen bouwen waarna je verder niks hoeft te overlayen. Dit is veiliger en iets strakker afgesteld dan onze open methode.
Bij Apple ging het wel met name om de beveiliging, je kan daar ook met root niet omheen komen en ze hebben een hele keten aan secure boot verificaties opgezet (de signed system volume is ook echt signed en veranderingen maken het unbootable)
Je kan in recovery opstarten, alwaar je met je Administrator wachtwoord SIP in delen of geheel uit kan schakelen. Nee, dat kan idd logischerwijs niet als het OS al opgestart is (anders heeft het voor security inderdaad weinig toegevoegde waarde); maar Apple heeft gewoon een fijnmazige control ter beschikking gesteld om het uit te zetten als je echt perse niet wil dat deze security features ingeschakeld zijn.
Dat is juist niet fijnmazig, het is alles of niets. Bovendien verdwijnt dan ook je toegang tot sommige functies van het apparaat.

Als je je eigen signing key zou kunnen toevoegen om zelf wijzigingen aan te brengen, dan zou het fijnmazig zijn.
Dat is juist niet fijnmazig, het is alles of niets.
Hoe kom je daarbij? Je kan het naar wens in delen uitschakelen, het is juist niet alles of niets. Als jij enkel restricties op dtrace wil opheffen, dan doe je dat. Wil je enkel nvram restricties opheffen? Prima. Enkel dtrace en nvram? Ook goed. Wil je enkel kernel extensies toestaan, maar de rest van SIP overeind houden? Geen enkel probleem...

... Hoe is dat precies alles of niets? Je kan elke individueel stukje beveiligingen van SIP onafhankelijk van de rest in- of uitschakelen. Uiteraard kan je ook kiezen voor "niets" (SIP geheel uitschakelen), maar dat is absoluut niet de enige keuze die je hebt en daarmee onmogelijk louter een "alles of niets" keuze.
Bovendien verdwijnt dan ook je toegang tot sommige functies van het apparaat.
Welke functies verdwijnen precies? Niets van gemerkt, niet eerder iets over gehoord en ik kan er zo 1,2,3 ook nergens iets over vinden. (Voor de lol ook nog door ChatGPT en CoPilot heen gehaald: beiden zeggen dat er geen functionaliteit verloren gaat (buiten uiteraard de security features die je zojuist hebt uitgeschakeld, maar dat is nogal wiedes :P.)) Maar goed, dat wil niet zeggen dat er inderdaad niets verloren gaat; dus ben benieuwd welke functies er verdwijnen met het (deels) uitschakelen van SIP. :)
Als je je eigen signing key zou kunnen toevoegen om zelf wijzigingen aan te brengen, dan zou het fijnmazig zijn.
Nee niet echt eigenlijk.

[Reactie gewijzigd door WhatsappHack op 7 augustus 2024 00:43]

Je kan na het uitschakelen van SIP geen iOS apps meer draaien.

Volgens mij zijn er ook andere DRM beperkingen op video gebied maar dat kan ik niet zo gauw terugvinden.

Ik heb zelf ooit (toen ik nog een Mac had) SIP uitgezet en toen was het alles of niets (csrutil enable of disable).. Ik zal het nog eens opzoeken. Wellicht is dat veranderd en dat is dan idd mooi.

[Reactie gewijzigd door Llopigat op 7 augustus 2024 00:59]

Er zijn verborgen parameters om specifieke delen van SIP uit te schakelen, volgens mij hebben die er wel vanaf het begin af aan in gezeten maar zijn dus nergens officieel gedocumenteerd. :') Dit is het beste overzicht wat ik zo kan vinden. Voor iOS apps hoeft SIP dacht ik niet volledig aan te staan.
Zodra je root hebt is het een commando en het systeem staat voor je open.
Ooit overwogen om een functie aan te bieden waarbij dit dus niet kan bij een running systeem, maar bijvoorbeeld enkel in Single User Mode of met een kernel parameter? De root user ook beperken heeft aardig wat voordelen. Ja het is vervelend als je snel iets wil aanpassen, maar dat is de prijs voor verhoogde beveiliging.
Dit is technisch niet mogelijk, tenminste niet zonder het systeem extreem gelimiteerd en onnodig complex te maken. Of door een "normale" gebruiker min of meer root access te geven :+ .

Het beste wat we kunnen doen is de toegang van applicaties limiteren door middel van access control, traditionele gebruikersrechten, apparmor etc..
Toch heeft *BSD al jaren securelevels waarmee je kunt regelen dat iedere gebruiker het niveau kan verhogen maar geen enkele gebruiker het kan verlagen zonder te rebooten. Immutable filesystems kun je dan dus niet remounten zonder reboot. Dit geldt bv ook voor de firewall ruleset. Waarom kan dit niet op Linux?
Dat hele immutable verhaal zie ik juist als een rage/fase die wel overwaait, maar goed we zullen zien wat de toekomst brengt.

Een read/only rootfs is niks nieuws, vooral distro's die mikken op embedded apparaten hebben het gehad. Sommige nog steeds.

OpenWRT had eerst een readonly rootfs met een aparte squashfs partitie. Later boden ze 2 versies en nu zijn ze er helemaal van afgestapt. Het biedt in de praktijk helemaal niks en is voor de eindgebruiker alleen maar een obstakel.

Datzelfde zal in de desktop wereld ook gebeuren. In de tussentijd wordt het internet overladen met de: "Ik snap er niks van, volgens deze tutorial moet dit werken, maar het lukt niet". Gevolgd door de: "download deze OS, of gebruik dit commando". Dan haalt PS readonly attribuut weg zonder zelf te begrijpen wat hij/zij nou heeft gedaan.

In de enterprise server wereld zie ik dan wel weer toepassingen. Daar is 1 server eigenlijk niks anders als een onderdeel van een gigantisch groot virtueel geheel. Niemand gaat handmatig 1 server configureren, debuggen of onderhouden. D'r wordt een package geupload naar die server en die server moet dat maar draaien tot er een update is naar de volgende package. Dan wil je juist dat die package altijd hetzelfde blijft.

Dat is eigenlijk de enige echte toepassing die ik kan zien.

[Reactie gewijzigd door TechSupreme op 7 augustus 2024 02:11]

Ik denk dat het voor veel thuisgebruikers waarbij ook minder deskundige familieleden met het systeem werken een uitkomst is!

Ik heb bij een kennis van mij gehad dat ze het besturingssysteem om zeep had geholpen omdat ze bepaalde belangrijke bestanden had weggegooid (want het zei haar niks)
Mijn vrouw is ook een nitwit die regelmatig hulp nodig heeft omdat er iets niet meer werkt

Dus dank voor het goede werk en ga het zeker proberen
Ik gebruik zelf geen Manjaro maar een andere distro, maar ik zie zeker wel voordelen in immutable en denk ook dat dit een stapje in de richting van een meer secure toekomst is. Knap werk!

Deze Manjaro Immutable ga ik toch eens opspinnen in een VM :)
Ook op de server denk ik dat declarative systemen infra-as-code tools zoals Saltstack en Ansible uiteindelijk zullen verdrijven, omdat je alleen met een schone herinstallatie kan garanderen dat het systeem exact in de gewilde configuratie draait, en je kan garanderen dat je infra-as-code werkt omdat je deze voor iedere update gebruikt om het gehele systeem te herbouwen.
Dus wat je probeert te zeggen is dat door een immutable bestandssysteem hogere eisen kunnen worden gesteld aan de gebruikers en de code geschreven voor een specifieke infra-as-code systeem.

Het forceren van een security standaard is niet iets wat alle infra-as-code systemen kunnen dus dan is het hebben van een immutual bestandssysteem handig.

Kunnen we dus stellen dat infra-as-code systemen juist niet ‘verdreven’ worden?
Ik denk zeker dat immutable de toekomst is, [..] voor simpele thuisgebruikers en op de werkplek is het ideaal.
De kenmerken van wat tegenwoordig maar onder de term 'immutable' vallen bestaan al vrij lang. Het is weinig anders dan een specifiek gekozen combinatie van die kenmerken leveren. Dat thuisgebruikers of bedrijven het niet zomaar gebruiken is juist omdat de kenmerken niet perse maar ideaal of zelfs geschikt zijn bij hun eisen en wensen dus ook niet zomaar wat kenmerkend is voor de immutable distributie. @Llopigat geeft daarbij een duidelijk voorbeeld dat het zelfs niet zomaar voordelig is, ook al is er naast de standaard levering wel enige eigen inbreng mogelijk.

Zelfs de simpele gebruikers en bedrijven laten zich niet zomaar beperkingen opleggen waar ze moeite mee kunnen verwachten als ze toch willen of moeten afwijken.

Daarbij neigt het naar de situatie dat de makers van een distributie wel zouden weten wat goed voor gebruikers is, maar dat het eerder neer komt op dicteren wat men zelf voor anderen en zichzelf het beste lijkt. Dat werkt prima als de ander zich graag laat dicteren maar dat is niet zomaar een kenmerk van mensen en bedrijven. Zal er een behoefte naar zijn? Zeker. Maar net zo goed dat er onder 'simpele' gebruikers en bedrijven behoefte is om niet zomaar te laten voorschotelen wat goed voor ze is.
Voor de gemiddelde thuisgebruiker is een gesloten systeem geen probleem. Wat ze hiervoor terugkrijgen is extra stabiliteit, zelfs een slechte update kan het systeem (bijna) niet stuk krijgen. Je kan als thuisgebruiker nog steeds applicaties installeren via de "app store". De gebruikerservaring is vergelijkbaar met iOS en Android.

Voor de zakelijke gebruiker werken we een aparte oplossing, die kunnen dan gemakkelijk het systeem afstellen op hun exacte eisen.

[Reactie gewijzigd door Omega op 7 augustus 2024 15:22]

Stabiliteit en zekerheid is er pas als gebruikers precies willen wat een os-distributie kan en wil leveren. Alles wat af wijkt van de verwachtingen is voor de gebruiker geen gewenste situatie, het systeem doet niet wat men wil, het is stuk. (De simpelheid vanuit de gebruiker.) De mogelijkheden in dat afwijken zijn daarbij eindeloos, en zeker niet beperkt tot wat een os-distributie en haar ontwikkelaars vooral zelf wel/niet belangrijk voor anderen menen te moeten vinden.

Als ontwikkelaars en community kun je dat dan een werking zoals ontworpen en stabiel noemen, maar het is een feit dat je gebruikers daarmee niet zomaar blijvend weet te overtuigen. Dat werkt vooral als er voor de gebruiker geen redelijk alternatief is, terwijl daar juist geen gebrek aan is.

Een Apple, Google en Microsoft kunnen op deze kenmerken de door hun gekozen zware beperkingen in wat een gebruiker maar moet accepteren verkopen als 'werkt als ontworpen' en dat het zou zorgen voor betrouwbaarheid en stabiliteit. Maar gebruikers en bedrijven gaan en blijven niet zomaar voor een beperkte omgeving kiezen als ze door hebben dat er meer mogelijkheden zijn dan wat de leverancier ze laat zien via de gui of een store. Natuurlijk gaan er ook gebruikers en bedrijven zijn die niet verder kijken dan wat ze voorgeschoteld krijgen, of kan je mogelijke nieuwe gebruikers proberen te overtuigen dat deze voorgeschotelde kenmerken ideaal zijn. Maar uiteindelijk zijn gebruikers en bedrijven vooral gericht op wat ze zelf nodig hebben, niet op wat anderen ze als beperkingen in mogelijkheden wil geven. Ook al willen bedrijven als Apple, Google en Microsoft de gebruiker graag laten geloven dat zij wel weten wat het beste voor hun klanten is aan stabiliteit en betrouwbaarheid.
Ik ben sinds kort over van Arch naar Fedora Silverblue en ik vind het echt fijn werken. Mijn grafische applicaties zijn gewoon user flatpaks en mijn commandline tools en virtualisatie software heb ik gelayered.

Je base image is read-only dus als daar malware terecht zou komen en je update naar een nieuwe base image is het weer weg, tenzij de source infected zou zijn maar dat kan ook gebeuren met het huidige packaging systeem.

Wat ik ook aan mezelf merk is dat ik minder met mijn systeem zitten spelen nu ik geen Arch meer draai maar dat ik het heb geïnstalleerd en geconfigureerd voor wat ik nodig heb en nu gewoon mijn systeem gebruik. Met Arch had ik vaak dat ik mijn systeem steeds wat probeerde te verbeteren of te veranderen. Maar dat is geen Linux probleem maar meer en probleem van mij.

Gamen gaat ook prima op immutable distributie zolang je geen custom kernels enz wil draaien. Voor veel mensen zal een immutable distributie prima werken, zelfs voor mij als power user en iemand die al Linux aardig een tijdje gebruikt.

Maar het zal niet voor iedereen zijn. Maar daarom fijn dat je zelf kan kiezen wat bij je past. Maar ben van mening dat iedereen het wel een keer moet proberen voordat ze het gelijk afschrijven van dat immutable distributies niks voor hem is alleen omdat het anders is dan de normale Linux distributies.

Maar super gaaf dat je aan een immutable Manjaro versie werkt!

[Reactie gewijzigd door Hydranet op 7 augustus 2024 17:46]

Ja maar 99,99% van de mensen past nooit hun sshd_config aan, of welk ander config bestand dan ook.

Voor die groep is het weldegelijk nuttig als malware het ook niet kan.
Het maakt anders wel je computer just een heel stuk veiliger. Geen paswoord meer te proberen (en laten de meeste Apple gebruikers ook niet vreselijk origineel zijn op dat gebied). Keys zijn veel veiliger en gewoon de standaard voor SSH (vergeet niet dat Macs ook in zakelijke omgevingen voorkomen). Maar Apple vertikt het ook om hier een schuifje voor te maken in de instellingen.

[Reactie gewijzigd door Llopigat op 6 augustus 2024 21:13]

Nou, 99.99% is wel heel extreem. Ik wil oom nog wel eens in de sshd config zitten, bijvoorbeeld om root login mogelijk te maken of juist niet, of om hashing algoritmes aan te passen (ivm oudere git repos) of om te rommelen met X forwarding params.

Genoeg redenen voor diverse individuen om toch van tijd tot tijd er wijzigingen in door te voeren.
Jij denkt dat als je 1000 willekeurige mensen neemt van straat dat er meer dan 1 persoon dit bestand nodig heeft? De meeste mensen zullen binnen Windows niet eens via een UI de instellingen significant aanpassen. "root logins en hashing algoritmes" is niet iets wat de gemiddelde persoon bezig houdt.
Je moet alleen niet 1000 willekeurige mensen van de straat pakken. Maar 1000 willekeurige Linux gebruikers. En dan is het inderdaad lastig te geloven dat het zo’n groot percentage is. Ik probeer niet je punt te ontkrachten maar enkel het genoemde extreme percentage.
Volgens mij heb je nog geen immutable OS gebruikt, of wel? Dingen in /etc kan je nog steeds aanpassen in de meesten. En anders wel via een declaratie in Yaml.
Op MacOS worden ssh_config en sshd_config inderdaad beschermd; je moet de beveiliging even uitschakelen om de gewenste wijzigingen door te voeren. Ik heb zelf alleen nog niet meegemaakt dat deze na een OS update opeens terug naar default gaan. Al moet ik zeggen dat ik ssh_config op m'n nieuwe Mac niet eens uitgezet hebt, een config file waarin alle hosts, diens IP-addressen, de bijbehorende key en bijbehorende poort gedefinieerd staan is een stuk makkelijker; hoef je voor ssh en sftp ook niet bij elke verschillende poort het commando aan te passen.

Overigens als immutable iemand echt enorm tegenstaat zoals bij ApexAlpha het geval lijkt te zijn (en die kiest voor een OS zonder bescherming), dan heeft Apple een hele simpele manier om heel SIP uit te schakelen. Het is één commando in recovery en klaar is kees. Dan is het OS-deel niet meer immutable en worden deze bestanden ook niet meer beschermd. Het is ook in delen uit te schakelen (eg: wel toestaan om nvram wijzigingen te maken of geen beperkingen opgelegd te krijgen op dtrace, maar nog wel kernel extensies blokkeren en het FS beschermen bijvoorbeeld. Het is best versatile).
Dat maakt het des te belangrijker dat het voor de 0,1% die wel sshd_config aanpast (zoals mijzelf), het wel nog steeds kan.
Bij mac gebruiyniet, Linux gebruikers zullen het wel meer aanpassen, dat zijn over het algemeen toch meer techies.
Toch zijn er wel degelijk voordelen. Zie bijv. een Linux hardened repository i.c.m. Veeam. Immutable zonder de torenhoge cloud kosten.
Oh er zijn zeker voordelen en op een server doos sta ik er al een stuk opener voor. Maar op mijn werkstation niet.
Dat doet men toch al sinds jaar en dag bij hardened versies van Linux en UNIX? Bepaalde bestandssystemen als read-only mounten?
Kheb zelf nog bij KBC de installatie van hardened Solaris moeten testen en documenteren, en je kan er eens geïnstalleerd niet veel aan veranderen.
Android is immutable, en dat werkt toch ook gewoon goed? Ik zou het juist fijn vinden als Windows ook een gedeelte immutable zou maken, dan zijn veranderingen een stuk makkelijker terug te draaien.

Bij Windows zal dit niet snel kunnen vanwege hun hele registry-systeem. Dat zou dan of weg moeten, of op de schop. Want zoals Windows dat doet, dat zou nooit werken in een immutablesysteem. In ieder geval niet op een manier waar immutable voor bedoeld is: Consistency & reliability

[Reactie gewijzigd door MrFax op 7 augustus 2024 00:05]

Ja en nee. Ik kan er allerlei dingen niet op die ik wel zou willen. Het wordt steeds meer dichtgetimmerd. Bijvoorbeeld Termux gebruik ik vaak maar die kan ook weer niet meer geupdate worden vanuit de play store (gelukkig nog wel via F-Droid). En ik kan niet in de private storage van apps zelf kijken of dingen aanpassen. Ook zit er DRM op zoals die voor apps, en voor video's met wildvine enzo. Ik vind het prima dat apps dat soort dingen niet mogen maar ik als gebruiker en eigenaar van het apparaat zou overal bij moeten kunnen.

Dan kan je gaan rooten natuurlijk maar dan werken veel apps weer niet meer.

Maar voor mij is een mobiel apparaat niet zo belangrijk. Het is iets dat ik alleen onderweg gebruik dus ik kan er wel mee leven. Een desktop computer is voor mij veel belangrijker.

[Reactie gewijzigd door Llopigat op 7 augustus 2024 00:08]

Daartegenover staat wel dat als je een app weghaalt, er ook echt niks meer opstaat dat traceerbaar is naar die app (als je de bestanden van die app ook weghaalt uit je /sdcard/-partitie).

Ik doe al 10 jaar met dezelfde dataset van Galaxy-devices overzetten via Smartswitch, nog nooit geen enkel gezeik gehad met het overzetten van App-data. Bij een niet-immutable OS zou dat nooit zo lang blijven werken, dat constant overzetten van applicatiedata.

[Reactie gewijzigd door MrFax op 7 augustus 2024 00:08]

Hoeft niet per se. Sandboxing van de apps is 1 ding. Het de gebruiker volledige toegang gunnen is een andere. Die twee zijn niet perse gerelateerd. Dat is juist precies wat ik tegen de mobiele OS'en heb want die doen alsof het een samen gaat met het ander. Zie bijvoorbeeld Ubuntu met hun snaps, die zijn ook gesandboxed en kan je ook netjes opruimen zonder sporen achter te laten, maar je kan wel overal bij als je dat wilt.

Natuurlijk kan je dan zelf gaan lopen klooien en dingen kapot maken maar dat is je eigen risico.

Gelukkig kan je op Android vaak nog een beetje hieromheen werken met ADB commando's. Dat is wel tof, maar je kan dat nooit op het toestel zelf doen dus je moet altijd een ander apparaat hebben. En het wordt ook steeds meer beperkt.

[Reactie gewijzigd door Llopigat op 7 augustus 2024 00:30]

Daar heb je gelijk in. Ook kan je bijvoorbeeld niet zelf je gpu drivers updaten, en andere fixes uitvoeren die de fabrikant soms gewoon niet wil oplossen.
Wat is het verschil met een live-systeem? Ik draai al jaren eem FreeBSD 'mfsroot' omgeving 100% uit RAM en niet blijvend vast aan een opstartdevice. Dat is dan niet read-only maar als je nooit iets verandert is r/o mount instellen geen probleem.
Hier moet ook iets kunstmatigs in zitten om dat na te bootsen. Als je opstart van een USB-stick moet je kernel er voor zorgen dat je daar niet op kan schriijven terwijl dat eigenlijk gewoon kan. Wat gebeurt er als je als root dat apparaat onafhankelijk adresseert zodat je OS niet door heeft welk apparaat het is? O-)

[Reactie gewijzigd door blorf op 6 augustus 2024 21:37]

Een livessyteem bestaat meestal uit een SquashFS bestand dat Linux as root mount. Daar bovenop wordt een overlayfilesystem gemount. Op live images zal deze overlay in het geheugen van de machine leven, zodra je herstart is het weg.

Op Manjaro Immutable werken wij met Btrfs en subvolumes. Je hebt een enkele root partitie, en daar leven dan de verschillende installaties op. Zo'n subvolume ziet er uit als een normale folder, maar op bestandssysteemniveau kunnen wij hier trucjes mee doen.

Zo kunnen we `/arkdep/deployments/aabbcc/rootfs` als root mounten door middel van mount options op de kernel command line. Deze folder is een subvolume, en onder deze folder leven ook nog de `rootfs/etc` en `rootfs/var` subvolumen. Root is gesloten, var en etc zijn wel schrijfbaar.

/etc is vroeg in het opstarten al nodig dus deze moet hier beschikbaar zijn, het is schrijfbaar omdat sommige programms hier toch naar toe schrijven, zoals grafische netwerkbeheer applicaties. /var zou later gemount kunnen worden, dit was ook het geval in een eerdere implementatie van Arkdep toen /var nog gedeeld werd.

En dan hebben we nog gedeelde subvolumen onder `/arkdep/shared/` zoals root (De homedir van root), home en flatpak. Deze worden later gemount door middel van fstab.


Leuk feitje: Voordat Manjaro contact met mij had opgenomen omdat ze interesse hadden in de technologie van mijn Arkane Linux distributie voor hun eigen immutable, hadden ze zelf ook al geëxperimenteerd met een eigen immutable implementatie. Ze gebruikten SquashFS met overlays, deze overlays werden op de schijf weggeschrevenen en dus behouden.

[Reactie gewijzigd door Omega op 6 augustus 2024 22:42]

Klinkt erg ingewikkeld. Mfsroot, wat ik noemde is een malloc-based virtueel opslagvolume, oftewel ene ramdrive. Wat je moet doen om helemaal "in de lucht" te draaien is zorgen dat daar de kernel en init in zitten en alle afhankelijkheid van andere hardware uitsluiten. In principe is het hele idee van een OS "uitrollen" op een systeem flauwekul. Alles hangt aan de kernel maar het maakt niet uit waar die zich bevindt. Wat je uiteindelijk echt nodig hebt is bijna niks. Het image wat ik nu gebruik is 70MB als gz, en daar zit nog overbodig spul in.

[Reactie gewijzigd door blorf op 6 augustus 2024 22:43]

Dat is het mooie van Unix. Het is zo ongelooflijk flexibel.

Je start de kernel op en zegt; "Dit is waar je bestanden staan", en de rest doet die helemaal zelf.

Er was enkele weken geleden iemand die z'n systeem vanaf een Google Drive schijf opgestart. Op het system zelf stond enkel een kernel en een initramfs met wat kernel modules, een binary dat Drive kan mounten en een bash scriptje.

Het bash scriptje wordt uitgevoerd als het initsystem, dat mount dan vervolgens die Google Drive als root en voert systemd uit dat op deze drive staat, waarna dat de rest van het systeem opstart.

Dit is een perfect voorbeeld van wat er allemaal mogelijk is met dit soort systemen.
Het is me gelukt met een CLI bittorrent client. Je moet dan alleen wel je blob zelf blijven seeden want niemand gaat dat downloaden en dan aan laten staan. :+ Het zou nog beter moeten kunnen door een bootloader met een klein netwerkstackje als een soort micro-omgeving ook de kernel zelf te laten ophalen.
Bootloader is bloat, kernel rechtstreeks opstarten als EFI executable. :+

Bonuspunten als je helemaal geen lokale opslag hebt en dit over het netwerk doet.

[Reactie gewijzigd door Omega op 6 augustus 2024 23:20]

Ik gebruik alleen maar de sector als beginpunt Volgens mij moet Linux dat noodzakelijk ook doen omdat er behalve PXE niks anders is om je eerste bytes binnen te krijgen. Er zit bij FreeBSD een hele Forth of Lua omgeving in maar dat heb ik nog nooit gebruikt. Je kan er een interactief kernel settings scherm in maken die de standaard kale loder prompt vervangt.

[Reactie gewijzigd door blorf op 6 augustus 2024 23:30]

Zoals we in 1994 al deden met een Sun Sparcstation SLC/ELC deze booten van een server met bootp en dan via NFS je root mounten. Diskless Desktops waren toen heel gebruikelijk :)

"The Network is the computer" was toen al het motto :)
Ik vind het toch zonde dat dit soort technische oplossingen tegenwoordig zeer zeldzaam zijn geworden.
Niet echt. Je hebt nog steeds thin clients. Die booten vaak vanaf het netwerk. En Intel Macs kunnen helemaal vanaf internet booten, zelfs als er helemaal niets op hun disk staat. Volgens mij is die functionaliteit bij de Apple Silicon macs weer verdwenen en moet je nu DFU mode gebruiken vanaf een andere Mac net zoals een iPhone.

[Reactie gewijzigd door Llopigat op 7 augustus 2024 00:07]

Oh ja de SLC, heb ik ook nog eens een blauwe maandag gehad! Was idd best een gedoe om geboot te krijgen. Maar dan draaide het wel goed. Ik draaide er alleen een lichte omgeving op om hem als X-Terminal te gebruiken. Heb later ook de Sparc X-Terminal gehad, dat was eigenlijk ook gewoon een lichtere versie van de SparcStation 5 zonder disk.

Het was leuk om daar mee te spelen. Dat mis ik nu wel een beetje, er is weinig exotische hardware/software meer.
Voor de mensen die toevallig nieuwsgierig hier naar zijn.

https://ersei.net/en/blog/fuse-root
Kun je met een readonly core nog wel updates draaien?
Niet het volledige system is read-only. Bij het updaten wordt er een subvolume export, dat is een soort schijfimage, naar `/arkdep/deployments/` gekopieerd, en deze wordt dan opstartbaar gemaakt door middel van een bootloader entry, en dan gebruiken we EFI variablen om deze entry op een veilige manier als standaard aan te merken.

Bij het opnieuw opstarten wordt je geboot in de geüpdatet versie van het OS.

[Reactie gewijzigd door Omega op 6 augustus 2024 23:52]

Sinds ik over ben op Fedora Silverblue (ook voor oa ouders) ben ik helemaal niet meer aan het kloten, helemaal niet meer met onderhoud bezig voor anderen.
Niet alleen om het immutable aspect, maar ook dat alles via 1 enkele "App Store" achtige app gaat: OS updates, additionele layers, en apps die ze zelf installeren (Flatpak).

Echt een soort Android/iOS ervaring. Werkt heerlijk. Tegenwoordig is daarnaast RDP ingebouwd, Chromecast ook. Dus je hoeft ook niet allerlei vage apps te zoeken en te bepalen welke beste werkt.

Uiteindelijk doe ik altijd rebasen naar uBlue OS (vanilla. Dus de base image).
Want dan zijn de gelicenseerde codecs direct erin verwerkt. Als je dat zelf doet, gaan je upgrades naar nieuwe versies niet seamless. Dus uBlue OS base is een no brainer als je voor Fedora Silverblue gaat.

Met uBlue OS, en daarmee ook automatische updates, heb je helemaal geen ommekijk meer naar je OS. En kan je gewoon doen waarvoor je de laptop/pc in eerste instantie aanzette :)

[Reactie gewijzigd door Jazco2nd op 6 augustus 2024 21:32]

Ik heb 7 jaar lang Manjaro gedraaid als mijn main systeem.

Meerdere keren serieuze crashed gehad door niets geks te doen behalve dood normaal updates uit te voeren.
Op het forum wordt je vervolgens of van het kastje naar de muur gestuurd, of gewoon ongelooflijk onvriendelijk behandeld met een hoop ongeloof dat het niet kan etc.
(Dus blijkbaar verzin ik het en lieg ik?)

Sorry, maar niet iedereen heeft de tijd en zin om continu alles te lopen repareren.

Inmiddels weer terug naar windows dan maar.

Ik heb jaren geleden Fedora proberen te gebruiken als mijn main OS, maar toen was de compatibiliteit lastig.
Ook waren bepaalde patches of updates van bv Wine wel heel erg traag en laat.

Is dat nu inmiddels beter?
Ik zit ook op Manjaro en heb hetzelfde ervaren: bij een reboot is het nogal eens "fingers crossed" of het allemaal blijft werken.

Dat komt door twee dingen: ten eerste is Manjaro een "rolling distro", net als het voorbeeld Arch, alleen iets vriendelijker opgezet. Ergo, je moet er nog steeds wel van uit gaan dat de dingen stuk kunnen gaan en dat je de expertise in huis moet hebben om het te repareren. Wat wel erg helpt daarbij is de zeer uitgebreide wiki die Arch heeft, waarin zelfs hele technische ingrepen vaak netjes uitgelegd worden. Het is geen Linux From Scratch, zeg maar. Een logisch gevolg is dan wel dat als je naar het forum gaat je opgescheept zit met techneuten, en die zijn wel kundig maar vaak niet altijd vriendelijk.

Het tweede ding dat bij mij voor veel frustratie en problemen zorgde was Grub. :P Die is heel kieskeurig of je configuratie wel goed is een heeft nota bene z'n eigen drivers voor file systemen in zich, zodat hij toch alvast bestanden kan lezen zonder dat de kernel live is. Dat moet dan wel allemaal compatibel zijn, anders boot hij lekker niet en mag je het zelf uitzoeken. Voor iedere scheet moet je `grub-update` draaien en wee je gebeente als je dat vergeet. Na een paar keer had ik daar wel tabak van en heb ik Grub er helemaal af gekieperd en ben overgestapt op Dracut en rechtstreekse EFI images. Dat is wel een technisch klusje waarbij je moet weten wat je doet, maar als het eenmaal staat is het stukken simpeler te begrijpen dan de hele Grub keten.

Als je gewoon zorgeloos Linux wil gebruiken zit je naar mijn mening ook met Manjaro Stable niet goed, dan kun je het nog steeds beter op Ubuntu houden. Het nadeel van Ubuntu (en de reden dat ik overgestapt ben) is dat ze vaak behoorlijk achterlopen qua software (inherent aan een LFS) en dat Canonical steeds meer enge dingen in Ubuntu stopt onder het mom van gebruikersvriendelijkheid (zoals diverse vormen van tracking). Allemaal uit te zetten jawel, maar als ik dat wil gebruik ik Windows wel.

Met Manjaro heb ik overigens wel een picobello game ervaring en dat is een van de redenen dat ik het gebruik. Arch is ook de basis voor Steam Deck, dus dan weet je dat het wel goed zit qua compatibiliteit.
Manjaro gebruikt uitgestelde updates, worden eerst getest voordat ze uitgebracht worden, en dat schijnt voor nogal wat problemen te zorgen.
Het gaat bij mij niet om de ervaring, die is er genoeg, maar het feit dat ik weer een vrije avond of weekend aan het pielen ben.

Laat ik het zo formuleren, de lol van het gebruiken van een computer was er vanaf.
Het gaat bij mij niet om de ervaring, die is er genoeg, maar het feit dat ik weer een vrije avond of weekend aan het pielen ben.

Laat ik het zo formuleren, de lol van het gebruiken van een computer was er vanaf.
Je haalt de woorden uit mijn mond over mijn ervaring met Manjaro.

Eigenlijk het enige wat ik geleerd heb van Manjaro, is dat upstream van menig package zo onbetrouwbaar als de pest is. Ze testen hun eigen code niet. Alsof MR's doodleuk gemerged worden. De package maintainers van menig distro zijn de gatekeepers dat de kwaliteit nog op orde blijft.

En als je op Manjaro Forums zegt dat de slechte versie van package xyz shitty is, krijg je een ban vanwege slecht woordgebruik. Daar zit je dan met een kapotte OS installatie en geen toegang tot de officiële help kanaal.

Mocht je weer overwegen om je Windows installatie te vervangen voor Linux, probeer dan eens MX Linux KDE. Werkt gewoon.

[Reactie gewijzigd door RoestVrijStaal op 7 augustus 2024 18:45]

Ik vind zelf XFCE iets fijner, maar het is mij een beetje om het even :)

Ik vond de ervaring extreem ironisch eerlijk gezegd.
Vooral het kastje-naar-de-muur ervaring was net alsof je bij een grote coöperatie zit = Winhoos.
Iedereen op zijn eigen kleine eilandje met oordoppen en oogkleppen op.

Dat ik zei dat de lol er vanaf was, was overigens ook alles behalve overdreven bedoeld.

Ik heb helaas op het moment een aantal programma's die ik professioneel nodig heb die maar met moeite werken onder Wine en dual boot vind ik een kansloze middenweg.
Ik vind zelf XFCE iets fijner, maar het is mij een beetje om het even :)
Dat is mooi, want de standaard spin van MX Linux blijkt met XFCE te zijn, las ik net.
Ik vond de ervaring extreem ironisch eerlijk gezegd.
Vooral het kastje-naar-de-muur ervaring was net alsof je bij een grote coöperatie zit = Winhoos.
Iedereen op zijn eigen kleine eilandje met oordoppen en oogkleppen op.

Dat ik zei dat de lol er vanaf was, was overigens ook alles behalve overdreven bedoeld.
Ik begrijp je helemaal. Bij periodes dat ik een werkende pc echt nodig had (voor de belastingaangifte bijvoorbeeld) update ik mijn Manjaro install expres niet, om zo een werkende machine te blijven behouden.
Ik heb helaas op het moment een aantal programma's die ik professioneel nodig heb die maar met moeite werken onder Wine en dual boot vind ik een kansloze middenweg.
Dual boot is ook irritant omdat je 2 besturingsystemen up-to-date moet houden en je altijd wel een document of bestand hebt in je $HOME of %USERPROFILE% directory waardoor je weer naar het andere besturingssysteem moet booten 8)7

Met MinGW/MSYS was eigenlijk al een dual boot overbodig omdat je in Windows met het veel krachigere bash kon scripten (PowerShell bestond toen nog niet of was Enterprise-only).

Daarna met de komst van WSL(2) werd dual boot nog onzinniger. Sowieso hebben de meest in het oog springende Linux applicaties een Windows-port.

[Reactie gewijzigd door RoestVrijStaal op 8 augustus 2024 23:22]

Als je gewoon zorgeloos Linux wil gebruiken zit je naar mijn mening ook met Manjaro Stable niet goed, dan kun je het nog steeds beter op Ubuntu houden.
Zelf gebruik ik momenteel gentoo, eenmaal goed geconfigureerd vind ik het een super stabiel systeem.
Ook had ik dit met arch, nooit zware problemen mee gekregen waardoor mijn systeem "uitviel".
Dit voorkom ik ook met het gebruik van btrfs, met btrfs kan je makkelijk gebruik maken van snapshots. Die kan je dan bijvoorbeeld op een NAS neerzetten als je het helemaal mooi wilt maken.

Tuurlijk heeft niet iedereen dezelfde hardware, en is dit geschreven vanuit mijn eigen perspectief.

[Reactie gewijzigd door mediocre op 8 augustus 2024 10:22]

uBlue OS = Fedora Silverblue met wat gebruikelijke toevoegingen voor eindgebruikers (die Fedora devs om licentie redenen niet kunnen toevoegen) plus wat instellingen die puur voor consumenten no brainers zijn.

uBlue OS wordt vervolgens gebruikt om verschillende base images voor bepaalde dingen te maken. Zoals DE Linux gaming distributie: Bazzite. Maar bijvoorbeeld ook laptop fabrikant specifieke images. Sterker nog, volgens mij levert Asus een uBlue OS image.

Het feit dat uBlue OS Bazzite dus gewoon Silverblue is met Wine etc er al in verwerkt, en super populair is zelfs voor mobiele game consoles, lijkt me dat je dan heel weinig compatibiliteits issues zal hebben.

Ik kom trouwens ook van paar jaar Manjaro. En daarvoor Ubuntu. Manjaro vond ik een enorme verademing tov Ubuntu. Maar met uBlue OS base/Fedora Silverblue is het nog veel relaxter.

Om uBlue OS base te installeren, installeer je eerst Fedora Silverblue via een USB stick en daarna rebasen naar de base image (normale of Nvidia variant). Zie hier de uitleg:

https://universal-blue.discourse.group/docs?topic=868

[Reactie gewijzigd door Jazco2nd op 6 augustus 2024 22:51]

Ik werk al zo'n 20 jaar met Linux.
Behalve voor server of embedded systemen, heb ik mijn draai voor desktop nog niet kunnen vinden na al die jaren helaas.

Voor een daily driver heb ik vooral geen zin in gezeur.

Dit ziet er wel interessant uit, dus misschien dat ik toch weer wat ga proberen.
Heb ff linkje bij mn reactie gezet om je op weg te helpen :)

Ik heb alles wat ik daarna doe, aan Gnome extensies, configuratie en additionele apps in een post install script gezet die ik vervolgens (na rebooten) uit voer:

https://github.com/zilexa/Fedora-Silverblue-Intuitive

Als ik ooit tijd over heb maar ik daar mss nog een officiële uBlue variant van :)

[Reactie gewijzigd door Jazco2nd op 6 augustus 2024 22:53]

Voor een daily driver heb ik vooral geen zin in gezeur.
Het hangt er misschien wat vanaf welke applicaties je belangrijk vindt, maar ik draai al tien jaar Debian Stable met een Cinnamon desktop precies om die reden. Simpel en stabiel. En dan bedoel ik zowel dat het niet crasht, als dat niet na elke update alle knoppen opeens ergens anders zitten.

Vaak noemen mensen als nadeel dat Debian erg achterloopt met versies, maar ik heb daar nooit echte problemen mee gehad. Omdat Debian de basis is van heel veel andere Linuxen, is er vaak wel een officiële manier om de app of tool te installeren. Discord heeft gewoon een deb package, om maar eens wat te noemen.
Dat vond ik in het verleden al toen ik Ubuntu begon te gebruiken: geen gedoe met allerlei updates van programma's (zoals in Windows), maar 1 centrale update manager voor OS en alle applicaties.

Ik vrees dat ik het grote voordeel nog niet zie, dus als iemand het kan verduidelijken, graag. :)
Updates kunnen worden getest voordat deze beschikbaar worden gesteld. Iedereen draait bijna exact hetzelfde systeem.

Daarnaast, mocht het wel stuk gaan dan kan je terugdraaien naar de vorige versie die nog geïnstalleerd zal zijn, of zelfs een specifieke versie die je niet meer geïnstalleerd hebt.
Ik ben juist weg van Ubuntu.. ik vond het juist een bende. Misschien is er iets veranderd, maar ik kon niet puur met Gnome Software in 1x alles updaten. OS, apps etc.. en hoewel er heel veel documentatie is over Ubuntu, is het meeste van vrij slechte kwaliteit of outdated.

Met Fedora (maar ook Manjaro) kan je gewoon de Arch wiki volgen.

De voordelen van "immutable" zijn weer anders. Geen geklooi meer met je systeem. Net zoals je niet met Android of iOS OS kan klooien als eindgebruiker.
Voor immutable staat Manjaro nog in de kinderschoenen. Dus zoek vooral even Fedora Silverblue op.. daar is ook redelijk veel over te vinden.
Het herstarten voor updates lijkt mij dit te beperken tot desktop Linux, op servers betaal je zelfs voor live patch om niet te herstarten. En servers zijn nu net de markt waar Linux het goed doet...
Als ik iets handmatig installeer of update kan ik --apply-live gebruiken.
Als het om een app gaat (Flatpak) is er geen herstart nodig.
Manjaro is een club die ik nooit zou vertrouwen met iets als veiligheid, gezien hun lange historie met veiligheidsblunders. Herhaaldelijk TLS certificaten laten verlopen (en vertellen de klok terug te draaien) is daar maar een druppel van.
Zijn we mee bekkend. We zullen binnenkort tijd besteden aan dit onderwerp en werken aan het herstellen van het vertrouwen in het project.

[Reactie gewijzigd door Omega op 6 augustus 2024 22:31]

Misschien dan beginnen met Philip de deur uit gooien 😉
Compleet off-topic, maar man man man, wat hebben we toch een geweldige community hier op Tweakers; bij dit bericht komt gewoon even de auteur van Manjaro Immutable langs om vragen te beantwoorden en dingen te verduidelijken. Ik heb zelf niks met Linux (behalve op servers/appliances) dus inhoudelijk kan ik niets toevoegen, maar dit moest ik toch even kwijt.
Oh jippie, Yet another Linux distro in de oceaan aan linux distro's.
Zolang memory mutable is zal de malware zich daar nestelen en alsnog heb je een besmet systeem tot de volgende reboot...

Maar wie reboot zijn servers nou iedere dag
Voor eenvoudige toepassingen kun je dit ook DIY maken. Heb een oude rpi met een afgebakend doel, conversie ve stream usb data (midi). Het device is niet (publiek) online bereikbaar dus security updates zijn minder relevant. Stroom erop / stroom eraf, geen probleem. Vrijwel geen risico op sd kaart corruptie. Beetje als een internetmodem. Er staan diverse tutorials over readonly rootfs. Het is een uitgeklede openrc linux distro (devuan/debian).

Ik vermoed dat bij een volledige en actuele distro met regelmatige updates gecompliceerder is om dit DIY te doen. Sowieso zijn die bijna allemaal systemd, weet niet goed hoe dat werkt onder de motorkap.
Technisch gezien is dit dan een immutable, maar je mist dan nog wel de atomic updates. Als een update fout gaat kan je niet terug. Je zou snapshots kunnen maken, en deze dan vervolgens als bootable kunnen configureren in de bootloader. Maar dan doe je dit allemaal handmatig. Manjaro Immutable doet soortgelijke trucjes, maar dit is allemaal geautomatiseerd.
@Omega zou deze versie ook met dual boot kunnen werken. Ik wil graag immutable proberen, maar bij opensuse (huidige distro) werkt Aeon alleen met dual boot op twee Ssd’s. Mogelijk is dat eigen aan dual boot (heb me er nog niet in verdiept), maar zou tof zijn als dit zou kunnen.
Dat is technisch mogelijk. Op dit moment zal het niet werken omdat de installer de ESP-partitie formatteert. Mogelijk kan ik dit gemakkelijk aanpassen dat dit niet gebeurt bij een bestaande ESP.

Op dit item kan niet meer gereageerd worden.