Newsgroup: it.comp.os.linux.development
Titolo: Programmazione di un Set Top Box

Dopo alcuni mesi da auto didatta in cui ho cominciato a conoscere
Linux, utilizzandolo ogni qual volta potevo e avevo il tempo per
farlo, ho finalmente avuto l'opportunita' di coniugare la mia passione
per questo mondo, con una proposta di lavoro che potrebbe consentirmi
di approfondire la mia esperienza. 
Grazie alle sue caratteristiche di flessibilita' infatti, la sua
adozione come sistema per un Set Top Box si e' rivelata necessaria per
evitare il costo dell'installazione di un Hard Disk (necessaria nel
caso di Windows invece, almeno cosi' dicono ;-), costo che avrebbe
inciso molto nell'offerta del sistema finale.
Grazie a Linux quindi, la scelta su chi sarebbe andato a sviluppare la
soluzione e' caduta su di me, dato che oltre a non essere del tutto
digiuno di tale sistema, godevo della stima del capo commessa ;-)
Ora siccome la mia conoscenza sull'ambiente di sviluppo di Linux e'
ancora piuttosto superficiale, mi farebbe piacere se qualcuno potesse
consigliarmi il linguaggio di sviluppo piu' conveniente da adottare,
java piuttosto che C (sono i due linguaggi sui quali probabilmente
cadra' la mia scelta), quali ambienti, e soprattutto quale
documentazione mi conviene guardarmi.
Ringraziando in anticipo chiunque vorra' consigliarmi, chiudo
augurandomi che questa possa essere una buona occasione per mostrare
ancora una volta le qualita' di Linux, anche a chi, magari, e' ancora
scettico ;-)
ciao, Michele

Non so cosa sia una "Set Top Box" e se mi darai lucidazioni ti sono grato, 
comunque:
secondo me non esiste il problema java vs C: sono su due livelli diversi.
Per java esiste una libreria standard che fa prtaicamente tutto; certo e' 
lento e si porta appresso un interprete non proprio snello.
In C puoi fare tutto, ma essendo molto piu' di basso livello certe coso 
sono piuttosto lunghette.
Non disdegnare i vari linguaggi script alternativi del tipo perl, python, 
tcl/tk .. con cui puoi fare tutto ( ed in quanto a librerie il perl non e' 
secondo di certo al java ).
IL linguaggio migliore dipende fortemente dall'use che ne devi fare; e 
dalla conoscenza che hai del medesimo.

dalla conoscenza che hai del medesimo.
Credo che scegliero' solo in base alle qualita' del linguaggio in
rapporto al problema e ai vincoli imposti dal sistema.
Grazie e ciao,
Michele

il costo dell'HD (e della licenza del SO).
Il che mi sembra una strana giustificazione: i Disk On Chip, almeno
quelli che uso io, costano da pochi Mega come un HD da alcuni giga.
Il vero vantaggio e' nell'ingombro, e nelle piu' scarse richieste di
alimentazione, oltre che nella silenziosita' totale e l'assenza di
possibili problemi meccanici.
-- 
           |Save our planet!
  Ciao     |Save wildlife;
  roberto  |For your E-MAIL use only recycled Bytes !!
           |roberto poggi  
rpo...@softhome.net

possibili problemi meccanici.
Sono d'accordo. Per risparmiare qualcosa si dovrebbe piuttosto fare un Flash
Disk "fatto in casa", con tutte le complicazioni HW/SW che ne seguono. Ma
trovare la Flash Mem é quasi impossibile.
F.

possibili problemi meccanici.
Ho girato la tua obiezione e la risposta che mi hanno dato e' che un
Set-top-box con un DOC di 16MB costa circa 100 dollari in meno di uno
con un HD (credo parlassero di 2 Giga).
E' chiaro che per poter lavorare con 16 Mb, bisognera' studiare una
soluzione molto parca nei consumi (e quindi il problema java/C nemmeno
si pone a questo punto:): il problema immediato che dovremo
affrontare, una volta che avremo delle informazioni piu' precise
riguardo l'applicazione da sviluppare, e' proprio quello di capire se,
dentro questi limiti, si puo' realizzare.
In ogni caso, e' una soluzione che puo' essere percorribile solo con
Linux, dato che la strada Windows, con queste limitazioni, non si puo'
nemmeno *tentare* di imboccare... ;-)
ciao, 
Michele

nemmeno *tentare* di imboccare... ;-)
Ehi, psst, non dirlo a nessuno, ma con winCE, e 16 MB, ci fai parecchie
belle cosette.
Se poi ci metti su un dos 5, con 16 mega ci mandi su lo shuttle, visto
che da cio' che dici, non dovrebbe servire la parte multitasking, se ho
capito cio' che dovrebbe diventare.
Ribalta cio' che ho detto su elks, che  dovrebbe diventare la base per
un linux embedded, e ottieni lo stesso risultato open source.
Quando sara' funzionante elks? Mah, non lo vedo fare grossi passi,
potresti cogliere la palla al balzo (come diceva il veterinario che
castrava le gazzelle nel parco nazionale del Kenya) e partecpare allo
sviluppo, tempi di marketing permettendo.
Consiglio finale del vecchio brontolone (non me la sono sentita, di
dichiararmi vecchio saggio):
Se, da come sembra di intuire, il discorso e' smaccatamente commerciale,
e tu sei investito in prima persona delle scelte progettuali, fai
moooooooooolta attenzione alla licenza di cio' che userai, potresti
trovare dall'altra parte gente che vuole tenere close-source il
risultato finale, e gli strumenti potrebbero obbligarti ad un rilascio
open, oppure a violare i termini di licenza, e in questo caso, il mio
provocatorio consiglio su aggeggi di mamma MS, nonostante mi pesi
parecchio, non e' da scartare a priori.


parecchio, non e' da scartare a priori.
Non credo che questo possa costituire un problema, dato che il valore
aggiunto per il cliente finale non e' tanto l'applicazione in se' che
andro' a sviluppare io (se la andro' a sviluppare), ma le
*informazioni* che gli spedisco con essa ... ;-)
Grazie e ciao, Michele

Grazie e ciao, Michele
Prego, spero di vederti, tra un periodo ragionevole, su freshmeat.:-)


Prego, spero di vederti, tra un periodo ragionevole, su freshmeat.:-)
Lo spero anch'io :-)
ciao, Michele