Quello che i linuxari non hanno capito

Volete identificare un assoluto, incommensurabile cialtrone, uno che avrebbe bisogno di una raccomandazione di ferro per fare il vice-assistente spazzino? Chiedetegli cosa pensa di Linux. Se comincia a spiegarvi che il supporto della comunità, che la libertà di modificarlo, che non hai la pappa pronta come con Microsoft, che lo devi capire a fondo per farlo funzionare, eccetera, statene alla larga. E' un cialtrone senza vergogna.

Cari sviluppatori, evangelisti, consulenti opensource e chi più ne ha più ne metta, lasciate che vi spieghi una cosina semplice semplice.

Io adoro andare in bicicletta. Adoro usarla per andare dal punto A al punto B, per fare esercizio, per fare delle cose. Non la uso allo scopo di far girare le ruote. Che le ruote girino senza bisogno di interventi costanti é una necessità basilare perché la bicicletta sia utilizzabile. Se delle 3 ore in cui uso la bicicletta ne dovessi passare 2 e mezza a metterla in condizioni di funzionare, non andrei in bicicletta: perché la bicicletta é un mezzo, non un fine. Ci sarà sicuramente un sacco di gente che ha l'hobby di assemblare, modificare e riconfigurare in continuazione la propria bicicletta - e magari gente che fa solo quello e in realtà poi in bici neanche ci va; ma io ho comprato una bicicletta allo scopo di usarla

Per dirne un'altra, adoro avere una lavastoviglie. Ancora, non adoro avere una lavastoviglie allo scopo di consumare tempo e sforzo intellettuale per farla funzionare: il mio piacere non sta nella sfida di far funzionare la lavastoviglie, ma nel fatto che la lavastoviglie faccia delle cose. Non discuto che esista gente che ha l'hobby di costruire e riparare lavastoviglie, ma non é quello il motivo per cui io - e, sospetto, al maggior parte degli acquirenti di lavastoviglie - l'ho comprata.

Io non ho un computer all scopo di passare il mio tempo a cercare di farlo funzionare. Io ho un computer perché ci faccio (o ci vorrei fare) delle cose. E quando in una settimana mi ritrovo a pensare per tre volte "grazie al cielo ho anche una macchina Windows, così posso usarla per googlare i sintomi e vedere cos'altro é successo alla linux box", vuol dire che c'é qualcosa di catastroficamente sbagliato in Linux.

P.S. L'eventuale àchero sopraffino e 1337 che dovesse passare di qui e dovesse essere tentato di ribattere che se sono troppo ignorante per capire la superiorità di Linux e modificarlo a mio piacimento per far funzionare le cose che non funzionano, posso solo rispondere che ha centrato esattamente il problema, e finalmente e definitivamente spiegato perché negli ultimi 10 anni Linux sul desktop é rimasto sempre la stessa mosca bianca. Nonostante Vista.

Se le auto fossero open source

Tutti conoscono quella vecchia storiella (falsa, ovviamente) in cui Bill Gates avrebbe detto, durante un intervento al COMDEX, che se l'industria automobilistica avesse cavalcato il progresso tecnologico bene quanto l'informatica, oggi le auto costerebbeto 30 dollari e farebbero 3000 chilometri con un litro di benzina, ricevendo come risposta l'osservazione che, se l'industria automobilistica avesse seguito lo stesso percorso di quella informatica:

1) Le auto si schianterebbero due volte al giorno per nessuna ragione apparente.

2) Ogni volta che rifanno la segnaletica orizzontale bisognerebbe comprare una nuova auto.

3) A volte, eseguire una normale manovra come svoltare a sinistra farebbe irreversibilmente spegnere l'auto e non ci sarebbe altra via d'uscita che reinstallare il motore.

4) Ogni volta che l'auto si spegne senza ragione in autostrada, gli automobilisti dovrebbero essere preparati a riavviarla senza protestare ed accettare il fatto come una normale parte di qualsiasi viaggio.

5) In auto ci potrebbe essere solo una persona per volta, salvo comprare Car95 o CarNT [la storia e' vecchiotta, NdE] ed acquistare a parte sedili supplementari.

6) Apple produrrebbe un'auto ad energia solare, affidabile, cinque volte piu' veloce e due volte piu' facile da guidare, ma costerebbe 100 volte di piu' e potrebbe viaggiare solo sul 5% delle strade [ed eseguire solo le manovre che Steve Jobs approva, NdE].

7) Le spie di olio, temperatura e alternatore verrebbero sostituite da una singola spia di "errore irreversibile dell'automobile".

8) I sedili sarebbero conformati in modo da costringere tutti ad avere il sedere delle stesse dimensioni.

9) L'airbag chiederebbe "Sei davvero sicuro? SI/NO" prima di gonfiarsi.

10) Occasionalmente, e per nessuna ragione apparente, l'auto vi chiuderebbe fuori e si rifiuterebbe di farvi rientrare a meno che afferriate l'antenna della radio mentre girate la chiave e tirate la maniglia dello sportello.

11) Ogni volta che un nuovo modello viene introdotto, bisognerebbe reimparare a guidare perche' nessuno dei controlli funzionerebbe alla stessa maniera di prima [questo gia' succede se si compra un'auto francese, NdE].

12) Bisognerebbe premere il bottone "Start" per spegnere il motore.

Tutto vero e divertente, ma in realta' ci dice solo cosa succederebbe se l'industria automobilistica avesse seguito il pattern di sviluppo di Microsoft (ed Apple, vedi punto 6), non quello dell'industria informatica in generale.

Sono sicuro che alcuni dei miei colleghi seduti ad una o due scrivanie da me potrebbero raccontarvi cosa sarebbe oggi l'industria automobilistica se avesse seguito il pattern di sviluppo dei mainframe IBM - ad esempio, ne sono certo, che l'auto puo' svoltare solo se una formale richiesta di cambio di direzione viene presentata due giorni prima ed approvata da tutti i passeggeri; ma da stamattina ho cominciato a chiedermi cosa succederebbe se l'industria automobilistica fosse open source. Linuxiana, diciamo. L'idea, onestamente, mi riempie di terrore.

1) Le auto sarebbero distribuite gratuitamente. Chiunque sarebbe in grado di assemblarle in modo che riescano a fare il giro dell'isolato prima di perderne completamente il controllo e doverle ricostruire da zero. Pochi, strapagati ingegneri diventerebbero ricchi assemblando auto personalizzate per i clienti che hanno bisogno di arrivare dal punto A al punto B senza esplosioni.

2) Ogni auto avrebbe comandi radicalmente differenti: alcune avrebbero uno sterzo, alcune una cloche, alcune una colonna di controllo e una pedaliera come gli elicotteri, alcune una tastiera con cui introdurre l'angolo di cui si intende variare la direzione attuale. In radianti. Senza una macro per pigreco.

3) Ogni scelta costruttiva verrebbe difesa ad oltranza come l'unico modo logico in cui una persona anche solo lontanamente sana di mentre potrebbe voler controllare un veicolo, salvo essere abbandonata nella versione successiva.

4) Quasi nessuna auto avrebbe un manuale di istruzioni. Gli acquirenti verrebbero incoraggiati a passare il proprio tempo in un'apposita stanza della concessionaria, in cui tutti gli altri guidatori discutono delle varie caratteristiche di quel modello e/o di altri modelli simili, nella speranza di cogliere un brandello di conversazione inerente a quel che desiderano sapere.

5) Nelle poche auto che ne hanno uno, il manuale di istruzioni raramente conterrebbe le informazioni a cui siamo abituati. Piuttosto, sarebbe costituito da una trattazione di 3-4 pagine sulle proprieta' chimiche dello strato di vernice antiruggine, da una dettagliata spiegazione su come svitare i bulloni per cambiare una gomma, e da 10 pagine di minuta descrizione del funzionamento delle serrature degli sportelli, con un rapido excursus sulla teoria e storia delle chiavi e delle tecniche del loro intaglio [per chi pensasse che questa e' un'esagerazione, vi invito tutti a dare un'occhiata alla "documentazione" di quello che sta diventando lo standard open source per la gestione dei data center, RackTables. Che e' una fantastica applicazione, beninteso. NdE].

6) Ad ogni automobile mancherebbero delle caratteristiche essenziali. I progettisti ovvierebbero alla mancanza in maniere che renderebbero orgogliosi Dastardly & Muttley. Ad esempio alcune auto sarebbero incapaci di svoltare a sinistra, ma verrebbero modificate con un complicato sistema di regolazione della velocita' e freno a mano servoassistito per andare in testacoda (semi)controllato e cambiare orientamento verso sinistra quando necessario.

7) L'autoradio di UbuntuCar si guasterebbe ogni volta che si fa benzina o si cambia l'olio.

8) RHELCar sarebbe open source, ma dovreste pagare una fortuna per fare benzina o gonfiare le gomme.

9) Molti guidatori sarebbero fieri ed orgogliosi di fare gratis da manichini per crash-test in FedoraCar e deriderebbero i "servi delle multinazionali" che pagano per godere dei risultati dei crash-test in RHELCar.

10) Dopo ogni incidente non potreste mai dare la colpa a guasti meccanici o difetti dell'auto, pena essere circondati da progettisti, ingegneri e altri automobilisti che vi sottopongono ad un linciaggio morale e vi accusano di essere troppo stupidi per godere del privilegio di guidare un'auto open source. Dovreste invece sottoporvi ad un rituale di purificazione in cui sostenete che il posto ideale per mettere una mina antiuomo e' in effetti proprio sotto l'acceleratore, e vi scusate per essere stati cosi' stupidi da non capirlo prima.

11) Richard Stallman al posto di Enzo Ferrari. Non dico altro.

Breve corso di management

Andate a lavorare per un Application Service Provider. Dato che, per la natura del business, un ASP avrà un gran numero di clienti, assicuratevi che per ogni cliente si costruisca una nuova applicazione da zero, non curandovi del fatto che il tipo di applicazione è sempre lo stesso. Il riutilizzo del codice è per i pigri.

