Anche se ormai si è concluso da pochi minuti ci tenevo ad augurare ai quattro gatti a cui capita di leggere queste pagine buon Darwin Day!

Quale miglior modo di festeggiare questa importante ricorrenza se non consigliare un bellissimo libro che tratta proprio di evoluzione, scritto da scienziati con la S maiuscola e che spiega perchè il nostro bel cervellino fa così fatica a credere alla teoria dell’evoluzione ed è invece così fortemente attratto da maghi, fattucchiere o santoni di turno che propinano disegni intelligenti a destra e a manca.

Nati per credere
autori: Giorgio Vallortigara, Telmo Pievani, Vittorio Girotto
Codice Edizioni
ISBN: 978-88-7578-110-1

Buona lettura!

Ed eccomi qua, a circa un anno dall’inizio della mia prima esperienza con una tastiera meccanica a provare un nuovo esemplare, stavolta dotato di switch Cherry MX Blue, una fiammante CM Storm Quickfire XT ritirata giusto giusto stamattina dal celebre store Drako.it.

Era da tempo che stavo meditando di acquistare una nuova tastiera, non perchè non fossi soddisfatto della Ozone Strike, ma per la pura e semplice curiosità di (letteralmente) mettere le mani su un differente tipo di switch Cherry MX e quindi un feeling totalmente diverso.
Purtroppo sui miei primi pc non ho avuto la fortuna di utilizzare una tastiera meccanica, ricordo però con grande piacere e nostalgia le poche esperienze su pc altrui dotati di IBM Model M o simili, ricordo il gradevole feeling tattile degli switch, il piacevolissimo suono prodotto dalla digitazione, ecco perchè non ho avuto dubbi e per questa mia seconda tastiera meccanica ho scelto un modello dotato di Cherry MX Blue.

Esteticamente ho scelto un modello che imho rappresenta una via di mezzo tra le tastiere dal design tradizionale (es Cherry G80 oppure le bellissime Filco Majestouch) e le tastiere dal design stravagante e imho orripilante (pensiamo ad esempio ai modelli prodotti da Razer, piuttosto che le orribili Logitech da gaming).

La Quickfire XT si presenta con un design pulito ed essenziale ma caratterizzato da dimensioni compatte e da forme arrotondate, il lato che presenta il connettore usb (quasi minimalista nella sua semplicità) mostra soltanto il logo CMStorm posizionato sul lato opposto che trovo carino e discreto, per concludere i font selezionati per i keycap sono moderni quasi stilizzati.

Riguardo agli switch devo confessare che l’impressione iniziale è stata… “amore alla prima digitazione”, ancora adesso mentre scrivo queste poche righe mi si riempie il cuore a sentire questo piacevole “clickettio”, in fondo basta poco per fare felice un kender nerd :D

Tirando le somme confesso di essere ESTREMAMENTE SODDISFATTO, quando iniziai ad usare la Ozone Strike (che reputo ancora oggi una ottima tastiera, forse una delle migliori basate su switch MX Black) provai un po’ di disorientamento (forse dovuto anche al layout un po’ più compatto rispetto alla mia precedente – e mai rimpianta – Logitech G510) e sperimentai qualche errore di battitura di troppo (poi svaniti con l’abitudine), ora con questa Quickfire invece mi trovo immediatamente a mio agio e trovo la digitazione più piacevole, leggera (merito del minor sforzo attuativo degli switch) e veloce.
Unico neo è l’inevitabile suono (chiamarlo rumore non mi è possibile) prodotto dagli switch MX Blue che può causare grande fastidio in chiunque si trovi in stanza con voi mentre usate la tastiera.

L’indicizzazione full text di IBM Domino è sempre stata, è, e sempre sarà una gran figata per tanti motivi, primi fra tutti l’oggettiva utilità e semplicità necessaria per implementarla.
Mentre altri prodotti (che mi piace etichettare come “polpettoni”) propongono servizi di indicizzazione invasivi, pesanti, estremamente complessi e dall’efficacia spesso risibile, l’indice full text di Domino è una delle tante certezze di questo prodotto, un paio di click e l’indice è pronto all’uso.

