Contributed by jose on from the how-fast-is-it? dept.
See http://osuosl.org/benchmarks/bc/
How can we best achieve this benchmarking across many different distributions? Simple, we gather the finest minds and administrators from each camp and bring them together to build the machines themselves.
We have selected the following distributions. This list is not final and if people want to ante in to try this with their favorite distro, let us know at bc2004 at osuosl dot org or in #beaverchallenge on the Freenode.net IRC network.
- Debian GNU/Linux
- Fedora Linux
- FreeBSD
- Gentoo Linux
- NetBSD
- OpenBSD
- Red Hat Linux
- Slackware Linux
- SuSE GNU/Linux
(Comments are closed)
By Anonymous Coward () on
Comments
By Noryungi () n o r y u n g i @ y a h o o . c o m on mailto:n o r y u n g i @ y a h o o . c o m
Yep. Dell SMP system 2xXeon @ 2.0 GHz. Stupid, Stupid, Stupid.
Here is a link to the machine that will be used.
FreeBSD may have a chance. NetBSD may be able to install pre-2.0 (1.6.2?) with SMP support, but high performances is not OpenBSD main concern. If they tested reliability and security, OpenBSD may stand a chance...
Comments
By Job () on
If they really do a good job and publish decent reports, it may be helpful the developers to see which operations take longest; they can then examine the code to see if they can speed it up.
There is no reason that something cannot be secure and perform well. A local root vulnerabilty doesn't happen because someone is trying to push data through too fast, it happens because of a design flaw or coding error.
I've patched a lot of security holes on my own apps over the years, and the patches never make the system slower. Designing an app for security can often put extra steps into the process, but it is almost always possible to find a way to make those steps faster so that the security has the minimum effect on performance.
Comments
By Kim () on
Comments
By Anonymous Coward () on
Still, I hope they decide to run lone processor tests in addition to dual ... most of us don't have dual processor machines.
By Shane () on
Hang on a minute. This is not just secure code that been audited. This is code that has additional mechanisms which go to incredible lengths to provide consistency checking and randomisations where they are appropriate.
No matter how fast you can make that code, it cannot be faster than the same code without the consistency checking and randomisations.
So as such, OpenBSD cannot be the fastest as long as it retains these mechanisms. It can be fast and secure, but not fastest. And that is okay because the goal of OpenBSD is security, first and foremost.
I've patched a lot of security holes on my own apps over the years, and the patches never make the system slower.
This is not about changing a "255" to "254" or a "greater than" to a "greater than or equal". It is about much larger additions to code with the intent of greater security. Extra code hurts "performance".
But what is "performance" anyway? Web pages served per second? For me security performance is most important. Buy a computer which can saturate your internet connection while running OpenBSD and be happy.
By LB () l0rd@xs4all.nl on http://www.xs4all.nl
By Anonymous Coward () on
It would be more comparable if it was on a single processor machine. I have no plans to get a dual processor machine for the forseeable future. I just stack up cheap single CPU boxes.
By Anonymous Coward () on
OpenBSD's goals aren't to be the fastest OS or even speed at that. It's mainly security.
FreeBSD on the other hand I think would be a good contender, but then again it would be better to test FreeBSD 5.3-stable (once it's out) with better SMP support than 4.x.
NetBSD, personally, I have next to no experience with so I couldn't comment.
Just my $0.02.
By Chad Loder () on
We shouldn't be afraid of the truth. Is OpenBSD going to come out on top? I doubt it...but if OpenBSD is shown to be less slow than most people assume, that's a good thing. If performance bottlenecks are identified, it will help prioritize development. I say we should do our best to configure the server, with no excuses, and see what the results are. What are you afraid of?
Comments
By Matt Fleming () splitscreen@splits.mine.nu on mailto:splitscreen@splits.mine.nu
By Anonymous Coward () on
I always think in openbsd to solve my problems and not to be fastest os in the hill.
By tedu () on
Comments
By Anonymous Coward () on
*actually I wish I had been gifted with brain cells sufficient to do more than criticize ... but alas it wasn't to be ...
Comments
By Paul () spawn@maltliquor.ca on mailto:spawn@maltliquor.ca
I haven't done alot of testing on this, but its been suggested it might something specific in our setups; as a few people aren't able to re-produce these results. Though I've seen this on Intel and Sun boxes with various configurations.
-Paul
Comments
By Anonymous Coward () on
Comments
By Anonymous Coward () on
Softdeps has also never worked right on my SparcStation 20.
At this point I'd just stopped using softdeps entirely -- but since everyone doesn't have this problem I guess I'll keep trying on each individual machine I use.
By Anonymous Coward () on
Comments
By Anonymous Coward () on
Comments
By Oliver Neubauer () on
Hopefully they will publish methods along with results (as I think the former will prove more interesting than the latter)....
By Anonymous Coward () on
Comments
By Anonymous Coward () on
Comments
By Shane () on
And the more we use and enjoy OpenBSD, the more we appreciate Theo's determiniation.
And BTW, regarding this defeatism crap, OpenBSD actively improves security with a willingness to do this at the expense of performance if that is what is required. It is not a defeatist attitude to admit to the reality that OpenBSD can be very quick, but not quickest by default as long as all these consistency checks and what not are in place.
I'd be happy to see improvements made to OpenBSD due to areas that might be highlighted in these benchmarks, but I know a lot of slashdot kids will be running around claiming OpenBSD sucks and some arseholes will come in here to gloat over something that matters little to the project in the grand scheme of things.
Comments
By Anonymous Coward () on
And the people who think it's true, deserve to continue in ignorance...or is that bliss?
Comments
By Anonymous Coward () on
And the people who think it's true, deserve to continue in ignorance...or is that bliss?
I agree. As long as they stay away from the lists and deadly, I'm happy.
By Dave () on
Comments
By asdfg () on
Of course, sites like OSNews claim that Slackware is the fastest and snappiest for desktop use (http://www.osnews.com/story.php?news_id=5307), whatever that means. :-)
In the end, however, it's up to the experts from each camp to tweak each distribution to the max. I expect that they would probably end up with the "same" optimized binaries for each system with the "same" kernel, so there shouldn't be any difference.
By Anonymous Coward () on
If, on the other hand, they all go to kernel.org and grab 2.6.2 and compile it for i686, then testing multiple Linux distros is pretty pointless.
By Sergey Sokolov () siddkharta@yandex.ru on mailto:siddkharta@yandex.ru
By IDunno () on
By dawg () on
In fact I hope it is slower and I hope all the slashdot sheep make a big deal out of it.
If they do, hopefully the idiots that can't figure out why won't degrade the openbsd genepool :-) with their presence.