> 	The > 2G drives are rapidly coming down in price. I can see within a
> 	year where it would be possible to need such a thing.

Hey, even if so, wouldn't you rather make several partitions on such a drive?
Anyway, I still think this HAS to be an option, only a (small) minority  of
our user base will ever face such decisions...

> 	As far as size bloat, how about waiting to see what it actually is?
> 	Not everything uses off_t type...

Actually, for me it's even more an issue of software compatibility
(I'm not even talking binary compatibility for a change:-)), the
current system is very handy to compile all sorts of available
sources, without having to dwelve into each and every source file to
"fix" some incompatibilities (howdy solaris 2...). I don't want to
lose this state. This (my) goal *might* be contrary to goals of other
NetBSD communities.

> 	Let's see what the actual result is before throwing it out.

Sure, just make the extension conditional...

> 	I personally am against changing the default on something this
> 	fundemental vs the other NetBSD ports. This is supposed to be

I don't rate it THAT fundamental, it is one aspect of 4.4, nothing more.

> 	NetBSD after all. Will we also not add in the other 4.4 changes
> 	that all the other ports will have (and will no doubt add bloat to
> 	the kernel)? If it's to be called NetBSD then it should have all the

My opinion here is: look at each feature, rate its usefulnes, what
will it add to the system, what are the drawbacks. If the pros
outweight the cons, go for it, if not, nuke it. I don't care VERY much
about the name of the resulting system, I think it would be nice if we
could continue the very close relationship to the other ports, but I
(with my very own personal kernel :-)) will probably go my own way if
NetBSD was to develop unconditionally into 4.4. Since we have source to
all systems, this decision doesn't look as tough to make as if we'd be on
a binary-only dependency.

> 	features and functions that all the other ports have. If not then
> 	start a new BSD, like the FreeBSD and 386BSD people have.

That would be the easiest solution, but I'm optimistic for now that perhaps
there is a less drastic solution? Easy solutions are rarely optimal.

I'll be away for the next 4 weeks, I'll try to read some mail during that
time, but I can't guarantee.

-Markus
-- 
CHUUG/EUnet Switzerland				Markus Wild
Zweierstrasse 35	Tel: +41 1 291 45 80	mw@eunet.ch
CH-8004 Zuerich		Fax: +41 1 291 46 42	S=mw;P=EUnet;A=EUnet;C=CH

------------------------------------------------------------------------------