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
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 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
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.
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.
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
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.
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”.
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)
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.
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
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.
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.
Now THIS is what I call a good article, not the usual “Jack’s failure of installing DISTROHERE-VERSIONHERE”.
on a great OS. I wish more Linuxheads would try it.
My only gripe w/FreeBSD is it refuses to be installed in extended partitions and its not as good support for 3d on my ATI Radeon 7500.
It’s as well supported under the DRI with FreeBSD as it is under Linux.
Adam
Couldnt get it installed, went through the install process, appeared to install packages but it wouldnt boot.
I have some problems setting up Voodoo5 with FreeBSD 4.8 in 3D accelerated mode. “Load dri/glx/666/blahblah” is all set on my XF86Config file (XFree86 4.3.0 used), I have the agp module ON in the kernel (voodoos don’t use agp anyway), but I don’t get 3D acceleration, GL apps run on software mode (mesa/glut is installed). I have installed ‘driglide’ via the ports system btw (not DRM though – do I really need to mess up with that?). I have also read the pages here (http://people.freebsd.org/~anholt/dri/), but still no joy. Any pointers or tricks?
Eugenia,
What does /var/log/XFree86.0.log say about Direct Rendering?
If it says it’s enabled, set the environmental variable LIBGL_DEBUG to verbose in an xterm and launch glxgears. See if it gives any errors.
E-mail me if you like.
Adam
I loved this article. I’m amazed at the level of detail the guys went into to answer the questions. Please continue this trend.
very nice article, indeed. i’d be more than happy to see similar interviews with members of NetBSD and OpenBSD projects (hint! hint!). thank you.
Today I run Gentoo Linux on my primary machine (this is important because it’s what I have most experience with, and therefore, what I’d most compare FreeBSD to). This past weekend I decided to give FreeBSD a try, for various reasons. My experiences:
(1) The installer is kind of like Debian’s – text-based, but simple to use. I was able to get the system installed properly without problems, without documentation. I didn’t consult the superb FreeBSD handbook (available online) until after the primary install process. It’s rather intuitive. It took about 30 minutes.
(2) The FreeBSD handbook is great. It’s not overly detailed but covers all of the basics clearly, succinctly, in plain language. As someone who has always been impressed with Gentoo’s documentation, I have to give kudos to the FreeBSD handbook. It’s in a similar vein, perhaps with a little more “why are you doing this” information than the Gentoo docs. Print it out or leave a browser window open when you’re first figuring things out; it’s your first resource for anything FreeBSD related. Small parts of it are a little out of date for 5.0 (which is understandable), but if you’re installing 4.8, this won’t matter.
(3) FreeBSD is almost more similar to Gentoo or Debian than Gentoo or Debian is similar to other distributions like Mandrake. FreeBSD’s ports system will be immediately recognizable to Gentoo users, though its use is a little more granular than Gentoo’s portage (cd into the ports directory, then do a make, make install, make clean – it then fetches the files from a CD or the net, does the requisite dependency/requirements checking, downloads and compiles those). There’s nothing as simple as USE, but FreeBSD does support various compile options, including specifying the CPU you’re using (via config options in a configuration file or on the command line). A Gentoo user will be able to figure it out easily with help from the Handbook. Debian folks will like the fact that you also have the option of downloading compiled packages. In a sense, the best of all worlds. I would add that I make no comment as to what’s under the hood with all of this; from a user’s perspective though, all of this is pretty familiar. If you live in the United States and are familiar with the US, think of FreeBSD as Canada, from a user’s perspective. A little different, but easily navigable (I may have just bothered some Canadians – my bad).
(4) Got KDE and Gnome installed. I’ve been compiling everything via use of ports, perhaps out of habit. They work great, and are of course indistinguishable from Linux.
(5) The directory structure is a little different, but not radically so. There’s a /stand directory, for example. There’s also a menu-based system management tool (as referenced in this article) called sysinstall, which is optional, but useful, especially in the beginning. I don’t see any great problem with it that it needs replacing; of course, you’ll probably eventually get into manually editing the various configuration options via a text editor instead.
(6) The boot sequence for starting services struck me as a little bit unusual. There’s nothing like rc-update in Gentoo. Took me about 30 minutes to figure out how all of my services were starting, but it’s just a matter of being used to something different. I’ve noticed that a little more attention is paid to “local” vs shared or global applications and daemons in FreeBSD, than what I’m used to. This can lead to things being installed in places you might not expect. For example, the Apache 2 httpd.conf file is installed in /usr/local/etc/apache2/ – This may be even par for the course even for Linux distros I haven’t run, but not for the ones I have (which install into, usually, /etc/httpd/ or /etc/apache).
(7) Compiled a kernel. In FreeBSD, you edit a large textfile filled with commented and uncommented lines for each module you want compiled in. I didn’t see any menuconfig type tool like there is in Linux. I was able to successfully recompile kernels with ease; even a beginner should be able to follow the guide and get a new kernel compiled and installed without difficulty. However I haven’t yet found a very good reference explaining what a lot of the modules did, and the consequences of including or excluding them. menuconfig contains a little metadata on each module; the text file containing the list of modules has a comment for most modules but I’d like a little more info. The first time I compiled the kernel, it failed because one module required another I had commented out. I’d like to see these kinds of dependencies better documented. Perhaps they are, somewhere. I haven’t found any such resource. Nothing to panic about, but it might take you a try or two. I was able to figure out what was missing through a single Google search on the error I was getting.
(8) I installed 5.0, which is considered unstable (“New Technology Release”, but it seems to be as stable as anything else I’ve run. Supposedly it’s slower than the 4.8 production release (as per this article) but I have nothing to compare it to. Seemed snappy enough on my P2-400, even in Gnome and KDE.
(9) For whatever reason (I am full of preconceptions from reading too many OS-related websites), FreeBSD (in my mind) had a sort of reputation for being a niche, geek OS, but I’ve found it to be rather intuitive, well documented, and about as easy as any non-commercial Linux to install (Alternately, I could just be a major geek. Which is probably the case). The ports collection is vast, and I haven’t had to mess around with the Linux compatibility layer (unless it’s enabled by default by some of the ports; I don’t know yet – I’ve just not had to specify anything about it, or go through any gymnastics as you have to with WINE under Linux or anything like that). Every single application I run in Linux is available via ports, and there are *thousands* of them. Also, it plays well with my Linux and Windows boxes in terms of NFS and samba; it’s a good “network citizen”. Most of the configuration files are the same. In short, it’s all familiar stuff. Ports may be new to you, depending on where you’re coming from, and if you’re stuck on an RPM based Linux distro, you’ll probably love Ports. No question.
(10) I’m still very new to FreeBSD and may have hosed things a little bit trying to get KDE 3.0 up to 3.1 – if you install FreeBSD, be sure to cvsup (serves the same basic function as emerge rsync in Gentoo) before you go around installing big packages. Had I done that, I’d be fine. I’m still finding my way around the ports system; there are a fair amount of permutations of what you can do, in terms of command-line switches for updating packages and so forth.
Worth an install, if the only reason you’ve been avoiding it is fear, or something.
If, on the other hand, you are a Windows user and hate Linux for all of the typical reasons, you’ll probably hate FreeBSD too (With the exception of package management, which is wonderful in FreeBSD).
Users of Mandrake, Red Hat, SuSE, may find it a little more complicated, but nothing insurmountable. Easier than Gentoo to install, about the same as Debian to work with in terms of difficulty (Trust me, the dependency handling goes a long way).
Debian and Gentoo users (and probably Slackware users) should find it a breeze. Gentoo users will probably smile about how much Gentoo has borrowed and improved from FreeBSD (I assume FreeBSD, and not another BSD) in terms of portage. Of course, this is pretty common knowledge anyway, I think.
The choice of using precompiled packages, is, of course, a great plus for people who are too impatient to compile everything.
I like it a lot so far.
nice review of your experience, i’m a Linux user myself (both debian and redhat) am getting a new hard-drive considering puttin FreeBSD on the old one just to see what it’s like, then again nothing can beat IRIX on a Origin 3800 (i’ve an account on one
I’ve run FreeBSD 5.0 since it was released. I’ve had no problems at all with it. In fact I’d say FreeBSD’s unstable is considerably more stable than any Linux stable distribution I’ve ever run.
Also FreeBSD 5.0 is NOT SLOW, as long as you stick with the Release Engineering branch instead of current, all of the debug code is disabled. In addition, you can disable the debug code in Current by changing some options in the kernel config file.
I’ve been using FreeBSD since FreeBSD 4.3 and I’ve been very impressed with every release.
Keep up the good work team.
I couldn’t imagine using anything else on a production grade server.
-bytes256
freebsd is very nice. I got it installed on my home server. Now its dual boot linux, freebsd until I figure out how to set up all the services I have running on the linux side. Probably that would have happen much faster if I could sort out NAT so I can work on it from my other box.
Which firewall people use ? The IPfilter or the default freebsd one? I guess it will have to wait until the end of the semester…
I really like it thought.Thats proper unix.
And yes coming from an rpm distro I loved the ports.
However my favorite command will be “make world”
—
antonis
Lack of Java is bound to have a significant impact on adoption of FreeBSD at companies.
In Linux (and Windows) we have many great options in terms of development languages and environments (C/C++, Java, Python, Perl), and that allows us to use the right tool for the job.
Sometimes Java is that right tool. Without Java, FreeBSD is missing a major piece.
Hopefully Python (or another higher level language) will mature enough to fully replace Java, at which point FreeBSD won’t be left out.
It is interesting to me that I have seen something like the following a thousand time:
“Linux and Java: The killer combo”
Mandrake doesn’t let you install it by default and Redhat doesn’t either. For something that goes great together, you would think you could install it from the get go.
I heard Gentoo does a great job with Java though. ; )
Why hasn’t someone made a “distro” of FreeBSD in the same vein as RedHat, Gentoo, etc?
This was excellent reading, not just like someone noted already the detailed answers but the atmosphere and attitude. Professionalism, just pure professionalism is what I smell from this core team of people.
I’ve been trying to install FreeBSD for a while, but my GF4 card makes it halt during install process very early and I just can’t seem to get passed it. I hope this will be solved with 5.1.
I’d love to see half of these questions to be asked to NetBSD and OpenBSD too… very curious to hear how they consider things…
I agree, no proper Java support is a significant issue. As it matures (and more to the point, speeds up), Java is really starting to turn into a useful language.
Replace Java with Python? Surely, sir, you jest. I like Python as much as the next guy, but I think Java has a much better programming paradigm.
-Erwos
Why hasn’t someone made a “distro” of FreeBSD in the same vein as RedHat, Gentoo, etc?
Did you ever bother reading the article? The interviewees themselves stated clearly that FreeBSD isn’t just a kernel like Linux, hence making a distro is like buying a pre-fabricated PC only to throw everything out, save the motherboard, and populating it with off-the-shelf parts.
IOW: FreeBSD is a “distro” in itself. That is one of its strengths.
“Their attitudes speak volumes as to why ANY flavor of BSD isn’t ruling the desktop”
And that’s the thing, we don’t care. Go use Windows XP if it meets your needs. If all you want to do is run play games and run kiddie apps like kazaa, msn messenger and word, then Windows XP is just right for you; if you are a software developer, consultant, or use your computer for technical writing, a Unix-based OS might be a better choice.
Freethinker, if you want to use FreeBSD on your desktop, you’re free to do so. It will provide much the same experience as Linux on the desktop, even. However, the FreeBSD developers seem to have a certain grip on reality which is lacking amongst certain crowds swearing by another UNIX-like OS. BSD is a UNIX. Its conception dates back to the time before there were such things as graphics capable computers or non-keyboard input devices available outside a select few laboratories. They recognise that their system as a whole isn’t the ideal foundation for a modern desktop OS, especially not while still accomodating their current users.
In other words, if you want to use FreeBSD on your desktop, please do so. A lot of others prefer to keep it on their servers, but it can serve as a workable desktop OS, too. And since you obviously know what FreeBSD entails, as well as having Linux desktop experience, you know what to expect and will probably make do with that.
But if you want a desktop OS which extends beyond X11+KDE+GNOME, you’d do better with MacOS X. And it features a lot of FreeBSD goodies, so you wont miss out on much, either.
As for why any BSD flavour (save OSX) isn’t ruling the desktop (something which Linux can’t claim to be, either), you pointed it out yourself; they don’t consider it to be any important goal. Nothing particularly wrong with that. Not every OS has to be a desktop OS. Some OSes are aimed at embedded applications, others are server OSes, and content to be used in the field where they stand out.
FreeBSD has TONS of Java support. Due to it’s excellent Linux emulation, it can run all of the Linux JVMs and SDKs. I’ve used the Sun and IBM Linux SDKs and never had a single issue with stability or compatibility. I’ve also used the FreeBSD Java ports and i’ve read somewhere that the 1.3 version is actually upwards of 90% compatible with Sun’s version.
Hey Quag7, excellent writeup. I’m a long time Debian user who’s run all of the BSDs at one time or another. My experiences agree with yours entirely. Of course, where as I just kept them to myself, you posted them. Maybe you should try doing some guest articles for OSNews? You seem level headed, technically competent, and, best of all, coherant. Anyways, just a thought.
Thanks Eugenia, it’s kind one of best article that I have ever read about BSD!
Hey, I have some questions to ask you, Eugenia. I saw in your screenshot, you have the Straw installed and ran it. Does the Straw runs great on your machine? Does the RSS update (poll) fine without the problem by time in Straw? If so, then I guess it’s kind of broke on FreeBSD 5.0, but runs great on 4.x..
Greg ‘groggy’ Lehey: compared to Linux:
[….]
* 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.
This is exactly same as in my experience; it’s why I dumped Linux and fell in the love with FreeBSD.
Quag7: (1) The installer is kind of like Debian’s – text-based, but simple to use.
I think, it’s more similar to Slackware than Debian does on the text-based installer. 🙂
Quag7: (5) The directory structure is a little different, but not radically so. There’s a /stand directory, for example.
Yes, FreeBSD follows the hier(7) pretty very well. I am fan of it. 😉 You can check in the ‘man 7 hier’ for the more details about the standard file system hierarchy, if you want to.
Quag7: (7) [….] However I haven’t yet found a very good reference explaining what a lot of the modules did, and the consequences of including or excluding them. menuconfig contains a little metadata on each module; the text file containing the list of modules has a comment for most modules but I’d like a little more info. [….]
How about check in the LINT (4.x) or NOTES (5.x)? It’s in the same place as where you edited your kernel.
Quag7: (7) [….] The first time I compiled the kernel, it failed because one module required another I had commented out. I’d like to see these kinds of dependencies better documented. Perhaps they are, somewhere. I haven’t found any such resource. Nothing to panic about, but it might take you a try or two. I was able to figure out what was missing through a single Google search on the error I was getting.
Most of time, it will tell you that option required to enable like scbus, da, miibus or so in the comment. But, I agree they need the better and improvement on documente of the kernel option.
Quag7: (8) I installed 5.0, which is considered unstable (“New Technology Release”, but it seems to be as stable as anything else I’ve run. Supposedly it’s slower than the 4.8 production release (as per this article) but I have nothing to compare it to. Seemed snappy enough on my P2-400, even in Gnome and KDE.
Me too, but GCC 3.2.x is taking the more time to compile, which meaning took more longer time to finish the buildworld/recompile kernel. That included the ports tree. It really doesn’t matter to me, when I am doing them while I am in the bed. 😉 But, after that the apps seem run at the same speed or so, I haven’t done any of benchmark. 🙂
Quag7: (10) I’m still very new to FreeBSD and may have hosed things a little bit trying to get KDE 3.0 up to 3.1 – if you install FreeBSD, be sure to cvsup (serves the same basic function as emerge rsync in Gentoo) before you go around installing big packages. Had I done that, I’d be fine. I’m still finding my way around the ports system; there are a fair amount of permutations of what you can do, in terms of command-line switches for updating packages and so forth.
Since, you are still very new to FreeBSD. In case, just let you know about portupgrade. It’s one of best and recommend add-on third party for the ports tree. It will update all of your installed apps by automatic. This tool rocks! It’s in sysutils/portupgrade, which it’s a Ruby script.
1) CVSup your ports tree.
2) pkgdb -F
3) portupgrade -ra
bytes256: I’ve run FreeBSD 5.0 since it was released. I’ve had no problems at all with it. In fact I’d say FreeBSD’s unstable is considerably more stable than any Linux stable distribution I’ve ever run.
I second, I have FreeBSD 5.0 since it was before dp1.
bytes256: Also FreeBSD 5.0 is NOT SLOW, as long as you stick with the Release Engineering branch instead of current, all of the debug code is disabled. In addition, you can disable the debug code in Current by changing some options in the kernel config file.
You should update to -CURRENT, because it’s way more stable than -RELEASE right now.
> I saw in your screenshot, you have the Straw installed and ran it. Does the Straw runs great on your machine? Does the RSS update (poll) fine without the problem by time in Straw?
No, it doesn’t work…
It says “polling” forever and it doesn’t fetch the headlines.
No, it doesn’t work…
It says “polling” forever and it doesn’t fetch the headlines.
Damn, here too. Looks like I will have to send the PR about ADNS, py-adns and py-xml have the bugs on FreeBSD, they all need to be fix. I will see if I can get them fix, but I doubt I can thought.
Thanks again!
Eugenia,
What theme is that? Very nice.
Can’t remember, I think it is this one: http://lighthouseblue.sourceforge.net/
Can’t remember, I think it is this one: http://lighthouseblue.sourceforge.net/
Yes, it’s correct. It’s included in the Gnome 2.2’s theme package by default.
If that’s a long read, does it mean most osnews articles are just one or two paragraphs?
That was a great interview. Very refreashing. It was also good to read their comments on the whole SCO issue. Very vaild points and reasuring at the sametime.
Well done OSNEWS
Wow. Great stuff. Contradictions and all make for an illuminating discussion of the development behind BSD.
Makes me want to try it all the more.
Excuse me while I dowload an ISO or two….
Thanks for your positive comments. I’d like to help out in a few areas if I can.
As you note, the FreeBSD Handbook is a great resource. The Handbook chapter on compiling a new kernel might be of help to you as well. It will certainly point out that the place to learn what various kernel modules do is in the man pages for that kernel module. There are a few missing but generally they are an excellent resource. FreeBSD users, unlike Linux users, expect the manpages to be complete and accurate. ;^)
You may also want to take a look at The Complete FreeBSD coming soon from O’Reilly. Written by Greg Lehey, one of our core team members who also participated in this interview, it is a valuable resource. It is much more tutorial than the Handbook, and quite a professional publication. Greg has authored other books published by O’Reilly and previous editions of TCFBSD were published by Walnut Creek CD-ROM, so it’s OK to keep your expectations high.
For beginners, you may want to check out FreeBSD: An Open-Source OS for your PC by Annelise Anderson, Absolute BSD my Michael W. Lucas (who is also the FreeBSD Donations Liaison Officer), or FreeBSD Unleashed by Brian Tiemann and Michael Urban.
The ‘menu system’ or GUI for editing a FreeBSD kernel config exists, in fact you can choose from several. My favorite is ’emacs’, others prefer ‘vi’ or ‘vim’. We place a strong emphasis on storing configurations in human readable form rather than placing a layer of GUI between the user and the real configuration. The config file ‘LINT’ on 4.x or ‘NOTES’ on 5.x will show you what all the options are, and are heavily commented around the more esoteric functions.
The booting sequence that seems to puzzle you is new to FreeBSD as well. It is a port of the NetBSD boot system, designed by Luke Mewburn. It is known as ‘rcNG’ in FreeBSD, and has quite a few desirable features. The main attribute of interest is that it allows subsystem or application designers to drop in a startup script that will be automatically sequenced with the rest of the system boot. Say, for instance, you’ve written an application that relies on both PostgreSQL and Apache to be started before your application can be started. In the Linux SysV-type startup, the system administrator would have to look through the startup scripts and give the application startup a sequence number that occurs lexically after both the Apache and PostgreSQL startups. With rcNG, the script itself reports that it depends on Apache and PostgreSQL, and the system starts and stops it in the correct order. The rcNG project is also a great example of code sharing between these two development teams, who have goals that in some ways differ greatly.
Lehey exhibits all the worst things I have heardabout the BSD culture: he’s snobby and argumentative and can’t stop promoting himself (see the plugs for his books). But the other guy, Warner, seems to have his head on straight and really know what he’s talking about. I say promote the latter and give the former the boot.
I would like to try one
Why hasn’t someone made a “distro” of FreeBSD? Mainly cause there’s not much of a point to it. FreeBSD is a complete OS. “Linux” is a kernel only; most common Linux distros are the Linux kernel with tools that actually make it do neat tricks. FreeBSD already has the tools and everything as part of the OS, so there’s not much reason to create multiple distributions. Organization is key to any good OS and FreeBSD is *organized*; several distributions would most likely work against the organized model FreeBSD uses.
There’s nothing stopping someone from packaging up FreeBSD and doing something unique with it (I built a bootable, live-file system CD I use for backing up laptop hard drives at work using dd/split and writing to an NFS share), but it wouldn’t officially be “FreeBSD” any more. When you distribute “your” version of FreeBSD it becomes “based on FreeBSD,” not FreeBSD.
CURRENT is not more stable than RELEASE right now. Just last night I had repeated kernel panics while trying to compile gtk2. The nVidia driver doesn’t seem to play nice with CURRENT at the moment either.
One thing that I find interesting throughout this is that Linux is referred to as a single entity. It is not. Linux is just the kernel (and glibc+tools according to GNU zealots). Mentioning which OS it was easiest to install application X, Y or Z on should always refer to which linux distro was used. Redhat is the evil empire of linuxland, yet much more freebsd-like distributions with up to date packages with managed dependancies requiring little if any interaction exist (gentoo).
Another thing to add to the “what is the desktop really?” definition is that device driver support for random device Foo is important to non-technical users. Linux is much further along in this area than FreeBSD. (witness: el-cheapo network cards not always working on freebsd, cardbus support only just becoming available 5 years after cardbus was common, etc..). Despite all of this, both freebsd and linux fail on the non-technical users desktop when it comes to device support due to lack of a consistent super simple easy plug and play experience that can never get into trouble. Leave that to Mac OS X or windows who have real budgets and usability/idiot testing labs.
I just switched away from RedHat to FreeBSD 5.0-RELASE when the BIOS on my last computer frizzled. I’m now using an older system, the memory is the same, but the chip is about 1/3 slower. I haven’t noticed a real slowdown in system response which rather amazed me. That along with the easy install and overall polishedness of the complete system is keeping me leaning toward FreeBSD for my desktop. Seems to me there’s alot that ‘just works’ where you have to endlessly tweak a RedHat system.
Great job on this article, the detail and depth of questions and answer was excellent. I hope OSNews.com can continue to bring us such detailed interviews. Thanks OSNews & FreeBSD Team!
Keep up the good work 🙂
OK, so FreeBSD rocks, and beats Linux in most fields. That’s great. Now make it popular. Why don’t you add an installer for newbies, config tool for newbies and so on. Do to FreeBSD the same think that Mandrake did to Linux – make it easy to use for ordinary people.
Read my lips, MOST PEOPLE DO NOT WANT TO SPEND 2 HOURS TO GET THEIR_FAVOURITE_SYSTEM_TO_WORK. And please don’t tell me that it takes less for you. It’s the newbies you should be fighting for. Make a bsd for the masses
PS. don’t tell me about OSX, I’m not willing to buy Apple’s hardware – too expensive.
Well is it? Also I too wish the Linux kernel was as neat as FreeBSD’s and that the package management was as good. However portage and autopackage are looking good. Also SCO so far seem to be a bunch of lost liars continually making false claims.
“Why hasn’t someone made a “distro” of FreeBSD in the same vein as RedHat, Gentoo, etc?”
Hey, distro exists, they are called freebsd netbsd openbsd darwin etc……
On other side I can assure you that Debian has no distro. It is an integrated system, not only a kernel 😉
Perhaps you missed some of the statements in the article regarding the true focus of FreeBSD? It is not the same as Linux’s, i.e., an OS for the masses. The installer is suitable for those who want to use the operating system as they have probably determined that FreeBSD suits their needs. Windows XP can take more than 2 hours to get it to “work” and yet millions of users have chosen this path.
From the original article:
> 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.
The responders all missed noting that after 5.0 came out, 4.8 came out — for exactly this reason. In other words, development is actively continuing on the 4.x branch, which is the recommended branch for people to run production systems on while the 5.x tree undergoes its shakedown cruise. It is likely that the “push” to get people to upgrade to 5.x won’t happen until 5.1, or more likely, even 5.2, has been out for a while.
There were simply too many large changes in 5.0 — many of which had interactions — to hold off releasing it any longer. (There is a development roadmap at http://www.freebsd.org/doc/en/articles/5-roadmap/ that goes into much more detail about the future plans).
From other’s comments:
> The Apache 2 httpd.conf file is installed in
> /usr/local/etc/apache2/ – This may be even par for the
> course even for Linux distros I haven’t run,
> but not for the ones I have (which install into,
> usually, /etc/httpd/ or /etc/apache).
The FreeBSD philosophy, since it avoids the “distribution” paradigm in favor of the “one source base” paradigm, winds up including a very minimal subset of applications in the “base system”. This is entirely by intention. So, for instance, Apache is not part of the “base system”: it’s a “port”. Ports are expected to be generally well-behaved in terms of modularity: thus, by implication, they only install their configuration files under directories outside the traditional places such as /root and /etc. By default, it’s /usr/local, but you can change it. (There are probably ports that don’t get it right if you do change it, but those are defined as bugs).
A side-effect of this philosophy is that ports are expected to cleanly de-install themselves when asked to. Ports that don’t cleanly de-install are defined as having bugs, too.
Thus, the risk for “just trying” a port is lower, since no system files are supposed to be messed with.
> In FreeBSD, you edit a large textfile filled with
> commented and uncommented lines for each [kernel] module
> you want compiled in. I didn’t see any menuconfig type
> tool like there is in Linux.
No one commented on the fact that in 5.x there is a new “hints” mechanism for specifying things such as IRQs and other common configuration information _outside_ your kernel build. A great deal more work has gone into making this work smoothly (and thus probably saving many more users having to build kernels) than has gone into making the kernel build itself easier.
> Every single application I run in Linux is available via
> ports, and there are *thousands* of them.
8595 as of yesterday’s checkout 🙂
It’s important to emphasize that you don’t have to “hunt around” for a version that will plug into your system. Each port maintainer is responsible for making sure that each port “plays nice” both in terms of installing, deinstalling, and (for all but the binary-only ports) compiling. If it doesn’t, file a Problem Report (PR)!
To reiterate, there is none of this “hunt around for an RPM that works” effort needed, which I personally found annoying under Linux. It’s cd /usr/ports/<category>/<portname>; make install. If it doesn’t work, it’s a bug. (Given that most ports require installation as root … but people are interested in fixing that.)
> Why hasn’t someone made a “distro” of FreeBSD?
Well, in the FreeBSD philosophy — you don’t! The system exists in terms of “base functionality” (kernel and minimal toolset) and “ports” (all applications).
Now, the system installer “suggests” some combinations of ports that most people will want (XFree86 & related things being one).
But you can always design your own — just make it itself a “port” that installs nothing of its own, merely defines dependencies on other ports. See, for example, the ports contributed by teh aforementioned Greg Lehey, http://www.freebsd.org/cgi/cvsweb.cgi/ports/misc/instant-server/ and
http://www.freebsd.org/cgi/cvsweb.cgi/ports/misc/instant-workstatio… .
Of course, it turns out that some ports are “more equal than others”. Even though Perl is not installed in the base system, almost inevitably it’ll be installed as a dependency from some other port (I did mention that all ports check for, and if necessary install, all their dependencies, didn’t I? 🙂 ) Also the canonical port to manage the ports collection is portupgrade; almost everyone will want to start with that.
Next to last comment:
Having said all this nice stuff about FreeBSD, it’s fair to say that the system installer is graceless and has aged very badly. It is fine to use _but only once you understand exactly what it’s doing_. I found it very counterintuitive to learn.
But everyone who hates the installer, once they’re done with it, then goes on to work on other, more fun, stuff, and thus the old installer remains 🙂 But I think it’s also fair to say that a lot of people would welcome its retirement.
Final comment:
As for some of the questions of “why isn’t XYZ available”, the plain and simple answer is that no one’s done it yet — same as any other Open Source project 🙂
Ah hah, thanks Wes. I was looking for LINT, couldn’t find it in 5.0 until someone on a FreeBSD support channel gave me a command to generate it, but it didn’t generate what I expected. I’m looking at NOTES now, and this is just what I was looking for. Thanks. I’m going to read over this file completely. I am still digging into the documentation on a lot of things.
Actually I have been running portupgrade with the (-a) switch (Upgrade all installed packages) now for several hours, and it’s going along swimmingly (To make another Gentoo comparison, this is like emerge –update world, pretty much).
I still don’t have my sound working properly but it may be unsupported; it’s onboard sound from a 5 year old computer. I haven’t worked with it much yet.
Quag7, when you find something interesting in LINT (4.x) or NOTES (5.x) try: man module, most modules have their own manpages that explains what they do and how to use them.
Also note that on 5.x there are two NOTES files to look into, one machine independant (/sys/conf/NOTES) and one for the specific architecture that you are using (eg. /sys/i386/conf/NOTES) if you are on IA32.
FreeBSD officially slags its own installer, so if you hate it, it’s not just you. From the man page for “sysinstall”:
BUGS
This utility is a prototype which lasted several years past its expiration date and is greatly in need of death.
http://www.freebsd.org/cgi/man.cgi?query=sysinstall&apropos=0&sekti…
It’s not really that horrible of an installer, though; there’s just a few places where the selection process is a little counter-intuitive, notably the “type of installation” selection, where it’s remarkably easy to biff the “select everything” option. (For FreeBSD, “everything” is much leaner than a typical Linux distribution!)
Compile from the Source
[quote]
Greg ‘groggy’ Lehey: compared to Linux:
[….]
* 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.
This is exactly same as in my experience; it’s why I dumped Linux and fell in the love with FreeBSD.
[/quote]
=> I still don’t understand… if Linux is not as stable as FreeBSD, why would you run COUPLES of Linux and willing to reboot it again and again. Why don’t you just wipe it and install your FreeBSD? Linux vs FreeBSD ?
Don’t mind what Greg Lehey says… He comes off as a jerk throughout the whole interview.
Firstly, I almost became a *BSD user – 386BSD was getting popular at about the time I bought my 486 in 1991, and I wanted an OS that could use that power – since DOS couldn’t.
However, Linux had also started drawing attention, and it came on fewer disks, so it was a little cheaper. I got SLS 1.0, running Linux 0.99plsomething or other.
Then some time later I got a 1995 BSDisc cdrom with FreeBSD and NetBSD, and also got some cdroms with Slackware 2.8, with Linux 1.2.8 on them. I had an ATAPI cdrom at that stage, so since neither BSD could read the cdrom (not SCSI), and Slackware could, I went with Slackware.
It does seem that Linux has played to a lower denominator than the BSds. That’s my observation.
I would like to think that some sort of arrangement could be made to dual-license the device drivers, so that Linux could make use of the *BSD’s, and the *BSDs could make use of the Linux ones – even the playing field a little.
Then, also in the interview discussing SCO’s lamentable (and thoroughly baseless and stupid) case, it is mentioned that SCO has BSD-licensed Research Unix. As far as I can make out, that only applies up to Seventh Edition – it would be interesting if they also BSD-licensed up to Tenth Edition, but I have no idea who owns that.
Does anyone know?
=> I still don’t understand… if Linux is not as stable as FreeBSD, why would you run COUPLES of Linux and willing to reboot it again and again. Why don’t you just wipe it and install your FreeBSD? Linux vs FreeBSD ?
Since, you quoted on my sentence too. I never said that I still keep Linux, which I said that I dumped it. I don’t have any of Linux in my boxes, so they all have Win2k Pro, WinXP Pro, FreeBSD, NetBSD and OpenBSD. Soon, will be Yellowtab and BlueEyedOS, when they release them.
Greg Lehey:
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.
Kind of funny to read this coming from you, as you have pointed out the fickleness of the ports system numerous times in your diary.
Let me for instance quote from your diary entry of the 18. of April 2003:
Started upgrading the ports on battunga. Somehow it’s touch and go whether port upgrades work at all. People seem to have forgotten that one of the aims of the FreeBSD project is to keep machines running as long as possible. battunga has now been up for 219 days, not very long, and it was a relatively fresh install at the time, but now half the ports have rotted to the point that portupgrade can’t recognize them.
On a Debian system, this kind of behavior would be simply unacceptable.
I should take some time to think of a better way.
The ‘better way’ requires a lot more work. Just take a look at the Debian Policy Manual: http://www.debian.org/doc/debian-policy/
Greg Lehey:
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.
A little nitpicky, but there is no such thing as fvwm2 anymore, unless you installed a very old beta. Once fvwm2 was declared stable, it became the official fvwm.
Anyway, I think GL makes a very good point here. WMs like fvwm and sawfish gives end users who are willing to put in a little effort an amazing amount of power to create a desktop in your own image. I would think an effort well spent for people who spend hours a day, year after year in front their computer.
Scott Long:
[regarding SMPng] 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.
Are there any benchmarks to support this ‘feel’? If you skim the Linux kernel mailing list, you will see that a number of different benchmarks are regularly posted, and the regressions and optimazations of the development kernel is being closely monitored. I see nothing like that in the FreeBSD-camp. Not on the public mailing lists, anyway.
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.
And how exactly does that helps with regard to the development of ‘new’ technologies like SMP, threading, NUMA, and so forth?
This might have been a good argument back in the mid-nineties when the free unix-systems were still very much playing catch-up, but it’s becoming less and less relevant. Besides, doesn’t actual deployment and number of eyeballs count for something?
Wes Peters:
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.
Really? Any specific reasons why? I mean, nothing has changed as far as the actual development model is concerned (though a number of hackers including Linus has adopted BitKeeper). It’s still very much Linus and his lieutenants. Nobody has been able to cram anything down Linus’ throat, that I’m aware of. Perhaps you know differently?
Paid Linux developers are paid to develop what their employers want, not what is best for the Linux system at this moment in time.
Of course, quite a few Linux hackers have been employed to do exactly what they previously did as a hobby.
Here’s Linus’ take on it: (http://australianit.news.com.au/articles/0,7204,5897985%5E15397…)
Part of the thing I like about the commercial side of it is it’s doing a lot of things I personally wouldn’t be interested in – and we do need it, it’s just it’s not what I do. So when I say commercial, in a way that implies I’m not very interested, that doesn’t mean it’s not a good thing. A lot of the commercial impact, a lot of the green stuff, that you need to make it successful.
The involvement of so many different entities is pulling Linux in many directions
Which is in exact accordance with Linus’ philosophy of software development. To let Linux go where people are willing to take it.
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.
And despite this supposed lower barrier of entry, there seems to be a lot more happening on the Linux side of things.
I mean, projects like KSE and SMPng which are supposed to be major new features in the 5.x branch aren’t even done yet, and even when they finally get there, noone really seems to know what kind of performance boosts they will bring to the table. In practice, that is.
There were a few other silly things in at as well that I just can’t be bothered to respond to.
Scott Long: [regarding SMPng] 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.
samb: Are there any benchmarks to support this ‘feel’? If you skim the Linux kernel mailing list, you will see that a number of different benchmarks are regularly posted, and the regressions and optimazations of the development kernel is being closely monitored. I see nothing like that in the FreeBSD-camp. Not on the public mailing lists, anyway.
The only benchmarks I’ve encountered regarding things like the performance of the I/O scheduler, VMM, and process manager were my own dbench tests, in which FreeBSD 5.0 held a commanding lead over Linux 2.4 in terms of total throughput.
Of course, even despite my own caveats, these were contested by many to the point that they were relegated to meaninglessness.
Neverthless, I’m yet to see benchmarks to the contrary.
Care to post some, samb? I’d be especially interested in system throughput benchmarks of Linux 2.6 versus FreeBSD 5.0.
Scott Long: 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.
samb: And how exactly does that helps with regard to the development of ‘new’ technologies like SMP, threading, NUMA, and so forth?
I don’t think anyone is arguing anything along the lines of FreeBSD having better NUMA support than Linux.
As far as threading goes, Linux and FreeBSD took two very different paths initially, and both were terrible implementations. Linux suffered awful context switching penalties with its _clone() based implementation, and FreeBSD’s threads couldn’t scale across processors, and didn’t provide support for multiple concurrent system calls from within different threads due to its userspace implementation.
Only now has Linux solved its threading woes with NGPTL. FreeBSD is trailing behind as far as adding KSE support to its userland libraries and finishing KSE support in the kernel (see http://www.freebsd.org/smp and http://www.freebsd.org/kse for further information)
As far as SMP goes, Linux and FreeBSD took a virtually identical approach. Both added initial support for SMP via a global lock on the entire kernel, the Big Kernel Lock (BKL) in Linux and the Big Giant Lock (BGL) in FreeBSD.
The main difference is in the move to a more modern and scalable SMP implementation. Linux has been slowly and progressively increasing its locking granularity. FreeBSD did virtually nothing until the 5.x series to move from the BGL. However, FreeBSD 5.0’s locking granularity is much finer than in Linux. Furthermore, the inclusion of scheduler entities will provide a very nice tradeoff between the advantages of both kernel and userland threads implementations.
But back to the issue at hand, I think, as everyone know, Scott Long’spoint stands out the most the most with FreeBSD’s VM subsystem, which is, at this point, a very well tuned and mature implementation. Linux has a very ecclectic VM implementation, especially in 2.6, utilizing new, untested, and untuned technologies almost exclusively. This lack of testing and maturity was what lead to the VM switch in the 2.4 series.
I think that primarily because of that very incident many people are wary about the code quality of the mainline Linux kernel. Certainly 2.4 has grown to be quite mature, but will we see a similar incident with 2.6? One can’t really know…
The bottom line is that FreeBSD’s legacy code base does not result in a development path that is markedly different from that of Linux. The simple fact remains that Linux has more zealots, therefore more mindshare, and consequently more developers and corporate support.
Scott Long: 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.
samb: And despite this supposed lower barrier of entry, there seems to be a lot more happening on the Linux side of things.
Well obviously, Linux has considerably more mindshare, and consequently it receives the bulk of corporate backing.
I think many FreeBSD users are sore that Linux began receiving this corporate backing not for its technical merits but simply for the sheer amount of zealotry surrounding it.
Of course, the result of such corporate backing and its significantly larger mindshare is that Linux has eclipsed FreeBSD in most areas.
samb: I mean, projects like KSE and SMPng which are supposed to be major new features in the 5.x branch aren’t even done yet, and even when they finally get there, noone really seems to know what kind of performance boosts they will bring to the table. In practice, that is.
No, no one does. The proof is in the code, and the code isn’t there yet. However, the following is known: Sun switched from an M:N threads implementation to a 1:1 implementation in Solaris. While Solaris’s M:N implementation didn’t support scheduler activations and faced many of the same I/O starvation issues that FreeBSD 4.x was experiencing, the overall opinion seems to be that the complexity required for an M:N implementation leads to deficient overall performance.
Of course, as I said earlier, the proof is in the code. For the time being Linux has FreeBSD beaten with the NGPTL.
And another thing is for certain: the KSE threads implementation will be a significant improvement over the userland implementation in FreeBSD 4.x. Whether or not it will outperform Linux and the NGPTL remains to be seen.
So which OS is “better” in terms of purely technical merit? Well, I think it’s important to keep the following in mind:
The majority of the systems running FreeBSD or Linux are going to be uniprocessor.
Most of these systems aren’t going to be under considerable load, therefore stability becomes paramount.
Can one really say one stable kernel line is “better” than the other one? I know many people who experienced system locks or systems entering virtually unusable states under intense VM load with both Rik van Riel’s VM and Andrea Arcangeli’s VM (in fact, some people I know recommended avoiding 2.4.13 as “unlucky number 13”)
As things have stabilized later in the 2.4 series, is there anything now worth mentioning?
One of my biggest with Linux remains to be the OOM killer. The OOM killer uses somewhat arbitrarily constructed algorithms (see http://linux-mm.org/docs/oom-killer.shtml for a full explanation of criteria) to determine which processes to kill in a low memory situation. This approach follows a surge of low-quality code being churned out primarily on the Linux platform which doesn’t properly handle low memory situations in userland applications.
Personally I think the OOM killer is a horrible decision on the part of the Linux kernel designers. Because of this on systems which don’t properly set ulimits, or even in other conditions where a memory exhaustion attack may be carried out on some service, the kernel will arbitrarily kill another process, often times a mission critical one.
The OOM killer seems to be an outgrowth of a very common practice in Linux kernel development, which is the desire to work around problems in userland applications via kernel hacks.
Personally, in a low memory situation I would rather see poorly written applications die in favor of more robust ones, or even better, have well-written non-mission critical applications exit gracefully.
I know there is a road map, but I would have liked a
question about its date confirmation (5.1, I mean). Also if we are to expect a 4.9 or not (at this point in time).
A big Thank You to the BSD persons for a really good
interview (and long to read). Thanks to osnews (Eugenia)
too.
______________
FreeBSD will never be a BSD ‘for the masses’.
Start with Linux if you can’t get used to BSD and then
switch later(you won’t regret it). FreeBSD never attempted
to rule the world (as said by the developers) don’t try to
change its mentallity now.
The basic administration GUI would be a nice development
but seems like it’s a time consuming task.
We don’t need a new installer but some gui admin
frontend would facilitate things a lot on basic changes to
the system:
boot options and maybe a ports and packages
installed *manager* with python and tcl/Tk, that could
read a file with the port version and other information,
but not a gui ports installer, the prompt is better.
Plenty of people like FreeBSD.
I very much enjoyed reading the interview. Once again, another fine interview.
Amen. The installer as it is has been one of the most easiest installers that I’ve ever used.
Eroll Flynn wrote
“PS. don’t tell me about OSX, I’m not willing to buy Apple’s hardware – too expensive.”
Well you should!!!!!!!!!!!
I began using FreeBSD in the spring of 2001. For years I had tried, unsuccessfully, to wean myself from MS Windows. I had tried RedHat 3.0 when it came out as well as debian and then Redhat again. But alas it never quite stuck. From what I remember my biggest problem was getting the system up and running and connected to my isp. The simple task of correctly setting up my modem was difficult. Everytime I read a how-to or explaination on some webpage I discovered that my system was setup differently than the system refered to. I always eventually got things working, but the process wasn’t enjoyable. When I installed FreeBSD everything wasn’t roses, but I wasn’t nearly as frustrated. The FreeBSD Handbook more than anything else contributed to my overall satisfaction with the Operating System. With the help of the HandBook I was able to not only connect to my ISP, but share the connections with my wife’s running windows 98. I had never been able to do that so simply before using Debian or RedHat.
I’ve found that the learning curve for FreeBSD is very linear and easy to pace as compared to Linux. I discover and remember things about FreeBSD naturally as opposed to having to write things down in order to remember them with Linux. As subjective as this might seem I feel differently using FreeBSD, the expected way to do things just seems to make sense.
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.
That was a horribly snotty comment, and one I find to be very untrue.
If anything, I’ve got to mess more with software on FreeBSD than on Linux, although admitidly that has more to do with a lack of carefull effort on the part of software developers than FreeBSD itself.
One thing that I hope could move most people from Linux to BSD is zeals like Samb. The way to discuss things in BSD land is obviously far more professional…
I’d be especially interested in system throughput benchmarks of Linux 2.6 versus FreeBSD 5.0.
So would I actually. The IO scheduler, process scheduler, VM and VFS work being done on the linux kernel in the past year are major changes. This doesn’t mean that they aren’t well tested though. Noone wants a repeat of the VM debacle (circa linux 2.4.10). Past mistakes are learned from quite often on lkml.
Only now has Linux solved its threading woes with NGPTL.
There were two approaches taken. IBM developers came out with NGPT (Next Generation Posix Threads), an M:N implementation, that performed around 2x as well as the older linuxthreads module to glibc. The glibc maintainer, (and RedHat employee) Ulrich Drepper,. and others whose names escape me wanted to keep the simplicity of a 1:1 implementation, and with the help of a simple and fast userspace mutex (futex) written by Rusty Russell, Drepper authored the NPTL (Native Posix Thread Library) pthread implementation, which is also binary compatible with the older linuxthreads implementation, differing in favor of closer posix compliance. Preliminary benchmarks show it performing 4x as well as NGPT, though it is not a finished product yet. Better info is <A HREF=”http://people.redhat.com/drepper/“>here .
Still remains to be seen which approach, M:N or 1:1 is simpler to code for and is more robust, and under what workloads.
Well obviously, Linux has considerably more mindshare, and consequently it receives the bulk of corporate backing.
I think many FreeBSD users are sore that Linux began receiving this corporate backing not for its technical merits but simply for the sheer amount of zealotry surrounding it.
It could also be the difference in licensing. It would be one thing for SGI to release XFS, a technology that they have invested much in, under a license that says ‘You may take this, and use it for your own commercial profit, no strings attached, total freedom’, and quite another for them to release it under a license that says ‘You can use this as you please, but if you make changes to it, you have to tell us what you did to make it better and share your improvements to this code you benefit from.’
In the case of the latter license, any advantage for possible SGI competitors (Sun, Microsoft, IBM), to take XFS and improve it and ship it with their respective OS’s is gone, due to the ‘viral’ aspects of the GPL. This works for SGI, and others. The BSD license was not appropriate for situations like this,. and this is likely what led to corporate interest in linux. The GPL would not work for Apple,. their situation is entirely different.
The rest of this particular sentiment is just mindless baseless trollbait.
( As an aside, I would have liked to see what fbsd-core thought of reiser4, if they had a chance to look at it. It is completely different from reiserfs. Also ext3, which journals metadata _and_ data.)
Most of these systems aren’t going to be under considerable load, therefore stability becomes paramount.
Can one really say one stable kernel line is “better” than the other one? I know many people who experienced system locks or systems entering virtually unusable states under intense VM load with both Rik van Riel’s VM and Andrea Arcangeli’s VM (in fact, some people I know recommended avoiding 2.4.13 as “unlucky number 13”)
This is a confusing statement. AFAIK 2.4.13 isn’t a shipping default kernel anywhere. Which means your friends built their own. If they are downloading and building their own kernels, I assume they also follow linux kernel development. If so,. they’d have been aware of the change in 2.4.10 and the various versions it took so solve some of those issues. I’d put this one as comparable to the users who are complaining about FBSD 5-CURRENT as being slow with debug on.
Also I think the term ‘stable’ is thrown around far too often by all. Stability needs to be measured, quantified. It means far different things to a sysadmin’s servers than it does to a end user who may have no concept of what real LOAD is. There are even seasoned admin who will probably never see what real load is like. Also,. as was mentioned before, there is only one FreeBSD, the various linux distributors often patch and modify their systems, and every bit of software on them. Stability issues on RedHat Linux do not mean that SuSE Linux Enterprise Server is necessarily deficient. It really is “Redhat’s Linux”, and “SuSE’s Linux”. In Slackware for example, there are no patches to things unless Patrick absolutely must. The default kernel shipped in that case may fall over in a VM corner case that RedHat’s kernel (which uses Rik Riel’s rmap vm) may hum happily along in.
In this example, the unity of FreeBSD is very advantageous. Any one linux distributor can soil the reputation of a kernel that only makes up one part of the system, and that is used by many others besides. The attention and detail in finding out the causes and reasons for problems ‘in linux’is not something everyone is willing to invest in. Or even should.
Personally I think the OOM killer is a horrible decision on the part of the Linux kernel designers.
Agreed. It sucked. Live, learn, yank the bad stuff out.
The OOM killer seems to be an outgrowth of a very common practice in Linux kernel development, which is the desire to work around problems in userland applications via kernel hacks.
Personally, in a low memory situation I would rather see poorly written applications die in favor of more robust ones, or even better, have well-written non-mission critical applications exit gracefully.
One userspace application that is well written but hasn’t always performed well in all situations on linux is X.
Often distributions (like Debian), would renice X to a higher priority to enhance the interactivity of X. It’s a hack that should no longer be necessary in 2.5. One more step along a path towards a good desktop experience for even the most demanding users. In short, with the speed of linux development (helped in the past year by various commercial interests, IBM, SGI, Namesys, Bitmover, etc) the things you dislike about linux may be gone tomorrow. Literally.
samb:There were a few other silly things in at as well that I just can’t be bothered to respond to.
Likewise, I saw a lot of little things in the article, the interviewers responses, and the comments thus far that are skewed, snide, false and more than just a bit off, where the developers glossed over their weaknesses and poked at others’ failings. Then again they’re here to represent FreeBSD and that is their concern. The interviewer wasn’t exactly unbiased either. All in all though, good reading.
I really really enjoyed this interview. Wes Peters responses were really on point. I would have liked to see less said about linux, and more about FreeBSD development, as I don’t tail their mailing lists. The commentary on SCO from fbsd-core was something I had wondered idly about previously.
>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.
That was a horribly snotty comment, and one I find to be very untrue.
Nope, it’s true. Why don’t you go to java/jdk14 and do the ‘make install’? You will find it out, which ports will not download. Because, you have to go website and agree the license, then download it. Drop the tarballs in the /usr/ports/distfiles/ and do the ‘make install’.
Pretty good interview. I thought a few of the Linux bashings were a bit off though, the whole “linux is fragmented and inconsistant” – well, I don’t know for sure but I suspect you’d have problems running NetBSD binaries on FreeBSD, and OpenBSD binaries on NetBSD. What is their point? There are multiple versions of *BSD too, and Redhat is no less a “system” than Red hat is. I think they underestimate the amount of integration and testing the distros do.
Oh, BSD users always seem to come out with “Linux zealots want to rule the world”, and use that to try and make the “we don’t care what the rest of the world thinks, we can use what we like” attitude seem more reasonable. I personally don’t agree. Wanting to rule the world is a sign of confidence in the product!
Anyway, to pretend that a FreeBSD or Linux user exists in isolation is false – whenever you hit problems with friends sending you word files, not being able to play the latest games, view movie trailers etc you have the problems caused by the rest of the world using non-free software. So, it seems like a defeatist argument really to say improving the desktop doesn’t really matter. I don’t mind them taking that approach, they should work on what they want, but I detect slight bitterness over the fact that Linux does.
The comparisons with MacOS were rather funny as well. MacOS X is not FreeBSD, not even close. Yes, it may use some of its code, but some of the responses seemed to be “that’s a solved problem, just use MacOS X”, or “if you want FreeBSD on a Mac, use MacOS” seemingly ignoring the fact that MacOS is not a free nor open platform like FreeBSD/Linux is.
I have scanner and scsi adapter for it.
But i couldn’t find driver for my scsi(sym53c416) in FreeBSD 4.x and I don’t see any support of it in FreeBSD 5.0
So for scanning I forced to use Linux!
Anyway FreeBSD really is the most productive and performant operating system I ever seen. Of course it lacks some features that Linux filesystems have. I don’t mean logging, softupdates are better, but it really would be nice to have features like dynamic inode allocation.
I really liked to try FreeBSD, but that harddisk kept timing out. After a reboot, everything works fine, but the more hd access there has been, the more timeouts come. That made the system wholly unusable so I threw it away.
Does anyone know what the problem is here?
I also tried NetBSD, but when I installed too much software I did not trust the 102% disk usage with -5xxx free blocks.
probably wrong geometry of disk
Eugenia, I didn’t mean the QUESTIONS were full of errors, but the ANSWERS. Editing their words never entered my mind, but I think that spelling errors, if not corrected, would at least be indicated as such, i.e.[sic], as is the custom in print media. To me, online journalism is print journalism in a different way and feel that as print articles are proofed so to are electronic ones.
As for the rest of my post, which WAS critical of the attitudes
manifested by those interviewed, but I think no more so than some others I’ve read here today (and, in fact, quoted or otherwise referred to by other posters) why was it modded along with the flame? Critique them I did and I also said specifically what I was referring to in the article.
As for the thumbnails, I really can’t recall having seen the thumbnails accompanying each section like that. Most distro reviews/articles do have screenshots in them, but I thought the thumbnails were particulatly illustrative. If I’ve missed them before, I’ve missed out then and I’ll need to re-read those distro reviews.
Only once response toward happy bsd users(happy for them means always bash linux) and immidiately response “i wish that linux zealots would disappear..”. Every time we have article about FreeBSD all that BSD lovers (of course linux haters) appear.
And they still claim that linux users are zealots. Just look
at that 70 responses and calculate how much contain someth. like “yes on BSD in start in 1 millisecond in linux 1 hour , linux crash, linux unstable”. Why u cannot love your OS without hating another ? I love linux but donot hate FreeBSD,
may be only some “suporters”. And most of the time they really doonot have linux on their disk , but there is something called Winxxxx.
However, FreeBSD 5.0’s locking granularity is much finer than in Linux.
That really isn’t true at all. Both Linux 2.5 and FBSD 5.0 continue to use a global lock although the former currently uses it far less than the latter (is seems this is largely because work to push Giant down hasn’t progressed very far yet.)
Linux has a very ecclectic VM implementation, especially in 2.6, utilizing new, untested, and untuned technologies almost exclusively. This lack of testing and maturity was what lead to the VM switch in the 2.4 series.
That isn’t a mistake which’ll happen again as organisations like OSDL have been performing extensive regression testing and benchmarking all throughout the 2.5 development process.
Linux’s VM has to stretch a lot further than FreeBSD’s – with Linux being used on everything from swapless embedded devices to SSI boxes with half a terrabyte of RAM there are a lot of cases to cover. A /lot/ of work has been done on the VM in 2.5 and current indications are extremely good.
FreeBSD’s VM is very robust within the <=4GiB PC/Server segment, but it hasn’t been tuned (or even designed) to cope with situations outside of this bracket. cf. the PAE work.
It’s also not fair to claim that the technologies used in 2.5’s VM are untested or untuned – the work done by OSDL, IBM and various other vendors combined with the leasons of the early 2.4 debacle mean that it’s far from untuned and untested.
I met Greg during a small FreeBSD meeting in 1996 in Cologne, at a time when he still lived in Germany and used to work on the Siemens-Nixdorf Unix kernel.
Interesting guy, professional attitude with a slight consultant touch, good at networking with people.
What you interpret as jerky or typical bad BSD style,
is rather part of a professional’s mindset in my opinion.
I always felt that FreeBSD was more about doing a free project with the high standards of industry, than the just for fun hacking approach and/or political (world domination) that I believe is typical for Linux.
It is worth listening to Greg.
Or take OpenBSD’s Theo DeRaadt.
I can only judge that guy from what I read directly from him and that was always competent and very worth to think
about.
So I believe that professional attitude and/or high technical competence seems to attract undeserved bashing from some parts of the Linux crowd.
Regards,
Marc
Slashdot got a story up about Debian GNU/NetBSD running on a sparc, just went through the Debian page seems they also got a project involving FreeBSD, it uses the kernel, libc and a number of kernel related bits and then the rest of the Debian system.
What i’d find interesting would be if somebody took the FreeBSD system and swapped in the Linux kernel, (yeah i know we got gentoo for a ports based system)
be interesting to compare a Linux system using glibc and one using FreeBSD libc
Nope, it’s true. Why don’t you go to java/jdk14 and do the ‘make install’? You will find it out, which ports will not download. Because, you have to go website and agree the license, then download it. Drop the tarballs in the /usr/ports/distfiles/ and do the ‘make install’.
Half the time I try that, something messes up, and I end up building from source anyway. Ports isn’t all it’s cracked up to be. It’s nice, but it’s far from 100% reliable. When I download a source distro, I do a make install and everything usually works, generally. Not so much with FreeBSD.
There was a distro of Tomcat that included -pthreads in it’s build, which caused Apache to freak out. The -pthreads was in there by mistake for the FreeBSD build (there was also -dlinux), which again isn’t any fault of the FreeBSD system, rather sloppy packaging.
So Linux source builds tend to go much more smoothly than FreeBSD builds, although that’s more of an effect of usage than Linux versus FreeBSD.
I recently was in a situation where we had to upgrade from Java 1.1.8 on FreeBSD to something more, oh, say modern. Why would I run a Linux compatibility mode on a FreeBSD kernel to get 1.4.1 working when I could just run Linux and eliminate the compatibility factor?
That takes an entire layer of things that could go wrong out of the loop. And that is important when you’ve got developers writing buggy code and when things go wrong they might say “well it’s the compatability layer”.
Eugenia,
Well done on the article. Thank you for providing a piece i enjoyed reading.
I have a misc question for you though:
What sys monitor app are you using (as shown on http://img.osnews.com/img/3300/freebsd1.png between gaim & gnumeric)? Is that also a theme on the app or standard look?
Thanks.
Great article! Kudos to Eugenia, and the FreeBSD participants.
Marc van Woerkom:
So I believe that professional attitude and/or high technical competence seems to attract undeserved bashing [of Greg Lehey and Theo DeRaadt] from some parts of the Linux crowd.
That’s probably partially true — but I’m a Free/OpenBSD zealot, and I think GL and TdR are both dinks. Technically very sharp, but dinks. Case in point:
GH’s very first words in the entire article: “It’s interesting that this is your first question: I would have considered it relatively uninteresting.”
Also, see this post by TdR about the DARPA-hotel situation:
http://archives.neohapsis.com/archives/openbsd/2003-04/1850.html
Now, I can be a dink, and it’s fun sometimes — but I try to never be both 1) a dink and 2) stupid, in the same breath. In the GL quote above, it’s factually and demonstrably STUPID of GL to claim that he’d consider the question uninteresting, while insulting the interviewer’s journalistic acumen in the process. The interviewer found it interesting enough to ask — finito benito, answer the damn question. He even gets wisely put in his place by Losh. As for TdR, he’s often an intelligent dink, which is entertaining, but in his reponse in the URL above he is a STUPID dink — ironic, considering the fact that he insults someone else for being inattentive (the caffeine quip).
About FreeBSD (and other BSD) ‘distros’:
PicoBSD: http://people.freebsd.org/~picobsd/picobsd.html
EmBSD: http://www.embsd.org/ (page down — alternate?)
ClosedBSD: http://www.closedbsd.org/
TrustedBSD: http://www.trustedbsd.org/
MicroBSD is no longer with us (RIP). There may be others.
Dan Langille: If that’s a long read, does it mean most osnews articles are just one or two paragraphs?
There’s some little green text under the article that says “Read More”. Click on that. Once you’re done reading the ensuing page, there’s some more little green text at the bottom. Bis, ad infinitum.
Quag7: If you live in the United States and are familiar with the US, think of FreeBSD as Canada, from a user’s perspective. A little different, but easily navigable (I may have just bothered some Canadians – my bad).
No insult here, except from residents of Toronto and Alberta — who might only be insulted because they’re so Americanised
And I guess this means that OpenBSD is like Québec! (before anyone thinks I’m being derogatory: I’m French-Canadian, and also an OpenBSD user).
novel is spelled novell. go check it out
http://www.novell.com
Bascule: However, FreeBSD 5.0’s locking granularity is much finer than in Linux.
phil: That really isn’t true at all. Both Linux 2.5 and FBSD 5.0 continue to use a global lock although the former currently uses it far less than the latter (is seems this is largely because work to push Giant down hasn’t progressed very far yet.)
I probably should say something along the lines of “theoretical locking granularity”
However I’m simply going off the number of locks present in each of the various kernel subsystems, and there are significantly more in FreeBSD.
From what I’ve read of recent Linux kernel ChangeLogs though (and due to overall stalls in FreeBSD development) Linux is currently farther along in removing the global lock. A considerable number of FreeBSD device drivers still require the Giant lock (see http://www.freebsd.org/projects/busdma/ for a complete list) whereas Linux has been working on removing it for the past three kernel revisions. So, in response to Linux being farther along than FreeBSD in removing the BKL, all I can really say is “One would hope so”
Linux could, in theory, have the BKL removed by the 2.6 release, whereas in the case of FreeBSD the driver rewrites would necessitate the removal as part of 6.0 at the minimum.
As far as kernel subsystems go, the only area where Giant continues to see considerable use is in support for non-native ABIs (see http://www.freebsd.org/smp/ for more information) This issue isn’t even comparable between Linux and FreeBSD as Linux doesn’t really need robust support for any ABI but its own.
That’s probably partially true — but I’m a Free/OpenBSD zealot, and I think GL and TdR are both dinks. Technically very sharp, but dinks. Case in point:
GH’s very first words in the entire article: “It’s interesting that this is your first question: I would have considered it relatively uninteresting.”
It’s interesting that you use “dink”: I would have considered it a relatively unknown word, as I can’t translate it via babelfish and you probably don’t relate to “double income, no kids”.
As I don’t know its exact definition, I can’t comment on it. 🙂
Fun aside. Perhaps I worked with too many dinks (I studied physics
in the past, that I consider it appropriate style. 
Regards,
Marc
‘Dink’ is Canadian for dick.
And the snarky comments here slagging Greg Lehey, in general, have been uncalled for and more telling of the posters’ characters’ themselves than of GH. I mean, really, the guy spends his time answering questions for you, and then in turn gets all this shit. A ‘thank you’ might have been more appropriate.
Our founder and chief system administrator, who is one of the biggest BSD advocates on the planet and trained most of us to do BSD system administration, told us that Lehey has tried several times to get him kicked out of the FreeBSD community out of sheer malice. I was not sure that I believed this before, it seemed far-fetched that someone who wrote a column called “Demon’s Advocate” would be so nasty. But now I do. Lehey really does come across like a snobbish, self serving jerk. -Sarah
This is from maillists (names do not really matter):
[ … some of irrelevant text skipped … ]
> > > We really need to think about efficiency. Our 5.x performance sucks.
> > > Really sucks. We’re being nickled and dimed to death by extra
> > > instructions here, there, and everywhere.
> >
> > Unfortunately 5.x attempts to run with a thread-safe kernel, and that
> > involves extra overhead to work around races that 4.x didn’t even have
> > to dream about. In theory the increased performance should come from
> > increased parallelism at the cost of increased overhead. If FreeBSD
>
> No, in theory increased performance should come from increased
> parallelism with no increased overhead. Any increased overhead is a
> bug. Linux 2.4 runs a thread safe kernel with less overhead than we
> have in 4.x. Its possible.
How are we going to achieve increased paralellism w/o increased overhead?
Discounting redesigning algo’s which would have been a win in the
non-parallel kernel as well. A mutex is far more expensive than an spl.
You have to protect against more things. Of course overhead is going to
go up.
> As we get closer to a stable branchpoing, and continue to suck, I’m
> starting to think we should start over.
Well, the Project is free to choose that if it wishes.
[ … a bit more of irrelevant text skipped … ]
Judging from theses, there seem to be some really serious problems and concerns within FreeBSD community. And frankly I don’t like it. *sigh*
Grog’s linux box running his sat connection probably went down again. He did sound a bit edgy during the interview though. If you do choose to judge him based on this interview, please do it after you run a google search on “Greg Lehey” and read the thousands of past threads on the FreeBSD mailing lists where he has personally helped people like myself with FreeBSD related questions over the years.
1. No bad mouthing or cursing.
2. No attacks to other users or news editors of this web site.
So those who agreed to the rules, still wish to belittle interviewees ?
Please show some respect for other people and their views/ideas/way of doing things ( i wouldn’t post this if there was no rules, but as you see above, there are! )
Hi !
First I want to say that this article is very great. Please more !!!
I have a look at FBSD since the late 3.x versions. I`m using Linux (Debian & SuSE).
The most nice things of FBSD is in my own opinion the speed, stability and topicality (apps) of FBSD.
But a little bit more comfort would be nice. Without spending time for additional configuration a useful shell prompt and dircolors like in Debian and SuSE woult be great. Ok, that are small things but things which make computerwork a little bit more pleasing. Also I couln`t find some graphical tools configurating my FBSD-System and handle my apps such as SuSEs yast2 or gnome-apt. (I just think at the graphical Layout and its features of yast2. Not the underlaying code !!!!).
An graphical Installer (alternatively) to the curses version would be nice too. I think the curses base Installer really good but a OS in The year 2003 shoud offer a graphical option.
Yes I no that these Points are not the core targets of developing FBSD. Working with Computers shoul make fun too. In Germany we have a Sentence which means “The eye is eating
too”. If you no what I mean. Beside all Features and technical questions we should not forget a sensible portion of user-friendliness.
Marc van Woerkom: It’s interesting that you use “dink”: I would have considered it a relatively unknown word
I’m trying not to be TOO vulgar here
The real word I was thinking of, I’d rather not commit to an OSNews post. I think I spend plenty of bile here already.
slang: the guy spends his time answering questions for you, and then in turn gets all this shit. A ‘thank you’ might have been more appropriate.
Does the “Kudos” I gave count? I do appreciate GH’s (and everyone else’s) input — that doesn’t suddenly make GH a SUPAR GUY. He didn’t seem too thankful that the interviewer gave him a public forum to express his view (unless his views are that the interviewer sucks).
I’m trying not to be TOO vulgar here
The real word I was thinking of, I’d rather not commit to an OSNews post. I think I spend plenty of bile here already.
If it is your opinion its ok to express that.
Thanks for dink-enlarging my vocabulary.
Regards,
Marc
Judging from theses, there seem to be some really serious problems and concerns within FreeBSD community. And frankly I don’t like it. *sigh*
This kind of message may seem discouraging, but it is par for the course of any large opensource project. What was the resolution in this thread,. if any? Trailing linux-kernel, one sees all manner of disparaging commentary on differnt approaches taken to solve a problem,. or to current problems.
(For example, dynamic allocation of device nodes has been something desired in linux for many years,.. noone has figured out a way to do it very well yet,. they’re considering making dev_t bigger in the interim).
Just because you see a few messages that are not terribly encouraging doesn’t mean that the Project is in any danger. To the contrary, it shows that it’s quite healthy :o)
“On a Debian system, this kind of behavior would be simply unacceptable.
I should take some time to think of a better way.
The ‘better way’ requires a lot more work. Just take a look at the Debian Policy Manual: http://www.debian.org/doc/debian-policy/“
I have tried Debian numerous times. Unfortunately I always seem to kill it. The apt-upgrade doesn’t always work properly and leaves the system half toasted. There have been times when I’ve somehow managed to toast the internal database that governs the packaging system so it has no idea what to update or upgrade. And NO, I have no clue what I did wrong. I was following Steve Hunger’s Debian GNU/Linux Bible. By all accounts a decent book.
Perhaps my hardware was flaky in this regard, but it’s happened to numerous systems I’ve tried Debian on. For all the much vaunted reputation of Debian, for me it just doesn’t work. A friend of mine seemingly has absolutely none of the issues I’ve had with it. Go figure.
I’ve had issues with the ports system in FreeBSD too. Normally this is simply a case of waiting a day or two for whatever is screwy to get fixed. Sometimes it’s a case of pkg_deleting the old program and reinstalling via the ports.
No system is perfect, and there will always be issues on any OS.
I’d use FBSD but want installation to be easy. Sorry. I see this issue like those who make a pretty good car and leave the Model-T type crank starter on it–“The rest of it works great” they say, “Our users don’t care!”
Certain writers produce a novel which appeals to a certain crowd, a certain market segment. Thereafter they write to that crowd. This is what the FBSD team seems to be doing. In so many words it was said that desktop usability is antithetical to the other functions this OS has been used for, and that the users don’t expect that.
I think the best idea is a system which is user-friendly like Mac, but runs on Intel/AMD chips–best of both hardware and software worlds.
I liked the interview very much.
I found that Greg Lehey didn’t come across at all well, in fact he came across as a very poor interview candidate and socially awkward. He seemed to frequently misunderstand or simply poorly answer questions (though in contrast Long and Losh came across very well).
The cheap shots shots made… e.g.:
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.
…are entirely puerile, quite stunningly stupid from a self interest perspective and display an amazing degree ignorance of modern software package management solutions.
No project needs a contributor with an immature attidue (and I belive that goes for commercial software development too).