[re: CONFIG_PROC_FS, CONFIG_SYSVIPC, CONFIG_BINFMT_AOUT, etc.]
> Yes! Away with these config options. Or at least hide them so they are hard
> to disable, and document them "strongly recommended". What Joe Random Hacker
I am not against having them documented as "strongly recommended" but I am
against removing existing flexibility in the hope of making some commercial
vendors "more comfortable" with creating apps for linux. In fact, the on
line Configure help has been a great addition, making "newbie" kernel
building choices a lot easier than it ever has been in the past. Most
options that are in common use are already listed as "strongly recommended".
> compiles into his kernel is his own business, and he is responsible for it.
Exactly. So if he/she deviates from the recommendations in Configure.help
without a clue as to what they are doing, then they deserve what they get.
The converse is that if the average newbie takes the time to read and
follow the recommendations in Configure.help, they should get a kernel
that (a) matches their system, (b) runs all the applications that they
will use, and (c) is not bloated out with lots of unused functionality.
> But what happens when a major distribution ships a kernel without /proc or
> SYSV IPC support?
That is a lame argument. Nobody like Red Hat or Slackware is going to
do something that stupid. That would be the equivalent of shooting
themselves in the foot. Distributions that do stupid things and that
don't respond to public complaints simply die. See SLS as an example.
> Do we want Linux to remain a hackers kernel forever?
No, and fortunately it is already far from a "hackers kernel" already.
But do we want linux to throw away useful flexibility just to simply
try and be more appealing to at most a handful of commercial software
suppliers? Hrmmm.... not for me thanks. I can buy a commercial unix if
I want limited flexibility, and dictated policy on what I must support.
Paul.