Sembra incredibile: con un mercato delle console portatili ormai saldamente in mano a Nintendo, con Sony a inseguire a distanza, e con altre grandi come Atari e Sega che hanno miseramente fallito, all’orizzonte si prospetta l’arrivo di un terzo incomodo! Per giunta da parte di una sconosciuta casa che ha puntato tutto su hardware e software completamente aperti (non che sia una novità; infatti gli ideatori di questo progetto si sono ispirati a un’altra console portatile open source, il GP2X, che ha riscosso notevole successo nell’ambito dell’homebrew), realizzando OpenPandora.
Le caratteristiche sono di tutto rispetto e ben superiori anche alla PSP: processore ARM Cortex a 600Mhz (ma si parla di versioni finali a 800Mhz), DSP a 430Mhz (per l’elaborazione dei segnali audio e video 2D), GPU OpenGL 2.0 ES (per il 3D), 128MB di memoria di sistema e ben 256MB di memoria flash, e ciliegina sulla torta un display touchscreen da 4,3″ che arriva alla sbalorditiva (per questi gioiellini) risoluzione di 800×480 (la stessa dell’eeePC). Che dire: semplicemente impressionante!
L’elenco, comunque, non si ferma qui: uscita TV, microfono, Wi-Fi, BlueTooth 2.0, RS232 (!), USB 2.0, joypad, due analogici e persino una mini tastiera in formato qwerty completano un quadro che… sembra da favola. A maggior ragione se guardiamo il prezzo a cui dovrebbe essere venduto: 330 dollari, pari a 210 euro circa. Poco più di una PSP!
Ma cosa spinge un programmatore, che ha il chiodo fisso del software, a parlare di un “aggeggio” come questo? Tenersi aggiornati sulle novità del mercato è un imperativo (non ci si può certo fossilizzare sulle conoscenze acquisite), ma davanti a roba come questa la prima cosa che mi viene in mente è: che ci posso fare?
Molto. Moltissimo. Come dicevo prima, OpenPandora è basato su hardware e software “aperti”. In particolare per quest’ultimo è importante sapere che il firmware è basato su Open2X, che è una soluzione basata su kernel Linux e, quindi, apre le porte per sfruttare molto del software che gravita attorno a questa comunità, inclusi… parecchi editor di testo, compilatori, ambienti di sviluppo.
Questa, però, sarebbe tutta roba inutile se non fosse disponibile l’oggetto più caro per un coder: la tastiera. Già, perché qui, a differenza del DS e della PSP, hanno pensato bene di metterne una; piccolina e con pochi tasti oltre ai canonici alfabetici, ma è quanto basta per permetterci di smanettare ovunque ci troviamo, specialmente con linguaggi dotati di un interprete a riga di comando, che permettono di scrivere velocemente pezzi di codice da provare.
Un must, insomma, un sogno che si avvera si dirà. Niente affatto: da tempo i palmari permettono di fare le stesse cose, ma a costi decisamente più elevati e con una dotazione hardware generalmente non all’altezza di quanto offra OpenPandora (spesso, infatti, manca l’accelerazione hardware per il 2D, e il 3D è quasi del tutto assente).
Le premesse, quindi, sono eccellenti, ma rimane da vedere se riuscirà a ritagliarsi una fetta, anche piccolina, in un mercato che è letteramente soffocato da DS e, in minor parte, dalla PSP. Purtroppo anche qui torna maledettamente in gioco il fattore software: senza di esso una piattaforma potrà anche essere molto attraente, ma è destinata all’oblio. Il prezzo più elevato potrebbe essere un ulteriore motivo di penalizzazione, ma bisogna sempre considerare che si distacca poco da quello della PSP, e l’hardware è superiore.
Volete mettere il piacere di aprire in qualsiasi momento una shell con Python e iniziare a smanettare? Impagabile…
Un gioiello di tutto rispetto con un ottimo comparto hardware. Spero che abbia il successo che merita. Io appena disponibile me lo comprerò sicuramente.
L’unico problema di questi prodotti è la fascia di mercato che hanno. Ovvero gli smanettoni. Che è solo una piccola parte in confronto ai miliardi di potenziali acquirenti di psp e ds.
Oggetto culto – mi interessa anche solo per poter avere “un PC in tasca”: se davvero costa quello che promettono, la prossima recensione la faccio io :D
Dubito che mantenga quel costo cosi’ basso.
Un oggetto cosi’ ha milioni di applicazioni; altro che quello starnuto di eeeTc; che ormai e’ il fighettopc, in compagnia al fighettofonino
Infatti. Con quel prezzo mi vien voglia di vendere la mia PSP, visto che la uso esclusivamente per il retrogaming. :D
Con questa ho un enorme valore aggiunto rappresentato dalla tastiera e, quindi, dalla possibilità di poter programmare. Per non parlare del touchscreen (a proposito: al momento sembra non esser dotata di pennino, ma si rimedia lo stesso fregandolo a quello di scorta del DS :D ).
sembra un GP2X con gli steroidi :D
Il doping nelle console portatili. :D Da farci un altro articolo. :D :D :D
Ma non era la gp2x il terzo incomodo ? Il pandora poi ha una storia abbastanza strana :D
Comunque nessuno parla del successore della gp2x ovvero il Wiz ?
Ma dai… anche touch screen! :- D spettacolare.
p.s. proprio in questi giorni sto iniziando a giocare con Python e pensavo quanto figo non sarebbe avere un aggeggino portatile da usare in treno…
x Ciny2: dacci il tempo! :D In futuro arriverà un articolo anche per quello. ;)
E’ possibile farci girare una versione snella di Linux?
Ci gira già. ;)
Quando esce?????
Sembrerebbe per fine anno, ma la compagnia è piccola ed è meglio non metterci la mano sul fuoco. ;)
Programmare con quella tastiera? Siamo seri… ;)
Ho visto adesso, sembra “comoda” ma secondo me programmare direttamente su Pandora fa venire l’emicrania in un quarto d’ora esatto :D
Ma no, sarebbe da pazzi, dai! Mica mi metterei a sviluppare interamente su questo gioiellino: lo usere per testare il codice, sperimentare al volo soluzioni sul momento, ecc.
Insomma, per lo sviluppo vero e proprio gli IDE su PC sono il non plus ultra, ma avere una macchinetta che ti permette di giocare col codice ovunque ti trovi per me è un valore aggiunto non da poco. ;)
[…] note al popolo di Internet e delle community open source, sono le due console portatili GP2X Wiz e OpenPandora. In questo articolo mi soffermerò sulla GP2X Wiz però facendo prima un po’ di storia. Nel […]
io attendo il cortex A9
ho gia’ sperimentato una piattaforma simile, ma di origine nipponica, e usata come PDA avanzato, mi sono pero’ reso conto che gnu-linux non sia affatto il sistema operativo e contorno adatto a questo tipo di piattaforme !
assolutamente non ci siamo!
ho in mano un arm-v5, un Intel Xscale(tm) PXA270 a 416Mhz e la risposta e’ buona, il supporto e’ circa buono, il kernel linux su quella CPU e’ abbastanza reattivo, e la preemption fa la sua brava differenza in userspace regalando altrettanto brio reattivo
pero’ !
essendo un dispostivo portatile ogni istanza suspend deve essere curata, tanto che deve essere possibile in qualsiasi momento mandare in suspend il kernel, ridurre i consumi, e risvegliarlo senza effetti collaterali
questo xke’ un bootstrap completo impiega troppo tempo, quindi si preferisce bootstrappare una sola volta il sistrema, poi tenerlo in standby fino all’esaurimento delle batterie
nel kernel linux accada invece che ci sia una catastrofica situazione, troppa confusione nei sorgenti, nella direzione da seguire, nelle implementazioni delle istanze di suspend
morale il suspend non funziona mai come dovrebbe, o quantomeno e’ dalla versione 2.6.22 alla 30 che si sta tirando dietro + magagne che risultati, e ancora vi sono problemi non risolti che compromettono la stabilita’ del sistema
siamo in un momento di profonda transizione nelle strutture internel del kernel e quindi appena i coder si assesteranno su direttive unanmimente accettate queste scaramuccie verranno si spera risolte
ma se questi sono le rogne in kernel space, in user space ci si scontra con l’interfaccia grafica, che, per sfruttare davvero il grosso del parco software a disposizione per linux-gnu, bisogna che poggi su X11, il quale, di suo, e’ un abominevole elefante, ingordo di ram all’inverosimile, lento, e composto da troppi inutili layer
lo si puo’ ricompilare in salsa uclibc, (o meglio ancora digestlibc, non ho ancora provato), in modo da ridurre sia fisicamente lo spazzio occupato dai binari, sia l’occupazione di ram quando e’ in eseguzione
questo risolve il problema dell’avere SOLO 128Mb di ram, che sarebbe grave saturare per finire a swappare su una flash, su una compact flash (che non possono permettersi di sprecare cicli di riscrittura perche’ questi sono molto + limitati di quelli di un disco fisso), o peggio ancora su un microdrive (lento per definizione)
ecco, qui non ci siamo davvero !
tanto e’ vero che e’ stata creata la direttiva kdrive di x11: cio’ comprende un set di flag che attivano e disattivano features specifiche in modo che x11 risulti compilato nel suo profilo + essenziale
il risultato, unito all’uso delle uclibc, consiste di qualcosa di appena soddisfaciente …
di fatto e’ la soluzione adottata di recente, anche se … brutto a dirsi sono in corso dei fixup a terribili bug che da almeno 2-3 mesi stanno minando l’usabilita’.
Questo fa capire la natura estremamente pionieristica di questo approccio … approccio che riduce il bacino di utenza e la pazienza di un coder.
Nel corso del tempo sono state presentate soluzioni eretiche, soluzioni come QT … beh, ai tempi di iPaq facevano la loro brava figura, ma allora anche nanoWindows … erano altri tempi, c’erano altri kernel (2.4) e le applicazioni finali non erano troppo lontande da quelle di una ridottissima “aggendina tascabile su PDA”
Oggi vogliamo ben altro … ecco, linux-gnu non e’ pronto, non e’ maturo, e comporta troppi gravi compromessi
Infine, data la natura multimediale di openPandora Linux inizia ad non essere nemmeno + il kernel giusto
Per questi e per altri motivi, il kernel e il rootfs che meglio dovrebbero sposarsi su questo tipo di piattaforme e’ ….
… Haiku OS (http://www.haiku-os.it/)
basato su un kernel a grana fine (newOS, riscrittura open delle spoglie del kernel di BeOS, della defunta Be), orientato e concepito espressamente per il multimedia, e un rootfs pulito, moderno, scritto in C++, appositamente per trarre vantaggio da quel particolare tipo di kernel
purtroppo si sta lavorando sul porting intel x86, restano ancora acerbi i porting per ppc e per arm, ma davvero se dobbiamo credere ed investire su oggetti come openPandora, allora dovremmo prima credere ed investire su haiku perche’ Linux-gnu davvero non e’ adatto e comporta tutta una serie di scelte di compromesso con relativo spreco di tempo e risorse
il vero problema dunque e’: openPandora probabilmente verra’ sviluppata per linux confezionando un rootfs “castrato” per mame e suoi relativi cloni, ecco, nel caso con un cortex A8 o A9 sembrara’ di avere in mano un oggetto veloce e potente come una scheggia, ma aime’ deludera’ parecchio appena ci si spingera’ a riconfezionarlo come PDA
il che signigica strozzargli una buona fetta di utenti: chi vuole giocare, gioca con PSP, al limite installa corpi monociclo mame e di li gioca con ROM retrogaming … sicuramente non ha troppa voglia, curiosita’ a parte, di spendere altri quattrini per un oggetto su cui a parte il mame-gaming e qualche demo da aggendina, altro comporta il doversi sporcare le mani e scervellarsi all’inverosimile per ottenre cio’ che un qualsiasi PDA fa con molta meno fatica (questa e’ la logica degli utilizzatori)
se invece ci fosse Haiku openpandora sarebbe produttivo, e non solo mame gaming, just-out-of-the-box
questo, in soldoni quello che penso
Io, invece, ancora aspetto un rimpiazzo decente per il mio Zaurus.
Nel frattempo mi consolo con la PSP.
Comunque non vedo l’ora che sia completato il porting per ARM di AROS, perché muoio dalla voglia di vedere come gira sullo Zaurus.
sul mio akita ho ritagliato un 2.6.23 molto particolare, e ben mi guardo dalle rogne dei successivi, tutti instabili e con magagne gravi, lavori in corso fino al 2.6.30 .. che e’ “quasi-usabile” xke’ han riscritto e risolto molti guai, ma aime’ il suspend/resume falla da tutti i cantoni tanto che sta’ su grazie ad un workaround piuttosto imbarazzante (ovvero infischiarse se al resume i checksum falliscono, infischiarse di ogni sorta di segnalazione errore, tanto .. o si impanica, oppure malfunziona ma si fa sempre a tempo a lanciare lo shutdown -h now, questo in soldoni lo stato e la filosofia fino ad un fix “serio” e definitivo)
cmq, al alto rootfs, sul mio akita ho rinunciato completamente ad X11 e sue app: troppo pesenati, troppo rognose.
riassumendo: 2.6.23 levigato, rootfs rifatto su misura (eabi-softfloat, uclibc), a corredo un gcc-3.4.6/binutils 2.6.19 (non il ramo gcc-4, + lento nel compilare), e varie applicazioni da text console
quando serve qualcosa di “grafico”, si sfrutta il framebuffer brutale e diretto, come links2 -g fb, o come quanto sto sviluppando per leggiucchiarmi pdf su un “aggeggio” che giostra direttamente /dev/fb0
poi, volendo fare di akita anche un mp3 player, cosa golosa per via del touch screen, beh .. sto confezionando una GUI touchscreen direct-framebuffer che giostri il solito mpg123 sotto
e direi che per zaurus altro non si potrebbe fare
openpandora, invece, ha (e dovrebbe avere) molte + utili possibilita’ di impiego vista la + “ciccia” dotazione hw
Già. Comunque tu hai uno dei modelli top di gamma. :D
Io, invece, ho un ben più vecchio e limitato Collie, anche se per le funzionalità di PDA e per qualche giochino andrebbe più che bene.
Con un s.o. decente, ovviamente. ;)
ieri mi sono preso la briga di smontarlo per bene
per infilarci un driver i2c (sfruttando un bus USB proprio della CPU ma che in sharp hanno deciso di non implementare verso l’esterno)
avendo ritagliato tutto il rootfs in termini di textconsole e’ stato davvero un attimo aggiungere anche un paio di tools scritti appositamente in C (ancora grezzi, cioe’ senza scomodare le ncurese lib, forse prox tappa) per impiegare il nuovo bus i2c
oggi programmavo eeprom i2c senza dovermi portare dietro portatile, programmatore su usb e qualtaltro di ingombrante pesante e scomodo
ecco, questo ha di “buono” il kernel linux e il suo rootfs gnu: il kernel particolarmente e’ per certi versi grasso che cola (questo in soldoni il vero motivo di tanta “lentezza elefantica”, basti guardare la compatibilita’ forzata delle modalita’ di funzionamento delle MMU: codice astratto per far si che le istanzie siano le stesse su tutte le arch supportate: risultato 2 “pesanti” layer in +), e’ tenuto su con lo sputo (xke’ + codice = + tempo da dedicargli, ma anche + complicatezza, quindi di fatto meno persone in grado di seguirlo, ergo si spalamano veri fix up in molte + release, questo e’ proprio il caso del mio akita) e il rootfs e’ di quanto + ostico e disordinato si possa immaginare
certe volte, pero’ altre volte e’ possibile cavar fuori applicazioni utili spendendo poco tempo perche’, essendo linux-gnu l’OS unix + diffuso, vanta un bacino applicativo opensource maggiore di tutti gli altri OS che andrebbero invece adattati (e che nell’adattarli, io ricordo il bagno di sangue su BeOS, ma certe volte anche sui *BSD, spesso cio’ richiede lo stravolgere, e qualche volta anche parecchio, i sorgenti)
ah, sottointeso: lo stato del supporto kernel di openpandora e’ nettamente migliore di quello degli zaurus (o dell’ormai morente porgetto openmoko)
primo xke’ gli sviluppatori sono fortemente motivati dal dedicare il proprio tempo all’ultimo “state of art” in termini tecnologici (e quindi si capisce quanto i cortex A8, ma sopratutto l’A9 che uscira’ fra qualche mese, ingolosiscano e motivino i coders)
secondo xke’ dietro openpandora non c’e’ una compagnia che ha ormai dismesso la produzione, come sharp con zaurus, zaurus che ritaglia dietro di se sopravvivenza grazie agli appassionati, ma una piccola azienda che trae vantaggio (nonche’ piacere, tutto nacque da una scommessa) nel meglio supportare la propria piattaforma (di cui vende l’hw incamerando dei ritorni economici che motivano, in feedback, un megliore supporto in modo da incentivare l’acquisto di altro hw da parte di nuovi consumatori)
terzo xke’ con corte-A8/A9 anche le tool’s chain (gcc,binutils&C) sono maturate parecchio: si, il ramo 4.1.*, e per certi versi anche il 4.2.* era molto buggato (io me ne sono accorto su HPPA e potrei raccontare divertenti aneddoti), ma dal ramo 4.3.* le cose sono migliorate parecchio, sopratutto per gli ultimi ARM che puossono quindi far dissipare molto meno tempo per issues imputabili al compilatore (detto francamente compilare un kernel per il mio akita risulta molto sensibile al compilatore: risultati diversi in termini di “stabilita’”, esattamente come il 4.1.* su HPPA, il che e’ MOLTO grave!. Una pacchia, invece con dal 4.3.* in poi, con ottime ottimizzazioni dei binari … anche se siamo dovremo constatare come si comportera’ sul campo su A9). Essendo meno bagno di sangue richiede molto meno tempo regalando molte + soddisfazioni, quindi attrae nuovamente molti + utenti “smanettoni” si, ma disposti ad esserlo fino ad un certo punto (o meglio fino ad un certo “tempo a disposizione per imparare, provare, ecc”)