Gentoo: applicazioni, dubbi, filosofia

[marcoc1712]

no, sta semplicemente facendo il "build" dei relativi "pacchetti", per integrarli nel sistema.

Forse sbaglio io, ma normalmente la 'build' è intesa come insieme di compilazione e link guidata dal makefile, qui si tratta piuttosto di script di installazione di eseguibili prodotti altrove.

Forse solo a me, ma la cosa provoca confusione.

[antonellocaroli]

Forse sbaglio io, ma normalmente la 'build' è intesa come insieme di compilazione e link guidata dal makefile, qui si tratta piuttosto di script di installazione di eseguibili prodotti altrove.

Forse solo a me, ma la cosa provoca confusione.

Ti devi lamentare con chi mantiene gentoo...perché funziona cosi.

emerge ha bisogno di un file .ebuild

tutte le ebuild che lavorano un binario hanno sempre un nome-bin , bin sta per binary.
infatti mi é sembrata strana anche la tua domanda precedente.

un esempio questo é un overlay dove ci sono le ebuild di LMS binario

https://gpo.zugaina.org/media-sound/...ediaserver-bin
media-sound/logitechmediaserver-bin
e si chiamano logitechmediaserver-bin-9999.ebuild

e questo per i sorgenti
https://gpo.zugaina.org/media-sound/logitechmediaserver

[antonellocaroli]

Una nuova compilazione deve essere effettuata ad ogni aggiornamento del programma, giusto?!

Ammettendo che non cambino le dipendenze, basta cambiare il nome della ebuild
es.

mv /usr/local/portage/media-sound/hqplayer-bin/hqplayer-bin-3.14.2.ebuild /usr/local/portage/media-sound/hqplayer-bin/hqplayer-bin-3.14.3.ebuild

ricreare il manifesto

ebuild /usr/local/portage/media-sound/hqplayer-bin/hqplayer-bin-3.14.3.ebuild manifest

e poi

emerge --ask hqplayer-bin

[UnixMan]

Forse sbaglio io, ma normalmente la 'build' è intesa come insieme di compilazione e link guidata dal makefile, qui si tratta piuttosto di script di installazione di eseguibili prodotti altrove.

Forse solo a me, ma la cosa provoca confusione.

that's the way it is... :-)

