FreeBSD 7.0 Bests Linux In SMP Performance

cecom writes "After major improvements in SMP support in FreeBSD 7.0, benchmarks show it performing 15% better than the latest Linux kernels (PDF, see slides 17 to 19) on 8 CPUs under PostgreSQL and MySQL. While a couple of benchmarks are not conclusive evidence, it can be assumed that FreeBSD will once again be a serious performance contender. Some posters on LWN have noted that the level of Linux performance could be related to the Completely Fair Scheduler, which was merged into the 2.6.23 Linux kernel." Update: 03/06 21:32 GMT by KD : An anonymous reader sent in word that Linux kernel developer Nick Piggin reran the benchmark today and came to a different conclusion: In his benchmark Linux was faster than FreeBSD.

Comments

Well

[morgan_greywolf]

I'd be interested to see results from pre-CFS kernels.

Not that FreeBSD hasn't made major performance improvements.

Also, I think that a database test isn't a complete picture. For example, some OSes like IRIX or Mac OS X perform very well on streaming of local video and audio, but I wouldn't benchmark Oracle or PostgreSQL on either.

Re:Well

[archen]

And I like the article summary stating that FreeBSD may now be considered "a serious performance contender". Like FreeBSD was 1000% slower than Linux? Most servers spend their time spinning their wheels anyway, generally I'd rather look at security, how it handles under load and other metrics than whatever "performance" is considered in this instance. Linux is good for some things, BSD for others.

About the only really good news here is that MySQL performance is actually adequate. As MySQL has always been a dog (usable, but a dog) on FreeBSD, the general rule of thumb was that if you needed MySQL you should stick to Linux; all other factors being equal. So now at least we can get down to other factors that are important instead of one database that performs poorly on one system.

Re:Well

[Zpin]

The linked PDF contains pre-CFS kernel benchmarks. Conclusion:

The new CFS scheduler in 2.6.23 is "Completely Fair" ...to FreeBSD

Re:Well

[saleenS281]

You also wouldn't run Oracle or PostgreSQL on them unless you wanted to lose your job. The test is a great test for linux vs. freebds, because it's the type of environment where they'd compete.

Re:Well

[calebt3]

Most servers spend their time spinning their wheels anyway And then along comes a /. article...

Re:Well

[Anonymous Coward]

You don't need to test pre-CFS kernels...here you can find a linux vs freebsd benchmark where linux tops freebsd: http://www.kernel.org/pub/linux/kernel/people/npiggin/sysbench/

Re:Well

[makomk]

Acoording TFA, FreeBSD didn't even have proper SMP support until relatively recently. Until 5.0, released in 2003, only one CPU could run kernel code at once. (To be fair, I think Linux still hasn't fully got rid of its own Big Kernel Lock, but...)

Re:Well

[SanityInAnarchy]

Yep. Thanks, Linus, for dropping the pluggable schedulers in favor of The One Scheduler...

Re:Well

[mr_mischief]

That benchmark shows some sound methods and shows Linux ahead in performance. As TFS states, a benchmark or two doesn't mean too much. What one can take away from this is that under some tests a prerelease of FreeBSD beats a released Linux kernel and under some others a prerelease Linux kernel beats a prerelease FreeBSD kernel. That means there's probably not enough difference by the time both kernels are released to declare a clear winner based on performance, and if so then not by much. Other factors are probably more important than a vanishingly small performance advantage anyway, but using either FreeBSD or Linux is much faster than some of the other options.

Re:Well

[kkenn]

Just to clarify, 7.0 is now released, so we're not comparing "prerelease FreeBSD" to Linux.

Re:Well

[Flodis]

Made me laugh out loud for real, not just chuckle. I wish I had modpoints. Thank you, sir.

Re:Well

[illumin8]

To be honest, when using Linux for database applications, you shouldn't use the Completely Fair Scheduler. I build and tune Oracle database servers for a living, and I've researched this very thoroughly. Take it from the master himself, Mr. Werner Puschitz:

The Completely Fair Queuing (CFQ) scheduler is the default algorithm in RHEL4 which is suitable for a wide variety of applications and provides a good compromise between throughput and latency. In comparison to the CFQ algorithm, the Deadline scheduler caps maximum latency per request and maintains a good disk throughput which is best for disk-intensive database applications. Hence, the Deadline scheduler is recommended for database systems.

Granted, this is for Oracle database, which may be different than Postgres or MySQL, but I'd be willing to bet that database workloads are very similar between Oracle and the other databases.

Also, this is a common tactic of people producing benchmarks when they want to make one system or OS look better: Tune the one they want to win so that it is optimally configured for the benchmark, and leave the one they want to lose at the default setting, or worse, just tune it so that it's performance suffers. In this case, leaving Linux at the default setting of CFQ scheduling is not good for database applications.

Re:Well

[illumin8]

The linked PDF contains pre-CFS kernel benchmarks.

Prior to 2.6.23, the 2.6 kernel used the Completely Fair Queuing (CFQ) scheduler, which was also bad for database workloads. Please see this note by Werner Puschitz:

The Completely Fair Queuing (CFQ) scheduler is the default algorithm in RHEL4 which is suitable for a wide variety of applications and provides a good compromise between throughput and latency. In comparison to the CFQ algorithm, the Deadline scheduler caps maximum latency per request and maintains a good disk throughput which is best for disk-intensive database applications. Hence, the Deadline scheduler is recommended for database systems.

Also note that RHEL4 (RedHat Enterprise Linux 4) uses kernel 2.6.9, which was pre 2.6.23 and CFS.

Re:Well

[ultranova]

I'd be interested to see results from pre-CFS kernels.

And I'd love to see how the last -ck patchset compares. CFS began as a politics-driven copy of RSDL, so it would be nice to see which actually performs better. Just to conclude that particular flamefest...

Re:Well

[setagllib]

CFS is a thread scheduler, CFQ is a disk IO scheduler. They are independent but can coexist (and in many modern distro releases, do so by default). Both seem to be focused on desktop user experience, although they're not exactly "bad" for servers either.

Re:Well

[setagllib]

Once again, CFS is a thread scheduler, CFQ is a disk IO scheduler. They're completely different things. Uust how will did you research it?!

Re:Well

[illumin8]

You're completely right and I was incorrect. Thanks for clarifying this for me.

Re:Well

[mr_mischief]

Just to clarify, the benchmark document says October 2007, and the release was February 2008. Where's the changes file to show what changed in the meantime? Plus, the tested scheduler is not yet the default scheduler in the released version.

Re:Well

[bugg]

Having a threaded kernel or having fine-grained locking is hardly a reasonable barrier for "proper SMP support." If I have two processors and they can be both running code at the same time, it's SMP support - everything else is just icing.

On virtually every CPU bound application, the time is spent not in the kernel, but in userland.

finally

[Zashi]

I can finally make full use of my quad-core toaster!

That toast isn't going to serve itself!

Re:finally

[BitZtream]

Your comment would have been funny if we were talking about NetBSD. NetBSD is the one that runs on everything, including a toaster.

Re:finally

[UbuntuLinux]

Hello. I don't believe you know me, but you might be able to help. I use Ubuntu Linux, and I am helping the daughter of a friend to install Linux onto her PC this evening. I have never really spoken to a girl before, and was thinking that maybe if I made a joke, it might break the ice. You are obviously excellent at humour, and I was wondering if you could give me some tips? For instance, it is inevitable that something will go wrong during the process, and I was thinking that maybe if I said something like 'this is almost as unreliable as my beard trimmers!' then it would demonstrate that I am a funny guy. Can you offer any kind of critique of this line, or offer any other advice?

Re:finally

[thePowerOfGrayskull]

Holy carp, that was funny. One of the few comments that's gotten me to laugh aloud for more than a half-second. Oh, to recant my hastily-spent mod points...

Re:finally

[revans2]

FreeBSD did just get arm support so you might have a good chance at getting it to run on a toaster.

Re:finally

[rubycodez]

be sure to install a distro that will necessitate you coming back again and again, you know, one of those where the package maintainers constantly break shit.

Re:finally

[JK_the_Slacker]

Depending on which SMP chip you're talking about, FreeBSD will now run 15% faster than Linux on your toaster.

Re:finally

[MadMidnightBomber]

Stick to the tried and tested - "is it hot in here, or is it just you?". Honestly.

Re:finally

[ScrewMaster]

"Why, yes ... I am glad to see you."

Re:finally

[motokochan]

So, like Debian Unstable or Gentoo?

It's that year again!

[n3tcat]

Maybe now we can finally declare year of the linux desktop!

Wait, what?

Re:It's that year again!

[leuk_he]

Did you note that the report was dated 20 OCT 2007.

What year again?

Re:You don't have to be Kreskin

[morgan_greywolf]

Nothing against Linux, but it's hardly an apples to apples comparison. Exactly. I mean, who cares about performance on a dying OS? ;)

Dual Core

[Anonymous Coward]

Does this apply to single processor machines with dual cores or just multiple processors?

Re:Dual Core

[morgan_greywolf]

Does this apply to single processor machines with dual cores or just multiple processors? Interesting point, but from the OS kernel's point-of-view a single-processor, dual-core machine looks exactly like a machine with two processors. So it runs the same code to support SMP whether we're talking single-processor dual-core or multiple processors.

IOW, if there is a performance difference, I would expect it to show up exactly the same in both FreeBSD and Linux (as well as any other OS that supports SMP).

Re:Dual Core

[AvitarX]

Don't dual core CPUs share components (cache maybe?) that an aware OS can exploit for performance improvements?

The same way an HT CPU shows up as 2 CPUs (with disasterous effects) unless the OS is away and can properly exploit it?

Re:Dual Core

[bhima]

From reading the PDF I have the impression it applies to both multi-cores and multi-processors. I don't know how it applies to hyper-threading (or whatever they're calling it these days) though... which I suppose will become interesting again in a few months when Intel releases the CPUs that support 2 threads per core. Or, are those out now?? There are so many different Intel CPUs out now I can't keep up with them.

Re:Dual Core

[Fweeky]

Yes; Jeff Roberson, the author of FreeBSD's new ULE scheduler, wrote a bit about it on his blog a couple of months ago.

Re:Dual Core

[TeknoHog]

Don't dual core CPUs share components (cache maybe?) that an aware OS can exploit for performance improvements?

The same way an HT CPU shows up as 2 CPUs (with disasterous effects) unless the OS is away and can properly exploit it?

Some dual cores share L2/3 cache, but not all. Another important factors are the shared connections to external world, such as memory. So I presume inter-CPU communication is faster, but external communication can be slower.

That aside, HT is a hack which should not be compared to dual core systems at all. In fact, "dual core processor" is a rather silly marketing term, because it means "two processors on one piece of silicon". In other words, you could interpret the phrase "dual-core CPU" as "a CPU that contains two CPUs".

Re:Dual Core

[Wdomburg]

Have you ever looked at a block diagram of the predominant dual core designs? They're not simply "two processors on one piece of silicon". Both Intel and AMD used a shared cache design with a single connection to the system bus (FSB and HT, respectively). In the case of AMD, it also means a shared memory controller. It's a real difference with real performance and power implications, not a "silly marketing term".

Now if you complained about Intel shoving two dies into a multi-chip package and calling that quad-core, I'd agree with you. All the reduced bandwidth of a shared connection to the FSB with none of shared cache! Sign me up!

Re:Dual Core

[kkenn]

Yes, there can be different challenges in how to optimally schedule processes depending on what resources (e.g. cache) are shared between multiple CPU cores. The ULE scheduler does a good job in all cases though. In 8.0 Jeff has just committed patches that make use of explicit knowledge about CPU topology, which improves performance in some configurations (e.g. a lot on 16-core xeon systems).

Re:Dual Core

[TheLink]

Your HT = Hyperthreading or Hypertransport?
His HT = Hyperthreading or Hypertransport?

Re:Dual Core

[AvitarX]

The only comparison I was trying to draw to Hyper Transport is that it requires OS awareness to appear as anything different than 2 processors. The fallout of the OS getting this wrong is very different though, with one possibly tanking performance, and the other simply not running as optimally as possible.

Re:Dual Core

[TeknoHog]

Both Intel and AMD used a shared cache design with a single connection to the system bus (FSB and HT, respectively). In the case of AMD, it also means a shared memory controller.

I thought I just said that, though you're being more precise with the terms.

It seems to me that the shared cache is a necessity borne out of the shared outside connection (FSB/HT). Thus, when you try to save space and money by putting two CPUs on the same die, you end up with the dual core design. Perhaps I don't view L2/3 cache (and possibly memory controller) as the defining parts of a CPU. I'm assuming the rest of the CPU, the actual processing unit, hasn't changed much, but I could be wrong.

Re:Dual Core

[AcidPenguin9873]

