So I’m sitting here in my hotel room in Helsinki, after a quick flight from Oslo. In fact, the flight arrived early, and that’s a first time that it has happened for me. I was in the taxi on my way to the hotel 5 minutes before the scheduled time of arrival for the flight.

Anyway, so I got to hotel, had a shower, turned the laptop on, and logged on to the wireless service provided by the hotel along with the phone company. Then I connected to the Nokia VPN and my own VPN to download my emails. After reading said emails, I hopped on to IRC.

As a helpful chap that I am, I saw someone posting a link on the #qt channel to some code of theirs they were having problems with. I clicked the link to see what the problem was. The bizarrely-sized progress window in my KDE 4 popped up, with the progress bar indicating no progress at all.

“Odd,” I thought, then I clicked Cancel and tried again. No such luck… “Maybe that website is just not working from here” I pondered. I decided to try one famous search engine whose reminds us of a very large number. And again it didn’t load.

I was having network trouble.

My first reaction was to test whether the Nokia VPN was still on. It was dead, but vpnc had not disconnected, so the traffic to the Nokia VPN wasn’t going anywhere. I disconnected, but still no Internet.

A couple of minutes of searching, I found out the reason:
cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 10.0.0.6
search example.com

(This is not edited, the hotel internet really gave me a domain search of “example.com”)

Can you guess what the problem was?

Let me give you a hint: my blog six months ago called “The Great Crash of 2009” addressed this very subject.

The DNS server that the hotel network gave me is on the same network as my home VPN (because my home DHCP server is the ADSL router by my Internet provider). So all my DNS queries were timing out, because they were being transmitted over the VPN to an address that isn’t active. (I think it’s assigned to my N95 when I’m at home, but I’d have to be home to check)

This problem I had is probably quite common, I imagine. I mean, the hotel I’m in isn’t exactly in a touristic spot. It’s probably sought more by business travelers, who, like me, come with a laptop and VPN access to their offices. How many of them reroute 10.0.0.0/24 when the VPN is active? I would bet quite a few.

So we’re 6 months into the year of the Great Crash because IPv4 runs out. And we’re still not using IPv6.

Quick update on how the transition worked

The blog of 6 months ago analysed our own transition into the Nokia network as a case study of where IPv6 would have been helpful. The curious readers of this blog were left imagining “how will they pull off this transition? Will the FTP servers ever be tested again? Can the Trolls print?”

I left you in suspense, so here’s what happened in these 6 months.

Yes, we can print. Otherwise I wouldn’t be here in Helsinki, because I wouldn’t have printed my eTicket.

The network transition isn’t complete yet. I don’t know the exact reasons why our test farm remains in the old Trolltech network, but it does. All I’ve heard are anecdotes and the worst cases. For one thing, we received the level 3 switches that serve the network. But our sysadmins could not install them: we had to wait for a technician to come from the outsourced network provider, unpack the switch, install it in the rack and plug the cables.

Our QA department has been expanding our virtual machines for running tests in parallel. A week or two ago, they reported they couldn’t add more machines. The reason? They had run out of IP addresses in the block allocated by the outsourced network provider. They had to wait for a new allocation — possibly a reallocation!

The network tests in Qt have all been updated to reference the test server by a generic name, “qt-test-server.qt-test-net”. Anyone running the network tests must update their /etc/hosts or Windows equivalent with the IP address of the virtual machine.

(By the way, the network tests of Qt have been made available in the open repository for anyone to see)

We also had to go over all the tests and fix any failures caused by moving to the Nokia network. All of the network tests are now passing (including the one in tst_QHostInfo that assumed that “foo” would never resolve).

Now we have to face other problems. Like today not being able to log in to the Nokia intranet websites… but this one I had been expecting: Nokia IT requires us to change our passwords every 90 days.

The price of security. (Or is it?)

As the Nokia Developer Summit 2009 wound down to a close, I spent a few minutes pondering what effect it had had.

For those who didn’t know, the Summit was held on April 28 and 29 in Monaco and I had a chance to participate and present. Don’t worry, when I arrived on Monday, it was rainy and cold, so I had to spend time in my hotel room working And I did not lose any money in the casinos — nor won. I did have the time to take some pictures of where the Formula 1 Grand Prix will take place in a few weeks’ time.

