Newsgroup: it.comp.hardware.palmari
Titolo: Treo 650: recensione online:-)

Come da oggetto: ho questo smartphone tra le mani da qualche giorno (non so 
se 4, 5 o 3, ma che importa?;). L'impressione generale è che si tratti di un 
bel pezzo d'hardware. Il software, che volete, è PalmOs... bisogna 
accontentarsi:-)
Scherzi a parte: ne sono davvero soddisfatto (ma "sospendo" il giudizio 
definitivo).
Abbiate pietà di eventuali refusi o incongruenze: ho fatto tutto in 
pochissimo tempo, rubato al lavoro. Presto la integrerò con una seconda 
parte, più approfondita.
Eccola: 
http://makeashorterlink.com/?P2FC34E9A
Ciao, Gianni.
P.s. Chiedete, se servono informazioni. 

> P.s. Chiedete, se servono informazioni.
Che applicazioni (oltre le standard + parte telefono) ci sono in ROM
(Blazzer?)?
--
Andrea Zanellato
andyegiorgy(at)
libero.it
http://www.3wstyle.net
--> Spazio *infinito* nel web *GRATIS*? 
http://www.3wstyle.net/upload

 > P.s. Chiedete, se servono informazioni.
Qualcuno ha detto che telefonare mentre è in ricarica non è agevole. E' 
vero?
Grazie
Stefano
-- 
Stefano Zenni
www.sidma.it

 vero?
Non mi è capitato di usarlo sotto carica. Oggi provo e te lo dico.
Ciao, Gianni. 

 vero?
Nessuna difficoltà. Tral'altro il cavetto dell'alimentatore sembra restare 
fortemente ancorato al telefono. Se avevi letto di qualcosa in particolare, 
dimmi che verifico.
Ciao, Gianni. 

 (Blazzer?)?
Blazer (4.0), Versamail, RealPlayer.
Ciao, Gianni. 

 Ciao, Gianni.
Certo che 21MB son pochini.
E anche la storia della NVFS è un pò na stronzata. Cioè l'applicazione viene
eseguita in 10mb di *vera* RAM. Superato il limite ti da "Memory full". Ora,
per applicazioni tipo Mapsonic che possono richiedere anche 14MB di RAM per
la velocizzazione dei calcoli itinerario su grandi mappe, il Treo650 si
troverà svantaggiato nei calcoli/ricalcoli.
Infatti c'è scritto che si stanno già adoperando per far in modo che i
produttori di software di 3° parti utilizzino l'NVFS alla vecchia maniera
Palm (RAM condivisa tra esecuzione/storage).
Poi che sia utile per i Backup va bene. Ma potevano già pensarci al problema
del "tetto di ram".


Senza contare che tutti i database vanno a pesare un sacco di piů. Es: 127KB
di contatti su RAM *normale* alla Palm diventano 500KB su NVFS (grandezza
dei record aumentata di brutto).


del "tetto di ram".
sara' utile per non perdere dati in caso che le batterie si scaricano, ma
per il resto non mi convince per niente.
Saluti.
  Paolo

 del "tetto di ram".
Sospendo... se il tempo me lo permetterà, testerò applicativi pesanti. 
Vediamo.
Ciao, Gianni. 

 il T5...
Enorme passo indietro. E quello delle grandezze dei record? Cioč 252kb di
PIM diventano 950kb con la nuova memoria.
Avremo anche guadagnato in sicurezza (cmq Palm č sempre stato molto
affidabile) ma abbiamo perso su tutto il resto.


PIM diventano 950kb con la nuova memoria.
e dipende sempre dal fatto che tale memoria non volatile di tipo flash
(tipo quella delle chiavette USB credo: NAND flash) richiede l'uso di un FS
per gestirla, e il FS introduce il concetto di cluster, ogni file
memorizzato ha un'occupazione minima, 512 bytes nel nostro caso, e questo
specialmente se si devono memorizzare record di pochi bytes comporta uno
spreco notevole di spazio.
Saluti.
  Paolo

 spreco notevole di spazio.
Infatti. Anche se il record ha solo, per dire, nome e cognome son 512.
IMHO meglio come prima.


 dei record aumentata di brutto).
Attenzione che questo non č un calcolo vero in assoluto, č piů una cosa
legata al numero di records del db.

 ha scritto nel 
messaggio news:396abvF...@individual.net...

