Friday, 15 April 2011

Why?

Why do people have to complicate something that was already
complicated already?

OpenSUSE 11.x - very nice system, very slow network gui configurator
(GUI network configurators drive me mad also - everyone is different,
none of them as good as the old fashioned SunOS /etc/rc.local files,
and all of them bloat. OpenSUSE cannot even have a settings control
panel that even looks familiar to any other operating system).

But my beef is the kernel source/images. Everyone has the
module include files in /lib/modules/`uname -r`/build/. Except
OpenSuse who has them in the /lib/modules/`uname -r`/source directory.
(Maybe they are available in the build/ dir if I had installed the
right extra package, but its like russian roulette trying to guess
where people have stored things or what the package names are).

apt-get, zypper, pkgadd, ... the list of names for proprietary package
installers is maddening. WTF is "zypper"? At least "pkgadd" hints what
it is. apt-get - which I am now familiar with, is standard across
many distros, yet the name of the package installer on Fedora eludes me.

Whilst I am bitching, what is "plymouth", what is "policykit", what is
"hald-runner", and the other ten zillion memory hogging wasteful utilities
on a Linux system? Go look for "plymouth" on google and see how well
you find references.

What happened to meaningful names. Even "dtrace" hints at what it might
be, and is unique to not clash with any other English word.

So....why do I care? Because I am setting up a new dual-core VM
to debug the smp_call_function issue. I think I know why smp_call_function
might be causing me erratic reliability issues, but I need a good
kernel to demonstrate/cause the bug I am trying to find.

Incidentally, I have turned up the clock ticks in the tests/tests.d script
to 1mS, to force a higher rate of clock-ticks interrupting caught probes to
help diagnose the tests. (I might even go higher - I want to torture
any system I come into contact with, because that is the only way
to validate interrupt-based coding systems; reading code or test-driven
scenarios can never handle the multi-dimensionality of interrupts occuring
at just the right + wrong points in time).


Post created by CRiSP v10.0.5a-b5969


No comments:

Post a Comment