[vox-if] Installfest Hardware, etc.

Christopher James McKenzie mckenzie at cs.ucdavis.edu
Tue Mar 18 17:29:50 PDT 2008

I'm taking further discussion off the list --- please email me if you 
want to be included...

>      Knowing what you are doing is a hinderance.  It is when you don't 
> know what you are doing, that you find shortcuts...
>      But then, just about everything I do is a research project.

Online forums help you in volume with the trivial operations.  However, 
they are useless under complex situations.

>       Perhaps if I knew which conflaguration files to ignite...

I could show you at the installfest

>      I have the option on the BIOS.

Great, then it's easy.

>     c... c.. Compile???!!!  I mean, simple things I compile.  10k, 50k 
> source files.  But the whole dinking thing with non ECC, not even Parity 
> checked RAM???  That's on the edge of insane.  

Huh? Recompiling the kernel is trivial.  Really, it is.  Don't be scared.

>     Several machines share drives for low I/O (usually final 
> destination) files, served to the web by a low front end machine. Took 
> two hours to write.  And if I need to repurpose a machine, no problem!
>       As for LVM, No!  I rig things so onle one process is writing to or 
> reading from ONE file per drive.  Dramatic speed improvements that way, 
> as the head movements are minimal.  Hardware level optimization, simply 
> by the number of drives per machine; though you do have to write the 
> application yourself...

Although ACID is generally a good policy, manufacturers and industry 
design things to be used specifically.  Usually, letting these things do 
there thing is a better policy.  You are assuming contiguous files for 
instance, and that the file directory listings are reasonably placed on 
the disk.  You are assuming that the caching mechanism of the drive is 
more favorable in your model then in some other one.  You are assuming 
that the cost of latency is minimal to some speed increase.  You are 
assuming that the kernel stack to the ioctl level isn't better when 
parallelized.  Additionally, ACID, which is what you are essentially 
describing, was designed for reliability, more then speed.

>      Yes!  But I'd rather plunk down my dollars to let someone else give 
> me a STANDARD, tested, Known Good system. Then, if something goes 
> strange, and does so ONLY on my machine, I know it must be my software, 
> my hardware, not some screw up in the operating system.

The Cathedral and Bazaar by Eric S. Raymond may be an interesting read. 
  The highly integrated systems do not necessarily function better then 
the hacked together ones.  My Dell Poweredge only goes down with the 
power, and it runs FreeBSD 4.x - something it certainly didn't come with 
--- on processors it didn't come with, with RAM it didn't come with, on 
drives it didn't come with.  I've had uptimes on it for about 1 year --- 
and only because I tend to move around a lot.

To put it another way, if I was to want a sandwich, given the time, I 
would rather buy the ingredients myself to be assured of their quality 
then entrust a deli.

>       I've fought that war before on lots of systems... Nothing like a 
> Known Good Standard! (I've seen enough OS level bugs, etc... standards 
> make bug replication easier, and more conclusive as to cause if you 
> can't replicate it on another machine.)

That model of software development, specing standards before devel, is 
on it's way out.  It really is.  Just look at extreme or agile 
programming.  People in the field of software development life cycles, 
rhythms and methodologies are now actively recommending different models 
then the traditional "let's build a bridge" one.

>      None of them offer the kind of facilities that BASH offers.  I can 
> whip up a custom app in Bash in a matter of hours to day that youd take 
> weeks in Perl/Icon/Python, etc. and months in C.

I accept this challenge...

>      BASH delivers the most computation (using standard Linux utilities) 
> per line of code and per hour of human programming; far more than any 
> other language when used by a skilled programmer.  

I and Stephen Wolfram would have to disagree.  Let's try for nonlinear 
optimization and least square minimizing.  Then we can move on to FFT's 
and things that utilize transcendental and imaginary numbers.  Move a 
bit over to abstract algebra and I bet that BASH is starting to hurt a 

>      What I want, is to be able to say:
> a=de
> b=fg
> defg=testing
> and get echo {{a}{b}} to say "testing".

This is basic reflection.  Most modern languages, in fact, even 
Javascript, supports this.  I really suggest you do a survey of what 
modern scripting has to offer.

>      That's the kind of crazy stuff I do. I've programmed in over 35 
> different computer languages, been a Software Linguist on an project for 
> IBM, etc. Don't claim to be good at any language... but I get things 
> done.  And do it faster and simpler than most anyone else.

I'm guessing you've worked a bit with JCL, right?

>      If you can do that kind of crazy recursive substitution, you can do 
> fantastic rule based AI. I've done things like that. That is power that 
> blows all compiled and many interpreted languages away when used by 
> someone like myself.  Even blows prolog away.  And as I said, it can be 
> used to generate other code.

Here is how to do it in awk

ls -ltr | awk '{for(x=0;x<NR;x++) print $x;}'

x is substituted for $1 $2 $3 $4 etc.  It's basic reflection, in about 
30 characters of awk --- you could easily emit this too if you sprinkle 
a little quote here or there.

>      The first cut of anything I'll do in BASH, if I can.  Next, we try 
> making portions more efficient.  And finally, I'll use something like C, 
> or even assembler, for the parts that really need speed.

Yeah, going back to above --- I think that Intel's Compiler, icc, has 
probably a better track record, being internally developed by the 
company that made the processor, at knowing what will optimize the code 
as opposed to what just looks like optimization.

I've thrown a few optimization flags on icc with basic c code and been 
on par or faster with my assembly writing counterparts simply because, 
perhaps, for example, using the EFLAGS register in some sequential 
manner is faster then using the same over and over - for some obscure 
reason based on the architecture of the chip.  You and I don't know 
these details, but Intel does.

>      What else I am looking for, is a good, simple editor that has macro 
> capabilities, and the ability for the macros to kick off into BASH to 
> run utilities.  I had a version of CRISP way back that could do it under 
> Interactive Unix (pre Slowaris) and DOS...  but I lost the source.  (No, 
> I don't want to learn Emacs.  My fingers do word star.)

Wikipedia has a nice survey of text editors, many supporting what you 
talk about.

>      Anyway, it sounds to me that if I could set up an ethernet boot, I 
> might be able to get something installed.  (Gentoo would be 
> interesting... but again, I don't trust this hardware for compiles.)

Compilers have come a long way in the past 10 years - realy.  EGCS of 
1998 cannot in anyway be compared to modern GCC.

More information about the vox-if mailing list