Linux and its Collaboration Explained (Video)

I can recommend this video giving a quick intro to what Linux is and does today as well as how it's built, though there's probably not much new in there for regular readers.

Optimizing Code for Small Size

Many people know the -Os flag of gcc to reduce the code size. Now a while ago Benno posted some tipps to reduce the size of a compiled program for ARM, which give a good hint what to look for in any case. His Summary

"Compile to Thumb instructions.
Use -Os to optimise for space.
Look for unnecessary code.
Look for examples of registers used in the wrong place."

Using a Linux Driver for a Device that is not yet supported without recompiling

If you have  a new shiny webcam or some other device you want to use in Linux, here is a quick short guide how you can have it runnig within minutes with a bit of luck.

Kindle 3 Discovery Tour: Kernel Config, Processes, Programs, Modules, /proc, cpuinfo, dmesg, meminfo, mounts, fstab and other Inside Information (Firmware 3.1)

There doesn't seem to be a copy of the Kindle 3.1 kernel config file on the internet yet. So I will put it online here. Also I will list a few interesting directories, like proc. This is just for documentation purposes and so people don't have to hack into the kindle to find out that e.g. though it has powertop, the kernel's support (timer_stats in /proc) is disables and so it's of no use. Check below for tons of information from the kindle root shell environment.

Minimal Powertop as Bash Script esp. for Embedded Environments

I wrote this for my kindle and android devices. It's a nice, easy script though and should be great especially for embedded environments, where you have a shell but not all of the powertop dependencies. It works wonderfully on my notebook and netbook, but you may have to slightly adjust the path names to work on your system.

It turns out that this wasn't needed for either, as the kindle comes with powertop preinstalled. But it can't work on either of my devices, as timer_stats are disabled in their kernels.
I do wonder: Why do they disable the timer_stats? Is the overhead of timer_stats too high? Let me know how you use it!

Rzip - A new compression star is born

Remember when Bzip first came out and out-compressed Gzip\? Well, then came LZMA with another significant increase in compression ration a bit later. And then one of the authors of Samba, Andrew Tridgell, developed a new compression algorithm called Rzip. It compresses even more efficient, though it needs large amounts (may be 1 GB) of memory to do so. And now Con Kolivas, author of the great Desktop Latency patches including the BFS scheduler and the man who designed the current kernel scheduler (though another implementation of his design was used), took it to himself to further develop the rzip algorithm. And the results are quite promising: The linux kernel is compressed about 3 times as fast as with LZMA2 with just 2 percent difference in final size. I look forward to this going downstream into end-user desktop software.

Update: Con just commented with a link to more detailed and accurate lrzip statistics.

Is the Linux Desktop getting slower and more bloated?

In his "failure of logic" post "K. Mandla" writes that the Linux Desktop is not getting faster even though all the hardware around it is getting faster, pointing to an article with the same argument 10 years ago. The ensueing discussion was much too abstract for my taste. ("Why are clouds?" "What clouds, where?") But if you split up the question you get answers:

0.4 Watt Less During Audio Playback - (Updated:) Power Performance: Pulseaudio + Interrupt-Less Alsa

(Skip to the update)
Ok, so with some help from Pierre-Louis from Intel I've managed to get it working and do some performance/power tests. But let me start at the beginning: Recently, pulseaudio not only switched to a more power efficient (and otherwise) timing system, as far as I understand a callback API. It also provided the infrastructure to use ALSA devices without causing any interrupts ("period wakeup disabling"), so you CPU can stay longer in standby mode (e.g. "C6 residency"), saving you power and avoiding playback glitches at the same time. See here and here or more background information. With kernel 2.6.38 the first driver (snd-hda-intel) supports this infrastructure out of the box, the snd-hda-intel driver. This combination is what I tested for power efficiency...

The Linux Kernel Trojan Horse Gift

Linus describes how he prefers new features to be introduced to Linux:

In other words, every new crazy feature should be hidden in a nice solid "Trojan Horse" gift: something that looks _obviously_ good at first sight.

The fact that it may contain the germs for future features should be hidden so well that not only is it not used as an argument ("Hey, look at all those soldiers in that horse, imagine what you could do with them"), it should also not be obvious from the source code ("Look at all those hooks I sprinkled around, which aren't actually used by anything, but just imagine what you could do with them").
Linus

Why it's a problem that Ubuntu spinned off of Debian

Check out this great article.

Debugging Alsa HDA Audio

If you're using the snd-hda-intel module and you've got audio problems, you might want to try out manually using a specific model, the list is in e.g. patch_realtek.c:

