Date: Tue, 6 Jan 2004 14:22:29 -0500 (EST) From: Robert Watson <rwatson@freebsd.org> To: Paul Robinson <paul@iconoplex.co.uk> Cc: freebsd-chat@freebsd.org Subject: Re: Where is FreeBSD going? Message-ID: <Pine.NEB.3.96L.1040106134840.87887B-100000@fledge.watson.org> In-Reply-To: <3FFAF1D4.4000709@iconoplex.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 6 Jan 2004, Paul Robinson wrote: > And therein lies a problem. The only thing any of the committers cares > about is what they think. Got a problem? Submit a patch. Don't like the > way things are done? Submit a patch. Don't like how such-and-such a util > works? Submit a patch. While it's clearly the case that many people have met with the "submit a patch" response, that's probably more a property of time constraints from developers than a lack of desire to work with users to produce a system users want. Many FreeBSD developers find FreeBSD of particular appeal because it gives them a chance to produce a system they've always wanted to use: one that addresses the frustrations of many other systems out there. For example, a fair number of FreeBSD developers have their time funded by Internet Service Providers who appreciate the scalability, performance, and mangeability of FreeBSD when deployed on tens of thousands of machines. They bring changes to FreeBSD regularly reflecting those needs. Many FreeBSD developers do hang out in the public IRC channels and try to answer questions, hang out on questions@, stable@, etc. Sometimes, you post a question and get the answer "That doesn't work yet, but we're looking for a few good developers...", but frequently, you also get a patch and "If you could try this and see if it helps with your problem..." Obviously, the harder question you ask, the more likely you'll get "We're looking for a few good developers..." :-). The marketting department of Microsoft may be able to keep their less user-friendly developers from talking to their users, but many people would argue that one of the greatest benefits of open source is increasing that communication, even if it means the unwashed developers talk to real people once in a while. A great many developers pick FreeBSD to work on because they're quite aware of what users of other systems have to deal with, and want to produce a system people can use. But no one is paying the bills for hand-holding, so unless people step up to do the hand holding (thanks greatly to those who do!) it's not going to happen. We'd appreciate your help in making it happen, if that's something that strikes you as done wrong or poorly. As with any commercial software development enterprise, we also have limited resources, but unlike a commercial software development enterprise, we can help involve a much larger community in building and supporting a product. > Personally, unless the madness around SMP, the 5- branch and various > other bits are ironed out, I can see my next server deployment making > use of DragonFly. At least they listen to people who don't submit > patches due to the limitations of time/skill/whatever. No, I'm not a > Matt fan - I like and respect most on -core and others. I just think 5- > has got... well, it's all a bit out of hand really, isn't it? The reality is that operating system development takes a lot of time, energy, and expertise. We can't pull a next generation operating system out of hats overnight -- it takes literally hundreds of man years of work to do. It's not something one, three, or even ten people can do alone. FreeBSD 5.x remains a work in progress, but has made a lot of progress in the right direction. I think what you think of as "madness" is a necessary step on the path of a major engineering project. I can't think of any major project I've seen where at some point, people haven't taken a pause for a breather saying "Oh my god -- what have we gotten ourselves into". On the other hand, I think referring to it as "madness" dismisses years of hard work by a great many competent and dedicated developers. A year ago, M:N threading was extremely far from productionability -- today, it's on the cusp of being there, with higher performance and increasingly high reliability. It's almost ready for 5-STABLE. There's substantial on-going work on SMP, with a huge investment of time and energy into the network stack, VM system, VFS, process support, scheduling, etc. These are areas where the primary feedback today is going to be "stability and performance", and believe me, we're listening. All the FreeBSD developers I correspond with regularly run FreeBSD 5 on their desktops, on their servers, in their appliances, etc, to make sure we keep shaking out problems. Many companies have production products based on 5.x, and their feedback (and contributions) have been valuable. We've also invested substantial efforts in areas like compiler toolchains, standards compliance, not to mention new features. 5.x is, at long last, starting to land; it will take about one more minor version number to get there, we believe, but it is in dramatically better shape than it was a year or two ago. As I said above: writing operating systems isn't a small task. Companies invest tens (hundreds) of millions of dollars writing and maintaining operating systems, and (net across developers, if you actually bill for the volunteer hours), you're probably talking about the same. I think it's disingenous to dismiss the level of work put into FreeBSD 5.x -- this stuff is hard, folks! > All they had to do was ask a few sysadmins and end users what they > thought. All of this could have been avoided nearly 2 years ago. FreeBSD consumers asked for high performance threading, better SMP support, features like NFSv4, the ability to run without fsck, better security, NSS, and better C++ support. FreeBSD 5.x provides many (all?) of those. The biggest problem with FreeBSD 5.x was biting off a lot, not biting off enough. We looked at the large set of desirable tasks, and to some extent gotten bitten by the change in economy. It's easy to look back in retrospect and say "well, maybe a bit more investment here, and a bit less there", but it's a lot harder to make the changes after hindsight kicks in. The FreeBSD Project has changed the way we've developed as a result of lessons learned: we aren't introducing major new features at this point, with almost all major development in the "honing" department, currently. And that's chafing too: many FreeBSD developers like working on FreeBSD as an opportunity to create Big New Things, and want to keep doing that at a time where we're putting the breaks on Big New Things to produce a productionable result. But I guess that acts as motivation to get the current set of tasks in the air landed well :-). Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Senior Research Scientist, McAfee Research
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1040106134840.87887B-100000>