Alle posts van Wander

In een moderne IT omgeving is het heel erg makkelijk om oplossingen te bedenken en te maken die erg complex zijn, terwijl hetzelfde probleem over het algemeen ook met minder complexiteit opgelost kan worden. Dit zegt niks over de effectiviteit van de oplossing, maar wel over de onderhoudbaarheid. Complexe oplossing zijn vaak foutgevoeliger, en moeilijker te onderhouden dan elegantere, minder complexe, oplossingen.

In Bash scripts is het mogelijk om bepaalde signalen af te vangen voordat ze het huidige draaiende proces raken. Het script kan dan kiezen om iets anders met zo een signaal te doen.

Netwerken scannen hebben we hier al vaker bekeken, bijvoorbeeld met nmap. Maar dit is wel altijd een commandline bezigheid geweest, met veel opties, vlaggetjes, en een steile leercurve. Dat moet ook makkelijker kunnen…

De meeste grote muziek streamingsdiensten hebben een officiële desktop client voor Linux, of in ieder geval een web-based player met een Electron client eromheen die moet doen also hij een volwassen client is. Het nadeel aan deze clients is dat ze meestal veel resources gebruiken, en/of niet mooi in de rest van je desktop passen of integreren.

Bijna iedereen heeft wel eens set -euo pipefail bovenaan een shell script zien staan. Maar wat betekent dat nou precies? En waarom gebruiken we dat? Waar vind ik daar de documentatie van? Wat is de betekenis van het leven?

In het verleden hebben we op dit kanaal al vaker gekeken naar het configureren van metrics, voornamelijk op Kubernetes platformen. In die gevallen was het vaak een eenvoudige setup met behulp van bijvoorbeeld een Operator, waardoor je met een paar klikken klaar was. Nu is het tegenwoordig bijna net zo makkelijk om goede, robuuste, metrics te verzamelen van je “klassieke” systemen. De RHEL System Roles Ansible collection heeft een een role genaamd metrics die gebruikt kan worden om Performance Co-Pilot (PCP) te configureren om metrics te verzamelen, maar ook om een Valkey (of Redis op oudere systemen) te configureren om metrics van meerdere hosts te verzamelen, en een Grafana (inclusief dashboards en datasources) op te zetten.

Als je een digitale foto (of ander plaatje) van lage resolutie of kwaliteit hebt, en je wilt die toch kunnen gebruiken ergens waar je een hogere resolutie nodig hebt, dan kun je grijpen naar wat standaard beeldbewerkings software zoals Gimp. Een beetje “scale”, een beetje “sharpen”, en je hebt waarschijnlijk al redelijk snel iets dat je met trots “mèh” mag noemen, misschien zelfs wel “mid”. Gelukkig zijn er applicaties die niks anders als doen hebben dan het vergroten/verbeteren van plaatjes. Sommigen daarvan zullen niet veel betere resultaten halen dan wat je zelf met generieke bewerking software kon doen, maar anderen gebruiken wat modernere (en CPU/GPU intensievere) algoritmes om een beter resultaat te behalen.

Op zich lijkt YAML niet zo raar. Whitespace is misschien belangrijk, en het inline gebruik van JSON kan er soms wat vies uit zien, maar over het algemeen lijkt het toch redelijk eenvoudig. Totdat het niet meer zo eenvoudig blijkt te zijn. Waardes die spontaan lijken te veranderen, landen die blijkbaar niet mogen bestaan, port-mappings die veranderen in (schijnbaar) willekeurige getallen…

Wanneer je op OpenShift een cluster-brede (AllNamespaces) operator installeerd wordt er door de Operator Lifecycle Manager (OLM) een kopie van de Cluster Service Version (CSV) in elke namespace op je cluster neergezet. Deze kopie is hier voor de informatie van je eindgebruikers, zodat ze kunnen kijken welke operators beschikbaar zijn in hun namespaces. Dit klinkt natuurlijk heel nobel en eervol, maar wanneer je honderden, of zelfs duizenden, namespaces hebt op een cluster kost dit behoorlijk wat resources (CPU, Geheugen) voor OLM zelf om bij elke reconcile deze CSVs bij te werken. Ook is het een grote aanslag op de performance van Etcd en de Kubernetes APIServer, want die moeten al die aanpassingen op al die objecten verwerken.