LNX Kroeg - Deel 2

[L0g0ff]

@Touchdomex Zelf draai ik mijn eigen image (KompassOS) based on Universal Blue waar bazzite ook een onderdeel van is. Probleem met rpm-ostree based immutable distro's is dat je eigenlijk zelf niet moet gaan zitten rommelen met rpm-ostree install.

Je gebruikt dan flatpak, brew of distrobox voor je niet geïntegreerde tooling. En verder moet je de fundering willen laten as-is. Zo niet dan kun je beter je eigen image bouwen en daar kun je dan helemaal in los gaan.

Toch is bazzite in de basis echt heel erg af. Na de install wordt automatisch je secure boot key gepushed en moet je 1 malig via je BIOS scherm het wachtwoord "universalblue" opgeven.

Als je dat niet doet (of deze stap overslaat) dan heb je idd allemaal driver issues. Want alles wat dan niet door fedora (zit standaard in je secure boot al) ondertekend is (en dus door het universal blue team) zegt dan krak bij het laden van de modprobe module. Omdat secure boot dit tegenhoud. Dat wil je ook.

Dit is eenvoudig te fixen door ujust --choose en dan even op zoek te gaan naar mokutil (ken even het command niet uit mijn hoofd). Die forceert bij de volgende boot dat je het wachtwoord kan ingeven en dan is het weer opgelost.

En precies wat @himlims_ zegt. Maak even een draadje aan of kijk anders even in 1 van de vele discord kanalen. Er zijn echt heel veel mensen die willen helpen. Mensen doen dit uit liefde voor FOSS en de tijd dat je echt naar 300 pagina's doorgestuurd wordt is wel een beetje verleden tijd gelukkig.

Daarnaast doe ik zelf veel met claude code op mijn systeem. Collega's van me met gemini-cli of codex van Openai. Je kunt die tooling installeren en dan heb je een hulpje op je eigen computer die je kunt vragen om even mee te kijken naar issue xyz.

Dan gebeurt (log) analyse door een vraag en hoef je alleen een beetje bij te sturen en logisch na te denken.

[HollowGamer]

@L0g0ff Waarom heb je een eigen image gebouwd? Vind het wel interessant, vind de ublue images soms wat bloated.

[Hero of Time]

L0g0ff schreef op dinsdag 28 april 2026 @ 15:39:
[...]

Je wil niet graag genoeg. Dan zoek je excuses. Zelf sabotage wordt dat ook wel genoemd. Je wilt je (aanname) 30+ jaar Windows ervaring inruilen in een weekend met Linux. Zo werkt dat niet helaas.

Ik denk niet dat @Touchdomex te weinig 'wil' heeft. Timberborn heeft volgens ProtonDB een platinum status, maar zodra je met mods gaat werken, ben je afhankelijk van de eventuele mod manager en de mods zelf. Dat geeft zo'n grote onzekerheid of de mods ook wel lekker werken in een Wine/Proton omgeving tov native Windows dat wanneer er gezeik is, de mod maker gegarandeerd gaat wijzen naar Linux want 'op mijn systeem (met Windows) werkt het vlekkeloos'.

Hoe vaak heb jij wel niet ergens tegenaan gelopen terwijl iemand anders tegen je zegt dat jij het probleem bent, want zij hebben nergens last van? En dan niet puur computertechnisch gezien.

@Touchdomex, dat er naar documentatie gewezen wordt is toch wel een tijdje terug hoor. Zolang er maar voldoende informatie en inzet is, is er geen probleem. Simpele one-liners en een summiere start, tja, dan vraag je er eigenlijk gewoon om. Dat weet je.

Bluetooth is een beetje hit en miss in Linux, omdat je heel erg afhankelijk bent van de chip die gebruikt wordt. De MediaTek die met m'n moederbord werd geleverd bijvoorbeeld was een drama. WiiU ProController deed het prima, evenals m'n Keychron K1Se toetsenbord en Logitech MX Ergo, maar een bluetooth 5 headset en het ging op z'n muil. Zo erg dat m'n toetsenbord niet meer werkte, 't systeem volledig uit moest en de stekker uit de voeding (of schakelaar even om) om het weer te laten werken. Reboot of power cycle was onvoldoende.
Nadat ik deze had vervangen voor een Intel AX210 kaartje was er niks meer aan de hand en werkt het vlekkeloos.

[L0g0ff]

HollowGamer schreef op dinsdag 28 april 2026 @ 19:55:
@L0g0ff Waarom heb je een eigen image gebouwd? Vind het wel interessant, vind de ublue images soms wat bloated.

