Hoofdmaintainer van sudo wil niet stoppen, maar zou wel graag meer geld willen

De belangrijkste maintainer van sudo zegt dat hij geen plannen heeft om de tool in de steek te laten, maar dat hij wel verwacht dat de Rust-versie in de toekomst belangrijker gaat worden. Todd Miller zegt dat tegen The Register nadat hij eerder om geld vroeg om sudo te blijven onderhouden.

Todd C. Miller, de hoofdmaintainer van sudo, ontkent dat hij wil stoppen met het project. The Register schreef eerder deze week over een oproep op Millers website. Daarin vraagt de ontwikkelaar naar sponsoren die hem financieel willen steunen bij het onderhoud. Die pagina staat overigens al een tijd online. Sinds februari 2014 krijgt Miller geen geld meer van Quest Software.

Miller zegt tegen The Register dat hij niet verwacht sudo voor eeuwig bij te kunnen blijven werken, maar dat hij ook nog niemand heeft om het stokje aan door te geven. Dat betekent dat hij in de praktijk ook de enige is die nog werkt aan de tool.

Dat is geen goede zaak; sudo, of superuser-do, is een van de belangrijkste commando's in Linux-terminals. Gebruikers kunnen er acties met adminrechten mee uitvoeren. Dat betekent dat eventueel misbruik flinke gevolgen kan hebben voor een geïnfecteerd systeem.

Dat laatste is een van de redenen dat Miller niet zomaar een willekeurige opvolger aan wil wijzen, zegt hij. Hij verwijst naar de incidenten rondom de malware in compressietool xz in 2024. Daarbij bleek dat een van de twee maintainers de veelgebruikte software misbruikte. Later werd duidelijk dat xz slechts door twee mensen werd onderhouden, die elkaar niet goed kenden. Miller wil zo'n situatie voorkomen.

Toch blijft Miller voorlopig sudo verder ontwikkelen, zegt hij. Dat is wel voornamelijk onderhoud. "Door mijn beperkte tijd ben ik voornamelijk bezig met bugfixes en het opschonen van de codebase in plaats van het toevoegen van nieuwe functies", zegt hij.

Miller ziet vooral toekomst in de Rust-versie van sudo, sudo-rs. Rust wordt gezien als een veiligere taal, specifiek op geheugengebied. Ubuntu wordt inmiddels standaard uitgebracht met sudo-rs aan boord.

sudo geef geld

Door Tijs Hofmans

Nieuwscoördinator

06-02-2026 • 07:54

163

Reacties (163)

Sorteer op:

Weergave:

Misschien nog een keer aankloppen bij NLNet foundation, er lopen (of liepen?) al een paar sponsored Sudo projecten zo te zien:

https://nlnet.nl/search/static.html?q=sudo&submit=Search
Bizar dat de hele linux community soms op één enkele ontwikkelaar hangt. Zou niet moeten maar helaas zie je het vaker. Zeker in vakgebied specifieke software of bedrijf. Vaak gemaakt/onderhouden dior één enkel persoon. Als die iets anders gaat doen of ‘onder de bus komt’ ben je de pineut.

Sinds corona zouden we beter moeten weten

[Reactie gewijzigd door fenrirs op 6 februari 2026 08:09]

Precies de reden dat ik het niet zo heb op opensource dingen, zeker niet op professioneel niveau. Als karel geen zin heeft om support te leveren of heeft ergens anders zin in (en dat is zijn goed recht) is 't beurt met de support en ontwikkeling.
Ik heb het niet zo (en echt totaal niet) met closed source. Ik bedoel niet Linux vs Microsoft, maar Open Source vs Closed Source. Als ze iets veranderen of droppen waar je afhankelijk van bent, kan je niets meer doen, terwijl je bij OpenSource kan forken of een consultant kan inhuren. Als ze opeens iets super duur maken, kan je enkel de portefeuille opentrekken, terwijl je het niet gebudgetteerd hebt. Als ze iets niet meer ondersteunen, heb je de keuze: investeren in een volledig ander product of gewoon stoppen. Er zijn zelfs soms online checks waar het product stopt met te werken vanaf een bepaald moment, zelfs als je interne migratie nog niet voltooid is.

Ook: je weet dat achter de meeste opensource projecten het niet Karel is, maar grote bedrijven zitten, zoals Redhat, Ubuntu, IBM, Microsoft, enzoverder? En dat de support meestal wordt gegeven door consultants, en niet door het bedrijf zelf (Microsoft geeft al quasi geen support meer en pusht al hun support naar resellers).

Ter info, ik beheer 2 bedrijven. Een werkt voornamelijk met Open Source (niet client side). Het andere (helaas) voornamelijk met Windows (server).

[Reactie gewijzigd door blinchik op 6 februari 2026 09:07]

Het heeft natuurlijk ook zijn voordelen maar de realiteit is dat dit soort initiatieven veelal starten vanuit een opensource gedachte, vrij en gratis te gebruiken. Hartstikke mooi maar de schoorsteen moet wel roken. En dan krijg je dit soort nieuwsberichten.

Ik wist persoonlijk echt niet dat dit een one man show was! Ik dacht dat het gewoon een standaard Linux commando was, net als ls of dir :P
Ook de standaard commando’s moeten door iemand onderhouden worden.
Inderdaad, en als je ergens niet voor betaald dan kan je nu eenmaal niet veel verwachten. Dus aan de klantenzijde: jij wil het gratis, dan is dit het gevolg.

En aan de developerzijde: jij biedt het gratis aan, sja dan kan je er geen huur mee betalen he
Ls en dir zijn ook geen standaard commando's, die komen uit (GNU) CoreUtils.

