
DragonFly BSD 5.2 - joeschmoe3
https://www.dragonflybsd.org/release52/
======
niftich
Just the other day I voiced [1] a concern on a ZFS thread about not enough
modern filesystems [2] shipping as defaults (or being recommended as such),
despite some of these filesystems having been around for many years.

This is a promising move to the contrary.

[1]
[https://news.ycombinator.com/item?id=16798244](https://news.ycombinator.com/item?id=16798244)

[2] in some loose, but recognizable definition of modern, featuring
checksumming, CoW, deduplication, snapshots...

~~~
AnIdiotOnTheNet
In some ways I think we actually need simpler file systems more than fancier
ones. Here's an exercise: create a USB flash drive that can be both read and
written on any system it is plugged into, by any user, without using FAT.

Can't be done. It's 2018 and FAT is still apparently the best we can do for
universally usable filesystem.

And don't go trying to pin this on Windows not supporting ext or something
stupid like that, because an ext filesystem cannot by default be both read and
written universally even on systems that have full ext support, because they
bake in permissions and the default umask botches this simple use case.

I realize this is sort of tangential to what you're saying, but I think a big
problem we have in tech communities is that we focus too much on fancy
interesting things and not enough on stuff that gets things done simply.

~~~
yepguy
Have you tried UDF?

[http://duncanlock.net/blog/2013/05/13/using-udf-as-an-
improv...](http://duncanlock.net/blog/2013/05/13/using-udf-as-an-improved-
filesystem-for-usb-flash-drives/)

~~~
AnIdiotOnTheNet
UDF has a lot of issues in actual implementation. For instance MacOS will only
support UDF on an unpartitioned disk, while Windows will only support it on a
partitioned one (IIRC was true for 7, may not be anymore). Additionally, since
it has posix permissions, I expect it will have the same multi-user issue on
posix systems that ext does, though I haven't tested this.

------
agar
With DragonFly's architecture being designed with multiprocessing and
clustering in mind, how does it fare (relative to Linux and other BSDs) in
modern environments with many-core CPUs, horizontally-scalable architectures,
reliance on VM-based workloads, and containerization?

I would think it would really shine, but haven't seen comparisons - or much
market uptake.

Wouldn't significant advantages result in lower costs (e.g., fewer CPUs needed
because of higher performance per core due to lower OS overhead) and therefore
economics would drive greater use? If it hasn't, why not?

~~~
gh02t
I'm not an expert on DragonFly, but from what I know it's design differences
aren't really that radical. It differs substantially from FreeBSD, but it's
not like a fundamental re-imagining optimized for SMP. Performance is a bit
better in some places, and about the same in others.

I do think DragonFly is neat and quite interesting, but I suspect it didn't
gain as much momentum because the community behind BSD is already small and
reluctant to fracture without stronger reasons. It's worth noting that this is
not like spinning off a new Linux distro where you're ultimately just
repackaging different variations of the same basic OS - DragonFly is
effectively an entirely different OS since the kernel is significantly
different.

Slightly out of date, but still relevant benchmarks:
[https://www.phoronix.com/scan.php?page=article&item=freebsd1...](https://www.phoronix.com/scan.php?page=article&item=freebsd11-beta-
benchmarks&num=1)

~~~
agar
Thanks, I took a look through that and most (all?) of the benchmarks seemed to
be fairly traditional tasks, some not even highly threaded.

I guess I'm wondering if complex, multi-box, cloud-scale workloads have any
advantage on Dragonfly - or if the optimizations for clustering are in such a
narrow band of use cases that modern architectures have passed it by just
through brute force.

There's an irony here, in that Matt Dillon was an ex-Amiga hacker (IIRC, some
of Dragonfly's architectural choices were inspired by the Amiga). Anyway, the
Amiga's linear memory, co-processor-driven architecture was ridiculously more
elegant than the PC's segmented memory, CPU-bound approach. Didn't matter
though, a huge investment in working around the PC's limitations led to its
market dominance.

So, if massive technical accommodations for less efficient OS architectures
end up marginalizing Dragonfly, it would be a bit of history repeating itself.

And I'm sure the irony wouldn't be lost on Mr. Dillon.

------
dec0dedab0de
I never heard of HAMMER2( or HAMMER) until just now, but a quick search seems
awesome. I might have to give bsd another try, its been over a decade.

------
0xcde4c3db
Anyone know what the state of GPU support actually is? The Supported Hardware
page [1] only says "Intel GPUs are supported up to the Skylake generation
(2016 machines)", but this seems to be outdated. At the very least, Matt
Dillon himself reported good OpenGL performance with a Kaby Lake machine [2].

