Newsgroup: it.comp.os.dibattiti
Titolo: PSP

http://www.ossblog.it/post/1912/primi-passi-di-linux-su-psp
carino 

 carino
Minchia, cosi` ci possono far girare oracle.
-- 
Sensei <senseiwa@Apple's mail>
Research (n.): a discovery already published by a chinese guy one month
               before you, copying a russian who did it in the 60s.

                before you, copying a russian who did it in the 60s.
ma un mini xfce adattato?



GPE
-- 
NoWhereMan (e.v.)
-- 
http://www.nowhereland.it
-- 
http://flatpress.nowhereland.it

 ha scritto nel messaggio 
news:1170326095....@v45g2000cwv.googlegroups.com...

Non serve a niente. C'č Nanodesktop....
Ciao
Pegasus

 
http://www.ossblog.it/post/1912/primi-passi-di-linux-su-psp
l'inizio della fine di nanodesktop.....

 l'inizio della fine di nanodesktop.....
te piacerebbe vero ?

 te piacerebbe vero ?
Ti piacerebbe che non fosse così a te, semmai. Perchè il brand "Linux" è
giusto un attimo più conosciuto di "Nanodesktop".
Poi magari non succede niente, ma a priori la situazione è questa.
-- 
Vide
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq'|dc


Nanodesktop può girare anche su Linux.
Non basta avere un kernel che gira (non si sa bene come...) su
un dispositivo. Poi ti servono altre cose: per esempio una
libreria grafica o un gestore VFPU se sei su PSP.
E GTK+ sarà sempre più lento di Nanodesktop.

 E GTK+ sarà sempre più lento di Nanodesktop.
gtk+ penso sicuro. le versioni embedded per gtk, qt e altro dubito che saranno
più lente, visto che sono librerie grafiche con un bagaglio di esperienza molto
maggiore e utilizzate in palmari ed altri dispositivi spesso più lenti di una psp.


Purtroppo non è così che stanno le cose.
Primo: io non ho usato l'SDK di Sony perchè non è disponibile (o meglio,
viene dato solo ai patner di Sony). Ho usato il PSPSDK che è una soluzione
open source liberamente disponibile, ma che non viene da Sony.
Secondo: l'SDK non fornisce tutto il necessario. Ma proprio per nulla.
L'SDK fornisce solo delle API di base con cui interfacciarsi con il
sistema operativo della PSP (che è qualcosa di simile a NetBSD,
tantovero che si è sempre mormorato che nel firmware della PSP
fossero finite sezioni di codice di NetBSD).
Avere un insieme di syscalls (date dal firmware della PSP, o date da
ucLinux, poco cambia), non significa che tu hai fatto il lavoro.
Ti serve tutto quello che sta sopra, che non è certamente solo una
libc o una libm.
Nanodesktop si inserisce sopra al firmware PSP, e fornisce un sistema
grafico, una API per la gestione della webcam, una API per gestire
l'infrarosso, una API per gestire la VFPU, delle librerie per
accedere alle immagini, un porting completo del sistema OpenCV
di Intel.
Queste sono cose che ho scritto io, non è che l'SDK mi fornisce tutto
il necessario. Quello che voglio dire è che Nanodesktop non è
una stupidaggine che si scrive in 5 minuti, prendendo un pezzo di
codice scritto per PC e ricompilandoselo. E sono cose che comunque
continuerebbero a funzionare (ed ad essere utili/inutili per gli
sviluppatori)
anche se sotto, invece dell'os della PSP, ci fosse uclinux.
Quindi, che **ora** sia possibile anche installare Linux su PSP, è questione
che
non cambia di una virgola i termini del problema, per una semplice ragione:
ok, ora si può installare Linux su PSP, e con questo ?
Chi scrive gli homebrew per la PSP che fa: integra il codice del
kernel Linux nel codice del proprio homebrew? Te l'immagini un
ragazzo che vuole scriversi un programma di posta elettronica, e
deve rilasciare il suo homebrew che contiene un kernel linux
completo per funzionare ?
Ma al di là di questo, io ho avuto il problema tecnico da risolvere
*10 mesi fa*: non è che ogni volta che si deve sviluppare
qualcosa per una piattaforma si può sempre aspettare che
prima qualcuno ci porti Linux, e poi qualcun'altro ci scriva
i drivers, e poi qualcun'altro ci porti sopra le GTK, e poi
arriviamo noi che facciamo il lavoretto basando tutto su
l'ambiente già bello, pronto, preparato (da altri) e funzionante.
Saluti
Pegasus

 l'ambiente già bello, pronto, preparato (da altri) e funzionante.
E chi ti dice nulla.
La discussione è nata perchè hai minimizzato un risultato importante, solo per
l'arroganza di dire "il mio nanodesktop è più figo".
Tra qualche mese se ci saranno evoluzioni forse torneremo a parlare dell'argomento.

 l'arroganza di dire "il mio nanodesktop è più figo".
Ma quale arroganza d'Egitto.....
C'è Campana che inizia dicendo che è l'inizio della fine per
Nanodesktop, io gli rispondo semplicemente "te piacerebbe..."
e tu viene a dire a me che ho scritto "il mio nanodesktop è
più figo...".
Mai scritta una cosa del genere. Mai sognata.
Ho scritto una cosa differente: non serve a niente mettere
X-Server + XFCE minimale, perchè a questo punto ti
gira più lento di una lumaca, ed hai già Nanodesktop che
è scritto appositamente.
Certo, il ragionamento ora non si fa perchè Nanodesktop
è in sviluppo, attualmente è un embrione in via di
gestazione, ma alla fine, una volta completato, fa la
stessa cosa di un XFCE minimale senza bisogno che
tu sotto ci metta un kernel Linux che gli fornisca un
layer di compatibilità.....

 Ci sarà.
e allora potrà girare su linux. Cazzo, i tempi dei verbi!

 elettronica?
è una battagli apersa. Purtroppo Filippo e il concetto di layer sembrano
essere ortogonali....

Ottavio Campana wrote:

E' troppo chiederti cosa intendi ?

 è scritto appositamente.
E insisti....
Lascia che siano altri a decidere se il porting sia utile.


urca.. forse la battuta è troppo nerd, mutuavo un concetto da geometria.
Il prodotto interno di due oggetti ortogonali è nullo.


Come sopra....

 piuttosto che interfacciandosi con il kernel Linux.
E saranno cazzi di chi vuole fare il porting non tuoi.

 E rimarrai con il tuo bell'esperimento che non serve a niente.
esperienza personale? :-)
Questa però priendila solo come una battuta, non ti offendere... :-)


NO. Nanodesktop usa l'accelerazione NanoTile (vers. 0.2, non
ancora rilasciata). Quando vuole usare il chip grafico, richiama
una funzionalità SceGu**** che altro non è che una
routine del firmware della PSP che fornisce l'accelerazione
hardware.
Il risultato è che, anche non conoscendo il funzionamento dei
registri del chip grafico, tu lo usi lo stesso perchè passi dalle
routines che ti mette a disposizione il sistema operativo
fornito dalla PSP. Quando a questo sistema operativo vuoi
sostituirne un altro (Linux per esempio), ti trovi nella necessità
di scrivere un driver video. E per farlo devi avere le specifiche
dei registri del chip. O no?
E se queste specifiche non le hai ?

 La gente è libera di installare quello che vuole.
vero. e per fortuna

 o forse sei tu che ogni volta che lo spieghi la racconti diversa...
No, l'ho sempre spiegata nello stesso identico modo.
http://visilab.unime.it/~filippo/Nanodesktop_PSP_PSPE/FAQ/Italian/faq_ita.htm
Che cosa è Nanodesktop?
Tecnicamente, Nanodesktop è una libreria, ossia una collezione di routine 
già pronte che facilita agli utenti la creazione degli HomeBrew.
Un HomeBrew, (letteralmente fatto in casa), è un'applicazione realizzata per 
una data piattaforma embedded. Chi possiede una piattaforma può, 
compatibilmente con le leggi vigenti nel proprio stato, scrivere 
autonomamente del codice C compatibile con il proprio hardware ed 
utilizzarlo sull'hardware di cui è proprietario.
Mai scritto che è un sistema operativo multitasking progettato
per dare filo da torcere a Linux.
Sarei stato un pazzo a fare lo scontro "Filippo contro il resto del
mondo".
E' stato scritto per consentire alla gente di scrivere delle applicazioni
domestiche laddove non esisteva completamente nulla. E nel suo
minimalismo, è valido perchè è la soluzione più veloce. Consente
di scrivere la propria applicazione, testarla su PSPE, e poi
flasharla rapidamente su PSP.
Ci sta consentendo di portare avanti l'EmbVision Project. Ha
consentito di portare su PSP le librerie OpenCV, cosa mai
vista prima d'ora. Fornisce supporto per XFPU ed ha una
modesta accelerazione grafica.
Per noi già questo è più che soddisfacente.
Poi, che oggi qualcuno sia riuscito a lanciare un kernel Linux
(mancano ancora 250 cose e questo non è un dato trascurabile),
è una questione che non cambia di una virgola il problema.
Anche perchè, lo ripeto, fin dall'inizio era stata prevista una versione
di Nanodesktop per Linux.
E perchè, soprattutto, non potevo 10 mesi fa dire: "aspettate, prima
aspettiamo che qualcuno ci porti Linux, poi aspettiamo che qualcuno
scriva i drivers, poi aspettiamo che qualcuno porti X, poi aspettiamo
che qualcuno porti GTK, poi aspettiamo che qualcuno scriva un
driver Raw-IR, poi aspettiamo che qualcun altro scriva un driver per
webcam e poooooooooooooooooiiiiii iniziamo con l'Embvision
Project".
Il problema andava affrontato e risolto quando si è presentato,
non 10 mesi dopo.

 non 10 mesi dopo.
su questo concordo.


Continui a non capire: se un kernel linux mi da la possibilità di
accedere ad una webcam, per me è molto meglio: il mio HAL
si interfaccia al kernel Linux e sfrutta le potenzialità della webcam
in ambiente Linux.
Nanodesktop non deve fare funzioni di kernel: usa il kernel della
piattaforma dove si trova. L'NDSA è chiara: al livello più basso
sta il kernel della piattaforma, poi il sistema NanoCore, ed in
alto sta Nanodesktop.

 vedo che ancora non ci capiamo.... [...]
Pegasus, in alcune occasioni non hai bisogno di memoria protetta, per 
semplicissimi motivi: non hai altri processi. Hai kernel con PID 0, 
init con PID 1 ed un unicissimo processo attivo, che in moti casi puo` 
essere l'init stesso. Sono architetture particolari, non credere che un 
oscilloscopio abbia bisogno di multitasking preemptive e memory 
management.



