# [HOWTO] Volare con Gentoo

## ErniBrown

Mi è piaciuto molto questo post, per cui lo ho tradotto in italiano: ammetto che alcune parti, come ad esempio quelle riguardanti lo swap e rc-update, possono risultare vecchiotte, ormai acquisite da tutti gli utenti linux, ma in ogni modo spero possa tornare utile!!! 

PS: perdonatemi se non traduco tutti i link a cui fa riferimento, il lavoro diventerebbe titanico  :Wink:  ! Comunque se trovate le traduzioni già fatte, mandatemi gli indirizzi delle versioni in italiano.

PS2: tutte le configurazioni si riferiscono all'howto originale: appena avrò finito di sperimentare tutto metterò come esempi la mia configurazione.

COME OTTIMIZZARE E VELOCIZZARE IL SISTEMA  

...ovvero come volare con gentoo 

Questa guida è il risultato di alcuni post del forum e di alcune ricerche fatte sulle mie gentoo boxes provando svariati programmi e opzioni. Mentre alcuni di essi sono completamente sicuri, altri possono danneggiare il sistema! Vi suggerirei quindi di effettuare un back-up dei vostri dati importanti, provare queste ottimizzazioni su macchine di test e quindi portarle su macchine d produzione.

Queste migliorie avranno sicuramente un grande effetto su un vecchio computer, mentre i risultati saranno meno evidenti su un computer veloce.

SOMMARIO

 Come fare prove in sicurezza

 Ottimizzazione degli script di init

 Usare rc-update

 Cflags e ldflags

 Usare hdparm

 E' necessario prelinkare?

 Usare partizioni Swap

 Ccache

 Distcc

 Flag USE

 Modificare gli ebuild e ingannare il sistema

 Spegnimento vs Sospensione

 Xdelta - Deltup

 NPTL

 GCC

 Filesystems [Sicurezza dei dati vs velocità]

 Scripts utili

 Link interessanti

1. Come fare prove in sicurezza 

Per provare nuovi ebuild e testare nuove configurazioni ho fatto un installazione dentro chroot, in modo che sia completamente sicura. C'è una guida qui per fare ciò ed essere in grado di testare questo howto senza danneggiare il sistema. In alternativa potete usare vmware o uml, ma credo che questa sia il metodo più veloce.

Una volta fatta l'installazione in chroot ho fatto un'immagine compressa, in modo che ognivolta che il sottosistema crasha a causa dei miei tes sono in grado di riprendere i test con un sistema appena installato.

2. Ottimizzazione degli script di init 

Alcune delle operazioni eseguite quando avviate il sistema non sono sempre necessarie. Modificando gli script è possibile fare in modo che vengano eseguite solo quando realmente necessario:

/etc/init.d/modules

cambiate: 

```
ebegin "Calculating module dependencies"

    /sbin/modules-update &>/dev/null

eend $? "Failed to calculate dependencies" 
```

in:

```
if [ /etc/modules.d -nt /etc/modules.conf ]

    then

        ebegin "Calculating module dependencies"

        /sbin/modules-update &>/dev/null

        eend $? "Failed to calculate dependencies"

    else

        einfo "Module dependencies are up-to-date"

fi 
```

Così facendo modules-update verrà eseguito solo se effettivamente necessario a causa di modifiche al sistema

/etc/init.d/localmount 

cambiate:

```
mount -at nocoda,nonfs,noproc,noncpfs,nosmbfs,noshm >/dev/null
```

in:

```
mount -aFt nocoda,nonfs,noproc,noncpfs,nosmbfs,noshm >/dev/null
```

Questo farà partire tutti i punti di montaggio locali allo stesso momento, e non uno dopo l'altro

/etc/init.d/bootmisc 

cambiate:

```
if [ -x /sbin/env-update.sh ]

then

    ebegin "Updating environment"

    /sbin/env-update.sh >/dev/null

    eend 0

fi
```

in:

```
if [ -x /sbin/env-update.sh ]

then

    if [ /etc/env.d -nt /etc/profile.env ]

    then

        ebegin "Updating environment"

        /sbin/env-update.sh >/dev/null

        eend 0

    else

        einfo "Environment up-to-date"

    fi

fi
```

Così facendo env-update verrà eseguito solo quando effettivamente necessario in seguito a modifiche del sistema

/etc/conf.d/rc 

cambiate:

```
RC_PARALLEL_STARTUP="no"
```

in:

```
RC_PARALLEL_STARTUP="yes"
```

Questo farà partire tutti i servizi contemporaneamente, e non uno dopo l'altro

3. Usare rc-update

Grazie ad rc-update è veramente facile gestire i runlevels:

per vedere come sono settati i runlevel di boot:

```
# rc-update show
```

per togliere un servizio dall'avvio automatico:

