Some numbers in the 503 area code require that you dial a 1 first. Most do not. You’re supposed to know that a given number lies outside of some imaginary geographic boundary around Portland. Apparently Qwest thinks we have telephonic geolocating chips embedded in our heads.

This shameful tactic was attempted years ago in Los Angeles where the population quickly rioted and a technical fix was just as quickly produced. My mobile phone dials all 503 area codes (in fact all area codes) without a 1 first and so should my landline. And I don’t want to hear about the difficulty of programming physical switches or the upgrade costs. This just shows a complete and utter disregard for the value of their customer’s time. VoIP here I come.

The Qwest managers responsible should have their phone service “enhanced” so that every time they dial someone a randomly generated number is required to make it go through. For the rest of their lives. If the managers guess wrong they will be informed of the correct number by a piercing three-tone bell and a garbled voice remarkably similar to the cassette tape-based system Qwest uses today to inform their customers when they blunder into the 1+503 landline landmine.

I call that power and simplicity.

I’ve been providing technical support for my Dad and in-laws’ desktop Linux machines for years now. Linux on the desktop is an excellent fit for them, but they all suffer from ACS.

Just yesterday I restored OpenOffice’s primary toolbars on my father’s machine. These toolbars are his primary interface to OpenOffice - they’re critical tools, and to him they just went missing one day. Of course he had accidentally dragged them off of the primary interface, but I found that this is surprisingly easy to do. Try it; start OpenOffice and aim just two pixels below File on the primary File - Edit - View interface. Hold down the left mouse button and drag down as you might expect to do if the File menu were to appear. Did you just pull the main toolbar off of the interface? I did. Now try and put the toolbar back without screwing things up. I wasn’t able to, and it took me a few minutes to get it back to “normal.” Should the default action of a click and drag be to remove the toolbar? No. Should a mistake in a common usage action (pulling down the FIle menu) cause a major configuration action? Of course not.

Another example — at my in-laws, the main application bar in Gnome seems (to them) to change in mysterious ways. Application launch icons move around, appear and disappear without any apparent reason. What’s happening is that instead of left clicking to start an application, they accidentally right-click and select move, or accidentally click and drag. Once the damage is done, there is no easy way for them to set it right, because they weren’t intentionally making the change - they literally don’t know what they’ve done. Similarly, their desktop is periodically littered with multiple launch icons for solitaire in a failed attempt to simply start the program, again, a right-click presented a configuration option and literally in the blink of an eye they accidentally make a configuration change. To them it appears as if the program simply didn’t start - they don’t notice the new icon on the desktop.

Configuration states should also not be activated by keystrokes - the chance for ACS here is just as great.

The fix for all of this is simple, and it has nothing to do with educating people using computers. This is a user interface problem. We need to build applications and operating systems that assume people will primarily be using them instead of configuring them, and require explicit, deliberate action from a person to enable any configuration changes. Use, not configuration, must be the default state.

On the left, today’s required nutrition label. On the right, a proposed label containing the energy used to create the product and how much it would add to your energy consumption footprint. Click the image for the full-size version on the Wattzon site. Someday this sort of labeling will be required on all products sold.

Quirks
There are three quirks that I’m aware of.

Things I tried that didn’t work
I’ve been trying on and off to synchronize my palm with various PIMs under Linux since 2001 with little success. Backing up through Kpilot or pilot-xfer has always worked fine, but getting real sync has been pretty much impossible until now. It may not be the holy grail, it is one of the last pieces to the perfect desktop puzzle.

Initially I tried to get OpenSync to work. I failed with the command line tool, with Kitchensync (best name for sync software evar) and with Multisync090. The KDE PIM/Google Calendar sync failed every time, and I never could get my palm to sync. While that project looks quite promising for now isn’t ready for prime time, as they fully acknowledge on their site.

With a bit of effort, GCALDaemon allowed me to sync between Kontact and Google Calendar, as well as Swiftdove and Google Calendar. And since I was able to sync my Palm with Kpilot (and therefore Kontact) I figured everything would be fine. Alas, that didn’t work - Kontact would display both calendars but would not pass the palm calendar to Google, and vice-versa. I was about to give up when I tried one last trick - I noticed that Kpilot allowed me to specify the ical file to link to, and that GCALDaemon uses a google.ics to sync up with Google Calendar.

