Newsgroup: it.comp.os.dibattiti
Titolo: vale la pena di ricordare: "VegetaOS: security by design?"

http://groups.google.com/group/it.comp.os.dibattiti/browse_frm/thread/15b8261ff72b371f/c1d08a8f011f7c83?lnk=gst&q=galaxyos&rnum=5#c1d08a8f011f7c83
dopo 2 lunghi anni di vaporware, 2 anni di spalare merda su unix e linux,
2 anni a dire che GalaxyOS sarebbe stata la soluzione ai problemi
dell'informatica moderna, dopo 2 anni di dire cazzate cosa ci ha regalato
Pasqualino da Ganzirri?
Un'OS inutile per un device inutile, dedicato all'embedded vision, ma
sul quale si possono aprire solo 12 finestre e per trascinarne una devi
premere il mouse, premere il tasto A e premera la  freccetta cursore e che
per di piu' non funziona ancora sul device per il quale era stato
progettato ma suo per il suo emulatore in windows.
Complimenti per averci regalato il replacement per Unix e Linux, ma era
meglio un piatto di cozze
http://sicilyweb.com/foto/439/439-04-39-42-3537.jpg
-- 
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
  printf $i }'; echo

 meglio un piatto di cozze
Tu sei un cretino ed è perfettamente inutile che io che stia
a parlare con te.
Speravo che dopo la gigantesca figura di merda che ti ho
fatto fare ti dessi una bella calmata, ma è impossibile:
sei un cretino e non lo puoi capire....



in definitiva, se non vuoi spiegarlo a me che sono un cretino, spiega al
resto dell'uditorio le seguenti cose
qual e' il tuo punto di vista su UNIX/Linux
poi - visto che tu non sei vegeta (LOL) - cosa ne pensi di Vegeta e del
progetto GalaxyOS? 
E cosa ne pensi dei commenti scritti da Vegeta sul suoGalaxyOS? Dicci la
verita': era o non era un pezzo di cretino questo Vegeta? No? Era o non
era una cretinata il GalaxyOS di Vegeta?


 progettato ma suo per il suo emulatore in windows.
Certo, infatti le foto postate mostrano un PC che sta eseguendo un
emulatore Windows.
Adamo, ma vattene in bagno, và.....

 disposizione diminuisce.
non capisco.
un momento mi dici che questo device ha prestazioni eccellenti e che non
e' vero quello che dico io (cioe' che e' un giocattolino).
un altro momenti mi racconti che devi ricorrere a dei sotterfugi per
limitare il numero di finestre complessivo (al fine di preservare un
livello accettabile di prestazioni)
Insomma, e' o non e' un device per l'embedded vision (ri-LOL)? Allora
perche' questi limiti? 
Io una risposta ce l'ho. La tua  risposta quale.


 Io una risposta ce l'ho. La tua  risposta quale.
LOLLI come un cretino con te stesso, perchè io non ho mai
scritto che la PSP è un device per l'embedded vision.....
Ho detto che noi usiamo la PSP come dispositivo per fare
visione artificiale, esattamente come usiamo altri sistemi
embedded.
Quindi, perchè LOLLI?
Perchè sei un cretino?

 ). E vale anche per Nanodesktop per Linux x86.....