Ik ben ooit begonnen met Bluefin (gnome) en daarna Aurora (KDE) omdat die standaard werkte met surface laptops. Fedora op een surface was echt een kriem. Vervolgens sloopte ze de surface support eruit. Dus dat ben ik toen zelf maar gaan doen. Verder wilde ik een image die ik kon uitrollen waar meteen echt alles zou werken. Voor mij maar ook voor collega's die dezelfde tooling gebruikte.

En dat is ook zo. ISO install, reboot, even wachten dat de laatste flatpaks zijn binnengehaald en je bent echt klaar met de devops basis.

Verder vind ik het gewoon leuk heb ik sinds mijn 16e altijd een eigen OS willen hebben (ben nu 42 ) of daaraan mee willen helpen. Ik doe redelijk veel met beheer (oa docker, ansible, git, pipelines, nutanix, windows server, citrix golden images, monitoring) en heb ik graag volledige controle over mijn OS. Met de bluebuild bouwstenen kun je dit echt heel erg eenvoudig realiseren.

[L0g0ff]

Hero of Time schreef op dinsdag 28 april 2026 @ 20:16:
[...]

Ik denk niet dat @Touchdomex te weinig 'wil' heeft. Timberborn heeft volgens ProtonDB een platinum status, maar zodra je met mods gaat werken, ben je afhankelijk van de eventuele mod manager en de mods zelf. Dat geeft zo'n grote onzekerheid of de mods ook wel lekker werken in een Wine/Proton omgeving tov native Windows dat wanneer er gezeik is, de mod maker gegarandeerd gaat wijzen naar Linux want 'op mijn systeem (met Windows) werkt het vlekkeloos'.

Hoe vaak heb jij wel niet ergens tegenaan gelopen terwijl iemand anders tegen je zegt dat jij het probleem bent, want zij hebben nergens last van? En dan niet puur computertechnisch gezien.

Vaak. En ik mijn eigen saboteurs nog vaker tegen. Niet alleen IT maar met alles wat ik doe.

Het ding is met het leven in general dat mensen wel zeggen dat ze iets willen maar het eigenlijk niet willen. Verhuizen, sporten, andere baan, voor jezelf beginnen, afvallen, cursussen volgen, klussen, altijd in rust voor de kinderen zorgen, voor je privacy opkomen, op tijd komen, een hobby, niet meer overwerken, andere helpen, openstaan voor kritiek, je mening durven geven, etc etc etc.

Alles wat je doet moet je concessies voor doen. Echt alles. En je moet bereid zijn om concessies te aanvaarden. Als je dat niet bereid ben dan wil je het niet graag genoeg. Dit is geen aanval. Dat is een spiegel.

In het geval van een overstap naar OS. Dit doet soms wel een beetje pijn. Je VR werkt niet meer, je virtualdj hardware apparatuur inclusief software geen support, je webcam kwaliteit, je docking station aansluitingen met issues en dan heb ik het nog niet eens over het politiek gesteggel wat je over je heen krijgt als je bedrijf ineens alleen nog maar compliant is wanneer je intune op je computer moet staan.

Omdat voor elkaar te krijgen moet je veel concessies doen en soms zelfs een beetje moeten knokken. Dit kost energie maar bovenal wilskracht dat je echt iets wilt.

[surcharge]

Over ai gesproken, ik heb nu de nieuwe intel oneapi drivers gedownload en met wat gepor is het gelukt om unsloth studio werkend te maken en lokaal modellen te draaien op mijn B580 met redelijke snelheid.

Weet iemand toevallig of er ook projecten zijn om LLM's hoe ik dit kan gebruiken voor code schrijven?

[L0g0ff]

surcharge schreef op dinsdag 28 april 2026 @ 21:20:
Over ai gesproken, ik heb nu de nieuwe intel oneapi drivers gedownload en met wat gepor is het gelukt om unsloth studio werkend te maken en lokaal modellen te draaien op mijn B580 met redelijke snelheid.

Weet iemand toevallig of er ook projecten zijn om LLM's hoe ik dit kan gebruiken voor code schrijven?

Met Roo Code kun je je eigen lokale LLM's koppelen.

[Hero of Time]

surcharge schreef op dinsdag 28 april 2026 @ 21:20:
Over ai gesproken, ik heb nu de nieuwe intel oneapi drivers gedownload en met wat gepor is het gelukt om unsloth studio werkend te maken en lokaal modellen te draaien op mijn B580 met redelijke snelheid.

