Se le auto funzionassero come i software, si bloccherebbero due volte al giorno senza motivo e l'unica soluzione sarebbe reinstallare il motore

— anonimo dirigente General Motors

Destabilizzare lo stabilizzatore

http://www.stenoweb.it/files/blog/archflag.png Ma allora è proprio vero: riesco a comunicare con il pensiero ! Sono un ! :D Fregnacce a parte, la di una iniziativa per la creazione di un ramo stable di Archlinux non mi sorprende affatto. Chiunque la provi vorrebbe con lei fare tutto: desktop, embedded, caffè, thè, prima colazione, merenda e ... server. Non lo sò se questa iniziativa avrà successo, sinceramente non sò neppure quanto (nel mio umile caso di un server SBS) serva. Vediamo perchè.

Arch sul Server

Spero si sia capito. Se non si è capito lo ribadisco.Io non installerei mai Arch in un server di fascia medio alta. Non mi sognerei mai di installare ad esempio un ambiente virtualizzato Xen o VMware importante (magari pure su hardware "proprietario") basandomi su Arch, gli attori qui sono altri e ben noti.
Ho di proposito chiamato la guida per sottolineare il fatto che stò parlando di piccole (ma numerose) installazioni.
Arch non è una distro desktop, non è una distro server. Non è niente, o meglio è quello che la facciamo diventare. Anche per questo mi piace.

Detto questo faccio gli auguri ai promotori dell'iniziativa, ma lasciatemi dare una opinione sul progetto in questione da mio punto di vista "Small Server". Non voglio giudicare il progetto da "workstation ", dove forse potrebbe anche avere più senso.

Pacchetti Stabili e Instabili

Uffa, quanto sono inflazionate queste definizioni ! Quando un pacchetto è "stabile" o "instabile" ? Rispetto a cosa ? Samba è stabile ? OpenLDAP è instabile ?
Se andate nei rispettivi siti probabilmente trovate la versione "stable", e non credo che Arch o altra distro pacchettizzi la versione di sviluppo. E allora come faranno i nostri eroi a definire la versione "stable" che sia, scusate il bisticcio di parole, più "stable" dei pacchetti standard ? I casini si manifestano quando si mettono insieme i pacchetti, quando sono troppo vecchi e superati, non quando sono soli e beati. Proveranno tutte le combinazioni ?
In un server si usano software belli tosti, e sono più incline a credere al team di Samba che al "pacchettizzatore" amatoriale. E' meglio una patch applicata dal team di sviluppo di Postfix in una nuova versione che un backport amatoriale sulla vecchia, questo nessuno me lo leva dalla testa, ci vogliono strutture e risorse importanti per un lavoro del genere di cui forse solo RedHat e Novell dispongono.

Allora tutto alle ortiche ?

No, no, per carità, nelle installazioni di piccoli server dove si usano software consolidati da anni la situazione è già buona così qualsiasi distro usiate da momento che i software in gioco sono praticamente sempre quelli. Io personalmente non installo xorg, gnome, kde, un software di acquisizione scanner, o un driver audio in un server, questi sono instabili di natura (non solo su Linux) e non mi servono.
Con Arch si installa un tassello per volta, niente calderone predefinito, e questo è già un grande vantaggio. E poi non si passa già per i repo "unstable" e "testing" o è solo una barzelletta ?
E insomma, sono arcistufo di pasticciare con i sorgenti nel tentativo di aggiornare un software, molto meglio Postfix "bleeding" ma pacchettizzato che il contrario, oppure no ?
Il non era dovuto ad un pacchetto instabile, ma ad un mio errore di configurazione, (oggigiorno i problemi sono quasi sempre di questo stampo) sostanza che non sarebbe certo cambiata con un ramo presunto "stable"...

Kernel

Ecco, ora cambio parzialmente opinione :), qui sì che si potrebbe lavorare in questo senso. Il kernel è il vero direttore d'orchestra, e un sistema operativo così, che si lascia "plasmare" a piacimento è un grosso vantaggio.
Il un server sarebbe opportuno ripulire il kernel da cose inutili in questo campo, e magari ottimizzarlo per i processori multicore o per la RAM a disposizione o per che sò io. Magari non mi serve il nuovo scheduler CFS e voglio privilegiare i processi in background. Semplificare la "customizzazione" del kernel in base all'hardware a disposizione sarebbe fantastico. Enormi possibilità.

Ora mi accontento, una volta terminata l'installazione, di mettere in "freeze" gli aggiornamenti del kernel in pacman.conf con un bel

IgnorePkg = kernel26

anche se probabilmente si potrebbe fare di meglio. Va bhè, nessuno e perfetto.
In definitiva possiamo ritenerci fortunati, al giorno d'oggi è più importante un po di "testa" che la distro che si usa.

E adesso lasciatemi riposare che domani mi aspetta una installazione importante: un bel Dell Poweredge con una rete composta da ben 5 utenti e una stampante. Prosit. :D

Che volete di più dalla vita ?