This site is now 100% read-only, and retired.

XML Logo

Posted by Azerthoth on Fri 27 Oct 2006 at 14:14
Tags: none.
This may be something simple stupid, however I cant seem to find any documentation on it.

With a sym link to a file or directory regardless of the permissions of that file or directory you end up with full permissions (777) on the sym link. Why is that or what am I missing that would mean I'm not seeing what I think I'm seeing?

ls -l for the symlink returns

ls -l on the original returns


Posted by Azerthoth on Fri 25 Aug 2006 at 02:50
Tags: none.
This article has been inspired by a few comments I have recieved over my previous article. The upshot is a few people were more than a little upset that I had blasted their favorite environment as bloated, and that it worked faster than others. So I decided to see if my opinion based upon my own observations were viable or I had been in fact talking out my ass.

The following are a few things I discovered about how much memory is used by the base system using the following ground rules.

1: Reboot between each test to guarantee that the system memory was completely flushed.
2: The only running program that I added would be conky. If you have looked at the snapshot of my destop, its the system monitor that is in the top right corner of the display.

Fluxbox: 38.7 meg
Openbox: 40.1 meg
KDE: 57.6 meg
Afterstep: 60.9 meg
Gnome: 77.6 meg

Admittedly Gnome running that high suprised me a bit. I had been expecting KDE to take that position. Openbox shocked me a bit as well, I had assumed that it would have been less than Fluxbox.

The next thing that was under debate (I was getting lightly flamed for in my bashing of KDE) was that konqueror was faster and had a lighter footprint than Firefox. This is true if you happen to be running KDE, because upon a bit of looking KDE precaches a few things. For the next bit of testing I only used KDE and Fluxbox, the reasoning being that while Firefox is not native to either, konqueror is native to KDE.


App %CPU %mem
konqueror 2.7% 4.9%
firefox .5% 4.5%

This isnt the whole story though, when bringing up konqueror the following extra processes fired.

klauncher 0.0% 1.5%
kded 0.0% 2.1%
kdeinit 0.0% 1.6%
kiofile 0.0% 1.6%
kiofile 0.0% 1.6%
kiofile 0.0% 1.6%
kiofile 0.0% 1.6%
dcopserver 0.0% 1.3%


firefox 0.7% 4.5%
konqueror 1.4% 4.6%

Now of course when we went to look, all those same extra apps were in place and running. The interesting thing I saw was that those same 4 kiofile processes disappeared when I shut konqueror down. However if you want here are the same processes I found in Fluxbox but this time running inside KDE, some of these of course are running when in KDE regardless (that sneaky precaching)

kiofile 0.0% 1.5%
kiofile 0.0% 1.5%
kiofile 0.0% 1.5%
kiofile 0.0 % 1.5%
kded 0.5% 3.0%
dcopserver 0.0% 0.5%
kdeinit 0.1% 1.5%
klauncher 0.0% 1.6%

Let me close this with:
A: This is not truly a fair test. Konqueror does much more than just act as a web browser.
B: All the info I pulled in the second half of the comparison was gained by the use of

ps -aux

while both firefox and konqueror were minimized in exactly the same condition that they opened up in. I didnt go to any websites or browse and files.
C: In running the same set of tests in Gnome the results were close enough to the same as the first to as to not to mention it.
D: I wont draw any conclusions for anyone, but let the numbers tell their story.

Regardless, I will still use both programs as the need arises. Firefox for webbrowsing and Konqueror for system browsing. The previous tests were run on a compaq presario R3200, 2.6.16r2 non optimized kernel, AMD+3000 32bit, and 512M ram.

If someone runs similar tests and comes up with significantly different numbers, please share them.


Posted by Azerthoth on Wed 23 Aug 2006 at 00:49
Tags: none.
Well, the first article I wrote seems to have struck a cord with a few people.

It seems that a few of those "In The Know" didnt know that the security repositories for etch are included in the sources.list even if you choose not to use a network mirror. So now they know too *grin*

Anyway the goal of that article was to help out with something I could find no documentation for that was written for non programmer humans. I think I succeeded in that, and some of the comments that have been made are good for helping others choose a path that they might want to take. All in all a pretty good start here I think.