Sysadmin panics: history al posto della documentazione

Non ho mai fatto molto affidamento sulla history della shell, in parte perché sono troppo pigro per cercare nella history, in parte perché non tutte le shell si comportano in maniera analoga riguarda l'history e infine perché invece che ricercare e ripetere lunghi comandi cerco sempre di realizzare degli script.
Ma quella che vado a narrare è una storia che mi capitò diversi anni fa quando l'history venne usata per spiarmi. Eh si, perché invece che domandarmi come si facesse a fare determinate cose, un mio ex collega penso' bene di usare l'history di account condiviso per imparare e controllare le mie azioni.
Ok, ci sono due errori qui: il primo è quello di avere un account condiviso, ma ogni tanto serve un compromesso; il secondo è quello di lasciare la storia attiva su un account appunto condiviso, ma ogni tanto si deve concedere fiducia al genere umano.
Ma quando ho capito che, invece che leggere la documentazione che ogni volta scrivevo e manutenevo, il collega pigro non faceva altro che consultare l'history e ripetere a scimmia i comandi senza nemmeno capirli, decisi di prendere provvedimenti. Il primo e ovvio fu quello di rimbalzare l'history a /dev/null, e magicamente tutte le sessioni precedenti si svuotarono dei loro comandi. Oggi dovessi trovarmi nella stessa situazione userei un "trucco" ancora migliore e maggiormente impenetrabile.
Ad ogni modo il rimbalzo di /dev/null non fu sufficiente a sviare l'ex collega dalle intenzioni maliziose, a tal punto che lo trovai che spiava le mie sessioni interattive direttamente guardando il mio monitor e usando il tracking dei miei processi...
Ma leggere la documentazione e le istruzioni che fornivo non era piu' facile?

Duck Duck Emacs

Circa due anni fa ho iniziato ad usare DuckDuckGo (abbreviato DDG) come motore di ricerca al posto di Google Search, o meglio e' da circa due anni che alterno i due motori di ricerca.

Oggi ho scoperto che il Wiki di Emacs utilizza DDG come motore per la ricerca all'interno del sito stesso, e questo mi appare un chiaro segnale della community nei confronti della liberta' dei motori di ricerca...

IBM MT-M 8086 21G e i driver misteriosi...

E' passato tanto tempo da quando configuravo macchine Windows (e per fortuna!), ma ogni tanto un qualche parente chiede aiuto, e così mi sono ritrovato fra le mani un IBM Thinkcenter MT-M 8086 21G, sul quale ero costretto ad installare un Windows XP.

Ebbene i driver di questa macchina non sono compresi nella distribuzione del sistema operativo scelto, nemmeno alla piu' evoluta Service Pack.

Poco male, sul sito IBM si troveranno tutti i driver. O almeno così pensavo.

Anzitutto il sito dell'IBM ha lasciato posto al Lenovo Support Center e i driver non sono facili da trovare dato che il modello in questione non compare in elenco. C'è però un simile S50 8086 (ma io dico, ma proprio come un processore lo dovevano catalogare?). 

E la faccenda si complica ancora: sono presenti differenti driver di scheda audio e di rete, e addirittura tre marche di scheda video. Non sapendo quali componenti avevo sotto mano, e non avendo voglia di avviare un qualche altro sistema operativo per testare l'hardware, scarico tutti i driver e li eseguo.

Già, perché i driver sono autoinstallanti!

Ma nulla nella macchina cambia: nessuna periferica funziona. E oggi giorno avere un computer in cui nemmeno la scheda ethernet va è un bel problema.

La cosa va per le lunghe, provo e riprovo ma nulla. Fino a quando mi accorgo che in realtà i driver non installavano nulla (nonostante InstallShield) ma scompattavano una serie di cartella in C:\IBMTools. Controllo meglio e dentro a queste cartelle dai nomi assurdi (es. q37kvenz) vi sono dei driver per vari sistemi operativi, DOS incluso!

Allora dico a Windows di cercare in C:\IBMTools il driver appropriato per ogni dispositivo, ma la cosa fallisce. Non mi è chiaro se Windows sia troppo studipo o pigro per sfogliare le sottocartelle, ma tanto è che devo andare io a provare uno ad uno i file .inf che sono sparsi in quella directory.

