Browse Author by Open Source Expo
Guide

Come Impostare Cflags su Gentoo

Gentoo offre molti tipi di personalizzazioni in fase di compilazione. Anche chi non utilizza Gentoo avrà (a lungo andare) sentito parlare di make.conf. make.conf è il file di configurazione che informa portage su cosa e come passare alcuni parametri di ottimizzazione al compilatore. Tra i vari (tanti) parametri di ottimizzazione che il compilatore offre spicca tra tutti -march , che nella riga del make.conf è contenuta in una riga simile a CFLAGS=”-O2 -march=native -pipe” .

Non mi avventuro nella spiegazione di sudetto parametro , ma vorrei soffermarmi su -march il quale indica al compilatore per quale tipo di Cpu ottimizzare il codice della compilazione .

Esempio : -march=pentium ottimizzerà il codice per un pentium di prima generazione ; -march = pentiumpro ottimizzerà il codice per un pentium pro e così via. Compilazioni generiche sono : x86_64 , i686 , i586 etc per codice comune a quelle architetture non eccessivamente ottimizzato. Dalla versione 4.2 di GCC è possibile passare il parametro native a -march ; questo setterà automaticamente le opzioni della propria cpu nel caso si abbia dei dubbi su cosa passare al compilatore. Ma “native” quale impostazione utilizzerà ? Quale “architettura” passerà al compilatore ? Scopriamolo con questo test :

# gcc -march=native -E -v – </dev/null 2>&1 | sed -n ‘s/.* -v – //p’
Controllare cosa riporta nell’output il parametro -mtune=

Esempio su un processore Intel(R) Core(TM)2 Solo CPU U3500 @ 1.40GHz :

# gcc -march=native -E -v – </dev/null 2>&1 | sed -n ‘s/.* -v – //p’
Riporterà :

gcc -march=native -E -v – </dev/null 2>&1 | sed -n ‘s/.* -v – //p’
-march=core2 -mcx16 -msahf -mno-movbe -mno-aes
-mno-pclmul -mno-popcnt -mno-abm -mno-lwp -mno-fma -mno-fma4
-mno-xop -mno-bmi -mno-tbm -mno-avx -mno-sse4.2 -msse4.1
–param l1-cache-size=32 –param l1-cache-line-size=64
–param l2-cache-size=3072 -mtune=core2

Quindi per la CPU Intel U3500 -march=native imposterà l’ottimizzazione per un core2.

Un ulteriore codice da passare al compilatore per scoprire come verrà settata -march è :

gcc -march=native -E -v – &1 | grep mtune
Che restituirà un output simile al seguente :

/usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.3/cc1
-E -quiet -v -march=core2 -mcx16 -msahf -mno-movbe
-mno-aes -mno-pclmul -mno-popcnt -mno-abm
-mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi
-mno-tbm -mno-avx -mno-sse4.2 -msse4.1 –param l1-cache-size=32
–param l1-cache-line-size=64 –param l2-cache-size=3072 -mtune=core2

Guide

Come Condividere Pacchetti su più Pc Linux

Durante la fase di installazione o aggiornamento di un pacchetto, esso viene salvato di default in una delle directory /var/lib/entropy/client/packages/{packages,packages-nonfree,packages-restricted} a seconda della tipologia di pacchetto in download.

