Starbucks Gold Card

[flickr-photo:id=2943019511,size=m]
Starbucks “Black” Gold Card

This summer I fell in love with Starbuck’s Vivanno, their high-protein, high-fiber smoothie beverage. My signature drink: a banana-chocolate Vivanno, one espresso shot, with non-fat milk. Because I was going there so often, and because the new Starbucks and AT&T partnership gave 2 hours free WiFi a day, I started buying things through a free Starbucks Card (essentially a prepaid, reloadable gift card).

Apparently, I went to Starbucks more than I thought. A few weeks ago, Starbucks invited me to be part of their Starbucks Gold program. The program provides a special card, which is quite pretty: the back is standard glossy card fare, but the front is a black matte with gold embossed logo.

Starbucks started this program earlier this summer, and they’ve been tweaking the benefits. The benefits my card comes with (as says the flyer that came with it):

  • 10% off most purchases
  • Coffeehouse rewards, including special discounts on family and friend days
  • Surprise indulgences, like treats on my birthday
  • Members-only website and insider promotions

Unfortunately, this comes at a price.It has a membership fee of $25/yr—only the hardcore Starbucks coffee drinkers (which isn’t me) need apply. Also, supposedly, the card does not provide any of the Starbucks Card Rewards,such as the free WiFi, or free milk and syrup options. So far, I’m going to pass on the program, and continue using my old Starbucks Card. But I will keep the pretty-looking card.

Correction: My beta invite entitles me to the Starbucks Gold membership for free. Funny this not indicated anywhere. Also, even though the fine print says Starbucks Card Rewards do not apply, the Starbucks Gold program portal implies that WiFi is an included reward, and it does appear to work…

Update: Now that the Starbucks Gold membership has officially launched for the general public, you can get a description of the benefits in-store. With the Starbucks Gold card, you do not get all the Starbucks Card Rewards—that is, no free syrups, milk or whipped cream, refills on drip coffee, or free tall drink with purchase of whole bean coffee. However, as I mentioned, you do get WiFi.

samat.org upgraded to Drupal 6.5

After over 2 years, I’ve finally upgraded this website from Drupal 4.7 to 6.5. It’s something I’ve been meaning to do for a long while. Hopefully, with the new Drupal version management scheme I’ve developed for Rhombic Networks (article coming soon), along with the advancements in update management within Drupal itself, it will be much easier to keep current with updates.

Like I discussed my last upgrade to Drupal 4.7, there are several new features I’m excited about:

  • OpenID support. Instead of having to leave comments anonymously, or waste time creating an account, use your OpenID. If you have your own domain, check out Simon Willison’s article how to turn your blog into an OpenID. I’ve noticed with an OpenID, I find myself commenting and participating on sites much more often. Hopefully I can expect the same of others with my website.
  • Drupal’s Mollom module. The old site was getting hit with hundreds of spam comments a day. I gave up trying to filter them all, which meant it took a long time for users’ comments to show up on the site. Hopefully, with Mollom, that will change, and I will be able to screen comments again instead of screening spam. I like Mollom more than I do Akismet.
  • Drupal’s Atom module.RSSsucks. You can now aggregate this blog via an Atom feed. Like most home pages on the Internet, most surfers find content on this site via search engines, or via their feed reader.

Hopefully, I can get my development mojo going and finish porting my Drupal Sands and Sands_CSS themes to Drupal 5.x and 6.x. I’m sorry I took so long!

jQuery: the new defacto Javascript web framework

News from a couple days ago: both Microsoft and Nokia are now including the jQuery Javascript framework as part of their development kits. That is: jQuery will be part of Microsoft’s ASP.NET AJAX framework and be available for use in applications written for ASP.NET; and jQuery will also be distributed on millions of Nokia phones.

