Avian’s Blog

Recently I had an opportunity to see development labs of a few local hardware shops and chat with people working there. In addition to my recent work at the Jožef Stefan Institute it made me realize that, for someone familiar with development practices in the world of free open source software, the field of professional electronics development is quite lacking in some regards.

Interesting. The software world has long ago established a need for revision control systems, code review tools, bug trackers and release procedures. And rightfully so - as I often rant about here, most software is so complicated today you are basically forced to use of such tools to achieve any kind of collaboration or a usable quality level. While it's true that too often good practices are overlooked in commercial settings and deadlines and marketing given priority, at least most developers will tell you what is the ideal they strive for.

Compared to that it was somewhat striking to hear that manual checking over multiple-sheet schematics for differences is common practice. Or that proper revision control systems aren't required and that keeping multiple folders of versions was all anyone would ever need. Or procedures for making fabrication documents, equivalent to a software release, that take too many minutes of clicking various settings in a graphical interface.

Agreed, most electronics development done in small groups and companies is simple enough to involve only one person. It also involves simpler designs and nowhere near the layers of abstraction present in software. But on the other hand mistakes are much costlier here. If a botched software release these days means uploading a new package or even just updating some scripts on your web server, a broken prototype hardware design sent to manufacture wastes much more tangible resources.

One thing software developers learn is not to trust themselves. Any repetitive tasks should be scripted and should involve as few and as simple steps as possible. There should always be ways to double check your or your colleague's work. After a long work day I don't trust myself that upon saving a file I only made the changes I wanted and didn't accidentally drag an odd trace out of place while I was experimenting with layout. I don't believe that I won't forget to check that critical check box in the GUI the tenth time I will be exporting Gerber files. And most of all, I will never be sure that when comparing two PDFs centimeter by centimeter and line by line I won't miss a difference.

Not surprisingly, voices to improve this situation are being heard as open hardware philosophy becomes more widespread. Some of the blame here certainly goes to the lack of tools that would allow such processes. It appears that if you want to have them out of the box, you either need to go for some very expensive proprietary software aimed at large teams and huge projects, or funny enough, free software tools like gEDA.

More concretely, CadSoft Eagle, the software most used for small projects and not that uncommon also in the open hardware community because of its low cost, has a distinct lack of such capabilities. Having just finished my first design in it and finding out all of the above, I tried to change a few things for the better.

Hence, eagle-automation. It's a small collection of Python scripts that currently allow you to do just two things:

• Make a set of fabrication documents from a single Makefile without clicking on a single dialog (with credits to Andrew and his blog post).
• Do visual diffs between revisions of schematics and board layouts stored in git, like the one shown above

The installation is as simple as the usual Python setup.py install dance (you need Python Imaging Library) and the git integration uses git-difftool which is present in recent versions of git. For the rest I refer you to the README file. Apart from finicky Eagle scripting it's quite simple actually.

So, most of all, I hope this will make open hardware development easier and more reliable. I will still strive to use open tools like gEDA as much as possible - with which, by the way, I never had much use for visual diffs because of its human readable ASCII file format - but I also understand that a lot of people are stuck and will be stuck for some time behind proprietary tools. But I don't see that as a reason why lessons learned the hard way by the software world should not be reused.

I noticed that a lot of talks and presentations I attend, especially in the more academic circles, begin with the speaker showing a slide with the outline of the talk in form of a bulleted list and talks through it, explaining what he will talk about. With short talks this can actually take a significant part of the total time, especially if the speaker returns to that slide after each part, showing how far into the talk he progressed.

What is the point of that, short of giving the audience an opportunity for one last glance of their email client? The purpose of such an overview in printed articles is to give the reader some idea of the contents. This means that you can skip reading it altogether and move to the next article if the table of contents doesn't give you enough confidence that the article will be of use to you. Via page numbering it also allows you to skip directly to the interesting part, should only a part of the document be useful.

None of these uses apply to the spoken word though. You can't fast forward to the interesting bit and if you find that the talk won't be worth your time after the introduction it's usually considered quite rude to walk out at that point. As is browsing the web waiting for the part the interests you.

Some may argue that the table of contents makes the slide stack more readable in stand-alone form. I don't buy that - slides are part of the presentation and I don't think any consideration should be given on how useful they might be without the accompanying speech. It's 2012 after all and making at least an audio recording with cheap equipment shouldn't be science fiction anymore.

Photo by lowk3y

