Slashdot videos: Now with more Slashdot!

View

Discuss

Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

LinuxWatch writes "'It's been long promised, but there it is now,' began Linux creator Linus Torvalds, announcing the 2.6.25 Linux kernel. He continued, 'special thanks to Ingo who found and fixed a nasty-looking regression that turned out to not be a regression at all, but an old bug that just had not been triggering as reliably before. That said, that was just the last particular regression fix I was holding things up for, and it's not like there weren't a lot of other fixes too, they just didn't end up being the final things that triggered my particular worries.' There were numerous changes in this revision of the OS. The origins of some of those fixes is detailed in Heise's brief history of this kernel update."

That's not really a Linux thing - look at Debian, you've got two kernels there and effectively the same userspace. Now, if you say you want everyone to stop using X, you'd probably need to implement some sort of direct rendering on the next level up, which is going to be your toolkit stuff (GDK/Cairo/GTK+ or the QT equiv, for most apps) You have now just bisected your GUI application compatibility.I'm not sure that X11 is so lacking anymore - the recent versions have been making some nice improvements, an

My history with Linux has the problem not being with the Linux Kernel but with the X Windows System (Xwindows is big and clunky to support features that we don't fully utilize and are fully utilizeing them less and less). I think Linux needs to seporate from its Unix haritage and start moving away from X11 and to something a bit more direct with the frame buffer and video card (Much like how OS X has). Granted X11 has improved in the areas of 3d acceleration and such. But compared to OS X it is lacking

And that has precisely what to do with the kernel? X is in user space. If you want to replace X with any other windowing system you like, just port it or write it. And when you've written something as powerful and stable as the X Window System, come back and tell us about it.

I'm no proponent of the GP, but there *is* a 'third way', if you will - expand the X-library so that a) local connections don't necessarily use a protocol over a pipe, but make function-calls instead, and b) implement widgets in the X-client library much more detailed than the current window- and image-primitives; say a basic set of menu-bar, scrollbar, list, tabs etc. All pluggable in the X-server, of course, so that everybody can still 'skin' their desktop according to their taste. c) Do away - finally - with the silly ways that cut-n-paste and drag-n-drop, in short, IPC and buffers, have been implemented in X. Invent a serious way to communicate between X clients, not a tag-along.

expand the X-library so that a) local connections don't necessarily use a protocol over a pipe, but make function-calls instead

What you are asking for would add substantial complexity to the codebase. Right now things are simple because X messages are just that, messages; it doesn't matter if they're carried over TCP/IP or a Unix Domain Socket. That's a feature. As computers get more powerful, message passing becomes more commonplace for convenience's sake. There ARE other GUIs available for Unix, especially on Linux where there's a kernel gui package. Perhaps one of those solutions would better be suited to your needs?

implement widgets in the X-client library much more detailed than the current window- and image-primitives; say a basic set of menu-bar, scrollbar, list, tabs etc. All pluggable in the X-server, of course

I will say I agree with you on the message passing situation, it doesn't seem to be a significant penalty (I can still get Windows or better frames per second in 3d games, for example).

We have that already. It's called GTK+ or Qt or WxWidgets. Why should they be directly in X?

While I in part agree with your sentiment, I will say that richer X primitives would mean better default remote performance. Instead of 'here are *all* of the x primitives required to draw a GTK button with the word Cancel on it', which is a not insignificant number, it could say 'draw Cancel button' and cut down on network

I said: expand the current functionality with something that simply *must* have better performance. Think laying out functioncalls in shared memory and calling interrupts for local clients. Think transporting events back to the client in the same way. Think painting directly in the frame buffer using shared memory.Also, I realize that there are a load of APIs on top of the X client library that paint beautiful (and sometimes less beautiful) widgets, but a) they can't be fast because they wrap both the wa

I said: expand the current functionality with something that simply *must* have better performance. Think laying out functioncalls in shared memory and calling interrupts for local clients. Think transporting events back to the client in the same way. Think painting directly in the frame buffer using shared memory.

Firstly, as I've said in a different post [slashdot.org], you can rip X network transparency from bleeding dead hands. Secondly, this already exists, and is a job for extensions: c.f. MIT-SHM [wikipedia.org].

Also, I realize that there are a load of APIs on top of the X client library that paint beautiful (and sometimes less beautiful) widgets, but a) they can't be fast because they wrap both the way in (XCreateWindow) and the way out (XGetEvent), and b) it would be a lot nicer if the X server actually understood what you *meant* when you said: 'make a scrollbar'. It can implement a faultless scrollbar namely. And generate scrollbar specific events.