In particolare, visto che la piattaforma è costituita da un front-end Windows e un back-end Linux, non assumete specialisti Linux: fate il massimo sforzo possibile per uniformare e standardizzare la parte Windows e mettete insieme la roba Linux un po' come viene e quando serve. A questo stadio è essenziale non avere più di due o tre server con la stessa versione della stessa distribuzione Linux.

Abbiate cura, in questa fase, di non limitarvi a creare una diversa applicazione per ogni cliente: preoccupatevi di usare diverse metodologie per risolvere gli stessi problemi. Per alcune applicazioni, recuperate i dati dal sito o da un feed del cliente; per le altre, ignorate l'esistenza di un analogo sito e costringete il cliente a inviare i dati via FTP una volta al giorno, e costruite una complessa architettura tutta basata su cron script, avendo cura che fallisca miseramente e in maniera assolutamente silenziosa se il cliente invia i dati alle 9:05 invece che alle 9. I cron job, poi, dovranno essere a volte in una directory dedicata inclusa nell'applicazione, a volte in una directory dedicata sotto /root, a volte nella home directory dello sviluppatore (esportata all'uopo via NFS dai server di sviluppo a quelli di produzione), a volte su un diverso server messo su alla bisogna; ed eseguiti ora dall'utente root, ora da un utente standard comune a tutte le macchine, ora dall'ID dello sviluppatore che li ha creati. Altre volte ancora, scrivete un daemon che interroghi ogni 48 secondi un server FTP del cliente e prelevi i dati trasferendoli poi su uno share da cui cron script che girano su un'altra macchina ancora li prelevino e li sottopongano all'applicazione. Non usate mai un solo server per un'applicazione quando potete distribuirla su un numero casuale di macchine in diversi hosting centre. Non usate mai un database quando potete salvare decine di migliaia di file su un fileserver, indicizzati esclusivamente per data di creazione. Non usate mai un singolo logfile quando potete salvare centinaia di migliaia di file di testo, uno per ogni singola transazione, su un fileserver, assicurandovi che l'ID della transazione non venga mai salvato all'interno del file ma solo nel suo nome, per semplificare l'aggregazione dei dati.

In uno sforzo verso la standardizzazione delle applicazioni web, imponete che tutte le opzioni di configurazione vengano impostate in un singolo file, sempre lo stesso per ogni applicazione. Accertatevi che metà delle funzionalità vengano attivate settando il parametro corrispondente a 1, l'altra metà settandolo a 0. Non fate documentare nulla: che bisogno ce n'è, quando lo sviluppatore sa già quali sono i valori giusti?

Spalmate tutta l'infrastruttura, back-end e front-end (distribuita su quattro diverse locazioni), su un'unica rete classe B senza segmenti. Mostrate sorpresa quando gli hub esplodono e/o fondono o il traffico si strozza a 1 byte per secondo. Mostrate ulteriore sorpresa alla scoperta del concetto di latenza.

Una volta arrivati al magico numero di 200 macchine per il back-end, assumete un sistemista Linux. A partire dal terzo giorno, dategli la colpa di tutto quello che va storto. Quando, dopo sei mesi, si dimette, accusatelo di scarsa professionalità e annunciate che in ogni caso fra un mese o due sarebbe stato licenziato per manifesta incompetenza.

Assumete un nuovo sistemista Linux. Dategli l'incarico di standardizzare l'infrastruttura. Quando annuncia che è impossibile farlo nei tempi desiderati (settimane) senza causare falle nei servizi, licenziatelo. Scoprite di non avere avuto una giusta causa. Pagategli un cospicuo indennizzo.

Assumete un nuovo sistemista Linux. Dategli dello stronzo senza ragione ogni mattina. Dategli nuovamente dello stronzo per la ragione che dopo tre giorni non si è più presentato al lavoro.

Assumete un nuovo sistemista Linux. Licenziatelo il giorno prima che entri effettivamente in servizio perchè avete dovuto pagare una multa colossale per violazione di alcune regolamentazioni sulle telecomunicazioni. Mostrate sorpresa quando scoprite che invece di tagliare i costi, con quest'astuta mossa gli avete dovuto pagare una penale che levati, e siete ancora senza sistemista.

Assumete un nuovo sistemista Linux. Dategli la colpa di tutto dal giorno prima di assumerlo. Dategli il compito di portare ogni singolo server allo stesso standard, e contemporaneamente vietategli di standardizzare i server perchè la loro configurazione deve rispecchiare i compiti specifici che devono svolgere. Accusatelo di insufficiente elasticità per non aver capito quello che volevate dire con la frase precedente. Incaricatelo di segmentare la rete. Vietategli di segmentare la rete. Incaricatelo di creare un accesso VPN per permettervi di lavorare da casa. Mandategli una lettera con minaccia di licenziamento per aver creato un buco di sicurezza gravissimo con un accesso VPN che è stato violato quasi immediatamente, a causa del keylogger/bot che gli alieni avevano teletrasportato sul vostro laptop personale con cui pretendevate di collegarvi da casa. Chiedetegli di trasferire tutti i cron job di ogni singolo server su una macchina centrale di servizio da cui dovrebbero poi accedere al server desiderato ed eseguire le azioni necessarie. Dopo due giorni, lamentatevi perchè "ancora non sei riuscito a mettere insieme quella che dopotutto è una semplice crontab".

Assumete un junior sysadmin. Mostrate sorpresa quando vi fa notare che al colloquio nessuno aveva parlato di "portare quotidianamente il caffè ai manager in riunione" come uno dei suoi compiti.

Continuate a sfornare applicazioni ognuna diversa dalle altre e accusate i sistemisti di scarsa professionalità se non riescono a tener dietro a tutte le dipendenze, minuzie e idiosincrasie rigorosamente non documentate di ognuna.

In nome di una maggiore standardizzazione, adottate due diversi database come standard e lasciate assoluta libertà agli sviluppatori di utilizzare l'uno, l'altro o entrambi. Fate girare tutte le istanze di uno sotto Linux, alcune istanze dell'altro sotto una diversa distribuzione di Linux e altre sotto Windows (2000, XP e 2007 Server). Se tutte le applicazioni devono salvare certi dati critici per il business in un database comune, create lo stesso database su ognuna delle tre piattaforme e offrite agli sviluppatori assoluta libertà di scelta, creando poi una complessa architettura al solo scopo di replicare i dati di quel database attraverso tre piattaforme.

Quando un tecnico del supporto vi chiede di mandarlo a fare un corso su Linux, accettate. Addebitategli il costo del corso sullo stipendio, ostentando sorpresa quando lui lo scopre e s'incazza.

Mandate un'altra nota disciplinare/minaccia di licenziamento al senior sysadmin quando una delle vostre applicazioni web viene penetrata. Rifiutatevi di ritirarla quando lui vi fa notare che l'applicazione era stata messa in linea da uno sviluppatore, su vostra autorizzazione, e a sua insaputa perchè utilizzava una piattaforma con vulnerabilità note e ampiamente sfruttate di cui lui aveva espressamente vietato l'installazione. Controbattete che comunque lui è alla fine responsabile di quei sistemi.

Accusatelo di scarsa professionalità quando si dimette.

Restate sei mesi senza senior sysadmin. Accusate il junior sysadmin di generica incompetenza e restringete il più possibile le sue mansioni all'ordinaria manutenzione. Vietate esplicitamente al tecnico di supporto che ha fatto il corso per la certificazione Linux anche solo di toccare una macchina Linux. Fate curare l'installazione e il setup di nuove applicazioni e di nuovi server Linux agli sviluppatori che ne hanno voglia, quando ne hanno voglia.

Assumete un nuovo sistemista Linux. Durante il colloquio, rispondete di sì a tutte le sue domande, soprattutto a quelle relative all'esistenza di un ambiente di test, alla pianificazione dei rollout, alle procedure formali di hand-off delle applicazioni, al sistema di ticketing per il supporto. Non importa che non abbiate idea di cosa stia parlando: è essenziale rispondere di sì a tutto.

Dategli come primo compito quello di riordinare i cron job e gli script che fanno variamente funzionare (o no) ognuna delle applicazioni. Dategli come secondo compito quello di portare tutti i server allo stesso standard per sistema operativo, software installato e versione delle librerie. Per facilitargli la vita, dopo il primo mese licenziate il junior sysadmin e il tecnico di supporto con la certificazione Linux, con la doppia giustificazione (resa pubblica) che comunque Linux è stabile e non ha bisogno di supporto continuo, e che i soldi per lo stipendio del senior sysadmin da qualche parte devono pur uscire.

Quando il sistemista crea una procedura automatica che permette di sfornare un numero arbitrario di server perfettamente standard in un'ora, passate due giorni a farvi spiegare ogni riga dello script kickstart, il funzionamento di DHCP e TFTP, fraintendete tutto il fraintendibile, lamentate che un'ora è troppo, lamentate che non è PCI-compliant, mostrate sorpresa quando scoprite che lo è, fatevi rispiegare cosa significa PCI-compliant, pretendete che ogni singola riga vi venga spiegata nuovamente alla luce di quel che avete appena imparato, mettendoci altri due giorni, e alla fine mandate un'email di fuoco al sysadmin (in copia al resto del management e alle risorse umane) perchè ha finalizzato la procedura una settimana fa, millantandone la velocità, e in una settimana non è riuscito a mettere in linea neanche un server.

Per ogni server portato allo standard, lamentate rumorosamente e pubblicamente sia il troppo tempo speso, sia il tempo insufficiente dedicato al testing. Durante il processo di aggiornamento, rifiutatevi di fornire qualsivoglia informazione sul testing. Chiarite subito che il tempo degli sviluppatori è troppo prezioso e il testing di ogni aspetto (non documentato) delle applicazioni deve essere eseguito dal sysadmin.

Siate apertamente e pubblicamente sospettosi della lealtà del sysadmin per aver avuto precedenti rapporti di lavoro con un cliente molto importante. Quando il sysadmin risolve (ripetutamente) casini che avevano messo a rischio il contratto con quel cliente, accusatelo pubblicamente di essere più leale al cliente che alla compagnia per cui lavora, portando come prova una mail del cliente che ringrazia tutti "e in particolare il sysadmin" per il magnifico lavoro svolto. Mettete il sysadmin a completa disposizione di quel cliente. Fatelo sbattere ripetutamente in giro per l'Europa a risolvere casini accessori del cliente. Accusatelo al suo ritorno di trascurare il lavoro.

Accusate il sysadmin (e gli altri tecnici senior) di scarsa professionalità ed incompetenza, pubblicamente, se possibile sulla lista di distribuzione interna della compagnia, per ogni svista o omissione, anche e soprattutto se priva di conseguenze (e.g. aver usato "reply" invece che "reply all" in uno scambio di email), dilungandovi su tutti i motivi per cui queste sviste denotano che non sono affidabili, mancano di competenza e probabilmente molestano i bambini.

Pretendete di avere l'ultima parola su ogni dettaglio di ogni decisione tecnica. Indite meeting di quattro ore per discutere il fatto che un default gateway abbia indirizzo .1 piuttosto che .254.

Pretendete di continuare ad usare nastri DLT da 20 Gigabyte per il backup di una SAN da 16 Terabyte, perchè "il backup funzionava benissimo prima che comprassimo la SAN". Imponete al sysadmin di chiamare il supporto del produttore della SAN e protestare perchè "la SAN ha rotto il sistema di backup".

Stupitevi della perplessità del sysadmin davanti ad un cron job che riavvia un certo daemon (in produzione) ogni minuto, giustificato con "yes, the daemon is a bit flaky, you know". Informatelo che lo sviluppatore ha cose più importanti da fare che trovare qualche stupido bug di un daemon che comunque se viene riavviato regolarmente non causa quasi nessun problema.

Se è un giorno lavorativo dove vi trovate voi, aspettatevi che la gente sia al lavoro anche se nel loro Paese è un giorno di festa. Se siete a Londra, fate una sfuriata agli sviluppatori francesi (sul telefono di casa di ognuno di loro, in teleconferenza) perchè non sono al lavoro il 14 luglio o a Ferragosto. Se siete in Francia, fate una sfuriata agli inglesi che non sono al lavoro ogni Bank Holiday Monday.

Non sforzatevi troppo a cercare di imparare a parlare inglese. Quando non capite qualcosa, potete sempre fare una sfuriata a chi vi sta di fronte e parla un inglese "inutilmente complicato" - ma solo dopo che eventuali malintesi hanno causato danni irreparabili. Non siete mica Shakespeare, come si può pretendere che sappiate che "indeed" significa "esatto, proprio così"?

Il giorno in cui il governo dichiara che chi si prende l'influenza suina deve restare a casa per due settimane, annunciate che i giorni di malattia pagati sono ridotti da quindici a dieci all'anno. Accusate chi viene al lavoro con la febbre di essere distratto e taciturno perchè non ha voglia di lavorare. Quando alla fine uno dei tecnici del supporto finisce in ospedale con la polmonite, abbiate cura di telefonargli per chiarire che i giorni pagati sono comunque dieci indipendentemente dalla gravità della malattia. Visto che ci siete, accusate il sysadmin, che vi fa notare la mancanza di tatto, di aver fomentato una cultura del relax e del dolce far niente fra i membri del suo team.

Licenziate poco meno di metà del personale tecnico della compagnia in un mese, al ritmo di uno al giorno o quasi. Mostratevi scandalizzati ed offesi quando scoprite che qualcuno degli ultimi aveva mandato in giro il proprio CV prima di essere licenziato. Accusateli di scarsa lealtà. Ringraziate pubblicamente i superstiti per la loro lealtà e dedizione. Licenziatene due il giorno dopo. Rimpiazzate tutti i licenziati con diciannovenni americani (inviati dalla nuova proprietà) e francesi (figli di vecchi compagni di scuola) e date la colpa ai "vecchi" per ogni sopravvenuta inefficienza.

Celebrate il fatto che siete riusciti a perdere personale più rapidamente di quanto abbiate perso clienti, realizzando così un profitto col taglio dei costi nonostante il crollo del fatturato. Proclamate che questo prova l'oculatezza della vostra strategia ed un segnale positivo per il futuro.

Mostratevi esterrefatti e feriti negli affetti quando metà dei "vecchi" superstiti si dimettono.

Prendete ogni lamentela dei clienti riguardo alle sopravvenute inefficienze come un attacco personale condito di insinuazioni sulla verginità delle vostre figlie. Per ripicca, cancellate contratti su contratti con i clienti. Fate una sfuriata a chi vi fa notare che rifiutare i soldi di un cliente non è una ripicca efficace.

Riprendete il sysadmin per aver usato la pausa pranzo per pranzare invece di lavorare.

Quando il sysadmin si dimette, accusatelo di scarsa lealtà e competenza, e annunciate che comunque il suo stipendio non era affatto giustificato e sarebbe stato licenziato presto, perchè di un sysadmin Linux non ce n'è veramente bisogno.

Assumete un sistemista Linux... (ad libitum, o fino al fallimento)

Ubuntu! (e due)

Per i fortunati possessori di un netbook Compaq mini 700 (non troppo rari, da queste parti - è il netbook che Three regala quando si sottoscrive un contratto dati), due righe di consigli su cosa fare per installarci una distribuzione che si suppone essere user-friendly.

In primo luogo, la connessione di rete. Se c'è un modo per far funzionare Ubuntu 9.10 con le schede di rete del mini 700, io ancora non l'ho trovato. Se installate da zero Ubuntu 9.10, non sembra esserci modo di farle funzionare affatto (sebbene i driver vengano caricati correttamente e lspci identifichi entrambe le schede). Dovete dunque installare Ubuntu 9.04 e poi aggiornare a 9.10, per provare il piacere di avere un netbook funzionante per circa due riavvii e/o un aggiornamento del kernel, prima che Ubuntu, per suoi motivi misteriosi, rinomini la vostra scheda wireless "eth1_renamed" e smetta di riconoscerla. A quel punto (saranno passati circa due giorni) vi tocca ricominciare da zero.

Potreste rimanere con Ubuntu 9.04, che funziona perfettamente col problema, relativamente minore, che non ha audio. Il problema si risolve scaricando i sorgenti di alsa-driver, alsa-lib e alsa-utils e ricompilandoli a mano (./configure && make && sudo make install in ciascuna delle tre directory). Il processo porta via poco meno di mezz'ora e va ripetuto (premettendo un make clean) ogni volta che il kernel viene aggiornato.

L'alternativa è Kubuntu, con qualche accortezza. Intanto, assicuratevi di avere il netbook connesso con l'alimentatore fin dal momento del riavvio: altrimenti Kubuntu non riconosce la scheda di rete (quella fissa). Problema minore, direte voi, tanto io sul netbook conto di usare solo la wireless: e qui casca l'asino, perchè Kubuntu non ha i driver della scheda wireless e deve scaricarli dalla rete - utilizzando la scheda wired.

L'interfaccia utente di Kubuntu Netbook Remix non è delle migliori (spero che la versione definitiva, attesa per il prossimo anno, sia almeno marginalmente utilizzabile). La lista delle applicazioni è dinamica e viene gestita in maniera piuttosto oscura, spostando le icone, mi pare, in base alla frequenza d'uso delle varie applicazioni; non sembra possibile modificarla in alcuna maniera, non esiste, come in Ubuntu Netbook Remix, un pannello dei "favorites" dove piazzare in permanenza le applicazioni più usate - il pannello superiore sembra essere adibito ad una funzione simile, ma l'utente non può controllarlo, mi par di capire che il sistema ci piazzi le applicazioni usate più di frequente, ma all'atto pratico sembra che le icone appaiano e scompaiano in maniera più o meno casuale. La cosa più curiosa di tutte però l'ho vista nel pannello delle applicazioni per Internet. Sotto l'icona di Firefox (con la dicitura "Mozilla Firefox Browser") si trova in realtà uno script che cerca di installare Firefox anche se è già installato. Per far comparire un'icona corrispondente in effetti a Firefox bisogna lanciare l'installatore almeno una volta e poi riavviare il computer. Al riavvio, ci saranno due icone di Firefox, quella giusta è quella con la dicitura "Firefox Web Browser", a cliccare sull'altra si finisce semplicemente a cercare di reinstallare Firefox all'infinito.

Tanto per non farvi sentire la mancanza di Ubuntu, anche in Kubuntu l'audio non funziona. C'è stato il grande passaggio a Pulse come infrastruttura audio unificata, e il team di Kubuntu lamenta (giustamente) che un sacco di applicazioni fanno casino perchè cercano di usare ancora Alsa; dunque, per facilitare la vita a tutti, hanno stabilito dei default che assicurano che nessuno dei due sistemi funzioni correttamente.

Per far funzionare l'audio dovete

• andare in system -> system settings, selezionare multimedia e per ogni voce spostare "Pulse Audio" al primo posto nella lista. Dal momento che Pulse è adesso l'infrastruttura base per KDE4, hanno pensato bene di non farlo utilizzare per default da nessuna applicazione a meno che non andiate a spostare le preferenze a manina. Geniale
• installare una serie di pacchetti. Andate a linea di comando, risparmiate tempo: sudo apt-get install libasound2-plugins "pulseaudio-*" paman padevchooser paprefs pavucontrol pavumeter e poi sudo vi /etc/asound.conf (che non esiste) mettendoci dentro quanto segue:
  

  pcm.pulse {
      type pulse
  }
  ctl.pulse {
      type pulse
  }
  pcm.!default {
      type pulse
  }
  ctl.!default {
      type pulse
  }

• A questo punto (dopo un riavvio) in realtà funziona tutto, ma non potete accorgervene perchè tutti i componenti che utilizzano Alsa (via un plugin che ridirige l'output di Alsa a Pulse) hanno il volume pressochè azzerato e non c'è modo, dall'interfaccia, di cambiarlo. Tornate al terminale ed eseguite alsamixergui che vi permetterà di regolare il master volume delle applicazioni che usano Alsa

Non sono ancora riuscito a capire come far funzionare la webcam (per ora non si accorge neanche della sua esistenza) e purtroppo, a differenza di Ubuntu Netbook Remix, non sembra esserci un modo per liberarsi dell'atroce interfaccia utente per passare a quella regolare di KDE. Anche l'audio MIDI, per ora, non sembra funzionare, quindi scordatevi i vecchi giochi MS-DOS in Dosbox/Dosemu. Per il resto sembra ragionevolmente stabile e la procedura di installazione e configurazione è piuttosto semplice in confronto, per esempio, a cercare di suonare il pianoforte con i testicoli.

Random rant

Penso che ci sia un girone speciale dell'inferno dedicato a quelli che decidono che il default per una funzione di ricerca debba essere "OR". Meglio ancora, dal momento che non credo nell'aldilà, sarebbe un enorme campo di lavoro volontario in Siberia in cui venisse loro spiegato da amorevoli guardiani mongoli, equipaggiati con robusti manganelli con punta-taser (come in Blade 2), che NESSUNO su questo cazzo di pianeta quando cerca "to-do list" sta cercando tutti gli elementi che contengano "to-do" oppure "list".

È venerdì, e si vede

Certe volte le mie discussioni col management hanno del surreale, soprattutto quando coinvolgono il Gentile Concessore Francese e, per qualche motivo, specialmente di venerdì.

Gentile Concessore Francese: Eugenio, per quando possiamo avere questi blade server pronti all'installazione?

Io: Guarda, c'è solo da avviarli da CD e puntare ogni blade al kickstart server, il resto dell'installazione è automatica

GCF: Ah, forse non te l'ho detto, ho modificato l'ordine all'ultimo momento ed ho ordinato tutti i Blade Center senza CD, abbiamo risparmiato quasi 120 sterline [su un ordine da quasi 100.000 sterline, NdE]

Io: Ah, vabbe', non c'è problema, infilo i loro indirizzi MAC nel server DHCP e li installiamo via tftp.

GCF: No, mi spiace, non possiamo, quando ho cambiato l'ordine ho anche deciso di ordinare separatamente i moduli switch per ragioni fiscali e arrivano la prossima settimana, poi con la consegna ritardata Dell ci fa anche uno sconto - tanto non ci servono fino a quando abbiamo bisogno di attaccarli alla rete di produzione.

Io: Vabbè, hai una calamita da frigo? Mi metto lì ed edito a mano gli inode dei dischi rigidi...

GCF: Non scherzare! Com'è possibile che ci abbiano venduto delle macchine su cui non si può installare un sistema operativo?

Io: Posso sempre provare a installare CentOS su una chiavetta USB ed avviare ogni blade in successione da lì. Ci copio sopra anche i file kickstart o magari seleziono i pacchetti a mano uno per uno e faccio anche a mano le modifiche NIST a tutti i file di configurazione...

GCF: Davvero?

Io: No.

GCF: Ma abbiamo bisogno di quei server pronti e in produzione entro venerdì prossimo!

Io: Quando arrivano gli switch?

GCF: Venerdì prossimo.

Io: Allora uno di noi due ha delle spiegazioni da dare.

Ahh, che relax, quando la tua giornata lavorativa è terminata da 4 minuti e 30 secondi, è venerdì e un managerone due livelli sopra il tuo si affanna a cercare di darti la colpa di non averlo protetto dalla sua stupidità di fronte ad un pubblico sempre più incredulo.

You can't have too much of a good thing

Linux è figlio della New Economy, e si vede. Nessun altro pezzo dell'Information Technology è così stracolmo di ritardati, sociopatici, farlocchi, teste di cazzo che si sono inventate un mestiere in un momento particolare di ubriacatura collettiva in cui l'unica qualifica necessaria per essere un manager, un tecnico, un esperto di qualsiasi cosa era di riuscire a mantenere una faccia seria mentre affermavi di esserlo.

Il motivo per cui lavorando su Linux riesco a farmi pagare bene è semplicissimo: a differenza del 99% dei cosiddetti "esperti", non mi invento cazzate, non millanto fantasmagorici risultati inesistenti, ma, semplicemente, se mi chiedono di fare una cosa dico che si può fare solo se so di poterla fare fottendomene di quello che dice la documentazione (che tanto è in buona parte frutto di fantasia) e di quel che si dice sui forum degli "esperti", e se non si può fare lo dico, prendo la borsa, me ne vado ignorando le accuse di incompetenza e disfattismo, e torno due settimane dopo per riparare ai danni causati da un farlocco che sosteneva che si poteva fare perchè l'ha letto su Ubuntuforum.

Incidentalmente, neanche Microsoft è mai riuscita nell'impresa di prendere un prodotto che funziona su un certo hardware, farne una nuova versione dedicata a quell'hardware e introdurre un bug che lo rende inutilizzabile, come ha fatto Ubuntu con il suo "netbook remix".

Ubuntu!

(post per linuxari)

Devo dire che non sono sorpreso che Canonical, la compagnia che sta dietro a Ubuntu/Kubuntu/Xubuntu/Edubuntu, sia inglese. Riconosco lo stile, quell'orgoglio che sta dietro alla produzione di oggetti e servizi assolutamente agghiaccianti, lo stesso orgoglio che fa venire i lucciconi agli occhi ai più anziani quando ti raccontano di che gioiello dell'ingegneria inglese era la BSA, e di come usciva invariabilmente di strada se frenavi mentre curvavi a sinistra, come Lawrence d'Arabia avrebbe potuto testimoniare se avesse ripreso conoscenza.

NON ho ovviamente aggiornato a 9.04 le macchine con cui lavoro, ma approfittando di un po' di tempo da perdere, venerdì ho fatto un upgrade e/o un'installazione pulita su un po' di macchine che avevo sottomano, giusto per vedere cosa succedeva.

Il primo é stato un vecchio portatile IBM, un T23 con Ubuntu 8.10. L'upgrade via internet é andato benissimo, nel senso che é andato ogni volta in crash prima di cominciare effettivamente ad aggiornare la macchina, prevenendo quindi ogni danno da installazione incompleta. Anche apt-get dist-upgrade subiva lo stesso destino. Un upgrade dall'Alternate CD ha avuto successo. Ubuntu 9.04 gira senza apparenti problemi su un vecchio PIII con 512MB di memoria, naturalmente senza alcun tipo di effetti speciali.

Il secondo é stato un computer figlio di nessuno, una macchina Frankenstein assemblata con pezzi avanzati. Aveva Kubuntu 8.10. adesso ha Kubuntu 9.04, upgrade via Internet senza problemi. Kubuntu gira, kded usa il 100% di uno dei due cores per il 100% del tempo per nessuna ragione apparente, Plasma continua a crescere e crescere in memoria fino a papparsi 3-4 GB fra RAM e swap e costringere al reboot in media ogni 48 ore. Niente di nuovo rispetto alla 8.10 dunque.

Il terzo e il quarto sono stati un paio di Dell Optiplex GX620 che avevo qui sulla scrivania in attesa di essere usati per qualcosa di serio. Uno era pulito, l'altro aveva Kubuntu 8.10. Per qualche ragione sul primo l'installazione é stata un completo successo ma il sistema semplicemente non parte - o meglio, parte, ma in una modalità grafica che credo sia CGA 320x200 a 4 colori (no, la scheda grafica, una Radeon X600, non é saltata, Knoppix funziona perfettamente). Ripetute reinstallazioni non hanno sortito alcun miglioramento. L'upgrade dell'altro (identico hardware) é andato a catafascio a circa metà installazione: lo schermo si é semplicemente spento e buonanotte a tutti. Inutile dire che é stato necessario ripulire tutto e installare da zero. Dopo qualche tentativo, adesso parte regolarmente e rimane utilizzabile a volte anche per 10 minuti prima di saltare. Applicazioni estreme come Firefox lo distruggono, specie l'apertura di un nuovo tab, ma anche aprire un terminale o Dolphin può risultare fatale. Un'altra cosa interessante é che la scheda di rete viene attivata solo circa una volta su tre - quando non lo é, é necessario spegnere fisicamente il computer e riaccenderlo, un reboot non é sufficiente (anche qui, Knoppix vede e attiva la scheda di rete ogni volta).

La conclusione é la solita: salvo crash durante la procedura di upgrade, non dovrebbe essere troppo pericoloso aggiornare a 9.04 fra circa 6 mesi, quando esce la 9.10. Ammesso che non cominci a uscire di strada in curva, ovviamente.

Film di guerra

Avete presente nei film di guerra quando c'è un tipo che fra meno di una settimana se ne torna a casa che il suo turno di servizio è finito, e gli arriva una lettera che gli dice che sì, la più bella ragazza del villaggio ha accettato di sposarlo, e c'è da compiere solo quest'ultima missione da cui dipendono le sorti della guerra eccetera eccetera e insomma è evidente che ha già il bersaglio disegnato in mezzo alla fronte e deve morire al massimo all'inizio del secondo tempo?

Ecco, oggi ho da aggiornare un server in produzione che presenta sintomi comparabili.

Mi serve del repellente per squali.

Le regole della casa del C++

(nota: post per addetti ai lavori e geek)
(nota2: noi non lavoriamo in C++ - ma l'assonanza era perfetta per il titolo)

Esistono delle regole universali, nel mondo dell'informatica, tramandate di padre in figlio e di sysadmin in sysadmin, che risalgono, si mormora, a quando i Druidi hanno costruito il loro primo NTP server a Stonehenge. Le regole sono semplici e lineari

1) Tu non manderai in produzione un daemon che genera log in debug mode
2) Tu non manderai in produzione un daemon che genera log in debug mode in ragione di 20-30 righe per evento, e processa 20-30 eventi per secondo
3) Tu non manderai in produzione un daemon che genera log in debug mode in ragione di 20-30 righe per evento, e processa 20-30 eventi per secondo, con un framework obsoleto che non riesce a gestire file più grandi di 2 GB e non ha meccanismi di gestione delle eccezioni
4) Se proprio non riesci a obbedire ai primi 3 comandamenti, tu non irriterai il sysadmin.