11687 static const char *alc268_models[ALC268_MODEL_LAST] = {

11688 [ALC267_QUANTA_IL1] = "quanta-il1",

11689 [ALC268_3ST] = "3stack",

11690 [ALC268_TOSHIBA] = "toshiba",

11691 [ALC268_ACER] = "acer",

11692 [ALC268_ACER_DMIC] = "acer-dmic",

11693 [ALC268_ACER_ASPIRE_ONE] = "acer-aspire",

11694 [ALC268_DELL] = "dell",

11695 [ALC268_ZEPTO] = "zepto",

11696 #ifdef CONFIG_SND_DEBUG

11697 [ALC268_TEST] = "test",

11698 #endif

11699 [ALC268_AUTO] = "auto",

e.g.
sudo modprobe -r snd-hda-intel; sudo modprobe snd-hda-intel model=test

See here for more.

Testing the Development Kernel in Ubuntu

Testing the bleeding edge development kernel from Linus' git tree has never been easier. You can now download precompiled debian packages for the current release candidates from the Ubuntu kernel ppa.

What's New in Linux v. 2.6.28

Heise's got a nice article about what's new, what's hot, what's not in the not yet quite released 2.6.28.

Apple's Lock-In Syndrome

Apple is locking iPhone users into their rigid software framework through the App Store: They would not let people develop interfaces to Gmail and now they prevent the great Opera Mini from being ported to the iPhone.

Adobe Flash has also been ported, but is kept away from the iPhone by Apple.

So if you've wanted to buy an iPhone, reconsider. It's buggy and Apple won't let you install any software that might "duplicate" available functions. They should be honest and say software that competes with theirs.

Source: Heise Article [german original]

Rude Linus Torvals

If you ever wondered why people say the kernel developers are sometimes very rude, check out this article, referring to a post by Linus himself.

Automated Linux Kernel Testing

I'm currently always using the current git kernel. And my thought is: Why isn't there some tool available to automatically tell the developers how many users are currently runnig the kernel, on what platform, how many segfaults, crashes, etc. the test systems had. That would make it much easier to know bugs are there... And it could all run automatically in the background, or at least semi-automatically.

Arjan van de Ven Interview

As I mentioned in my last post, O'Reilly interviewed him and it's a quite interesting read. I only disagree on one point. He says "I think there are always going to be keyboards." (...) "it's also the fastest way to get more than a few characters into the computer."

I think that will change. At some point voice detection has to come around and get better than the keyboard and we will finally start talking again - as nature wants us to - instead of quietly sitting in front of our computer.

And at some point there will be developments to directly transfer sentences from your brain to the computer without the need to talk - though I'm not sure if that's really an improvement, language is just too cool an invention imo.

Well, for now I really look forward to improvements in booting time and on latency issues. That's another point were Windows has a really hard time to compete. The drivers' and applications' code is mostly proprietary and hidden somewhere behind closed doors and servers.

It's simply a great technical advantage to be immediately able to look at all the code, see how it works and find out where's the best point to fix a certain problem. And then being able to fix the actual root cause of the problem. That's one of the neatest things about open source.

Chrome Developer's Channel

There's now a Chrome Developer's Channel available with automatically installed bleeding-edge versions of Chrome.

The Great Sysctl Mystery

Most advanced Linux users with know the sysctl interface for fine-tuning the Linux kernel. But there is probably noone on earth who really understands all those parameters. Well no wonder, as they're usually not even documented.

So I just thought to myself:
It would be great to have a program which has all the values and explanations to them. It could then create configuration files and let sysctl parse them. "Linux Kernel Tuning" would be a cool name. If I had more time... ;-)

Git Bisecting the Linux Kernel to Find Bugs

You can help the Linux developers by testing out the current bleeding edge version of Linux by downloading the current version from git:
git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git

And then you can compile the kernel normally. To fetch the newest updates you enter the directory (linux-2.6) and enter git pull.

Then if you find a bug that wasn't there before you can find out which patch caused it with a git bisect search. It's relatively quick through a binary search algorithm, it only needs around 14 compiles and boots for about 4000 patches, and the complexity is logarithmic I believe (so it's always relatively quick, even with a lot to test).

Also see this quick intro and the man page.

Compiling really takes most of the time. You can decrease that time by creating a minimal kernel configuration (it's worth it!) with only the features activated that are needed to trigger the bug.

I recommend compiling everything directly into the kernel, you can then just do "make bzImage" instead of make and save the time for making and installing the modules (over and over again).