The subtitle of the summit was “Creating tomorrow’s technology” and the whole subject was “developers matter”. And I, as a developer (if only at heart if not on paper), feel proud that the company is putting that emphasis. It is no surprise to anyone who has followed the mobile market that applications are the driving force. No matter how good and sexy a company makes its devices, it’s the applications made by 3rd-party developers that make the allure. In other words, a company cannot compete with the combined agility and innovation of a community of developers.

That sounds familiar, doesn’t it? It’s the whole principle behind Open Source, even though opening the source code is not necessary here.

That brings me to another subject of the summit: Open Source. It wasn’t emphasised by presenters, but it was there if you looked for it. Let’s recap:

• Qt is Open Source and always has been
• Maemo is Open Source and always has been
• Symbian is going Open Source (under the Eclipse Public License)
• Nokia relies on Open Source software and needs the power of the community

Now, why am I posting this here? Am I now a corporate drone?

Well, there was also another undercurrent present throughout the presentations: Qt. Almost every presentation (non-Nokia guests excluded) mentioned Qt in some form or another. In fact, if you go to the summit website and watch the introductory video by Rob Taylor, Head of Forum Nokia, you’ll see him saying around 8:45:

For those of you who have cut your teeth on mobile application development with Symbian and Java, we encourage you to learn more about Qt. Sure we’ll continue to support Flash and Java, make no mistakes about that. But it’s Qt that’s our future direction in this space.

Surprise? Not to me (just like when the S60 port was announced last year). After all, Nokia spent a hundred million euros acquiring Trolltech. That was to use Qt.

We had a lot people coming to our stand about Qt and learning about it, the licensing terms, etc.. There were 4 or 5 exhibitors there at all times (thanks to KDAB and basysKom for the help!) and they were always busy. We had a hands-on hacking session, going all the way from QString to SQL and ItemViews. Again, the room was full.

So, interesting times ahead.

BTW, Qt Developer Days has been confirmed for this year again, in Munich and in the SF Bay Area. Hope to see you there!

Last year I wrote a rather strong blog when I was frustrated, titled Desktop Effects? Never more. In that blog, I was relating one of the side-effects that I had when I switched from KDE 3 to KDE 4. For context, for those who don’t want to read the entire blog (and you shouldn’t), I finally switched just before KDE 4.1 was released. Until then, I had been running KDE 3 and 4 in alternance, or with some KDE 4 applications inside KDE 3, etc. (and it would be a few more months until I stopped using my last two KDE 3 applications: Amarok and Kontact).

The issue that was driving me crazy was that desktop effects were unusable at that time. First, kwin would use 90% of the CPU. Second, windows would disappear (100% transparent) or turn black. To top it off, one runaway debug message in kio_imap4 ate all of my disk space, driving me over the edge (as far as I know, that issue is still present). Since then, I have also had problems with Kontact / KMail — every two weeks, more or less, it would forget its account configuration then proceed to delete all my email cache.

This blog now had been long coming: I officially apologise for my words and retract all I said. I have been running desktop effects for months now, without a hitch. What’s more, all the issues I mentioned in the blog are fixed (aside from the kio_imap4 debug output), including Konsole’s redrawing speed on window resize. Turns out that KWin taking 90% of the CPU when using glib was caused by some code that had been designed to save CPU when using glib…

Also contributed to this the newest NVidia binary drivers. It took a long time, but finally the 180.22 version fixed all issues I had in my workstation (8600GT, TwinView) and in my laptop (8400GM, also running TwinView). All versions prior to it had issues, either causing freezes or showing garbage or with disappearing windows.

Now, it would be a pretty boring blog if it didn’t have a plot twist: I have been thinking about writing this blog for over a month now. I was delayed due to travelling (I did OSL-MUC-SFO-PDX-DFW-SAO-REC-SAO-FRA-OSL in 15 days, attended two conferences, visited my parents and two offices). And I was delayed by a bug in Plasma.