Quel calcolo e' realistico, e si riferisce (basta fare due conti molto 
semplici) ad una condizione leggermente pessimistica, ovvero nella realta' 
c'e' da aspettarsi che da 127KB si possa arrivare a qualcosa in meno di quei 
valori indicati. Ma e' inevitabile, un file system ha i cluster e gli spazi 
di allocazione predefiniti, anche ai tempi della FAT16 sotto DOS si gridava 
allo scandalo con le partizioni da 512MB e cluster da 32KB che facevano 
perdere un sacco di spazio se i dati erano frammentati in molti files 
piccoli. A mio avviso era un passaggio inevitabile per Palm OS, e non ci 
vedo molti svantaggi, soprattutto se i devices avranno piu' RAM (minimo 64 
MB interni direi).
Gianvincenzo 

 del "tetto di ram".
Infatti questo modo "a cavolo" in cui la cosa è stata implementata *non è*
una nuova caratteristica di Palm OS Garnet come qualcuno ha erroneamente
detto. E' una modifica strutturale della sola versione di Garnet rilasciata
da palm0ne ed installata su T5, Treo 650 ed eventuali prossimi dispositivi
Garnet. Il File system integrato di default nell'OS da PalmSource lo avremo
con Cobalt e trovo lecito ritenere che, nel momento in cui l'architettura
dovesse presentare il rischio di incontrare i medesimi problemi, PalmSource
avrà già risolto preventivamente la cosa probabilmente con delle release
apposite dei tools di sviluppo ufficialmente supportati.

 Quel calcolo e' realistico,
Quel singolo calcolo può essere realistico ma può anche essere del tutto
fuori misura in meglio o peggio, lo sai. Dipende dal numero di records della
banca dati in primis, e dalla dimensione di ogni record *se* supera i 512
bytes. E' vero che è inevitabile (non ho vissuto a contatto con
l'informatica i tempi che citi e dunque non ne ho memoria, ma ci arrivo),
visto che ogni record pesa nominalmente 512b, però palm0ne questa cosa l'ha
fatta in modo un pò dilettantesco e senza avvertire la developer's
community. Condivido anche che la cosa possa diventare un vantaggio da un
certo punto di vista, ma sarebbero dovuti intervenire prima almeno sui
produttori di tools di sviluppo.

 
 wrote:

Grazie della risposta. No, l'avevo letto in qualche post, un ricordo 
volatile e, a questo punto, forse impreciso.
Grazie ancora


 produttori di tools di sviluppo.
Non sono completamente d'accordo e ti spiego il motivo: non credo che 
pa1m0ne l'abbia fatto in modo dilettantesco, e' vero che ci sono problemi 
legati ad alcuni bug (
http://www.bitsnbolts.com/tungsten_t5.html
) anzi 
sinceramente non vedo proprio alcun problema, secondo me hanno fatto bene e 
la cosa *finalmente* ha creato devices in cui -come primo effetto immediato 
per l'end user- se non li carichi trovi tutto come prima, dal T5 in poi. 
Come altro potevano fare, creare un filesystem con unita' di allocazione 
pari ad un byte? Non e' possibile... Mi pare abbiano operato la scelta 
giusta.
Certo potevano usare un po' piu' di memoria per il Treo 650, diciamo 64 NVFS 
+ 16 RAM ed eravamo a posto in tutto e per tutto.
Gianvincenzo 

 con Cobalt
Chiedo scusa se puntualizzo, ma da quanto scritto sopra non si capisce (o 
sono io che non capisco), sembra che Garnet sul T5, Treo 650 eccetera non 
abbia filesystem - invece ce l'ha. Forse e' solo il gioco di parole poco 
chiaro, probabilmente indendi dire che altri OEM non hanno integrato con 5.x 
nessun filesystem e qui siamo concordi, mentre da Cobalt in poi ci sara' 
integrato per tutti visto che PalmSource (e le varie developer's conference 
lo hanno ripetuto da un bel po') fornisce l'os con suo filesystem.
Rileggendo quanto ho scritto io mi pare ancora meno chiaro di quanto hai 
scritto tu, vabbe'
Gianvincenzo 

 con Cobalt
Ma non era stato annunciata la sostituzione di Cobalt con Linux ? Sono 
ritornati indietro ?
-- 
Saluti. 

 scritto tu, vabbe'
:)

 ritornati indietro ?
No, ma allo stato attuale ci sono dei progetti in essere su Dialtone (aka
Cobalt 6.1) che, iniziati prima dell'annuncio Palm OS for Linux, verranno
portati avanti fino a lanciare dei devices.
Palm OS for Linux, che sarà formalmente presentato alla base sviluppatori e
licenziatari a Maggio, dovrebbe essere spedito ai licenziatari da
Ottobre/Novembre. E Palm OS for Linux sarà comunque nell'overlay molto
simile se non identico all'attuale Dialtone (forse aggiungeranno le
modifiche di UI e le features aggiuntive che erano previste in Corsica -
Cobalt 6.2) con la differenza che, invece di girare su di un microkernel
proprietario, girerà su Linux (e intendo gran parte delle distribuzioni,
visto che sembra utilizzerà le API standard di Linux a prescindere dal fatto
che PalmSource rilascerà anche una propria distribuzione ottimizzata).

 + 16 RAM ed eravamo a posto in tutto e per tutto.
