Gentoo: applicazioni, dubbi, filosofia

[antonellocaroli]

E per ultimo se avresti letto un po la guida non si parla solo di USE Flags...ma di un make.conf dove ci sono le istruzioni di compilazioni

https://wiki.gentoo.org/wiki//etc/portage/make.conf

https://wiki.gentoo.org/wiki/CPU_FLAGS_X86

https://dev.gentoo.org/~zmedico/port...ke.conf.5.html

Che ti puoi ritagliare come meglio credi sulla propia macchina...e tutto il sistema/programmi vengono compilati in quel modo (a parte Hqplayer e Netwokaudiod-binari, ma le librerie che vanno ad usare si)...compreso il kernel.

[antonellocaroli]

Rimosso, doppio.

[marcoc1712]

Cari signori,

il tempo vale per tutti e nessuno qui vende nulla, ho mai venduto qualcosa io?

Non è nelle mie corde offendere, mentre è un bel po che passo sopra a quelle che invece ricevo gratuitamente, per essere poi messo sul banco degli imputati?

continuate pure ad alimetare il mito, senza (voler) capire quali sono le pleonastiche verità sottostanti, di mio cercherò sempre di far vedere che il re è nudo, totalmente indifferente alle sue lamentele e minacce...

Iniziamo da qui, dato che mi ci avete puntato:

USE="mmx mmxext sse sse2 sse3"

CPU_FLAGS_X86="mmx mmxext sse sse2 sse3"

cosa credete che facciano di per se nell'ebuild?

Attenzione ai miti...

[bigtube]

Cari signori,

il tempo vale per tutti e nessuno qui vende nulla, ho mai venduto qualcosa io?

Non è nelle mie corde offendere, mentre è un bel po che passo sopra a quelle che invece ricevo gratuitamente, per essere poi messo sul banco degli imputati?

continuate pure ad alimetare il mito, senza (voler) capire quali sono le pleonastiche verità sottostanti, di mio cercherò sempre di far vedere che il re è nudo, totalmente indifferente alle sue lamentele e minacce...

Iniziamo da qui, dato che mi ci avete puntato:

USE="mmx mmxext sse sse2 sse3"

CPU_FLAGS_X86="mmx mmxext sse sse2 sse3"

cosa credete che facciano di per se nell'ebuild?

Attenzione ai miti...

Ma di quali miti stai parlando....abbiamo mitizzato Gentoo...ma dove lo hai percepito che vogliamo mitizzare questo sistema.
Io stesso ho detto a piu' riprese che Daphile e Wtfplay che sono derivate da Gentoo in realta' hanno appiccicato un peccato
originale e cioe' di andare a funzionare in modo generico su macchine generiche. E dello stesso peccato originale sono "affette"
tutte le distro che conosciamo che infatti sono precompilate e generiche.
Scegliere di sperimentare Gentoo mirava a verificare che un sistema tutto orientato alla compilazione dai sources compreso il kernel
adattato per bene alla macchina in cui deve lavorare mantenesse le promesse di funzionamento ottimizzato, leggero e performante.
Dove sta il mito?
C'è stata una esperienza che non è nemmeno facile da attraversare che ha dato buoni frutti. A noi interessano i buoni frutti...non Gentoo
Gentoo è uno strumento....un tramite...come lo sono le buone Applicazioni.
Squeezelite-R2 non è un mito per me .....è un medium ottimo per il mio obbiettivo...ascoltare come si deve la mia musica preferita.

La costruzione di miti la fa' chi vuole vendere qualcosa e colpire la psicologia altrui....che cosa dobbiamo vendere noi?
Il nostro tempo perso a fare delle prove....per condividerle liberamente.....nel senso liberale e gratuito del termine. PURO SPIRITO DI CONDIVISIONE.
Non stiamo facendo nessun panegirico.
Da cosa vuoi mettere in guardia ?
Siamo tutti adulti e maledettamente scettici....ognuno sapra' scegliere per se'
Ma chi ci segue?......non vedo nessuna folla che si butta a pesce verso questo nostro suggerimento.
Preferiscono cose piu' facili e menon impegnative. NON SONO SCEMI come noi....viva la liberta' di scelta.

[marcoc1712]

Ma di quali miti stai parlando.....
un sistema tutto orientato alla compilazione dai sources compreso il kernel
adattato per bene alla macchina in cui deve lavorare
Dove sta il mito?

Il mito è esattamente quello che hai riproposto (evidenziato in rosso più sopra):