Last Tuesday I gave a talk about my 433 MHz receiver project at Kiberpipa's Open Sessions. I presented what I learned about the radio communication between cheap, simple everyday devices, described the receiver hardware and software and did a live demo.

I think the talk was well received and although I didn't go much into the security consequences of some of my finds the Q & A session that followed made it clear that it wasn't really necessary.

A few minutes ago I also uploaded the version of the software that I was using during the demo. Compared to the 0.0.1 version which I put on-line during the 28C3 it contains some minor fixes for the software demodulator and a bootstrap script that (hopefully) compiles everything in one step.

If you missed the talk, the video recording of it is already on-line thanks to the efforts of the Viidea team. You can either download it or watch it in the web browser synced to high-res slides at Kiberpipa's shiny new video archive.

28th Chaos Communication Congress is much more than just the things that are neatly listed on the Fahrplan. If the safety personnel would allow it, the halls and walkways would be filled to the top with all sorts of more-or-less identifiable hardware, interspersed with empty bottles of a certain caffeinated drink. Some of it was there just for display or for sale in kit form, some was being actively developed or disassembled and some was a target for scheduled and ad-hoc workshops. Sharing ideas by participating in this chaos is a big part of the congress.

Hacked Brother KH930 knitting machine by Fabienne

This year I had the feeling that there were many more low-level hardware projects going on than last year. As with previous events there was a large hardware hacking area in the basement, but portable oscilloscopes, multimeters and soldering irons were a common sight also in the hackcenter and the hallways. Arduino workshops were absolutely packed and I escaped from the room each time they started to run away from the crowd. The well-known Linux distributions and other free software groups occupying their usual places at the Berliner Congress Center almost felt pushed aside.

The r0ket badge, introduced at the CCC camp, was back. The version 2.0 with some minor improvements was available half-assembled at the info desk for 30 € and was sold-out in minutes. There was also a new official firmware image available with which you could play Tetris on a big green LED display at the hackcenter and control a few other things around the congress. In combination with the tiny joystick that practically guaranteed a sore thumb for everyone.

Speaking of sore body parts, a special kind of attraction was the PainStation, an exhibit from the Computerspiele Museum. It's a Pong clone where missed balls result in pain being inflicted on your hand through heat, electric shocks and a mechanical whip. Since you had to sign a disclaimer to play with it I guess it wasn't very forgiving. I didn't give it a try under the excuse that I'm already being shocked frequently enough in my profession. Considering that in the end one third of medical emergencies at the congress had a connection to this machine maybe that wasn't such a bad idea after all.

Jure and I spent some time trying to find a problem that this little device would solve. It's a TP-Link TL-WR703N, a tiny portable wireless router that is capable of running OpenWRT. For around $20 you get a MIPS system with 4 MB of flash and 32 MB of RAM storage, 802.11 radio, wired Ethernet, USB, serial and at least one GPIO port. Certainly something worth considering when the next idea comes around that needs Internet connectivity in a small package.

Next on the list of tiny things is the MC HCK, a very basic open hardware ARM Cortex M0 board that is little more than a microcontroller on a PCB that fits into the USB socket. I thought it's hard to get more basic than an Arduino, but this certainly proved me wrong. Simon (who also let us borrow the TP-Link board above) is trying to get it down to $5 per board.

I should also mention, that I had a nice chat with a developer from the Sigrok project. They are developing a portable logic analyzer software that works with a wide range of different hardware devices. I've been missing a good logic analyzer and I got some good advice on which hardware capture device works best with Sigrok.

Congratulations go to the Network and Phone Operation Centers. Wi-Fi was working surprisingly well this year and I mostly didn't have problems keeping a link up for IRC chat or an occasional website load. It was slow but stable except in Saal 1 when it filled up. Eventphone GSM network also worked the few times I attempted to use it. Only an occasionally a General error popped up on my N900. The only complaint would go to this year's Wiki, which had a somewhat unusable theme and was down a lot.

By the way, I learned that stability of the 802.11 link in this environment depends largely on what drivers you use. On my aging Eee 901 with the Atheros chip for instance, the ath5k driver that comes with recent kernels can barely keep the link up for a few seconds before dropping it and forgetting all the iwconfig settings. On the other hand the old madwifi worked almost perfectly.

All summed up, this was one of the best congresses I've attended. There was always something to do and it never happened, as it did occasionally at the previous events, that there wasn't an interesting talk on the schedule or interesting people to talk with. Unfortunately I didn't manage to prepare a lightning talk about my 433 MHz receiver project before the trip to Berlin and once I was there everything went by so fast I didn't even manage to finish my slides.