Defacto standards, I believe, are a good way to inform the development of real standards. Standards developed the other way around, at least in the tech industry, have had a habit of taking a very long time to reach end consumers… for example, how many decades has it taken for your average web user to gain access to a fully CSS2-compliant web browser? How many more decades will it take for OASIS’s OpenDocument format to supplant Microsoft Word and its *.doc files?

Hopefully, this is the beginning of a path that will lead to jQuery’s inclusion into the Javascript language, as well as initiatives that will improve jQuery’s performance.

I like the fact that Microsoft and Nokia are not trying to reinvent the wheel, and roll their own Javascript frameworks. Sun did this with Java Server Faces. A frequent lament with JSF is that it’s nearly impossible to customize any of the widgets. There is too much complex, custom Javascript, and the adoption of the frameworks used makes figuring out how to work with them difficult.

Also, as others have noted, this is the first time Microsoft itself is distributing an open-source project with one of their products. A sign of things to come?

Speeding up SpamAssassin rule processing on Debian and Ubuntu

SpamAssassin is one of the most-used spam filtering systems in use today. Unfortunately, because there are so many different ways SpamAssassin can be used, SpamAssassin remains subject to many performance problems. Fortunately, there are several speed-ups and optimizations that can be applied to most SpamAssassin installations to speed up its rule processing, especially on Debian and Ubuntu GNU/Linux-based systems. These instructions can be adopted to other operating systems as well.

This article does not discuss configuring your mail filtering system (i.e. procmail, maildrop). This depends completely on your setup, and more than likely there are plenty of other articles that describe the best way to setup what you want.

The spamc/spamd client/server combination

A normal SpamAssassin setup invokes the spamassassin command for each incoming e-mail that needs to be scanned. This process is expensive when you consider what this does: for each incoming e-mail, a perl interpreter starts and loads all of SpamAssassin’s perl code, including its thousands of rules. Starting SpamAssassin like this, with a decent amount of incoming e-mail, will increase I/O load and slows things down, fast.

SpamAssassin 2.x introduced the spamc/spamd combination to alleviate this issue. spamd is a version of SpamAssassin intended to be run as long-running process that accepts connections from spamc. spamc is a lightweight C program made to replace the spamassassin command, taking a message and passing it to spamd for processing. This alleviates all of the I/O caused by loading perl and all of SpamAssassin’s rules repeatedly. Instead, both perl and SpamAssassin’s rule sets are only loaded once.

Setting this up and relatively quick and easy. Install:

sudo aptitude install spamc

Then, edit /etc/default/spamassassin to enable startup of the spamd process. In this file, change:

ENABLED=1

Start the spamd process:

sudo /etc/init.d/spamassassin start

Next, in your mail filtering scripts wherever you invoke the spamassassin command, invoke the spamc command instead. After verifying spam filtering still works after all these changes, you are done.

One important thing to note: the spamd/spamc combination sets up another service running on your system, possibly opening up a security hole waiting to be exploited. Make sure to follow due process (securing user accounts, setting up firewall, etc) before enabling new network services.

Precompiled Rules

Erich Schubert went into SpamAssassin 3.2’s ability to precompile rules a few months ago. While Perl’s regular expressions are fast, C regular expressions can be faster (and consume less memory). SpamAssassin can compile its rules into a C shared library that is used instead of interpreted perl code. Eric mentions a negative to precompilation: it requires your mail server to have a C compiler.

If you’re comfortable with that, setting up your system for precompiling SpamAssassin’s rules is easy. Install the required depencencies:

sudo aptitude install re2c build-essential

and run the sa-compile command:

sudo sa-compile

You then need to configure SpamAssassin to use the precompiled rules. This is done by editing /etc/spamassassin/v320.pre, and uncommenting out the line:

loadplugin Mail::SpamAssassin::Plugin::Rule2XSBody

Has the war on spam been lost?

O’Reilly Radar has an article written by Dale Dougherty, a roundtable set of opinions on whether the war on spam can be won. Rafe Colburn also has his own response.