E finalmente la scheda video inizia a funzionare, poi è il turno dell'audio e alla fine perfino la scheda di rete mostra segnali positivi.

Cara IBM, la prossima volta abbi pietà di noi poveri umani costretti a lavorare con tali sistemi operativi e dacci dei driver che siano veramente autoinstallanti. E se hai modo, oltre a nominarli in modo comprensibile, cerca anche di fare in modo che i tuoi modelli si possano trovare sul sito ufficiale!

Bug = $$ ?

Ogni tanto salta sempre fuori, nei progetti OpenSource, l'idea del sostentamento tramite bug bounty.

L'idea e' semplice, e spesso anche molto redditizia sia in termini monetari che di qualita' del codice: qualche investitore, solitamente una grossa azienda che usa il progetto in questione, si propone per versare un bounty (ossia una ricompensa) per ogni bug individuato e corretto nella codebase.

Sembra una buona idea, e in effetti lo e', ma non se il bounty serve a sostenere il progetto. In altre parole la caccia al bug (e alla ricompensa) ha senso solo se viene svolta da persone esterne al progetto.

Si immagini di usare il progetto OpenSource X, e che questo dica chiaramente che intende auto-sostenersi tramite le donazioni fatte dallo sponsor Y per ogni bug trovato nel codice. Che pubblicita' ne ricava X? Che piu' bug ci sono e piu' il progetto acquisisce moneta? E quindi puo' pagare piu' sviluppatori (o pagare meglio quelli che ha), andando quindi a ridurre i bug e quindi i soldi a disposizione? Il progetto X dovrebbe gia' fornire codice libero da bug, o impegnarsi a fondo in quello. Nessuno vuole prendere una code base piena di bug e pagare per rimuoverli.

Discorso diverso se la caccia al bug avviene da fuori al progetto: in questo caso si aumenta veramente la qualita' del codice poiche' si usano risorse esterne e quindi con una visione distaccata e capaci, se presenti, di scovare bug che il team non e' stato in grado di trovare.

Ma se il team del progetto X, che si pone come scopo quello di fornire un codice con meno bug possibili, si auto-finanzia con una caccia al bug, allora chi garantisce che qualche bug non sia stato introdotto per sopperire ad una carenza monetaria?

Insomma, i soldi sono importanti, ma lo e' molto di piu' l'etica del progetto!

If Linux did not existed...

Paul Venezia published an interesting article  where he

analyzes what the history of FLOSS could have been without Linux.

Whilte it is worth reading this article, I have to say that it seems to me the conclusions are quite trivial. In particular, assuming Linux never existed, the article states that all the hackers and developers in the world would have been part of the BSD movement. From this, the natural and easy conclusion is that the BSD operating system family would have been much more advanced than what is today.

Well, I don't agree with the article, and it seems to me this is a quite shallow conclusion. One key point of the Open Source movement is the ability to "fork", that is to create another project on the shoulder of an existing one. Having said that, and considering that, as the author states, Linux developers have reinvented the wheel in the beginning, what would have prevented such developers to fork or even start over and get a new project from scratch?

License is another issue that, in my opinion, invalidates the article conclusions: Linux has been released as a GNU project, while the BSD operating system family is, well of course, BSD license. License is religious aspects to many developers, and therefore I assume that many of them would have never chosen a BSD project, again pushing a fork/scratch with another license.

What about the different BSD distros? I believe all of them would have been existed anyway. After all NetBSD was founded when 386BSD was already running, and OpenBSD was founded from NetBSD controversy, and therefore none of these includes a specific Linux-related issue. Other BSD distros, like PCBSD or FreeNAS and the others would have been the same history as of today.

In the industry marketplace I believe some differences would have been generated: today the market is split between the Linux embedded systems and the (Free)BSD ones. As an example, Apple has based OSX on FreeBSD userland and BSD kernel, while Sony and others are basing their multimedia products on Linux. Since Linux has gained a very strong momentum, the hardware support is better than in other BSD systems, and I'm referring to consumer and commodity hardware, not server and high end devices. Therefore, the choice today is about hardware support, and this leads many vendors to choose Linux instead of a BSD system, even if this could break the license (think about the TiVo). If Linux had never ever existed I believe that hardware support for BSD based system would have been better because vendors would not have been any choice of supporting this kind of platform.

