Re: Pkg-based base system.

Gary W. Swearingen wrote:
> Johan Pettersson <manlix_at_demonized.net> writes:
> 
> 
>>>| Wouldn't it be nice to have ha pkg-based base system? 
>>>| So you easily can remove parts from the base system, like 
>>>| openssh, ipfw, ipf, bind, sendmail and so on. 
>>>| This couldn't be too hard to implement. :)
> 
> 
> Apparently it IS too hard, so let's dream of a system even harder to
> implement.  Someone should (sic) do it so well and so flexibly that
> almost all BSD users will want to use the same base system for which
> they will select their favorite BSD kernel (eg, FreeBSD's or NetBSD's)
> and their favorite applications (eg, one each of the most popular
> MTAs, firewalls, and CD burners), so that we don't have four or more
> teams maintaining and documenting a similar userland, while having the
> many people interested in kernel development able to continue their
> rather separate innovations.

I think that you are missing a key point here.  FreeBSD is an operating
system.  It is not a kernel with interchangeable userland pieces.  It is
not designed that way, and frankly that is one of it's strengths.  It is
an integrated system that has defined pieces in defined locations that
work together in a defined way.  When one BSD has something that another
BSD wants, it gets ported and integrated.  I understand that this is
quite a bit different from the Linux model that you are advocating, but
not all the world has to follow in the footsteps of Linux.

> 
> That's my ideal.  I'm afraid that the reality will be that as Linux,
> Sun, MSFT, and even Apple further dominate "the enterprise", the BSDs'
> market/mind- share will make a serious decline as its developers
> retire and move on to what's left in the enterprise, except that
> NetBSD might manage a significant chunk of the embedded OS niche
> (where Linux suffers from copyleft and a harder-to-port design) and
> might even continue as a development platform for itself.  To
> facilitate the later, it might help to take over FreeBSD's userland,
> taking advantage of FreeBSD's better userland documentation.  (No, I
> don't know how hard THAT would be.)

Linux will rise and fall on it's own, as will Windows.  MacOS has been
around in some incarnation longer than both, and BSD has been around
longer than MacOS.  As long as BSD has interesting and compelling
features, it will continue to exist and be used.  In the case of
FreeBSD, the compelling features have changed over time, and we need
to recognise that we need to continue to innovate and not stagnate.
However, this has little to do with the press covering every little
sneeze that Linus Torvalds or Bill Gates makes.  Frankly, it's not a
contest to be #1.  It's an OS that is interesting to work on and useful
to use.  If you want a contest, please consider Linux.

As for compelling features, we do need to focus a bit.  Right now,
FreeBSD has several good and bad things going for it:

Good:
- Jails
- Choice of full featured firewalls
- TrustedBSD/MAC/ACL
- Mature AMD64 support


Bad:
- No journaled filesystem
- 4.x branch is stagnant, 5.x branch is not up to production standards
yet.


We need to address these soon.  With disk storage capacity booming, we
can't squeak by without a journaled filesystem any more.  FFS snapshots
and background fsck looked promising but really haven't panned out.
Whether this need is satisfied by porting XFS/Reiser/JFS or adding
journaling onto FFS is not important.  What is important is that we
have a production quality FS within the next year.

5.3 is looking to be a very good release, assuming that no regressions
pop up.  On the network side, we'll have the entire IPv4 stack 
multithreaded, and maybe more.  Lots of other MPSAFE work is going on 
too, so I expect 5.3 to be a huge jump in performance.  I'm excited for 
it, and I think that it's only going to improve after that.

But we still can't just sit around and stagnate.  Here is a list of 
broad items that really need to be addressed in the next 12-24 months:

- Journaled filesystem
- iSCSI and SAS support
- IPv6/KAME update
- PCI-Express support
- Improved PCI and system resource allocation
- Modern installer and unified configuration framework

I also think that we should start looking at some more embedded 
appliance areas.  I'm not terribly interested in pursuing the
leaner architectures like ARM and MIPS, though having these would
be interesting.  Instead, I'd really like to see us work on some
of the higher-end PPC embedded platforms like the IBM G4xx series.
With Wasabi being aligned to Intel now, this is a perfect area to
grow into.

Scott