Skip site navigation (1)Skip section navigation (2)
Date:      27 Jun 2002 10:31:27 +1000
From:      Andrew Reilly <areilly@bigpond.net.au>
To:        Terry Lambert <tlambert2@mindspring.com>
Cc:        arch@freebsd.org
Subject:   Re: Where do you see FreeBSD in 10 years?
Message-ID:  <1025137887.15145.46.camel@gurney.reilly.home>
In-Reply-To: <3D06EBDC.99C72671@mindspring.com>
References:  <3D06EBDC.99C72671@mindspring.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Hi Terry,

Not many followups.  Did you get any direct responses?

I'm interested in the answers myself, so here's a few thoughts from a
non-developer but long-time BSD user ('85 or '86).

On Wed, 2002-06-12 at 16:36, Terry Lambert wrote:
> 1) Where is your "stake in the ground", your "line in the sand"?
>    What is your goal for the FreeBSD project?

I'm not sure that I understand the first question, but I'd like to think
that the second was something like: Be the most useful, reliable and
efficient way to use the popular computer hardware of the day.  (And
still freely available for any use.)
I would hope that the measure of FreeBSD's success would continue to be
based on internal consistency and equal measures of academic rigor and
pragmatism, rather than marketing-style dot-point competition with the
the alternatives (assuming that there are any).

> 2) Where do you see FreeBSD in 10 years?

In the pursuit of the aforementioned goal, I would hope that in those 10
years we would have comprehensively brought FreeBSD aka Unix up to date
with all of the good ideas from academic OS research: to be a truly
state of the art system.

A few dot-points along that path might be:

* sufficient modularity that the future FreeBSD can be one-size fits
all: swappable schedulers, authentication systems, user-land utility
sets.  Servers do (and will) run the gamut from single-processor
appliances to multi-processor enterprise behemoths, and I can't think of
a reason not to be suitable for them all.  Workstations are servers with
a graphics subsystem, so we should be able to do that too.  Modularity
might not ultimately prove necessary where a basic system can be made
sufficiently flexible all on it's own.

* I don't know how much distortion of the Unix mold this introduces, but
I would like to see mounting file systems, particularly remote ones and
dynamic ones (say on flash cards, or pluggable disks) be something that
user's can do, and that affect only that user (plan-9 style).  Perhaps
that is something that can be managed adequately in user-land libraries,
like the GNOME VFS stuff, or some future modification of automount but
that seems needlessly redundant.

* Of course the SMP scalability issue will be well-and-truly licked by
then, and FreeBSD will happily control 1000-node NUMA HPC racks as well
as more distributed systems, cluster-style.  This will have brought
hard-real-time capabilities with it, so that FreeBSD can be used in
medical, mechanical and other types of "equipment".

* I expect that NetBSD will be the first to bite this particular
bullet-point, but perhaps I can hope that by that time the systems will
still be sufficiently close (if not actually the same) that FreeBSD will
get this too: I expect that processor architecture is likely to
diversify, and for there to certainly be a diversity of instruction sets
in common use across the range of platforms.  I'd like to think that
FreeBSD could attract commercial applications, and expect that these
would be provided as binary executables.  It is still convenient to
supply pieces of FreeBSD itself as pre-compiled binaries (packages). 
Taken together, I think that this implies either an emulator framework
or (I would prefer) a TAO-style intermediate VM for distributed object
code.  Even pico-java or IA32 would probably do, and be useful in any
case.  Not sure why I like this particular idea, I just do.  I strongly
suspect that dynamic recompilation is going to prove necessary for
Itanium systems to be competitive in any case.  From the FreeBSD
perspective, this is really a tool-chain issue.  But it's one of those
issues that sits at the junction between OS and tool-chain: where do you
draw the line --- how much work does the linker/loader really do...

Oh, well, there's my ramble for the morning.

-- 
Andrew


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1025137887.15145.46.camel>