The kits are selling for $75 each, and include all of the parts required to build a functional ybox2.

Here is the cool part: You don't need any extra tools to reflash the firmware! The EEPROM in the kit comes preloaded with an ethernet bootloader I wrote, which allows you to upload new firmware to the device over the network! This works so well that over the past month or so I've used my prop-plug only two or three times. 90% of my development—including development of the bootloader—has been over the network.

More information is available in the FAQ.

UPDATE: The ybox2 made it on Engadget!! w00t!

The com.google.android.xmppService package has been replaced by the com.google.android.gtalkservice package. This is driven by the fact that the GTalk API is not XMPP compliant, and will be less so going forward. The reason is that XMPP is too verbose and inefficient for mobile network connection, and the GTalk API will be moving to a binary encoding for the protocol between the client and the server.

I'll enumerate the implications and conclusions:

1. XMPP is verbose.
2. XMPP is inefficient for mobile networking.
3. A proprietary binary protocol would be more efficient for mobile devices.
4. The former Android xmppService API will diverge away from XMPP.

I think that this direction is unfortunate, and the reasons misguided. Read on, and I'll elaborate...

After playing around with it for a few days, I have come to a few conclusions about the device. And, for my own amusement, I'm making this post entirely from my XO-1.

But lately teredo hasn't been all it's cracked up to be, and I think I know why: BGP routes to broken teredo relays. Whichever teredo relay which happens to be covering most of North America is really busted. I can connect to Japan (kame.net) just fine. I've been having problems like this for months but it only recently got really bad, because I no longer have a teredo relay set up at my home. Even though most of the IPv6 internet has been unavailable thru teredo for months, I didn't really notice—because at least I could access my home network. Now I can't even do that.

This is a damn shame. What was once a very promising transition path from IPv4 to IPv6 has fallen into such a state of disrepair that it has become useless.

It works! Woo-hoo! Now comes the hard part: the Propeller TCP/IP stack.

Keep in mind that this is just a prototype. The next version will be cooler.

Oh. Maybe not. Well, it was pretty cool.

There is a special place in my heart for the original ybox, as it is what finally got me into tinkering with microcontrollers. However, the more I've learned, the more things I can find wrong with it's current design:

• It's expensive! The XPort component is $51 in single quantities!
• The XPort shielding isn't properly grounded on the original PCB, so if you have stray VDD wire touch the XPort, you just fried a $51 part! (I speak from experience)
• The PCB seems largely autorouted, with lots of vias and unnecessarily long traces for the video signal.
• Did I mention it was expensive?

So I've set out to make a better and less expensive networked set-top box in an altoids tin. It should be around $40 cheaper to build. This is what the board is looking like:

Ain't it beautiful? Anyone care to guess what it does?

It’s hard to work the concept of a “software update” into a cow analogy, but here goes: You willingly purchase a cow, which, the purveyor of said cow makes explicitly clear, is intended only to be used to produce milk. You buy it and figure out a way to make cheese. Two months later the purveyor of the cow offers you a pill, free of charge, which, if administered to the cow, will result in slightly better-tasting milk, but which pill comes with a stern and plainly worded warning that, if administered to a cow that had been used to produce cheese (which, recall, was made clear from the outset the cow was not intended for), the pill might kill the cow, and that, even if it doesn’t kill the cow, will prevent all previously known cheese-making hacks from working. Further, let’s stipulate that there is no medical or bovine pharmacological reason the pill could not have instead been engineered in such a way that it would enable the cow to produce the better-tasting milk and still allow the previously discovered cheese-producing hacks to continue unabated — that the reason for this frustrating limitation is, at best, marketing, and at worst, spite — and so that, in some way, the whole situation is, undeniably, at least somewhat shitty.

Take for example the San Mateo Court website. Being located in the tech-savy area that it is, it gives you the ability to pay your traffic ticket online—which is darn convenient. If you have Microsoft Internet Explorer. If not, you are out of luck.