Last week, after updating Plasma from Subversion trunk and restarting it, the secondary (right) screen in my dual-screen setup started not repainting completely. The wallpaper was shown only at the top-left corner, leaving the bottom and right not painted. And with desktop effects enabled, this not-painted area got composited with the windows, thus yielding garbage. (Think about it: if you alpha-blend a nice Konsole window with unpainted garbage, you get blended garbage)

So I had to turn off desktop effects. And I felt it would be hypocritical to say I’ve been using desktop effects while I had it turned off.

Well, if I’m blogging now, it’s because it’s fixed. And desktop effects are back on. The bug was quite simple and doesn’t deserve much attention (r948226 is the fix). What’s interesting is what I learnt in the process. Besides, this was a one-week period only, whereas I have been using desktop effects for months now.

Remember: I’m the network guy, who knows the tool classes and maintains D-Bus. I don’t have the first clue about painting. What’s more, my day job now is about maintaining Powerpoint presentations…

1. First thing I learnt is that Qt Creator can already load CMake-based projects quite fine;
2. To load a CMake project, Qt Creator requires a generator called “CodeBlocks“, so you should start cmake like this:
   cmake “-GCodeBlocks - Unix Makefiles” <other options> $srcdir;
3. If you already have a CMake build tree, you can add a new generator (or any other options) by using the undocumented -H and -B options:
   cmake “-GCodeBlocks - Unix Makefiles” -H$srcdir -B$builddir;
4. Once I did that, I could use Qt Creator’s very useful “find definition” F2 shortcut to navigate the code. It came in very handy as well when I was debugging D-Bus last week. And note that D-Bus uses an automake/autoconf-based buildsystem which is not supported yet;
5. The CMake support in Qt Creator lets you choose which targets to build and to debug. The list was impressive when I loaded kdebase;
6. Debugging Plasma inside Qt Creator is possible;
7. However, debugging my problem in Qt Creator was extremely slow. Apparently having 120+ stack frames slows things down considerably (but I hear it’s being worked on already);
8. Turns out that the 120+ stack frames should have hinted me to the problem in Plasma (having three nested paint events was the clue);
9. If you’re step-by-step debugging Plasma, the clock doesn’t get updated,

On that last thing, here’s how I found out: I was debugging Plasma while in a phone conference, and every time I looked at my clock, I wondered, “Time is going slow today, it’s still 14:25. This phone conference seems like it’s never going to end”. I really should have clued in by the third time…

The remaining things I would like to see fixed (they’re by now only annoyances):

• The NVidia binary Open GL libraries are compiled without -fPIC. This means every single process that links to libGL.so on Linux automatically uses 10 MB of non-shared memory, at load time, and there’s nothing we can do about it. This affects every user of the binary drivers, regardless of desktop.
• My keyboard has a few extra keys labelled 1 to 5 that xev recognises, but I can’t get them to work as application switchers with KWin. I’ve heard that this is related to a Qt issue (have you ever tried to set a shortcut and the KDE dialog tells you “the key you pressed is not supported by Qt”?), but I have yet to see some confirmation on the issue. If you know this to be a bug, please report it.

And, oh, it’s now way over a month since my last blog when I said the snow was melting away… we’re now in April and the snow is not completely gone yet.

Today we is a day that will be remembered for a long time in Qt history (I expect that we’ll remember it all the way until next week at least — that’s at least a thousand commits). I made today two 280,000-line changes to Qt, touching over 6500 files in each. At the end of the day, three Qt branches (4.6, 4.5 and 4.5.0) now contain the LGPL license header in all Qt’s .cpp and .h files, plus an assorted set of scripts. Third-party code is obviously excluded from this change. That means the GPL era of Qt comes to its end — and LGPL starts.

Today, I stopped the cron job that creates and publishes the Qt snapshots. Mostly because the LGPL and other changes are very likely to break stuff. And that we don’t want the snapshots published under the LGPL until we actually release 4.5.0 next month. What’s more, I don’t know if snapshots will ever come back: maybe we will go directly to the open repository. That’s the end of the snapshot era.

Today, Alexis also made changes to the Qt repository in Git, removing the never-released files and adapting the the license files. He also refactored the license part of the configure script and the Windows configure.exe (it’s a good thing that I turned snapshots off, because he went to ski shortly afterwards in a classical example of “submit-and-run” ). That’s one of the last steps required for the open repository, though there are a few minor things to go.