Nel gergo comune, la creazione di un "pacchetto" per una distribuzione binaria (o l'equivalente operazione di integrazione di un software in Gentoo) si chiama comunque "build".

Questo sia perché di solito (cioè, quando è possibile) si parte dai sorgenti originali del sw, unitamente ai "sorgenti del pacchetto" (gli ebuild ed i relativi files accessori nel caso di Gentoo), per cui il "build" dei binari a partire dai sorgenti è parte integrante del più ampio processo di "build" del "pacchetto" (l'installazione di software precompilato costituisce una eccezione, non la regola), sia (soprattutto) perché si tratta comunque di un processo di "costruzione" di una nuova "unità software" a partire da diversi componenti di partenza (quindi di un processo per molti versi analogo a quello della "costruzione" di un binario a partire dai suoi sorgenti).

Spesso anche gli strumenti utilizzati sono (almeno in parte) gli stessi (in molti casi per costruire i "pacchetti" si usa proprio "make", oppure altri strumenti dedicati ma per molti versi analoghi a quello).

BTW: temo che la tua "confusione" - e molte delle incomprensioni che ci sono state - nascano fondamentalmente da una scarsa comprensione della "filosofia" dei sistemi Linux, nonché dei concetti di base dell'organizzazione, della gestione e dell'integrazione del software in tali sistemi. Che è profondamente e sostanzialmente diversa da quanto accade per altri.

Forse la difficoltà di comprensione origina dal tuo punto di vista, dal modo in cui “guardi” le cose. Se intuisco correttamente, tu vedi "il sistema" e "gli applicativi" come due entità distinte, sostanzialmente diverse e separate tra loro.

Al contrario, alla base della filosofia, dell'idea stessa dei sistemi Unix - ed ancora di più nel caso di quelli GNU/Linux - c'è invece il concetto di "integrazione". In un sistema Linux un applicativo non è visto come qualcosa di diverso e distinto dal sistema stesso, ma piuttosto come una sua parte. Magari opzionale, ma integrata ed integrante.

Quindi un qualsiasi applicativo che si vuole "aggiungere" al sistema è un qualcosa che (a prescindere dalla sua "origine") deve essere integrato, "standardizzato" e reso quanto più possibile affine ed "indistinguibile" da tutti gli altri elementi del sistema.

Lo scopo di un "pacchetto" (o di un "ebuild") non è banalmente solo quello di "installare sul sistema" un dato software (così come è stato pensato dai suoi sviluppatori), ma piuttosto quello (molto più ampio ed "invasivo") di cercare di integrare quanto più possibile quel software nel sistema.

Va da sé che la cosa fa letteralmente a cazzotti con la tua idea di software applicativo indipendente ed autoconsistente, "chiuso in sé stesso", agnostico rispetto al sistema. In effetti, per molti versi ne è l'esatto contrario.

Nel mondo Unix/Linux la "portabilità" è vista soprattutto a livello dell'intero sistema (con tutti i suoi applicativi) rispetto a piattaforme (hardware) differenti, non di singole applicazioni tra "mondi" differenti. L'idea stessa di software autocontenuto, autoconsistente ed "indipendente dalla piattaforma" (laddove per "piattaforma" si intenda anche il SO) è sostanzialmente antitetica con la filosofia di base dei sistemi Unix. Che al contrario si basa soprattutto sull'idea di avere una collezione di software semplici, leggeri, altamente specializzati e fortemente integrati tra loro che formano e costituiscono il sistema stesso. Ciascuno pensato per svolgere al meglio un unico semplice compito, mentre la realizzazione di funzioni più complesse è affidata alla combinazione (spesso decisa dall'utente stesso) di software diversi ed indipendenti che interagiscono tra di loro.

Volendo fare una analogia politico/sociologica, al contrario di altri sistemi che sono basati su modelli sostanzialmente "individualistici" (e.g. windows, MacOS), un sistema Unix/Linux è un sistema basato su un modello di tipo intrinsecamente, fondamentalmente e radicalmente "collettivista" e "cooperativista". :-)

Anche l'idea alla base dei sistemi di gestione del software con i "pacchetti" (o gli ebuild in Gentoo) si basa su questa stessa filosofia e su questa idea di sistema totalmente integrato e standardizzato (e quindi per certi versi anche "centralizzato", dove al centro di tutto c'è il sistema stesso visto come un tutto unico e sinergico, non come un semplice "supporto" di base su cui poggiare più o meno alla rinfusa elementi esterni indipendenti tra loro).

Hope it helps...

[marcoc1712]

that's the way it is... :-)

