# [bashrcng] quale alternativa? [risolto]

## cloc3

mai etichettare nulla con l'attributo nuova generazione, che al primo cambio di vento lo riscopri deprecati e stantio.

purtroppo anche  bashrcng sembra avere fatto il proprio tempo.

!equilibrium ha lasciato gentoo e il suo tool non sembra più capace di adatttarsi alle novità del portage in alpha.

per chi non lo conosce, bashrcng era uno script di shell per /etc/portage che permetteva (tra le altre cose) di compilare i pacchetti in ram, guadagnando molto tempo e salvaguardando l'intregrità dei dischi rigidi.

vorrei sapere se adesso esiste qualche software alternativo o qualche opzione di emerge che permetta di ottenere lo stesso comportamento.

----------

## pingoo

Non conosco bashrcng, non basta più dare un

```

mount -t tmpfs tmpfs -o size=$dim /var/tmp/portage

```

per la compilazione in ram (almeno in parte)? Che sia cambiata la cartella di "appoggio" e non sia più /var/tmp/portage?

----------

## cloc3

 *pingoo wrote:*   

> Non conosco bashrcng, non basta più dare un
> 
> ```
> 
> mount -t tmpfs tmpfs -o size=$dim /var/tmp/portage
> ...

 

bashrcng era più comodo perché, eseguendo il mount e il corrispondente unmount per ogni singolo ebuild, gestiva in un modo più efficente la ram, riducendo il pericolo di fallimenti per spazio esaurito nel dispositivo di memoria virtuale.

compilando centinaia di ebuild, il vantaggio era evidente.

----------

## xdarma

 *cloc3 wrote:*   

> vorrei sapere se adesso esiste qualche software alternativo o qualche opzione di emerge che permetta di ottenere lo stesso comportamento.

 

Non ho mai usato bashrcng ma uso questi:

- abilito "ccache" tra le features di portage;

- ho aggiunto a make.conf: PORTAGE_TMPFS="/dev/shm" e ho in fstab

```

shm   /dev/shm   tmpfs   nodev,nosuid,noexec

```

Non garantisco che funzionino e nemmeno che sostituiscano bashrcng  ;-)

----------

## cloc3

 *xdarma wrote:*   

> 
> 
> - abilito "ccache" tra le features di portage;
> 
> - ho aggiunto a make.conf: PORTAGE_TMPFS="/dev/shm" e ho in fstab
> ...

 

la prima opzione esegue una funzione diversa, alla quale ad un certo punto ho rinunciato.

la seconda, invece, non sembra documentata in man make.conf.

che versione di portage usi?

ps: forse intendevi PORTAGE_TMPDIR.

non è come bashrcng, ma  a questo punto mi ci sto rassegnando.

strano però che a te funzioni, con l'opzione noexec nella riga di fstab.

----------

## !equilibrium

 *Quote:*   

> !equilibrium ha lasciato gentoo e il suo tool non sembra più capace di adatttarsi alle novità del portage in alpha.

 

non ho mai abbandonato Gentoo ed è inutile usare bashrcng perché portage 2.1 e 2.2 contengono già tutte le sue feature, quindi è ridondante.

----------

## xdarma

 *cloc3 wrote:*   

> la prima opzione esegue una funzione diversa, alla quale ad un certo punto ho rinunciato.

 

Sì, hai ragione: ccache non serve a compilare in ram. La uso perché spero diminuisca lo "stress" del disco.

 *cloc3 wrote:*   

> la seconda, invece, non sembra documentata in man make.conf.

 

Giusto anche questo. È un'impostazione "fossile" in make.conf di chissà quale versione di portage  :-D

Ti incollo la descrizione:

```

# PORTAGE_TMPFS is a location where portage may create temporary files.

#     If specified, portage will use this directory whenever possible

#     for all rapid operations such as lockfiles and transient data.

#     It is _highly_ recommended that this be a tmpfs or ramdisk. Do not

#     set this to anything that does not give a significant performance

#     enhancement and proper FS compliance for locks and read/write.

#     /dev/shm is a glibc mandated tmpfs, and should be a reasonable

#     setting for all linux kernel+glibc based systems.

PORTAGE_TMPFS="/dev/shm"

```

Versione di portage: 2.1.10.3

PORTAGE_TMPDIR è commentata.

Quanta ram hai? Probabilmente ci sono altri "trucchi" possibili proprio con PORTAGE_TMPDIR.

----------

## fbcyborg

 *pingoo wrote:*   

> Non conosco bashrcng, non basta più dare un
> 
> ```
> 
> mount -t tmpfs tmpfs -o size=$dim /var/tmp/portage
> ...

 

Io uso questo sistema da anni ormai, o comunque da quando quello script non funzionava già più bene come prima.

Ricordo che a volte non smontava/montava fra l'emerge di un pacchetto e l'altro.

Uso portage 2.2.0_alpha78.

----------

## Deus Ex

 *pingoo wrote:*   