You do realise that such a widget set would have to be implemented using... wait for it... exactly the event and graphics primitives you're so keen to get rid of! Um, sorry, but your idea fails the common sense test, in that it would provide exactly nothing that the existing libraries you're slating don't already. In fact, the

I said: expand the current functionality with something that simply *must* have better performance. Think laying out functioncalls in shared memory and calling interrupts for local clients. Think transporting events back to the client in the same way. Think painting directly in the frame buffer using shared memory.

Actually ipc is the fastest way if designed right. You are ignoring the fact that it can easily send MORE than one message in a single context switch, by buffering them. Windows only got modern speeds by changing as many of the calls as possible to ones that write messages in a buffer, only sending that buffer when a return value or sync is needed. So in some ways the design of X is already the correct one for maximum performance. Pipelines are how graphics hardware runs so fast, you know.

Also, I realize that there are a load of APIs on top of the X client library that paint beautiful (and sometimes less beautiful) widgets, but a) they can't be fast because they wrap both the way in (XCreateWindow) and the way out (XGetEvent), and b) it would be a lot nicer if the X server actually understood what you *meant* when you said: 'make a scrollbar'. It can implement a faultless scrollbar namely. And generate scrollbar specific events.

The X server and your application are running in different processes, so communication between them can't be done with function calls. But for clients running locally, pipes haven't been used in a long time -- Xorg uses shared memory for transferring messages efficiently between the client and the server.

The "basic set of menu-bar, scrollbar, list, tabs etc." are provided by toolkits such as GTK and Qt, which are used by most modern applications. These work fine already; building a toolkit into the X se

We don't need remote X Windows applications as much as we did before.New applications are designed Web Based so anyone can use them depending on their OS and default configurations and setting.

Most people who use XWindows don't use it over TCP/IP anymore. (Yes I will probable get comments from a bunch of Slashdot users say Yea I Do it is great...) But for normal use it is between the Computer and the Monitor.

We have better and more effecent ways of comunicating the data then Xwindows ofers.

Well, you go run some benchmarks and prove that there's a big win to be had by moving to a non-IPC based model of communication. A significant rewrite like that requires some serious numbers to back it up, and so far, all you've provided is anecdotes and gutfeel, and my friend, that ain't enough.

Benchmarks may not help as well. Gut feel is sometimes the best we get. I have found linux to be sparatic. with Xwindows. Tiny Delay Blast Tiny Delay Blast. On Average it may be on par but there is something off on its performance that doesn't vibe with me, that other systems such as OS X and Windows doesn't give me.

Oh, for pity's sake. Throw all your engineering discipline out of the window (ha!) and fall back on gut feel. and superstition. The fact is that Linux (with X Windows) performs much better on the same hardware than either Windows or MacOS. Why is this? Until you've shown that X Windows is a significant cost, then you really don't have any argument beyond hand-waving.

I have this to add: I personally have been using the X Window system for eighteen years. I've used it on hardware which had an 8MHz - MHz, not GHz - processor. I've used it on hardware that had 8Mb - Mb, not Gb - of RAM. The X Window system performs perfectly well on that hardware spec. It's always outperformed every other windowing system on the same hardware, and it still does now.

Basic engineering tenet, known to all old engineers (but obviously not taught to young ones): if it ain't broke, don't fix it.

Benchmarks may not help as well. Gut feel is sometimes the best we get.

That has to be the most absurd thing I've read in a long time. Either you're not a software developer, or you're an incredibly bad one. Either way, it's clear your opinions regarding X can probably be safely ignored.

The problem is NOT with the IPC. So "gut instinct" might make you know there is a problem, but also leads to wrong conclusions.There are imho two problems with how X works:

First there is the ICCCM window manager design. This makes it absolutely impossible to have clean updates and resizes of windows because two asyncrhonous processes are updating different parts of the window. Programs that bypass the window manager, such as media players that do it to make windows without borders, work obviously faster and

You miss the point compleatly. I say Hech check it out there may be a problem, and your ways of testing currently may not find it. I am not saying we need to do anything or that it is fundementaly broke. Me, I don't care if X11 works or not. I am not a primary Linux User. I havent been so sence 2002, After being a Linux Zealot from 1994-2001. But Linux is missing the "Snappy Effect" somewhere and if X11 Crashes it seems to effect the entire system. X11 has always seemed like a hack to get graphics running,