This week, the temperature in Oslo reached 0°C again. That means the snow is starting to melt and the streets are very dirty now. The mountains of snow that we have collected over the past few weeks will gradually disappear. That’s the end of Winter, but I hear it will come back (I don’t put too much faith in those rumours).

This month, I’m also stepping down as Release Manager for Qt. I had pre-announced this at Developer Days last year, but it’s effective now: after 18 months and releasing Qt 4.3.3, 4.3.4, 4.3.5, 4.4.0-tp1, 4.4.0-beta1, 4.4.0-rc1, 4.4.0, 4.4.1, 4.4.2, 4.4.3, 4.5.0-tp1, 4.5.0-beta1, 4.5.0-rc1 (and two mac-cocoa alphas), it’s time I pass the torch to the next poor sob brave soul to take on the job. So this is also the end of my era as Release Manager. (No, I’m not leaving Qt Software, I’m just moving on to other responsibilites)

It’s interesting to note that the change in RM matches the change in environment. It’s tradition that each new RM gets to rewrite the release scripts from scratch. The RM before me had all of it working for our setup with Perforce. I rewrote it to use Git. After me, you can’t call them release scripts anymore, because I rewrote them in C++, using memory-mapped files and QtConcurrent. Now my successor will have the chance of rewriting it to match the open repository. It looks like packaging will be a lot simpler, since there will be no file editing or removal.

This is not a sad time. At least, I haven’t seen anyone crying their eyes out in the office. So I must conclude that this is a happy time: the end of an era marks the beginning of a new one. We can only hope that the new era will be even better than the current. We’re certainly going to make our best effort.

Disclaimer: this blog could be part of a conspiracy against Qt on Windows.

Sebastian Kügler blogged yesterday about why distributions shouldn’t jump on upgrading to Qt 4.5 while shipping KDE 4.2. This caused quite a stir in the community as well as inside Qt Software. Sebas then replied to Cyrille’s blog explaining a bit more (if the link doesn’t work, scroll down; blogspot comment links don’t do anything for me).

Sebas is right: Plasma developers did not test KDE 4.2.0 with Qt 4.5. So there may be issues that they have not seen or corrected. That’s entirely true and no one can blame the Plasma developers. After all, resources are limited and prioritising the work was necessary. Therefore, distributions should be careful when upgrading Qt, because they may introduce problems. But, then again, isn’t that the job of distributions? To make sure their package set works without issues? And in case patches are needed, they can backport fixes from upcoming releases or introduce a temporary hack.

However, Sebas is right only up to a point. We at Qt Software have done testing of Plasma with Qt 4.5. In fact, we know it works better with 4.5 than with 4.4.3, though some of the qt-copy patches help somewhat. Has anyone noticed that the system tray finally works in 4.5? But, more importantly, other parts of KDE (other than Plasma) benefit greatly from Qt 4.5.

Just to give you an example: I still build my KDE trunk with Qt 4.4, then run with 4.5 on my main development workstation, but with the standard 4.4 (pristine, unpatched) in my laptop. After logging in to KDE, I usually get Kontact crashing within 5 minutes of using: when I click on a folder, it crashes with a dangling pointer dereferencing. Then I remember I have to restart it with QT_NO_SHARED_PAINTER=1. But this crash never happens on my workstation: standard 4.5, pristine, unpatched.

What’s more:

• We did lots of testing and fixing of KDE 4.2 for Qt 4.5, but not with Qt 4.4
• We did a lot of fixing and stabilisation in 4.5 itself and most of these changes did not make into 4.4
• Performance improvements in 4.5 are noticeable, especially in the painting code and itemviews

I can hear the arguments saying that those fixes should have bene done in the 4.4 line and that we should have prioritised that over the feature release. I know those arguments because the discussion happens in Qt Software too: it’s only natural to have it. But the same way that Plasma developers were faced with a finite amount of resources, so were we: we had to prioritise work. Qt 4.5 is the future and we needed to stabilise it, so we did focus most of work there. (We did not forget 4.4, you can find several fixes in the Qt 4.4.4 snapshots)

