Linked by Thom Holwerda on Wed 3rd Aug 2016 23:26 UTC
BSD and Darwin derivatives

DragonFly version 4.6 brings more updates to accelerated video for both i915 and radeon users, home-grown support for NVMe controllers, preliminary EFI support, improvements in SMP and networking performance under heavy load, and a full range of binary packages.

Order by: Score:
Kudos!
by ebasconp on Thu 4th Aug 2016 15:57 UTC
ebasconp
Member since:
2006-05-09

It is nice to see new releases of highly technical projects as DragonFly BSD, ReactOS or GenodeOS.

Kudos for them.

Reply Score: 3

Woo, KVM improvements!
by tidux on Thu 4th Aug 2016 18:23 UTC
tidux
Member since:
2011-08-13

This is huge for me. I run a DragonFly VM under KVM with 32GB RAM and virtio as a test box to make sure I'm not accidentally introducing Linuxisms, so this is great news for me.

Reply Score: 3

RE: Woo, KVM improvements!
by Alfman on Thu 4th Aug 2016 20:50 UTC in reply to "Woo, KVM improvements!"
Alfman Member since:
2011-01-28

tidux,

This is huge for me. I run a DragonFly VM under KVM with 32GB RAM and virtio as a test box to make sure I'm not accidentally introducing Linuxisms, so this is great news for me.


I'm guilty of that. I've been using epoll/eventfd alot. The problem is that posix AIO is very poorly supported on linux because it's implemented with blocking threads, which defeats the entire purpose of AIO. Since I'm not familiar with it, how is the state of AIO on BSDs? I am interested in hearing about what kind of things would typically break for you?

Reply Score: 2

RE[2]: Woo, KVM improvements!
by tidux on Thu 4th Aug 2016 21:58 UTC in reply to "RE: Woo, KVM improvements!"
tidux Member since:
2011-08-13

I've heard that kqueue is much nicer than epoll, but I haven't written anything that needs either so I can't comment on it directly. Using DragonFly BSD for testing uncovered some surprising issues with existing projects written in Go.

Reply Score: 2

RE[3]: Woo, KVM improvements!
by Alfman on Thu 4th Aug 2016 23:17 UTC in reply to "RE[2]: Woo, KVM improvements!"
Alfman Member since:
2011-01-28

I've heard that kqueue is much nicer than epoll, but I haven't written anything that needs either so I can't comment on it directly.


I found this comparison, which favors kqueue as well.
https://people.eecs.berkeley.edu/~sangjin/2012/12/21/epoll-vs-kqueue...

Apparently kqueue can handle timers, events, and disk IO. Epoll is limited to sockets, and they've invented new kinds of sockets like eventfd and timerfd so that those things could be polled as though they were sockets. Linux doesn't support AIO for disks/files at all, which is why Posix had to handle it the way they did.

Another review with similar conclusion:
http://austingwalters.com/io-multiplexing/


So yea while I haven't (and can't) use it, kqueue might be the preferable API.

Edited 2016-08-04 23:20 UTC

Reply Score: 2

HAMMER and privacy
by libray on Fri 5th Aug 2016 02:33 UTC
libray
Member since:
2005-08-27

I would love to see a comparison on the HAMMER fs and its default settings against others like zfs and privacy implications. Not from a crypto standpoint, but rather from a standpoint on general knowledge of what that filesystem is doing behind the scenes. When I played around with it in the past, I found default snapshot directories that even though snapshots were eventually turned off, the old files still existed, even after a hammer cleanup. The deleted directories could not be erased. This is not HAMMER 2 I'm talking about.

Reply Score: 4

ThomasFuhringer
Member since:
2007-01-25

It seems to have some technical merits as a server platform.
I wonder if there is any compelling reason on the horizon for it to become an alternative on the desktop.

Reply Score: 2