Zack's Kernel News

Git Survey Results

Jakub Narebski recently announced the results of the 2009 survey of Git users. The graphical results are available at Among almost 4,000 participants, most found Git easy to learn and use. The biggest block of users used Git for managing code, and some used it for backup and configuration files. The vast majority relied on a binary package of Git, rather than compiling the source themselves. As one might expect, the majority of users used Git under Linux, but a lot also used it under Mac OS X, and a surprising 22% of users also used it under Microsoft Windows. Virtually everyone relied on the command-line interface, as opposed to front ends like gitk, and most users either hosted their Git repository themselves or used Github.

The most commonly used Git commands are git add and git push. Not much surprise there. A full 94% of Git users are happy with the tool; although that might not be saying much in that, if they weren't happy, they might not be using it enough to answer a survey about it. In terms of what were the most desired new features, users were fairly evenly split between a better user interface, better documentation, and better auxiliary tools.

The full analysis is fun to look at and has more information than the quick digest I'm posting here. I can't help but wonder whether statistician Nate Silver would have any special comments to make. To me, these results seem to say that Git has definitely entered mainstream use, as opposed to being just a developer's tool.

The 22% of users that use Git under Windows is surprising, partly because my understanding is that Git's tremendous speed advantage doesn't translate well under Windows. If anyone's actually done a comparison and wants to share a graph or two, please send them to me and I'll publish them here under your name next time.

The 94% approval rating might go down over time as more users are forced to adopt Git in a work environment, when they'd rather stick with more familiar tools. Git, after all, still lacks some sophisticated features that other revision control systems have. One of Git's main claims to fame is speed, and some users might find that to be less important than some of the fancier bells and whistles that haven't yet been implemented.

Scheduler Controversies

Con Kolivas has been working on his own BFS (Brain F * Scheduler) as an alternative to the existing kernel process scheduler, and recently, there was a fight about it. The situation is interesting because the existing scheduler, while trying to ensure good performance for smaller machines, also supports systems that have thousands of CPUs. To support such large systems, it apparently makes sacrifices with regard to latency on smaller desktop-oriented computers. For example, video playback might freeze for a fraction of a second; a game of quake might act a little jittery.

Clearly, Ingo Molnár, the maintainer of the in-kernel scheduler, wants to have good performance on smaller systems too, but it's a tough needle to thread, especially because Linus Torvalds doesn't want to have multiple schedulers in the kernel that target systems of different sizes.

Con's work on BFS, therefore, was not an effort to write a scheduler that might be incorporated into the official source tree. Because he didn't like the latency issues he saw on smaller systems and didn't like the complexity of the in-kernel scheduler, he decided to write BFS as a manifestation of everything he had come to believe about schedulers over the years. So the discussion on the linux-kernel mailing list was a little unusual in that it concerned a piece of code that was not being submitted and whose author had no plans to try to get included.

Still, various folks, starting with Ingo, ran comparisons between BFS and the in-line scheduler. He ran his tests on hardware that Con had said would be at the upper bound of where BFS would still work well – a dual quad-core system, with hyperthreading. The tests confirmed that BFS didn't work better than the in-kernel scheduler on a system that size.

A bunch of other folks ran benchmarks and did other sorts of testing. Nikos Chantziaras found that when using BFS on his Intel Core 2 Duo E6600, MPlayer no longer dropped frames when he dragged the window around on the desktop and the LMMS sound synthesizer no longer crackled and popped during playback. Additionally, Doom 3 and similar games no longer froze for fractions of a second during play. These things were difficult to test numerically, but he did clearly notice the improvement under BFS.

Con himself had no interest in the debate. He replied only once during the discussion to say that he didn't like benchmarks that relied too heavily on abstract ideas and not enough on real-world usage; essentially, he wanted the folks on the mailing list to drop the whole thing and let him code in peace.

Undoubtedly people will continue to pay attention to the progress of BFS, but Con is right that, for a significant number of reasons, the code might never be an official part of Linux. Con's disdain to support systems with thousands of processors and Linus' reluctance to include multiple schedulers in the kernel relegates BFS to the very geekiest members of the Linux user community, at least for now.

Visualizing Kernel Sources

Taro Okumichi has written a tool that converts kernel source code into HTML and lets users easily expand and view macros and include statements and examine structs. He used a lot of AJAX-y features to make the whole thing easy to use. Florian Mickler was super-impressed with this and encouraged Taro to share his code. Américo Wang was also really impressed, and Bill Davidsen was interested in seeing more features.

Taro posted a link to his tool, at, but at the time of this writing, it led to a dead page. Taro hasn't posted any other information yet, but this seems like a pretty cool tool. Hopefully he'll keep working on it and share it with folks again.

Buy Linux Magazine

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

comments powered by Disqus