And I don’t have to say that we can’t fix further issues unless they are reported to us. If people don’t use 4.5, those issues will not be found (read: our QA people can’t find every single issue). With the 4.4 release, we had a very good feedback from the KDE community: KDE 4.1 started using 4.4 very early, I think even before the beta (Feb 2008). That means we had a lot to work with in order to stabilise Qt 4.4. By the time of the 4.4 release candidate, we had had two months of continuous feedback and stabilisation work done. And we have one more month left, more or less, by which time KDE 4.2.1 (with its own set of fixes) should be out.

And my personal, subjective experience comparing now (4.5 RC) to 10 months ago (4.4RC), things are a lot better and more stable.

We’re finally there! The long-awaited Qt 4.5 release candidate is out! Downloads are available through the QtSoftware website. For the impatient, I’ve copy/pasted the download table here:

Note to self: ask webmaster to use the same CSS theme in both Labs and in the main website

We’ve done lots of work in performance and we added the pluggable graphics system support. Performance on the native and raster engines should be much better than it was before. Performance work also touched Graphics View (clipping, scrolling) and went even as far down as URL-parsing in QUrl

We added support for 64-bit applications on the Mac with Cocoa — though you can use Cocoa in 32-bit too. I don’t know why, after all you have more registers in 64-bit (that’s what Apple tells anyways).

We upgraded QtWebKit to upstream trunk, bringing in some HTML5 features as well as Netscape Plugin support, meaning you can finally see ads on websites (who knows, you may even be one of those who click on them!). By integrating QtWebKit with Phonon, we added support for <audio> and <video> tags, without the need for a Flash video player.

We also upgraded Phonon to the latest release (4.3.0), though this technically means we’re making a new release of Phonon (4.3.1). The QuickTime 7 / QTKit backend for Phonon got an overhaul and was rewritten in Objective C so that it can be built in 64-bit mode too. We also added a new, very simple backend called “waveout” for Windows CE devices that have no codecs or DirectShow.

QtScript got a debugger, both in the form of an API (see the QtScriptTools module) and a graphical debugger.

And one of my features has finally made it to the news page: improved proxy support.

Thanks to all the trolls who did amazing work for this release and to all contributors who sent us patches, ideas and feedback. We’re releasing at an all-time low of Priority 1 tasks left, but feedback is definitely welcome. Please post your feedback to the qt4-preview-feedback@trolltech.com mailing list and we’ll be sure to address it as soon as possible.

Edit: Qt Creator 0.9.2 RC is also out!

I was going to blog about the news the net is now talking about, but when I opened up the Labs blogging homepage, I noticed that one certain “snystrom” had beat me to the punch

So, I won’t repeat what he said: please read his Nokia to license Qt under LGPL blog. Other useful links:

• The announcement
• The FAQ
• The KDE dot article

I’ll just add that the opinion of most trolls here in Oslo is positive, supportive of the decision.

I was searching the Internet now for the phrase “Greek present”, but I couldn’t find it in English. It appears to be a Portuguese expression only: “presente de grego” means a present you really don’t want. The reference is to one famous present the Greek gave to the Trojans a couple thousand years ago.

The reason this came to my mind today was we’re giving you two early Christmas presents today, both related to the Greek alphabet. And unlike the Ancient Greek, we think you’re going to like these presents . The first one, Thorbjørn blogged about earlier today. The second, it’s my honour to present once again: Qt 4.5 Beta is released!

That’s two betas in one day. You’d think that we would have planned this carefully to coincide and to be close to the holidays. I guess that, had we planned that in the first place, we wouldn’t have made it. But it’s all for the better that it worked out fine

You all know the main features we added for Qt 4.5, so I won’t dwell on them here. But you can see that the addition of a new port (to Mac Cocoa) is our focus for the moment (Watch the Widget Pimp^W^W^WTrenton’s video on Youtube if you can’t see in our webpage)

I’d like to emphasise one point that Thorbjørn didn’t emphasise enough: Qt Creator is now Open Source. We had planned on doing that the whole time, but the need to publish the alpha trumped getting organised. And more than that: Qt Creator’s source code repository is available for everyone to see. Unlike the existing Qt snapshots, this is the real thing and is the same source code that our developers are using. No tricks!

