"That, needless to say, is a recipe for irrelevance and, eventually, disappearance."
In the last eight+ years I've used OpenBSD extensively as the networking and firewall core for smart grid networks. I can, with confidence, say that 100% of the smart grid transactions on at least two $Billion+ utilities on at least two continents flow through OpenBSD servers.
We evaluated the full gamut of Cisco, Fortinet, and other Firewall technologies, but, from 2004 through 2010, only OpenBSD had the functionality and failover that we were looking for for < $100K/appliance. (And, when you want two for redundancy, plus another two for your DR center - Four appliances add up). It almost pained me to see how low-end a server could handle hundreds of thousands of IPv6 UDP states compared to what Cisco would have charged. (Note - and, regardless, Cisco didn't, until recently, handle IPv6 in fault-tolerant Active-Hot-Standby mode on their ASA platform)
For those that have a lot of experience with OpenBSD - the continued rock solid stability, almost 100% complete (and useful) _systems_ documentation (as opposed to the utility and library documentation you get on a linux system), consistent startup/configuration for 10+ years, plus, of course, very mature pf, makes the platform a continuing highly relevant product, that will not disappear for many years to come.
I've been involved in north of 50-60 servers running OpenBSD since 2001, and I've never seen, nor even heard, of anybody running OpenBSD on the desktop. It's never been relevant on that platform and serves no useful function as a Desktop Environment beyond the core developer and OpenBSD Hobbyist community. Not to suggest that they aren't an important community - but they are fully capable of taking care of their own needs. The rest of the world uses OpenBSD as a firewall/routing/networking/reliable-appliance platform.
I must confess, my desktop adventure with OpenBSD was quite short. Not that I didn't appreciate the simplicity (and I think that's the key appeal), but just the bareness was a little too much for me. I'm sure others will feel differently; I've got a friend who keeps his desktop and server Puffy and he seems quite happy. Then again, he's also quite odd.
I did get a kick out of seeing my old Celeron Windows 95 machine now running a modern OS, browser and chat client.
If you read the article, you'll see they aren't deploying OpenBSD to their users as a general desktop, but as an Appliance Environment - which makes total sense. Call Centers, Transaction Centers, NOCs, etc... - Anywhere you have a pre-set configuration/applications, OpenBSD is a great choice. Rock Solid stability and super secure. This is also an area where ChromeBooks will do well.
By "Desktop" - though, I mean users who are planning on downloading/installing various productivity utilities, applications, etc... to do their job. Creating Reports, Slide Decks, PDFs, Spreadsheets, charts, diagrams, IM apps, Skype - whatever random app they want to use to do their Job.
I've never seen an OpenBSD user in 20+ years of supporting Desktops in Engineering and Corporate environments - Windows obviously, but lots of Macintosh OS, A nice run of NextOS, Lots of FreeBSD, umpteen distros of Linux (for a while, that's all people seemed to be running), many versions of Solaris, tons of Irix, a handful of HPUX users, and even a couple AIX users.
But, in that same time - I've seen OpenBSD squirreled away in all sorts of Appliance/Network/Firewall duties.
``By "Desktop" - though, I mean users who are planning on downloading/installing various productivity utilities, applications, etc... to do their job.''
I think the average user could be satisfied with what's available on OpenBSD. The only bummer is flash.
The BSD in general (I mostly know FreeBSD, but I doubt OpenBSD is much better) haven't been perfect for running desktop software, and especially the big desktop environments, for a long time. If they ever were adequate.
It can be done, but with quite a bit of tweaking, battling strange inconsistencies, and in the end, missing some functionality compared to the same thing on linux. Possible, but not by any stretch a core value proposition or a major component direction of the projects (whatever they officially say). Or at least, not the successful projects.
Sucks to see a lot of things becoming linux-specific, but in a ton of these cases, the impact on the BSDs will be minimal.
I wouldn't call it a failure, but it's not really a success either. At least not yet.
I don't know anyone who uses it, nor do I really hear about it apart from the people developing it. Sometimes, people mention it, in a "Maybe you should try PC-BSD, I've heard it's good" kind of way, but that's as far as it goes.
KDE 4 had, for a long time, a misfeature relating to pthread_mutex_t support on OpenBSD (which was my fault, I suppose).
A couple of years later I heard from an OpenBSD dev who noted the issue and recommended a workaround, which I implemented and hopefully means KDE works in OpenBSD now.
But other than that one dev I'm not aware of any OpenBSD users or devs noticing or complaining about that bug (which would have been quite noticeable from the terminal output at least).
My conclusion: Your typical KDE user is not in the position to do the non-trivial work of porting a large C++ code base. Nor does she know where to get started. Such bloatware needs at least one dedicated and interested developer on each target OS.
We now have one, so there is quite some movement on this front in the recent months.
> Such bloatware needs at least one dedicated and interested developer on each target OS.
That's correct. Although I'm one of the few who actually seems to care about portability as a good practice I don't have the time to run 5 different OS'es to verify each of my volunteered contributions works on every feasible POSIX platform.
In the end someone who is interested in each of those platforms needs to help take on the task of ensuring that the software they use works on the platform they use (that is, if they wish for the software to work). This can be as simple as reporting bugs, helping with integration into platform-specific libraries (which KDE is usually very good about using through adapter libraries to ensure portability), reporting platform-specific bugs that need worked around, etc.
Some projects are already taking a WONTFIX attitude to portability bugs. I will push where I can to make sure that KDE isn't one of them, but I can't change the number of hours in a day... non-Linux developers need to contribute too if they want a great KDE on that platform.
It is incredibly easy to have a buildfarm (entirely made up of virtual machines even) that can build and test your software across dozens of operating systems. When I install a large software package like KDE, and see that there are glaringly obvious bugs, I assume it is because the developers do not care enough to do the most trivial automated testing. So I simply uninstall it and use software that works. When you create an impression of "we don't care about you", people are much less likely to bother reporting issues.
> So I simply uninstall it and use software that works.
Which is convenient, as then I feel less guilty about the issues I don't have time to triage, less alone fix. You don't think I personally care if you use KDE or not I hope... I contribute where I can, as time becomes available. If people find that useful, that's wonderful. If people don't find that useful, that's fine too.
I've heard from many people who have found useful those things I've found time to implement, so I'll keep plugging along for now.
As it turns out though, there actually is a build farm/continuous integration infrastructure that our wonderful sysadmins have setup for KDE by now: http://build.kde.org/
But CI isn't useful unless it results in actionable information, and it still requires developer action to make the fixes. We're accepting patches...
You seem to be confused. I was explaining why you don't see many bug reports, not threatening you with my not using KDE. I haven't tried KDE in like 12 years, it was just a general statement, not a comment on KDE specifically.
No... we see tons of bug reports. Just not from OpenBSD users.
If you're saying OpenBSD users are in general pickier about what software they install based on what practices are used to develop that software I'd certainly believe it. I've certainly done no studies myself to figure out why there are so few bug reports so I can't say any one reason is better than another.
Yep, I used to run OpenBSD firewalls exclusively. I really liked pf, the "programming language" is powerful, clear and concise. IIRC, they were doing stateful connection tracking years before whatever was on Linux at the time. I didn't get around to playing with the failover stuff, but I read about it eagerly when it first came out.
Sadly, due to the limited amount of time I have for IT these days, I have standardized on Linux for my new firewalls (because I need it for my fileservers and desktops too). After trying some other firewall setup systems, I'm currently using ShoreWall, which is... OK. I feel almost as safe, in part because of what I learned about TCP/IP networking while using pf.
So my reaction to not having good GUI support for OpenBSD is kind of "so what?". It is awesome for what it is right now.
I would suggest they throw their weight behind one of the smaller DE projects like LXDE or XFCE. In my mind's eye, the stereotypical OpenBSD enthusiast is not that impressed with whizzy GUIs with a dumbed-down interface that has significant compromises just so that it can also run on a tablet. I would guess that they just want a simple DE with terminal windows, a browser and PDF reader. Well, that's nearly all that I want, so that's probably why I run LXDE. Not that I'm a stereotypical OpenBSD enthusiast. All I really ask of my DE is that it supports auto-raise and doesn't steal my focus while I'm typing (grrrr, Windows 7, grrrrr).
fvwm is the default wm on OpenBSD. I think they are unlikely to replace that with either LXDE or XFCE due to the lack of a BSD-like license. I don't know what other options there are but perhaps they are happy with fvwm.
I don't understand, how can some wacky desktop be harmful to OpenBSD if they introduce low-level dependencies difficult to port over? I don't think any OpenBSD user are even interested in using systemd, pulseaudio or any of those end-user applications. OpenBSD is for servers and such, only very technical users have it as a "desktop".
It's interesting how many people in this thread apparently have authoritative knowledge of what others should use OpenBSD for. You are utterly wrong.
I want KMS, I want to be able to install Gnome and see what they are up to. Not that I care about Gnome, but it should work if at all possible. There are a lot of users and developers who want a well working modern desktop running OpenBSD.
How does running an OpenBSD firewall compare to running one on FreeBSD using the ported version of PF? I only have experience with the latter and I wonder if I'm missing out on something.
I really wish pf had enough people to get the full "portable" treatment like OpenSSH, etc. get.
I agree. I'd rather use pf than ShoreWall on my Linux systems. If someone who had more time/energy for this wanted to start up that project, I could chip in at least a little money. I'm sure others could too, but I don't know how much that would add up to.
Well, OpenBSD is more secure, and are less likely to break. OpenBSD is top quality into its core, even their release model is much better than FreeBSD's.
Why did the author, Jonathan Corbet, and HN submitter, "iso-8859-1",
decide to revive the slashdot troll meme of "BSD is Dying" here on HN
which is running FreeBSD?
The article is no meme recitation. Did you read the article? Did you not even consider if GUI's are useful to the BSD's? Do you really think the BSD's would retain the same level of popularity if they have to maintain more and more infrastructure every year?
How does it matter which platform HN uses? It is about the content, not the technology. 99% of HN visitors do not care if HN is running on a lemon powered Babbage engine or not.
I love BSD, but the user community is hostile to entry and hostile to causal users, so it's not surprising that everyone but the experts has switched to Linux.
Like tobiasu pointed out, there is no BSD user community. Having split off from the same code base 20 years ago doesn't make the projects into a single entity.
> One could easily poke holes in this complaint; the characterization of PAM as "modern" is somewhat amusing; it is 1990s technology. There is an evident case of cognitive dissonance shown in the simultaneous desire for the comfortable "Posix and Unix" world of decades past and the ability to "innovate and do cool things." It is difficult to simultaneously innovate and stand still, but that is what Marc seems to be asking for here.
There's a bit of nitpicking in the above. PAM may not be a new technology, but it's not used by every OS. The problem is the implicit assumption by many devs that it is being used. Multiply this by every choice that the Linux kernel and various distros have made differently than other Unix-like OSs and you end up with a ton of open source software that is effectively locked into Linux.
In my (limited) open source experience, most devs using Linux do NOT do this on purpose. They just assume that they're writing UNIX software when they are not. They end up using GNUisms, #defines only available in Linux, assume PAM and other things, ad nauseam. When I've pointed such things out, I usually get a bewildered look. Many Linux people think they're using vi when they're using vim. They don't understand that their sed scripts are really gsed and won't work on traditional sed. They don't know their sh scripts are really bash scripts and break on traditional /bin/sh. And C code is a similar story. In most cases these little things do not improve the code; they only introduce incompatibility. So when Espie uses scare quotes on "progress" and "modern" I get his point. When progress and modern mean an equivalent but incompatible system, then they deserve scare quotes.
This is exactly why I stopped using linux. It seems that in their attempt to compete with windows, linux has forgotten about trying to be a decent unix OS. A modern linux distro is every bit as complex, disorganized, undocumented and buggy as windows. So now linux distros feel to me like the worst of both worlds, a bad unix platform, and a bad desktop experience. I end up running windows 7 for a desktop, with an openbsd virtual machine for my unix/dev environment, and get the best of both worlds.
If you think that the OpenBSD has it right, why don't you use it as a desktop, too? Why aren't you running a virtual machine of Windows 7 under OpenBSD? Probably because there's no proper virtualization support in OpenBSD.
Linux is complex because sometimes it has too be, not just for the sake of it. systemd (which is great in my opinion) wouldn't be possible without cgroups. Should I also mention the better multi-processor support? Regarding the desktop, I strongly recommend watching "27c3 - Desktop on the Linux... (and BSD, of course) - Wolfgang Draxinger (+ Lennart Poettering)" [1].
>If you think that the OpenBSD has it right, why don't you use it as a desktop, too?
Because I need to run windows applications.
>Why aren't you running a virtual machine of Windows 7 under OpenBSD?
Because my laptop already had windows 7 on it, why install two OSes when I can install one?
>Linux is complex because sometimes it has too be
No, using complexity to justify further complexity does not mean it has to be that way.
>Should I also mention the better multi-processor support?
That has nothing to do with simplicity though. NetBSD is also simple, and it has SMP support as good as linux does. I am just using openbsd because fine grained locking is un-noticable for a dev box, and openbsd comes with better package management than netbsd.
>Regarding the desktop, I strongly recommend watching "27c3 - Desktop on the Linux...
I'm not very far through, but I have no idea why you think I should be watching this? Is there a particular time I can jump to where something relevant happens?
I'm not familiar enough with NetBSD, but David Miller from Red Hat said "I love NetBSD releases, because their new feature lists help remind me what I implemented a decade ago." [1]. I've also found a benchmark done by the DrangFlyBSD guys[2]:
The tests were performed using system defaults on each platform with pgbench as the test client with a scaling factor of 800. The test system in question was a dual-socket Intel Xeon X5650 with 24GB RAM.
NetBSD 6.0 was unable to complete the benchmark run.
That video shows that things aren't as simple as one might think, at least on the desktop.
David Miller is better known for spewing crap than he is for writing code, with good reason. When you feel the need to stir up shit by posting stuff like "durr netbsd is doing stuff I did a decade ago" while ignoring the fact that netbsd also did it a decade ago and is just updating their implementation (just like linux does), you stop being someone worth listening to.
It is pretty unfortunate that the dragonflybsd camp still insist on pushing deliberately misleading benchmarks, I must admit. They have a great OS and there is simply no need for them to be doing that shit. Refusing to adjust the default limits when you know full well netbsd and openbsd ship with conservative limits to prevent accidentally DoSing yourself on low end hardware is just plain stupid. "Oh look, netbsd mysteriously stops working right when we hit the default resource limits!"
Nevertheless thread-local storage (TLS) and Logical Volume Manager (LVM) functionality have been available under Linux (and probably other BSDes) for quite some time.
So that benchmark is kind of wrong. What about the results for fewer concurrent clients? NetBSD seems to perform worse than (Scientific) Linux. Is it because of those resource limits?
TLS is not a feature, it is a problem. It was added because of the very problems that started this thread. Modern linux software expect stupid crap like that, so NetBSD eventually feels forced to add it. The entire point is that BSDs try to avoid adding unnecessary complexity like that.
The dragonfly benchmark doesn't give us any real info, so it is impossible to say what exactly the problem is. Clearly something is wrong though, given we already know netbsd made performance and scalability a major focus of the 5.0 release, and nobody has reported any regressions in 6.0:
This is in some sense a good counterpoint to the recent comparisons of WebKit monoculture to Linux monoculture: everyone working together on Linux is nice, but it has downsides, too, because things do become unduly Linux-specific to the detriment of competition.
53 comments
[ 3.2 ms ] story [ 96.9 ms ] thread"That, needless to say, is a recipe for irrelevance and, eventually, disappearance."
In the last eight+ years I've used OpenBSD extensively as the networking and firewall core for smart grid networks. I can, with confidence, say that 100% of the smart grid transactions on at least two $Billion+ utilities on at least two continents flow through OpenBSD servers.
We evaluated the full gamut of Cisco, Fortinet, and other Firewall technologies, but, from 2004 through 2010, only OpenBSD had the functionality and failover that we were looking for for < $100K/appliance. (And, when you want two for redundancy, plus another two for your DR center - Four appliances add up). It almost pained me to see how low-end a server could handle hundreds of thousands of IPv6 UDP states compared to what Cisco would have charged. (Note - and, regardless, Cisco didn't, until recently, handle IPv6 in fault-tolerant Active-Hot-Standby mode on their ASA platform)
For those that have a lot of experience with OpenBSD - the continued rock solid stability, almost 100% complete (and useful) _systems_ documentation (as opposed to the utility and library documentation you get on a linux system), consistent startup/configuration for 10+ years, plus, of course, very mature pf, makes the platform a continuing highly relevant product, that will not disappear for many years to come.
'Hacker' News, indeed.
I did get a kick out of seeing my old Celeron Windows 95 machine now running a modern OS, browser and chat client.
By "Desktop" - though, I mean users who are planning on downloading/installing various productivity utilities, applications, etc... to do their job. Creating Reports, Slide Decks, PDFs, Spreadsheets, charts, diagrams, IM apps, Skype - whatever random app they want to use to do their Job.
I've never seen an OpenBSD user in 20+ years of supporting Desktops in Engineering and Corporate environments - Windows obviously, but lots of Macintosh OS, A nice run of NextOS, Lots of FreeBSD, umpteen distros of Linux (for a while, that's all people seemed to be running), many versions of Solaris, tons of Irix, a handful of HPUX users, and even a couple AIX users.
But, in that same time - I've seen OpenBSD squirreled away in all sorts of Appliance/Network/Firewall duties.
I think the average user could be satisfied with what's available on OpenBSD. The only bummer is flash.
``Creating Reports, Slide Decks, PDFs, Spreadsheets, charts, diagrams[...]''
LibreOffice is available on OpenBSD.
``IM apps''
Pidgin and a ton of other clients are available.
``Skype''
It used to work a few releases ago, I don't know if it still does now.
`` - whatever random app they want to use to do their Job.''
Yes, if you compare it to Windows in that regard then it's at a loss. But if you compare it to Liunx I'd say it's up to par.
The problem is that it's getting harder to keep up to date, which is what Marc is trying to explain in his email to tech@.
It can be done, but with quite a bit of tweaking, battling strange inconsistencies, and in the end, missing some functionality compared to the same thing on linux. Possible, but not by any stretch a core value proposition or a major component direction of the projects (whatever they officially say). Or at least, not the successful projects.
Sucks to see a lot of things becoming linux-specific, but in a ton of these cases, the impact on the BSDs will be minimal.
I don't know anyone who uses it, nor do I really hear about it apart from the people developing it. Sometimes, people mention it, in a "Maybe you should try PC-BSD, I've heard it's good" kind of way, but that's as far as it goes.
A couple of years later I heard from an OpenBSD dev who noted the issue and recommended a workaround, which I implemented and hopefully means KDE works in OpenBSD now.
But other than that one dev I'm not aware of any OpenBSD users or devs noticing or complaining about that bug (which would have been quite noticeable from the terminal output at least).
Drawn whatever conclusions you will from that. ;)
We now have one, so there is quite some movement on this front in the recent months.
That's correct. Although I'm one of the few who actually seems to care about portability as a good practice I don't have the time to run 5 different OS'es to verify each of my volunteered contributions works on every feasible POSIX platform.
In the end someone who is interested in each of those platforms needs to help take on the task of ensuring that the software they use works on the platform they use (that is, if they wish for the software to work). This can be as simple as reporting bugs, helping with integration into platform-specific libraries (which KDE is usually very good about using through adapter libraries to ensure portability), reporting platform-specific bugs that need worked around, etc.
Some projects are already taking a WONTFIX attitude to portability bugs. I will push where I can to make sure that KDE isn't one of them, but I can't change the number of hours in a day... non-Linux developers need to contribute too if they want a great KDE on that platform.
Which is convenient, as then I feel less guilty about the issues I don't have time to triage, less alone fix. You don't think I personally care if you use KDE or not I hope... I contribute where I can, as time becomes available. If people find that useful, that's wonderful. If people don't find that useful, that's fine too.
I've heard from many people who have found useful those things I've found time to implement, so I'll keep plugging along for now.
As it turns out though, there actually is a build farm/continuous integration infrastructure that our wonderful sysadmins have setup for KDE by now: http://build.kde.org/
But CI isn't useful unless it results in actionable information, and it still requires developer action to make the fixes. We're accepting patches...
If you're saying OpenBSD users are in general pickier about what software they install based on what practices are used to develop that software I'd certainly believe it. I've certainly done no studies myself to figure out why there are so few bug reports so I can't say any one reason is better than another.
And NetBSD users, and minix users, etc, etc. That's exactly what I was saying.
Sadly, due to the limited amount of time I have for IT these days, I have standardized on Linux for my new firewalls (because I need it for my fileservers and desktops too). After trying some other firewall setup systems, I'm currently using ShoreWall, which is... OK. I feel almost as safe, in part because of what I learned about TCP/IP networking while using pf.
So my reaction to not having good GUI support for OpenBSD is kind of "so what?". It is awesome for what it is right now.
I would suggest they throw their weight behind one of the smaller DE projects like LXDE or XFCE. In my mind's eye, the stereotypical OpenBSD enthusiast is not that impressed with whizzy GUIs with a dumbed-down interface that has significant compromises just so that it can also run on a tablet. I would guess that they just want a simple DE with terminal windows, a browser and PDF reader. Well, that's nearly all that I want, so that's probably why I run LXDE. Not that I'm a stereotypical OpenBSD enthusiast. All I really ask of my DE is that it supports auto-raise and doesn't steal my focus while I'm typing (grrrr, Windows 7, grrrrr).
That's true. There's not much out there in GUI land that isn't GPL these days though, from my brief survey.
I'd guess they're not completely satisfied with FVWM though, because they mention working on Gnome for OpenBSD.
OpenBSD WILL disappear if not supported, no matter how useful it is.
I want KMS, I want to be able to install Gnome and see what they are up to. Not that I care about Gnome, but it should work if at all possible. There are a lot of users and developers who want a well working modern desktop running OpenBSD.
4.8 and later introduced some syntax changes, so current OpenBSD docs aren't applicable to other systems.
I really wish pf had enough people to get the full "portable" treatment like OpenSSH, etc. get.
I agree. I'd rather use pf than ShoreWall on my Linux systems. If someone who had more time/energy for this wanted to start up that project, I could chip in at least a little money. I'm sure others could too, but I don't know how much that would add up to.
How does it matter which platform HN uses? It is about the content, not the technology. 99% of HN visitors do not care if HN is running on a lemon powered Babbage engine or not.
I doubt those two are used to gain market share ... maybe openbsd is just pure fun
http://news.ycombinator.com/item?id=4798791
The previous discussion is more informative.
There's a bit of nitpicking in the above. PAM may not be a new technology, but it's not used by every OS. The problem is the implicit assumption by many devs that it is being used. Multiply this by every choice that the Linux kernel and various distros have made differently than other Unix-like OSs and you end up with a ton of open source software that is effectively locked into Linux.
In my (limited) open source experience, most devs using Linux do NOT do this on purpose. They just assume that they're writing UNIX software when they are not. They end up using GNUisms, #defines only available in Linux, assume PAM and other things, ad nauseam. When I've pointed such things out, I usually get a bewildered look. Many Linux people think they're using vi when they're using vim. They don't understand that their sed scripts are really gsed and won't work on traditional sed. They don't know their sh scripts are really bash scripts and break on traditional /bin/sh. And C code is a similar story. In most cases these little things do not improve the code; they only introduce incompatibility. So when Espie uses scare quotes on "progress" and "modern" I get his point. When progress and modern mean an equivalent but incompatible system, then they deserve scare quotes.
Linux is complex because sometimes it has too be, not just for the sake of it. systemd (which is great in my opinion) wouldn't be possible without cgroups. Should I also mention the better multi-processor support? Regarding the desktop, I strongly recommend watching "27c3 - Desktop on the Linux... (and BSD, of course) - Wolfgang Draxinger (+ Lennart Poettering)" [1].
[1] http://www.youtube.com/watch?v=ZTdUmlGxVo0
Because I need to run windows applications.
>Why aren't you running a virtual machine of Windows 7 under OpenBSD?
Because my laptop already had windows 7 on it, why install two OSes when I can install one?
>Linux is complex because sometimes it has too be
No, using complexity to justify further complexity does not mean it has to be that way.
>Should I also mention the better multi-processor support?
That has nothing to do with simplicity though. NetBSD is also simple, and it has SMP support as good as linux does. I am just using openbsd because fine grained locking is un-noticable for a dev box, and openbsd comes with better package management than netbsd.
>Regarding the desktop, I strongly recommend watching "27c3 - Desktop on the Linux...
I'm not very far through, but I have no idea why you think I should be watching this? Is there a particular time I can jump to where something relevant happens?
The tests were performed using system defaults on each platform with pgbench as the test client with a scaling factor of 800. The test system in question was a dual-socket Intel Xeon X5650 with 24GB RAM.
NetBSD 6.0 was unable to complete the benchmark run.
That video shows that things aren't as simple as one might think, at least on the desktop.
[1] https://plus.google.com/101384639386588513837/posts/ZD5ZhZ2F...
[2] http://www.dragonflybsd.org/performance/
It is pretty unfortunate that the dragonflybsd camp still insist on pushing deliberately misleading benchmarks, I must admit. They have a great OS and there is simply no need for them to be doing that shit. Refusing to adjust the default limits when you know full well netbsd and openbsd ship with conservative limits to prevent accidentally DoSing yourself on low end hardware is just plain stupid. "Oh look, netbsd mysteriously stops working right when we hit the default resource limits!"
So that benchmark is kind of wrong. What about the results for fewer concurrent clients? NetBSD seems to perform worse than (Scientific) Linux. Is it because of those resource limits?
The dragonfly benchmark doesn't give us any real info, so it is impossible to say what exactly the problem is. Clearly something is wrong though, given we already know netbsd made performance and scalability a major focus of the 5.0 release, and nobody has reported any regressions in 6.0:
http://www.netbsd.org/~ad/50/img13.html