Un breve antefatto:

Quando ho letto il bellissimo post di EdipeoEnciclopedico sulle 10 buone ragioni per andarsene dalla Francia ho riso moltissimo, ma c'era qualcosa di più che non riuscivo a mettere a fuoco - fino a quando non mi sono reso conto che molte delle ragioni di scontento di EE (3,4,5 e 8, in particolare) si riflettevano perfettamente nella cultura del lavoro comune a tanti latini - italiani, francesi, greci. Ora, attenzione, non voglio dire che i latini siano "peggio" e i tedeschi o gli inglesi "meglio": ognuno ha il proprio set di pregi e difetti, la tipica, estrema familiarità inglese sul posto di lavoro indispone molti continentali (anche con ragione, qualche volta), la prevenzione della maggioranza dei tedeschi nei confronti delle capacità professionali di qualunque straniero è a dir poco irritante, e così via; mi limito a dire che quella di EE è una divertente descrizione di problemi che ho incontrato sul lavoro anche in Italia, problemi che per quella che è la mia personalissima forma mentis trovo difficili da superare.

Purtroppo, la compagnia per cui lavoro al momento è anglo-francese. La compagnia inglese qualche anno fa ha comprato una piccola compagnia francese, e nel corso della fusione il CTO della compagnia francese è diventato Head of IT della risultate idra a due teste. La medaglia è che passa la maggior parte del tempo in Francia a lavorare con gli sviluppatori, che sono in maggioranza lì. Il rovescio della medaglia è che la Francia non è abbastanza lontana.

