/fdg/ Friendly DragonFly BSD General

OS-tan edition.

dragonflybsd.org/

DragonFly belongs to the same class of operating systems as other BSD-derived systems and Linux. It is based on the same UNIX ideals and APIs and shares ancestor code with other BSD operating systems. DragonFly provides an opportunity for the BSD base to grow in an entirely different direction from the one taken in the FreeBSD, NetBSD, and OpenBSD series.

Features:
>HAMMER2 filesystem (comparable to ZFS)
>Virtual Kernels (run a full-blown kernel as a user process)
>The kernel uses several synchronization and locking mechanisms for SMP (an extremely stable, high-performance kernel that is capable of efficiently using all cpu, memory, and I/O resources thrown at it)
>DragonFlyBSD has virtually no bottlenecks or lock contention in-kernel. Nearly all operations are able to run concurrently on any number of cpus.
>SSD "swapcache": Make use of swap space to cache filesystem data and meta-data
>Robust, natively written AHCI and NVME drivers, stable device names via DEVFS and a partial implementation of Device Mapper for reliable volume management and encryption
>DragonFly leverages the dports system to provide thousands of applications in source and binary forms.
>NO POZZED CODE OF CONDUCT

Just found this DragonFly BSD OS-tan on their main website; it's a very cute design, though the art style is not the best. I hope a talented drawfag can make a very cute OS-tan for us using the same design as the one in this pic.

Haven't used DragonFly BSD before, am going to install it tonight. What most interests me is the HAMMER2 filesystem and that it has LUKS.

Attached: dragonfly_BSD_tan.png (1920x1080, 1.08M)

Other urls found in this thread:

dragonflybsd.org/hammer/
dragonflybsd.org/features/
phoronix.com/scan.php?page=article&item=bsd-threadripper-2990wx&num=5
informit.com/articles/article.aspx?p=766375&seqNum=2
gitweb.dragonflybsd.org/dragonfly.git/commitdiff/c70d456200b358cf28b9b0d3b450ab482b91a9f8
twitter.com/NSFWRedditImage

HAMMER2 filesystem:
dragonflybsd.org/hammer/

General details
>HAMMER file systems are immediately available after a crash. There is no fsck.
>A single HAMMER file system can be up to 1 exabyte in size, and can encompass up to 256 volumes, each of which can be up to 4 petabytes (4096 terabytes).
>HAMMER retains a fine-grained history. The state of the filesystem can be accessed live on 30-60 second boundaries without having to make explicit snapshots, up to a configurable fine-grained retention time.
>Coarse-grained history is controlled by snapshots. By default the system cron generates one snapshot a day and retains 60 days worth. Snapshots can be accessed live.
>A convenient undo command is provided for single-file history, diffs, and extractions. Snapshots may be used to access entire directory trees.
>Data and meta-data is CRC-checked for integrity.
>Data block deduplication

Snapshots
>Snapshots of the file system can be taken at any time, with no limitations.
>Snapshots are indexed by the on-media B-Tree and are extremely storage-efficient.
>Snapshots are "live", and can be accessed at any time.
>Snapshot and historical data retention are controlled through a config file kept in meta-data - no manual maintenance is required for historical files.

Backups and history
>HAMMER file systems can be split up into multiple pseudo-file systems, or PFSs. Snapshots and backups can be different for each individual PFS.
>HAMMER PFSs can be backed up continuously or in batch to other HAMMER PFSs, on a per-PFS basis.
>Backup PFSs (slaves) are functionally identical to the original (master) and can be promoted to a master.
>Slave PFSs can retain file history independent of the master volume's settings.
>HAMMER can efficiently stream bandwidth-controlled near-real-time backup data to slave PFSs on remote hosts.
>1 master PFS can stream backups to any number of slave PFSs.
>Slave-to-slave mirroring streams are supported, allowing mirrors to be chained together.

Attached: dragonfly_OS_tan.jpg (790x1011, 220K)

Here's a very cool DragonFly BSD feature:

Process Checkpointing
>Processes under DragonFly may be "checkpointed" or suspended to disk at any time. They may later be resumed on the originating system, or another system by "thawing" them. See sys_checkpoint(2) and checkpt(1) for more details.

Basically, you can save the state of any running process to disk, and then restore that state from the file on disk at any time, like savestates for programs.

