If you think iproute2 is new, you’re mistaken. It was actually released over 10 years ago, I just happened to not notice that until now. Maybe it’s time to move to BSD like all the other old people and leave Linux to the kids.

Most of the stuff was interesting, but not applicable to what most people will have to work with, unless you try to work with a massive dataset… like… let’s say building an index of everything on the web.

One of the most interesting parts for me was the following paragraph:

Our experience with thread-per-request was, on the whole, positive: application code is simple, we achieve good utilization on many-core machines, and crash debugging is simplified by meaningful and complete stack traces. We encountered fewer race conditions in application code than we feared. The biggest drawbacks of the approach were scalability issues in the Linux kernel and Google infrastructure related to high thread counts. Our in-house kernel development team was able to deploy fixes to address
the kernel issues.

This will probably take a few months to really become useful, after it’s included in various distributions, but it’s a huge step for Broadcom wireless chipset support on Linux.

The Debian project has decided to adopt a new policy of time-based development freezes for future releases, on a two-year cycle. Freezes will from now on happen in the December of every odd year, which means that releases will from now on happen sometime in the first half of every even year.

I didn’t see that coming.

“The Linux device drivers we are releasing are designed so Linux can run in enlightened mode, giving it the same optimized synthetic devices as a Windows virtual machine running on top of Hyper-V. Without this driver code, Linux can run on top of Windows, but without the same high performance levels. We worked very closely with the Hyper-V team at Microsoft to make that happen.”

As of late I think someone in Redmond is trying to drive RMS crazy and it looks like they’re doing a good job ;-)

Seriously though, this is good because it is in Microsoft’s best interest – which should mean that the drivers actually work well in real-world applications – and it makes it easy for Microsoft’s clients to run Linux applications on Windows without having to port everything to Windows.

Update 7/21: Please also refer to Greg Kroah-Hartmann’s blog post and the lkml post.

1) As a payments company do you really want to “follow the Linux kernel development process” just to process a few transactions per second? Is it really a prerequisite to have people that know the kernel? A moment ago we were still talking about a payment system, not a device driver.

2) Does it sound sensible to run thousands of servers and maintain the staff and software to actually do it? – I have to say that I always found it interesting to see how much workload large systems can process and how few people you need to do it.