Nel gergo comune, la creazione di un "pacchetto" per una distribuzione binaria (o l'equivalente operazione di integrazione di un software in Gentoo) si chiama comunque "build".

Questo sia perché di solito (cioè, quando è possibile) si parte dai sorgenti originali del sw, unitamente ai "sorgenti del pacchetto" (gli ebuild ed i relativi files accessori nel caso di Gentoo), per cui il "build" dei binari a partire dai sorgenti è parte integrante del più ampio processo di "build" del "pacchetto" (l'installazione di software precompilato costituisce una eccezione, non la regola), sia (soprattutto) perché si tratta comunque di un processo di "costruzione" di una nuova "unità software" a partire da diversi componenti di partenza (quindi di un processo per molti versi analogo a quello della "costruzione" di un binario a partire dai suoi sorgenti).

Spesso anche gli strumenti utilizzati sono (almeno in parte) gli stessi (in molti casi per costruire i "pacchetti" si usa proprio "make", oppure altri strumenti dedicati ma per molti versi analoghi a quello).

BTW: temo che la tua "confusione" - e molte delle incomprensioni che ci sono state - nascano fondamentalmente da una scarsa comprensione della "filosofia" dei sistemi Linux, nonché dei concetti di base dell'organizzazione, della gestione e dell'integrazione del software in tali sistemi. Che è profondamente e sostanzialmente diversa da quanto accade per altri.

Forse la difficoltà di comprensione origina dal tuo punto di vista, dal modo in cui “guardi” le cose. Se intuisco correttamente, tu vedi "il sistema" e "gli applicativi" come due entità distinte, sostanzialmente diverse e separate tra loro.

Al contrario, alla base della filosofia, dell'idea stessa dei sistemi Unix - ed ancora di più nel caso di quelli GNU/Linux - c'è invece il concetto di "integrazione". In un sistema Linux un applicativo non è visto come qualcosa di diverso e distinto dal sistema stesso, ma piuttosto come una sua parte. Magari opzionale, ma integrata ed integrante.

Quindi un qualsiasi applicativo che si vuole "aggiungere" al sistema è un qualcosa che (a prescindere dalla sua "origine") deve essere integrato, "standardizzato" e reso quanto più possibile affine ed "indistinguibile" da tutti gli altri elementi del sistema.

Lo scopo di un "pacchetto" (o di un "ebuild") non è banalmente solo quello di "installare sul sistema" un dato software (così come è stato pensato dai suoi sviluppatori), ma piuttosto quello (molto più ampio ed "invasivo") di cercare di integrare quanto più possibile quel software nel sistema.

Va da sé che la cosa fa letteralmente a cazzotti con la tua idea di software applicativo indipendente ed autoconsistente, "chiuso in sé stesso", agnostico rispetto al sistema. In effetti, per molti versi ne è l'esatto contrario.

Nel mondo Unix/Linux la "portabilità" è vista soprattutto a livello dell'intero sistema (con tutti i suoi applicativi) rispetto a piattaforme (hardware) differenti, non di singole applicazioni tra "mondi" differenti. L'idea stessa di software autocontenuto, autoconsistente ed "indipendente dalla piattaforma" (laddove per "piattaforma" si intenda anche il SO) è sostanzialmente antitetica con la filosofia di base dei sistemi Unix. Che al contrario si basa soprattutto sull'idea di avere una collezione di software semplici, leggeri, altamente specializzati e fortemente integrati tra loro che formano e costituiscono il sistema stesso. Ciascuno pensato per svolgere al meglio un unico semplice compito, mentre la realizzazione di funzioni più complesse è affidata alla combinazione (spesso decisa dall'utente stesso) di software diversi ed indipendenti che interagiscono tra di loro.

Volendo fare una analogia politico/sociologica, al contrario di altri sistemi che sono basati su modelli sostanzialmente "individualistici" (e.g. windows, MacOS), un sistema Unix/Linux è un sistema basato su un modello di tipo intrinsecamente, fondamentalmente e radicalmente "collettivista" e "cooperativista". :-)

Anche l'idea alla base dei sistemi di gestione del software con i "pacchetti" (o gli ebuild in Gentoo) si basa su questa stessa filosofia e su questa idea di sistema totalmente integrato e standardizzato (e quindi per certi versi anche "centralizzato", dove al centro di tutto c'è il sistema stesso visto come un tutto unico e sinergico, non come un semplice "supporto" di base su cui poggiare più o meno alla rinfusa elementi esterni indipendenti tra loro).

Hope it helps...

Avevo risposto in modo molto più articolato, ma ho perso tutto...

Riassumo:

0. Il codice viene - normalmente - scritto affinchè possa avere la massima diffusione possibile. Tutte le evoluzioni tecnologiche degli ultimi 70 (settanta) anni vanno in questo senso.

Fino a qui, individualisti, anarchici, collettivisti o sovietici hanno poco da fare... Il codice è scritto NECESSARIAMENTE nel modo più agnostico posibile rispetto alla particolarità di OS e HW.

1. Parlando di codice scritto in C, per semplicità, l'unica istruzione in grado di produrre binari diversificati in funzione della piattaforma è CFLAG (o CXXFLAG se C++) e questo si applica in fase di LINK del MAKE. (build).

stessi CFLAG su sistemi diversi producono uguale eseguibile, diversi CFLAG su stesso sistema producono eseguibili diversi.

sui sistemi GNU, la compilazione (gcc o cc o c o ...) ed il link vengono getsiti dal makefile, invocato dal comando make. in MSVS si usano strimemnti diversi, ma con analogo risultato.