Attached: DragonFly_BSD_OS-tan.jpg (255x320, 42K)

More DragonFly BSD features:
dragonflybsd.org/features/

EXTREME SCALING
>DragonFly will autotune kernel resources and scaling metrics such as kernel hash-tables based on available memory. The autoscaling has reached a point where essentially all kernel components will scale to extreme levels.

>Process and thread components now scale to at least a million user processes or threads, given sufficient physical memory to support that much (around 128GB minimum for one million processes).

>File data caching scales indefinitely, based on available memory.

>IPI signaling between CPUs has been heavily optimized and will scale nicely up to the maximum hardware thread limit (256 cpu threads, typically in a 128-core/256-thread configuration).

>The network subsystem was rewritten pretty much from the ground-up to fully incorporate packet hashes into the entire stack, allowing connections and network interfaces to operate across available CPUs concurrently with little to no contention.

>All major kernel resource components are fully SMP-aware and use SMP-friendly algorithms.

>The disk subsystem, particularly AHCI (SATA) and NVMe, are very SMP friendly. NVMe, in particular, will configure enough hardware queues such that it can dispatch requests and handle responses on multiple cpus simultaneously with no contention.

Attached: DragonFly_BSD_OS-tan_2.jpg (576x860, 417K)

Oof

Attached: dragonflybsd.png (644x6981, 531K)

Looks like DragonFly BSD was middle of the pack for most of those tests, but yikes it was really bad (worst results) for some of them.

Got a link to that benchmark? What hardware was being used?

phoronix.com/scan.php?page=article&item=bsd-threadripper-2990wx&num=5

I'm waiting for DragonflyBSD to catch up to FreeBSD before I use it.

So quite recent then, that's unfortunate.

I'm going to be trying it out anyways as HAMMER2 seems quite cool, as does process checkpointing. DragonFly BSD is also designed for building clusters, which could be fun to play with.

Will report back with rice.

>No CoC
>Working radeon driver for modern cards
>Hammer2

Based.
I'm having real problems with firefox tho, for some reason it gets laggy as fuck whenever I browse jewtube - dont have this problem with chromium.

Where did you get Firefox binary from? What version?

Some information on DragonFly BSD and clusters:

informit.com/articles/article.aspx?p=766375&seqNum=2

Apparently DragonFly BSD was the first BSD to implement ZFS, but they ditched it and wrote HAMMER because ZFS is not really compatible with clustering.

>One of the main focuses for DragonFly is clustering. As commodity hardware dropped in price, clusters have become a very cost-effective way of achieving high performance and reliability. In many ways, individual computers are beginning to look more and more like small clusters.

>DragonFly BSD aims to support Single System Image clustering. This concept will be familiar to VMS users, but is relatively rare in the UNIX world. The idea is that a bunch of nodes connected together will appear to be a single, large, SMP machine. All processing resources, memory, disks, and peripherals will be shared.

On ZFS:

>DragonFly was one of the first operating systems to have a serious port of Sun's ZFS attempted, and for a while it looked like it would see some heavy use, but this was not to be. Matt spoke briefly on the limitations of ZFS, saying:
>"At this point it doesn't look like I'll be importing ZFS, but instead designing a filesystem from scratch along similar lines. ZFS has the redundancy we need but doesn't seem very cluster-friendly, and DragonFly really needs a cluster filesystem."

>ZFS is designed for a more client-server architecture. It assumes that some machines will be responsible for managing storage and others will simply be consumers of storage services. The aim for the new (and, as yet, unnamed) DragonFly filesystem is that each node in a cluster will have some storage space, but the cluster as a whole will see it as a single storage pool. This will allow nodes to make use of local storage for speed and remote storage for reliability, with cached copies of data being moved around in a manner somewhat reminiscent of CMU's Andrew Filesystem.

afaik Matt said that this Phoronix guy has no clue what he is benchmarking, and I personally tested HTTP req/sec with wrk on Ubuntu/FreeBSD/DragonflyBSD, and Dragonfly has +50% more req/sec and lower latency numbers than FreeBSD and over 100% increase in Req/sec over Ubuntu

also after these benchmarks were taken there was serious 2990X kernel commits added, so, wait for new ones