> Non conosco bashrcng, non basta più dare un
> 
> ```
> 
> mount -t tmpfs tmpfs -o size=$dim /var/tmp/portage
> ...

 

Ma così facendo, non è necessario poi smontare (o meglio, ricordarsi di smontare) manualmente il dev tmpfs montato in ram? Non si rischia di saturare la ram se, oltre a compilare, si fanno girare altre applicazioni?

----------

## fbcyborg

Io ormai sono abituato e non mi dimentico mai.

Sì, si rischia di saturare la RAM e bloccare il PC. Ad esempio a me è capitato quando ho compilato chromium. Ho solo 4 GB.

In questo caso, se sai che devi compilare pacchetti che possono dare problemi (e a me ne sono capitati veramente pochi - ora solo con chromium ho questo problema), eviti di compilare in RAM.

----------

## pingoo

Piccolo OT

 *xdarma wrote:*   

> 
> 
> Sì, hai ragione: ccache non serve a compilare in ram. La uso perché spero diminuisca lo "stress" del disco.
> 
> 

 

Mi pare di ricordare che non fosse poi così scontata la diminuzione di stress, ovvero che portasse benefici solo nel caso di ricompilazione di uno stesso identico pacchetto mentre negli altri casi si ha un rallentamento dovuto ai controlli aggiuntivi necessari oltre a possibili errori in compilazione. Dovrebbe esserci una serie di post argomentati sul blog di flameeyes, l'ultimo potrebbe essere questo

----------

## cloc3

 *!equilibrium wrote:*   

> 
> 
> non ho mai abbandonato Gentoo ...

 

rieccolo al bar  :Smile: .

quindi, per compilare in ram, usiamo PORTAGE_TMPDIR per la versione alpha o PORTAGE_TMPFS per le versioni differenti?

i meccanismi di pulizia alla fine di ogni singolo ebuild sono affidabili?

----------

## fbcyborg

Io ad esempio PORTAGE_TMPDIR non l'ho settata, o meglio è rimasta quella di default /var/tmp, e quando monto in ram faccio:

```
mount -t tmpfs tmpfs -o size=4000M,mode=770 /var/tmp/portage
```

----------

## djinnZ

per me ccache è sempre stata una inesauribile sorgente di rogne e non vedo tutti questi benefici. Quando il codice è nuovo rallenta, e non di poco, la cpmpilazione, quando è in cache velocizza.

Di fatto se lavori da cvs è una buona cosa ma per l'uso normale (e sei facile a fare cretinate nelle opzioni del gcc o tenti a cambiarle strada facendo sono propriamente dolori di pancia) non vedo quanto possa essere utile.

Su flashdisk è un ottimo modo per raddoppiare lo stress e su HD "normale", se c'è una fisica  distanza apprezzabile tra /var/tmp e /var/cache, può farti perdere più tempo con i seek continui che a compilare direttamente.

Tornando a tmpfs ho una serie di mount alternativi 

```
# per compilare openoffice

buildo  /tmp/build  tmpfs   noauto,size=7G,nr_inodes=7M,mode=0775  0 0

# compilazione contemporanea sui due chroot

buildm  /tmp/build  tmpfs   noauto,size=4G,nr_inodes=4M,mode=0775  0 0

# normale

buildn  /tmp/build  tmpfs   size=2G,nr_inodes=1M,mode=0775         0 0
```

e questo invece non è gestito o non vedo come farlo in automatico (si accettano suggerimenti ... come sempre) e faccio prima a lanciare 

```
unmount buildn ; mount buildo
```

 se devo compilare libreoffice (o meglio dovevo perchè è dimagrito tantissimo).

@cloc3:I meccanismi di pulizia sono sempre gli stessi anche e soprattutto non ripulisce un tubo quando vai di --resume --skipfirst (o --keep-going per quel che so). ma come vedi dall'fstab non mi sono mai applicato più di tanto.

il mio solito ¼ ... di centesimo ... di lira ... tanto val spenderlo prima che me lo rapinino ... anche con gli ingrati che non ti apprezzano ... la solfa delle due mele e delle due idee, che non guasta mai ... asinus asium fricat ... a lavar la testa... etc.  :Mr. Green: 

 *!equilibrium wrote:*   

> non ho mai abbandonato Gentoo

   :Confused:  allora posso chiedere qualcosa ... senza rischio che nessuno mi risponda...  :Crying or Very sad:   :Twisted Evil: 

----------

## cloc3

 *djinnZ wrote:*   

>  e soprattutto non ripulisce un tubo quando vai di --resume --skipfirst (o --keep-going per quel che so). 

 

Ahi.

allora è grave non avere bashrcng.

bashrcng eseguiva un mount separato per ogni singolo ebuild.

compilato l'ebuild, eseguiva l'unmount che risultava, in pratica, equivalente alla pulizia della cartella.

comunque, oramai ho disabilitato bashrcng e sono passato a PORTAGE_TMPDIR.

nei prossimi giorni staremo a vedere.

----------

## djinnZ

Fai sapere, sono interessato anche se non mi applico perché in genere lancio due emerge -aDNuv @world contemporaneamente o di seguito (quindi un unico tmpfs è più gestibile per me)

----------

## cloc3

 *djinnZ wrote:*   

> Fai sapere, sono interessato anche se non mi applico perché in genere lancio due emerge -aDNuv @world contemporaneamente o di seguito (quindi un unico tmpfs è più gestibile per me)

 

```
s939 ~ # genlop -c

 Currently merging 62 out of 231

