Sistemi Dell con Linux preinstallato: parliamone

Si, ricordo di aver letto in proposito alcuni articoli... ma una cosa mi sono sempre chiesto: se la flash non c'è (è stata tagliata per risparmiare) il firmware viene caricato nella ram embedded del dispositivo oppure viene caricato nella ram centrale del sistema e vi accede attraverso lo spazio di indirizzamento del driver?

Magari ho scritto una castroneria, ma chiedere non fa mai male...

Ciao.

In genere questi dispositivi sono dei computerini a se stante, con tanto di RAM e periferiche interne.

No, un momento, non ho problemi funziona tutto bene con la versione degli alsa già presenti nel kernel (openSuse 10.1, per la cronaca). E' solo che un paio di mesi fa mi era saltato il grillo di provare i driver rilasciati dal produttore, visto che li fornisce, per poi scoprire l'ambaradan: sono una versione apparentemente personalizzata degli ALSA (oltre a presentare versioni diverse dei componenti alsa, sono forniti in tre "salse" con lo stesso numero di versione: una per fedora, una per red hat ent. e una generica per le altre distro, che ho scaricato), esistono solo come sorgenti (mi ero illuso male dopo aver trovato i driver nvidia anche in un bel rpm - avendo una gf4, non mi faccio problemi a non usare l'ultimissimo driver) e, leggendo il file install prima di avventurarmi, essendo io curioso come un animale_che_non_mi_viene, ho scoperto che prima di installarsi vanno a ricercare/cancellare/sovrascrivere cartelle con eventuali versioni precedenti degli alsa, solo che dette cartelle nel mio sistema hanno nomi leggermente diversi, quindi ho desistito per evitare di incasinare il sistema (essendoci quasi riuscito, semplicemente aggiornando il kernel con yast2 - non senza pasticciare - e ritrovandomi con il kernel debug, che non avviava kde, come default in grub, ma questa è un'altra storia ).

Comunque, la pagina della wiki non ufficiale del progetto alsa che ho linkato, suggerisce di compilare il kernel per gli alsa in generale, non per la versione realtek, almeno con le prime versioni del 2.6; però mi sembra più un suggerimento, per avere una installazione più pulita e stabile rispetto al semplice aggiornamento dei driver già presenti (non saprei perchè, magari le prime release del 2.6 integravano una versione vecchia degli alsa, che usava diverse cartelle/impostazioni/convenzioni per il kernel cambiate nelle versioni più recenti - o poteva essere così per scelta di qualche distro specifica - e, comunque, suppongo - non dimientichiamo che sono niubboooo! - che ricompilando il kernel successivamente per altri motivi, senza togliere dalla configurazione le impostazioni specifiche per gli alsa già presenti, possa/potesse annullare le modifiche apportate e/o ritrovarsi con moduli diversi per gli alsa, creando conflitti/errori al momento del caricamento (?) - è previsto anche un metodo per sostituire i sorgenti della versione alsa scelta nell'albero dei sorgenti del kernel). Un utente diceva di riuscire "tranquillamente" ad aggiornare gli alsa con il kernel 2.6.1, già configurato per supportare gli alsa e tutte le caratteristiche desiderate, anche se poi doveva mettere mano a /etc/rc.d/rc.local e sistemare il caricamento dei moduli scelti su red hat 8

In genere un firmware è un pezzo di codice che gira interamente su un altro processore che non è quello principale.

All'origine (al momento del boot) le periferiche che richiedono un firmware non 'sanno fare' praticamente niente: accettano solo di caricare un firmware. Nel momento in cui lo carichi, esse lo eseguono e a quel punto sono in grado di accettare 'comandi' dal sistema operativo host; ma il codice non viene eseguito in alcun modo dalla CPU di sistema.

Tanto per farti un esempio, di recente è stato un 'grande successo' il nuovo driver per le schede wireless ipw3945 di Intel. Prima richiedevano un demone userspace che era closed-source (oltre al firmware closed-source), ora è sufficiente il driver open + firmware closed source per far funzionare il tutto. Credo che il codice sia già in -mm e vedrà probabilmente la luce nel kernel ufficiale .22, ma ci sono delle patch in giro per i kernel precedenti.

Detto questo, i due problemi sostanziali nel rilascio delle specifiche sono secondo me essenzialmente questi:

1) Un problema IP 'inverso'. Ci sono così tanti brevetti idioti in giro che secondo me un'azienda ha paura che, rivelando anche solo le specifiche, qualcuno possa pensare che un suo certo prodotto viola un certo brevetto. Con driver e specifiche closed, invece la cosa può passare inosservata.
2) Design subottimali. Con la corsa continua al 'facciamo di più e sempre più in fretta' probabilmente molti dei dispositivi in giro hanno delle belle lacune visibili già a livello di specifiche, e i produttori non vogliono che si faccia.
3) Se non lo fanno gli altri, perché dovrei farlo io? Non mi risulta che, a livello di mercato, ci siano grossi vantaggi economici per un produttore che rilascia specifiche o driver open - almeno sul mercato desktop, perché il fatto che un prodotto di fascia server sia incompatibile con Linux è invece una castroneria che nessuno si sogna - e quindi non lo fanno.