Rafe’s solution is to use GMail. In the Dougherty’s article, Paul Vixie mentions that the internet is going to become a “walled garden;” relying on proprietary technology provided from a single company is the same thing in my eyes. There’s no way I’m going to advocate a proprietary solution for something as important as my e-mail.

Eric Allman mentionsDKIM, which I think is an excellent weapon in the war on spam. I’m not using it however, as it doesn’t fit in with the way I use e-mail, andMUA(e-mail client) andMTA(e-mail SMTP server, essentially) is extremely sparse.

My unfortunately ineffective and impractical solution to this problem is use of PGP. Besides identity verification via digital signatures, it is also a generic platform for encrypted digital communication, and provides a distributed, robust trust model. Unfortunately, its learning curve is high, and that is why it’s basically been a failure for the past 10 yrs.

Though, lack of user education is why the spam problem keeps getting worse too. It’s users who click links in spam e-mail; it’s users who allow spammers to take over their machines through their negligence in applying security updates; it’s users (sometimes) who allow their identities to be stolen.

GPG public key signing post-party automation with KMail

This past Ubucon‘s key signing party was my first key signing party. One thing I noticed—signing keys after a key signing party is a boring repetitive task. Summarized from the Ubuntu wiki entry on typical key signing post-party protocol:

  1. Retrieve all public keys of key signing party participants, using gpg –-recv-key
  2. Compare the hardcopy fingerprint from the keysigning party to the fingerprint of the retrieved public keys, using gpg –-fingerprint
  3. Sign the key, using gpg –-signSend the signed key back, either by
  4. E-mail: export the key, then e-mail it to the key owner, using gpg –-export -a| mail -s “Your signed key” user@example.com
  5. Key server: send the key to a public keyserver, using gpg –send-keys

This is incredibly monotonous—and people have to wonder why Web of Trust-based encryption is not more popular?

The Debian signing-party package provides the utility caff to automate some of this. It’s not very friendly to “desktop” users, however:

  • it’s aCLI application
  • it requires a localMTA(/usr/sbin/sendmail in particular), or an “open” SMTP server, with no support for authenticated SMTP or SMTP/SSL
  • the configuration file syntax is Perl and confusing; there are also few examples on the Internet

You could add authenticated SMTP or SMTP/SSL support to the script, but having to know how to hack Perl definitely disqualifies caffe from being a desktop-friendly application.

So, I hacked together my own key signing party script in Python that would send signed keys back to people via KMail. To use it, create a text file listing all key IDs you wish to sign, one per line. Pipe the contents of this list into the script:

cat list-of-ids.txt | key-signing-party-batch-process-via-kmail.py

The script will download each key, ask you to verify the fingerprint, and then sign it. It then will open a KMail composer window, pre-filled with the key owner’s e-mail address, a friendly template message (customizable in the script), and attached key. Review each e-mail to make sure it is kosher, and click send. Other than continuing to be a CLI program, I think this is much friendlier—the only manual work done is the creation of list of keys to sign, comparing fingerprints (this could be automated, but it seems in the spirit of the Web of Trust-based systems not to), and clicking send in a familiar desktop e-mail client.

Now for some notes…

It uses the DCOP automation features of KDE’s Kmail to send messages. You could similarly use Evolution and D-Bus, but I don’t use Evolution so I can’t contribute that bit of functionality. Mozilla’s Thunderbird unfortunately does not yet support any kind of automation features (as far as I know, anyway), so you’re completely out of luck if you use it.

DCOP with Python is a complete, utter, pain. The easy way to drag-and-drop boiler-plate code with kdcop did not work, as it appears the APIs have changed. A problem with KDE/Python dcopext’s module and multiple identically-named-functions sealed the deal for me and I gave up trying to use DCOP with Python, and instead settled for a hack of using the shell instead. I’m looking forward the one Linux desktopIPCprotocol to rule them all, D-Bus, to debut in KDE4.