Che non si fa mai. Hint, preallocazione ovvero lista linkata a blocchi 
(presente inodes e blocks in un FS unix?). Piu` efficiente di avere un 
array statico non c'e`, ma mettere un massimo senza altra possibilita` 
e` pazzia pura.
-- 
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.

 e` pazzia pura.
okkio. Stai parlando con un progettista di OS.


 Perchè sei un cretino?
dispositivo per la "visione artificiale"
LOL-again.
Chiarisciti un po' le idee su come gira il mondo dell'embedding:
http://www.arm.com/markets/showcase/
dal cellulare, all'ipod, alla console, alla TV, alla video camera,
alla macchina fotografica, al GPL, compresa la PSP e compresi device per
il "multimedia processing".
Poi, se vuoi proprio ribollire dalla rabbia, c'e' pure questo:
http://www.epson.com/cgi-bin/Store/consumer/consDetail.jsp?oid=49164278



usare realloc quando ti avvicini al limite  fa brutto ?


Guarda, sto proprio ribollendo, eh....
Minchia come ribollo....
Senti cretino: parliamoci con estrema chiarezza. Tu avevi intenzione di
iniziare una meravigliosa pantomima sul fatto che Nanodesktop sia
stato realizzato con Powerpoint.
Ti andata male... molto male...
Allora, dopo essere stato sputtanato, ecco che si passa ad altre cazzate:
ma sì, il device fa schifo, ma sì di cose così ce ne sono già migliaia,
cerchiamo di mettere in relazione Nanodesktop con GalaxyOS per
vedere di fare numero, insomma vediamo cosa ci possiamo inventare....
Tu sì che sei una persona seria, cazzo: dici "preferisco parlare di
fatti....".
Ecco bravo, quali sarebbero i fatti: "scommettiamo che i demo PSPE
sono fatti con Powerpoint perchè sono nitidissimi (certo cazzo, basta
fare ALT+STAMP e copi l'immagine dell'emulatore in funzione
negli appunti)", quando è presente l'immagine scaricabile da Internet.
Ma l'immagine scaricata da Internet non la scarichiamo perchè "non
scarico mai roba strana/inutile.....". Ovvio, non scarica roba strana
ed inutile lui, ma si sente il diritto di ipotizzare che non esista, che
sia fatta con Powerpoint o che qualora esiste davvero faccia schifo
a prescindere. Questo è il parlare di fatti di Adamo....
ROFTL. Anzi stra-ROFTL.
Poi, sempre per parlare del modo in cui lo scemo parla di fatti:
"ti prego, pasqualino, postami qualche riga della libc, basta
anche vegeta.h, a me va bene....". Sono stati postati 70 kb ed
ancora stai a rompere le balls.
Il bello è che stai inzozzando il NG con tutte ste stupidaggini
e non si capisce ancora dove vuoi andare a parare...

 pazzia pura.
Non sono d'accordo.
Supponiamo di mettere una lista di struct che contenga i
dati relativi a tutte le finestre.....
Così, possiamo implementare infinite finestre, giusto?
Sbagliato.
La memoria della PSP è limitata, non è che usando una lista
(o una lista di array), abbiamo la possibilità di aprire realmente
infinite finestre.
Quello che invece otteniamo è un overhead bestiale che si
manifesterà sempre, anche per le applicazioni che usano
2,3, o 10 finestre.
Con delle modifiche al codice (che sto eseguendo), posso
supportare fino a 64 finestre. Ma il problema è sempre
lo stesso: la RAM a disposizione è quella.
Di fatto, in questa situazione, è meglio dire che abbiamo a
disposizione un numero limitato di finestre, ma abbiamo
un sistema grafico veloce. E' estremamente improbabile
che ci sia un'applicazione per PSP che apre 64 finestre
contemporaneamente.
Al contrario, il vantaggio in termini di velocità che consiste
nell'uso di un'array con un numero fisso di elementi si
vede sempre.

 vede sempre.
Ehem... la mia soluzione (*) e` una cosa del genere:
Block = { [ win0, win1, ..., winMAX, ], *nextBlock }
(*) ``mia'' e` grosso, mia perche` la uso io, ma si usava ai tempi dei 
tempi quindi...



Ed ogni volta che WindowsRender dovrà verificare il colore
del pixel della finestra nr.20, invece di fare un semplice
calcolo di indirizzamento su un array statico, dovrà prima
eseguire del codice macchina per verificare che i dati
relativi alla finestra in questione siano nel chunck di memoria
nr. 0.
E questo controllo lo dovrà eseguire qualsiasi routine che
scriva o legga in WindowsData, ogni volta, per ogni pixel
che viene scritto.....
E cicli di clock che se vanno.....

 E cicli di clock che se vanno.....
Visto che e` un modo che viene usato per ottimizzare proprio i cicli di 
clock... ma sei libero di non usare mai la memoria dinamica eh, malloc 
buttalo.



Il problema è che c'è modo e modo di usare malloc.....




mah, forse in queso caso usare una struttura non è che sia così
terribile... in fondo se prendiamo i palm, non ho mai visto più di 2
finestre aperte in contemporanea (se di finestre si può parlare, credo che
in realtà siano pressoché degli overlay...) ;
multitasking sembra ce l'abbia ma in pratica non viene usato (a parte
suonare la musica in background)... questo in PalmOS 5; poi avevo letto di
cambiamenti in OS 6...
Niente a che vedere con Symbian..
-- 
NoWhereMan
-- NoWhereBlog: 
www.nowhereland.it
-- deviantArt: 
http://nowhereland.deviantart.com
-- Giochi a BiteFight? 
http://bitefight.nowhereland.it/
-- Vagisil migliora la tua vita intima: 
www.vagisil.com/teencenter.shtml


Appunto, ecco perchè dico che elevate prestazioni unite alla possibilità
di visualizzare 10-20 finestre contemporaneamente già è un ottimo
compromesso.....

 Il problema è che c'è modo e modo di usare malloc.....
Quello che ti ho indicato viene usato per minimizzarli, basta saper 
scriverlo. A te prendere un libro di algoritmi e di ottimizzazione per 
leggere molte altre tecniche.


 schifo a prescindere.
http://alnitak.ctt.it/lserni/woowoo/
Bye, G. 

 usare delle liste di struct.
Ci sono molte altre possibilità (un array di puntatori a WindowData, magari 
di dimensione variabile?), questa mi sembra effettivamente la meno 
efficiente, e non credo che sia usata da qualche windows manager esistente.
Ciao