ED E' GIUSTO.
Ed infatti è quello che succede *sempre* con la PSP. E' Ottavio che
mi contesta che Nanodesktop sarebbe indietro di 30 anni perchè
è monoprocesso, ma non c'entra niente: è il so della PSP che è
multithread ma monoprocesso, io non c'entro proprio nulla.
E tutti gli homebrew scritti per PSP, con Nanodesktop o meno, usano
proprio questa soluzione: UN SOLO PROCESSO, magari con +
threads.

 significa che vuole fare da concorrente a Linux.
no, ma che includi cose che sarebbero più da os che da framework che ci
gira su.

 multithread ma monoprocesso, io non c'entro proprio nulla.
no io contesto la tua contestazione al porting del kernel, perché non
credo che sia inutile.

 gira su.
Ma che mi servono per fare quello che sto facendo ora....

 Ma che mi servono per fare quello che sto facendo ora....
non sto dicendo che sono inutili, ti sto dicendo che quello che è emerso
dallo zip è che il tu codice va strutturato meglio.

 che gira attualmente sulla piattaforma.
Che gi debba girare un unico processo multithread o piu' processi il
problema non cambia di molto: un processo erratico, come un thread
erratico puo' far danni agli altri processi/thread, o peggio al
kernel. La mmu e i ring sarebbero utili anche se il sistema puo' o deve
far girare un solo processo... Tuttavia, ti hanno fatto l'esempio dell'
oscilloscopio.
bye G.L.
-- 
Renaissance, aka Gian Luca Sole
Per rispondere, togli nospam al contrario, e cambia nazione
"E' assolutamente evidente che l'arte del cinema si ispira
alla vita, mentre la vita si ispira alla TV" - Woody Allen