1. Non è vero che la compilazione avviene in modo ottimizzato SE non si selezionano accuratamnete le opzioni (i CFLAGS) di compilazione, le sole USE NON hanno effetto su questo e le opzioni 'stadard' riconoscono SOLO la famiglia del processore, in pratica lo stesso livello di 'ottimizzazione' a livello del seplice -O2, presente n qualsiasi sistema gnu linux.

2. A livello applicativo, in diversi casi vengono installati ed utilizzate versione binarie compilate in modo generico per sistemi generici e, comunque, anche ricompilando dipende tutto dai CFLAGS utilizzati, normalmente altrettanto generici.

3. Leggendo in giro, è spesso sconsigliato ricercare una ottimizzazione di livello superiore rispetto a quella 'di default', al massimo si può provare a specificare l' 'instruction chipset', ma con attenzione.

4. Sempre leggendo in giro, pare vero che portage, ANCHE mediante le USE (ma non solo), permetta di orchestrare al meglio il sistema, i risultati che riportate lo confermano, ma - ribadisco - è sbagliato asserire che questo è merito del fatto che le applicazioni (come tutto il resto) viene compilato in funzione del sistema target, grazie alle USE FLAGS.

Sono strumenti distinti con scopi distinti.

Concludendo,

Come avete compilato il Kernel o le altre componenti di sistema non lo so, ma HQP/NAD sono precompilati, quindi non si pone e l'ebuild in mio possesso per 'linnominabile' usa "-O2 -fPIC -Wall" nei CFLAGS, esattamente come il makefile in ogni altro sistema gnu linux. Mpd non lo so, ma basta verificare.

Tutto ciò mi porta a credere che il vantaggio non sia nella compilazione in se (...lo diceva anche il tipo del terzo intervento...) e certo NON in quella delle applicazioni, ma proprio nell'orchestrazione del sistema, vale a dire in una ottimizzazione e cura delle attività sistemistiche di installazione del sistema, A PRESCINDERE dalle applicazioni successivamente installate.

Accetto volentieri un a smentita, ma possibilmente non sbraitata, basata su fatti concreti ed attinenti e non su confusione di termini e concetti.

Nel merito, ho già scritto che mi fido tanto delle vostre opinioni 'acustiche' che ho già un monitor hdmi ed un mSata nuovo in arrivo da dedicare a Gentoo, ma - come sempre - mi pongo l'obiettivo di capire il perchè di quello che faccio, altrimenti non mi diverto.

[bigtube]

Il mito è esattamente quello che hai riproposto (evidenziato in rosso più sopra):

1. Non è vero che la compilazione avviene in modo ottimizzato SE non si selezionano accuratamnete le opzioni (i CFLAGS) di compilazione, le sole USE NON hanno effetto su questo e le opzioni 'stadard' riconoscono SOLO la famiglia del processore, in pratica lo stesso livello di 'ottimizzazione' a livello del seplice -O2, presente n qualsiasi sistema gnu linux.

le CFLAGS del mio make.conf :
CFLAGS="-march=core2 -O2 -pipe" ....la mia CPU è un core2
vedi qua'
https://wiki.gentoo.org/wiki/Safe_CFLAGS
POI dove rintracci l'affermazione "che le sole USE sono rilevanti" per le istruzioni al compilatore usato da Portage. Le USE fanno parte delle istruzioni.

2. A livello applicativo, in diversi casi vengono installati ed utilizzate versione binarie compilate in modo generico per sistemi generici e, comunque, anche ricompilando dipende tutto dai CFLAGS utilizzati, normalmente altrettanto generici.

Vedi sopra....nel mio make.conf oltre -O2 -pipe
Quando ho installato un binario l'ho fatto solo per Firefox.....mi era piu comodo e lui non suona.
Per HQP non esiste l'opzione ....o cosi o niente .

3. Leggendo in giro, è spesso sconsigliato ricercare una ottimizzazione di livello superiore rispetto a quella 'di default', al massimo si può provare a specificare l' 'instruction chipset', ma con attenzione.

Ne sono informato e consapevole

4. Sempre leggendo in giro, pare vero che portage, ANCHE mediante le USE (ma non solo), permetta di orchestrare al meglio il sistema, i risultati che riportate lo confermano, ma - ribadisco - è sbagliato asserire che questo è merito del fatto che le applicazioni (come tutto il resto) viene compilato in funzione del sistema target, grazie alle USE FLAGS.

Ma chi l'ha mai detto . Come ampiamente descritto le USE ( che sono una parte delle istruzioni di compilazione) si occupano delle dipendenze degli applicativi.
Quindi di cio che al sottoscritto piace che venga utilizzato delle dipendenze ....non di tutto e di piu come in una compilazione generica.
L'applicativo verra' compilato con le sue istruzioni specifiche che Portage esegue e basta.

