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.
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
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 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.
3. FreeBSD’s ever present “competitor,” GNU/Linux, started winning the crowds with a first wave of hype around 1999, while now many try to convince us that Linux can perform well in the desktop space as well as in the server space. How does the FreeBSD project see the whole situation and how do you feel about a sub-project of “FreeBSD on the desktop?”
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
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.
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
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
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
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.
5. Strictly technically speaking, what are the biggest advantages of FreeBSD against Solaris, Linux, IRIX and AIX today, and where does it still lack compared with these Unix alternatives?
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
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
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
* 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.
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
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
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
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”.
8. Are there any plans to optimize FreeBSD by default for the i586 or i686 architectures only as opposed to plain i386? How are your port to PPC is coming along? Are there any plans for a working SPARC port? Most importantly, what about support for the AMD Opteron and Intel Itanium?
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)
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
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.
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.
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
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,
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
Others here who are more knowlegable about filesystems can give you a
more detailed, feature-by-feature comparison if that’s what you’re
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
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
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.