Vacation ended, made up my mind, here is what I want to do

mabell at mabell at
Sun Jun 11 15:06:35 PDT 2000

>> You wouldn't happen to be part of Debian now would you? :)
>    nice one-line comeback there :).
>    of course Gerard will comment here with his own point of view, but i
>personally think that LFS is a HOWTO on how to build your own system.  you
>can (and should) modify it as you see fit.  lfs is not a distribution with
>strict guidelines on the filesystem hierachy, systems of packaging, or
>otherwise; if you want that, it is always possible to rebuild any of the
>current distributions from source (Slackware in particular fits this role
>nicely.)  rock-linux is also designed around this concept.
>    you should probably tell the user to install things into /usr instead
>/usr/local and provide basic hints like that, but one thing that LFS should
>not become is another distribution.  it's a guide on how to get a system up
>and running from source code only.  if an advanced user wants to do things
>differently, of course he should, and he should have the freedom to do so
>without a HOWTO bogging him/her down.

i guess i should have been a little clearer on what i was saying..
i meant basic guidelines.. otherwise we have some people using
installing packages into /usr/local/[name], ie /usr/local/samba with
the config files in /usr/local/samba/etc and such.. some people
putting them into /opt and even others into just /usr
we would have someone write a firewall howto with ipchains.. but what
if he doesn't update it when 2.4 comes out? then this howto will only
screwup people who don't know that 2.4 doesn't use ipchains, there
might be three different howtos on how to install apache, each one
using a totally different method.
we need to setout some rules not to say the person installing cannot
break them, but to make the howtos agree.. such as:
1. packages go into the /usr dir instead of /opt or anywhere else
2. the howto must be written as though the user has installed only the
   base lfs system
3. the init scripts should be written following a certain pattern
4. even assign a certain order that daemons startup, otherwise we might
   have our named and dhcpd both telling the user to link to /etc/rc2.d/S45*
   or whatever
5. the writer must keep it updated, help out when problems arise

otherwise this thing will become a mess...

the decision to kill my redhat stickers came after my boss had me talk
to a RHCE that he thought was a linux guru,
the rhce told me about how i should load my network by putting ifconfig
statements in my /etc/rc.d/rc.local, he said that the one file that linux
(he wasn't saying redhat, but was saying linux) had to have to startup
was the rc.local (funny, i don't even have one on my lfs box.. umm..)
he went on about how you can sit in a ftp and wait for the root to put his
password in so you can get root access, taking telnet connection by using
ip spoofing (was he thinking of rlogin, dos, ip spoofing.. kevinmitnick
told me about how linux is "rocksolid" and if you set it up right it is
"impossible to hack" and all sorts of bullcrap.... oh, and that he worked
for redhat and was a major part in making portsentry, anyways after this
i decided that redhat was for extreme pussies, not to say i won't still use
it some at work sometimes because its easier then making coffee..
problem is i don't want to buy a bunch of stickers from redhat then print
back over.. cost too much and probably illegal.. but it would be cool if the
offical lfs sticker was a overprint of other linux dists.. umm.... ideas

enough wasted screen space..
mabell at

Mail archive:
IRC access: server: port: 6667 channel: #LFS
News Reader access:
Unsubscribe: email lfs-discuss-request at and put
"unsubscribe" (without the quotation marks) in the body of the message
(no subject is required)

More information about the lfs-dev mailing list