Focus on FreeBSD: Interview with the Core Team

By Eugenia Loli-Queru
OSNews.com

April 28, 2003

Today we feature an in-depth interview with three members of FreeBSD's Core (Wes Peters, Greg Lehey and M. Warner Losh) and also a major FreeBSD developer (Scott Long). It is a long read, but we touch a number of hot issues, from the Java port to corporate backing, the Linux competition, the 5.x branch and how it stacks up against the other Unices, UFS2, the possible XFree86 fork, SCO and its Unix IP situation, even re-unification of the BSDs. If you are into (any) Unix, this interview is a must read.

Intro, Java, Corporate Support

1. What is the status of the Java 1.4.x port to FreeBSD? How has its absence impacted FreeBSD's market penetration? (Editor's Note: Java patchset 3 for BSD was just released)

Scott Long: Several months ago the FreeBSD Foundation funded a contract to bring Java 1.4.1 to FreeBSD. Unfortunately, the process of gaining certification from Sun is quite lengthy, and the money available for the contract ran out before it was complete. Still, the work that was done is quite impressive. Most users have reported that it is relatively bug-free for common applications like tomcat, and some have also reported that it is measurably faster than the Linux version. It is even in production use by a very large internet portal company. The FreeBSD Foundation is currently working to raise funds to complete the contract and have it certified by Sun.

Wes Peters: The current status has been answered well by Scott Long.

As for the market penetration, the only possible answer is "we don't know," at least partly because we don't have a marketing department. I know of a few embedded development firms who use FreeBSD and Java successfully, but cannot comment on how they use it or on their performance needs, etc. I and a number of other developers are very much looking forward to being able to distribute Java 1.4.x in binary, but in the meantime the source distribution works well.

Developments in FreeBSD 5.x may have a strong positive effect on the performance of Java threads once we have time to sort out the interactions between the JVM and the new threading capabilities found in FreeBSD 5, but this work will be completed after the 5.1 release.

Greg 'groggy' Lehey: It's interesting that this is your first question: I would have considered it relatively uninteresting.

M. Warner Losh: I find this answer a little rude.

Greg 'groggy' Lehey: Scott has described the status. As others have said, it's difficult to assess the impact, but I would suspect that Sun's current licensing strategy would have more of an effect on the use of Java under FreeBSD: it's a real pain just getting the software. Possibly Linux users are more accustomed to jumping through hoops to get software installed, but FreeBSD users expect to be able to type 'make install' and have things done automatically. Sun's licensing conditions make this impossible.

2. A few years ago, companies like WindRiver/BSDi were helping out the FreeBSD project in many ways, including PR, handling relationships with other companies regarding drivers, etc. Now that the FreeBSD project is completely autonomous, how do you handle these issues? PR, tech specs for drivers that might require NDAs (e.g. an ATi/nVidia relationship) etc...

Scott Long: The loss of corporate backing from BSDi has slowed FreeBSD down without a doubt. Without a central focus point anymore, FreeBSD has relied on a more distributed set of backers. This includes NAI Labs, Yahoo!, The Weather Channel, and Apple, among others. They have provided employment for key developers, helped coordinate NDA deals with other companies, and donated server space and bandwidth to the project. Our experience with PR issues is also growing over time and we hope to make a good PR splash with the 5.1 release.

Wes Peters: Scott also answered this quite well. I want to note that FreeBSD was not ever a "division of" BSDi, or Wind River, nor was it ever a product of either of those companies. It is inaccurate to say that FreeBSD is *now* completely autonomous; it always was. I hope your article reflects this point.

BSDi (and Walnut Creek CD-ROM before it) were quite helpful to the FreeBSD Project in many ways; it's not clear (to me) that Wind River ever helped in any meaningful way.

Greg 'groggy' Lehey: This is an interesting perception. We never felt more or less autonomous. Yes, different groups have supported us; before WindRiver it was Walnut Creek CDROM, and now FreeBSD mall, which you could consider a successor to Walnut Creek, is doing the same thing. There are also many others.