```
# rc-update del applicazione runlevel
```

per aggiungere un'applicazione:

```
# rc-update add application runlevel
```

Ad esempio ho configurato certi servizi nel runlevel di boot ed altri ancora in quello di default.

Inoltre bisogna sottolineare che alcuni servizi devono essere avviati dopo altri (ovvero "dipendono" da altri): potete verificare le dipendenze editando il file /etc/init.d/service e controllando le prime righe, dove sono dichiarate le dipendenze. Ad esempio se volete lanciare sshd dovrete prima lanciare i servizi di rete.

Recentemente ho creato un nuovo runlevel (battery) dove ho aggiunto tutto ciò che voglio venga lanciato quando non sono collegato alla rete elettrica. Quindi, con l'aiuto di acpid's, ho configurato il runlevel on modo tale che quando scollego la rete, il sistema passa automaticamente al runlevel battery, e quando ricollego la rete torna al runlevel default. In questo modo quando passo alla batteria utilizzo speedfreq, hdparm e iwconfig per ridurre il consumo di corrente dell'harddisk, della scheda wireless e del processore.

Potete conoscere l'attuale runlevel usando rc-status:

```
# rc-status

Runlevel: battery

acpid                                          started

alsasound                                      started

domainname                                     started

gpm                                            started

hdparm.battery                                 started

local                                          started

metalog                                        started

speedfreq.battery                              started

vixie-cron                                     started

wireless.baterry                               started
```

altre informazioni su RC- qui

Per coloro che avviano X direttamente (xdm, gdm,kdm, ...) ho letto che è possibile aggiungere xdm e le sue dipendenze direttamente nel runlevel di boot, in modo tale che X venga caricato all'avvio, mentre il resto del sistema viene caricato in background.

4. cflags and ldflags

Le CFLAGS (che possono essere settate nel file /etc/make.conf) sono parametri che vengono passati a gcc quando compiliamo un pacchetto. Si può essere più o meno cauti, in questa pagina e in quest'altra si trovano un sacco di informazioni e raccomandazioni sull'uso delle varie CFLAGS. Le mie CFLAGS per il mio pentium4 sono le seguenti:

```
CHOST="i686-pc-linux-gnu"

CFLAGS="-march=pentium4 -mcpu=pentium4 -O3 -pipe -fforce-addr -falign-functions=4 -fprefetch-loop-arrays -fomit-frame-pointer"
```

nota: le cflags sono leggermente differenti per gcc 3.4.X: ad esempio -mcpu è deprecato, andrebbe usato -mtune al suo posto.

nota2: pentium-m è compatibile con le architetture centrino: le CFLAGS del mio laptop centrino sono le seguenti:

```
CFLAGS="-O3 -march=pentium-m -mtune=pentium-m -pipe -ftracer -fomit-frame-pointer -ffast-math -momit-leaf-frame-pointers"
```

Come per le CXXFLAGS, -fvisibility-inlines-hidden viene comunemente considerata un'ottima flag per migliorare la velocità di compilazione.

Anche Frepo viene considerata una buona cxxflag, ma non sembra funzionare molto bene sul mio sistema.

Anche le ldflasg sono estremamente interessanty, sono discusse dettagliatamente qui e qui. Ldflags sono ottimizzazioni per il loader dinamico (ld), cioè più o meno lo stesso modo in cui prelink dovrebbe funzionare. Io le uso e non ho avuto nessun problemma nell'emerge di nuovi pacchetti

```
LDFLAGS="-Wl,-O1 -Wl,--enable-new-dtags -Wl,--sort-common -s"
```

Qualcosa di più stabile potrebbe essere:

```
LDFLAGS="-Wl,-O1"
```

nota: nel -W sono "L", non "1"

nota2: alcuni utenti hanno riscontrato errori usando le ldflags, se avete problemi nella compilazione di un pacchetto provate a rimuoverle (e postate ldflags/package in questo thread).

CONCLUSIONE:  Le cflags e ldflags sono e saranno sempre una materia in cui ognuno ha la sua opinione: la cosa migliore è testarle personalmente, fare qualche benchmark, e tenere solo le flags giuste per il vostro sistema. Inoltre provate sempre a leggere tutte le discussioni nei forum a proposito dell'argomento, in modo da farvi prima un'idea. Un ottimo programma per stabilire quali cflags dovreste usare è ACOVEA (presente nel portage tree), un tool di benchmarking che effetua svariati test e setta le variabili: il test standard dura circa 15 ore. Per script e risultati per ACOVEA fate riferimento a questo thread

5. Usare hdparm

Un'altra importante applicazione è hdparm. Permette di configurare i prametri dell'hard disk, in modo da ottenere le migliori performance possibili

```
# emerge hdparm

# rc-update add hdparm default
```

Per vedere la configurazione attuale:

```
# hdparm -i /dev/hda
```

Per testare la velocità:

```
# hdparm -Tt /dev/hda
```

Nel mio computer ho modificato /etc/conf.d/hdparm per ottenere il massimo dal mio hard disk

```
hda_args="-d1 -X69 -c1"

cdrom0_args="-d1"
```

Se cercate altre informazioni il man è molto utile

```
# man hdparm
```

Inoltre date un'occhiata a questo tutorial.

6. E' necessario... prelinkare?

Prelink è una potente applicazione, permette di pre linkare le librerie necessarie per un eseguibile prima di usarlo. Quindi, invece di cercare soltanto le librerie necessarie all'eseguibile prelink lo modifica aggiungendo una breve descrizione delle librerie che usa. In questo modo non sarà più necessario cercare le librerie condivise ogni volta che l'eseguibile viene lanciato, rendendolo più veloce.

Importante: ogni volta che upgradate le librerie necessarie per gli eseguibili (ad esempio glibc) dovrete rilanciare prelink sul sistema!

Questa ottimizzazione si rivela molto utile quando vengono lanciati eseguibili di grande dimensione e complessità come ad esempio KDE (ed inoltre, prelinkando il vostro sistema KDE non avrà più bisogno di lanciare kdeinit, diventando quindi molto più veloce all'avvio). Gli eseguibili di piccole dimensioni invece sono già estremamente veloci, per cui prelink non apporta grandi vantaggi.

Requisiti: gli eseguibili devono essere compilati con le binutils-2.13.90.0.xx e gcc-3.2 o superiori, ed inoltre devono essere installate le glibc-2.3.1.r2 o superiori. La dimensione degli eseguibili sarà superiore con prelink, ed inoltre lanciare il processo richiederà sufficiente spazio libero sull'hard disk.

Cominciate quindi con:

```
# emerge prelink
```

Cercate il file di config /etc/prelink.conf

```
# prelink -afmR
```

Questo è l'uso più comune di prelink: in questa maniera TUTTI gli eseguibili saranno prelinkati, ed inoltre verrà verificato se sono stati prelinkati precedentemente.

E' possibile che prelink riporti degli errori: questo è dovuto al fatto che non tutti gli eseguibili possono essere prelinkati (come ad esempio quelli compressi con upx).

Altre informazioni qui e sul man di prelink

7. Usare partizioni swap

In questa sezione voglio soltanto ricordare alcune cose che possono tornare molto utili.

Innanzitutto se avete due hard disk ricordatevi di mettere la partizione di swap sul secondo disco (ovviamente con la partizione di root nel primo)(e con i due dischi montati su canali separati, N.d.T.), in modo da migliorare i tempi di lettura e scrittura.

Inoltre non è consigliabile usare un file come spazio di swap: l'ho provato una volta, cancellando la partizione di swap e impostando un file ./swap di 256 MB modificando fstab. Questo metodo è decisamente più lento di una partizione dedicata, dato che il sistema deve trovare il file, aprirlo, stabilire cosa c'è scritto sopra, riscriverci, salvarlo e chiuderlo. COn una partizione dedicata il processo risulta molto più veloce

Un concetto abbastanza recente è quello della "swappiness" (solo nei kernel 2.6 o superiori). Quando un'applicazione fa richiesta per della memoria e la RAM è piena il sistema operativo ha due opzioni: o pulisce la RAM eliminando i dati ormai vecchi, oppure sposta i processi in attesa nello spazio di swap. Negli ultimi kernel è possibile impostare una variabile che indica al kernel a quale di queste due tendenze dare maggiore peso

/etc/sysctl.conf:

```
vm.swappiness = 40
```

Questo valore può essere compreso tra 0 e 100: più vicino a 0 indica che il kernel deve liberare la maggior quantità di memoria possibile, più vicino a 100 indica di usare più spesso lo spazio di swap

Il vaolre di default è 60. Sul mio laptop è impostato a 25, in modo da ridurre gli accessi al disco. potete usare il comando free per visualizzare le statistiche d'uso della vostra memoria

```
free -m
```

8. Ccache

Ccache è un'applicazione (inclusa in portage ed attivata di default una volta emersa) che mette a disposizione del compilatore una cache. Quindi con questo programma la compilazione risulta velocizzata, soprattutto con i make di grande dimensione.

Potrebbe sembrare che usare una cache in compilazione non sia di nessuna utilità, ma in realtà vengono velocizzate molte operazioni, come ad esempio il make clean.

Per usare ccache basta emergerlo e settare la dimensione di default della cache (leggete le einfo dopo l'emerge). Potete verificare l'installazione usando:

```
# emerge info | grep ccache

ccache version 2.3 [enabled]
```

Inoltre potete visualizzare le statistiche di ccache con il comando:

```
# ccache -s
```

9. Distcc

Distcc è un'applicazione molto utile durante l'installazione di gentoo su di una rete di computer, oppure se il nostro computer è vecchiotto, ma abbiamo a disposizione un altro computer più potente: si occupa di distribuire il processo di compilazione su più computer, in modo da ridurne i tempi. Inoltre fornisce ottimi risultati combinata con ccache.

Non mi soffermerò molto su questo, in quanto non si tratta di una caratteristica usata da tutti (mica tutti hanno a disposizione più di un computer!) e in quanto è un argomento largamente trattato all'interno del forum e in vari tutorial.

L'unica nota particolare riguarda la possibilità di crosscompilare su architetture differenti, semplicemente si spartiranno i task di compilazione (sono riuscito a far funzionare distcc fra un amd e un minimac, N.d.T.)

Per ulteriori informazioni potete fare riferimento a questo documento.

10. Flag USE

Le flag use sono un utile strumento messo a disposizione da gentoo: permettono di configurare in maniera rapida ed intuitiva i pacchetti. Ad esempio, supponiamo che vogliate compilare apache:

```
# emerge -pv apache

[ebuild N ] net-www/apache-2.0.50 -debug -doc -ipv6 +ssl 6,197 kB
```

Ie opzioni precedute da (+/-)  che appaiono dopo il nome del programma che stiamo per installare sono le flag USE che possiamo settare per questo pacchetto. Ad esempio, se non vogliamo che apache usi ssl possiamo emergerlo in questa maniera:

```
# USE="-ssl" emerge -pv apache

[ebuild N ] net-www/apache-2.0.50 -debug -doc -ipv6 -ssl 6,197 kB
```

Si noti che adesso ssl è deselezionata, ed apache verrà compilato senza il relativo supporto

In questo esempio, la flag USE è stata settata direttamente da riga di comando, ma non è questa la maniera corretta: in realtà infatti andrebbe settata nel file /etc/make.conf (se volete che sia settata globalmente), oppure in /etc/portage/package.use (se volete che sia settata soltanto per uno specifico pacchetto)

```
# echo "net-p2p/amule -gtk2 -unicode" >> /etc/portage/package.use
```

Nota: anche per la flag ACCEPT_KEYWORDS si dovrebbe utilizzare questo metodo, cambiando però la destinazione, ovvero aggiungendo il nome del pacchetto e la flag per l'architettura al file /etc/portage/package.keywords.

N.d.T.: l'autore suggerisce anche di impostare ACCEPT_KEYWORDS="x86" nel make.conf se si vuole che sia una flag globale: personalmente, ma credo che sia un consiglio "ufficiale" degli sviluppatori gentoo, non consiglio questo metodo: nella maggior parte dei casi porta ad avere un sistema instabile; inoltre non è facile fare il downgrade di tutto il sistema se qualcosa dovesse andare storto.

```
# echo "app-editors/nano ~x86" >> /etc/portage/package.keywords
```

E' importante controllare le flag USE di un pacchetto prima di installarlo, in modo da disabilitare caratteristiche inutili e risparmiare spazio su disco. Ad esempio se vogliamo emergere il client irc da console BitchX, portage cercherà di installare xmms e X, ed altre dipendenze legate all'ambiente grafico. Impostando le flag USE -xmms e -X in /etc/portage/package.use X ed xmms BitchX verrà installato senza il supporto xmms e X, evitando quindi che vengano scaricati e compilati.

Vi accorgerete che questo è un potente strumento da usare quando emergete, fornisce un ottimo controllo su come i pacchetti vengono installati sul sistema.

C'è una breve descrizione delle flag USE in /usr/portage/profiles/use/desc

N.d.T.: se siete alla prima installazione di gentoo potete anche lasciare delle flag semplici, come "kde -gnome alsa...", al massimo vi verrà installato qualche pacchetto non necessario. Potrete sempre correggere questi "errori" in seguito.

11. Modificare gli ebuild e ingannare il sistema

Perchè ingannare il sistema? Avete presente quando volete installare il pacchetto X, ma a causa di una dipendenza portage vi chiede di installare prima il pacchetto Y? Ad esempio molti utenti preferiscono gestire il kernel senza l'ausilio di portage. Quindi installando un qualunque pacchetto che faccia riferimento ai sorgenti del kernel questo cercherà di emergerli (un buon esempio sono gli alsa-driver), quando in realtà la vostra directory /usr/src è già correttamente configurata. 

Potete dire a portage che un determinato pacchetto è già stato installato manualmente modificando il file /etc/portage/package.provided, aggiungendo una riga relativa ad esso, come ad esempio

```
echo "sys-kernel/ck-sources" >> /etc/portage/profile/package.provided
```

package.provide fornisce a portage esattamente questa indicazione, gli comunica che il pacchetto è già presente sul sistema (anche se non lo è realmente!). Inoltre package.provide non si applica ai pacchetti virtuals: i pacchetti virtuals sono usati per dire a portage quale pacchetto installare per una determinata categoria. Ad esempio potete dire a portage di usare xorg invece di xfree come x11 (in realtà xfree non è più nell'albero di portage, ma rende comunque l'idea)

```
echo "virtual/x11 x11-base/xorg-x11" >> /etc/portage/profile/virtuals
```

Per ulteriori informazioni su portage e sul suo uso vi rimando a "man portage" e a questo post.

12. Spegnimento vs sospensione

Vi siete mai chiesti come mai spegnete il computer quando invece potete soltanto metterlo in sospensione nella ram o su disco? Se lo sospendete in ram avrete il problema di dover continuare a fornire alimentazione al sistema, in modo da mantenere lo stato. Potete però sospenderlo su disco, spegnendo quindi il pc, senza perdere la sessione.

Così facendo eviterete di riavviare tutto il sistema all'avvio, se non un'istanza di recupero dallo stato di sleep, che però è molto veloce.

Ho usato swsusp2 sul mio laptop e funziona egregiamente, ma dovrete patchare i sorgenti del kernel. Potete trovare informazioni in questo post.

13. Xdelta - Deltup

In questo post si discute di Deltup: in breve ogni volta che portage ha bisogno di scaricare un file deltup cercherà nel sistema una versione precedente (in /usr/portage/distfiles) e proverà a scaricare soltanto la differenza fra i due file, creando al volo il nuovo.

Questa utility si rivela molto utile per tutti i gentooisti con un modem 56k che usano /usr/portage/distfiles soltanto per scaricare patch quando nuove "revisions" sono rilasciate, in modo da diminuire la quantità di dati da scaricare.

14. Native POSIX Thread Library (NPTL)

Questa libreria può velocizzare notevolmente il vostro sistema, dato che è 4 volte più veloce che i Threads standard di linux. Dovreste (ma praticamente è un obbligo) usare gli header linux 2.6, e una versione recente di gcc e glibc (magari ~x86). Per usare ntpl dovrete ricompilare le glibc con la flag USE "nptl" attivata.

Qui potete trovare maggiori informazioni a riguardo.

N.d.T.: Le threads NPTL non sono completamente compatibili con le applicazioni che sfruttano le feature realtime del kernel (come ad esempio il server sonoro jack  :Evil or Very Mad:  ). Proprio per motivi di compatibilità la compilazione delle glibc con flag nptl attivata comporta anche la creazione di una versione con thread linux standard; per compilare esclusivamente la versione aggiornata aggiungete la flag nptonly.

15. GCC

GCC è estremamente importante, specialmente in una distribuzione come gentoo, dove l'utente cerca di ottimizzare al massimo il sistema compilando ogni pacchetto che viene installato. Usare una versione aggiornata di gcc porta molti vantaggi, in quanto tutto il codice creato in compilazione sarà ottimizzato meglio. Inoltre permette di avere  un supporto migliore per la propria architettura: ad esempio le architetture centrino sono supportate specificatamente dalla versione 3.4 di gcc, come -march=pentium-m

Per installare l'ultimissima versione di gcc emergetelo dopo aver settato la flag ~x86 (o ~ppc, a seconda della vostra architettura):

```
# echo "sys-devel/gcc ~x86" >> /etc/portage/package.keywords

# emerge -u gcc

```

16. Filesystems [sicurezza dei dati vs velocità]

Dopo aver provato vari filesystem, ho adottato reiser4, in quanto il più veloce disponibile. Penso che sia molto importante usare un filesystem veloce, ma dovrete anche salvare i vostri dati per prevenire errori di corruzione. Inoltre bisogna dire che con ext2, ext3,reiserfs, xfs ed altri filesystem criptati non ho mai avuto problemi di perdita di dati. Soltanto penso sia sempre saggio mantenere una copia dei propri documenti.

Per poter usare reiser4 dovrete usare un kernel patchato, quindi dovrà essere un kernel development

Per convertire la vostra partizione root (/) in reiser4 vi servirà un livecd che lo supporti, come questo, e dovrete inoltre installare un kernel compatibile.

Nota: alcune persone non riescono a trovare reiser4 nel sottomenù Filesystem: assicuratevi di aver deattivato l'opzione "use 4kb for kernel stacks instead of 8kb" nel menù hacking; così facendo troverete l'opzione reiser4.

17. Scripts utili

Nel forum e nel portage tree ci sono alcuni script utili per gestire il sistema:

1- esearch

Esearch è incluso nell'albero di portage: è un'utility che permette di cercare nel database dei pacchetti di portage. La cosa interessante è che è davvero veloce (molto più di emerge -sS).

Come difetto c'è che dopo ogni emerge sync il database di esearch deve essere aggiornato con eupdatedb (anche se si può usare esync, che prima aggiorna il portage tree, poi visualizza la lista dei cambiamenti rispetto all'ultimo sync).

2- eix

Lo stesso concetto di esearch, ma è più veloce, anche nell'aggiornamento del database dei pacchetti. E' un progetto recente, ma funziona abbastanza bene.

Altre informazioni qui

3- Cruft

Questo script genera una lista con tutti i file del sistema che possono essere cancellati in quanto non dipendenti da nessuno dei pacchetti installati. Fate attenzione usandolo, può generare dei falsi positivi!

Uso:

```
# ./cruft > cruft.log
```

A questo punto potete leggere la lista e rimuovere i file che non volete cancellare, e poi lanciare il comando 

```
# cat cruft.log | xargs rm -rf
```

per cancellare i file della lista.

Ovviamente nessuno vi vieta di cancellare manualmente i file della lista

Altre informazioni qui.

4- Stale

Interessante script che aiuta a mantenere /usr/portage/distfiles in uno stato ottimale. Questo script analizzerà la directory e cancellerà i file obsoleti (se lanciato con l'opzione --nopretend), mantenendo quelli aggiornati

Ad esempio se in distfiles sono presenti sia libtool-1.3.5.tar.gz e libtool-1.5.2.tar.gz, cancellerà libtool-1.3.5.tar.gz

Non funziona con i file come font-arial-iso-8859-1 e font-arial-iso-8859-2, doce la numerazione non coincide con la versione del pacchetto (come ad esempio per gtk e glib nelle versioni 1.x e 2.x).

Altre informazioni qui.

5- Porthole

Questo è un front-end per portage scritto in python (+gtk); offre quindi uno strumento visuale per la configurazione di portage, rendendo più facile la predisposizione dei pacchetti e la loro emersione. E' già nell'albero di portage, per cui basta un "emerge porthole".

6- kuroo

Un'altro front-end di portage, ma scritto in Qt (per la gioia degli utenti kde). E' un progetto recente, ma funziona abbastanza bene.

Altre informazioni qui.

7- portage cdb

Questo non è propriamente uno script, ma un ottimo metodo per migliorare la velocità di portage.

Altri utili script e programmi relativi a portage possono essere trovati in questo thread.

18. Link interessanti

1- Come montare / nella ram

Articolo molto interessante, assolutamente da leggere!

----------

## fedeliallalinea

Aggiunto ai post utilissimi sezione howto. Non vuoi anche scriverlo sul wiki?

----------

## lavish

Ragazzo mio, complimenti! I non-anglofoni ti faranno un monumento  :Wink: 

----------

## mouser

 *lavish wrote:*   

> Ragazzo mio, complimenti! I non-anglofoni ti faranno un monumento 

 

Quoto in pieno!!!

Ottimo howto!

Ciriciao

mouser  :Wink: 

----------

## gutter

Davvero un buon lavoro, se ti va mettilo nel wiki  :Wink: 

----------

## ProT-0-TypE

aiutatelo a finirlo  :Very Happy: 

----------

## rust5

 *ErniBrown wrote:*   

> 
> 
> /etc/init.d/localmount 
> 
> cambiate:
> ...

 

io mi ritrovo invece

```

# Mount local filesystems in /etc/fstab.

        ebegin "Mounting local filesystems"

        mount -at noproc,noshm,no${NET_FS_LIST// /,no} >/dev/null

        eend $? "Some local filesystem failed to mount"

```

faccio lo stesso la modifica?

----------

## ErniBrown

 *rust5 wrote:*   

> faccio lo stesso la modifica?

 

Controlla prima a cosa fa riferimento ${NET_FS_LIST// /,no}, comunque direi di si'! dovrebbe essere sufficiente un

```
echo ${NET_FS_LIST// /,no}
```

----------

## luna80

complimenti per il lavoro e grazie per averlo messo a disposizione di tutti!!  :Very Happy: 

----------

## AlterX

Ottimo, ottimo  :Laughing: 

Attivo subito delle interessanti opzioni dell'how-to!!  :Cool: 

Per il prelink...non saprei; quanto ci mette a prelinkare un sistema medio, dopo che eseguo un che emerge -u????

----------

## PboY

complimeti.

bell'howto.

----------

## BikE

 *AlterX wrote:*   

> 
> 
> Per il prelink...non saprei; quanto ci mette a prelinkare un sistema medio, dopo che eseguo un che emerge -u????

 

A me ci mette circa un minuto...

----------

## rust5

 *ErniBrown wrote:*   

> 
> 
> Controlla prima a cosa fa riferimento ${NET_FS_LIST// /,no}, comunque direi di si'! dovrebbe essere sufficiente un
> 
> ```
> ...

 

ok funziona, grazie mille

----------

## AlterX

 *BikE wrote:*   

>  *AlterX wrote:*   
> 
> Per il prelink...non saprei; quanto ci mette a prelinkare un sistema medio, dopo che eseguo un che emerge -u???? 
> 
> A me ci mette circa un minuto...

 

Perfetto!!  :Surprised: 

----------

## bandreabis

Bell'how to, provato oggi... e mi ha sminchiato tutto.. un sacco di errori in fase di boot (errori che non so come riportare)!!

Forse da marzo le cose sono cambiate e questo howto non è più attuale, o il mio PC ha qualche problema.

Cmq rimettendo tutto come prima, ora tutto è tornato OK.

Andrea

----------

## BikE

 *bandreabis wrote:*   

> Bell'how to, provato oggi... e mi ha sminchiato tutto.. un sacco di errori in fase di boot (errori che non so come riportare)!!
> 
> Forse da marzo le cose sono cambiate e questo howto non è più attuale, o il mio PC ha qualche problema.
> 
> Cmq rimettendo tutto come prima, ora tutto è tornato OK.
> ...

 

Prova a rifare un passaggio alla volta e cerca di risovere gli errori  :Smile:  non dovrebbe essere cambiato niente secondo me... io sto usando tutte le modifiche senza problemi..

----------

## gutter

 *bandreabis wrote:*   

> Bell'how to, provato oggi... e mi ha sminchiato tutto.. un sacco di errori in fase di boot (errori che non so come riportare)!!
> 
> Forse da marzo le cose sono cambiate e questo howto non è più attuale, o il mio PC ha qualche problema.
> 
> 

 

La maggior parte delle cose penso siano ancora attuali. Che problemi hai avuto di preciso?

----------

## bandreabis

Mi spiace molto, ma considerando che non mi va di ripetere l'esperienza e che il mio sistema è velocissimo già così (ho seguito solo il punto 2), non credo che per il momento potrò riportare gli errori (coldplug quello che mi ricordo).

So che dovrei essere molto più altruista. Magari più avanti.

Sia chiaro che non voglio sminuire l'howto o dire che sia errato, dico solo che da me ho/ha fatto un po' di casotto. Ma che ho potuto senza problemi tornare indietro alla situazione di default.

Grazie e scusate ancora.

Andrea

----------

## codadilupo

penso che il problema che hai avuto sia legato al parallel startup degli init script (che non é ancora troppo preciso, in alcune situazioni).

Puoi provare, se vuoi, a cambiare solo quello. Se ti da errore, hai individuato cosa non toccare mai sul tuo sistema  :Wink: 

Coda

----------

## bandreabis

La modifica in rc giusto?

Quella è ancora impostata e va tutto abbastanza bene (a parte cercare di far ripartire coldplug già avviato), gli altri problemi erano dovuti alle modifiche degli script.

Andrea

----------

## Luca89

Io uso queste modifiche agli init-script su tutte le mie macchine, secondo me hai fatto tu qualcosa di sbagliato.

----------

## bandreabis

Probabile, anche se credo di aver fatto le modifiche in modo esatto... non ho la certezza, per questo quando avrò tempo ci riproverò... e vi saprò dire.

----------

## Sparker

Usare cdb come gestore della cache di portage: 

https://forums.gentoo.org/viewtopic-t-261580-highlight-portage+cdb+speed.html

Velocizza di molto l'aggiornamento dei metadati eseguito alla fine di emerge sync

----------

## kattivo

L'ho letto un po in ritardo questo how to...

devo fare dei grossi complimenti... :Razz: 

Bravo bravo ! Credo sia uno dei migliori che abbia letto   :Smile: 

----------

## cloc3

 *ErniBrown wrote:*   

> 
> 
> 6. E' necessario... prelinkare?
> 
> ...
> ...

 

Era un anno che non mi occupavo più del prelink, perché, vista la mia predisposizione maniacale per l'aggiornamento sistematico, era diventata un'operazione noiosa. Oggi, ho cercato nuovamente questo post per una macchina che non intendo toccare a lungo e ho scoperto delle cose nuove, indicate proprio nell'howto linkato sopra.

Due cose mi sembra così importanti che prov ad evidenziare. Personalmente, le integrerei nel post, pur violando parzialmente il testo integrale della traduzione.

1. Il prelink è diventato una funzione integrata di portage. Se è stato emerso il pacchetto prelink, tutti gli eseguibili vengono prelincati automaticamente all'atto della compilazione.

2. Per far funzionare il prelink con kde, bisogna inserire il comando KDE_IS_PRELINKED="true" in /etc/env.d/99kde-env

----------

## Ic3M4n

@cloc3: ti spiacerebbe dirci come hai fatto ha reperire tale informazione sul prelink? 

questa discussione era incentrata sullo stesso argomento ma la conclusione era completamente opposta.

----------

## cloc3

 *Ic3M4n wrote:*   

> @cloc3: ti spiacerebbe dirci come hai fatto ha reperire tale informazione sul prelink? 
> 
> 

 

Quello che ti domandi sarebbe emerso chiaramente se io non avessi bimenticato di scrivere la parola "linkato" davanti alla parola "sopra".

Anzi. te la cito direttamente nella versione italiana:

 *Gentoo Linux Prelink Guide wrote:*   

> 
> 
> Le versione corrente di Portage tratta correttamente, attraverso prelink, i cambiamenti di MD5sum e mtime degli eseguibili. 
> 
> Non è necessario impostare FEATURES="prelink" in make.conf: Portage si appoggerà automaticamente a prelink se troverà il file binario 'prelinkato'.
> ...

 

----------

## Ic3M4n

si, esatto. tu leggi le due paginette che ti ho passato, trattano dello stesso argomento. solo che viene spiegato cosa effettivamente fà portage.

----------

## randomaze

 *cloc3 wrote:*   

> Due cose mi sembra così importanti che prov ad evidenziare. Personalmente, le integrerei nel post, pur violando parzialmente il testo integrale della traduzione.

 

Si potrebbe inizare a modificare questa pagina nel wiki e, in cima al post, un moderatore specificherà che esiste una versione estesa dell'HOWTO nel wiki di gentoo-italia  :Wink: 

Un'ulteriore aggiunta al wiki potrebbe essere l'uso di cdb con portage.

----------

## Ic3M4n

l'unica cosa è che l'estratto del thread che ho linkato è che portage effettivamente riconosce un eseguibile prelinkato nel momento in cui si va a fare un controllo sulle modifiche effettuate al pacchetto. quindi esegue un controllo sull'md5 del pacchetto per vedere se è stato "manomesso". 

se portage non avesse questa feature risulterebbe che tutti gli eseguibili prelinkati siano stati in un qualche modo manomessi. questo è il supporto di portage al prelink. 

il resto, ovvero che portage prelinka i pacchetti emersi automaticamente è falso, in quanto per far ciò bisognerebbe andare a prelinkare un'eseguibile che non è necessariamente nel pacchetto compilato in quel dato istante. faccio il solito esempio:

se compilo firefox:

viene compilato e prelinkato alle librerie condivise.

se compilo glibc:

a che cosa lo prelinko? sono gli altri programmi che si devono prelinkare parte delle glibc, quindi su un aggiornamento delle glibc non avrei effettivamente la possibilità di prelinkare nulla, o forse qualche dipendenza delle glibc, ma sta di fatto che bisogna rieseguire il prelink su tutti gli eseguibili che "dipendono" dalle glibc. quindi praticamente tutto il sw installato. e questo non lo potrà mai fare portage, ma deve essere fatto a manina.

----------

## cloc3

 *Ic3M4n wrote:*   

> si, esatto. tu leggi le due paginette che ti ho passato, trattano dello stesso argomento. solo che viene spiegato cosa effettivamente fà portage.

 

Bah. Adesso ho il tempo di leggere.

Mi cala molto l'entusiasmo   :Sad:   :Crying or Very sad:   :Sad:  .

----------

## VegetaSSJ5

 *ErniBrown wrote:*   

> Per coloro che avviano X direttamente (xdm, gdm,kdm, ...) ho letto che è possibile aggiungere xdm e le sue dipendenze direttamente nel runlevel di boot, in modo tale che X venga caricato all'avvio, mentre il resto del sistema viene caricato in background.

 

si può approfondire un po' meglio questa questione? qualcuno l'ha già fatto? se si come va? ci sono problemi di compatibilità?

----------

## cloc3

 *VegetaSSJ5 wrote:*   

>  *ErniBrown wrote:*    ho letto che è possibile aggiungere xdm e le sue dipendenze direttamente nel runlevel di boot, in modo tale che X venga caricato all'avvio 
> 
> si può approfondire un po' meglio questa questione? qualcuno l'ha già fatto? se si come va? ci sono problemi di compatibilità?

 

Immagino che il riferimento sia a questo comando:

```

# rc-update del xdm &&rc-update add xdm boot

```

Si tratta di provarlo e vedere se ci si guadagna qualcosa. Male non dovrebbe fare.

Io, personalmente, non lo uso.

 Edit:  :Embarassed:   :Embarassed: 

----------

## VegetaSSJ5

 *cloc3 wrote:*   

> Immagino che il riferimento sia a questo comando:
> 
> ```
> 
> # rc-update del xdm &&rc-update add xdm default
> ...

 

casomai

```
# rc-update del xdm && rc-update add xdm boot
```

----------