Uiteindelijk zal alles onderhouden moeten worden, ik vind het toch fijner als iemand anders het makkelijk kan over nemen of dat er alternatieve implicaties zijn (zoals voor CoreUtils) dan dat ik vast zit.
Daarom werken grote bedrijven vaak met een Escrow.
waar je dan helemaal niks mee hebt gewonnen boven de situatie waarin je al open source gebruikte. Je bent immers alsnog de orginele leverancier kwijt, en kunt dan omdat je van de escrow de sources krijgt er verder aan werken met eigen mensen. Daar was je al, als je direct een open project had gepakt, met als voordeel dat je in de open source situatie niet in je eentje staat, en de code niet met anderen mag delen, maar dat dat juist bevorderlijk is.
Prima, andere mensen, andere wensen.
Wij zitten in een redelijke niche markt. Als ik zie hoeveel commerciële software er draait waar de enige ontwikkelaar met pensioen is gegaan, word ik er ook niet blij van. CentOS 6, Windows Server 2003,... werkelijk om te huilen. Bugfixes komen zeer traag of niet. Nieuwe features al helemaal niet. Maar goed, er zit een commerciële firma achter, dus dan kan het allemaal wel (of we even 3 mil willen aftikken om de ontwikkeling opnieuw te doen). Voordeel met open source is dan nog dat je andere (zotten?) kan aanspreken om het over te nemen of dat er andere tools bestaan die relatief gemakkelijk kunnen worden ingepast.
En dat in reactie op een artikel van een opensource ontwikkelaar die graag beter betaald wil worden voor zijn werk? Professioneel betalen bedrijven bakken met geld voor closed source spul, waar ze verder geen enkele invloed op heeft. Zou het niet eens een idee zijn om degene die support moet leveren, beter te betalen?
Voor de meeste bedrijven zijn de kosten niet het probleem, maar wil men niet betalen voor iets waar de concurrent ook van kan profeteren.
Dit is wel iets waar je echt kritisch op moet zijn, maar binnen software ontwikkeling, of het nu dotnet is of javascript zit je er best vaak aan vast en is zo'n project van 1 developer de de facto standaard geworden.
En ik maar denken dat dit juist een van de voordelen is van opensourcesoftware, dat je inderdaad een consultant kunt inhuren (of het zelf doen) om het vlot te trekken mocht dat nodig zijn.
Je kan inderdaad zoveel idealen hebben maar uiteindelijk draait het toch om geld. Waarmee ik niet willen zeggen dat opensource altijd gratis moet zijn.
Dat je bij de broncode zegt echt helemaal niks over een eventueel bedrijfsvoering achter de software. Omgekeerd is het net zo waar... Er zijn genoeg projecten met gesloten broncode die niet commercieel zijn.
Volgens mij haal je twee begrippen door elkaar. Open source software kan ontwikkeld en uitgebracht (of gebruikt) worden door professionele bedrijven als Red Hat of Canonical en closed source software kan uitgebracht worden door een eenmanszaak. Bovendien kunnen grote closed source software bedrijven ook zomaar besluiten bepaalde software of producten die daar op draaien niet meer te ondersteunen.

Daarbij moet ik wel zeggen dat het mij verbaasd dat een dergelijk belangrijke functie bijgehouden wordt door 1 persoon. Daar heeft linux dan blijkbaar nog een slag te maken.
Gelukkig denken professionals daar anders over. De afgelopen decennia is dat scenario immers nooit voorgekomen en met de afhankelijk van bedrijven, zal dit alleen maar sneller opgelost worden.
Zoals zo vaak zie je weer een tunnelvisie, vaak uit onwetendheid.


Neem VMWare. Een prima closed-source product waar veel bedrijven dankbaar gebruik van maken. Of, maakten. Sinds het is overgenomen door Broadcom zijn de prijzen door het dak gegaan en klanten kunnen nu kiezen: Voor veel (ongebugetteerd) geld de licentie verlengen of voor veel (ongebudgetteerd) geld een dure migratie naar een ander platform maken. Ben je als klant ontevreden, jammer dan! Voor jouw 10 andere.

Neem World of Warcraft. Een leuke MMORPG, tenminste... ooit. Ooit heb ik vele uren in Azeroth doorgebracht, de ene quest na de andere. Toen kwamen de uitbreidingen en werd het snel minder. Zo erg zelfs dat mensen een illegale server zetten waar de uitbreidingen niet in zaten. Uiteindelijk is Blizzard gezwicht onder druk van de community en hebben ze WoW Classic uitgebracht. Ik was toen al lang gestopt met WoW en ben er nooit terug gekomen.


Als er met closed-source software iets gebeurd wat 'men' niet vind kunnen dan heb je pech gehad en moet je maar hopen dat de ontwikkelaar er iets mee doet. Hoe anders is het met open source?

Neem MySQL. Een prima database voor wie niet al te zware queries tegen veel te grote datasets wil loslaten. Voor menig website of kleine applicatie is het een prima gratis alternatief voor de dure Oracle of Microsoft databases. Toen werd het project overgenomen door Sun, je weet wel: eerst een hardware bouwer, later vooral bekend van Java. En Sun werd op zijn beurt weer overgenomen door Oracle. Zo kwam de gratis MySQL database in handen van ... Oracle. En daar kun je natuurlijk inmiddels een commerciële licentie voor aanschaffen. De oorspronkelijke ontwikkelaars vonden dat geen strak plan en hebben de database 'geforked' zoals het heet. Forken is feitelijk een kopie ervan maken en onder een andere naam verder. MariaDB was geboren. Kon hetzelfde als MySQL, was 100% compatible aan MySQL... het WAS feitelijk MySQL. Inmiddels zijn MySQL en MariaDB van nature wat verder uit elkaar gegroeid, maar in hoofdlijnen is het nog altijd hetzelfde product. Als jouw applicatie kan verbinden met MySQL, dan is er een grote kans dat hij ook prima werkt met MariaDB en vice versa. Alleen de product-specifieke features nodig hebt die slechts in een van beide zit zal het niet werken.


Daarbij komt ook dat een linux distributie uit heel veel projecten bestaat. Het sudo-project is slechts een heel klein radertje in het geheel en er zijn alternatieven. Mocht die ontwikkelaar de handdoek in de ring gooien, dan zullen de distributies kijken wat ze ermee aan moeten. En dan heb je best kans dat iemand het onderhoud op zich neemt, of er wordt een alternatief gekozen. Hoe dan ook, als klant van (bijvoorbeeld) Red Hat hoef jij je daar niet druk over te maken. Je neemt een supportlicentie af en Red Hat zorgt ervoor dat het product veilig blijft. Dus als de ontwikkelaar vandaag stopt, dan zijn Red Hat Enterprise Linux versies 8, 9 en 10 die daar last van zullen hebben. Red Hat heeft contractueel de verplichting om jouw systeem veilig te houden, dus als er een security-issue optreed in sudo, dan zal Red Hat zelf een of meerdere ontwikkelaars aansturen om. het probleem te fixen. Dat wordt dan (afhankelijk van de prio) waarschijnlijk niet direct in Red Hat gefixed, maar in de Fedora Project, zeg maar de upstream van Red Hat. En via CentOS-Stream komt de fix bij Red Hat terecht. En vanuit daar zakt die fix door naar Oracle Enterprise Linux (yup dat is een downstream van Red Hat Enterprise Linux), Rocky Linux, Alma Linux enzovoort. Natuurlijk zal hetzelfde gelden voor Canonnical die Ubuntu beheert. Ook die zal de kwetsbaarheid fixen en op die manier is ook de Debian-familie gedekt. En voor de volgende versie van het OS? Who knows! Een van de distributies kan de handschoen oppakken. Of ze zoeken een alternatief.


