Gerard Beekmans gerard at
Thu Jul 20 11:08:12 PDT 2000

> If you just ask the question "will everyone need it atleast once?" then
> there are clearly other programs that could go. For example, not everyone
> will need to have man installed. Obviously, almost everyone needs man unless
> they have all the commands that they use memorized. But I would argue that
> with the new kernel module daemon (kmod not kerneld) almost everyone will
> want cron. kmod doesn't remove modules like kerneld did. It leaves the
> cleanup to the user. So, unless you want to check which modules you have
> installed and remove the unneeded ones every 15 minutes, you need a cron
> job. Personally, I don't really care if it gets in the book because I can
> always install it on my own. However, I do believe that kmod makes it part
> of the basic system software.

I don't use kmod. I'm sure I'm not the only one. I don't like the kernel
loading modules when it needs them. I want to be in control when the
kernel starts loading something (when I need something frequent I put
them in rc scripts).

I'm aware that there are programs in the book that you could do without
on a bare system such as groff, man, bzip2, and more of those.

When I say "I included them because they are often used and it's simply
wise to have it around" then cron does fall under that category.

If kmod was going to be part of a more or less required kernel option
(like devfs is going to be) for an LFS system then cron will be
introduced since it's needed to use kmod most effectively.

But I don't want to start requiring kernel options. If you come with the
argument "install cron because it's recommended with kmod" then the book
has to install ISDN Utils as well because somebody might configure LFS
for use with ISDN. And I have to include IRDA in case somebody enables
an infrared port. Do you see where I'm getting at?

Including cron because a kernel option recommends it isn't a good enough
reason for me to include it.

Gerard Beekmans

-*- If Linux doesn't have the solution, you have the wrong problem -*-
Mail archive:
IRC access: server: port: 6667 channel: #LFS
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