There's a good proposal going through the rounds on the FreeDesktop.org mailing list which seeks to help the kernel decide which process(es) to kill first in the event of memory pressure. The proposal is simply adding a TerminateSafe=true key to the .desktop files of applications which are stateless or which constantly save user data. Examples of stateless applications might be the character map and calculator tool. Applications which save continuously might include Tomboy. Terminals, office suites, and IDEs would not have this key set to "true."
The Linux kernel's OOM (out of memory) Killer has a method to determine which processes get killed first in a critical situation: it's called "magic." No, not really. It is complicated, though, and it offers a "user-friendly" way to help the kernel make its decision. oom_score is located in /proc/ under the number of each running process. The oom_score for each process is based on factors such as memory use and running time. The process directory also contains oom_adj, which, as the name suggests, allows one to adjust the score of the process. Think of it like nice, but for killing, not running.
If TerminateSafe=true were implemented on Linux, it would likely signal the desktop environment to adjust oom_score to put the application on the top op the assassination list using oom_adj. Other OSes might use a different method or not support the key at all.
The problem with this approach is that the process the .desktop file spawns may not even be the main process if the file calls a script. The situation is made worse by processes that fork. Luckily, the kernel offers process groups to handle this situation, something Systemd is planning to use.
I hope you've heard of Systemd, the init/upstart replacement with a model half way between launchd and inetd. If you haven't you should take a look at it.
A little over a year ago, Google contributed the Android kernel modifications to the Linux kernel maintainers. As of Tuesday, the driver contributions have been deleted. Why? Google used a specially modified kernel API for Android, which is incompatible with the mainline kernel, and attempts to come to an agreement over how to modify and maintain the new code failed.
Google now has two forks of the Linux kernel to maintain. You see, Google started forking and maintaining Linux for its own servers several years ago, and is now having trouble updating and backporting its forked version. Google has come to realize the problem, and is working to move from a proprietary version control system to the Git DVCS which the mainline kernel uses. Google is also trying to clean up the code a little in order to have as much of the code as possible accepted upstream so that the employees have less work to do. This is what the Linux kernel maintainers recommend to everyone.
While Google tries to fix the problem with one hand, though, the company is going down the same road with Android. Because Google can't come to grips with merging the code, the developers will have to maintain that code themselves, leading to a less secure and robust product. Good luck to them.
Google probably just needs to abstract out the parts that change the main kernel's functions and bolt those changes on top.
Just in case you're ever tempted to say something stupid like "Ubuntu is unkackable," watch this video, then re-think the statement.
The video shows a local root exploit in the Linux 2.6.30 kernel. Karmic will ship with 2.6.31 so this exact exploit isn't likely to still work. Oh, and even though the vulnerability is local, remember that remote user exploit plus local root exploit equals remote root access. ;)
Tridge again steps up his game and gives Linux a great way forward, this time in the FAT patent situation. Let's look at a little background about that situation before we find out how Tridge soved the dilemma, shall we?
FAT (or FAT16) is an ancient system originally used on DOS and only supported eleven-character filenames (commonly called the 8.3 format). Windows used a backwards-compatible variant of FAT, called VFAT or FAT32 which supported longer filenames while still having the shorter names. Long filenames were written as is and shortened to 8.3 for the legacy system. This is origin of the "C:\Progra~1" jibe common in *nix circles ten years ago when referring to "C:\Program Files." Microsoft filed patents for the process of having both long and short names on FAT partitions, and those patents were granted (patents #5,579,517 and #5,758,352 in the U.S.) in 1996 and 1998, respectively.
In 2008, Microsoft decided to start suing businesses over infringement of these patents, and they started with TomTom, a manufacturer of in-car navigation devices (shown above) that are Linux-based. The message to everyone was clear: "Linux infringes our patents. Don't use it in your embedded devices." Despite community attempts to find prior art and nullify the patent, which are still being carried on by the Open Invention Network, TomTom was forced to settle the suit and remove FAT functionality from its hardware. The Linux community was rocked and considered pulling FAT from the kernel completely, virtually killing it's ability to read thumb drives and otehr removable media.
Wait! What's that on the horizon? Is it a bird? Is it a plane? No, it's Tridge in his super-suit here to save humanity ....
How did he solve this riddle and allow Linux to keep FAT? The key was in the patents. They cover methods to have both short and long filenames. Tridge proposed a patch which would write the short filename if under eight characters, and write only the long name if it was over eight. Since Windows will crash without the short name, the method writes invalid characters to the short filename space, not creating a valid short filename, and also not crashing Windows.
All hail Tridge! ;)
On an aside, this is my 256th (2^8) post, meaning that I have averaged over one post every three days for the two-plus years I've had this blog. Cheers. I hope to be around for another byte's worth of posts.
Image via Wikipedia![Reblog this post [with Zemanta]](https://lh3.googleusercontent.com/blogger_img_proxy/AEn0k_s1MPh_elBlT8ugNBprW00ah9djaehWwkuWj0dKhPHuZaYRLzI6TiKLWlVIGYPZXaz77JiL7ARGz7QEiJpOTvk-iZ5SvdukOGOptvNmYUj3PI873WzNnFZnDskRAzW-dWY0KygEadP1hH6Upf4zJXY=s0-d)
![Reblog this post [with Zemanta]](https://lh3.googleusercontent.com/blogger_img_proxy/AEn0k_tkQP1RGbs_zbqcI7bAiDdfeHinwiylz-_NzBJcMv3huPhfN2COCFpJi7ZaaP0kpFzN-yS4Cl3ZjGXuKrb8p8eTrrwRM6m3dC99z5aBqoTwTWv8HPgXTZeT06dNwknD4uONnWopUDIk6RddjDNlgVM=s0-d)
![Reblog this post [with Zemanta]](https://lh3.googleusercontent.com/blogger_img_proxy/AEn0k_vk7uGjUKzgZBzah9bJwLDuBQsHZ86EuUmgpLWfjmkJhUJN2c_eNQc5YyH9NJJg2RjhELiN4DPgqTBkzIvHsI-aWUogKO6bIus6BOb_cr3bjlEK9eXBbuT4PNv8e9sHQC8I4onvXtmK55tiQYSedZbQ=s0-d)
