BSD Usage Survey 74
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.'"
Dragonfly BSD (Score:4, Interesting)
Kudos to the Dragonfly BSD team!
- dshaw
Not really (Score:4, Interesting)
Re:Personal use? (Score:4, Interesting)
4 Main? (Score:4, Interesting)
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:Personal use? (Score:3, Interesting)
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? (Score:5, Interesting)
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:The loss of Matt Dillon hurt FreeBSD 5. (Score:5, Interesting)
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/200
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
MySQL benchmarks (Score:4, Interesting)
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