M. Warner Losh: FreeBSD has grown beyond the one company that nurtured it in the old days. FreeBSD gets much of its development done via different kinds of funding, but from the private and public sectors. My current employer, for example, allows me a certain amount of time each month to work on FreeBSD bugs that impact our ability to deploy a system. These get fed back into the base FreeBSD from time to time. Many other people are in a similar situation.

Greg 'groggy' Lehey: The FreeBSD Foundation handles these issues. You might like to get in touch with them. See here [ http://www.freebsdfoundation.org/ ] for further details.

I note that my reply to this question contradicts Scott's. Perceptions obviously play a role here.

M. Warner Losh : I disagree with Greg here. Most of the time when there are NDA issues, individuals will enter into agreements with the companies in question, or it will be done through their current employer. We've had a number of drivers contirbuted by people who had inside access to information. Some of these were done on a individual basis (much of my work on the wi driver for Prism II, 2.5 and 3 chipsets was based on an NDA that I have on file with Intersil, for example). I know that the nVidia stuff was done under contract with one of the developers, but the FF wasn't in the loop on that.

Greg 'groggy' Lehey: However, a lot of people are motivated more than by money to work on FreeBSD. It is their hobby or passion. They find an itch to scratch using FreeBSD and FreeBSD benefits.

Linux, the desktop market

Scott Long: GNU/Linux actually got its first PR win with the USL lawsuit in the mid-1990's. That drove an unbelievable amount of momentum away from BSD and towards Linux. In light of that I think that it's a testement to the quality of BSD in general that FreeBSD, NetBSD, and OpenBSD have remained viable and interesting.

I think that Max OS X has really set the bar for what Unix can do on the desktop. FreeBSD is just as capable as Linux as a desktop OS, but I think that OS X has reminded us that making a desktop OS with mass appeal is a huge task and that FreeBSD should still concentrate on its other strengths as a server OS.

Wes Peters: Most FreeBSD users use FreeBSD on their desktops daily; I have for just about ten years now. I don't know that we have the same drive our friends over in the Linux camp have to rule the world, we just want to make a system that works well for our needs.

To some extent the BSD world in general has already conquered the desktop in the form of Mac OS X. It's a very good product; it has all of the wonderful strengths of BSD and UNIX underneath, and has an unaparalleled user interface and world class applications on top. To many in the BSD world, OS X freed us from any need to become the desktop to the masses; we can concentrate on making a really good technical workstation for users that are comfortable with the X Window System, window managers, and such, and let Apple pick up those who specialize in something other than computers for a living.

I've been a part of the FreeBSD Community right from the start; I downloaded the 1.0 distribution onto floppies the night it was released. In the ensuing ten years the issue of making FreeBSD the operating system of choice for everyone has rarely come up, and when it has it's been mostly ignored.

This doesn't mean I don't think it's suitable to be a commercial operating system. Whatever pretty face your Linux distributor throws on top of Linux will run just as well on FreeBSD. The graphical installer might make a bit of difference, but the key to becoming a commercial operating system is not to have a nice graphical installer but rather to get IBM, Dell, HP, and Gateway to pre-install your OS on their hardware. Without the kind of financial backing that RedHat provides for Linux, that's not likely to happen to FreeBSD anytime soon. It's only just barely happened with Linux, in terms of shipping volume. Better operating systems than Linux or Windows have died on the cross of getting support from just one vendor, BeOS being the most recent visible victim.

Greg 'groggy' Lehey: There are a couple of issues here:

1. Linux and FreeBSD both separate the operating system from applications software, including the concept of a "desktop". The applications layer on Linux is usually identical to that on FreeBSD, so from that aspect you should expect to see no difference.

2. What is a "desktop"? There has been a lot of effort in the Linux space to duplicating Microsoft functionality; see OpenOffice for a good example. FreeBSD also supports OpenOffice. The real question, though, is whether we're doing anybody a favour by copying Microsoft. Like Wes Peters, I have been using BSD on the desktop for well over ten years. I find the current crop of "desktop" software incredibly difficult and frustrating to use. I am forced to do it from time to time, but it's both limited and limiting in its approach. The BSD community should be working towards a better alternative, not playing copycat.

As regards ease of use on the desktop, consider: recently, the Australian UNIX User Group (AUUG), of which I am currently president, participated in a seminar by the Australian Government. We supplied all delegates with a CD-ROM of OpenOffice for a number of platforms, including FreeBSD, Linux and Microsoft. It proved to be easiest to install the FreeBSD version of OpenOffice. Linux required significantly more work.

[quote]Geeks and developers don't mind extra complexity or unpolished desktops or different toolkits that all look different and inconsistent. [/quote]

I contend that geeks and developers would also prefer a consistent and tidy approach. The question is, why do so many choose not to use the current "desktop" software?

I most certainly see KDE and Gnome as issues. On the face of it they should make life easier. On several occasions I have attempted to adopt one or the other. The real issue is this term "desktop". Both KDE and Gnome give you a set of tools, some of them good, which fit together. They don't make it particularly easy to do things that the developers didn't think of.

I recently investigated desktops in some detail for my book "The Complete FreeBSD"), which will be on the bookshelves in the next few weeks. I had intended to describe only one desktop, and spent some time trying to decide whether it should be KDE or Gnome. For whatever reason--exhaustion may be part of it--I chose KDE.