So what sort of magical Microsoft stuff is this website doing? Some funky javascript, perhaps? Maybe some ActiveX goodness? Apparently not. Quite simply, if you aren't using MSIE attempts to look up your ticket will fail; telling you that it can't find the ticket using the information you provided. This is just a normal web form. No fancy javascript. No ActiveX. Just a plain-old HTTP POST form. Disgusting.

I ended up writing the webmaster an email. I wonder if I'll get a reply. Here it is:

I cannot look up and pay for a traffic ticket using Safari on your website.

It is despicable that your ticket payment system on your website only works for Internet Explorer. You aren't even doing anything fancy, it's just a friggin' POST web form. The amount of effort required to allow other browsers to operate (such as Safari, Firefox, Opera, etc) would be minimal, and you would be making the world a better place.

Please consider taking the 2-3 hours to debug and rectify this problem. More and more people are using other browsers these days, and Internet Explorer is no longer widely available on the Mac. As a government entity, you should be promoting the use of open standards and interoperability, and not inadvertent vendor lock-in via lazy web programming.

• libsigc++ 2.0.17 Framework
• libxml++ 1.0.4 Framework

Support for the Teredo protocol is actually in WindowsXP, but it is disabled by default. However, that has changed for Windows Vista—where IPv6 and Teredo are enabled by default². This is important because this means that relatively soon, widespread deployment of IPv6 will become a reality. This is great for Windows users, but what about other platforms?

Miredo is an open-source (GPL) user-space teredo implementation for linux and BSD. Someone went thru the effort to get miredo to work on MacOS X, but setting it up is not something your average joe can accomplish. What is needed is an installer package.

Well, that's exactly what I'm putting together. I'm releasing a prerelease version of the package today for early-adopters and power-users. You just download it, install it, and you should have IPv6 connectivity.

IMPORTANT: This package is a prerelease version intended for early adopters, and is NOT intended for widespread deployment. If you decide to install and use this experimental package, you should subscribe to the miredo mailing list, paying serious attention to any security advisories.

. . . Imagine a world where every online store sells DRM-free music encoded in open licensable formats. In such a world, any player can play music purchased from any store, and any store can sell music which is playable on all players. This is clearly the best alternative for consumers, and Apple would embrace it in a heartbeat. If the big four music companies would license Apple their music without the requirement that it be protected with a DRM, we would switch to selling only DRM-free music on our iTunes store. Every iPod ever made will play this DRM-free music.

Why would the big four music companies agree to let Apple and others distribute their music without using DRM systems to protect it? The simplest answer is because DRMs haven’t worked, and may never work, to halt music piracy. Though the big four music companies require that all their music sold online be protected with DRMs, these same music companies continue to sell billions of CDs a year which contain completely unprotected music. That’s right! No DRM system was ever developed for the CD, so all the music distributed on CDs can be easily uploaded to the Internet, then (illegally) downloaded and played on any computer or player.

I knew I liked this guy.

It seems that Macrovision's CEO, Fred Amoroso, has formally responded to Steve's "Thoughts on Music". Luckily, John Gruber of Daring Fireball has translated the letter from PR-speak to plain English. Worth a read.

Ever since Google Talk flipped the switch to enable server-to-server communications, Google Talk has become my default recommendation for anyone looking to get a ‘jabber account’. Back then, jabber.org was still having stability problems (as it was still running jabberd 1.4), and my own server was also less than reliable. Google Talk also came with several useful features, such as the chat client built right into gmail.

However, I have recently realized that Google Talk is not the ideal, stable jabber server that I thought it would be. Read on to find out why.

UPDATE: (2006-11-01) Google Talk now supports offline message delivery!

Why in the world Apple doesn't provide a nice user interface for changing these things without mucking around in the terminal is beyond me.

Making a website secure is a surprisingly non-trivial task that requires plenty of thought and discipline. What makes it worse is that it is all too easy to create gaping security holes without realizing it.