A final note is about numbers: many Linux distributions have a lot of people devoted to quality control, source code management, community and advocacy management, and, of course, development and packaging. BSDs have a lot less people available and this is, in my opinion, a big difference: BSDs systems can assure the today's high quality thanks to ability to keep their staff under control. If Linux never existed and a lot of more developers and members would have joined BSDs projects, would have been the quality be the same of today's? I don't think so, and therefore my final conclusion is that if Linux never existed something in the world would have been happened to create a very similar ecosystem.

INSERT/SELECT shortcuts

Selena Deckelmann ha pubblicato sul planet un articolo a mio avviso troppo complicato per spiegare un problema piuttosto semplice: la necessita' di specificare sempre in una istruzione INSERT tutte le colonne coinvolte nel comando stesso.

E lo stesso vale per SELECT, aggiungo io.

A mio avviso dovrebbe essere prassi consolidata quella di non usare mai, in produzione, comandi SQL incompleti (INSERT senza colonne e SELECT *), ma qualora non lo fosse e' giusto ricordare le motivazioni.

La prima e' il riordino, aggiunta, eliminazione di una o piu' colonne. In questo caso l'ordine dei valori di una INSERT o l'output di una SELECT * cambia formato, e quindi non e' piu' affidabile.

La seconda motivazione e' il cast: a volte e' necessario informare esplicitamente il database su come usare un tipo di dato in ingresso/uscita, e nel caso di INSERT via SELECT si potrebbero avere anche tipi molto differenti fra loro (es. inserire una data come testo).

La terza riguarda l'accesso ai dati: non indicando esplicitamente quali colonne si vanno a manipolare si rischia di agire su troppi dati, e ad esempio mostrare (o inviare) colonne che non dovrebbero essere effettivamente visibili.

C'e' poi anche una motivazione di manutenzione: nonostante sia forte la tentazione di passare per la scorciatoia di non indicare le colonne, il fatto di elencarle esplicitamente consente di individuare esattamente tutti e soli i punti che agiscono su un determinato attributo, semplificando il mantenimento del codice, la ricerca di bug e il refactoring.

In altre parole, mai usare le "scorciatoie" se non si sta facendo solo una query one-shot su un sistema di test.

E per prassi, nell'era degli editor super-evoluti, non vi e' ragione per usarla nemmeno su quei sistemi.

IDO (era ora!)

Ho attivato IDO (Interactively Do Things), un modo per Emacs che facilita l'interazione con i buffer e i file. L'idea e' tanto semplice quanto potente: ogni volta che uno switch e' richiesto (ad esempio da un buffer ad un altro o verso un altro file) IDO entra in azione proponendo dei completamenti sulla base di quello "che trova". Se si sta cercando un file IDO mostra le possibili directory e file per ogni livello, se si sta cercando un buffer IDO mostra le alternative. Premendo solo alcuni caratteri del nome di un file/buffer IDO lo "promuove" come prima scelta, semplificando e velocizzando lo switch.

Come ogni personalizzazione, richiede tempo e pazienza per abituarsi ad usarla e ad usare i nuovi keymap, ma confido di essere attivo ed efficiente in IDO nel giro di pochi giorni (considerando anche il tempo che ormai passo in Emacs!).

E dire che l'ultima volta che avevo dato uno sguardo ad IDO non era ancora parte della distribuzione ufficiale Emacs, quindi parlo di prima della release 22!

Wall Street

Anche se ormai vecchio, rimane uno dei miei film preferiti, con un cast veramente degno di nota e un accurato uso dei termini tecnici.