Both Intel and AMD used a shared cache design with a single connection to the system bus (FSB and HT, respectively).

In AMD's case, the shared cache sits on the other side of the fully-connected crossbar, which allows intra-core communication to happen without using HyperTransport at all. So yes, it's shared, but each core has its own "port" to it and can access it independently. Same deal for the Intel shared L2. The phrase "single connection to the system bus" is misleading because it implies a bottleneck where there (most times) isn't one.

In the case of AMD, it also means a shared memory controller.

The memory controller on Intel systems is shared as well. It's just sitting on a different chip, across the FSB.

In fact, once you move to multi-socket, AMD systems generally have as many memory controllers as there are sockets, and with NUMA optimizations in modern OS's, it's likely that a core will only ever need the memory controller which it's closest to. In Intel systems, all cores on all sockets still share a single memory controller.

Re:Dual Core

[Wdomburg]

I was speaking of the system bus, so Hypertransport.

Re:Dual Core

[Wdomburg]

I actually miswrote, too. The X2 uses exclusive L2 for each core, not shared. And I didn't mean to imply a performance bottleneck, since on-die communication and cache sharing (when applicable) are typically a performance win.

In regards to AMD I specifically meant in contrast to multi-socket Athlon configurations, where each processor has a discrete memory controller.

Re:Dual Core

[Wdomburg]

You equated multi-core with multi-processor. I countered that it's fallacious to say that about both volume designs currently in the marketplace.

Shared cache is hardly a necessity. The original Pentium D didn't have any. And (I misspoke, er typed) neither does the Athlon X2. It's just an option that makes sense when you're sharing silicon.

Another differentiator is that multi-core designs can communicate at native clockspeed, rather than resorting to an interconnect. Hypertransport is fast, but shared silicon is faster.

I wouldn't discount cache and interconnect as tangential aspects of a processor. If you look at any modern CPU the majority of the die size is going to be cache, and a significant portion of the power draw comes from the system interface.

Even discounting the performance gains possible with shared resources and on-chip intercommunication and ignoring the power savings (note that quad core parts are hitting the same power envelope as quad core without drastic process changes) there's the simple matter of density. Producing a 1U rack server with eight discrete processor slots would be an engineering miracle, yet any white box operation will happily sell you a 1U rack server with dual four core processors.

Re:Dual Core

[Just Some Guy]

Your HT = Hyperthreading or Hypertransport?

I think you meant:

Intel's HTT = Hyperthreading Technology

Re:Dual Core

[Grayswan]

A NUMA Linux kernal, at startup, tests memory access speeds to all CPUs/Memory Controllers. *IF* there is a large discrepency in access times, the NUMA features are enabled. In my Dual Opteron, it decides access to the memory on each CPU from the other CPU is fast enough, so it disables NUMA and treats all memory as identical.

Re:Dual Core

[Anonymous Coward]

"All the reduced bandwidth of a shared connection to the FSB with none of shared cache! Sign me up!"

For only $300?? Hell yes, fucking sign me up! Why people nitpick about the meagerest of things, I'll never know.

Re:Dual Core

[yakovlev]

NO, shared cache has been around (at least in servers) a lot longer than dual core. That cache just lived on an off-die chip. There are some small system advantages to having multiple processors on a single die (for instance, L2 cache access latency for shared memory) but the impetus behind this design is simply that the cheapest design for performance per unit silicon area is to put multiple "processors" on a single die.

Once the decision to put multiple processors (cores) on one die has been made, it starts to make sense to make some of the on-die cache shared. This decision is secondary, and isn't significantly different from having a shared off-chip cache.

So, dual core is largely a marketing term for putting multiple processors (cores) on a single die. For those in the industry, this implies certain design, cost, and manufacturing trade-offs and challenges, but for the typical consumer or software designer the distinction is really semantic. Software designers optimizing for performance care about the cache sizes, latencies, and characteristics, but they cared about this long before dual-core processors existed.

Symmetric Multi-Threading (SMT, Hyperthreading) is something completely different, and does involve lots of shared processor structures (besides cache) and represents a completely new set of performance considerations that software needs to be aware of. Regardless of how you feel about SMT or Intel's Hyperthreading in particular, this one isn't just a marketing term.

Possibly

[Malevolent Tester]

While a couple of benchmarks are not conclusive evidence, it can be assumed that FreeBSD will once again be a serious performance contender Right up until someone displays a crucifix, that is.

Re:Possibly

[BitZtream]

The beastie is not evil! Just because he has horns, a pitchfork and looks like the devil doesn't make him evil!

You can tell by his smile. It doesn't look freakish or anything ... does it ...

Re:You don't have to be Kreskin

[CastrTroy]

It probably has a lot to do with FreeBSD having a much more focused niche. FreeBSD is really tuned primarily for servers. You can use it on your desktop, but that's not really it's main purpose. Linux on the other hand, has really branched out. It has desktop distros, server distros, embedded distros, and probably a couple other areas I haven't thought of.

BSD Desktops

[parvenu74]

Speaking of which: are there any "distros" out there ship a combination of FreeBSD and the latest Gnome desktop? I think that would be a better combination than Ubuntu's Debian+Gnome combo, personally.

Re:BSD Desktops

[BitZtream]

Yes, the only FreeBSD 'distro'. FreeBSD is not fragmented like the 100 and 1 Linux distros

Download the FBSD isos, install the gnome packages. Not new enough, build from source using ports. While it probably doesn't include the absolutely latest Gnome, the FreeBSD people tend to appreciate stability over cutting edge features, so its probably going to be a little behind the bleeding edge, for something popular like gnome though, it should match up with the latest stable release within a very short period of time.

Re:BSD Desktops

[oscartheduck]

