From: Marsh J. Ray (marsh-obsdmysteray.com)
Date: Wed Jun 02 2004 - 05:13:04 CDT

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Theo de Raadt wrote:

> Ben Goren <bentrumpetpower.com said:
>
> > On 2004 Jun 1, at 10:41 PM, Damien Miller wrote:
> >
> >> One of the best things about OpenBSD is that it works out of the
> >> box. I don't have to worry about kernel modules not matching my
> >> kernel, runtime-loaded kernel rootkits or obscure module
> >> dependancy bugs. I can't recall one occasion where I have
> >> /wished/ for a particular driver to be a module.
> >
> > Hear, hear. Back in the day, I wasted far more time screwing around
> > with compiling Linux kernels--and the modules were the worst
> > part--than I ever saved by even the more aggressive performance
> > boost. And those loadable modules didn't give me anything in
> > convenience, either; quite the contrary. Ethernet modules refused
> > to load, and more....
> >
> > Sure, if you're running at the margins, you might need a custom
> > kernel. But, if you're running at the margins, you're in the
> > minority (by definition), and you either know what you're doing, or
> > you have the money or the time to learn.
>
> Well, spoken. And don't worry -- nothing is going to change. Simple
> is powerful.

I can recall _one_ time where I had to compile a smaller kernel to
shoehorn some old version (maybe 2.9 or something) on a laptop with 8 MB
RAM. How I wish I had the time I spent doing that back.

Having a single build to test simplifies testing (and therefore will
improve quality) greatly. For those of you who haven't thought this
through, if there are N possible modules/drivers/switches, then there
are N**2 combinations to test, debug, and support. You can divide that
by some factor that discounts the obvious silly combinations, and that
factor can be made fairly large, but it's still a combinatorial
explosion that can only be attacked with real resources.

This particular user would prefer the development team be working on
security, stability, hardware support, and new features (perhaps in that
order). I would also prefer that the project work on breaking out of the
"old obsolete-for-Windows server repurposed as firewall" stereotype. SMP
and >4GB RAM are steps in that direction.

I could see an argument made for an exception for splitting SMP and
non-SMP kernels. What's the current thinking on that? (apologies if it's
in the archives).

- Marsh

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]