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."
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."
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
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.