So, I finally got my hands on an Eee. There's only one store over here that sells the Linux version of the 901, which is the only model that has exactly everything I'd want from it. Here are my experiences with it so far.

I've played with it for a couple of day now, and am very happy with it. It came with Asus's own software based on Xandros, which was not really to my liking; the software I use most isn't directly available, and the default interface could be a bit slicker. It did boot really fast though.

So I threw that out and installed Ubuntu Eee . This is very much a work in progress, and therefore a lot of features you really want from a laptop/netbook don't really work out of the box. However, the sheer power a 'general' Operating System gives you, while still directed at such specific computers, is great. Also, since the Eee seems to be pretty popular, and there is still an overseeable number of different configurations, people tend to run into the same problems, and most are easy to find and fix.

Here are the ones I ran into so far:

By default, the Fn-F5 combination does not work. It doesn't do anything at all. Here is a wiki page describing how to fix this. When you have done this, it is also trivial so change the default resolution it uses, and as a bonus, you get to learn how to do it manually, if needed.

Switching the wireless off using Fn-F2 crashed the system. Yes. Crashed. The. System. This was quite a surprise, to say the least. Turns out that the internal driver somehow screws things up if the wireless networking interface is still up. The default scripts do bring it down, but apparently the chipset has been changed between Eee versions, and the wrong interface is brought down. So, replacing the ifconfig down statement with the correct one fixed this. Again, a little bonus is that you get to tweak how the switch button works (for instance you can decide whether bluetooth should be shut off too. I think i got the information from the comments on this bug report.

Hibernation did not work either; after the default install, the swap space was too small to store the suspend data. Recreating another swap space on the second disk did not work for me either; it somehow immediately seemed to start up again. I got around this by installing the uswsusp package. Now hibernation works fine. This was pretty important to me, because Ubuntu Eee boots a lot slower (about a minute from cold start to a logged in state where you can start to actually do anything). Getting out of hibernation takes about 20 seconds now.

The final problem I encountered, and for which I unfortunately have no fix at this time, is IPv6. It appears to support IPv6, and gets both a link-local and a global scope address. The routing table seems fine, and ICMP works. But unfortunately, TCP does not; I did some experimenting with netcat and incoming packets are handled just fine, but it will not send out any tcp packets at all. They don't even show up on a local tcpdump. I did notice that the iptables modules for IPv6 were not loaded, but loading them did not seem to work. I will continue to play around with this and if I find a solution I'll post it. In the meantime, please let me know if you have one :)

Apart from these issues, or maybe even because of them, I am very happy with my little netbook. It is a lot snappier than I dreamed of hoping for, and with Ubuntu Eee, it has a really nice interface. The battery life is also amazing, so if you are on the road a lot, or just fancy a really tiny laptop that can still do some pretty heavy lifting, and if you are not afraid of doing a little work to get the most out of it, I heartily recommend the 901.

Here's another one from my software wish-list, a full implementation of PKCS#11 as a software library.

Let's do this as a little brainstorm, in the form of a small FAQ.

A software implementation of an API that is designed for hardware interaction... For the love of crypto, why?

Very good question! The reason I'd like to see a software implementation is simply because not everyone has cryptoki hardware available at all times, or maybe even not at all.

However, in order for libraries or other products to support cryptoki hardware, one would have to either make an elaborate plugin structure, possibly depending on multiple cryptographic libraries, and perhaps even implement it's crypto multiple times using different API's.

Of course, one solution is to take a general crypto API such as the very nice OpenSSL project. However, due to its design and implementation, getting it working may be a little more work than one would expect.

So, a completely new crypto library then?

Yes, well, hmm. Implementing all the algorithms is probably going to be a problem; this stuff is hard. So we could make it depend on another library. Again, OpenSSL comes to mind. But that would pose a possible problem; why create a library that implements an API that is then again possibly used by one of the libraries that it uses?

So a more 'light-weight' crypto library would be nice. Or maybe the cryptographic functions should indeed also be implemented, thereby keeping the number of dependencies low.

So how would it work?

It might be necessary to provide a daemon service; it can store keys and other data in it's own location that is not readable by other users or software. On the other hand, having yet another service running on a computer that may or may not want to use cryptographic function through this api might be a bit much, so another solution that does not have continual state would be nice.

And when exactly will this be done?

Just a little while after somebody decides to build it, of course! Or maybe a long while. Until somebody (which very well may be me, if i find the time, and the energy to get to it) actually makes a start, it certainly won't be done.

So here's one idea:

An OpenID 2.0 Library, in C minor.

There are already a lot of implementations of OpenID, but none of them are done in C. Now this might not be the first language that comes to mind when one thinks about it implementing it, especially since OpenID is (at the moment?) mainly targeted at blog-style web sites, which are often programmed in languages like Ruby, Python, or Java.

But there might be just a target for a C implementation; it could be light-weight, and perhaps a little faster, though this would not be a design goal it could be plugged directly into webservers like lighttpd * it could be used as a basis to create libraries for other languages, since most languages seem to have C-hooks to create API's

For instance, what I'd like to see (i actually had a working version of this for OpenID 1.1, just never got around to polishing it up and releasing it, and now it's a bit stale, to say the least) is a plugin for lighttpd and/or apache, that uses OpenID as the underlying mechanism for http authentication.

When this is used instead of any http-auth modules, scripts and websites that rely on the authenticated-user value in the web server, don't have to be changed, and they can support OpenID.

Okay, one of these days I'm going to misuse this news page to put forth some wishes, or other things I would like to do or see done in the near future.

I'll keep the topics to possible software projects, not unattainable stuff like world peace, or finding true love.

The idea is mostly to sort my head around various ideas I've got floating around in my mind for quite some time now, and maybe sorting them out and putting them down will get me far enough to actually start doing some of them. Or, alternatively, drop some of them altogether, so my head has more room for other stuff.

If anyone thinks some ideas are better than great, and would like to either do them or start some form of collaboration, drop me a line.

Of course I'm not going to put one up right away, if you're interested, just check back in a few days.

Legend of color of LED lights:

• Green On
• Red Error
• Orange Busy
• Blue Modern