Neem ReiserFS, ooit het standaard filesystem in SuSe, maar ook te gebruiken bij andere distributies. Als Hans Reiser, de enige ontwikkelaar daarvan besluit om zijn vrouw af te slachten en daarvoor voor meerdere jaren de bak in draait, moet je toch iets. Gelukkig waren er genoeg alternatieven in de vorm van EXT3 / 4 of XFS voorhanden en stierf ReiserFS een stille dood. SuSe verklaarde overigens dat de keuze om over te stappen uit andere overwegingen werd gemaakt, zoals dat een volume met ReiserFS3 niet geupgrade kon worden naar ReiserFS4 zonder het compleet te formatteren.. maar toch.

Dus het is niet altijd koek-en-ei in Open source land. Net als bij Closed source bedrijven wordt er wel eens ruzie gemaakt of iemand er uit geschopt omdat men niet tevreden is met diens resultaten of gedrag op de werkvloer. Alleen bij Closed source bedrijven hoor je daar doorgaans niets van. Iemand mag even bij de manager komen en loopt even later stilletjes voor de laatste keer het pand uit. In Open source is zelfs dat open. Dus de ruzie tussen de ontwikkelaar van BTRFS en de ontwikkelaars van de Linux Kernel heeft een soap opgeleverd waar GTST bij verbleekt. En iedereen kon meegenieten. Het eindresultaat is dan ook toch subtiel anders; BTRFS mag dan wel niet meer standaard in de kernel zitten, maar je bent als gebruiker wel vrij om de btrfs-kernel-module te downloaden en te installeren.


Het gebeurt dus weleens dat een Open source project zonder ontwikkelaars komt te zitten. Maar juist door de open natuur van de software is er vaak snel een opvolger of alternatief gevonden. En daar merkt de eindgebruiker doorgaans helemaal niets van. Zeker niet gedurende de levensduur van de gebruikte distributie-versie. Maar als een closed-source bedrijf ermee stopt (of failliet gaat), dan heb je vaak een enorm probleem. Zelfs als Red Hat zelf om zou vallen komt de Open source community er wel bovenop. Microsoft en Oracle zullen in het gat springen om support te mogen leveren aan de voormalige klanten van Red Hat en de ontwikkelaars werken gewoon door aan hun projecten die tezamen weer in Fedora gebundeld worden. Er zal wel een financiële schok door de community gaan, maar ook daar komen ze wel overheen.
Ach, ms heeft ook geen zin om de bugs die ik meld op te lossen. Andere prios is dan het verhaal.
Lost MS überhaupt iets op of veroorzaakt het eerder steeds meer problemen?
goeie, als je kijkt naar de release notes van bijvoorbeeld OneDrive, dan is de enige regel die je kan vinden:

"We've resolved product issues to improve the reliability and performance of the OneDrive sync app."

Dus wat er nou precies aan issues is feixed? Geen idee.
Jij zegt "ik gebruik liever closed source dan open source vanwege dit soort dingen" en dan zegt iemand "maar de closed source projecten lossen de problemen ook niet op" waarna jij reageert dat je er geen "closed source vs open source van wil maken".
Je start een discussie maar je wilt niet tegengesproken worden door andere ervaringen?

Apple, Google, Microsoft, Adobe, Affinity, Mozilla, Unity, Unreal, Valve. Allemaal bedrijven met closed source systemen met duizenden bugs waar mensen last van hebben maar niet worden opgelost.
Hoe beschikbaar de source is maakt helemaal niets uit voor de prioriteiten die developers of managers hebben.
Nee ik wilde er geen ms vs whatever discussie van maken . Je leest selectief.
Dat statement kan je helaas oprekken tot 'de open source community'. Er zijn ook buiten Linux veelgebruikte programma's en bibliotheken die door één iemand - of zelfs niemand - wordt onderhouden.
Het gebeurt overal, ook bij niet open source spullen. Denk aan het overlijden van Robert Zale, meteen klaar met zijn creatie. Als Aandi Inston overlijdt, kan Quite ook meteen stoppen (bezoek z'n website zeker: je gaat echt terug naar de jaren 90 qua webbeleving, afschuwelijk).

Maar dit is wel een reden voor organisaties om voor een "stabiele" leverancier te kiezen boven open source (hobby) werk. Eentje waarvan ze er min of meer uit gaan, dat deze over 10-20-30 jaar ook nog bestaat. Er kleven gewoon teveel risico's aan het voortbestaan. Dat zou allemaal niet erg zijn, als het software landschap vol met concurrerende partijen zou zitten, maar eigenlijk is er voor een heel groot deel maar echt een enkele speler.
Het grote probleem met open source is gewoon de heel erg vampiristische houding van de commerciele software-industrie, die het consumeert zonder terug te geven.
En nu met LLMs wordt dat alleen maar erger, waar bedrijven een zeer slechte versie van een deel van een opensource-library uitgenereren in plaats van mee te ontwikkelen aan de open source-projecten waarvan gejat is.
Aan de andere kant werkt ook de FOSS wereld zelf niet altijd oplossingsgericht. Een beetje onenigheid en je krijgt vaak een fork, resources die samen veel beter werk kunnen verrichten worden ineens gesplitst, gebruikers moeten een keuze maken dus ook die geraken verdeeld.
forks zijn juist de kracht van opensource.

ik heb nog wel eens meegemaakt dat een fork uiteindelijk weer mergede, wat tot een fantastisch product kwam.

Waar forks nu meestal door ontstaan is dat er een bedrijf, of erger venture capitalist achter dat bedrijf opeens alles achter de commerciële paywall gooit, wat enorm kwaad bloed veroorzaakt. Daarom zie je nu mensen kijken naar alternatieven voor minio.

Never piss of the community.
En forks zijn helemaal niet altijd een opensourceding. Genoeg bedrijven waar een prominente ontwikkelaar opstapt en een eigen bedrijf opricht, omdat die het niet eens met de houding van diens werkgever, maar wel hetzelfde gedachtegoed achter de producten wilt voortzetten. Dat zou je ook kunnen zien als een soort fork.

[Reactie gewijzigd door TheVivaldi op 6 februari 2026 10:06]

Niet helemaal. Een fork begint als exacte kopie van het origineel. Een ontwikkelaar die een eigen bedrijf opricht moet alles vanaf scratch gaan schrijven, want als die source code van zijn oude werkgever meeneemt kan die hem aanklagen wegens copyrightschending/diefstal/bedrijfsspionage/weet-ik-veel.
Het ging me meer om het concept, niet om de exacte uitwerking. :)

