Harald Welte's blog

Nokia, FOSS, SIM Locks, DRM and the universe + Motorola's failure

As Bruce Perens points out at this blog entry, it is very much possible to design a product, particularly an embedded Linux device such as a mobile handset with all the usual bits and pieces (DRM for mobile media content, SIM locks, etc.) while preserving the freedom of Free Software.

I'm really pissed off by the kind of FUD that big vendors try to spread about it. There are so many claims that the user has to be locked down, that he cannot be allowed to modify/replace the Linux kernel or other bits of the software stack, etc.

I can only agree full-heartedly with Bruce's article. Such claims are all bullshit. I've worked for a long enough time with Free Software, the Licenses involved, the legal framework of those licenses (Copyright Law), the Hardware Industry, lately even a mobile handset manufacturer. I've seen the software and hardware architecture of a number of phones myself by reverse engineering. Never have I found any reason why the bright-line philosophy (see Bruce's article) should not result in a perfectly working, all-interests-satisfied solution.

Let me use this opportunity to point out my disappointment at the failure of Motorola to solve this problem properly. Instead of designing their MotoMAGX family of handsets in a way that preserves the freedom of the Free Software [community, users] and protects their valid business interests, they chose to go the easy shortcut of walking borderline on what they think the GPL permits them: They use cryptographically signed kernel images, a bootloader that only accepts binaries signed by them, plus a kernel that only accepts signed modules, plus a SELinux locked-down userspace that is very restrictive on what userspace programs can still do.

This would all be nice and good _if_ they were to provide the user with a way to either sign his own kernel images with their key, or (better) to store his own signature in the bootloader. So the hardware would accept Motorola-signed kernels and kernels signed by the user (actual owner!) of the device.

The further proprietary bits of the software stack required for DRM protection can simply refuse to operate if not run under a Motorola-signed kernel. Especially with TPM's and similar technologies becoming more widespread in the mobile world, there is a very straight-forward solution to this problem. The bootloader can store the hash of the kernel image in some TPM protected register, and the proprietary DRM system can refuse to operate if the hash is not the original one.

With regard to SIM-Lock, Operator-Lock and all the other locks: As Bruce points out, those are restrictions of the GSM/3G modem. All implemented in the firmware of this device. It doesn't matter if you run Windows Mobile, Symbian, Motorola's own locked-down Linux kernel or a custom user-built Linux kernel on the application processor. The various GSM/3G related locks are never implemented on that processor, but on the baseband side.

