Sarà il burn out, sarà l'età che avanza, ma ho come l'impressione che tutto si complichi andando avanti nel tempo.
Per esempio ho scoperto questo nuovo server HTTP: Caddy.
Caddy is a powerful, enterprise-ready, open source web server with automatic HTTPS written in Go.
Al contrario dei classici #Apache e #Nginx, con due righe due di configurazione hai un webserver in funzione, con possibilità di fare agilmente un reverse proxy e tante altre cose con poche direttive. In più, fantastico, ha la gestione dei certificati #letsencrypt integrata (generazione e rinnovo). Ganzo.
Senonché vedo che c'è la versione 2 (ancora in beta, ma per poco). E diavolo, le opzioni per la configurazione sono più articolate. Oh sì, saranno più potenti. Punta molto sulle API per fare le configurazioni al volo senza dover riavviare il servizio, uuuh, molto utile forse per il sito di ecommerce. Introduce la sintassi in JSON anziché le classiche righe di testo (sebbene sia comunque possibile utilizzarle). E per configurare la stessa cosa che con la versione 1 ho messo due minuti, con questa nuova versione c'è voluta un'ora, perché sì, sono cambiate le opzioni e la logica (e io sono particolarmente duro di comprendonio, sicuramente).
E non è l'unico caso.
Prendiamo l'avvio dei servizi su #Linux (al solito: per chi vuole, legga #GNU/Linux). Non sono un detrattore di #Systemd, anzi. Però, se una volta dovevi far partire uno script stupido (e non parlo del programma di una banca o di una centrale nucleare) una volta completato l'avvio del sistema, lo mettevi in rc.local e avevi fatto il tuo lavoro. Ora, su alcune distribuzioni sarà ancora possibile fare così, ma è deprecato e non professionale, sei uno scarpone artigiano non degno di usare una tastiera. Adesso ci sono file di configurazione, dipendenze, ventimila opzioni, demoni da riavviare, posti precisi dove andare a mettere il file che invoca il tuo stupido script. Cioè, non parlo di un servizio di un programma importante. Parlo di un banale script da avviare al volo.
O il cron. Ora ci sono i timer di Systemd. Se impari a usarli sono bellissimi e potentissimi. Ma se il cron lo capiva anche mio nonno (più o meno), per impostare un timer di Systemd devi leggere il manuale, scrivere due file di configurazione, ricordarti dove metterli, abilitare uno e non l'altro, ecc.
UEFI? ... ... ...
Sviluppi uno script stupido, ma che vuoi condividere col mondo. Devi metterlo su un server git; e via a imparare git, e a ricordarti la sintassi Markdown per scrivere il readme, ecc. Certo nessuno ti obbliga a farlo.
O anche per esempio la documentazione di Fedora. La scrittura di un howto. Una volta c'era il wiki. Voglio dire, anche mio nonno arrivava a saperlo usare. Edit della pagina, e scrivi l'howto. Ora no. Devi imparare git, capire qual è il repository, capire asciidoc, seguire delle regole di scrittura, saper lanciare un container. Poi certo, il documento sarà più bello di una pagina sul wiki fatta in fretta, e passerà per un processo di revisione. Ma che fatica.
Ma Docker stesso.
Certo, se usi un container preconfezionato, può sembrare semplice, come installare un pacchetto, dopotutto. Ma se vuoi fare un container tuo? Se vuoi mettere in ascolto il container su un'altra porta? Se vuoi che due container vadano a braccetto?
Sarà che ho ancora da approfondire molto la questione, e ammetto di non averci capito molto, ma sento puzza di cose difficili.
O un altro esempio è l'IPv6. Bene o male l'IPv4 un umano qualsiasi con un minimo di dedizione e sforzo, arriva per lo meno a capire che sono 4 numeri divisi da dei punti. Poi ripeto, sarò io particolarmente ignorante.
E insomma sarò vecchio e ignorante, ma sento questa puzza. Una volta, vent'anni fa, le cose erano più difficili, sicuramente, ma umane. Mi posso sbagliare, ripeto.
Ricordo che anche i documenti su pluto.it (esiste ancora ILDP, Italian Linux Documentation Project?), voglio dire, la sintassi non era delle più semplici, ma se volevi tradurre un documento, aprivi un editor di testi e quando avevi finito mandavi una mail per la revisione. Meno efficiente? Sicuramente.
Le cose erano più difficili, ma più umane, anche un non laureato in ingegneria del software, sporcandosi le mani, poteva per lo meno fare l'artigiano di basso livello. Un lavoro brutto, sporco, poco professionale. Ma funzionante. Obiettivo raggiunto.
Ora, invece, sembra che ci voglia una laurea anche per cambiare il dispositivo di boot.
Ah! Ma è un po' come le automobili. Le auto di una volta le aggiustavi con un pezzo di fil di ferro. Adesso per individuare un guasto ci vuole il computer (e non sempre torni a casa con la macchina riparata).