kwin dove sei finito (ossia l'ennesimo update sbagliato)

Ancora una volta il sistema di update automatico di (k)Ubuntu mi ha deluso.

A seguito di un normale upgrade, e pur avendo letto tutte le informazioni, il mio desktop KDE ha smesso di funzionare correttamente. In particolare kwin, il gestore di finestre, non reagiva lasciando le finestre prive di bordo e titolo. Il resto del desktop sembrava funzionare regolarmente e anche lo switch fra le applicazioni si comportava correttamente, ma nulla da fare per le window-decorations. E a nulla e' servito un ben assestato

kwin --replace

Unica soluzione fare un nuovo aggiornamento pulito con installazione fresca della nuova versione del desktop.

Ritengo che Linux sia una buona scelta per il desktop, ma occorre che le distribuzioni risolvano questo fastidioso problema dell'aggiornamento-che-spacca-tutto-il-sistema. O quantomeno prevedano un buon sistema di rollback (a chi viene in mente BootEnvironment di OpenSolaris e FreeBSD?).

Framework 5

E' di ieri la notizia del rilascio del Framework 5, l'infrastruttura che sara' alla base della nuova versione del KDE.

Pur essendo una Technology Preview, e quindi non stabile, questa notizia e' molto importante per il mondo Open Source: non si tratta infatti di una "semplice" evoluzione di uno dei desktop piu' conosciuti e utilizzati, bensi' di un vero e proprio Framework di sviluppo rapido. Come riporta infatti l'annuncio:

Through KDE Frameworks efforts, these libraries have been methodically reworked into a set of independent, cross platform modules that will be readily available to all Qt developers.

The KDE Frameworks—designed as drop-in Qt Addons—will enrich Qt as a development environment with functions that simplify, accelerate and reduce the cost of Qt development. Frameworks eliminate the need to reinvent key functions.

In altre parole, pur rimanendo KDE-focused, il framework 5 potra' essere sfruttato anche da applicazioni non-KDE (purche' Qt) apportando vantaggi di sviluppo e integrazione a tutto tondo.

Ritengo che questa decisione potra' giovare enormemente alla diffusione di KDE: se uno sviluppatore trarra' beneficio dal Frameowkr 5 anche fuori dal contesto KDE sara' maggiormente invogliato a completare la migrazione verso il desktop.

La Nebula che avanza

E' passato molto tempo da quando iusavo Nebula, un framework di widget SWT estesi complessi atti a creare interfacce grafiche ricche e complete. Vedo che il progetto è andato avanti con determinazione, creando nuovi widget di transizione e tabelle che, a prima vista, sono ideali per programmi di interfacciamento con la borsa o mercati dinamici. Ahimé alcuni dei widget che avrei sempre voluto usare, come il CollapsibleButton sono ancora in fase di incubazione.

Sono convinto che il progetto Nebula sia molto importante, anche se probabilmente ha risentito dell'avvento delle interfacce web che hanno, in parte, semplificato e ridotto le richieste ai programmi desktop.

Source Code & Films

Ho trovato per caso un interessante sito che riporta diversi esempi (ben documentati) delle apparizioni di codice sorgente nei film piu' svariati. Penso che l'idea di chi usa tale codice sorgente sia quella di rendere il film piu' realistico senza dover fare la fatica di inventare qualcosa che assomiglia a del codice sorgente.

Ovviamente non puo' che trattarsi di codice Open Source!

Verso Emacs 24.4

Sono in trepida attesa del rilascio ufficiale della nuova minor release di Emacs, la 24.4, che promette molte novità interessanti.

E' possibile trovare diverse informazioni a riguardo sul planet ufficiale, ad ogni modo quelle che a colpo d'occhio mi stanno tenendo con il fiato sospeso sono:

• un sistema di bilanciamento delle parentesi degno di tale nome. Sono abituato ad usare il modo di bilanciamento di parentesi e virgolette, ma sinceramente non funziona molto bene se si forza uno sbilanciamento (ad esempio cancellando una parentesi). La nuova versione sembra essere finalmente completa dell'intelligenza necessaria a tenere il bilanciamento corretto;
• un modo uniforme e platform independent di massimizzazione della finestra;
• il modo di indentazione elettrico è ora il default, inoltre il modo di indentazione rigido si comporta un po' come in Org: le frecce consentono di spostare l'intero blocco di indentazione;
• eshell supporta ora molti comandi "visual", ossia che richiedono una modalità interattiva e non line-oriented;
• c'è un browser integrato in Emacs, e quindi non è piu' necessario installare moduli esterni;
• supporto alle notifiche di file (inotify o via glib), quindi questo dovrebbe risolvere la necessità di aggiornare buffer Dired aperti, anche se ancora non mi è chiaro se e come questa funzioni si attivi e come portarla su sistemi non Linux.

