Dopo varie peripezie, sono finalmente riuscito a montare e iniziare a usare il nuovo PC.

La parte più “delicata” del tutto è la scheda madre. Non volevo spendere un capitale, ma nemmeno mettere roba troppo vecchia, quindi ho puntato sulla MoBo in oggetto per diversi motivi: 6 porte USB esterne e 4 interne, 6 porte SATA interne e 2 esterne, 4 slot DDR2 (con supporto dualchannel) e scheda WiFi integrata. Le altre caratteristiche erano meno importanti, ma comunque utili: firewire, un (solo) connettore PATA, ethernet 10/100/1000, due connettori PCIe (16x e 4x) oltre ai due PCIe 1x e ai tre PCI (che non uso, eliminando anche la scheda WiFi che era l’ultima rimasta sul vecchio PC, a parte la scheda video).

Wi-Fi

Il dubbio più grosso era sulla scheda WiFi, inizialmente perché non sapevo nemmeno quale chipset montasse e poi, avendolo scoperto, sul suo supporto. Si tratta infatti di un Realtek 8187. La mia precedente esperienza con questo chipset era stata disastrosa, al punto che ho reinscatolato la scheda e ne ho comprata un’altra con chipset Atheros, già allora (circa 3 anni fa) abbastanza ben supportato.

Mi sono quindi guardato intorno e ho scoperto che il kernel 2.6.24 (appena uscito) la supporta.

Finito di installare la Debian testing, attraverso la Ethernet ben supportata dal kernel 2.6.21 che c’era sul DVD di installazione, ho scaricato dai repository il nuovo kernel, prendendolo direttamente da “pool” tramite lynx e ho installato tutto. Ho scaricato anche i pacchetti necessari a module-installer, perché in seguito mi sarebbero serviti per i driver fglrx, necessari per avere il 3D sulla nuova Radeon HD3870.

Riavviato il computer, il (magico) udev ha rilevato la scheda WiFi senza alcun problema, e ho dovuto solo dare un paio di comandi:

iwlist scan    			# per vedere se funzionava e rilevare l'AP
iwconfig essid MioEssid    	# Per associarla con l'AP
ipconfig wlan0 1.2.3.4    	# Per assegnare l'IP statico
route add default gw 1.2.3.1    # Per impostare la route verso l'AP

Tutto perfetto (dopo aver impostato i DNS in /etc/resolv.conf naturalmente), 1 minuto ed ero in rete. Non mi era mai successo con le schede WiFi. Sembra che il nuovo stack WiFi nel kernel funzioni bene, e anche il kernel di per sé sembra molto stabile, almeno per i 3 giorni di funzionamento continuato che sono riuscito a fare.

L’unico problema l’ho avuto con network-manager. L’avevo installato sperando mi “desse una mano” nella configurazione, ma visto che uso un IP statico per esigenze di forwarding dall’AP al PC, alla fine non l’ho usato. Solo che ogni tanto, senza apparente ragione, la scheda perdeva la portante, per poi riprenderla qualche secondo dopo.

Secondi sufficienti a rallentare mostruosamente i trasferimenti, e a far cadere anche qualche connessione per timeout. Non me ne sono accorto subito perché ogni tanto succedeva anche prima, a causa della linea ADSL.

Rimosso network-manager, la scheda non ha più avuto problemi. Ho quindi provveduto a configurare /etc/network/interfaces per attivarla al boot.

CPU e RAM

La CPU che ho scelto è un Intel Core 2 Duo E6550, a 2,33 GHz.

Da questo punto di vista nessunissimo problema. Linux riconosce due processori e lavora in parallelo. Un mostro in confronto al vecchio Athlon XP 2400.

Qualche problemino dal punto di vista della RAM, ma solo perché non ci ho perso troppo tempo: ho installato la Lenny a 32bit (per rimanere compatibile con alcuni software che dovrò far girare, è un po’ lunga…) e “vede” solo 3.5 GiB dei 4 installati. Magari nei prossimi giorni proverò il kernel bigmem (che supporta fino a 16 GiB) e vedrò cosa salta fuori.

Tutto il resto