Why is it that Macs came from the ashes and haves close to 10% marketshare, while Linux install base (is between 0.5% - 3%) and you need to pay for Macs, and for OS upgrades, get stuck on priority OS and Hardware. The Linux comunity really step on its foot durring the Late 90's and early 2000's It really could have been a huge player on the desktop area, but the comunity is so Anti-Corproate and so resistant to change that it left them off as a distant 3rd place.

Why should we care whether you use Linux or not? Hint: Steve Jobs makes a lot of money if MacOS becomes popular. He's in it for the money and he's making lots of it. Good for him! Linus Torvalds makes a reasonable salary if Linux becomes popular, but he's a talented guy and he'd make a reasonable salary anyway. He's not in it for the money, he's in it for the fun.

When you buy a Mac, Steve Jobs gets more money. When you use Linux, Linus doesn't have more fun (if anything, with all your moaning and whingi

Most people who use XWindows don't use it over TCP/IP anymore. (Yes I will probable get comments from a bunch of Slashdot users say Yea I Do it is great...) But for normal use it is between the Computer and the Monitor.

I certainly use it all the time. I'm at university, and the ability to pull up Emacs running on my box in my room from any of the Linux workstations around the university (or in my friends' rooms) is really useful.

Here's an example of how it saved my arse once. I'd been writing a report using LyX, and was at my department to hand it in. Just as I was about to, I noticed that the caption of one of the figures was totally wrong. I logged onto one of the department's workstations, fired up SSH, launche

I definitely agree. I use FreeNX to do more or less the same thing at school, and it's just damn handy.

Although that is a totally different mechanism, and a slightly different use case. Note that the big advantage of remote X is that the applications you launch are fully fledged window session clients in their own right:

Each application appears in its own window on the desktop on the local machine, and can be managed using the local machine's taskbar.

Applications running on the remote system can put icons in the local machine's system tray.

Also, what evidence do you have that network transparency is any kind of a bottleneck. As I understand it, local communication with the X server takes place over Unix sockets instead of TCP sockets. Unix sockets are much faster, and are caching friendly, so there's no real speed penalty over something like shared memory.

Most people who use XWindows don't use it over TCP/IP anymore. (Yes I will probable get comments from a bunch of Slashdot users say Yea I Do it is great...) But for normal use it is between the Computer and the Monitor.

One of the best things I ever did was go to work in a corporation. A few years ago I was fairly typical for what I suppose could be called a nix-geek. Whilst I still use things like RTFM all the time, more and more I'm finding, childishness I suppose is the word I'm looking for, in the Linux community. Everyone wonders why the system doesn't make it to the desktop and I could think of a few reasons. Probably the best one for this discussion is what parent just said, nobody cares that XWindows runs over TCP

Various ways: currently, the use of a pipe makes the protocol very safe; there's just one way to 'enter' the X-server, and that way can be monitored byte for byte. You could imagine a more cooperative (but less 'safe') model for local clients; one that uses nothing but shared memory, messages, signals and semaphores to do its job; you could make a model a la kernel syscalls; fill up a piece of memory and call an interrupt. Or even a special build model which delivers a '.so' which is linked into the X ser

And that has precisely what to do with the kernel? X is in user space. If you want to replace X with any other windowing system you like, just port it or write it. And when you've written something as powerful and stable as the X Window System, come back and tell us about it.

Userspace and kernelspace are developer-speak, not something the average user really has to know. Users divide the world in to the operating system and applications, and since X isn't an application it's part of "the system" and goes into one big pile. Paricularly since the line has become very blurred, not only is X in userspace, but drivers are in userspace (all high-level USB drivers, for example) or filesystems (FUSE) and so on. It's fairly valid to point out that often problems with "Linux the system" isn't a problem with "Linux the kernel" but rather everything around. For example, USB support in the kernel is done but there's plenty work left on USB device support...

You have just articulated the major perceptual obstacle to Linux developers' ability to grasp the desktop. They refuse to draw a neat line between "system" and "applications" and then promote and support that set of interfaces, so there is no consistent platform that facilitates independent distribution of applications to end-users.

You have just articulated the major perceptual obstacle to Linux developers' ability to grasp the desktop. They refuse to draw a neat line between "system" and "applications" and then promote and support that set of interfaces, so there is no consistent platform that facilitates independent distribution of applications to end-users.