So I told Kpilot to synchronize with the GCALDaemon ics file instead of the Kontact ics and played some tricks. And it worked - with a little coaxing!

Howto
Here’s a guide for getting the tricky parts working under Ubuntu 7.10 (Gutsy) 64 bit. I followed this page of the GCALDaemon guide, then this page through step 5 of the same guide to set up file sync. Now on this page of the Terminally Incoherent guide for Kontact, continue from where it says “Now open Kontact” and once you get to where you specify the filename, use /usr/local/sbin/GCALDaemon/google.ics instead of the location Terminally Incoherent specifies. And since all configuration files should be stored in /etc, I moved /usr/local/sbin/GCALDaemon/conf/gcal-daemon.cfg to /etc and made a symbolic link to the original location. I also set file.polling.google to 5 minutes in the cfg file.

By the way to get this all working you’ll need Kpilot, pilot-link and Sun’s Java. The default Java that ships with Ubuntu 7.10 will not work with GCALDaemon. You’ll also need GCALDaemon and configure Kontact to sync with GCALDaemon - install this software and then use the tutorials I liked to above.

sudo apt-get install kpilot pilot-link sun-java6-jre

Once you have GCALDaemon working with Kontact and Google Calendar, you can begin the next steps. Once you’ve done the following steps ones all you need to do is sync your palm normally.

1) Make a backup of your entire palm (you may need to replace that /dev/ttyUSB1 with something else):

pilot-xfer -p /dev/ttyUSB1 -b /home/yourname/somedirectory

Having a backup is crucial, so don’t skip this. You were warned.

2) Open Kpilot, go to Settings -> Configure Kpilot and tell it to sync to the same google.ics that GCALDaemon is using. Again, mine is at /usr/local/sbin/GCALDaemon/google.ics. Under the Conflicts tab choose Handheld overrides.

3) Synchronize your palm and wait until GCALDaemon transfers all of your appointments to Google Calendar. I had thousands of appointments so I gave it an hour.

4) All of the calendar entries in your palm may have vanished. Don’t panic. Sync again - all of the entries should be there. If not, restore the calendar to the palm using pilot-xfer. You don’t have to start over, just restore the calendar. Two way sync should still work with no duplicates.

That’s it.

A) Add the swiftweasel repository to apt by adding this line to /etc/apt/sources.list:

deb http://download.tuxfamily.org/swiftweasel gutsy multiverse

B) Update the cache and install Swiftdove:

apt-get update | apt-get install swiftdove-athlon64

Swiftdove is noticably faster, and the inclusion of Lightning is a nice bonus.

This should be required on all devices sold. I’d most like to know the expected lifetime for a product.

I left out things that seemed obvious - that it is better to bike, walk, use mass transit or just stay home. That there are a bunch of other things we need to do in addition to moving to entirely renewable sources of energy - combine trips, massively increase efficiency of our vehicles, buy locally, use flex cars, work from home, carpool… I figured these things were safe to leave out, given the audience would be smart, educated people with open minds.

I wish I could have covered algae in greater depth. I don’t think it is possible for us to get out of this mess without it (where ‘this mess’ equals peak oil + climate change). And there is no way our need for liquid fuel is going to go away, unless we go back to living in the trees. Liquid fuel is fundamentally a part of everything we do, and biodiesel has the least impact of any of our choices. Any of them. I did another ten hours of research on other renewables and caught up on the latest biodiesel research to make sure everything was up to date. I uncovered some new research that bears some further following up - it might be the case that some farming methods may have negative impacts. That’s why it is all the more important to focus on algae, which alleviates those concerns entirely. The best I could do on that was get the message out about not buying Palm oil biodiesel.

Anyway, I received overwhelmingly good responses both at the show and afterwards, and had a great time. I can’t wait to see the next round of Ignite presentations!

You’re done.

I’ll test mine at a few public access terminals. I’m curious how easy it would be to boot from the USB drive instead of being forced to use the inevitably crippled and/or virus/spyware/malware-ridden boxes one usually finds.