Questo signore di suo non è cattivo - almeno non più della media; ma riconosco in lui una serie di difetti che affliggevano la maggior parte dei manager pubblici o privati con cui ho avuto a che fare in Italia, e relativamente pochi dei manager che ho incontrato qui. Ad esempio la necessità di stabilire una gerarchia e di rinforzare il concetto ad ogni piè sospinto, o quella di far passare cose perfettamente normali per privilegi: non credo, per dire, che i membri del mio team di supporto della piattaforma si debbano profondere in ringraziamenti per aver magnanimamente ricevuto il blackberry con cui vengono allertati di problemi nel weekend, e non credo neanche che la richiesta di un portatile condiviso da portare in giro negli hosting centre, per usarlo come macchina diagnostica, terminale seriale e tutte quelle cose pazzerelle e divertenti che i sysadmin fanno nel corso della loro vida loca vada evasa con una smorfia sprezzante e un lungo discorso che si può riassumere in "E tu quante ore hai dedicato a leccare il mio prezioso culo per pensare di poterti meritare un sì mirabile privilegio? Vuoi anche uno yacht personale? Una cameriera che ti serva i drink?".

Sono certo che in ogni posto gli indigeni hanno caratteristiche che qualcuno trova supremamente irritanti; per me, l'abitudine latina di far pesare costantemente che qualunque cosa accada accade per la magnanimità di un Gentile Concessore che detiene qualche miserevole autorità è difficile da sopportare. È anche una abitudine generalmente estranea, per quel che ho visto, alla cultura del lavoro di anglosassoni, teutonici e scandinavi - che poi è il motivo per cui nonostante tutto mi trovo decisamente bene a lavorare qui: non è che i locali non abbiano difetti, è che ho girato finchè ho trovato una nazione in cui i difetti degli indigeni mi davano meno fastidio.

