If I had to actually drive to the library, I wouldn't actually DRIVE each time I was wondering about some trivial answer to a meaningless question.
Okay, now what about that major report due for school. Or any other non-trivial meaningless question that you would have went to the library for and now don't have to.
They aren't implying they are great because of the energy you saved not doing something you wouldn't have done before, even if your habits didn't change, and you searched once or twice a month, Google would STILL be saving massive amounts of energy, and on top of it, they're answering millions of extra meaningless trivial questions.
All you've done is shown me that a ton of CO2 isn't a lot. You're trying to use 60 tons in an OMFG THOSE BASTARDS sort of way, but when you look at it as a single private airplane flight, which really doesn't produce THAT much CO2. So you're probably making your point less relevant to most normal people. You're also ignoring that any other method of getting there would have produced more. So you're either blowing things out of proportion on purpose, or just raging against the fact that Googles founders have a lot of money and enjoy themselves.
They may be hypocrites, I'm not arguing that. I will say that if you get all bent out of shape over their single private flight, you just make yourself look irrational and overreacting. They've saved hundreds of times that in the last years modifications to their data centers efficiency, so acting like they are evil bastards for using a little bit of what their organization saved just makes you seem like nothing will ever be enough.
So they took a plane flight, its not that big of a deal, certainly not outweighted by the good they've done in that same area. Go have a beer and chill out, otherwise you're going to stress yourself to an early death, long before global warming gets you.
The company I work for does marketing of sorts. We try to pretend we don't, but thats really what it is.
We do track users, but not in any way that is passed along to our customers as personally identifiable. We track aggregates like 'X number of people say it, Y number of people clicked on it, Z number of people bought it'. I'm probably the only person currently that could even type sale Z to event X within our system, their is no internal code to do so. Even then, the only way I could tie it back to an individual (rather than an IP address) is if they ALSO happened to be one of our customers. This is intentional. If I don't write it or log it, it can't be abused until someone does.
My first thought to this however is...
Hahahaha go fuck yourself, no way I'm implementing that. None of my competition will, why the fuck would I? If they don't want me to track them, dont' randomly load shit from my website, and accept/send me cookies and other personally identifiable information. We've already cut ourselves off from tracking information because, well its just wrong. I'm not writing more code... to deal with a flag that says 'ignore this information I'm sending you!'... rather than just NOT FUCKING SENDING ME THE INFORMATION IN THE FIRST GOD DAMN PLACE.
Sorry Mozilla, you can kindly go fuck yourselves, this is yet another example of how completely disconnected from reality you are. You want me to not track you? Fix your fucking browser so it doesn't default to making itself trackable as all hell. Your browser is leaking information, not my problem. (Its common to all browsers mind you, but still not my problem)
Information IS money, always has been, the web didn't create this situation, and never has someone saying 'hey, don't track me!' stopped anyone from remembering such information. Computers have just made it far easier to correlate.
So that would be Mozilla, and other browser makers who allow this to happen by making the browsers so easily provide personal information.
Every bit of information users can use to track you with the exception of your IP address is controlled by the browser.
Cookies Cache User Agent Plugins HTTP-Accepts
All of these methods and the others used to track people are a direct result of browser functionality. Of course, it won't be anywhere nearly as functional without these things, but thats another story. Mozilla doesn't want to fix the problem. 'The Problem' is the reason they exist. Without tracking, Google would be far less profitable and would have far less incentive to pay Mozilla anything. If Mozilla actually fixed the problem, they'd cut off their food supply.
Right up until some disk IO causes your last frame to be 2 seconds long, now every frame in the future is forced to 2 seconds between updates! Awesome for the win.
Its only slightly (and by slightly, I mean a lot) more complicated than you think it is.
No, OSX doesnt' do anything like this. It just boots fast. No need to save the last boot and resume like this.
And for reference, a full resume from hibernate on my Mac takes about 8 seconds, faster than a windows quick boot.
Another feature looking a lot like the boost feature on old 486 tower when it had the boost option, who was stupid enough to leave it at slow?
Anyone who had a reason to? So basically anyone who used an app that expected a specific CPU speed rather than looking at a real time clock or something like that to figure out how to do things at the proper speed. During that time, most things ran on bear hardware and assumed they had full CPU, so they could do things based on CPU timing. When the CPU timing suddenly changed, everything that had any sort of video or audio was horribly broken.
The turbo button turned that off so things would run slower, more like the program was expecting. LOTS of people used it, you were just too busy putting your hands down your diapers to notice or remember.
Way to totally not have any clue what you're talking about, go back to middle school and shut your pie hole.
I see two problems with that, both at the core of Linux. - Closed source driver support. - The Unix/X11 (and thus Linux) kernel model doesn't allow for a high enough level hardware abstraction. So the desktop environments and applications have to do a lot that should be in the core OS.
Than how does OSX do it? And Solaris? And HP-UX, AIX, and the others I'm too lazy to mention?
This is an open source problem, not a unix problem. Commercial UNIXes which also use X.org seem to have no problem what so ever.
It all comes down to who WANTS to do it. OSS will remain second class because no one wants to do the hard work, like testing and making things stable. Everyone wants to just do the new shiney feature.
What people fail to realise is that having users on versioned distros (as opposed to rolling release) is bad for devs. It means that when you release software you need to make sure that it's compatible with all the versions of all the libraries all the distros are currently on.
Yes, it means that the devs have to do their fucking job.
I myself, am a developer, I know how much work it takes, that doesn't excuse NOT DOING it.
The problems you're refering to with QT stem from the 'JUST FORK IT!' mentality of Linux in general. Everyone works off on their own with little concern for others. If you guys would learn how to actually write stable software with a stable (and expandable in the future) API, you'd have far less issues integrating things.
The way it is now, you're just continually dealing with software that never really has ever worked like it was supposed to. Its so broken and been that way so long, you don't even realize its broken.
Why don't you have a local mirror of the repository? Several advantages I can think of off the bat:
Because its easier and cheaper to just go with someone else without such a retarded release program?
You're also ignoring the fact that it indicates they do not actually care about their users wishes and are in fact following the exact same track as the previous netscape administration.
It shows they don't want to put actual effort into testing and release management, they just want to play with shiney new code.
Basically, it paints them as idiots who are throwing out literally hundreds (if not thousands) of years of basic engineering principle because they simply don't want to do it and it takes work.
It shows they want YOU to do THEIR WORK for THEM, and thats where I get off to bus.
FreeBSDs syscall emulation layer for running Linux binaries performs at between 98% and 102% of that on Linux. Its been that way since I switched to FreeBSD from Linux (1996? 7? 2.2, whenever that was). Some apps will run faster, some will run slower. In reality, they'll run in a way that you're just not likely to notice the difference at all.
I've also seen reports of people running full disk encryption showing higher read/write speeds in certain cases.
Just for reference, this is almost always related to compression being used.
Now days, there is enough spare CPU most of the time to do compression on the data on the fly while waiting for the disk to read/write some block.
In a 32 bit Windows, with Battlefield 2, you would get FAR faster load times by compressing the BF2 installation directory using NTFS compression because the only thing the CPU is doing during that time is frontending for DMA transfers to/from disk, of massive amounts of data. By compressing them, you move some of the load to the CPU (which is basically idled at this point, so we're not slowing anything else down by using it) and cut down on the physical disk IO that is required.
I say 32 bit windows as I haven't tried it with more than 4 gigs of RAM. More may change it due to better disk caching, less swaping and all that.
Hahahah, you have no clue what you're doing, and you think you're making it faster...
Thats priceless, theres a meme in there somewhere I'm missing.
Don't ask what os_raise_smp_barrier
My guess would be that its an op designed to ensure the CPU cache is flushed to RAM and that all out of order instructions are completed and flushed before continuing so that the contents of RAM actually match up with what they are supposed to be rather than being slightly off due to the processor making on the fly optimizations and reordering memory writes.
And this is why you don't listen to same random fuck on slashdot telling you why nVidia's drivers suck. He's clearly never worked in kernel code, yet is telling us how to get massive speedups!
I presume you have a bunch of nuts and bolts left over after you work on your car too.
FreeBSD is an entire system, as is PC-BSD. It is not JUST a kernel.
When you use Debian's kFreeBSD, you are not using FreeBSD, you are using Debian, with a FreeBSD kernel. You can't call it FreeBSD any more than you can call it Ubuntu.
Keep in mind, Linux is the only 'OS' on the planet, where people like to pretend that the kernel is the OS and the OS is the kernel. No one else says 'we run the Solaris kernel', or 'We run ntkern.dll'. Its only Linux where you seem to think the kernel is the OS and that the userland isn't part of theOS.
Kernel tests are pointless, as the kernel is worthless on its own. You test the SYSTEM since thats what you'll actually have to use. No one uses the kernel in a void, which means benchmarking just the kernel is useful to no one.
You don't get to optionally pretend such flaws don't exist in order to not be the loser.
For instance:
If FreeBSD didn't have to deal with managing the VM, swap, disk IO can memory bandwidth, it would outperform every other OS on the planet!$!@.
Which is true... except it wouldn't be very useful, and so probably not actually true in any meaningful way.
Of course, my other response is... WTF is wrong with your system if applications which aren't being displayed and are running in the background are consuming 3d hardware rather than being idled? The proper thing to happen would be that the background 3d application gets little to no resources and doesn't cause a problem, does the Linux scheduler not deal with this problem or are you guys still running around arguing over which one of the 3 that perform almost identically should be the default.
Even Windows deals with the situation gracefully for fucks sake.
So you're arguing over which part of Linux is the problem and saying that its not a Linux problem because its not one particular bit of the system?
Heres a hint, the Linux kernel, alone, is worthless. It requires a system to go alone with it to be useful, so stop trying to pretend that Linux can be narrowed down to JUST THE KERNEL. If you want to go that route then you have to stop claiming Linux capable of doing anything, as I said, on its own, its worthless. Can't even boot without help on a PC.
But you don't want to look at the Linux kernel that way, you want to say its awesome when it is winning BECAUSE ITS THE KERNEL!!!! but its not bad when its losing because... its something OTHER THAN THE KERNEL!!!!
It was once lean and fast but now is an industrialized bloated mess. It will take a lot more to get me to stop using Linux but that doesn't mean I can't see when something is wrong.
FreeBSD's emulation layer has ALWAYS been performing Linux emulation at between 98 and 102% of that on Linux.
Its not that Linux is slower, its that its different. The tests run here take advantage of things FreeBSD does faster, but there are things that Linux runs faster, which is why sometimes its a tad slower, and othertimes its a tad faster
The emulation layer is more or less a syscall mutator and some patched up libraries, its not really DOING anything that would cause it to be slower, its just a small shim that basically reorders some syscall arguments and reorders them to match up with how FBSD does it. We're talking about very very tiny wrappers making this all work.
I'm a huge FreeBSD fan, and particularly hate Linux fanboys/zealots, but this is one area where there is only room for debate if you're too ignorant to realize the way the FreeBSD emulation layer performs is right on target for good solid code. Both being open source, Linux and FBSD SHOULDN'T PERFORM THAT MUCH DIFFERENTLY as they are both general purpose OSes.
Want fast networking, you use FreeBSD, you want wider support for fringe hardware, use Linux. Last I looked, Linux had the SMP side pretty much locked down away as the winner too.
There is nothing wrong with Linux based on this study that wasn't wrong in 1996, because the emulation layer performance hasn't really changed overall since then (which is when I had my first experience with it). Considering how long the performance has been more or less the same, and I know FreeBSD isn't 'bloated' considering it powers some of the fastest packet analazysis machines on the planet, I'd say that its unlikely Linux could be called bloated.
I could easily change this benchmark in a few subtle ways and throw it the complete other direction. I don't know exactly what they did (they didn't say) but my experience tells me that they just happen to hit the upper side of the emulation layer and not the bottom side.
What you should take away from this however is that you can emulate most things in FreeBSD that will run in Linux and you won't notice a speed difference, should you need to migrate away from Linux for some reason, like faster packet switching or something along those lines.
Slashdot Mirror
the entire website into one txt message.
I can't imagine the website will be of much use after its been encoded into a single 160 character text message packet.
And text messages ARE actually slow to send over the air, you just don't notice it when typing on a keyboard that you can't do more than 10 bps on.
Until Smozzy starts getting a bill from T-Mobile for all the SMS communications. Do you REALLY think they'll let this go?
If I had to actually drive to the library, I wouldn't actually DRIVE each time I was wondering about some trivial answer to a meaningless question.
Okay, now what about that major report due for school. Or any other non-trivial meaningless question that you would have went to the library for and now don't have to.
They aren't implying they are great because of the energy you saved not doing something you wouldn't have done before, even if your habits didn't change, and you searched once or twice a month, Google would STILL be saving massive amounts of energy, and on top of it, they're answering millions of extra meaningless trivial questions.
With that in mind, the question becomes: which company offers these services in the greenest way ?
All of them. Lower power costs mean more profit. Google is behaving like a business, nothing more. (Not that I'm bitching about it, just stating it)
You need to experience a Mormon girl gone wild, you'll change your opinion.
All you've done is shown me that a ton of CO2 isn't a lot. You're trying to use 60 tons in an OMFG THOSE BASTARDS sort of way, but when you look at it as a single private airplane flight, which really doesn't produce THAT much CO2. So you're probably making your point less relevant to most normal people. You're also ignoring that any other method of getting there would have produced more. So you're either blowing things out of proportion on purpose, or just raging against the fact that Googles founders have a lot of money and enjoy themselves.
They may be hypocrites, I'm not arguing that. I will say that if you get all bent out of shape over their single private flight, you just make yourself look irrational and overreacting. They've saved hundreds of times that in the last years modifications to their data centers efficiency, so acting like they are evil bastards for using a little bit of what their organization saved just makes you seem like nothing will ever be enough.
So they took a plane flight, its not that big of a deal, certainly not outweighted by the good they've done in that same area. Go have a beer and chill out, otherwise you're going to stress yourself to an early death, long before global warming gets you.
The company I work for does marketing of sorts. We try to pretend we don't, but thats really what it is.
We do track users, but not in any way that is passed along to our customers as personally identifiable. We track aggregates like 'X number of people say it, Y number of people clicked on it, Z number of people bought it'. I'm probably the only person currently that could even type sale Z to event X within our system, their is no internal code to do so. Even then, the only way I could tie it back to an individual (rather than an IP address) is if they ALSO happened to be one of our customers. This is intentional. If I don't write it or log it, it can't be abused until someone does.
My first thought to this however is ...
Hahahaha go fuck yourself, no way I'm implementing that. None of my competition will, why the fuck would I? If they don't want me to track them, dont' randomly load shit from my website, and accept/send me cookies and other personally identifiable information. We've already cut ourselves off from tracking information because, well its just wrong. I'm not writing more code ... to deal with a flag that says 'ignore this information I'm sending you!' ... rather than just NOT FUCKING SENDING ME THE INFORMATION IN THE FIRST GOD DAMN PLACE.
Sorry Mozilla, you can kindly go fuck yourselves, this is yet another example of how completely disconnected from reality you are. You want me to not track you? Fix your fucking browser so it doesn't default to making itself trackable as all hell. Your browser is leaking information, not my problem. (Its common to all browsers mind you, but still not my problem)
Information IS money, always has been, the web didn't create this situation, and never has someone saying 'hey, don't track me!' stopped anyone from remembering such information. Computers have just made it far easier to correlate.
Find companies that violate these rules.
So that would be Mozilla, and other browser makers who allow this to happen by making the browsers so easily provide personal information.
Every bit of information users can use to track you with the exception of your IP address is controlled by the browser.
Cookies
Cache
User Agent
Plugins
HTTP-Accepts
All of these methods and the others used to track people are a direct result of browser functionality. Of course, it won't be anywhere nearly as functional without these things, but thats another story. Mozilla doesn't want to fix the problem. 'The Problem' is the reason they exist. Without tracking, Google would be far less profitable and would have far less incentive to pay Mozilla anything. If Mozilla actually fixed the problem, they'd cut off their food supply.
Right up until some disk IO causes your last frame to be 2 seconds long, now every frame in the future is forced to 2 seconds between updates! Awesome for the win.
Its only slightly (and by slightly, I mean a lot) more complicated than you think it is.
So,, they are actually thinking of imitating MAC
No, OSX doesnt' do anything like this. It just boots fast. No need to save the last boot and resume like this.
And for reference, a full resume from hibernate on my Mac takes about 8 seconds, faster than a windows quick boot.
Another feature looking a lot like the boost feature on old 486 tower when it had the boost option, who was stupid enough to leave it at slow?
Anyone who had a reason to? So basically anyone who used an app that expected a specific CPU speed rather than looking at a real time clock or something like that to figure out how to do things at the proper speed. During that time, most things ran on bear hardware and assumed they had full CPU, so they could do things based on CPU timing. When the CPU timing suddenly changed, everything that had any sort of video or audio was horribly broken.
The turbo button turned that off so things would run slower, more like the program was expecting. LOTS of people used it, you were just too busy putting your hands down your diapers to notice or remember.
Way to totally not have any clue what you're talking about, go back to middle school and shut your pie hole.
Wait till everything you want to put into a release is stable and tested and you will be obsolete
You and I have very different definitions of obsolete. A few months old is not obsolete in my world, hell even a year isn't obsolete.
I see two problems with that, both at the core of Linux.
- Closed source driver support.
- The Unix/X11 (and thus Linux) kernel model doesn't allow for a high enough level hardware abstraction. So the desktop environments and applications have to do a lot that should be in the core OS.
Than how does OSX do it? And Solaris? And HP-UX, AIX, and the others I'm too lazy to mention?
This is an open source problem, not a unix problem. Commercial UNIXes which also use X.org seem to have no problem what so ever.
It all comes down to who WANTS to do it. OSS will remain second class because no one wants to do the hard work, like testing and making things stable. Everyone wants to just do the new shiney feature.
What people fail to realise is that having users on versioned distros (as opposed to rolling release) is bad for devs. It means that when you release software you need to make sure that it's compatible with all the versions of all the libraries all the distros are currently on.
Yes, it means that the devs have to do their fucking job.
I myself, am a developer, I know how much work it takes, that doesn't excuse NOT DOING it.
The problems you're refering to with QT stem from the 'JUST FORK IT!' mentality of Linux in general. Everyone works off on their own with little concern for others. If you guys would learn how to actually write stable software with a stable (and expandable in the future) API, you'd have far less issues integrating things.
The way it is now, you're just continually dealing with software that never really has ever worked like it was supposed to. Its so broken and been that way so long, you don't even realize its broken.
If you like using open source software or development tools, it's a lot easier to install and maintain everything under Linux than OSX.
I'm sorry, what exactly are you doing differently under Linux for OSS tools than you were in OSX? apt-get isn't exactly different under OSX.
Why don't you have a local mirror of the repository? Several advantages I can think of off the bat:
Because its easier and cheaper to just go with someone else without such a retarded release program?
You're also ignoring the fact that it indicates they do not actually care about their users wishes and are in fact following the exact same track as the previous netscape administration.
It shows they don't want to put actual effort into testing and release management, they just want to play with shiney new code.
Basically, it paints them as idiots who are throwing out literally hundreds (if not thousands) of years of basic engineering principle because they simply don't want to do it and it takes work.
It shows they want YOU to do THEIR WORK for THEM, and thats where I get off to bus.
And if you have a clue, that makes sense and is why you don't want 'rolling releases' in general.
Google it.
But ... by Always, he means sometimes.
FreeBSDs syscall emulation layer for running Linux binaries performs at between 98% and 102% of that on Linux. Its been that way since I switched to FreeBSD from Linux (1996? 7? 2.2, whenever that was). Some apps will run faster, some will run slower. In reality, they'll run in a way that you're just not likely to notice the difference at all.
I've also seen reports of people running full disk encryption showing higher read/write speeds in certain cases.
Just for reference, this is almost always related to compression being used.
Now days, there is enough spare CPU most of the time to do compression on the data on the fly while waiting for the disk to read/write some block.
In a 32 bit Windows, with Battlefield 2, you would get FAR faster load times by compressing the BF2 installation directory using NTFS compression because the only thing the CPU is doing during that time is frontending for DMA transfers to/from disk, of massive amounts of data. By compressing them, you move some of the load to the CPU (which is basically idled at this point, so we're not slowing anything else down by using it) and cut down on the physical disk IO that is required.
I say 32 bit windows as I haven't tried it with more than 4 gigs of RAM. More may change it due to better disk caching, less swaping and all that.
You could have just looked it up on dictionary.com rather than taking an arbitrary meaning from some random person on slashdot, whom is wrong, btw.
You need to look up the definition of emulation.
And heres a hint, the WINE guys don't actually get to define emulator, as much as they'd like to.
Its a fucking emulator, get over yourselves and your retarded naming schemes.
Hahahah, you have no clue what you're doing, and you think you're making it faster ...
Thats priceless, theres a meme in there somewhere I'm missing.
Don't ask what os_raise_smp_barrier
My guess would be that its an op designed to ensure the CPU cache is flushed to RAM and that all out of order instructions are completed and flushed before continuing so that the contents of RAM actually match up with what they are supposed to be rather than being slightly off due to the processor making on the fly optimizations and reordering memory writes.
And this is why you don't listen to same random fuck on slashdot telling you why nVidia's drivers suck. He's clearly never worked in kernel code, yet is telling us how to get massive speedups!
I presume you have a bunch of nuts and bolts left over after you work on your car too.
Because FreeBSD is NOT A KERNEL, its a system.
FreeBSD is an entire system, as is PC-BSD. It is not JUST a kernel.
When you use Debian's kFreeBSD, you are not using FreeBSD, you are using Debian, with a FreeBSD kernel. You can't call it FreeBSD any more than you can call it Ubuntu.
Keep in mind, Linux is the only 'OS' on the planet, where people like to pretend that the kernel is the OS and the OS is the kernel. No one else says 'we run the Solaris kernel', or 'We run ntkern.dll'. Its only Linux where you seem to think the kernel is the OS and that the userland isn't part of theOS.
Kernel tests are pointless, as the kernel is worthless on its own. You test the SYSTEM since thats what you'll actually have to use. No one uses the kernel in a void, which means benchmarking just the kernel is useful to no one.
That would be a flaw with the system.
That flaw makes it slower.
You don't get to optionally pretend such flaws don't exist in order to not be the loser.
For instance:
If FreeBSD didn't have to deal with managing the VM, swap, disk IO can memory bandwidth, it would outperform every other OS on the planet!$!@.
Which is true ... except it wouldn't be very useful, and so probably not actually true in any meaningful way.
Of course, my other response is ... WTF is wrong with your system if applications which aren't being displayed and are running in the background are consuming 3d hardware rather than being idled? The proper thing to happen would be that the background 3d application gets little to no resources and doesn't cause a problem, does the Linux scheduler not deal with this problem or are you guys still running around arguing over which one of the 3 that perform almost identically should be the default.
Even Windows deals with the situation gracefully for fucks sake.
So you're arguing over which part of Linux is the problem and saying that its not a Linux problem because its not one particular bit of the system?
Heres a hint, the Linux kernel, alone, is worthless. It requires a system to go alone with it to be useful, so stop trying to pretend that Linux can be narrowed down to JUST THE KERNEL. If you want to go that route then you have to stop claiming Linux capable of doing anything, as I said, on its own, its worthless. Can't even boot without help on a PC.
But you don't want to look at the Linux kernel that way, you want to say its awesome when it is winning BECAUSE ITS THE KERNEL!!!! but its not bad when its losing because ... its something OTHER THAN THE KERNEL!!!!
You don't get to keep your cake and eat it too.
Linux has lost its way.
It was once lean and fast but now is an industrialized bloated mess. It will take a lot more to get me to stop using Linux but that doesn't mean I can't see when something is wrong.
FreeBSD's emulation layer has ALWAYS been performing Linux emulation at between 98 and 102% of that on Linux.
Its not that Linux is slower, its that its different. The tests run here take advantage of things FreeBSD does faster, but there are things that Linux runs faster, which is why sometimes its a tad slower, and othertimes its a tad faster
The emulation layer is more or less a syscall mutator and some patched up libraries, its not really DOING anything that would cause it to be slower, its just a small shim that basically reorders some syscall arguments and reorders them to match up with how FBSD does it. We're talking about very very tiny wrappers making this all work.
I'm a huge FreeBSD fan, and particularly hate Linux fanboys/zealots, but this is one area where there is only room for debate if you're too ignorant to realize the way the FreeBSD emulation layer performs is right on target for good solid code. Both being open source, Linux and FBSD SHOULDN'T PERFORM THAT MUCH DIFFERENTLY as they are both general purpose OSes.
Want fast networking, you use FreeBSD, you want wider support for fringe hardware, use Linux. Last I looked, Linux had the SMP side pretty much locked down away as the winner too.
There is nothing wrong with Linux based on this study that wasn't wrong in 1996, because the emulation layer performance hasn't really changed overall since then (which is when I had my first experience with it). Considering how long the performance has been more or less the same, and I know FreeBSD isn't 'bloated' considering it powers some of the fastest packet analazysis machines on the planet, I'd say that its unlikely Linux could be called bloated.
I could easily change this benchmark in a few subtle ways and throw it the complete other direction. I don't know exactly what they did (they didn't say) but my experience tells me that they just happen to hit the upper side of the emulation layer and not the bottom side.
What you should take away from this however is that you can emulate most things in FreeBSD that will run in Linux and you won't notice a speed difference, should you need to migrate away from Linux for some reason, like faster packet switching or something along those lines.