Gnome in FreeBSD is at something like 2.20 -- pretty damn recent. Just install FreeBSD, and either use pkg_add to grab the most recent binaries or build your own gnome by grabbing the latest ports tree ("portsnap fetch extract"'ll do that ) then "cd /usr/ports/x11/gnome2 && make install clean". Done.

Re:BSD Desktops

[ninjaz]

Yes, the only FreeBSD 'distro'. FreeBSD is not fragmented like the 100 and 1 Linux distros

There are FreeBSD-based PC-BSD and DesktopBSD Both of them are using KDE, though.

Re:BSD Desktops

[Anonymous Coward]

FreeBSD is not fragmented like the 100 and 1 Linux distros

I'm a FreeBSD fan, but what kind of logic is that? You pick one example out of a fragmented set, and compare it to an entire other set of operating systems.

You act as if NetBSD, OpenBSD, DragonflyBSD, Darwin, etc, do not exist. Of course and item cannot be fragmented if if you define it's containing set as "itself". Makes about as much sense as:

Ubuntu is not fragmented like the 100 and 1 BSD distros

Re:BSD Desktops

[RiotingPacifist]

yeah whe you only have 101 (its much quicker type than explicitly spelling out the and) users you just don't have time to setup distros.

Whats the advantage of not having any distros? that everything needs to be compiled from source (ala gentoo) or that everything is precompiled for somebody else's needs (ala debian). While i see that BSD does have many advantages (reliablity, checked code, speed), i really don't see how not-having distros is one, sure it means you don't have to choose a distro, but it also means you cant. The linux distros mean that there is constant competition to deliver the best desktop/server/freest/fastest/securest/smallest/scientific/livecd/usb distro, and while it means there is some duplication of effort the overall pace of development is quite fast (fortunately a lot of the development then makes it into BSDs, but FreeBSD needs linux alot more than linux needs freeBSD (especially as stupid license nazis stop us sharing code *shakes fist*))

p.s the FTA is a troll as this was already coverd at freebsd release time and the wise pointed out that solaris still beats both systems

(as /. mods seam to have degenerated to youtube levels recently, ill have to point out that the top of this post IS a joke, it IS NOT flamebait, and the meat of the post is below. Oh and dear god the comment in brackets is ironic, not stupid)

Re:BSD Desktops

[Ed Avis]

You could try Debian GNU/kFreeBSD, though this is not really a distribution of the full FreeBSD system but just its kernel with a GNU userland.

Re:BSD Desktops

[Vexorian]

I guess that's the main reason for its lack of success.

Re:BSD Desktops

[BitZtream]

No, those are forks.

FreeBSD is not just a kernel like Linux. FreeBSD is the entire package. You don't have other distros, you have forks of the original.

Re:BSD Desktops

[BitZtream]

Of those you listed, Only DragonflyBSD and Darwin use a FreeBSD kernel, Darwin considerably modified, to the point that it might as well be counted on its own. You can not drop the FreeBSD kernel in any of them and have things work, except for Dragonfly, but even then it still requires (minor) modification.

Compare/Contrast to Linux distributions. The kernel, assuming version matchs, is rather interchangable between the distros. Its the file system layout, the utilities included, and default configurations that define the 'distro'.

With FreeBSD, all of the above is defined as 'FreeBSD'. DragonflyBSD is a fork it. As is PC-BSD and a couple of the even less known forks.

Linux distros are 'the GNU/Linux kernel' and 'the utilities and userland tools required to make it usable'.

Saying there are FreeBSD distros is like saying there are 'Slackware' distros, or some such variation. While I'm sure you could argue it, the meaning behind what we all consider it to be would be different than what people think of when its said.

Re:BSD Desktops

[DragonWriter]

Yes, the only FreeBSD 'distro'.

If FreeBSD is the only FreeBSD distro, then what are (among others) PC-BSD and Desktop BSD?

Re:BSD Desktops

[geminidomino]

You act as if NetBSD, OpenBSD, DragonflyBSD, Darwin, etc, do not exist. Of course and item cannot be fragmented if if you define it's containing set as "itself". Read the question again. The question as about FreeBSD + GNOME. Not *BSD + Gnome. Grandparent is right. The only one that might, loosely, be considered a "distro" would be FreeBie (A freebsd liveCd). None of the other things you mentioned are FreeBSD. If you want to complain about set definition, take it up with the questioner.

Re:BSD Desktops

[xtracto]

'the GNU/Linux kernel' and 'the utilities and userland tools required to make it usable'.

You got it almost right, but the Linux kernel is The Linux Kernel. The GNU part was added by Stallman because they provided "the utilities and userland".

However, I agree with you that FreeBSD has nothing to do with netBSD and openBSD. Only that they all are "based" on the BSD distribution of Unix. But if you want to go that far, then Linux would be based on the System V distribution of Unix and all of them would be different flavrous of Unix.

Re:BSD Desktops

[ninjaz]

No, those are forks. FreeBSD is not just a kernel like Linux. FreeBSD is the entire package. You don't have other distros, you have forks of the original.

Well, both PC-BSD and DesktopBSD claim to not be forks. DesktopBSD explicitly identifies itself as a distribution of FreeBSD and PC-BSD says "PIF" (PC-BSD is FreeBSD). Here are the references: http://faqs.pcbsd.org/index.php?action=artikel&cat=14&id=304&artlang=en

http://desktopbsd.net/wiki/doku.php?id=doc:faqs

Of course, I appreciate the fact that FreeBSD's base is an integrated system which is maintained as a unit as opposed to Linux distributions which are sourced from multiple projects.

Re:BSD Desktops

[Sancho]

We're getting into semantic Hell here.

FreeBSD doesn't have distros because FreeBSD itself is very much like a distro. It's not a requirement from the FreeBSD team--rather, FreeBSD is a complete operating environment akin to a Linux distribution.

There's nothing technically or legally preventing me from creating a new installer that uses the FreeBSD kernel and FreeBSD userland, with some modifications to the default packages installed. In fact, people have done just that. PFSense even calls it a distribution of FreeBSD.

I think the main reason that more of them haven't cropped up is because they're just not all that necessary. Since FreeBSD comes with the ability to add third-party software in using a repository (extremely similar to Gentoo's Portage, as the Gentoo team based some of their design decisions on BSD ports), so there's not much to add. If you notice, the major Linux distros of times past largely differed in the software repository and default options for precompiled packages.

especially as stupid license nazis stop us sharing code *shakes fist* Well, if it violates the license, I don't know what you want. *shrug*

Re:BSD Desktops

[Sancho]

You have to be wary with pkg_add. It will only grab packages from the -version-release branch (which are not updated--they're static for that release.) For example, if you're running 6.2, you'll find that pkg_add tracks this URL for packages:
ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-6.2-release/Latest/

And the software is over a year old.

If you want updated packages, you will need to set some environment variables to force you to track a -stable URL (such as ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-6-stable/Latest/). See man pkg_add for details.

Of course, just compiling from ports is probably the easiest way, if you've got a fast enough computer.

Re:BSD Desktops

[sremick]

Incorrect. Both track the main FreeBSD tree. Consider them "value add" packages of software and tweaks layered on top of the official FreeBSD. A fork would be traced to a single point in time with ever-growing divergence (think DragonflyBSD). Both DesktopBSD and PC-BSD include updated bases of the main FreeBSD with their own updates. For example, PC-BSD 1.0 was based on FreeBSD 6.0. The current version of PC-BSD, 1.4.1, is based on FreeBSD 6.3. PC-BSD 2.0 will be based on FreeBSD 7.0.

In fact, a lot of the DesktopBSD components are available as an add-on in the Ports collection:
http://www.freshports.org/sysutils/desktopbsd-tools/

Re:BSD Desktops

[Blackknight]

There is no such thing as a BSD distro. FreeBSD is an entire operating system which includes the kernel and the core utilities needed to manage it. The nice thing about FreeBSD is consistency, it doesn't matter what server you login to things are going to be laid out the same and have the same options. Most systems will have extra packages installed but everything goes under /usr/local so you can just look around.

Re:BSD Desktops

[Eivind Eklund]

I would count both Darwin and DragonflyBSD as their own kernels; they are substantially modified.

Eivind (ex/inactive FreeBSD kernel developer).

Re:BSD Desktops

[Brandybuck]

You don't need a "distro". Just install the latest GNOME on FreeBSD. Done. While I am a huge KDE fanboy myself, the FreeBSD/GNOME team has done some amazing work.

Re:BSD Desktops

[setagllib]

This is going to scare you, but BSD stands for "Berkeley Software Distribution", so BSD is automatically a distro. How can there be no such thing as a BSD distro? Maybe the definition of the word has changed since then. BSDs are each like a single Linux distribution with a selection of tools from the open source world, as well as a lot of project-specific code and legacy code from BSD heritage.

Re:BSD Desktops

[smash]

They're not FreeBSD.

Pre-emptable kernel?

[Gothmolly]

Does FreeBSD have a pre-emptable kernel? One of the things Linux has really focused on lately is desktop interactive performance, so there may be performance tradeoffs vs. a kernel which can't pre-empt itself.

Re:Pre-emptable kernel?

[archen]

in the kernel config there is a preemption option which I believe is enabled in the default kernel. Generally you can turn this on and off, and use a different scheduler if you want to, but there isn't the myriad of options to tinker with in Linux. Since many don't bother switching from the defaults, and many others tend to choose wrong anyway, this might be a good thing.

Re:Pre-emptable kernel?

[halber_mensch]

Does FreeBSD have a pre-emptable kernel? One of the things Linux has really focused on lately is desktop interactive performance, so there may be performance tradeoffs vs. a kernel which can't pre-empt itself. Yes. The FreeBSD kernel has preemption options to enable preemption. The distributed generic kernels have it enabled.

I look forward

[Clover_Kicker]

to the enlightening and respectful conversation this article will provoke.

Re:I look forward

[garett_spencley]

Screw you!

Wait, you forgot to mention ... you use BSD or Linux ?

Re:I look forward

[drolli]

Yes. Me too. similar discussions:

-Smartphone xyz has a touchscreen, similar to the iphone, and the animations are even nicer.
-web based product abc is better than google efg. You can select more fonts.
-[Notebook from notable series] is nearly as thin as the apple air
-[free office suite x] can read [some standard] better than open office
etc.

General scheme:
[alternative product well known to everybody interested] has [arbitrary unsuprising advantage withing the "version flucuation" in some feature] since [last patchday/last version] over [well known, overhyped popular product], when measured by [some arbitrary method or by looking at it].

Re:I look forward

[Chemisor]

You go right ahead. I'm just going to keep beating the dead horse.

Re:I look forward

[Clover_Kicker]

"'My system'" is technical purity incarnate and the embodiment
of all that is good in the universe. 'Your system' is a loose
collection of hacks done by experimental gerbil subjects on
amphetamines. Remember those two constants in any debate of
this nature and much of what gets said will come into the
proper perspective."
- John Hubbard, in c.o.l.m

Re:I look forward

[teknopurge]

Fuck off. :)

Re:I look forward

[teknopurge]

Screw you!

Wait, you forgot to mention ... you use BSD or Linux ? This is slashdot - does it really matter?

Re:I look forward

[Billly Gates]

And which editor to use on Freebsd OR linux. VI or Emacs?

Bad news for Linux?

[Chrisq]

Since they switched to the Completely Fair Scheduler to improve performance then it means one or two things. Either they have failed, as it seems to run slower than earlier Linux versions in the BSD test, or the tests that BSD chose are "untypical", maybe selected to show a particular advantage to BSD. I don't have the expertise to tell which, but I would be happier seeing some benchmarks from an independent source rather than BSD.

Re:Bad news for Linux?

[BitZtream]

Benchmarks are almost but not completely useless. In this particular setup, FBSD 7.0 runs postgres doing some specific set of queries faster than Linux.

Its a safe bet Linux will do some other set of things faster than FreeBSD does them, possibly even another specific set of PostgreSQL queries for that matter. Linux is definately more concerned with desktop app performance. I can say this safely because Linux actually cares about it, FreeBSD does not. Its there to serve, not run X. It will run X, and if they see a way to make performance better for the desktop apps AND the server apps, then it may go in the source tree. If its going to hurt the server side, don't bet on it.

While I use FreeBSD for my servers because its got a clean filesystem layout and is designed to be a server OS, I'd be willing to bet that someone with deep knowledge of PostgreSQL on Linux could give it a run for its money by tweaking the kernel for server performance.

Re:Bad news for Linux?

[Azarael]

The article is probably misleading (surprise, surprise), as the tuning documentation for PostgreSQL *states* that good IO performance has more of an impact than good CPU performance. Additionally, some other information I've read (search for postgres tuning/optimi(z|s)ation online) recommends FreeBSD because of its strong IO performance. I'll go out on a limb and assume that MySQL's performance attributes are similar.

In my opinion, the article summary is a pretty big red herring because the SMP performance may not have a huge impact on the result.

Re:Bad news for Linux?

[atomic-penguin]

For one, CFQ is not supposed to be an optimized I/O scheduler for database loads. That's where the Deadline scheduler comes in. You wouldn't want a "Fair" scheduler on your database server, as you would end up putting the database in I/O wait to handle lower priority processes.

Re:Bad news for Linux?

[Vexorian]

There are lies, damn lies, statistics and benchmarks.

Re:Bad news for Linux?

[Fweeky]

CFS is a CPU scheduler, and rather similar to FreeBSD's ULE; CFQ and Deadline are IO schedulers, and completely different beasts.

Re:Bad news for Linux?

[MrNemesis]

As t'other poster pointed out;
CFS = Completely Fair Scheduling = CPU scheduler = what process gets how much of the CPU
CFQ = Completely Fair Queuing = I/O scheduler = what process gets how much of the hard disc

FWIW, on our database loads at least, I find that whilst deadline tends to give the lowest single transaction rate, CFQ gives better overall performance (i.e. more transactions served) over a given time period. Anyone tried the CFQ, deadline and no-op schedulers on a solid state disc yet?

Re:Bad news for Linux?

[Sancho]

Generally speaking, MySQL doesn't perform that much better than Postgresql if the former is using the MyISAM engine. Turn on InnoDB (for silly things like transactions and foreign keys) and Postgresql typically wins out.

Of course, if you're just using your database as a data store--an easy way to store data with convenient, known methods for finding and updating that data, you may be ok with just MySQL/MyISAM. If you're using your database as an actual, relational database and looking for data integrity enforced there instead of in your application, you might want to look at Postgresql.

Re:Bad news for Linux?

[mi]

In my opinion, the article summary is a pretty big red herring because the SMP performance may not have a huge impact on the result.

Slide 10 out of 37 (emphasis mine -mi):

• Online transaction processing" benchmark; /usr/ports/benchmarks/sysbench
• Complex transaction-based queries
• Read-only: no disk access to avoid benchmarking disk performance
• Clients and servers on the same system
• PostgreSQL 8.2.4 (process-based + System 5 Inter-Process Communication (IPC)
• MySQL 5.0.45 (thread-based)
• Test hardware:
  1. 4 * 2-core Opteron (amd64 mode) 2.2GHz CPUs, 4 GB RAM
  2. 2 * 4-core Xeon E5320 (i386 mode) 1.8GHz CPUs, 3.5GB RAM

Re:Bad news for Linux?

[Azarael]

Yep, it's usually a good idea to read the whole article.

The telling slide though is 17, from the summary, the so-called "Latest Linux Kernel" is Linux 2.6.23.0.214.rc8.git2.fc8, a release candidate on an unstable branch of the kernel. Even with that being the case, the graph shows a slight edge given to FreeBSD, until there's a blip in the Linux results between 9-16 threads, after which the performance levels out. The fact remains, while the results for FreeBSD are clearly in FreeBSD's favour after 8 threads, I don't think you can make any judgments on the results until the benchmark includes a Linux 2.6.24 series server kernel.

The next slide, 18, is interesting though, as neither of the Linux kernels handle MySQL's concurrency nearly as well. There's are some reasons why I prefer Postgres though : )

Re:Bad news for Linux?

[Just Some Guy]

I don't have the expertise to tell which, but I would be happier seeing some benchmarks from an independent source rather than BSD.

This is entirely subjective, but:

FreeBSD 6 was quick on our dual two-core Opteron server, but upgrading to FreeBSD 7 gave a real kick in the pants. Honestly, the thing just screams along now. Our servers have never had Linux on them so I can't directly compare it on the same hardware, but can confidently say that 7 is a huge improvement over 6.

Re:Bad news for Linux?

[dpilot]

They didn't switch to the CFS to improve raw performance. The driving impetus behind the CFS was interactive performance. For some time schedulers have been "too fair" and treated batch and background tasks by the same rules as interactive tasks. The general way to improve interactive performance has been with shims and jimmies, like "nice -10 X". The real problem has been detecting *what* is an interactive job, and deciding whose priority to boost, especially without problems like priority inversions or boosting waiting threads. Kon Colivas took on the interactivity problem, trying to come up with a wart-free scheduler that would give good interactive response. Somewhere in that time Ingo Molnar got into the game, too. Eventually Ingo's CFS design was chosen, with the decision at least partly based on the responses and noise of Kon's fanbois. Unfortunately Kon left, after this.

It's worth mentioning that 2.6.23 is the entry of CFS into the mainline kernel. *Nothing* hits the kernel perfect, first time. A quick check of LKML saw a flurry of CFS patches shortly after the release of 2.6.23, and I have no doubt that some level of tuning will continue. To look at 2.6.23 and say that CFS *is* deficient may be fair, but to make the judgment to throw it out is not. At the very least, it's worth a revisit on 2.6.24 and a few kernels onward.

Re:Bad news for Linux?

[kkenn]

Yes, this was indeed the latest kernel distributed by Fedora at the time those slides were produced in October 2007.

Re:Bad news for Linux?

[Azarael]

That doesn't really legitimize the claims made in the summary however. This is ./ though, so probably not worth making a big fuss about it. Anyway, even last year I was interested in giving FreeBSD a try as our DB host but I haven't had time. It's just a shame that most readers aren't going to get much useful information from the summary or discussion.

Re:Bad news for Linux?

[nconway]

the tuning documentation for PostgreSQL *states* that good IO performance has more of an impact than good CPU performance

This is often, but not always the case -- it depends on the nature of the query workload. In this case, the benchmark was done using read-only queries, specifically for the purpose of minimizing the I/O requirements and therefore focusing on CPU performance.

Re:Bad news for Linux?

[love2hateMS]

Thank god. Someone who knows what they are talking about... a novelty on Slashdot.

Re:You don't have to be Kreskin

[oscartheduck]

You think so? I dunno, it seems to me that FreeBSD suits the desktop role really well; I use it for preference. Especially when you consider that the only OS with more packages is Debian, it makes sense that it can fit a desktop role extremely nicely.

In your face, bazaar!

[Anonymous Coward]

Cathedral FTW!

In short, wow

[MrNemesis]

Very, very nice scaling performance under PGSQL is evident in the PDF, and I've no reason to assume the benches aren't legit. I think part fo the reason that PG was traditionally slower than MySQL was that it did lots of complicated locking to provide better scalability across processors, whereas we see MySQL performance dropping off after we go to more than eight cores. I think this was the same philosophy Sun took with "Slowaris", which was also far more scalabe than Linux at the time the moniker was in widespread use.

Still, I hope Linux can at least match this sort of superb scalability. CFS is fairly new, and I know there's optimisation work been done to it in .24 and .25, although it was a little sad to see the first iteration of CFS performing more poorly than its predecessor (and, if this is the case, I can see why Linus stonewalled CK's patches for so long, since they were mainly tested on desktop workloads). Are there any apples-to-apples comparisons out there that test various flavours and versions of Linux and BSD with a wide range of benchmarks? At the best review sites do a few benches with MySQL, and six months later everything has changed so it's incredibly difficult to do good performance comparisons.

Even so, it's refreshing to see precious little of the "BSD fudged their benchmarks!" trollspeak in the LKML thread, and plenty of talk about how to make Linux better. Open source is hippy capitalism - it also needs healthy competition to keep it in check :)

Offtopic: bug linked to in the LKML pointed me at this http://www.latencytop.org/ Sounds quite nifty

Re:In short, wow

[ivoras]

Very, very nice scaling performance under PGSQL is evident in the PDF, and I've no reason to assume the benches aren't legit.

Oh they are legit. The guy who did them has a thing for proper benchmark procedure and statistical analysis and is a physicist in real life.

He isn't an expert in MySQL and PostgreSQL but if he did underoptimize them, you can be assured he uderoptimized them in exactly the same way on both OS-es :)

Re:In short, wow

[Entrope]

I don't think that the FreeBSD guy fudged his benchmarks -- more likely, other FreeBSD people fudged the OS. Working with large-scale IRC servers, I have seen a few serious kernel-level race conditions on FreeBSD cause problems (like server processes that stop accepting connections in an unkillable state -- rebooting the server is a good way to fix things, right? -- and clients that appear to have the IP address 0.0.0.0). What's worse is that the unkillable process bug took many months to resolve. Linux and Solaris servers on the same IRC network never seem to have OS-related problems. It goes back to the old saw: make your code correct, *then* make it fast.

Re:In short, wow

[SanityInAnarchy]

I think part fo the reason that PG was traditionally slower than MySQL was that it did lots of complicated locking to provide better scalability across processors, whereas we see MySQL performance dropping off after we go to more than eight cores.

Actually, what I remember is a bit different: Postgres supports transactions. MySQL's default MyISAM does not, and is thus faster.

Personally, I prefer correctness to speed -- and I also seem to remember that Postgres was always faster than MySQL's InnoDB.

Re:In short, wow

[kkenn]

The "0.0.0.0 client address" bug was only present in the 7.0 development versions and was fixed prior to 7.0-RELEASE. If you are running IRC servers on unreleased OS code, you should expect problems.

Re:In short, wow

[MrNemesis]

Yeah, I've spent enough (down)time repairing MyISAM's to care about the supposed speed benefit any more - I'm a firm Postgres fan as well. On mine and others machines, the new 8.3 is blazingly fast, and there was a bench that I can't find any more that showed it trouncing MySQL for speed, and I've since ported all my little homebrew database thingies over to it. Shame that alot of apps only support MySQL (damn you, MythTV!).

Re:In short, wow

[MrNemesis]

Aye, I didn't expect they were - it's just a shock to see such a huge improvement almost overnight :D Development of the BSD's might appear glacial to those, like me, who are used to Linux, but it's refreshing to see that when they finally implement things they tend to get it very, very right.

Re:In short, wow

[Sancho]

I work in a total FreeBSD shop, and we've never seen the problems you've seen. Off the top of my head, we have FreeBSD deployed as firewalls in about 40 boxes, and probably that number in servers, too.

Of course, we're not running IRC--could these problems be systemic to that use?

Re:In short, wow

[A beautiful mind]

Well, as someone who uses Pg with 100k unique user visits a day, Pg beats the crap out of Mysql if we're talking about anything else than very simple selects.

If you need transactions, stored procedures, subqueries, complex queries with joins, multi-value insert, etc., then you'll get much better performance results with Postgresql >= 8.2 than with Mysql. 8.3 adds a nuce performance gain on 8.2 aswell, while the database is much more consistent than mysql is.

I think this boils down to the philosophy: Postgresql strived/strives to be correct first and then fast, mysql strives to be fast and then they decided they'd like some correctness and ACID features. We can see how well that worked out.

Re:In short, wow

[MrNemesis]

Agree 100%. I've got to the stage where if I see something list MySQL support without Postgres support, I'm generally of the opinion they're not taking things seriously enough :) Postgres has been by DB of choice for about two years now, and I've yet to have it balls up on me, and speed has never been an issue - like you say, as soon as you start doing non-trivial stuff, Postgres utterly thrashes MySQL.

Re:In short, wow

[SanityInAnarchy]

Fortunately, at work, this isn't a problem, as we do everything in Rails. It's a small feature that I'm starting to see in more and more places -- the database is abstracted away.

Let me clarify: I just recently had to do a bit of restructuring of the corporate website. I developed and tested my changes locally on a sqlite database, then deployed to MySQL.

Which means that, as I'm also our admin, if I want to switch us over to Postgres, the app will be fine. It's the data I'd worry about...

Re:In short, wow

[Entrope]

No, they were both garden variety race conditions. This is single-threaded application code that doesn't do anything particularly novel or clever. IRC servers deal with new connections more often than most applications except high-traffic web servers, so the racy paths (in the system calls implementing accept() and getpeername() respectively) run a lot more often on large IRC servers than most places. To quantify "a lot", the server where the first problem was most troublesome sees upwards of 230 incoming connections per second -- both over the last ~50 days and over one recent minute.

Re:You don't have to be Kreskin

[CastrTroy]

How many of those packages are desktop packages? Seems like a odd metric to just compare the number of packages as to how well an OS is suited to the desktop.

Kreskin sez

[eclectro]

Linux is actually better than BSD because you can roast marshmallows over the schedular flamewars.

Re:Kreskin sez

[teknopurge]

Forget the flamewars, from the looks of things you can roast marshmallows over the CPU the scheduler is running on.....

Re:Kreskin sez

[ClamIAm]

I think you're forgetting about OpenBSD. Theo alone can match the output of your silly scheduler flames. :)

Silly, ignorant children.

[DaedalusHKX]

Dig up Desktop BSD.

Quite nice, if not my cup of tea. IMHO, BSD is for servers, but if I were tempted to use BSD for desktops, it'd be Desktop BSD.

That being said, it seems VERY clean and useful, but it does use KDE (no load time on my laptop, when accessing menus, which means something has been fixed on BSD that hasn't been fixed on Linux KDE yet.)

I think one can force it to use something other than KDE and still keep the "Desktop Tools", which make Desktop BSD quite useful. (Only OS that detected my SD MMC controller without a single extra effort from me.)

Re:Silly, ignorant children.

[yo_tuco]

There is another BSD distro that makes a good desktop. I've been using it with excellent results. It's OSX.

Re:Silly, ignorant children.

[Atriqus]

I don't think it counts as a distro if the underlying system is forked to the amount Darwin has from FreeBSD. But it's definitely a Darwin distro.

Re:You don't have to be Kreskin

[oscartheduck]

Well, I don't think I've ever installed any package from anything other than the ports system. Lots? I know I've installed everything from Gnome, XFCE and KDE, through OpenOffice and a bunch of stuff in between.

You're right that mere numbers of packages is a weird metric, but what else can we offer? FreeBSD has great performance, and has everything necessary to be either a good server *or* a good desktop. It's much like Gentoo that way -- it doesn't focus on being either one or the other, it focuses on being a solid basis. What you put on top of that basis is your choice. It honestly seems to me that the distinction between server OS and desktop OS is its own entire discussion; if we can come to a good notion of what either means, we can reach a nice conclusion. If we take the current crop of Linux desktop OSes, though, I don't see any more integration between, say, Fedora and Gnome and FreeBSD and Gnome, or Ubuntu and Gnome and FreeBSD and Gnome.

If I think about it, it does seem that Ubuntu starting with a GUI interface and letting you find the command line by yourself is more friendly to the average user; I haven't installed FreeBSD using anything other than minimal-install for so long that I don't know whether you can have a GUI start up by default. And FreeBSD's installer, whilst excellent for its audience, is less friendly to a first timer. If we take those metrics, the idea of "can I sit down and first time use it without documentation?" then a lot of the linux crop are friendlier, yeah. But the documentation *is* very hand-holdy, and very very thorough for FreeBSD. And nicely available online.

Bogus PostgreSQL tests

[greg1104]

While I'm glad for FreeBSD they're showing good numbers again, their testing of PostgreSQL in this study is rather odd. The results are using the read-only tests from sysbench. You can see from its sourceforge page that sysbench is a MySQL benchmarking tool that has some rudimentary PostgreSQL support bolted on top. That particular code is so bad that the last time I checked, turning on the write OLTP tests deadlocked the PostgreSQL server, as it wasn't putting statements into transactions correctly (which of course the ancient MySQL versions this code targeted doesn't care about). As the sysbench tool hasn't been actively maintained in ages I doubt that has improved.

The claimed "15% faster than linux" is pretty clear in the MySQL tests; the PostgreSQL ones have a weird dip in them but are in general much closer. I'd be comfortable if the result of this study was "FreeBSD 7 has been optimized to be 15% faster running MySQL than Linux", because that matches what they did (note the specific libpthread patch for example). But the fact that they used such an awful PostgreSQL benchmarking methodology leaves me hesitant to draw a broader conclusion than that based on their tests.

Re:Bogus PostgreSQL tests

[Anonymous Coward]

I think you've just highlighted the issue which is that there isn't a decent, up to date, Unix/Linux benchmarking tool.

Overall it seems that FreeBSD 7 has really dragged itself back into the fray. And considering how nice FreeBSD's wireless support is, compared to the half-assed Linux crap that someone thought was a bright idea, I am strongly tempted to give it a go again.

Re:Bogus PostgreSQL tests

[kkenn]

You are correct that the pgsql driver in sysbench is broken for read-write loads. It needs a small patch to get it to detect deadlocks properly. However your objection is irrelevant to this benchmark, which is for read-only loads. Furthermore, the goal is not to evaluate mysql vs postgresql, it is to evaluate FreeBSD vs Linux.

Re:Bogus PostgreSQL tests

[greg1104]

If sysbench has some performance problem running PostgreSQL, and the tests I've done never gave me any confidence in it there, those issues could end up bottlenecking the benchmark results. Now: what if that's the case, but that bottleneck is less of a problem with FreeBSD than Linux? All you've proven is that FreeBSD is faster at running sysbench, not PostgreSQL.

Unless you're using a good benchmark for the database you're testing, you can't draw any strong conclusion about how that database performs, and I feel it's suspicious even for comparing the OS as a result. Maybe it's good data, maybe it's not, but you can't really know. Even the PostgreSQL bundled pgbench has limitations you must be aware of in order to get good results from it.

Oh, and if you could tell me where that deadlock patch is, that would be great; I'd like to dig into this issue some more. If all the patch does is detect deadlocks that's not really the right resolution though. There shouldn't be any deadlocks if the transactions are correct, the PostgreSQL MVCC keeps that from happening. I've taken the same queries sysbench chokes on and fed them into pgbench, wrapped properly in begin/commit blocks, and there's no trace of a deadlock then.

Re:Bogus PostgreSQL tests

[mrami]

I agree that "15% faster than Linux" isn't defendable, but I think the point of the benchmarks was to get a taste of the SMP scalability. pgsql and mysql were just the vehicles to demonstrate it.

Now once the scheduler becomes topology-aware... look out!

Re:Bogus PostgreSQL tests

[kkenn]

The database is putting load on the kernel, and the performance of the kernel is what is being tested here. If you like, sysbench+pgsql is just a fancy concurrent syscall load generator and the underlying workload is irrelevant as long as the pattern of syscalls models the kind of thing that a reasonable application could be doing. The sysbench output numbers are just a function of the number and type of syscalls performed, i.e. they measure kernel throughput.

Analysis of the syscalls being performed indeed shows that it is not doing anything bogus that a reasonable application should not be doing, so in this sense it is a reasonable kernel benchmark target. If your contention is that the sysbench throughput is not an accurate model of what an *SQL* application is doing because it is generating sequences of commands that are non-representative when interpreted as SQL commands, then I can't comment. It still doesn't invalidate the benchmark, because if the kernel has good performance on a certain workload of syscalls then it will perform well no matter what application is executing them.

My RW patch indeed just detects the deadlock so I don't resolve the underlying problem. I agree that this makes sysbench not so useful for testing postgresql rw performance.

Re:You don't have to be Kreskin

[Anonymous Coward]

Why on earth do you think FreeBSD is a dying OS? Just because kids seem to think Linux is cool and better than everything else, doesn't mean FreeBSD or any of the the other *BSDs are dying. It just means it has more serious and educated users :-)

I have Vista

[StarKruzr]

but I heard it wasn't compatible with Windows or labtops.

Can you help? Sorry, I am not good with computers. :) I want to download the internet onto my labtop.