At the same time I rebuilt an old machine and installed KDE and OpenOffice on it. I had two intentions here: first, a neighbour needed a newer computer, and secondly I wanted to be able to describe first-hand how to use the software. The machine wasn't very fast (233 MHz AMD K6, 96 MB RAM), and the results were painful: KDE needs more memory, and preferably a faster CPU.

Just to get the thing to run at any speed, I installed fvwm2 and discovered that, apart from flashy graphics, it wasn't missing too much. My neighbour is completely non-technical, and I gave her the choice of which to use. She chose fvmw2. As a result, I added a section on fvwm2 to the book, as an alternative to KDE.

I could go on on this topic for hours, but that's probably enough.

Maturity of 5.x branch, speed of development compared to Linux

4. FreeBSD 5.0 has come out, and while this was mostly a "preview" of sorts, many were unhappy with the instability and slowness the 5.0 release offered compared with the 4.x branch. With Linux getting many advances in its kernel due to help from engineers working at big commercial companies like IBM, Red Hat and SGI, how do you feel your roadmap is holding up against the competition? Do you believe that a (mostly) commercial engineering-free project can pull out advancements faster than the Solaris or Linux teams can today?

Scott Long: The major focus for FreeBSD 5.x has been reworking the SMP capabilities of the system. This task has been huge and is largely the cause for the delays that 5.0 experienced. However, as more subsystems and drivers are converted to use it, we feel that the result will be faster and more scalable than what is available from Linux. There are also two related projects that will provide vastly improved threading support to applications, and will hopefully be another reason for people to look at FreeBSD.

While a lot more development money may be going into Linux right now, FreeBSD is helped by the 20+ years of development and maturity that the BSD base brings. Companies like NAI Labs also greatly help out by funding projects in the enterprise, stability, and security spaces, so FreeBSD keeps on advancing and setting the bar for others to follow.

Wes Peters: It's hard to understand how they could be unhappy with something they had been warned about for months before the release.

It's not clear that Linux and FreeBSD are in competition with each other, other than in editorial opinion pages. We have clear evidence that in many cases they are complimentary to each other, and numerous clear cases of cooperation, especially in the application world.

It's also important to note that development of FreeBSD isn't driven by sales, it is driven by what the FreeBSD developers want it to be. There is an assumption in your question that the influx of paid development has been good for Linux; I know many long-time Linux developers who feel this is most emphatically not the case. Paid Linux developers are paid to develop what their employers want, not what is best for the Linux system at this moment in time. The involvement of so many different entities is pulling Linux in many directions, it remains to be seen if the commercial success will make it a better system.

This certainly happens to some extent in the FreeBSD world; some of my own contributions to FreeBSD are for features my employer(s) have requested. The difference is on the emphasis.

Greg 'groggy' Lehey: While we expected this, I haven't heard any concrete reports. We warned people about this issue, so it's hard to understand why they should be disappointed, unless they didn't want to believe us.

I personally also think the slowness and instability are exaggerated. I've been using both release 4 and release 5 on my personal desktop systems for a couple of years now, and I don't notice significant differences in stability or performance.

