Slashdot Mirror
Matt Dillon On FreeBSD 5.0 VM System And More
JigSaw writes: "OSNews features a very interesting interview regarding FreeBSD 5 with the guy responsible for the very good (technically) FreeBSD VM among other things. Matt Dillon talks about everything: FreeBSD 5, Linux, .NET and much more. Additionally, OSNews also includes two mini interviews with the NetBSD and OpenBSD head developers."
KSE = Kernel-Scheduled Entities
"The FreeBSD kernel-scheduled entity (KSE) project is striving to implement new kernel facilities that allow the implementation of SMP-scalable high-performance userland threading, as well as a new userland POSIX threads library (libpthread). KSEs are heavily based on a technology referred to as scheduler activations, and differ only to the degree necessary to support features that the original research does not address. The new libpthread uses as much of libc_r as is reasonably possible."
You should never NEED to compile GNOME or KDE for FreeBSD. They come precompiled and are an option during the install if you want one. Personally I did compile GNOME because I was bored. ;-)
But even if there was some reason that you could not use the code the way it is, FreeBSD has a very good ports tree that will download the current source, patch it for FreeBSD, compile it for your system, install it, and then clean up after itself. VERY SEXY... YEAH!
Well, I need to clean my underpants again. So I guess I am done ranting here.
---
"Do not meddle in the affairs of sysadmins,
for they are subtle and quick to anger."
The problem with Rik's VM isn't that it spends cycles here or there, it's that it is demonstrably broken in the field. If you load down a linux 2.4 box for any length of time with a lot of I/O, you will eventually see the failure mode of kswapd using 100% CPU forever. People are willing to try alternative VM systems because Rik hasn't proposed a solution to the problems that people are seeing with his system.
The question isn't some cycles here versus a lot of cycles there, the question is whether we will ever return from kswapd, or should we just power cycle the damn thing and see if it comes back up?
There was at least one mining company that changed their name to "linux services" in order to get a stock jump (which they did). I can't recall the name, but they have probably changed it recently anyway...
These linux-isms are popping up everywhere now, and just plain causing crossplatform (or at least differing unix platforms) problems.
For those who haven't figured it out yet, let me clue you in on a couple of facts:
1) The linux kernel is specific to Linux. If you make linux specific kernel calls then your program will only run under Linux. If you're writing a kernel module, then go for it. Otherwise forget it. It will only make you look stupid.
2) A Standard C Library (libc) is standard for every Unix and Unix-like operating system. For 99 systems out of 100, this libc will NOT come from GNU. If you write a program that makes use of glibc extensions, your program will not be portable. It will only make you look stupid.
A Government Is a Body of People, Usually Notably Ungoverned
I use NetBSD at Uni and Linux and home.
I like all the BSD's but FreeBSD is my favourite. However, my Linux box at home with kernel 2.2.19 on reiserfs is noticably more responsive when I have a lot of programs running.(similar hardware)
This is just my observation.
I am glad to see FreeBSD around it is a great OS.
Scheduler activations by Anderson et.al. paper
appeared way before Solaris introduced its LWP
based threads.
I will be really surprised, if Sun will sue
FreeBSD folks on that ground.
Why not just start a project on sourceforge?
http://cxfs.sourceforge.net/
It's not the latest, or all of, the code.
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
Matt is no stranger to Linux, having helped with the TCP implemenation in the Linux IPv4 network protocol stack. For confirmation, see linux/net/ipv4/tcp*.c on your favorite Linux machine.
Merged From Current. Most new features (esp big ones) go into the "current" version of BSD. Most users use the "stable" version because current isn't exactly stable... If current is a long time off from going throught a code freeze and becoming stable, then some of the new features that don't depend on new other parts get Merged From Current into the stable version that most people use.
The older SMP kernel had a "giant" lock on basically all of the OS. In theory more then one CPU could be int he kernel, in practice one would have a lock on Giant, and the rest would block waiting to get the lock (or would be running free in user code). The stable SMP code has a few other locks, and you can do a little in the kernel without hitting Giant. The SMP code in "current" pretty much (or totally) does away with the Giant lock.
Lotsa little locks is more like how Solaris works. I'm not sure if Linux has lots of little locks, or a hand full of mid-level ones (lots of little ones works better if they are all in the right place, a few mid-level ones works much better then the one giant lock, or lots of little ones in the wrong places).
And yes, it would have been nice to explain all the terms at the start of the article (even SMP which isn't BSD specific). I'll live though.
2) A Standard C Library (libc) is standard for every Unix and Unix-like operating system. For 99 systems out of 100, this libc will NOT come from GNU. If you write a program that makes use of glibc extensions, your program will not be portable. It will only make you look stupid.
This isn't most definately not true. The C library on Unices implements a set of standards, but which standards are implemented is up to the implementators. There are quite a few conflicting functions in between ANSI, SUS, SVID, BSD, ISO, and POSIX though most of them have to do with simple things such as errno values, but there are more serious cases such as the setjmp(3) conflict between BSD and POSIX.
Now, even without the conflicts, not every Unix has a complete implementation of these standards, especially given how frequently they've been coming out in recent years. POSIX 1003.1* for instance contains a good amount of optional functionality (SUSv2 made a lot of it mandatory however) including extremely useful features such as read-write locks for threads.
Now, that's not to say that I don't wish every Unix was at least was SUSv2 conformant, but OS specific code is a fact of life in cross-platform Unix development unless you are working on just Linux and *BSD. Calling someone stupid because they check to see if sigaction(2) exists because they want SA_RESTART to simplify their code just doesn't fly.
I look forward to the day when autoconf doesn't need to exist.
The world is neither black nor white nor good nor evil, only many shades of CowboyNeal.
Not just little tools.
Matt also wrote Dice C, which was a rocking good compiler, though admitedly not quite up to par with SAS's tool suite.
Once the Amiga market died, Matt gave Dice away to the community under the BSD license. You can still find it on Aminet today.
Matt. Want XML + Apache + Stylesheets? Get AxKit.