NULLA dopo il make può cambiare le istruzioni che vengono eseguite, compree le iUSE di Gentoo, che sono sonlo una DICHIARAZIONE di dipendenze tra pacchetti, ma in nessun modo possono contrastare le dipendenze DA CODICE.

Quello che puoi cambiare sono la presenza o meno di librerie o componenti nel sistema (non il fatto che le usi, solo che siano necessariamente pesenti) il che IN ALCUN MODO può influenzare il funzionamento dell'applicazione in se, piuttosto, questo si, è il sistema che cambia, ma non in ragione dellle dipendenze (se corrette) di un applicativo.

Puoi fare danni, ma non migliorarlo.

2. Io sono individualista ed anarchico, quindi standardizzazione, centralizzazione, cooperzione e collettivismo sono concetti che rifuggo in generale, nella realizzazine di codice applicativo appartengono all'età dei dinosauri, ormai completamente sostituiti al concetto di integrazione debole o addirittura inversione di controllo, che 'liberano' il programmatore ai vincoli dettati dalle altre applicazioni, se non in ragione di 'contratti' precisi in merito ai servizi mutualmente utilizzati.

In che modo, a titolo di esempio MySQL, è più integrato in Linux che non in Win o altrove?

3. Quello in cui Linux è diverso da Win è "l'orchestrazione" del middleware, cioè di quello strato di software costituito da installers, gestore di pacchetti,... che conducono a che l'insieme del software ESEGUIBILE A,B e C funzioni nel più efficient emodo possibile.

Ma si tratta di tools. Comunque tu arrivi alla configurazione finale, quella è, sia con ebuild, che manualmente, se repplichi esattamente gli stessi passi. Non che lo consigli, anzi, una efficiente gestione dei pacchetti è un plus notevole a mio avviso, soprattutto per la manutenzione, ma NON AGGIUNG ENULLA (per fortuna) a quanto stabilito nell apartitura (il sorgente).

4. Il fatto che Linux possa comprendere la build nel corso dell'installazione del pacchetto e che gentoo chiami ebuild lo strumento contribuiscono ad aumentare la confusione, rimangono comunque fasi distinte con significati e portata del tutto diversa.

Non sono incomprensioni (al netto dei termini), sono punti di vista radicalmente diversi. Io credo che una buona applicazione NON debba sapere su che sistema giri, così da poterlo fare su tutti, tu che debba essere realizzata in modo da 'integrarsi al meglio' nel sistema di destinazione.

Al netto delle idee, però, i fatti sono concreti: Solo i CFLAGS possono cambiare l'eseguibile prodotto dalla BUILD, nulla di quanto viene dopo, quindi parlare di 'integrazione' prodotta dall'ebuild (a parità di CFLAGS) è quantomeno imporprio.

Per favore evitiamo di prolungare la polemica sulle idee, se ci sono errori in quello che ho scritto, perchè le cose non stanno così, allora correggetemi pure, portando però casi pratici concreti. Parliamo di squeezelite?

[bigtube]

Avevo risposto in modo molto più articolato, ma ho perso tutto...
.................................................................................................... ..............................................
Riassumo:

Parliamo di squeezelite?

Marco
dal basso di mero utente di Sistemi Operativi e di Programmi faccio delle osservazioni.
- i Programmi o Applicazioni sono scritti per essere usati. Per usarli ci vogliono i sistemi operativi nei quali si devono integrare
Un bel programma scritto benissimo inserito in un S.O. osserviamo comunemente tutti i giorni che lavora bene o molto bene....in altri S.O. meno bene....in altri ancora in modo eccellente.
Se tu mi chiedessi di usare per es. Windows io ti rispondo .... "Mai" o una volta che riscontrassi che va' molto bene...."Ok lo uso ma solo se mi soddisfa per quel programma specifico".
Per quello che serve a me Win non mi interessa quotidianamente.
Ora se dopo tante esperienze con sistemi operativi utilizzati per l'ascolto di musica GLI STESSI PROGRAMMI CHE PIACCIONO A ME....e tu sai quali sono molto bene,
fatti girare su Gentoo fanno letteralmente il salto nell'eccellenza, secondo me dimostra quanto segue :
un bel programma ben articolato nel suo funzionamento per dare il meglio deve integrarsi in un sistema che glielo permette.
Mi pare del tutto utopistico che tu pensi di isolare l'applicativo dai sistemi che lo devono gestire.
Puo essere che in futuro ci arriveremo ma ora nel mondo reale le cose vanno cosi.
Ancora stiamo nel software proprietario e open source e le distorsioni del software propietario sono sotto gli occhi di tutti.