Overigens hangt het er maar net vanaf of de broncode open of gesloten is. Jolla kon SailfishOS relatief makkelijk ontwikkelen, omdat MeeGo deels open source was. Daar konden de oorspronkelijke ontwikkelaars dus gewoon op voortborduren.

[Reactie gewijzigd door TheVivaldi op 6 februari 2026 13:58]

nee, als de voormalig medewerker forked, kan hij volstaan met het vermelden van.
oude code geniet dan nog de eer en glorie van jet origineel en de nieuwe mag de medewerker lekker aan zichzelf toeschrijven. Echter moet ook zijn wijzigingen op die code open source houden.

Bijvoorbeeld in de code van NextCloud worden nog steeds de copyrights van OwnCloud aangehaald.
NextCloud is een fork van OwnCloud omwille wat @TheVivaldi noemt.
Dat klopt als de originele code onder een andere licentie valt waarbij dit toegestaan is - niet alle open-source licenties staan wijzigingen maken toe (al kun je je dan vragen of de source wel "open" is). Maar ook de andere kant op, niet elke open-source licentie vereist dat aanpassingen ook open-source zijn (denk Apache License 2.0, MIT - een acknowledgement is genoeg). En als de code die je forked closed-source is dan kan je er over het algemeen wel vanuit gaan dat je behoorlijk in de problemen komt als je die source code meeneemt.

LibreOffice is trouwens ook een goed voorbeeld waarbij het wel mocht. Dat is geforked van OpenOffice.org dat op zijn beurt weer gerforked is van StarOffice.
Never piss of[sic] the community.
Zie Redis. Bye Redis, hallo Valkey als drop-in replacement.
Klopt en vaak nemen bedrijven zelden of nooit hun voorzorgen. Genoeg gezien dat een hele fabriek draait op een machine waarvan de software in handen is van een externe eenmanszaak. Busfactor = 1

Het kan trouwens ook anders, ooit bij een werkgever gewerkt dat software had afgenomen bij een Duitse developer, maar daar was wel de afspraak dat de source code moest worden overgedragen na zijn dood.
Dat gebeurt heel vaak. Ik werk zelf voor een bedrijf dat software ontwikkeld en ook wij geven de broncode aan een escrow dienst daar bepaalde klanten het recht hebben om bij failisement van de onderneming een kopie van die code te krijgen.
Aan de andere kant heb je ook weer mega corporaties die hun hele bestaansrecht dankzij open source hebben maar dan nauwelijks tijd of geld in de projecten steken. Denk bijvoorbeeld aan YouTube en Netflix die ffmpeg gebruiken. Een voorbeeld, volgens de ffmpeg maintainers had Google een bug gevonden met gebruik van AI in ffmpeg want het decodeerde een video bestand van een game uit 1995 niet goed en dan ook nog de bug report indienen zonder ook een fix te geven. Maar de bug word dan wel automatisch gepubliceerd over 90 dagen, wat eigenlijk een soort dreigement is. Dit gaat om Google die geld en mensen zat heeft om de bug zelf te fixen waarvan de dochter bedrijf YouTube flink gebruik maakt van ffmpeg. Wel gebruiken, wel bugs indienen met AI maar dan verwachten dat vrijwilligers het fixen.

[Reactie gewijzigd door Smash1231 op 6 februari 2026 10:12]

In veel bedrijven is dat vaak ook zo voor bepaalde cruciale onderdelen. En vaak ook door iemand die matig wordt gewaardeerd in salaris. Die dingen zijn zo technisch of fundamenteel dat de directe manager er zelf geen begrip van heeft, zelfs als de expert zegt hoe belangrijk het is, denkt de manager "het zal wel, ik hoor er niemand anders over, dus valt vast wel mee", niet realiserend dat de reden dat hij niets hoort is omdat de persoon al jaren zorgt voor een stabiel product. En dat het daardoor nooit opvalt, er zijn geen incidenten, geen frictie, het werkt "gewoon", dus niemand heeft het er over.

[Reactie gewijzigd door djwice op 6 februari 2026 15:26]

Inderdaad, ik weet nog niet zo zeker dat het beter zou zijn als bedrijven achter dit soort tooltjes zit. Zo’n lange termijn project past 9 van de 10 keer niet bij de bedrijfsvoering.
Aan de andere kant: er zijn ook developers die daardoor zo'n ego krijgen (omdat ze weten dat ze een unieke rol vervullen) en daarom met onrealistische (salaris) eisen komen. Dan geldt toch nog: niemand is onvervangbaar of onmisbaar en praktisch: niemand leeft oneindig. Iedereen stopt een keer met werken.
Klopt, value based payment is vaak maar een kant op en dat zelfde geldt voor loyaliteit.

Je kunt miljoenen besparen of zelf extra winst (letterlijk) binnen brengen, structureel, door een initiatief waar niet om gevraagd was en als dank krijg je een iPad mini waar je niet op zit te wachten.

[Reactie gewijzigd door djwice op 6 februari 2026 15:32]

Ja en nog meer bizar is dat alle bedrijven die het gebruiken inclusief overheden niet bijdragen.
Dan zou al het geld naar een handjevol bekende projecten gaan, zoals de kernel, LibreOffice, Mozilla, Apache en nog wat projecten waar een stichting achter zit. Geen enkel bedrijf gaat geld overmaken naar een privepersoon die een klein componentje als sudo onderhoudt.
Inderdaad, daarom zie je steeds meer open source projecten als sponsor van andere opensource projecten.
Een van de redenen dat je tot de dag van vandaag nog een verborgen optie hebt in Windows om Internet Explorer te gebruiken is omdat bedrijven er specifiek software voor hebben die door niemand meer onderhouden wordt.

Probleem is altijd tweezijdig, tijd en geld.

