Re: Future of FreeBSD

On Thu, 8 Apr 2004, Atte Peltomaki wrote:

> As an active FreeBSD user, I'm ever so interested about the future plans
> of FreeBSD and direction of developement. Many of the features that 5.x
> taunts are very impressive. But as of late I have been increasingly
> worried about the direction (or, lack of direction) things have been
> going.

I'm not sure I see the same lack of direction.  The stated goal of the
project in the short term is to continue to support 4.x in a stable
production model, complete moving FreeBSD 5.x branch from an agressive
development model to a stable production model.  There are also a number
of longer term goals for the 6.x branch that have been brought up in
various forums, including the arch_at_ mailing list.  While the 5.3 release
TODO list is a bit stale, the objectives are fairly clearly understood and
being actively chased.  The FreeBSD Project has always been a little poor
at communicating the details of its status to the public, but if you
haven't seen our recent developer status reports, I think you might want
to take a look at them since they show a lot of material progress towards
these goals. 

> Departure of Jordan and Greg. Jordan said it's not fun anymore. Is the
> strive for new features driving developers past their limits, or has jkh
> simply gotten old? Also kicking out Dillon, a very talented and active
> programmer, didn't look good at all, especially when it went down
> completely without any explanations to userbase.

The reality is that developers move on.  Jordan had worked on FreeBSD for
what must have been going on 8 or 10 years -- are you saying that in that
time he shouldn't consider a career change?  He's at a company that is
actively adopting FreeBSD technology into a mainstream workstation
product, and I don't think we can fault him for that.  If anything, it's
an example of how companies can adopt FreeBSD to build their own products
and succeed at doing it.  Greg indicated he left the core team so that he
could spend less time on administrative issues, and actually get some
coding done (and on FreeBSD, no less).  Can we fault him for that? 
Admittadly the Matt issue was a PR debacle.  We should have started up
front why we felt Matt should leave the project; instead, it trickled out
later.  As I said, though, PR hasn't been a FreeBSD strong point, and we
certainly learned from that lesson.  Part of the reason for it not being
handled well is that, to be honest, is that most people leave the
committer team on fairly good terms, so we don't have a whole lot of
experience with people leaving on less good terms.

> Stability of 5.x: from my point of view, the 5.x series, although
> including a lot of very fancy work in many areas, is nowhere near the
> reliability you'd expect from a stable FreeBSD release. Originally 5.x
> was due to go stable in the beginning of summer, are there any new plans
> made yet?

We're still talking about "During the summer", but the date will depend
the technical work being done.  We don't want to release anything
prematurely -- the reputation of the project is based on our meeting
expectations about performance and stability, and frankly, we'd like to
keep those expectations.  Remember, this project is staffed almost
entirely by volunteers, and in the end, we have to work around a lot of
realities: the job market, committers getting married or having children,
etc.  On the other hand, we're no different than most commercial software
companies in this, and commercial software companies notoriously slip
deadlines, so perhaps that's just the status quo for industry.  I'm trying
to remember the last time I heard about an on-time software release of a
major product.  In fact, many companies don't publish release schedules
for that very reason :-).

> Feature-wise: things simply don't seem quite ready. ACPI breaks every
> other box,

This seems like an extreme characterization.  My experience is that ACPI
works imperfectly on older machines, often due to bugs in the BIOS's of
those machines, and works a lot better on most new machines.  Upgrading
the BIOS's on older machines (often required to run any recent operating
system) often corrects most of the problems, since recent BIOS's are
intended to run with Intel's reference ACPI implementation (which we use). 
And we're not the only system that has problems with ACPI -- Windows does
somewhat better, but is the source of many of the problems for us, and
newer versions of Windows face many of the same challenges.

> ULE is still not SMP aware,

This is simply incorrect.  If anything, ULE is extremely SMP-aware.  It's
even aware of non-symmetric topologies, such as found with hyper-threading
and more NUMA-like amd64 systems.  My experience has been that ULE is
still reaching maturity -- it schedules some things much better than the
4BSD scheduler, but other things slightly less well.  One nice thing about
our current system is that you can choose the scheduler to use -- you can
even write a new one and plug it into the pluggable scheduler interface,
something which makes it easy to experiment with changes in scheduling,
and allows us to explore more experimental scheduling approaches.  The
reason ULE is now the default in -CURRENT is to increase exposure through
much more broad testing.  If you notice specific negative performance
differences between 4BSD and ULE, a careful characterization of the change
in a PR would be extremely helpful.

> Giant is far from being completely removed and so on. 

This is a work in progress, but it's something that's being worked
extremely actively on.  You should see substantial progress in the near
term.  Some aspects of this work are, of course, going to remain a
long-term project. 

> Yet, all these features have been presented in the media long ago,
> giving the impression they would be ready (soon). 

Time is a funny thing in the world of computers: people think it runs on
an extremely short schedule, but the reality is there's simply a lot going
on.  If you don't think a year is "soon", then you don't live in the same
world I do.

> Now, I'm not trying to pick a fight with anyone. I just want to talk
> about things with their real names. And when things are going bad,
> things are going bad and calling shit on one another ain't gonna make it
> one bit better. I would dearly like to hear an honest opinion from
> someone who feels he knows what he's talking about, against my feeble
> knowledge over much anything. And I would really like to see FreeBSD get
> a grip again, put the media behind it, see what's real and attainable
> and go an' do it, and as a user I will do what I can to assist.

I'm not convinced things that things are as bad as you think; however, I
agree with your general assertion that we don't present our project to the
world in its best light.  We need to do a better job at promoting our
system, and improving communication about the hard work we're doing.  We
also need to do a better job at highlighting some of the pretty cool
places FreeBSD is used -- take advantage of the clear confidence many of
our consumers have in our product.  Do you have some specific and concrete
suggestions about how we might do this better, other than that we update
the release engineering todo lists a little more?

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert_at_fledge.watson.org      Senior Research Scientist, McAfee Research