My script does not provide all the functionality of caffe. It, for example, does not encrypt the messages and their keys back to their owners. There doesn’t appear to be an easy way to do this with KMail and DCOP, so it’s a feature that will have to wait.

The GNOME font dialog, why?

Fredico M Quintero pointed out some serious flaws in GNOME’s font configuration dialog; the Novell Product Design wiki also describes some problems. In a sentence that fits in with what I believe is GNOME’s “simplicity mantra”, GNOME should just get rid of its useless, confusing fonts configuration dialog.

Why does it have a font configuration dialog anyway? Well, unfortunately, GNOME’s setting daemon completely ignores several fontconfig settings and instead uses its own settings for things like antialiasing type, whether hinting is used, DPI, etc. You need the font configuration dialog to change these settings, or you have to dig through gconf. Most of this was put in place probably to subvert a broken X setup; instead of implementing these hack-ish workarounds GNOME should instead push to fix X instead.

It’s extremely difficult to discern the difference between the different types of antialiasing. GNOME’s dialog doesn’t let you select arbitrary text, or let you render text in-place so that you can quickly compare between different antialiasing styles and subpixel orderings. These settings, along with DPI, are unlike the rest of the settings in the font configuration dialog because they don’t apply immediately. They only affect newly started applications, and the dialog does nothing to alert you of this.

Do users really need to be able to select subpixel ordering from a dialog? There are very few LCD monitors that do not use an RGB subpixel ordering. The very few people who rotate their LCD monitors into portrait mode (including me, see my past article Misery with online reading of PDFs and the need for portrait monitors) would use VRGB. Why not just set RGB subpixel ordering if the user is using an LCD? VRGB if their display is rotated? Again, these are things GNOME could discover by querying X…

Lastly, do users need to change the fonts used by their UI in the first place? The majority of Windows and MacOS X users don’t deviate from the defaults at all—why would GNOME users be given a choice through this confusing dialog? GNOME instead should use the fontconfig aliases “Sans”, “Sans Serif”, and “Monospace” rather than letting users choose fonts. A fresh GNOME setup already uses these aliases as the defaults anyway.

Of the settings in the font configuration dialog users may actually want to set, whether to use antialiasing or not is the only one that sticks out to me as needing an option. I think that the dialog could be replaced with a simple, descriptive checkbox somewhere that read “Antialias text” that would toggle all the heuristics I’ve described above.

Yes, GNOME is limiting!

There’s been a lot of fallout from Linus’ latest criticism of the GNOME desktop, with which I complete agree. I feel as if I need to comment on some of the responses.

Carthik Sharma writes in Of Apples and Oranges, GNOME and KDE:

I dread having to find something, since it most definitely will be placed in some non-intuitive sub-menu.

KDE has no control over where applications decide to place themselves.

I like the way GNOME display fonts on the screen. I don’t want to have to change every little variable to get the perfect system.

GNOME pioneered use of fontconfig; in fact, lately, GNOME has been pioneering the use of many next-gen APIs and technologies (e.g. AIGLX, Beryl, etc). But Qt/KDE have also been using fontconfig for several years now—what’s different?

Interesting enough, there has been criticism about how GNOME handles fonts. Taking points from that article, GNOME’s font configuration is a mess:

  • What’s a “Terminal” font (it should be called “Monospace,” as it is in KDE, because this is how it’s also used throughout GNOME)?
  • What does “size” mean (apparently, it’s not what you think)?
  • Why do I care about the subpixel ordering of my fonts’ antialiasing?
  • Why would I need to set fonts at all (see my weblog entry The GNOME font dialog, why?)?

KDE is no different than GNOME in trying to provide “sensible” defaults, defaults that its developers have decided are intrinsic to a “perfect desktop.” But, what the developers have decided is the perfect desktop may not be your perfect desktop—and here lies the essence of Linus’ argument, and the difference with KDE and GNOME. With KDE, you may have an option to make a setup “perfect”; with GNOME, quite often the option won’t exist and you are limited to what the powers that be decided was perfect for them, not you. This is Linus’ argument: GNOME is limiting.

