[lug] dumpdates

[Wayde Allen]

On Mon, 14 Aug 2000, John Starkey wrote:

> You were right. I was looking at the Kernel as /lib, /bin, /src,
> /proc, /boot, /sbin, /temp and /var. Probably a left over assumption from
> the Windows and MacOS install features.

I don't even think that Windows or Mac machines work that way.  There
should still be some master program (win.exe or something similar) that
runs and would be kind of akin to the kernel.  Yes there is a lot more
interdependancy there though.

> Maybe the term is System instead
> of Kernel. 

You could probably think of it that way.  In Linux, the kernel, the file
system, and the collection of program is all called a distribution.  If
you are a purist only the kernel program itself is actually Linux.
Everthing else is someone's idea about what constitutes a good file
structure, and a collection of GNU/OpenSource software.

> I assume at this point Mac and Windows also have a Kernel (for
> lack of...).

That is correct.

> Thinking that each of these would be modified for whatever I compile into
> the kernel (and erased using make clean).

Nope!  The make utility works only on the source code directories.  One of
the compiler gurus can tell you for certain what "make clean" does.  My
guess is that it cleans out the intermediate object files so that the
compilation process starts over "clean".  In any case, compiling a kernel
does nothing more than compile the source code pieces and link them
together to create an executable kernel file.  There is nothing like a
"make install" (at least not that I'm aware of) that actually copies the
resulting program anywhere, overwrites anything, or sets the new kernel up
to be bootable.

(Actually, the "make modules" and "make modep" commands probably do write
the object code to the /lib/mod directories.  I'd have to check to be
certain.)


>  So my grand plan was to rename
> all of these, well except for /var and /tmp and start over, again,

That is a pretty sure way to get started all over again alright <grin>.

> thinking that I could boot via floppy,

I haven't looked at the details of a boot floppy lately.  It either has a
boot loader that points to the kernel on the hard drive, or has a bootable
copy of the kernel that starts and  mounts the root file system from the
hard drive.  Either way, as soon as you start renaming major parts of your
system like this, you pretty much guarantee that the boot floppy will fail
too.

> copy the kernel and sort through
> the renamed files putting what I needed back in once I saw what the kernel
> put in these dirs (when it created replacements.)

OK, but hopefully now you know that the compilation really didn't create
any so-called replacements in all of these directories.

> I'm kinda glad it didn't
> work out that way because the info you've given me makes me think the
> kernel wouldn't rebuild the dirs I mentioned. And if it did I think it'd
> take forever to figure out what everything was for and make the box
> functional again.

That is correct.

> So regarding the security aspect of modules. It is safe to leave them in
> if the kernel doesn't support modules? 

To the best of my knowledge the kernel is the only thing that uses the
modules, and I don't think that programs that are not running are a
security problem.

> What I'm trying to do is get down
> to an "only what I need" state, without losing the existing functionality.

I think you need to modify your thinking slightly.  For security purposes,
I think what matters most is what processes are actually running on the
CPU.  Extra stuff on the hard drive is really just data taking up hard
disk space.  You worry about that sort of thing when your hard drive gets
full.

> what this box will do I need to know what's in here. And I'm not the type
> that can read a book and know what everything does, no adrenaline
> involved :}.

I like your willingness to experiment!

- Wayde
  (wallen at boulder.nist.gov)