M. Warner Losh : I've done benchmarks that show that 5 is slower than 4 in a number of areas, but the biggest one is gcc. gcc 3.2 is a lot slower than 2.95, but it produces better code more of the time. That's one area where the system will feel slower to developers. Interactive performance is about the same on my laptop booted 4 as it is in 5.

Some people that are trying 5.0-current will notice things are slower because more debug options are turned on by default. We tried to clear most of them for the release, but maybe one or two snuchk through.

Greg 'groggy' Lehey: Until recently my day job was working on Linux with one of those [commercial] companies, and I spent a lot of time looking in the Linux kernel. Yes, it's getting better, but I think it will be some time yet before it overtakes FreeBSD. I'm certainly very happy that I no longer have to work on Linux.

[Do you believe that a (mostly) commercial engineering-free project can pull out advancements faster than the Solaris or Linux teams can today?]

No. Agreed, that's a distinct disadvantage.

M. Warner Losh : It makes things riskier in a lot of ways. There's a lot more chance and projects go awry for the strangest of reasons. When there's money involved, the project will get done, but the quality may or may not be high. Such is the nature of the power relationship between employer and employee, and work for open source is no different than work for other areas. When it is done because of the passion, it generally turns out better, people tweak it more, but it has a higher risk of not being finished. And timeline tend to be more predictible in compesnated realm than in the uncomensated. So having big money behind you is a mixed blessing.

How FreeBSD compares to other Unices

Scott Long: Linux development is so quick and scattered that it's hard to assess many of its technical merits. The strict social hierarchy in Linux often forces changes that are either large or are from 'unknown' developers to be kept outside of the main Linux development stream, making the work of developers and integrators harder. FreeBSD, OpenBSD, and NetBSD have a much lower barrier for entry for developers in that the official source trees are publically availalbe via CVS, and there are many more developers with CVS commit access that can funnel in changes.

FreeBSD has traditionally excelled with it's VM, SCSI, and network subsystems. The lack of a journaled filesystem is seen by some as a shortcoming, but UFS2 with softupdates and background checking solves most of the problems that journaling filesystems attempt to solve. This particular area is very polarized, though, and it should be noted that efforts are also underway to port the SGI XFS to FreeBSD.

Wes Peters: Against IRIX and AIX, it's a no-brainer. Those systems are staring at an open grave. IBM and SGI have obviously switched horses; their marketing releases are attempts to placate their current customers while they come up with a migration plan better than "buy Sun now."

One of the biggest advantages of FreeBSD over Solaris that may not be mentioned by others you are interviewing is the FreeBSD Ports system. There are currently more that 8,000 applications, development tools, and other software packages that you can install on a FreeBSD system by simply asking for them. The amount of work that has been doone in creating and maintaining this system is incredible, and it is one of the crown jewels of the FreeBSD Project.

Against Linux, the situation is different. One of the problems in the Linux world is perhaps too much choice. With nearly 200 different distributions of Linux, each going in different directions, it's hard to know where to go to get what you need. The applications can be difficult to find; you'll come across an app that looks like exactly what you need, only to find that the developer hates whatever distro you're using and only makes packages for a different distro that is almost but not quite compatible with what you've got.

Yes, these are technical issues. Having two major packaging formats, a number of major distributions, all with differing sets and releases of critical libraries, is a management nightmare nobody really wants to tackle. This is why everyone that goes with Linux picks one distro and makes it an organization standard even if it's not the best.

FreeBSD is a *system*, not a kernel with a bunch of other stuff thrown on top to make a "distro." The kernel, userland programs, libraries, booting system, etc., are all tested together to make a release that's known good. Our backwards compatibility has remained quite good as well; a number of commercial vendors have FreeBSD 3.x and even 2.x binaries they still sell today because they don't need to change the executables.

Greg 'groggy' Lehey: I can't think of a way to answer that question in a few sentences. Firstly you need to distinguish between UNIX and Linux; under the hood the UNIX kernels and FreeBSD are very similar, while Linux is very different. A few thoughts:

compared to UNIX:

* FreeBSD has much tidier source code and fewer crocks. Hardly anybody sees UNIX source code, and keeping it tidy is expensive, so big companies don't go to great lengths to do so. FreeBSD code is kept tidy by a number of beginning kernel coders who pride themselves on the neatness of the result.

* At the other end of the scale, we haven't made as much progress as we would have liked with pervasive kernel changes such as SMP and kernel threads. This is probably a direct result of the open source development methodology, which is not as rigorously structured as in closed source projects.

M. Warner Losh : I'd agree on the threading issues, but much progress is being made there, but disagree with you on the SMP area.

Greg 'groggy' Lehey: compared to Linux:

* FreeBSD is a tidier system. You "know what you have". If I say "I am running FreeBSD 4.8-RELEASE", I define exactly the system I am running. Currently, there is no way to say something similar about Linux. You can say "I am running Red Hat 8.2", but if you have built a new kernel, that no longer applies. You would at least have to say something like "... with kernel 2.4.20". Every time you add software to a Linux system, you have (to make) a choice of where to get it from. With FreeBSD, you install nearly all software from a known place (the Ports Collection) in a defined manner. This makes bug fixing much easier.

* Independently of the issue of how Linux gathers its system components, you have the choice of distribution. The tools in one distribution may be completely different from those in another, and the configuration files might also be completely different.

* In my experience, Linux is not as stable as FreeBSD. I run a couple of Linux systems in my home network, and though they don't have much work to do, they tend to have software problems which require rebooting much more often than the FreeBSD systems. One machine regularly has hangs in the IP stack due to what look like memory leaks. From my last job I know a number of high-profile Linux hackers, but none have been able to help diagnose the problem.

* Linux is probably ahead in the issue of SMP support. Numerous people are working on such projects. But where do you see the results? Most such work that I know of is "bleeding edge" and hasn't yet found its way into Linux distributions.

Bug resolution, team work, graphical installer

6. Which are the hardest parts during the resolution of the architectural or coding bugs in the 5.x branch? How many people are working in the 5.x branch these days?

Scott Long: The hardest problems have come from mediating two solutions to the same problem that take competing directions. We formed a Technical Review Board last fall that is chartered to resolve these kinds of disputes and help set future technical direction. Luckily, these problems rarely happen, and the issues they bring up are valuable and help us grow.

Wes Peters: Keeping all the various development projects moving and from bumping into each other. This is no different than any other software engineering project involving hundreds of developers all over the globe. In point of fact, it's quite a bit easier than any of my experiences with similar size development teams in the commercial world.

I believe this is because everyone in FreeBSD wants to be there, and wants the system to grow and succeed by our standards, rather than being there just because it pays the bills, but don't have proof of this.

Since FreeBSD 5 is such a new system in many ways, everyone who wasn't intimately involved in the underlying changes comes to 5.x as a mostly new system. We try to ameliorate this with documentation on the new and changed APIs; the documentation group is one of our big strengths.

Greg 'groggy' Lehey: Resolution of bugs is seldom an issue. A bigger one is the question of direction. In open source projects, there's a tendency for the person with the greatest amount of drive or spare time to get to choose the solution. It may not be the best solution, but others don't have the time or energy to fight to get their version accepted. This is one of the backgrounds for our Technical Review Board, which should help stabilize the direction of the project.

M. Warner Losh : Actually, I'd say that the hardest parts of getting things right is more getting the progammers to play nice together. I sit on both the trb and on the core team. Often times technical disputes are really personality conflicts using the technical issues as proxies. Typically they reach a fairly advanced state of dysfunction before the core team is brought into the loop, and it takes a lot of time and effort to resolve the issues. I've spent 20x the time on the "play nice" aspects of the project than I have on the technical aspects. Usually after individuals start to play nice, they resolve the technical problems. I know of only one case where the trb had to get in the middle of a dispute and actively work on a solution that both parties could agree on. All the other times people were able to work it out, or the role of the TRB was to pick A or B as being better. In contrast, the core team has mediated something like 10 or 15 developer disputes in the past year.