Quello che io contesto è che, (a parte il fatto che è del tutto inutile
contestare a Nanodesktop la mancanza del multiprocessing quando
lo scheduler che viene sfruttato è quello fornito dall'os della
piattaforma), se non c'è MMU, il kernel linux non se la può
inventare. E quindi di fatto il vantaggio è abbastanza contenuto.
Non a caso:
http://www.uclinux.org/pub/uClinux/FAQ.shtml#2-5
Does uClinux support multitasking? What limitations are imposed by not
	having a MMU?
A.	uClinux absolutely DOES support multi-tasking, although there are a
	few things that you must keep in mind when designing programs...
         1. uClinux does not implement fork();  instead it implements 
vfork().
	    This does not mean no multitasking, it simply means that the
	    parent blocks until the child does exec() or exit(). You can still
	    get full multitasking.
         2. uClinux does not have autogrow stack and no brk(). You need to 
use
	    mmap() to allocate memory (which most modern code already does).
	    There is a compile time option to set the stack size of a program.
    **********************************************************
    3. There is no memory protection. Any program can crash another
            program or the kernel. This is not a problem as long as you are
	    aware of it, and design your code carefully.
    ***********************************************************
         4. Some architectures have various code size models, depending on 
how
	    position independance is achieved.
Tornando all'esempio dell'oscilloscopio, la mia sensazione (ma mi posso 
sbagliare
è chiaro...) è che sarà sempre 10 volte più veloce un oscilloscopio fatto 
con
Nanodesktop+PSP-OS che non un oscilloscopio fatto con xlib + ucLinux.
Ma è chiaro che è solo una mia opinione e che posso sbagliarmi ....

 fatto con xlib + ucLinux.