And it couldn’t be any different: Qt Creator beta uses Qt 4.5 beta. So you should download the latest and greatest Qt too.

The Qt 4.5 beta is a great improvement to the technical preview we released almost two months ago. Whereas that was a package just after feature freeze, containing whatever we had at the time, with minimal QA, the beta is about a more polished product. We aren’t release quality yet, but we’re that much closer.

Between the TP and the Beta, we’ve done a lot of bug-fixing, regression testing and general polishing. We’ve updated the documentation and added new examples and demos too (I highly recommend the new Boxes demonstration, even though that’s very CPU and GPU intensive). Like I mentioned in my last blog, we’ve taken a lot of care to fix both glaring and subtle issues that still plagued Qt. I’ve been running KDE 4.2 beta using Qt 4.5 beta for the past weeks, without major issues, and, like I said above, the Qt Creator beta is also using Qt 4.5 beta.

That says a lot. In fact, when we started discussing with other groups inside Nokia what they call “alpha” and “beta”, it became quite apparent that our definitions are one step ahead of theirs. What they call “beta”, we’d call “alpha” or “technical preview” (feature-complete, documented, unit-tested, minimal integration testing and manual QA). For us, “beta” has to pass a series of baseline scenarios, compile in all of our supported platforms, plus it needs a month or two of QA.

That being said, you’ll still probably find issues with Qt 4.5 beta. If you do, please let us know: send email to the qt4-preview-feedback@trolltech.com mailing list (see the announcement for subscription instructions).

Happy holidays everyone and happy hacking!

But in a good way

I remember back in 2006, when I was a brand, new engineer at then-Trolltech AS, I was the only one who still built KDE 3 from sources. Everyone was using distribution-prepared packages: mostly Kubuntu and SuSE, but also source distros like Gentoo, as well as FreeBSD (ports tree). And I remember this fact for one simple reason: being able to run many Qt applications (KDE) with the Qt you’re developing makes you find your issues a lot sooner. In other words, the chances for ugly issues slipping through releases was much less.

But 2006 means we were working on Qt 4.2 already, while KDE hadn’t released 4.0 yet. We had only Qt Designer, Assistant, Linguist, and one other internal application to test with.

Now, the situation is different. Many of the engineers are running KDE 4. Not only that, a few brave souls are actually running — if not compiling — KDE 4 with the current Qt 4.5 from our Git repository. That’s why I say KDE 4 is blocking the release of Qt 4.5. I won’t say it is the only reason, but it’s a very important one.

Three weeks ago, I did a full build of KDE 4 from trunk (to-be-4.2) with the standard Qt 4.4 sources. Then I launched it with Qt 4.5. For one thing, I haven’t detected a single issue related to symbols, so there don’t seem to be any binary- or source-compatibility issues.

However, even though applications started, they were unusable, if they didn’t crash. Three weeks ago, this was the situation of a KDE 4 desktop with Qt 4.5 (with desktop effects enabled):

• the Plasma panel was 100% transparent
• moving the mouse over the Panel taskbar had no on-mouse-over effects; worse, the clicks went through the taskbar to the panel, so you couldn’t activate windows with it
• for a few days, Plasma crashed on startup
• Plasma looked completely horrible with the raster paint engine
• Kontact crashed on startup
• the slideshow screensaver (kslideshow.kss) showed inside a window, occupying half of my left screen only (the rest of the desktop was visible and updating)
• going to an https website in Konqueror then going to the next would show the wrong certificate
• Akregator hit an assertion failure and crashed
• opening any directory with Dolphin would show everything unsorted, until you changed the sort order
• krunner crashed when you typed “kat” (no e)
• some threaded applications (like krunner) crashed randomly
• …

I must point out that the same KDE 4 build worked fine with Qt 4.4.

Suffice to say that a release of Qt 4.5 with those issues would be a Brown Paper Bag release.

So we looked at our plans for Qt 4.5 beta and decided: among other criteria, we would make sure KDE 4 was running smoothly on X11 with whatever we released. (Other criteria included Qt Creator running smoothly on all our main platforms, all of our Tier 1 and 2 platforms compiling, etc.)