Sono strumenti distinti con scopi distinti.

Mi era ampiamente chiaro

Concludendo,

Come avete compilato il Kernel o le altre componenti di sistema non lo so, ma HQP/NAD sono precompilati, quindi non si pone e l'ebuild in mio possesso per 'linnominabile' usa "-O2 -fPIC -Wall" nei CFLAGS, esattamente come il makefile in ogni altro sistema gnu linux. Mpd non lo so, ma basta verificare.

Essendo HQP un binario che deve essere compilato con una specifica versione di gcc l'unica cosa da compilare per Portage è proprio questo compilatore.
Come compilare il kernel l'abbiamo detto tenendo conto di variabili legate alla macchina . Le altre componenti del sistema sono proprie di Gentoo e sono state descritte

Tutto ciò mi porta a credere che il vantaggio non sia nella compilazione in se (...lo diceva anche il tipo del terzo intervento...) e certo NON in quella delle applicazioni, ma proprio nell'orchestrazione del sistema, vale a dire in una ottimizzazione e cura delle attività sistemistiche di installazione del sistema, A PRESCINDERE dalle applicazioni successivamente installate.

A me è chiaro qual'è il vantaggio con una precisa scala di valori....le magie non esistono con i sistemi informatici .....esiste che quelli fatti bene funzionano bene

Accetto volentieri un a smentita, ma possibilmente non sbraitata, basata su fatti concreti ed attinenti e non su confusione di termini e concetti.

Ma non dimenticarti mai che non puoi esigere che ti diamo risposte da professionisti della materia .....perchè altrimenti ti devi cercare altri.
E sopratutto finiscila di fare di tutto per dimostrare che siamo dilettanti allo sbaraglio.....è fin troppo chiaro a chiunque che siamo solo dei dilettanti.
Vuoi sottolinearlo....l'hai gia' fatto.
Ma non l'hai fatto nel modo giusto....ti sei mosso dal pregiudizio anzi avevi un giudizio preconfezionato

Nel merito, ho già scritto che mi fido tanto delle vostre opinioni 'acustiche' che ho già un monitor hdmi ed un mSata nuovo in arrivo da dedicare a Gentoo, ma - come sempre - mi pongo l'obiettivo di capire il perchè di quello che faccio, altrimenti non mi diverto.

E adesso scontrati tu con le difficolta' che incontrerai....noi da perfetti imbecilli le abbiamo superate....e non siamo per questo convinti di aver operato chissa' quale magia.

[marcoc1712]

le CFLAGS del mio make.conf :
CFLAGS="-march=core2 -O2 -pipe" ....la mia CPU è un core2

Quindi compilando e linkando sul tuo sistema produrrai binari adatti ad un core2 (che è una indicazione generica), nulla di meno ma nemmeno nulla di più. Lo stesso grado di 'ottimizzazione' lo puoi ottenere, per esempio, anche in win e su ogni sistema GNU.

Potresti dettagliare anche di più, volendo, e 'personalizzare' le impostazioni di ogni singolo pacchetto (cosa non consigliata), ma Il bello di Gentoo (e non solo suo) è che installando da sorgente sei certo che tutti i pacchetti (sorgente) vengano compilati con CFLAGS allineati e compatibili (salvo errori, ovvio), cosa di cui non hai controllo installando binari.

Immagino che questo sia alla base delle superiori prestazioni, ma difficilmente ha effetti sugli applicativi, specie quando installati da binario.

Credo che almeno su questo non ci sia discussione, vero?

Come ampiamente descritto le USE ( che sono una parte delle istruzioni di compilazione) si occupano delle dipendenze degli applicativi.
Quindi di cio che al sottoscritto piace che venga utilizzato delle dipendenze ....non di tutto e di piu come in una compilazione generica.
L'applicativo verra' compilato con le sue istruzioni specifiche che Portage esegue e basta.

NO, qui è l'errore. LE USE, di per se, NON hanno nulla a che fare con la compilazione e NON descrivono dipendenze tra applicativi, ma tra pacchetti.

Questo è il fraintendimento di fondo. Le USE informano SOLO il gestore dei pacchetti che installando il pacchetto X si deve installare anche il pacchetto Y e Z, con quello che ne consegue in cascata, non alterano MAI ed in nessun modo il processo di compilazione e link, cioè la produzione dei binari, per farlo, si deve necessariamente modificare i sorgenti o cambiare le opzioni di compilazione (CFLAGS) [*]:

Stando nell'esempio, se e solo se Y o Z richiedono la compilazione, allora i componenti y o z (per semplicità) verranno compilati applicando le specifiche regole espresse per Y o Z nei rispetivi CFLAGS, ma ciò NON comporta che l'applicazione x usi effettivamente y o z e, d'altro canto, se l'applicazione x richiede k, se non inserisce nel sistema in qualche modo (con le USE o manualmente) il pacchetto che comprende k (poniamo K), l'applicazione produrrà un errore.

Le dipendenze APPLICATIVE sono descritte nei sorgenti, le USE sono dipendenze TRA PACCHETTI, non c'è nessun meccanismo automatico che garantisca congruenza alle due cose, puoi metterne di inutili o ometterne di indispensabili, ma non puoi cambiar equelle che vengono davvero usate.

Sono aspetti diversi gestiti in momenti diversi da tools diversi.

Questo è il punto chiarito il quale il mito o svanisce o diventa realtà. Possiamo chiarire questo aspetto invece di parlare di pregiudizio ed insulti?

Al resto eveentualmente rispondo in privato, visto il rispetto che ti porto.

[*] portage, mediante i file .ebuild consente di definire degli 'script' eseguiti in fase di installazione, questi si considerano le USE (come molte altre variabili d'ambiente) e possono certamente prevedere di ridefinire le opzioni del make ed anche applicare patch ai programmi, esattamente come è possibile in altri sistemi con altri tools, ma è una cosa completamente diversa e non stiamo parlando di questo.

Che io ritenga l'abuso di tali pratiche un erorre è noto, ma ininfluente qui.

[bigtube]

Quindi compilando e linkando sul tuo sistema produrrai binari adatti ad un core2 (che è una indicazione generica), nulla di meno ma nemmeno nulla di più. Lo stesso grado di 'ottimizzazione' lo puoi ottenere, per esempio, anche in win e su ogni sistema GNU.

Potresti dettagliare anche di più, volendo, e 'personalizzare' le impostazioni di ogni singolo pacchetto (cosa non consigliata), ma Il bello di Gentoo (e non solo suo) è che installando da sorgente sei certo che tutti i pacchetti (sorgente) vengano compilati con CFLAGS allineati e compatibili (salvo errori, ovvio), cosa di cui non hai controllo installando binari.

Immagino che questo sia alla base delle superiori prestazioni, ma difficilmente ha effetti sugli applicativi, specie quando installati da binario.

Credo che almeno su questo non ci sia discussione, vero?

Per me no. installare da binario è un'opzione.
Quindi una scelta personale.
Gentoo la prevede per chi non abbia per qualunque motivo la necessita' di fare la compilazione dai sources.

NO, qui è l'errore. LE USE, di per se, NON hanno nulla a che fare con la compilazione e NON descrivono dipendenze tra applicativi, ma tra pacchetti.

Dipendenze fra applicativi.....ma di che cosa parli...le dipendenze sono librerie di cui si servono gli applicativi. Le Use selezionate mettono Portage in condizione di utilizzare quelle prescelte, e non tutte quelle possibili, per confezionare i binari a questo punto personalizzati e
pronti all'installazionevera e propria.

Ma dove l'hai vista l'affermazione che enunci come errore catastrofico.

Questo è il fraintendimento di fondo. Le USE informano SOLO il gestore dei pacchetti che installando il pacchetto X si deve installare anche il pacchetto Y e Z, con quello che ne consegue in cascata, non alterano MAI ed in nessun modo il processo di compilazione e link, cioè la produzione dei binari, per farlo, si deve necessariamente modificare i sorgenti o cambiare le opzioni di compilazione (CFLAGS) [*]:

Stando nell'esempio, se e solo se Y o Z richiedono la compilazione, allora i componenti y o z (per semplicità) verranno compilati applicando le specifiche regole espresse per Y o Z nei rispetivi CFLAGS, ma ciò NON comporta che l'applicazione x usi effettivamente y o z e, d'altro canto, se l'applicazione x richiede k, se non inserisce nel sistema in qualche modo (con le USE o manualmente) il pacchetto che comprende k (poniamo K), l'applicazione produrrà un errore.

OVVIO

Le dipendenze APPLICATIVE sono descritte nei sorgenti, le USE sono dipendenze TRA PACCHETTI, non c'è nessun meccanismo automatico che garantisca congruenza alle due cose, puoi metterne di inutili o ometterne di indispensabili, ma non puoi cambiar equelle che vengono davvero usate.

Sono aspetti diversi gestiti in momenti diversi da tools diversi.

OVVIO

Questo è il punto chiarito il quale il mito o svanisce o diventa realtà. Possiamo chiarire questo aspetto invece di parlare di pregiudizio ed insulti?

A me era chiaro....e il mito non c'è mai stato.....il mito l'hai voluto vedere solo Tu.

[*] portage, mediante i file .ebuild consente di definire degli 'script' eseguiti in fase di installazione, questi si considerano le USE (come molte altre variabili d'ambiente) e possono certamente prevedere di ridefinire le opzioni del make ed anche applicare patch ai programmi, esattamente come è possibile in altri sistemi con altri tools, ma è una cosa completamente diversa e non stiamo parlando di questo.

Che io ritenga l'abuso di tali pratiche un erorre è noto, ma ininfluente qui.

Non mi risulta che Gentoo caldeggi le patch qualora non sia assolutamente necessario perchè il sistema non diventi instabile.
E a proposito di patch....le hai confezionate anche tu le patch per gli applicativi.
C'è chi le applica al kernel (vedi le patch di Kolivas )
Le patch si fanno dappertutto e per fortuna visto che il codice è aperto....o no?
Servono per migliorarlo.....o no?

[antonellocaroli]

Per le USE Flags ho postato link a destra e a manca giusto per chiarire e non alimentare niente...

https://gentoo-handbook.lugons.org/d...?part=2&chap=2

L'idea dietro le flag USE

Durante l'installazione di Gentoo (o di altre distribuzioni o comunque di altri sistemi operativi), sono possibili diverse scelte a seconda dell'ambiente di lavoro. Le impostazioni per un server differiscono da quelle per una workstation, così come una stazione per giocare differisce da una per il rendering 3D.

Questo non è vero soltanto per la scelta dei pacchetti da installare, ma anche per le caratteristiche che un certo pacchetto dovrebbe supportare. Ad esempio, se l'uso delle OpenGL non è richiesto, perchè installarle ed abilitarne il supporto nei pacchetti che ne farebbero uso? Per lo stesso motivo, se non si vuole usare KDE, perchè preoccuparsi di compilare i pacchetti col supporto per KDE se questi pacchetti funzionano tranquillamente senza?

Per aiutare gli utenti a decidere cosa installare/attivare e cosa no, è necessario che l'utente specifichi il proprio ambiente nel modo più semplice. Questo forza l'utente a decidere cosa desidera realmente e facilita Portage, il sistema per la gestione dei pacchetti, a prendere le decisioni appropriate.

Definizione delle flag USE

Concettualmente un flag USE è una parola chiave che racchiude l'idea di supporto e di informazione sulla dipendenza. Se si definisce una certa flag USE, si indica a Portage la volontà di avere il supporto per la parola chiave scelta. Questo, naturalmente, altera anche le informazioni sulle dipendenze per un dato pacchetto.

Prendendo come esempio la parola chiave kde, si ottiene questo comportamento: se questa parola chiave non è presente nella variabile USE, tutti i pacchetti che hanno il supporto opzionale per KDE vengono compilati senza tale supporto; conseguentemente tutti i pacchetti cha hanno una dipendenza opzionale con KDE vengono installati senza le relative librerie KDE. Se invece la parola chiave kde è stata definita, questi pacchetti vengono compilati col supporto di KDE e di conseguenza anche le sue librerie vengono installate come dipendenze.

Definendo in maniera corretta le parole chiave si avrà a disposizione un sistema perfettamente ritagliato sulle proprie esigenze.

se poi nessuno li ha letti...

[marcoc1712]

Giovanni, ti voglio bene ed ho un grande rispetto di te, ma evidentemente c'è un mio deficit di comunicazione, vediamo di consolidare, scusa se qualcosa ripeto, ma è al fine di chiudere un quadro condiviso:

a. Solo le opzioni di compilazione (i.e. CFLAGS) influenzano la produzione dl codice binario a fronte di un dato sorgente.

b. gentoo non aggiunge opzioni di compilazioni proprie, sono le stesse di tutti i sistemi GNU.

c. le USE FLAGS non rientrano tra le opzioni di compilazione, quindi non possono influenzare il binario.

d. le USE FLAGS non possono modificare le dipendenze dinamiche, dichiarate nei sorgenti ma soddisfatte al runtime.

e. le USE FLAGS nulla aggiungono in termini di possibilità, rispetto di diverse versioni di codice a soddisfazione di dipendenze dinamiche. E' possibile solo se le due versioni sono compatibili rispetto a quanto stipulato nei sorgenti, come in qualsiasi altro sistema operativo.

f. le USE FLAGS dichiarano dipendenze DA e VERSO pacchetti, utilizzate in fase di installazione ed aggiornamento allo scopo di automatizzarne ed ottimizzarne la gestione.

Puoi confermarmi che condividiamo quanto sopra? Se no, puoi riformulare i punti non condivisi?

Grazie.