LNX Kroeg - Deel 2

[HollowGamer]

gambieter schreef op vrijdag 1 mei 2026 @ 02:21:
[...]

Die gasten moeten nog een hoop leren over hoe documentatie toegankelijk te maken, ik heb er naar gekeken en kan er niets mee. Wat moet ik nou testen en hoe repareer je het?

Aangezien ik low risk ben laat ik het voorlopig zo

Ik denk dat je zelf niet veel van kan doen. Je kunt de module blacklisten, maar ik ben zelf daar ook geen voorstander van. Dit moet de distro voor je doen, niet de eindgebruiker.

Het is voor deze reden dat ik voorstander ben van managed servers/services in Enterprise. Laat die het maar oplossen, daar zou de kennis moeten liggen.

[LEDfan]

Hero of Time schreef op donderdag 30 april 2026 @ 21:42:
Ben blij dat ik op al m'n servers op werk unattended-upgrades heb ingesteld die praktisch dagelijks draait. M'n PC thuis update ik niet zo vaak, maar ik zag dat Plasma 6.6.4 beschikbaar is (heb nu 6.6.3), dus die zal ik van het weekend doen. Laptop vd zaak komt maandag wel met de wekelijkse updates.

Maar heb je ook ingesteld dat die de server automatisch rebooten? Anders is het vrij nutteloos.

[segil]

Als ik dit copy_fail Python script draai onder mijn zorinos 18 installatie, krijg ik deze error:

code:

Traceback (most recent call last):
  File "<stdin>", line 9, in <module>
  File "<stdin>", line 5, in c
FileNotFoundError: [Errno 2] No such file or directory

Houdt dit in dat mijn installatie sowieso niet vatbaar is/was voor deze exploit?

[synoniem]

segil schreef op vrijdag 1 mei 2026 @ 11:02:
Als ik dit copy_fail Python script draai onder mijn zorinos 18 installatie, krijg ik deze error:

code:

Traceback (most recent call last):
  File "<stdin>", line 9, in <module>
  File "<stdin>", line 5, in c
FileNotFoundError: [Errno 2] No such file or directory

Houdt dit in dat mijn installatie sowieso niet vatbaar is/was voor deze exploit?

Daar lijkt het op. De mitigation is om de de module algif_aead te blacklisten en met rmmod te verwijderen en dan krijg je dezelfde melding. Het is een mixed bag wat dat betreft op een aantal van mijn servers is deze module niet standaard geïnstalleerd op andere weer wel.

[Hero of Time]

LEDfan schreef op vrijdag 1 mei 2026 @ 10:36:
[...]

Maar heb je ook ingesteld dat die de server automatisch rebooten? Anders is het vrij nutteloos.

Ik zou een slechte beheerder zijn als ik dat niet ook gelijk had meegenomen. Genoeg software dat tijdens update nog wel eens een herstart van de daemon doet, dus waarom dan niet een reboot als je kernel is bijgewerkt? Unattended-upgrades kijkt dus gelukkig of /var/run/reboot-required aanwezig is en herstart op je ingestelde moment, als je auto-reboot ook hebt opgegeven.

Bij 1 Ubuntu systeem heeft degene die 'm beheert ingesteld dat het bij shutdown moet gaan updaten. Het systeem herstart regelmatig via een crontab regel bij root, maar tot op heden gebeurt er geen klap bij de reboot. Dat werkt dus geweldig. ....

[Sjah]

Laatst een programma tegengekomen dat toch wel wat fouten vertoonde op die betreffende install.... heb het over digiKam. Daar heeft mijn vertrouwen in linux een knauw van gekregen, jah.

[Cyphax]

Sjah schreef op maandag 4 mei 2026 @ 10:13:
Laatst een programma tegengekomen dat toch wel wat fouten vertoonde op die betreffende install.... heb het over digiKam. Daar heeft mijn vertrouwen in linux een knauw van gekregen, jah.

Tja, ik heb ook weleens een applicatie (van Ga(a)rmin) niet aan de praat gekregen op Windows (10), maar toen was mijn vertrouwen in Windows al helemaal kaalgevroten.

[Lizard]

Weer een LPE: https://github.com/V4bel/dirtyfrag/

[HollowGamer]

Lizard schreef op donderdag 7 mei 2026 @ 23:06:
Weer een LPE: https://github.com/V4bel/dirtyfrag/

Dit leest heel raar. Alsof het een opgezet spel is ofzo. Hij zegt dus dat beide de exploit hebben gevonden, maar omdat de andere hetzelfde openbaar heeft gemaakt, doet hij het ook maar?

Of snap ik het niet zo goed?

[Vishari Beduk]

Zojuist mijn fedora ge-upgrade naar 44 maar ik zie eigenlijk helemaal geen verschil.
Ook eens de release notes bekeken waar ik de verschillen moet zoeken maar die zijn blijkbaar klein.

[Lizard]

HollowGamer schreef op donderdag 7 mei 2026 @ 23:13:
[...]

Dit leest heel raar. Alsof het een opgezet spel is ofzo. Hij zegt dus dat beide de exploit hebben gevonden, maar omdat de andere hetzelfde openbaar heeft gemaakt, doet hij het ook maar?

Of snap ik het niet zo goed?

Het gebeurt wel vaker dat verschillende mensen/teams dezelfde exploit vinden.

De clausule was dus dat als iemand anders het ook zou publiceren dat het dan publiek mocht worden gemaakt. Zie https://github.com/V4bel/dirtyfrag/blob/master/assets/write-up.md#disclosure-timeline

2026-05-07: Detailed information and the exploit for this vulnerability were published publicly by an unrelated third party, breaking the embargo.
2026-05-07: After obtaining agreement from distribution maintainers to fully disclose Dirty Frag, the entire Dirty Frag document was published.

[HollowGamer]

Lizard schreef op donderdag 7 mei 2026 @ 23:36:
[...]

Het gebeurt wel vaker dat verschillende mensen/teams dezelfde exploit vinden.

De clausule was dus dat als iemand anders het ook zou publiceren dat het dan publiek mocht worden gemaakt. Zie https://github.com/V4bel/dirtyfrag/blob/master/assets/write-up.md#disclosure-timeline

[...]

Kennelijk was het gebeurt doordat iemand per ongeluk het had gedeeld in het verkeerde chat kanaal (die publiekelijk was).

edit:
YouTube: New Linux Exploit Just Dropped (Before the Fix)

Beter uitleg hier.

[ Voor 11% gewijzigd door HollowGamer op 08-05-2026 14:20 ]

[HollowGamer]

Vraagje: Fedora komt mogelijk met x86_64 v3 packages (V4 heeft Cachyos al).

Zitten jullie hier op te wachten? Ik heb Cachyos gedraaid, vond het opzicht prima, maar ook erg Arch Linux achtig.

Fedora is die mooie middle ground, dus zou het zeker willen proberen.

[gambieter]

https://ubuntu.com/blog/d...erability-fixes-available
Hier is de Ubuntu blog over DirtyFrag met hoe het op te lossen.

[surcharge]

Heb su maar opnieuw geïnstalleerd omdat 'su' na een test niet meer normaal werkte.

[HollowGamer]

surcharge schreef op vrijdag 8 mei 2026 @ 23:08:
Heb su maar opnieuw geïnstalleerd omdat 'su' na een test niet meer normaal werkte.

Doen mensen dit echt testen op hun productie machine?

[ed1703]

surcharge schreef op vrijdag 8 mei 2026 @ 23:08:
Heb su maar opnieuw geïnstalleerd omdat 'su' na een test niet meer normaal werkte.

???

Cleanup

⚠️ Important: After running this exploit, the page cache is contaminated. To clear the polluted page cache and ensure system stability, either run:

code:

echo 3 > /proc/sys/vm/drop_caches

or reboot the system.

Was dus eigenlijk niet nodig geweest denk ik? Afgezien daarvan ben ik het wel met @HollowGamer eens en zou ik voor zoiets een simpel VM'tje oid opzetten die voor diverse testjes kapot mag nadat je eerst een snapshot hebt gemaakt

[ Voor 17% gewijzigd door ed1703 op 08-05-2026 23:38 ]

[surcharge]

Die manier werkt ook. Ik zit bijna altijd op de laatste linux snapshot, bijna nooit problemen, alleen tussen de vorige release en -rc1 let ik wat meer op.

[gambieter]

Heb een extra reden gekregen om wat te doen met mijn Linux computers . De Tidal-GUI download app die ik gebruikte op Windows doet het niet goed meer, en de maker is blijkbaar al een tijdje afwezig. Dus nu maar eens tiddl geprobeerd, en dat werkt uitstekend en is lekker simpel.

[HollowGamer]

gambieter schreef op zaterdag 16 mei 2026 @ 21:20:
Heb een extra reden gekregen om wat te doen met mijn Linux computers . De Tidal-GUI download app die ik gebruikte op Windows doet het niet goed meer, en de maker is blijkbaar al een tijdje afwezig. Dus nu maar eens tiddl geprobeerd, en dat werkt uitstekend en is lekker simpel.

Wat is Tidal precies?

[L0g0ff]

HollowGamer schreef op zaterdag 16 mei 2026 @ 22:59:
[...]

Wat is Tidal precies?

TIDAL is an artist-first, fan-centered music streaming platform that delivers over 110 million songs in HiFi sound quality to the global music community.

Aldus tidal zelf.

Ik heb het zelf een paar jaar geleden gebruikt voor een virtual DJ set. Dan kon je alle music rechtstreeks op je apparatuur zetten. Dat ging voorheen ook met spotify maar die blokkeerde dat op een gegeven moment.

[gambieter]

HollowGamer schreef op zaterdag 16 mei 2026 @ 22:59:
Wat is Tidal precies?

Spotify, maar dan beter qua kwaliteit en minder problematisch qua andere dingen. Je kunt de liedjes als flac downloaden voor offline gebruik.

[Liegebeest]

surcharge schreef op vrijdag 8 mei 2026 @ 23:08:
Heb su maar opnieuw geïnstalleerd omdat 'su' na een test niet meer normaal werkte.

Alleen de in-memory cache, de file op disk is niet veranderd. En nee @HollowGamer , een verstandig mens test dit op een VMtje ik had nog een “slachtoffer” VM in m’n security testlab.

[ Voor 21% gewijzigd door Liegebeest op 17-05-2026 07:20 ]

[TobyW]

Ik heb vanmiddag op mijn laptop de update van Kubuntu 25.10 naar 26.04 gedraaid. Op een klein probleempje met Nextcloud na lijkt alles goed te zijn gegaan. Ik heb ook meten de switch naar x86-64-v3 gedaan.

Ik heb nog drie servers op 24.04 draaien, maar daarmee wacht ik nog even - minimaal totdat 26.04.1 uit is.

[HollowGamer]

TobyW schreef op donderdag 21 mei 2026 @ 21:04:
Ik heb vanmiddag op mijn laptop de update van Kubuntu 25.10 naar 26.04 gedraaid. Op een klein probleempje met Nextcloud na lijkt alles goed te zijn gegaan. Ik heb ook meten de switch naar x86-64-v3 gedaan.

Ik heb nog drie servers op 24.04 draaien, maar daarmee wacht ik nog even - minimaal totdat 26.04.1 uit is.

Ik wist niet dat Kubuntu deze had? Ik hoop dat Fedora 45 het willen aanbieden.

[Hero of Time]

Ik moet dus eens gaan uitzoeken wat dat x86-64-v3 gebeuren is. Dacht dat het alleen een Fedora dingetje was. Daar zag ik ook jaren terug iets over dat ze voor 32 bit niet meer i586 builds deden, maar dat het verhoogd werd naar i686. Is dit vergelijkbaar? Zou dat niet issues geven met oudere 64 bit processors?

[HollowGamer]

Hero of Time schreef op donderdag 21 mei 2026 @ 21:29:
Ik moet dus eens gaan uitzoeken wat dat x86-64-v3 gebeuren is. Dacht dat het alleen een Fedora dingetje was. Daar zag ik ook jaren terug iets over dat ze voor 32 bit niet meer i586 builds deden, maar dat het verhoogd werd naar i686. Is dit vergelijkbaar? Zou dat niet issues geven met oudere 64 bit processors?

Het is helaas geen Fedora ding, meer een CachyOS ding.

Je hebt v3, v4 en ook zen (als je op AMD zit). Ik vond het niet perse sneller of beter. Soms had ik zelf het gevoel meer crashes te hebben. Fedora is wel bezig met het beter maken van performance, maar voorlopig is de vraag of dat doorgaat, Microsoft wilt Azure rebasen naar Fedora.

[synoniem]

Hero of Time schreef op donderdag 21 mei 2026 @ 21:29:
Ik moet dus eens gaan uitzoeken wat dat x86-64-v3 gebeuren is. Dacht dat het alleen een Fedora dingetje was. Daar zag ik ook jaren terug iets over dat ze voor 32 bit niet meer i586 builds deden, maar dat het verhoogd werd naar i686. Is dit vergelijkbaar? Zou dat niet issues geven met oudere 64 bit processors?

Deze post legt een en ander uit wat als starter kan gebruiken.