[marcoc1712]

Marco
dal basso di mero utente di Sistemi Operativi e di Programmi faccio delle osservazioni.
- i Programmi o Applicazioni sono scritti per essere usati. Per usarli ci vogliono i sistemi operativi nei quali si devono integrare
Un bel programma scritto benissimo inserito in un S.O. osserviamo comunemente tutti i giorni che lavora bene o molto bene....in altri S.O. meno bene....in altri ancora in modo eccellente.
Se tu mi chiedessi di usare per es. Windows io ti rispondo .... "Mai" o una volta che riscontrassi che va' molto bene...."Ok lo uso ma solo se mi soddisfa per quel programma specifico".
Per quello che serve a me Win non mi interessa quotidianamente.
Ora se dopo tante esperienze con sistemi operativi utilizzati per l'ascolto di musica GLI STESSI PROGRAMMI CHE PIACCIONO A ME....e tu sai quali sono molto bene,
fatti girare su Gentoo fanno letteralmente il salto nell'eccellenza, secondo me dimostra quanto segue :
un bel programma ben articolato nel suo funzionamento per dare il meglio deve integrarsi in un sistema che glielo permette.
Mi pare del tutto utopistico che tu pensi di isolare l'applicativo dai sistemi che lo devono gestire.
Puo essere che in futuro ci arriveremo ma ora nel mondo reale le cose vanno cosi.
Ancora stiamo nel software proprietario e open source e le distorsioni del software propietario sono sotto gli occhi di tutti.

Non stiamo dicendo cose necessariamente diverse.

Lo stesso sorgente (compilato per ed) eseguito su sistemi diversi può avere prestazioni anche molto diverse, questo è nell'esperienza di tutti ed i motivi per cui può accadere sono molteplici:

a. Nel programma l'esecuzione di determinate sezioni di codice è condizionato al 'tipo' di sistema su cui si trova a girare (es. if WINDOWS...)
b. In fase di compilazione vengono attivate opzioni diverse che includono o escludono determinate componenti (es. portaudio o alsa) allo scopo di consentire l'esecuzione delle medesime funzionalità su sisstestemi operativi diversi.
c. le stesse librerie sono compilate con opzioni diverse per sistemi diversi e quindi si comportano in modo diverso (v. sopra)
d. i drivers di dispositivo e le componenti del sistema interfacciate dinamicamente sono diversi o compilati in modo diverso (v. sopra)

il risultato è che, ad esempio, Squeezelite ha lo stesso codice sorgente per tutti i sistemi, ma in realtà attiva componenti completamente diversi in sistemi diversi e lo stesso vale per molte applicazioni 'portabili'.

Oltre a questo, in fase di compilazione vengono specificati parametri (i CFLAGS) che determino i sets di operazioni 'elementari' utilizzati per compiere le operazioni 'logiche' descritte nel sorgente, come ad esempio aprire un file, che sono ovviamente funzione del sistema utilizzato ma anche meno ovvie come il tipo di preallocazione della memoria a fronte di una istruzione di copy o move,...

Chi scrive il sorgente decide in prima battuta COSA fa e secondo quale algoritmo (o logica). Solo in casi particolari imposta comportamenti particolari in funzione del sistema ospite, come ad esempio fa squeezelite potendo utilizzare portaudio ovunque, ma anche ALSA su LINUX e di questo ringraziamo Triode.

Di certo però NON scende a sostituirsi al COME le diverse librerie utilizzate eseguono (cioè traducono in istruzioni assembler) la singola funzione nello specifico sistema, o meglio, se vuole farlo NON usa le librerie e ne realizza una versione sostitutiva, che includerà nel suo programma (da codice) al posto dell'altra, ma non è per nulla usuale farlo e di certo non è garanzia di successo (In squeezelite non avviene mai, per fortuna).