Bij Open Source zou je hopen dat er minimaal geld of tijd komt van bedrijven die het in hun commerciële producten verwerken.
Daarnaast is het vrijwilligerswerk, net zoals je vrijwilligers hebt die bijspringen via een voedselbank, bij festiviteiten, etc. Die vrijwilligers moeten wel skills hebben voor het bouwen van code wat de groep kleiner maakt. Die vrijwilligers bij source code moeten ook langdurig samenwerken als maintainers. Uiteraard kun je op basis van de Open Source zelf ook code schrijven en submitten zonder dat je een maintainer bent, de maintainer kan die code dan samenvoegen.
Niet alle opensourceontwikkelaars zijn vrijwilligers, en ook vrijwilligers bij de voedselbank, festiviteiten, etc. kunnen gewoon betaald worden (tot 150 euro per maand, als ik me niet vergis).
Ja, als er geld is voor een vrijwilligersvergoeding, en de organisatie die door de vrijwilligers ondersteunt wordt die kan en wil wil uitkeren zijn er mogelijkheden. Bijvoorbeeld ik ben vrijwilliger bij een stichting ten behoud van een monument waarin in de charter staat dat er geen vergoedingen worden uitgekeerd. Het enige wat ik krijg is een kopje koffie of thee als we samen komen voor een overleg. En voor mij is die vergoeding ook niet nodig, daar doe ik het ook niet voor.
Maar bij een andere organisatie weet ik dat ze mensen niet konden vinden om te assisteren met schoonmaak en 12,50 per ochtend uitkeren waardoor er toch voldoende animo kwam.
Precies. Ik ben eveneens vrijwilliger en ik hoef er ook geen vergoeding voor, maar ik wilde alleen aangeven dat het wel mogelijk is om een vergoeding te geven.
Nou dat besef is er echt wel alleen niet bij de mensen die over het geld gaan.

Hoe moeilijk bedrijven al niet doen over een donatie van 5 euro per maand...
Ondernemer hier en ik maak ook gebruik van open source. Naast mijn eigen bijdrages zo nu en dan aan OS projecten waar we mee werken doneer ik ook af en toe wel iets.

Maar bij meerdere projecten maandelijks kleine bedragen doneren doe ik ook niet. Hoewel ik het prima zou vinden 50-100 eu per maand daaraan te besteden heb ik vooral geen zin in de administratieve rompslomp ervan. Ook de keuze wie wel en wie niet vind ik lastig.

In plaats daarvan schaf ik dan weer vaker betaalde software van die ontwikkelaars aan, als die er is natuurlijk of een eenmalige donatie. Maar ik kan me echt prima voorstellen waarom andere bedrijven, net als ik, niet staan te wachten op die kleine donaties.
Begrijpbaar als je een eenmanszaak hebt maar als je al paar dozijn werknemers in dienst hebt is 'teveel gedoe' een beetje zwak.

Bedrijf in kwestie wilde trouwens niet eens 1 project ondersteunen.
Precies. Als eenmanszaak, begrijpelijk, maar als je een bedrijf ter grootte van IBM hebt, is het helemaal niet zo'n probleem om, zeg, 10 cruciale projecten van een kleine donatie te voorzien.
Eenmanszaak inderdaad (met één werknemer). Momenteel ligt alles van uitvoering tot administratie al bij mezelf en dan zit ik hier echt niet ook nog eens op te wachten.

Ik kan me prima voorstellen dat wanneer mijn onderneming groter zou zijn ik wel andere manieren hiervoor zou vinden. Maar het is ook een instelling die je moet hebben, ergens is het ieders goed recht om niets te willen doneren, het is immers opensource. Als je er dan ook niets over te klagen hebt heb ik er vrede mee. Maar andersom net zo goed: als je van mening bent dat iemand je iets verplicht is zit je fout en dan is een donatie een mogelijke manier om iemands tijd ervoor vrij te maken.
Open source projecten worden grotendeels helemaal niet gedraaid door bedrijven.

En wat is dit nu voor een houding : "Het is mij te weinig geld, dus ik wil het niet doneren"? Dan mag je ook meer geld overmaken als je dat makkelijker is.
Het is makkelijk om af te geven op anderen, toch?

Voor mij specifiek: ten eerste draag ik al van tijd tot tijd bij aan de open source projecten waar ik mee werk. In elk geval wanneer ze in dezelfde taal geschreven zijn als waar ik in werk. Ten tweede ben ik afnemer betaalde softwarepakketten die de mensen achter enkele van die open source projecten hebben uitgebracht. Ten derde heb ik al meerdere keren eenmalige donaties gedaan als die mogelijkheid er was en ik het OS pakket ook op (voor mij) voldoende waarde schatte. En ten vierde is er ook software die ikzelf open source released heb, waar ik overigens nog geen koffie voor heb gekregen in al die jaren.

Dus ja, met bovenstaande 4 zaken meegenomen neem ik inderdaad de houding aan om mezelf (eenmanszaak met 1 personeelslid) de administratieve rompslomp te besparen om kleine bedragen maandelijkse aan 10 projecten te doneren. Ik draag waarschijnlijk al meer bij dan 95% van de gebruikers.

/Edit: mocht ik je reactie nu iets te persoonlijk hebben opgevat en het meer een algemene opmerking was. Ook dan sta ik er als zowel gebruiker als bijdrager nog steeds begripvol in tegenover (kleine) bedrijven die de rompslomp liever vermijden.

Als open-source ontwikkelaar ben ik bewust ervan en accepteer ik dat het me geen euro op kan leveren. Anderzijds accepteer ik als gebruiker ook dat een andere ontwikkelaar me niets verplicht is. En in beide gevallen begrijp ik ook dat een vorm van betaling ervoor kan zorgen dat er meer moeite in zo'n project gestoken wordt.

Hoe je het ook draait of keert is er niemand fout, ondanks dat je in beide kampen mensen hebt die er wat anders van vinden. Het is ook echt niet veel eenvoudiger dan "iemand steekt zoveel tijd en moeite als hij zelf wilt in de ontwikkeling en onderhoud van iets zonder dat er enige vorm van onderhoud of doorontwikkeling verwacht mag worden van de gebruikers.".

[Reactie gewijzigd door joshua043 op 6 februari 2026 11:50]