[1]
[https://www.dragonflybsd.org/docs/supportedhardware/](https://www.dragonflybsd.org/docs/supportedhardware/)

[2]
[http://lists.dragonflybsd.org/pipermail/users/2017-September...](http://lists.dragonflybsd.org/pipermail/users/2017-September/313586.html)

~~~
ftigeot
DragonFly web documentation is wiki-based and tends to not always be up-to-
date (contrary to man pages).

All recent Intel GPUs are supported, including Kabylake and Coffeelake.

------
jasonkostempski
A few years ago I wanted to try this as a local Minecraft server but it was 64
bit only and the spare machine I had was 32 bit. Glad this post came up
because now I've got a 64 bit machine sitting in my basement I had forgotten
about until now.

~~~
h1d
Can you not just spin up a cloud instance and boot it off of a cd image?

------
pmoriarty
Are there any plans to bring HAMMER2 in to Linux?

~~~
kalessin
Afaik the whole purpose of DragonflyBSD is HAMMER so no.

~~~
azinman2
Can you go into more detail please? That sounds interesting. I thought it had
to do with concurrency.

~~~
doctorsher
You're not wrong. Interview from 2004 [0]: "DragonFly split off from FreeBSD-5
over major architectural differences, not anything else. We really do feel
that FreeBSD-5 is taking the wrong approach to _SMP_ and building something
that is so complex that it will ultimately not be maintainable. We think we
have a better way."

But their original architectural decisions were done with this goal in mind
[1]: "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." It's not difficult to see how HAMMER came to be
three to four years later, given their stated design goals.

[0]
[http://www.onlamp.com/pub/a/bsd/2004/07/08/dragonfly_bsd_int...](http://www.onlamp.com/pub/a/bsd/2004/07/08/dragonfly_bsd_interview.html)
[1]
[https://www.dragonflybsd.org/history/](https://www.dragonflybsd.org/history/)

------
azinman2
Are there many users of dragon fly bsd? Are people using it in production, and
why/why not?

------
gaius
Still haven’t quite managed to get Dragonfly going in Azure, but not given up
on it either

------
subway
MD5 release checksums? c'mon folks, get with the times...

~~~
ceratopisan
I generated them; what would you prefer, and why?

I know MD5 hash collisions are vaguely possible, but I would think they would
be extremely unlikely here.

~~~
subway
There's no vague about it. MD5 collisions have been possible to generate for
over a decade now.

[http://www.win.tue.nl/hashclash/SoftIntCodeSign/](http://www.win.tue.nl/hashclash/SoftIntCodeSign/)

A sha256 or sha512 would be more appropriate.

~~~
tedunangst
If you don't trust the dragonfly team to not produce collisions, you probably
shouldn't use the software anyway.

~~~
michaelmrose
The malicious case would be a bad actor distributing phony files that appear
to check out because the flaws have been found that would allow someone to do
so.

~~~
tialaramex
In practice today this requires that the bad actor collaborates with the real
distributor.

MD5 fails to _collision_. A collision is when you can find two different
things with the same hash. But being able to collide the hash is NOT the same
as being able to find a second pre-image, which is what you'd need in order to
get "phony files that appear to check out" if the person who originally issued
the MD5 checksums didn't collaborate with you.

~~~
kilburn
There have been practical demonstrations of using padding in several formats
to generate valid files that collision with an original one, but with entirely
different contents.

This means that it is possible that someone could download the real image,
introduce some rootkit, and then tinker that (for instance, by adding a hidden
file with carefuly crafted content) until the resulting md5 is the same as
that of the original image. Then hack the server and upload the modified image
in place of the original one, and everyone who installs Dragonfly is now their
minion.

If you use a stronger hash (which is not harder for anyone than using md5),
then this attack vector becomes impossible. So... even if it is a remote
possibility, just use the stronger hash because it is just a dominant strategy
(it has upsides, yet 0 downsides).

~~~
temprature
There have been no practical demonstrations of colliding the MD5 of an
arbitrary file (ie. pre-image attack), only situations where two files are
created specifically with the intended purpose of creating a collision. This
is precisely what the post you replied to said but you seem to have not
understood that there's a distinction.

Yes, it is possible that the DragonFly developers could collude to create two
ISOs with the same MD5, one good and one malicious. No, it is not possible
that random, evil ne'erdowells could replace the ISO with one with the same
MD5, unless the DragonFly developers have conspired with them to make that
possible.

If you don't trust the DragonFly developers not to collide the MD5s, you
probably shouldn't trust them with the code running in your kernel anyway.

