Linked by Eugenia Loli on Mon 28th Apr 2003 15:48 UTC
Original OSNews Interviews 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.
Permalink for comment
To read all comments associated with this story, please click here.
re: Bascule
by Alan Willis on Tue 29th Apr 2003 07:16 UTC

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.