Greg 'groggy' Lehey: We don't distinguish between people who work on the 5.x branch and other parts of the src tree. We've seen 152 different people commit code to the src tree in the last 12 months, 102 in the last 3 months, 63 in the last month, and 13 in the last two days.

7. Are there any plans on offering a graphical installer for FreeBSD and maybe some graphical or Curses-driven front-ends for most of the main services (e.g. for NAT, dhcp, firewalling etc)?

Scott Long: The 'libh' project was meant to provide a modern replacement to the venerable 'sysinstall', but work on it seems to be stalled. There has been talk over the years of different FreeBSD vendors and resellers stepping into this area, but nothing yet has happened publically.

Wes Peters: This is an issue that always generates a lot of discussion but little code. There is a long-running project aimed at creating the underpinnings for an entirely new installer, in the form of a library of code that handles the really hard parts of doing things like updating system configuration files in a way that can be islotated to a single installation, and backed out. We anticipate that as this project matures it will grow into an actual installer program, but don't have a timeline on such a development.

I don't know of any currently running projects to develop a graphical installer along the lines of what RedHat or Mandrake have for Linux. Nobody who wants one badly enough and has the skills to do so has materialized yet. Its not completely clear that such an installer is critical to the ongoing success of FreeBSD either; we are asked more often for installers that can be run remotely over a network, or over a serial console.

Greg 'groggy' Lehey: There have been various plans, but none have been overly successful. Currently people are enhancing sysinstall (which is curses-based) to perform some of these functions.

I also investigated such tools in some detail while updating "The Complete FreeBSD". I came to the conclusion that such tools are frequently counterproductive. They give people the impression of control when in fact they're frequently just capable of updating files without understanding the effects. This is particularly the case with firewalling. If people can't read a configuration file and use an editor, why should they be more successful with less powerful tools? Yes, lots of people ask for this kind of tool, but I'm reminded of the punch line "It's just what I asked for, but not what I want".

Optimizations, SPARC/PPC/Itanium/Opteron ports, third party tools

Scott Long: FreeBSD 5.0 stopped support for the 80386 in the default installation due to the pessimisation it brings to kernel. The 'make world' command makes it very easy to rebuild the entire OS, so we leave it up to users to decide what optimizations they want to enable.

FreeBSD 5.0 introduced support for the sparc64 platform. With used UltraSparc systems cheaply and easily available, this has been a hit. There are no plans for supporting the older sparc32 platform as it is quite dated in comparison.

AMD64 platform support is quickly gaining momentum. Peter Wemm from Yahoo! has a native 64-bit amd64 kernel booting right now, and it is only a matter of time before it is running useful userland applications. FreeBSD 5.0 also introduced support of the ia64 platform, though it only supported the Itanium1 systems. Itanium2 support has progressed significantly since then.

Wes Peters: i586 or i686 only? No, but FreeBSD already has a number of optimizations that are specific to each class of Intel (and AMD) processor.

Even more than that, parts of the kernel support functionality that only works on 586 or 686 processors. FreeBSD 5.1 will ship with support for PAE, the Physical Address Extensions in the 686-class processors. This means you can put more than 4GB physical RAM in a machine and make use of it. Each process still has a 4GB virtual address space, but you can have more than one 4GB process resident in memory without paging to external storage. This is very important for databases, for instance, where you may need to store large index tables in memory.

This doesn't mean we're going to remove support for 386- or 486-class processors, these optimizations are produced as you build the kernel or the rest of the system. In the BSD world, rebuilding the system is not seen as a barrier; in my home workstation it takes 30 minutes or so, on a garden-variety Athlon XP 2000+ system.

Note that some of gcc's optimizations produce code that fails, you do have to be careful when trying to optimize some kernel functions. We try to focus on correct and elegant code rather than relying on esoteric compiler optimizations to achieve performance. At the lowest levels, understanding the interactions between critical code segments, the data structures they reference, locking issues, and cache interactions lends enough complexity without worrying about what the compiler might be doing behind your back as well.

The SPARC64 and IA64 (Itanium) ports have been running stably for months now and were included in the 5.0 release. We even have clusters of machines building binary packages from the ports system for these architectures. x86-64 (Opteron) boots and runs but is still in the early stages of development. It is in the hands one one of our most experienced and capable developers (a fellow Core Team member) and I expect it to progress rapidly.