probabile, ma chi installerebbe mai l'xserver su un oscilloscopio?
-- 
NoWhereMan (e.v.)
-- 
http://www.nowhereland.it
-- 
http://flatpress.nowhereland.it

 tra "thread" e "processo".
premettendo che la definizione può cambiare in base al paradigma
adottato, in generale questo è falso. In generale un processo ha la sua
entry nella tabella dei processi, il thread no. Il task ha una maschera
dei segnali tutta per lui, i thread no. I thread condividono lo spazio
di indirizzamento, i task no (e attenzione, è ben diverso da dire che
non c'è la protezione della memoria).
Comunque ti pongo una riflessione: windows 95/98/ME facevano protezione
della memoria solo per la pagina 0. Non era abilitata per il resto ed
infatti non era così difficile bombarsi il sistema anche se girava su
una macchina con mmu. Vuoi dire che quei tre sistemi operativi non sono
multitasking?
http://everything2.com/index.pl?node_id=668981&lastnode_id=0

, ma non si dice mai che era "multiprocesso".
Che non l'abbiano mai detto, non significa niente: o vorresti dire che
non ci sono i processi su AmigaOS? In che modo pratico e concettuale te
li gestisci l'esecuzione di piu' programmi condividendo le risorse fra
cui il tempo di cpu? (*)
bye G.L.
p.s.: (*) le argomentazioni basate sulla "mancanza" di un qualcosa per
arrivare ad una certa conclusione, sono errate a parte poche eccezioni.