Se è quindi possibile sostituire ALSA con PORTAUDIO in Linux è perchè Triode l'ha previsto, è pertanto possibile utilizzare direttamente ASIO invece di PortAudio in win o su macOsx per esempio? No, non senza modificare i sorgenti.

Posso imporre a squeezelite di utilizzare alcune istruzioni piuttosto di altre di una libreria dinamica? No, questo dipende solo da come la libreria dinamica è stata effettivamente compilata.

Posso imporre a squeezelite di usare solo istruzioni comuni ai sistemi a 32 e 64 bit? certo, in fase di compilazione, ma non c'è nulla di diverso nel codice sorgente, solo nei CFLAGS del makefile utilizzato.
.
Come mi sforzo di dire da sempre, il ciclo di play sono meno di 10 righe, che mediante la compilazione si possono tradurre in sequenza di istruzioni anche sensibilmente diverse già nell'eseguibile e di certo attivano componenti di sistema dverse in funzione dei diversi sistemi ospite e dei drivers di dispositivo.

E' , di conseguenza, del tutto normale che le prestazioni siano anche diverse su sistemi diversi, ove ciò che cambia però non è l'applicazione in se, forse può cambiare il binario e cioè le istruzioni effettivamente utilizzate in funzioni delle opzioni di compilazione utilizzate, ma di certo sono diverse le componeniti di sistema interfacciate dinamicamente, sulle quali chi rilascia l'applicativo non ha nesusn controllo (correttamente).

Questo a dire che se il player A sul sistema X suona meglio che su Y, con ogni probabilità è perchè Y è meglio ottimizzato di X, per quanto concerne le componenti attive durante l'esecuzione di A.

Altra possibilità è che A sia stato compilato con opzioni errate per X, nel qual caso o non è possibile altrimenti o è un errore ed andrebbe risolto, sperimentando opzioni diverse a partire da quelle usate per Y, se possibile, fino a trovare le più corrette (o meno sbagliate).

Una terza ipotesi vorrebbe che A su Y goda di una particolare, irripetibile combinazione alchemica, tutto è possibile, ovviamente, ma lo giudico improbabile e comunque non si avrebbe nessuna garanzia di replicabilità

In ogni caso, quanto viene dopo (ebuild, aptitude, installed di osX o win o la manina santa) è invece necessariamente specifico di ogni sistema e NON può in nessun modo cambiare il contenuto dell'eseguibile, ma solo - eventualmente - sostituire i binari delle librerie dinamiche o delle altre componenti di sistema interfacciate, quindi eventualmente cambiando il COME viene eseguita una funzione, a ulteriore dimostrazione del fatto che l'applicazione - giustamente - non se ne preoccupa.

In altre parole serve per assemblare e manutenere il sistema target secondo schemi più o meno liberi o rigidi, in modo più o meno facile o complesso, con implicazioni limitate alla singola applicazione o al sistema in generale,... ma NON serve per cambiare COSA fa l'applicativo e nemmeno il COME lo fa, almeno oltre al primo livello di indirezione.

Per farlo bisognerebbe cambiare i sorgenti, creando di fatto un'applicazione diversa, ma di questo abbiamo già diffusamente parlato.

Quello che può fare è:

a. appesantire inutilmente il sistema ospite dichiarando 'dipendenze' da componenti del tutto inutili
b. rendere instabile l'applicazione non fornendo tutte quelle di cui necessita.

inserire dicotomie è una libera scelta del sistemista, qualsiasi sia il modo prescelto per farlo, ma NON puoi 'migliorare'. le prestazioni dell'applicazione in questo modo, Le 'vere' dipendenze (e le uniche che l'applicazione utilizzerà) sono quelle previste nel codice (e quelle in cascata, ovviamente).

Oltre a questo puoi indubbiamente attivare servizi accessori quali l'avvio automatico o l'impostazione di default nei parametri di esecuzione, impostare priorità dei processi, assegnare un utente di esecuzione, ecc. ecc. ma sono cose di cui l'applicazione non sa nulla e le 'subirà'.