Weet iemand toevallig of er ook projecten zijn om LLM's hoe ik dit kan gebruiken voor code schrijven?

Dat is niet echt een vraag die hier hoort. Je wilt technisch antwoord voor specifiek AI/LLMs. Er is nog geen apart forum voor, maar dit topic is iig zeker niet de plek hiervoor.

[surcharge]

Het hoeft niet met specifieke LLM's, gewoon een algemeen idee. Ben zelf wel actief in de ontwikkeling van linux in bredere zin, maar heb geen zin in een eindeloze discussie.

Ik ben al blij dat ik iets werkend heb lokaal, was nog wat werk om de setup werkend te krijgen.

[himlims_]

Hero of Time schreef op dinsdag 28 april 2026 @ 21:31:
[...]

Dat is niet echt een vraag die hier hoort. Je wilt technisch antwoord voor specifiek AI/LLMs. Er is nog geen apart forum voor, maar dit topic is iig zeker niet de plek hiervoor.

Er loopt (al lang) een draadje bij de crew voor nieuw fora: Een AI (thema) forum?

Gevoelsmatig kotst een groot gedeelte van community op alles met AI
Anderzijds is het wel een van de grootste innovaties op gebied van tech

Denk dat de crew/team ergens zoekt naar balans

Terug om-topic, die ollama is wel super toegankelijk, en easy peasy in gebruik, zeker met web ui,
catchy lijkt meer diepgang te bieden, en veel beter te optimaliseren of specialiseren. Hoe dat allemaal werkt ben ook nog aan uitvogelen.

Links of rechts om, de gpu maakt over uren

[ Voor 19% gewijzigd door himlims_ op 29-04-2026 01:38 ]

[surcharge]

Ja, ik kan de meeste grotere modellen helaas niet draaien, ik zit te overwegen om mijn oude A770 16 GB toe te voegen om dan tot 28 GB te kunnen gebruiken. Die gebruikt helaas een andere intel driver dus dat is misschien nog uitzoekwerk.

[Ghoulli]

Ik vermoed echter dat wanneer een topic ik erover ga openen hier of op andere plekken dat ik terug krijg geslingerd hier is de documentatie van 300 pagina's. Als je dit doorgenomen hebt dan weet je hoe je kan beginnen met het zoeken naar je fout. Kom daarna maar terug naar dit topic. Kijk en daar heb ik zeker bij het opstarten geen tijd meer voor om elk issue op die manier aan te gaan pakken. Het is leerzaam maar dat is op dit moment niet aan mij besteed. Dat is de verkeerde soort vrijheid.

@Touchdomex We zijn echt wel bereid om te helpen, zelfs zonder de documentatie naar je hoofd te smijten hoor .

[TobyW]

surcharge schreef op dinsdag 28 april 2026 @ 21:20:
Weet iemand toevallig of er ook projecten zijn om LLM's hoe ik dit kan gebruiken voor code schrijven?

OpenCode?

[himlims_]

surcharge schreef op dinsdag 28 april 2026 @ 21:20:
Over ai gesproken, ik heb nu de nieuwe intel oneapi drivers gedownload en met wat gepor is het gelukt om unsloth studio werkend te maken en lokaal modellen te draaien op mijn B580 met redelijke snelheid.

Weet iemand toevallig of er ook projecten zijn om LLM's hoe ik dit kan gebruiken voor code schrijven?

ik vind prachtig, gebruik veelal Gemini en sinds kort lokaal ollama geïnstalleerd voor lokaal gebruik.

AI wordt hier door vele hier uitgekotst. Jammer, soms begrijpelijk. Maar ik ben terughoudend geworden om dit op Tweakers te bespreken.

Projecten van me (tooltjes, plug-ins, scripts) zijn “review bombed” (negatief) nadat hier op Tweakers over gesproken heb.

Anyway; heb je beetje power-pc; kijk of zelf kunt draaien.

//edit; als ze hier nu eens opschieten met dat ai-fora

[ Voor 3% gewijzigd door himlims_ op 29-04-2026 17:33 ]

[Hero of Time]

Ik zei eerder al dat AI gepraat in dit topic off-topic is. Gelieve er dus niet mee door blijven gaan en claimen dat het 'on-topic' is. Heb geduld, er wordt aan gewerkt en tot die tijd moet je je even inhouden. Ik ga anders reacties snijden/trashen.

Het is nog steeds de LNX kroeg, niet een AI kroeg.

[gambieter]

[himlims_]

https://copy.fail/

wordt weer wat bakkies bijwerken

[gambieter]