Dat ligt vooral in de processen helaas. 5 euro per maand aan licentie kosten is vaak geen probleem maar 5 euro per maand doneren aan een persoon is vaak niet mogelijk.
We zouden een open source kwaliteitskeurmerk kunnen ontwikkelen, waarbij een van de vereisten is dat het beheer ervan toekomstbestendig is en dat het zelf enkel en alleen open source producten gebruikt die dat ook zijn. Zo ontstaat er vanzelf druk om dit goed te regelen, want dan gaan bedrijven ook sturen om enkel dit soort open source pakketten te gebruiken en kunnen er normen en audits worden ontwikkelen hieromheen.
Bullshit. Je betaalt niets dus je krijgt niets. Blijf met je corporate tengels af van de mooie dingen die vrijwilligers bouwen. En uiteindelijk is het gewoon zo dat als Bob er mee stopt, dan heeft het project geen onderhoud meer. Hetzelfde natuurlijk met bedrijven die gewoonweg stoppen, sluiten, failliet gaan, etc.


Je kunt bij redelijk wat opensource dingen al betalen voor support. Daarvoor hebben we o.a. Red Hat Enterprise Linux uitgevonden ;).
Ja ik snap je opmerking en wil de open source ontwikkeling ook niet remmen hiermee, maar als we met zijn allen op een verantwoordelijke manier software willen ontwikkelen, dan is het wel handig dat we het probleem onder ogen willen zien. Nu hebben we namelijk een hele berg software dat afhankelijk is van kritieke opensource tools waarvan de ontwikkeling niet geborgd is. Dit komt omdat de risico's van het gebruik van deze opensource software niet inzichtelijk zijn, m.a.w. je gaat er maar vanuit dat sudo of een populaire log library goed wordt onderhouden, maar eigenlijk heb je geen goede mogelijkheden om dat echt te checken.
Dat is weer heel licentie afhankelijk, als de licentie het toelaat commercieel ingezet te worden dan mag iemand met zijn corporate tengels doen wat hij wilt. En anders zou dat ook gelden voor jouw tengels en die van mij. Pas zodra iemand support gaat verwachten of andere dingen gaat eisen kun je de "je betaalt niets, dus je krijgt niets" kaart inzetten.
Dat is juist het probleem. Heel de OSS ecosysteem leunt op kleine projectjes van 1 persoon die gewoon lekker code wil kloppen. Die willen niet de overhead en stress van keurmerken, teammanagement en andere zaken die van het eindproduct afleiden, en waar geen salaris tegenover staat. Een groot deel van de OSS community haakt dan gewoon af.
Je kunt niet een beetje hobbyen en graag willen dat mensen je software gebruiken en daarnaast verwachten dat daar niet een verantwoordelijkheid tegenover staat.
Je kunt geen eisen stellen aan een hobbyist die zijn tijd gratis ter beschikking stelt en daar ook elk moment mee kan stoppen als jij gaat zeuren dat jij niet genoeg gratis werk van hem krijgt. Neem hem dan in dienst en betaal hem een salaris.
Ben het met je eens, maar zie mijn reactie hieronder. Het gaat erom dat we ergens een manier vinden om het stapelen van kritieke kleine open-source projecten tegengaan. De grote jongens die hun geld verdienen met OSS en veel gebruikers hebben moeten daarom hun verantwoordelijkheid gaan nemen en zij moeten hiertoe gedwongen worden door bijvoorbeeld een keurmerk, maar er zijn vast ook andere manieren te verzinnen.
Eens. M.i. is de oplossing niet 'meer eisen stellen aan de hobbyist', maar juist het faciliteren van die verantwoordelijkheid. We hebben een 'suikeroom-model' nodig (zoals een Sovereign Tech Fund of NLnet) dat de lasten draagt zoals geld, audits, juridisch gedoe, zodat de dev gewoon kan coderen zonder burn-out, mits die dat wil. Het initiatief om contact op te nemen ligt dan bij de 'suikeroom'. Ik weet dat er ooit sprake was van een Fellowship for Maintainers... Geen idee of dat nog bestaat.

Sterker nog: dit zou wettelijk verankerd moeten zijn. Als overheden 'open standaarden' eisen in aanbestedingen, moeten ze verplicht financieel bijdragen aan de projecten die die standaarden mogelijk maken. Puur faciliterend ('no strings attached'), dus zonder inhoudelijke inmenging. En dat kun je zelfs nog doortrekken met een overheid als launching customer of als een soort escrow voor intellectueel eigendom.

Als overheden dit kunnen doen voor kunstenaars en influencers, dan moet dat ook kunnen voor deze publieke zaak.
Dus wil je leuke hobby projectjes maken en delen, prima en dat moet ook nog steeds kunnen. Maar eigenlijk zouden grote opensource projecten van bijvoorbeeld RedHat of SpringBoot dan niet jouw tooling moeten gebruiken, echter nu doen ze dat wel omdat niemand ze hiervoor verantwoordelijk houdt. Sterker nog, de mensen die die kleine projecten runnen krijgen de schuld over het algemeen. Een keurmerk zou ze dwingen deze verantwoordelijkheid wel te nemen.
Niet een Meme, en niet van die site maar van XKCD.
huh, hoe komt corona nou ineens in dit verhaal?
https://xkcd.com/2347/ :+

Oh ik zie dat een ander mij al voor was...

[Reactie gewijzigd door erik_t op 6 februari 2026 09:49]

Dat doet me denken aan dat probleem op Github/NPM dat 1 specifieke library offline gehaald werd, en honderdduizenden programma's die leunden op deze library in de problemen raakte.
Wellicht inderdaad tijd dat de EU zo’n belangrijk onderdeel eens gaat ondersteunen en overnemen. Dan kunnen we verder van Amerika af komen met unieke code, die ons, de EU, meer onafhankelijheid geeft. Misschien is het nu de tijd om eens beslissingen te nemen EU. Beter een slechte beslissing, dan nooit of te last beslissen. Pak het moment om de hefboom eens de andere kant op te zetten.
Ben ik de enige die niet wist dat 'sudo' echt een tool is die actief ontwikkeld wordt? :X
Ging er eigenlijk vanuit dat dat gewoon één van de standaard commando's in vrijwel ieder distro was...
Dat is precies de Unix-filosofie: Minimalisme en modulariteit. Dus kleine tools die één ding heel goed doen, en output van andere tools naadloos kunnen oppakken, als input. Ontzettend veel "commando's" op nix-systemen, zijn echt losse programmaatjes. Neem bijvoorbeeld Core-utils, aanwezig op praktisch elk nix-systeem. Als die commando's, zijn losse programma's. Ze worden wel gebundeld verspreid, maar ze hebben elk hun eigen code-base.
Ik dacht hetzelfde. Ben ook benieuwd wat het doet behalve er voor zorgen dat commando's met admin rechten kunnen draaien.
Dat is wat het doet. Je doet dingen als de superuser. De kracht van sudo zit hem erin dat je heel specifiek kunt aangeven welke gebruiker/groep welke commando's mag uitvoeren, en hoe. Op mijn machines mag ik bijvoorbeeld met mijn eigen gebruiker 'apt' commando's draaien (update, upgrade) zonder ook maar een wachtwoord in te hoeven voeren. Voor andere commando's wordt dan weer wel om mijn wachtwoord gevraagd. Er zijn ook commando's waarvoor ik specifiek root moet worden, zodat ik niet onbedachtzaam een destructief commando uitvoer.
Sudo is geen commando maar een programma.