Che poi si possa raggiungere una ottima orchestrazione di squeezelite ed altri componenti all'interno di gentoo, in modo da abilitare funzionalità ed automatismi di livello speriore, stupendo, ma di certo non è quello cui triode ha posto attenzione, certo non più di quella necessaria a rendere possibile l'utilizzo di Falcon o di un .bat in windows o chissà che diavolo in OSX.

Squeezelite NON sa nulla di tutto ciò, fa quello che deve fare e 'pubblica' i suoi modi di interazione, che nel suo caso sono banalmente la riga di comando, fa sempre le stesse cose indipendentemente da come arrivi a lanciare la riga di comando, su qualsiasi sistema utilizzi.

In questo senso, si può dire che il sistema ove l'applicazione da il suo meglio è quello che meno la penalizza, esattamente negli stessi termini di cui si può parlare di una orchestrazione nei confronti della partitura. Chi si sognerebbe di dire che Beethoven ha scritto le partiture perfette per Karayan ed i Berliner o - peggio - per essere riprodotte su un push pull di el34 o magari su un player con temporizzazione così da consentirne l'avvio automatico?

Non è una affermazione falsa, ma certamente non descrive un corretto rapporto di causa/effetto e risulta un minimo ingenerosa nei confronti certamente di Beethoven, ma alla fine anche di Karajan, i BPO ed il push pull di EL34, non credi?

Più chiaro di così non so spiegarlo.

[antonellocaroli]

Più chiaro di così non so spiegarlo.

Ma era giá chiaro un po di post fa il tuo punto di vista.
Ma esiste anche la libertá di lasciare liberi gli altri di seguire i propi.

Per le dipendenze "sbagliate" ti avevo giá spiegato che era una scelta dell´autore, ho scelto io la ebuild sbagliata.



la r1 é dichiarata con un bel + pulseaudio (che significa che non é una dipendenza vera e propia ma un opzione)......

Ma non era un gran problema...se non era dichiarato nelle USE flag...non veniva preso in considerazione...comq scelta sbagliata da parte mia.

E in questo tread si tornerá a parlare di squeezelite quando ci sará una ebuild che soddisfi le tue richieste fatte in precedenza, redame , licenze eccc.. Se ci sará...
E comunque se vuoi puoi anche dare una mano in questo senso, se ti va. Ma credo non ti interessi e non fa niente...no Problem.
"Amici" come prima...ma per favore non continualra a menare, altrimenti Paolo deve dire la sua (e sono quasi sempre daccordo con lui), io deve dire la mia...poi a catena non la finiamo...

Abbiamo Idee diverse.




Per come usare squeezelite su sistemi linux, giá c´é una guida....
http://www.nexthardware.com/forum/pc...tml#post945012

Questo é quanto, da parte mia.

[marcoc1712]

Ma era giá chiaro un po di post fa il tuo punto di vista.
Ma esiste anche la libertá di lasciare liberi gli altri di seguire i propi.

Per le dipendenze "sbagliate" ti avevo giá spiegato che era una scelta dell´autore, ho scelto io la ebuild sbagliata.



la r1 é dichiarata con un bel + pulseaudio (che significa che non é una dipendenza vera e propia ma un opzione)......

Ma non era un gran problema...se non era dichiarato nelle USE flag...non veniva preso in considerazione...comq scelta sbagliata da parte mia.

E in questo tread si tornerá a parlare di squeezelite quando ci sará una ebuild che soddisfi le tue richieste fatte in precedenza, redame , licenze eccc.. Se ci sará...
E comunque se vuoi puoi anche dare una mano in questo senso, se ti va. Ma credo non ti interessi e non fa niente...no Problem.
"Amici" come prima...ma per favore non continualra a menare, altrimenti Paolo deve dire la sua (e sono quasi sempre daccordo con lui), io deve dire la mia...poi a catena non la finiamo...

Abbiamo Idee diverse.




Per come usare squeezelite su sistemi linux, giá c´é una guida....
http://www.nexthardware.com/forum/pc...tml#post945012

Questo é quanto, da parte mia.