(fine dell'antefatto)

Come diceva Tolkien, "Do not meddle in the affairs of sysadmins, for they are subtle and quick to anger"; lavoro in questa compagnia da un anno e mezzo, e un po' perchè sul lavoro cerco di essere pacioso, un po' perchè ho delle mansioni un po' particolari che mi fanno sysadministrare al massimo per metà del tempo, non m'era mai capitato di dover rafforzare il concetto. Però a tutto c'è un limite.

(due settimane fa)
Telefono: "ring ring ring"
Io: "Hello?"
L: "Ciao sono L, scusami, lo so che tu non sei a disposizione nel weekend, ma ho un problema e non sapevo a chi chiedere"
Io: "Tranquilla, stavo giocando col server di casa, non hai interrotto niente di particolare"
(intermezzo: siccome se sei a disposizione nel weekend e risolvi i problemi da casa vieni pagato, anche essere a disposizione nel weekend è un privilegio che bisogna meritarsi. E io non sono particolarmente interessato a meritarmelo)
L: "È saltato il daemon di XXX, Nagios continua a mandarmi allarmi e io non so che fare, ho provato a riavviarlo ma mi dà un errore"
(altro intermezzo: quelli che lavorano al supporto piattaforma sono praticamente sistemisti Windows piuttosto junior; devono da qualche tempo supportare anche piattaforme Linux ma, avete indovinato, il training è un privilegio che bisogna meritarsi e loro non se lo sono ancora meritato abbastanza)
Io: "Vabbe', fammi dare un'occhiata, se ci son problemi ti richiamo io fra 10 minuti"

Controllo e scopro che il daemon muore perchè il log, un file su cui scrive un diario della propria attività, ha raggiunto la dimensione magica di 2 gigabyte. Uccido pezzetti del daemon (è un processo che chiama altri daemon ma non li uccide correttamente, per cui ogni volta che lo fermi poi devi uccidere a mano i processi-figli), rinomino il file, lo faccio ripartire, tutto a posto. Do un'occhiata al log che il daemon ha ri-creato: 3 megabyte. 4. 5. Guardo che c'è dentro, e scopro che sta scrivendo un centinaio di righe al secondo, tutte uguali:

[DEBUG]: XXX daemon doing some work

Dissolvenza. Lunedì, interno giorno, non troppo lontano dal luogo in cui si svolgono i fatti di Orgoglio e Pregiudizio:

Io: "...e il problema si risolve facilmente disabilitando la funzione di debug del daemon"
Gentile Concessore Francese: "Impossibile"
Io: "Pardon?"
(intermezzo: la colpa è mia. Il GCF è costantemente in guerra per il territorio, non si sa bene con chi, e il suo territorio sono, principalmente, gli sviluppatori; dire che il problema si risolve così e cosà lascia intendere che esista un problema col codice, cosa che lui vede come un attacco personale; da quel momento quel pezzo di codice diventerà immutabile nei secoli dei secoli)
GCF: "Smettiamola di cercare di dare la colpa del disastro di ieri ad H. e al suo daemon. Se il servizio di rotazione dei log avesse funzionato come tu mi avevi assicurato che funzionava il problema non si sarebbe verificato affatto"
Io: "Il servizio di rotazione dei log funziona esattamente come tu hai richiesto che funzionasse - ossia solo durante i giorni lavorativi, perchè il riavvio dei daemon durante il weekend era troppo rischioso"
GCF: "E perchè Nagios non controlla la dimensione dei log? Eh? Eh?"
Io: "Nagios non controlla un sacco di cose che non abbiamo mai avuto ragione di controllare"
GCF: "Io ho promesso a T. una soluzione entro oggi, quindi sarà meglio..."
Io: "...disattivare il debug"
GCF: "Il modo in cui il log viene scritto è assolutamente ininfluente e per l'ultima volta non ne voglio più sentir parlare. Entro questa sera dobbiamo monitorare tutti i log su tutti i server della compagnia. Vai in teleconferenza con ognuno degli sviluppatori in Francia e chiedigli il valore per cui ciascuno dei log deve essere considerato critico"
(intermezzo: stiamo parlando dei log di un paio di centinaia di virtual host Apache, di una cinquantina di daemon assortiti e di una dozzina di applicazioni VoiceXML, il tutto distribuito su una cinquantina di server)
Io (cinque minuti dopo): "Non ne hanno idea"
GCF: "Allora usa una stima prudenziale"

E così passo una giornata inutile a scrivere gli script di monitoraggio (ognuno dei quali, fra l'altro, deve essere visionato e approvato da uno sviluppatore: motivazione ufficiale, io non sono un programmatore, loro sì, e gli script sono dopotutto dei programmi), li installo, li testo, funzionano tutti e non manderanno mai un allarme, ovviamente, tranne quello per XXX, ma almeno il management è contento di questo nuovo e scintillante sistema configurabile su ognuno dei server per controllare la dimensione di un numero a piacere di file. Che bello.

Dissolvenza. Domenica scorsa:

Telefono: "ring ring ring"
Io: "Hello?"
A: "Ciao, sono A., scusami, non volevo disturbarti ma sto ricevendo un allarme ogni cinque minuti relativo a..."
Io: "...al log di XXX"
A: "Come lo sai?"
Io: "È una storia lunga. H. dovrebbe avervi lasciato delle istruzioni su cosa fare"
A: "Le ho seguite, ma continuo a ricevere questi allarmi"
Io: "Mi leggi le istruzioni di H?"
A. esegue, e per non scendere troppo nei dettagli H si è dimenticato che la rotazione dei log richiede un riavvio del daemon per funzionare
Io: "Vabbe', non è un problema, riavvia il daemon e dovrebbe andare tutto a posto"

Non va tutto a posto. Il daemon viene riavviato, e quando riparte comincia a inviare 30-40 email al secondo ad H. A quanto pare H ha introdotto una funzione per cui il daemon, quando non riesce a scrivere nel proprio log, comincia a inviare direttamente a lui, per email, le informazioni che non riesce a scrivere. Purtroppo ha trascurato a) di considerare che per ogni email che manda, il daemon cerca di scrivere una riga nel log e non ci riesce, e b) di introdurre una regoletta per smettere di mandare email quando il log ricomincia a funzionare. Per le successive 24 ore, fino al momento in cui H torna alla sua scrivania per fermare il daemon impazzito, il processo continua a inviare fra le 20 e le 30 email al secondo. Uccidere sendmail causa problemi con una serie di altri servizi che girano sullo stesso server, uccidere il daemon responsabile è inaccettabile perchè interromperebbe un servizio per cui il GCF ha firmato allegramente un SLA capestro.