Je kan prima werken zonder en dat maakt je systeem ook veiliger. Het enige dat 'sudo' doet is alles dat je als parameter opgeeft uitvoeren, wat gebeurt als 'root' vanwege de setuid bit.

Aanmelden als 'root' bereik je hetzelfde mee en het is erg makkelijk om een vervangende binary te maken met setuid bit. Ook bestaan er alternatieven zoals 'doas' als je graag wel dat beetje extra gemak hebt.

Dus nee, "Linux" leunt helemaal niet op 'sudo' zoals in de reacties hier soms wordt beschreven.
Sudo kan wel even iets meer dan dat. Zo hoeft een commando helemaal niet als root uitgevoerd te worden, en heeft het bovendien een vrij flexible regel-systeem waarmee je fijnmazig bepaalde (groepen) gebruikers vrij specifieke commando's (met eventueel zelfs controle over de parameters) kan laten uitvoeren als andere gebruikers. Zie https://linux.die.net/man/5/sudoers.
En daar bovenop wordt elk commando dat via sudo wordt uitgevoerd gelogd, met informatie over wie dat deed. Samen met de onmogelijkheid om als root in te loggen, zorgt dat voor een omgeving die beter te controleren is. Ja, je kunt nog steeds sudo su doen, maar dan kun je vragen stellen aan diegene en als inbreuk op policy zien.
Het is net veiliger om iets als een sudo te gebruiken en goed in te regelen. Je wil net zo min mogelijk aanmelden met root, in essentie enkel voor disaster recovery. Is ook een reden dat root al jaar en dag standaard geblokkeerd wordt over SSH.
Het hangt er maar net vanaf wat je als "veilig" beschouwt. Op een multi-user-systeem waar je niet weet hoe sterk de wachtwoorden zijn, kan sudo een enorm risico vormen. Als een gewone gebruiker gehackt wordt (social engineering?), dan is er ook meteen root toegang, tenzij de beheerder sudo heel expliciet heeft geconfigureerd.

Ik log zelf altijd in als normale gebruiker op een GUI, maar open wel direct een root-console. SSH-logins doe ik louter als root. Is dat onveilig? Ik sta geen wachtwoorden toe, maar alleen ED25519 keys. Om die te gebruiken zul je toch echt eerst fysiek toegang tot mijn pc moeten hebben.

Tja, en dingen verneuken als root, dat doe ik al heel wat jaartjes niet meer.
Sudo is net iets meer dan alleen maar even snel root worden en verder hacken.

De betere sudo configuratie laat jou een commando uit voeren als een andere gebruiker, zoals bijvoorbeeld een service-account. In den beginnen bood unix/linux hier het s-bitje op de executable. Maar daarmee kan je het zonder controle. Daarna kwam het `su` commando maar daarmee moest je het wachtwoord van het account weten waar je naar toe gaat. Met `sudo` kan de beheerder het zo configureren dat een selectie aan gebruikers op een veilige manier een systeem bestand kunnen wijzigen. Of dat je een service kan herstarten maar niet stoppen. en zo nog veel meer/creatiever.

Toegegeven, het verbaast mij dat de grote linux distributies hier niet op 1 of andere manier in springen. Maar aan de andere kant, voor de linux kernel is er uiteindelijk ook 1 wortel.
Je zou verwachten dat mensen zoals Todd geld zouden ontvangen van alle grote bedrijven die Linux gebruiken voor hun stack.
Open source software is zo iets als liefdadigheid.
Sommige werkgevers staan toe dat open source ontwikkelaars aan zulke projecten werken tijdens hun 'normale' werk.
Maar heel veel projecten worden onderhouden door mensen met een passie voor hun project in hun vrije tijd.
Absoluut waarom betaalt de Linux Foundation hem niet ... ?
Juist omdat veel mensen dat denken doen veel mensen het niet. En organisaties betalen al voor RedHat en dus denken er verder niet over na.
AuteurTijsZonderH Nieuwscoördinator @spoonman6 februari 2026 08:04
Heb m'n hele pc moeten herstarten om naar de Ubuntu-partitie te gaan voor één stomme grap, ben blij dat iemand em waardeert.
Kun je oplossen door met Ubuntu te werken, en dan moet je af en toe je pc herstarten voor een stomme Windows grap. (Of je draait Windows virtueel in je Ubuntu)
AuteurTijsZonderH Nieuwscoördinator @jvwou1236 februari 2026 08:10
Ik heb problemen met de vpn die we voor werk nodig hebben, daarom zit ik voor werk doorgaans op Windows (helaas).
Je kan de VPN draaien in een kale Windows VM en het netwerkverkeer doorzetten naar de host. Dat is het alternatief als opensource alternatieve VPN clients geen soelaas bieden.

[Reactie gewijzigd door The Zep Man op 6 februari 2026 08:23]