I hereby challenge the mobile industry to come up with hard, technical fact about what particular problem they have in designing open, FOSS-compatible devices, where every user can modify and/or replace the FOSS programs, while ensuring the integrity of their DRM, IPR, SIM lock and other business model related technologies. I will sit down and look at any such issue brought forward and I'm extremely confident that for all of such problems there's a straight-forward technical solution (bright-line in Bruce's terminology) which will not require the proprietary or FOSS side to make any sort of moot compromise.

If not only for the reason of legal safety and security, such solutions should always preferred to going borderline with FOSS licenses or against the FOSS developers and users community!

Persistent Google recruiters suck

I think I've read this before by one or the other Linux/FOSS developers blog: Googles persistent recruitment sucks. At least I've spoken with a number of well-known developers in the community, and they all have been contacted before.

What makes the situation even more difficult is that there are apparently different recruitment teams, so sometimes they want to hire you in Australia, sometimes somewhere else. I've heard rumors that they now have a company-wide blacklist, and I've asked a number of times to not receive further recruitment mail, so I should be on that list by now.

The worst message arrived today. The particular recruiter actually _knew_ that the same department had last contacted me six months ago, and that I was completely not interested. But she was hoping that by now my mind or my job situation had changed, and that she would want to talk to me about employment options at Google.

I'm now really running out of options. I've tried to state it politely a number of times over many years that I am not interested and do not want to receive further emails. As if this wouldn't occur to me automatically, given their omnipresence in the Internet world, and their numerous previous recruitment mails, even in the case I actually was seeking employment now.

I guess I will have to try to be rude now, maybe then they think my personality wouldn't fit the company spirit. I don't know.

Just let me say that this kind of aggressive recruiting is in itself alone reason enough for me to not want to work for this company :(

Last minute: Presenting at LinuxTag

As apparently there was a last-minute drop-out in the Security track of LinuxTag 2008, I have been invited to present. It is great that I could convince them to do a talk about my current favorite subject: Enabling more security research in communications protocols outside the TCP/IP/Ethernet based Internet.

I don't want to spoil it by providing too much information upfront. I'm sure there will be recordings available afterwards. For now, you can get the main points from the abstract

Victory: Skype withdraws appeals case, judgement from lower court accepted

The court hearing in the "Welte vs. Skype Technologies SA" case went pretty well. Initially the court again suggested that the two parties might reach some form of amicable agreement. We indicated that this has been discussed before and we're not interested in settling for anything less than full GPL compliance.

The various arguments by Skype supporting their claim that the GPL is violating German anti-trust legislation as well as further claims aiming at the GPL being invalid or incompatible with German legislation were not further analyzed by the court. The court stated that there was not enough arguments and material brought forward by Skype to support such a claim. And even if there was some truth to that, then Skype would not be able to still claim usage rights under that very same license.

The lawyer representing Skype still continued to argue for a bit into that direction, which resulted one of the judges making up an interesting analogy of something like: "If a publisher wants to publish a book of an author that wants his book only to be published in a green envelope, then that might seem odd to you, but still you will have to do it as long as you want to publish the book and have no other agreement in place".

In the end, the court hinted twice that if it was to judge about the case, Skype would not have very high chances. After a short break, Skype decided to revoke their appeals case and accept the previous judgement of the lower court (Landgericht Muenchen I, the decision was in my favor) as the final judgement. This means that the previous court decision is legally binding to Skype, and we have successfully won what has probably been the most lengthy and time consuming case so far.

Tomorrow: Court hearing in Welte vs. Skype GPL case

Tomorrow at 10:30am at the Oberlandesgericht Muenchen (higher regional court of Munich) there will be an oral hearing in the "Welte vs. Skype Technologies SA" case. The hearing is to be held in room E.06.

This case is about a GPL violation of Skype, related to their sales of Wifi Skype phones based on the Linux operating system kernel.

I'm fighting as part of the gpl-violations.org project in enforcing the GPL against Skype since February 2007. Initially Skype didn't respond, we then applied for a preliminary injunction. That injunction was granted by the court in June 2007, but Skype chose to file an appeals case against it.

The court hearing tomorrow is exactly to debate about this appeal.

Interestingly, Skype is arguing against the validity of the GPL as a whole, asserting that it is violating anti-trust regulation and similarly strange claims.

First ASUS day of OpenTechSummit Taipei

As I might have indicated before, I have the pleasure of being invited to the OpenTechSummit 2008 in Taiwan. Two days ago, I was at the opening dinner. The problem of that dinner was the lack of attendees. There were loads of delicious (free, sponsored) food, but not even remotely enough people to eat it.

Today I had a bit of a problem finding the ASUS venue, since it was said to be at "exit 2" of the MRT station. Unfortunately it had two exits of that name, one on each side of the station :)

One presentation there I found particularly embarrassing was the one about the eePC SDK. First of all, I will ignore my thoughts about why you actually need such an SDK if it really is nothing more than a customized Debian Linux with Eclipse. But even then, why fly in a foreing speaker to do a click-by-click walk-thhrough on how to create a 'hell world' Qt program using eclipse?

My favourite of the day was definitely the presentation on the OpenPattern router board.

Review of DORS/CLUC 2008 in Zagreb, Croatia

I've spent the last five days in beautiful Croatia - most of the time in its capital Zagreb. The local conference DORS/CLUC has been around for a couple of years, and in fact I've been at a previous incarnation three years ago.

It's a nice, small but great event. And in fact, for the invited speakers as myself it feels more like an all-inclusive holiday than a conference. The organizers went out of their way to make us feel at home, including a trip to the waterfalls of Plitvice national park (photos will be available shortly at my public photo album.

It was also great to spend some time with Alan Cox again, who to my surprise was also attending the event with two lectures. Hope his luggage didn't get lost again on his way home...

Report from FSFE FTF Licensing and Legal workshop

I'm on seven-hour train ride back from Amsterdam, where I've been attending the first Licensing and Legal workshop of the Freedom Task Force (FTF) of the Free Software Foundation Europe (FSFE).

While having a somewhat lengthy name, the FTF has been doing great work on bringing together a large group of legal and technical experts in the field of Free Software licensing. So far this was all 'virtual', happening on mailing lists.` The meeting in Amsterdam was the first of its kind, and was a huge success.

By the nature of the FSFE, most of the people were from Europe, though there were attendees from the US and even Australia, too.

There were many interesting and surprisingly interactive workshops. It was also a good opportunity to meet Armijn (the second half of gpl-violations.org) and Shane (full-time manager of the FSFE FTF), as well as many lawyers, both corporate legal counsel and from law firms.

The interest in Armijns presentation about gpl-violations.org and Till Jaeger's overview about the legal cases we've handled over the years in Germany were very well received and there was more interest and questions than the short time permitted.

What was really good for me to see is that large consumer electronics companies in Europe and the US are now implementing internal business processes to ensure GPL and other FOSS license compliance. They're also increasingly using very clear contractual language throughout their supply chain to minimize the potential risk of any "hidden" GPL surprises in products they source from OEM/ODM companies.

We don't do Advertisement on the netfilter.org homepage

For some reason, the amount of inquiries about companies who want to put ads on netfilter.org has significantly increased. Since the content of that site has not really changed much in the last (at least) four years, this sudden interest is somewhat surprising to me.

However, we are absolutely not interested in advertisements. I personally hate any form of advertisement, whether in print media, radio, TV, WWW or on billboards. In fact, advertisements are the reason for me to not watch any privately owned TV or radio stations for at least eight years.

So to all the advertising companies out there: Only over my dead body will there be any kind of banner ads on any of the websites of the projects in which I have anything to say.

I don't work for Google - no matter what the rumors say

A number of people have recently independently approached me about rumours that I'm now working for Google/Android, after having left OpenMoko, Inc. in November 2007.

According to one source, some friend who visited Android was told by Android that I would be now working for them. There is no truth to this.

Please put an end to those rumours. I'm not working with or for either Google or Android. There also are no plans to do so, and there have never been any negotiations, aside from the usual Google headhunters that approach anyone visible in the FOSS world every so often - which I always decline, indicating that I am not interested in a dependent employment position, no matter for which company.

I will continue to be doing freelance contract work on projects that are interesting to me and within my fields of expertise. Should anyone chose to approach me with an interesting technical Android system-level and/or hardware related project, that would certainly potentially be interesting. But I'd look at it like any other inquiry.

KLM also using Linux in their Entertainment System

The intercontinental KLM flight from Sao Paulo to Amsterdam was using a fairly new (05/2007) Boeing 777-300, and it was equipped with something like an 8" wide screen entertainment system, not unlike the one that I saw some months back in a Shanghai Airlines flight.

This time I had the luck to see the Linux based system boot twice. The boot time is horrible (on the order of 4 minutes) and you can see many hardware details. It's using a Geode type CPU and a realmagic GPU, has a natsemi Ethernet chip and the credit card reader is actually a USB HID device.

All over the place they have fairly low-level debug code spit out to the console, this really looks like "it worked on one developer board, ship it to the airline" product. You can see mistakes in shell scripts ("ls: no such file or directory" and similar stuff from init scripts, as well as debug code from their UI applications.

It would really be interesting to get my hands onto an Ethernet link in that in-plane network. Guess one could have quite a bit of fun with that :)

I've taken a series of snapshots throughout the boot process. Will post them once I'm back home and find time to wade through the holiday pics.

Receiving the 2007 FSF Award for Advancement of Free Software

The news has already made it to the net during my (offline) holidays, so this entry in my journal will come hardly as a surprise to you: The Free Software Foundation Award for the Advancement of Free Software 2007 has been granted to me :)

I am deeply honored to be the recipient of the award, joining the list of (much more distinguished) recipients of the award. At the same time I'm sorry to not having been able to personally attend the awards ceremony. I've outlined the three key reasons for this in the statement that I prepared to be read at the ceremony.

Thoughts on FOSDEM 2008

I really have been disappointed quite a bit with my visit to FOSDEM this year. In fact, many of my observations might actually apply to Brussels as a whole, I really don't know.

It all started with arriving at Bruxelles Central station on friday, where the entire station was so crowded it took me ages to fight my way through the crowds. Then something like only the fourth idle cab driver was willing to actually take us to the hotel. The others for whatever reason didn't want to earn those 15 EUR. Aren't there some regulations forcing them to transport paying passengers?

Then, let's talk about the social event on friday. How can you hold such an event in a place that's about one third of the required size, and which has a music volume level that effectively prevents any form of communication. I left after about 10 minutes there, since there just was no point at all. One wonders what happens if there is a fire. Aren't there some kind of regulations of the max number of people you are allowed to cram into tiny places like that pub?

At the conference venue the problem seemed to re-occur. All the rooms are significantly too small. Combined with the lack of ventilation and the lack of a PA system it was not possible to stand more than a single talk in the X.org devroom, before I had to get out to get fresh air.

Getting in and out of the DevRooms is also a challenge by itself, since the hallways are over-crowded and full of noisy and loud conversations. Opening the door for even a small amount of time is barely impossible, since that would expose the talk on the inside to the enormous noise levels on the hallway. Especially since the DevRooms don't have any PA system, it's already quite a challenge to understand the speaker inside the room. Somebody opening the door just completely kills the communication flow

The entire idea of putting up all the projects with tables in the hallways seems questionable to me. They do nothing but block the path for other people (also blocking emergency escape paths). Furthermore, cold air gets in all the time since many people have to use the doors in order to walk between the different buildings. It would make much more sense to keep the hallways for what they are: Ways where people walk between rooms. The project tables should be inside rooms. Those rooms would self-contain the noise generated by the tables, be more comfortable (warm, no wind) and keep the hallways free for people to walk on.

The same problem exists for the "BAR" where you get food and drinks. It's too small, too crowded, and absolutely not comfortable at all (cold wind coming in through the permanently open doors, ...)

And then consider the public transport "performance" on weekends. It took me regularly more than an hour for something that was a 2.6km distance between hotel and venue. That's quite ridiculous. Given how crammed those few trams are that actually run, it doesn't seem to be a shortage of passengers that makes them operate so few trains per hour.

All in all, I could not do anything else but to attribute FOSDEM 2008 as something like "the most inefficient event", i.e. where I wasted a lot of time for reasons stated above, rather than actually attending lectures.

flu provides opportunity to watch linux.conf.au video recordings

A quite serious flu hit me four days ago. While this prevented me from getting any serious work done (my doctor actually explicitly asked me to refrain even from mental work), it provided me with ample opportunity to watch through all the exciting video recordings of linux.conf.au 2008.

The various technical X.org driver side related talks were really good to hear, and I'm happy that there is so much innovation and development happening there now.

The most hilarious talk according to my scale of humor was Matthew Garrett's presentation on suspend to disk. I had to watch it twice, just because it's so entertaining. Rusty: Even you'll have a hard time competing against that level of entertainment :)

Something is wrong if your mail client is using 13.0GB of memory

On my fairly new quad-core 4GB RAM system I noticed that suddenly closing tabs in the web browser resulted in tons of disk accesses, which I [correctly] attributed to swap usage. This is quite a big surprise, since I don't use any integrated desktop and generally only run lots of uxterms in ion3 (over two 1600x1200 heads with 8 virtual desktops on each head) plus firefox.

As it turns out, earlier today I started thunderbird (Debian calls it icedove) in order to do some cleanup (moving folders around) on my IMAP server. After about half a day, I was looking at the following line in top:

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                               
 3474 laforge   20   0 13.1g 3.1g  10m D    1 81.7  47:49.91 icedove-bin

This is ridiculous. 13GB virtual, 3.1GB resident set size. And all that with something like roughly 3 million e-mails spread over about 200 IMAP folders.

Who is supposed to use those programs? What do they use for testing? People with 10 mails in their inbox? Also, if you actually download the headers of a new folder, or headers of new mails in a folder, it takes _ages_. It looks actually like they individually request the headers of each email, without using the tagged command features of IMAP, thereby removing all the pipelining effects and being bound to one complete thunderbird-through-kernel-through-network-through-imap-server roundtrip per message. I haven't actually looked at the code, but just from observing the application, this seems to be the case. Also, every time I use the 'search messages' feature for any header that the IMAP server does not have an index for, thunderbird refuses to wait long enough until the server responds.

So far I always thought mutt's memory usage of 40-80MB is already excessive, considering all it does is displaying a bit of plain-text emails. Well, for once I've been happy again that I'm not a regular user of those kind of bloated GUI programs. firefox somehow being the sole exception to that. It's barely useable on my 1.06GHz / 512MB laptop, where you already notice quite considerable lag in the responsiveness of the UI. :/

Guess next time I have to move folders, I'll probably revert to something like cyradm (that's a minimalistic imap client with command shell, not unlike the old 'ftp' command for FTP).

Working on ISO15693 support for librfid

It's really been bugging me for a long time that librfid was lacking support for the ISO15693 protocol. The supported reader hardware ASIC can do it, but librfid always was lacking the respective code. It has been on my agenda even three years ago, but there were always higher priority items to pre-empt it.

In December 2007, Bjoern Riemer submitted a long patch to add partial ISO15693 support to librfid. The size of the patch reflected the huge amount of work that must have went in that code. So I couldn't really afford to let all that work bit-rot. I went through several iterations of code cleanup, starting with cosmetic issues, and digging deeper and deeper. I think it now doesn't really look all that similar to what Bjoern originally did, but at least now we have a working and fairly well-organized ISO15693 anti-collision implementation in librfid.

However, ISO15693 has many different options with regard to speed, modulation, coding, etc. All those combinations have to be carefully tested. What's also missing is a way how to iteratively cycle through all available ISO15693 tags within range, similar to what we do with ISO14443A and B.

Once that work has been finished, the actual higher-level standard commands, as well as the nxp I*Code2 and TI Tag-it vendor-specific extensions can be implemented on top. This can probably be done on one or two more days of additional work. Stay tuned...

Meeting between gpl-violations.org and FSFE FTF

The last two days, I enjoyed a meeting between gpl-violations.org and the FSF Europe Freedom Task Force.

Participating were Armijn Hemel (whom I have to thank to assure gpl-violations.org doesn't die while I was in Taiwan for OpenMoko), Shane Coughland (who is doing an excellent job coordinating the FTF) and myself. For a couple of hours we've also been joined by Till Jaeger, who has handled all the legal cases of gpl-violations.org so far.

This meeting has been over-due, mostly because I basically dropped off the planet for way too long time. We've discussed all the current matters regarding strategies for license enforcement, current cases, progress of the FTF legal and technical networks, as well as future plans for incorporating the gpl-violations.org project.

Yes, you have read correctly. I've been planning to do this for quite some time, and I'm confident that 2008 will finally be the year in which this happens. It's too early to talk about any details, but this is the logical step to assure both financial and legal independence of the project from my person, as well as scalability. As you might know, we have a couple of hundred reported violations and can only cherry-pick those we consider particularly important.

In any case, it was a very productive meeting. I seriously believe it has helped to make all of us work together in a coherent manner, i.e. increased productivity and effectiveness for a long-term strategy to increase the amount of free software license compliance in the industry.

Learning about NAS chipsets

For gpl-violations.org, I've been analyzing a number of NAS devices recently. While most of them are based on some kind of more or less general purpose CPU (Intel StrongARM based IOP or e.g. VIA's embedded x86) plus standard peripherals, there appear to be more and more special purpose SoC's for this purpose.

To some extent, this is only a logical development. NAS appliances seem to be a growing market, and the desire to achieve higher integration by e.g. moving the SATA/IDE controllers into the SoC make development easier and reduce BOM cost.

It's quite amazing how much effort some companies actually go through. One series of chips that particularly caught my attention is the Stormlink Gemini series of NAS CPU's, e.g. the SL-3516. Looking at the public data sheets is particularly boring since they only have two pages. Instead of that, I'd recommend looking through the kernel sources that their downstream appliance vendors publish. They actually have hardware crypto, hardware IPsec acceleration, TSO (TCP segmentation offloading), hardware NAT, ...

As if that wasn't enough already, they also now have a dual core variant, which has two ARM920 cores next to the hardware crypto and pimped-up Ethernet controller!

While reading through the code, I made a slightly cleaned up diff against vanilla 2.6.15. It reveals a number of things that I'd like to point out:

They have actually managed to implement a arch/arm/mach-sl2312 directory (instead of just editing some existing machine), though there seems no distinction between 2312/3516/3518/...
They have GPL licensed drivers for their entire hardware functionality, not a single bit of proprietary stuff. It even comes with proper license headers and MODULE_LICENSE tags. This is really remarkable, especially for stuff coming from Taiwanese hardware companies. Congratulations!
They integrate DMA capable RAID5 hardware generation, integrated with the Linux raid code
They have two OTG capable EHCI USB controllers
The ARM core they use is a FA526. It seems to originate from (another Taiwanese) ASIC/IP vendor called Faraday. Apparently an independent implementation of the ARMv4 instruction set, allegedly 100% compatible, even including a replica of the ARM ICE/JTAG. Could Faraday be to ARM what VIA is to Intel? In any case, definitely exciting.
While the vendor-released GPL licensed sources contain support for this FA526 in a fairly decent way, it has not been merged into the mainline kernel. That's a pity. Does anyone know more about this? I think this should definitely be cleaned up and merged mainline.
they re-use an entry from the mach-types registry for the sl2312. Not only do they use that machine type for all Stormlink SoC, but also the downstream hardware vendors use the same for all their products. not good. Did anyone tell them that registering new machine types is free?
They're doing some obscure I/O pin sharing between IDE and the flash controller resulting in lots of ugly code. Probably a hardware workaround :)
They have very invasive code all across the Linux crypto code, probably because they need async crypto support, which the crypto framework of 2.6.15 doesn't yet provide
They seem to integrate their crypto with cryptoloop, but not dm-crypt
They seem to be able to store their OS image in NOR, NAND or serial SPI(!) flash
They have four hardware queues per Ethernet MAC
They have done some serious hacks to the network stack in order to integrate their TCP offloading engines and hardware NAT. This code is obviously not the most beautiful you have seen. But what surprises me is that they actually have it working, and went all they way to get it developed. And all that for some obscure NAS chipset. I would be interested to learn how many man-years of engineering time they have in that code... Oh, and they do actually have code for TCP-over-IPv6 offloading
Hardware-accelerated recvfile support

As a summary: Kudos to those who have designed the product, and actually implemented all its features, in purely GPL licensed code. It's just such a pity that none of the code, not even the most generic and clean bits have been merged mainline.

proprietary MiFARE [in]security finally falling

At a presentation entitled "Mifare - Little security, despite obscurity" at the 24C3, Henryk Ploetz and Karsten Nohl presented about their revelations of the proprietary Philips MiFARE classic RFID system.

As everyone in the IT industry suspected, the level of security provided by such a cheap, low-gate and completely undisclosed system is in fact very limited.

I'm particularly proud that this security research is exactly what Milosch and me originally wanted to enable by creating the OpenPCD and OpenPICC project. We wanted to put easier accessible and open, documented tools for low-level access to 13.56MHz RFID systems.

With a bit of luck, at some point in 2008, it should once again become clear that security by obscurity doesn't work. This lesson seems to be well-understood in the Internet world, but apparently has little penetration into the RFID sphere so far. There are still many proprietary systems whose security relies solely on the secrecy. Once a single person reveals that secret, the system is broken.

I can only hardly imagine the amount of economic damage imposed by the perpetrators of such systems. There are a couple of hundred million MiFARE classic tags on this planet, particularly in public transport ticketing and access control. The vendors of such systems should be blamed for their false claims. And anyone who bought it should be blamed for their blind belief in the claims of profit-oriented corporations without any independent validation or verification.

Dependency of essential Linux bluetooth features on dbus

Apparently I'm not the only one with outspoken criticism of the BlueZ dependencies on dbus.

I do not want to debate the merits of a message bus system on any system (desktop or non-desktop) and neither do I want to start a debate on how efficient dbus is trying to solve that problem.

However, what I'm fundamentally opposed to is when basic interaction in a network or between a computing device and its peripherals depends on extensive userspace dependencies. Now you might argue that ipsec needs a userspace keying daemon, that routing protocols need a routing daemon, and 802.1x or WPA need a userspace daemon, too. This is not the point. There are very valid technical reasons for doing so, and nobody really proposes that such things should move into the kernel. Also, none of the above-mentioned programs have requirements on other userspace components aside from glibc or maybe some netlink specific library.

Bluetooth however now requires dbus. At least it is almost impossible to do without. I have tried for neverending hours and didn't make it work. Others apparently have similar problems.

If people want to [d]bus-enable their kernel-related tools, let them do it. But please make it optional and don't depend on it. This is just not how things are done in the Linux kernel world until now, and I don't think there has been any debate on whether we really want such a paradigm change yet..

HTC TyTN II / Kaiser doesn't look like a GPL violation!

There have been numerous rumors floating around the net that the HTC TyTN II (aka Kaiser) might be a GPL violation due to a number of strings in the firmware image referring to Linux and vmlinux.

I've done some analysis on this subject, and posted my preliminary results in this posting to lkml earlier today.

So as indicated, I do not see any reason to believe there is a GPL violation with regard to the Linux kernel in the MSM7200 modem side as used in the abovementioned device.

So please stop those rumors now. I'm obviously not opposed to people being watchful and report/investigate potential GPL violations. But before you call it an actual violation, please rather make sure that you have some evidence!

Final cleanup of OpenMoko Neo1973 kernel patches

I'm doing one final review+cleanup iteration for the OpenMoko Neo1973 GTA01 related kernel patches before pushing them for review later tonight or at some point tomorrow.

The cleanups are mostly dead code removal, avoiding compile-time warnings as well as cosmetic cleanups such as adding MODULE_DESCRIPTION to all modules, and using consistent naming for files and driver names.

GTA02 will have to wait a bit more. On the one hand, changes that the kernel developers want me to do on PCF50606 will likely appear in the PCF50633 driver, too. On the other hand, the entire Smedia Glamo driver core has not been polished yet.

Merging OpenMoko patches with u-boot and kernel mainline trees

Those following the OpenMoko commitlog will have noticed quite a bit of activity in the areas of u-boot and kernel patchset. For u-boot we always tried to track mainline git. For the kernel, there is now a patchset against the current Linus git tree (2.6.24-rc4 should also work) at http://svn.openmoko.org/branches/src/target/kernel/2.6.24.x/patches.

I'm intending to do some level of testing after the merge, and then submit the majority of the stuff. For kernel, I don't expect many issues. For u-boot, it will be a quite painful process.

So if you now think this means that I'm back working for OpenMoko, this is wrong. I'm doing this for a personal reason: I merely want to make sure that the code I wrote throughout the last 18 months will not bit rot somewhere but is actively merged into mainline.

Day one of FOSS.in

It was a great first day at FOSS.in 2007. It's been surprisingly quiet at the venue today, compared with the previous incarnations of the event. This is due to the changed structure, in which the first two days are focused "project days" and the main conference only starts on day three.

This does by no means imply that the project days are less important, or that the lower number of people is bad. Quality matters, not quantity. And since the event is about contributions, project days are a very important addition to FOSS.in

I spent most of the day talking to Rusty and James. It has been quite nice and I now have learned about Rustys new exciting CCAN project. As a long-time perl developer (I have leanred Perl before C!), I definitely understand the beauty of something like CPAN. With C however, the hardest issue will be resolving the namespace problem. Unfortunately I am currently not in the mood of adding even more unfinished things to my task list.

Looking forward to FOSS.in

In a few days FOSS.in 2007 will start. I'm departing from Germany on Monday next week. I have a ton of things to do until then, including a trip to my family in Nuernberg on Friday,, visiting a industrial festival in Chemnitz on Saturday and packing my suitcases on Sunday ;)

So this will be the fifth year in a row that I visit Bangalore in late November/early December for the event formerly known as Linux Bangalore. What once started like a crazy reason for visiting India the first time (after enjoying Indian food and bollywood music from Germany for a couple of years), has turned into a regular mark in every years' calendar for me.

I've been told that FOSS.in this year will be very different from all the previous events. The focus has been shifted from doing just another round of 'this is free software and this is how to use it' event, the focus is now entirely on the community developer.

India still has, to my deep regret, shown relatively few significant contributors to Free Software - especially if you relate it to the size of the IT industry and the number of people working as software engineers in that country. Thus, I very much welcome any effort to nurture and foster the active, contributing part of the FOSS community there.

Meanwhile, the Schedule has been published by the organizers. Looking at the speakers and topics covered, it definitely looks more than promising!

Also: My openmoko-induced absence to the major Linux events in Europe and Canada have resulted in a way too long time since I've last met Rusty and James, my former fellow netfilter/iptables hackers :) Make sure you don't miss any of Rusty's talk. It's going to be fun :) And be prepared to switch your brain's English parser into high-speed mode :)

As a final side note: I'm happy to learn today that my application for a five year visa to India has been granted. During the last five years, I had to obtain a total of seven 6months visas - sufficient evidence to support my argument in favor of a 5 year visa.

Slowly getting back to my normal life

For the last couple of days I finally felt like in the "good old" (pre-openmoko) days. Suddenly things that have been piling up to higher and higher stacks are getting resolved. Tax related issues, various other administrative things like housing, insurance related, etc. I even find time for regular medical checkups like dentist's visit again.

I'm also slowly browsing through the various lists like netdev, which I haven't had time to read throughout the last year or so. Finally I get the feeling of being "in sync" again with what's happening in the rest of the Linux world.

I'm also making quick progress on gpl-violations.org (just ordered two new test purchases of allegedly infringing devices). And I even have time for the occasional homepage update of my various rotting (and rotten) websites.

I'm also almost finished with Ulrich Dreppers excellent paper "What Every Programmer Should Know About Memory". Being a kernel hacker, most of the issues have been known to me more or less, but it's good to read about all of them in a concisive paper, together with benchmarking on current hardware.

There ares still hundreds of pending issues here and there, and I yet have to find some time to e.g. finally do a ulogd2 release, work on integrating all the pending patches in librfid, work on ISO15693 support for it, and last but not least work on getting a lot of the work I did for openmoko on u-boot and kernel finally merged mainline. But if I'm able to continue getting things done at this pace, I'm very optimistic

It seems like all the time with OpenMoko has actually made me forget how easy and fast things have been moving all the time before ;)

Leaving OpenMoko "Lead System Architect" position

The regular reader of this blog will have noticed a distinct lack of any OpenMoko related news. This is not a coincidence. As Mickey wrote in a blog entry, there has been quite a bit of internal friction lately.

Adding that to the enormous amount of stress over the last 18 months has made me feel quite a bit demotivated over time. I've tried to cut down on the amount of work I do, but it hasn't helped much. So now I'm at a point where I feel unable to work in any active/leading role inside the project and/or company. My deep apologies to the the project and its community.

But don't worry. OpenMoko is a team, and I'll do everything to help smoothen the transition. I'm more than willing to assist those who will take care of my various tasks.

From today on, I'm nothing more than a volunteer to the project. I'll likely continue a bit of hacking in my areas of personal interest. Just like in many of the other FOSS projects that I have been (or still am) involved.

All the best to the OpenMoko project, the OpenMoko company, FIC Mobility. The last 18 months was an intense experience. Thanks to everyone who has helped the project both inside FIC/OpenMoko and outside. Thanks to FIC for funding and supporting the project. I wish everyone the best, and I'll be the most happy person (next to Sean) at each and every milestone the project achieves in the future.

My last netfilter training

Since I've been doing no netfilter/iptables related work recently, I've announced that the three day training is going to be the last one, at least for the time being.

Though stressful as usual (have you ever talked/presented straight 8 hours on three consecutive days?) it was a quite joyful experience. Apart from the netfilter/iptables workshop earlier this year, the only contact with my former much-beloved project in 2007.

However, the training made me realize how outdated all the existing documentation (and even my own training material) is. Basically everything was written in the early 2.4.x days - and much has changed ever since.

There's all the nf_conntrack / nf_nat related changes, as well as the x_tables transition, which can cause many subtle errors due to old scripts expecting different kernel module names, etc.

None of the HOWTO's or similar documents talk about the conntrack userspace program yet, there's no documentation (and no release) for ulogd2, etc.

So I'll really try to sit down and find some time to improve some of those areas. It yet remains to be seen if I can actually make it. But I feel there's a real gap to be filled...

Slowly getting back to work on gpl-violations.org

Today I've finally started to pro-actively work on gpl-violations.org again. I haven't been able to do any work on it for almost 1.5 years due to my intense involvement with OpenMoko.

Among my first tasks was to update the ssl certificate for our internal Request Tracker, which apparently expired quite some time ago. After that, I went through all RT tickets and deleted tons of spam from it. Now it finally looks like I can start working with it again :)

I'm also trying to catch up with all the gpl-violations.org related email, but please give me a couple of weeks, there's just way too much of it :(

Seeing netfilter/iptables boot-up messages in an airplane

I've read a couple of blog posts about the suspicion (or even confirmation) that some of the in-flight entertainment systems are using Linux. It's completely understandable that if you have to put 400+ such systems into a plane, you'd rather use free software for the economics of licensing costs.. imagine 400+ windows licenses :)

Now in any case, during my Taipei-Singapore flight enroute my trip back from OpenMoko headquarters to Berlin, I was amazed by the new big-screen entertainment systems that Singapore airlines is apparently using in some of their planes. This particular plane was a Boeing 777-300R. The screens are not the usual 4" or similar, but actually something like 10" - and that in economy class. Also, they're really high-res, and seem to be entirely controlled digital, i.e. no blurry PAL/NTSC or VGA resolution, but actually something on the order of (guessing) XGA.

The second unusual bit was the three connectors on the right hand side of the screen. Ethernet (!), USB host and composite video-in. I've never seen something similar in an airplane before.

Now unfortunately the system on my seat was stuck. I called the flight attendant, who then issued a remote system reset. To much of my surprise, I could soon see the BIOS boot screens of a VIA based embedded system. Afterwards, it executed RedBoot, followed by a Linux kernel, to be followed later by an X server (you could see the grey background pattern with the X cursor for quite some time), and then some custom X11 applications.

As the RedBoot message suggests, the system was implemented by Panasonic Avionics.

The first thing worth mentioning was the incredibly slow boot progress. They must be running those systems at low clock speed, and boot them over the network, even though the rootfs was ext2. I didn't see the details since I was too busy grabbing my camera to take this photograph.

The amazing thing about this system is that it has 512MB RAM per seat, dissipates a dangerous amount of heat (you can feel it getting very uncomfortably warm under that screen, where probably the entire system is located, similar to a "tablet PC" form-factor). Still, it is very slow. And then look at the details. Why on earth do you need a wifi stack and netfilter/iptables, including ip_conntrack on such a system inside the airplane? I severely doubt that they use packet filtering to prevent a hacker to get from one seat to another - and thus connection tracking adds anything aside a performance hit.

So what's it with those connectors? I couldn't get the Ethernet part. And for whatever reason, I didn't have a patch cable in my carry-on luggage either. Maybe the entertainment system might have been even more entertaining that way, who knows :(

The USB connector is meant for a user-provided USB memory stick, where you can then watch your own pictures, or use a word processor or spreadsheet to view / create / edit documents. The software used for this is - unsurprisingly - a customized version of StarWriter/StarCalc, based on OpenOffice.org. I've played a bit around with it. Using the controller, you can actually resize the window from full-screen to something smaller, but there's nothing interesting in the background. I've tried to see if one can somehow change the print command to "/bin/sh" and then print a document - but the printing functionality had been removed altogether, so no luck here.

I decided to sleep for the rest of the flight, rather than trying different attack vectors. If I run into such a system again, I'm probably quite tempted to do so again. Would be fund to get an entire plane full of Linux hackers (let's say: OLS attendees) and have them play around with it to see how well is is done from a security point of view. I guess the worst-case scenario is something like people connecting their USB hard drives (or laptops via Ethernet) and then ripping the entire entertainment library during the duration of a 12 hour intercontinental flight. I'd suppose they actually should have looked a fair bit at the security of such a system. But then, the same is true for many systems, and developers still neglect that aspect way too often.

Heading back to Germany

So, after roughly two weeks of OpenMoko Taipei headquarters, I'm now heading back to my Home+Office in Berlin. And I'm really looking forward to it. During the last couple of months I've tried my best to help the transition from OpenMoko a a project inside a FIC business unit to OpenMoko, Inc. the independent company inside the FIC Group. I've helped with tons of things that are definitely by no means related to kernel/bootloader development, or even the hardware architectural planning that I've been heavily getting involved starting with GTA02.

So now it is a good time to finally focus again on what my actual and original task is: Software development. This can be done much better remotely, so I'll expect to be able to work way more from Berlin. Which makes me happy, since it always was and still is my favorite city. And I definitely missed it a lot during the last year of intensive OpenMoko work. Now I'm on my way back, and I'm looking forward to spending more time with my friends, the CCC Berlin. Being able to go to concerts and clubs that play music I actually like. Being able to work on finally improving (or rather: finishing) home improvement in my apartment, and many other things.

So don't get this wrong. I'm very much continuing my technical work for OpenMoko, and as the first developer on this entire project and a OpenMoko core team member, I'm always going to maintain an influential role in the project. But finally, I can go home, feel better, work more focused and efficiently, and improve the technical quality of our products even more :)

Since OpenMoko now actually has three full-time paid project members in Berlin, It's also going to be nice to closer cooperate with them. (or co-work, like the Chinese English speaking would say)

Back to Taipei

Today I got back to Taipei, almost three weeks later than originally anticipated. More news after at least one night of full sleep and the first day at the office...

FOSS.in 2007 Call for Participation

The Call for Participation of this years incarnation [it's in India, after all] of FOSS.in has just been released.

This is great news. I've cut down on all other events this year: I haven't visited at OLS, LinuxConf Europe, linux.conf.au, ... Only FOSS.in I really cannot miss ;)

I haven't yet decided on the exact title of the lecture that I'm interested to submit, but it seems like I'll have to decide soon. It will be OpenMoko related, that's for sure ;)

If you have worked on something exciting in the FOSS world, please don't hesitate and submit it to the FOSS.in/2007 CfP. It's a great event with a very technical audience. And an ideal opportunity to catch a glimpse of India :)

netfilter developer workshop 2007 is over

The days of the netfilter workshop passed quite fast, and I'm finally back to my home in Berlin now. In case you're interested, here is a link to the group photo.

Among other things, we've had the following major decisions at the workshop:

Patrick McHardy finally officially head of the coreteam
ulogd2 will see an official release candidate soon
we want to merge ipset soon
we will try to shift future developments in the direction of libnl and slowly deprecate libnetfilter_*
we will move the netfilter and netfilter-devel lists to vger.kernel.org since we don't have to care about spam filtering there. Other, lower-traffic lists remain on lists.netfilter.org
we will switch to git even for userspace code, at least for the iptables source code

Finally, I'd like to use this opportunity to thank all our Workshop sponsors, particularly Astaro for their continuous and generous support of netfilter/iptables throughout the last five years.

Enjoying the netfilter workshop 2007

I've returned to Germany in order to attend the 5th netfilter development workshop in Karlsruhe. It's sponsored by Astaro, whose continuing support of netfilter/iptables is really outstanding. Even after I took my "leave" to work on OpenMoko, they continue their funding by paying for Patricks maintenance of the netfilter/iptables codebase, and things like hosting the netfilter workshop.

It's really great to meet with the old colleagues with whom I've co-worked for a number of years on netfilter/iptables. I really miss those days, basically spending most of my day working together and communicating with cool people hacking on similar problems. Quite a bit different from what I'm doing right now.

So while I'm here, I'm actually trying to spend most of my time related to netfilter/iptables, which is really refreshing.

Two days of intense u-boot hacking

After finishing most of the basic device support for GTA02v2 in both kernel and u-boot during the last week, I've finally turned back to implementing one of the longest standing issues in u-boot: GSM passthrough.

GSM passthrough allows you to basically ignore the smartphone part of the device and connect the GSM modem more or less directly to a host PC. The feature has been long known by various smartphone hacker projects such as e.g. OpenEZX (which as a side note has made quite some progress recently, much appreciated by me as retired project founder).

So GSM passthrough is mainly useful for rapid development (developing gsmd more efficiently by running it on the developers workstation, without cross-compiling and ipkg installs), but also if you want to use some legacy application that was written at a time where a phone really only was a phone (e.g. sim card managers, ...)

Now the GSM passthrough was always pushed back on the TODO list, since our usbtty code in u-boot was never very reliable and caused lots of data corruption such as bogus and/or missing characters. Quite useful for the human operator, but definitely not acceptable for getting a program with AT command parser to work. So that had to be fixed first (and it is now fixed).

As I pointed out in my announcement, the generic way of implementing this feature has actually quite interesting but much more obscure use cases such as dialling from a landline via GSM (CSD call) into your Neo, manually accepting the incoming call and then attaching the u-boot command line to it. That's sort of the feature you have on hosted/colocated servers, when you use a boot-loader with serial console support and attach a modem or terminal server to it.

So does this mean the Neo1973 is now ready for the enterprise? Not quite. Even though it has a built-in UPS (called battery), and GTA02 will even allow you to change the battery without shutting down the device, resulting in higher availability ;)

But then, the expectations / requirements for mobile communications devices are quite a bit different from that world. But the hackers community likes those kind of strange features. Have you ever heard of another smartphone with that capability?

Oh, and before I get any complaints about the security: This "feature" has to be explicitly enabled and every call manually accepted by typing a sequence of commands into the u-boot command line. So unless the attack involves tons of social engineering (getting the device owner to do all those things) there's not that much of a big deal. But maybe we should start to think of some kind of user authentication for u-boot now *rotfl*.

OpenMoko Taipei office network setup

For the last three days I've been busy setting up the network in the new OpenMoko office. Finally something that just works, without any major flaws. That's probably because the involvement of external entities is fairly small. But looking at it closer, actually exactly there the problems start. FIC purchasing e.g. only bought 50% of the switch equipment that I asked for, something that I still don't yet have received any details about, neither some kind of apology.

In any case, the network is up and running. We now have a pretty uncommon heterogeneous combination of Cisco, Dell and even some D-Link switches, with the core switch being a pretty impressive Dell 6248. The 10GBit transceivers are still missing, so the backbone is just running 1GBit for the time being.

There's a total of about 190 Ethernet access ports throughout this new office, and we have various different broadcast domains, safely separating guest network, office network, r&d network, ... from each other.

The server room also looks quite nice now, with five 19" full-height 19" racks, 2 layers of UPS (building-wide and extra small UPS in front of servers), with three fairly big servers in operation, and eight more pending to be used soon.

The Internet uplink is a 100MBit capable physical layer (fiber optics), of which we only subscribed to 8MBit initially. But one phone call (plus additional transfer of money) later, we can bump the speed to any rate below that 100MBit physical layer limit.

The operation of our own (netfilter/iptables based, what did you think?) firewall now also brings us back the long-missed basic fundamental networking needs of any free software hackers (called luxury around here) of all our developers being able to

access the web without restrictions and blocked sites
finally use IRC!
access external IMAP4 servers
have SSH and other interactive sessions not time out every couple of minutes

Progress with the new OpenMoko and FIC Mobility office

The final 24 hours of my current Taipei trip have started. This is a good time to reflect on what has happened in those last weeks since July 9.

As with the overall status of the project, I'm still extremely dissatisfied. The frequent reader of this blog will have noticed the last postings on this subject, full of discontent.

So the further we are into this project, the more time we put into it - the further I expect it to produce anything that I would consider reasonable results. Please don't confuse this with the commercial success, or the ability to produce working products. This is an entirely different matter.

To me, it is extremely important to do things systematically, with lots of planning, safeguards, checks, verifiable and reproducible processes, as much automatization as possible, little room for human error, etc. So as long as not everything from hardware to software development, mass production, production testing, distribution/logistics/sales, etc. follow a well-thought-through process, I will not be happy with the results. Because any such "results" are more or less the mere product of luck or randomness, and not a trustworthy basis upon which we can rely on.

So reflecting on those past weeks, I think the following things have made humble and moderate progress:

GTA02v2, the second prototype generation of GTA02 was finalized after many issues including unavailability of key components. I'm more than looking forward to see how it turns out
DebugBoard v3, the third version of the Neo1973 Debug Board was finalized and is actually also verified and can go in mass production
Our internal software team finally has proper leadership and guidance from somebody who is both Taiwanese and has a thorough understanding of Free Software: jserv
The new, second (intermediate) generation user interface was implemented and released. It's implemented mainly by O-Hand, since embarrassing as it is, we still don't yet have managed to build a proper internal software development team.
The first batch of Neo1973 GTA01 was sold, though with a entirely last-minute, error-prone and way-too manual process for order, payment and logistics.
We have found a capable sysadmin for our hosted, publicly-accessible servers. More news about that in September.
We have managed to find a extremely valuable senior technical person for our graphics driver and low-level UI work. This, too, will make big news in September.
The FiWin (FIC wireless networks) company, home to the team working on the it-exists-but-nobody-publicly-knows-what-it-is HXD8, was merged into OpenMoko and FIC Mobility
We have finalized the specification for the workstations of our software developers. It's incredibly complex to find something that's compliant with our requirements (mainboard with Intel 945/965 on-board graphics, Ethernet chip != attansic/realtek, dual core CPU with 2x2048kByte cache) in Taiwan. So now our developers will all get a Q6600 CPU (what nonsense!). I've tested it, and it compiles the GTA01 kernel in 1.59minutes. Guess they'll be happy about that.
Realize how many things really are fundamentally wrong internally. What we knew so far about our inheritance was just the beginning ;)

One major thing that finally started to move forward, with something like four to six weeks of completely unnecessary delays, is the new office. After it was decided that we will split FIC MCBU into the independent OpenMoko, Inc. and FIC Mobility (aka Mobile Communications), we also decided to move into bigger, scalable and independent offices.

To our big luck, two thirds of the 7th floor in the FIC headquarters were currently unused, and they're now undergoing quite a bit of renovation and reconstruction. Walls have been removed and brought in, floors have been properly removed and new ones laid - after days of fighting by Sean and myself.

The networking and phone cables get a major overhaul and will be tested. I've also seen the AC for the new OpenMoko server room being brought in. The contract for our own Internet plink has been finalized. The fiber will be put in place within the next week. The core switches have been configured, but we're still fighting very hard to get those damn 10Bit XFP transceivers from Dell.

So the current schedule is to move on August 17, one day after I'll be back from Germany. If that works out, I could spend the weekend 18/19 for doing the final network/server/router/firewall/... configuration.

Obviously, all of this causes quite significant resource drainage for everyone involved. But it's a more than necessary step forward to building an environment that we can actually work in. An environment where our developers have real Internet access, can join IRC channels, and can get in touch with the OpenMoko community without the obstacle of strange corporate policies. An environment where we can have a 'clean start', even in the most literal meaning of the word :)

So all in all, bear with us, have patience. The revolution might take significantly longer than anticipated. But we're still busy doing whatever it takes to get us to the product that the OpenMoko core team set out to build.

Sick but not insane (yet)

Some people were troubled by my last posting about 'insanity'. And I have to admit it is justified. It isn't nice to pull internal issues of some company out into the public that way. But I just couldn't do differently anymore. FIC should think about providing a free corporate psychiatrist for us. ;-) I think I have a fairly big tolerance when it comes to mishaps, incompetence and cluelessness, but some of the things we're experiencing here are just not bearable. Especially not if they lack any kind of rational explanation.

So my latest outburst was mainly related to the fact that despite being with flu and fever in bed, I had to personally hack that embarrassing little online shop we now have at https://direct.openmoko.com/ [my first perl CGI code in about ten years!!]. Can you believe it, we just did not have (and still don't have) anyone in this project who has ever done some real work on CGI's or 'technical web things' at all. And if this was not enough yet, the requirements kept constantly changing all the time, up to this day, more than one week after the webshop opened.

So for gods sake, how many months have we been knowing that at some point we need to ship? And then you have plenty of people who produce over many months three entirely different concepts on how to shop and distribute those devices. And in the end, you have something with a Chinese-only credit card processing page, no proper setup with regard to the carrier (UPS in our case), tons of people talking vapor, but from what I've heard drawing nice diagrams. And no working solution.

Some people might wonder why those shipping rates in the shop are so high. Shouldn't a large company like FIC get huge discounts? Yes, they do. But believe it or not, FIC does up to this day not know in advance how much a shipping costs. Only after it was made. UPS has something like a Rates and Service Selection API. UPS has also a nice and detailed manual on how this XML API reports those rebated 'negotiated rates' in addition to the standard rates.

But then till this very day, UPS keeps claiming that such an API does not exist. Despite the fact that off-the-shelf e-commerce applications _support_ this API, and despite the fact that UPS' very own API documentation goes into every detail describing how that information is XML-encoded. What comes to my mind is the O'Really: Distributing Clue to users in a slightly modified version: Distributing clue to UPS' own sales representatives. How on earth can you get or keep a job there if you haven't even read the company's own documentation on their products?

Then you have companies like WorldPay, who very broadly advertise the many different payment variants they accept, not only all the credit cards known to man, but even things like direct debit (Lastschrift) in Germany. But do you believe they are able to process American Express for us? No, obviously not. Customers located in Taiwan (like FIC/OpenMoko) cannot process AmEx. No explanation given. So much for the word WORLD in WorldPay.

Or would you believe that some large bank like Citibank (Taiwan) was able to charge credit cards (VISA/MasterCard) in USD? No, obviously, being in Taiwan they can only charge in NT$ (New Taiwan Dollars). WTF? It's the 21st century, and there are dozens of online credit card acceptance partners that allow you to bill in about any currency you want. But not a world-class bank like Citibank.

And now you might think that we're actually no longer working on development. That is wrong. Yet another funny story from the MokoUniverse is that one of the worlds largest semiconductor distributors just had a long meeting yesterday, with FAE's and tons of FIC hardware engineers to crack their heads about the question whether or not we can use a "new" silicon revision of a certain component, and where exactly the differences between the old and new revision might be. I refused to participate in such a meeting, indicating that I just want a document describing those differences. In writing. Soon after that, I find out that we have always been using that supposedly-new revision, for the better part of one year. Nobody actually bothered to look at a unit of hardware, or at all the high-res photographs of GTA01 that I posted on people.openmoko.org ages ago.

Then lets get to another of my favorites. Purchasing. I wrote an extensive list of networking gear that we desperately need in order to crate the internal IT environment for our fast growing new OpenMoko company. After many delays, today I finally got our two core switches. And what did they do? They "forgot" to order the transceivers, even though they were explicitly listed in the requirements/order list. God knows what happens in the heads of such people. So I'm now back to once again just mail-ordering things from Germany and then billing FIC for the expenses.

And to not bring up more embarrassing facts, and to at least preserve some level of confidentiality, I'm now going to stop. But believe me, there are _much_ more insane stories to be told. With some luck, at some distant point in the future, I'll get permission to publish them in my memoirs.

But that's basically the kind of thing that drives me close to insanity. Whether for that cause, or completely unrelated: My health is actually quite bad recently. Maybe the lack of regular sleeping hours, let aside regular intake of food and the tons of stress have contributed to the flu that lead to a severe fever attack today. You know there's something wrong if at 33 centigrade in the sun, you're shivering more than when riding your motorbike at -13 centigrade in German winter.

So I'm going to take it slowly for the time being, working much from what has now become my 2nd home (apartment in Taipei, provided gratuitously by FIC for people like Werner and myself, who are spending so much time over here).

My sincere apologies in advance. But given my multitude of roles/hats and functions in the OpenMoko project, I bet my health issues will now contribute to some further delays in about any area of the project. But there's little I can do. One day, we will get there. Let's hope you're still interested in our products at that point.