Intanto occorre portare pazienza, poi presto si potrà lanciare la compilazione di Emacs 24.4 per fare una prova su strada!

BlackHole FDW

Un interessante frammento di codice che vuole essere uno scheletro per la costruzione di nuovi Foreign Data Wrappers (FDW) per PostgreSQL. Una buona lettura per comprendere un po' meglio come PostgreSQL lavora internamente.

RAID: Redundant Array of IDiots!

RAID, ovvero Redundant Array of Inexpensive Disks.

Una sigla che tempo fa solo i sysadmin di alto livello conoscevano, e ora un acronimo che si trova sulla confezione di parecchie motherboard di fascia commodity.

Ne ho configurati tanti di sistemi RAID, sempre a livello enterprise. I primi software, perché l'I(nexpensive) è troppo spesso sinonimo di gratis. Poi sono arrivati i controller hardware, tanto costosi quanto veloci e affidabili. Sia chiaro, non mi sono mai pentito di un RAID software e, complice la fortuna, non ho mai avuto dei problemi che un softraid (ora md) o un GEOM non sia stato in grado di risolvere. E se oggi dovessi fare un RAID nuovo valuterei il software come primo investimento.

Ma questo post non è relativo a ciò che io penso del RAID, quanto alla esperienza accumulata vedendo sysadmins configurare RAID in modo piuttosto sconclusionato.

Pazienza fare il RAID fra dischi di taglio differente, dopotutto con un po' di lavoro su MBR ci si riesce ancora. Ma usare dischi di velocità differenti è veramente da virtuosi! 

Per non parlare di quando si tenta di fare un RAID con il numero sbagliato di dischi, o con troppi dischi di spare (comprare 8 dischi per fare un RAID con due dischi di spare, ad esempio). O di quando si pensa che un RAID 5 sia robusto quanto un RAID 6 e, per pura assunzione matematica, un RAID 10 è il top perché è semplicemente quello con il numero piu' alto...

E per finire: configurare una serie di dischi in un modo RAID per poi trovarsi con molto meno spazio di quello stimato. E pensare pure di aver fatto le cose giuste senza rendersi conto che si è solo sbagliato livello di RAID.

Altri laboratori PostgreSQL

E' comparsa la notizia di un laboratorio PostgreSQL basato su streaming replication, e subito la mente corre all'ottima esperienza dell'ITPUG Lab del PGDay.IT 2013. Anche se è facile notare le differenze: il nostro lab era destrutturato (ossia non si aveva una agenda rigida, ma i partecipanti erano liberi di scegliere gli argomenti da sviluppare) e non c'era la sponsorizzazione ufficiale di aziende (si ricadeva nell'ombrello ITPUG/PGDay.IT).

Sia chiaro, non voglio essere negativo riguardo a queste iniziative, anzi ritengo che queste siano il contributo maggiore alla community di utenti in questo momento (anche perché le unconference sono a mio avviso ancora troppo di basso livello per gli utenti). Spero solo di poter vedere altri laboratori con meno organizzazione e struttura formale, in modo da permettere veramente a tutti gli utenti di avvicinarsi, comprendere e apprezzare PostgreSQL.

Giocare su Linux o attraverso Linux?

Valve, la nota casa di videogiochi, sta realizzando un nuovo sistema operativo, denominato SteamOS (il nome deriva dalla piattaforma di gioco Steam). Il sistema si basa su una distribuzione Debian (quindi GNU/Linux) modificata per essere usata come piattaforma multimediale e di gioco.

L'esperimento è sicuramente interessante e compete, da un certo punto di vista, con lo sforzo di Sony per rilasciare la sua piattaforma di gioco su FreeBSD. In effetti mi pare piu' sensato l'utilizzo di FreeBSD per questioni di licenza, anche se devo ammettere che GNU/Linux è sicuramente piu' evoluto dal punto di vista multimediale (ma solo per il supporto hardware).

In ogni caso l'Open Source si sta affermando sempre di piu' come piattaforma pervasiva.

Il bug numero uno di Ubuntu

Per caso sono stato rimbalzato al bug numero 1 di Ubuntu, e una cosa che non ha direttamente a che fare con il software rilasciato da Canonical....una curiosa e interessante lettura.