Dissolvenza. Lunedì scorso

Io: "Sospetto che dover aspettare che H torni al lavoro per interrompere il flusso di email sia poco pratico"
GCF (al telefono): "Questo è un problema che non ti riguarda, non credo che qualcuno ti abbia nominato Head of Development a mia insaputa. Piuttosto, perchè sei intervenuto tu ieri? A non riusciva proprio a combinare niente?"
Io: "Ricordi quando hai licenziato il mio junior sysadmin e l'unico del supporto che sapeva qualcosa di Linux lasciandomi con tre specialisti Windows, perchè tanto Linux non ha bisogno di supporto continuo?"
GCF: "Allora mi spiace ma da domani quei tre non devono più metter mani su sistemi Linux, fanno solo danni"
Io: "Mi spiace che la pensi così, e guarda che in questo momento io non credo di potermi mettere in reperibilità per il weekend"
GCF (con risatina sprezzante): "Certo, ti pare che stiamo tutti qui pronti a pagarti uno stipendio extra per lavorare la notte e il weekend? Magari vuoi anche un'auto della ditta? Una segretaria personale?"
Io: "Ma se i log file crescono oltre i 2 GB..."
GCF: "Finiscila con questa storia dei logfile, non tollero che cerchi di dare la colpa ad altri per coprire l'incompetenza tua e del tuo team. I log sono sotto controllo, l'hai detto tu stesso"
Io: "Sì, i log vengono controllati dal sistema di allerta. Controllati."
GCF: "Appunto, quindi problema risolto. Se qualcosa va storto riceveremo immediatamente un allarme"
Io: "Però se non ti spiace voglio che tu mi metta per iscritto che non vuoi che il mio team tocchi le macchine Linux e che non hai bisogno che io sia disponibile durante il weekend"

Il messaggio arriva subito, in tono anche più sprezzante del solito.

Dissolvenza. Stamattina.

Telefono: "ring ring ring"
Io: "Hello?"
L: "Scusa Eugenio, sto avendo un allarme ogni cinque minuti dal daemon XXX, ma ho una tua email che mi dice di non preoccuparmene, confermata da un'altra email del GCF in cui dice che sono troppo cretina per risolvere questi problemi"
Io: "Lo so, scusa, mi spiace per il tono di quell'email..."
L: "Mica è colpa tua se è uno stronzo"
Io: "Comunque non preoccuparti degli allarmi. Il GCF vuole che li ignoriamo e noi li ignoriamo"

Circa un'ora dopo.

Telefono: "Ring ring ring"
Io: "Hello?"
GCF (con voce più stridula del solito): "Eugenio! È successo un disastro! Il servizio per XXX è crollato!"
Io: "Lo so"
GCF: "Lo sai?"
Io: "Certo. Non poteva non crollare, se il log continua a crescere e anche dopo gli allarmi nessuno va a rimuovere manualmente il file"
GCF: "Lo sapevi?"
Io: "E ti ho anche mandato un'email in cui ti dicevo che senza una rotazione manuale dei log gli allarmi erano inutili"
GCF: "Inutili?"
Io: "Ma non preoccuparti, fra un po' gli allarmi smetteranno di arrivare"
GCF: "Arrivare?"
Io: "Sì, a quest'ora il server Exchange dovrebbe star già ricevendo i suoi bravi 30-40 messaggi al secondo e non ci metterà molto a crollare, e usiamo quello anche per trasmettere gli allarmi di Nagios sia per email che al gateway SMS"
GCF: "Crollare?"
Io: "Ma c'è l'eco sulla linea?"
GCF: "Devi fare qualcosa! T. mi ha telefonato due volte, rischiamo di perdere il contratto!"
Io: "Mi spiace, ma temo di non potere. Hai insistito tanto sul fatto che non avevi bisogno di me, così ho preso la mountain bike e me ne sono andato alla foresta di Epping. Sono in bosco in questo momento, non so neanche dove potrei trovare un internet cafè, e comunque non ho con me le mie chiavi per la VPN"
(due volte falso: ero a casa a giocare con la gattina e a mettere insieme un cluster Rocks con dei vecchi server, e comunque chi mi conosce sa che non andrei neanche in mezzo alla giungla senza le mie chiavi ssh)
GCF: "Chiama L! Dille di far ripartire il servizio! Subito!"
Io: "Con piacere, ma non servirà a nulla. Come da tue istruzioni, ho rimosso le sue chiavi di accesso dal sistema di autenticazione per le macchine Linux, quindi non potrà accedere ai server almeno fino a quando io non le riattivo"
GCF: (starnazzamenti in francese)
Io (tranquillo): "Allora ci sentiamo domani, sì?"
GCF: (starnazzamenti in francese)

Due minuti dopo, telefonata a L.:

L: "Hello?"
Io: "Ciao, sono io. Fra cinque-dieci minuti ti telefonerà il GCF chiedendoti di metterti in macchina e andare in ufficio per risolvere in loco il problema di XXX dal mio computer [le cui chiavi sono ancora attive, NdE]. Mi aspetto che tu gli risponda che hai l'auto dal meccanico"

Viste le condizioni dell'SLA, sospetto che qualcuno vedrà il proprio bonus sensibilmente decurtato quando ad Aprile si chiude il bilancio, soprattutto quando le istruzioni che quel qualcuno ha messo per iscritto verranno accluse come da policy, domani mattina, all'incident report che va al senior management e al cliente.

Per fortuna che Linux c'è

Quelli che mi conoscono bene sanno che ho un carattere di merda, poca pazienza, sono quasi sempre molto irritabile ed ho il tipo di senso dell'umorismo che considera l'apoteosi della comicità un pianoforte a coda che casca su un pullmino carico di orfanelle cantanti canzoni di Cristina D'Avena. Anche chi mi conosce bene, però, non sa con certezza se sono sempre stato così (ipotesi genetica, cara ai conservatori) o se le mie esperienze e l'ambiente che mi circonda mi abbiano reso così nel tempo (ipotesi ambientale, cara ai progressisti).

Sarà il caso che lasci decidere ai miei tre lettori, parlando loro di Linux. Per la precisione, di Kubuntu 8.04.1-KDE4 Remix.

Cappadiè quattro (punto uno punto due, per la precisione) è un window manager - per i profani, è la parte visibile, grafica, di un sistema operativo: è quella roba che fa funzionare le finestre, le fa diventare semitrasparenti al momento giusto (o sbagliato, a seconda), fa vedere i menu eccetera. È, insomma, in generale quella roba con cui interagite. Astenersi puristi e perditempo, so bene che ci sto mischiando dentro anche Xorg che tecnicamente è a un livello più basso del window manager, ma stiamo cercando di spiegare le cose a profani e utenti di Mac. La cosa importante è che quella che chiamano l'esperienza d'uso di un sistema è definita in pratica dal window manager.

Da quando ho KDE4 sul computer al lavoro, la mia vita si è fatta interessante. Per esempio, erano anni, dai tempi di Windows 95/98, che non mi capitava di dover riavviare il computer un minimo di due volte al giorno. A KDE4, pare, non piace la mia scheda video; o meglio, gli piace, ma solo se gli faccio credere che si tratta di una scheda video diversa, di circa cinque anni più vecchia e impossibilitata ad utilizzare il 90% della propria capacità di calcolo, disabilitando il software che necessita di accelerazione 3D e la maggior parte degli effetti grafici di KDE4 stesso. Sì, l'unico modo per far funzionare KDE4 è non usarlo con la scheda video della quale necessita per funzionare appieno.

Un'altra caratteristica interessante, forse connessa anch'essa con la scheda video, è la sottile interazione fra il window manager e il sistema operativo sottostante (un fatto naturale per gli utenti Windows, che non sono abituati a pensare a questi due elementi come separati, ma abbastanza sorprendente per il linuxaro medio). Ad intervalli del tutto irregolari, per ragioni che non sono in grado per il momento di individuare, e senza preavviso, ogni partizione presente (sì, inclusa /) viene rimontata read-only. Questo non accade mai sulla stessa macchina utilizzando XFCE o altri WM, e non accade, sempre sulla stessa macchina, con Windows XP. Accade invece, tre-quattro volte a settimana, sempre e solo sotto KDE4.

KDE4 è, però, user-friendly. Ha un sacco di caratteristiche che lo rendono usabile anche da un criceto o da un utente Apple: per esempio, l'utente non può fare nulla per modificare la posizione delle icone nel panel, i menu, le icone sul desktop. Non può aggiungere o togliere applicazioni. Non può spostare le applicazioni fra i menu. Si può ancora decidere di quanti desktop virtuali si può disporre, ma non è possibile dar loro sfondi diversi. Ovviamente non si può modificare la dimensione del panel o delle icone sul panel stesso (posizione e dimensione che, a quanto pare, cambiano ogni volta che si installa un aggiornamento). Tutto questo risponde ad una precisa esigenza di prevenzione degli incidenti - è un fatto ben noto che KDE4 viene proposto come alternativa a MacOS X, e si rischia che le povere testoline degli utenti abituati alla filosofia "think different" di Apple, messe davanti a cose pericolose come informazioni o scelte, esplodano.

