Windows 11 optimaliseren voor dagelijks gebruik
Je opent een terminal, typt `gcc -O2 -o app main.c`, en de build is klaar voordat je koffie hebt gezet.
Dat is het gevoel waar mensen naar zoeken als ze zeggen dat ze hun systeem willen "optimaliseren". Geen regedit-trucs, geen telemetrie-uitzetters, geen veertig minuten YouTube waarin iemand met een stockfoto-gezicht uitlegt dat je achtergrondanimaties moet uitzetten. Gewoon: je gereedschap doet wat je vraagt, en snel.
De vraag is alleen wat je dagelijks gebruikt, en daar loopt het meteen uiteen.
Werk je in een browser, een mailclient en een tekstverwerker, dan is er weinig te optimaliseren dat de moeite waard is. Moderne hardware uit de afgelopen vijf jaar is snel genoeg voor dat werk. Wat je merkt is niet traagheid maar ruis: meldingen, achtergrondprocessen, dingen die je aandacht opeten. Dat los je niet op met een script maar met een beslissing over wat je op je machine toelaat.
Werk je daarentegen met een compiler, een editor, containers, databases, dan wordt het interessant. Dan is je dagelijkse omgeving een terminal, en dan zijn er echte keuzes.
Neem de terminal zelf. `zutty` is een X11-terminal emulator die rendering op de GPU doet en weinig geheugen gebruikt. Hij start snel en voelt direct. Wat hij je niet geeft: tabs, splits, een plugin-ecosysteem, een configuratiebestand waarin je alles kunt instellen wat je maar kunt bedenken. Je krijgt een venster met een shell erin, en dat is het.
Wil je tabs en splits, dan kom je bij de zwaardere emulators uit. Die kosten meer geheugen en meer opstarttijd, en leveren gemak dat je op een dag met drie terminals misschien wel wilt. Het is geen kwestie van beter of slechter. Het is de vraag of je de complexiteit wilt dragen voor de functies die je gebruikt.
Dan de compiler. `gcc` en `g++` zijn wat je waarschijnlijk al hebt. De optimalisatievlaggen zijn geen mysterie: `-O2` is het standaard compromis tussen snelheid en compileertijd, `-O3` gaat verder met aggressievere optimalisaties en kan de binary groter maken, `-Os` optimaliseert op grootte.
```bash gcc -O2 -march=native -o app main.c ```
`-march=native` laat de compiler instructies gebruiken die jouw specifieke CPU ondersteunt. Dat levert winst op, en het betekent ook dat de binary niet meer draait op een oudere machine. Voor software die je alleen zelf gebruikt is dat prima. Voor iets dat je deelt, is het een valkuil.
De preprocessor, `cpp`, is het gereedschap dat je gebruikt als je wilt zien wat er werkelijk naar de compiler gaat. Macro's, includes, conditionele compilatie. Als een build iets doet dat je niet begrijpt, is `cpp` hoe je kijkt wat er werkelijk gebeurt. Geen optimalisatie, wel het verschil tussen gokken en weten.
```bash cpp -I./include main.c ```
Voor logbestanden van GnuPG-diensten is er `watchgnupg`. Dit leest logs via een Unix Domain Socket. Je start het, en je ziet wat de daemon doet terwijl hij het doet.
```bash watchgnupg --force --verbose /var/run/user/1000/gnupg/S.log ```
Handig als je een probleem met sleutels of agent-communicatie probeert te vinden. Minder handig als er niets aan de hand is, want dan kijk je naar een leeg scherm en vraag je je af waarom je dit ook alweer deed.
Schrijf je Python, dan zijn `_thread` en `tkinter` twee kanten van hetzelfde verhaal. `_thread` is de laag-niveau threading-module. Weinig abstractie, veel controle, en je beheert zelf de locks. Voor de meeste taken gebruik je `threading`, dat bovenop `_thread` is gebouwd en je leven eenvoudiger maakt. `_thread` gebruik je als je precies wilt weten wat er gebeurt, of als je iets bouwt waar de overhead van `threading` niet past.
`tkinter` is de interface naar Tcl/Tk. Het zit in de standaardbibliotheek van Python, dus je hebt het al. Je bouwt er vensters, knoppen en invoervelden mee. Het ziet er niet uit als iets uit 2024, en het is overal beschikbaar zonder dat je iets hoeft te installeren. Voor een intern hulpmiddel dat één taak doet, is dat vaak precies genoeg.
Draai je Ubuntu en wil je zeker weten dat je security updates krijgt voor de pakketten die je gebruikt, dan is er `pro`, vroeger `ubuntu-advantage`.
```bash pro status ```
Dat vertelt je welke diensten actief zijn. Je kunt het aanzetten voor een gratis persoonlijk gebruik of voor een betaald abonnement op een server. Wat het je kost: het is een extra laag bovenop je normale updates, en je moet weten wat je aanzet voordat je het aanzet. Standaard laat je het uit tot je een reden hebt.
Wat al deze dingen gemeen hebben: ze zijn snel omdat ze weinig doen. `zutty` rendert en verder niets. `gcc` compileert. `watchgnupg` leest een socket. Geen van alle probeert je te helpen met iets waar je niet om vroeg.
De keerzijde is dat je zelf de samenhang regelt. Je shell, je editor, je window manager, je build-scripts. Alles wat je toevoegt moet je ook onderhouden. Een terminal met vijftig plugins is een project op zichzelf, en op een dag breekt er een na een update.
Dat is de echte afweging bij "optimaliseren". Niet welke vlag je aanzet, maar hoeveel je bereid bent te beheren. Hoe minder onderdelen, hoe minder er omvalt. Hoe meer je toevoegt, hoe meer je kunt, en hoe meer je moet bijhouden.
Er is geen instelling die dit voor je oplost. Je kiest een punt op die lijn, en je leeft ermee tot je merkt dat je te ver naar één kant zit.
En als je dan op een zondagavond ontdekt dat je build faalt omdat een plugin na een update iets anders doet dan gisteren, dan weet je in ieder geval waar je moet kijken. Dat is meer dan de meesten kunnen zeggen.