FreeBSD 8.0 vs. Ubuntu 9.10 Benchmarks
An anonymous reader writes "Phoronix has brought benchmarks comparing the FreeBSD 8.0-RC and Ubuntu 9.10 Alpha 6 operating systems. FreeBSD rather ends up taking a wallop to Ubuntu Linux, but there are a few areas where FreeBSD 8 ran well. They also posted benchmarks comparing this near-final FreeBSD 8.0 build to that of FreeBSD 7.2 to show performance improvements there but with a few regressions."
...once I'm done compiling.
I'm sort of curious what the point is of comparing an alpha to a release candidate. Additionally it's a minor update versus a major update. Throwing in an older release makes it all the more pointless as I'm not seeing anywhere in the summary that they disabled debugging.
It's interesting how on page 1, there are three graphs. Two of these are "lower is better" (where Ubuntu wins), however, when FreeBSD wins the graph is displayed in MIPS where "higher is better", thus appearing to make Ubuntu win there too.
If you're a casual reader not paying attention, reading, or clicking on to page 2 (and you know I'm right when I say that's most of the people reading this article), you can see where this is going.
The article is of little use other than tell the general populace of Slashdot that FreeBSD 8.0 and Ubuntu 9.10 are right around the corner, and that we should be hyped. Also FreeBSD 8 is a little faster than FreeBSD 7.2 but a lot slower than Ubuntu Linux 9.10
I'm not surprised, however I do belong to the group that does not really care about relative performance to other OS's as performance is only one of the aspects from the vector of decisions we had to make to finally choose FreeBSD for mass-scale deployment.
Benchmarks are useless. There are way more important things to judge an operating system then "speed".
Does Ubuntu have nearly as good of documentation? No. It has that "info" nonsense.
Does Ubuntu provide a stable platform to build a server? No. It, like most linux distros, changes whole versions during updates. That isn't stable.
Does Ubuntu provide a way to strip itself down to the bare metal? Ain't as easy as the BSD's.
Is Ubuntu built around solid engineering and design, or politics? Depends--Ubuntu seems to be less afraid of the big bad FSF as other distros, but it still is steeped in an OS built for politics. FreeBSD is pretty tame and tends to focus on solid engineering rather than political maneuvering.
But really, Comparing FreeBSD to Ubuntu is like comparing OpenSolaris to Windows 7. FreeBSD is largely a server operating system were as Ubuntu is an end user operating system. And if you are comparing server operating systems, there are far more important criteria than "speed". Things like version stability are vastly more important.
When my friends ask me about Linux, I usually steer them toward Ubuntu first, as it's the most user friendly and well-supported distro out there. Canonical really puts a lot of development work into it, and it shows (in this result and many others). In the past, I usually avoided the Linux topic altogether, as there were so many confusing distros that even trying to explain the concept of Linux to non-geeks (and even many geeks) was a huge pain in the ass. So, I for one welcome our new Ubuntu overlords.
SJW: Someone who has run out of real oppression, and has to fake it.
lrn2preposition
The areas where FreeBSD gets its ass kicked by Ubuntu start on page 7...
It seems to me like FreeBSD's real problem is incredibly bad I/O compared to Linux. The majority of the CPU-heavy tests were nearly neck-in-neck.
Maybe this is a sign that more systems will start coming with Ubuntu already equipped?
"Chance favors only the prepared mind." -Archimedes
My Karma is going to take a hit for this
What karma? You're already posting at +0, even with being a subscriber...
When there's something you need to do that can't be done with Windows but can be done with Lunix, keep in mind that you can do an even better job with Mac OS X.
Except true multitasking? That shared menubar seems to assume you're only doing one thing at a time, and Windows' lack of proper focus-follows-mouse (ie, without raise-on-click) likewise.
Some argue that BSD can do it better but no one makes software for BSD since no one gives a flying fuck.
I was under the impression that the BSDs could generally run Linux binaries (some sort of compatibility mode thing)?
With all seriousness in mind, BSD isn't useful for anything really.
What about as an embedded OS for consumer electronics?
" FreeBSD rather ends up taking a wallop to Ubuntu Linux, but there are a few areas where FreeBSD 8 ran well." Not one of the most well written sentences, but it isn't very good either.
Is taking a "wallop to" something a good thing or a bad thing? I guess that's one way to make sure we read the story is to have the headline make no sense...
Eight pages of bar charts, each gray-on-gray. On half of them, shorter bars mean better performance, on the other half, longer is better; the only way to know which is which is in a legend, written in a small font.
Here's a suggestion: color-code the bars! Green is good, red is bad, yellow is in the middle of the road. For bonus points, choose the saturation based on magnitude of the differences. If the numbers are close, go with grayer bars, if the differences are dramatic, use dramatic colors.
Finally, how about a line chart at the end showing all of the numbers in one place? Yeah, you'd need to convert everything to be consistent if longer or shorter is better, but that's a good idea anyway.
Nothing for 6-digit uids?
I'm not a BSD user, but I don't see BSD taking a real kicking in these benchmarks. In the majority of the benchmarks, the average user could not discern a speed difference.
It depends a lot what you do - backend server/support? embedded? no way I'd use MacOSX, and there are even a lot of desktop and other frontend uses where I wouldn't recommend it to anyone but the absolutest moron or someone who knows what they're doing - then again I'm considered an improper mac user by many since I use macports and do professional stuff where pro is not defined as "some sort of design as claimed by pretentious designers".
It's fairly difficult to bungle traditional CPU-heavy loads. The kernel just needs to get out of the way and let userspace do whatever it wants to do. Try the same tests on Mac OS X and Windows (assuming they compile), and you'll see just about the same performance.
Finally! A year of moderation! Ready for 2019?
You'll have to explain that to Codeweavers, the Win4BSD people and the other commercial vendors that make software for it. Sure there probably isn't as much stuff aimed at home users as for Linux, Mac or Win, but there is a substantial amount of commercial activity involved. It's odd that some random company would fund a new routing architecture if it's not useful for anything.
Wait, you actually use focus-follows-mouse? You're a better man than I.
I'd actually like to see a chart with these types of performances going back a number of years. It would be interesting to see the difference between RH10 and the Latest Fedora release (assuming you could even get RH 10 to run on modern hardware without backporting drivers). Same wit FreeBSD.
That's to be expected considering the defaults of ext4 vs ufs2. You can increase flush time on ufs2 and expect a similar increase. Revert to ext3 and it would be a completely different outcome. Interesting to see all the chest pounding on choice for default settings in a desktop enviro vs a traditionally server one. Would have been a been comparsion to use the upcoming PCBSD's release vs Ubuntu's, but we've seen the bias from Phoronix before.
brandelf -t FreeBSD
From the update notes in /usr/src/UPDATING:
Since the article didn't mention anything about disabling all the debugging options, I'll consider this an invalid benchmark until shown otherwise.
Dewey, what part of this looks like authorities should be involved?
You should try. It is great to be able to work at windows without raising them.
Rethinking email
I which I'd seen this before I posted my last comment:
How "awful" for FreeBSD and good for the OS that Mark wrote. My grammar and clarity aren't always perfect, but hey, I don't get paid to write this stuff. :-)
Dewey, what part of this looks like authorities should be involved?
"FreeBSD was also using the default UFS file-system while Ubuntu 9.10 is running with EXT4." TRY RUNNING THE SAME FILESYSTEM YOU FUCKING MORONS!!!!!!!!!!!!!!!!!!!!!! the only benchmarks freebsd lost in were O/I intensive tasks, so all this showed is ufs2 is slower then ext4 in some cases.
epic fail.
If you mod me down, I will become more powerful than you can imagine....
Yet again a benchmark against a pre-release version of FreeBSD where the testers didn't even bother reading the documentation. Anyone actually familiar with the FreeBSD development and release process would know that a release candidate has a considerable amount of debugging options turned on. This is to help diagnose any problems as the last issues are shaken out of a release, but has an adverse impact on performance.
I stopped reading when I realized they didn't even use the same version of GCC in their compilation comparison.
i find it ironic that the gp talks about no one making software for BSD but cites Mac OSX as being his prefered option. what a fucktard....
If you mod me down, I will become more powerful than you can imagine....
I second that.
Interesting comparison but the SQL test was a bit off testing a database installed on ext4, a journalling filesystem. Anyone wanting intensive database work would use ext3 for the DB partition.
Also, it would be interesting to see whether FreBSD still outperforms Linux in low-memory situations. This used to be an area where BSD had a clear advantage.
First off Free-BSD is a sourced based thanks to Ports so you have the option of adding in optimization and Ubuntu is nativity binary based, not to say you can't get source out of apt. How can you compare a binary and a source, that's like comparing Gentoo VS Ubuntu. Gentoo will win 100% of the time because we you make sure that only use the fastest of the CFLAGS where in Ubuntu you need to have everything built into the binary. I just don't see a fair link between these two operating systems.
Personal experience with BSD shows me just how messed up that system is. I'm surprised they could even install the thing to bench mark with it, and then waited 5 days for ports to grind away getting the packages set up.
The conclusion of the benchmark seem pretty unclear to me. comparing a development versin with debugging compiled with different compilers on different operating systems lead to different result.
I could have guessed that. I believe a benchmark is useless without a good insight of why the performance are different and how to correct the problem.
With Ubuntu 9.10 we were using the x86_64 server CD of the Alpha 6 build. With FreeBSD not shipping with a desktop environment by default, we used the Ubuntu server CD so that both could be tested just from the terminal in a similar environment.
So they are comparing FreeBSD to the Ubuntu server version, but not really for the right reasons.
the same thing happens later when Ubuntu is losing and BSD is winning. Perhaps it is the fact that most ppl associate LARGER boxes with doing better and there is no manipulation going on?
For such a foolish response, I have to ask, how did you get modded up in the first place?
I suppose that's a bit closer, but it still doesn't address the differences between fs defaults. ext4 is far more aggressive than ufs2 is by default. A closer comparison would have be to gjournal ufs and mount async which would have been a relatively close comparison to ext4, but that still would not be a fair io comparison as gjournal scales incredibly well but can double write time on single write. I am struggling to comprehend ext4 as a default filesystem in a server(or anywhere) however, considering it still has crash corruptions issues.
http://en.wikipedia.org/wiki/Ext4
http://onlamp.com/pub/a/bsd/2008/02/26/whats-new-in-freebsd-70.html?page=3
brandelf -t FreeBSD
How is this really comparing OSses? From the article, I gather that the first benchmark, Imagemagick compilation, compares two GCC versions plus the OS that performs the I/O on behalf of GCC:
"Starting off with the timed ImageMagick compilation process, FreeBSD 8.0 was able to build this open-source application noticeably faster than on FreeBSD 7.2 (even though both are using GCC 4.2.1), but Ubuntu 9.10 with GCC 4.4.1 took much less time to build ImageMagick."
Duh.
I am the Shield Anvil. And I am not yet done.
FreeBSD rather ends up taking a wallop to Ubuntu Linux, but there are a few areas where FreeBSD 8 ran well.
Apparently taking a wallop to != bringing the hurt.
Perhaps it would be clearer to say For the most part, Ubuntu beat FreeBSD, or perhaps FreeBSD got walloped by Ubuntu.
coding is life
No it isn't. I want to SEE what I'm working on, not just perform random blind (potentially destructive) operations on occluded windows. That isn't even mentioning all of the problems that can occur if the mouse accidentally gets bumped and causes a different window to gain focus.
Millions of dollars have been poured into useability research and that research has found that focus follows mouse is a stupid and dangerous UI behavior. It's why no major OS has it enabled by default.
Wait, you actually use focus-follows-mouse? You're a better man than I.
Heh. Focus-follows-mouse and virtual desktops are actually one of the main reasons I run Linux (Debian/XFCE) at home, followed somewhat closely by apt-get/aptitude and less closely by the great command-line support (which if I ran Windows I could always get with Cygwin/MinGW or these days maybe powershell).
You can only do an equally good job with MacOS.
For this grant priveledge you get a meagre selection of hardware that will
either gouge you or leave you wanting. You also get an alien environment
with a number of annoying quirks and inferior package management to any
Unix. Package managment is a "Unix thing" and not just a Linux thing. This
is one area where MacOS demonstrates it's not really Unix.
Some of the proprietary tools you get with MacOS might be moderately more
useful but they will have quirks of their own, suffer from NIH syndrome
and may also suffer from addressing problems in a superficial manner.
BSD is at least a proper Unix.
A Pirate and a Puritan look the same on a balance sheet.
Some of the code in BSD family of code streams is so old its growing fungus. Still, when I set up a server I usually reach for OpenBSD, its proven rock-stable to me after years of trouble-free mail, firewall/NAT, and web server service. But Ubuntu's my desktop.
Python: 'And then suddenly you have a language which says "we're all stuck with whatever the whiniest coder wants".'
Actually, you'll probably do quite a bit of compiling in FreeBSD too. While you can pull binary packages, most people I know prefer to use a package manager like portsnap and compile source packages.
If you have a script to take care of compiling the common stuff, then just "make config" everything that need user input and let it fly. Granted, most servers I've used BSD on have been dual or quad core Xeon/AMD PC's with a fair bit of RAM, so it is overall a fairly quick process, though it was still not too bad on a few P4-era celerons.
The nice thing about FreeBSD source-compiled apps that I truly did love compared to BSD is the little tweaks you could do to avoid tons of crap dependencies. Debian used to be fairly "clean" as far as deps, but both Ubuntu and Deb are now getting quite ugly in that you get rather unwanted stuff in order to get the package you want. In most FreeBSD stuff, for example, I can check the "No X Server" box and happily compile my apps without any X support whatsoever. On Debian/Ubuntu I end up trying to install some CLI system monitoring tool or CUPS, whatever, and end up with a whackload of x.org stuff because it's tied to some font which is loosely tied to the actual package I'm trying to install. On Ubuntu desktops, trying to exorcize the demons of "Evolution" without having it remove other important stuff due to deps is near impossible. Sometimes there's a separate branch for a "cleaner" install, but often enough not.
Of course, BSD ain't perfect. Linux tends to have a lot of "new" stuff that BSD is a little more "conservative" in bringing into the mainline (iSCSI support for example was a fairly recent addition compared to 'nix), but overall the package system is powerful indeed.
Having not used Gentoo (yet) but knowing others who have, it seems like it might be somewhat similar in concept. The issues I've heard with are mostly in people getting to the up-and-running stage, but - similar to BSD - avoid annoying little conflicts or unwanted cruft is a lot easier than Debian/Ubuntu's precompiled binaries. Of course, I've also heard of much frustration in both if you have find halfway through a *long* compile that you missed something you should have flagged/included.
and perhaps disable WITNESS and a few other things.
Other than the binary-vs-compiled issues, part of my personal love/hate relationship with BSD has been related to IO tools and issues.
I find that FreeBSD's resource-usage monitoring to be quite a bit nicer than 'nix. One example is just pressing "m" in "top" to get a per-CPU list of usage rather than the 300% = roughly 3-of-4 CPU's in heavy use.
Stats on disk IO have always seemed to work for me, whereas in 'nix I've tended to need more specialized drivers compiled in the kernel. It could be that I just got lucky and always had supported hardware, but it has been much less of a trial.
Managing IO on certain devices in BSD has been much more of a pain though at times. The drivers of certain less-expensive RAID cards (often used in Dell servers) have been a true pain to optimize. They don't actually break, but all seem to have different buffer-depths requiring special config to prevent overruns which lead to poor performance.
It's worth noting that one of the things in RC1 is that ZFS is now considered 'production ready' by the FreeBSD ZFS team. Maybe they should enable it for FreeBSD and then add a benchmark of shapshot and transactional I/O performance...
I am TheRaven on Soylent News
ext3 is also a journaling file system. Perhaps you meant ext2?
I'm not sure you want to run fsck on an unclean shutdown on your nice big database partition either. Maybe using a journaled file system isn't such a bad idea. Also, it can be much faster for certain workloads:
http://en.oreilly.com/oscon2009/public/schedule/detail/8432
http://wiki.postgresql.org/wiki/HP_ProLiant_DL380_G5_Tuning_Guide
Note that while sequential writes could be much slower with journaled file systems, random writes were typically much faster. This is what one would expect, given how journaled file systems work.
Yeah there are loads of configuration options that are relevant on servers. Going with the defaults might be sensible when comparing desktop OSs (since Mr Noobey doesn't know how to select a more suitable IO scheduler) but we've already established that they're looking at server OSs here. I think Phoronix show here that they really haven't thought this comparison through. Once the competence of a benchmarker is called into question all of a sudden I feel a massive urge to completely ignore everything they say.
:)
It's good though that Phoronix have found a way to unite us Linux and BSD users in a joint criticism of their crappy benchmarks
While, interesting the test wasn't really comparing apples to apples. For example, FreeBSD RC 8 is using a slightly older version of GCC so the first test is somehwat invalidated. It is also notwworthy that several of the tests are canted towards desktop use. FreeBSD, you could argue, is not as optimized towards desktop use as Ubuntu. A better test would be to compare the Ubuntu Server edition with FreeBSD. I would like to see a test designed around the number of simultaneous website hits either OS can take or a test to see the number of concurrent ftp connections. I believe if the comparison were closer to apples and apples, we might see a more objective test.
Once the competence of a benchmarker is called into question all of a sudden I feel a massive urge to completely ignore everything they say.
You mean like pretty much every benchmark where there's a sore loser? Well, I'm sure they'll be glad to hearing spreading FUD is such an effective strategy. I'm not talking about this specific case, but for benchmarking in general your position is rather sad.
Live today, because you never know what tomorrow brings
Why that?
All one (1) of them.
How about we see this against a version of FreeBSD that doesn't have debug on according to /usr/src/UPDATING?
Perhaps "called into question" wasn't the best choice of phrase. I certainly don't mean that if absolutely anyone, anywhere cries BS about a benchmark then the benchmark is instantly void, rather I mean that once a benchmarker starts to look like they don't know what they're doing then since I don't have enough time to pick through every inch of their technique and raw data, it's easier just to file the whole thing under "useless" in my brain and move on with my life.
The problem is that there are so many poorly-conducted benchmarks around that really end up saying nothing that it can make one jaded and perhaps quicker to reject a benchmark than would be proper. Good benchmarks are certainly worth their weight in gold (erm, or maybe more. I don't know how much a benchmark weighs!).
NEVER solely use colours to describe things.
freebsd is 100% binary compatible with linux.
Snicker. I love FreeBSD and run it on all the servers I administer, but the Linux compatibility stuff pretty much ends at usermode. Good luck firing up VMWare or anything else that requires an un-ported kernel module! In practice, every program I personally want to run on FreeBSD is available as a native binary or in ports, with the exception of programs that require kernel mods, in which case they won't work at all anyway.
Dewey, what part of this looks like authorities should be involved?
People mentioned the self-checks and debugging features that used to be turned on in FreeBSD development branches and beta releases.
Self-checks, which are the major source of kernel slowdowns in those kernel options, are not turned on in the 8.0 release candidates.
Debugging is on, but unless you are very short of memory it should not cause a noticeable slowdown.
FreeBSD's slowness in these benchmarks can be attributed to two factors:
1) the compiler. The GPL v3 is unacceptable for FreeBSD, so newest GCCs cannot be used as the base compiler. Users can choose to install a new gcc on their own (as a port) and then even go and compile all ports and even the base system with that new compiler (some parts might not have been cleaned up to comply with new language strictness that might have come with new gccs).
2) threading, as in the userland threading library support. It is very hard to tell whether there is some performance problem in FreeBSD's thread libraries or whether applications just happen to have been optimized and tested only with Linux.
That happens a lot and you can also see Solaris with it's M:N threading fail miserably for some threading benchmarks that do dump things, such as just creating and destroying threads at a high rate.
%%
The problem of "thread benchmarks" benchmarking bogus things and/or just having been written with Linux' thread model in mind has been going on for 12 something years now. Benchmarking thread systems in a realistic manner is very difficult. In real-world applications you don't create and destroy threads at a high rate and you minimize locking. Benchmarking this is almost as hard as benchmarking programming languages.
I haven't benchmarked threading libraries, knowing that it will take time that I don't have right now. I can tell you, however, that just the I/O subsystem in FreeBSD, as in filesystems and networking, isn't any slower than Linux. Not to mention GbE and today's disks are too slow to really show an OS difference for most tests anyway.
%%
The real question of I/O subsystems will come in when ZFS+Zraid is standard in FreeBSD and BTRFS is standard in Linux. In a couple of years from now nobody will understand why we ran today with no snapshots, with the raid hole (from block layer raid systems) and without transparent compression in the subtrees where we want it.
But these filesystems are complicated and there's some real performance difference visible.
%%
An area completely overlooked in the benchmark is the VM subsystem. Namely - what happens when you overload your RAM and paging commences? Linux used to make very bad choices here (dropping readonly pages, which is a wise thing as such, at rates about 10 times higher than wise).
FreeBSD used to be the go-to OS on memory shortage thanks to John Dyson's VM work (backed by a large database company that provided support and a realistic benchmarking environment during that development).
But today? Nobody knows. I'm not aware of any benchmarks that you can download that simulate memory stress and map the tradeoffs that the OS makes.
In general, the biggest obstacle to improve Linux, FreeBSD and everybody's else's OS performance is a lack of high-quality benchmarks.
Why don't people develop more benchmarks? Because they get annoyed that today, in 2009, no realistic OS benchmark will show a single number as a result. All OS benchmarks today can only make a map of what tradeoffs the OS chose, what part of the running application suite got the short end in favor of what other part. This isn't sexy and publishers don't like it.
People like reality reduced to single numbers, but in the area os OS benchmarks (and language benchmarks) that party is over.
Myself, I found myself gasping many years ago when I benchmarked network I/O versus userland CPU load. I hammered a couple of GbE interfaces while at the same time running moderate memory-intensive CPU benchmarks (with no network access from those CPU lo
This test is invalid, because it allowed a major difference between GCC versions (4.2.1 in FreeBSD and 4.4.1 in Ubuntu)
According to GCC tests, 4.4 is as much as 20% faster than 4.2:
http://vmakarov.fedorapeople.org/spec/comparison32.html
You can only do an equally good job with MacOS.
For this grant priveledge you get a meagre selection of hardware that will
either gouge you or leave you wanting.
Feeding the trolls with more trolling? My 2009 Macbook "white" is no more expensive than PC laptops in the same form factor. Actually it's a bit cheaper than most comparable 13" laptops w/ a faster FSB than most.
I have no performance complaints and for an IGP the GeForce 9400M certainly doesn't suck.
And, I don't have to deal with the crappy PC BIOS anymore.
What are you doing that a 2.0GHz Core 2 Duo "penryn" on a 1066Mhz FSB w/ 4GB DDR2-800 RAM would "leave you wanting"? Playing games? Grow up and go buy a PS3.
You also get an alien environment
Gee, most Windows users say the same thing about anything that isn't Windows.
with a number of annoying quirks and inferior package management to any
Unix. Package managment is a "Unix thing" and not just a Linux thing.
There is nothing in the UNIX standards about package management. In fact, I prefer app bundles to UNIX-style package management. I've had Linux package management systems screw me more than once to the point where a lesser SysAdmin or end user would simply have to reload.
App Bundles are great, the app can easily be bundled with all dependencies in one spot instead of littering your entire filesystem. If your package database becomes corrupted with most Linux package managers, there is no way to COMPLETELY uninstall an app and any libraries that got installed with it.
App Bundles make a lot of sense. I kind of like the PBI installers with PC-BSD but their dependence on QT is a showstopper for me.
This is one area where MacOS demonstrates it's not really Unix.
Again, there's nothing in the UNIX standards about package management. MacOS X is AT LEAST as much UNIX as Tru64 (DEC UNIX, OSF/1, whatever) is. Both are based on a bastardized Mach implementation.
It's certainly no more non-standard than IRIX or NeXTstep were.
Some of the proprietary tools you get with MacOS might be moderately more
useful but they will have quirks of their own, suffer from NIH syndrome
and may also suffer from addressing problems in a superficial manner.
That same statement could apply to Linux or Windows.
BSD is at least a proper Unix.
That statement is true but apparently in your eyes, it's not a proper UNIX unless Freetards endorse it and make it "easy".
By your definition, AT&T 7th Edition wasn't a proper UNIX.
I love my new girlfriend at about 87% under load and 93% under blue skies while my last gf was a mere 89% under load but a stunning 97% under blue skies... Add some beer to the equation and it was a full 100%! (with 23% impared judgement to take into account, of course). Tests were run on the exact same heartware as usual. Whether "fewer seconds are better" is a question of perspective, though.
Performance? Out of the box windows ME was pretty damn fast.
Let's try uptime? BSD vs Debian. No contest. When you can measure a debian servers uptime in years, not weeks, let me know.
Which is why one has to wonder why they used bleeding edge ext4 on Linux, and didn't use ZFS on FreeBSD. It couldn't be because they were trying to intentionally skew the numbers! And yes, ZFS is fully baked on FreeBSD.
>> You can only do an equally good job with MacOS.
>>
>> For this grant priveledge you get a meagre selection of hardware that will
>> either gouge you or leave you wanting.
>>
> Feeding the trolls with more trolling? My 2009 Macbook "white" is no more expensive than PC
> laptops in the same form factor. Actually it's a bit cheaper than most comparable 13" laptops
> w/ a faster FSB than most.
In the same form factor? If you are going to argue this stuff at least make a little
sense when you do it. Mac laptops compete favorably with PC laptops when you include
"similar components".
Although even that proves my point: "Purevideo or nothing" is the Mac option.
> ...and it's your ONLY OPTION
> I have no performance complaints and for an IGP the GeForce 9400M certainly doesn't suck.
>
Widen the field to laptops with anything else and the Mac gets creamed.
>
> And, I don't have to deal with the crappy PC BIOS anymore.
>
Like that is a real problem for a user like you...
OTOH, my ION nettop with a "normal BIOS" is booted up before a mini gets to it's white screen.
If Macs represent the state of EFI, then give me a small boot disk so I can avoid it.
A Pirate and a Puritan look the same on a balance sheet.
Doesn't the kernel code in 8RC1 still have debugging stuff enabled? I know that is a speed killer and would at the least skew the numbers.
---- Booth was a patriot ----
Learning to use focus-follows-mouse isn't hard, though I admit it can be a little confusing at first; going back to crappy systems that don't offer it after you've learned its benefits is what's hard!
--Nice try, but IMHO it's not " 100% " until you can run Vmware Workstation on FreeBSD.
.
== WolfriderV6 == I'm willing to admit that *I just might* be wrong... Are you??
But I think we already knew that.
The Linux scheduler historically isn't thread-fair
Specifically, as long as there is work to do in the thread, it doesn't force a context switch; this attribute is why the GIF renderer on Netscape would crash on FreeBSD but not on Linux, because after an involuntary preemption, FreeBSD did not guarantee that the preempted thread would be the one reselected to run; Linux did, but in the process eliminated scheduling fairness for the other threads. So FreeBSD defaults to better thread fairness. This is also why the SQL benchmarks from last year were better on Mac OS X 10.5.5 (Leopard) than on Ubuntu.
If Linux actually honors the SCHED_RR policy, and were to explicitly set it, it would probably do better on the SQL benchmarks; however, it would likely do worse than with SCHED_OTHER or SCHED_FIFO (not sure which is the implementation default in the current Linux scheduler), but certain workloads like to serialize their operations and get better cache line efficiencies from doing so. Oh, and if the default scoping is PTHREAD_SCOPE_SYSTEM vs. PTHREAD_SCOPE_PROCESS will also matter here (again, assuming it's supported).
A decent benchmark would explicitly set the policy and scope to the best value for the system it was running on. The FreeBSD numbers could have easily been better as well, by adjusting these values to explicit values, rather than taking the system defaults.
-- Terry
Ubuntu is better than the BSD's in a majority of the tests, but its not a slam dunk. There are places where the BSD's shine (and shine bright). I don't take this as a bragging rights thing (you can I guess), instead, because the code is open, you can take the software design and warts of your system and examine it and compare it to the other guys and change yours to get more speed. For those who have no idea how these systems work, benchmarks are all they have. For those studying these systems, side-by-side comparisons are extremely useful for making improvements. You can literally take your code, benchmark it on a step-by-step basis, take the other guys code, do the same thing, and see exactly where things can be improved. This can actually be useful.
The triangle in the upper left corner points up when up is good (operations per second). It points down when down is good ( seconds to complete test suite). Seems pretty clear to me.
Think global, act loco
Focus follows mouse is available as an option in Windows. It has been since the first release of PowerToys for Win2k. The XP I am using now and my Vista box at home all have it turned on because that is how I work seamlessly with my terminal windows.
You have the option of just following the mouse, auto-raise, and auto-raise after configurable delay.
I just stick with follow the mouse.
Powertoys. It's free from Microsoft. It's just a download away.
Focus follows mouse is available as an option in Windows. It has been since the first release of PowerToys for Win2k.
I've tried that (well, the XP version), and last I checked there was no way to turn off raise-on-click. Which makes it mostly useless.
Unless the kernel does some batshit insane OTF code generation optimizations.
I know tobacco is bad for you, so I smoke weed with crack.
You can't really compare the two. Yes they have similiarities because they are *nix's. Its like comparing a apple to an orange. I love both but I use them for two different things. FreeBSD for me runs on my network as emails, web, ftp, openvpn, etc servers and Ubuntu is on the desktop/laptop.