Re:I have Vista

[MadMidnightBomber]

wget -r http:/

HTH, HAND, etc.

Re:You don't have to be Kreskin

[street struttin']

Well, according to this, there are several thousand. Not to mention that due to linux emulation, freebsd can run anything linux can run.

Linux ups the bar

[argggh]

http://article.gmane.org/gmane.linux.kernel/650739

Re:Linux ups the bar

[A beautiful mind]

Choice quote:

But it sometimes seems a bit sloppy... eg. a full 35% of the syscalls the MySQL server makes are failed sched_setparam calls that are passing in invalid values.

Oh wow, I knew mysql doesn't have the most beautiful code, but this is pretty funny.

How to recover your mod points

[A nonymous Coward]

Post a comment. When faced with the two incompatibilities, slashcode keeps the comment and tosses the mods, presumably because comments might have attracted subcomments and thus be impossible to remove.

This assumes that youare still within the time frame of modability. I don't know what happens if you have used all your modpoints; does that automatically end your modability time slot?

Re:How to recover your mod points

[thePowerOfGrayskull]

What is with the offtopic police and their poor usage? Ah, well - anyway. The points were actually spent earlier, in a couple of different articles. Though I think posting in the conversation after modding actually results in not only losing the mod, but also not regaining the lost mod points...

Re:You don't have to be Kreskin

[Klaus_1250]

I dunno, it seems to me that FreeBSD suits the desktop role really well

It does (I use it too) BUT only in specific environments. FreeBSD hardware support is not bad, but it is nowhere near as complete as that found in the various Linux distro's. My wireless keyboard + mouse is supported under any recent Linux distro, on FreeBSD, only the keyboard works (fixable with a unofficial ums.ko though). No support under FreeBSD for my DVB-C PCI card either.

Re:You don't have to be Kreskin

[Anonymous Coward]

Don't forget, there's always PC-BSD for the Linux users - simple, point'n'click installer, etc.

Re:You don't have to be Kreskin

[fandrieu]

Although FreeBSD ports contain all the major "Desktop" packages, I don't think it's a "Desktop OS".
Mainly because the "base system" is purely text based, if you want to do something with the system, you do it on the command line, there's no GUI based procedure in the FreeBSD handbook.
From what i've used, there's no GUI configuration tool specific to FreeBSD. I would even guess there's *nothing* FreeBSD specific which is a GUI.
Compare this to RedHat or Ubuntu where every bit of graphic is themed and you have a bunch of custom graphic utilities.

When you install XFCE on FreeBSD, you get XFCE.
When you install XFCE on Ubuntu, you get Xubuntu.

Don't get me wrong, I don't say it's not suited to Desktop, just that the Desktop experience is not part of the OS, it's in the ports....and that's why i've been using it since 4.x

Where does this leave dragonfly?

[CarpetShark]

While I'm glad for FreeBSD they're showing good numbers again, their testing of PostgreSQL in this study is rather odd.

Agreed, on both points. What I want to know though, is where this performance improvement, and 7.0 in general, leaves Dragonfly BSD... do they still feel that Dragonfly's choice to split off at 4x and start making radical changes is paying off? Is dragonfly making progress towards better performance, in general, or on particular workloads?

I saw what Matt Dillon did back in Amiga days. I saw what Amigas themselves could do. If Amigas inspired Dragonfly towards a more lightweight model, I'd love to see that fork making more progress.

Re:Where does this leave dragonfly?

[renoX]

The dev of Dragonfly BSD has switched its aim from being 'a better way to do SMP' to 'SSI clustering' so I doubt that Dragonfly BSD is going to compete with FreeBSD in SMP scalability anytime soon if ever.

Re:Where does this leave dragonfly?

[kkenn]

Dragonfly has still made no progress towards SMP performance with even 2 CPUs (they are still "competitive" with FreeBSD 4.x performance, and sometimes much slower), but this somehow doesn't deter their advocates from believing that Matt Dillon's -- still largely unimplemented -- ideas are still vastly superior.

As we know, unwritten code has no bugs and runs at twice the speed of thought, so maybe so :)