High-speed cellular wireless modems (e.g. EVDO, HSPDA) in Ubuntu GNU/Linux 6.10

[inline:novatel-s720.gif]

Note: If you are running Ubuntu 7.04 or greater, this article is no longer relevant. Your EVDO modem should be detected and run at a higher speed automatically.

I’ve been raving about cellular wireless modems/data cards for a while now. While they’ve been available for a long while, they’ve finally become practical with networks such as EVDO and HSPDA that offer broadband-like speeds. I personally own a Novatel Merlin S720 that I use with Sprint’s Mobile Broadband service.

Most of these datacards are easy to get running in Linux—I actually setup mine in Linux faster than I did in Microsoft Windows. However, due to some shortcomings in the kernel used by Ubuntu GNU/Linux 6.10, you cannot take advantage of the speeds that these modern wireless networks offer.

This article talks about some of the problems of the often-used usbserial driver, and how to use the better-performing airprime driver instead.

Using the usbserial vs airprime drivers

Many instructions on the Internet that detail how to use these modems in Linux talk about using the usbserial driver, often having to pass custom vendor and device IDs to the driver so that it recognizes the device. While this does work, the usbserial driver was not made to handle high-speed devices like EVDO and HSPDA modems. It has some small I/O buffers, and with these small buffers you will not be able to get transfer speeds greater than 60 KB/sec. There are patches available to increase usbserial’s buffer size, but with the airprime driver, this is not needed.

The Linux airprime driver can operate these modems at full-speed, after support for larger buffers was added in 2.6.18. Unfortunately, the driver has to be patched to recognize any kind of new device.

This doesn’t help me using since I am Linux 2.6.17 on Ubuntu 6.10, and I’ve also no desire to deviate far from the distribution-provided kernel. 2.6.17’s airprime driver does not have the support for large buffers, nor does it contain the driver IDs so that the driver takes control of the device.

I took Andy Gay’s airprime improvement patches and backported them (“backport” is a misnomer since it was so easy), also adding the device IDs from 2.6.20 and a few other popular wireless modem devices (Note: I’ve not personally tested anything but the Novatel Merlin S720).

You can get the patch against Ubuntu’s 2.6.17 kernel, or simply download the entire patched airprime.c file. The patch contains device IDs for:

Kernel and driver setup

Install the minimum build environment, Linux sources, and Linux headers for your currently-running kernel: apt-get install build-essential linux-headers linux-source

Go into /usr/src/ and uncompress the kernel source code: cd /usr/src tar xjvf linux-source-2.6.17.tar.bz2

Enter the directory containing the airprime driver:

cd linux-source-2.6.17/drivers/usb/serial

Now, either apply the patch, or replace airprime.c with the pre-patched version (see above for download links).

If patching:

patch -p0 < airprime-sjain-012807.patch

If replacing (not recommended, patching is safer):

mv airprime.c airprime.c.bak mv airprime-sjain-012807.c airprime.c Normally, to patch a driver, you have to recompile the entire kernel tree and replace all the kernel modules as well as the core kernel image itself. But since we are using Ubuntu’s sources, we can only compile the driver’s that we need and overwrite the old ones.

To compile only the airprime dirver (this actually compiles all drivers in the directory): make -C /lib/modules/uname -r/build M=pwd

Then, install it (you need root privileges to overwrite the existing driver) and update module dependencies: sudo cp airprime.ko /lib/modules/uname -r/kernel/drivers/usb/serial/airprime.ko sudo depmod -a

You can either remove and reinsert the driver, or take the easy way out and reboot. Your device should now be recognized by the airprime driver, and a new device node /dev/ttyUSB0 created.

Some ending notes…