cellulari cn linux ci sn da tempo e per la maggior parte motorola soltanto che sn tutti in asia. In europa si è visto giusto l'A780. Però nn c'è la possibilità di installare software di terze parti se nn lo prevede il costruttore e nn si aggiorna il firmware. Ad esempio sull'A780 girava opera.
il rokr II dovrebbe arrivare anche da noi cn linux sotto. Però sn come normali cameraphone che anziché avere un sistema proprietario usano linux.
Symbian fa schifo anche a me e pensavo anche io che nokia si stesse preparando a linux visti l'N770 e l'N800. Però adesso nn mi spiego più la recente aqcuisizione di symbian uiq da parte di sonyericsson. Nn è la stessa cosa del symbianS60 ma cmq l'origine è comune. Se symbian nn ha più tanto futuro sta scelta come si spiga? Tra l'altro neanhce da dire che abbia mai avuto tanto successo. Pure motorola ha presentato un nuovo modello cn symbian uiq (però senza touch screen).

Puoi essere iscritto pure al Jet Propulsion Laboratory della NASA, ma se non hai imparato a cogliere le battute, soprattutto quando espressamente indicato, stai messo male. Che poi gli ingegneri del cazzo stanno pure all'IEEE stai tranquillo.

"Non ha piu' tanto futuro" se parliamo di questioni "tecniche" eppure la clientela va in euforia quando sente parlare di Symbian, nemmeno fosse l'ultimo ritrovato tecnologico ceduto da popolazioni aliene in omaggio agli umani. Tanto, alla fin fine, quello che interessa è quali applicazioni ci saranno alla resa dei conti e non quale kernel starà girando sotto la gonna. Piu' che altro mi domando cosa rimarrà di Linux una volta che questi sistemi operativi mobili "Linux" saranno pronti
Useranno QTopia come GUI?

La nokia sa fare dell'ottimo marketing, questo è sicuro. Non solo verso gli utenti, ma anche nei confronti degli altri produttori (Sony e Motorola), tanto che è stata capace di ottenere l'adozione di quel sistema persino nei telefoni concorrenti (beccandosi una vanlanga di soldi, visto che symbian limited è di fatto proprietà di nokia). Ma ti assicuro che è davvero un sistema difficile da installare sui device... la sua configurazione è complessissima. E che lo dicano o no, nokia stessa sta cercando di liberarsene...



Quello che interessa è che le modifiche eseguite dovranno essere rilasciate, rendendo il kernel linux ancora più versatile... a vantaggio di tutti.

Non credo che in realtà sarà cosi. Anzi, sono sicuro che la base "comune" avrà ben poco del prodotto completo e funzionante. Il resto sarà tutta un'accozzaglia di estensioni al kernel chiuse che non renderanno mai pubbliche. Un po' come hanno ipotizzato succeda con la piattaforma phoneME. Alla fine la piattaforma base è aperta e accessibile a tutti. Ma continua ad essere lontano dall'essere un prodotto "finito" (come del resto è ovvio).

Però il kernel di linux è sotto gpl, al limite si può mettere un'interfaccia open nel kernel e una parte proprietaria a parte, ma quello che gira nel kernel e ne fa parte dev'essere gpl, o sbaglio?