This week we have implemented a system which makes it possible to return the geographically closest anongit and anonsvn mirror available for you.

We have three mirrors for both. One not located in europe and two are. If you are europe you want to use the ones in europe and if you are physically closer to the third mirror, you want to use that. That improves everyones latency and probably makes anongit/anonsvn a bit faster, as you should always get the server which is close to you.

We have not heard anyone complaining about this change, so I figure that the best compliment you can get. It also means that we are now able to take out mirrors and add new mirrors within some minutes. In the previous setup it took us 2-3 hours for the nameservers to spread the news. Which sucks if a mirror suddenly has dropped out. This is now solved.

Another option we have is to push load info to the system, the system can then adapt and traffic some more visitors to a server with lesser load. We have not yet implemented that, but it’s nice that we have this option.

We will also explore the possibility to use this system for the ftp-mirrors, so ftp.kde.org will return automatically a mirror close to you. But if that’s going to happen remains to be seen.

Anyhow, you can do a quick test how far away you are from a anongit/anonsvn mirror by executing dig -t txt anonsvn.local-kde.org @ns1.geoscaling.com, this will return the city you are in and the mirror you will be using. Please note that in many cases the city is a bit off, but that does not really matter as we don’t have so much mirrors that it would really make a difference. Enjoy.

This service was kindly donated by GeoScaling. They are providing such a service for free currently. The support was awesome and fast. They even started to chat with me on the site while I was setting up the system, asking if I had any problems. I wish all companies would be like this.

Today is a historical day. The last 5 free blocks of IPv4 blocks were assigned to the regional organisation. Which means the central organisation is now out of IPv4. Why would you care and why should KDE care?

In 6 months to a year we can expect the first users who only have IPv6 who want to contribute to KDE. This is due to the fact that we have contributors from all over the world, it can be expected that we run into someone like that as one of the first. IPv6 only users can not approach IPv4 only servers. That means all our servers need to be dual stack. They need to talk IPv4 and IPv6.

Today I heard people say that users should not care, they should buy new hardware which is IPv6 capable and get an address automatically. Well, forget it. It won’t happen. It is highly unlikely that father and mother will buy a new ADSL modem before there are servers which can only talk IPv6, which means those servers won’t be accessible for them.

The other way around is even more problematic. IPv6-only users can not access any server which only talk IPv4, which will be a lot. I would not like to be in that position. Sure there will be NAT like constructions for it, but those will have their own set of problems.

I tried to buy a IPv6 capable ADSL modem 2 weeks ago. I could not find a suitable one. Hardware vendors should be kicked into action now, now, now.

I’ve connected some KDE servers to IPv6 recently. Most providers and hosters do not provide native IPv6 connections yet. Those should be kicked into action yesterday.

Back in 1999 people were scared about the millennium bug. People had all kind of doom scenario’s what would happen when the year would end and a new millennium would start. That did not happen, this will happen. And you should be scared too, time is ticking.

The current switch to IPv6 is many times more scary than the millennium bug. The thing is, the press conference given today gave a much more positive image than the currently reality is. I admit immediately that the IPv6 technology is proven and works. Most of the applications and operating systems are ready too. But the hardware vendors, which sell things like ADSL-modems are not ready and most hosters and providers are not ready to deliver IPv6 to the consumer.

For KDE, we are in good shape. Pretty much all our main servers are IPv6 capable or even talking it already. Some servers are connected, but the services are not yet connected to it. Just a matter of sitting down and fixing it. We have a good overview of what needs to be done and we can be ready for IPv6-only contributors before they appear.

An important change has just been made to the git infrastructure. We now have brand new, shiny, get-it-while-it-is-hot, bling-bling hooks. You might think, wtf are hooks? Let me explain about them. On each push to the git repository each commit will be checked for sanity. For example we check that the name and e-mail of the committer is somewhat sane, if a committer has forgotten to set a proper name and e-mail the commit / push will fail. This is exactly the job of a hook.

We have several hooks. There is one that checks the end of line signs, one that checks for invalid licenses, but also the ones that deal with keywords, like the one for closing bugs, or CC’ing someone. That brings us to another set of hooks, the ones that sent out mails to CIA.vc and the commit mailinglist.

In the past months we have worked with the hooks written in the past for gitorious, if I’m correct. In the meanwhile we have detected multiple problems, which began to build up in the last few months. For example keeping the whole diff in memory for all the processing is convenient, and also very possible in projects like Amarok and Konversation, but now kdepim is also using it, we reached the memory limit quite often, which broke stuff. We have solved that now, and used a quite intensive set of kdepim commits from the past to make sure the new hooks were up to the task.

We also tried to match the existing mail layout as we use it for svn. The git repo mails where a bit messy, and that’s been cleaned up now. We have added new headers, like X-Commit-Ref, X-Commit-Project and X-Commit-Folders, so that makes it possible for commitfilter to be able to support kde repos natively. Especially the lack of X-Commit-Folders broke many people’s filters.

The keywords syntax has been improved, some of the syntax that was supported for svn commits did not work for git, we hope to have corrected them, so they work now. And we moved from bash+ruby+perl tangled mess to pure python, which makes it way better maintainable for everyone.

I’m writing ‘we’, but as usual, I did not do much. All credits go to Ben Cooksley, so all comments should go to his first blog. He is one of the people that works pretty silently, but does amazing work. If I could propose someone for an Akademy Award, I would definitively put him on the short list. Luca Beltrame (or we rather know him as einar77) also helped, so give him a beer if you see him and sent the bill to me. Hmm. I might take that back.

Anyhow, enjoy the new hooks, and if you spot regressions, feel free to contact us.

After two months of beta testing, I’ve released version 0.11. There now is a suspend button in the popup you see just before it is time to break. This way you can finish that all important mail before you go to kitchen to fetch some koffee. Also an endless loop has been found and fixed, this took quite a bit of time to find and resolve. I hopy you enjoy this new version. A lot has changed since 0.10, and I hope it now is a mature and solid piece of software which can benefit a lot of people.

Download is available on the RSBreak site.

What is RSIBreak
Repetitive Strain Injury (RSI) is an illness which can occur as a result of continuous work with a mouse and keyboard. The risk of suffering injury increases the longer users work without breaks. RSIBreak simply offers reminders to take a break now and then.

After the start it will show up in your system tray and will monitor your activity. Whenever it detects that you have been active for a certain amount of time (configurable) it will prompt you for a break. It has some settings so if you walk away from your keyboard, it can reset the timers, so you will not be bothered with a break right after you return from that coffee break.

You can setup RSIBreak to popup a tiny notification popup to remind you to take a break, but you can also configure it to black out your screen so you can not continue working. All to your liking. As full screen work prevention methods, there is the possibility to gray out the screen, show a slideshow with your images or show the plasma dashboard (read only).

RSIBreak also provides statistics about the amount of time you actively worked, the amount of time you were idle, how many breaks you skipped, etc, etc.

RSIBreak is an open source application with a GPL license and is free software – both in money and in code. At this moment this application is only for Linux/X11 systems.