Re:Where does this leave dragonfly?

[KangKong]

http://people.freebsd.org/~kris/scaling/os-mysql.png

Basically, dragonfly is both slower with a single thread and fails to scale at all

good news, everybody!

[debatem1]

Sounds good. Presuming that there is merit in the methodology here, we may see some more competition in the market. I'd like it more if there were more code sharing going on, but maybe if we don't get tempers too hot we'll see a little more of that too.

FreeBSD SMP threads + boehm-gc = totally broken

[chrysalis]

Cool, however it would be better if software working on Linux were also working on FreeBSD.

boehm-gc is totally broken when using threads on FreeBSD SMP. And it's still totally broken on FreeBSD 7.

The Neko virtual machine is in ports, but it's unuseable due to this, I don't even understand why it's in the ports tree. Was it ever tested before being imported?

Just creating a thread:

$loader.loadprim("std@thread_create", 2)(function(z) { $print(z) }, "OK");

makes is crash with a corrupted stack. It works on every other operating system. It seems to work on an UP FreeBSD system, but on a FreeBSD 7 SMP system, it crashes, crashes, crashes.

Re:FreeBSD SMP threads + boehm-gc = totally broken

[Sancho]

Did you file a bug report and contact that port's maintainer?

Re:FreeBSD SMP threads + boehm-gc = totally broken

[Just Some Guy]

Off-topic observation: you said the exact same thing as the AC above you, but you got +1 and he got -1. Nice one, mods. :-)

Re:FreeBSD SMP threads + boehm-gc = totally broken

[chrysalis]

Yes, PR121336

Re:FreeBSD SMP threads + boehm-gc = totally broken

[nuke]

What about running a linux binary of it using the Linux ABI?

Re:FreeBSD SMP threads + boehm-gc = totally broken

[chrysalis]

It doesn't work with Linux emulation either. Dies with "absurd stack bottom value". The only way is to run Qemu and another operating system, boehm-gc / neko even works on windows.

Re:FreeBSD SMP threads + boehm-gc = totally broken

[chrysalis]

Unfortuately kQemu is as stable as nitroglycerine on FreeBSD, so this is not an option, either.
Back to Linux.

Re:You don't have to be Kreskin

[Corporate Troll]

Mainly because the "base system" is purely text based, if you want to do something with the system, you do it on the command line, there's no GUI based procedure in the FreeBSD handbook.

Strange, I was under the impression that Debian's base install has no GUI either. As a matter of fact, I have a Debian Postgresql server that has never seen anything related to X.

Re:You don't have to be Kreskin

[bondjamesbond]

Dude - the "BSD is dying" thing is an old joke. Get with it!

Re:You don't have to be Kreskin

[calebt3]

only OS with more packages is Debian Whatever happened to Windows? Or does programs != packages?

Some clarifications on my benchmarks

[kkenn]

Hi, I am the one who performed these benchmarks and I'd like to clarify a couple of things:

* The point of this benchmark is not to unilaterally declare victory over Linux, but to point out that FreeBSD is once again competitive with it on modern high-end hardware and certain workloads. Of course, we are working on other workloads too, and currently perform better than Linux on other benchmarks, and still worse on others. There will no doubt be further friendly competition between the two OSes that will work to the benefit of both. Our message to the Linux developers is that they should not expect to get away with resting on their laurels :-)

* I benchmarked both mysql and postgresql, and FreeBSD 7.0 performs better than all Linux kernels (at least up to 2.6.23) with both databases. Incidentally postgresql is much faster than mysql, contradicting common wisdom. Other fun facts are that mysql 5.0.51 has poorer scaling than 5.0.47, and 5.1.x has *much* worse performance and scaling than 5.0.47 on my tests.

* I benchmarked several versions of Linux including 2.6.20.x, 2.6.22 and 2.6.23. 2.6.20.x has terrible performance http://people.freebsd.org/~kris/scaling/scaling.png. This graph is from Feb 2007 and the FreeBSD performance also improved after this point.

* 2.6.22 (which is pre-CFS) mostly fixed this but still performs worse than FreeBSD http://people.freebsd.org/~kris/scaling/os-mysql.png. 2.6.23 included the new scheduler and was a major performance regression. I did not yet retest with 2.6.24, so maybe they have fixed CFS by now.

* Contrary to some commenter's assertions that this is not a CPU benchmark, this benchmark is *extremely* sensitive to CPU performance and especially scheduling (in fact, as noted in the PDF, I/O performance is not a factor here). The scheduler really matters here, which is why Linux took a big hit when they switched to CFS (similarly, on FreeBSD the 4BSD scheduler performs much worse). Tuning the scheduler is critical to performance on this kind of workload. The other critical aspect is having a highly optimized kernel without concurrency bottlenecks. 2.6.20 fell over on kernel concurrency, and 2.6.23 fell over with the scheduler.

Hope this helps to clarify things.

Re:Some clarifications on my benchmarks

[Bill, Shooter of Bul]

FYI. Your observations of mysql performance are right in line with what others including google have noticed. The famous google patches significantly improve the scalability regressions introduced. They should eventually make there way into the official Mysql in a couple months or so.

Re:Some clarifications on my benchmarks

[kkenn]

Thanks, it's useful to know. As a "consumer" of mysql it's kind of disappointing they don't do this kind of performance analysis in-house.

Re:Some clarifications on my benchmarks

[Bill, Shooter of Bul]

I absolutely agree. The good news is Mysql is going to open up its development process a little more to streamline the integration of changes / features from outside the company into official releases.

Re:Some clarifications on my benchmarks

[Vellmont]

Tuning the scheduler is critical to performance on this kind of workload. The other critical aspect is having a highly optimized kernel without concurrency bottlenecks. 2.6.20 fell over on kernel concurrency, and 2.6.23 fell over with the scheduler.

The interesting part for me is really performance across the board for lots of other different workloads, on a variety of different systems.

If the numbers are really 15% different, that seems essentially equivalent to me. I never understood why 15% better really matters when processor speeds, and processor cores are increasing on a yearly basis.

Re:Some clarifications on my benchmarks

[kkenn]

Yes, I agree. We in fact track a spectrum of workloads, and try to optimize for all of them simultaneously. Sometimes there are trade-offs but this is rare.

The main point you should take away from this is that FreeBSD 7.0 does not run into scalability bottlenecks on this configuration, so it can make efficient use of 8 CPUs where FreeBSD 6.x (and older Linux kernels) could not.

The scalability of the architecture is more important than a few % variation in absolute numbers, which as you say will be wiped out by the march of technology within months.

Re:Some clarifications on my benchmarks

[JasterBobaMereel]

The CFS may not scale well (and this needs fixing) but this is still primarily a server benchmark

I expect (but don't know) that desktop performance and the performance of other applications would be better with CFS than the FreeBSD Scheduler? ...but saying that it is nice to see that FreeBSD (which I always considered the Linux that wasn't) is a contender again if nothing else it will keep the competition on it's toes ...

Re:Some clarifications on my benchmarks

[kkenn]

Why do you "expect" this? The ULE scheduler is also designed with interactive (e.g. desktop) performance in mind, so your expectation seems unmotivated by prior probability and more by a prejudice that Linux must be better :-)

Re:Some clarifications on my benchmarks

[JasterBobaMereel]

