Knoppix V6.7.1

[ruymbeke]

Hi Klaus,
Your steps are working great, thank you very much !
(I should stop using synaptic and better start using apt-get...)
Best Regards,
Gilles

[utu]

I've found the cause of this strange behaviour; it is the testing version of "lxpanel". After downgrade to stable version "0.5.6-1" I have the menu at my preferred position.

@ Werner

PCLinuxOS has another work-around at post #15 of this thread:
http://www.pclinuxos.com/forum/index...,95512.15.html

Cheers,

[utu]

@ Werner

There is also an lxmenu (empty menu) work-around on the LXDE wiki that may interest you at:
http://wiki.lxde.org/en/LXPanel#gxine_menu_icon_fix

[ruymbeke]

Hello,
Does anyone know why compiling a source tree as "root" is much slower than as the default "Knoppix" user ?
(by just using "su" before starting the make). Top indicates a much higher percentage of system call (%sy)
with root than Knoppix and as such there is not much time left for the user apps (%us). Any idea how to fix it ?
(I know it is usually a bad idea to compile as root anyway but in some cases root is required...)
Thanks,
Gilles

[kl522]

Hello,
Does anyone know why compiling a source tree as "root" is much slower than as the default "Knoppix" user ?
(by just using "su" before starting the make). Top indicates a much higher percentage of system call (%sy)
with root than Knoppix and as such there is not much time left for the user apps (%us). Any idea how to fix it ?
(I know it is usually a bad idea to compile as root anyway but in some cases root is required...)
Thanks,
Gilles

Personally I am not so convinced that compiling things as root will be slower, unless the makefiles do additional things when detecting compiling as root verses normal users. In any case, if one compiles something repeatedly, the speed can be improved by installing/configuring 'ccache'. Therefore if compile as root is indeed slower, perhaps the cache has not been setup for 'root' ? It's easy to verify that, just check if there is a .ccache folder for /home/knoppix. If the folder exists, meaning likely you have been using ccache without realizing it.

[ruymbeke]

Hi kl522,
I do clear ccache: "ccache -C; ccache -z" and do a "make distclean" before the "make"
to have a fair comparison between the root and knoppix user. It is actually a cross-compile
but I don't think that it makes any difference...
Best Regards,
Gilles

[kl522]

Hi kl522,
It is actually a cross-compile
but I don't think that it makes any difference...

The ccache may not support your cross-compile, you have to check if the "non-ccache" compiler binary name is one of those having the same name as one of those in /usr/lib/ccache. If the binary you used for cross-compile is not any of those, then too bad, debian ccache package does not support your cross-compile.

[ruymbeke]

Hi Kl522,
I do run my test both with and without ccache. As expected, running twice or more with ccache provides some speed improvement.
But at this point I do not care much about ccache. The problem that I try to understand is the time difference when compiling as root
or as the knoppix user. Or in other words, in both cases (with or without ccache) running as root is much slower than with the user Knoppix.
Thanks for your help. Best Regards,
Gilles

[kl522]

The problem that I try to understand is the time difference when compiling as root
or as the knoppix user. Or in other words, in both cases (with or without ccache) running as root is much slower than with the user Knoppix.

Without disclosing any of your proprietary work/sources, are you able to provide with a test-case of compiling as root is slower than compiling as knoppix user ?

[ruymbeke]

Hi Kl522,
After trying to reproduce the problem with some sample code and a toolchain publicly available
I found out that the problem is linked to the Code Sourcery ARM toolchain (full license).
Or in other words the problem disappear when the lite version is used. I did post a support
request with Code Sourcery as this problem is most likely not linked to Knoppix at all.
Thanks for your help, case closed.
Best Regards,
Gilles