Public SourceMage Discussion List

[Andrew <afrayedknot AT thefrayedknot.armory.com>]

> >
> Well, that may very well be a reason ;-). Also, it may be easier to 
> maintain.

bubble sort is also elegant and easy to maintain whats your point?

> 
> >If we look at things from a efficiency standpoint I'd put my money on
> >a chroot. A chroot simply remaps some of the values in the chroot'ed
> >process's tables, and thus all its children as well, thus incurring
> >essentially no time penalty and running the same as non-chrooted
> >processes in terms of efficiency. A UML implementation, to my knowledge,
> >runs a linux kernel as a user land process. This means that any process
> >running under this user-mode kernel will eventually make system-calls
> >(thats what a kernel provides), these system-calls in the userland
> >process will eventually traverse through our user mode kernel down
> >through some idealized hardware and come back out the other end, where
> >might this be? well system calls on your native kernel, which then
> >have to run through a whole mass of stuff (again) before it gets to
> >real hardware. So you are essentially incurring unnecessary overhead,
> >and throwing cpu cycles out the window (IMO).
> >
> If you look at the whole tinderbox idea from efficiency viewpoint, it's 
> a complete waste of everything.

yes so lets make it worse!

> 
> >So we have what amounts to something that is functionally very similiar
> >but less efficient. If someone has benchmarks to correct me I'd be
> >willing to change my opinion of course.
> >
> Testing is never efficient IMO. It never gives you immediate return on 
> any investments, including time and resources.

uhm....
I think what you are missing is that there is a difference between doing
testing efficiently and doing testing inefficiently.

Why not crank the clock speed down to 25mhz while were at it? I mean
after all, its going to inefficient so whats the harm in making it
worse. We could run a crappy file systems under it too, because after
all testing is inefficient and theres no point in helping it go faster
so we actually get something productive done. We could strip out all
our ram, or load up our swap space by filling up a tmpfs mount until
our system doesnt have a reasonable amount of memory to deal with and
just thrashes.  And why not just recompile make and gcc with busy loops
in them everywhere (i'll write the patches even!) so they waste some more
cycles while we twiddle our thumbs waiting to learn why our broken distro
has newbies give up on it because things dont compile. Since after all
testing is never efficient, and since we wont get an immediate return on
our investment, of time and resources, we may as well not give it any help
either! in fact testing should be as slow and inefficient as possible.

*grin*

Show me benchmarks and I'll shutup ;)

Andrew