[As of April 2006] I can't discover anywhere on Nokia's web site how to order a spare BP-5L battery, which I wanted to do, and neither could one of the customer service reps and a tech support person. Definitely you need to add to your sales program these items:
As of August 2006, I have the following comments about the Nokia web site.
Find Products/
All Phones, the 770 was not listed.
Accessories/
Browse Categories/
Power/
Batteries, the BP-5L was listed, but the
show compatible phoneslink did not show the 770.
buy itlink. See the battery section for a reference to an outside vendor with a 1300 mAh substitute, probably a lot cheaper than Nokia's price, and a warning about cheap 800 mAh imitations.
show compatible phonesare Javascript only, and could not be displayed.
The Nokia 770 team needs to monitor the web site frequently and make sure that the idiots maintaining it take all Nokia's products into account.
Today's bloatware demands more than 64 MB of RAM. (I remember when there was an addressing limit of 1 MB, of which 384 kB was reserved for BIOS, and you were really rich if you had over 256 kB of RAM installed.) You can't really squeeze the browser and a PDF (downloaded by that browser) in at once, nor the browser and a lot of complex Flash eye candy. All the reviewers mention that they crashed the system repeatedly until (or unless) they learned to avoid such issues.
Update: the N810 has 128 Mb of RAM. Also, I'm coming to believe that the resident set (the frequently and actively used memory) is a lot less than the total virtual memory commitment of each application. On the other hand, Mozilla (the web browser) uses a big memory cache which fairly regularly gets out of hand.
Many of the more interesting uses of the ITB require large memory, like 1 GB, and the provided 64 MB removeable memory card is kind of skimpy. Examples of large memory applications are music (0.6 MB/minute, replace your iPod), video (apparently 2 MB/minute, 250 MB for a whole DVD), and GPS navigation (ask Karoliina Salminen). Also the system is a lot more resilient if it has a swap file. [This has appeared in Maemo-2.0.]
The VFAT filesystem is really bad for large storage devices. The operating system should tolerate other filesystems, such as ext2. The ideal would be JFFS, but that would take some major hacking.
The Nokia 770 uses the BP-5L battery, which appears to be what's used on some of Nokia's high-end phones. Emphatically, don't change the battery; use one that is widespread in your product line, and don't go gratuitously changing the style, so suppliers can keep the batteries in stock.
Update: The N810 uses the different, physically incompatible BP-4L battery. Hiss, boo!
The provided power supply is good. But people with two batteries would like to charge one of them in an external charger while the other one is powering the ITB.
I really suspect that the sluggishness of PDF viewing is because floating point is emulated in software. Clearly Nokia is using hardware, specifically the OMAP-1710, for which they already have a volume purchasing agreement, until they can figure out how successful the product will be. And I suspect strongly that the OMAP-1710 lacks floating point. The next model should have a faster processor, with floating point, and more RAM. The OMAP-3430 (550 MHz) has it (and how much is TI going to charge for that monster?) I think the OMAP-2420 doesn't.
Notice that I'm not saying the machine is a slug
. It takes
slightly longer for the stripped-down Opera web browser on the ITB to start and display an easy page,
than for the full Opera to do the same on my laptop (Pentium-M 1.6 GHz).
[That was on Maemo-1.1; the Opera version on Maemo-2.0 is twice as fast
or more.]
That means that the processor is [probably] properly scaled for the software
it's running and for the storage device available. But there's this one
issue that really holds back an important class of applications, that needs
to be improved in the next model.
I would like to be able to transfer photos from a digital camera to the ITB. I've seen a camera that does Bluetooth, but they're rare, and most imitate USB storage devices as clients. It should be fairly easy to switch the USB mode by software. The big problem that I see is the cabling. You would need a gender changer, and the USB connector would have to supply a few milliamps on the power wires to let the camera know it was alive and was a host. In fact, if someone wanted to run his battery down (or use mains power), you ought to allow enough current to run a USB keyboard, a mouse, or a joystick.
Update: This wish has been granted on the N810, which has a USB-OTG micro-AB connector and that can act as both a device and a host.
A CompactFlash slot or possibly SDIO would allow people to add quite a variety of devices. Currently a CF card with 4 GB of flash is sold (for almost as much as the Nokia 770 :-). Bluetooth is useful for larger peripherals like GPS units.
Update: No CF slot on the N810, but it takes Mini-SD cards (the RS-MMC card from your 770 is unusable), and cards up to 8 Gb are available. Generally the vendors sell Micro-SD cards but include in the package adaptors for mini and standard sockets; this is what I'm using.
The cover of the 770 needs a cutout so the stylus can be inserted and removed when the ITB is in use -- but not when the cover is turned to cover the screen.
Depending on a person's mode of using the ITB, it may make sense to attach a security alembic (leash), or at least a wrist strap. Although an anchor point could possibly be glued onto the top rear of the case, the anchor point is a whole lot more secure and better looking if molded in as part of the device's original design. The Nokia 6126 cellphone has such an anchor point.
Recent Compaq (HP) iPaqs have a fingerprint reader. If reliable this would be a whole lot more convenient than the numeric lock code. Some business uses of a PDA necessarily involve sensitive information, and it's important to keep it out of enemy hands, enemies who steal your PDA.
If a casual thief re-flashes the filesystem image and BIOS, does this reset the BIOS pass number, resulting in a working ITB?
Next to the battery box is a hole revealing a group of nine vacant pads (seven on the N810): obviously for JTAG and/or a serial console. The bare metal hackers would love you if you would sell the connector that you use in the factory to contact these pads.
It would be really helpful to have a file analogous to /etc/SuSE-release that clearly and authoritatively states what version of the software is on the machine. Let's call it /etc/maemo-release. Perhaps /etc/osso_software_version and /etc/debian_version could be combined with this file; the data there is not very helpful. This issue is discussed futher here.
It's very important that the handwriting trainer should be able to remove user glyphs entered in error and to suppress factory glyphs that conflict with glyphs that the user wants to assign to a different letter. [Done in Maemo-2.0]
The glyph storage should be findable and should be included in backups. (Use the source, Luke!) While multi-user operation may be rare, philosophically the glyph storage should be individual per user, i.e. in /home/user/something.
It should be possible to find and back up all relevant data. When I horked my root filesystem I was able to restore most settings. The ones which I've noticed are missing so far are these:
Everything involved with user data or user preferences in applications, like bookmarks and glyphs, should be in the user's home directory; everything changeable that's involved with machine configuration, such as the display brightness and the WLAN connection list, should be in a well-defined directory. [In Maemo-2.0 it's /var/lib/gconf.]
For some uses of the ITB the user needs to be authenticated on his
company net, and it's a whole lot easier if he has his own loginID and UID,
also groups, rather than <user> 29999. However, this loginID and UID are
somehow imbedded in Maemo, and they shouldn't be. See here for my baleful experiences in
fixing
the loginID -- and a partial success in this area.
Also I can think of scenarios, both at work and in the family, where one ITB is shared by multiple people. Then you would want the full multi-user treatment with individual authentication plus (particularly at work) an area for shared content. Think of how Windows® XP Home does it -- or desktop Linux. It just takes thought and care in the system administration; code bloat is not required.
The VFAT filesystem on the memory card cannot do symlinks or UNIX-style ownership and access modes. I would very much like to like to put a different filesystem on. JFFS2 would be the ideal, but I did some research and that isn't going to fly. It looks like a specially tuned ext2 would be best. But then Maemo doesn't want to mount the memory card. Please make it do hotplug normally.
This wish has been granted in Maemo-2.0. Here's the original item for historical interest:
I have three WLANs that I use
regularly, and when I change location, e.g. home to work, I need to open up
the connection configuation dialog and select the preferred connection.
The list of connections should be ordered by user preference, and each
should have its own use without asking
switch. When connecting,
the connection manager should scan a few times to make sure it sees all
available beacons, then pick the most preferred one. If none are preconfigured
or if it's not allowed to use without asking, then it should just show the
list of what's available -- it should not claim to have gotten an error
connecting.
You can't hack what isn't there.
In this context, if the ITB isn't
running any inet daemons, those daemons can't be hacked. But it's inevitable
that it's going to be used for peer-to-peer connections, or other uses that
nobody has thought of yet. I would feel a whole lot more comfortable with a
complete firewall. I went to put my standard firewall on the ITB and was told (for the nat table),
Table does not exist (do you need to insmod?) Perhaps iptables or your
kernel needs to be upgraded.
The iptables utility has a complete set of
setting modules; I'd really like to see a complete set of runtime kernel
modules to go with them.
In some significant uses of the ITB the user has secret data on it, which needs to be on an encrypted filesystem. But the kernel lacks any crypto support, and the mount command (from busybox) cannot do a loopback mount, even unencrypted. Please add the following items:
The features requested here should be in kernel modules, not hard-wired, because many users will not use them at all, and no user will use every one.
The init filesystem is mounted on a subdirectory of /mnt. It should have its own directory, such as /initfs. /mnt is supposed to be available so the system administrator can temporarily mount arbitrary filesystems. Covering the module storage directory is an unfriendly act, making /mnt useless.
I notice the port of Python. I would have expected Glade to be used for a lot of user interfaces. I really look forward to the port of Perl, since all of my administrative scripts use it and I don't want to re-code everything in Python. Tcl/TK is out of favor these days, but I notice that it also has been ported and I'll be installing that soon. [Perl has appeared as part of the Maemo-2.0 distro.]
License issues for MP3 compression
are murky at best, and a squeaky clean Linux system cannot legally create
MP3 files. Ogg Vorbis is the Open Source alternative, and I haven't
investigated how much it's better or worse than MP3 (a complex question since
quality settings are significant), but in absolute terms it's good
.
Oggplay works, but it runs on the CPU, not the DSP. The Osso audio player
really needs a plugin for Ogg Vorbis with DSP decoding. See here for details, tests, and a reference to an existing DSP codec.
Update: My wish has been granted: the mogg
package for Maemo-2.0
and the ogg-support
package in 4.0. Follow the link
above for author credits.
Numerous people, myself included, would like to use Bluetooth headphones with the ITB , either the A2DP profile for music, or the HSP profile for telephony (including microphone). They would also like the AVRCP profile to control the media player, and/or the HFP profile to use the buttons on the headset to control call progress. Starting 2006-03-xx there is work in progress for A2DP but no result so far, and Maemo-3.0 for N800 does not include it natively.
Definitely you should include standard
PDA software in the
provided filesystem image, so potential buyers can say I'm getting a
PDA that can do all this
other stuff
, rather than I'm getting this cute geek toy and if I learn
to do some geekery I can download GPE for it
.
This wish has been granted in Maemo-2.0, except the provider is GizmoProject. Real Skype has appeared for Maemo-4.0 (N810). Here is the original request, for historical interest.
Nokia should grease the wheels for a port of the Skype VOIP software to Maemo. See here for a link to a post suggesting why the port is not happening. Skype is one of the leading reasons people give for buying a Nokia 770, until they find out there's no software. The recommendation for Skype is not to be interpreted as discouraging porting other VOIP software. But Skype's advantage is that for a very modest fee they will bridge your call to PSTN land lines or mobile phones. While I encourage do-it-yourself VOIP users to make such a bridge for themselves, I believe this capability is rare.
The OMAP-1710 includes a hardware random
number generator and an accelerator for SHA-1 and MD5. Are we using them? I
don't recognize any crypto engine library. How could I answer that question
without locating and examining the kernel config? (/proc/config.gz is not
present; maybe it should be; only 17 kB compressed.) dd if=/dev/random
of=/dev/null bs=1k count=10
takes 10 times longer on the
ITB than on my laptop (Pentium-M
1.6 GHz) which does not have hardware random numbers, so Maemo is not using
the random generator that's on the OMAP-1710 chip. It should.
I would really love a single device, like the Palm Treo 650 or the Nokia 7710, that was a cell phone, a PDA, and a real Internet device running Linux, i.e. a ITB. I'm sure you can figure out some way to make this happen and stay legal. Maybe a completely separate phone processor?