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.'"

Personal use?

[theapodan]

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.

Re:Personal use?

[Homology]

Have a look at the OpenBSD Project Goals [openbsd.org]. Do you see any goal about "intended for business"? Here is the gist of it if you search the mailinglists: The OpenBSD developers develops for themselves, and that it incidentally is usefull for other is a nice bonus. They are not very interested in "markets" or "market share".

Re:Personal use?

[Saeed al-Sahaf]

...Do you see any goal about "intended for business"?...

and...

They are not very interested in "markets" or "market share".

If this is the case, then honestly, what is the purpose of a BSD Certification? Obviously the goal of such a certification (in fact all "professional" certifications) is acceptence of BSD (or whatever the product) in the business sector. Think about it.

Re:Personal use?

[theapodan]

What you seem to be ignoring is that the way to drive acceptance of *nix operating systems has been to bind them to hardware, sun, ibm, etc. Linux has rewritten paradigm to great success, and the BSD's also do so. However, without sufficient push for more devices, BSD can ONLY be targeted at the business sector.

So here's the question that I pose to you: what is the purpose of a BSD certification if only the business sector uses BSD? Without end users, there is nobody that needs a certified tech. There i

Re:Personal use?

[Homology]

If this is the case, then honestly, what is the purpose of a BSD Certification? Obviously the goal of such a certification (in fact all "professional" certifications) is acceptence of BSD (or whatever the product) in the business sector. Think about it.

The BSD Certification "certifies" that you have a certain skill set level working with *BSD. This is about using an OS as distinct from creating one. So those making this BSD Certification has different goals than those creating the *BSD. See?

Re:Personal use?

[Shanep]

If this is the case, then honestly, what is the purpose of a BSD Certification? Obviously the goal of such a certification (in fact all "professional" certifications) is acceptence of BSD (or whatever the product) in the business sector. Think about it.

As a very happy OpenBSD user, in my private and business life, since 2.5, I say... think about this... I view the fact that OpenBSD does not wish to impress any business clients as a priority, to be a HUGE benefit to OpenBSD quality.

They're not out to form a bullshit glossy image to sell product in a competitive marketplace full of other bullshit companies with bullshit glossy brochures, paid-for reviews and advertisements. OpenBSD sells itself on the merits of its code quality. People who care and know better enjoy and appreciate this.

