posted by Eugenia Loli on Mon 28th Apr 2003 15:48 UTC

"XFree86 issue, re-unification of the BSDs, UFS2"
10. What is the official position of the FreeBSD Project on a possible fork of the XFree86 codebase?

Scott Long: Until a release comes from the new fork, we have no official position. FreeBSD 5.0 will ship with XFree86 4.3 as it is the latest stable release of X.

WindowMaker under the stable FreeBSD 4.8 Wes Peters: We would have to consider that as a group. None of what I've written here is an official position of the FreeBSD Project, these are my ideas. We don't do position papers, as the Core Team is really just the 9 people tasked with keeping the project under control, not a true board of directors. The direction in FreeBSD is controlled by the people that contribute to the project.

As for my own opinion, forks can be good or bad. When the Apache team forked their codebase, it hardly raised a wimper; ditto for Samba. They were both done for the best of positive reasons, to rearchitect a system where the developers thought it was badly needed. We basically do this every time we create a new FreeBSD development branch, so FreeBSD has forked development at least 5 times already.

That said, if XFree86 forks because one of the developers can't get along with the rest, it rests on his shoulders to go forth and make a success of his project, whatever it will be. OpenBSD essentially started this way and the OpenBSD project has made many valuable contributions to the computing and internet society in general, and to FreeBSD in particular.

Greg 'groggy' Lehey: The FreeBSD Project does not have an official position on forks of other projects. In any case of a fork in a project from which we import software, we will evaluate the results and may end up supporting one or both forks. In the case of the XFree86 project, it would be difficult but not impossible to support both.

M. Warner Losh : I think most of the community is taking a wait and see attitude. FreeBSD has traditionally picked the best available technology for inclusion in the base system. At times FreeBSD has purposely lagged the latest release of X11 or gcc because newer versions had too many issue for too many of our user base. I suspect in the future we'll continue this tradition and base our releases on the best technology available, possibly giving our users the choice to use the one that best fits their needs. However, any fruit from this code fork is months away so it would be premature to make any judgements.

11. Suppose a complete fantasy world... how would you feel about a "re-unite" between the big three BSDs, FreeBSD, OpenBSD and NetBSD, under a common umbrella/project where each project would merge its best features to the common code?

Scott Long: This has been discussed many times over the years. Each BSD has its speciality, philosophy, and core developer personalities. The competition and cooperation amoung the three has been very productive over the years, and I expect it to remain that way. Several FreeBSD developers are also OpenBSD and NetBSD developers, so development is more united than it might appear on the surface. As long as each provides a niche and has developer and user support, there is no urgency to merge.

Wes Peters: The first task would be to determine if this fantasy land is paradise or just a branch of hell. ;^)

Your question again assumes this would be a positive output; I'm not certain of that. I think the best of the 3 projects, and many good ideas from Linux, are already shared. The level of cooperation has grown steadily greater over the years.

The differing focus of each of the 3 groups leads them not only to different solutions, but also to different problems. When one of the other projects discovers a similar problem, they have "prior art" to consider in formulating their own solution. In many cases, the code and ideas are shared, in some cases new solutions are attempted. The reasons for this can vary from the orignal solution not fitting well into the second system to wanting to create an independant solution to see if anything can be learned from the experience, or a better solution found.

Greg 'groggy' Lehey: I think a complete reunification would be a bad idea. Many of us are also contributors to the other projects, so it's not a case of NIH.
On the other hand, we see:

* Maintaining a big software project is difficult at a personal level. A lot of the core team's work involves settling disputes between developers. If we were to merge, we would almost double the size of the development team, and I would expect at least a fourfold increase in such disputes.

* I mentioned above the "strongest developer decides how to implement a feature" problem. One solution to this problem is to have multiple projects. NetBSD implements something one way, OpenBSD does it a different way, and FreeBSD does it a third way. At some later date we can then compare the success of the three approaches and then adopt the one we find best. This has happened a number of times in the course of the projects. If we were to merge, we would lose this advantage.

* What advantage would there be? There are dozens of different versions of Linux, many of them with user interfaces which differ more from each other than the BSDs do. There appears to be an advantage in diversity.

On the other hand, it is a good idea to maintain more consistency between the projects. We could do more to maintain a consistent user interface, for example. The problem there is not so much a matter of cooperation as a matter of the time it takes.

M. Warner Losh : I have lots to say about reunification. It sounds good on paper, but the people in the various projects makes this hard. FreeBSD, NetBSD and OpenBSD all smell different. Some people prefer one smell over the others. To make them all smell the same would be difficult, and I'm not sure completely desirable. The healthy competition between the groups helps foster innovation, and the code bases are close enough that people can pick and choose from the other project's work.

I agree that large chunks of userland could be common, but we lack the tools to make that happen. A number of attempts to make this happen have ended in failure for a variety of reasons.

12. A lot of people are asking us about the differences between UFS2 and XFS/Reiser/JFS and NTFS. What are the strong points of UFS2 against these other modern file systems of this generation and which are its weak points, technically-speaking?

Wes Peters: From my viewpoint, the strongest point of UFS2 is that it is based on code that is known good, and has been working in production for more than 25 years now. Some of the developers working on UFS2 in FreeBSD are younger than UFS. This is not to imply that UFS2 was gifted to us from on high, perfect in every way, but the path has been far less rocky that I expected.

I attribute a lot of the development effort thrown into XFS, ReiserFS, JFS, and others in Linux to the weak feature set of ext2. FreeBSD saw a lot less interest in such "advanced" filesystems because UFS + softupdates was already working in FreeBSD by the time ReiserFS became usable in Linux, and UFS + softupdates was "good enough" for most needs.

Others here who are more knowlegable about filesystems can give you a more detailed, feature-by-feature comparison if that's what you're looking for.

Table of contents
  1. "Intro, Java, Corporate Support"
  2. "Linux, the desktop market"
  3. "Maturity of 5.x branch, speed of development compared to Linux"
  4. "How FreeBSD compares to other Unices"
  5. "Bug resolution, team work, graphical installer"
  6. "Optimizations, SPARC/PPC/Itanium/Opteron ports, third party tools"
  7. "XFree86 issue, re-unification of the BSDs, UFS2"
  8. "The SCO questionmark"
e p (0)    94 Comment(s)

Technology White Papers

See More