Salix Forums

The Linux desktop may soon be a lot faster - Computerworld Blogs

It says that by adding 233 lines to the Linux thing (by Mike Galbraith) makes the Linux stuff faster or something like that

Even if this is really gonna happen then application coders will do their best to waste the saved cycles by performing something useless or just by sloppy coding (you know: CPU cycles are cheap so why optimize? RAM is cheap too...).

I can remember several years ago I was running KDE3 on 64MB RAM and 700MHz CPU and it was OK. Nowadays you need ten times this in order to use KDE. You might have read my rants on resource waste elswhere already anyway.

You have a really good point about that waste of computer resources and useless tasks (something useless), sometimes I'm wondering about that same thing, as well.

witek wrote:You might have read my rants on resource waste elswhere already anyway.

No, I haven't, I'm reading it now, thanks.

Edit: well, you have some very good questions there, I really like it, very well done.

Edit: Off-Topic

[color=#FF00FF]GazL[/color] wrote:I don't buy into the inefficiency conspiracy theory between hardware manufacturers and software vendors that you suggest, but it does make you wonder where it all went wrong!

Oh no! Mozilla Firefox the king of conspiracies (funded by CIA/Google) to screw our PCs (Get Midori)

GNOME has key people who are working for Novel... Love GNOME, Beware of Mono
EDIT: removed super big picture.
(I'm trying to find the reply to the post (2009/11/12) from one of the GNOME developer - I think the title was: "I'm famous")

Mod edit: removed big picture

KDE4 maybe has a conspiracy, but according to what I know so far, they're suggesting a fancy desktop by nature (I'm not sure, though) and I've never had any problems with it - I mean, KDE are pretty much consistent with their declarations.

Politics, the bad kind (=personal benefit/special interest), is ALWAYS involved, and we always must be in guard.

witek wrote:coders will do their best to waste the saved cycles by performing something useless or just by sloppy coding

This is not about saving CPU cycles, it's about faster switching between apps on a multitasking system to improve responsivness.

zAchAry wrote:Mod edit: removed big picture

Code: Select all

http://techrights.org/2009/05/03/mono-free-gnome-based/

it that ok?

@thenktor:
I guess that switching between apps takes some CPU cycles as well

So if they optimize this process they will save some cycles, too. I`m not going to argue about that. I just want to emphasize that soon this speed gain will be compensated with more resource-hungry applications.

@zAchAry:
My suggestion about conspiracy between coders and manufactures was much exaggerated. I just wanted to emphasize some points about resources and make people think about this a bit. People don`t realize what gigabyte means and what nanosecond means, etc. If one tries to imagine how much information fits into a gigabyte then he might conlude: "hey, why do we need so much memory? why my computers boots so long, what did it do during these billions of cycles that just passed?" etc.

witek wrote:@thenktor:
I guess that switching between apps takes some CPU cycles as well So if they optimize this process they will save some cycles, too. I`m not going to argue about that. I just want to emphasize that soon this speed gain will be compensated with more resource-hungry applications.

I just wanted to explain that in fact it's not about any speed gain at all. Things won't be faster. It just feels more responsive and this is what is important. Perhaps the total computing time even may be longer, but noone cares as long as you can really use the computer under load, too.

I`ve just found an "alternative to this patch that does the same thing yet all you have to do is run 2 commands and paste 4 lines in your ~/.bashrc file"
You can try by your own:
http://www.webupd8.org/2010/11/alternat ... patch.html

EDIT: does anybody understand what these entries in .bashrc means? And if it works why didn`t it was used before? It looks that linux kernel got big and complicated and nobody understands it as a whole if someone tries to patch a kernel against something solvable with bash setup.
EDIT2: I can see the matter is being discussed on Fedora and Slackware forum and I`m gonna ask them too.

Interresting thread in the LKML.
I just miss the pop-corn

witek wrote:EDIT: does anybody understand what these entries in .bashrc means? And if it works why didn`t it was used before? It looks that linux kernel got big and complicated and nobody understands it as a whole if someone tries to patch a kernel against something solvable with bash setup.

It is doing almost the same thing the kernel patch did. For every interactive shell (->PS1) created it creates a new cgroup with the pid of the shell as name and adds that shell/process to that group. Accordingly all subprocesses of that shell/group are also added to the same group.
By dividing the processes into groups the kernel can distribute cpu time better between them and therefor the system's responsiveness improves.

I'm only wondering whether with the bash approach those cgroups are again destroyed automatically, if all processes attached to it terminate. (EDIT: To my understanding of http://www.mjmwired.net/kernel/Document ... groups.txt it creates but doesn't delete groups anymore, thus imho leaves a mess behind.)
Furthermore I think the bash approach enables any user to create cgroups to his liking, which might be a security problem.

Unfortunately I couldn't try it out as the Slackware kernel lacks (at least on 64-Bit) cgroup support.

EDIT2:

JRD wrote:Interresting thread in the LKML.
I just miss the pop-corn

Better than watching reality TV/ soap operas. Honestly, I think more people should be watching.

Salix Forums

The Linux desktop may soon be a lot faster

The Linux desktop may soon be a lot faster

Re: The Linux desktop may soon be a lot faster

Re: The Linux desktop may soon be a lot faster

Re: The Linux desktop may soon be a lot faster

Re: The Linux desktop may soon be a lot faster

Re: The Linux desktop may soon be a lot faster

Re: The Linux desktop may soon be a lot faster

Re: The Linux desktop may soon be a lot faster

Re: The Linux desktop may soon be a lot faster

Re: The Linux desktop may soon be a lot faster