The PowerPC port has been progressing slowly, only a single developer is working on it. He has gotten the kernel booting on at least one of his development systems. You can keep up to date with his progress at the Daily Daemon News site. ;^)

Greg 'groggy' Lehey: Yes, we've been doing this for some time, and we'll continue to do so.

[ How is your port to PPC is coming along?]

Slowly. PPC is not a priority for the FreeBSD project: if you want BSD on PPC, buy a Mac. MacOS X is a BSD operating system, and it's not clear what advantages a FreeBSD implementation on this hardware would have for normal users.

Yes, we have a working SPARC port.

M. Warner Losh : The Sparc64 port is one of the tier 1 platforms in FreeBSD 5.x. A tier one platform has full support, and everything is expected to work on that platform. In addition, full releases are built by our release engineering team.

9. Are there any talks with Intel to port their compiler and tools to native FreeBSD? How about Rational's Purify? (commercial companies developing for or under FreeBSD might be in great need of these tools).

Scott Long: Intel's 'icc' and Rational's Purify both run great under FreeBSD's Linux emulation layer. This layer provides a linux-like kernel and userland environment for linux applications to run in. Linux games like Quake 3, Return To Castle Wolfenstien, and NeverWinter Nights also run flawlessly on FreeBSD via this layer. Some say they even perform better than running on native linux.

Wes Peters: Not that I know of, in either case. The Intel compiler for Linux runs adequately on FreeBSD and can be used to compile C source files into object files that are linked into FreeBSD executables. While the Intel compiler produces object files that are in some cases quite a bit faster on Pentium 4 processors, making a compiler that can't just plug into the Linux native development tools was a curious step.

If they would release the source code to the compiler we would have a port to FreeBSD in short order at no expense to Intel, but I dont' foresee that happening anytime soon.

XFree86 issue, re-unification of the BSDs, UFS2

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.

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.

The SCO questionmark

13. SCO went after IBM, now they seem to go after Linux, while they hinted that Mac OS X also uses their Unix IP. This does raise an eyebrow, as MacOSX is partly based on FreeBSD, 4.4BSD and Mach3... How does this situation affect the FreeBSD Project? Is FreeBSD using "clean" code, or are some remaining SysV code is still part of your project? Additionally, FreeBSD ships with Linux emulation libraries. Does this part of the Linux code in FreeBSD includes any claimed SCO IP?

Greg 'groggy' Lehey: Technically, not at all. It's not clear what SCO's motives are, but I consider them completely unfounded in all points. The Linux source code is available to any user, and SCO themselves ship Linux source code, so it's difficult to understand how SCO can make these claims without pointing to a single instance to substantiate the claims.

It's also interesting to note that over the last few years SCO has been attempting to release more and more source code under open licenses. I was involved in an attempt to release sar a few years back, but nobody in the BSD communities was interested enough. I get the impression that new management has moved in without understanding the obligations and commitments that SCO has made in the past.

Note also that SCO's claims that IBM is stealing their SMP technology are ridiculous. SCO never had any useful SMP technology, and the implementation in Linux both predates IBM's involvement, and is also completely different from the SCO implementation.

There is some code in FreeBSD which was derived from System V. It was released specifically for this purpose, and there had never been any dispute about it. The "BSD Wars" of 1992 to 1994 were about code imported from Research UNIX, not System V. SCO (then called Caldera) released all Research UNIX code under a BSD style license in January 2002, so there is no way they could complain about this.

M. Warner Losh : The code was *NOT* derived from System V, but rather from Unix 6th and 7th edition, as well as 32V. Only the copyrights were similar to those used in System V source files. The code in question was merely blessed by USL and acknowledges as originating there by the Regents. Read here.

The settlement restricts further use and distribution of certain files in the Second Networking Release and requires that certain files in 4.4 BSD-Lite include a USL copyright notice. In addition to providing several enhancements, the new 4.4 BSD-Lite Release will replace most of the restricted files and incorporates all the agreed-upon modifications and notices. Thus, 4.4 BSD-Lite will not require a license from nor payment of royalties to USL. The University strongly recommends that 4.4 BSD-Lite be substituted for Net2.