...

s939 ~ # ls /dev/shm/portage/ -lA|wc -l

4

```

effettivamente, ora portage si comporta piuttosto bene.

la pulizia è efficente. semmai, bisognerà fare attenzione ad eventuali ebuild falliti, perché in quel caso la pulizia dovrà essere fatta a manina. ma questo è anche abbastanza inevitabile.

----------

## xdarma

 *pingoo wrote:*   

> Piccolo OT
> 
> Mi pare di ricordare che non fosse poi così scontata la diminuzione di stress, ovvero che portasse benefici solo nel caso di ricompilazione di uno stesso identico pacchetto mentre negli altri casi si ha un rallentamento dovuto ai controlli aggiuntivi necessari oltre a possibili errori in compilazione. Dovrebbe esserci una serie di post argomentati sul blog di flameeyes, l'ultimo potrebbe essere questo

 

Se lo dice lui ci credo  ;-)

Leggendo i commenti al post alcuni facevano notare che il suo test fosse particolarmente svantaggioso per ccache. Anche gli errori in compilazione forse non sono così numerosi.

Nel mio caso mi capita di ricompilare più di qualche pacchetto, spesso sono legati a kde (quindi tendenzialmente c++) e, peggio di tutto, lo spannometro mi dice che senza ccache compilare qualcosa relativo a kde è mortale. E compilare kde&friends occupa gran parte del tempo totale.

Penso che almeno i primi due aspetti siano simili anche per cloc3 e quindi penso che ccache possa essergli utile.

Ovviamente posso anche cambiare idea, soprattutto se riesco a mettere a confronto le compilazioni. Come faccio a "misurare" il rallentamento dato da ccache?

Ciao e grazie.

----------

## djinnZ

Oggi come oggi il mondo è in una deriva medioevale e pertanto si tende alla superstizione ed all'oscurantismo.

Una persona razionale valuta i pro ed i contro su base oggettiva e decide ma è sempre pronta a cambiare idea.

Gli imbecilli, colmi delle loro incrollabili certezze, pensano che un singolo comando od una impostazione magicamente risolva tutto e debba essere la soluzione. Lo si può chiamare atteggiamento sacerdotale, superstizioso, medioevale, oscurantista o più banalmente imbecille.

Polemica già affrontata più volte in passato a proposito del "RAID! ammazza tutti" (sono il primo ad usarlo ma non per questo lo ritengo una necessità inderogabile ed un sostituto dello storage[/quote]) e quant'altro.

Non esiste "La Soluzione", solo opzioni più vantaggiose, caso per caso.

Ma d'altro canto se la madre degli imbecilli non fosse sempre incita il mondo sarebbe un paradiso.

Flameyes ha giustamente evidenziato come ccache non è questa gran cosa che si credeva. Quindi è utile solo in determinate condizioni che vanno valutate prima di fare una scelta (razionale).

Se vai a compilare kde tutti i giorni (quindi non fai salti di versione), non c'è una distanza fisica enorme sull'hd tra i dati, non usi opzioni di ottimizzazione od hardening che fanno variare il codice, non sei su flashdisk e non è la prima volta che lo usi (etc.) velocizza; negli altri casi rallenta o non migliora apprezzabilmente i tempi rimanendo una costante fonte di rogne.

Premesso che alcuni pacchetti, in primis libc e gcc, non andrebbero mai compilati con ccache.

Le risposte sul blog, molte delle affermazioni in thread come questo, sono manifestazioni di questa tendenza. Sommate ad alcune affermazioni frettolose delle guide ed alle risposte spicce che spesso si usano conducono alla creazione di autentiche leggende urbane. Quando qualcuno prova a metterle in discussione si scatenano i sacerdoti.

Questo per chiarire in generale e senza riferimento alcuno a chi partecipa a questa discussione quanto siano inutili e fuorvianti certe polemiche. Chi è meno addentro a certi meccanismi potrebbe ricevere un messaggio dogmatico ad usare o non usare ccache indipendentemente dalle sue necessità.

@xdarma: come opinione personale resto dell'idea, in accordo a flameyes, in casi come il tuo, di farne a meno per alcuni pacchetti lavorando in /etc/portage od abilitarla solo per kde & C via linea di comando.

Una cosa che i test di flameyes non hanno evidenziato è che ccache tende ad essere meno efficiente quando la si usa per tutto e nella guida (che se non ricordo male una volta consigliava direttamente di usarla e basta) i meno smaliziati tendono a leggere una indicazione all'uso od alla disabilitazione a carattere esclusivo.

Per esempio se lavori con pacchetti -9999 è quasi un obbligo nella mia visione usarla.

Per portage_tmpdir continuo a rimanere con i mount alternativi, la uso solo per non giocare con remount e link simbolici.

Ma non tutti mantengono più di un chroot per compilare.

Ed ovviamente preferire non andare ad usare /dev/shm

----------

