OLS 2008 is over

Yesterday was the last day of OLS 2008. In fact, the last day of OLS in general, since from next year on, it will no longer be in Ottawa, but Montreal.

2008 marked the 10-year anniversary for OLS. Impressive. I have missed at least the first one (1999). I'm not sure if I started with the 2000 or the 2001 incarnation. Most likely 2000, since that was about the time I got heavily involved with netfilter.

I had the honor to be mentioned in the 10-year-anniversary talk in a reference to my fashion style (wearing skirts/kilts at earlier OLS's). If I only had known, I might have brought and worn it again ;)

As for the conference itself: I don't want to follow all the various people who have been voicing their discontempt with recent incarnations of OLS. Sure, due to the advent of the kernel summit, the UKUUG linux developer conference, linux.conf.au, the Linux plumbers conference and other events there now is more 'competition' to attract the Linux celebrities. However, most people should not be attending a conference like it was some kind of fan club. There are still quite many people at OLS who actually _do_ a lot of die-hard Linux development work. And those poeple have interesting things to say, and it's interesting to share ideas with them. OLS is pretty much a conference where mainline developers can talk to other mainline developers. It's not an event directed at users, and not an event directed at non-participatory 'consumers' of Linux like many commercial embedded vendors.

So after all, I have to say that the conference was a success and I'd be happy to attend it's future incarnations. Hopefully with my own paper and presentation.

There is one thing, though, that upset me a lot: At the closing ceremony, there was something like a lottery for a handful of Linux-based devices. Among those devices was the Motorola ROKR2 V8. For those of you who don't know: This is a device where the vendor chose to remove your freedom to 'run modified versions of the program'. It will not boot any non-signed bootloader, kernel or executables. And the user is locked out of his own device by means of SELinux. I think it is a grave insult to the Linxu developer community that something like that was chosen by both organizers and sponsors.

Receiving the 2008 Open Source Award

According to reports here and here I had the honor of being the recipient of one of the the 2008 Google+O'Reilly Open Source Awards entitled Defender of Rights", presented by Google and O'Reilly.

I'm obviously very happy to see that my work has been recognized this way. Following the FSF Award in March, this is definitely a big honor. Did anyone else receive both awards in the same year so far? ;)

Thanks to the committee for the trust they put in my work. I'd also like to use this opportunity to thank again my lawyer Dr. Till Jaeger and his law firm JBB, as well as Armijn Hemel, who has been running the day-to-day gpl-violations.org operations for quite some time now.

Becoming VIA Open Source Liaison

Today, VIA made public what I've already been doing behind the scenes for some time: I've been contracted and appointed to be VIA's Open Source Liaison. As first part of the process, they've released the Padlock programming guide and the CX700/VX700 integrated north+southbridge manuals on linux.via.com.tw.

This basically means that I'll be helping VIA with improving their strategy for Open Source support, such as Open Source driver support, merging those drivers into the respective mainline projects as well as working on publicly available reference documentation for their hardware.

This is an incredible chance to contribute my part to help a major manufacturer of CPU, Chipset, Ethernet, WiFi, Card Reader and PC Graphics components understand what it takes to interact properly with the Free Software community. This is a big learning experience for VIA, and a teaching experience on my part, of course. I feel very happy to be able to work in such a key position, and to be able to put all my knowledge about Linux driver development, the development process, the FOSS community values/ethics/practises as well as licensing related knowledge at work.

VIA is truly interested to learn, and they're already doing a lot internally which you might not have been aware about. I am well aware of many of the historic problems between VIA and the community, related to binary only drivers, not cooperating with mainline development, suboptimal press announcements with little action, etc.

I'm very confident that together we can move beyond this and take a fresh start for much better FOSS support of VIA products. Of course the change will not come overnight. It's a process, and it involves many groups in a large company, each group with their own management, R&D and so on. So please bear with us, and don't expect all drivers to be finished in mainline quality tomorrow.

If you are a Free Software developer and you have some comment/feedback/demand to via, please feel free to contact me (preferably at HaraldWelte@viatech.com. I will try my best to follow-up with all those comments. If you are missing some piece of documentation for hardware or have some other issue, please let me know. I do care, and I will take up the issue with VIA's management.

Arrived in Canada for OLS again

I've just arrived in Canada for Ottawa Linux Symposium 2008. After my last visit to OLS in 2005, there were two years of intensive work that prevented me from attending the event. Last year I actually had to cancel an already accepted paper submission :(

In Year 01 post OpenMoko, I have time to visit OLS again. Unfortunately no company to pay for my travel expenses this time, but well, what can you do. Due to scheduling issues with a family celebration, I didn't know until very recently that I would be able to make it this year. Thus I happily forwarded the invitation to talk about OpenMoko to Werner. I was surprised that it's now actually one of the keynotes. Looking forward to it :)

There have been many rumors that OLS is not like what it used to be. Maybe I'm now in a good position to make up my mind about it, since I've missed two years and will be able to directly compare my memories from before with the current event.

UPDATE: Astaro has retroactively offered sponsoring my travel expenses, which is very nice of them - especially considering that I haven't been doing any netfilter/iptables related work for years.

Judge determines NXP has no right to prevent researchers from publicizing about MIFARE insecurity

As reported here and here, NXP has apparently not been able to convince a Judge that the researchers at the University of Nijmegen should be restrained from publicizing about weaknesses in their MIFARE RFID products.

This is really good news. And it came so quick! Sometimes, I can still believe that there is some good left in this world. Almost too good to be true.

NXP sues security researchers studying Mifare classic

In the last couple of days multiple reports stated that NXP has filed a lawsuit against security researchers from a Dutch university who were looking at security flaws of their proprietary MIFARE Classic products.

This is so ridiculous. I'm surprised that this still happens! We live in the 21st century, and IT security has become a well-established field within computer science. Furthermore, systems based on security by obscurity should be long gone.

So we have a company that in 1994 first ships a allegedly secure RFID technology. They developed a proprietary algorithm that did not receive public peer review in the cryptographic community, and used weak random number generation as well as made some mistakes in the protocol/system design. They ship this even back then questionable product without any fix/update for 14 years, irrespective the advances in technology and cryptographic research. During all that time, NXP marketing material claimed the product was fit for 'high security applications'.

Any reasonably skilled person in IT security could determine that the public statements "proprietary cipher" and "48 bit key length" did certainly not sound like high security at all. Thus, it's not surprising that in the last two years, some people, mostly friends of mine, started to look closer at what MIFARE classic is and what it does.

They should be honored and rewarded for their public service in demonstrating the irresponsible behavior of mostly NXP's customers (system integrators) and NXP itself. And exactly those companies are the ones that should be sued for continuing to milk a known-insecure cash cow for more than a decade.

I'd be more than happy to see somebody actually standing on their feet and demanding damages from those vendors. Imagine a small system integrator for a vertical market who wants to look for a secure/safe electronic wallet system and believes in the vendor promises. Now he gets defrauded because some criminal energy - not the ethical researchers at universities - exploit some weakness.

The only reason why large technology companies rarely get sued over the massive security problems they cause in their proprietary products is the fact that almost nobody (even the system integrators and developers) really understand that very technology enough. I sincerely hope that this changes at some point, and we see all those lame promises about alleged (but completely unverified) security go away.

If people would just use publicly disclosed, well-known, well-studied and well-analyzed cryptographic algorithms and implementations thereof, this world would be a much more secure place.

A trip to Fulong beach in the northeast of Taiwan

On Saturday I went to Fulong beach. Believe it or not, my first bathing-at-a-beach trip in Taiwan, despite the long time that I spent on this tropical island.

The venue of the beach is really nice (photos will follow later). The water temperature of the pacific ocean felt surprisingly cold to me - but keep in mind that I'm still spoiled by the 28 centigrade warm Atlantic ocean in Pernambuco/Brazil ;)

However, it wouldn't have been a Taiwanese experience if there weren't some strange observations. First of all, I obviously appreciate that there are a number of life guards. But then I found out that they had a rope in the water, which you were not supposed to pass. The problem with that rope, though: It was at a water depth of about 1 meter to 1.10 meter!

So imagine a huge beach, of which there is a small portion separated by this rope floating on the water, and all the people are crammed into the small confinements between the actual waterline and that rope. The sea was incredibly calm, I could not even detect the remotest hint of any underwater currents, the slope of the ground is _very_ flat, but you can't actually get into the water to swim.

The other peculiarity was that the beach closes at 5.30pm. WTF? Especially during those incredibly hot days, why not just stay in the water into the evening or even at night?

So as a summary, I have to say, Brazilian beaches rule in comparison! Nobody to tell you that you cannot go into water deeper 1.10 meters, beaches are always open (there are no private beaches, they're all public), and most part of the day you will get served beverages, alcoholic drinks and fresh food.

So this trip to Fulong beach was certainly an experience I wouldn't want to miss. But not one that I'm likely wanting to repeat again. I now know what it's like :)

Submitting pcc_acpi for mainline inclusion

The last couple of days I've once again updated my kernel to current linux-2.6.git and I had to do the manual merge of the apparently abandoned original out-of-tree pcc_acpi.ko driver in order to get brightness control of the LCM on my Panasonic CF-R5 laptop.

I've tried to contact the original author multiple times during the recent years asking about his mainline inclusion plans, with no response so far. So this time finally I decided to submit the driver even without explicit wish by the original author. It was already GPL licensed, so no problems here.

However, the driver didn't yet support the backlight class device API, neither did it support user-configurable keymaps on the input device for the hotkeys. It furthermore added tons of new files to /proc with all the ugliness of writable proc files, and it didn't conform to the coding style at all.

Matthew Garrett was extremely helpful with his fast review, and I have just sent the 0.94 version to linux-acpi, hopefully the last one before kernel inclusion. I should have done this a long time ago, but it just didn't feel right to go ahead without the original author's opinion. However, the driver now doesn't really look like the old driver anymore, very little code left. So I feel like I have more moral right to go ahead with it now...

Of course I've only tested it on the CF-R5. Anyone with different Let's note models and versions: Please feel welcome to test it and send bug and success reports.

Electrical installations in Taiwan

I haven't noted this here yet, but I'm in Taiwan again since two weeks ago. I also have two more weeks of Taiwan ahead, since I decided to stay a full month and go to a Chinese language school. Now don't expect too much, this is basically just to find out whether I really want to seriously learn about the language or not. Four weeks will not get me anywhere, at least not beyond pronunciation drills and very basic sentences + vocabulary.

Anyway let's get to the subject of my posting: During the last couple of days I actually spent a significant amount of time trying to find something that to me is the most normal thing: A 60W 220V light bulb with an E14 socket. But that would apparently only be normal in Europe. Here in Taiwan, the voltage typically is 110V at 60Hz, with US-style power sockets. Basically just like the US or Japan.

However, for some really strange and unknown reason, the particular apartment has both 3 phase 110V and 3 phase 220V. The power sockets are all 110V, whereas the fixed ceiling lights are all 220V.

So apparently sometimes people have 220V lights here, and you can get a limited selection of usual bulbs in 220V type, even though 90% of the light bulbs in the store would be 110V.

I've been to Carrefour, B&Q and Tsan-Kuen (all large super-stores in NeiHu). 220V was really rare, and neither of them had any E14 bulbs (independent of shape) for 220V. So after a lot of wasted time, I then decided that I'm just going to replace the entire lamp socket with an E27 type in order to accommodate a different lamp. My other option would have been to add another E14 socket in series and then use two 110V bulbs attached to 220V mains.

Now the really big question is: Why would anyone have the lighting at 220V whereas the power outlets are running1 at 110? This means you need separate infrastructure, separate lines, transformers, metering devices, circuit breakers, etc. And three simply is no point. I could understand 3-phase 220 is better than 3-phase 110 in case you want to use extremely high-power consumers.