Mistral
Mistral(And Later Releases)
One area of nervousness is that a number of packages, available for
Maemo-1.1, are not ready for Maemo-2.0.
Link to Maemo-2 software catalog.
Here's a list of my current
packages. Self
means I'm using a version I compiled myself.
(Link to my package archive)
Deps
means the package itself has been found but it has non-found dependencies.
Yes2
means it was found on the second round of searching.
Avail | Package | Description |
---|---|---|
Self | bash | Complete Bourne shell (not busybox) |
Yes4 | evince | Gnu multiformat (PDF) reader |
Yes3 | gpe | Gnu Palmtop Environment (PDA software) |
Yes* | gnupg | Gnu Privacy Guard (now part of distro) |
No | iputils | Ping, etc. (use special busybox) |
Self | less | Like morebut better |
Yes2 | maemo_gaim | Instant messenger, works on MSN and others |
Yes2 | maemopad | Super-simple text editor |
Yes | oggplay | Plays Ogg Vorbis audio files |
Yes | openssh | Secure Shell (dropbear also available) |
Yes | openvpn | Virtual Private Network (with LZO compression which I need) |
Yes | osso-xterm | Xterm; may or may not include other goodies |
Yes | panelclock | Shows clock in applet area (BEWARE) |
Self | pine | Very good terminal based mail reader |
Yes | rsync | For copying data to-from another machine |
No | slocate | Locate files by name, with some security |
Self | sntp | Simple Network Time Protocol (clock sync) |
Yes | findutils-find-xargs | The former some-gnu-utils |
No | sylpheed | Mail reader with GUI, uses POP |
Yes | vim-tiny | VI editor [check back for updates] |
Yes | vncviewer | Interact with Windows or Linux screen |
Yes | wirelesstools | Wireless network: set up or scan interface |
These were not on Maemo-1.1 and I'm adding them. | ||
Yes | load-applet-run | CPU/Mem/Screenshot applet with Run command. |
Yes | fbreader-maemo2 | E-book reader, multi format |
Yes | free42 | Emulator for HP-42 calculator |
Mistral
Nomenclature of software image:
Mistral: SU-18_2006SE_1.2006.26-8_PR_MR0.
Scirocco: SU-18_2006SE_2.2006.39-14_PR_MR0.
Gregale: SU-18_2006SE_3.2006.49-2_PR_MR0.
Sciroccois that it is essentially a bugfix release of
Mistraland the comments on this page apply equally to it. I have not yet installed
Gregalebut the release notes say it is mainly a bugfix release also.
The kernel is now 2.6.16.
The default desktop theme is now orange, with a swirly background (compared
in Maemo-1.1 to the gray colors and angular background). The out of the
box
desktop apps are:
community environmentwith help writeups, contests, etc.
The task navigator (left side bar) items now are:
Other, which consists of:
The new task navigator menu is more useable than the old one, and also you can create folders and move objects among them as you like.
Trouble with the wireless network, can't get DHCP address. The reason was that I mistyped the WEP key. Twice. Hiss, boo.
Large botfly in ointment: osso-xterm_0.13.mh8_armel.deb is corrupt; appears to be truncated. 0.12 is for Maemo-1.1; won't work on Maemo-2.0. ssh_3.8p1-3osso4_armel.deb allegedly is an incompatible package. These problems were overcome later.
These packages were installed successfully from the links in the Maemo-2 package catalog: fbreader (and its dependency libenca0), findutils, free42, load-applet-run, oggplay, panelclock, rsync, vncviewer, wget, wireless-tools.
However, when I rebooted I could not launch any apps whatsoever. One of the above packages must have been poisonous. Suspicion falls on (in this order): load-applet-run, panelclock, vncviewer. I re-flashed and reloaded all the packages. Vncviewer was fine. Panelclock... killed it. Repeating, omitting panelclock but installing load-applet-run... works! Including running a command. On the other hand, a later trial of panelclock gave no trouble. Strange. Subsequently, Panelclock has not given any trouble.
Next step is to re-do my customizations. I decided that restoring the files from Maemo-1.1 probably would work, but there was enough chance that back-version stuff would mess up something, that I only restored a very few files, making most of the settings anew in the Control Panel. Here are some of the new features I discovered:
This turns out to be for defining accounts on external servers such as Google Talk or Jabber. Apparently only the XMPP protocol is supported, not IRC, but of course XMPP is batter :-) But the account setup module absolutely requires you to save a password, which is unacceptable in my security regime, and the provided chat client is unable to recover if the configured password is deliberately wrong. So this feature is not working out.
This defines settings for being available for
chat, and automatically going away
after an idle time.
There's a new tab for virtual memory.
With this, you can create a swap file on the MMC card.
Several people had postings about how to do that in Maemo-1.1,
but it looks like the developers have made it official. The overhead must
be horrendous, though, with the VFAT filesystem and the MMC card itself.
Creating the swap file was extremely slow, taking about 3.5 minutes for
64 Mbytes. I repeated the procedure doing it by hand, and using dd
(the Busybox version) to clear the file to zero took the whole 3.5 minutes.
However, the blame may not fall to Busybox; the speed of 3.2e5 bytes/sec
is comparable to other activities writing the memory card, which may be the
limiting factor. The real dd
on an Intel laptop, writing to
a real disc (ultra PATA 133 MHz), takes only 4.0 secs counting syncing the
blocks to the disc.
While some combinations of programs will definitely run you out of memory, and will be helped by the swap file, my nemesis is the Opera web browser, which dies intermittently on certain operations (suggesting memory starvation), but it still does so with the swap file.
Here you can select the theme (color scheme) for the desktop. I don't really like any of the new themes and would like to get back an old one from Maemo-1.1. Theme 1, the default orange, is the best; the others are just hideous. It is now possible to download themes. Theme 7 is closest to the one I like, but it has a bad interaction with some GUI elements so I think I'll stick with theme 1. Or (later) try to hack a theme. The background image is not part of the theme; it is settable separately in the page menu of the desktop (see Tools). But the various standard images seem to have the most harmonious colors with the same-numbered themes, and the angular background from Maemo-1.1 is available as image 4. I'm using my own otter picture as the background.
There's a hot new category here: ringtones, with three sample tones provided. This is for incoming VOIP calls.
There's a new category, Finger
.
Is it for telling your ITB under
what circumstances to display the Universal Friendship Gesture? I don't think
so; I'll have to dig to find out what this does. It turns out that if you
press your jelly-smeared finger over a text input area, making a contact area
much larger than the stylus would, then a full-screen keyboard suitable for
finger use will appear. It looks fairly useful. Activate by rocker
switch
refers to the center button on the arrow keys. I could have found
out all of this if I had used the search feature of the help viewer.
Wonder of wonders, the developers have been listening, and there's now
a Remove
function in Teach Handwriting
, so you can remove a
glyph that you entered incorrectly. I'll have to try handwriting recognition
again.
It has a listbox that can only select
Web
and, apparently, not do anything to it. It turns out that the
listbox is for picking which item appears in the top left corner of the task
navigator area, but out of the software I've installed, only that one
application is eligible. There is also a submenu titled Organize
for
changing the everything else
menu tree. But they don't tell you, if you
do this the machine needs to reboot when you close the dialog (or is this a
bug?)
The Clock utility now can act as an alarm clock: it can play a sound
(selectable) at a prespecified time, even if the ITB is in standby mode, i.e. the cover is closed. First a
dialog box appears. If you don't acknowledge it, it plays the sound
repeatedly, getting louder each time. There's also a snooze
choice
which shuts up the alarm but repeats it in 10 minutes (choosable, under Set
Snooze
). Sound 1 is an annoying jangly bell that's sure to wake you up.
Sound 2 is a marimba track that may be less annoying. Sound 3 is ocean sounds
with a seagull squawking in your ear.
However, the desktop clock display is no longer there by
default. Here's how to turn it back on: use the page menu for the desktop. Hit
Select Applets
and turn on the clock (and it will help to turn something
else off, to make room). It drops you into layout mode, meaning that you can
move the windows by dragging. But I wasn't able to change their size. When
finished arranging, go back to the page menu and hit Accept Layout
(or
cancel).
From the same desktop page menu you can hit Applet Settings
, which
lets you fill in a URL for the desktop web link, and edit the list of
quick contacts
. Under Tools
you can set the background image,
plus quick links to the Personalization (theme) and Screen Calibration
control panel programs.
Undocumented feature that I discovered: at the end of booting, the Nokia hands are always shown with their tinkly tune. Then if /usr/share/custom exists and contains custom.png (or custom.jpg) and custom.wav, that picture will be shown while the sound plays. Symlinks are OK. The Nokia files are /usr/share/icons/hicolor/scalable/hildon/qgn_indi_nokia_hands.jpg and /usr/share/sounds/ui-wake_up_tune.wav . Of course you can hack those files... Their names appear explicitly in /usr/bin/osso_startup_greeting and /usr/lib/systemui/libsystemuiplugin_splashscreen.so. The filenames, except the startup sound file, also appear in /etc/gconf/gconf.xml.defaults/schemas/system/systemui/splash/%gconf.xml (/etc/gconf/gconf.xml.defaults/system/systemui/splash/%gconf.xml makes reference to values in this file), and possibly these values override the hardwired ones.
A lot of personalization will have to wait until xterm and ssh are brought to life.
Notice: In Maemo-1.1 packges were installed with a prefix of /var/lib/install, and it was necessary to hack /etc/profile to include its subdirs on the path. In Maemo-2.0 the package software is installed in its normal location, so for example the ssh host keys will now be found in /etc/ssh (not /var/lib/install/etc).
Most developers produce standalone Debian packages, whose filenames will
have the format pkgname_version_armel.deb (where the version is something
like 0.5 or 2.6.8-2). But a really professional developer organization will
have a real Debian repository, and you can just do apt-get install
pkgname
, or use the Application Manager which will do this for you.
It will even identify and download prerequisites (e.g. libraries) of the
selected package.
Repository.maemo.org and maemo-hackers.org have set this up.
For some reason when I used the web browser to dig through the repositories
I was only able to find non-useable .deb packages,
leading to my problems installing xterm and ssh.
Later I used Scratchbox to build several of my favorite packages, and I created this Debian repository to hold them. The structure of the repository is described in the next section. I also downloaded and cached other repositorys' packages in a private repository on my home network, because I had a bad experience in Maemo-1.1 when I wiped out my root filesystem and the server for some key packages was off the net for a week.
Installing osso-xterm from the maemo-hackers.org repository: when you configure this repository (http://maemo-hackers.org/apt) in the Application Manager (follow the directions found at the above link) and then let the Application Manager do the download, the package goes in. And works! Alternatively, osso-xterm can be obtained from http://repository.maemo.org. You'll also need the prerequisites ncurses-base, libncurses5, libvte-common and libvte4. All of these are available from repository.maemo.org.
Installing maemo-gaim from the maemo-hackers.org repository: it has two missing dependencies: libgcrypt11 and libgpg-error0. These will have to be found. Duh, read the description on the site and they tell you which repository has these libraries: their own.
Repository: http://repository.maemo.org, distro mistral, component free: They have the old Maemopad, which I installed and tested. Works.
They also have OpenSSH. but you don't install it with the regular installer. Follow the instructions: start xterm. sudo gainroot; apt-get install ssh. Something magical will happen :-) This time it's much faster in making the host keys (which I'm going to overwrite with my own). The install process produced several error messages (can't find xargs) -- I believe because the path is screwy. I hope they aren't critical.
New procedure for setting up the ssh environment. You just created new host keys, and your other machines don't recognize them. You could remove the old public key from .ssh/known_hosts on your other machines, but let's assume you're going to be anally retentive and restore the old keys. The best move would be if you had saved the old keys (and /root/.ssh/authorized_keys) on the memory card (warning: because of the VFAT filesystem the files are readable by anyone), but if you didn't you'll have to retrieve them from your backup server. Here's an efficient way to do it. This is all executing on the ITB; for these examples the backup root on my server is fafnir:/home/backup/selen. Remember that you're not <jimc> on the ITB; you're <user> which has no account on the remote machine.
rsync --rsh=ssh -a jimc@fafnir:/home/backup/selen/home/jimc/.ssh $HOME (Confirm adding remote key to known_hosts. Give remote password.) cd $HOME eval `ssh-agent` ssh-add .ssh/id_rsa #Give names of secret key files. Give passphrase.) echo $SSH_AUTH_SOCK (it prints something like /tmp/ssh-OPSly3755/agent.3755) sudo gainroot export SSH_AUTH_SOCK=/tmp/ssh-whatever
The most important config files in /etc have now been restored, plus some of jimc's personal data.
Documentation links:
This is a brief summary of material from those documents, illustrating what jimc did to set up his repository.
For the optimum experience the client needs on the package installer's
keyring, /etc/apt/trusted.gpg, the PGP public key of each repository that it is
going to use. Without the key apt-get update
produces a warning
message; the Application Installer just swallows the unverifiable information
without comment. So the steps with the PGP key are optional but recommended.
Maemo provides key C6903E72 which apparently covers both Tableteer and
repository.maemo.org. Given the keyID of the archive maintainer, the client
can retrieve the key with this command line (substitute the archive's keyID):
Alternatively you may post the key on your web site and the client can download and import it as a file.gpg --keyring /etc/apt/trusted.gpg --keyserver hkp://wwwkeys.pgp.net \ --recv-keys 0xC6903E72
In a normal Debian installation, including Maemo-2.0, the client has a file /etc/apt/sources.list which has a list of all the repositories that the client believes in, most preferred first. You may hand-edit this file, or in the Application Manager, page menu, tools, application catalog, it gives you a form to change lines in this file. There are two format variants for the lines; the first is for a full-featured repository and the second is for one that has just one directory; mind the ending slash.
The first one translates into the URL http://host.fqdn/directory/dists/distro/section. There can be multiple sections on one line. If you changedeb http://host.fqdn/directory distro section section.... deb http://host.fqdn/directory subdir/
debto
deb-srcyou can refer to source packages (useful on Scratchbox but not on the ITB itself). The Maemo Application Manager pre-fills a section of
user, which you may need to change. For protocols you can use http, ftp, file or ssh (it runs a shell on the remote host, finds the desired file, then does
dd if=$fileto stdout). Blank lines and comment lines, starting with
#, are ignored.
The Debian package manager caches locally the list of available packages at
each repository. If the repository content changes, or if you add a new one,
you need to do apt-get update
. At appropriate times the Application
Manager will offer to update the package catalog (by execing this command);
it's also available from the page menu, Tools, Refresh List of Packages.
To install packages you do apt-get install packagenames
(you can
specify several packages). It will automatically identify prerequisite
packages and install those too. The Application Manager can show you a list of
available packages and you can just click to download and install one; however,
apt-get lists all the packages and their total size, whereas the Application
Manager hides this output. (I've noticed cases where known dependencies
were ignored without comment, specifically with NTP; I don't know why.)
It's optional but recommended to make the archive maintainer's PGP public key available to clients. First you need to create (or already have) a PGP key, for which see the man page of gpg or the HOWTO linked above. You need to post your key to the public keyservers, and also extract a local copy for your web page. Use these command lines (substitute your own keyID):
gpg --list-keys /home/jimc/.gnupg/pubring.gpg ----------------------------- pub 1024D/9BDF9274 2003-07-13 uid James F. Carter <jimc@math.ucla.edu> etc... gpg --keyserver wwwkeys.pgp.net --send-keys 0x9BDF9274 gpg -o /tmp/mysig.gpg -a --export 0x9BDF9274
Now, onward to the directory structure, which should be accessible from your
web home page. In our case there will be only one distro, mistral
, and
one architecture, armel
, but potentially there could be several of each.
In the repository root (what http://host.fqdn/directory points to) you need a
subdirectory called dists
, in that a subdirectory named after the
distro, within that a subdirectory for each section, and within that a
subdirectory for each architecture called binary-armel
in our case.
Normally there is also an architecture
of source
.
Within the distro directory you also need a PGP-signed file called Release, similar to this sample, containing checksums of the Package files. This sample was stolen from repository.maemo.org and modified.
Origin: Fafnir Label: Maemo Suite: stable Version: 2.0 Codename: mistral Architectures: armel Components: user cache Description: Local cache of Maemo-2.0 Mistral Date: Sat Aug 5 14:27:05 PDT 2006 MD5Sum: bc0b8932e09018c8c92ae6684d21ea28 10662 user/binary-armel/Packages dd14c92c831e854d3364d134446e4885 3314 user/binary-armel/Packages.gz SHA1: 88dcc35cb62449874169429450433a254218621a 10662 user/binary-armel/Packages df55776e3508bf3a8ef577295697c8bb1e16518b 3314 user/binary-armel/Packages.gz
In the checksums the second field is the size of the file in bytes, followed by the path name relative to the Release file. You also need Release.gpg, which is a detached signature of Release, produced by this command line (substitute your own loginID or key ID in -u):
gpg -a -o Release.gpg -u jimc --detach-sign Release
The PGP signing works like this: the checksum of Release in the signature proves that the archive maintainer himself created and signed the file and that it hasn't been fraudulently altered afterward. The checksums in Release prove that the various Packages files haven't been altered. The checksums in Packages prove that the various packages themselves haven't been altered. In particular, if the maintainer posts an updated or additional package, he must go through the whole checksum and signing procedure again. Jimc's script for doing this is provided below.
Within the architecture directory you need Packages.gz or Sources.gz, and also the same files uncompressed (I haven't figured out why, but you do need both for the package checksum to be recognized). Below I give the procedure to generate them, and a script. The Repository Howto recommends putting in a Release file also (optional). The Howto doesn't discuss checksums and I'm not sure if checksums are expected here, because they're in the Packages file; I haven't put them in. Release is plain text looking like this (from repository.maemo.org, modify for your own organization):
Archive: mistral Component: free Origin: Nokia Label: mistral Architecture: armel
Archiveis a synonym for the distro as appearing in /etc/apt/sources.list;
Componentis a synonym for the section;
Originis a brief text description of where the packages came from;
Labelis a text description of what the collection
is.
The packages themselves should not be directly in the binary-armel
directory, but rather in subdirectories whose names suggest their function.
In the Application Manager's Install New Packages
dialog there is
a list of categories named after these subdirectories (case sensitive),
and packages in the binary-armel directory itself are not shown anywhere.
Try to use category names that other people are using. Here's my translation
of the categories in the Maemo catalog:
GUI-Network | Hildon GUI apps whose main purpose is to interact with another computer |
Network | Command line network tools |
Multimedia | Audio and video players |
Accessories | PDA things and other items with a proper Hildon GUI |
Statusbar | Little programs that display in the status bar |
Games | Games |
Themes | Installable themes (color and shape schemes) for the Hildon desktop |
Commandline | Conventional UNIX programs running in an xterm (excluding networking) |
Programming | Interpreters for scripting languages; compilers :-) |
Libraries | Libraries, generally prerequisites for other packages |
Here is how to create the Packages.gz file. The man page for
dpkg-scanpackages may be found at this
URL, among others. cd
to the archive root, i.e. the one for which
dists
is a subdirectory. Let $bindir be the relative path of the
architecture directory, and let $pkgdir be the relative path where the packages
will be found. (In a simple archive these will be the same, but in a complex
archive with multiple architectures it makes sense to use a pool
directory to hold the packages.) Packages will also be found in subdirectories
of the pkgdir, if any. Now execute this command (shown first with symbolic
directories and then repeated with the values they would have on my system):
dpkg-scanpackages $pkgdir /dev/null | gzip -9c > $bindir/Packages.gz dpkg-scanpackages dists/mistral/user/binary-armel /dev/null | \ gzip -9c > dists/mistral/user/binary-armel/Packages.gz
(-9 = most aggressive compression, -c = results to stdout. Ignore the complaint that all the packages were missing from the override file /dev/null.)
This is fine for an archive to be used with apt-get, but it's a little more complicated if you want to play nice with the Application Installer. I've written this script to create an override file matching the packages' directory structure, create the Packages file(s), create the Release file, and sign it with GPG (password required).
Flash. Do initial setup.
How to load osso-xterm:
Dependencies of osso-xterm are:
Off the web page: Prerequisite packages are missing. Load prereq packages from the cache off the web page: can't install, incompatible package. Load prereq packages from repository.maemo.org off the web page: same message.
Using the Application Manager I added Fafnir and repository.maemo.org to the source list. I was able to install ntpdate (showing that GPG issues were not getting in the way, alghough my GPG key was not present and this was noted in the log file). However, I was not able to install osso-xterm off the cache because it didn't appear on the list.
When both Fafnir and Maemo were enabled (Fafnir first), osso-xterm was not on the list. But when Fafnir was disabled, the instance on Maemo appeared. So what's the difference? Comparing the entries for osso-xterm and its prereq libncurses5 in the Packages file, the ones on Fafnir and Maemo differ only in the Filename (of course), the Priority (required on Maemo, extra on Fafnir), and the Section.
So I used the Application Manager and downloaded osso-xterm from repository.maemo.org.
Later I *was* able to do apt-get install osso-xterm
(after
de-installing it plus its two prereq libraries, libvte4 and libncurses),
using only my cache. Very mysterious.
I tried a squeaky clean GPG setup. First, gpg --recv-keys
doesn't work because gpg exudes no remote program execution
supported
-- probably a compile-time option that was turned off.
Alternatively I downloaded my key and used gpg --import. When I do
apt-get update
(and this also happened before importing my key) I
get a warning message: W: GPG error:
http://catalogue.tableteer.nokia.com mistral Release: The following
signatures were invalid: BADSIG CBFC2BECC6903E72 Nokia Internet Tablet
Archive Automatic Signing Key <integration@maemo.org>
.
Anyway, Application Manager can see my user packages but not my cache
packages, with any combination of: on separate source lines; either order;
with only the cache line uncommented. Hiss, boo.
Given that the cache has all needed prerequisites, the stuff goes right in. Two programs ask what menu section the shortcut should be installed in, but other than that there's no user interaction. You do end up with 7.9 Mb of packages in /var/cache/apt/archives, which should be removed afterward.apt-get install \ pine \ ntpdate \ etc. etc.
be myselfissue. I discovered that in af-base-apps, the desktop failed to open /tmp/session_bus_address.jimc . *.user exists; it's a plain file that says
export DBUS_SESSION_BUS_ADDRESS=unix:path=/tmp/session_bus_socketwhich exists and is a socket with mode 777. af-startup may have a similar problem but says only
/etc/osso-af-init/real-af-startup: Error, the D-BUS session bus did not start. I'll create a script S13pickuser that writes a loginID into /tmp/pickuser, and the above scripts will use it. I hacked af-base-apps and af-startup to do
su - $user $SCRIPT; maemo-launcher also sets UID to $USER and this was hacked. /etc/osso-cud-scripts/rss-reader-cud.sh also chowns some stuff to
user, but if the numeric UID is the same I can leave off hacking that script. Well, here goes nothing... Oops, it self-healed too effectively. Modified self-healing script to self-heal on the 3rd reboot, only if a file in /root exists. Also modified /etc/init.d/rc to log all startups to /media/mmc1/rc.log (appending).
Unable to open storage location. The web browser gets this too.
storage locationthat it can't open. OK, I put back the original ~/.osso, rebooted, and reselected theme 1 from the desktop page menu. The machine looks decent again; xterm still has its hyphen; certman still is horked.
Perodical Temporary File Purging Daemon. This is a crock -- this should be run by cron. Similarly, the osso-alarm, which handles the alarm clock, should be done by atd. And gpe-calendar has a function (that doesn't work) to
play sound before event, which also should be handled by atd.
This needs to be on the path. [Done]
When I hack and there's a problem, frequently
the symptom is that the machine will just not boot. There's no serial console.
A partial solution may be to start an xterm at boot time, so at least I
can investigate. For security it would run as <user>, not that
sudo gainroot
is effective at keeping the black hats out of the machine.
[Not pursued; the watchdog timer will kill it in 30 secs.]
Set up the failing being myself
configuration, then systematically go through boot scripts.
[Done, success!]
Make a second version of the backup-selen
script to write the backup data on the MMC, in a compressed tar file so
mode and ownership can be preserved. And I should write a script that
restores this data automatically -- either from MMC or across the net.
Internet Callmenu choice does. I think this links to Google Talk.
It becomes obvious that the keyboard layout is not hardwired in the application; some gconf.xml file affects it, because it changed (on osso-xterm) when I restored everything in my homedir. Project: find it and hack. Comparing a pristine and affected image did not reveal the secret... See the en_GK writeup for the result.
(See also the main wish list.)
Please make it possible to set up the ITB with the owner's normal loginID rather than <user>. In fact, if the ITB is shared by several people it will be important to have multiple user accounts.
Some applications, specifically the provided e-mail client (Sylpheed), have undesireable fonts; that one is too big. In a normal UNIX system the user can override the system defaults by specifying his preferred font face and size (among other things) in the ~/.Xresources file. A generic font can be set, and it can be overridden with different fonts for special applications, or for particular windows in an application. At login he loads this information into the X-server, from which all the applications can retrieve it. This behavior should be used standardly, but I don't see the xrdb program that would load the settings. As a distant second choice, there should be an ad-hoc global mechanism to set the default font. All applications should be very strict about honoring the user's choice, using this font for all body text, and using relative variants (e.g. bold, or 10% larger) for special cases like titles. But if you're going to have X-Windows on the machine you should use its features.
I don't have anything against Sylpheed, except for the font size and the password issue. While some people permit computers to remember their passwords, an important subset can't tolerate that, and as an intermediate strategy the reader should keep the IMAP connnection open all the time, or for POP it should keep the password in memory and re-use it. Also for mail sending, it's very frequent for the same password to be needed, and needed for each message.
I was hoping that a DSP codec for Ogg Vorbis would materialize, but it didn't.