Again, thank you CCC and all of the Angel volunteers for the wonderful event and see you next year!

It's been two days since I returned from the 28th Chaos Communication Congress in Berlin. Enough I guess to recover my sleep cycle and detox from Club Mate and other caffeinated drinks. Those were also the primary reasons why I didn't feel capable of writing a coherent blog post about the happenings inside the Berliner Congress Center during the congress. However, I do have a ton of notes and I'll try to share my thoughts on the congress in a few retrospective posts.

The best way to start would probably be at the talks. Two of those have circled the web and I can't add anything that hasn't already been said about them: How governments have tried to block Tor by Tor project developers Jacob Appelbaum and Roger Dingledine rightfully received a standing ovation while Cory Doctorow's The coming war on general computation had a fan-made transcript within hours. Both are well worth a look, including the Q & A sessions that followed.

GSM and mobile phones remain in the focus of security researches and reverse engineers. Karsten Nohl released a set of tools for assessing the security of calls made through your local mobile operator and an IMSI catcher detector. Both require only an OsmocomBB-compatible phone and I would love to see how Slovenian operators score on the former. There was also a very interesting talk by Guillaume Delugré on Reverse-engineering a Qualcomm baseband. In a flawless demonstration he showed how he managed to inject a GNU debugger compatible interface into a proprietary real-time OS running on the baseband processor inside a USB 3G dongle. We might soon see a OsmocomBB equivalent for UMTS based on this hardware.

Outside of the limelight there was the usual spectrum of talks on all sorts of topics. Continuing the CCC camp's hackers in space theme there was the unveiling of the new lunar rover by the Part Time Scientists team. The work they are doing on their hardware is impressive to say the least, however the presentation they gave was somewhat poorly prepared. Inviting questions from the audience with cheap give-aways might work on disinterested college undergraduates, but it just looked silly with this crowd.

Anyone dealing with wireless networks will probably be interested in Packets in packets talk about how the noisy nature of a radio link can be exploited to attack security of low level code even if the attacker only has access to protocols further up the OSI stack. And talking about security, Peter Eckersley of Electronic Frontier Foundation presented their Sovereign Keys proposal for fixing the current, broken situation regarding SSL certificate authorities.

Old home computers are still a popular topic, as proved by the Atari 2600 and the Commodore 64 demo talks. So is Bitcoin, although I haven't heard anything about this electronic currency I haven't seen before.

Leaving computers aside for a moment, there was also an interesting talk about Eating in the Anthropocene, which had a refreshingly rational approach to the topic of genetically modified organisms. These are usually automatically considered evil, even in the population frequenting this kind of events.

On a similar note, I should also mention something that happened on the final track of lightning talks. One of the speakers ringed all the bells of a new-age pseudo-scientific nonsense. While the IRC channel immediately exploded with skeptical remarks, the real-life audience actually patiently waited for the end of the four minute slot. A few people then gave a courtesy applause and the rest of us expressed our disagreement. Nick Farr, moderator for the session and otherwise a very respected member of the congress organization team, scolded us for not respecting the speaker's effort and gave the speaker an extra minute that was otherwise reserved for well-received talks. I think speaker was shown enough courtesy by giving him an equal opportunity to make a convincing case for his negative-ions-atmosphere-fertilization thing. Giving him extra time in my opinion showed lack of respect for all of the other speakers before him that presented more sensible topics.

Finally I should also mention there was an unscheduled panel on depression, motivated by the recent suicide of Diaspora developer Ilya Zhitomirskiy. It focused mostly on personal stories, but the IRC discussion it triggered raised some questions I would very much like to see discussed more in-depth, like how much is depression correlated with the hacker culture and motivations behind it.

This more or less covers the talks I attended and found worth sharing. Of course, you can find the whole list of talks, plus official video and audio recordings, on the Congress Wiki.

This year quite a few of the more security-oriented technical talks moved to a smaller, parallel event called BerlinSides at the other end of the city. I would certainly attend a few of the talks scheduled there and some actually choose to hop between the two events. However in hindsight, I didn't miss them at 28C3. The better selection of talks meant less of the bad feeling that I'm missing interesting presentations in the upper floors and more time socializing and doing other awesome things in the hackcenter. But more about that in the next part. Stay tuned.

