[FSUG PD] distribuzione per robot

[puglia]

Con stumbleupon sono capitato per caso in una pagina dove si
elencavano varie live distributions di linux a seconda degli
scopi che perseguono. 
Cliccando su Robotics (ho pensato a questo thread di qualche
giorno fa) questo è quello che è venuto fuori:

Legnoppix  	http://debian.ipsyn.net/legnoppix/

Pyro Live CD
	http://pyrorobotics.org/pyro/?page=PyroLiveCD

Magari non c'entrano nulla con il tuo intento (non sono in
grado di valutarlo personalmente), ma io le posto lo stesso.
Magari, invece, una di queste due distribuzioni potrebbe
essere proprio quella che stai cercando...
Ciao. 

Francesco

----- Original Message -----
Da : max_xxv <mauro.soligo a gmail.com>
A : "Il Software Libero a Padova e dintorni"
<fsug-pd a lists.fsugpadova.org>
Oggetto : Re: [FSUG PD] distribuzione per robot
Data : Wed, 30 Jan 2008 23:43:18 +0100

> Allora vediamo di spiegare meglio quello che vogliamo
> ottenere che forse il problema è la, non mi sono
spiegato.
> 
> Prima di tutto l'HW, non è che stiamo lavorando ad un
> robot unico ma ad un sistema SW che ci permetta di
> lavorare con gli stessi strumenti SW ciascuno sul suo HW,
> le specifiche minime sono che il robot avrà una scheda
> madre X86 con una CF da almeno 512Mb e 1Gb di RAM e almeno
> una interfaccia di rete per uso interno ( dialogo con
> altro HW IP ) e una per l'amministrazione (probabilmente
> WiFi ). Quello che vogliamo ottenere è una cosa che
> copiata nella CF mi permetta di fare il boot della
> macchina ed avere un mio sistema funzionante con certi
> strumenti già presenti ( compilatori, interpreti, etc...
> ).
> 
> Molto semplicemente potremmo prendere una distribuzione
> USB-oriented e personalizzarla, il punto è se ce ne sia
> una già pensata così, ora mi stavo guardando la SLAX e
> SLAX-RT
> (http://www.mecatronica.eesc.usp.br/~aroca/slax-rt/) che
> potrebbero essere un buon punto di partenza...
> 
> Per come "organizzare la memoria" la cosa che ho visto
> fare solitamente è di creare una immagine che viene
> decompressa in RAM ma questo ha lo svantaggio che per
> modificare un file bisogna sempre ricreare l'immagine, se
> potessimo tenere i dati in CF già decompressi e lavorare
> in tmpfs in modo da essere però matematicamente sicuri
che
> non andiamo a toccare la CF la cosa sarebbe ottima, di
> contro ha che occupa un po' più spazio ma ha molti
> vantaggi di praticità e velocità.
> 
> Per quello che riguarda l'embedded, il sistema nasce per
> un compito preciso, è una scatola nera che ha uno scopo,
> il fatto che l'HW che lo esegue sia vario non ne preclude
> l'appellativo "embedded" a mio avviso e anche così fosse
> non è un problema, non è il nome embedded che ci
interessa
> ma il risultato...
> 
> In ultimo una precisazione sulle risorse, non è che non
ci
> interessa usare il 100% della CPU, anzi, ma se per passare
> dal 90% al 100% mi servono decine di ore di lavoro mi
> costa molto meno mettere una CPU il 100% più veloce,
> l'ottimizzazione non va vista in termini di sola CPU ma di
> tempo di lavoro umano... insomma, da un processore a
> 600Mhz a uno da 1Ghz l'aumento teorico di velocità è
di
> quasi il 100% e in termini di costi meno di un 10%...
> 
> 
> 
> 
> -- 
> Visita il mio sito
> http://www.katodo.com e http://wiki.tuttoelettronica.org
> oppure contattami in MSN, GTALK o ICQ N° 129440900
> Radioamatore: IW3HZQ --- Gentoo user!!
> "Tutto è impossibile fino a quando qualcuno non ci
> dimostra il contrario... "
> _______________________________________________ fsug-pd
> mailing list fsug-pd a lists.fsugpadova.org
> http://lists.fsugpadova.org/listinfo/fsug-pd