And beleive it or not, OpenBSD (and the other BSD's), do actually get used in big business. I know of two major banks which use OpenBSD for firewall and VPN machines just as one example. I also use OpenBSD in various roles at certain firms where I provide support and consulting.

Re:Personal use?

[KwKSilver]

Good point. I had no trouble installing and using the 4.8, 4.9 and 4.10 Free BSD O/S. It was for personal use & just to see ... Never could get a functioning system out of the 5.x series. It is silly for FreeBSD to be getting harder to istall while Debian has gotten trivially easy.

However, PC-BSD [pcbsd.org] works quite well, but with limited software installation, unless one goes to the ports. The base is OK for someone who just wants to surf and e-mail. Getting OO installed is trickier. It got a good revi

The loss of Matt Dillon hurt FreeBSD 5.

[CyricZ]

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 multicor

Re:The loss of Matt Dillon hurt FreeBSD 5.

[Ecalos]

I'm a *BIG* huge fan of DragonFly BSD and from everything I've seen and read, Matt Dillon and co. are fantastic coders. However, the reason why 5.x has for a long time sucked has far more to do with the fact that the FreeBSD Project bit off more than it could chew; they were adding far too many features all at one time for them to be able to do it all in a managable, and timely fashion, and not due to the loss of Matt Dillon.

SMPng (fine grained kernel locking), KSE (multi-threading the kernel, and providing both M:N and 1:1 threading for userland programs), TrustedBSD MAC Framework and POSIX ACLs, Itanium, AMD64, PowerPC and UltraSparc processor ports, GEOM and GBDE, full kernel preemption, new drivers (including a mass migration to NetBSD's BUSDMA APIs), inclusion of OpenBSD cryptographic code, a new SMP aware process scheduler (Shed_ULE), devfs, a few thousand new ports/packages and a ton of other things that I can't even remember right now were all begun around the same time, all requiring the others to be aware of the various changes that were being made all over the kernel and userland. Matt Dillon was around for at least half of that work, and even then, it was far too big a project for the FreeBSD developers to have undertaken all at one time.

Quite frankly, it was madness. Let's not forget that they also had to support the 4.x branch because it would have required one to be absolutely insane to employ 5.x in *any* mission critical tasks during most of it's lifetime. (OT: I remember when 5.0-RELEASE came out, I attempted to switch to another virtual terminal, only to be greeted with what I called the "Lava Lamp of Death," because that's what I saw on screen, and I was unable to get out of it without rebooting.)

I hold Matt Dillon in high regard, but his departure from the project was not the reason for it's woes over the last few years. Poor planning and a monsterous set of goals were the biggest reasons why it's taken so long for FreeBSD 5.x to get to where it is today.

DragonFly is not currently without it's problems either. The serializing token code will probably have to be completely replaced at least one more time (making it Matt's third attempt IIRC) because although he believes the current API to be both nice and correct, the implementation is bug-prone, having caused a number of issues that seriously impacted the stability of DragonFly in multiprocessor systems:

http://leaf.dragonflybsd.org/mailarchive/bugs/2005 -09/msg00018.html [dragonflybsd.org]

DragonFly also suffers from the lack of a proper package management system. FreeBSD 4.x ports with the dfports overrides is neither up to date, nor especially fun to make work when something breaks, and although pkgsrc is an option, not all of the most important ports (like X.org) currently build on DragonFly without a number of patches from Jörg Sonnenberger (which sadly have not yet been integrated into pkgsrc itself by the NetBSD folks), and even then (at least for me) it seems to be hit or miss.

I am not the most knowledgable person in regards to these issues; I'm not a programmer, but I read alot of documentation as well as the mailing lists for both projects, and I have used both systems over the past three years (and FreeBSD since 4.5), and I can safely say that it was not Matt Dillon's loss that was the cause of the nightmare that was 5.x until the most recent releases, but was rather due to people trying to do more in one go than was probably a good idea to have tried.

All that said, I am looking forward to both DragonFly 1.4 (which I hope will become my primary platform as overall it's bugged me far less than any other OS I've used), and FreeBSD 6.0 (despite the fact that it no longer feels "right" to me for day to day stuff anymore).

--Jeremy Almey

Re:Jump Off The Boat

[sp0rk173]

Jump off your mom before she goes under.

Re:Personal use?

[Huge Pi Removal]

Harder to install? /stand/sysinstall (run from the boot CD) is functionally identical in 4 and 5. I've installed many FreeBSD servers down the years, and I can't say I've noticed any difference with 5. You just say "yes" or "no" to the options, hit install, then spend the next few minutes digging round the ports installing what you want (and the ports system is unchanged too).

What, precisely, did you have problems with?

Re:Personal use?

[gkndivebum]

Odd. I've been a user of FreeBSD from 2.2; the 4.9 -> 5.3 transition was more or less painless for me.

Dragonfly BSD

[dshaw858]

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

Re:Dragonfly BSD

[CyricZ]

But don't forget that the core DFBSD developers were a few years back amongst the core FreeBSD developers. They include guys like Matt Dillon, who basically was FreeBSD before the split. It's no wonder that DragonFlyBSD is now becoming the premiere production BSD: all of the developers who once made FreeBSD great are now working on it! Meanwhile we see FreeBSD still struggling to produce a stable branch. It was only with the latest FreeBSD 5.4 release that many people actually considered switching over.

Like

Re:Dragonfly BSD

[Fweeky]

Well, thanks for that hugely convincing, well thought out and detailed rational argument. Which two-word reply do you think you've earned?

Please try again, preferably with less handwaving. I'd be especially interested in MySQL benchmarks, if you have them, btw.

Re:Dragonfly BSD

[CyricZ]

'Thank you' would be sufficient.

While I do not have any MySQL benchmarks to provide you (I prefer to use the far more mature PostgreSQL myself), I do agree with you that Matt Dillon is by far one of the premiere BSD developers today.

It isn't surprising to consider that his project is bound to become the server/workstation BSD of choice in the near future. After all, it is built upon his decades of operating system development experience, in addition to his raw natural talent. From the perspective of the Fre

MySQL benchmarks

[tlambert]

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

Plainer English: MySQL is broken.

[tlambert]

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

Re:Dragonfly BSD

[CyricZ]

Indeed. With the loss of Matt Dillon, Mike Smith and Jordan Hubbard, FreeBSD lost its essence. There are indeed good programmers like PHK still around, but nobody to truly lead the system into the future, as you have said. Perhaps FreeBSD will find replacements for those they have lost, but I fear by that time FreeBSD will be technically inept.

Re:Dragonfly BSD

[molnarcs]

Oh please, don't spread misinformation:

"It's no wonder that DragonFlyBSD is now becoming the premiere production BSD.." Dragonfly is nowhere near production quality yet. It may or may not be better than FreeBSD in the future, but your fanatism (earning you +5 insightful apparently) blinds has blinded you to the fact that not even its developers recommended for production use.

"Like it or not, DragonFlyBSD is bound to take the role FreeBSD has.." Seeing how Dragonfly has a different set of goals than FreeBSD, I cannot see how it would take FreeBSD's role ... provided it becomes better, which is not proven yet! This is like saying that Open~ or Net~ will take FreeBSD's role in the future! It is stupid.: "Meanwhile, systems like FreeBSD which have failed to make the transition to a far more threaded kernel design will lose the performance race." Just as silly as the rest - FreeBSD 5/6 now shows very good performance on MP systems. Last time a more or less objective comparison [bulk.fefe.de] was made, FreeBSD 5.x proved to be more scalable than 4.x - and the difference by which linux won was quite negligible, if you read the whole article. So, what you wrote is one of the silliest rants I have recently read.

Re:Dragonfly BSD

[CyricZ]

I think your inability to read English is causing you some problems here. Reread what I wrote. Notice that I used terms like "is now becoming" and "is bound to". The very nature of those phrases suggest that the event will occur in the future. You know, the "future" as in not now, but sometime soon.

FreeBSD 5 had better be more scalable than FreeBSD 4. I mean, come on. New releases are supposed to improve upon old releases! But DragonFlyBSD is being architectured to trump them all. Literally, to trump them a

Re:Dragonfly BSD

[geminidomino]

I think your inability to read English is causing you some problems here. Reread what I wrote. Notice that I used terms like "is now becoming" and "is bound to". The very nature of those phrases suggest that the event will occur in the future. You know, the "future" as in not now, but sometime soon.

Err.. I think his problem is more like mine; that is, an inability to trust in your clairvoyance. "Is bound to" suggests a definite future. I guess "Nostradamus" was taken as a slashdot ID, eh Miss Cleo?

And for t

Re:Dragonfly BSD

[CyricZ]

The phrase "is now becoming" obviously suggests that DFBSD is not, as of now, the premiere BSD. But in time (ie. the future!) it will take the place of FreeBSD as the general purpose BSD of choice.

Doubt me all you want. The fact remains that the quality, usability, reliability and overall development of FreeBSD is seriously lacking these days. That is because the project no longer has the talents of an individual like Matt Dillon. Consequently, there is strong reason to believe that a project lead by Matt D

Re:Dragonfly BSD

[nacturation]

The phrase "is now becoming" obviously suggests that DFBSD is not, as of now, the premiere BSD.

To join in on the pedantry, "is now becoming" suggests a definite transformation which is already underway. For example, if you had the phrase "Linux is now becoming the dominant server platform for web services", that doesn't suggest that perhaps in the indefinite future it's a possibility. Rather, it suggests a definitive trend which, if it continues, will make Linux the dominant platform.

You would need to add

Re:Dragonfly BSD

[geminidomino]

Seeing as I'm correct on this issue...

Hey, John Edward, what are next weeks lottery numbers?

Re:Dragonfly BSD

[nacturation]

Oh, and for some objective reference: [okccc.edu]

"Present progressive (also called present continuous) tense indicates an action that is happening at the time it is written or spoken about. Present progressive is formed with am, is or are plus the present participle.

The crowd is looking up at a man standing on the ledge of a tenth story window.

Law is becoming an overcrowded profe

Re:Dragonfly BSD

[Eivind Eklund]

I'll note that your behaviour is *negative* influence when it comes to DFBSD achieving that goal.

Also, with all due respect to Matt, there are a LOT of others doing FreeBSD work, and while he is definately talented, he has never contributed anywhere near the same amount of code as all others combined.

As for problems with FreeBSD development: There have been some, and there's some that's resolved, and I definately welcome DFBSD to the table. It (fortunately) seems like it will be viable. Whether it wil

Not really

[JamesTRexx]

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.

Re:Not really

[Nimrangul]

There have been plenty of forks that didn't do that though, almost all the forks have been so completely out of the 3 main BSD's league that they've been ignored. This is different for DragonFly BSD because it s run by Matt Dillon, the guy's got skill and determination - and I suppose enough money that he doesn't need to work too much to eke out a living.

DragonFly BSD's not been around as long as MirOS or many other projects, but it's got someone that knows what they're doing in charge, someone that would be doing it even without anyone else working with him.

Because of who started it and why DragonFly BSD has had an easy edge over the others, that is why it has become the fourth over time - but it did not start out as a full-blown contender, this took time.

4 Main?

[Johnny Mnemonic]

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?

Re:4 Main?

[Anonymous Coward]

OS X is not a BSD distribution, nor is OpenBSD, NetBSD, DragonFly BSD, FreeBSD or FlyingWang BSD. Each BSD is it's own operating system, not that mangled mess that is used to refer to a Linux-based operating system.

Also, OS X contains BSD code, it is not based on BSD - it is based on OpenStep, which contained BSD code as well. Google's your friend.

Re:4 Main?

[drmerope]

It would be more precise to say that it is based on Mach code and BSD code--especially the FreeBSD userland.

However, substantial work went in during the NeXT era and subsequently from Apple directly.

This is a minor quibble with the meaning of "based" as you use it.

OSX is decidedly not a BSD variant though--most notably it is not developed under a BSD license.

As a point of fact, Windows is BSD based because microsoft forked their tcp stack off an early BSD one...

But we can still distinguish it as being in another class entirely.

Re:4 Main?

[CoolVibe]

OS X isn't really BSD, because the kernel isn't a traditional BSD kernel, it's a Mach hybrid. The only thing that OSX inherited from FreeBSD (and others) are parts of the userland.

OSX and FreeBSD are actually quite dissimilar. I wish people would realise that not anything that is thought up for FreeBSD (like the Dtrace thing last couple of weeks) can be easily ported over to Darwin/OSX. They are two completely different beasts.

Re:4 Main?

[CoolVibe]

Sure, just like OpenBSD, NetBSD and DragonFly (for example) have FreeBSD kernel bits. That doesn't make them FreeBSD. The BSD's use each other's kernel code for stuff like bugfixes, drivers and what not. A good example is for instance DragonFlyBSD which has NetBSD's USB stack. That's kernel code. But that doesn't make DragonFlyBSD a NetBSD derivative.

Re:FreeBSD for Snort Box.

[SillyNickName4me]

Probably because quite some of the people involved with snort run FreeBSD..

obligatory missing option

[messju]

I'm missing CowboyNeal in almost every question.

A quick peek...

[Foozy]

All data below is preliminary:

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 [bsdcertification.org].

Thanks to everyone who filled out the survey!

Of course (i.e., common sense)

[WebHostingGuy]

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.

Re:Of course (i.e., common sense)

[eneville]

> I am surprised by how high OpenBSD and NetBSD is.
> I would have initially thought it would be lower.

OpenBSD is very good for firewalls, the pkgs are vetted carefully and the team do a great job in keeping it as secure as possible. FreeBSD is more desktop orientated these days from what I can tell, and this makes it a little less appealing to those who just want a firewall and nothing else.

Kool-aid gargle

[relaxrelax]

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...