Guida a Logitech Media Server, Squeezelite e derivati.

Pagina 73 di 188
prima
... 23 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 123 173 ... ultimo
Visualizzazione dei risultati da 721 a 730 su 1875
  1. #721
    tebibyte L'avatar di UnixMan
    Registrato
    Sep 2013
    Messaggi
    2,529
    configurazione

    Predefinito

    Originariamente inviato da antonellocaroli
    Adesso lo script puó essere lanciato anche da utente normale senza sudo poi ti chiede la password di root...
    sì, verifica l'utente e nel caso non sia root utilizza banalmente "su" per ri-avviare se stesso come root. In effetti c'era già dalla versione precedente: era il comando di cui avevo chiesto di indovinare la funzione... ma nessuno ci si è neanche provato.

    Originariamente inviato da antonellocaroli
    Mi da un errore nell´installazione si squeezelite:
    codice:
    Download ed installazione di squeezelite-R2
    [...]
    ./aasetup.sh: riga 170: gdebi: comando non trovato
    il problema è a monte, qualcosa non ha funzionato nell'installazione dei pacchetti: non ha installato "gdebi" (e quindi probabilmente neanche il resto). Bisogna capire perché...

    Originariamente inviato da antonellocaroli
    Tranne
    in /etc/default/grub manca intel_idle.max_cstate=0
    GRUB_CMDLINE_LINUX="threadirqs intel_idle.max_cstate=0"
    questi a dire il vero li ho omessi di proposito, perché sono troppo "hardware-dependent". Che succede se uno ha una CPU diversa che non supporta quei parametri? Mmmh, forse in effetti nulla...

    Originariamente inviato da antonellocaroli
    nel mio specifico caso per esempio questo parametro é importante, mi elimina un fastidioso fischio quando la cpu é in idle...
    fischio? dal PC o dall'uscita audio??

    Originariamente inviato da antonellocaroli
    non so se é importante,
    questo me lo dovete dire voi...

    Voglio dire, quello che vi pare avere una qualche rilevanza dal punto di vista "sonico". Da un punto di vista "teorico" in genere i valori di default delle varie variabili sono più che appropriati per la maggior parte delle applicazioni; solo alcune, nel nostro caso specifico, potrebbero portare dei vantaggi se impostate diversamente. Sono comunque qui per supportarvi nelle prove più improbabili e spericolate... cercando di evitarvi solo errori potenzialmente catastrofici.

    Originariamente inviato da antonellocaroli
    fs.inotify.max_user_watches = 524288
    Non so se qualcuno (qualcosa) usi "inotify". Dubito che lo faccia SL (non vedo perché dovrebbe). Potrebbe invece farlo LMS (per aggiornare automaticamente l'archivio della musica quando viene aggiunto / modificato qualche file audio, come fa ad es. MPD) ma non so se LMS abbia questa funzionalità... e tanto meno se, nel caso, per farlo usi proprio inotify piuttosto che qualche altro metodo (considerato che LMS è multipiattaforma mentre inotify è una funzionalità specifica di Linux, ne dubito).

    Originariamente inviato da antonellocaroli
    Installare le cpufrequtils
    e impostare in /etc/init.d/cpufrequtils
    cambiare GOVERNOR="ondemand" in GOVERNOR="performance"
    in verità, questa è una delle cose che mi lasciano un po' perplesso: sicuro che convenga farlo? Perché? A me, "a naso", sembrerebbe controproducente. Perché far girare la CPU sempre alla max frequenza (e potenza), se non ce n'è alcun bisogno?

    Sul server (che in questa applicazione è l'unico che può eventualmente usare "pesantemente" la CPU) direi che sia comunque irrilevante mentre sul player, considerato che qui al contrario la CPU non fa quasi nulla, io penserei di impostarlo casomai a "powersave"...

    Originariamente inviato da antonellocaroli
    Paolo se le ritieni controproducenti non metterle
    vedi sopra: si tratta di impostazioni pensate per ottimizzare le prestazioni in un contesto che è lontano anni-luce dal nostro. Nel nostro caso dovrebbero essere "teoricamente sbagliate" (controproducenti). Però, considerate le nostre esigenze tutt'altro che pressanti in fatto di prestazioni di rete, presumo che non dovrebbero esserci differenze significative, almeno in termini di prestazioni "tecniche". Per il momento quindi l'ho messo per facilitarvi le prove (si fa prima a commentare una riga piuttosto che ad aggiungerla, e non si rischiano errori...). Se ritenete di percepire qualche differenza significativa (e favorevole) all'ascolto le lasciamo, in caso contrario (peggioramento o nessuna differenza avvertibile) le tolgo del tutto.

    Originariamente inviato da DacPassion
    Paolo, ancora non ti sei pronunciato, hai fatto qualche confronto tra questo sistema e quello che utilizzavi precedentemente (mpd credo)?
    in verità... no, ancora non l'ho neanche provato sull'impianto. Ho un periodo abbastanza impegnato e quando ho un po' di tempo libero ho più voglia di ascoltare musica piuttosto che di mettermi a giocare con il sistema e fare prove e controprove...

    Originariamente inviato da marcoc1712
    Grazie per aver cambiato il nome a squeezelite.
    di nulla, ci mancherebbe. In verità, devo ancora modificare i pacchetti .deb per cambiare nome anche a quelli... ma lo farò al più presto.
    Ultima modifica di UnixMan : 23-11-2015 a 00:49
    Ciao, Paolo.

    «Se tu hai una mela, e io ho una mela, e ce le scambiamo, allora tu ed io abbiamo sempre una mela per uno. Ma se tu hai un'idea, ed io ho un'idea, e ce le scambiamo, allora abbiamo entrambi due idee.»

  2. #722
    tebibyte
    Registrato
    Aug 2011
    Età
    50
    Messaggi
    2,928
    configurazione

    Predefinito

    il problema è a monte, qualcosa non ha funzionato nell'installazione dei pacchetti: non ha installato "gdebi" (e quindi probabilmente neanche il resto). Bisogna capire perché...
    Forse il problema é mio che ho provato su una Stretch....stasera riprovo su una jessie...

    fischio? dal PC o dall'uscita audio??
    Dal pc Paolo, piú precisamente dalla scheda madre...mi capita solo con alcune distribuzioni linux, con windows no, e lo risolvo solo inserendo quel parametro.

    si fa prima a commentare una riga piuttosto che ad aggiungerla, e non si rischiano errori...
    Giusto!!!
    Ultima modifica di antonellocaroli : 23-11-2015 a 07:04

  3. #723
    tebibyte L'avatar di UnixMan
    Registrato
    Sep 2013
    Messaggi
    2,529
    configurazione

    Predefinito

    Originariamente inviato da antonellocaroli
    Forse il problema é mio che ho provato su una Stretch....stasera riprovo su una jessie...
    possibile... ma non è escluso che ci sia un errore mio nello script.

    Originariamente inviato da antonellocaroli
    Dal pc Paolo, piú precisamente dalla scheda madre...mi capita solo con alcune distribuzioni linux, con windows no, e lo risolvo solo inserendo quel parametro.
    curioso. Sarebbe da segnalarlo agli sviluppatori: manda un bug report...

    BTW: che hardware hai? A che frequenza è (approssimativamente) il fischio?

    In ogni caso, metterò una opzione per aggiungere quei parametri.
    Ciao, Paolo.

    «Se tu hai una mela, e io ho una mela, e ce le scambiamo, allora tu ed io abbiamo sempre una mela per uno. Ma se tu hai un'idea, ed io ho un'idea, e ce le scambiamo, allora abbiamo entrambi due idee.»

  4. #724
    pebibyte L'avatar di marcoc1712
    Registrato
    Jan 2013
    Messaggi
    5,254
    configurazione

    Predefinito

    Originariamente inviato da UnixMan
    comprendendo che anche questa è fondamentalmente una questione sostanzialmente psicologica, di "percezione", hai centrato il problema. Però IMHO sei fuori strada sul resto. Purtroppo a mio avviso si tratta di un problema molto più profondo, e sostanzialmente insolubile. Mi spiego (ci provo...).

    La prima riflessione è addirittura banale. Di fatto, a ciascuno di noi sembra facile ciò che conosciamo e sappiamo già fare, mentre ci appare (più) difficile ciò che (ancora) non conosciamo e non sappiamo fare. Esempio banale: andare in bicicletta è facile, giusto? Ma prova a pensare a come ti sembrerebbe difficile (se non addirittura impossibile) pensare di dover restare in equilibrio su quelle due ruote sottili se non fossi mai salito su una bici in vita tua, e magari non avessi neanche visto nessuno farlo!

    Tornando al contesto in questione, tipicamente un utente Windows si trova spaesato ed in difficoltà ad usare un Mac (a meno che non lo conosca già), e viceversa. Entrambi poi si troverebbero spaesati di fronte ad una GUI Linux. Ed ovviamente vale anche il contrario: un utente Linux che non conosca win o mac si troverebbe spaesato ed in difficoltà di fronte a quei sistemi. Eppure in tutti e tre i casi stiamo parlando di GUI. Tipicamente pure piuttosto simili, quanto meno concettualmente (se non anche "graficamente").

    Il problema non è quindi se si tratti di una GUI piuttosto che una TUI, o altro. Il problema è se si tratta di qualcosa di conosciuto, di "familiare", oppure no.

    Se il nostro anziché l'installer "text-mode" (l'installatore di Debian, sebbene utilizzi un terminale in modalità testuale è a tutti gli effetti una "Guided User Interface"; più propriamente è una "TUI"; un tempo si sarebbe detta una "interfaccia semigrafica") avesse utilizzato la versione grafica (GUI propriamente detta, in tutti i sensi), non sarebbe cambiato nulla. Così come non sarebbe cambiato nulla se si fosse trattato di un qualsiasi altro installatore di qualsiasi altra distribuzione... o se è per questo di qualsiasi altro OS con cui non avesse già una buona familiarità.

    Presumibilmente è un problema che deriva dalla nostra ancestrale paura dell'ignoto: di fronte ad un territorio nuovo e sconosciuto possiamo anche essere incuriositi e/o affascinati ma, fondamentalmente, specie se incontriamo qualche difficoltà, tendiamo sempre ad essere intimoriti e disorientati. C'è poco da fare, è nella natura umana.

    Molto poi dipende anche dai presupposti psicologici inculcati dal marketing:

    Dopo decenni di martellanti campagne pubblicitarie in tal senso, tutti si sono convinti che Windows e Mac siano "facili da usare". Per cui, se si trovano in difficoltà, automaticamente (ed inconsciamente) pensano: "OK, ma allora sono scemo... il sistema è semplice, sono io che non riesco a vedere la soluzione... cerchiamola, non posso essere così stupido da non riuscire a trovarla da solo".

    Al contrario per Linux esiste il mito che "è difficile", complicato, una cosa adatta solo ad hackers e "Nerds", ecc. Di conseguenza, di fronte alla prima difficoltà, anziché cercare di ragionare per trovare la soluzione, il tipico atteggiamento psicologico (inconscio) del neofita è: "OK, questo è troppo complicato per me, non posso farcela"... così non ci prova nemmeno. Mentre magari invece la soluzione è li, banale, davanti ai suoi occhi. Basterebbe osservare, leggere e riflettere tranquillamente per trovare la soluzione (ovviamente sto parlando in generale, non mi riferisco al caso particolare... dove ci sono effettivamente state delle difficoltà oggettive non banalmente superabili).


    No. Infatti bastava pensarci... solo che a nessuno è venuto in mente. Non è poi così raro che le cose più banali siano quelle cui si pensa per ultimo. Specie se (in questo caso più che comprensibilmente) ci si è convinti di essere di fronte a difficoltà astruse e insormontabili.

    Comunque sia, siccome l'esperienza insegna, alla fine dell'esecuzione dello script, tra le varie note che visualizzo, ora ho aggiunto una bella avvertenza che suggerisce di controllare il livello dei volumi e l'eventuale presenza del "mute" con alsamixer, spiegando dove guardare.

    (avrei voluto risolvere la cosa in modo ancora più semplice automatizzandola, cosa facilmente fattibile grazie all'interfaccia CLI "amixer" ma, purtroppo, avendo a che fare con configurazioni hardware diverse ed imprevedibili, non sarebbe facile né affidabile da gestire in modo automatico).


    a dire il vero direi che è arrivato (più che comprensibilmente...) abbattuto e demoralizzato a causa dei problemi veri, prima quelli imprevedibili legati al suo hardware e poi a quelli prevedibilissimi (ed attesi) legati ad un progetto appena nato ed ancora tutto da sviluppare ed affinare (il mio script). Solo alla fine si è scontrato con un problema banale...
    Per non essere frainteso, io non ho MAI inteso riferirmi allo script... E' uno script di installazione, usato (si spera) una sola volta e via...

    Non è che InstallerShell aggiunga qualcosa di significativo qui.

    Lo Script è un lavoro pregevolissimo, incredibilmente pulito e privo di errori per essere così giovane, migliorerà nel tempo, certo, nel senso che controllerà più situazioni ed eviterà ancora più problemi e questo va nel senso che intendo io, come ho già scritto una GUI non è - qui - lo strumento che fa la differenza, anzi...

    Ma per quanto ottimo, lo script inevitabilmente, potrà incontrare problemi imprevisti, chiamando l'utente a fare i conti con il SO ed i suoi strumenti, almeno a fini diagnostici.

    Io mi riferisco a quest'ultima situazione e torno all'esempio di Alsa (perchè è l'unica che ho compreso ): ci fosse stato un 'pannello di controllo' Audio sarebbe stato più facile, non sarebbe stato necessario che a qualcuno venisse in mente di controllare se il mute fosse stato premuto, sarebbe saltato agli occhi, la differenza è TUTTA qui:

    da una parte devi pensare che forse il problema è quello, sapere che esistono comandi da dare per verificarlo, quali sono e che sintassi hanno, darli, leggere ed interpretarne l'output (cosa tutt'altro che banale), dall'altra - per come la vedo io - c'è un pannello di controllo audio che ti evidenzia lo stato corrente, tra cui in bella vista, il muting premuto.

    D'altrocanto, la 'forza' delle web UI sta proprio nella loro povertà funzionale, che costringe chi le realizza ad uno sforzo di semplificazione 'concettuale', ma rassicura l'utente che tutto quello che si può fare è li, davanti ai suo occhi, non ci sono oscure sequenze di tasti da ricordare...

    Sono una capra, pigra e stupida come una scimmia... lo so, ma sono difetti indispensabili per disegnare interfacce utenti efficaci.

    E' poi verissimo che c'è un percorso di avvicinamento a qualsiasi cosa nuova e c'è sempre una resistenza al cambiamento che viene superata più o meno facilmente in funzione di due cose:

    a. quanto il nuovo sistema risolve i miei problemi (bisogno).
    b. quanto il nuovo sistema ha 'appeal' (piacevolezza) ed immediatezza (non richiede training).

    Se ho mal di pancia, qualsiasi medicina me lo faccia passare è la benvenuta, ma un purgante al sapore di prugna da assumere come una caramella o una tisana sono - normalmente - meglio accettati che non un clistere... Pur essendo certamente il secondo metodo più efficace.

    NON è una questione di qualità intrinseca, questa non è in discussione, ma proprio della differenza di 'peso' relativo che spesso i fautori di Linux attribuiscono al fattore 'appeal' rispetto al 'contenuto'.
    Ultima modifica di marcoc1712 : 23-11-2015 a 14:24
    Ciao, Marco.

    "Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction."
    — E. F. Schumacher (mis-attributed to A. Einstein)
    ________________________________________________________________________________
    Autore della patch R2 per Squeezelite e del plugin C-3PO. note libere
    Logitech media Server 7.9 > miniPc + squeezelite-R2 / SB+ > "Lu Scalmentu" NOS R2R DAC by TubeOne/ AudioResearch DAC 1-20 >
    Klimo Merlino Gold TPS > DIS Interconnect > Kent Gold > Reference > Monitor Audio Studio 20 SE

  5. #725
    pebibyte L'avatar di marcoc1712
    Registrato
    Jan 2013
    Messaggi
    5,254
    configurazione

    Predefinito

    Originariamente inviato da UnixMan
    di nulla, ci mancherebbe. In verità, devo ancora modificare i pacchetti .deb per cambiare nome anche a quelli... ma lo farò al più presto.
    Non ti preoccupare, io devo ancora rilasciare la versione rinominata...

    Alcune risposte rapide:

    a. LMS non ha meccanismi per 'sentire' le modifiche su OS, esiste un plugin che li aggiunge (credo attivo in Daphile), ma non so cosa usi a livello di sistema. Esistono liberie portabili sia in Java che in C++ che lo fanno, immagino appoggiandosi sugli strumenti dell'OS ospite o mediante un classico polling, come si è sempre fatto...


    b. CPU e rete... Qualche tempo fa con LMS si sono verificati dei problemi in alcuni sistemi a causa delle impostazioni di risparmio energia, nel senso che provocavano dei momentanei dropouts, inizialmente era uscito un plugin che sospendeva lo stand by ora credo sia integrato in LMS, bisogna vedere cosa succede a SL, ma per sicurezza non abiliterei di default le impostazioni di risparmio.

    Se devo fare riferimento alle ultime esperienze fatte, devo dire che nemmeno l'upsampling più aggressivo riesce a mettere in difficoltà un normale porcessore impegnato ad alimetare un player via rete, i buffer sono sempre ben pieni, i problemi semmai sono a monte. Certo, se uno alimenta 100 player qualche problema può averlo, ma prima con la rete che non con il processore.

    Non ho provato la conversione PCM / DSD, però.
    Ciao, Marco.

    "Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction."
    — E. F. Schumacher (mis-attributed to A. Einstein)
    ________________________________________________________________________________
    Autore della patch R2 per Squeezelite e del plugin C-3PO. note libere
    Logitech media Server 7.9 > miniPc + squeezelite-R2 / SB+ > "Lu Scalmentu" NOS R2R DAC by TubeOne/ AudioResearch DAC 1-20 >
    Klimo Merlino Gold TPS > DIS Interconnect > Kent Gold > Reference > Monitor Audio Studio 20 SE

  6. #726
    tebibyte L'avatar di UnixMan
    Registrato
    Sep 2013
    Messaggi
    2,529
    configurazione

    Predefinito

    Originariamente inviato da marcoc1712
    A per quanto ottimo, lo script inevitabilmente, potrà incontrare problemi imprevisti, chiamando l'utente a fare i conti con il SO ed i suoi strumenti, almeno a fini diagnostici.
    purtroppo, come giustamente dici, è inevitabile... è semplicemente impossibile prevedere tutto. D'altro canto, lo stesso vale anche per qualsiasi altro sistema od interfaccia.

    Ad es., l'autore di Daphile ha fatto un lavoro veramente eccelso, ma... il suo è un sistema chiuso che o funziona bene così com'è o non funziona affatto: se qualcosa va storto, non hai modo di fare nulla.

    Sarò particolarmente sfortunato ma, personalmente, su ben due sistemi dove lo ho provato (il mio e quello di un amico), Daphile è praticamente inutilizzabile. In un caso perché il mio DAC deve essere acceso quando il sistema (OS, Alsa) è già attivo, altrimenti non viene riconosciuto... solo che se il DAC non è già attivo al momento del boot, Daphile non lo vede. Per cui non funziona (classico caso di "dipendenza circolare"...). Nell'altro invece c'è un problema con la scheda di rete. Entrambi sono problemi banali, che sarebbero facilmente risolvibili potendo mettere mano al sistema... mentre avendo a disposizione solo l'interfaccia preconfezionata non se ne esce.

    Senza dubbio stiamo parlando di casi molto particolari, ma l'esempio è paradigmatico: tanto più semplifichi la vita agli utenti finali, nascondendo dietro una interfaccia "semplice" l'inevitabile complessità del sistema, tanto più limiti le possibilità e la libertà di azione degli utenti stessi.

    L'unica soluzione per evitare (o quanto meno limitare enormemente) il rischio di trovarsi di fronte a problemi dovuti a situazioni impreviste ed imprevedibili è quello di realizzare una soluzione completa "a scatola chiusa", una "appliance" comprensiva di hardware e software dedicato e non modificabile dall'utente (un sistema "embedded").

    Che però, evidentemente, limita ancora di più le possibilità e la libertà di azione degli utenti.

    In conclusione, siamo sempre lì : "libertà" Vs. "totalitarismo".

    La "libertà" è una gran bella cosa... ma implica conoscenza, consapevolezza, difficoltà e responsabilità (come cantava Gaber, "la libertà è partecipazione").

    Il "totalitarismo" ti garantisce invece semplicità e sicurezza, ti libera da ogni pensiero e preoccupazione... ma ti impedisce di fare ciò che vuoi, limitandoti a poter fare solo ciò che è stato previsto.

    Qualsiasi soluzione possibile ed immaginabile (in qualsiasi contesto, in effetti...) è e sarà sempre una via di mezzo compresa tra i due estremi.

    Nello specifico, se vuoi più "semplicità" (d'uso) inevitabilmente paghi il conto in termini di "libertà", cioè di flessibilità e versatilità. Se al contrario vuoi più libertà di azione, lo scotto da pagare è una maggiore complessità e difficoltà d'uso.

    Non si scappa: you can't have your cake and eat it too... o, come diremmo noi, non puoi avere la botte piena e la moglie ubriaca.

    Originariamente inviato da marcoc1712
    ci fosse stato un 'pannello di controllo' Alsa sarebbe stato più facile, non sarebbe stato necessario che a qualcuno venisse in mente di controllare se il mute fosse stato premuto, [...]
    come no? avresti dovuto pensare ad aprire quel "pannello di controllo" e guardarci. Che non è affatto diverso da avviare alsamixer... (che poi l'interfaccia di questo non sia esattamente delle più intuitive è un altro discorso).

    Originariamente inviato da marcoc1712
    E' poi verissimo che c'è un percorso di avvicinamento a qualsiasi cosa nuova e c'è sempre una resistenza al cambiamento che viene superata più o meno facilmente in funzione di due cose:

    a. quanto il nuovo sistema risolve i miei problemi (bisogno).
    c. quanto il nuovo sistema ha 'appeal' (piacevolezza) ed immediatezza (non richiede training).
    che è esattamente quello che stiamo cercando di fare: un sistema che si installa nel modo più semplice possibile, e poi fa tutto da solo. In altri termini, un sistema tendenzialmente "totalitario".

    ...fermo restando che, lasciando libertà di scelta sull'hardware, non potremo mai realizzare un sistema veramente e completamente "totalitario". E quindi non potremo mai garantire (neanche lontanamente) l'assenza di problemi ed imprevisti.
    Ultima modifica di UnixMan : 23-11-2015 a 15:44
    Ciao, Paolo.

    «Se tu hai una mela, e io ho una mela, e ce le scambiamo, allora tu ed io abbiamo sempre una mela per uno. Ma se tu hai un'idea, ed io ho un'idea, e ce le scambiamo, allora abbiamo entrambi due idee.»

  7. #727
    kibibyte
    Registrato
    May 2012
    Messaggi
    308

    Predefinito

    Ciao a tutti!
    Ho letto in questi giorni la discussione con molto interesse e, dato che sono stato tirato in ballo più volte come esempio, mi sento in dovere di dire la mia.

    Premetto che: non sono un digiuno informatico. Ho fatto il programmatore per alcuni anni e, anche se adesso ho cambiato mestiere, rimango sempre un appassionato di tutto quello che è tecnologia.
    Ho SEMPRE lavorato in ambiente Windows, sistema operativo che conosco abbastanza bene, ed ho abbastanza esperienza per sapere cosa c'è "dentro" ad un pc (avendo modificati e assemblati diversi).
    Di linux conosco ben poco, anche se ho sempre avuto "simpatia" per questo SO.
    NON mi spaventa a prescindere la linea di comando, anche se confesso che, non avendola quasi mai dovuta utilizzare con frequenza, non conosco a memoria quasi nessun comando, a prescindere che l'ambiente sia di tipo Unix-Linux o dos.

    Detto questo, dico cosa a mio avviso ha reso la mia esperienza particolarmente "faticosa".
    Ho incontrato sostanzialmente due problemi che mi sembra siano rappresentativi dell'ambiente in cui stiamo lavorando.

    1) Hardware
    Qualcuno l'ha già sottolineato: la compatibilità dell'hardware con le varie distribuzioni è tutt'altro che scontata, perchè i produttori forniscono il più delle volte solamente i driver per Windows e null'altro. La capacità degli sviluppatori di riuscire a rendere compatibile l'hardware è lodevole, tanto che i casi in cui un componente risulti DAVVERO inutilizzabile è assai raro.
    Il vero problema è che nelle situazioni come la nostra, dove si gioca anche col kernel, recuperare la compatibilità non è banale.
    A mie spese, ad esempio, ho imparato che: l'installer consigliato della Debian o ha qualche baco nella versione 32 bit, o comunque non riesce a gestire il mio hardware.
    Non solo: non l'ho forse sottolineato, ma la Bunsen riesce a riconoscere senza problemi i vari componenti del mio mini-pc, ma questa compatibilità la perdo quando installo il kernel Liquorix con lo script! Infatti prima dell'installazione ho la scheda wi-fi attiva, dopo non più. (ho anche riportato qualche pagina addietro i warning che ho per la scheda di rete)
    Inoltre temo che anche la gestione sballata della mia tastiera dipenda dall'installazione del kernel.
    Io non ho le competenze per riuscire a sanare questi problemi, perchè la gestione dell'hardware in linux è tutt'altro che semplice, al contrario di Windows dove le cose si riducono di fatto all'esistenza dei driver specifici e a procedure più o meno standard in qualsiasi versioni di Windows si operi.

    2) Distribuzioni
    Un altro problema che per me è risultato parecchio ostico da superare è che le distribuzioni di linux a volte hanno fra loro differenze sostanziali!
    Cioè il mondo linux è davvero MOLTO frammentato, troppo.
    Per confermare questo, mi basta ripensare al problema che ho avuto nel lancio dello script. La prima volta che l'ho lanciato era stato con l'installazione della Debian che ero riuscito a completare (anche se presentava dei problemi): seguendo le istruzioni che dicevano come lanciarlo, mi sono ritrovato all'inizio la richiesta di immettere la password di root, cosa che ho fatto e da lì sono andato avanti. Memore di questa cosa, per la Bunsen ho seguito le stesse istruzioni della volta precedente, peccato che la gestione dell'utente root sia leggermente diversa rispetto alla Debian, tanto che alla richiesta della password di root mi sono bloccato. Prima di capire che bastava lanciare lo script con "sudo", ho perso una marea di tempo perchè non avevo la più pallida idea di dove fosse il problema!
    E stiamo parlando di una distro che DERIVA dalla Debian e che quindi non dovrebbe avere queste differenze così marcate...

    Aggiungo poi che la mia esasperazione e la mia stanchezza finale non dipendevano tanto dal ritenere tutto troppo complicato, ma da altri fattori.
    Il primo: ero molto stanco e provato per altri motivi (il lavoro, la famiglia), quindi questi inciampi li ho vissuti in un momento non particolarmente facile.
    Secondo (e per me più importante): il fattore tempo! Come già detto ero (e sono tutt'ora!) molto impegnato e posso oggettivamente dedicare a questo mio hobby solo pochi (a volte brevissimi!) ritagli di tempo. Immaginate quindi la frustrazione di vedere che procedure che sarebbero relativamente semplici e veloci sulla carta, nella realtà non ti funzionano e ti fanno perdere una marea di tempo per farle funzionare!
    "Smanettare" a me piace! Cercare una soluzione in rete ed avere la soddisfazione di riuscirci è grandiosa. Inoltre qui ho trovato un gruppo di persone che mi facevano da helpdesk quasi in tempo reale (cosa che per me non ha prezzo!). Il fatto è che in questo momento della mia vita, il tempo per "smanettare" in questo modo è un lusso che NON mi posso permettere.
    Sono quindi il primo a capire come mai in ambito informatico, alcune soluzioni "chiavi in mano", nonostante abbiano dei costi a volte anche elevati, continuano a prosperare...
    E continuo a riconoscere (come d'altronde diversi di voi) che una soluzione come Daphile abbia il suo punto di forza proprio nel fatto che è praticamente "pronta all'uso" senza particolari tribolazioni. Che poi non sia sonicamente al top e che Kimmo sia criticabile per tanti motivi non ci piove.

    Mi permetto di aggiungere qualcosa che alla fine per me è ovvio: la questione non è se si deve lavorare da linea di comando oppure da interfaccia grafica. La vera differenza la fa mettere su un sistema o una procedura che, seguendo opportunamente una guida (che sia cliccare su pulsanti in una finestra, oppure digitare gli opportuni comandi in una console), permetta a chi vuole di riuscirci senza particolari problemi.
    La guida che è stata approntata per l'installazione (ma anche per la configurazione) di Daphile è esemplare: anche chi ha poca dimestichezza informatica, con un po' di pazienza, seguendo passo-passo, riesce ad arrivare in fondo senza particolari intoppi.
    Anche nel mio caso, per montare un disco di rete, con la guida indicata ci ho messo non più di 3 minuti senza incontrare alcun problema.

    Insomma.
    Credo alla fine che quello che state facendo sia davvero lodevole, ma penso che per me e molti altri comuni mortali, questa strada sia al momento ancora impervia e "quasi" impraticabile! Mi fa piacere però vedere che continuate a darvi da fare per rendere le cose il più semplici e praticabili possibile!
    Non mollate: anche se con fasi alterne e che saranno molto più silenziose d'ora in poi, continuerò a seguirvi!

  8. #728
    pebibyte L'avatar di marcoc1712
    Registrato
    Jan 2013
    Messaggi
    5,254
    configurazione

    Predefinito

    Originariamente inviato da squonk
    Ciao a tutti!
    Ho letto in questi giorni la discussione con molto interesse e, dato che sono stato tirato in ballo più volte come esempio, mi sento in dovere di dire la mia...
    Grazie delle precisazioni, tieni presente che qui oltre che a fare, ci dilettiamo anche a filosofare, quindi non prenderla sul personale, sei stato usato come 'archetipo' per supportare il dialogo.

    Mi spiace per i tuoi problemi, ma sono contentissimo della tua decisione di continuare a seguirci, anzi, non appena puoi sei il benvenuto per qualsiasi contributo tu ti senta di voler dare, credo di poterlo dire a nome di tutti.
    Ciao, Marco.

    "Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction."
    — E. F. Schumacher (mis-attributed to A. Einstein)
    ________________________________________________________________________________
    Autore della patch R2 per Squeezelite e del plugin C-3PO. note libere
    Logitech media Server 7.9 > miniPc + squeezelite-R2 / SB+ > "Lu Scalmentu" NOS R2R DAC by TubeOne/ AudioResearch DAC 1-20 >
    Klimo Merlino Gold TPS > DIS Interconnect > Kent Gold > Reference > Monitor Audio Studio 20 SE

  9. #729
    pebibyte L'avatar di marcoc1712
    Registrato
    Jan 2013
    Messaggi
    5,254
    configurazione

    Predefinito

    Originariamente inviato da UnixMan
    che è esattamente quello che stiamo cercando di fare: un sistema che si installa nel modo più semplice possibile, e poi fa tutto da solo. In altri termini, un sistema tendenzialmente "totalitario"
    Allora evviva il totalitarismo, sempre che la scelta di adottarlo o meno rimanga nelle mie mani! Trionfo al dittatore, ma morte al tiranno, c'è una differenza...
    Ciao, Marco.

    "Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction."
    — E. F. Schumacher (mis-attributed to A. Einstein)
    ________________________________________________________________________________
    Autore della patch R2 per Squeezelite e del plugin C-3PO. note libere
    Logitech media Server 7.9 > miniPc + squeezelite-R2 / SB+ > "Lu Scalmentu" NOS R2R DAC by TubeOne/ AudioResearch DAC 1-20 >
    Klimo Merlino Gold TPS > DIS Interconnect > Kent Gold > Reference > Monitor Audio Studio 20 SE

  10. #730
    tebibyte L'avatar di UnixMan
    Registrato
    Sep 2013
    Messaggi
    2,529
    configurazione

    Predefinito

    Originariamente inviato da marcoc1712
    Esistono liberie portabili sia in Java che in C++ che lo fanno, immagino appoggiandosi sugli strumenti dell'OS ospite o mediante un classico polling, come si è sempre fatto...
    inotify serve proprio a quello: per evitare il "polling". Anziché dover verificare periodicamente se determinati files (o directory) sono stati modificati, puoi dire al kernel: "se modifichi uno di questi files/direcotries, avvisami" (dato che tutti i file-system sono gestiti dal kernel, il kernel sa sempre se/quando/cosa viene modificato).

    Originariamente inviato da marcoc1712
    b. CPU e rete... Qualche tempo fa con LMS si sono verificati dei problemi in alcuni sistemi a causa delle impostazioni di risparmio energia, nel senso che provocavano dei momentanei dropouts, inizialmente era uscito un plugin che sospendeva lo stand by ora credo sia integrato in LMS, bisogna vedere cosa succede a SL, ma per sicurezza non abiliterei di default le impostazioni di risparmio.
    vedi che succede ad usare sempre interfacce e sistemi troppo "astratti"? si finisce per prendere fischi per fiaschi...

    Quello di cui stiamo parlando non ha niente a che fare con sospensione o "stand-by" (che tra l'altro sono gestite da processi "user-space", attraverso ACPI, non direttamente dal kernel). Il "governor" della CPU si limita a gestire il “Dynamic CPU frequency scaling (also known as CPU throttling)”, cioè in sostanza a "modulare" la frequenza di funzionamento della CPU in funzione del "carico" momentaneo della stessa.

    Le possibili impostazioni sono:

    1) "performance", che tende a massimizzare le prestazioni facendo lavorare la CPU (quasi) sempre alla max potenza;
    2) "ondemand", che tende a bilanciare prestazioni e consumi (e dissipazione);
    3) "powersave", che tende a minimizzare i consumi facendo lavorare la CPU quanto più possibile a potenza ridotta;
    4) "userspace", che demanda la gestione della frequenza della CPU ad un processo esterno (in "user space", per l'appunto).

    In tutti i casi (tranne l'ultimo, che dipende da cosa decide il processo esterno), la frequenza della CPU è determinata automaticamente e dinamicamente: viene aumentata progressivamente quando il carico cresce e diminuita quando diminuisce. I diversi "governor" (tranne l'ultimo) cambiano semplicemente l'algoritmo che determina le caratteristiche di tale regolazione automatica.

    Originariamente inviato da marcoc1712
    Non ho provato la conversione PCM / DSD, però.
    quella immagino che sia inevitabilmente molto ma molto più pesante... forse in quel caso mettere "performance" sul server potrebbe essere utile nel caso si verifichino dei drop-out all'inizio di un brano (dopo non cambia nulla: una volta che il "carico" di CPU è salito al max, tutti e quattro i governor "interni" provvedono automaticamente ad aumentare la frequenza della CPU, se necessario fino al max delle sue possibilità).
    Ciao, Paolo.

    «Se tu hai una mela, e io ho una mela, e ce le scambiamo, allora tu ed io abbiamo sempre una mela per uno. Ma se tu hai un'idea, ed io ho un'idea, e ce le scambiamo, allora abbiamo entrambi due idee.»

Pagina 73 di 188
prima
... 23 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 123 173 ... ultimo

Informazioni Thread

Users Browsing this Thread

Ci sono attualmente 8 utenti che stanno visualizzando questa discussione. (0 utenti e 8 ospiti)

Regole d'invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
nexthardware.com - © 2002-2022