[CR2032]

Hero of Time schreef op donderdag 21 mei 2026 @ 21:29:
Ik moet dus eens gaan uitzoeken wat dat x86-64-v3 gebeuren is. Dacht dat het alleen een Fedora dingetje was. Daar zag ik ook jaren terug iets over dat ze voor 32 bit niet meer i586 builds deden, maar dat het verhoogd werd naar i686. Is dit vergelijkbaar? Zou dat niet issues geven met oudere 64 bit processors?

x86-64-v3 met de extra processor instructiesets kan interessant zijn bij veel multi threading met hoog data verbruik, zoals voor machine learning. Veel distro's zijn er nu mee bezig.

Bij Fedora is het nu een proposed change om het als standaard in te stellen. Zelf zou ik de ontwikkeling nog even afwachten, het komt vanzelf.

https://fedoraproject.org/wiki/Changes/Build_x86-64-v3_Packages

Tricky punt is dat data opslag niet meer uitwisselbaar wordt op computers die v3 niet ondersteunen. Je kunt zelf controleren of je processer het ondersteunt.

ld.so --help | grep '\-v[0-9]

x86-64-v4
 x86-64-v3 (supported, searched)
 x86-64-v2 (supported, searched)


.

[HollowGamer]

CR2032 schreef op vrijdag 22 mei 2026 @ 18:34:
[...]

x86-64-v3 met de extra processor instructiesets kan interessant zijn bij veel multi threading met hoog data verbruik, zoals voor machine learning. Veel distro's zijn er nu mee bezig.

Bij Fedora is het nu een proposed change om het als standaard in te stellen. Zelf zou ik de ontwikkeling nog even afwachten, het komt vanzelf.

https://fedoraproject.org/wiki/Changes/Build_x86-64-v3_Packages

Tricky punt is dat data opslag niet meer uitwisselbaar wordt op computers die v3 niet ondersteunen. Je kunt zelf controleren of je processer het ondersteunt.

ld.so --help | grep '\-v[0-9]

x86-64-v4
 x86-64-v3 (supported, searched)
 x86-64-v2 (supported, searched)

Vroeger kon je de setup meenemen, iets dat met Windows kan - maar nooit echt wordt aangeraden. Met Fedora zou ik dit concept enkel aanraden met Atomic varianten, want dan kun je die rebasen als je verandert van architectuur.

Het is inderdaad handig(er) voor apparaten die je erna niet meer zo snel veranderd. Of niet erg vindt om opnieuw te installeren.

[TobyW]

CR2032 schreef op vrijdag 22 mei 2026 @ 18:34:
[...]

Tricky punt is dat data opslag niet meer uitwisselbaar wordt op computers die v3 niet ondersteunen. Je kunt zelf controleren of je processer het ondersteunt.

Je kunt niet booten op een niet-v3 systeem, maar wel de data lezen.
Het is feitelijk niet meer dan dat alle executables en libraries met andere optimalisaties gecompileerd zijn die dus rekening houden met de functies (zoals AVX512) van recentere processoren.

[Hero of Time]

De link van @synoniem was erg verhelderend. Deed mij denken aan de vroegere PAE kernel voor Ubuntu Server. Als je CPU geen PAE had voor uitgebreidere geheugenruimte op 32 bit systemen, kon het systeem niet starten. En hoe m'n eerste pc met socket 939 geen Windows 8 en nieuwer kon draaien vanwege het ontbreken van SSE2 of SSE3.

[HollowGamer]

Hero of Time schreef op vrijdag 22 mei 2026 @ 23:05:
De link van @synoniem was erg verhelderend. Deed mij denken aan de vroegere PAE kernel voor Ubuntu Server. Als je CPU geen PAE had voor uitgebreidere geheugenruimte op 32 bit systemen, kon het systeem niet starten. En hoe m'n eerste pc met socket 939 geen Windows 8 en nieuwer kon draaien vanwege het ontbreken van SSE2 of SSE3.

Of MMX.. of ben ik al heel oud? 😅

[synoniem]

HollowGamer schreef op vrijdag 22 mei 2026 @ 23:52:
[...]

Of MMX.. of ben ik al heel oud? 😅

Ja.

[surcharge]

Het gaat natuurlijk om ondersteuning voor de 3DNow! instructies. Dan ben je pas hip.

[TobyW]

Was er ooit software die 3DNow! gebruikt heeft?

Mijn laptop leefde vanochtend twee uur in de toekomst, Ubuntu was opeens van mening dat de klok op UTC draait (wat bij mij niet het geval is vanwege dual-boot met Windows), dus ik had een gat van twee uur in een Grafana dashboard. Maar gelukkig draait alles nog... en de instelling is weer aangepast.

[RobertMe]

TobyW schreef op zaterdag 23 mei 2026 @ 09:00:
Mijn laptop leefde vanochtend twee uur in de toekomst, Ubuntu was opeens van mening dat de klok op UTC draait (wat bij mij niet het geval is vanwege dual-boot met Windows), dus ik had een gat van twee uur in een Grafana dashboard. Maar gelukkig draait alles nog... en de instelling is weer aangepast.

Was het niet logischer om Windows in te stellen dat de hardware clock in UTC is? (Register aanpassing). Dat is in ieder geval wat Arch beschrijft. En lijkt mij dan de voorkeur te hebben boven Linux aanpassen dat de hardware clock in local time is.

[Merik]

TobyW schreef op zaterdag 23 mei 2026 @ 09:00:
Mijn laptop leefde vanochtend twee uur in de toekomst, Ubuntu was opeens van mening dat de klok op UTC draait (wat bij mij niet het geval is vanwege dual-boot met Windows), dus ik had een gat van twee uur in een Grafana dashboard.

Waarschijnlijk de beste oplossing te laten syncen op netwerk tijd met NTP, en Windows op hardware clock, dat scheelt gerommel.

[synoniem]

TobyW schreef op zaterdag 23 mei 2026 @ 09:00:
Was er ooit software die 3DNow! gebruikt heeft?

Mijn laptop leefde vanochtend twee uur in de toekomst, Ubuntu was opeens van mening dat de klok op UTC draait (wat bij mij niet het geval is vanwege dual-boot met Windows), dus ik had een gat van twee uur in een Grafana dashboard. Maar gelukkig draait alles nog... en de instelling is weer aangepast.

Chrony installeren op Ubuntu en je hebt daar geen omkijken meer naar. Zover ik weet gaan alle Linux distro's er vanuit dat de hardware clock UTC is tenzij je zelf actief iets aanpast. Windows gaat er vanuit dat de hardware clock lokale tijd is. Wat ik zo gauw zie (ik heb zelf geen dual boot meer) kan je het aan de kant van Windows oplossen met:

reg add HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation /v RealTimeIsUniversal /t REG_DWORD /d 1

Of in Linux met:

sudo timedatectl set-local-rtc 1 --adjust-system-clock

Zelf installeer ik op alle linux machines chrony al sinds de eerste Raspberry Pi's zonder hardware clock battery op de markt kwamen.

[Hero of Time]

Merik schreef op zaterdag 23 mei 2026 @ 11:54:
[...]

Waarschijnlijk de beste oplossing te laten syncen op netwerk tijd met NTP, en Windows op hardware clock, dat scheelt gerommel.

Ik heb openntpd op mijn systeem en die was niet in staat om automatisch de afwijking die Windows veroorzaakt te corrigeren. Ik moest handmatig een sync doen om het te fixen. Dus alleen NTP sync is geen oplossing.

Heb ook eens gekeken hoe timedatectl werkt en dat is ook niet echt geweldig. Alternatieven zoals Chrony doen het denk beter. Heb ik ook op systemen draaien, maar geen mega afwijkingen meegemaakt omdat ik eens een portable Windows heb gestart.

[TobyW]

synoniem schreef op zaterdag 23 mei 2026 @ 12:12:
[...]Of in Linux met:

sudo timedatectl set-local-rtc 1 --adjust-system-clock

Dit is dus hoe ik het had (en nu weer heb), maar vermoedelijk door de update van 25.10 naar 26.04 was er dus iets fout gegaan. Dat van de registry aanpassing in Windows kende ik niet.

[Merik]

Grappig, geen idee dat dat op 2 manieren uitgelezen kan worden, en mogelijk verkeerde systeemtijd oplevert. Wordt daar maar eens wijs uit als (normie) eindgebruiker.

Link (Tilaa KVM) met de info van @synoniem

[RobertMe]

He bah. Ik dacht eindelijk een opvolger gevonden te hebben voor mijn antieke ("Windows" / Atom based) Asus Transformer tablet (met kickstand en toetsenbord). Zonder dan de hoofdprijs te betalen voor een Surface.

Tijd terug tegen de, wat oudere, Xiaomi Pad 6S Pro aangelopen. "Geen ingebouwde kickstand", maar wel een toetsenbord cover met kickstand. Bij PostmarketOS staat die ook vermeld incl een hele riedel "Works" en zelfs een vermelding van iemand die hem als daily driver / "desktop" gebruikt. Dat schept vertrouwen.
Voordat ik de knoop definitief doorhak toch maar even de pagina lezen... Blijkt er een locked bootloader op te zitten. Unlocken kan, maar is een dagelijkse loterij?! Je moet in de Xiaomi Community app een unlock aanvragen. Maar, je account moet een bepaalde leeftijd hebben (de originele uitleg waar PostmarketOS naar verwijst stelt 30 dagen, wat andere zoekresultaten suggereren "3 tot 7 dagen"). En ze geven maar X unlocks per dag weg (per model? Over hun gehele product lineup?). Met een "reset" elke dag om 00:00+08:00. En er gaat ook wat tijd (72 uur?) over de aanvraag heen. Ergo: je moet dan maar elke dag om 7u "onze tijd" een unlock aanvraag doen en hopen op het beste? En per account maximaal 1 unlock per jaar.
Dat zijn dus wel heel veel rare hoepels waar je doorheen moet springen voordat je een apparaat dat je 100% koopt ook 100% mag gebruiken.... Waarbij ik uiteraard het liefst het ding uberhaupt niet hoef te registreren. Uit de doos halen en flashen maar. Wordt dan wel een leuke use case om mijn recent ontdekte DuckDuckGo anonieme email-forwarding service te testen. Gewoon een account aanmaken op naam van Pietje Puck met zo'n willekeurig @duck.com mailadres dat dan forward naar mijn echte adres.

Edit:
Op die Asus Transformer heb in nu dan al een aantal jaren Arch met KDE Plasma draaien. Werkt okay-ish. Maar de specs zijn uberhaupt gewoon crap. Linux werkt in ieder geval wel beter dan Windows. Maar het is gewoon zwakke hardware.

[ Voor 6% gewijzigd door RobertMe op 28-05-2026 19:39 ]

[thunder7]

Ik kom er net achter dat de combinatie firefox/ebay.de/paypal nu alleen nog werkt als ik mezelf via de useragent als Chromium vermom. Strict tracking protection en u-block zijn dan geen probleem. Vroeger (eerder dit jaar) hoefde dat niet....

[franssie]

Ik had nog een Surface Go 3 - die ik eigenlijk alleen op vakantie meeneem om toch ets meer te hebben dan een telefoon. Maar hoewel err windows 11 op draait (vraag me niet hoe met die kreupele proc) er vandaag toch maar eens Ubuntu 26.04 op gezet (is toch geen productie ding dus gelijk het diepe in).
Werkt eigenlijk prima, geen kernel dingen moeten doen of wat dan ook.
OK, trackpad werkte even niet en opladen via USB C werkt soms wel en some niet, beide wel op te lossen met een herstart (zal nog even wat inschieten bij Ubuntu).
Maar ding is nog steeds niet erg snel, maar prima om op reis wat te streamen (en ik heb er een 1 TB sd kaartje in met wat doenloads), hotels te zoeken (ik kan dat niet op een telefoonscherm) etc etc.

[CR2032]

Iemand al ervaringen met de nieuwe Fedora Hummingbird?

De nieuwe volledig imaged based container rolling distro. Geen package manager meer nodig! De bootable image container is nu als POC beschikbaar.

https://fedoramagazine.org/fedora-hummingbird-linux-taking-the-hummingbird-model-to-the-full-os/

Ziet er interessant uit.

https://www.fosslinux.com/156974/fedora-hummingbird-is-this-the-end-of-traditional-linux.htm

[HollowGamer]

CR2032 schreef op zaterdag 30 mei 2026 @ 18:53:
Iemand al ervaringen met de nieuwe Fedora Hummingbird?

De nieuwe volledig imaged based container rolling distro. Geen package manager meer nodig! De bootable image container is nu als POC beschikbaar.

https://fedoramagazine.org/fedora-hummingbird-linux-taking-the-hummingbird-model-to-the-full-os/

Ziet er interessant uit.

https://www.fosslinux.com/156974/fedora-hummingbird-is-this-the-end-of-traditional-linux.htm

Ik wil het graag proberen, maar het is helaas (nog) niet geschikt voor de desktop.

[L0g0ff]

CR2032 schreef op zaterdag 30 mei 2026 @ 18:53:
Iemand al ervaringen met de nieuwe Fedora Hummingbird?