Io ho risposto E QUOTATO Giovanni, cercando di chiarire quello che - evidentemente - non gli era chiaro del mio post, se per te era già tutto chiaro, perchè non rispondi a Giovanni invece di tirare in ballo cose che non centrano nulla con il mio intervento?

a. Ho usato squeezelite solo come esempio ( e l'ho anche sottolineato) perche lo conosciamo tutti.
b. Non ho mai voluto replicare la guida per l'utilizzo disqueezelite su Linux, dove ti hodato l'impressione di farlo? Devo esermi spiegato molto male...
c. Non ho scritto che è sbagliato mettere pulsaudio, mai citato... io ho parlato di PORTAUDIO...confondersi è facile...
d. Se non cambii CFLAGS in che modo 'ottimizzi' l'applicazione in se o anche solo il singolo componente?

Francamente non credo ti sia chiaro quello che ho espresso, certamentenella risposta a giovanni ed anche prima.

Giovanni, scrive:

Mi pare del tutto utopistico che tu pensi di isolare l'applicativo dai sistemi che lo devono gestire.
Puo essere che in futuro ci arriveremo ma ora nel mondo reale le cose vanno cosi.

io non posso che rispondere che:

1. in generale oggi, ma in particolare quelli che lui definisce "GLI STESSI PROGRAMMI CHE PIACCIONO A ME" , sono scritti (codice sorgente) per essere portabili, astraendosi il più possibile dai sistemi operativi che li sosterrranno. Di certo NON sono stati progettati per rendere 'al meglio'su Gentoo, che ciò avvenga è possibilissimo, ma - nel caso - è grazie a Gentoo che supporta l'applicazione nel modo migliore, non il contrario.

Questo è in assoluto un bene, dato che l'integrazione la si ottiene mediante componenti specifiche e specializzate, con garanzia molto maggiori di qualità ed efficienza.

I momenti in cui questo può avvenire sono:

2. build time, impostando le opportune opzioni (CFLAGS in primis).
3. runtime, grazie ad una migliore orchestrazione nel sistema, NON tanto dell'applicazione, ma del sistema nel suo complesso.

Ogni fase usa tools appropriati, quello che avviene a runtime è - ovviamente - impostato in fase di installazione, in gento dall'ebuild, in altri sistemi da altri strumenti o anche da manina santa, ma non c'è modo di cambiare a runtime il binario o a build time il sorgente, o meglio il modo c'è, ma nel caso si parla di applicativi diversi o di build diverse, confondere i tre momenti, gli strumenti utilizzati ed i risultati prodotti non aiuta certo a capire e fare chiarezza.

Che Napoleone sia morto a Sant'Elena non è un'opinione, puoi pensare sia stato avvelenato, forse, ma non puoi sostenere l'opinione che sia ancora vivo e vegeto...

Quindi no, non si tratta (solo) di idee diverse in questo caso, esponiamo FATTI diversi, uno dei due è in erorre. Può darsi sia io, nel caso mi piacerebbe capire perchè e porvi rimedio.

p.s.

giudico improprio (vevo usato un altro aggettivo) chiedermi di NON rispondere a post EVIDENTEMENTE rivolti a me come quello di Paolo prima o di Giovanni poi, il fatto che tu sia daccordo con gli uni e non con me, non credo attribuisca maggiore dignità, non credi sia così?

Nel caso - ma per me non è certo un problema - chiedi a TUTTI di non inquinare il tuo THD, con argomentazioni OT, ma se le ammetti (e ci metti pure un mi piace) poi non chiedere a me di non replicare, un minimo di buon gusto, please.

p.p.s.

non so da quale repository derivi quelle versioni di squeezelite, ma la 1.8.x NON è in google code. In google code c'è solo la vecchia 1.6 di Triode, le altre sono in altri repository.

[antonellocaroli]

non so da quale repository derivi quelle versioni di squeezelite, ma la 1.8.x NON è in google code. In google code c'è solo la vecchia 1.6 di Triode, le altre sono in altri repository.

Te lo avevo giá detto in passato i sorgenti vengono presi dal github di ralfy....

ma se fai un view sulla build....lo puoi capire anche da te.

e chiudiamo l´ OT