From owner-freebsd-current@FreeBSD.ORG Fri Apr 9 07:11:21 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E5DB116A4CE for ; Fri, 9 Apr 2004 07:11:21 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4A37643D58 for ; Fri, 9 Apr 2004 07:11:21 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.10/8.12.10) with ESMTP id i39EAtPq063327; Fri, 9 Apr 2004 10:10:56 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i39EAtiS063324; Fri, 9 Apr 2004 10:10:55 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Fri, 9 Apr 2004 10:10:55 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Atte Peltomaki In-Reply-To: <20040408224527.GA8299@norsu.kameli.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org Subject: Re: Future of FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2004 14:11:22 -0000 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@ 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@fledge.watson.org Senior Research Scientist, McAfee Research