I got a few questions about what I'm working on at my new job at Jožef Stefan Institute, so here's a short story about that.

Approximately a month and a half ago I joined the team working in the laboratory for wireless sensor networks, or SensorLab as people around here call it. They have been developing their own software and hardware for a year or so and have come up with a impressive collection of tools for gathering data from a large network of small sensor nodes.

At the core of their efforts was the VESNA platform, a wireless sensor network node with cute female name from Slavic mythology. It's a small, modular microcontroller system built around an ARM Cortex M3 chip from ST microelectronics. At the center is a core board with the CPU, non-volatile storage and power supply. Then there's a connector to the right that connects to one of a collection of radio modules that take care of different communication needs. Finally there's an Arduino-like general purpose shield connector on the top and bottom that can carry application-specific expansion modules, for instance with specialized hardware for sensors that cannot be served by the general purpose IO and instrumentation amplifiers on the core board.

When you are mounting hundreds of such boards in places that were never meant to carry any electronics, getting power to each sensor gets problematic very fast. So one of the main features of VESNA is power provisioning. In addition to requiring very little power to begin with, the core board carries a very versatile power supply that is capable of efficiently harvesting power from a solar cell or a range of external voltages. You can also connect a rechargeable battery to it and it will weather through nights or other power shortages.

Since you can't yet depend on having UTP cables at each and every place, communications are mostly based on radio (hence the wireless in wireless sensor networks). Radio boards are built around several multi-purpose chips that can use a number of regimes in the ISM bands, from proprietary schemes to IEEE 802.15.4, from star topology to mesh networks.

On the software side there's also a lot of interesting things happening. Guys and girls at SensorLab have been developing their own C library for VESNA peripherals, which you can use to compile and run bare-bones programs on the CPU. For simpler applications there's an Arduino compatibility in the works while heavier applications might use a port of the Contiki operating system, which allows you to access sensors through web-friendly REST interfaces on a 6LoWPAN network.

An the best part of it is, most of the things I described are going to be released under a free, open source license in the following year, since we are hoping to build a lively open hardware community around this project. The internet of things is the new buzzword you know and there are plenty of IPv6 addresses to go around. We think VESNA will help you make good use of at least a small part of them.

It's almost that time of the year already. You know, to chat with fellow hackers over a bottle of Club Mate, pile up a fresh amount of sleep deficit and draw a line under this year's happenings at talks and workshops.

Yes, this means that in exactly one week I'll be flying to Berlin to attend the 28th congress together with the same group of guys from Kiberpipa as last year. This year I hope to bring a bunch of portable radio hardware with me to test and experiment with: the 433 MHz sniffer is certainly going into the bag, as well as the Funcube dongle and most likely also a handful of wireless sensor hardware I'm working on at my new job.

Perhaps I'll manage to schedule a lightning talk about some of that stuff. Anyway, if ISM band transmissions hacking sounds like fun to you, give me a call. In addition to all the usual means of communication I'll also be accessible via the 9-8087 extension on the Eventphone GSM network.

Communities developing modern open source and free (as in freedom) software now have more than 30 years of experience behind them. During this time software licenses like the GNU General Public License, BSD license and a small handful of others have seen such wide use that they became de-facto standards when it comes to releasing code to the public. Although there are still some gray spots regarding legal issues, as a document from Free Software Foundation Europe nicely explains, the community has developed some stable views on what is acceptable and what isn't under those licenses.

Logo by Mateo Zlatar

The situation is somewhat more complicated in the field of hardware. Hardware mostly falls outside of copyright law that makes software licenses possible. There is a fuzzy line between uploading a RTL design to a software-programmable circuit and etching a printed circuit board based on a schematic, but generally imposing restrictions on manufacturing and distribution of physical objects falls under the domain of patent and trademark law. While in most countries the author of a creative work is automatically granted copyright free of charge, patents and trademarks that would allow you to set any specific rules for use of your design documents are neither automatic nor cheap.

If you look around, practically all popular open hardware projects ignore this issue and simply apply either a software license like GPL or a Creative Commons license to their design documentation: for instance, RepRap decided on GPL, while Arduino uses Creative Commons Attribution Share-Alike for their board designs. This doesn't always have the desired effect though. For instance when someone sells products based on a modified design under GPL, he doesn't need to provide the modified documentation nor credit the original author, since he is not distributing their copyrighted works.