AuteurTijsZonderH Nieuwscoördinator @The Zep Man6 februari 2026 08:24
Ja of ik doe gewoon iets dat gewoon zonder gedoe werkt :P
Al eens aangekaart bij werkgever dat jullie een VPN gebruiken die niet op Linux werkt? In het verleden wel succes mee gehad, vooral wanneer er geen werklaptop wordt verstrekt met Windows erop.
AuteurTijsZonderH Nieuwscoördinator @donkerlicht6 februari 2026 08:43
Ze bieden wel een Linux-variant aan maar for some reason doet die het bij mij niet. Servicedesk wil echter geen techsupport leveren op selfmanaged devices en ik ben zelf te noob en te lui om dit écht een keer goed uit te zoeken. Maar ik ben heel OS-agnostisch verder.
Misschien op tweakers.net/forum eens vragen dan? 😈
Ach, binnenkort geen last meer van, als de EU het plan doorzet om vpn's te verbieden… ;)
Ah, ik wist niet dat je ook voor bokt.nl schrijft. :+
offtopic:
Grapje, mede-tweakers! Voor Tijs gaat het om zijn werk. Tweaken is leuk, maar het moet het werk niet in de weg staan.
Ben wel benieuwd wat voor exotisch ding dat is. Zelfs die meuk van fortinet werkt onder linux. Anders gewoon een tunneltje opzetten? Maar dan worden er vast wat ict poppetjes boos.
AuteurTijsZonderH Nieuwscoördinator @fenrirs6 februari 2026 08:53
Ik ga geen opsecfail doen maar het installeert en maakt verbinding, alleen laden er dan geen pagina's. Krijg ook geen foutmeldingen of zo. Zal best allemaal te fixen of omheen te werken zijn maar het boeit me allemaal niet genoeg om dat te doen. Ik ben ook echt heel erg slecht in netwerken dus ik weet niet wat ik doe.
Pak de log, dump het in GitHub copilot, Claude of gewoon ChatGPT en vraag om de fix.
Het schijnt dat hier een heel forum is met Tweakers die elkaar graag helpen ;)
Ik ken dit probleem van Wireguard over TCP-only (want "security) netwerken. Dan verbindt de VPN, alles staat op groen, maar verkeer... ho maar.
Klinkt als een post-up hook die mist / niet werkt waardoor je resolving naar je oude DNS-servers bljft kijken. Afhankelijk van je huidige software kan dat opgelost worden met installatie van een pakket.
Zeg, ben jij nou een tweaker, of niet? :+ :+ :+
Of je draait WSL2 in Windows, veel beter.
Of Ubuntu virtueel in Windows, zij het in een hypervisor of in WSL.
Daar hebben we WSL (2) voor
Heb m'n hele pc moeten herstarten om naar de Ubuntu-partitie te gaan voor één stomme grap, ben blij dat iemand em waardeert.
Waarom? Arch Linux heeft ook sudo. Geen herstart nodig.

:+
Ik hoor het al; hard werken bij Tweakers. ;-) _/-\o_
Heerlijk dit soort droge humor bij een nieuwsbericht _/-\o_
Je zou ook WSL kunnen gebruiken, werkt voor mij voor 99% van de gevallen prima. Voor die ene 1% is er wel een omweg te bedenken. Zelfs USB pass through werkt acceptabel.
Sudo geef meer geld -f
Ik ben dan voornamelijk benieuwd hoe het is ontstaan dat Miller momenteel de enige is die aan sudo werkt.

En kan er niets bedacht worden door de Linux foundation. Om bv een board op te zetten voor extra sudo ontwikkelaars?
Hier verbaas ik mij ook over, zo'n belangrijk onderdeel.
Laatste keer dat ik deze zag, was serieus in terminal output. Bincode 3.0 voor Rust, niet meer maintained, als je hem nog probeert te installeren krijg je een foutmelding met de URL naar dat plaatje.
De meeste open source software wordt beheerd door 1 developer. De grote applicaties worden vaak door meerdere beheerd, maar die leunen dan weer op libraries die maar 1 beheerder hebben.

Op een gegeven moment is software af. Dan hoeft er niet zo veel meer aan ontwikkeld te worden. In die gevallen zie je vaak dat er nog maar 1 persoon actief in is.
Waar basseer je dat op? Software is zelden af en veel FOSS hebben communities eromheen.
De meeste FOSS heeft absoluut geen community er omheen. Waar is de community van libxml2? Waar is de community van xz-utils. Ook van OpenSSL kan je nauwelijks spreken van een community eromheen. Als ik kijk naar de "commuinity" activiteit van sudo is die er ook niet echt. Communities zijn er voor de grotere software pakketten.

En wat betreft software die af is. Ja dat komt heel veel voor. Het is feature complete (zo ver men er nu tegenaan kijkt.) Op zo'n moment is er voornamelijk maintenance: fixen van bugs of compatibility/performance issues. Sudo is behoorlijk af, de laatste "grote" update was 1.9 in 2020 waarin een paar nieuwe plugin extension points toegevoegd werden, en ondersteuning van Python 4 voor plugins (maar dat is toch echt maintenance werk).

Dus waar baseer ik het op dat er weinig communities zijn? Door dat je ze simpelweg niet ziet als je naar de project sites gaat. Doordat er steeds vaker op nieuwssites berichten geplaatst worden over high profile software met weinig maintainers.

Waar baseer ik het op dat er veel software af is? Op basis van het aantal "grote" releases, eigenlijk het gebrek er van, die deze software projecten maken, en het ontbreken van een TODO/roadmap. GNU Coreutils zit vol met software die af is, als hele package is er nog wel wat te doen naast maintenance.
Ik wist niet dat door fundamentele tooltje door één persoon onderhouden werd. Kudos!

Helaas is deze xkcd voor heel veel dingen waar:

https://xkcd.com/2347/
Nou nou, ook zonder sudo kan je werken, maar wel veel gevaarlijker/onhandiger.
su
Als je alleen kijkt naar je dagelijkse dingen als enige gebruiker, absoluut.

In een zakelijke omgeving is sudo wel heel handig, of voor applicaties die je rechten wil geven als een andere user.
@TijsZonderH ^^ goed plaatje voor bij het artikel
https://xkcd.com/149/

Deze is meer in lijn met de huidige screenshot
Ik ben tijdje geleden geswitched naar doas van bsd, iets minder features, maar werkt goed voor wat ik doe. O.a. alpine heeft die als default.

Onder andere vanwege deze blogpost: https://blog.geraldwu.com/posts/why-and-how-i-switched-from-sudo-to-doas-and-why-you-should-too/
doas has ~3k SLOC compared to sudo’s ~177k. That’s nearly two full orders of magnitude less. While SLOC is not necessarily indicative of a secure implementation, it is far easier to audit a codebase that is 50 times smaller. Just by default, doas will have a far smaller attack surface than sudo.

[Reactie gewijzigd door Dala op 6 februari 2026 08:11]

Als OpenBSD-gebruiker (ook desktop & laptop), kan ik doas(1) inderdaad heel erg aanraden.

Ondanks dat het een heel simpel programmaatje is, is het in bijna alle gevallen voldoende.

De man-pagina van doas.conf(5): https://man.openbsd.org/doas.conf.5
Hoef er niet eens op te klikken om te weten welke dat is :)

Om te kunnen reageren moet je ingelogd zijn