[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.
_________________
vu vu vu
gentù
mi piaci tu

[pingoo]

Non conosco bashrcng, non basta più dare un

[cloc3]

[xdarma]

[cloc3]

[!equilibrium]

[xdarma]

[fbcyborg]

[Deus Ex]

[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.
_________________
[HOWTO] Come criptare la /home usando cryptsetup e luks
[HOWTO] Abilitare il supporto al dom0 XEN su kernel 3.X
Help answer the unanswered

[pingoo]

Piccolo OT

[cloc3]

[fbcyborg]

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

[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

[cloc3]

[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)
_________________
scita et risus abundant in ore stultorum sed etiam semper severi insani sunt
mala tempora currunt...mater stultorum semper pregna est
Murpy'sLaw:If anything can go wrong, it will - O'Toole's Corollary:Murphy was an optimist

[cloc3]

[xdarma]

[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
_________________
scita et risus abundant in ore stultorum sed etiam semper severi insani sunt
mala tempora currunt...mater stultorum semper pregna est
Murpy'sLaw:If anything can go wrong, it will - O'Toole's Corollary:Murphy was an optimist