Capisco il tuo punto di vista, ma il problema a cui mi riferisco č legato al
fatto che i developers che sviluppavano applicazioni su db con molti records
si sono trovati a non poter salire sui nuovi dispositivi. Avrebbero potuto
risolvere la cosa sě con una RAM maggiorata (e magari anche una cache), ma
anche preallertando i developers di modo da:
a) ottimizzare i database a blocchi, soluzione su cui oggi si stanno auto
organizzano.
b) passare ad un'architettura che faccia streaming e parsing del contenuto
letto dalla SD.
c) far gestire il problema a chi sviluppa i tools.

 che PalmSource rilascerà anche una propria distribuzione ottimizzata).
Mi chiedo che senso abbia tutto questo !
Vuol dire mettere sul mercato macchine morte prima di nascere (parlo di 
quelle con Cobalt 6.xx)  perchè, prevedibilmente, il supporto sw sarà breve 
ed effimero se il futuro sarà su Linux.
Questo perchè le differenze di architettura tra i due s.o. non sono proprio 
banali e, sopratutto, chiede agli sviluppatori di investire sul nulla.
Sarebbe bene che Palm faccia chiarezza prima di destabilizzare gli utenti e 
gli sviluppatori con sistemi operativi e macchine che si "bruciano" 
nell'arco di pochissimo tempo.
-- 
Saluti. 

 nell'arco di pochissimo tempo.
Le macchine non si bruciano, semplicemente dopo l'infornata delle prossime
ci sarà maggior possibilità da parte degli OEM di produrre macchine
Palm/Linux Powered che i mortali oggi si sognano... ;)

 Palm/Linux Powered che i mortali oggi si sognano... ;)
Si bruciano le macchine con Cobalt, a meno che non si possano upgradare a 
Palm OS for Linux.
-- 
Saluti. 

 Palm OS for Linux.
E perchè? L'utente non se ne accorgerebbe nemmeno. A parità di hardware,
Cobalt su kernel proprietario e Cobalt for Linux offriranno le medesime
caratteristiche. Le differenze saranno sulla possibilità per i produttori di
sviluppare hardware più velocemente con periferiche e protocolli standard
del mondo informatico, già supportate da Linux.
Già mi sogno il mio subnotebook Palm Powered grande come un quaderno 8)

 developers e chi rilascia tools di sviluppo).
Perfetto, e' come dici e sono d'accordo...
Comunque Pa1m0ne in un certo senso "anticipando" la cosa ha aperto la strada 
a quello che sara' lo standard con Cobalt, e non e' male...
Gianvincenzo 

 P.s. Chiedete, se servono informazioni.

 a quello che sara' lo standard con Cobalt, e non e' male...
Vero anche quello che dici tu, però lo ha fatto mettendo oggettivamente in
difficoltà chi utilizzava applicazioni con db molto lunghi e relativi
developers. Anticipare la soluzione tecnologica è ok, ma anche le condizioni
per fruirne pienamente non sarebbe male che ci fossero.

Io ricevo molte mail e questa funzione mi sarebbe molto utile per non
il Treo 650 viene fornito con il client di posta Versamail 3.0: lo puoi
configurare in modo da ricevere solo l'header della mail, in modo da vedere
il mittente e la grandezza in KB, a quel punto puoi decidere se scaricare
la mail o buttarla.
Quindi a mio avviso l'sms non serve a niente, a meno che indendevi qualche
altra cosa.
Saluti.
  Paolo

 altra cosa.
ehm... l'sms ricevuto è gratis... non devi scaricare nulla, neanche 
l'header. Ti arriva, avvisandoti che hai una mail da tal mittente. E ti 
invita a scaricare il mex o ad ascoltarlo al 49001 (che però non funziona 
quasi mai... lol...).
Ciao, Gianni. 

quasi mai... lol...).
ah ecco... ma dobbiamo essere piu' precisi: questo e' un servizio del
gestore, TIM in questo caso, e non del Treo 650.
Saluti.
  Paolo

 sms che indica quanto pesa la mail e chi l'ha inviata.
Niet, mi spiace. Viene notificato solo il mittente.
Ciao, Gianni. 

 
Pure Io, speriamo.