lunedì 20 febbraio 2012

Il motivo per cui preferisco altro - seconda puntata

Eccoci qui, uno degli altri motivi per cui, sul piano strettamente tecnico, preferisco the Debian way.

Si sa che uno dei talloni d'Achille di Debian è la vetustà dei pacchetti (qui per un esempio).

Ebbene, qual è la soluzione? Una risposta standard sarebbe te li tieni alla versione che te li diamo, oppure compili, oppure passi alla distribuzione in test. Ma nessuna delle tre è una risposta orientata all'utente, dato che tutte e tre hanno i loro problemi. E questo soprattutto in ambiente enterprise:
  • la versione di un prodotto, driver o altro spesso è legata a precise scelte architetturali o di progetto; ma anche fosse solo gusto personale, è il cliente quello che ha ragione;
  • compilare, anche quando non si trasforma in un incubo di compilazione di dipendenze in cascata, crea problemi di gestione: un conto è farlo sul proprio PC, un conto è farlo per decine di server, o peggio quando l'installazione dev'essere inserita in una procedura di deploy; certo si può ottimizzare, ma è comunque un passaggio in più, e un passaggio non standard, che può arrivare a decuplicare i tempi di deploy di un server (e questo vale anche di più per chi fa soprattutto sviluppo);
  • la distribuzione di test è appunto di test, anche fosse abbastanza stabile richiederebbe comunque continui aggiornamenti.

