Slashdot Mirror
BSD Usage Survey
hubertf writes "The BSD Certification Group announced the BSD Usage Survey today (non-English version also available). 'This survey aims to collect detailed statistics on how and where BSD systems are used around the world. The survey is short- only 19 questions- and should only take a few minutes to complete. The survey covers usage of the four main BSD projects - FreeBSD, OpenBSD, NetBSD and DragonFly BSD.'"
The survey doesn't address personal use, which I would assume is a larger, more important part of the various BSD projects because with larger consumer market share, there is more of a push to develop drivers to support devices, and more reason for appliation developers to port apps.
I think that developing an operating system intended for business is a fine thing, but developing an operating system that can handle different markets in the event of a collapse of a market is better.
I'm took this survey earlier this morning, when I got it from a mailing list. It struck me as interesting that Dragonfly BSD is now considered one of the main BSD distros. I'm sure that I speak for a lot of Slashdotters when I say that I think that it's awesome that a small project like this can evolve so quickly and efficiently.
Kudos to the Dragonfly BSD team!
- dshaw
From the start Dragonfly has been one of the main distros imho. They forked FreeBSD and have clear ideas about how it's supposed to work and work hard to get it done. They're part of the BSD landscape now and I think they'll be here for a long time.
home
Dude, look at the number of comments since this "story" was posted. Face it: BSD is dieing.
I understood OS X to be BSD based, so I'm surprised that OS X is not counted as a distribution. I'd be interested to see posted why or why not OS X can be counted as a distribution of BSD; if it quacks like a duck, it seems like it should be included in a survey of this sort.
If OS X is truly a BSD distribution, doesn't it serve BSD evangelists to recognize and promote that?
--
$tar -xvf
I think the reason is that because it's covered already by Apple training and certification. Get Apple certs, and you've got Darwin covered.
I also don't think that Darwin sees much use outside of Mac OS X because people who are running Mac OS X already have it and a whole lot more, and people who would like to run Darwin on x86 simply have not had the driver support needed to make it a viable option.
The loss of Matt Dillon truly hurt the FreeBSD 5 development efforts. That's why it has taken up until FreeBSD 5.4 before many people can even begin to get a system up and running, let alone stable enough for production work.
However, FreeBSD's loss has thankfully turned into DragonFlyBSD. Once the initial work of rearchitecturing DragonFlyBSD is complete, it is quite certain that we might have a platform to replace FreeBSD for server and workstation tasks. DFBSD will be able to handle the massively multicored CPUs that are about to become prevalent. FreeBSD will not. But the virtue of technological superiority, DFBSD will trump FreeBSD.
Cyric Zndovzny at your service.
I'm missing CowboyNeal in almost every question.
Survey is less than a week old and there are at this moment over 2200 responses in several languages!
- Usage: FreeBSD 74%,OpenBSD 32%,NetBSD 20%,DragonFly 3%
- Number of companies with less than 10 systems- 1515; more than 1000 systems- 18
- Where used: North America 44%; Europe 46%; Austrailia/New Zealand 6%; Asia 6%
- Company size: Less than $500K- 1199; Greater than $100M- 117
Coolest 'Uses' comments:- Running large computational fluid dynamic model
- Building access control
- impress chicks on saturday night
- Specialized image processing, touchscreen office appliance
The survey will run through at least the end of September, so these numbers will obviously change.We can use your help. Join the mailing list and contribute ideas and expertise. We're in need of business as well as technical expertise. Let us know what you can contribute with the 'Contact Us' form on the website www.bsdcertification.org.
Thanks to everyone who filled out the survey!
The usage is really only good for comparing BSD distributions between each other. If someone doesn't use BSD they most likely won't spend the time filling out a BSD survey when they don't use the product (and besides they probably won't know about it anyway).
I am surprised by how high OpenBSD and NetBSD is. I would have initially thought it would be lower.
Quality Hosting e3 Servers
Well, I'm not the original poster, but I'll take a shot at discrediting the current crop of MySQL benchmarks.
What will likely become quickly obvious after DTrace is ported to FreeBSD is that MySQL has a number of architectural issues that lead to poor performance on non-Linux platforms because of certain assumption about the system call overhead, scheduler behaviour, scheduling priority, and two relatively major problems that would actually result in even better Linux performance, if they were resolved. Everyone else would also benefit, although it would likely be proprtionately more benefit on non-Linux platforms.
The primary reasons for this are:
(1) because of LMBench, Linux has always valued low individual system call overhead, sometimes at the expense of other aspects of the system. Because of this, there's a wrong-minded idea in some of the basic design decisions that "system calls are free". Any place they aren't as or more cheap than Linux suffers disproportionately poorer performance.
(2) the Linux thread scheduler does not try to attempt to provide any degree of fairness in thread scheduling in a multithreaded program like MySQL; as a result, you tend to get individual threads running all their tasks to completion at the exclusion of other work, whereas other systems end up with significant context switch overhead as they attempt to provide the fairness that Linux does not. You could easily whack the FreeBSD or DragonFly scheduler over the head with a large "don't context switch while there is still work to do in the queue" mallet and get similar performance, at the cost of really scattered latencies, just like Linux(+)
(3) the priorities that are set via pthread_setschedparam() are incorrectly scaled for most non-Linux systems, and assume that all implementation have the same bounded range of priorities; this tends to actually drop the server threads in favor of the client and other processes on the system (even cron).
(4) the MySQL server associates a single thread with a single client, rather than using a statite and scheduling work from various clients to the worker threads in thread-LIFO order. Yes, the conversion from a per-connection thread to a work-to-do model would be difficult, but arguably well worth the effort, and would significantly lessen the apparent performance advanatage of #2, while at the same time improving Linux performance as well. When we switched to this model in NetWare, it got us about a 25% performance improvement.
(5) the MySQL client library pays a very high system call overhead, which is mitigated somewhat by #1; however even Linux would *greatly* benefit by batching the calls. This would be done by ensuring that the client library performs larger reads, rather than a 4 byte read followed by another message-type specific read, followed by a 4 byte read on the other end, and another message-type specific read on the other end(*)
Overall, MySQL benchmarks are actually pretty useless as a measure of relative system performance, and will remain so, at least until the performance issues inherent in its architecture have been addressed.
(+) At this point, the question "what about mean measured transaction latency and standard deviation?" should be occurring to someone to include in a future MySQL benchmark.
(*) actually, an even more efficient mechanism could be had here, given that client caching on the server side of things won't work because of the per-connection threading model; the model that would work would be a modified "accept filter" approach, to ensure that the client or server connection only received whole request/response messsages that could then be processed to completion, rather than stalling the work pipeline on partial packets in the face of long messages or intermediate fragmentation.
-- Terry
Probably because quite some of the people involved with snort run FreeBSD..
Plainer English: MySQL is broken.
Linux could score about 20-30% better on these benchmarks by fixing MySQL.
FreeBSD et. al. would tend to score about 50%+ better if these same fixes were made to MySQL.
I don't know how comparable the performance would be, but a simple test with a cache in the client library (one of the fixes MySQL needs) show about a 20% performance improvement for a BSD-based system.
Maybe you don't care about MySQL performance being better overall, but the MySQL people should.
-- Terry
You know, this would be a lot more convincing if it wasn't a mere list of puff pieces and doubtable "facts." The real fact is that the market has spoken, and Linux is the next generation unix. *BSD has failed to catch on because of its own shortcomings and therefore is considered by most impartial technologists as "dead" -- shorthand for "not growing, not being adopted, saddled with legacy technology issues and endless community in-fighting."
If making this clear makes me a "troll," then by god, I am a troll. I guess in this era of Bush 1984-isms, calling a truth-teller a "troll" and a "flamebaiter" only makes sense.
I guess.
The exact opposite is true. Linux packet-handling is about 400% faster and more efficient than *BSD. The Snort guys switched to Linux in 2003 for this very reason, particularly because of the improvements in kernel 2.6. Snort's recommended platform is Linux, not *BSD.
Your information is 2+ years out-of-date.
BSD developpers refuse to serve, drink, or believe in the kool-aid. That's what!
Of course people who do surveys gargle with it and as such can't add home users to the surveyed because then the survey may mean something more than they care about...
Microsoft is pure dog-ma. FreeBSD is pure cat-ma.
Here's my poll results:
FreeBSD:
NetBSD:
HatersBSD:
ClosedBSD:
InfightersBSD:
FlowerBlossomBSD:
RevengeBSD:
PissedOffBSD:
LINUX: 99.953%
Average Linux user: well-paid expert administrator.
Average *BSD user: angry unemployed D&D player.
C'mon, you all know these are the real facts.
Thus proving that any Linux distribution is superior to any *BSD. Time to switch, buddy. Jump off the boat before it goes under.