I'm currently sitting at Amsterdam Schiphol Airport, waiting for the last connection in my Recife - Sao Paulo - Amsterdam - Berlin return trip.
I'll be wading through the several thousand emails over much of the next couple of days, so please give me some time to get back to you.
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.
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.
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.
For those of you who're curious: The first week of holidays went just fine, spending something three days in Sao Paulo and three days in Curitiba In Curitiba, I had a rental car and went to Vila Velha, as well as driving the serpentines of the Rua Graciosa through Morretes to the Beach. Oh, and obviously in Curitiba I had to go to Homem Pizza and Happy Burger, the two restaurants that I frequented the most while working at Conectiva 7 years ago.
The biggest problem so far was the malfunction of the in-room Save of the Hotel in Curitiba, resulting in not being able to access any of my cash reserves, credit/debit cards, passport or laptop for two days. They actually had to physically break the safe open since the lock mechanism was stalled/clogged in a way that it did no longer move.
Now I've just arrived in Recife, where after two days, the journey will continue towards Porto de Galinhas.
I'm hereby announcing that I'll be offline most of the time between March 3rd and March 26. This is the longest time that I've been offline for quite some time - and it's a much deserved holiday after the intense work of the last year.
I'll be doing quite a bit of travel in Brazil through those more than 3 weeks, meeting some old friends and ex-colleagues from my time in 2001 at Conectiva. I'll also be spending some time at the beach, plus exploring a bit of Parana and Pernambuco by [rental] car.
This also means that I'll likely end up being forced to use my horrible Brazilian Portuguese again. But well, at least for me, unless forced to speak a certain language, I won't speak it at all. So this must be a good thing, then.
Please don't expect any reaction to e-mails, snail mail, phone calls, faxes or any of the like during that period of time. I won't even have my German GSM phone online to avoid roaming charges killing me.
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.
It was really surprising to see that there was absolutely zero control of any ID on the flight between Berlin and Brussels. I'm well aware of the marvels (and data protection nightmares) associated with the Schengen agreement. However, zero form of identification on air travel was really a big surprise to me. Not even my flights inside Germany had this 'feature'
How did this work? First of all, I booked the tickets through a travel agent quite some time in advance. No form of ID required (though he has my banking details). Next, I did a Lufthansa online check-in from my home, printed the boarding pass. On the airport, used the self-service luggage drop-off counter. Then directly went to the security check, and then to the gate. During the entire time, nobody asked for any form of ID.
So if I did buy the tickets on cash rather than with bank transfer, it would actually still be possible to travel under false name and thus anynomously. Amazing. Am I missing something?
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 :)
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-binThis 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).
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...
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.
My fellow friends from the CCC have tried their best to observer the elections in Hessen (Germany) yesterday. The amount of resistance they've met is more than shocking. If you want to read more about this (in German), I'd suggest reading Frank's blog entry, Holger's blog entry and the official CCC release on this subject.
In fact, in some of the municipalities the election supervisors have received official statements warning them about the CCC's intention to disturb the elections. What nonsense is this ?!?
Having been part of a CCC election observer team in the past, I can only state that this is beyond anything that we've seen before. Why would there be any resistance against quiet and peaceful observation of the elections?
The CCC election observers have absolutely zero history of ever having disturbed an election in any possible way. I'm sure you can ask about any municipality that has had first-hand contact about this. We know the laws and regulations very well, and want to do nothing else but to _observe_ the
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:
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.
As a friend of mine (who has studied political science) recently told me about the process of securitization. Finally I know a word for the process that seems so commonplace in todays politics: Framing something that is actually a minor problem with some criminals into a question of essential survival, thus eliminating any rational debate about it.
Just before Christmas, my vdr powered diskless Linux-based digital video recorder went bust. A bit of testing revealed that the VIA EPIA-ME6000 main board itself must be dead.
I immediately ordered a replacement mini-ITX board without further investigating the broken one, expecting that the replacement might actually arrive before the Christmas holidays. Unfortunately this didn't happen. While replacing the board, I discovered that six of the 1000uF electrolytic capacitors went bust.
So today I finally found a bit of time (it's great to be able to find time to do things again) to try and replace the broken capacitors. Despite the new ones being slightly larger, the board now works again like a charm. And that at a total cost of 1.62 EUR.
So now I have two working mini-ITX boards. Guess I have to either find some use for it, or sell the new one again...
I've seen quite a number of presentations live at 24C3 as well as recorded ones in the days following the event. While many of them cover important subjects, there is one lecture that is outstanding: "Deconstructing Xbox 360 Security".
The level of technicality of this presentation was just right. Finally something that went deep down into the technical details. Explaining what kind of flaws they found in the disassembled power PC object code.
I definitely want to see more lectures/presentations like this. Don't be afraid to overload the audience with technical details. Just go ahead with it :)
Also, this presentation has shown how far advanced the game console hacking is compared to mobile phone hacking (at least from what I've seen in the ETC (Ada-developers) and and Motorola hacker communities). The problems are similar: Completely undocumented hardware, cryptographic authentication of code by the boot loader (sometimes down to mask ROM), ...
So I hope that the mobile phone hacker community will grow and more people with this skillet, attitude and time will join. Free your phones!
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..
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.
It's great to be at 24C3, the 24th incarnation of the Chaos Computer Clubs annual congress in Berlin.
In fact, this is my 10th anniversary at this congress, i.e. the first one I visited was 15C3. I ended up at 15C3 as somewhat of a coincidence by just following a fellow Linux hacker from the Linux User Group Nuernberg to whom I've since lost all contact.
What's actually worth mentioning is that this is the first CCC congress that I visit as a pure guest. I have no lecture, and I am not actively involved with any of the things I have been involved before, such as the video recording/streaming team or the Sputnik RFID location system.
Interestingly, I felt the first day much more tiring than usually, despite having slept more than in any of the previous years. Apparently the lack of constant adrenaline caused by last-minute-problem-solving has its impact..
The congress is a lot of fun, I've been talking to many old friends, colleagues and fellow hackers from all over the world, involved in all of the projects and/or companies that I've remotely had any contact throughout that ten year time period.
It's a very nice feeling. I doubt there is any other event or occasion where I would feel more at home than at this annual congress. This is my culture. This is where I belong. Here are people who understand, or rather: understood.
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!
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.
For reasons that I cannot yet disclose, I have obtained a HTC TyTN II (aka Kaiser). This is my first (and hopefully last) Windows Mobile based device.
So far I've taken the device fully apart, unmounted all the shielding covers and took high-resolution photographs of each and every part of the phone. The resulting information is now that I'm aware of all the major components in the device, and I've started to do some data mining on those components.
As everyone knows, HTC used a Qualcomm MSM7200 based chipset in this device. The MSM integrates both the GSM baseband (DSP+ARM9) as well as the application processor (ARM11) and many other things. What's less known is the further peripheral configuration.
For those interested, I'll go through my PCB photographs and will edit and publish them soon.
I am now digging through all the various XDA/WM6 hacker information out there and trying to understand the various tools that can be used for further taking apart the software side. I've already managed to get into the bootloader, which apparently offers a standard USB serial emulation that can be accessed even from a Linux PC.
Unfortunately the MSM7200 is a highly proprietary/closed chipset, and there is very limited public information available. I've already ran into this while evaluating potential hardware for OpenMoko at some point in the past. I became curious about this MSM7xxx chipset family when they were first added to the ARM-Linux machine type registry many months ago.
Anyway, meanwhile Google seems to be doing a lot using this chipset, as they have recently announced the availability of a linux-msm.git tree. The source code should document many things such as GPIO assignments, IRQ's and contain drivers for most of the hardware (on the application processor side).
Now if some of you ask yourselves if I have turned my back on OpenEZX and OpenMoko: No, that's not true. I'm just looking at this for a very peculiar reason. Hopefully I'm able to reveal more soon.
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.
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.