Tale directory se non ripulita di tanto in tanto (# equo cleanup) può rappresentare un ottimo repository interno dei pacchetti.
Se si hanno più macchine Sabayon da mantenere è possibile condividere nella rete interna (LAN) questa directory sia in lettura che in scrittura tra i vari pc in modo che tutti i client possano accedere ad eventuali pacchetti già scaricati con un guadagno in termini di velocità di download molto rilevante. Tutto questo è possibile utilizzando il protocollo NFS .

Si dovrà decidere quale macchina farà da “storage” per questi pacchetti , quindi da server NFS. Supponendo che la nostra rete d’esempio sia composta da macchine miste (x86 e x86-64) , si configurerà il server solo per la condivisione dei pacchetti e non, per ovvi motivi , del database dei pacchetti installati in quanto ogni macchina potrebbe aver installato applicazioni diverse l’una dall’altra.

Configurazione

Server : su ip 192.168.0.10
Clients : 5 o più macchine con IP da 192.168.0.11 a 192.168.0.15 (o superiore)
Directory che ospiterà i pacchetti : /mnt/packages
(oppure se il server NFS è una macchina Sabayon si può sfruttare la directory di default /var/lib/entropy/client/packages)

La directory che ospiterà i pacchetti (nell’esempio /mnt/packages) potrebbe essere una partizzione dedicata con spazio a disposizione sufficiente.
Modificare gli indirizzi IP e percorsi secondo le proprie esigenze.

…::: Configurazione del server NFS :::…

Nota : A seconda della distribuzione in uso , per la configurazione di un server NFS fare riferimento alla documentazione fornita dalla distribuzione stessa.La seguente procedura fa riferimento ad un sistema Gentoo-based.
Una volta individuato quale macchina farà da server NFS , procediamo alla sua configurazione . Di default NFS è già installato e configurato a livello del kernel. Installare nfs-utils se non presente.

# equo i nfs-utils
Editare il file /etc/exports per configurare la cartella e le opzioni di mount

# nano -w /etc/exports
ed inserire

/mnt/packages 192.168.0.11/15(rw,no_root_squash,no_subtree_check)
La riga indica che la cartella /mnt/packages sarà condivisa con gli host con IP dal 192.168.0.11 all’ IP 192.168.0.15 ed avranno i permessi di scrittura e lettura (rw) , si dà l’accesso alla cartella all’utente root del client ( no_root_squash ) . Salvare ed uscire dall’editor.

Avviare NFS

OpenRC

# /etc/init.d/nfs start
# rc-update add nfs default
Systemd

# systemctl start nfsd.service
# systemctl enable nfsd.service
Nota : Se si dovesse modificare per qualche motivo /etc/exports , riavviare il servizio nfs o nfsd.service
Ora la cartella è pronta per essere condivisa con i vari client di rete.

Configurazione dei client NFS

Montare al volo la cartella remota per ogni client

# mount -o rw,_netdev,nolock,auto -t nfs 192.168.0.10:/mnt/packages /var/lib/entropy/client/packages
Montare all’avvio la cartella remota per ogni client

Editare /etc/fstab ed inserire la seguente riga

192.168.0.10:/mnt/packages /var/lib/entropy/client/packages nfs rw,_netdev,nolock,auto 0 0
Per ogni client occorre avviare un servizio per permettere l’accesso al protocollo NFS.

OpenRC

# /etc/init.d/nfsmount start
# rc-update add nfsmount default
Systemd

# systemctl start rpc-mountd.service
# systemctl enable rpc-mountd.service
Ora per ogni client occorre modificare il file di configurazione del repository perché punti al download verso la cartella condivisa editando il file

/etc/entropy/repositories.__conf.d/entropy_

dove corrisponde al repository in uso (sabayonlinux.org oppure sabayon-weekly o altro) ed aggiungere alla fine del file la seguente riga :

pkg = file:///mnt/packages

Salvare ed uscire dall’editor.

Ora /mnt/packages così come tutto il suo contenuto è condiviso su tutta la rete LAN per gli Host specificati.
Se ad esempio un Client richiede l’installazione di Libreoffice , esso verrà scaricato una sola volta dai mirror ufficiali e sarà condiviso in LAN con gli altri client. Se un qualsiasi Client nella rete dovesse richiedere lo stesso pacchetto , esso verrà scaricato direttamente dalla cartella del Server della LAN sfruttando la velocità maggiore di quest’ultima e risparmiando a sua volta banda di rete verso l’esterno ed un minor stress per i server ufficiali.
A lungo andare , la cartella condivisa dei pacchetti potrebbe aumentare di dimensione o alcuni pacchetti potrebbero diventare obsoleti nel tempo per cui non sarebbe più necessario mantenerli Si potrebbe procedere alla pulizia completa della cartella con :

# equo cleanup
oppure eliminare i file più vecchi di un determinato tempo schedulando un semplice comando bash . Comando che faremo eseguire solo al Pc adibito a Server NFS.

Esempio: Eliminare i file più vecchi di 120 giorni

# find /mnt/packages -name “*.*” -type f -mtime +120 -exec rm {} \;
Esempio: Rimozione dei pacchetti più vecchi di 60 giorni ogni 4 mesi alle ore 20:30

Editare il file /etc/crontab ed aggiungere :

30 20 * */4 * root find /mnt/packages/ -name “*.*” -type f -mtime +60 -exec rm {} \;
Salvare ed uscire dall’editor.
Automaticamente ogni quattro (*/4) mesi alle ore 20:30 (30 20) verranno rimossi (-exec rm {} /; ) i pacchetti più vecchi di 60 giorni (-mtime +60).

Guide

Come Comprare una Chitarra Usata

Per prima cosa, bisogna sempre preferire la prova di uno strumento usato: ci sono alcuni elementi, come anche solo le rifiniture dei tasti o del body, le condizioni precise dell’elettronica, che solo una prova in prima persona ci possono far comprendere bene. Ma alle volte le occasioni si trovano lontano da casa, che fare quindi? In questa guida cercheremo di analizzare entrambe le possibilità.

Per prima cosa dovete contattare il venditore, controllando che, ovviamente, la chitarra sia ancora in vendita. Se non è più in vendita, abbandonate pure questa guida, in caso contrario andate avanti.

A questo punto, dovete controllare che il venditore sia affidabile, e non stia cercando di rifilarvi una ciofeca o, ancor peggio, una chitarra “falsa”, cioè spacciata magari per un marchio famoso quando in realtà appartiene ad uno meno. Appartenere ad un marchio poco noto non è necessariamente un male, anzi, spesso si trovano chitarre con ottimi rapporti qualità/prezzo; però non è onesto spacciare una marca per un’altra, magari anche con un conseguente aumento di prezzo.
Quindi, informatevi bene sulla chitarra che volete prendere: fatevi mandare delle foto, e confrontatele con i siti del produttore. Questa parte è particolarmente importante se non avete la possibiltà di provare la chitarra: ma ne parlerò più avanti.

Una volta controllata l’affidabilità del venditore, le cose cambiano, a seconda della possibilità di una prova o meno. Se avete la possibiltà di provarla, è consigliabile controllare alcune cose: in primis la curvatura del manico, e la posa e la rifinitura dei tasti(cercate anche eventuali buzz o tasti “muti”, eseguendo note su tutta la tastiera, ma anche accordi completi); poi il bilanciamento del body; controllate pure che l’elettronica funzioni, con tutti i pickup ed eventuali fruscii o altri problemi; controllate anche la tenuta di accordatura. Se avete paura di sbagliare, fatevi accompagnare da un amico che provi la chitarra per voi. A questo punto, se la chitarra è di vostro gradimento, dopo aver concordato sul prezzo col venditore e la modalità di pagamento, compratela!

Se invece non avete la possibiltà di provare di persona, l’unica possibilità è fidarsi del proprio occhio e dell’onesta del venditore: informatevi ancora meglio sulla chitarra, e, se possibile, anche sul venditore. Fatevi lasciare dei dati dal venditore (nome e cognome, numeri di telefono vari, possibilmente anche di dove è). Non fidatevi di chi non vuole dirveli: se non ha niente da nascondere lo farà. Fatevi inviare più foto possibili: tasti, curvatura manico, body (con eventuali imperfezioni), ponte, vano elettronica. Controllate che sia tutto in ordine, poi concordate bene con il venditore il prezzo, la modalità di pagamento e le spese di spedizione. Ovviamente è necessario anche scegliere un sistema di pagamento sicuro e sull’argomento è possibile vedere questa guida su Frangenticulturali.com.

A questo punto, aspettate solo di ricevere la chitarra.

Guide

Come Installare Wine su Ubuntu da Terminale

Recentemente è stata rilasciata una nuova versione del software Wine, quindi ecco che non possiamo non parlare di questo tool e della sua installazione, va anche detto che non è la prima volta che trattiamo questo argomento, ma questa volta andremo a vedere come installare in modo veloce e indolore questo programma sul nostro OS Ubuntu 11.10 e 12.04.

Prima di continuare con la nostra guida, vediamo di rispondere a questa domanda: Che cos’è Wine?
Per chi nono lo sapesse oppure se lo fosse dimenticato Wine è un software che permette di eseguire sui sistemi operativi Linux software dedicati solo ai sistemi operativi Windows, senza che vi sia la presenza del sistema operativo marchiato Microsoft installato sulla nostra macchina. Questa magnifica “magia” è resa possibile perché il tool Wine implementa uno strato intermedio tra i due sistemi, in poche parole il software non fa altro che tradurre le richieste del programma Windows in chiamate native per i sistemi Linux. Sembrerebbe quasi un non senso, visto che, giorno dopo giorno, sono sempre di più gli applicativi nativi per Linux in grado di coprire il più vasto numero di esigenze, ma quasi tutti dispongono di una utility o di un programma che sono disponibili solo per Windows e quindi grazie a Wine possono usare il sistema operativo OpenSource senza rinunce.

Questo in poche parole e in pochi concetti è il tool Wine.

Adesso che abbiamo fatto mente locale su che cos’è Wine e a cosa serve, lasciamo le parole di troppo e mettiamoci a lavoro . Come prima cosa, avviamo il nostro Terminale e diamogli in pasto i seguenti comandi:

sudo add-apt-repository ppa:ubuntu/wine/ppa
sudo apt-get update
sudo apt-get install wine1.5

Molto interessante.

Guide

Come Aggiornare il Kernel Linux con Genkernel

Genkernel, per chi ancora non lo conoscesse, è una specie di script che va ad automatizzare la compilazione del kernel. Lo scopo principale è quello di rilevare automaticamente la configurazione hardware del sistema.

Genkernel è un tool per la compilazione di un kernel Linux per la distribuzione Gentoo.
Genkernel compila il kernel con ogni driver per l’hardware inserito come modulo, poi copia questi nel disco RAM che è passato al kernel al momento del boot, offrendo un’identificazione automatica dell’hardware. Questo tool è pensato per gli utenti meno esperti nella configurazione di un kernel Linux che devono affrontare questo problema.
La ragione principale per la creazione di genkernel è che la configurazione e la compilazione del kernel avvengono durante l’installazione di Gentoo, e questo rappresenta un problema per i nuovi utenti. Gli utenti esperti, invece, preferiscono configurare e compilare il kernel manualmente.

Per prima cosa è sincronizzare emerge e andare a installare/aggiornare genkernel. Per far questo bisogna andare ad aprire un terminale e con privilegi di amministratore dare il comando:

emerge –sync && layman -S
per sincronizzare, mentre per installare genkernel:

emerge genkernel
In alternativa è possibile installare genkernel utilizzando il pacchetto presente in Entropy o via terminale con equo install.

Al comando emerge genkernel avrete un output simile al seguente:

sabayonportatile carlo # emerge genkernel

* IMPORTANT: 7 news items need reading for repository ‘gentoo’.
* Use eselect news to read news items.

* IMPORTANT: config file ‘/etc/portage/package.use’ needs updating.
* See the CONFIGURATION FILES section of the emerge
* man page to learn how to update config files.
Calculating dependencies… done!

>>> Verifying ebuild manifests

>>> Emerging (1 of 1) sys-kernel/genkernel-3.4.19
* genkernel-3.4.19.tar.bz2 RMD160 SHA1 SHA256 size 😉 … [ ok ]
* dmraid-1.0.0.rc14.tar.bz2 RMD160 SHA1 SHA256 size 😉 … [ ok ]
* mdadm-3.1.4.tar.bz2 RMD160 SHA1 SHA256 size 😉 … [ ok ]
* LVM2.2.02.74.tgz RMD160 SHA1 SHA256 size 😉 … [ ok ]
* device-mapper.1.02.22.tgz RMD160 SHA1 SHA256 size 😉 … [ ok ]
* busybox-1.18.1.tar.bz2 RMD160 SHA1 SHA256 size 😉 … [ ok ]
* open-iscsi-2.0-872.tar.gz RMD160 SHA1 SHA256 size 😉 … [ ok ]
* e2fsprogs-1.41.14.tar.gz RMD160 SHA1 SHA256 size 😉 … [ ok ]
* fuse-2.7.4.tar.gz RMD160 SHA1 SHA256 size 😉 … [ ok ]
* unionfs-fuse-0.22.tar.bz2 RMD160 SHA1 SHA256 size 😉 … [ ok ]
* gnupg-1.4.11.tar.bz2 RMD160 SHA1 SHA256 size 😉 … [ ok ]
>>> Unpacking source…
>>> Unpacking genkernel-3.4.19.tar.bz2 to /var/tmp/portage/sys-kernel/genkernel-3.4.19/work
>>> Source unpacked in /var/tmp/portage/sys-kernel/genkernel-3.4.19/work
>>> Compiling source in /var/tmp/portage/sys-kernel/genkernel-3.4.19/work/genkernel-3.4.19 …
>>> Source compiled.
>>> Test phase [not enabled]: sys-kernel/genkernel-3.4.19

>>> Install genkernel-3.4.19 into /var/tmp/portage/sys-kernel/genkernel-3.4.19/image/ category sys-kernel
* Copying files to /var/cache/genkernel/src…
* bash-completion.eclass has been deprecated.
* Please update your ebuilds to use bash-completion-r1 instead.
>>> Completed installing genkernel-3.4.19 into /var/tmp/portage/sys-kernel/genkernel-3.4.19/image/

ecompressdir: bzip2 -9 /usr/share/man

>>> Installing (1 of 1) sys-kernel/genkernel-3.4.19

* Documentation is available in the genkernel manual page
* as well as the following URL:

* http://www.gentoo.org/doc/en/genkernel.xml

* This package is known to not work with reiser4. If you are running
* reiser4 and have a problem, do not file a bug. We know it does not
* work and we don’t plan on fixing it since reiser4 is the one that is
* broken in this regard. Try using a sane filesystem like ext3 or
* even reiser3.

* The LUKS support has changed from versions prior to 3.4.4. Now,
* you use crypt_root=/dev/blah instead of real_root=luks:/dev/blah.

* The following bash-completion scripts have been installed:
* genkernel
*
* To enable command-line completion on a per-user basis run:
* eselect bashcomp enable
a questo punto, sempre con privilegi di amministratore, andiamo a dare il comando:

USE=”sources_standalone” emerge sabayon-sources
seguito da:

eselect kernel list
come si vede dal seguente output, eselect andrà a creare un elenco dei kernel possibili:

[1] linux-2.6.39-sabayon *
[2] linux-3.0
[3] linux-3.0.0-fusion
[4] linux-3.0.0-sabayon
Starà a noi scegliere quale kernel utilizzare. L’importante è segnarsi il numero del kernel interessato. Il numero, che da ora lo chiameremo X, ovviamente è quello compreso fra parentesi quadre.
Andiamo quindi a definire il kernel desiderato:

eselect kernel set x
#NB. al posto di X va inserito il numero del Kernel

zcat /proc/config.gz > /usr/src/config
Arrivati qui la parte più complicata è fatta, infatti non ci resta altro che dare il comando:

genkernel –kernel-config=/usr/src/config –menuconfig –bootloader=grub –splash=sabayon –disklabel –luks all
Se si sceglie di editare manualmente le partizioni, altrimenti utilizzare:

genkernel –kernel-config=/usr/src/config –menuconfig –bootloader=grub –splash=sabayon –disklabel –lvm –luks all
se, sempre per quanto riguarda le partizioni, ci si vuole affidare ad anaconda/diskdruid

Consiglio la lettura del paragrafo 2 e 3 della guida a genkernel in Gentoo Linux per comprendere meglio le flag di compilazione.

Infine, se necessitate della ricompilazione dei moduli potete usufruire del comando:

module-rebuild rebuild