You have just articulated the major perceptual obstacle between you and the kernel developers. The kernel developers aren't doing it to scratch your itches - you don't pay them. They're doing it to scratch their own itches, or else to scratch their employers' itches. If you want an operating system with 'a neat line between "system" and "applications"', go away and write one (or pay someone else to write one). Come back and tell us about it when you're done.

Actually you're wrong about doing work. There is tons of activity around KDE, Gnome and their associated applications.A major problem is that the desktop environment's relationship to the kernel and vice-versa is so loose that UI expectations are pretty low. Software ultimately exists to control hardware, but our GUI software ends up not being able to control our video cards, sound chips, etc. very well as a result. I never know how my DVD drive is going to be handled, whether my player will be able to find

Userspace and kernelspace are developer-speak, not something the average user really has to know.

On this forum, in a thread about the Linux kernel, what the user sees is besides the point. A perceived problem was pointed out, which lies specifically in the kernelspace/userspace barrier (namely, that some measure of GUI support should be shoehorned into the kernel). This problem is posted by someone technically minded to be discussed and "resolved" by other technically minded people, and user perception of where the problem lies is behind the point (the perception of the problem existing to begin with

The line was blurred by a court case where Microsoft failed to convince the court that Internet Explorer was part of the Operating System. The line has been furthur blurred by clueless post-literate newbies that consider the beige box on their desks a "hard drive" and use technical words in an attempt to sound skilled. The definition in the texbooks didn't change.

Yes. The problem is, your vaunted "MS or Mac" still have a closed development cycle. Those talks still happen, you just don't hear about them, and fewer people get a say. That may mean quicker decisions are made, but that doesn't mean they're the right decisions.

Besides, most of us don't work on Linux to make money with it directly. We work on Linux because it's fun and it enables us to do what we want with a machine, rather than being told where to go today.

And that has precisely what to do with the kernel? X is in user space. If you want to replace X with any other windowing system you like, just port it or write it. And when you've written something as powerful and stable as the X Window System, come back and tell us about it.

Well there is a theory in kernel Design that the Kernel should handle all the Input and Output of the system. Xwindows bypasses a lot of the kernel with its own display drivers and such. As well if Xwindows crashes sometimes it is just as bad if the kernel crashed. Locking all user interfaces (including remote connections (at least this has happened to me on a couple of occasions)).

Actually with X11 DRI, most of the heavy lifting is done in kernel space anyways. X11 basically gives you the advantages true network transparency and performance in one. It's really an excellent and well thought out windowing system, arguably better then OS X Aqua or Windows. Not saying it's perfect, but most idea "inspirations" would actually be regressions.

Unlike previous display protocols, X was specifically designed to be used over network connections rather than on an integral or attached display device. X features network transparency: the machine where an application program (the client application) runs can differ from the user's local machine (the display server).

Pretty much all the alternatives listed are dead or dying, so pot kettle black on the amount of research done.

That's precisely the point. In a competitive environment, X Windows has won out. Why? Because it's extremely hard to write anything as good, and even harder to write anything sufficiently better to persuade any significant number of users to switch.

Install Ubuntu. Works great, 3-D effects on the desktop. Does everything that most people need. The only stupid pet tricks are the ones that you need to do to get DVDs to play. Thanks DMCA for that one. Other than that I find it as user friendly as WindowsXP and it seems a lot faster.BTW I work with at a software company that writes software that runs under Windows. Even the most pro windows drone here has fallen back to "I am sure Microsoft will fix it soon". Don't bother with the it works just fine for

Since Intel, nVidia, and ATI all have good support under Linux just what video card are you using?Card reader? Mine works fine and so does everyone that I have seen. All of the ones I have seen look like a USB mass storage device.WiFi adapter? I have heard that they can be a problem but I have not had any issues. Intel's just work.If they don't contact the manufacture and ask them for the drivers.If they don't offer them then well you picked hardware that doesn't support Linux.Kind of like those people that

Not really.No answer on what video card. Any halfway modern video card will be supported. nVidia, ATI, and Intel all provide good support for Linux as well as Windows.No real answer on what WiFi adapter. Again I have installed Linux a few differn't notebooks and have used a few different PCMCIA WiFi adapters. They all work.So on other words I think that orignal post was full of bull.

AS to who to complain at. Real simple answer. The hardware manufacture. Where are the drivers for Linux? They make and sell th

Linux devs are working their asses off in their parents basements, hacking and testing drivers for hardware that they don't have access to the interface specifications for. If things still look a little shakey, just remember to be glad that they work at all, given the hours of work for $0 return.

When you are done giving thanks, complain to your hardware manufacturer, who does make money from the deal, and does have the full specifications - AND for reasons unknown, have turned down the offer of OSS developers writing the drivers for them, for free [slashdot.org].

If a shopper wants to choose between 3 wifi cards, do the Linux developers bother to tell the shopper quickly and concisely which of those will work??

No. Why should they? Do the shoppers pay them? Do the makers of the wifi cards pay them? Answers: no, and no. The developers are doing it for fun - their fun, not your fun. If no-one else wrote a driver for the card you bought, write it yourself and contribute it back.

If Linus had one hairsbreadth of concern for a users' ability to discern compatibility while contemplating hardware purchases, then his group would have setup an HCL years ago. But instead he leaves that horrid little task of dealing with the unwashed to the distros, who produce pathetic nearly-empty HCL databases with some of the most unpleasant web-search design imaginable.

Why should Linus do anything for you? When did you last do anything for him? You have a really weird idea about how the world works.

I see your point, and don't mean to troll; but I think this is one reason Linux doesn't get as much use as it would. There is no real helpful Linux community. Linux nerds are a bunch of DIY guys, who expect everyone else to be so too. But the novice doesn't have the wherewithall (or knowledge) to hit up man pages, and start digging through arcane forums littered with snippets of code.Of all three of the OSs I use, Linux has the least helpful community. This isn't saying that the Mac and Windows communit

I see your point, and don't mean to troll; but I think this is one reason Linux doesn't get as much use as it would. There is no real helpful Linux community. Linux nerds are a bunch of DIY guys, who expect everyone else to be so too. But the novice doesn't have the wherewithall (or knowledge) to hit up man pages, and start digging through arcane forums littered with snippets of code.

I don't think we're disagreeing very much. The people who make Linux what it is don't need it to become popular, and, in particular, aren't terribly worried about making the system friendly to non-geek users. We are geeks, and we're also elitists. If Linux gets to be a 'user oriented' operating system, then it won't suit us, and we'll probably all decamp - to the Hurd, or something new.

If you want a user friendly operating system, and you don't have the skills to do it yourself, Steve Jobs or Bill Gates

We agree around 50%. I don't think that this is necessarily a good thing, and think that it shows that the community is at cross purposes.To a large degree Linux needs elitist geeks, their what makes it tick. But at the same time we speak of "The Year of the Linux Desktop", which leads me to believe that some subset of these elitist geeks want their pet OS to be adopted by the masses. Being elitist geeks is at good for Linux as a project, but bad for Linux as a pay OS alternative.

Right, and when you convince professional racers to give up their finely tuned gear shifters in favor of a stick shift with a chrome skull and glowing eyes you let us all know.

I truely don't understand this mentality of making everything stupid user friendly. Once upon a time you actually had to know a little bit about the tools you were using to make them work. Now instead of creating powerful tools that require some understanding we want to replace them all with stupid proof crippleware? And people wonder why well over 90% of all email on the internet is spam. People wonder why Windows infection rates are so high (aside from the security holes allowing the stupid user tricks, the stupid user still clicks on everything presented).

In this I propose that we place large concrete barriers along every major highway and paint tunnels on them with overhead messages like "Do you want a bigger penis? Drive here!" or "Get rich in this tunnel!" and maybe even "Protect your car from theives, enter here!"

If I want a machine that just works, I buy a pc (or a mac, if I don't want to play any games on it).

If I want to join the linux fan club, then I'd install linux. The point was... GREAT - it has a good motor. But good engineering isn't the key to making a good product - there are a lot more variables that go into it.

Sure, bad engineering would cripple a product. But good engineering alone doesn't cut it. It has to be paired with accessibility.

if I didn't have a laptop, you'd be correct. I thought i made it clear that i wasn't talking about servers. I guess not, but thanks anyways for the troll. You can go back to playing wow or whatever you spend your free time on.

... and maybe you didn't see the parent. I'm glad the kernal has been updated. I'm sure it serves some purpose to some people. but generally speaking, windows does most things for most people (end users).

Running a pre-release of Fedora 9 on his wife's computer, Linus Torvalds was not able to view YouTube videos with Swfdec, leading him to send a comical error report in which he makes an ardent appeal for help to Fedora developers, "This is 'high' priority because the wife will kill me if she doesn't have her videos."

Dear Linus,From all of us here at the Fedora Project we just wanted you to know we're verypleased you're testing Fedora 9 and filing bugs. We also wanted to let you knowthat we're never gonna give up fixing these bugs.We know when we do our bestwe're never gonna let our users down. Sometimes it may feel like it but we'renever gonna give you the run around on these bugs, either. We don't want todesert you nor you to desert us.

The Board wishes it to be known that:
1. Mr. Vidal has, in the parlance of second-rate spy movies, "gone rogue," and
has posted on behalf of the Board without the required routing through several
committees, endless cross-posted discussion, and explicit approval, and
therefore his pay will be docked accordingly.
2. He is clearly an enormous Rick Astley fan, although he attempts to disguisse
this fact through paraphrase.
3. We love you, Linus! *scream*
4. We wish for Mrs. Torvalds not to visit pain upon us, and thus thank our
community for stepping in and helping Linus get this bug handled.
5. Because it's Friday, things may get a little silly around here. Oh, and mind
the gap.
Paul W. Frields
Fedora Project Leader

Dear Mr. TorvaldsWe appreciate your submission of a bug report for swfdec, and we have submitted it to the maintainers. However we are unable at this point to assign it "high" priority because it appears to be an interaction of a buggy ACPI BIOS with the Intel HDA audio codecs. We refer you to Toshiba for support details.

In the meantime, you may not be aware that the traditional SYSV "inittab" mechanism has been replaced in recent editions of Fedora with the newer "upstart" mechanism. Simply edit the "/e

What does this kernel mean for the desktop? Does it for example allow me to use my Hauppauge PVR-150 remote control by default, just like the present kernel does for the TV card itself ?

Under the kernel for Mythbuntu 7.10, that getting that remote control to work is next to impossible...even after tinkering with all sorts of text configuration files. To cut it short, getting the remote control to work was an exercise in frustration.

The program which MythTV uses for remote controls is called "lirc". You didn't say which version of the PVR-150 remote you have, but it sounds like the MCE version (which was tailored to the Microsoft MCE OS).

Google for whichever version of remote you have and lirc, and there'll be a dozen howtos to help you.

When it comes to the remote control, I tried. Trust me. It just did not work. I know about lirc. I tinkered all I could but it did not work! There is community support for the WinTV-PVR-150 at http://ivtvdriver.org/ [ivtvdriver.org] and I can tell you that it did not work for me. By the way, I am no Linux newbie but I must admit I failed on this.

Then why did you raise a Microsoft/lirc issue in a Linux kernel discussion?

The page you've linked to is about support for the PVR-150's video decoding chips, not for the remote controller.

The problems you're having with the remote may be because there's more than one version, the original, and the Microsoft one. If you try to use the original config files with the Microsoft remote, it won't work.

Also kernelnewbies.org seems to be very slow at the moment. Here is a copy of the important changes section from their 2.6.25 changelog page:

1.1. Memory Resource Controller

Recommended LWN article (somewhat outdated, but still interesting): "Controlling memory use in containers"

The memory resource controller is a cgroups-based feature. Cgroups, aka "Control Groups", is a feature that was merged in 2.6.24, and its purpose is to be a generic framework where several "resource controllers" can plug in and manage different resources of the system such as process scheduling or memory allocation. It also offers a unified user interface, based on a virtual filesystem where administrators can assign arbitrary resource constraints to a group of chosen tasks. For example, in 2.6.24 they merged two resource controllers: Cpusets and Group Scheduling. The first allows to bind CPU and Memory nodes to the arbitrarily chosen group of tasks, aka cgroup, and the second allows to bind a CPU bandwidth policy to the cgroup.

The memory resource controller isolates the memory behavior of a group of tasks -cgroup- from the rest of the system. It can be used to:

* Isolate an application or a group of applications. Memory hungry applications can be isolated and limited to a smaller amount of memory.
* Create a cgroup with limited amount of memory, this can be used as a good alternative to booting with mem=XXXX.
* Virtualization solutions can control the amount of memory they want to assign to a virtual machine instance.
* A CD/DVD burner could control the amount of memory used by the rest of the system to ensure that burning does not fail due to lack of available memory.

The configuration interface, like all the cgroups, is done by mounting the cgroup filesystem with the "-o memory" option, creating a randomly-named directory (the cgroup), adding tasks to the cgroup by catting its PID to the 'task' file inside the cgroup directory, and writing values to the following files: 'memory.limit_in_bytes', 'memory.usage_in_bytes' (memory statistic for the cgroup), 'memory.stats' (more statistics: RSS, caches, inactive/active pages), 'memory.failcnt' (number of times that the cgroup exceeded the limit), and 'mem_control_type'. OOM conditions are also handled in a per-cgroup manner: when the tasks in the cgroup surpass the limits, OOM will be called to kill a task between all the tasks involved in that specific cgroup.

Code: (commit 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12)

1.2. Real Time Group scheduling

Group scheduling is a feature introduced in 2.6.24. It allows to assign different process scheduling priorities other than nice levels. For example, given two users on a system, you may want to to assign 50% of CPU time to each one, regardless of how many processes is running each one (traditionally, if one user is running f.e. 10 cpu-bound processes and the other user only 1, this last user would get starved its CPU time), this is the "group tasks by user id" configuration option of Group Scheduling does. You may also want to create arbitrary groups of tasks and give them CPU time privileges, this is what the "group tasks by Control Groups" option does, basing its configuration interface in cgroups (feature introduced in 2.6.24 and described in the "Memory resource controller" section).

Those are the two working modes of Control Groups. Aditionally there're several types of tasks. What 2.6.25 adds to Group Scheduling is the ability to also handle real time (aka SCHED_RT) processes. This makes much easier to handle RT tasks and give them scheduling guarantees.

Documentation: sched-rt-group.txt

Code: (commit 1, 2, 3, 4)

There's serious interest in running RT tasks on enterprise-class hardware, so a large number of enhancements t

I thought I'd heard somewhere that the new (fully OSS) Atheros drivers were going into the kernel with 2.6/.25, but see no mention. Does anyone have any information on the Atheros/DadWifi kernel merge plans?

From the "Controller Area Network" Wikipedia article: Controller Area Network (CAN or CAN-bus) is a computer network protocol and bus standard designed to allow microcontrollers and devices to communicate with each other and without a host computer.. This implementation has been contributed by Volkswagen.

It would be interesting to know where Volkswagen use this in Linux. Can I buy a car "powered by Linux"?

Has anyone noticed the forced CIFS migration warning yet? Do you have some links on how to do that? I mean just the obvious two things of being able to mount a remote windows share (preferably without being root), and setting up CUPS for printing to a windows-shared printer. All I see on Google are technical articles about the protocol.

i'm not 100% sure on what you're asking, but I'm guessing you are trying to change from smbfs to cifs, which isn't a big deal. Go in to the kernel config and select "CIFS", deselect "SMBFS" (you can have both selected, but there is no need), recompile, reboot. more details: http://www.gentoo-wiki.com/HOWTO_Setup_Samba [gentoo-wiki.com]

There is a big kernel warning that pops up in 2.6.25, saying that SMBFS is obsolete and will be removed by 2.6.27. As someone who has never even heard of CIFS until I saw that, my first reaction was "OMG, those Linux guys broke Samba! I'm so screwed!". I think that there are quite a few other people who will feel the same way when they try to mount a windows share.

SMBFS is where you're effectively pretending to be a windows 98 client to the windows host. The code is very old and barely maintained for the last few years.CIFS is the protocol that effectively replaced SMB in windows, and the CIFS module means you're pretending to be a windows 2000/XP client to the windows host.

mount -t cifs//[windows machine name]/[share]/[mount] -o "username="

is all you need for a manual mount, or use "mount.cifs", assuming cifs is compiled into the kernel or loaded as a modu

Was interesting - apparently it turns out that it's been there since the Sparse Memory Model was implemented but had never tripped before.

There was no range check on memory_present() so if you called it with a start/end range outside outside the scope of MAX_PHYSMEM_BITS it would overwrite areas of memory causing very weird and random effects during boot. Tracking it down was apparently a major effort by a good few people because the effects were so random.

It requires that you have 4G of RAM on a 32-bit kernel without PAE and have enabled sparsemem. Yes, despite having more physical memory installed than the size of the address space, you think your memory is sparse. Probably nobody ever configured the kernel like this until Ingo was doing random configurations (for testing) on a high-end machine.Sure, it's a bug, and was a mess to debug, but it turned out that probably nobody would have ever had a problem with this in practice. But they didn't know that unti