We then assigned Olivier and Alexis to spearhead the project that would ensure those issues were solved before the release. Of course they couldn’t do everything — for example, the screensaver issue required getting the Graphics Team to add a new flag to Qt 4.5. And some of the issues weren’t Qt issues, but bugs in the KDE code that just happened to get away with it in 4.4.

However, most of the issues I listed above were actual Qt regressions.

And I’m happy to announce that, today, the last visible issue we could see has been fixed! More than that, Qt 4.5 also fixes some issues that I still see in my laptop (which runs 4.4), like kontact randomly crashing when I click a folder, some KIO networking issues, or a race condition in QtDBus code.

By no means we’re done (krunner crashed on me today in QtDBus code), but at least it looks like we’re in good shape for a beta release sometime soon.

Stay tuned!

No, I’m not talking about the economy. That would be past anyways… And would be completely off-topic for a technology blog.

What I’m talking about a crash of the way Internet works. Several years ago, it was predicted that, unless we moved on by 2009 or 2010, we’d face serious problems. And, like many predictions, it may or may not come true. But this blog is about a symptom of this larger problem: IPv4 is running out. Quoting from Wikipedia:

David Conrad, the general manager of IANA acknowledges, “I suspect we are actually beyond a reasonable time frame where there won’t be some disruption. Now it’s more a question of how much.”

Background

I’ve been passionate about IPv6 for several years now. In fact, that’s what brought me to KDE in the first place in 2000, which indirectly contributed for my being here where I am now, in Qt Software. I added IPv6 support to KDE as my first contribution, thus making Konqueror one of the first browsers that were IPv6-capable. For several years, I was able to see the dancing turtle at the KAME webpage. It only stopped when I moved to Europe in 2006 and had to use one of those router boxes in my ADSL lines. Since then, I haven’t had the opportunity to use IPv6 anymore.

And that’s the truth for most people and companies. That means there’s a proliferation of intranets using addresses reserved by RFC 1918 — the famous 10.x.y.z, 192.168.x.y, etc. A couple of years ago, you’d still find companies that used public IP addresses on their workstations. Today, those are rare exceptions.

We’re seeing problems with that setup now. Almost every router box you can get puts you on 192.168.0.x or 10.0.0.x. And since corporate networks use the same reserved addresses in their own networks, many people are unable to use VPN solutions because they lose access to their own local network.

Case study

Trolltech used to be a small company. In the past, the workstations in the Trolltech office in Oslo were given their own public IPs, but were firewalled against intrusions from the outside. As the company grew, we exhausted our address pool and then decided to move to private addresses, leaving the public ones for servers.

A simple setup was devised: the 10.1.0.0/16 network was assigned to the Brisbane office, 10.3.0.0/16 was assigned to Oslo, 10.4.0.0/16 was assigned to the Berlin office, 10.5.0.0/16 was assigned to Munich, and 10.6.0.0/16 was assigned to the U.S. office (then in Palo Alto). The network administrators at Trolltech probably had the good foresight of not using 10.0.* because that would clash with routers.

Now, you can expect many medium-sized companies to have similar setups, right? How about large companies? In those, however, the situation is very different. Instead of assigning large blocks per location, smaller blocks are allocated per network, just like on the Internet. That’s because the range of IPs and blocks are limited. So you can expect a 50,000- or 100,000-employee company to use a much complex scheme.

The problem

And then Nokia acquired Trolltech.

Obviously the Trolltech IP allocation was too liberal for the Nokia network. It wasn’t enough to plug cables in our routers and set-up the VPN links to an entry point to the larger Nokia intranet: we couldn’t continue using the same IPs! Every single workstation and device that was/is plugged to the network needs to change addresses: not just our workstations, but also the printers, our embedded devices, our testfarm of exotic Unix flavours and jurassic Windows versions, etc.

In order to support a progressive migration, our network administrators set up NAT in the Nokia-Trolltech router devices. That is, every machine in the Trolltech network got an IP address in a temporary network in the Nokia intranet, so that the services can be routed. Then, once the machine/service is migrated, it gets its permanent IP. That means each machine has 3 different IP addresses reserved for it and, along with it, 3 different hostnames.