The above installs files outside the knowledge of Ubuntu’s package manager. If your kernel ever gets upgraded, dpkg will happily overwrite your custom driver, and you will have to go through the above procedure again. To prevent this happening at an inopportune time, set your kernel’s package status to “hold” to prevent automatic upgrades.

If you’re using Sprint’s Mobile Broadband service as I am, you may want to look the sister article I’ve written, Sprint’s Mobile Broadband on Ubuntu GNU/Linux 6.10.

Sprint’s EVDO Mobile Broadband on Ubuntu GNU/Linux

[inline:sprint-mobile-broadband-card.jpg]

So, you’ve gotten your shiny new EVDO datacard working under Linux (if not, see High-speed cellular wireless modems (e.g. EVDO, HSPDA) in Ubuntu GNU/Linux 6.10) and you want to now setup the actual Internet connection?

In this article I document how I setup Sprint’s Mobile Broadband service with ppp in Ubuntu GNU/Linux 6.10.

Setting up ppp

There are some great GUI tools for setting up PPP on Linux, but I don’t care to use them. I like editing text files and working on the CLI.

To get things working, we only need to create several different files (as superuser). The first, /etc/ppp/peers/sprint:

/dev/ttyUSB0    # modem
921600          # faster than this has no effect, and actually can be detrimental
defaultroute    # use cellular network for default route
usepeerdns      # use the DNS servers from the remote network
\#nodetach        # keep pppd in the foreground
\#debug
crtscts         # hardware flow control
lock            # lock the serial port
noauth          # don't expect the modem to authenticate itself
local           # don't use Carrier Detect or Data Terminal Ready
persist         # Redial if connection lost
user
ppp
holdoff 5       # Reconnect after 5s on connection loss

lcp-echo-failure 4      # prevent timeouts
lcp-echo-interval 65535 # prevent timeouts

connect         "/usr/sbin/chat -v -f /etc/chatscripts/sprint-connect"
disconnect      "/usr/sbin/chat -v -f /etc/chatscripts/sprint-disconnect"

Notice that you do not need your Sprint PCS username or password. The modem authenticates itself to Sprint in hardware via itsESN. Next is /etc/chatscripts/sprint-connect:

TIMEOUT 10
ABORT 'BUSY'
ABORT 'NO ANSWER'
ABORT 'ERROR'
SAY 'Starting Sprint...\n'

\# Get the modem's attention and reset it.
""      'ATZ'
\# E0=No echo, V1=English result codes
OK     'ATE0V1'

\# List signal quality
'OK' 'AT+CSQ'

'OK' 'ATDT#777'
CONNECT

and your connection will work

And then the optional /etc/chatscripts/sprint-disconnect:

"" "\K"
"" "+++ATH0"
SAY "Disconnected from Sprint."

You can also setup this connecton in /etc/network/interfaces, adding the stanza (assuming you want to use ppp0):

iface ppp0 inet ppp
        provider sprint

And that’s basically it! If you setup your interfaces file, you can simply run:

sudo ifup ppp0

to bring up the connection. Remember to ifdown the interface to disconnect. If not using interfaces, you can use the pon/poff pair of commands:

sudo pon sprint # Start connection
sudo poff sprint # Stop connection

Problem: default route does not get set

For some reason, my default route is not set properly. If not set properly, you look as if you’ve been connected to Sprint, but you will not actually be able to connect to any site on the Internet. To check if this is happening to you, look at the last line of “route -n” and see if it reads the nonsense:

0.0.0.0         0.0.0.0     0.0.0.0         UG    0      0        0 ppp0

To fix this, I created script into /etc/ppp/ip-up.d/zzz-fix-route:

\#!/bin/sh
/sbin/route del default gw 0.0.0.0      # Remove nonsense route
/sbin/route add default gw $PPP_REMOTE  # Add correct route

Remember to make the file executable. The “zzz-” prefix insures that it is the last script run, just to prevent a script after it from misconfiguring the route again,