There are attempts to address this issue. First of all, there is now a draft of the Open Source Hardware Definition that aims to be what Debian Free Software Guidelines are for software, outlining the basic requirements that need to be satisfied before a design can be called open source. There are also several license texts that attempt to focus specifically on hardware projects. Ones that appear the most complete and widely used are the TAPR Open Hardware License from the Tuscan amateur packet radio group and the recently released CERN Open Hardware License from the European organization for nuclear research.

Both of these, however, contain some terms that might be surprising for anyone used to software licenses. For instance, both require you to make some reasonable effort to contact the original author or authors when distributing derived works or manufacturing products based on their designs. While a nice provision for one-man efforts, this puts an upper bound on how large a project using this license might become. Imagine trying to contact all the contributors to the Linux kernel today. TAPR has even more terms that limit its scalability. For instance, it specifically requires attribution on PCB artwork, which can waste costly PCB area. It also requires you to distribute "before" and "after" versions of all modified files, which can again become quite unwieldy when you have to distribute the whole history with every copy.

On the other hand, what I miss in these licenses is stronger terms for practical modifiability. While GPL clearly defines that source code must be in the preferred form of the work for making changes in it, TAPR merely says that you must also include open format versions (such as Gerber, ASCII, Postscript, or PDF) if your tools can create them. The openness of the format does not however make the design easily changeable. In fact, all of the listed formats can be compared to a compiled binary in software world. CERN license makes no such constraints at all, but then, neither do Creative Commons licenses, so all are more like the permissive BSD license than the GPL of the software world in that respect. Modifiability of the hardware design files is arguably less important than having source for a binary computer program, since even a PNG image of the schematic will enable you to understand the design, but if you want to have a lively community around your open hardware project, I think keeping designs easily modifiable is a must.

Given all of the above, I find that currently existing open hardware licenses still fall short of specifying good terms for redistribution of the documentation. While they do state the top most requirement for open hardware, that documentation for physical products must be shared, I think it's questionable whether that is actually enforceable in the way specified. From what I've seen, CERN license shows the most promise of addressing these issues and I will closely follow the happenings around it. In fact they already have a list of issues to be addressed with the next version that more or less covers all of my concerns, so I'm keeping my fingers crossed. In the mean time, I'll probably stick to GPL or Creative Commons for my projects involving hardware designs.

I've written before about the Funcube Dongle Pro. Apart from receiving satellite telemetry and amateur narrow-band FM, it can also be useful as a poor man's spectrum analyzer.

I'm not talking about doing a Fourier transform on the baseband data. At around 80 kHz that's not really useful if you want to see the big picture, for instance when measuring spectrum of a DVB-T transmitter with a channel width of around 6 MHz.

What you can do however is to emulate a swept-tuned spectrum analyzer. You sweep the Funcube's tuner through the range of frequencies using steps of several tens of kHz and pipe the baseband stream to a software power detector. Then you can plot the received signal strength against the frequency and get a fancy graph like this:

Of course, there's a catch. Funcube Dongle uses an audio codec that is connected to the user space through the ALSA interface. This means that after you change the tuner frequency the sampled data needs to go through plenty of big buffers before it gets to the detector.

