Slashdot Mirror


Dragonfly BSD 3.2 Released

An anonymous reader writes "Dragonfly BSD recently announced the release of version 3.2 of their operating system. Improvements include: USB4BSD, a second-generation USB stack; merging of a GSoC project to provide CPU topology awareness to the scheduler, giving a nice boost for hyperthreading Intel CPUs; and last but not least, a new largely rewritten scheduler. Some background is in order for the last one. PostgreSQL 9.3 will move from SysV shared memory to mmap for its shared memory needs. It turned out that the switch much hurts its performance on the BSDs. Matthew Dillon was fast to respond with a search for bottlenecks and got the performance up to par with Linux."

85 comments

  1. Yes, but by Anonymous Coward · · Score: 1

    have they fixed the ssh port bug? They've ignored it for years.

    1. Re:Yes, but by Anonymous Coward · · Score: 1

      It's not a bug, it's a feature.

    2. Re:Yes, but by Anonymous Coward · · Score: 0, Redundant

      He is talking about the ssl port bug.

    3. Re:Yes, but by Anonymous Coward · · Score: 1

      THE ssl port bug. How many ssl port bugs have there been. You could easily find it.

    4. Re:Yes, but by Anonymous Coward · · Score: 0

      THE ssl port bug. How many ssl port bugs have there been. You could easily find it.

      Link to the bug report or you are full of $hit and no such bug exists or ever existed.

    5. Re:Yes, but by Anonymous Coward · · Score: 0

      THE ssl port bug. How many ssl port bugs have there been. You could easily find it.

      Link to the bug report or you are full of it and no such bug exists or has ever existed.

    6. Re:Yes, but by Anonymous Coward · · Score: 0

      There indeed is a bug. Everyone knows about the famous SSL port bug.

    7. Re:Yes, but by Anonymous Coward · · Score: 0

      THE SSL port bug. The bug to life, the universe, and everything!

    8. Re:Yes, but by Yebyen · · Score: 1
      --
      Restating the obvious since nineteen aught five.
  2. "got the performance up to par with Linux" by Anonymous Coward · · Score: 0

    Wouldn't "got the performance up to par with RedHat 2.6.32-220.el6" be a *tad* less misleading?
    Yes. 2.6. Really.

    1. Re:"got the performance up to par with Linux" by Anonymous Coward · · Score: 1

      I think the main point is the near linear scalability curve for both Scientific Linux 6.2 and DragonFlyBSD which shows how far DragonFly has gone in the last 2 years, the team of developers is tiny. Sure Linux performance might have improved 10% since then, but it might also only be 2% or -2% ON THIS TEST, while other BSDs are sucking the dirt.

    2. Re:"got the performance up to par with Linux" by Anonymous Coward · · Score: 0

      Is this actually reproducible?

    3. Re:"got the performance up to par with Linux" by aliquis · · Score: 1

      Since the attached PDFs to his post contain the benchmarks he ran I'd say yes.

    4. Re:"got the performance up to par with Linux" by blade8086 · · Score: 1

      The plots are based off of 3-run averages, all on the same hardware.

      A good portion of the tuning was done against this same hardware as a reference platform, doing the same test,
      with consistent results (plus improvements) across the development cycle.

  3. Too many dimwits by fnj · · Score: 1, Insightful

    16 posts and every fucking one of them is an anonymous fucking coward dipshit.

    1. Re:Too many dimwits by ArchieBunker · · Score: 4, Insightful

      Because this site is a giant linux circlejerk. I remember the good old days when FreeBSD ran linux binaries faster than linux itself.

      --
      Only the State obtains its revenue by coercion. - Murray Rothbard
    2. Re:Too many dimwits by Anonymous Coward · · Score: 0

      Indeed.

    3. Re:Too many dimwits by footNipple · · Score: 1, Funny

      You forgot leftist! A Linux and Leftist circle jerk. Why am I still here? I guess I'll always check in.

    4. Re:Too many dimwits by Anonymous Coward · · Score: 0

      It's still better than reddit's /r/programming, or HN, or Stack Overflow. I'd much rather ignore a few "Eat my butt."-style comments here than deal with an endless stream of Ruby on Rails "programmers" spewing their misogynist bullshit, or reading about "entrepreneurs" bragging about their shitty web startups, or seeing yet another blatantly incorrect "answer" from some fool in India.

    5. Re:Too many dimwits by Anonymous Coward · · Score: 0, Troll

      It still does.

    6. Re:Too many dimwits by Anonymous Coward · · Score: 0

      Reality does not have a political affiliation.

    7. Re:Too many dimwits by Anonymous Coward · · Score: 0

      Here's a fun fact, how many countries that have imploded haven't imploded? Or, how do you account for China and Scandanavia not yet imploding? By your reasoning, they much not be much into dependence on the government, oh, wait...

    8. Re:Too many dimwits by kdemetter · · Score: 1

      "Reality" only exists in our imagination.

    9. Re:Too many dimwits by Anonymous Coward · · Score: 1

      Unless "reality" happens to coincide with reality.

    10. Re:Too many dimwits by Anonymous Coward · · Score: 0

      You do realize that it's white people who use welfare the most, right? We got to keep you rednecks able to feed yourselves.

    11. Re:Too many dimwits by Anonymous Coward · · Score: 0

      I'm an eqaul oputunitist circle jerk since I prefer using both hands.

    12. Re:Too many dimwits by Anonymous Coward · · Score: 0

      I'll stop being Liberal when the Republicans stop wearing diapers.

    13. Re:Too many dimwits by wdef · · Score: 1

      Slashdot should delete crap posts. I agree Slashdot has gone way downhill and it's mystifying where all these cretins and imbeciles come from or why they bother posting here at all. Slashdot needs to work an algorithm that identifies and deletes crap posts eg any post that simply says "Eat my butt" is auto deleted. All posts modded -1 should be auto evaluated for deletion as well.

    14. Re:Too many dimwits by Anonymous Coward · · Score: 0

      I know right-wing libertarians. I'm a left-leaning libertarian. The word means more than its popular degenerate usage in the US.

  4. my experience with dragonfly 3.0 by Anonymous Coward · · Score: 5, Informative

    1) hammer is beyond awesome, it's inspired. you owe it to yourself to live with dragonfly for a week or two for this reason alone.
    2) the whole thing is pretty freaking snappy compared to freebsd (which itself is no slowpoke)
    3) hardware support is patchy, you might need to hang onto that old nic/sas/raid card
    4) linux emulation is not supported when running a 64-bit dragonfly system
    5) otherwise, it's just like any other sane BSD.

    my job forces me to run binary only linux crap so 4) rules out a wholesale move to dragonfly, but IMHO it is the BSD of choice for anyone with enough platform independence to seriously consider a BSD in the first place.

    1. Re:my experience with dragonfly 3.0 by Anonymous Coward · · Score: 0

      hardware support is patchy ...and that right there has been my experience with all BSD flavours, which is why I couldn't be bothered with BSD in general. I simply don't have the time or energy to constantly fuck around trying to get a simple NIC to work.

      sorry, bye bye BSD.

    2. Re:my experience with dragonfly 3.0 by Anonymous Coward · · Score: 1

      Thanks, this sums it up quite well. Id like to add that swapcache is pretty awesome, too.

      Also I think that DFBSD is one of the very few open source OS projects worth watching closely. They
      not only innovate, but still manage to keep a clean bsd OS. And while being small they are a very nice
      and helpful community.

      Way to go DFBSD!

    3. Re:my experience with dragonfly 3.0 by aliquis · · Score: 2

      But the Linux people got btrfs so HAMMER and ZFS isn't all that much to long for any more.

    4. Re:my experience with dragonfly 3.0 by nikolas · · Score: 2

      while many features of ZFS (and Hammer) are included in btrfs too, Hammer (specifically Hammer 2) has design goals that go way beyond those of ZFS (I believe it is going to be a fully fledged cluster FS). So there is something to wait for.

      And I am still hoping that theiy will pursue their single-system-image design goal eventually.

    5. Re:my experience with dragonfly 3.0 by Anonymous Coward · · Score: 0

      If you think btrfs is anywhere near ZFS, you have no idea what you are talking about. And yes, I have used both extensively.

    6. Re:my experience with dragonfly 3.0 by aliquis · · Score: 1

      The problem with anonymous cowards is that there really are no reason to answer because your answer may never be noticed anyway. You're just wasting your time.

      And no, I don't have extensive knowledge of either. I know they both do snapshots for instance and I know btrfs perform well. Whatever former Sun or Oracle can find a specific setup where ZFS beats btrfs is beyond me but I've never really trusted Suns benchmarks anyway. They feel just as useful as Apples to me.

    7. Re:my experience with dragonfly 3.0 by aliquis · · Score: 1

      What does single system image design mean?

      I only really followed DragonflyBSD early and I know their focus has been towards multi core and clusters from the beginning. I guess for me personally the point is rather that I thought ZFS was cool but I use a desktop machine and by now I could use btrfs and get about the same effect so by now Solaris, FreeBSD or Linux doesn't matter much for me in that regard. Or well, DragonflyBSD in this case :)

      It's always interesting to read about it though. (And I think it would had been interesting to read and get to know more about QNX to. Where is it going today? Thoms latest blog post was about how the Nexus 4 and 10 was ugly. I can see how that is a problem when you're talking about the OS side of your devices. Not.)

    8. Re:my experience with dragonfly 3.0 by nikolas · · Score: 2

      SSI would be when multiple connected computer running an instance of, say, dragonfly bsd, can act like a single (multi-user and multi-tasking) computer. Tasks will migrate to any processor core in the cluster (and ideally factor in the cost of migration over network).

      Similar to what openmosix did for linux ages ago - and very different from the infamous beowulf cluster.

      By the way - Hammer does not only do simple snapshots but it does them automatically in intervals. So if you use it with samba or nfs you get sort of an instant apple time-machine workalike - albeit with deduplication and all. Only disappointment for me was that trying it in a VM was not really going well - you need a spare PC for that.

      Yeah, OSnews has mostly become a mobile website, but I still enjoy it more than Slashdot nowadays.

    9. Re:my experience with dragonfly 3.0 by Anonymous Coward · · Score: 0

      I guess what he was referring to is stability. Before btrfs is where ZFS is now some 5 years will pass, at least.
      There was this ext4 bug recently. Don't remember what the exact circumstances of it where, but IIRC it boils down to CATASTROPHIC filesystem damage if you shut down or reboot your system while a lazy umount is still hanging in the background. Think of USB hard disks which you might umount with the lazy argument, and you risk losing it all.

      When have you heard such horrific stories the last time with other OS than Linux?

      Don't get me wrong, I'm a sysadmin by trade, and have been running Linux since 1997. But for my servers at home it isn't an option. On them I like the BSD "POLA" policy - "path of least astonishment". And hence their stability.

    10. Re:my experience with dragonfly 3.0 by aliquis · · Score: 1

      But ZFS snapshots every modification and got de-duplication to?

      Though from people in say #pcbsd or whatever it's called it seem like the memory requirements for using de-dup is massive?

      btrfs doesn't snapshot the whole time but just when you tell it to?

      The idea for me was to switch this usb flash drive to btrfs since zypper doesn't have the undo feature of yum but it can do undos using snapshots if you use btrfs.

      I guess the yum alternative may be safer for your data though.

      Guess I'm going away from the subject. But it would be interesting to hear how the memory requirements are of HAMMER using various features and compared to ZFS on Solaris or FreeBSD.

    11. Re:my experience with dragonfly 3.0 by siDDis · · Score: 1

      Hammer can do deduplication with minimal memory requirements. For example only 512MB ram would still give a responsive and fast system. Hammer deduplication doesn't take a hard hit on performance like ZFS does, as ZFS dedup data in realtime while Hammer does it with a CRON job.

    12. Re:my experience with dragonfly 3.0 by aliquis · · Score: 1

      On the other hand just think about how much better dd if=/dev/zero of=file bs=1048576 count=10240 would perform on ZFS?!

      (Or maybe not, what do I know?)

    13. Re:my experience with dragonfly 3.0 by Anonymous Coward · · Score: 0

      It's probably a good idea for you to remain anonymous, so no one knows who the moron is that can't click "Use DHCP" during the installer.

    14. Re:my experience with dragonfly 3.0 by Anonymous Coward · · Score: 0

      It's probably a good idea for you to remain anonymous, so no one knows who the moron is that can't click "Use DHCP" during the installer.

      Not the same AC, but assuming the AC you're referring to has run into the same issues with NICs I have, a bit more bloody fundamental than hurr-durr-I-knows-not-what-files-to-edits-so-lets-get-an-IP-number-from-a-DHCP-server type issues, more like fuck-me-why-isnt-the-card-even-working type issues, reread the comment and digest the hardware support is patchy bit.

      And this is coming from someone who has used various flavours of BSD for a long time (first NetBSD install was 0.9), of the four machines currently sitting in front of me as I type, only one of them has a fully supported NIC under any of the flavours of BSD I've tried, which is why they're all running Linux at present. Much as I like the *BSDs, I need the machines to work reliably with the minimum amount of faffing around. I do have another machine in the house which runs multiple *BSDs, but it's a wee bit older, by about half a decade or so.

    15. Re:my experience with dragonfly 3.0 by Anonymous Coward · · Score: 0

      CATASTROPHIC filesystem damage if you shut down or reboot your system while a lazy umount is still hanging in the background

      The initial diagnosis was wrong. Fortunately the bug only affects rare mount options:

      http://lwn.net/Articles/521860/

    16. Re:my experience with dragonfly 3.0 by Anonymous Coward · · Score: 0

      Stop using Broadcom and get Intel, which has great BSD support.

    17. Re:my experience with dragonfly 3.0 by blade8086 · · Score: 2

      Don't buy a shitty nic, and RTFM before buying hardware?

      You know - kind of like how Linux still is for some hardware, and definately used to be?

    18. Re:my experience with dragonfly 3.0 by blade8086 · · Score: 1

      Hammer linear write performance is pretty good, since it is somewhat akin to a log-structured filesystem.

    19. Re:my experience with dragonfly 3.0 by Anonymous Coward · · Score: 0

      This is simply parroting of anecdotes, which seems to be a very popular pass-time for BSD advocates. There is no analysis, not even any evidence. Simply assertions, and obvious logical fallacies.

      Where is your evidence that some BSD operating system is more stable than a particular Linux one? If your answer starts with "one day I", or "some guy I know", etc. then you are a nincompoop.

      If you think that no BSD operating system has bugs, or they don't have data corruption bugs, or they don't have security bugs, you are a nincompoop.

    20. Re:my experience with dragonfly 3.0 by Eunuchswear · · Score: 1

      Similar to what openmosix did for linux ages ago

      No, similar to what OpenSSI did for Linux years ago.

      openmosix was much less SSI.

      --
      Watch this Heartland Institute video
  5. Re:Does it support HOST file? by Anonymous Coward · · Score: 0

    No he just accidentally the everything.

  6. Re:Does it support HOST file? by Anonymous Coward · · Score: 0

    Hello -1 AC troll (aka apk)

  7. Re:Does it support HOST file? by Anonymous Coward · · Score: 0

    Hello -1 AC troll (aka apk)!

  8. Was Dillon right in SMP/threading vs FreeBSD 5+ ? by Anonymous Coward · · Score: 0

    So now looking back, was Dillon's approach & implementation of SMP/threading better thanks FreeBSD 5+ ... Which you'll recall was the reason for Dillon creating DrafonflyBSD.

  9. Ahh, the irony... by K.+S.+Kyosuke · · Score: 1

    BSD-style shared memory via mmap is slower on BSDs than SysV shared memory on the same system? Ah, the irony...

    --
    Ezekiel 23:20
    1. Re:Ahh, the irony... by nikolas · · Score: 1

      Do enlighten me - where can I read up on this (shmem on dragonflybsd being slower than SysVshm)?

    2. Re:Ahh, the irony... by K.+S.+Kyosuke · · Score: 1

      The point is, I didn't know, the summary claims it.

      --
      Ezekiel 23:20
    3. Re:Ahh, the irony... by Anonymous Coward · · Score: 0

      There's quite a bit in the links included in the summary.

      Anyway, the main problem, as I understand it, is that accessing mmapped memory causes way too many page faults for Postgres's access patterns. Most BSDs implemented a "sup" hack that kept SysV shared pages in memory, but after the switch it will be worthless. Quoting from a commenter on Robert Haas's blog:

      There is a serious problem with this patch on BSD kernels. All of the BSD sysv implementations have a shm_use_phys optimization which forces the kernel to wire up memory pages used to back SysV segments. This increases performance by not requiring the allocation of pv entries for these pages and also reduces memory pressure. Most serious users of PostgreSQL on BSD platforms use this well-documented optimization. After switching to 9.3, large and well optimized Pg installations that previously ran well in memory will be forced into swap because of the pv entry overhead.

  10. Re:Was Dillon right in SMP/threading vs FreeBSD 5+ by Anonymous Coward · · Score: 0

    It will be interesting what FBSD and NBSD will do in response. One of Dillon's claim was that the implementation of SMP in FBSD 5+ is too complicated and will be inefficient. I'm genuinely surprised by FreeBSD's apparent lack of scalability in this test. My impression was that they are very performance oriented and should be "up there" with Linux.

  11. Re:Does it support HOST file? by Anonymous Coward · · Score: 0

    Hang on, the apk who is always on about hosts files?

  12. Re:Was Dillon right in SMP/threading vs FreeBSD 5+ by laffer1 · · Score: 1

    If you were to look at benchmarks from a few years ago, FreeBSD blew out DragonFly on PostgreSQL testing. They've made real ground here, but it was a lot of work and it was only evaluated here against one application. PostgreSQL runs very well on the same core as it's a per CPU per connection setup. I believe the results but I do question if all applications would improve this much. The results are also very specific to the number of concurrent connections because the scheduler win goes away if there are many and a lot of context switching is happening.

    Let's look at where the numbers are coming from:
    1. Scheduling is a big difference in this benchmark.
    2. Compiler version. Comparing recent linux distros to dragonfly is fair because they've been using GPLv3 binutils and GCC. They actually update it. FreeBSD has been migrating to LLVM. Newer GCC versions have been shown in several benchmarks to be 10% faster or so from what FreeBSD is using.
    3. Improvements in system call overhead in dragonfly. They use a different setup for system calls (message passing) in DragonFly and much work has gone into making it not behave as crappy as most message passing systems like OS X. I mention this only as a comparison to DragonFly versions from several years ago.
    4. File system differences. HAMMER vs UFS2. It's a fact that different file systems have huge effects on PostgreSQL performance. Different tuning options for the file system and PG are also important here.

  13. drivers & DHCP? by unixisc · · Score: 1

    If the OS can't read your network card, how does DHCP help @ all? DHCP is only of use when your driver works, and it's a case of getting an IP address if you don't have one assigned already.

  14. sigh by xuvetyn · · Score: 1

    when's BSD gonna develop a (decent) desktop distro?!

    --
    alive to the universe, dead to the world
    1. Re:sigh by smash · · Score: 1

      PC-BSD.

      --
      I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
  15. Re:Was Dillon right in SMP/threading vs FreeBSD 5+ by Anonymous Coward · · Score: 0

    Re 4): It's been all-in-memory tests with pgsql on dragonfly