Slashdot Mirror

1. FreeBSD router running NATD and IPFW
2. AVG Free Edition for system scans and e-mail
3. Firefox 1.5 for browsing the Internet

It is official -- Netcraft confirms: FSF is dying

One more crippling bombshell hit the already beleaguered FSF community when IDC confirmed that the FSF's mindshare has dropped yet again, now down to less than a fraction of 1 percent of all computer users. Coming on the heels of a recent announcement from Linus Torvalds, which plainly states that the Linux kernel will NOT be moving to GPLv3, this news serves to reinforce what we've known all along. The FSF is collapsing in complete disarray, as fittingly exemplified by founder Richard Stallman's hairstyle and rambling GNU/Everything Communist anti-developers'-rights "I'm-right-and-you're-stupid" commentary.

You don't need to be a Kreskin to predict the FSF's future. The hand writing is on the wall: the FSF faces a bleak future. In fact there won't be any future at all for the FSF because the FSF is dying. Things are looking very bad for the FSF. As many of us are already aware, the FSF continues to lose mindshare. In a recent poll on Slashdot, 97% of computer users preferred Microsoft to the FSF in terms of both ideals and the quality of their flagship products.

The GNU operating system is the most endangered of all the FSF's projects, having lost 93% of its core developers. Unable to convince users to use GNU's own "Hurd" kernel, the FSF has made several desperate attempts to capture mindshare by riding Linux's coattails. The aforementioned sudden (although not unexpected) denouncement of the GPLv3 by Linus Torvalds only serves to underscore the point more clearly. There can no longer be any doubt, the FSF is dying.

Let's keep to the facts and look at the numbers.

FSF founder RMS states that there are almost 7000 remaining GNU users. How many of those use Emacs? Let's see. Consider the bell-shaped curve of an IQ distribution graph. At best, Emacs users universally score two standard deviations below the mean, which means that they make up approximately 2% of any given sample. Therefore, there are 140 Emacs users left in the world. A recent article showed that GCC usage is declining among truly free operating systems in favor of ICC or even SDCC. There's GNU and Emacs, what else does the FSF produce aside from hot air?

Due to the troubles of the GNU operating system, abysmal adoption rates and so on, the GNU folks gave up on improving their code and instead began to concentrate on marketing their beta-quality OS. Theirs is just another unfinished open source project with a poorly designed interface and a lot of ideological baggage. It's no wonder that more and more businesses are turning to Microsoft.

All major surveys show that the FSF has steadily declined in mindshare. The FSF is very sick and its long term survival prospects are very dim. If the FSF is to survive at all it will be among juvenile political dilettante dabblers. The FSF continues to decay. Nothing short of a miracle could save it at this point in time. People just don't want to hear their message anymore. For all practical purposes, the FSF is dead.

Fact: The FSF is dying

Why not just keep the current job, and on side start helping out one of the cool open source projects, such is KDE, FreeBSD or Haiku?

If you are making tons of money, then there is not reason to give that up. Why not just save some extra money, and help out one of these cool open source projects. You could do anything you'd like to try out and do. You want to code Operating Systems? Then join FreeBSD team or Haiku team for example. Or if you like to make desktop applications, then join the KDE team and help them out.
Of course, if you are making a lot of money, these projects would be more than thankful if you donated some to them.

Be lucky that you have a good paying job. Its hard to find a job that pays better, however its easy to join one of the open source projects and do what you like.

Why not just keep the current job, and on side start helping out one of the cool open source projects, such is KDE, FreeBSD or Haiku?

If you are making tons of money, then there is not reason to give that up. Why not just save some extra money, and help out one of these cool open source projects. You could do anything you'd like to try out and do. You want to code Operating Systems? Then join FreeBSD team or Haiku team for example. Or if you like to make desktop applications, then join the KDE team and help them out.
Of course, if you are making a lot of money, these projects would be more than thankful if you donated some to them.