In any event, those files with USL copyrights on them have specific permission to be distributed by the Regents of the University of California to settle thse lawsuits, with an additional agreement that Novel (and its successors) would not sue anybody basing systems on 4.4lite.

FreeBSD 2.0 base a new port from 4.4lite. It contains no code from the net2 releases that isn't in the 4.4 lite release. FreeBSD 1.x did include code that was subject to that lawsuit, but since the FreeBSD has not made that code available for years, I'd think that we'd be safe from any IP claims.

Greg 'groggy' Lehey: I do have some concern about the way in which Caldera released the software. The current litigation against IBM so completely contradicts the release last year that I can only assume that the people involved don't know about each other. We (in this case the UNIX Heritage Society) have asked SCO to put up information about the release on own web site, but so far they have not done so. A copy of the original is here. You may quote this URL if you wish.

[Linux emulation libraries threat] I don't believe so, but as I say, SCO's complaint was very vague. FreeBSD simply uses existing Linux libraries for the emulator, so I can't see any reason why the FreeBSD project should be held responsible for the content.

M. Warner Losh : SCO's claims are based on bad action by IBM. They make a copyright claim against IBM that is approximately: IBM derived AIX from System V. IBM took parts of AIX and put them into Linux. Therefore, since AIX is derived from System V, they put our IP into Linux.

The comments that they made about the Mac OS X sources are from a position of ignorance. All files in the Mac OS or FreeBSD source trees that have USL copyrights are specifically covered under an agreement to settle the 1992 lawsuit between the University of California Regents and Novel (the folks that purchased USL while the lawsuit was going on). That agreement specifically stated that Novel, and its successors, would not sue anybody who based their systems on 4.4lite. FreeBSD is based on 4.4lite, and is therefore immunized against such legal action based on copyright claims. UCB, for their part, removed certain files, rewrote others and added the copyright notices to still others. FreeBSD has no code that infringes upon the SCO group's intellectual property.

There never was any System V code in any BSD. Ever. The IP claims that USL made its 1992 suit were based on the inclusion of sixth and seventh editions and 32V. While these were the forerunners to System V and System III code bases, they are not specifically System V or System III. Furthermore, SCO released, under its ancient unix program, all sources that predated System III and System V to be freely distributed under a BSD-like license. These specifically included 6th edition, 7th edition and 32V.

IBM has never, to my knowledge, contributed significant work to the FreeBSD project. Since SCO's IP claims appear to be based in copyright law, FreeBSD is safe from claims via this vector.

Linux's libraries are completely free of SCO intellectual property as well. They are based on glibc, which has been written from scratch over the past 15 years or so. Other libraries are similarly written from scratch, or are based on code bases with well known lineages (for example, the X11 libraries). Therefore, FreeBSD is safe on this front.

Were we to include ibcs shared libraries that are necessary to run ibcs emulation, we might be volnerable to an ordinary copyright claim. However, we do not, so we are safe from that aspect of the claims that have been reported in the press.

Some, not connected with SCO as far as I can tell, have alledged that SCO is making patent claims against unix for its Unix IP intellectual property. Since most of the key concepts on Unix were invented before software patents, and also many years ago, the patents have either expired, been placed into the public domain, or were never issued. It is unlikely that SCO could prevail on claims in this area as well. A careful reading of SCO's statements show that they refer only to Unix IP, and copyright law to justify their suit against IBM. Even if that weren't the case, FreeBSD is safe here as well, as far as we can tell.

Finally, the FreeBSD core team has not been contacted by SCO representives directly. We have seen press reports, but they are not sufficiently specific for us to know what, exactly, would be alledged should SCO contact us. In addition, SCO's own web site has only talked about copyrighted code being transferred from IBM's AIX into Linux. Since there is no code that orginated in AIX in FreeBSD, we can only assume that we're safe from such claims. Our belief is that we're very safe from these actions, for the reasons I've outlined above. However, in the absense of specific allegations against us, we cannot, with certainty, say one way or the other.

Copyright OSNews.com 2003.