17 Nov 2000 (updated 17 Nov 2000 at 06:40 UTC)
»
WARNING for you academic Advos, sysadmin geek talk below Skip it
Waldo: put Windows on first, then Redhat, and be sure to tell Redhat's
LILO
setup screen about your Windows partition. (I think the newer Redhats actively look for Windows installs on the
disk.) If the installer sees the Windows partition it should set you up with a LILO stanza that will do the job. If for
some reason you must have Redhat on first, the Windows install will kill LILO when it installs its own MBR. Boot
from a rescue disk, mount the Linux partition, and rerun lilo with the "-r" flag.
Or wait, are you dealing with multiple hard drives? Ah, that is sufficiently more complex. Contact me.
cdent: when the restlessness
overcomes the intertia, I shall go. The vaguely dissatisfied rumblings I occasionally air out are the seeds of that
restlessness. And the hostile takeover may be closer than you think...
Kernels are fairly low level pieces of code, in which the common code paths are traversed a
lot.
There is probably plenty of justification there for micro-optimization. As you move up the "code ladder" i.e. kernel,
libraries, servers, apps[1] - optimization gets less emphasis. It seems
to be an article of faith among app programmers that "the hardware is fast enough." Visual Basic perhaps being
the modern culmination of this attitude. I recently read Software Runaways by Robert Glass and some of
the articles collected there suggest that faith is misplaced. Software written with 4GLs took minutes to do what
the old "antiquated" software did in seconds. Not that 4GLs are inherently bad, but in these cases they were
misapplied.
Maybe I will invest in some Knuth books for my collection, that should get me back into algorithms and math. (Not
that Knuth, the other Knuth.) I still have my Lewis and Denenberg book on data
structures (excellent book) and sometimes I pull it out and read some of the proofs or the algorithms. One problem
with college is that the students, willing as they may be, usually don't have the perspective to really grok the
lesson. Now that I've been doing this for a few years the books make a lot more sense.
I did a Google search for "discrete structures" and found this page with some interesting maxims. My
favorite is this one because, oddly enough, it is under the heading "General Operating Principles"
1.There is no general methodology for solving a problem.
========
[1] Strictly speaking, servers are applications but are a special
case in my little taxonomy because they mostly interact with other software, not people, so their performance
demands are somewhere between libraries and so-called end-user apps.