Non ho avuto occasione di provare il firewire, perché non ho nessuna periferica di quel tipo, ma tutto il resto funziona al primo colpo: USB 2.0, scheda audio (funziona talmente in automatico che non so nemmeno che chipset monti), ethernet (stesso discorso della scheda audio), SATA (il disco appare come SCSI: /dev/sda), PATA (riconosciuti lettore e masterizzatore DVD), e anche il pannello frontale con lettore di flashcard e porte USB, ma questo lo sapevo già visto che lo usavo anche prima.

La scheda video richiede i driver closed source fglrx per funzionare in 3D. Purtroppo i driver liberi radeonhd (peraltro inclusi in Debian) non supportano ancora l’accelerazione 3D, e sono ancora indietro anche per l’accelerazione 2D. Fortunatamente Debian pacchettizza tutto e basta un

m-a a-i fglrx

per installarli, e un

aticonfig --initial

per configurare Xorg.

Non ho ancora avuto occasione di provare a fondo la nuova scheda video, ma il tutto è sicuramente molto più silenzioso del precedente. Ho scelto tutto in modo che “downclocki” quando non viene usato, quindi le ventole sono quasi ferme.

Accorcio il titolo dei post, perché ormai non si tratta più solo di portatili e server, ma rientrano anche i client. L’argomento di oggi infatti è totalmente trasversale e riguarda tutti gli usi possibili.

Per motivi di efficienza nell’allocazione delle risorse, ogni (buon) programma su Linux si appoggia a una serie più o meno lunga di librerie condivise, le cosiddette Shared Objects, riconoscibili per l’estensione .so

Queste librerie sono gestite in modo da averne in memoria una sola copia in ogni momento, e tutti i software che hanno bisogno delle funzioni fornite leggono dalla stessa copia in memoria. In questo modo si risparmia RAM e tempo di caricamento da disco, in quanto la libreria viene letta da disco una volta sola e poi viene collegata (link) agli eseguibili che ne fanno richiesta.

Ma c’è un problema: ogni programma ha una sua area di memoria isolata dagli altri programmi, e il kernel deve mappare all’interno di ognuna di queste aree le diverse librerie, e ricalcolare tutti gli offset delle funzioni all’interno del binario che le richiama. Questa operazione ha il vantaggio di slegare completamente il binario dalle librerie (possiamo avere due versioni della stessa libreria in memoria con due software diversi che le usano, e caricarli quando vogliamo), ma ha lo svantaggio che, al caricamento del programma, tutte queste mappature devono essere ricalcolate.

Ma c’è, naturalmente, un modo per rendere più efficiente questa operazione.

(continua…)

Da un po’ sto raccogliendo informazioni per la seconda parte di questo articolo, cercando di estrapolare solo suggerimenti non troppo complicati da applicare.

Durante questa ricerca sono incappato in due documenti che raccolgono una messe di informazioni su come configurare varie componenti in diversi modi.

Non sono sempre “digita e dimentica”, anzi, a volte richiedono un’analisi preventiva dell’hardware presente, e un tuning dei parametri per funzionare al meglio, ma sono una bella lista abbastanza completa. Alcune cose le ho già scritte nella prima parte di questo articolo.

Ma ecco i link: Velocizzare Debian e Recuperare spazio sull’HD.

I consigli sono diretti a utenti Debian, ma la maggior parte sono validi per qualsiasi distribuzione.

Non tutti sono da applicare ad occhi chiusi, ma richiedono una minima conoscenza del (sotto-)sistema che si sta configurando. Magari in futuro ne estrapolerò qualcuno e lo approfondirò qui. Nel frattempo ne approfitto per ringraziare il progetto Linguistico per queste e per le altre guide che hanno pubblicato, oltre che per i dizionari e i thesaurus in italiano, naturalmente.

Ci sono molti piccoli accorgimenti che si possono adottare per adattare il nostro sistema Linux all’uso che lo aspetta, che si tratti di un sistema desktop o di un server.

Martin Michlmayr ha pubblicato un paio di articoli su come ottimizzare Linux per l’uso su dispositivi embedded (NSLU2 nel caso specifico): per la riduzione della memoria occupata e per il funzionamento su memorie flash.

Ma molti consigli valgono anche in generale per migliorare le prestazioni di Linux, sia su dispositivi portatili che non. Ne traduco qui alcuni e mi permetto di aggiungerne altri che possono tornare utili, con un’occhio all’uso desktop e uno all’uso server. (continua…)