Recentemente mi è però capitato un piccolo problema proprio durante la generazione dell’indice di alcuni nsf, lanciato il processo l’indice non è stato creato creato (nemmeno la directory “<nomedb>.ft”) e nel log.nsf è comparso il seguente messaggio di errore estremamente “parlante”.

Una breve ricerca sul sito IBM mi ha portato alla seguente technote che spiega la motivazione dell’errore e suggerisce di aggiungere nel file notes.ini il parametro TEMP_INDEX_MAX_DOC=<number>, dove il valore della variabile corrisponde al numero di documenti ammessi nell’indice temporaneo che viene creato durante il processo di generazione dell’indice full text.

Veloce restart dell’istanza Domino e problema risolto!

Da qualche giorno si sta consumando uno scontro piuttosto acceso tra gli (ormai ex) sviluppatori e manutentori dei nagios-plugins e Nagios Enterprises, che detiene i diritti per il marchio oltre a sviluppare e distribuire la soluzione commerciale e Nagios Core.

Da quanto è emerso pare che Nagios Enterprises abbia letteralmente defenestrato il gruppo di sviluppatori e li abbia estromessi dalla gestione del sito e del progetto dopo che questi hanno cominciato a citare anche altre soluzioni alternative al loro Core (Icinga, Naemon, Shinken etc etc..), sostituendoli con altre persone non meglio definite e che non hanno alcuna esperienza su quei progetti, mettendo a capo del tutto colui che ha mantenuto i nagios-plugins inizialmente (ma che da molti anni non contribuisce).
Il gruppo di sviluppatori storici dei nagios-plugins ha creato un fork e sta sottoponendo i propri package ai manutentori dei principali repository, trovate tutte le info al sito https://www.monitoring-plugins.org.

Per quanto può valere esprimo la mia più totale solidarietà ai ragazzi di monitoring-plugins.org che hanno subito un torto mostruoso, aggravato da futili motivazioni e da una arroganza spaventosa da parte del team ufficiale di Nagios, questi ragazzi hanno svolto un lavoro FANTASTICO e sono certo faranno altrettanto con il nuovo progetto, auguro a loro ogni fortuna.
Non so voi ma oggi ho un motivo in più per valutare seriamente un fork alternativo a Nagios Core…

Potete trovare riassunta un po’ tutta la diatriba alla url https://bugzilla.redhat.com/show_bug.cgi?id=1054340

Uno degli alert che odio maggiormente da parte del monitoraggio di server Windows (nel mio caso pochi e in lenta ma costante riduzione) è quello relativo al superamento delle soglie di occupazione sullo storage, specialmente quando questo riguarda l’unità di sistema e il cestino.

Sull’unità di sistema c’è poco da dire, il processo di update di questo sistema operativo (e dei relativi file che tendono ad accumularsi nelle directory di Windows) è una delle grandi follie di questo sistema operativo che non riuscirò mai a comprendere…

Quello su cui vorrei concentrarmi in questa sede invece è il cestino, questa mistica entità in grado di dare anche all’utente più banale il potere di causare disservizi su un intero server (ad esempio saturando a suon di cancellazioni il volume di turno).
Chiaramente anche ripulire il cestino dai file è tutt’altro che un’operazione scontata, non perchè questo sia complesso ma più che altro perchè i file “cancellati” da altri utenti risultano categorizzati sotto directory che riportano il security identifier (SID) dell’utente, quindi risulta piuttosto criptico capire “chi ha cancellato cosa” e regolarsi di conseguenza sulle possibili azioni da intraprendere.

Per “tradurre” questi identificativi negli username locali occorre lanciare il comando “wmic useraccount get name,sid”