DragonFly in my opinion is one of these projects that do amazing stuff, but simply don’t care about marketing. That’s usually the case when the success of a project doesn’t really provide significant financial gains and when the motivating factor is the project itself.
However, unlike many research projects they are not capsuled off from the real world or business needs, etc. Unlike research operating systems it’s not horribly inconvenient to use. Actually DragonFly BSD has a couple of tiny things here and there that make things a lot more convenient for developers and users than other BSDs or various Linux distributions.
This is a non-amazing example, something everyone could have, but strangely nobody seems to have. There is a Makefile in /usr/ allowing you to fulfill various tasks around managing the source code or ports.
What next to performance is appealing about DragonFly is pragmatism and a drive to fixing things. That’s something that sadly is lacking in the open source world, but also in IT in general. My guess is that this is also related to what the motivation is. If you use a certain piece of software and contribute to it it the outcome will be different if you use it on a daily basis, personally and professionally, vs only professionally in a certain area.
This often leads to states where topics that are not the most common use case are either not covered at all or done in somewhat hacky ways. Oftentimes these lead to bug reports and things that everyone complains about for years, sometimes even leading to forks and new projects that then only cover a certain topic and overoptimize there (JavaScript frameworks and libraries have done that for a very long time, even though it seems this gets better).
I think this is also partly a mindset. While many people categorize the BSDs in certain ways (OpenBSD for security, firewalls, etc., NetBSD for exotic architecture, etc.) you are not weird or special at all if you use it mainly for office work, watching YouTube or even producing videos. They are all designed as general purpose systems, which can also seen by the areas that ports/packages exist for.
While I also find the article above a bit short, maybe that’s the intention behind it. Often reviews focus on very small parts of operating systems. Many times they stop after installation, which hardware is supported or how the performance is like. While I haven’t used DragonFly BSD in many years I always enjoyed the fact that while having a focus on performance it got all these other parts. They were early with Intel drivers among the BSDs (from what I understand largely because of making it easy to port Linux drivers), they have multiple ways of encrypting file systems, including a BSD licensed implementation of the system coming from TrueCrypt, there also was some USB topic fixed early there (compared to mostly FreeBSD), packages tend to work very well, HAMMER, Swapcache, little tools like resident all can be quite handy. But that was quite a few years ago.
I can understand the mindset about “just try it”. Think about MacOS, Windows, GNU/Linux (Ubuntu, Debian, maybe Arch Linux are only distros). Summing up why you use it and reviewing it isn’t exactly easy. So it’s a bit odd to make basic statements as a reviews about other operating systems. In the end even after trying out a complete operating system for a few weeks only tends to give you a small glimpse around the parts one cares about. There tend to be books about pretty small parts and even they don’t tend to be complete or up to date.
Did you find out what caused this? Was this a bug in HAMMER? Did you report it?
Small anecdote. Ages ago I had a a dual boot with DragonFly. I did tend to have kernel panics, but later found out that it actually was a dying CPU. Pretty sure it also was the same kind of commands. First I found that unlikely since the other OS ran just fine, but because of someone suggesting it I ran some tests and later replaced the CPU with another of the same model. It worked perfectly from then on.
Not saying it’s not a bug, just that it tends to be worthwhile to report these things and analyze them, especially when it is a system you care about.
Did you find out what caused this? Was this a bug in HAMMER? Did you
report it?
I don’t know what the problem was.
Probably HAMMER was not intended for my setup:
i368
2GB RAM
3TB HDD
Small anecdote. Ages ago I had a a dual boot with DragonFly. I did tend
to have kernel panics, but later found out that it actually was a dying
CPU. Pretty sure it also was the same kind of commands. First I found
that unlikely since the other OS ran just fine, but because of someone
suggesting it I ran some tests and later replaced the CPU with another
of the same model. It worked perfectly from then on.
Thanks for sharing this!
Do you remember what tests you ran?
I think memtest86 was able to find it but honestly I mostly confirmed it by replacing the CPU with an identical. Had more time back then so probably dug quite far to confirm its the CPU.
I’m confused… where’s the “first taste” in this? I expected some sort of review.
[Comment removed by author]
it’s also telling you that the word upgradation exists
Lots of great performance improvements lately too!
DragonFly in my opinion is one of these projects that do amazing stuff, but simply don’t care about marketing. That’s usually the case when the success of a project doesn’t really provide significant financial gains and when the motivating factor is the project itself.
However, unlike many research projects they are not capsuled off from the real world or business needs, etc. Unlike research operating systems it’s not horribly inconvenient to use. Actually DragonFly BSD has a couple of tiny things here and there that make things a lot more convenient for developers and users than other BSDs or various Linux distributions.
This is a non-amazing example, something everyone could have, but strangely nobody seems to have. There is a Makefile in /usr/ allowing you to fulfill various tasks around managing the source code or ports.
What next to performance is appealing about DragonFly is pragmatism and a drive to fixing things. That’s something that sadly is lacking in the open source world, but also in IT in general. My guess is that this is also related to what the motivation is. If you use a certain piece of software and contribute to it it the outcome will be different if you use it on a daily basis, personally and professionally, vs only professionally in a certain area.
This often leads to states where topics that are not the most common use case are either not covered at all or done in somewhat hacky ways. Oftentimes these lead to bug reports and things that everyone complains about for years, sometimes even leading to forks and new projects that then only cover a certain topic and overoptimize there (JavaScript frameworks and libraries have done that for a very long time, even though it seems this gets better).
I think this is also partly a mindset. While many people categorize the BSDs in certain ways (OpenBSD for security, firewalls, etc., NetBSD for exotic architecture, etc.) you are not weird or special at all if you use it mainly for office work, watching YouTube or even producing videos. They are all designed as general purpose systems, which can also seen by the areas that ports/packages exist for.
While I also find the article above a bit short, maybe that’s the intention behind it. Often reviews focus on very small parts of operating systems. Many times they stop after installation, which hardware is supported or how the performance is like. While I haven’t used DragonFly BSD in many years I always enjoyed the fact that while having a focus on performance it got all these other parts. They were early with Intel drivers among the BSDs (from what I understand largely because of making it easy to port Linux drivers), they have multiple ways of encrypting file systems, including a BSD licensed implementation of the system coming from TrueCrypt, there also was some USB topic fixed early there (compared to mostly FreeBSD), packages tend to work very well, HAMMER, Swapcache, little tools like resident all can be quite handy. But that was quite a few years ago.
I can understand the mindset about “just try it”. Think about MacOS, Windows, GNU/Linux (Ubuntu, Debian, maybe Arch Linux are only distros). Summing up why you use it and reviewing it isn’t exactly easy. So it’s a bit odd to make basic statements as a reviews about other operating systems. In the end even after trying out a complete operating system for a few weeks only tends to give you a small glimpse around the parts one cares about. There tend to be books about pretty small parts and even they don’t tend to be complete or up to date.
Btw., if you care about features: https://www.dragonflybsd.org/features/
I was running DragonFly on a NAS several years ago, because HAMMER has snapshots and can export those over NFS.
Unfortunaly, it crashed the file system every time I was trying to
rma directory with ~40GB.Did you find out what caused this? Was this a bug in HAMMER? Did you report it?
Small anecdote. Ages ago I had a a dual boot with DragonFly. I did tend to have kernel panics, but later found out that it actually was a dying CPU. Pretty sure it also was the same kind of commands. First I found that unlikely since the other OS ran just fine, but because of someone suggesting it I ran some tests and later replaced the CPU with another of the same model. It worked perfectly from then on.
Not saying it’s not a bug, just that it tends to be worthwhile to report these things and analyze them, especially when it is a system you care about.
I don’t know what the problem was. Probably HAMMER was not intended for my setup:
Thanks for sharing this! Do you remember what tests you ran?
I think memtest86 was able to find it but honestly I mostly confirmed it by replacing the CPU with an identical. Had more time back then so probably dug quite far to confirm its the CPU.