For example, my machine was called “lothlorien.troll.no” (IP address 10.3.5.19). To access it from the Nokia network, one could use “lothlorien.nokia.troll.no” (10.215.5.19). Now that I’m connected to the new intranet, it’s known as “lothlorien.europe.nokia.com” (172.24.90.18).

Compounding the problem

As if that weren’t enough trouble, there are more issues. We have several services hardcoded in our internal tools, like our internal pastebin, our task tracker database, our wikis, etc. More than that, we have unit tests for the Qt network classes, for which the test server’s hostname was hardcoded.

That means someone in the Nokia intranet cannot run the unit tests: the host will resolve to the wrong IP address.

Change the tests, you say? Well, the migration isn’t complete. In particular, the machines doing the automated tests aren’t migrated, so we can’t. Even if we did, remember that we’d have to do it again…

So the trick is to add it to /etc/hosts? That solves some of the trouble, but not all. For one thing, the Qt3Support network classes use Q3Dns, which bypasses /etc/hosts. For another, the classes doing FTP tests will not work, since FTP servers doesn’t work behind NAT. And finally, our proxy tests won’t work, since we end up telling the proxy server to connect to the wrong IP address (problem solved in Qt 4.5 by using the hostname instead).

So, in the end, those of us who are doing network development are in the situation in which we have to ignore FTP and some other errors because of this issue.

(The actual solution we’re working on is to reinstall the network test server onto a VMWare image so that we can run it from anywhere, as well as distribute it sometime in the future).

What if we had had IPv6

Well, if we had had IPv6 to begin with, none of this trouble would have happened. First of all, we’d have been using public IP addresses from day 1, even if we were firewalled. Just like the old days in the Trolltech Oslo office.

The smallest allocation that is usually given is a network with a 48-bit prefix. That’s enough for 65,536 networks of 64-bit (good for 18446744073709551616 IPs, but usually you’d split the network long before that). The 64-bit number is not chosen by accident: it allows IPv6 to operate in the so-called “stateless address autoconfiguration” mode. Each network interface has its own 64-bit unique identifier known as EUI-64, which it concatenates to the 64-bit network prefix (the 48 of your allocation, plus the 16 of the network ID), forming the 128-bit IPv6 address. To do that, all it needs is a router advertising the prefix over ICMPv6. For Linux-based routers, you can install the radvd daemon to do exactly that.

That means we wouldn’t even need DHCP. That solves yet another problem of the transition: the policy of the Nokia network administrators is not to give static IP addresses to workstations. The rationale is that, by using DHCP, they are able to reuse addresses of machines not seen in a long time, as well as to find out when a network is reaching saturation. With IPv6, there’s no such problem: there’s no DHCP server to be maintained, there’s no need to reuse the address, since the chances of exhaustion are remote. Network congestion will happen long before that. And we get to keep a static IP address, so that I can ssh into my workstation from my home via VPN.

That’s assuming that we wouldn’t need a change in the network prefixes themselves. That could happen, though, since we got a brand-new 34 Mbit/s pipe, or because Nokia wanted everyone to be inside their main corporate prefix. Well, even if there were the case, there wouldn’t have been any disruption:

1. First, we install the new hardware (routers, level 3 switches, etc.) and the new Internet connection
2. Once the prefix is routed properly to our network elements, the routers in our networks start advertising a new IPv6 prefix
3. Automatically, all IPv6 nodes assign a new IP address, without losing the old one. Yes, two IP addresses on the same interface (you probably have one more anyways)
4. Then the network administrators do a search-and-replace on the DNS zone files, changing from the old prefix to the new one
5. The routers then stop advertising the old prefix
6. Since there would have been no NAT in place, we’d never have had the problems I presented for our FTP and proxy tests.
7. As a final step, after the automatically-configured IP addresses expired, the old Internet connection is disabled

As a side note, if the A6 DNS record had been put on production instead of AAAA, our administrators wouldn’t even need to do a search-and-replace in step 4: it would be a single change, in one place.

Conclusion

This was just one case study, showing how stubborness to move away from IPv4 can make our lives more difficult. The predictions I mentioned above are from several years ago. And we still have not seen the migration start. I guess it will really take hitting people where it hurts the most (their pockets) for the transition to start.

I wish circumstances were different.