De nieuwe volledig imaged based container rolling distro. Geen package manager meer nodig! De bootable image container is nu als POC beschikbaar.

https://fedoramagazine.org/fedora-hummingbird-linux-taking-the-hummingbird-model-to-the-full-os/

Ziet er interessant uit.

https://www.fosslinux.com/156974/fedora-hummingbird-is-this-the-end-of-traditional-linux.htm

Nice, klinkt een beetje als Dakota. Ook een "distroloos" gnomeos.

https://github.com/projectbluefin/dakota

[HollowGamer]

L0g0ff schreef op zaterdag 30 mei 2026 @ 19:47:
[...]

Nice, klinkt een beetje als Dakota. Ook een "distroloos" gnomeos.

https://github.com/projectbluefin/dakota

Het lijkt erg op systemd met mkosi. Je maakt daarmee meer Docker achtige images mee.

[L0g0ff]

HollowGamer schreef op zaterdag 30 mei 2026 @ 19:51:
[...]

Het lijkt erg op systemd met mkosi. Je maakt daarmee meer Docker achtige images mee.

Kende die niet. Thanks!

[HollowGamer]

L0g0ff schreef op zaterdag 30 mei 2026 @ 20:43:
[...]

Kende die niet. Thanks!

Je moet wel echt van systemd houden.. niet iedereen staat daar voor open 😅

[Hero of Time]

Vind systemd als init systeem prima, voor alle andere wat het doet/kan moet je ver weg blijven. Genoeg bestaande wielen die al prima werken en geen vervanging nodig hebben.

[HollowGamer]

Hero of Time schreef op zaterdag 30 mei 2026 @ 21:20:
Vind systemd als init systeem prima, voor alle andere wat het doet/kan moet je ver weg blijven. Genoeg bestaande wielen die al prima werken en geen vervanging nodig hebben.

Ik vind het juist fijn werken. Ook omdat alles gelogged wordt op een plek en je ook restart met systemctl.

[RobertMe]

Hero of Time schreef op zaterdag 30 mei 2026 @ 21:20:
Vind systemd als init systeem prima, voor alle andere wat het doet/kan moet je ver weg blijven. Genoeg bestaande wielen die al prima werken en geen vervanging nodig hebben.

