Pottering's code appears to just be a proof of concept. It really doesn't make sense to have this behavior in a bash initialization file. Not to mention you'd have to launch your X session from that bash instance (and you'd have to be using a bash-compatible shell to begin with or port the code your preferred shell) to get the desired effect.
That is nice, but I'd rather see how this would be properly implemented in userspace. Pottering was eager to prove the performance increase could be applied to userspace, not how he would integrate this approach with current Linux desktops.
Also, as Linus noted, it would be nice for users to just perform a standard system update and all of the sudden have a more responsive desktop on reboot. If it can be done in userspace, distros should flesh out the userspace code and disable the kernel feature. Once it is reasonably handled in userspace across Linux distributions it can be removed from the kernel.
I find more often than not, that "abrupt and to-the-point" is mistaken for "rude and offensive". A FOSS community is a meritocracy, and there's a lot of people who stroll in with a lot of talk, nothing to back it up. The few that show up with code and/or data are often received very well.
People with the aptitude to become community or project leaders often like a good debate (OK, sometimes it seems like an argument), and will often provoke it, if only to see how well the point can be defended. When the chips are down though, rational decisions based on facts is what wins.
I may not be as gruff as some of the more infamous names around, but I will often argue a point, as well as play devil's advocate, just to see how the debate plays out. I learn a lot that way, whether I'm correct or not.
[Edit] Re:Linus
I agree that Linus' reply was a rude, and perhaps I've been desensitized to this over time, and let it slide too often. My comment however, was meant for the more general case to which I replied.
> I find more often than not, that "abrupt and to-the-point" is mistaken for "rude and offensive".
Calling someone's theory bullshit is rude and offensive. Telling someone they are full of shit is also. Abrupt and to the point as a general class of communication further is often rude. Making or attempting to make people feel worse than you need to to get your point across efficiently is offensive.
In this case, for example, Linus could have simply said, "That's a nice theory. If you can prove it, we'll consider it." That's more to-the-point, communicates the entirety of what Linus managed to in his email, and also is not rude.
I disagree. There are hundreds if not thousands of people willing to waste his time (Linus) with theory and conversation, his abrupt, rude tone makes it clear that unless you are communicating actual information, not just theories, don't bother him with this stuff. It is rude but I expect he does not want to be bothered with fluff, only real information.
I agree in this case (see my edit). It seems most people in a working FOSS community will give quite a bit of slack to someone who's proven their value.
There is also context and a dynamic that outsiders may not always aware of. A colleague of mine could say "you're full of shit - come back with something that works", and I would be more likely to take that as a challenge than an insult. Similarly, within the LKML, this response is somewhat expected, and you better have your defense ready for the ensuing battle.
Get a bunch of egotistical, powerful, and moderately financially successful aspies together and have them solve a problem. This is a recipe for disaster and anybody who reads the kernel mailing list knows it. Sadly about half the coders I know in real life are even worse than Linus.
Consistently astonished? Not really. LKML is probably not the best place to go bikeshedding. Of course it will be met with hostility.
More to the point, Linus is known for that kind of comment. A lot of the time his point is as important as it is off-putting (see the git vs. C++ rant.)
I keep my .bashrc in version control and install it on all systems where I use bash. It's not the best place for platform-specific optimizations. Those 4 lines of code aren't portable, and there isn't a single line in my .bashrc that requires root privileges. I realize the example was a proof-of-concept, but I doubt this issue is easy to solve in userland, compared to just automating it in the kernel.
Alternate title: Red Hat speeds up Red Hat Linux with 4 lines of code and systemd.
I was wondering when the freedesktop dudes were going to make a "come back". Linus, in fact, does not oppose the user level approach [1]. I too, however, share his disgust for user level code to interact with every process and group, it's just awful. The kernel seems like a good place to implement an interface for this, that user space can use effectively and without imposing extra complexity on the kernel.
This actually worked for me on a recent quad-core amd with Ubuntu 10.04. My sunspider bench scores on Google chrome 8.x shot up by 30%, IIRC.
This was a couple of weeks ago.
It seemed like the CPU graph seemed to show higher cpu utilization line-trace for the core that was running the benchmarking Chrome process.
It causes readers to either slap their foreheads and say 'oh wow, 200 lines? I could have done that! why didn't I think of it?' or 'oh wow, it takes true genius to hit just the right 200 lines. I could have never done that!', the common factor being 'oh wow'
Why is the "I could have done that" reaction a good thing?
That implies "this should have been done from the beginning, but the developers were lazy / incompetent"
Also, it is better to have 500 lines of well-commented code with informative variable names, than just the right 200 lines. Software development should not be reserved for voodoo witch doctors who know just the right mysterious incantation to produce the desired effect.
Encouraging people to have the mentality "do it in < N lines or don't try" seems silly.
Number of lines is used as a proxy for complexity, especially among those who are less familiar with how the programming sausage is made (management, non-IT folks, etc.). To non-technical folks, it sounds pretty impressive that you can do a simple change (low # of lines) and get a huge improvement. Nevermind the fact that behind those couple of lines could be days of code analysis and several rewrites. It's the allure of the easy, "why didn't I think of that" kind of thing.
I imagine when you're talking about a code base the size of the Linux kernal, there is likely something to be said for code brevity. (There is also something to be said for "readable")
because a 200 line kernel change is not the same as 4 line shell-script change. fwiw, i had posted that many a moons ago here : http://lwn.net/Articles/414817/.
That is nice, but I'd rather see how this would be properly implemented in userspace. Pottering was eager to prove the performance increase could be applied to userspace, not how he would integrate this approach with current Linux desktops.
Also, as Linus noted, it would be nice for users to just perform a standard system update and all of the sudden have a more responsive desktop on reboot. If it can be done in userspace, distros should flesh out the userspace code and disable the kernel feature. Once it is reasonably handled in userspace across Linux distributions it can be removed from the kernel.