I expect it because the scheduler is supposed to be completely fair (it's in the name?) rather than biased towards processes that are highly active (which I would expect on a server)

Linux is a kernel, it is not a scheduler, there is nothing stopping anyone retrofitting the same algorithm into FreeBSD, or vice versa

Linux is not better just different same as OSX, Solaris, etc are different ....

Re:Some clarifications on my benchmarks

[kkenn]

OK, so basically you're just going on marketing ("it says it's completely fair, that has GOT to be better than a BIASED scheduler!") and your own prior beliefs, instead of technical insight. Thanks for clarifying :)

Re:Some clarifications on my benchmarks

[JasterBobaMereel]

Shock horror non-kernel hacker makes assumptions and *says so* and gets flamed on slashdot ...

Hope you enjoyed a your 5 minutes in the spotlight

[Lost Found]

Looks like it didn't last for long:

http://www.kernel.org/pub/linux/kernel/people/npiggin/sysbench/

SCHED_ULE

[Inuchance]

I upgraded to FreeBSD 7.0 recently, and I have to wonder: Who came up with the name SCHED_ULE?

Re:SCHED_ULE

[kkenn]

AFAICR it was a suggestion made on IRC that happened to stick. ULE does not in fact stand for anything.

Re:Possibly-Jessica Rabbit

[Brandonski]

I'm not bad, I'm just drawn that way.

Re:You don't have to be Kreskin

[peterpi]

I would say that packages != programs.

With a debian "package", I know exactly how to install it (the same way as all the others), and I know that there is a set version of that package that corresponds to, say, "Debian Sarge". I know that if I install it, it will pull along any libraries it needs, and that it won't break anything already on my system. I know it doesn't always work like that, but that's the idea. I think of a "package" as part of the distribution. Somebody has decided that it forms part of the distribution, and has hopefully tested it as such.

A "program" is what Windows has so many of. But all bets are off when it comes to versioning, library dependencies, etc. Even how to install it. If you think of Windows as a "distribution", then it doesn't come with all that many packages at all. A Desktop environment, a browser, some photo and media tools. Mac OS X doesn't really fare all that much better. I love OS X to bits, but the first thing I did was install a third party program (firefox).

From TFA...

[Lonewolf666]

As Zpin wrote a few posts above, the linked PDF contains pre-CFS kernel benchmarks.

Short version:
Linux pre-CFS is faster than post-CFS, but FreeBSD still comes out ahead, by maybe 5%.

Re:From TFA...

[LizardKing]

The article also describes a FreeBSD 7.0 pre-release from October last year. This still had debugging code turned on in the builds, as mentioned on the NetBSD lists when Andrew Doran was comparing NetBSD -current SMP performance.

Re:You don't have to be Kreskin

[AJWM]

only OS with more packages is Debian
Whatever happened to Windows?

Vista. That's a non-operating system.

Re:You don't have to be Kreskin

[girasquid]

Toaster distros...

Also noted in the FreeBSD 7.0 release announcement

[bconway]

Here, and it applies to a significant number of other network servers.

Dramatic improvements in performance and SMP scalability shown by various database and other benchmarks, in some cases showing peak performance improvements as high as 350% over FreeBSD 6.X under normal loads and 1500% at high loads. When compared with the best performing Linux kernel (2.6.22 or 2.6.24) performance is 15% better.

http://people.freebsd.org/~kris/scaling/bind-pt.png

Summary:

* FreeBSD 7.0-R with 4BSD scheduler has close to ideal scaling on this test.

* The drop above 6 threads is due to limitations within BIND.

* Linux 2.6.24 has about 35% lower performance than FreeBSD, which is significantly at variance with the ISC results. It also doesn't scale above 3 CPUs.

* 7.0 with ULE has a bug on this workload (actually to do with workloads involving high interrupt rates). It is fixed in 8.0.

* Changes in progress to improve UDP performance do not help much with this particular workload (only about 5%), but with more scalable applications we see 30-40% improvement. e.g. NSD (ports/dns/nsd) is a much faster and more scalable DNS server than BIND (because it is better optimized for the smaller set of features it supports).

Re:You don't have to be Kreskin

[darthflo]

A package is a bundle of stuff that can be installed using your OS' package management facility. BSD's Ports, Gentoo's portage, Debian's apt (also used by Ubuntu). The "big two" commercial OSes don't really have an equivalent to that; Windows e.g. only lets you install some optional components using a unified frontend. Counting the number of packages is easily possible and done by the repository maintainers.
A program is quite hard to define. A handwritten script could be considered a program by some, others may reserve the term for publicly available software. The number of programs is very hard to approximate and impossible to determine unless you chose an uncommon, restrictive definition and a point in time of which you possess all information.

Nobody said Windows didn't have lots of programs and software available for it; probably more than any other OS family on the planet. It does not, however, have a central facility to classify and automatically install them from. (Cue jokes about IE + ActiveX doing a great job of auto-installing all the malware from MSFT's repository called "the intertubes").

Re:You don't have to be Kreskin

[Neil Hodges]

Oh really? Have you tried to use Cedega on FreeBSD? What about Wine (on FreeBSD 6 or older)? What about anything that uses NPTL? If the emulation layer worked as 2.6, it would run everything Linux can in binary.

Why do you "need" distros?

[argent]

Whats the advantage of not having any distros?

What's the advantage of having multiple distros?

that everything needs to be compiled from source (ala gentoo) or that everything is precompiled for somebody else's needs (ala debian)

If you want to compile from source, you can, that's how Ports works. If you want to use precompiled versions you can install packages. You don't need to have multiple distros to be able to configure the system the way you need, you start with a core OS (which you can rebuild from source if you *really* want) and then add packages. There are people who do canned FreeBSD installs and ISOs, similar to Linux distros, but without the distro drama.

(especially as stupid license nazis stop us sharing code *shakes fist*)

What on earth does that refer to?

Re:Why do you "need" distros?

[RiotingPacifist]

What's the advantage of having multiple distros? Choice
while some distros provide only Free software (debian) others provide easy ways of installing proprietary software (ubuntu)

theyre compiled differently
some are designed for servers ( compiled with flags that dont include support for libLatestGUI ) others a designed for desktops ( compiled with all the gui flags)
some are designed to run of liveCDs ( compiled with flags that support whats on the CD but nothing else ) others are designed to be permanent installs ( compiled with flags for everything )
youd need one hell of a binary package managment system to pull that off

theyre patched differently
while some distros will patch quickly to fix a bug, others will pay more attention to the quality of the code to prevent latter patching

theyre released differently
while some push fiarly stable releases out every 6 months (ubuntu) other have longer more stable release cycles (debian) or none at all (they stay in perpetual beta)
while some test software thoroughly and pay attention to fixing bugs, others get it working and push it out the door to the users

they develop different software
while one might want the develop an easy to use gui installer (ubuntu), another might develop a complex full of options CLI installer (debian)
while one might develop a new gui with flashy effects (suse), another might develop a new lightweight GUI for older systems
while one might concentrate on making drivers another might concentrate on supporting closed sourced drivers

Im no expert so some of the above examples might not be true.

AFAIK bsd code cant be clinked to gpl code ( i dont know much about licenses tho)

Re:Why do you "need" distros?

[argent]

I thought I had just gone through explaining how you didn't need distros to get choice.

You can do everything you want to do with a distro using ports and packages. FreeBSD has a "hell of a package management system". The FreeBSD core doesn't include the GUI (even X11 is optional) and you can build less than the core (PicoBSD, for example, which we used to make automatic "ghost"-like Windows NT install floppies at ABB).

Basically, almost all the options you're talking about are possible with FreeBSD... including going with a bleeding-edge version or sticking with a stable one. You could build a fancy GUI installer if you wanted... the installer just builds the file systems and unpacks the core tarballs and packages in place... or you could install the core by hand by mounting a new disk and running the appropriate fdisk, disklabel, mkfs, and tar operations by hand.

What you don't get is the option of ending up with a system where you have to learn how to admin it all over again. You don't get battling package tools. You don't discover that yast has blown away half of /etc behind your back. I am more than happy to skip the stuff you don't get.

AFAIK bsd code cant be clinked to gpl code

That does not happen to be the case.

Re:Hope you enjoyed a your 5 minutes in the spotli

[ivoras]

The arms race continues: http://jeffr-tech.livejournal.com/17426.html#cutid1

Freebsd 7 has jemalloc, Linux doesn't yet

[mark_osmd]

There's an obvious issue I see here as to why there's this 15% difference. Freebsd 7 has jemalloc but the older Linux kernel they tested didn't. Linux will get jemalloc in the near future. It would be interesting to retest these benchmarks with both sides having the new malloc. Mark

Re:Freebsd 7 has jemalloc, Linux doesn't yet

[Anonymous Coward]

There's an obvious issue I see here as to why there's this 15% difference. Freebsd 7 has jemalloc but the older Linux kernel they tested didn't.

So, basically, Linux isn't as fast as FreeBSD because it hasn't yet incorporated FreeBSD's code. Thanks for clarifying. :-)

Isn't BSD dead?

[theendlessnow]

Of course, this one is about SMP, so maybe this is really "Dawn of the Dead in 3D".

Re:You don't have to be Kreskin

[nxsty]

Why on earth do you think FreeBSD is a dying OS? '
Because netcraft confirms it.

Re:Hope you enjoyed a your 5 minutes in the spotli

[SanityInAnarchy]

From that page:

Disclaimer: I'm not an expert with FreeBSD or MySQL. The Linux kernel used is not a "stable release" whereas FreeBSD is (although I'm not aware of any significant performance improvements over the 2.6.24 kernel -- 2.6.25-rc4 is simply what I have installed on the machine). Compilers were different versions of gcc-4.2, MySQL code base and compile options were slightly different due to being compiled from ports on FreeBSD. In other words, I can't say definitively that Linux is faster than FreeBSD. My primary interest is to see that Linux's performance problems on this workload are under control. Questions or suggestions are welcome.

And I do tend to agree with that. Ultimately, there are enough reasons keeping me on Linux (vs FreeBSD) that as long as there isn't that huge gap (seen in the graph linked to), I don't really care that much about whatever's left.

Nor am I particularly loyal to Linux. I understand and respect the GPL, but if there was another sufficiently open OS that beat Linux in ways I care about, I'd probably be using it, at least at home.

Re:You don't have to be Kreskin

[CastrTroy]

FreeBSD hardware support is not bad, but it is nowhere near as complete as that found in the various Linux distro's.

If it's not even as good as Linux, then it must be bad. That's one of Linux's major faults, and probably the most cited reason for not using Linux. If you don't have good hardware support, you are missing out on a lot of users. Because most people aren't willing to buy a specific machine, with just the right hardware just to use your OS. I'm an avid Linux user, but even I admit that their hardware support level isn't quite where I would want it.

Re:Hope you enjoyed a your 5 minutes in the spotli

[kkenn]

Well, it's actually taken the Linux developers more than 12 months to get to this point, which is a little longer than 5 minutes :). I have been in contact with Nick and he had trouble replicating the older results, so it is possible that his system is still not configured properly on the FreeBSD side. Even if it turns out that the next Linux kernel fixes the performance deficit, then that's fine too. Ultimately both kernels will have to asymptote to the same performance anyway, assuming both are efficiently designed.

Re:You don't have to be Kreskin

[TBerben]

Because netcraft confirms it, you insensitive clod!

Re:You don't have to be Kreskin

[Smackheid]

It honestly seems to me that the distinction between server OS and desktop OS is its own entire discussion; if we can come to a good notion of what either means

I don't think the desktop/server distinction means anything anymore, and for three reasons. One, cheap commodity hardware. Two, the literal glut of software. Apache too bloated? Use lighttpd. KDE overblown? Use fluxbox. And three is (open) standards (no sniggering in the back ,please.) When everything uses TCP/IP or XML or whatnot, interoperability increases exponentially.

Simply put, we have power and flexibility at easy disposal. What you do with it is up to you.

eight?

[dwater]

Is 8-way still considered SMP? I mean, 8-way is kind of consumer level now, isn't it? Even Apple produce 8-way machines SSI machines.

Get it to scale on some serious SGI kit, for example, then we'll talk.

Re:eight?

[PitaBred]

...what? I think you don't know what "SMP" stands for. It has nothing to do with big iron vs. consumer kit, and everything to do with the processor configuration. And SSI means nothing unambiguous as far as I can tell, at least in relation to CPU's. Perhaps you can help? The serious SGI kit you reference really only has a difference in the CPU architecture... it should scale just as well on Itanic as well as it does on x86/x86-64.

But I'm probably rising to a troll. Or an idiot. Or both.

Re:eight?

[Anonymous Coward]

Considering those SGI's 1024 CPU thingies are not SMP machines I'm guessing it's established who the idiot is...

Re:eight?

[dwater]

It was a lame attempt at being funny. Should have signed it 'smp snob' I guess.

Re:eight?

[PitaBred]

Sorry then :) Veiled sarcastic comments are even harder to discern online...

Re:eight?

[dwater]

Wow. An apology on /. - I'm not sure how to respond to that. So unusual. :p

btw, 'ssi' stands for 'single system image' - the concept that the entire computer is running a single copy of the OS and so each application has access to all the resources of the computer ...or something like that. It's supposed to exclude clusters since they don't work well with some application/problems.

Re:eight?

[dwater]

Considering those SGI's 1024 CPU thingies are not SMP machines I'm guessing it's established who the idiot is... Well, I don't think that quite qualifies as 'idiot'. NUMA scalability is still relevant and interesting - and some such systems are indeed SMP (ie systems with a single node) - their Altix ICE seems to go up to 2 quad-core Xeons per node, which would be 8 (it seems to be very similar to one of the configs they used in TFA).

In any case, I didn't mention which "serious SGI" kit. Even their power series systems back in the '80s went upto 8 CPUS (4D380S), and they've had several different architectures since (though mostly ccNUMA). Their Challenge XL (hehe)series also went upto 8, and applications scaled very nicely too.

Of course, other manufacturers continued making even larger SMP systems - wikipedia mentions "ASCI Red had 4,510 [cpus]".

Perhaps the linearity of the scaling performance from 1-8 shown in TFA is interesting, but 8 is pretty where things start to get interesting (scalability-wise).

As a side-note, I read this in wikipedia's smp article :

"It should also be noted that dual socket Opteron designs are technically ccNUMA designs, though they can be programmed as SMP for a slight loss in performance."