Ik gebruik systemd-networkd op alle servers/.... En daaronder valt ook mijn router (zelfbouw, plain Debian). Werkt an zich prima. Het enige dat die niet kan is PPPoE, maar dat heb ik met Ziggo toch niet nodig Maar zou niet perse onderdeel van systemd hoeven te zijn en kan ook als los project onder een eigen paraplu.
En systemd timers vind ik ook een prima ding. Tenminste niet overal cron voor nodig (lees: ik gebruik nu geen cron).
udev bestond natuurlijk al ver voor systemd, en is er later door opgeslokt. Lijkt me ook wel een vereiste voor je systeem.
User services maak ik niet echt gebruik van (ok, nouja, volgens mij start ik de ssh agent via een user service). En het maakt het beheer wel in lijn met het init gebeuren. Dus niks dubbel te leren. En uiteraard redelijk universeel tussen de DEs (+ het wordt onderwater sowieso gebruikt door voorheen Pulse Audio en neem aan nu Pipewire / Wireplumber / weet ik hoe het heet).
systemd-run is vervolgens een soort van interne abstractie die publiekelijk is gemaakt. Potentieel onzinnig, maar kan ook handig zijn. (Ik schedule een shutdown van mijn NAS altijd met systemd-run --on-calendar '<tijdstip> systemctl poweroff ).
Of het nu ook alweer een sudo vervanger moet worden? Hopelijk niet.
En owja, systemd-cryptsetup. Als systeem volgens mij toch fijner dan alle losse onderliggende zaken (luks etc). systemd-cryptsetup geeft dan een meer user friendly abstractie. Moet het onderdeel zijn van systemd? Nee, niet echt. Is het als tooling fijn? Ja.

[himlims_]

CR2032 schreef op zaterdag 30 mei 2026 @ 18:53:
Iemand al ervaringen met de nieuwe Fedora Hummingbird?

De nieuwe volledig imaged based container rolling distro. Geen package manager meer nodig! De bootable image container is nu als POC beschikbaar.

https://fedoramagazine.org/fedora-hummingbird-linux-taking-the-hummingbird-model-to-the-full-os/

Ziet er interessant uit.

https://www.fosslinux.com/156974/fedora-hummingbird-is-this-the-end-of-traditional-linux.htm

Hé wat hoe dan? Geen package manager? Terug naar 1998, en alles tar.gz compilen? Om na 2 dagen tot conclusie te komen dat je weer een lib.so mist

[Hero of Time]

HollowGamer schreef op zaterdag 30 mei 2026 @ 21:27:
[...]

Ik vind het juist fijn werken. Ook omdat alles gelogged wordt op een plek en je ook restart met systemctl.

Dat zeg ik toch ook? Voor init dingen, prima, werkt goed. Maar voor de volgende dingen, why the fuck moet het wiel hiervoor opnieuw uitgevonden worden?

• Timesync/NTP
• Netwerk
• DNS resolving
• Udev
• Bootloader
• FS mounting/mapping

En dan ben ik vast nog wel iets vergeten wat systemd doet, maar een init systeem helemaal niks mee te maken heeft.

RobertMe schreef op zaterdag 30 mei 2026 @ 21:42:
[...]

Ik gebruik systemd-networkd op alle servers/.... En daaronder valt ook mijn router (zelfbouw, plain Debian). Werkt an zich prima. Het enige dat die niet kan is PPPoE, maar dat heb ik met Ziggo toch niet nodig Maar zou niet perse onderdeel van systemd hoeven te zijn en kan ook als los project onder een eigen paraplu.

Wat was er mis met ifupdown van Debian? Of NetworkManager? Die kunnen wel gewoon PPPoE. En andere protocollen/verbindingen.

En systemd timers vind ik ook een prima ding. Tenminste niet overal cron voor nodig (lees: ik gebruik nu geen cron).

Timers vind ik een twijfel gevalletje. Sowieso is een override wat onlogisch, want zet je een nieuwe tijd met 'OnCalendar=....' dan wordt het toegevoegd, je moet eerst een lege 'OnCalendar=' neerzetten om de reeds bestaande default weg te halen.

udev bestond natuurlijk al ver voor systemd, en is er later door opgeslokt. Lijkt me ook wel een vereiste voor je systeem.

Ja, vereist voor je systeem, maar waarom moet een init systeem dit overnemen? Het deed het al prima, er was geen reden voor om het nu als diep gewortelde afhankelijkheid te hebben. Update voor udev is gelijk je hele init systeem moeten bijwerken, met alle andere meuk die het doet. Geeft veel te veel overhead.

User services maak ik niet echt gebruik van (ok, nouja, volgens mij start ik de ssh agent via een user service). En het maakt het beheer wel in lijn met het init gebeuren. Dus niks dubbel te leren. En uiteraard redelijk universeel tussen de DEs (+ het wordt onderwater sowieso gebruikt door voorheen Pulse Audio en neem aan nu Pipewire / Wireplumber / weet ik hoe het heet).

Niet dubbel leren, aardig, maar het is ook niet direct inzichtelijk met 1 commando om te zien welke services er allemaal draaien, dat vereist er 2, namelijk voor systeem niveau en voor user niveau.

Deels problematisch dat het universeel tussen DE's is, want ze gaan er op leunen en integreren. Niet zo fijn voor de non-Linux gebruikers, want o.a. BSD heeft geen systemd. Had je vroeger desktop parity tussen BSD en Linux, is dat er nu niet meer vanwege de sterke afhankelijkheid van systemd. *kuch*Gnome*kuch*.

systemd-run is vervolgens een soort van interne abstractie die publiekelijk is gemaakt. Potentieel onzinnig, maar kan ook handig zijn. (Ik schedule een shutdown van mijn NAS altijd met systemd-run --on-calendar '<tijdstip> systemctl poweroff ).

Langer commando dan 'at <time> <commando>'. Een tool van maar 162 KB (althans, package dat uitgepakt is, daar zit natuurlijk meer in dan alleen de tool). Gegarandeerd dat systemd-run een flinke veelvoud is daarvan.

Of het nu ook alweer een sudo vervanger moet worden? Hopelijk niet.
En owja, systemd-cryptsetup. Als systeem volgens mij toch fijner dan alle losse onderliggende zaken (luks etc). systemd-cryptsetup geeft dan een meer user friendly abstractie. Moet het onderdeel zijn van systemd? Nee, niet echt. Is het als tooling fijn? Ja.

Precies, het hoeft geen onderdeel te zijn. Er zijn al zaken voor LUKS, dat is een eigen ding dat al vele jaren bestond voordat systemd ook maar een brainfart was. Bovendien, aardig die abstractie, maar er zijn nog een paar extra opties bovenop cryptsetup zelf dat niet met systemd-cryptsetup werken/nodig hebben.
Er is trouwens ook een reden waarom het 'abstractie' is. Net als abstracte kunst, je ziet niet direct wat het moet betekenen/uitbeelden. Zo ook dit, het doet dingen voor je zonder dat je weet wat er nou eigenlijk gebeurt.

[L0g0ff]

himlims_ schreef op zaterdag 30 mei 2026 @ 22:03:
[...]

Hé wat hoe dan? Geen package manager? Terug naar 1998, en alles tar.gz compilen? Om na 2 dagen tot conclusie te komen dat je weer een lib.so mist

Toolbx/Distrobox/Docker/Brew/Flatpak.
Dat is in principe voldoende. Je host blijft dan ook schoon.

[RobertMe]

Hero of Time schreef op zaterdag 30 mei 2026 @ 23:43:
[...]

Wat was er mis met ifupdown van Debian? Of NetworkManager? Die kunnen wel gewoon PPPoE. En andere protocollen/verbindingen.

Die doen geen dienst als DHCP server, evenals dat ze geen router advertisements zullen sturen, evenals geen DHCP-PD ondersteuning. Zaken die systemd-networkd out-of-the-box kan. En DHCP server is wellicht een niche (want daarvan heb je er maar één nodig en vaak zul je een dedicated router hebben), maar IPv6 RAs stuur ik bv ook van op mijn servertje, om extra routes te publiceren vanaf de boos daarop het subnet gerouteerd wordt.

Daarnaast, als ik even zo snel kijk, doet ifup al helemaal geen Wireguard? Dan moet je met pre-up aan de slag en gewoon ip link add ... type wireguard doen, en vervolgens pre-up wg setconf .... Terwijl het in systemd-networkd (en NetworkManager) gewoon native ondersteund wordt.

En NetworkManager is gevoelsmatig meer voor "dynamische" verbindingen. Dus de categorie een laptop waarbij je nog wel eens verbindt met een ander wifi netwerk en zo. Waarbij je de configuratie dan at-runtime aanpast met nmcli of via een UI die het via DBus naar een daemon stuurt. Niet iets wat ik handig vind voor statische configuraties zoals op een server of router. Ook omdat je dan liever config files hebt die je eenvoudig kunt backuppen, bijhouden in git, evt uitrollen via Ansible of wat dan ook, ....

[...]

Timers vind ik een twijfel gevalletje. Sowieso is een override wat onlogisch, want zet je een nieuwe tijd met 'OnCalendar=....' dan wordt het toegevoegd, je moet eerst een lege 'OnCalendar=' neerzetten om de reeds bestaande default weg te halen.

Dat heeft dan weer totaal niks met systemd-timers te maken. Dat is gewoon hoe het systemd file format werkt. En geldt dus voor elke optie die meerdere keren ingesteld kan zijn. Bv ook een ExecPreStart kun je meerdere keren hebben. En ook die "reset" je met een lege ExecPreStart=. Dat is dus geen pijnpunt van systemd-timers maar een pijnpunt van het systemd file format.

[...]

Ja, vereist voor je systeem, maar waarom moet een init systeem dit overnemen? Het deed het al prima, er was geen reden voor om het nu als diep gewortelde afhankelijkheid te hebben. Update voor udev is gelijk je hele init systeem moeten bijwerken, met alle andere meuk die het doet. Geeft veel te veel overhead.

Nja ok, sure. Net zoals die andere dingen waarbij ik het aanhaalde hoeft het natuurlijk geen onderdeel van systemd te zijn.
En hetzelfde geldt natuurlijk voor gummiboot dat in systemd is opgegaan incl een rename naar systemd-boot. Ook dat had prima als eigen project kunnen blijven bestaan.
Maar uiteraard anderzijds de vraag: hoe "populair" zouden udev, gummiboot, ... zijn als standalone projecten? Wellicht waren en bleven beiden dan een one-man show zonder tractie onder gebruikers of cobtributors, en waren ze een stille dood gestorven. Nu ze onder systemd leven zullen er veel meer ogen naar kijken. Maar het monolitische ontwikkelmodel met 1 release van alles is zeker wel een pijnpunt ja. Losse projecten onder 1 paraplu met een los release schema / ... was een betere middenweg.

[...]

Langer commando dan 'at <time> <commando>'. Een tool van maar 162 KB (althans, package dat uitgepakt is, daar zit natuurlijk meer in dan alleen de tool). Gegarandeerd dat systemd-run een flinke veelvoud is daarvan.

Die kende ik niet. En natuurlijk heeft poweroff zelf ook al een optie om te plannen. Maar op een systemd gebaseerd systeem zijn poweroff, halt, reboot etc ook al polyfills / wrappers om systemd. Zou dus zomaar kunnen dat die ook een timer er voor aanmaakt onderwater.

En wat systemd-run potentieel over at heeft is dat je de volledige systemd functionaliteit tot je beschikking hebt. Je kunt ook met simpele opties het commando laten uitvoeren als een andere user, zonder netwerktoegang, met eigen temp dirs/mounts voor bepaalde locaties.... Bij wijze van alles dat je in een service unit file kunt zetten kun je ook als command line flags bij systemd-run opgeven.

[Hero of Time]

RobertMe schreef op zondag 31 mei 2026 @ 13:33:
[...]

Die doen geen dienst als DHCP server, evenals dat ze geen router advertisements zullen sturen, evenals geen DHCP-PD ondersteuning. Zaken die systemd-networkd out-of-the-box kan. En DHCP server is wellicht een niche (want daarvan heb je er maar één nodig en vaak zul je een dedicated router hebben), maar IPv6 RAs stuur ik bv ook van op mijn servertje, om extra routes te publiceren vanaf de boos daarop het subnet gerouteerd wordt.

Dus systemd heeft nu ook zelfs dhcp server overgenomen? Daar is dhcpcd, dnsmasq, coredhcp-server en meer voor. Voor IPv6 zie ik dat dhcpcd er ondersteuning voor heeft, radvd is er, wide-dhcpv6-server, en vast nog wel meer. Dit wiel is al meerdere keren uitgevonden en nu doet systemd het nog eens dunnetjes over.

Daarnaast, als ik even zo snel kijk, doet ifup al helemaal geen Wireguard? Dan moet je met pre-up aan de slag en gewoon ip link add ... type wireguard doen, en vervolgens pre-up wg setconf .... Terwijl het in systemd-networkd (en NetworkManager) gewoon native ondersteund wordt.

Die doen het niet echt native, maar hebben de WG tools ingebouwd zodat ze geen afhankelijkheid hebben van het aparte package. Met ook weer de nadelen ervan als er een issue blijkt te zijn: volledige set moet bijgewerkt worden ipv alleen het WG gedeelte.

En NetworkManager is gevoelsmatig meer voor "dynamische" verbindingen. Dus de categorie een laptop waarbij je nog wel eens verbindt met een ander wifi netwerk en zo. Waarbij je de configuratie dan at-runtime aanpast met nmcli of via een UI die het via DBus naar een daemon stuurt. Niet iets wat ik handig vind voor statische configuraties zoals op een server of router. Ook omdat je dan liever config files hebt die je eenvoudig kunt backuppen, bijhouden in git, evt uitrollen via Ansible of wat dan ook, ....

NetworkManager heeft gewoon z'n config in /etc/NetworkManager/system-connections staan als bestanden. Dus je hele verhaal gaat voor NM dus al niet op. Toen ik m'n RHEL 7 certificering haalde, werd er ook met NetworkManager het netwerk ingesteld ipv handmatig zut in /etc/sysconf/network-scripts frotten. Er was maar 1 unieke situatie waarbij dat nodig was en dat heb je echt zomaar als eis. Een situatie die alleen bij servers is en zelfs daar is dat ene puntje enorm niche.

[...]

Dat heeft dan weer totaal niks met systemd-timers te maken. Dat is gewoon hoe het systemd file format werkt. En geldt dus voor elke optie die meerdere keren ingesteld kan zijn. Bv ook een ExecPreStart kun je meerdere keren hebben. En ook die "reset" je met een lege ExecPreStart=. Dat is dus geen pijnpunt van systemd-timers maar een pijnpunt van het systemd file format.

Daarom zeg ik ook 'onlogisch'. Zoals je zelf ook aangeeft, het is met meer opties in het file format dat zo werkt. Het resultaat van een 'systemctl edit' maakt namelijk ook een override.conf aan voor de unit. Een override, geen addendum. Dat maakt het onlogisch en voor wie er niet dieper in kijkt, heel onverwacht in het resultaat/gedrag.

[...]

Nja ok, sure. Net zoals die andere dingen waarbij ik het aanhaalde hoeft het natuurlijk geen onderdeel van systemd te zijn.
En hetzelfde geldt natuurlijk voor gummiboot dat in systemd is opgegaan incl een rename naar systemd-boot. Ook dat had prima als eigen project kunnen blijven bestaan.
Maar uiteraard anderzijds de vraag: hoe "populair" zouden udev, gummiboot, ... zijn als standalone projecten? Wellicht waren en bleven beiden dan een one-man show zonder tractie onder gebruikers of cobtributors, en waren ze een stille dood gestorven. Nu ze onder systemd leven zullen er veel meer ogen naar kijken. Maar het monolitische ontwikkelmodel met 1 release van alles is zeker wel een pijnpunt ja. Losse projecten onder 1 paraplu met een los release schema / ... was een betere middenweg.

Als iets populair genoeg is, zou dat ook extra maintainers moeten aantrekken. Nu is het net alsof een groot bedrijf een startup overneemt en er helemaal niks meer overblijft van de startup zelf of de gedachtegoed. Udev bestond al lang voor systemd. Wat heeft systemd nou echt toegevoegd aan udev wat functioneel ontbrak en broodnodig was, wat ze niet al zelf konden doen?

[...]

Die kende ik niet. En natuurlijk heeft poweroff zelf ook al een optie om te plannen. Maar op een systemd gebaseerd systeem zijn poweroff, halt, reboot etc ook al polyfills / wrappers om systemd. Zou dus zomaar kunnen dat die ook een timer er voor aanmaakt onderwater.

En wat systemd-run potentieel over at heeft is dat je de volledige systemd functionaliteit tot je beschikking hebt. Je kunt ook met simpele opties het commando laten uitvoeren als een andere user, zonder netwerktoegang, met eigen temp dirs/mounts voor bepaalde locaties.... Bij wijze van alles dat je in een service unit file kunt zetten kun je ook als command line flags bij systemd-run opgeven.

Waar ik juist tegen systemd ben in de functie, is dat niks dynamisch is na een wijziging. Vroeger kon je zo je NAS of nieuwe schijf/partitie toevoegen aan fstab en gelijk mounten. Nu gaat het lopen janken dat je niet eerst even een daemon-reload hebt gedaan. Afhankelijk van de distro wordt dat toch nog even netjes voor je gedaan en werkt het, maar dat neemt het gejank niet weg.

Ook als je een service maakt of aanpast. Vroeger met de init scripts was het direct bekend en kon je door. Nu? Nee, niks van wat je hebt gedaan is bekend, herlaad systemd maar want het is te dom om een inotify te doen op bestanden die je hebt gewijzigd of toegevoegd. En om nou te zeggen "het is als bescherming tegen fouten", nee, dat is het ook niet. Maak je een fuckup dan is dat net zo van toepassing na een daemon-reload als zonder die noodzaak. Bij fstab krijg je al een error als de mount opties niet kloppen. Je unit start niet als daar ook iets ontbreekt. En syntax fouten waardoor heel systemd op z'n bek zou gaan en je systeem potentieel meeneemt is gewoon broddelwerk van de ontwikkelaar(s) en missen ze fatsoenlijke foutafhandeling.

Begrijp mij niet verkeerd, er is zeker meerwaarde aan systemd. Maar het is verre van het Ei van Columbus waar velen zo lyrisch over zijn. Doe 1 ding en doe het goed. Dat is niet systemd, die alles wil doen maar zelf niet eens uitmuntend is in z'n core.

[RobertMe]

Hero of Time schreef op zondag 31 mei 2026 @ 15:06:
[...]

Dus systemd heeft nu ook zelfs dhcp server overgenomen? Daar is dhcpcd, dnsmasq, coredhcp-server en meer voor. Voor IPv6 zie ik dat dhcpcd er ondersteuning voor heeft, radvd is er, wide-dhcpv6-server, en vast nog wel meer. Dit wiel is al meerdere keren uitgevonden en nu doet systemd het nog eens dunnetjes over.

En vervolgens heb je 3 services draaien met 3 (en nog meer) config files om één ding te doen.
Als ik nu een VLAN toevoeg betekent dat 2 bestanden aanmaken / invullen (1 voor het network device en 1 voor de config) en het bestand van de fysieke interface aanpassen (1 regel toevoegen). Ga ik NetworkManager + dnsmasq + radvd gebruiken moet ik met 3 tools bekend zijn en op 3 totaal verschillende locaties zaken aanpassen, om één ding te doen: mijn netwerk beheren.

Dat het vervolgens niet in een monorepo van systemd hoort ben ik het wél mee eens.

[...]

Die doen het niet echt native, maar hebben de WG tools ingebouwd zodat ze geen afhankelijkheid hebben van het aparte package. Met ook weer de nadelen ervan als er een issue blijkt te zijn: volledige set moet bijgewerkt worden ipv alleen het WG gedeelte.

Maar WG zit in de kernel dus je hebt niet echt te maken met verschillende implementaties. Ja sure, verschillende implementaties die de kernel APIs aanroepen. Maar dat veranderd niet echt als je de wg CLI als API hebt. Even verkeerd een commando uitvoeren en niet of verkeerd de arguments escapen en je bent ook de l*l.
En laten we eerlijk zijn, als de "config" bestaat uit zelf alles met pre-ups aan elkaar breien dan is er dus géén config en kun je net zo goed zelf een shell script schrijven. Nog los van dat fouten in de "config" niet te vinden zijn. Bij systemd unit files kun je prima de inhoud analyseren of alle keys bekend zijn, of de values kloppen met het verwachte formaat (dat een Address ook een IPv4 of IPv6 adres is. Dat een private key van een WG config ook correcte base64 is, ...), etc etc. Maar op het moment dat je met ifup begint met pre-up valt er niks, noppes, nada te valideren en moet at runtime maar blijken of de ingevulde value ook daadwerkelijk een uitvoerbaar commando is. Maar het kan net zo goed zijn dat bv de hele executable niet bestaat, of arguments niet kloppen, of.... Een probleem dat veel minder speelt als je een echte config er voor hebt. En je zult nu maar alles vol hebben staan met ip ... en vervolgens komt er een opvolger van iproute2 waardoor je alles weer anders moet doen (zoals dus het geval was voordat iproute2 bestond en je dus nog geen ip commando had).

Begrijp mij niet verkeerd, er is zeker meerwaarde aan systemd. Maar het is verre van het Ei van Columbus waar velen zo lyrisch over zijn. Doe 1 ding en doe het goed. Dat is niet systemd, die alles wil doen maar zelf niet eens uitmuntend is in z'n core.

Ter herhaling: eens. Er zit nu teveel in de monolitische systemd die prima apart zou moeten kunnen bestaan (en een deel al vooraf deed bestaan).

[Merik]

Als power user ervaar ik zelf ook niet de toegevoegde waarde, processen en services is een goede maar verder, tsja. Maar het zal wel de standaard worden nu sowieso.

Kleine flashback naar deze skit, bij het volgen van de discussie

[gambieter]

@Merik . Welke distro zou Harry Jekkers kiezen? Raampies, kan je lekker uit kijken

[synoniem]

Ik sluit me aan bij @Hero of Time dat systemd als init systeem goed bruikbaar is. Maar het verworden tot 1 grote monolithisch systeem voor van alles en nog wat, is totaal niet nodig en zelfs onwenselijk. Systemd is indertijd o.a. aan de man gebracht als sneller booten, concurrent inits etc. Dus "veel beter" dan die ellenlange init scripts van sysv. Doordat systemd een steeds grotere grip op het systeem krijgt, zijn die voordelen wel verdwenen. En hoewel ik systemd service files goede uniforme manier van werken vind is de eenvoud daarvan ook al lang weg. Als voorbeeld de chrony.service file

code:

[Unit]
Description=chrony, an NTP client/server
Documentation=man:chronyd(8) man:chronyc(1) man:chrony.conf(5)
Conflicts=openntpd.service ntp.service ntpsec.service
Wants=time-sync.target
Before=time-sync.target
After=network.target
ConditionCapability=CAP_SYS_TIME

[Service]
Type=forking
PIDFile=/run/chrony/chronyd.pid
EnvironmentFile=-/etc/default/chrony
ExecStart=/usr/sbin/chronyd $DAEMON_OPTS
PrivateTmp=yes
ProtectHome=yes
ProtectSystem=full
ProtectControlGroups=yes
ProtectKernelModules=yes
ProtectKernelTunables=yes

[Install]
Alias=chronyd.service
WantedBy=multi-user.target

Dus nee wat mij betreft wordt systemd zo snel mogelijk modulair.

[HollowGamer]

synoniem schreef op zondag 31 mei 2026 @ 18:49:
Ik sluit me aan bij @Hero of Time dat systemd als init systeem goed bruikbaar is. Maar het verworden tot 1 grote monolithisch systeem voor van alles en nog wat, is totaal niet nodig en zelfs onwenselijk. Systemd is indertijd o.a. aan de man gebracht als sneller booten, concurrent inits etc. Dus "veel beter" dan die ellenlange init scripts van sysv. Doordat systemd een steeds grotere grip op het systeem krijgt, zijn die voordelen wel verdwenen. En hoewel ik systemd service files goede uniforme manier van werken vind is de eenvoud daarvan ook al lang weg. Als voorbeeld de chrony.service file

code:

[Unit]
Description=chrony, an NTP client/server
Documentation=man:chronyd(8) man:chronyc(1) man:chrony.conf(5)
Conflicts=openntpd.service ntp.service ntpsec.service
Wants=time-sync.target
Before=time-sync.target
After=network.target
ConditionCapability=CAP_SYS_TIME

[Service]
Type=forking
PIDFile=/run/chrony/chronyd.pid
EnvironmentFile=-/etc/default/chrony
ExecStart=/usr/sbin/chronyd $DAEMON_OPTS
PrivateTmp=yes
ProtectHome=yes
ProtectSystem=full
ProtectControlGroups=yes
ProtectKernelModules=yes
ProtectKernelTunables=yes

[Install]
Alias=chronyd.service
WantedBy=multi-user.target

Dus nee wat mij betreft wordt systemd zo snel mogelijk modulair.

code:

PrivateTmp=yes
ProtectHome=yes
ProtectSystem=full
ProtectControlGroups=yes
ProtectKernelModules=yes
ProtectKernelTunables=yes

Dit willen ze allemaal 'true' maken, maar helaas zijn genoeg services die simpelweg niet werken zonder een eigen /tmp of group. Dat is een voordeel van systemd, je kunt die services sandboxen (of niet).

Het voordeel is juist dat het heel dicht op de kernel zit, en vrijwel daar ook alles van gebruikt. Ik vind run0 bijvoorbeeld ook prima i.p.v. sudo.

Vind je het niets? Prima toch, genoeg alternatieven. Alleen snap ik wel dat Linux-developers geen zin hebben om alles te gaan ondersteunen. Je mag ook op Xorg blijven, maar niet zeuren als dan developers ermee stoppen.

[RobertMe]

synoniem schreef op zondag 31 mei 2026 @ 18:49:
Ik sluit me aan bij @Hero of Time dat systemd als init systeem goed bruikbaar is. Maar het verworden tot 1 grote monolithisch systeem voor van alles en nog wat, is totaal niet nodig en zelfs onwenselijk. Systemd is indertijd o.a. aan de man gebracht als sneller booten, concurrent inits etc. Dus "veel beter" dan die ellenlange init scripts van sysv. Doordat systemd een steeds grotere grip op het systeem krijgt, zijn die voordelen wel verdwenen. En hoewel ik systemd service files goede uniforme manier van werken vind is de eenvoud daarvan ook al lang weg. Als voorbeeld de chrony.service file

code:

[Unit]
Description=chrony, an NTP client/server
Documentation=man:chronyd(8) man:chronyc(1) man:chrony.conf(5)
Conflicts=openntpd.service ntp.service ntpsec.service
Wants=time-sync.target
Before=time-sync.target
After=network.target
ConditionCapability=CAP_SYS_TIME

[Service]
Type=forking
PIDFile=/run/chrony/chronyd.pid
EnvironmentFile=-/etc/default/chrony
ExecStart=/usr/sbin/chronyd $DAEMON_OPTS
PrivateTmp=yes
ProtectHome=yes
ProtectSystem=full
ProtectControlGroups=yes
ProtectKernelModules=yes
ProtectKernelTunables=yes

[Install]
Alias=chronyd.service
WantedBy=multi-user.target

Dus nee wat mij betreft wordt systemd zo snel mogelijk modulair.

Het voorbeeld staan natuurlijk wel zaken in die "niet hoeven" (lees: niet verplicht zijn voor een correcte werking). En die je ook niet "even" in sysv doet (private temp en al die andere zaken). Dus ja, al die opties maken het erg verbose, maar als je het zelf moet doen zoals bij sysv kost het wel heel veel meer regels code. En vanuit security oogpunt is het natuurlijk alleen maar goed dat al deze zaken gedaan worden en iets dat je bij voorkeur ook zou moeten doen als je crony via sysv start.

[nelizmastr]

franssie schreef op donderdag 28 mei 2026 @ 22:44:
Ik had nog een Surface Go 3 - die ik eigenlijk alleen op vakantie meeneem om toch ets meer te hebben dan een telefoon. Maar hoewel err windows 11 op draait (vraag me niet hoe met die kreupele proc) er vandaag toch maar eens Ubuntu 26.04 op gezet (is toch geen productie ding dus gelijk het diepe in).
Werkt eigenlijk prima, geen kernel dingen moeten doen of wat dan ook.

Hier vorige week een MacBook Air uit 2014 voorzien van Kubuntu 26.04 LTS.

Mijn PC die hoofdzakelijk voor games is draait sinds december geen Windows meer.

Ik vond het vooral verbluffend hoe goed zo’n ouwe Air met z’n afgekloven Haswell U-serie dual core proc nog draait. Ga je er een snelheidsrecord mee halen? Nee. Maar het werkt verbluffend vloeiend voor office en browser werk. Onder macOS Big Sur is het allemaal moeizaam.

Zo’n surface go 3 zou toch net zo redelijk moeten zijn. Wellicht een andere desktop environment nemen. Zelfs met een Pentium Gold moet je toch prima kunnen werken als het ook prima kan op een 12j oude MacBook Air

[Sjah]

Ik zit nu dik een maand op Ubuntu 26.04, maar de .1 release mag komen (mits die volgende problemen oplost). Merk dat reboot langer duurt, en verder WW ingeven heeft ook een hickup bij boot.

[ Voor 10% gewijzigd door Sjah op 31-05-2026 22:21 ]

[synoniem]

HollowGamer schreef op zondag 31 mei 2026 @ 20:00:
[...]


[...]


Dit willen ze allemaal 'true' maken, maar helaas zijn genoeg services die simpelweg niet werken zonder een eigen /tmp of group. Dat is een voordeel van systemd, je kunt die services sandboxen (of niet).

Het voordeel is juist dat het heel dicht op de kernel zit, en vrijwel daar ook alles van gebruikt. Ik vind run0 bijvoorbeeld ook prima i.p.v. sudo.

Vind je het niets? Prima toch, genoeg alternatieven. Alleen snap ik wel dat Linux-developers geen zin hebben om alles te gaan ondersteunen. Je mag ook op Xorg blijven, maar niet zeuren als dan developers ermee stoppen.

Het was een voorbeeld. Ik kan gemakkelijk nog andere voorbeelden vinden maar mijn punt was dat het allang niet meer is wat eerder verkondigd werd.

Heeft een pid 1 supervisor met gestandaardiseerde service file format de voorkeur? Natuurlijk. Heeft een monolithisch systeem voor everything and the kitchen sink de voorkeur? Nee beslist niet, het is kwetsbaarder en er zijn betere tools dan de middelmatige kwaliteit van veel van de systemd onderdelen.

En voor mijn servers waar de hardware vrijwel niet wijzigt voegt al die extra functionaliteit weinig toe. Niet voor het booten, een beetje server is sowieso al minuten bezig. Niet voor het netwerk want dat stel je ook maar 1 keer in want je hopt niet van het ene wifi netwerk naar het andere en zo kan ik nog even door gaan. Voor een laptop ligt dat wel anders maar dan is een modulaire opbouw nog steeds te prefereren boven een monolithisch systeem.

[Merik]

gambieter schreef op zondag 31 mei 2026 @ 17:31:
@Merik . Welke distro zou Harry Jekkers kiezen? Raampies, kan je lekker uit kijken

Goede vraag... de militaire krachten zullen wel op Kaki Linux zitten

[ Voor 3% gewijzigd door Merik op 01-06-2026 11:38 ]

[RobertMe]

RobertMe schreef op donderdag 28 mei 2026 @ 19:37:
He bah. Ik dacht eindelijk een opvolger gevonden te hebben voor mijn antieke ("Windows" / Atom based) Asus Transformer tablet (met kickstand en toetsenbord). Zonder dan de hoofdprijs te betalen voor een Surface.

Tijd terug tegen de, wat oudere, Xiaomi Pad 6S Pro aangelopen. "Geen ingebouwde kickstand", maar wel een toetsenbord cover met kickstand. Bij PostmarketOS staat die ook vermeld incl een hele riedel "Works" en zelfs een vermelding van iemand die hem als daily driver / "desktop" gebruikt. Dat schept vertrouwen.
Voordat ik de knoop definitief doorhak toch maar even de pagina lezen... Blijkt er een locked bootloader op te zitten. Unlocken kan, maar is een dagelijkse loterij?! Je moet in de Xiaomi Community app een unlock aanvragen. Maar, je account moet een bepaalde leeftijd hebben (de originele uitleg waar PostmarketOS naar verwijst stelt 30 dagen, wat andere zoekresultaten suggereren "3 tot 7 dagen"). En ze geven maar X unlocks per dag weg (per model? Over hun gehele product lineup?). Met een "reset" elke dag om 00:00+08:00. En er gaat ook wat tijd (72 uur?) over de aanvraag heen. Ergo: je moet dan maar elke dag om 7u "onze tijd" een unlock aanvraag doen en hopen op het beste? En per account maximaal 1 unlock per jaar.
Dat zijn dus wel heel veel rare hoepels waar je doorheen moet springen voordat je een apparaat dat je 100% koopt ook 100% mag gebruiken.... Waarbij ik uiteraard het liefst het ding uberhaupt niet hoef te registreren. Uit de doos halen en flashen maar. Wordt dan wel een leuke use case om mijn recent ontdekte DuckDuckGo anonieme email-forwarding service te testen. Gewoon een account aanmaken op naam van Pietje Puck met zo'n willekeurig @duck.com mailadres dat dan forward naar mijn echte adres.

Edit:
Op die Asus Transformer heb in nu dan al een aantal jaren Arch met KDE Plasma draaien. Werkt okay-ish. Maar de specs zijn uberhaupt gewoon crap. Linux werkt in ieder geval wel beter dan Windows. Maar het is gewoon zwakke hardware.

Begin rant :p:
De Xiaomi Pad 6S Pro nu een klein weekje in mijn bezit. De grootste ergernis is..., dat de bootloader unlock alleen aangevraagd kan worden met een Xiaomi account van minimaal 30 dagen oud. "Gelukkig" had ik zoiets al voorbij zien komen (maar ook soms als 7 dagen) dus mijn account is al een weekje ouder.

Maar qua hardware echt een prima ding. Leuke grap is dat ik een 8K video file heb die mijn laptop niet kan afspelen omdat hardware decoding maar tot 6K gaat en software decoding natuurlijk veel te traag is (AMD CPU / APU? in laptop van 2022 meen ik). Mijn wat nieuwere PC met Intel i5-13500 doet wel 8K hardware decoding op de iGPU maar stottert. Een AMD GPU erin doet het wel, maar die staat dan ook flink te blazen. Deze tablet met een 3, 4 jaar oude Qualcomm Snapdragon 8 gen 2 + Adreno 740? 0 problemen
Voor de rest... Het zuigt. En dan vooral Firefox. Met het Xiaomi toetsenbord ("case") eraan... 0,0 sneltoetsen zijn geïmplementeerd: Ctrl + T voor een nieuwe tab? Nope; Ctrl + Tab voor tab wisselen? Nope; Etc etc. Ook een leuke: met de cursor op knoppen gaan staan, en de knop ligt op, op de touchpad tappen of klikken? De knop "knippert" maar actie wordt niet altijd uitgevoerd. Klikken in pagina's werkt weer wel altijd.
Gisteren eens de tablet aangesloten op mijn monitor (die zelf weer een DisplayPort daisy chain heeft naar nog een scherm). Onverwacht geven beide beeld, ik meen gelezen te hebben dat er maar ondersteuning is voor 2 schermen, maar 3 werken dus. Tablet scherm kan niet uit en enige optie is beeld dupliceren. So be it. Vervolgens de audio uitgang instellen? Niet mogelijk (op het "eerste" scherm heb ik aux ingestoken naar speakers, maar de tablet stuurt audio naar het "tweede" scherm. Steek ik USB-C oordopjes in het eerste scherm werken die weer wel want natuurlijk weer een losse DAC / output). Tweede scherm fysiek uitgetrokken (de daisy chain) begint het beeld te stotteren . Opgelost met een reboot, maar wel vaag. Aanpassen scherm configuratie kan dan ook niet (er wordt wel gevraagd of je wilt mirrorren, wat je kunt negeren / annuleren, maar een actieve mirror kun je niet opheffen).
En ook leuk, Firefox... bij de mirror verschijnt de cursor alleen op het tablet scherm en niet op de extra schermen Andere apps, launcher, ... staat de cursor gewoon op alle schermen.

TL;DR dus: kan niet wachten tot Linux er op kan.
Waarbij ik gisteren zag dat diegene die met de port bezig is (PR heeft gemaakt ervoor) ook nog vanalles vam sensoren en opladen heeft gefixt (licht sensor werkte niet en denk nu wel. En de Xiaomi Surge Charger? werkte niet op "volle snelheid" en nu wel).

[synoniem]

Dacht je dat wat systemd betreft wel zo'n beetje klaar zou zijn na alle eerdere discutabele toevoegingen. Maar nee het blijft groeien release notes systemd 261. Het lijkt wel het toevoegen van nieuwe features een doel op zichzelf geworden is in plaats van de kwaliteit van het bestaande te verbeteren.

[vanaalten]

synoniem schreef op zondag 21 juni 2026 @ 17:28:
Dacht je dat wat systemd betreft wel zo'n beetje klaar zou zijn na alle eerdere discutabele toevoegingen. Maar nee het blijft groeien release notes systemd 261. Het lijkt wel het toevoegen van nieuwe features een doel op zichzelf geworden is in plaats van de kwaliteit van het bestaande te verbeteren.

Mja, ik ben zelf nog steeds geen fan van systemd - als je incidenteel bezig bent met services checken, herstarten enzo, dan blijft bij mij niet hangen welke commando's ik precies moet geven. Telkens weer even google gebruiken en je komt er wel, maar voor incidentele gebruikers vond ik het oude init systeem een stuk doorzichtiger. En ja, gezien dat systemd een hoop fans heeft zal het vast wel veel goed doen.

Maar ben het wel met je eens, het blijft uitbreiden en een alles-in-1-oplossing worden. Dat gaat denk ik wel in tegen de filosofie van 'doe 1 ding en doe dat heel goed'.

[TobyW]

Ik heb net een update van mij grote PC van Kubuntu 24.04 naar 26.04 gedaan. De hoofdreden was dat ik dan een remote desktop verbinding met de lopende sessie kan maken i.p.v. in een aparte sessie gezet te worden. Maar wat blijkt, KRDP gebruikt alleen H.264 als codec, maar KRDC/libfreerdp3 is onder Ubuntu zonder H.264 gecompileerd. Claude stelde op twee systemen twee verschillende oplossingen voor: op de desktop het gebruik van de flatpak versie (die ook niet werkte), op mijn laptop het compileren van de lib met H.264 support. Het laatste werkte (na het patchen van een bestandje om H.264 altijd voorrang te geven) en nu kunnen eindelijk beide Linux machines via RDP met elkaar praten, maar ook met Windows, en ook vanuit macOS zijn ze op die manier te gebruiken.

[Sjah]

Feest, voor mij, statcounter geeft NL qua Linux-aandeel wel 6.7 procent. Sorry maar dat vind ik substantieel.

[ Voor 6% gewijzigd door Sjah op 08-07-2026 17:01 ]

[L0g0ff]

Leuke discussies over het snap concept onder het nieuws item nieuws: Tuxedo OS verruilt Ubuntu voor Debian vanwege Snap en AI-koers van Ca...

Must read als je het mij vraagt

[afterburn]

Hero of Time schreef op zondag 31 mei 2026 @ 15:06:
[...]

Als iets populair genoeg is, zou dat ook extra maintainers moeten aantrekken. Nu is het net alsof een groot bedrijf een startup overneemt en er helemaal niks meer overblijft van de startup zelf of de gedachtegoed. Udev bestond al lang voor systemd. Wat heeft systemd nou echt toegevoegd aan udev wat functioneel ontbrak en broodnodig was, wat ze niet al zelf konden doen?


[...]

bash lijkt me redlijk populair, en dat is al 30 jaar ofzo een one-man show. En zo zijn er talloze voorbeelden te noemen. Als het niet nieuw, hip of sexy is, is het voor veel projecten lastig tot onmogelijk om contributors te krijgen

[afterburn]

synoniem schreef op zondag 31 mei 2026 @ 18:49:
Ik sluit me aan bij @Hero of Time dat systemd als init systeem goed bruikbaar is. Maar het verworden tot 1 grote monolithisch systeem voor van alles en nog wat, is totaal niet nodig en zelfs onwenselijk.

Systemd is niet monolitisch. Het is een verzameling van losse programmas met een specifiek doel die onafhankelijk van elkaar gebruikt kunnen worden binnen 1 project. Vergelijkbaar in die zin met 'coreutils'.

Een distro die er voor zou willen kiezen om enkel systemd te gebruiken als init systeem en de rest niet, kan dit. En dan staat de rest van de programmas niet eens op je systeem.

Als jij cron wil gebruiken ipv systemd.timers, dan kan dit.
Als jij naar text files onder /var/log wil loggen ipv journald, dan kan dit.


Het is echt klinkklare onzin dat systemd een monolitisch programma is waarbij alle functionaliteit je door de strot gedrukt krijgt. En we zouden nu eens moeten ophouden om die onzin te verspreiden, want het is gewoon niet waar.

Als je dan toch ergens wilt klagen, klaag dan bij je distro en vraag ze waarom ze niet minder gebruiken. Of je de optie geven om dingen op de klassieke manier te doen.

[synoniem]

afterburn schreef op vrijdag 10 juli 2026 @ 16:26:
[...]

Systemd is niet monolitisch. Het is een verzameling van losse programmas met een specifiek doel die onafhankelijk van elkaar gebruikt kunnen worden binnen 1 project. Vergelijkbaar in die zin met 'coreutils'.

Een distro die er voor zou willen kiezen om enkel systemd te gebruiken als init systeem en de rest niet, kan dit. En dan staat de rest van de programmas niet eens op je systeem.

Als jij cron wil gebruiken ipv systemd.timers, dan kan dit.
Als jij naar text files onder /var/log wil loggen ipv journald, dan kan dit.


Het is echt klinkklare onzin dat systemd een monolitisch programma is waarbij alle functionaliteit je door de strot gedrukt krijgt. En we zouden nu eens moeten ophouden om die onzin te verspreiden, want het is gewoon niet waar.

Als je dan toch ergens wilt klagen, klaag dan bij je distro en vraag ze waarom ze niet minder gebruiken. Of je de optie geven om dingen op de klassieke manier te doen.

Over flauwekul gesproken systemd wordt als innig verknoopte modules aangeleverd en de distromaker moet er maar een hakbijl in zetten en dan hopen dat er geen onderlinge afhankelijken zijn als je een module achterwege laat?

Het bekende verschil tussen theorie en praktijk.

[Hero of Time]

afterburn schreef op vrijdag 10 juli 2026 @ 16:26:
[...]

Systemd is niet monolitisch. Het is een verzameling van losse programmas met een specifiek doel die onafhankelijk van elkaar gebruikt kunnen worden binnen 1 project. Vergelijkbaar in die zin met 'coreutils'.

Je kan niet de andere delen gebruiken zonder systemd. Wil je het NTP gedeelte gebruiken? Systemd is vereist. DNS resolving? Systemd moet er zijn. En zo met al het andere wat het biedt, alles heeft 1 grote harde afhankelijkheid aan systemd. Dat noem ik niet onafhankelijk. Wel modulair op de harde basis vereisten.

Een distro die er voor zou willen kiezen om enkel systemd te gebruiken als init systeem en de rest niet, kan dit. En dan staat de rest van de programmas niet eens op je systeem.

Als jij cron wil gebruiken ipv systemd.timers, dan kan dit.

Je kan ook beide tegelijk gebruiken. Lekker overzichtelijk natuurlijk.... maar het is mogelijk.

Als jij naar text files onder /var/log wil loggen ipv journald, dan kan dit.

Nou..... je kan wel rsyslog e.d. installeren, maar je hebt geen enkele optie om journald de nek om te draaien en eraf te trappen. Dit zit juist zo enorm verweven in systemd dat je geen enkele keus hebt. En als je journal nogal wat historie heeft, wordt systemd ook tering traag. Als ik op m'n Pi de status van Domoticz opvraag, duurt dat gerust een minuut. Omdat het journal 3 GB is en het blijkbaar niet in staat is om alleen de laatste 5 regels voor een unit op te halen in 15 ms. Ik heb er ook rsyslog op staan om juist alleen de logs van Domoticz te krijgen die wél snel te lezen zijn. Maar ondertussen heb ik de logs dus wel dubbel.

Het is echt klinkklare onzin dat systemd een monolitisch programma is waarbij alle functionaliteit je door de strot gedrukt krijgt. En we zouden nu eens moeten ophouden om die onzin te verspreiden, want het is gewoon niet waar.

Puur het init systeem niet nee, maar het pusht wel erg hard om de overige modules ook te hebben. Die druk lijkt net op het panische gedrag van MS om allerlei shit door je strot te duwen waar je niet op zit te wachten. Het beïnvloed deels je keuzevrijheid door het gedrag.

Als je dan toch ergens wilt klagen, klaag dan bij je distro en vraag ze waarom ze niet minder gebruiken. Of je de optie geven om dingen op de klassieke manier te doen.

Distro's krijgen niet altijd een keus. Gnome bijvoorbeeld wil het heel graag. Bied de distro Gnome aan als DE, dan zit die praktisch vast aan systemd. Zo simpel is het dus niet om maar eventjes een andere aan te bieden.

[HollowGamer]

Je kunt prima investeren in iets anders, net zoals je voor iets anders dan Wayland en Flatpaks kunt kiezen.

Als je perse geen systemd wilt, kan je die gewoon eruit slopen hoor. Je kunt het ook gewoon laten, en dan wat je niet wilt, overrulen.

Er zijn distros met openrc en ook die meer richting BSD gaan.. ik ben allang kwijt waar de hele discussie over gaat.

[Hero of Time]

Nieuwe week, dus updates toepassen op m'n werk laptop. Zie ik KDE applicaties een update krijgen van 6.6.5 naar 6.7.2. "Oh, dat is leuk, Plasma 6.7!" dacht ik. Nou... even shift+u in aptitude voor 'mark all upgradable' en gelijk de melding onderin voor 1 install en 17 removals. Eh... Dat was 1 nieuwe dependency en 17 packages die nog niet als update beschikbaar zijn en stuk gaan.

Dat was dus maar even de beschikbare KDE updates deselecteren en een week wachten.

[HollowGamer]

https://www.tuxedocompute...yBook-Pro-14-Gen10.tuxedo

Iemand toevallig hier ervaring mee? Ik ben opzoek naar een Linux laptop, die vrijwel geen firmware bug heeft. Mijn huidige Lenovo 'werkt', maar ik heb toch wel erg veel issues op Secureblue en freezes - wat vooral lijkt te komen door mijn Lenovo Optimus setup.

[L0g0ff]

HollowGamer schreef op maandag 13 juli 2026 @ 21:55:
https://www.tuxedocompute...yBook-Pro-14-Gen10.tuxedo

Iemand toevallig hier ervaring mee? Ik ben opzoek naar een Linux laptop, die vrijwel geen firmware bug heeft. Mijn huidige Lenovo 'werkt', maar ik heb toch wel erg veel issues op Secureblue en freezes - wat vooral lijkt te komen door mijn Lenovo Optimus setup.

Als ik nu een laptop zou kopen dan zou het een framework worden. Alles is vervangbaar.

[RobertMe]

Gisteren eindelijk PostmarketOS op mijn nieuwe / hiervoor gekochte Xiaomi Pad 6s Pro kunnen zetten, na door alle hoepels gesprongen te zijn voor de bootloader unlock (moet je aanvragen, daarvoor moet account 30 dagen oud zijn, vervolgens accepteren ze maar X aanvragen per dag, maar er is een script voor dat precies om middernacht China de aanvraag doet, ik had niet gezien dat je dat script daarna moet stoppen dus die had nog een half uur de server lopen spammen wat me weer een 10 dagen "ban" opleverde. Vervolgens ging het script wel goed (en zelf maar de loop er uit gehaald zodat die maar 1x de aanvraag deed), en dan moet je nog eens 72 uur wachten voordat je daadwerkelijk kunt unlocken).

Uiteraard kwam ik er woensdag, toen in kon unlocken, pas achter dat de pmOS build "niet bestaat". Is niet opgenomen in hun repo (wel een PR voor), en de maker ervan heeft wel op GitHub een repo die op basis van een GitHub action build, maar het image rolt alleen als artifact uit de build, artifacts worden maar 7 dagen bewaard, en de build faalt al sinds eind mei Zelf image builden viel wel mee. O.a. door niet volledig zijn build stappen over te nemen, error te krijgen op missende checksums in APKBUILD (pmOS is op Alpine gebaseerd), waarvoor die zelf simpel een pmbootstrap checksum <package> in de GitHub Action had staan. En de build error in zijn action was voor een nieuw package met missende checksums
Builden viel verder ruim mee, 20 minuten of zo dat PC er op stond te ratelen. Maar hij build ook alleen wat niet in de repo zit. Maar dat houd in dit geval ook een near mainline kernel in (wat gewoon 7.1 is, nieuwer dan de meeste distro's is en zo actief wordt die fork dan ook bijgehouden).

Eerste observaties na een avondje gebruik zijn... twijfelachtig. Als het puur een experiment was was ik waarschijnlijk tevreden, alleen heb ik het hiervoor gekocht.
De toetsenbord + touchpad "cover" verliest continu (10 - 15 minuten max?) zijn verbinding waarna die weer even los gemaakt moet worden. Staat ook in pmOS wiki vermeld, maar puur "verliest soms verbinding", maar max 15 minuten is wel kort / vaak.
Battery drain lijkt vrij hoog (van 45% naar 36% over 8 uur in sleep / "met de klep dicht". 1% per uur dus. Onder Android kon ik 6 dagen incl gebruik, met deze drain zou die na ~5 dagen zonder gebruik leeg zijn).
Audio werkt niet. Zou volgens pmOS wiki wel moeten werken (en er zitten ook alsa ucm2 profielen in de build, maar ben er niet bekend mee verder dus moet hier even goed in duiken).
Aangesloten op mijn computerscherm met USB-C die een daisy chain naar een tweede scherm heeft werkt alleen het scherm waarop die is aangesloten, tweede wordt niet herkend. Onder Android herkende die beide (maar die kan alleen een mirror doen).
Toetsenbord en muis aangesloten op het computerscherm werken (/werkten?) helemaal niet. Ook USB-C oordopjes deden niks, noch direct aangesloten noch op USB-C downstream poort van het scherm. Later, na reboot, werkte oordopjes wel. Wellicht dus een dikke USB crash aangesloten op het scherm waardoor een reboot nodig is? Maar dan nog vermoed ik dat USB naar het scherm niet werkt. Onder Android werkte USB, incl toetsenbord en muis, wel gewoon, en in pmOS wiki staat ook dat USB werkt.
Firefox geeft vage crash errors op pagina's met video.
MPV met vo=gpu-next (default) geeft volledig flets beeld (als in: bij windowed mpv wordt het hele beeld flets, ook buiten mpv). Met vo=gpu werkt het wel goed. hwdec=v4l2m2m-copy werkt in ieder geval waardoor video hardware decoding werkt.
Seeken in MPV is traaaag. Beeld blijft 1 of 2 sec stil staan. Ook als die paar minuten vooruit gebuffered heeft. En starten afspelen is ook instant, dus buffer vullen is ook geen issue.
Het scherm zelf heeft afgeronde hoeken. Dus daar vallen pixels weg . Het kruisje om een venster te sluiten staat maar net in beeld bv.

Edit:
Dit is overigens met Plasma ("desktop", niet mobile). En an zich werkt het dus gewoon goed. Start op zonder gedoe. Wifi werkt. Bluetooth zou moeten werken (schuifje stond in ieder geval aan en neem aan dat de adapter dan ook herkend werd). Uberhaupt komt dus beeld uit het scherm . Toetsenbord + touchpad cover werkt kinda (maar daarvoor draait extra software, daarvoor is een key-exchange nodig? Terwijl het een fysieke verbinding is dus je zou denken dat het niet encrypted is want er is al een fysieke verbinding).
Ik heb in de afgelopen ~20 jaar toch wel meerdere systemen gehad waarbij het meer moeite kostte om de boel aan de praat te krijgen. Maar in dit geval dus al opgelost door anderen Zoals dan het al bestaande tooltje dat de toetsenbord cover laat werken.

Fingerprint scanner werkt bv weer niet, maar die vind ik niet nodig (nice to have). En dat staat ook vermeld in de pmOS wiki dat die niet werkt. Net zoals NFC, dat er blijkbaar op zit Of een stylus die niet werkt (ook niet gekoch en geen behoefte voor).

[ Voor 11% gewijzigd door RobertMe op 17-07-2026 10:09 ]

[synoniem]

Zou het kunnen dat in de wiki er uit gegaan wordt van de mobile versie en dat deze het beter doet?

[RobertMe]

synoniem schreef op vrijdag 17 juli 2026 @ 10:20:
Zou het kunnen dat in de wiki er uit gegaan wordt van de mobile versie en dat deze het beter doet?

Naar mijn idee gaat het puur om hardware support ja/nee. Met zo nu en dan ook een specifieke notitie, zoals bij Bluetooth "werkt wel met systemd maar niet met openrc. Systemd is de default".

Zie https://wiki.postmarketos...S_Pro_12.4_(xiaomi-sheng) en dan de tabel bij "Component status table".

[L0g0ff]

RobertMe schreef op vrijdag 17 juli 2026 @ 10:02:
Gisteren eindelijk PostmarketOS op mijn nieuwe / hiervoor gekochte Xiaomi Pad 6s Pro kunnen zetten, na door alle hoepels gesprongen te zijn voor de bootloader unlock (moet je aanvragen, daarvoor moet account 30 dagen oud zijn, vervolgens accepteren ze maar X aanvragen per dag, maar er is een script voor dat precies om middernacht China de aanvraag doet, ik had niet gezien dat je dat script daarna moet stoppen dus die had nog een half uur de server lopen spammen wat me weer een 10 dagen "ban" opleverde. Vervolgens ging het script wel goed (en zelf maar de loop er uit gehaald zodat die maar 1x de aanvraag deed), en dan moet je nog eens 72 uur wachten voordat je daadwerkelijk kunt unlocken).

Uiteraard kwam ik er woensdag, toen in kon unlocken, pas achter dat de pmOS build "niet bestaat". Is niet opgenomen in hun repo (wel een PR voor), en de maker ervan heeft wel op GitHub een repo die op basis van een GitHub action build, maar het image rolt alleen als artifact uit de build, artifacts worden maar 7 dagen bewaard, en de build faalt al sinds eind mei Zelf image builden viel wel mee. O.a. door niet volledig zijn build stappen over te nemen, error te krijgen op missende checksums in APKBUILD (pmOS is op Alpine gebaseerd), waarvoor die zelf simpel een pmbootstrap checksum <package> in de GitHub Action had staan. En de build error in zijn action was voor een nieuw package met missende checksums
Builden viel verder ruim mee, 20 minuten of zo dat PC er op stond te ratelen. Maar hij build ook alleen wat niet in de repo zit. Maar dat houd in dit geval ook een near mainline kernel in (wat gewoon 7.1 is, nieuwer dan de meeste distro's is en zo actief wordt die fork dan ook bijgehouden).

Eerste observaties na een avondje gebruik zijn... twijfelachtig. Als het puur een experiment was was ik waarschijnlijk tevreden, alleen heb ik het hiervoor gekocht.
De toetsenbord + touchpad "cover" verliest continu (10 - 15 minuten max?) zijn verbinding waarna die weer even los gemaakt moet worden. Staat ook in pmOS wiki vermeld, maar puur "verliest soms verbinding", maar max 15 minuten is wel kort / vaak.
Battery drain lijkt vrij hoog (van 45% naar 36% over 8 uur in sleep / "met de klep dicht". 1% per uur dus. Onder Android kon ik 6 dagen incl gebruik, met deze drain zou die na ~5 dagen zonder gebruik leeg zijn).
Audio werkt niet. Zou volgens pmOS wiki wel moeten werken (en er zitten ook alsa ucm2 profielen in de build, maar ben er niet bekend mee verder dus moet hier even goed in duiken).
Aangesloten op mijn computerscherm met USB-C die een daisy chain naar een tweede scherm heeft werkt alleen het scherm waarop die is aangesloten, tweede wordt niet herkend. Onder Android herkende die beide (maar die kan alleen een mirror doen).
Toetsenbord en muis aangesloten op het computerscherm werken (/werkten?) helemaal niet. Ook USB-C oordopjes deden niks, noch direct aangesloten noch op USB-C downstream poort van het scherm. Later, na reboot, werkte oordopjes wel. Wellicht dus een dikke USB crash aangesloten op het scherm waardoor een reboot nodig is? Maar dan nog vermoed ik dat USB naar het scherm niet werkt. Onder Android werkte USB, incl toetsenbord en muis, wel gewoon, en in pmOS wiki staat ook dat USB werkt.
Firefox geeft vage crash errors op pagina's met video.
MPV met vo=gpu-next (default) geeft volledig flets beeld (als in: bij windowed mpv wordt het hele beeld flets, ook buiten mpv). Met vo=gpu werkt het wel goed. hwdec=v4l2m2m-copy werkt in ieder geval waardoor video hardware decoding werkt.
Seeken in MPV is traaaag. Beeld blijft 1 of 2 sec stil staan. Ook als die paar minuten vooruit gebuffered heeft. En starten afspelen is ook instant, dus buffer vullen is ook geen issue.
Het scherm zelf heeft afgeronde hoeken. Dus daar vallen pixels weg . Het kruisje om een venster te sluiten staat maar net in beeld bv.

Edit:
Dit is overigens met Plasma ("desktop", niet mobile). En an zich werkt het dus gewoon goed. Start op zonder gedoe. Wifi werkt. Bluetooth zou moeten werken (schuifje stond in ieder geval aan en neem aan dat de adapter dan ook herkend werd). Uberhaupt komt dus beeld uit het scherm . Toetsenbord + touchpad cover werkt kinda (maar daarvoor draait extra software, daarvoor is een key-exchange nodig? Terwijl het een fysieke verbinding is dus je zou denken dat het niet encrypted is want er is al een fysieke verbinding).
Ik heb in de afgelopen ~20 jaar toch wel meerdere systemen gehad waarbij het meer moeite kostte om de boel aan de praat te krijgen. Maar in dit geval dus al opgelost door anderen Zoals dan het al bestaande tooltje dat de toetsenbord cover laat werken.

Fingerprint scanner werkt bv weer niet, maar die vind ik niet nodig (nice to have). En dat staat ook vermeld in de pmOS wiki dat die niet werkt. Net zoals NFC, dat er blijkbaar op zit Of een stylus die niet werkt (ook niet gekoch en geen behoefte voor).

Dank voor deze uitgebreide review. Het zijn dankzij pioniers zoals jou dat de markt hopelijk ooit echt open gebroken wordt. Maar als ik het zo lees dan ben ik blij dat mijn zakelijke jolla een deze dagen op de deurmat valt en dat mijn fairphone met /e/OS een hele goede gebruikers ervaring geeft. Want inleveren op functionaliteit is 1. Maar wat er werkt moet wel stabiel zijn.
Als ik het zo lees zou het eigenlijk helemaal niet zo gek zijn een fork te trekken en 1 versie te maken voor 1 type toestel. Dan leen je gewoon alle code van upstream en dan injecteert je eigen patches en lever je een image die wel direct werkt zonder eerste door 10 hoepels te moeten springen.

[RobertMe]

L0g0ff schreef op vrijdag 17 juli 2026 @ 18:26:
[...]

Dank voor deze uitgebreide review. Het zijn dankzij pioniers zoals jou dat de markt hopelijk ooit echt open gebroken wordt.

Ik zou mijzelf nu, in deze, geen pionier (meer) noemen. Voornamelijk voor deze "oplossing" gegaan omdat die op basis van de pmOS wiki redelijk "out of the box" zou werken. Alleen bleek er vervolgens helemaal geen build (meer) te zijn. Werkt audio nu niet. En is dat "toetsenbord verliest soms verbinding" veel erger (/vaker) dan ik dacht.

Maar als ik het zo lees dan ben ik blij dat mijn zakelijke jolla een deze dagen op de deurmat valt en dat mijn fairphone met /e/OS een hele goede gebruikers ervaring geeft.

Tsja, Jolla.... Mijn eerste smartphone was een Nokia N9, daarna "de" Jolla (later werd dat de "Jolla J1", bij introductie verwachte ze nog geen tweede toestel? En daardoor dus " merknaam is toestelnaam"). Beiden waren voor mij prima toestellen. Maar de app gap werd maar groter en groter. Daarom uiteindelijk ook de overstap naar Android gemaakt.

En met de huidige stand van zaken, waarbij steeds meer Google Integrity gaat vereisen..., is het maar de vraag hoe lang je van /e/ kunt genieten op een Fairphone, laat staan de Android laag van Sailfish.

En ja, toen ik de N9 en Jolla had was ik wellicht nog een pionier. Voor de N9 bijgedragen aan een XBMC remote app, werd ontwikkeld door een Nokia medewerker (een Duitser, die daar werkte aan dat nooit uitgegeven nieuwe Linux based OS dat weer een soort van opvolger van MeeGo moest worden). Nadat die bij Nokia ontslagen was kon die bij Canonical aan de slag, voor het daar uiteindelijk weer mislukte Ubuntu Touch project. Waarbij we in die tijd nog steeds in een single repo werkte aan wat intussen "Kodimote" was. Hij voor Ubuntu Touch, ik voor Sailfish. Waarbij ik ook nog rondhing op de IRC van Jolla / Sailfish, maar nooit echt bijgedragen.

Als ik het zo lees zou het eigenlijk helemaal niet zo gek zijn een fork te trekken en 1 versie te maken voor 1 type toestel. Dan leen je gewoon alle code van upstream en dan injecteert je eigen patches en lever je een image die wel direct werkt zonder eerste door 10 hoepels te moeten springen.

Als ik je goed begrijp: daar wordt aan gewerkt. Er ligt bij pmOS een merge request voor device support voor de Pad 6s Pro op te nemen, als testing. Waarmee ik meen ik ook officiële builds komen en je dus ook alles kunt apk update && apk upgrade-n. Dat laatste kan nu semi ook. Iets van 5 pakketten of zo geeft die melding van dat ze niet in de repo staan.
En v.w.b. andere distro's. Er is een tweede persoon, die IIRC ook de kernel fork onderhoudt, die ook stappen en/of builds voor o.a. Arch Linux ARM, Ubuntu en meen ook Debian heeft. Waarbij naast de kernel fork ook andere zaken gedeeld worden tussen deze distro's. Dus het tooltje voor het toetsenbord te laten werken, recentelijk het (beter?) laten werken van de sensoren. Ondersteuning voor snelladen (MiPPS?) met de officiële lader (130W!, zelfs de Dell lader van mijn werk laptop is maar 120W). Er is naar mijn idee dus genoeg kennis en software die rond gaat tussen in ieder geval 2 personen die actief net deze tablet bezig zijn qua support.

---

Vandaag ook even mijn toetsenbord en muis gekoppeld via Bluetooth, en dat ging gewoon in een keer goed.

USB naar het scherm is raar. dmesg geeft alleen aan een nieuw apparaat te zien, maar als ik het goed begreep ziet die (dan pas) de poort als USB host (mogelijk omdat die automatisch van slave naar master gaat?). Vervolgens... niks. lsusb geeft ook maar twee regels, met IIRC dan dezelfde verwijzing, naar sm8550, het typenummer / naam van de Snapdragon 8 gen 2. Sluit ik vervolgens een ander USB apparaat aan (dus scherm uittrekken en bv de oordopjes aansluiten) gebeurt er ook helemaal niks meer.
Na een reboot wel ook eens het toetsenbord via USB-C aangesloten, en ook dat werkt prima.

Met beetje neuzen in video playback liep ik daar nog tegen fouten aan met 6K / 8K video Incl. kernel error. Zo uiteindelijk in een rabit hole beland waarbij 1. Er nog niet zo heel lang patches van Qualcomm zijn (maar nog niet geaccepteerd / merged) die hier hopelijk iets aan doen (het zou in ieder geval moeten helpen tegen dikke crashes (spontane volledige reboot) van Firefox op pagina's met veel video's, dat ik ook al gemerkt had); 2. Er nog meer patches zijn bij alleen al "linux-media" gezocht op de "sm8550"; 3. Qualcomm (tenzij anderen patches sturen vanaf @oss.qualcomm.com ) actief patches aandraagt bij Linux (daadwerkelijk kernel dan). Al dan niet primair gericht op hun nieuwe X1 / X2 processors (voor de laptops dus) waar in ieder geval dezelfde soort / familie "VPU" (ik neem aan Video Processing Unit ) in zit, genaamd "Iris". De error in dmesg die ik zag leide tot een link naar https://github.com/qualcomm-linux/kernel-topics voor een X1 systeem, die weer leide tot een Freedesktop bugreport, die uiteindelijk weer leide tot die patchset op de kernel mailing list. Waarbij in ieder geval de patchset meermaals verwijst naar sm8550 als "wijzigingen voor...".

Als ik het goed begreep is er in relatie met 7.2 ook veel veranderd waardoor die patchset niet is toe te passen op 7.1. Even afwachten dus op 7.2 final en tot dan die "near mainline" versie is bijgewerkt.

Edit:
Owja, wat ook funky is.... In ieder geval met pmOS is er een usb0 netwerk apparaat. Daarop draait, zeer zeker vanuit pmOS een DHCP server die alleen 172.16.46.2 uitgeeft. De usb0 interface zelf heeft 172.16.46.1/16. Geen idee waar die config vandaan komt. Maar het sloopt in ieder geval "mijn netwerk". Lees: ik heb een VLAN op 172.16.1.1/24, en dat kan ik niet bereiken door de route die voor 172.16.46.1/16, via usb0, wordt aangemaakt Maar ik ben er nog niet achter waar dat vandaan komt. Wel de hoe en wat van unudhcpd en dat die dan .46.1 en .46.2 gebruikt. Maar niet waarom die usb0 bestaat ("voor debugging doeleinden") en waarom die /16 is (als die /24 was zou ik het niet gemerkt hebben dat die er was).

[ Voor 6% gewijzigd door RobertMe op 17-07-2026 20:11 ]

[RobertMe]

Mooi, intussen audio aan de praat

Wellicht dat er niet heel goed wordt getest... Want als ik de oudere Alsa ucm files van hier pak doet die het wel. Uiteindelijk kwam ik achter een error in wireplumber dat het HiFi profiel / ... niet bestond. Wat dus zou betekenen dat, alsnog, iets mis gaat met die ucm config. Ondanks dat die wel "iets" doet, want als ik de symlink (vanuit de conf.d/sm8550/ map waar die de config "origineel" zoekt op basis van de daadwerkelijke hardware gegevens (sm8550 soc met ingebouwde audio)) verwijder dan zag die helemaal geen audio outputs meer. Vervolgens wireplumber met debug logging gestart en toen bleek die te falen op de cset "name='DISPLAY_PORT_RX_0 Audio Mixer MultiMedia4' 1". Verder nog niet naar gekeken, maar in ieder geval werkt het wel als ik terug ga naar de pre-DisplayPort commits (wat dat resulteert in een file van april 2025, wat verklaard waarom op de pmOS wiki staat "het werkt", want het heeft dus ook meer dan een jaar gewerkt).

En mogelijk dat het wél werkt als Wireplumber start met DisplayPort aangesloten? Dat heb ik op dit moment nog niet geprobeerd. Waarmee het niet "niet getest" is maar maar half getest

[himlims_]

RobertMe schreef op zaterdag 18 juli 2026 @ 11:08:
Mooi, intussen audio aan de praat

Wellicht dat er niet heel goed wordt getest... Want als ik de oudere Alsa ucm files van hier pak doet die het wel. Uiteindelijk kwam ik achter een error in wireplumber dat het HiFi profiel / ... niet bestond. Wat dus zou betekenen dat, alsnog, iets mis gaat met die ucm config. Ondanks dat die wel "iets" doet, want als ik de symlink (vanuit de conf.d/sm8550/ map waar die de config "origineel" zoekt op basis van de daadwerkelijke hardware gegevens (sm8550 soc met ingebouwde audio)) verwijder dan zag die helemaal geen audio outputs meer. Vervolgens wireplumber met debug logging gestart en toen bleek die te falen op de cset "name='DISPLAY_PORT_RX_0 Audio Mixer MultiMedia4' 1". Verder nog niet naar gekeken, maar in ieder geval werkt het wel als ik terug ga naar de pre-DisplayPort commits (wat dat resulteert in een file van april 2025, wat verklaard waarom op de pmOS wiki staat "het werkt", want het heeft dus ook meer dan een jaar gewerkt).

En mogelijk dat het wél werkt als Wireplumber start met DisplayPort aangesloten? Dat heb ik op dit moment nog niet geprobeerd. Waarmee het niet "niet getest" is maar maar half getest

Heb in verleden wat vervloekt als gaat om DP en HDMI - inmiddels snap ik dat bepaalde functies wel/niet werken aan de hand van “versie” kabel/aansluiting (DP fan sinds eerste 4e uur)

[RobertMe]

himlims_ schreef op zaterdag 18 juli 2026 @ 14:22:
[...]

Heb in verleden wat vervloekt als gaat om DP en HDMI - inmiddels snap ik dat bepaalde functies wel/niet werken aan de hand van “versie” kabel/aansluiting (DP fan sinds eerste 4e uur)

Nah, in dit geval is het puur de config file die niet geparsed kan worden als "dat nieuwe" er in staat. Onafhankelijk van of de USB-C kabel is aangesloten heb ik intussen ondervonden.

Alhoewel die volgens mij helemaal niks meer deed als ik de "geïnstalleerde" of nieuwste config file pakte, en ergens heb ik iets van een state file gezien. Misschien dat ik die dus had moeten weggooien tussendoor. Dat er een "cache" is en door een mismatch tussen config file en "cache" de boel helemaal niet meer geladen wordt.

[LievenD]

Is er hier iemand geïnteresseerd in zelf een Debian distro bouwen?

Ik doe het af en toe zelf met oude instructies, die mogelijks niet meer online staan (was een post van capink op www.ubuntuforums.org denk ik, maar het ubuntuforum is al een tijdje offline)

Ik kan de stappen hier delen (twee bash-scripts en een aantal hulpbestanden), maar uiteraard enkel indien er interesse is en misschien doe ik dat dan beter in een apart topic.

[Hero of Time]

Bedoel je daarmee zelf alle packages compileren of eerder een preseed maken met wat er effectief geïnstalleerd moet worden en eventuele configuratie? Want voor een preseed zou de Debian wiki ook het een en ander moeten hebben.

[LievenD]

Nee, eerder een .iso-bestand laten bouwen dat alle gewenste packages aan boord heeft.
Dat lijkt nogal op wat Debian Live doet, maar daarmee heb ik niet de beste ervaring, daarom gebruik ik liever de instructies van capink.

[Hero of Time]

Omdat er nogal een verschil is tussen een live omgeving en wat er bij installatie op je systeem komt.

[vanaalten]

LievenD schreef op maandag 20 juli 2026 @ 20:49:
Nee, eerder een .iso-bestand laten bouwen dat alle gewenste packages aan boord heeft.
Dat lijkt nogal op wat Debian Live doet, maar daarmee heb ik niet de beste ervaring, daarom gebruik ik liever de instructies van capink.

Dat is denk ik iets wat ik regelmatig doe:
Live iso downloaden, uitpakken, live omgeving aanpassen met wat extra packages en gebruikersdata, dan weer een live iso bouwen.

Mijn idee ervan is een live iso te hebben met de essentiële gegevens om een backup van Backblaze ofzo terug te halen.

[LievenD]

vanaalten schreef op maandag 20 juli 2026 @ 21:00:
[...]

Dat is denk ik iets wat ik regelmatig doe:
Live iso downloaden, uitpakken, live omgeving aanpassen met wat extra packages en gebruikersdata, dan weer een live iso bouwen.

Klopt, zoiets is het inderdaad, maar dan vertrekkende vanaf nul, niet vanaf een reeds bestaande iso.

Mijn idee ervan is een live iso te hebben met de essentiële gegevens om een backup van Backblaze ofzo terug te halen.

Sorry, maar wat is Backblaze?

Hero of Time schreef op maandag 20 juli 2026 @ 20:53:
Omdat er nogal een verschil is tussen een live omgeving en wat er bij installatie op je systeem komt.

Goh, het verschil is volgens mij relatief beperkt, behalve in sommige gevallen (vele taalpakketten in de live-omgeving waarvan er maar 1 taal op het uiteindelijke systeem terecht komt bijvoorbeeld).

[ Voor 27% gewijzigd door LievenD op 20-07-2026 23:11 ]

[franssie]

vanaalten schreef op maandag 20 juli 2026 @ 21:00:
[...]

Dat is denk ik iets wat ik regelmatig doe:
Live iso downloaden, uitpakken, live omgeving aanpassen met wat extra packages en gebruikersdata, dan weer een live iso bouwen.

Mijn idee ervan is een live iso te hebben met de essentiële gegevens om een backup van Backblaze ofzo terug te halen.

ok klinkt wel als een leuk project, is er een link naar hoe je dat doet?
En hoe zet je de updates op je live USB of maak je om de drie weken een nieuwe?

[RobertMe]

franssie schreef op maandag 20 juli 2026 @ 23:07:
[...]

ok klinkt wel als een leuk project, is er een link naar hoe je dat doet?
En hoe zet je de updates op je live USB of maak je om de drie weken een nieuwe?

Als je een echte live USB hebt is die natuurlijk read/write. Dus updaten is dan een kwestie van apt update && apt upgrade

* RobertMe heeft dat 15 jaar terug eens gedaan met Arch. Gewoon een USB stick formatten met ext4, Arch er naar installeren, MBR op de USB stick en gaan met die banaan.

Edit:
En natuurlijk met Debian net zo simpel tegenwoordig. Formateren met EFI (/FAT32) partitie + ext4 ernaast. Met debootstrap installeren naar de ext partitie, bootloader op de EFI partitie zetten en klaar.

[ Voor 16% gewijzigd door RobertMe op 20-07-2026 23:21 ]

[LievenD]

franssie schreef op maandag 20 juli 2026 @ 23:07:
ok klinkt wel als een leuk project, is er een link naar hoe je dat doet?

Dat was juist mijn vraag, of er mensen interesse hebben in een stappenplan voor het bouwen van een distro. Ik kan dit gerust hier op Tweakers zetten.

En hoe zet je de updates op je live USB of maak je om de drie weken een nieuwe?

Normaal gezien installeer je updates enkel op je installatie die op je harde schijf (SSD) staat. Eén uitzondering is een USB-stick met persistence. Die bewaart immers tussen reboots gedane aanpassingen, zoals bijvoorbeeld het installeren van updates. Alleen heb je daarvoor een vrij ruime USB-stick nodig, met 2 partities. Op de ene partitie staat je live-systeem (je uitgepakte iso-bestand) en op de andere alle data die bewaard wordt tussen reboots.