My OLPC XO arrived today! I managed to pry it from the kids when they went to bed and started mucking around with it.



It's a little slower than I was expecting (not that I was expecting it to be swift or anything), and the soft keyboard takes a little getting used to, but on the whole I'm liking it. The industrial design is great in my opinion, and has some neat little touch: the texturing in the case has large nobbles, and around the handle the nobbles become Xs, so that the texturing repeats the XO logo. The Sugar UI feels good and the included apps, a.k.a. Activities, provide a good cross section of functionality, from word processing to recording video on the built-in camera.

The browser, which is Firefox derived, works well and even has some Flash support (via Gnash). It also has some integration with Sugar, since when I went to upload a photo to Flickr and hit the Browse button, a popup appeared showing my last few activities, including the picture I had taken. When I clicked on it, it inserted a /tmp path to a JPEG file into the form. Alas, when I hit the Ok button Flickr told me that the file was empty. I popped into the shell and could the file in question was indeed empty, but there was a non-empty JPG also in temp. I copied it to the path the browser was pointing at (I couldn't get it to let me edit he path in the browser for some reason), and this time the upload worked. I'm sure that's either just a kink or something I didn't do properly when saving the photo.

My MacBook looking at the XO:


My XO looking at my MacBook (the photo referred to above):


The Neighborhood page in Sugar showed my home wireless network's SSID, but I couldn't figure out how to connect to it. I have since found out that you just need to click on the dot representing the network, but I expected there to be a "Connect..." option in the popup dialog that appears when you hover the mouse over the dot. In any case I use WPA and, at least according to the OLPC "getting connected" page, "we do not support WPA-enabled WiFi access points; we anticipate including WPA support in early 2008." However, I did some googling and found that I could drop to the shell to get WPA working (see http://wiki.laptop.org/go/WPA_Manual_Setting). I created the script suggested, ran it, and rebooted the XO, and it came up on my WPA network.

Some of the Activities require more than one XO. Fortunately, one of my colleagues at work ordered an XO the day after me, so his ought to be here soon. I'd particularly like to try out the Distance Activity,



which can measure the distance between two laptops by measuring the length of time it takes for sound to travel between them, but since it requires 2 XOs, it'll have to wait until we both can get them into the office after the holidays.

For more photos of the XO, see the unboxing set I put on Flickr.

BugLabs have now opened the beta up, so you can now download the SDK, sign up for the forums and check out the apps on BugNet. Feel free to mock my quickly-hacked up apps ;-)

I realize I haven't posted about BugLabs for a while; actually, looking at the top of the window I'm typing in I can see it's been close to 6 weeks. Well, the truth is there doesn't seem to be much going on at all, in the beta program at least. The last posting from anybody in the forum was December 6th, and I've been super busy at work so I haven't played with it much either. Plus the questions I've posted as to the direction they plan to go as far as user input, and display mediation between modules haven't been answered, so I haven't really figured out what else I could usefully do to test the SDK at this point. I have seen some bugzilla emails come in, so I know the guys are still working on stuff. I'm sure they're trying to get the last few kinks out before they release, which they are/were slating for mid-December.

We did get an update from Jeremy (the marketing guy) update the beta program back on November 20th:

---

Hi there - we know that it's gotten a little quiet around here and we want to apologize. We also want to give you an update (overdue!) so you don't think something is amiss.

First - BIG thanks to everyone whose been involved in our beta program. We've learned a ton from you and are applying it to our software and hardware. We would not be where we are right now without you. Please keep pounding. There's more fun stuff on the way.

Second, when we initiated this beta program we got a great response from everyone - applicants, selected testers, etc. Many people jumped in and started exploring, coding and building things. Others hung back and waited to see what unfolded. And the truth is, not very many did. It became clear to us pretty quickly that we were asking a lot of you. Without hardware to play with and more module types to mash up, folks ran out of energy. We intended to get more resources into the mix but we weren't able to because everyone's working hard on getting product out the door. Since then we've been hiring and I'm happy to say we will be making hardware available soon too!

We are a few defects away from moving out of closed beta and into an open beta of the BUG SDK and BUGnet. And as I mentioned above, our hardware is fully up and operational (although we can't say there's no defects just yet!). Needless to say, we're pretty excited about getting to this point!

In December, we'll be bringing the first batch of BUGbases and BUGmodules to market. These initial BUGbase units will be limited production v0.9 hardware. We're giving them that designation for a couple reasons. We decided to change the design of the front panel a little bit and will not be able to get that change into these first units before the end of the year. Same thing for the wifi chip set. We will not be able to incorporate our new wifi design into BUGbase before year end. So rather than delay shipment, we've decided to go into limited production. These units are functionally identical to what our final production units will be (with the only exception being wifi). All our BUGmodules will be v1.0 production and will be fully compatible with both our limited production and full production BUGbases.

Between now and the open beta, you are welcome to continue to use BUGnet, the SDK, and participate in the forums. There will be at least one update to the SDK in the meantime. As we have reached this great milestone, we invited some of our blogger friends to come take a look at working hardware, here's a few videos (Gizmodo, TechCrunch, Silicon Alley Insider) that show it off. If any of you'd like to come by the office, please let us know, we'd love to meet you in person. For those of you in the SF Bay Area, we're having a meetup on November 29th and we hope you can stop by!

Thanks again,
Jeremy

---

I asked a couple of follow-up questions (sorry for the image c&p):



I'll post back when he lets us know what the plan is. They demoed some units running Qtopia to the press, but not anything running within the BUG framework. It's going to be interesting to see how the BUG SDK fits into the rest of the device's infrastructure.

Dave Nanian over at Shirt Pocket posted an update on their progress with SuperDuper! for Leopard. And the good news is that he mentioned a release date more specific than "soon" this time: "within a few weeks". The article is an interesting read. I admire their fortitude in taking the time they need to make SD rock-solid on Leopard before releasing an update for it.

I'm looking forward to the update. SuperDuper! has always been my backup solution for OS X and I've been feeling itchy running on Leopard without it; I've got Time Machine running, but you have to restore from a boot CD with that if things go awry - yuk. I'm particularly nervous for my PowerMac, since it's boot volume is on the same 3+ year-old 120GB drive in it that it came with. I really ought to pick up a new ATA drive for it before it goes belly up.

While I wait for my XO to arrive (as they stated, there's no ship date yet), I thought I'd give the emulator a go. Conveniently the laptop.org site has a no-brainer startup guide on the OLPCWiki for running the XO emulator on the Mac (and others) using a port of QEmu to the Mac called Q.app. (I first tried building qemu via MacPorts but it wanted to use GCC 3.3 and 10.5.1 has GCC 4.0; I didn't fancy pulling in the old compiler just for this.)

I downloaded Q.app and a recent build of the XO emulator disk image - olpc-redhat-stream-development-build-542-20070801_0412-devel_ext3.img and configured a VM as per the instructions on the OLPCWiki. It started up first time, asked me for my name and I was in. Here's a view of the main page:



I didn't mess around with the emulator's DPI settings as suggested, so it looked a little fuzzier than the real thing would. Paint wouldn't start for me, but the word processor, chat program, browser, and other things I tried did. Some, like the chat program and connect 4 game needed other XO users to be in your neighbourhood, and for some strange reason there wasn't anyone else running the XO emulator on my rural street at 2am; weird huh?

I'm excited for it to arrive. I wish I could have gotten a couple to be able to have them talk to each other, but I was pushing my luck getting one, never mind two. One of the guys at work is thinking about getting one as part of the Give One Get One program. I'll have to try and persuade him so our XOs have someone to play with.

The OLPC Give One Get One program starts today. For a donation of $399 (plus $24.95 shipping), they will send one XO laptop to "empower a child in a developing nation" and "receive one for the child in your life in recognition". $200 of that $399 is tax-deductible and T-Mobile is throwing in a free year's access to their HotSpot service, which is in of itself worth $360.

I ordered mine today. Even though I don't use my laptop at Starbucks that much, I'll get some use out of the HotSpot service and I would really like to see OLPC get off the ground and do well. There's some truly innovative technology in there - see David Pogue's video for more details - and it's all good old-fashioned open source. How could I say no?

I switched to RapidWeaver's iPhone theme today. I was using a hand-tweaked version of Dark Glass, but it just wasn't cutting it for me. I couldn't get the code extracts to look good, and when I posted pictures that were wider than the blog column it looked bad and stomped on the tag/archive sidebar (usually I cut them down but sometimes I'm linking directly from another site). In the iPhone theme that information is moved to a pull-down which keeps the main page nice and clean. I like clean. Hope you do too.

Things are still rather quiet on the Buglabs front. I have been very busy with release stuff at work, and the forum postings have been pretty thin on the ground. The community application count was still at four yesterday, and I posted two of those (and the other two are at least partially based on my two). There are 14 apps in total, but the others are from Buglabs directly. I don't know if it's that people didn't realize that beta-testing something like this would involve coding, or working with the emulator is just too intangible for them, or what. Some people have being having problems getting the SDK integrated into Eclipse but other than that I'd say it was going pretty smoothly for a beta. Perhaps when the actual Bug comes out the interest will pick back up.

I'm trying to do my part anyway (this is fun for me) and so I posted the fifth community app tonight. I found time last night to put together a first pass at a location-aware to-do list manager application and cleaned up the GUI some tonight. It's far from pretty, but it has several (canned for now) to-do lists, each with a name, related location and list of items. On the VirtualBUG's LCD modules, it looks like this for now:



("Choose a Todo List" is a menu)

Once you've plugged the LCD and GPS modules into the bug, it will by default show you the to-do list whose location is nearest to your current position. I made it so that you could also explicitly select a list from a menu though. I posted it as-is, but I need to come up with a way of actually creating and working with lists. The bug doesn't have a keyboard, but an on-screen one could be created, iPhone-style. I've also considered exposing the lists via a servlet, but that would only be helpful if you had a 'real' computer to-hand; ideally you could work with lists directly on the bug. Another possibility in the less-than-ideal camp is to make it sync with web-based to-do list sites such as Remember The Milk or Ta Da Lists. I posted my thoughts on the forum, so I'll see what the buglabs folks and the other beta-testers think before going much further. I certainly don't fancy trying to create the on-screen keyboard myself in PhoneME's AWT.

Well the guys at buglabs made good on their promise and sent me a lovely gift for posting the first community app: a one-of-a-kind buglabs t-shirt. Warning, pictures of me below.

Last week, the folks at Buglabs posted pictures of the real device. It's not what you'd call Apple-pretty but I like it because of that; it has a clunkiness to it that just appeals to me (although I like my PowerMac and MacBook too, don't get me wrong). Engadget posted an article when the pictures were released, including some shots that don't show up on the press page. My favourite of those is a shot of the label that reads "Series 1.0 HIRO P." Nice little nod to Snow Crash there.

I noticed tonight that one of the press images, which is labelled "Community Applications Image", is the one that they used on the t-shirt they sent me, and it includes the name of the first app that I posted: GpsLogger (which still doesn't log; I ought to get on that, huh).

I've been dipping my toes into GTD territory for some time. I've tried doing it in Backpack, Basecamp, iGTD, OmniOutliner, and the OmniFocus beta to name a few. I seemed to get on okay for a while with each of them, but eventually I gave up; they were either just too complicated, or web-based which doesn't play well with the uplink tube at my work. I came across TaskPaper from Hog Bay Software. I had played with their WriteRoom app a while back, but it wasn't something I had too much of a need for.

At first glance, TaskPaper seemed just too simple. But when I actually started using it, I found that its simplicity was exactly what I needed. It's like a piece of paper with fring benefits. The simple syntax->format mechanism fits my programmer brain, and the fact that I can make up my own structure in a document without the application getting in my way is priceless. That's what always ended up putting me off the fuller featured apps in the end, and it's what ultimately sold me on TaskPaper.

To define a project, you type in the name of the project followed by a colon. That's it. TaskPaper turns what you've just type into a nice title. Within a project you can create to-do items by typing a dash as the first non-whitespace character on a line. It doesn't force that dash to be at the left margin though, so you can create simple subtask structure without any fuss. It doesn't do rollup of those subtasks, but then why does it need to?

So if you type:

Shopping:
- eggs
- milk
- cake
- more cake
Home:
- eat cake
- eat more cake

you will end up with:



Easy! If you notice, there's a tab there at the top that says Home. That means it's showing you your entire todo document. You can type a search into the search and it will instantly restrict your view to the matching entries. For example, here's the view when I search for cake:



So you can still see your projects, but only the important, cake-related entries within.

You can also click on a project title to focus on that project:



You can also open multiple tabs on the same document:



So you can see, it's pretty easy to get around in your to-dos. Once you find something you need to do, and then you actually go and do it, you can mark it as done by either clicking the circle in the margin or placing your cursor somewhere on the line and pressing Cmd-D. Here I only have more cake to finish my lists:



You will notice that "@done" appears in gray on a task that you have marked as complete. This hints at another feature of Taskpaper: tagging. You can tag items by prefixing the tag name with an ampersand. Here I'm trying to offset some of that cake:



And, like projects, and arbitrary text, you can also filter based on tags. TaskPaper even builds a drop-down list of them for you automatically:






So it actually does a fair bit more than you might expect, but just as importantly, it doesn't try to do too much. There's a 15-day trial, and if you like it it's $18.95 so I'd recommend giving it a go.

BugLabs pushed out an update to their SDK the other day. The status display on the VirtualBug now has 2 lines like the real one will have. They fixed a number of minor issues and also pushed through the pain to get it working on OS X. So do I switch back to working on my MacBook or do I stay pure and keep on working on Bug stuff on my Etch box?

One of the other beta testers, koolatron, took the simple GpsLogger app I pushed out and came up with a much nicer version, complete with a properly centered google tile and button-based zooming. I haven't had much time to spend on the Bug, between the release march at work and DIY stuff at home. I'm looking forward to messing around with it again, but it probably won't be this week.

Oh, I got a very nice email from the BugLabs marketing guy Jeremy:

Dave,

Just wanted to let you know your first prize is coming at ya. Please know it might show up in a fairly generic package, but it's unique and we spent a lot of time making something we thought had the right amount of personal touch. Hope you receive it as fondly as we sent it, and please let me know when it arrives - sometime next week I believe.

Best,
Jeremy

I'll post back when it arrives.

Over the weekend, the BugLabs folks posted a request to have the testers try and all work on the same task:

Hi, Now that you've had some time playing around in a fairly open context, we'd like to try a structured project where everyone is working on the same task, and see how the results play out.

The first project is to use the BUGbase and the motion detector module to build a home security system. This is a pretty straightforward project (in our estimation) and shouldn't take too long if you're already up to speed on the platform. For those of you new to the environment, it should be a good way to learn the basics of BUG.

Here's the "specifications" of the home security system: On any detected motion, the system should log an alert with the current date/time stamp. The alert log should be accessible via a Web interface.

Yup, it's that basic. For a little extra help, here are the basic steps to build the system: 1. Create a new BUG application, in the creation wizard select the IMotionSubject service.
2. Register a listener for callbacks to when motion is detected. Create and append to a file and log the date and time of occurence.
3. Create a menu item for the application that allows for the logging to be turned on and off.
4. Create a servlet that retrieves the log data from the log file and presents it to a web client.
5. Confirm that your application works by triggering motion events from the command line.

Once you are done, upload the app to BUGnet. If you need any help with the project, please let us know.

We also have a few ideas for those of you who want to push your app "to 11" (although you can be as creative as you want!), here are some of ours: * When an event happens, send an SMS * Send an email report at the end of every day * Double gold star project: also integrate with the camera, and make a picture available with each event. * something else???

Thanks, we'd love to see this wrapped up in a week if possible!
Best,
Jeremy
_________________
I'm the Bug Labs "marketing guy"

I had a bit of spare time on Sunday night so I put together "BUGer" that does pretty much what Jeremy was asking for. I added in the camera stuff too, so BUGer takes a picture on each motion event. However the servlet container in the VirtualBUG doesn't yet support static resources, so the image can't be displayed on the webpage. It's there for when it can though. If I find time I may look at putting in the email part, but the PhoneME JME doesn't have email stuff in it that I could see, and scraping SMTP seems tedious, so I may not. I'm also not sure how you would do SMS unless you did it as email-to-your-cell-phone, which is just email from the BUG's perspective, since the SMS part is done by the carrier's email server.

So midnight last night was the cut off for the first BugLabs application bake off. No-one else had posted an application so it was looking like a sure thing. However the BugLabs folks decided to extend the deadline by a couple of weeks, to give people some more time. But very nicely they've decided to "reward" me for posting an app despite the issues with the SDK (which have been pretty minor).
One of the other testers is working on a new and improved version of my GpsLogger application. I'm looking forward to seeing what he comes up with. I bumped my version to 1.0.3 last night after factoring out the utility classes to a separate package and doing some general cleanup and documentation. I'm thinking about doing some webcam stuff with it next. There's a sample app that posts images to Flickr, but I'd like to do it more like a regular webcam. It would be pretty cool to update a picture every few minutes while you're out and about (assuming of course you have municipal WiFi...).

I added the Google Tile code from one of the sample apps to my el-cheeso GpsLogger application for BugLabs last night. So now it shows the appropriate Google tile for where the position module is reporting that you are right now. I also created a few NMEA data log files using Google Earth and gpsbabel, so that I could have different fake routes to watch it run (since there's obviously no actual GPS chip in the Virtual BUG it just reads position data from a file).

b

Sorry to shout, but this has been my work life for the last year and a half.

Here's a picture of me with our new AccuNurse Voice Assistant (hastily taken with PhotoBooth, so excuse the backlighting):



It looks a bit big in that picture because of the perspective, but it's actually pretty darn small.

I finally found some time to sit down with the BUG SDK and play around. They're using the OSGi framework under the hood: a dynamic module framework for Java. I wrote the beginnings of what I intend to be a GPS logger. So far it just shows a starting position, your current position and the distance between them (using the Haversine formula). There's still some work to be done in the SDK to define the constraints of the actual LCD device - for now the SDK just exposes an AWT Frame - so I haven't spent any time on GUI layout. The VirtualBUG emulator also doesn't work properly on OS X, apparently due to a bug in Apple's implementation of Swing. The buglabs guys have been working on that one but for now I've fallen back to working with it on Debian Etch on my MythTV box, and it's working fine on that.

They had their first webinar with the beta testers on Thursday, but we're in the final throes of getting a release completed at work, so I couldn't attend. They've also initiated an application cook-off where they judge tester-created applications and award some prizes. I doubt my humble offering will make it too far in the process, but it was at least the first user-generated app uploaded to the site.

Right, I best be off for now; gotta remote into a customer site and do an upgrade soon. I'll leave you with the entry for my first app:

Last month I posted about backing up metadata for your Flickr photos using a simple little Python script. That script gives you an XML file for each photo with all that photo's metadata stored inside it for ready access. If you're a recent switcher to OSX, you might want to take advantage of that data to get your photos from Flickr into iPhoto.

Once you have iPhoto and Flick in sync, you can import new photos from your camera into iPhoto and then export to iPhoto using FlickrExport and they will stay in sync. Of course you may have no interest in getting your photos from Flickr to iPhoto, in which case feel free to stop reading. In my case, while I had the photos around, they were in multiple folders on my hard drive and didn't have any tags associated with them. On Flickr I had them tagged, dates corrected, and so on. Rather than recreate that process I decided it would be easiest to take what I'd done in Flickr and push it to iPhoto.

The linked AppleScripts below were mostly what I used to accomplish this process, again in conjunction with the XML files from the script mentioned in Backing up your Flickr photo info. Now some caveats: I had never used AppleScript before when I wrote these, and my copy of AppleScript: The Definitive Guide was still in the mail. If you know AppleScript you will be aware of how quite unlike most other scripting languages it is. The scripts below are undoubtedly not in best AppleScript style, and I didn't spend any time modularizing them, so you'll see common functions in each for XML parsing and so forth.

So with that said, take them for what they are and do with them what you please. Hopefully between them they'll give you enough to make a start on whatever iPhoto library-munging project you've decided to take on.

• Copy photo "date taken" information from Flickr to iPhoto
• Copy photo metadata from Flickr to iPhoto (title, comment, keywords)
• Download photos from Flickr and import them into iPhoto
• Change YYMMDD_N titles to YYMMDD_0N in iPhoto

In Windows CE 5 and earlier, each process is limited to 32MB of virtual address space. That 32MB has to hold your executable, your DLLs, everyone else's DLLs, your heap, and some other stuff. If you're on a plain Windows CE device the so-called 'DLL crunch' isn't always too bad, since the OEM only has to include what they want or need to include in the platform image. However, on a Windows Mobile device, the OEM has to include everything required to get LTK verification: Pocket Word, and all that fun stuff. That means a bunch of extra DLLs that eat into the available space in your process' slot.

In Windows CE 6, the limit was raised to 2GB, so you have much more breathing room (you are limited to 512MB of physical RAM, but still, what luxury).

So, what do you do if you're developing for pre-6 Windows CE and you run out of heap space for your application? Well, you can play some tricks with DLL load ordering, but that only gets you so far. One neat trick I rely on is what I like to call the 'LMA incantation'. It goes like this:
If you ask for at least 2MB, and you ask for it in a particular way, then CE will allocate that memory for you from the Large Memory Area. This is the area of memory above where the individual 32MB slots exist for normal processes. It's normally used for memory-mapped files (which is another way you can make use of the LMA if you need to).

Here's the incantation:

DWORD size = 2*1024*1024; // (or more)

void *p = VirtualAlloc(0, size, MEM_RESERVE, PAGE_NOACCESS);
p = VirtualAlloc(p, size, MEM_COMMIT, PAGE_READWRITE);

// optional:
#define LMA_START_ADDRESS (0x42000000)
assert(ptr > LMA_START_ADDRESS)

Now if you do this in one line rather than two, that is do the commit without the reserve, then you will get memory from your process' 32MB slot rather than the LMA, and the assert will of course fail.

This one has saved my behind on more than one project. Enjoy!

Notes:

• From the MSDN description of VirtualAlloc:
  

  In Windows CE 5.01 and earlier versions, if you call VirtualAlloc with dwSize >= 2 MB, flAllocationType set to MEM_RESERVE, and flProtect set to PAGE_NOACCESS, it automatically reserves memory at the shared memory region. This preserves per-process virtual memory.... Since CE 6.0, irrespective of the value of dwSize, kernel will always try to allocate VM in user process space. Also, user applications cannot call VirtualAlloc with shared heap address range (0x70000000 - 0x7fffffff) since this is read only for user applications and read/write for kernel mode threads.

• A recent article from CE whiz Doug Boling on CE memory architecture.

I'm honoured to have been chosen in the first wave of beta testers to get access to the BugLabs beta. I read about BugLabs in an Engadget blog post and it sounded intriguing: "An open source, web-enabled, modular software + hardware platform."

We're not under a formal NDA or anything, but we've been asked not to disclose URLs for the various components of the beta program, and so on, which is fair enough:

By the way, please keep these links to yourself, they should all be considered confidential to the beta program. You are welcome to blog about, chat about, Twitter about, text about, email about, or send smoke signals about the beta program, but please don't share the links or SDK.

They have bug tracking, forums and a WiKi already up and running, and they made an SDK available. The SDK includes VirtualBug: an emulator for the hardware, since hardware isn't available at this stage.



They built their SDK on top of Eclipse and I have to say it's pretty slick for things being so early. The instructions to get everything up and running are also unusually polished for a beta program.

There are a few sample applications that do real things, like post pictures to Flickr with geo-tagging. Some things are still necessarily in the mock-up stage until the hardware is ready, like the camera module (which pulls pictures from file rather than an actual camera) and the motion sensor (which 'detects' motion by you typing the word 'motion' into the Eclipse console).

Still, I'm very impressed at how it looks at this point. The few questions I've had have been replied to promptly in the forums and the folks at BugLabs all seem very helpful.

I'm still getting my feet wet in the SDKs, but I'll post updates as I make progress.

Gruber posted a link to Stephen Fry's new blog. Now I'm a big fan of Stephen Fry, and he's a good writer, but lo and behold he also happens to be a gadget freak and a Mac user to boot. I had no idea. He even had a Psion 3, one of my favourite PDA predecessors, and something I still keep around to play with now and again.

His first post is all about smart phones. Let's hope he keeps it going. I for one am already subscribed to his feed.;

So a while back, I signed up for the VMware Fusion beta. Shortly thereafter I started getting a ton of all the usual delightful varietes of spam through the address I have them. Now I use sneakemail, so the email address I gave them was actually a sneakemail alias that I set up specifically and solely for that purpose. Now that their mailing list has made it to the spammers, I can simply go into my sneakemail control panel and send that alias to the bitbucket. If you haven't come across sneakemail before, I highly recommend that you take a look. They have a free offering, but the real power is in the autoaddressing keys that you get with the paid account, which is only $2/month.

I'm surprised, and a little disappointed, that a company of VMware's stature would let their mailing lists get abused like this though.

For more C++0x fun, check out Herb Sutter's trip report for the July 2007 ISO C++ Standard meeting.

OnSoftware is putting out some pretty neat video podcasts right now. As a (predominately) C++ guy, I found the ones with Bjarne Stroustrup, Herb Sutter and Scott Meyers to be particularly interesting.

They're making me eager for C++0x to get here! I realize it's going to be a while though: to my knowledge, Microsoft still haven't said when Visual C++ will have TR1 support, never mind C++0x. I can live with getting my shared_ptr fix from the the Boost libraries for now, but having shared pointers fully and officially in the language, along with things like lambda functions, will certainly make life easier.

Note that you can get TR1 now from Dinkumware, and they'll likely be first to put out proper C++0x support once it's ratified (fingers crossed for 2009). P.J. Plauger and Pete Becker are very nice to deal. Indeed, we used Dinkumware on Windows CE 4.2 so that we could make use of streams. Unfortunately for our application, it's tough to justify the overhead of an alternate library, and we had problems on other people's devices that exported C++ APIs in their SDKs (they would export a function that returned a Microsoft std::wstring for example, which isn't binary compatible with a Dinkumware std::wstring so we'd end up wrapping their SDK in C: very ugly).

Fun little project for after the kids went to bed tonight: we picked up an old Western Electric Model 500 rotary telephone from boldoldphones.com via eBay. We chose the cheaper one, so we had to clean it. That was no big deal, and it was fun unscrewing the handset couplings like spies used to do in the old movies ;-)

I researched our exchange and found at Telephone World that it used to be called CYpress-5, so I printed up a little label using the 1942 report font, since it seemed fitting (well the 500 was introduced in 1949, and the coiled cable version is newer, but let's not split hairs).

Then, I'm ashamed to say, I had to find instructions on getting the finger wheel off to replace the label. Luckily, I found just what I was looking for at porticus.org.

The phone looks great, and it sounds fantastic: the bell could wake the dead, and really brings me back to the beige British Telecom equivalent we had when I was growing up. Best of all was my daughter's reaction to it, and walking her through the use of the rotary dial.

Parallels 3.0 Beta 2 (Build 5120) came out the other day. I updated my copy and checked to see if they had fixed the problem I've been seeing with Linux VMs assigned more than 512MB. Unfortunately, they haven't.

I'm running Slackware 12.0 in a Parallels VM with a vanilla 2.6.21.5 kernel. If I assigned that VM 512MB of RAM it runs just fine. If I give it 768MB or 1024MB, modprobe crashes on startup. Set it back to 512MB and it's happy again. I've seen other people have similar issues trying to get Parallels to run the server version of Ubuntu.

Parallels doesn't have this restriction with a Windows XP VM, so it has to be something they aren't emulating correctly for Linux. It makes me wonder if I ought to have waited for VMWare Fusion, as I use VMWare Workstation at the office a lot, but the beta wasn't even out when I bought Parallels. Ah well, 640KB512MB should be enough for anyone, eh?

A poignant article from Dave Dribin recommending against using SSH without a passphrase. (Link via Daring Fireball.) I am going to have to take a look at SSHKeychain as it looks pretty handy. As an aside, I just got done setting up a Slackware 12 VM on my MacBook and am using MacFuse via MacFusion so that I can edit files on the VM indirectly using TextMate. It works great with public key authentication.

RapidWeaver 3.6.3 just came out, which is the web site publishing application that I use. One of the new features they've added is support for SSH public key authentication for publishing changes to a site to your web server. This reminded me that I've been meaning to post a quick how-to on this under-appreciated feature of SSH. So here goes.

Back in the day we all used TELNET to connect to our servers. This was fine until bad people came along. TELNET sends your username and password in the clear, and so bad people started watching packets fly past and grabbed your account information out of the air. And then came Secure Shell, or SSH, which uses secure sockets technology to encrypt the connection between your client and server machines. No more password grabbing.

By default you use SSH pretty much like TELNET, where you specify your username and password every time you connect. However, SSH also supports public key authentication, which allows you to securely not have to enter your username and password every time you connect. Yes, this sounds counterintuitive but it's true.

What follows is a super-quick how-to. If you want more specifics check out Dave Aaldering's SSH with Keys HOWTO or the various man pages for ssh (try man -k ssh to see what man pages your system has for SSH).

To configure anything for SSH you need to create SSH's configuration directory, if you don't already have it. On your client and server:
mkdir ~/.ssh
chmod 700 ~/.ssh

The chmod is so only your user account has access to the SSH configuration directory. That's important. Once you have done that, you can proceed to creating your key. On your client:
cd ~/.ssh
ssh-keygen -t dsa

Accept all the defaults and specify a blank keyphrase when asked. You can include a passphrase, in which case the server will prompt you for this passphrase each time you connect. I'm assuming you want to skip that step, but feel free to specify a passphrase if you wish. The advantage is not specifying one is convenience. The disadvantage is that anyone with access to the console on your client machine will be able to access your server without a password.

You should now have a public key in ~/.ssh/id_dsa.pub and a private key at ~/.ssh/id_dsa. The public key needs to go on your server. The private key needs to stay where it is (this is what identifies you to the server and lets you log in without needing to specify a password). You may want to backup the private key file, since if you lose it you'll have to go through these steps all over again.

Transfer your newly-created ~/.ssh/id_dsa.pub public key file to the same directory on your server. Then on your server:
cd ~/.ssh
cat id_dsa.pub >> authorized_keys
chmod 600 authorized_keys
rm id_dsa.pub

This tells the SSH daemon on your server that you authorize clients that know the private key that goes with this public key. The >> appends to authorized_keys if it already exists: you authorize as many clients as you wish (one for your laptop, one for your home desktop machine, etc.).

Now that you've told the server it's okay for your client to connect using a key, try it out. On your client:
ssh server-username@server-ip

You should be logged in without being prompted for a password! If not, make sure that ~/.ssh has permissions of 700 and ~/.ssh/authorized_keys is 600. You may also need to tweak your server's SSH daemon configuration file. It's usually at /etc/sshd_config and the entry you want is PubkeyAuthentication yes.

Once you have it working, if you want to disable log ins with a password, so that you can only do it with your key, set PasswordAuthentication in /etc/sshd_config to no. Be sure you don't lose that private key once you've done this though!

Extra Credit

If your username is different on your client than on your server then create ~/.ssh/config on your client and add an entry like the following:

Server server-name-or-ip
User your-server-username

You can also add Port and Hostname entries for your server which can be convenient if you want to refer to the host by a different name when connecting (or if it a name if it doesn't have a DNS entry), or if the port is not the usual 22 and you don't want to remember to have to use the -p option to the ssh command. See man ssh_config for all the details.

I just watched the demonstration video for Linux MCE 0704, and it's pretty darn impressive. It is well produced and the set of features are very impressive. The low-resolution video is on Google Video:



There are higher resolution versions in WMV and OGM formats available via torrents from the Wiki downloads page. I downloaded the DVD ISO to play with it on my P4 linux box, but after the 2 and a half day download it failed the MD5 check. I burned it to a DVD+RW anyway, trying to be optimistic, but it failed a CRC check while untarring something. Oh well; I'll keep an eye on it and try downloading it again some other time. It's based on Kubuntu and integrated MythTV for PVR functionality. I've run a Myth box before but had some stability issues with it, so I'll be curious to see if things have gotten any better.

The new Fiire Chief gyroscopic remote control from Fiire that's featured in the video looks like a winner, but at $149 it's a bit out of my mad-money range for right now.

When I drank the Flickr cool-aid, I had to move all of my pictures from my home-grown Perl/CGI webserver setup. They uploaded to Flickr just fine, but quite a few of them had incorrect dates due to incorrect or missing EXIF information. Fortunately I had all of the image files named in the YYMMDD_n.JPG format, so I knew there had to be a way to fix their dates programmatically.

Starting from the python script I had previously written to archive my photo tagging information (see this post), I just had to add a function that used a regular expression to parse the date information out of the photos' filenames and call photos.set_Data in the Flickr API. The function is up on TextMate's pastie site for those interested.

My iLife '08 family pack arrived yesterday and I eagerly installed it on the G4 PowerMac (yes, it refuses to install the new iMovie on a G4, but that's for another day) and on my MacBook. I downloaded the iPhoto 7.0.1 update and started it up. It said it need to update my library and the process took hardly any time at all, in spite of being on the G4 and there being about 5000 pictures in the library.

Events
When the main window appeared I was presented with a surprisingly small number of the much-touted Events. On closer inspection it seems that Events, at least from an upgrade, are pretty-much synonymous with the old Rolls, albeit given equal billing with Photos in the sidebar and a very pretty facelift. This was a little disappointing. I had understood that events were created based on their date taken, not the date they were imported into iPhoto (who cares about that date). I often batch import several days worth of pictures. Of course iPhoto will let you split an event, but the whole point of Steve's pitch was that you didn't have to do it manually. What made this more disappointing was the 3000 or so pictures I imported when I switched; these all showed up as 1 event spanning multiple years.

Since I didn't feel like splitting that mega-event up, I decided to create events from the albums I had created. This proved to be a little clumsy, but perhaps I just didn't find the simplest way to do it.

For each album, I:

1. Selected the album in the side bar.
2. Selected all the photos.
3. Picked Create Event... from the Events menu.
4. Accepted the warning about photos only being in one event at a time. (which can silence after the first time)

This created an event. I could tell because the count after "Events" in the sidebar went up by one, but it left me with my pictures selected back in the album. I then had to:

1. Click Events in the sidebar.
2. Find the new Event (which fortunately was selected).
3. Edit the title of the new event and pick my key photo.

Moving forward this shouldn't be so tedious, but had iPhoto created events based on the date each photo was shot, I think it wouldn't have giving me a better starting point.

Tags
I use the excellent FlickrExporter to public my photos to my Flickr account (Fraser has updated it to use the new official Apple API in iPhoto 7 by the way). One of the many nice things about FlickrExporter is that it turns iPhoto keywords into Flickr tags. However, getting keywords added to photos in iPhoto 6 was a pretty tortuous experience; or it was until I discovered Ken Ferry's Keyword Assistant. With Keyword Assitant I just wouldn't have been able to contemplate keeping my tagging up-to-date. A few days ago, Ken posted on the Keyword Assistant blog:

I'm happy to report that I won't be updating Keyword Assistant for iLife '08 for one reason: The native keyword interface in iPhoto 7 is good enough that Keyword Assistant is unnecessary! You can enter keywords by typing, the keywords autocomplete, use of a non-existent keyword will implicitly create it, and you can assign keywords for an entire album without using the mouse.

And boy was he right. If you enable viewing of keywords in iPhoto 7, you can simply click in the space where the keywords are (or would be if there aren't any yet) and start typing. And I mean right under the photo in the main Photos view, not in the information popup in the sidebar. The keywords tab-complete, and you can use comma to accept one and start adding another, just like Mail does with contacts when you're addressing an email. Same goes for the photo's title: click on it and start typing.

Tab takes you to the next photo's title; tab again and you're at that photo's keywords. You can create new keywords inline and it doesn't say boo. Very very nice.

iPhoto Library a package
The iPhoto Library folder under /Users/username/Photos is now a package (so you have to right- or Ctrl-click on it and select Show Package Contents to get to your photos. iPhoto never really did like you poking about under its hood; I guess Apple want to make that even clearer with version 7.

Web Gallery
Now that .Mac accounts have been bumped to a health 10GB, I decided to give the new Web Gallery feature a go. Creating a Web Gallery album was straightforward and they look nice in the browser. I did noticed that in Firefox, the slideshow option's fade doesn't work: each picture flashes off and on alarmingly during the transition to the next one. In Safari 3 Beta 3.0.3 when the new picture fades it, the old pictures shows once then disappears. I didn't noticed either of these quirks with Safari 2.
Minor browser quirks aside, the new Web Gallery looks great. The drag-to-see-the-pictures-inside feature of events in iPhoto also works in the Web Gallery, and the thumbnail size slider too is straight out of iPhoto. Apple did a nice job here. I expect I will stick to using Flickr, but for others who don't feel the need to post every single photo of their kid for others to 'enjoy', Web Gallery looks like it will be just the ticket.

I gave up on my Perl/CGI scripted website for my kids' photos a couple of years back and moved them lock, stock and barrel to Flickr. It's a great service and I'm very happy with it. My initial upload was more than a thousand pictures, but I wanted to start out the right way so I tagged them all with people's names and so on. As you can imagine, this was pretty tedious, so I decided I would try and make sure I would never have to do that again. I did some digging around and came across the Flickr API. The authentication mechanism is a trifle cumbersome but some kind soul had already gone through the pain and posted a CC-licensed Python script that did most of the work. I messed around for a little bit and ended up with a little Python script that downloads an XML file for each photo in my photostream. The XML file contains all the metadata for the photo, including its title, description, tags, dates taken and posted. I run this script every week or so and it grabs the data for the pictures I've posted since the last time I ran it. This way I have all my photos' metadata in a parse-able form, so if Flickr should ever go away I can write something to parse the files and import them to whomever at that time.

I posted the script via TextMate's excellent Pastie service, in case anyone is interested. I had to strip out my Flickr API key and its shared secret (which you need in order to access the Flickr API) for obvious reasons, but it's simple enough to get your own from Flickr.

UPDATE April 3rd, 2008:
I had to update the script to pass the authorization token when looking up your username as it started returning "failed to find user". The updated script is linked above.

I received my PayPal security key a couple of days ago. It's a device that generates a different 6-digit PIN every 30 seconds. Once activated on PayPal and/or eBay you have to append these 6 digits to your regular password. If you don't, it will ask you for the PIN once you've entered your password. According to the Director of Account Protections at PayPal, who was interviewed on a recent episode of Security Now, this is part of Verisign's VIP network, which is to include banks and such. So you should be able to use the same security key for your online banking, rather than ending up with a pocketful of dongles.



The key worked for me to begin with, but then today both eBay and PayPal started rejecting the PIN I entered. Finally, PayPal made me go through the setup process again, to resync the server to the key's internal clock. Hopefully that won't happen too often. I also tried out the "I don't have my Security Key" option, and it just made me answer the usual security questions, so I'm not sure how much more secure the key is really making my account, but it's an interesting development nonetheless.

Apple has made good on its promise to bump .Mac accounts from 1GB to 10GB:



Maybe I will be able to do something with it other than syncing my Keychains and Address Book now. I use Flickr for sharing my photographs, but the new iLife '08 Web Gallery might be useful for sharing movies (I've never had much luck with YouTube: it always seems to end up mangling my videos too much).

I happened upon my Timex Sinclair 1000 the other day, while looking for something in the cupboard. I bought it a few years back on eBay because my very first computer as a kid was a Sinclair ZX81. The T1000 is basically the same but has 2K of RAM instead of 1K. I plugged it in and it still seems to be working just fine.



It's been an awfully long time since I've coded in Sinclair BASIC but I threw something quick together:



and behold its graphic prowess:

...wearing your EFF t-shirt on the day you happen to get a meritorious award for a patent disclosure.