So they could have run in SMP mode, I suppose, and wikipedia doesn't mention the Intel's design (so I suppose it's SMP, but Intel can do some weird stuff too).

Re:You don't have to be Kreskin

[imus]

http://filebox.vt.edu/users/rtilley/public/bsd/

Nuff said.

Re:You don't have to be Kreskin

[eldepeche]

The Debian installer gives you a choice of optional stuff at the end of the installation, like LAMP server, desktop environment, etc. I believe the FreeBSD installer does the same thing.

Re:You don't have to be Kreskin

[quitte]

huh? Linux is the OS with the best hardware support you can get. I have never installed Windows without having to get 90% of the drivers from cds or the web. With Linux otoh the hardware support became that good that youll have less trouble just buying something and see if it works than figure out what works beforehand. And whats even better: no installing drivers necessary. they all are already there. Please name a couple of devices that dont already work in linux. I can think of only one: bisoncam. and driver support is on its way.

Re:You don't have to be Kreskin

[Bert64]

How about vmware? I dont think that runs on bsd either...
Linux will run virtually everything bsd will (after a recompile)... And most linux apps will recompile for bsd, but bsd's linux emulation isn't perfect when it comes to precompiled linux apps...
There's also hardware support, does bsd have drivers for modern ati videocards yet? I know the linux drivers suck, but its slightly better than nothing.

Re:You don't have to be Kreskin

[Knuckles]

And that's why Debian is not a "desktop OS" (for the casual user group).

Re:You don't have to be Kreskin

[CastrTroy]

It may come with a larger number of drivers included with the operating system, but that doesn't mean that the drivers work. I had a Voodoo 3500 TV card. It worked under the 2.4 kernel, but not under the 2.6 kernel, because whoever was maintain the drivers disappeared. Most video card drives are way worse quality then what you get on Windows. Sure the drivers exist, but they are buggy, or quite slow compared to their windows counterparts.

Seriously: who cares?

[mcrbids]

Yes, I meant that: who cares?

Nobody living outside their parents' basement is going switch from Linux to BSD for a 15% performance increase. Somebody already using BSD might upgrade if the latest BSD kernels and environment are significantly better than past environments, but 15% is so slight as to be basically undetectable in a real-world environment!

My rule of thumb for upgrading equipment has been to not bother until we hit a full order of magnitude improvement. In other words, if 1) we can 10X the performance of a system AND 2) there have been complaints about performance, then the upgrade is probably worth it. Even then, the value is dubious. For example, in Postgres, (or any other database application) it's very typical to see 100x improvement simply by creating an index!

Maybe this is good for frail BSD egos, who have been long bruised by the mindshare success of Linux over the more historic and "more free" BSD. So be it. But it's not performance that's kept me from using BSD, it's familiarity and the pain of switching. And that's also what kept me running it yesterday, will today, and tomorrow too.

Don't get me wrong - I would hate to see BSD "die" in any meaningful way. The different cultures between Linux and BSD create a very rich, diverse environment where ideas can be tested, and the cross-feed of proven concepts and technologies (EG: Open SSH) benefits all involved!

But the benefit of a 15% performance increase is almost never going to be sufficient reason to pick one computing technology over another!

Re:Seriously: who cares?

[Pharmboy]

But the benefit of a 15% performance increase is almost never going to be sufficient reason to pick one computing technology over another!

So if you are google, and your software will all 100% run with Linux or BSD, you don't see the idea that 15% better performance means the same work with 15% less machines means something? In certain cases, 15% can mean thousands or millions of dollars, all for changing to an operating system that will basically run on the exact same hardware and run the exact same software, after a recompile.

No for most it isn't a big deal and may not make people CHANGE operating systems on existing hardware. We use both Linux and BSD, so it *might* make me consider BSD instead of Linux on the next new box. I'm likely not alone in this.

Re:Seriously: who cares?

[cblack]

I would think the cost of changing the OS in an environment large enough such that a 15% performance increase could result in millions of savings might be an expensive proposition on its own. Despite the impression many home users or small shops have, changing an OS in a large environment is far from "free".

Re:Seriously: who cares?

[Pharmboy]

Despite the impression many home users or small shops have, changing an OS in a large environment is far from "free".


but migrating new machines that are constantly be added weekly is much less expensive, and ROI *might* be reasonable in the right circumstances.

Re:Seriously: who cares?

[mcrbids]

Compare 15% against Moore's law, and you find that it equates to a few weeks delay in the price-performance curve.

If it takes more than a few weeks to make the switch, you've already lost your benefit, as well as the potential of destabilizing your administration of those systems. Backups have be revisited, since the file tree will have changed. Network monitors will have to be updated, and tested for compatibility changes. Little one-off scripts to solve problem X or Y in a hurry will break. Admins will have to be trained, and will make more mistakes for a while until they find out what not to do. Unforeseen wrinkles will inevitably appear, Etc... Etc... Etc...

Worth it for Google? Not a chance!

Re:Seriously: who cares?

[Brandybuck]

But the benefit of a 15% performance increase is almost never going to be sufficient reason to pick one computing technology over another!

Unless it was Linux that recently edged ahead with a 15% increase, then every product manager with a Linux fanboy in his company would be indundated with demands to switch. I agree with your basic premise that one shouldn't blindly switch operating systems based on a few benchmarks. But I do have to disagree with your implication that only BSD user have ego problems.

Re:Seriously: who cares?

[Cal Paterson]

Nobody living outside their parents' basement is going switch from Linux to BSD for a 15% performance increase. Somebody already using BSD might upgrade if the latest BSD kernels and environment are significantly better than past environments, but 15% is so slight as to be basically undetectable in a real-world environment!

Obviously, it depends on cost:benefit, which is exactly why there is no rule of thumb. Blanket generalisations and "rules of thumb" are a bad way of making a decision for everyone that they don't need to make

That isn't the important point though; the important point raised is that CFS might be less good than promised and that there's the accusation that Linus picked CFS over other projects because Ingo is in the in-crowd. I don't follow lkml, so I wouldn't know whether this is true.

Re:Seriously: who cares?

[hxdmp]

Wrong! Commersial Database vendors will give their eye teeth to get 15% higher TPC-C scores. 15% isn't something to sneeze at when it comes to benchmarks. Now if you can get the 15% for "free" by switching to a different OS to submit your scores on.... They 100% will.

Re:Seriously: who cares?

[BlackCreek]

Yes, I meant that: who cares? Nobody living outside their parents' basement is going switch from Linux to BSD for a 15% performance increase. Somebody already using BSD might upgrade if the latest BSD kernels and environment are significantly better than past environments, but 15% is so slight as to be basically undetectable in a real-world environment!

I only use Linux as a desktop OS. I don't know much about the implications of this particular benchmark, but I care a lot about the current schedule work, for the simple fact that they have been causing me problems for my desktop use.

https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/131094/

And Linus rejected Con Colivas

[slashdotlurker]

The mind boggles.

Re:You don't have to be Kreskin

[Just Some Guy]

Whatever happened to Windows? Or does programs != packages?

Funny you should mention that. If you rule out junk software like sparkly mouse cursors, Windows seems to have less software than any other major OS (given that most Unix software is already ported to OS X, or at least can be). I feel constricted every time I have to use a Windows box because none of the programs I want to use are installed, or even readily available. No, I'm not joking.

FreeBSD 7.0 performance

[erc]

I run 7.0 now - I was running 6.2, then upgraded to 7.0 - a 10 minute task, by the way - and gained a noticeable performance increase. I haven't had the time or the inclination to run any benchmarks, but for a MySQL/Escapade/IMAP/squid server, I can certainly tell the difference.

I did this once

[SteveFoerster]

I did this once. Your mod points are undone and lost.

Re:I did this once

[mrv20]

The reason behind this is explained here http://slashdot.org/faq/com-mod.shtml#cm1800.

Re:Server vs. Desktop

[MrNaz]

That's a shame, because the FreeBSD developers were pinning their hopes on you and you alone.

Re:You don't have to be Kreskin

[Toby_Tyke]

I am so fed up of reading this. Yes, Linux has more drivers installed "out of the box" than windows. Big deal. Every single piece of hardware I have ever bought came with a CD that had drivers for windows. Yes, it's a bit of pain having to install them all manually after reinstalling the OS, but you only have to do it once. It's far more of a pain to find that you shiny new toy has no working drivers for Linux.

I use Linux as my desktop OS, but I am no prepared to ignore it's shortcomings. From where I'm sitting right now I can see three devices that do not work with Linux. All of them have drivers for XP (not sure about vista).

I see hardware support like this. If a driver exists for Linux, then the support is generally far better than windows. You plug it in, it works. If, however, your distro does not have a driver, then you are very probably shit out of luck. The device will either not work at all, or require hours of fiddling. Windows on the other hand, has virtually no "out of the box" support. Plug anything in and prepare to be met with yellow exclamation marks in the device manager. The difference is that unless it's some ancient or obscure bit of kit, it will either come with a driver disk or have a driver available on the manufactures web site. Every piece of hardware you could buy works with windows.*

And since you asked:
My PCLine webcam, my Nokia phone, and the USB modem my ISP gave me. Now to be fair, it might be possible to coax all of these devices into working if you know the correct incantations and rituals, but in every case they failed to work "out of the box".

* Before someone replies to me with an example of a device that won't work in windows, allow me to qualify this. I'm referring to to desktop hardware, manufactured in the last, ooh, lets say seven years. I defy you to find anything on PC world's shelves that is not Windows XP compatible ( I have never used Vista, so in a break with Slashdot tradition, I'm not going to spout off about something I know nothing about). I'll bet you a months salary I can find something that won't work with Linux.

15%?

[Danathar]

dead + 15% is still dead.

Re:You don't have to be Kreskin

[toadlife]

I wont argue with you that for desktop purposes, Linux does better job out of the box, but I do own a piece of hardware, the Areca ARC-1210 SATA controller, that was supported from day one in FreeBSD out of the box, and not in the two or three Linux distros I tried. Linux support existed, but you had to download the driver separately, or in one case enable the module during the install (and being a FreeBSD person, I had no idea how to do that). I bought the card for FreeBSD support, so the flaky linux support was not an issue.

Re:You don't have to be Kreskin

[router]

Amen. I want a piece of software on a linux box, open the pkg mngr and click (or open a terminal and type) and its there. And when I want to update, everything does, automatically, with one command. Usually in cron. If I want to reinstall, copy home and the dir with all the dl'ed pkgs in it somewhere, nuke, copy back, update from the dir, and back to happy. It ain't religious anymore, Windows really does suckTM, I will take any *nix os. And what up with Win2k3 server? 885$?! For a damn OS? Damn, it costs twice the hardware its going to run on. Will all you stop freaking developing on Windows already? Hardware is commodity, so I shouldn't be paying more for a damn shiny disk than 2 (or 3!) 1u hearing-destroying space heaters, dig? Its less I am willing to pay for your crapware; my budget gets almost 3k$ richer for your fscktard masterpiece spaghetti-code niche software if I don't have to pay the MS (win2k3/SQL) tax to run it. Think of it that way, next time you open Visual Studio .NET and feel the urge to code. Fsck.

andy

Re:You don't have to be Kreskin

[mustpax]

The difference is in the real-time scheduling requirements that come with a GUI. Very minor delays in GUI rendering have very perceptible impact on the snappiness of a UI. Server workloads (DB, HTTPD or whatever) have less stringent real-time requirements. Throughput ends up mattering more as long as the latency is in a reasonable range.

So, is this picture an accurate respresentation..

[Anonymous Coward]

So... is this picture an accurate representation of FreeBSD vs Linux now?

Re:linear scaling? not according to their graph.

[Just Some Guy]

They need to retract their claim. That graph clearly shows a performance difference based on installed CPU count.

Alternatively, you could bring your definition of "linear" in agreement with the rest of the world's, meaning "looks more like a line than anything else".

Re:You don't have to be Kreskin

[pajor]

What metric? Desktop drivers.

Re:You don't have to be Kreskin

[Ilgaz]

It probably has a lot to do with FreeBSD having a much more focused niche. FreeBSD is really tuned primarily for servers. You can use it on your desktop, but that's not really it's main purpose. Linux on the other hand, has really branched out. It has desktop distros, server distros, embedded distros, and probably a couple other areas I haven't thought of. In one way of thinking, FreeBSD also runs on Desktop, Server, Embedded. It is also damn popular and user friendly at nerd sickening levels.

OS X ;)

Re:You don't have to be Kreskin

[ducomputergeek]

You don't use the latest and greatest consumer hardware on FBSD. That's why my primary computers are all Mac's. But I am typing this from an old Dell Inspiron 1000 laptop with FBSD 6.2 installed and it works like a charm on a 2.2Ghz Celeron and 256MB of Ram. I've found FBSD to run very snappy on older hardware. Makes for cheap development machines when I'm developing specific web applications.

I dev

The Linux people all want to know what distro I'm running KDE on. Half think it's Kubuntu. When I tell them it's FreeBSD, they look at me all googly eyed.