himlims_ schreef op donderdag 30 april 2026 @ 13:22:
https://copy.fail/

wordt weer wat bakkies bijwerken

Oh shit, moet dat dan in elke Conda environment worden gedaan? Want die krijgen allemaal hun eigen Python (soms noodzaak voor verschillende versies etc).

[leander-s]

gambieter schreef op donderdag 30 april 2026 @ 14:04:
[...]

Oh shit, moet dat dan in elke Conda environment worden gedaan? Want die krijgen allemaal hun eigen Python (soms noodzaak voor verschillende versies etc).

Nee dat valt mee, het is een functie in de Linux-kernel die misbruikt wordt en gepatched moet worden met een update. Pythonkernels en Python zelf hebben voor deze exploit niets mee te maken.

[gambieter]

leander-s schreef op donderdag 30 april 2026 @ 14:28:
Nee dat valt mee, het is een functie in de Linux-kernel die misbruikt wordt en gepatched moet worden met een update. Pythonkernels en Python zelf hebben voor deze exploit niets mee te maken.

Ah, dank. Phew . Dat is dan nog wel te overzien!

[Hero of Time]

himlims_ schreef op donderdag 30 april 2026 @ 13:22:
https://copy.fail/

wordt weer wat bakkies bijwerken

Site is wel wat knudde imo. "Distributions we directly verified" zegt Ubuntu 24.04, Amazon Linux 2023, RHEL 10.1 en SUSE 16. Vervolgens in de animatie erboven staat er RHEL 14.3. Eh, whut? RHEL 11 is er nog niet eens en dan laten zien dat het in 14.3 werkt? Nogal een fail daar.

[L0g0ff]

himlims_ schreef op donderdag 30 april 2026 @ 13:22:
https://copy.fail/

wordt weer wat bakkies bijwerken

Soww, dat is een flinke. Gelukkig beheer ik alleen maar linux servers waar mensen zelf al sudo rechten hebben. Maar als je shared hosts heb dan is het wel overuren draaien nu.

[surcharge]

Had de crypto user api niet geactiveerd in mijn kernel, dus ik kreeg de exploit niet werkend. ff testen wat er gebeurt als ik dat wel doe.

[RobertMe]

L0g0ff schreef op donderdag 30 april 2026 @ 20:04:
[...]

Soww, dat is een flinke. Gelukkig beheer ik alleen maar linux servers waar mensen zelf al sudo rechten hebben. Maar als je shared hosts heb dan is het wel overuren draaien nu.

Het gaat natuurlijk niet alleen om wat de gebruikers bewust doen / "uitvreten". Je kunt ook "onbedoeld" software installeren die dit misbruikt. Zie in het meest extreme geval dus de xz backdoor dat (bijna) door meerdere distributies was uitgegeven. En nouja, ik wil best software reviewen die ik draai, maar ergens trek ik een lijn. En dat betekent dat ik niet elke package update door mijn distro ga lopen reviewen. Maar volgens mij is dit lek ook te misbruiken door, bv, Docker containers? Dus even in een experimentje een container draaien en hoppa, iemand neemt je systeem over doordat de container dit lek ge/misbruikt. Of dus weer via een dependency van software die je draait en vertrouwd dat via een supply chain aanval er ineens code die hier misbruik van maakt wordt uitgevoerd.

Dus zeker, als er gebruikers op jouw servers zitten die je niet vertrouwd, en die dus geen root toegang hebben, zou ik hier extra zenuwayvan worden. Maar dat je de gebruikers vertrouwd in dat ze niet bewust iets schadelijks doen betekent niet dat het niet per ongeluk alsnog kan gebeuren.

[Hero of Time]

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.

[L0g0ff]

RobertMe schreef op donderdag 30 april 2026 @ 20:25:
[...]

Het gaat natuurlijk niet alleen om wat de gebruikers bewust doen / "uitvreten". Je kunt ook "onbedoeld" software installeren die dit misbruikt. Zie in het meest extreme geval dus de xz backdoor dat (bijna) door meerdere distributies was uitgegeven. En nouja, ik wil best software reviewen die ik draai, maar ergens trek ik een lijn. En dat betekent dat ik niet elke package update door mijn distro ga lopen reviewen. Maar volgens mij is dit lek ook te misbruiken door, bv, Docker containers? Dus even in een experimentje een container draaien en hoppa, iemand neemt je systeem over doordat de container dit lek ge/misbruikt. Of dus weer via een dependency van software die je draait en vertrouwd dat via een supply chain aanval er ineens code die hier misbruik van maakt wordt uitgevoerd.