Che si sono inventati quelli di Debian? Backport. Ossia, ricompilano loro alcuni pacchetti dalla distribuzione di test e li mettono a disposizione della distribuzione stabile. Il che, indipendentemente dal fatto che sia una buona soluzione o no, è un atteggiamento orientato al cliente molto più di quello di tante blasonate distribuzioni commerciali. Tra parentesi, anche IBM con Aix affronta (e risolve) lo stesso problema, anche se in un modo diverso (ossia rilasciando fix facoltative intermedie tra un aggiornamento e l'altro).

Questo per dire che non c'è un solo modo di risolvere il problema: il punto è essere disposti a farlo e ritenere che le esigenze dell'utente non siano solo capricci. E per quanto riguarda l'utente, è capire che certe cose non sono impossibili a livello tecnico, ma tutto sommato (IBM docet) non lo sono neanche a livello commerciale.

giovedì 9 febbraio 2012

Non sono sola

Ecco, questa è una bella consolazione, però non è che sia poi molto consolatoria.

Open Source projects are gone crazy, period

Ragazzi, qui c'è gente che lavora, che vogliamo fa'?

martedì 7 febbraio 2012

Il motivo per cui preferisco altro

Quando Linux non è solo un bel giocattolo, ma uno strumento di lavoro, ci si scontra sempre con le preferenze altrui. E di solito, quando si è in un'azienda e il proprio potere decisionale rasenta lo zero da sotto, Linux è quasi automaticamente Red Hat. O la sua sottomarca, CentOS.

Ci sono casi in cui scegliere Red Hat è quasi obbligatorio, per carità: servizio di assistenza, percorso di training, ecc. la rendono una soluzione appetibile da vendere. Ha i suoi vantaggi, anche se li si paga fior di soldini, ma è una questione di rapporto prezzo/prestazioni: si paga un servizio e quel servizio tra l'altro pure funziona e non ha nemmeno una politica di licensing scomoda.

Quello che veramente non capisco è perché scegliere una piattaforma così quando questi servizi non servono. Cioè, in realtà, quello che veramente non capisco è perché scegliere CentOS per i server interni. Ossia, non in caso di sviluppo o di education (dove potrebbe avere anche il suo senso perché "più compatibile" con Red Hat), ma quando è usato per ospitare applicazioni interne e non servono tutti i servizi accessori.

Ora, uno dice, una distribuzione varrà l'altra, no? Sarà questione di gusti? Be', non proprio. Le due cose che mi servono ora e che CentOS non fa sono:
  • aggiornamento tra una major release e l'altra (ossia un passaggio da 5.7 a 6.0): bisogna reinstallare;
  • installazione via netinstall attraverso un proxy (ma come gli è venuto in mente di non supportare i proxy?).
La cosa bella sono certi commenti che ho trovato in giro, del tipo: «Eh, ma neanche Windows lo fa.» Già, peccato che Debian faccia entrambe le cose dalle origini. Ma persino il commercialissimo, supportatissimo, malvagissimo Aix le fa. E scommetterei che i flavour di Unix e Linux là fuori in maggioranza fanno entrambe le cose.

La cosa divertente è che poi sono io l'integralista senza una visione aziendale quando propongo Debian.

lunedì 23 gennaio 2012

Firefox e java

Continua la battaglia per un Firefox a 64bit.

Per avere il plugin di java è banale. Posto che uno si sia scaricato una JDK (ma anche solo una JRE), il plugin è:

JAVA_HOME/jre/lib/amd64/libnpjp2.so

Per esempio, su una Debian il path con la jvm di Sun installata da pacchetto è:

/usr/lib/jvm/java-6-sun/jre/lib/amd64/libnpjp2.so

Basta creare un link simbolico in FIREFOX_HOME/plugins, ossia per esempio:

# cd /usr/local/firefox-7.0.1/plugins
# ln -s /usr/lib/jvm/java-6-sun/jre/lib/amd64/libnpjp2.so .

lunedì 9 gennaio 2012

Grub e troooppi dischi

Se per caso a qualcuno capitasse di avere un server con più di 26 dischi e grub, fino alla versione 1.99 incappa in un curioso bug. In pratica, grub-probe non identifica i dischi con label del tipo sdaa, sdab, cioè come da sempre vengono etichettati i dischi oltre il ventiseiesimo.

L'unica è aggiornare o patchare grub-probe (che è quasi la stessa cosa). Questo significa, per una Debian Squeeze, fare il backport da Wheezy del package grub-pc, che vince la palma come il primo necessario in Squeeze.




martedì 8 novembre 2011

Tu quoque Cups

Io amo cups. Adoro cups. Cups mi ha quasi salvato la vita in almeno un'occasione.

Per chiunque abbia conosciuto la stampa da unix prima di Cups, Cups è stata la benedizione. Ma non dev'essere il mese giusto per pretendere qualcosa anche dal più consolidato dei software.

Ho configurato una stampante. Non venticinque come mio solito, una. Ma, che ci crediate o no, non è la stampante di default se uno non glielo dice. E quindi, con una stampante definita (non zero, o duemila), lpr non sa dove stampare.

Avrei un messaggio da lanciare: la linea di comando esiste e c'è pure chi la usa. Vi prego, sacri signori sviluppatori di software, ricordatevene ogni tanto.

L'esasperazione

La mia relazione con Unix compie diciott'anni giusto in questi giorni, per cui non sono neanche proprio una novellina.

Si può dire che Linux l'ho visto nascere, mettere i primi passi, sbrodolare il tappeto e anche diventare abbastanza grande. Abbastanza, però, che poteva andare bene qualche anno fa, ma certo non più adesso.

Ho un portatile nuovo fiammante, e ancora (siamo nel 2011) devo impazzire per farlo funzionare come vorrei. L'audio è un mistero: le cuffie funzionano, il microfono no. Perché? Boh. Qualcosa che segnali un errore, un modulo che manchi? Ma figuriamoci: nell'era della userfriendliness presentare un log a un utente sembra diventato un insulto. Meglio ignorare il problema: qualsiasi mixer dice che va tutto, ma poi non va un accidente.

Fino a un paio di versioni di X fa, uno doveva farsi tutto a mano: morale, si impazziva un paio di giorni (la documentazione di X è... no, non arriva nemmeno a essere), poi la cosa funzionava per l'eternità. Finché appunto editare file (ma non era Unix-like?) è diventato un impiccio e le cose han cominciato a fare quello che volevano loro. Per una come me, che aveva una configurazione di X che faceva il caffè, è un incubo: se prima potevo avere ogni cosa che desideravo (che so, una tastiera custom o una risoluzione non ortodossa o -eresia- non avere un desktop) adesso è già tanto che parta.

E perché sto trascurando shell che spariscono, device che diventano un'altra roba tra un apt-get e l'altro, renumbering degli inode di lvm, robe cioè che l'utente normale non dovrebbe neanche sapere che esistono.

E vogliamo parlare di Firefox su x86_64 o su PowerPC?

L'ultima di oggi è inkscape: si rifiuta di salvare i file. Li crea, ma vuoti e poi protesta pure.

Insomma, comincio a essere veramente esasperata. Anche perché non ci sono poi molte alternative, MacOS è troppo rigido per le mie esigenze (ma funziona) e Windows, be', è già tanto che lo si possa classificare tra i sistemi operativi.