(quanto sopra non è del tutto esatto: ho casualmente scoperto che è in effetti possibile spostare le icone nel panel, almeno in KDE 4.1.2, cliccando sul bottoncino per aggiungere widget. Mentre il pannello delle opzioni è aperto, le icone non funzionano ma possono essere spostate. Non sono certo se si tratti di una funzionalità nascosta o di un bug)

I progettisti di KDE sono anche, purtroppo, dei distrattoni. Per esempio, si son dimenticati di aggiungere il tool per configurare una stampante - anche se c'è quello per modificarne le opzioni, una volta installata (solo una locale, eh, niente stampanti di rete). Non c'è nulla: non c'è neanche un'icona in grigio nel pannello delle opzioni, non c'è una parolina di spiegazione, non c'è neanche una nota che dica "whoops, ci siamo proprio scordati, ce la infiliamo alla prossima release". Non c'è nulla. Non c'è nulla alla versione quattro punto uno punto due, e non c'era nulla nella versione quattro punto zero. Sono andati avanti per almeno tre o quattro versioni senza rendersi conto che un elemento fondamentale come la configurazione della stampante mancava, o senza considerare la sua mancanza un problema. E a cercare con Google, si scopre anche perchè: non ce n'è bisogno, a quanto pare, basta usare Cups puntando il proprio web browser a http://localhost:631 e accedendo all'interfaccia di amministrazione del server di stampa. Cups, il sistema che se fosse un'automobile avrebbe, inframmezzati con i bottoni dell'aria condizionata e dei fari antinebbia, un tasto per svuotare il serbatoio, uno per l' autodistruzione ed uno per suonare l'Ouverture 1812 col clacson (chi ha usato Cups o ha letto questa cosa qui sa di cosa parlo).

Da 15 anni e spiccioli per mestiere amministro sistemi creati da gente con questo tipo di testa. Cosa dicevamo a proposito del mio carattere?

