Maxwell now prints the circuit element values next to each element. I suppose this makes it somewhat more useful for demonstration purposes.
This is done using the WHATWG Canvas text API, which is newly supported in Firefox 3.1, thanks to Eric Butler. (Firefox 3.0 users will get the old behavior, where the element values are printed in the status area upon mouseover.)
Ubuntu Intrepid (8.10) users can get Firefox 3.1 alpha packages from Fabien Tassin's PPA.
Update: for instructions for Ubuntu Lucid/10.04 see this post.
Update: note, these instructions work for me on Ubuntu 8.10 Intrepid as well as 9.04 Jaunty and 9.10 Karmic on a Thinkpad X61s. Alternatively, the Karmic repos have gpointing-device-settings, a GUI tool for enabling trackpoint scrolling (as well as other special trackpoint/touchpad features).
Ubuntu GNU/Linux 8.10 (Intrepid) switches to evdev for X server input, which has the unfortunate side effect of breaking old EmulateWheel configurations. So scrolling using the middle button + TrackPoint (which I absolutely love) was broken for a while, although it is now fixed. Instead of modifying your xorg.conf, create a new file called /etc/hal/fdi/policy/mouse-wheel.fdi with the following contents:
<match key="info.product" string="TPPS/2 IBM TrackPoint"> <merge key="input.x11_options.EmulateWheel" type="string">true</merge> <merge key="input.x11_options.EmulateWheelButton" type="string">2</merge> <merge key="input.x11_options.XAxisMapping" type="string">6 7</merge> <merge key="input.x11_options.YAxisMapping" type="string">4 5</merge> <merge key="input.x11_options.ZAxisMapping" type="string">4 5</merge> <merge key="input.x11_options.Emulate3Buttons" type="string">true</merge> </match>
(Based on code from Michael Vogt and adapted to support both vertical and horizontal scrolling.)
Update: you'll have to restart hal and gdm, and remove the cache file /var/cache/hald/fdi-cache, for the changes to take effect. Log in on a VT (e.g. with Ctrl+Alt+F1) and then do:
sudo rm /var/cache/hald/fdi-cache
sudo /etc/init.d/hal restart
sudo /etc/init.d/gdm restart
(Be sure to log in on a console/VT, because restarting GDM will kill all your X apps...)
Note for Ubuntu 8.10 users only: an update to Ubuntu Intrepid (subsequent to my original post) breaks TrackPoint scrolling either completely or possibly only after suspending and resuming. A comment on Ubuntu bug 282387 gives instructions for downloading and installing a fixed version from upstream:
sudo apt-get install build-essential git-core
sudo apt-get build-dep xserver-xorg-input-evdev
git clone git://git.freedesktop.org/git/xorg/driver/xf86-input-evdev
cd xf86-input-evdev
git reset --hard 5f2c8a2dcdf98b39997ee5e7c9a9ace3b640bfa3
./autogen.sh --prefix=/usr
make
sudo make install
Later releases already have a fixed version of xserver-xorg-input-evdev.
Feedback/testing: I've tested the policy file and workaround above on an X61s. On 8.04/Intrepid, people have indicated that it seems to work on most or all R and T series Thinkpads as well as the X31, X40, X61, and X200. The X300 and X301 Thinkpads seem to have different TrackPoint hardware. On those machines you may need to disable the touchpad in the BIOS to make the above workaround work.
Thanks to all the commenters below who left additional tips for getting this to work and providing feedback on what hardware is supported!
Here's a workaround for fixing the one sound issue I've had with the Freerunner, namely that the people I'm calling complain that I'm too quiet. This is caused by a mixer setting which makes the mic volume on the Freerunner too low. My gratitude to the folks on the OM mailing lists who managed to piece this (very easy) solution together.
This kind of problem can be corrected just by running alsamixer while a call is in progress. Play around with the volume on the various channels until you are satisfied. In particular, raising the "Sidetone" volume seems to do the trick. This will fix the problem, at least for that call.
ASU keeps different sets of mixer settings for all sorts of scenarios (e.g. headset, handset, speakerphone, etc.). However, every time one of these scenarios is activated, ASU just loads the mixer settings from a file. If you change the settings in alsamixer, those changes never get written back to the file, so they aren't applied in the future.
To save those changes, adjust the settings to your satisfaction and then, during the call, to save your new mixer settings, do this:
alsactl -f /home/root/newsettings.state store
Use that to overwrite the file from which the mixer settings are read, which is /usr/share/openmoko/scenarios/gsmhandset.state (if you are curious, you can also play around with the other .state files in that directory).
For me, the net result of all this was the same as applying the following one-line patch to /usr/share/openmoko/scenarios/gsmhandset.state. You can try it too, if you dare:
--- old/gsmhandset.state Tue Sep 23 01:20:14 2008
+++ new/gsmhandset.state Mon Sep 22 00:16:28 2008
@@ -112,7 +112,7 @@
comment.range '0 - 7'
iface MIXER
name 'Mono Sidetone Playback Volume'
- value 2
+ value 6
}
control.13 {
comment.access 'read write'
Development is continuing at an incredible pace on the OpenMoko software. OM 2008.8 (the "ASU") was released in August and I installed it when I got back from my vacation. I also tried OM 2008.9 when was released last week. It looks like they are going to continue with updates monthly like this. This software is still rough around the edges but at this point the Freerunner is definitely usable as a primary phone now (while, I would argue, it was not with 2007.2).
To be honest, both of the 2008 series updates are very much "fix two bugs, introduce one bug". Nevertheless, the software is improving by leaps and bounds. The ASU software is a big improvement over the original GTK stack. Notably, it is much more finger-friendly, not requiring a stylus (or fingernails) for as many tasks.
Here are some of the most visible bugs that were fixed (hooray!):
To put the situation in perspective, here are, in my view, the most visible/annoying bugs that remain. None of these really block normal phone use.
One other bug I've had is an issue with sound quality (the volume being too low). I'll show you how I'm working around that in my next post.
Some interesting talks I heard recently:
Ron Rivest talked about the MD6 hash function, which is a candidate in the upcoming SHA-3 hash contest, sponsored by NIST. It is based on a tree structure instead of a chain structure so that it's parallelizable, is resistant against certain cut-and-paste attacks, and is provably resistant to differential attacks, which have been worrying people. Extensive computer simulations were used to verify that MD6 "scrambles" its inputs enough to put a lower bound on the complexity of this particular kind of attack which is higher than the birthday bound.
Kevin Knight gave a talk on machine translation without parallel texts. Which sounds, on the face of it, absurd. Except that translation can be thought of as just applying a secret code, and statistical methods for cracking codes (without having much/any parallel text, of course!) have been around for a long time. Nowadays, computers can solve the cryptogram you find in the newspaper, and some analagous problems, but we don't know a whole lot about stuff beyond that. This kind of research could be useful for helping to translate texts in specific domains (e.g. computer manuals), where lots of example text can be found but little parallel text is available. Methods trained on general corpora often do quite poorly in this kind of niche.
By the way, I love this comic by Kevin Knight.
I went to the Software Freedom Day 2008 event in Boston today. It was a good opportunity to learn about the fascinating things people are doing with free software (and free culture ideas in general), as well as to learn about some of the major threats to our freedom, and some things we can do about them. Thanks to everyone who was involved.
Some nifty things:
Now, for the bad news. The two most talked-about threats to free software were mobile phones and DRM. The big two software makers have done a good job of convincing people that they shouldn't care about freedom on phones because it's "just a phone". But if you think of all the things you can do on phones nowadays, you realize that you really don't want to surrender your autonomy there, regardless of what your phone maker claims. DRM is a little better. It has been somewhat widely discredited in a number of high-profile incidents now. Sadly, that doesn't keep people from trying it.
Advocating free software should be easy, right? (Ed.: apparently, no.) After all, the big proprietary software companies have made huge missteps lately. They just can't stop making their software more and more restrictive and obnoxious! Not to take pride in the misfortune of their customers, but I believe there is a good chance that in the short term future it will become increasingly clear to many "ordinary folks" that proprietary software is not just a theoretical hazard but a real liability. Multiply that danger by the pervasiveness of software in our everyday lives and business, an extent which probably even most technically-minded people fail to completely appreciate. So I believe that projects like Mako Hill's Revealing Errors are a critical link in helping people, especially non-technical people, understand the importance of free software.
Happy 25th birthday to GNU! Richard Stallman gave a lightning talk about the story of GNU, among other things. To hear it from the horse's mouth on this anniversary helped to put in perspective how far we have come in the last 25 years, and how far we still have to go. (Boy, do I feel odd personally identifying with a movement that is older than I am.) May the next 25 years be just as productive.
Emacs 22.3 was released on 5 September 2008.
You may know that Romain Francoise maintains a repository with emacs-snapshot packages for Debian updated weekly. Well, what about Ubuntu users? Since earlier this summer-ish, the ubuntu-elisp PPA has also been receiving emacs-snapshot packages regularly! Great news for those of us who always want to try out the features that the awesome hackers on emacs-devel are writing about.
I have a setup that I'm quite pleased with on my Ubuntu machines, so I recently installed Ubuntu to my XO-1, thinking that I would get more out of the machine than I have with Sugar/Fedora. I bought a 4GB SD card to use with the machine and followed these instructions, which call for installing to a disk image within Qemu and then copying that disk image to an SD card.
I installed an alpha of Ubuntu Intrepid Ibex 8.10 without any major hitches. It works. I'm using Openbox as my window manager, which keeps touchpad use to a minimum.
Some remarks on what hardware works out of the box, with Ubuntu Intrepid:
It's a little poky, but more than adequate for using Emacs, reading mail, and browsing the web.
I posted an article on reading your mail with VM in Emacs, which contains a minimal VM orientation, information about how I read mail in VM, and the elisp configuration I used to set that up.
I attempted the switch a couple of months back after realizing that the volume of email I was dealing with was seriously impairing my work ability. Gmail does have some tools for managing lots of email (labels), but with VM I can be much more fine-grained about what messages I look at at any particular time. Scanning and reading mail is also much faster, if only because I don't have to wait for the RTT to a Google server and the browser render time every time I want to do something.
And, of course, the best part of VM is that it comes with a great e-mail editor.
Why VM? The big choices are Gnus, VM, and MH-E. I had tried Gnus and couldn't really wrap my head around its model of doing things. MH-E sounded acceptable but I assumed that VM, which had more Lisp implementation, would probably be more flexible. I am pretty happy with VM, but I suspect that changing mail clients is really just a matter of performing a conversion process on the mail folder files. Some operations (such as writing an entire mailbox to disk) are probably slower than they could be, but in general it is blazing fast.
I also wrote about setting up BBDB (the Insidious Big Brother Database), an address book program which is strangely satisfying to use.
Read about my VM configuration and workflow.
Matlab's documentation for the logspace function:
>> help logspace
LOGSPACE Logarithmically spaced vector.
LOGSPACE(X1, X2) generates a row vector of 50 logarithmically
equally spaced points between decades 10^X1 and 10^X2. If X2
is pi, then the points are between 10^X1 and pi [instead].
This very odd specification is, of course, totally well-intentioned. The online documentation gives this rationale:
y = logspace(a,pi) generates the points between 10^a and pi, which is useful for digital signal processing where frequencies over this interval go around the unit circle.
Unfortunately, half the Matlab functions I read about seem to have these bizarre corner cases and caveats. I can't help but think that this is the numerical equivalent of Perl and the "penny wise, pound foolish" approach to language design: all these odd shortcuts make Matlab code (slightly) easier to write but harder to debug, read, and learn from.
I do like Gmail, but (1) it feels sluggish, (2) writing anything nontrivial in a browser text box is just too awkward, and (3) I occasionally wish I had a copy of my mail accessible offline. So I've been trying to switch over to retrieving and reading my mail in Emacs. After a failed experiment in using Gnus to read my mail last year, I recently mustered the energy to try VM.
It seems to be working well, and I'll write more about my configuration and workflow later, but I wanted to mention one package that I just found.
One of the (few) things I liked about Gnus was that it color-coded the blurbs in each message by author, which it inferred from the line prefixes (">", ">>", etc.), like so:
VM doesn't support such functionality out of the box, but the package u-vm-color.el mimics it. The package is fairly straightforward to install and works as advertised.
One thing I discovered that when you run a TTY Emacs it assumes that it is working with light text on a dark background. If you are running Emacs in an xterm with dark text on a light background, you'll need to supply the -rv (reverse video) option to Emacs. Otherwise, Emacs may choose unreadable, or at least, suboptimal, colors for all its faces.