So while the actual hardware might settle very quickly to the new frequency (I don't have data for the E4000 chip used in FCD, but other comparable tuners have channel change times in the order of milliseconds), software buffers limit the minimum sweep time.

For instance, this is what becomes of the picture above when you are not waiting enough time for the buffers to flush between (random, in this particular case) frequency hops.

It takes around 5 minutes to draw such a persistence plot with the bandwidth of 20 MHz, 50 kHz hops and 10 passes. So don't expect to get anywhere near the theoretical limit for sweep time versus resolution bandwidth.

You can get the Python source from the git repository below. It requires a recent GNU Radio installation, FCD source block and matplotlib.

$ git clone http://www.tablix.org/~avian/git/fcd_scanner.git
$ python fcd_scanner/fcd_scanner.py --help
Usage: fcd_scanner.py: [options]

Options:
  -h, --help            show this help message and exit
  -d DEV, --device=DEV  Use Alsa DEVICE for FCD access
  -c FREQ, --center=FREQ
                        Center frequency in kHz
  -s SPAN, --span=SPAN  Scanning bandwidth in kHz
  -t ST, --sweep-time=ST
                        Time for one frequency sweep in s
  -g GAIN, --lna-gain=GAIN
                        LNA gain in dB (default 10)
  -p STEP, --step=STEP  Frequency step in kHz (default 25)
  -n N, --pass=N        Number of passes (default 1)
  -o FILE, --output=FILE
                        Write measurements to FILE
  -l, --line-plot       Draw a real-time line plot
  -e, --pers-plot       Draw a real-time persistence plot

With a new job comes a new work laptop. Last week a shiny new Hewlett Packard EliteBook 8460p was waiting for me on my desk at Institute Jožef Stefan.

From the outside it's one of the prettier PC laptops and it's hard to say HP industrial designers haven't looked at Apple for inspiration. Aluminum case dotted with small white LEDs, chiclet keyboard, black bezel around the screen, a round HP logo on the back of the display. If you've seen a MacBook Pro you can probably see the similarity. However, good looks don't necessarily mean good design and HP made some weird decisions that I find hard to believe for a machine that costs more than 1600 €.

First of all, I might say quality control seems a bit lacking. Left and right mouse buttons were out of level just enough to look sloppy. The "a" key keeps falling out. There's something wrong with the latches on the docking station since the cracking noise they make when I take the laptop off always makes me cringe. There are also some unfortunate design decisions: each time you pick up the laptop from the table you basically lift it up by the DVD drive door, which I fear is not good for its longevity. The Apple-like LEDs that shine through (laser-drilled?) holes in the aluminum are quite hard to see unless you bend down to the table and look directly at them.

What about the software side? Linux Laptop Wiki has some general information that gives a good overview of Linux support for this laptop's hardware.

Out of the box the disk had all 4 primary partitions already used. Sadly I had to retain the Windows installation, so I only deleted two partitions at the end of the drive that looked like they contained some HP restore and diagnostics software. Debian Squeeze installer then shrunk the remaining NTFS filesystem without further problems and Windows seemed to have survived the operation without any noticeable damage.

Getting the installer to boot however did take some experimenting: the laptop has 4 USB ports and will happily boot off a USB key in any of them. However for some reason all except one on the right with a thunderbolt icon are turned off after the boot. So unless the installation USB key was in that drive, the installer couldn't find the installation media. Funny, since after installation all USB ports work without problems.

To get the Radeon HD 6470M running in xorg I had to install a newer kernel from Squeeze backports (linux-image-2.6.39-bpo.2-amd64) and a newer Radeon driver (xserver-xorg-video-ati 1:6.14.2-1). The card also requires non-free firmware, which is shipped separately in the firmware-linux-nonfree package. Without it you will only get military-grade noise on the LCD panel. For 3D acceleration you also need libdrm-radeon1. With this setup everything seems to work fine except setting the display brightness (there's a kernel bug already reported): manual setup through the sysfs is ignored although the interface is there and I don't even know how to approach the ambient light sensor.

By the way, I've heard complaints about the low quality of the LCD. Mine looks great and makes my EeePC 901 look pretty dim in comparison.

Regarding other periphery, there is not much to say. Wi-Fi works with Intel drivers and requires firmware-linux-iwlwifi. Compared to the Thinkpad monstrosity the dock is only a bunch of hot-pluggable USB devices, which means no additional headaches there. Web-cam for some reason isn't detected automatically and you need to insert uvcvideo kernel module manually for it to work.

The power consumption hovers around 25 watts at idle, which is 10 watts more than when booted up in Windows. With that battery lasts a little bit more than 2 hours. This might have something to do with that kernel PCI Express power consumption bug. Setting power saving profiles on Radeon doesn't affect the battery drain which makes me suspect that power management doesn't work there either. Also, GNOME power manager crashes because of an empty second battery bay. I've written a patch against the version shipped in Debian Squeeze, but I'm not that optimistic it will get applied, since it's now sitting in the bug tracker right next to another patch I've made 3 years ago.

I should also mention the weird phenomenon where the computer freezes for several tens of seconds sometime after boot. There are no kernel messages logged about that and it doesn't seem to affect the running processes. I've seen such freezes on my old Thinkpad and on the EeePC, but they were always connected to IO contention. These freezes occur on an otherwise idle machine and the HDD light remains off, which makes me think they have some other cause. Also, a colleague with the exact same hardware and the latest Ubuntu version isn't seeing this, so I'm guessing it has something to do with my setup.

As you can see, after a week with this machine I have very mixed feelings about it. On one hand the aluminum case gives you a solid feeling. I love the dead simple screwdriver-less access to all the components inside, Linux support is pretty good and of course I don't have any complaints about the performance either. But seriously, shipping a laptop in this price range with a broken keyboard, dock and cheap-looking track pad?