Re:You don't have to be Kreskin

[Architect_sasyr]

Pity this AC got a -1 for it, so I'll whore up a bit of my Karma to restate the point:

"Don't forget, there's always PC-BSD for the Linux users - simple, point'n'click installer, etc."

This isn't really flamebait, or trolling. The current trend for Linux users (especially Ubuntu users) is exactly that, sure they have the power of the command line but most everything is done through $package_manager via the GUI. To draw slightly on my own experience, my IRC channel has around 40 people in it, so yes it is a small number and not really viable for this sort of analysis. The entirety of the channel (not including myself) runs Ubuntu or Windows, and whenever we get into a discussion about how best to do things, the discussion invariably leads to "go to x menu and click y". It's easier, hell it might even be faster, but the fact remains that most users (Linux and Windows alike nowdays) are looking for a simple "point'n'click installer"

PC-BSD gives them that, and it's a nice, stable, and solid system.

Besides which if anyone wants to argue that FreeBSD isn't up to the task, let's get some Mac fanboys in here to tell us about their favourite OS.

All that aside, of the two tests in the article, was the Linux guys one actually done properly? Look at all his notes down the bottom, different compilers, different code bases, bleeding edge kernel? Sure there are no major points between 2.6.24 and 2.6.25-xxxx but everyone refines their code slightly, I'd be surprised if there wasn't a slight performance review.

But ultimately, who cares, so long as the OS I select for the job works...

Re:Dual Core diff; more so quad core

[lpq]

A dual core is likely to be different from a dual processor machine. With Intel's Core2 Duo machines (am only using that processor because I know it's architecture, not because it's better or worse than anything else), both cores on a chip share the L2 cache. So a Dual Core Xeon with 8MB-L2 cache, shares the caches between the two cores and is not the same as 2 processors with each having 4MB of L2 cache. Besides the ability to have 1 Core use 8MB of the cache (presuming the 2nd core is forcibly halted and left idle), there are scheduling differences and differences in migration costs. Intel's 1st Quad core chips after the Core 2, were logically 2-Core2 Processors on the same chip. Each pair shared an L2 cache with their being a total of 2-L2 cache's on the one chip.

In some ways, that quad arrangement is like a Dual-Socket motherboard that has a Core2 Duo in each socket. Migration costs between adjacent cores (if migration includes cache loading costs) would be considerably less than between the two separate processors.

I believe the first Dual Core chips were similar to Dual processors machines in that each core had its own separate, fixed size cache. Logically -- one could achieve maximal resource usage on Processors with shared-caches, since whether your workload involved 1 active thread or multiple, the threads that are active can use all of the available core, whereas multi-core processors with each core having it's own separate cache will be limited to that cache even when other cores are idle.

At the time the Core Duo came out, AMD chips seemed to mostly (?completely?) sport per-core cache's, so the Core duo was a jump forward. Which the Quad-Core2 based chips had fully shared L2 caches -- would have been a no-brainer to upgrade to a quad-core with 8M L2 from a dual-core with 8M, but the processors on the quad core chip would be limited to 4M, max/core (or per/pair), whereas the dual-core chips could use up to 8M cache.

Of course the impact of cache size and whether it is sharable is totally dependent on what program(s) you are running, but local benchmarks between a 2GHz-8M-Core2Duo and a 3.2GHz-4M-Core2Duo showed the 2GHz beating out the 3.2GHz chip on small-medium problems with the 3.2GHZ chip taking the lead, only, in larger problems.

Supposedly, the linux kernel scheduler (pre-CFQ), recognizes the increased costs of inter-Processor switching being higher than intra-processor switching, but I've been unable to verify this. It might require some manual configuration using "CPUsets", but don't know.

FWIW, the new CFQ-cpu scheduler (which is different than the block-layer's CFQ Block-I/O scheduler) seemed awfully rushed into use as the "mainline" scheduler. I think it is because Linux has a "design choice" that it doesn't allow for modular CPU-schedulers as it does in the case of "block-i/o" (and USB I/I scheduling, and file systems, and choice of network layer, and partition type ...even partly with security (a hybrid model with some security being configurable, (LSM) and some designed not to be (the "standard", user-controlled Unix file-access bit checking isn't modularized). It's odd that CPU scheduling was thought to be a 1-size fits all model when virtually nothing else is). But because it isn't configurable, there was no way to make the CFQ cpu scheduler an optional, _testable_ scheduling module before it was chosen as the "one-and-only" model.

Re:You don't have to be Kreskin

[jgoemat]

Exactly. I mean, who cares about performance on a dying OS? ;)

Sounds like something Hitler would say...

Re:You don't have to be Kreskin

[dbIII]

I defy you to find anything on PC world's shelves that is not Windows XP compatible

Any CPU more recent than the Pentium Pro. Of course Windows XP 64 bit and Server 2003 fixed this and implement the extension to allow memory access beyond 2GB.

Lies...

[Viper233]

Lies, damn lies, statistics and bench marking
=)

Re:You don't have to be Kreskin

[Mista2]

Drivers - I have a nice modern PC, but my scanner is no longer supported under Windows by the manufacturer. The drivers for XP do not work in Vista (I actually had trouble with it since XP SP1) and HP will not be releasing new drivers for Vista. Under Suse 10.3 and Ubuntu 7.04 it works fine. Why? because some other linux hackers have the same sort of scanner and reverse engineered the driver. it will probably keep on being supported and working until the SCSI interface no longer exists. I call that better driver support. Under an opensource system the hardware can still be supported by people who still feel that that hardware has value, long after the manufacturer has abandoned the product. Take the Apple Newton and Amiga as examples for complete abandoned systems that still have an active user base.

Re:You don't have to be Kreskin

[Grayswan]

How did you wind up with all this hardware that doesn't work with your OS? It should be a straightforward matter to only buy things that are supported. Granted, you can't expect that sort of thing from windows users and maybe that is why Linux/* isn't for the general populace. But, If you had bought compatible stuff, it rewards the manufacturers that support linux.

Re:You don't have to be Kreskin

[dpninerSLASH]

I can't be the only one who caught the following quote in the page linked to in the updated section:

In other words, I can't say definitively that Linux is faster than FreeBSD.

Re:You don't have to be Kreskin

[Toby_Tyke]

The webcam was given to me, the modem came from the ISP (I use my own router any way), and I don't really care that the phone isn't supported. The only thing I need to hook it up for is installing apps, and I only do that very occasionally, so rebooting is no great hardship. I selected the phone on other grounds. Which, really, is my point. Every phones software works with windows. "Is it compatible with my OS is not an issue for windows users. Despite all the strides made in the last few years, it still is for Linux users.

Re:You don't have to be Kreskin

[Toby_Tyke]

The drivers for XP do not work in Vista

I did explicitly say I was talking about XP.

I actually had trouble with it since XP SP1)

How old is it? Because I also said seven years old or less. and SP1 was 2002, if memory serves, so it's at least seven years old if it's pre SP1.

Having said that, I do take your point. One massive benefit of open source is better support for older hardware. But that's not what I was arguing about. I explicitly excluded older hardware from my argument. What I was pointing out is that every piece of consumer hardware (with the obvious exception of Mac only stuff) you can buy today is supported under windows. That is not true of Linux.

Take the Apple Newton and Amiga as examples for complete abandoned systems that still have an active user base.

I know. I still have working A1200. And a working Speccy +3.

Re:You don't have to be Kreskin

[hxdmp]

Add to this list my Logitech USB headset (headphones + microphone) won't work out of the box on Fedora Core 8.

Re:You don't have to be Kreskin

[micheas]

"Is it compatible with my OS?" is not an issue for windows users. Despite all the strides made in the last few years, it still is for Linux users.

I believe you meant:

"Is it compatible with my OS?" is was not an issue for windows users. Despite all the strides made in the last few years, it still is for Linux users.

As windows will not mean Windows XP after next year but Windows Vista.

Re:You don't have to be Kreskin

[Allador]

PAE has been in windows since at least NT4, maybe earlier.

On the XP desktop (x86 version), MS made a support choice to not support PAE, due to (their claim) driver issues. If you'll remember, early versions of XP supported PAE on the desktop, but then was shut off around XP SP2. MS claim is that a large percentage of drivers for consumer hardware were not built to handle both PAE and non-PAE environments, and so caused system crashes. Therefore, as a tradeoff between scalability and reliability, they chose the latter.

Typo in title?

[willodotcom]

Bests or beats?

Re:You don't have to be Kreskin

[dbIII]

Yes he was talking about XP - hence the quick answer. The support for PAE is not paticularly usable outside of MS Server 2003.

Re:You don't have to be Kreskin

[dbIII]

I'm running a Logitech USB headset on Fedora Core 6 without problems. One problem that could crop up is if alsa is looking for sound from other hardware and has effectively muted the headset. You'll just need to play with your distros mixer program just like the MS windows people have to.

Re:You don't have to be Kreskin

[kkenn]

Yes, indeed. So far Nick has not been able to replicate our results, so there is clearly something different about his setup that needs to be understood. One hypothesis is that he is using a self-compiled glibc, and maybe something in the fedora 8 glibc is either slowing performance, or was fixed in the version Nick is using. Or maybe it is something non-default in his kernel. We need a baseline comparison of the same configuration (fedora 8 + updates) on his hardware before we can determine that some other Linux configuration improves performance.

BSD license is opened for abuse

[GNUPublicLicense]

It's the BSD license which spawned all the proprietary *nix... and made a mess of it pushing the borg OS on the desktop. Moreover if you want performance: do not use a relational database. Whatever happens, THE kernel have to be GPL. Do not contribute to BSDed software, only single licensed GPLed ones.

Re:You don't have to be Kreskin

[dave87656]

FreeBSD still occupies 4 of the top ten most reliable server categories according to Netcraft and it holds the top position.

http://news.netcraft.com/archives/2008/02/12/swishmail_is_the_most_reliable_hosting_company_in_january_2008.html

Re:You don't have to be Kreskin

[dave87656]

Nick says this, as well:

"The Linux kernel used is not a "stable release" whereas FreeBSD is (although I'm not aware of any significant performance improvements over the 2.6.24 kernel -- 2.6.25-rc4 is simply what I have installed on the machine)."

Re:You don't have to be Kreskin

[Toby_Tyke]

Sorry, I have specified repeatedly elsewhere in this thread that I am talking about XP.

BLA BLA BLA ....

[yvesdandoy]

"and mine is faster that yours !!!! - That's not even true, mine is faster than yours ........."

One set of figures, two different conclusions.

[Anonymous Coward]

Lies, damned lies, and benchmarks. Some things never change.

Re:You don't have to be Kreskin

[oscartheduck]

The reason I started using FreeBSD was because I went to the store and bought a wireless card, a linksys something or other. I got home and SuSE couldn't detect it. Neither could Ubuntu (this was around the days of Ubuntu 5.something) nor Debian. I had a friend who was a FreeBSD nut who walked me through the install and my wireless card worked straight away.

Whether desktop drivers are a good metric really depends on what hardware you own. Sometimes what you need just ain't there.

The red!

[Yfrwlf]

It burns! Oh, it's just the BSD section.

But seriously, where is the third test to confirm who's test is accurate and who's is a lie? Or are they different, and both Linux and BSD perform better in their own way? :)

Re:linear scaling? not according to their graph.

[tetlowgm]

Linear doesn't necessarily mean that the slope is 1. It means that is scales linearly, as opposed to say exponentially or logarithmically.

Re:You don't have to be Kreskin

[petrus4]

If it's not even as good as Linux, then it must be bad. That's one of Linux's major faults, and probably the most cited reason for not using Linux.

I don't actually blame Linux for lack of said hardware support, personally. I blame hardware manufacturers for making closed hardware that is barely functional outside Windows.

There's a reason why USB in particular is barely supported by anyone outside Windows; it's because, contrary to the name, in software terms it ain't universal.

Re:You don't have to be Kreskin

[hxdmp]

No this is a brand new model, that upon research - I need to download an updated driver, compile and install it. While this is doable, I would have preferred it work out of the box - or I could just do a binary update and get it working.

Re:You don't have to be Kreskin

[dbIII]

usb-audio module.

Not so fast there sparky

[tuxgeek]

Linux is still MY favorite OS above all else.

I'm not subject to M$ lock-in, I have ten times the applications you have in your best BSD variant.
But most important of all, the last time I tried to install FreeBSD, I ended up with something that no average user could use. I'm not a BSCS, I'm a business owner looking for an easy to install desktop OS that is production ready, reliable, stable, and not Microsoft.

The BSD system is still a cousin and great for server application but it is not ready for the desktop prime time. When it has the software ported to it and is as simple to install as Debian Etch or Lenny, then you may have something to brag about and I'll give it a sincere consideration.