“With the release of FreeBSD 5.5 and FreeBSD 6.1, the second quarter of 2006 has been productive.” The status report contains a lot of information about (for example) DTrace, Embedded FreeBSD, GJournal, XFS for FreeBSD, and the new BSDInstaller.
“With the release of FreeBSD 5.5 and FreeBSD 6.1, the second quarter of 2006 has been productive.” The status report contains a lot of information about (for example) DTrace, Embedded FreeBSD, GJournal, XFS for FreeBSD, and the new BSDInstaller.
With the release of the 5.x line of FreeBSD came quite a lot of grumbling and criticism. The developers decided to add a very large number of new features all at the same time. This had the effect of lowering the performance and reliability significantly as compared to 4.x, due to the amount of time that needed to be spent on cleaning up the oodles of new code.
Now, however, we are well into the 6.x cycle. The 6.x branch can be thought of as the coming to maturity of all the features that were added to the 5.x line; it is a logical continuation from 5.x, but with much improvement in performance and stability. Some of the most important new features include better hardware support, including wireless; better 64-bit and multiprocessor support; and a faster filesystem (this is easily noticable when playing 3D games, for exmple, and particularly when compiling software from source); as well as lots more technical stuff.
As a desktop operating system, FreeBSD requires the same level of work to set up as a Debian or Slackware Linux system does, so don’t expect everything to be autoconfigured (that’s what the PC-BSD and DesktopBSD projects were initiated for). Also, as FreeBSD is not backed by a large corporation and does not have the same presence and mindshare as Linux, there are more hardware compatibility hurdles than with Linux distros (including ATI video cards, Palm handhelds, and cutting edge hardware in general), so you do need to check to see if your hardware is supported. But with it’s UNIX heritage and now having over 15,000 packages available, it is a serious choice.
So it’s great to see the development continuing with things like DTrace, TrustedBSD, and further improvements in wireless networking as well as kernel enhancements and the summer of code projects.
For all those who like to experiment with operating systems and who haven’t already done so, I strongly recommend giving FreeBSD 6 a thorough try. If you hate and/or don’t want to spend time configuring things, take a look at PC-BSd or DesktopBSD. These projects are still relatively new, but are maturing fast and are certainly already at the point where they are usable for the average computer user. They include easy setup of stuff like video codecs, CD and USB drive automounting, printing, java, flash, as well as setting up X and the KDE Desktop Environment. They also feature more user friendly software installation methods.
Very nice comment, thanks Mr. Gibson
On a minor note: We don’t have 15,000 packages. We have Ports (15,166 exactly, see http://www.freshports.org/ ) but we not always have a package available because the port is marked IGNORE/RESTRICTED/FORBIDDEN etc.
Sometime during the 4.x branch, a big war broke out between Mathew Dillon and the rest of the FreeBSD Core team. The FreeBSD Core chose to go the POSIX compliant route. Mathew Dillon was on the opinion that the approach was not practical and the team was taking the wrong route. He argued, M:N threading (KSE) was too complex, ULE was useless, and the NUMA architecture is the future.
It turns out he was right. Fast forward to today. ULE is both unstable and generally slower than the optimized BSD scheduler. KSE is also very unstable, causes all kinds of performance issues, and creates unmaintainable code. The idea of using ULE as the default schedular was dropped around the time of 5.1R. M:N threading and all the kernel bloat workarounds will probably be dropped in favor of 1:1 threading by the time of the 7.0 release.
While these experiments were failures and rather painful for the FreeBSD team, a lot of the other projects the project underwent were a resounding success. Giant Lock has been basically pushed out of the kernel, A new ncurse installer will replace sysinstall, the BSD scheduler is being optimized, 1:1 threading has made great strides (libthread), and the kernel code is becoming very clean (especially after removing all the KSE workaround code.)
While I am anxiously waiting for the 6.2 release, FreeBSD 7 will be the release that FreeBSD 5 should always have been. It will allow FreeBSD to compete against Linux performance-wise and it will allow FreeBSD to scale to 32 processors and higher. Finally, it will allow the team to once again focus their energy in one direction.
Sometime during the 4.x branch, a big war broke out between Mathew Dillon and the rest of the FreeBSD Core team.
At one time or another, Matt is feuding with someone. It’s in his nature to aggressively depend his position. But I think “big war” overstates the feud over 5.x direction.
It turns out he was right.
Well, the jury’s still out on most of your points, but he was certainly wrong about at least two things:
1) Eventually you have to go to M:N scheduling if you want an efficient scheduler for certain workloads. It’s the only way to avoid certain convoying problems. Maybe 5 was the wrong release for it, but it’s inevitable.
2) The future is definitely not NUMA, at least not in the sense that Matt usually means. With the exception of computer-server “grid” clusters, the future is small processor count on-chip SMPs, at least for the next 5-10 years.
ULE is both unstable and generally slower than the optimized BSD scheduler.
I don’t think so- PC-BSD is using ULE scheduler by default and all users report that PC-BSD feels much faster than vanilla FreeBSD on same hardware. No problems with crashing or whatsover on proper hardware- with buggy drivers or with some poorly ported app you have troubles on all systems.
Users may report that PC-BSD is faster, but I’d like to see benchmarks to prove it. It’s already been proven that the ULE scheduler performance isn’t up to par. Considering that the ULE scheduler doesn’t have an owner you shouldn’t expect anything else. ULE isn’t really unstable but it doesn’t beat the 4BSD scheduler in most benchmarks I’ve seen.
ULE isn’t really unstable but it doesn’t beat the 4BSD scheduler in most benchmarks I’ve seen.
How do you benchmark desktop feeling? And all benchmarks are useless in real life…
“How do you benchmark desktop feeling? And all benchmarks are useless in real life…”
You can “benchmark desktop feelings” by timing CPU utilization, time it takes to finish tasks, time it takes to open applications, time it takes to compile applications, number of skips of programs, etc. If it takes ten seconds to open an application, you can measure it. If your application keeps pausing because the scheduler decided to do something else at that time, you can measure this too.
Also, benchmarks are not useless in real life. That statement is very similar to saying scientific research is useless in real life. While you should probably ignore “scientific research” on the health benefits of smoking from the tobacco industry and while you should be very skeptical about the “scientific research” from Joe SixPack and his conclusion after watching five friends smoke, you might want to listen to what real researchers might actually have to say about a topic. The same is true for FreeBSD and the benchmarks they run themselves to measure performance and to give themselves insight in which direction they want to go.
I can’t seem to find it in Google. What do they mean by Giant and Giant-less?
They are refering to the “Giant Kernel Lock”. It’s a lock that’s used throughout the kernel and tends to cause SMP systems to serialize with lots of contention.
“Giant-less” means using finer level synchronization, so that subsystems use appropriate locks for their purpose, so that something trying to acces, say, the page table lock, doesn’t stall something that’s doing disk i/o and not modifying page tables.
There’s an art to finding the “right” level of synchronization in a kernel. Not fine grained enough, and you find unrelated parts of the system waiting on each other, because they’re all grabbing the same lock. Too fine grained, and you find subsystems wasting time grabbing locks that are never contended for. Both make mulitprocessor systems performance scale more poorly.