6 ms·

DragonFly BSD 6.4

82 points by lelf 4y ago

amalgamated_inc 4y ago
Can somebody explain the niche or role of Dragonfly BSD? I'm only vaguely familiar with BSDs. So far my impression is that OpenBSD is the secure one, FreeBSD is the fast one (for servers). What's DragonFly good at?
- bmacho 4y ago
  I don't think it has a niche or role anymore. Some years ago they claimed to be fast. [0,1,2] I don't know where did you get that FreeBSD is regarded as the fast one. I think it is considered the popular/general purposed one, without a single aim like openBSD or netBSD have. [0] : https://www.dragonflybsd.org/performance/ https://www.dragonflybsd.org/performance/ [1] : https://www.dragonflybsd.org/features/ https://www.dragonflybsd.org/features/ [2] : https://www.dragonflybsd.org/history/ https://www.dragonflybsd.org/history/
  - amalgamated_inc 4y ago
    Maybe just cause allegedly Netflix uses it for servers.
    - mistrial9 4y ago
      see https://news.ycombinator.com/item?id=28584738 https://news.ycombinator.com/item?id=28584738
    - nix23 4y ago
      >allegedly Netflix uses it for servers Not really "allegedly" as you can read here: https://openconnect.netflix.com/en/appliances/#software https://openconnect.netflix.com/en/appliances/#software
  - loeg 4y ago
    FreeBSD focuses on performance moreso than Net or OpenBSD.
  - nix23 4y ago
    >Some years ago they claimed to be fast. It is fast, maybe the fastest of all BSD's: https://www.phoronix.com/review/bsd-linux-eo2021/2 https://www.phoronix.com/review/bsd-linux-eo2021/2
    - bmacho 4y ago
      You are right, it seems much faster than freeBSD in a lot of areas and relevant benchmarks (real world programs and scenarios). They got similar overall results, but as far as I see, freeBSD is mainly faster in irrelevant benchmarks. (This is an opinion based on a glance of the phoronix article. I haven't spent much time looking at the results, also I am not an expert at benchmarking.)
      - nix23 4y ago
        I mean it's just impressive for such a small project, and benchmark's...well they just count for your very own workload..it's good to find regressions but not much else. BTW i run FreeBSD ;)
- nortonham 4y ago
  I always thought it was centered around the HammerFS.
  - sidewndr46 4y ago
    Based on the Wikipedia page, HammerFS does basically everything.
    - abudabi123 4y ago
      Would be interesting to know the hardcore performance benchmarks for memory handling, comparing Darwin, Linux, Dragonfly and sw-engineer's aesthetics.
- Koshkin 4y ago
  From Wikipedia: Intended as the logical continuation of the FreeBSD 4.x series, DragonFly has diverged significantly from FreeBSD, implementing lightweight kernel threads (LWKT), an in-kernel message passing system, and the HAMMER file system. Many design concepts were influenced by AmigaOS.
- j16sdiz 4y ago
  Scalability. filesystem designed with cluster in mind (Just the design - the implantation still experimental). Process checkpointing. etc
- todd8 4y ago
  First two paragraphs of History section found on DragonFly web site[1]: > A technical introduction: The ultimate goal of the DragonFly project at its inception was to provide native clustering support in the kernel. This type of functionality requires a sophisticated cache management framework for filesystem namespaces, file spaces and VM spaces. These and other features eventually culminate in the ability to allow heavily interactive programs to run across multiple machines with cache coherency fully guaranteed in all respects. This also requires being able to divide resources, including the CPU by way of a controlled VM context, for safe assignment to potentially unsecured third-party clusters over the internet. This original design direction, although no longer the primary goal of the DragonFly project, has influenced many of the design decisions made in the intervening years. While full cache coherency is no longer a top level goal, filesystem coherency is, and that direction continues to guide the project in a number of ways. > DragonFly BSD was forked from FreeBSD 4.8 in June of 2003, by Matthew Dillon. The project was originally billed as "the logical continuation of the FreeBSD 4.x series", as quoted in the announcement, but this description has long since become obsolete. From a performance perspective DragonFly's only real competitor these days is Linux. [1] https://www.dragonflybsd.org/history/ https://www.dragonflybsd.org/history/
  - amalgamated_inc 4y ago
    Yea, I checked the about section of the website a bit and honestly didn't get it :) Not familiar with most of the terms.
    - jasonwatkinspdx 4y ago
      Roughly the original idea was similar to https://en.wikipedia.org/wiki/Single_system_image https://en.wikipedia.org/wiki/Single_system_image That is, make a cluster of machines look like a single BSD instance, by allowing virtual memory to span multiple machines, processes to move, etc, all while preserving cache coherency. Obviously this is an insanely difficult goal, which is why DragonFly didn't make it particularly far towards it. Additionally we've seen the rise of virtualization and systems like k8s for managing clusters, which would reduce interest from potential collaborators.
- maegul 4y ago
  Perhaps a bit too scandalous (I don't know), but my understanding is that there was also a falling out of sorts between the DragonFly lead and BSD people, largely caused by allegedly abusive behaviour form the DragonFly lead while they were still working on BSD main. As I understand it, DragonFly came after this. Maybe doesn't answer your question, but it contextualises (however accurately!) part of how it came to be. My source on that is a LinuxConfAU talk I can't recall off the top of my head (the same speaker gave a somewhat notable talk in defence of SystemD)
  - nix23 4y ago
    Benno Rice -> "The Tragedy of systemd" OR "The Trouble with FreeBSD" I am a bit torn apart about him, he's half right half wrong, anyway it's good to have discussions like that.
- mtlmtlmtlmtl 4y ago
  Originally it was planned to be a distributed OS. The main reason for the fork from FreeBSD was disagreement about what the threading primitives and their semantics should be, IIRC. One major early goal was cache coherency between different machines, though that seems to be abandoned or indefinitely on hold. Other projects have been HammerFS(a filesystem similar to ZFS, and I believe it started before ZFS was ported to FreeBSD), moving more towards a microkernel approach, and dropping support for all platforms other than x86_64. This makes the implementation of things like threading much simpler. In short, DragonflyBSD is Dillon's experimental OS with ideas he would never be able to get into FreeBSD. It's never really found a niche for production use as far as I can tell, but I'd love to be proven wrong on that. Source: FreeBSD user of several years either as a server OS, workstation OS or both. And I've dabbled with Dragonfly and love reading about obscure unices and their quirks.
  - amalgamated_inc 4y ago
    > FreeBSD user of several years either as a server OS, workstation OS Oh, could you give a bit of an overview of the State of FreeBSD on the Desktop (or laptop)? I'm playing with the idea. Tried OpenBSD for a while but it just wasn't very consumer-ready. No bluetooth support at all, videos would have audio and video lag, and other issues. Is FreeBSD more suited to daily consumer laptop use? I use Arch btw
    - mtlmtlmtlmtl 4y ago
      It's been a couple years since I daily drove FreeBSD on, my desktop/workstation and I never ran it on a laptop. Still chugging along on my home built NAS(read: shitty old tower with a bunch of disks in it) though. I switched over from Arch on the desktop for a couple years at one point, and overall I was very happy. The FreeBSD project is still going strong, and they've been greatly improving their Linux syscall compat layer the last few years. ZFS support is great. It's perfectly viable as a desktop OS if you're experienced with Arch and you don't use a lot of weird hardware or software. What I did when switching was just to install it and start slowly rebuilding my Arch setup as much as possible. It's a fun weekend project with some patience, and you'll quickly find what the pain points might be that way.
- rubyfan 4y ago
  I was an OpenBSD and FreeBSD user at that time DragonFly was announced so I remember the original fork. Improving SMP (or SMP at all) was a thing a few of the BSDs were working on around this time as I believe processors were starting to add hyper-threading. I think that was the core rationale for the fork but Matt Dillon had a few other things he was trying. There have been a few similar forks like this where someone wanted to go their own way some with better success than others. See Annoucning DragonFly BSD! https://lists.freebsd.org/pipermail/freebsd-current/2003-July/006889.html https://lists.freebsd.org/pipermail/freebsd-current/2003-Jul... Further reading https://people.freebsd.org/~kuriyama/www/smp/ https://people.freebsd.org/~kuriyama/www/smp/ https://people.freebsd.org/~fsmp/SMP/SMP.html https://people.freebsd.org/~fsmp/SMP/SMP.html
- 0x457 4y ago
  Dragonfly BSD is very good at being bad at taking constructive feedback /s It was born out of disagreement about how SMP should work in FreeBSD around Northwood P4 era (first HyperThreaded consumer CPU). Around that time, every general purpose OS as absolutely horrible at utilizing more than one logical cores. FreeBSD first gained SMP support at 5.0, and it was actually usable at 5.2. DragonFly BSD author had a disagreement how to implement it and though 5.x direction is bad, so, IIRC, he forked 4.x line and implemented his own vision from there. Then it was "FreeBSD does it, so I'm going to do it differently", at least that's how it looks from an outside perspective. So, it's good at SMP if we're going by that outdated classification of BSD systems.
  - alberth 4y ago
    A lot of people would consider FreeBSD 5.x a horrible release (especially given how rock solid 4.x was), and things not stabilizing again until 8.x (many years later). Some would argue that in hindsight, Matt was correct at the time for the fork - from a technical standpoint.
    - 0x457 4y ago
      Oh, I know. I suffered the entire way to 8.0. Until 5.2 it was completely unusable. I also remember unplugging or plugging USB device would often lead to kernel panic until 9.0 IIRC. I agree that he was correct at the time. Likewise, I do wish that split never happened, though.
      - alberth 4y ago
        > * I do wish that split never happened* I too wish the split hadn’t happened, and for Matt’s ideas to have landed in FreeBSD. Dragonfly today is remarkable, still competing head to head with FreeBSD 15 years later but with a development team literally 1/50th the size.
        loeg 4y ago
        FreeBSD doesn’t have 50 active core developers so it’s hard to imagine how Dragonfly could be 1/50th the size.
- somat 4y ago
  My impression(i only really use openbsd) Freebsd has the most developer resources and tends to be good at optimizing for speed but the userland always feels, it is hard to explain, but off, if you are fine with with the linux userland this will be a step up, openbsd, a step down. It has very good zfs integration and that is a solid reason for using it alone. Netbsd just sits in the corner doing their own thing, I am not sure what that is but I suspect if I had not fallen for openbsd I would be using netbsd. A good solid small OS. Dragonfly has an incredible main developer who has strong views about how parallel systems should be structured and the programing chops to pull it off. If you can take using a system with absolutely minuscule developer resources you will find real gems here, an amazing filesystem and very good multiprocessor support. Openbsd strives for correctness above all else, speed tends to be a second class citizen, that is, if the developers have to make a choice between a simple obviously correct solution and a messy but quick one, they will almost always go for the simple one. speed is fine but not at the expense of readability. the system is probably the most full featured. With an emphasis on network daemons. but limited developer resources keep everything simple. I think of it as the best desktop system due to it's ease of administration and excellent ports system.
  - nortonham 4y ago
    >Netbsd just sits in the corner doing their own thing, I am not sure what that is but I suspect if I had not fallen for openbsd I would be using netbsd. A good solid small OS. Portability, pkgsrc, some neat innovations, and a small and welcoming community. I'm not qualified to judge this, but they also value code quality and security.
- loeg 4y ago
  DragonFlyBSD is Dillon’s FreeBSD. It’s a fork because of personality disagreements between Dillon and other developers in the FreeBSD 5.0 timeframe. It does some interesting experimental stuff like HammerFS but isn’t really suitable for general use.
  - nix23 4y ago
    >but isn’t really suitable for general use. Can you tell me why? Because i used it for 3 years regularly in a professional setup (~10 servers). Never had a problem with hammer 1 or 2 or anything else.
- rektide 4y ago
  The original plan was a SSI, single-system-image operating system, where one cohesive system could span across multiple physical machines. It's quite a long ambitious plan, but it's still up on the project's history page[1]: > DragonFly BSD has been going through rapid and ever increasing development since the fork. One of the important works included the simplification and general cleanup of the majority of the kernel subsystems. This work was originally intended to support single system image clustering, but has had the effect of making the kernel much more reliable, understandable and easily maintainable. One of the fundamental synchronization concepts that DragonFly uses throughout the kernel, the token, lends itself directly to ease of maintenance and understandability of the kernel. There's been plenty of neat off-shoot advantages DragonflyBSD has gained along this quest. Great great scalability has been notable; the core coherency construct, the serializing token, targets reducing locking in the system & potentially allows scale-out into SSI. DragonflyBSD has some really cool tricks, like being able to run virtual kernels- running a kernel as a process, for "jail" or just kerneldev reasons. Still it's impossible to mention DragonflyBSD without mentioning it's filesystem, HAMMERFS, and now HAMMERFS2, which is a great Copy-on-Write & snapshotted fs intended for radical scale out, & ultimately, clustering, where multiple machines can cohesively contribute & operate a single filesystem together, with pooled resources. There is already a good bit of quorumed clustering support in HAMMERFS2. > The HAMMER filesystem is also intended to serve as a basis for the clustering and other work that makes up the second phase of the project. There's a StackOverflow question talking to DragonflyBSD as a SSI[2] as well, which mainly cites the same History page, but also has some other links. [1] https://www.dragonflybsd.org/history/ https://www.dragonflybsd.org/history/ [2] https://unix.stackexchange.com/questions/429464/dragonfly-bsd-purpose-myth-one-os-on-several-physical-machines https://unix.stackexchange.com/questions/429464/dragonfly-bs...
- lproven 4y ago
  I am a bit of a BSD outsider, but I've been exploring them recently. I'd say it's more like: • NetBSD – the oldest, aims at the widest platform support • FreeBSD – next oldest, aims at modern hardware, best hardware and desktop support, native ZFS. • OpenBSD – a bit younger, aims at correctness and security, so very basic hardware support, e.g. no Bluetooth at all. But that means it supports some of the newest kit, e.g. Apple M1 and M2, because its idea of "support" is so rudimentary. • Dragonfly BSD – the youngest, the most experimental. X86-64 only. Aims at supporting lots of CPUs, lots of memory, lots of disk via a homegrown fancy modern FS, HAMMER2. So, no, I suspect DragonFly is the fastest.
snvzz 4y ago
Back when Dragonfly 6 was released, phoronix found it quite performant in their benchmarks[0]. 0. https://www.phoronix.com/review/corei9-freebsd13-dfly6/4 https://www.phoronix.com/review/corei9-freebsd13-dfly6/4
linsomniac 4y ago
Kind of wish HAMMER2 development switched to Linux and got a big boost in visibility and exposure. I've been excited about it for ~15 years, but I've never gotten enough round-tuits to put it to any real use. I'd love to switch my rsync+ZFS snapshots backup servers over to HAMMER, but ZFS works great except for deduplication.
- snvzz 4y ago
  Linux has a history of rejecting any actually good file systems. This includes but isn't limited to Tux3 and ReiserFS 4 & 5.
  - linsomniac 4y ago
    What was the story with tux3? It looks like it "read and wrote it's first file" in August 2008, and then had it's last update a few months later in Dec 2008. If if never got out of heavy development phase, being in the kernel wasn't the right place for it. ReiserFS 4, it's been a very long time since I thought about it, but ISTR there were technical issues the needed to be addressed to bring it in mainline, and personality issues didn't help any, but that's a fading memory. Which is unfortunate, because ReiserFS had some great features. On the other hand, btrfs made it into the kernel fairly easily, as a counterpoint. It's a unusual situation because it's been fairly broken and in heavy development for much of it's life in kernel, but early in-kernel versions were actually working fairly good (in my experience, I ran some fairly early versions in my laptop for a year or two with good luck, then an OS update brought in a new version and I had terrible corruption issues.
- nix23 4y ago
  >I'd love to switch my rsync+ZFS snapshots backup servers over to HAMMER Why don't you do that? You don't need linux to be happy, quite be opposite actually, install DFly and have fun.
  - linsomniac 4y ago
    As I said, I haven't made the time: it's not just installing DFly, I've got to convert all my backup code to work with HAMMER, track down issues, figure out updates, etc... Really the thing I want to try about HAMMER is the deduplication, ZFS deduplication perpetually seems to require more RAM than I have to give it HAMMER2 is really impressive, and Matthew Dillon's work on it and the rest of DragonFly is spectacular. I guess I feel like DragonFly is limiting the exposure that HAMMER could have. I know long ago there was an early aborted effort to port it, not sure it was ever very serious.

82 points by lelf 4y ago

Can somebody explain the niche or role of Dragonfly BSD? I'm only vaguely familiar with BSDs. So far my impression is that OpenBSD is the secure one, FreeBSD is the fast one (for servers). What's DragonFly good at?

bmacho 4y ago
I don't think it has a niche or role anymore. Some years ago they claimed to be fast. [0,1,2] I don't know where did you get that FreeBSD is regarded as the fast one. I think it is considered the popular/general purposed one, without a single aim like openBSD or netBSD have. [0] : https://www.dragonflybsd.org/performance/ https://www.dragonflybsd.org/performance/ [1] : https://www.dragonflybsd.org/features/ https://www.dragonflybsd.org/features/ [2] : https://www.dragonflybsd.org/history/ https://www.dragonflybsd.org/history/
- amalgamated_inc 4y ago
  Maybe just cause allegedly Netflix uses it for servers.
  - mistrial9 4y ago
    see https://news.ycombinator.com/item?id=28584738 https://news.ycombinator.com/item?id=28584738
  - nix23 4y ago
    >allegedly Netflix uses it for servers Not really "allegedly" as you can read here: https://openconnect.netflix.com/en/appliances/#software https://openconnect.netflix.com/en/appliances/#software
- loeg 4y ago
  FreeBSD focuses on performance moreso than Net or OpenBSD.
- nix23 4y ago
  >Some years ago they claimed to be fast. It is fast, maybe the fastest of all BSD's: https://www.phoronix.com/review/bsd-linux-eo2021/2 https://www.phoronix.com/review/bsd-linux-eo2021/2
  - bmacho 4y ago
    You are right, it seems much faster than freeBSD in a lot of areas and relevant benchmarks (real world programs and scenarios). They got similar overall results, but as far as I see, freeBSD is mainly faster in irrelevant benchmarks. (This is an opinion based on a glance of the phoronix article. I haven't spent much time looking at the results, also I am not an expert at benchmarking.)
    - nix23 4y ago
      I mean it's just impressive for such a small project, and benchmark's...well they just count for your very own workload..it's good to find regressions but not much else. BTW i run FreeBSD ;)
nortonham 4y ago
I always thought it was centered around the HammerFS.
- sidewndr46 4y ago
  Based on the Wikipedia page, HammerFS does basically everything.
  - abudabi123 4y ago
    Would be interesting to know the hardcore performance benchmarks for memory handling, comparing Darwin, Linux, Dragonfly and sw-engineer's aesthetics.
Koshkin 4y ago
From Wikipedia: Intended as the logical continuation of the FreeBSD 4.x series, DragonFly has diverged significantly from FreeBSD, implementing lightweight kernel threads (LWKT), an in-kernel message passing system, and the HAMMER file system. Many design concepts were influenced by AmigaOS.
j16sdiz 4y ago
Scalability. filesystem designed with cluster in mind (Just the design - the implantation still experimental). Process checkpointing. etc
todd8 4y ago
First two paragraphs of History section found on DragonFly web site[1]: > A technical introduction: The ultimate goal of the DragonFly project at its inception was to provide native clustering support in the kernel. This type of functionality requires a sophisticated cache management framework for filesystem namespaces, file spaces and VM spaces. These and other features eventually culminate in the ability to allow heavily interactive programs to run across multiple machines with cache coherency fully guaranteed in all respects. This also requires being able to divide resources, including the CPU by way of a controlled VM context, for safe assignment to potentially unsecured third-party clusters over the internet. This original design direction, although no longer the primary goal of the DragonFly project, has influenced many of the design decisions made in the intervening years. While full cache coherency is no longer a top level goal, filesystem coherency is, and that direction continues to guide the project in a number of ways. > DragonFly BSD was forked from FreeBSD 4.8 in June of 2003, by Matthew Dillon. The project was originally billed as "the logical continuation of the FreeBSD 4.x series", as quoted in the announcement, but this description has long since become obsolete. From a performance perspective DragonFly's only real competitor these days is Linux. [1] https://www.dragonflybsd.org/history/ https://www.dragonflybsd.org/history/
- amalgamated_inc 4y ago
  Yea, I checked the about section of the website a bit and honestly didn't get it :) Not familiar with most of the terms.
  - jasonwatkinspdx 4y ago
    Roughly the original idea was similar to https://en.wikipedia.org/wiki/Single_system_image https://en.wikipedia.org/wiki/Single_system_image That is, make a cluster of machines look like a single BSD instance, by allowing virtual memory to span multiple machines, processes to move, etc, all while preserving cache coherency. Obviously this is an insanely difficult goal, which is why DragonFly didn't make it particularly far towards it. Additionally we've seen the rise of virtualization and systems like k8s for managing clusters, which would reduce interest from potential collaborators.
maegul 4y ago
Perhaps a bit too scandalous (I don't know), but my understanding is that there was also a falling out of sorts between the DragonFly lead and BSD people, largely caused by allegedly abusive behaviour form the DragonFly lead while they were still working on BSD main. As I understand it, DragonFly came after this. Maybe doesn't answer your question, but it contextualises (however accurately!) part of how it came to be. My source on that is a LinuxConfAU talk I can't recall off the top of my head (the same speaker gave a somewhat notable talk in defence of SystemD)
- nix23 4y ago
  Benno Rice -> "The Tragedy of systemd" OR "The Trouble with FreeBSD" I am a bit torn apart about him, he's half right half wrong, anyway it's good to have discussions like that.
mtlmtlmtlmtl 4y ago
Originally it was planned to be a distributed OS. The main reason for the fork from FreeBSD was disagreement about what the threading primitives and their semantics should be, IIRC. One major early goal was cache coherency between different machines, though that seems to be abandoned or indefinitely on hold. Other projects have been HammerFS(a filesystem similar to ZFS, and I believe it started before ZFS was ported to FreeBSD), moving more towards a microkernel approach, and dropping support for all platforms other than x86_64. This makes the implementation of things like threading much simpler. In short, DragonflyBSD is Dillon's experimental OS with ideas he would never be able to get into FreeBSD. It's never really found a niche for production use as far as I can tell, but I'd love to be proven wrong on that. Source: FreeBSD user of several years either as a server OS, workstation OS or both. And I've dabbled with Dragonfly and love reading about obscure unices and their quirks.
- amalgamated_inc 4y ago
  > FreeBSD user of several years either as a server OS, workstation OS Oh, could you give a bit of an overview of the State of FreeBSD on the Desktop (or laptop)? I'm playing with the idea. Tried OpenBSD for a while but it just wasn't very consumer-ready. No bluetooth support at all, videos would have audio and video lag, and other issues. Is FreeBSD more suited to daily consumer laptop use? I use Arch btw
  - mtlmtlmtlmtl 4y ago
    It's been a couple years since I daily drove FreeBSD on, my desktop/workstation and I never ran it on a laptop. Still chugging along on my home built NAS(read: shitty old tower with a bunch of disks in it) though. I switched over from Arch on the desktop for a couple years at one point, and overall I was very happy. The FreeBSD project is still going strong, and they've been greatly improving their Linux syscall compat layer the last few years. ZFS support is great. It's perfectly viable as a desktop OS if you're experienced with Arch and you don't use a lot of weird hardware or software. What I did when switching was just to install it and start slowly rebuilding my Arch setup as much as possible. It's a fun weekend project with some patience, and you'll quickly find what the pain points might be that way.
rubyfan 4y ago
I was an OpenBSD and FreeBSD user at that time DragonFly was announced so I remember the original fork. Improving SMP (or SMP at all) was a thing a few of the BSDs were working on around this time as I believe processors were starting to add hyper-threading. I think that was the core rationale for the fork but Matt Dillon had a few other things he was trying. There have been a few similar forks like this where someone wanted to go their own way some with better success than others. See Annoucning DragonFly BSD! https://lists.freebsd.org/pipermail/freebsd-current/2003-July/006889.html https://lists.freebsd.org/pipermail/freebsd-current/2003-Jul... Further reading https://people.freebsd.org/~kuriyama/www/smp/ https://people.freebsd.org/~kuriyama/www/smp/ https://people.freebsd.org/~fsmp/SMP/SMP.html https://people.freebsd.org/~fsmp/SMP/SMP.html
0x457 4y ago
Dragonfly BSD is very good at being bad at taking constructive feedback /s It was born out of disagreement about how SMP should work in FreeBSD around Northwood P4 era (first HyperThreaded consumer CPU). Around that time, every general purpose OS as absolutely horrible at utilizing more than one logical cores. FreeBSD first gained SMP support at 5.0, and it was actually usable at 5.2. DragonFly BSD author had a disagreement how to implement it and though 5.x direction is bad, so, IIRC, he forked 4.x line and implemented his own vision from there. Then it was "FreeBSD does it, so I'm going to do it differently", at least that's how it looks from an outside perspective. So, it's good at SMP if we're going by that outdated classification of BSD systems.
- alberth 4y ago
  A lot of people would consider FreeBSD 5.x a horrible release (especially given how rock solid 4.x was), and things not stabilizing again until 8.x (many years later). Some would argue that in hindsight, Matt was correct at the time for the fork - from a technical standpoint.
  - 0x457 4y ago
    Oh, I know. I suffered the entire way to 8.0. Until 5.2 it was completely unusable. I also remember unplugging or plugging USB device would often lead to kernel panic until 9.0 IIRC. I agree that he was correct at the time. Likewise, I do wish that split never happened, though.
    - alberth 4y ago
      > * I do wish that split never happened* I too wish the split hadn’t happened, and for Matt’s ideas to have landed in FreeBSD. Dragonfly today is remarkable, still competing head to head with FreeBSD 15 years later but with a development team literally 1/50th the size.
      - loeg 4y ago
        FreeBSD doesn’t have 50 active core developers so it’s hard to imagine how Dragonfly could be 1/50th the size.
somat 4y ago
My impression(i only really use openbsd) Freebsd has the most developer resources and tends to be good at optimizing for speed but the userland always feels, it is hard to explain, but off, if you are fine with with the linux userland this will be a step up, openbsd, a step down. It has very good zfs integration and that is a solid reason for using it alone. Netbsd just sits in the corner doing their own thing, I am not sure what that is but I suspect if I had not fallen for openbsd I would be using netbsd. A good solid small OS. Dragonfly has an incredible main developer who has strong views about how parallel systems should be structured and the programing chops to pull it off. If you can take using a system with absolutely minuscule developer resources you will find real gems here, an amazing filesystem and very good multiprocessor support. Openbsd strives for correctness above all else, speed tends to be a second class citizen, that is, if the developers have to make a choice between a simple obviously correct solution and a messy but quick one, they will almost always go for the simple one. speed is fine but not at the expense of readability. the system is probably the most full featured. With an emphasis on network daemons. but limited developer resources keep everything simple. I think of it as the best desktop system due to it's ease of administration and excellent ports system.
- nortonham 4y ago
  >Netbsd just sits in the corner doing their own thing, I am not sure what that is but I suspect if I had not fallen for openbsd I would be using netbsd. A good solid small OS. Portability, pkgsrc, some neat innovations, and a small and welcoming community. I'm not qualified to judge this, but they also value code quality and security.
loeg 4y ago
DragonFlyBSD is Dillon’s FreeBSD. It’s a fork because of personality disagreements between Dillon and other developers in the FreeBSD 5.0 timeframe. It does some interesting experimental stuff like HammerFS but isn’t really suitable for general use.
- nix23 4y ago
  >but isn’t really suitable for general use. Can you tell me why? Because i used it for 3 years regularly in a professional setup (~10 servers). Never had a problem with hammer 1 or 2 or anything else.
rektide 4y ago
The original plan was a SSI, single-system-image operating system, where one cohesive system could span across multiple physical machines. It's quite a long ambitious plan, but it's still up on the project's history page[1]: > DragonFly BSD has been going through rapid and ever increasing development since the fork. One of the important works included the simplification and general cleanup of the majority of the kernel subsystems. This work was originally intended to support single system image clustering, but has had the effect of making the kernel much more reliable, understandable and easily maintainable. One of the fundamental synchronization concepts that DragonFly uses throughout the kernel, the token, lends itself directly to ease of maintenance and understandability of the kernel. There's been plenty of neat off-shoot advantages DragonflyBSD has gained along this quest. Great great scalability has been notable; the core coherency construct, the serializing token, targets reducing locking in the system & potentially allows scale-out into SSI. DragonflyBSD has some really cool tricks, like being able to run virtual kernels- running a kernel as a process, for "jail" or just kerneldev reasons. Still it's impossible to mention DragonflyBSD without mentioning it's filesystem, HAMMERFS, and now HAMMERFS2, which is a great Copy-on-Write & snapshotted fs intended for radical scale out, & ultimately, clustering, where multiple machines can cohesively contribute & operate a single filesystem together, with pooled resources. There is already a good bit of quorumed clustering support in HAMMERFS2. > The HAMMER filesystem is also intended to serve as a basis for the clustering and other work that makes up the second phase of the project. There's a StackOverflow question talking to DragonflyBSD as a SSI[2] as well, which mainly cites the same History page, but also has some other links. [1] https://www.dragonflybsd.org/history/ https://www.dragonflybsd.org/history/ [2] https://unix.stackexchange.com/questions/429464/dragonfly-bsd-purpose-myth-one-os-on-several-physical-machines https://unix.stackexchange.com/questions/429464/dragonfly-bs...
lproven 4y ago
I am a bit of a BSD outsider, but I've been exploring them recently. I'd say it's more like: • NetBSD – the oldest, aims at the widest platform support • FreeBSD – next oldest, aims at modern hardware, best hardware and desktop support, native ZFS. • OpenBSD – a bit younger, aims at correctness and security, so very basic hardware support, e.g. no Bluetooth at all. But that means it supports some of the newest kit, e.g. Apple M1 and M2, because its idea of "support" is so rudimentary. • Dragonfly BSD – the youngest, the most experimental. X86-64 only. Aims at supporting lots of CPUs, lots of memory, lots of disk via a homegrown fancy modern FS, HAMMER2. So, no, I suspect DragonFly is the fastest.

snvzz 4y ago

Back when Dragonfly 6 was released, phoronix found it quite performant in their benchmarks[0]. 0. https://www.phoronix.com/review/corei9-freebsd13-dfly6/4 https://www.phoronix.com/review/corei9-freebsd13-dfly6/4

linsomniac 4y ago

Kind of wish HAMMER2 development switched to Linux and got a big boost in visibility and exposure. I've been excited about it for ~15 years, but I've never gotten enough round-tuits to put it to any real use. I'd love to switch my rsync+ZFS snapshots backup servers over to HAMMER, but ZFS works great except for deduplication.

snvzz 4y ago
Linux has a history of rejecting any actually good file systems. This includes but isn't limited to Tux3 and ReiserFS 4 & 5.
- linsomniac 4y ago
  What was the story with tux3? It looks like it "read and wrote it's first file" in August 2008, and then had it's last update a few months later in Dec 2008. If if never got out of heavy development phase, being in the kernel wasn't the right place for it. ReiserFS 4, it's been a very long time since I thought about it, but ISTR there were technical issues the needed to be addressed to bring it in mainline, and personality issues didn't help any, but that's a fading memory. Which is unfortunate, because ReiserFS had some great features. On the other hand, btrfs made it into the kernel fairly easily, as a counterpoint. It's a unusual situation because it's been fairly broken and in heavy development for much of it's life in kernel, but early in-kernel versions were actually working fairly good (in my experience, I ran some fairly early versions in my laptop for a year or two with good luck, then an OS update brought in a new version and I had terrible corruption issues.
nix23 4y ago
>I'd love to switch my rsync+ZFS snapshots backup servers over to HAMMER Why don't you do that? You don't need linux to be happy, quite be opposite actually, install DFly and have fun.
- linsomniac 4y ago
  As I said, I haven't made the time: it's not just installing DFly, I've got to convert all my backup code to work with HAMMER, track down issues, figure out updates, etc... Really the thing I want to try about HAMMER is the deduplication, ZFS deduplication perpetually seems to require more RAM than I have to give it HAMMER2 is really impressive, and Matthew Dillon's work on it and the rest of DragonFly is spectacular. I guess I feel like DragonFly is limiting the exposure that HAMMER could have. I know long ago there was an early aborted effort to port it, not sure it was ever very serious.