Dus zeker, als er gebruikers op jouw servers zitten die je niet vertrouwd, en die dus geen root toegang hebben, zou ik hier extra zenuwayvan worden. Maar dat je de gebruikers vertrouwd in dat ze niet bewust iets schadelijks doen betekent niet dat het niet per ongeluk alsnog kan gebeuren.

Ja true. Je zou bijna antivirus gaan overwegen ondertussen.

Hoe doen jullie dat? Ik heb op een aantal linux servers sentinelone draaien. Maar zeker niet allemaal.

[himlims_]

L0g0ff schreef op vrijdag 1 mei 2026 @ 01:02:
[...]

Ja true. Je zou bijna antivirus gaan overwegen ondertussen.

Hoe doen jullie dat? Ik heb op een aantal linux servers sentinelone draaien. Maar zeker niet allemaal.

ligt heel erg aan de situatie (doel/functie van bak, zakelijk of prive, type data en info)

- https://www.crowdsec.net/ (kan leuk zijn, soort zonealarm)
- elk+wazuh (elastic search + logstash + kibana + security monitoring + reporting en alerts)
- ik ben al snel van 'dagelijks' updaten; gaat t stuk maak daarna wel weer in orde
- salt is leuk voor beheer meerdere hosts
- anti-virus? nope
- deploy uit vertrouwde bronnen
- stukje hardening / owsap / zcert
- backup wat nodig is
- verwijder wat je niet nodig hebt
- vpn/ssh etc.

als je er echt voor gaat zitten, kan je een systeem zo gruwelijk dicht timmeren; succes! maar moet ook nog leuk blijven, en snel reageren etc.

alles afhankelijk van systeem, doel, functie, rol, wens, kosten etc.

maar virusscanner voor linux server, hooguit op de mail-server zodat client niet bekende rotzooi binnenhaalt

[gambieter]

Hero of Time schreef op donderdag 30 april 2026 @ 18:52:
Site is wel wat knudde imo. "Distributions we directly verified" zegt Ubuntu 24.04, Amazon Linux 2023, RHEL 10.1 en SUSE 16. Vervolgens in de animatie erboven staat er RHEL 14.3. Eh, whut? RHEL 11 is er nog niet eens en dan laten zien dat het in 14.3 werkt? Nogal een fail daar.

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

[Liegebeest]

L0g0ff schreef op donderdag 30 april 2026 @ 20:04:
[...] Maar als je shared hosts heb dan is het wel overuren draaien nu.

ik mag bidden dat de mensen die zulk werk doen gewoon Ansible en andere tools hebben om t gat te dichten.

[RobertMe]

Wel een raar verhaal, dat de distros nergens vanaf wisten.

Vinder heeft het issue gemeld bij het kernel security team; issue is opgelost; 30 dagen na oplossen heeft de vinder het gepubliceerd (wat een industrie standaard is, 30 dagen na oplossen publiceren).

Terwijl niemand de distros heeft ingelicht en zij nu halsoverkop nieuwe kernels moeten bakken en uitgeven (en gebruikers dus halsoverkop moeten updaten). Kernel security team wijst blijkbaar naar de vinder en dat die het bij de distros had moeten melden. Terwijl de algemene consensus toch lijkt te zijn dat het kernel security team hier veel beter toe in staat is / zou moeten zijn. Het zijn hun downstream "users" die ingelicht moeten worden waar zij veel betere (/makkelijkere) contacten mee moeten kunnen krijgen. Als in: zet als kernel security team "eenmalig" een afgesloten mailing list op met daarop de security gerelateerde personen van de (bekende) distros. En bij het fixen van een lek is het dan een kwestie van één mailtje de deur uit doen. Je kunt ook niet verwachten dat de vinder van een lek van elke distro gaat uitzoeken wat de procedure is inzake security issues is en die doorlopen. Want dat is én veel werk én grote kans dat distros worden overgeslagen. En dat zou dan ook bij elk gevonden lek uitgezocht moeten worden door de vinder.

[LEDfan]

Ik snap het ook niet goed. Als beheerder van servers moet je nu ook zelf gaan uitzoeken of je distro al patches heeft, wat soms met cloud servers (en cloud specifieke distros of images) lastig kan zijn. Als ze hadden gewacht tot de meeste distros nieuwe kernels hadden was het eigenlijk gewoon snel upgraden.
De mailing list die je beschrijft bestaat ook gewoon: https://oss-security.openwall.org/wiki/mailing-lists/distros , dus het had waarschijnlijk toch beter kunnen verlopen.

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