Be lucky that you have a good paying job. Its hard to find a job that pays better, however its easy to join one of the open source projects and do what you like.

nope

$0 is nice but I bought my first copy of Slackware long before I could download it, I even had to copy it to (I think 22) floppies from cdrom so I could install it.

And even after I have downloaded them, I've paid for FreeBSD, plan9 and Inferno.

Free as in Freedom is more important than you give it credit for.

Just one business case is that one can mitigate risk by having multiple OS vendors to choose from. I know that if my chosen OS goes kaput or gets litigated out of existence then I won't go with it. And it doesn't cost me a fortune to try out the alternatives.

In other news, Google can't quite own a googol of IP addresses. Which will, of course, be why we'll move to IPv8 at some point.

While I whole-heartedly agree with you on several of your points (especially FreeBSD's short straw) I see GPL Java going the way of w3.org HTML specifications and Microsoft's HTML "standard". One effective & correct way of doing things, but a more widely distributed audience of crap that makes the entire idea quite muddy and less effective.

Another large potential reason for keeping Java guarded is that it may really screw up Sun's enterprise stack if allowed to be GPL'd. Although I am in no way affiliated with Sun, I would suspect that this would be of a much larger concern than opening up Java alone. However, I can see a OpenJava site similar to OpenSolaris with a source code browser and using a similarly restricted CDDL license with the potential for adopting the new GPL3. Such a collaborative site could serve as the testing code and a base for future production quality code similar to the current Solaris model. This would enable quality back-ports (yay FreeBSD!) and seem to serve all needs I can think of, besides pure GPL2 zealots.

BTW, nice site Raven, I've visited frequently.

Also, FreeBSD released their status report for the forth quarter of 2005 yesterday.

http://www.ch.freebsd.org/news/status/report-oct-2 005-dec-2005.html

Oops. Here is the actual report.

FreeBSD just realeased its report a couple of days ago.

IIRC Linus has said that back when he started coding Linux that he was not aware of the *BSD project (Free only at that point I think but am not sure) and that if he had known of it he would have simply used that.

That's what he meant. He just said BIOS out of habit i'm sure. This is such a non-issue it's almost funny. There was a thread on the FreeBSD list about this actually...it boiled down to this:

(non-dev) "Will freebsd be able to support these?! I heard windows is having problems!!!"
(dev) "We've supported EFI for a while now. should be non-trivial"

Actual Thread here

I mean, if FreeBSD is already a majority of the way there without having any machines donated...i'm sure redhat should be able to do it in about a day without any problems. Seems like just them trying to get some media attention to me.

Strange, considering that FreeBSD has good support for wireless either via ndiswrapper or native drivers. If author's wlan card is based on Belkin F5D7050 v2000 chipset (it would have been useful if he posted more details, it is not that difficult find out which chipset it is based upon), it is supported by the ural driver. On FreeBSD, that is. But then, one of the goals of 6.0 release was to add and improve wireless support - both the native drivers and ndiswrapper.

go in to /usr/bin and you'll find the ever useful window(1) command. What a gem.. not sure how gnu screen compares :)

          THIS FILE SYSTEM TYPE IS NOT YET FULLY SUPPORTED (READ: IT DOESN'T WORK)
          AND USING IT MAY, IN FACT, DESTROY DATA ON YOUR SYSTEM. USE AT YOUR OWN
          RISK. BEWARE OF DOG. SLIPPERY WHEN WET.

Yeah, BSD licenses sure have killed a lot of projects.
That's just five minutes of searching for BSD licensed projects, I didn't look for MIT licensed projects.

One of the things I loved about the G4 powerbook I briefly had was that it could do useful work for 5 hours on a routine basis. My wintel laptop knocks out after about 3-4 hours (and if I'm running my favorite Free OS where power management isn't a priority, I'm lucky to get half that much).

Going from the low power G4 with circa 6 hours of battery life to a dual core Intel, regardless of all the good reviews of the Duo, makes me nervous. Apple has also been consistently mum about battery life on these units.

Battery life is listed right on the front page of the powerbook page in the apple store - up to 5.5 hours. The MacBook page says nothing about battery life - nor does any other page I can find on apple's website.

I would probably spring for one of these guys if I knew battery life was comparable to the lowly G4 laptops apple sells - hell even if they told me it would only get 3-4 hours of battery life. But the fact that they omit battery life after raving so much about performance per watt leaves me wondering if folks who are ordering these puppies are going to be severely disappointed when they find their shiny new toy conks out after playing a full length movie.

Can someone with one of these beasts tell us how long the thing runs unplugged?

Apparantly nVidia are awaiting Page Attribute Table support before they can release a FreeBSD/amd64 driver.

here here here here and here

There are long discussions on FreeBSD's lists about the complexities of handling the leap seconds.

the parent is a troll and an idiot, but you seem to be genuinely asking, so i'll take the time to answer.

GUI quality: The troll gives no indication of what or how he's measuring. it's difficult to deny that MS's GUIs are more polished, but there are numerous inconstancies. GUIs available on unix systems, including FreeBSD, tend to be more configurable. i'm inclined to agree that traditional X11-based GUIs are behind that of Windows, but that's a far cry from FreeBSD not having one, as the troll claims. also, OS X is widely agreed to be easier to use than Windows' and is unquestionably more technically advanced (we'll see what Vista brings).
Support: The troll's claims that Microsoft is "the world's most trusted software company" is simply laughable. major failures in security and stability in Microsoft products are legendary; their reputation for quality is thoroughly mediocre. they are, however, quite large and do stand behind their products (such as they are) for defined periods of time, which has a certain level of comfort associated with it. FreeBSD, on the other hand, has much higher initial quality and also has commercial support available from various sources. the open source nature of FreeBSD and the vibrant community existing around it also means particularly obscure problems are more addressable than they are in Windows, where you're left waiting for Microsoft to release a patch. again, there are trade offs to be made, but i think FreeBSD is a clear winner here.
Cost and convenience: It is undeniable that having the system pre-installed is a huge win for convenience. but the troll goes way off-track from there. first, XP is available pre-installed, but for how many architectures, maybe two (x86 and itanium)? FreeBSD is available on about a half dozen (NetBSD, incidentally, is available on dozens); this is particularly important in the sever and appliance realms, which are FreeBSD's primary target spaces. FreeBSD is available pre-installed at least on server equipment (i don't know of anyone who does workstations/laptops). the troll claims that XP is free, which is flatly false: the cost is bundled in the cost of the hardware. the troll is also implicitly defining terms like "every major manufacturer" to be only ones he cares about: get me an XP system from Sun or Apple, for example.
Stability/scalability:Again, the troll gives no measurements. at a minimum, XP has a reputation for being unreliable. in my experience at work, XP is a step down in stability and reliability from 2000, although both of these are still leaps ahead of any Microsoft system predating that (except probably DOS, which was highly stable by virtue of being so tremendously simple). DoS-style attacks which bring down the system remain common against XP and virtually unheard of against FreeBSD. FreeBSD is highly stable. the standard edition of XP also scales to 2 processors; special versions are available to get it up to higher number, but still pretty modest number of processors (i think it was 16, but i don't remember). i'm not sure specifically what SMP problems the troll is talking about (again, no specifics), but i've personally run FreeBSD on dual-processor SMB systems without issue and other BSDs on systems much, much larger than any Microsoft product has any hope of touching. for reference, note that BSD-based systems hold many places in the Top 500 supercomputer list, including several in the top 20; Windows can't hope to touch that level of performance.
Software availability: No, troll, not everyone uses it. but yes, it does have more software. for that reason, when i was Director of IT for our company, we continued to by Windows boxes; our accounting package wasn't available on any other platform. but this very much depends what you need. FreeBSD certainly runs a far cry more than vi. most things that'll run on other open-source systems like Linux,

sure they do.

8. Office embraces XML..

Actually... *BSD ain't so bad. I am sure this guy just pulled some sh*t out of his ass.
Here is some information about FreeBSD if you are interested.

There are some amazing compression programs out there, trouble is they tend to take a while and consume lots of memory. PAQ gives some impressive results, but the latest benchmark figures are regularly improving. Let's not forget that compression is not good unless it is integrated into a usable tool. 7-zip seems to be the new archiver on the block at the moment. A closely related, but different, set of tools are the archivers, of which there are lots with many older formats still not supported by open source tools

here

If you consider FreeBSD to be Unix, then consider chflags and securelevel. Together, they can prevent even root from having more than read-only access to a file. Same goes for OpenBSD, and I think NetBSD as well.

If you consider FreeBSD to be Unix, then consider chflags and securelevel. Together, they can prevent even root from having more than read-only access to a file. Same goes for OpenBSD, and I think NetBSD as well.

Didn't renowned geek babe Ceren Ercen work for LinuxCare at one time?

Anyone now how many packets a Linux router can forward per second?

How many it may be, FreeBSD can do more. :)

Mandatory Access Control has been available (but not turned on by default) in FreeBSD since its 5.0 release (Jan 2003). Documentation on using MAC is available in the FreeBSD Handbook. Manual pages are also available.

Mandatory Access Control has been available (but not turned on by default) in FreeBSD since its 5.0 release (Jan 2003). Documentation on using MAC is available in the FreeBSD Handbook. Manual pages are also available.

Mandatory Access Control has been available (but not turned on by default) in FreeBSD since its 5.0 release (Jan 2003). Documentation on using MAC is available in the FreeBSD Handbook. Manual pages are also available.

from the linked to web site:
"Mac OS X Tiger delivers 200+ new features which make it easier than ever to find, access and enjoy everything on your computer. Upgrade your Mac for $129."
$ 129 !!!
...for a second rate bsd.
why rank this higher than the real thing (more than 200 improvements), available for free (of course)
I can undestand than joe public could be taken in but, really, pcworld should know better

I have a stack of old boxen in my office doing reliable duty as (respectively) a NAT router / packet filter, an SMTP server, DNS server, SMTP server and SMB fileserver. They are all running OpenBSD except the fileserver which runs FreeBSD (because my SATA RAID controller shipped with a driver for FreeBSD). They all perform excellently, although Gallery is a bit slow on the webserver when doing things like resizing photos. The "fastest" one of the bunch is a Pentium II with 64 Mb RAM.

"Don't even try to compare that trashy xbox hardware to the linux OS."

No need to. Linux (mmm spaghetti code) is, indeed, a piece of shit/trash/etc.

Anyways, I have a present for you. A link to a real operating system just for you!

I wish people would stop stereotyping all people from Alabama as redneck, uneducated, slackjaw hicks. I am a male in my mid-20s, a democrat, have a college degree in both computer science and mathematics from the University of Alabama (currently #104 of the 1400 in the most widely referenced list. I live in Huntsville, a city of more than 160,000 residents speaking over 100 languages, home of Redstone Arsenal, NASA Marshall Space Flight Center, and the 2nd largest research park in the United States (4th in the world). I work for NASA at MSFC making an upper-middleclass living, live in the suburb of Providence and drive an Audi, not a tractor. I don't follow any type of sports, run FreeBSD on one of the many computers at home, listen to music on my iPod while getting my MMORPG fix via EDGE on my widescreen Powerbook while drinking overpriced coffee.

Are there people in the state that fit your stereotypical remarks? You bet. Can you honestly say that there are no people in your state that you are embarassed by? Of course you can't. So the next time you make your uninformed, stereotypical remarks - remember the nut doesn't fall far from the tree.

Why do embedded developers continue to imprison themselves in the GPL trap by using Linux, when there are better available alternatives that provide more freedom for developers?

Try the daemon book (that's a link to Chapter 2, the overview, which is online), or the 4.4BSD architecture manual (which will never be a bestseller).

Other than that, let me give you a start. If you want under-the-hood, this is a starting point. It's pretty technical.

Unix is a multitasking, multiuser operating system with a monolithic kernel. (Ignore whatever you don't understand about that sentence.)

The basic organizational unit of access privileges is the user. You know what a user is; I won't bore you with that. I'll just say that, almost everywhere, users are identified internally by a user id (uid), but displayed with their username (such as "piquan"). A significant user is root, uid 0. In general, root has access to everything.

The basic unit of execution under Unix is the process. When you run "ls", then while ls is running, it is a process, with a unique (during the time of execution) process id, or pid. You can get a list of all the processes on the system by running ps -ax. (Note that ps's flags vary from system to system.) (There's a smaller unit of scheduling, the thread, but that's largely irrelevant to our discussion.)

Each process has some information associated with it. This includes the arguments used when the program was run (such as "ls -a -l", which has three, including the command name). It also includes the uid of the user who launched it (real uid), as well as the uid for its authorizations (effective user id, or euid). These normally are the same, but can vary.

For instance, the Apache web server is normally started by root (as part of the boot sequence), but because it doesn't want bugs to give an intruder root access, it changes its euid to a dummy user ("nobody", uid 65535) as soon as it can.

This can work in reverse, as well. For ping to work, it needs to be able to access the interface directly. Since that also allows all sorts of nasty spoofing things, it's restricted to root. Since a normal user should be able to ping, the ping program is marked with a flag saying "set the euid of the process to root". That's called the suid flag, and we'll talk about it later. For now, my point is that the real uid and effective uid can differ.

An individual can perform computations without any help (other than from the MMU, like any other modern system), but to perform I/O with the user, files, etc, they need to talk to the kernel. The general interface between processes and the kernel is the syscall. This is like INT 21h in DOS: it's a request for the kernel to do something on behalf of the process's. Processes often make dozens or hundreds of syscalls per second. Common syscalls are read, write, open, close, exit (since the kernel manages processes, it has to be responsible for terminating them), etc. There are 456 syscalls in FreeBSD 6.0 (including a few that are obsolete and have been retired), but only about 200 are commonly used; the remainder are for highly specialized tasks.

The kernel is always resident. It's not a process. It's stored in a part of RAM that the CPU is set up to go to whenever a program executes a syscall. (CPUs have special instructions for executing syscalls, since every OS uses them.) The kernel has many tasks, including managing and scheduling processes, coordinating I/O, interpreting filesystems, paging virtual memory, etc.

For the purpose of task scheduling, each process can be in one of several queues. One of those queues is the run queue, which means that the process has something to compute. The kernel gives the CPU (or one of the CPUs, in the case of SMP systems) to each process on the run queue for a short time. The length of time is called the scheduling quantum, and how often the kernel gives the CPU to a given process is determined by a complex scheduler, but can be adjusted by the user using val

Try the daemon book (that's a link to Chapter 2, the overview, which is online), or the 4.4BSD architecture manual (which will never be a bestseller).

Other than that, let me give you a start. If you want under-the-hood, this is a starting point. It's pretty technical.

Unix is a multitasking, multiuser operating system with a monolithic kernel. (Ignore whatever you don't understand about that sentence.)

The basic organizational unit of access privileges is the user. You know what a user is; I won't bore you with that. I'll just say that, almost everywhere, users are identified internally by a user id (uid), but displayed with their username (such as "piquan"). A significant user is root, uid 0. In general, root has access to everything.

The basic unit of execution under Unix is the process. When you run "ls", then while ls is running, it is a process, with a unique (during the time of execution) process id, or pid. You can get a list of all the processes on the system by running ps -ax. (Note that ps's flags vary from system to system.) (There's a smaller unit of scheduling, the thread, but that's largely irrelevant to our discussion.)

Each process has some information associated with it. This includes the arguments used when the program was run (such as "ls -a -l", which has three, including the command name). It also includes the uid of the user who launched it (real uid), as well as the uid for its authorizations (effective user id, or euid). These normally are the same, but can vary.

For instance, the Apache web server is normally started by root (as part of the boot sequence), but because it doesn't want bugs to give an intruder root access, it changes its euid to a dummy user ("nobody", uid 65535) as soon as it can.

This can work in reverse, as well. For ping to work, it needs to be able to access the interface directly. Since that also allows all sorts of nasty spoofing things, it's restricted to root. Since a normal user should be able to ping, the ping program is marked with a flag saying "set the euid of the process to root". That's called the suid flag, and we'll talk about it later. For now, my point is that the real uid and effective uid can differ.

An individual can perform computations without any help (other than from the MMU, like any other modern system), but to perform I/O with the user, files, etc, they need to talk to the kernel. The general interface between processes and the kernel is the syscall. This is like INT 21h in DOS: it's a request for the kernel to do something on behalf of the process's. Processes often make dozens or hundreds of syscalls per second. Common syscalls are read, write, open, close, exit (since the kernel manages processes, it has to be responsible for terminating them), etc. There are 456 syscalls in FreeBSD 6.0 (including a few that are obsolete and have been retired), but only about 200 are commonly used; the remainder are for highly specialized tasks.

The kernel is always resident. It's not a process. It's stored in a part of RAM that the CPU is set up to go to whenever a program executes a syscall. (CPUs have special instructions for executing syscalls, since every OS uses them.) The kernel has many tasks, including managing and scheduling processes, coordinating I/O, interpreting filesystems, paging virtual memory, etc.

For the purpose of task scheduling, each process can be in one of several queues. One of those queues is the run queue, which means that the process has something to compute. The kernel gives the CPU (or one of the CPUs, in the case of SMP systems) to each process on the run queue for a short time. The length of time is called the scheduling quantum, and how often the kernel gives the CPU to a given process is determined by a complex scheduler, but can be adjusted by the user using val

I've got no problem learning the "how", but I really need to know the "why" before I will spend the valuable time re-learning my way around an OS.

Wow! You're a born Unix person. Really. Windows was made for people who don't care how it works, Unix was made for people who do. You're a perfect fit.

Unfortunately, the current crop of Unix advocates are too busy trying to shield the potential newbie from the "why" to realize how important it really is. If the "why" scares the newbie, then they're not a good fit for Unix, so we shouldn't be trying to fit them into an OS that they won't like.

Does anyone know any books that address the "how it all works together" part?

Someone else mentioned "Design and Implementation of *BSD", but that's too hardcore for your needs (unless you're a developer and are keenly interested in the inner workings of kernel data structures). I'm going to point you in other directions instead.

First, check out the set of newbie documents for FreeBSD, http://www.freebsd.org/projects/newbies.html. More technical, but much less so than the Design book, is the FreeBSD Architecture Handbook, http://www.freebsd.org/doc/en_US.ISO8859-1/books/a rch-handbook/index.html. Finally, "Learning the Unix Operating System", http://www.oreilly.com/catalog/lunix5/, is a very good introduction to Unix that doesn't hide away the "why" nearly as much as other introductory books do.

I've got no problem learning the "how", but I really need to know the "why" before I will spend the valuable time re-learning my way around an OS.

Wow! You're a born Unix person. Really. Windows was made for people who don't care how it works, Unix was made for people who do. You're a perfect fit.

Unfortunately, the current crop of Unix advocates are too busy trying to shield the potential newbie from the "why" to realize how important it really is. If the "why" scares the newbie, then they're not a good fit for Unix, so we shouldn't be trying to fit them into an OS that they won't like.

Does anyone know any books that address the "how it all works together" part?

Someone else mentioned "Design and Implementation of *BSD", but that's too hardcore for your needs (unless you're a developer and are keenly interested in the inner workings of kernel data structures). I'm going to point you in other directions instead.

First, check out the set of newbie documents for FreeBSD, http://www.freebsd.org/projects/newbies.html. More technical, but much less so than the Design book, is the FreeBSD Architecture Handbook, http://www.freebsd.org/doc/en_US.ISO8859-1/books/a rch-handbook/index.html. Finally, "Learning the Unix Operating System", http://www.oreilly.com/catalog/lunix5/, is a very good introduction to Unix that doesn't hide away the "why" nearly as much as other introductory books do.

I don't know whether to laugh or cry at Apple/Jobs lastest attempt to monopolize. Maube this time even the Apple devotess/apologists will sit up and notice. What has Apple actually contributed to the invention of the desktop computer? Almost everything that makes an Apple/Jobs computer - has been taken from others - at no cost to Apple/Jobs - and is based on the inventiveness and the sweat/work of others. OS X's Darwin is based on FreeBSD. Check out the Free BSD site http://www.freebsd.org/doc/en_US.ISO8859-1/article s/contributors/index.html and you'll see that Apple/Jobs neither contributed money or staff to the development of FreeBSD. In a similar fashion the GUI, the mouse, ICONS all came from Douglas Englebart in the early 60s and in the following years at Xerox. Check out http://arstechnica.com/articles/paedia/gui.ars "The combination of Smalltalk and the Alto was essentially a modern personal computer with a very similar graphical user interface to the ones we use today. Altos had networking and could send e-mail to and receive it from one another, and seemed ideal for an office environment. Many of the PARC team wanted Xerox to market the new, cost-reduced Alto III as a commercial product (the original Alto was never available for sale) but Xerox management declined."

What features does FreeBSD 5 have over FreeBSD 4 that make the former "simply more easy to use" ?

If it's features such as rc.d as rc(8) or rescue(8), then those features were obtained from NetBSD, even if the history section in those two manual pages neglects to mention this heritage.

What features does FreeBSD 5 have over FreeBSD 4 that make the former "simply more easy to use" ?

If it's features such as rc.d as rc(8) or rescue(8), then those features were obtained from NetBSD, even if the history section in those two manual pages neglects to mention this heritage.

If you look at the GENERIC kernel config file for 6.0 Release, it shows the ULE scheduler is not enabled by default, the 4BSD scheduler still is. http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/s rc/sys/i386/conf/GENERIC?rev=1.429.2.3.2.1&content -type=text/plain&only_with_tag=RELENG_6_0_0_RELEAS E The basic benefit the ULE scheduler was designed to have is O(1) performace for the SMP case. Here's the BSDcon '03 whitepaper Jeff Robertson wrote about ULE http://www.chesapeake.net/~jroberson/ULE.pdf Yes it's been fixed up a lot, you can read kerneltrap's coverage of it a few times, but you'd have to dig into the mailing lists to see why it is not default still, which I didn't do.

In practice, a huge corporation that gets caught using GPL'd code would have the FSF helping out whomever the author is

So there is little or no prospect of any "GPL infringement" lawsuit in which the plaintiff doesn't have to prove material breach of contract under the most unfavorable construction the defendant can justify.

Of all organisations in the world, be assured that the FSF is the least likely to sue you for anything less than brazen cut-and-pasting of entire programs, despite your personal vendetta against them.

You should go to at least 4.11, now. And probably start making plans to leap to 6.x when 4.x rolls of the security teams watch list.

The FreeBSD versioning takes a little getting used to. If you want to cvsup to FreeBSD 5.4-RELEASE, you'd cvsup to RELENG_5_4. RELENG_5 is always pointed at 5-STABLE, which is the development head for 5.

So, for FreeBSD 6-RELEASE you'd cvsup to RELENG_6_0.

See FreeBSD's releng page for details.

I know you're only trying to be funny, but you'll need to at least upgrade to 5.3-RELEASE before upgrading to 6.0.

So those 5.4 discs won't go to waste after all :)