gitweb.dragonflybsd.org/dragonfly.git/commitdiff/c70d456200b358cf28b9b0d3b450ab482b91a9f8

More info on this?

Id like to eventually use Df in my personal PC, but some of the benchmarks are horrible.
Also, any news of electron in BSD? I know, pleb, but I'd find really difficult to ditch vscode as my main editor.

Im quite a pleb, any info on how to install wayland on this?
If Im going to mess with it Id like to make a df+wayland+sway combo

Are you serious? If DragonFly BSD require an update to get acceptable at this point in time the whole thing is a piece of crap with shit developers.

What did you smoke? Of course it will need updates for new processors and Its a tiny project, its not as fast as linux, who in many get early access to the hardware.

>if an OS can be improved by updates it's a piece of crap
>if its developers can create those updates then they are shit developers
Imagine being this retarded.

hop on IRC and ask him yourself, for the 2nd part, download ISOs and bench yourself against HTTP server hello world

how can u be this retarded user? its a brand new processor which requires kernel tuning for good scheduling and other stuff, DragonflyBSD dev actually bought the CPU to test it and develop tuning profiles for it. Dragonfly has the fastest network stack w lowest latency by far

* Update AMD topology detection to use the correct cpuid. It
now properly detects the Threadripper 2990WX as having four nodes
with 8 cores and 2 threads per core, per node. It previously detected
the chip as one node with 32 cores and 2 threads per core.

* Report the basic detected topology without requiring bootverbose.

* Record information about how much memory is attached to each node.
We previously just assumed that it was symmetric. This will be
used by the scheduler.

* Fix instability in the scheduler when running on a large number
of cores. Flag 0x08 (on by default) is needed to actively
schedule overloaded threads onto other cores, but this operation
was being executed on all cores simultaneously which throws the
uload/ucount metrics into an unstable state, causing threads to
bounce around longer the necessary.

Fix by round-robining the operation based on something similar to
sched_ticks % cpuid.

This significantly improves heavy multi-tasking performance on systems
with many cores.

* Add memory-on-node weighting to the scheduler. This detects asymetric
NUMA configurations for situations where not all DIMM slots have been
populated, and for CPUs which are naturally assymetric such as the
2990WX which only has memory directly connected to two of its four
nodes.

This change will preferentially schedule threads onto nodes with
greater amounts of attached memory under light loads, and dig into
the less desirable cpu nodes as the load increases.


gitweb.dragonflybsd.org/dragonfly.git/commitdiff/c70d456200b358cf28b9b0d3b450ab482b91a9f8

back to hackernews please

Wayland is Linux only for now IIRC.

I just used pkg install firefox

Anyway I'm using palemoon now as it doesn't seem to have the same problem.

If netbsd can support extremely obscure platforms that no other BSD care to support. What is so great about dragonfly?

Does dragonfly support more filesystems than openBSD? I want HDD where I can access files between Linux and *BSD but I don't want to use ext2.

HAMMER is the new GNU Hurd. It's not fully implemented in DragonFlyBSD and nowhere near stable enough to be ready for production. Even the specs are not completely done.

>leverages
Buzzword bingo!

Just set up a NAS you dumb fuck.

>7zip compression
jezus that is fucking bad. What did they fuckup?

Im curious too.
It can simply be lack of performance, there has to be a mayor, possibly easy to fix, issue

*It can't

Not him, but this isn't always practical. If you're a poor student and can't afford the spare components, it's not a great solution. And NFS is fucking terrible by comparison to many major filesystems -- hard to use, not performant, etc.

Linux supports about ten times as many filesystems as any other OS. Expecting filesystem level compatibility between OSes is very, very dumb.

I agree. That's part of what eventually made me nuke my Windows gayman partition. It became so fucking troublesome to install ext3 drivers for Windows and vice versa that I just decided to give it up. It certainly doesn't help that really the only filesystem the *BSDs have in common is the awful UFS.

Honestly probably the easiest thing to do would be an external drive formatted to FAT32 or something.

>64bit only

does dragonfly support ext2? i can do with that as long as the support for it its reliable

Yes it supports ext2.

read-write, right?

also this guy says it has working radeon driver for modern cards. is that true? I currently have a GTX 650 but I was thinking on buying a radeon

yes, r/w.