(sì, oggi o domani esce Kubuntu 8.10. Magari nel frattempo hanno scoperto l'esistenza delle stampanti, ma ne dubito)

P.S. Ma sì, lo so, con le Nvidia funziona bene, sono le ATI che lo fanno saltare. E gli effetti sono carini.

UPDATE: vorrei solo aggiungere che Adept 3.0 è una cagata PAZZESCA

A conti fatti

A conti fatti, se si potesse sottrarre dal conteggio dei miei anni tutto il tempo che ho sprecato combattendo contro l'idiozia nel solo campo dell'informatica, sbattendo la testa per intere giornate prima di accettare che in Ubuntu, se sei tanto stupido da cambiare scheda wireless, ti conviene reinstallare tutto da zero che manco sotto Windows, e poi ricompilare i sorgenti di ndiswrapper perchè tanto quelli che vengono con Ubuntu sono bacati e servono solo a prenderti per il culo; diventando matto dietro a schede wireless Netgear che si resettano (e fanno cadere la connessione, sotto Linux, o causano un BSOD, sotto Windows) ogni 20.5 MB di traffico, o router wireless Netgear (you can't have too much of a good thing) che, quando gli cambi l'antenna con una ad alto guadagno, rimuovono la configurazione del proprio indirizzo IP, azzerano la crittografia e spengono l'interfaccia di amministrazione, ignorando ogni successivo reset; lottando contro l'evidente verità che un terzo degli autori di Howto, sotto Linux, si inventano le soluzioni (memorabili le configurazioni per l'autenticazione Courier/IMAP via Mysql: 3 diversi Howto, tutti sbagliati); recuperando hardware reso inutilizzabile dall'ultimo kernel (sì, risolve il bug dell'automount - oh, i tuoi server hanno due Tulip embedded? Peccato, abbiamo deciso di non supportare più metà delle schede di rete Tulip di questo pianeta); dando ascolto a cazzari e millantatori infilatisi in forum e gruppi di supporto (Sybase15 su RHEL5? Ma certo, ne avrò installati 200, si fa così e cosà! Ah, scusa, volevo dire che ho provato 200 volte a installarlo, ma non so se funziona perchè non so come si fa a farlo partire); insomma, se si potesse sottrarre tutto questo tempo sprecato al conteggio dei miei anni, sarei probabilmente un adolescente.

Sto pensando seriamente di corrompere gli addetti del centro di riciclaggio su a North Finchley perchè mi facciano entrare il sabato dopo l'orario di chiusura e mi permettano di sfondare un po' di vecchi computer a martellate.

Le gioie dell'informatica

Mi alzo alle tre, salto in auto, arrivo in ufficio, lo switchover è completato per le 7, due ore di test, tutto perfetto, email di un cliente, 9:05: "Il sito non va bene".

Panico

Che significa, non va bene? Che errore riporta? Che funzionalità manca? Come è possibile che non ce ne siamo accorti in un mese di test? Riunione di emergenza per una disamina dei casi possibili - abbiamo bisogno che tutti i server rispettino i parametri di sicurezza NIST/NSA, se qualche funzionalità cade per via delle nuove restrizioni bisogna necessariamente modificare il codice dei siti. Preparo frusta e pungolo elettrico per incentivare i programmatori.

No, dice il cliente quando lo richiamo, quella roba va benissimo, ma non mi piace molto il colore dello sfondo, è un mese che stavamo pensando di chiedervi di cambiarlo.

L'informatica, l'unico settore in cui essere autistici fa bene alla carriera.

In compenso, ho avuto un'oretta per aggiornare la mia workstation a KDE4. Siccome sono vecchio e scafato, ho aspettato la versione 4.02, ho anche aspettato che fosse in giro da un po', poi ho aspettato che venisse usata su Kubuntu per qualche settimana, e infine l'ho installata.

Tutto sommato, poteva andar peggio. Adesso non riconosce più le chiavi USB a meno che non attivi il widget apposito nella taskbar; le icone della taskbar sono gigantesche e non più personalizzabili, per favorire il pubblico americano e gli analfabeti in genere, che non solo hanno bisogno delle figure, ma le vogliono grosse; il bottone del new tab è scomparso dalla Konsole, costringendomi a premere 14 tasti di cui due con le orecchie per aprire un nuovo tab terminale nella stessa finestra; le opzioni per la localizzazione non esistono, e tutte le personalizzazioni per ottenere caratteri internazionali sulla tastiera sono evaporate (curiosamente, sono state cancellate anche dalla configurazione del vecchio KDE3); i widget sono fissi, non si possono spostare e vengono disposti alla rinfusa nell'ordine in cui vengono aggiunti, non sembra esserci modo per raggrupparli per funzione - magari c'è, ma mi sembra il caso di preavvertire che il primo commentatore che mi dice che sono stupido, ho usato troppo Windows, non capisco la filosofia di KDE4 e i nuovi paradigmi visuali, e basta andare in system->bugger_a_donkey->custom->Netherlands->beware_of_leopard->move_taskbar_widgets per risolvere tutto vince una botta di Hazet 36 nel cozzetto. Chi ha usato Linux e cercato di segnalare un problema in qualche forum sa di cosa sto parlando.

Temo proprio che abbia ragione il mio amico Emmanuele, a tutti questi coloratissimi nuoviparadigmivirtualidiinterazioneuomomacchina manca un elemento fondamentale, il bottone "please unfuck my system".

Adoro questo lavoro.

Management for dummies

Caro J.

Adesso che è passato un po' di tempo e siamo tutti e due più tranquilli e possiamo guardare al passato in maniera un po' più rilassata, mi permetto, nel mio piccolo, di darti qualche consiglio spassionato che potrebbe tornarti utile per la prossima volta - approfittando del fatto che ho poco da fare in attesa della partenza per un viaggio di lavoro.

Capisco che quando sei arrivato ti sei trovato, e non per colpa tua, in una situazione difficile: il senior management aveva cancellato ogni residua fiducia nel futuro in un bel po' di gente, l'IT manager che stavi rimpiazzando era una delle poche persone decenti, che non a caso ad un certo punto aveva detto basta e s'era diretto a più verdi pascoli, i nostri programmatori e analisti migliori se ne andavano ad un ritmo di uno a settimana (non l'hai mai saputo, ma c'era un giro di scommesse mica da ridere su chi sarebbe stato il prossimo). Tutto verissimo, e non lo metto in dubbio: per qualche giorno, infatti, sei stato oggetto della massima solidarietà di tutti i superstiti. Credo sinceramente, però, che avresti potuto far meglio nella gestione della situazione. Ad esempio, quella famigerata settimana in cui perdemmo 3 persone (non l'hai mai saputo, ma c'è voluta più di una birra per convincerli a darti la lettera di dimissioni uno al giorno, tutti e tre alla stessa ora: N. te la doveva consegnare la settimana prima, per esempio) credo che quando il direttore europeo ti mandò un'email chiedendo "ma è un problema?" non avresti dovuto rispondere "ma no, li rimpiazziamo con niente con qualche scimmia ammaestrata a Bombay"; o almeno, prima di rispondere avresti dovuto controllare che le prime tre lettere del nome del direttore europeo non fossero in comune con le prime tre lettere di una certa lista di distribuzione di Exchange; e questo non tanto perchè l'email avrebbe potuto essere interpretata come razzista (tranquillo, non ce ne poteva fregare di meno; avevamo P. come collega, dopotutto, uno le cui uscite avrebbero fatto arrossire Nick Griffin) quanto perchè a) faceva capire a tutti in quanta considerazione era tenuto il nostro lavoro e b) faceva capire a tutti che il nostro IT manager non aveva la minima idea della complessità del lavoro che era chiamato a gestire. No, dico, ma pensavi davvero che tre-quattro programmatori neolaureati di Bombay potessero prendersi carico di qualcosa come 50.000 righe di codice C++ per HPC e occuparsi della manutenzione e bug fixing "come niente"? Programmatori che avrebbero dovuto correggere bug e occuparsi della QA prima di portare le patch in produzione? Su un sistema ASP su cui le 10-12 maggiori banche d'investimento del mondo facevano girare ogni mattina le proprie valutazioni?

Un altro consiglio che mi sento di darti è di evitare, per quanto possibile, di parlar male della gente che lavora per te; soprattutto poi se (ancora) parli male soprattutto delle loro capacità professionali senza averne un'idea ben precisa. Se dividi i programmatori in Tier-1 e Tier-2 dove il Tier-1 è composto di assunti -da te- da una settimana che dovrebbero in qualche maniera riscrivere da zero il software che costituisce il core business della società (che io non abbia mai visto una sola riga di codice scritta da loro non è grave; che non l'abbia vista neanche il server CVS, magari, lo è di più), e il Tier-2 si compone delle uniche persone che sanno come quel software esattamente funziona, che hanno passato gli ultimi due anni a tradurre in algoritmi i modelli sfornati dai nostri matematici (sì, si sono licenziati anche loro e lavorano per BNP-Paribas, adesso: e tu non te ne sei neanche accorto perchè credevi che i modelli si prendessero da qualche libro), si compone insomma delle persone che tengono in piedi e fanno funzionare l'unica fonte di reddito per la compagnia, ecco, in questi casi non è una buona idea venire a dire a me e a P. che quelli li hai messi nel Tier-2 perchè sono programmatori e analisti di second'ordine; primo, perchè è (evidentemente) falso, e secondo perchè, Cristo, sai benissimo che la senior programmer del Tier-2 è anche la mia migliore amica, e P. e la moglie vanno in vacanza ogni anno con la famiglia del senior analyst Tier-2.

Per finire, devo consigliarti anche, laddove possibile, di non limitarti a fare in modo che i tuoi piani siano buzzword compliant. Capisco che ogni buzzword che riesci a mettere nel piano aggiunge qualcosa al tuo bonus di fine anno; capisco anche che in una situazione in cui i profitti si sono dimezzati, la gente se ne va ad un ritmo di uno a settimana, l'affidabilità del software si degrada con ogni "miglioramento" che viene aggiunto senza essere testato (no, eliminare i sistemi per il QA per ridurre il budget non è stata una delle tue decisioni più brillanti, ma magari ne parliamo un'altra volta), diventa necessario far contenti i piani alti; con tutto questo, a volte le buzzword da sole non solo non bastano, ma possono diventare controproducenti.

Mi spiego.

Se il core business è costituito da un sistema ASP composto di un'interfaccia (Linux/Apache/Tomcat) a cui i clienti sottopongono i portafogli azionari da valutare, un cluster Rocks/Linux su cui il sofwtare che valuta i portafogli gira, diversi database (Linux/Mysql) a cui il cluster attinge per i dati del mercato su cui basare le estrapolazioni, e un'intera infrastruttura Linux per lo sviluppo, il QA (almeno fino ad un certo punto) e le comunicazioni, bene, in questo caso pronunciare la magica parolina "outsourcing" potrebbe non essere il toccasana che molti ritengono.

Certo, in teoria è possibile riscrivere il software che gira sul cluster in modo da disaccoppiarlo dal database; questo probabilmente significherebbe caricare sul cluster quantità enormi di dati per accompagnare i vettori delle valutazioni - pensa, due anni di dati delle tre o quattro maggiori borse mondiali, in formato XML, ogni mattina. Certo, in teoria è possibile allo stesso tempo portare quelle 50.000 righe di codice da Linux a Solaris (sì, il C++ è portabile; Rosy Bindi è di sinistra; quei soldi mi servivano per andare a trovare mia nonna malata; no, davvero, lei non è niente per me, io amo solo te). Certo, in teoria, visto che ci siamo, è possibile anche cancellare ogni riferimento alle librerie MPI e tradurre ogni chiamata ad una corrispondente chiamata alle librerie Solaris Grid, o come cavolo si chiamano questa settimana. E certo, in teoria è possibile, dopo aver fatto tutto questo, eseguire tutte le valutazioni in outsourcing sui Grid Cluster pubblici di Sun - ammesso, ovviamente, che si riesca a rendere sicura secondo gli standard, piuttosto stringenti, di una dozzina di banche d'investimento sia la comunicazione con il cluster, sia l'elaborazione stessa dei dati, visto che ci si troverebbe a condividere gli stessi nodi con lo sa Manitù quanti altri clienti di Sun. Tu lo sai, vero, che la mia amica Annarella in questo momento sta visualizzando un enorme diagramma GANTT in cui ogni tanto compare una casella con l'iscrizione "A miracle happens here", e sta scuotendo la testa; ma Annarella è una malfidata, non starla a sentire.

In teoria, tutto questo è possibile. In teoria, tutto questo è possibile contemporaneamente. Ma se mi permetti di darti un ultimo consiglio, magari per la prossima volta, tieni a mente questo semplice fatto: non licenziare tutti quelli che dovrebbero fare il lavoro in base al fatto che una volta che avranno fatto il lavoro, diventeranno superflui.

Perchè se lo rifai, ti ritroverai un'altra volta a spasso, con poche offerte di lavoro e costretto ad elemosinare referenze da quelli che lavoravano per te, che è veramente una delle cose più umilianti del mondo - non è che di te me ne freghi qualcosa, ma la business unit (un tempo una compagnia indipendente) che hai trascinato nel fango e portato allo smembramento, un tempo era tosta, all'avanguardia e ricca di potenzialità, e sarò sentimentale, ma un po' mi dispiace.

De rerum Linux

Qualche tempo fa, stufo dei sempre maggiori problemi di compatibilità fra i vari repositories, ho abbandonato SuSE come OS principale di casa per tornare al mio primo amore, Debian, sebbene, come si confà ad un geek in crisi di mezza età, fosse un primo amore con aggiunta di lifting, botox e silicone - in altre parole, Ubuntu, o meglio, Kubuntu.

Girellando per siti alla ricerca di temi per Emerald/Compiz ho trovato la prova definitiva che Linux trionferà su tutti gli altri sistemi operativi:

Ubuntu Satanic Edition

e

Ubuntu Christian Edition

No, sul serio. Ubuntu CE, che D*o li perdoni, è annunciata su What Would Jesus Download.

Faccia tosta

Fare l'esame da Red Hat Certified Engineer e passarlo con 100%, 100%, 92.9%, indossando una T-shirt Debian

Lo metto qui...

...senno' mi scordo.

Linux SuSE 10 non supporterebbe monitor multipli. Bisogna andare a configurare a manina /etc/X11/xorg.conf nella maniera seguente, dopo essersi assicurati di aver scaricato eventuali driver proprietari (Nvidia Quadro 280, nel mio caso):

creare un secondo "Device" clonandolo dal primo:

Section "Device"
BoardName "Quadro NVS 280 PCI-E/Quadro FX 330"
BusID "5:0:0"
Driver "nvidia"
Identifier "Device[0]"
VendorName "NVidia"
Screen 0
EndSection

Section "Device"
BoardName "Quadro NVS 280 PCI-E/Quadro FX 330"
BusID "5:0:0"
Driver "nvidia"
Identifier "Device[1]"
VendorName "NVidia"
Screen 1
EndSection

Commentare le righe "Screen" in "ServerLayout" e inserire queste:

Screen 0 "Screen[0]" 0 0
Screen 1 "Screen[1]" RightOf "Screen[0]"

(Nei "Device" assicurarsi che ci sia "nvidia" e non "nv", ca va sans dire, che il driver opensource non supporta il dual-head)

Andare a linea di comando, diventare root, init 3, init 5, fatto - si spera.

Un piccolo appunto personale, pero', ci vuole. Uno dei motivi per cui uso SuSE e' perche', come sanno quelli che mi conoscono, sono mortalmente pigro. Non che non sia capace di passare un pomeriggio a spulciare file di configurazione, ma sulla mia macchina desktop, o sul computer di casa, preferisco non doverlo fare ogni volta che modifico qualcosa: se non altro, perche' ho di meglio, o di piu' urgente, da fare. SuSE mi offre degli strumenti di configurazione semplici e intuitivi, che mi permettono di portare una macchina da vergine a perfettamente funzionante nel giro di un paio d'ore (e il grosso del tempo va via per installare in automatico un paio di GB di software, sia chiaro); per questo, sul mio desktop preferisco usare SuSE.

Alla luce di questo, amerei sapere, chi e' il cretino che ha deciso che "per semplificare le cose", da SaX2 (il tool di configurazione di X Windows/Xorg) e' stata rimossa l'opzione dual-head? Chi e' il marketroid che ha deciso che la possibilita' di avere uno o due monitor poteva confondere gli utenti?

L'informatica e' l'unico settore al mondo in cui qualche imbecille stellare riesce a farsi venire idee del genere senza essere immediatamente rinchiuso in una cella imbottita o linciato da una folla inferocita. Pensate un attimo ad una situazione analoga nel mercato dell'auto, per dire. Andate a ritirare la vostra nuova Alfa xxx e vi trovate questo avviso lasciato sul sedile del guidatore:

Gentile utente, da oggi, per evitare confusione negli automobilisti, abbiamo deciso di rimuovere la retromarcia dalle nostre auto. Abbiamo stabilito che la possibilita' di andare sia in avanti che indietro poneva un serio rischio di confusione nel guidatore, col risultato che le nostre auto venivano scartate in favore di altre perche' "troppo complesse".
Naturalmente, e' ancora possibile far andare indietro l'automobile, se per qualche oscuro motivo questo dovesse rivelarsi irrinunciabile per una ristretta minoranza di automobilisti: e' sufficiente mettere il cambio in folle, scendere dall'auto e spingerla nella direzione voluta, assicurandosi che qualcuno al posto di guida mantenga il controllo dello sterzo.

Ditemi quanto durerebbe il concessionario prima di essere impalato...