A running description of activity related to DragonFly BSD.
Matthew Dillon’s been using a Kabylake NUC for a DragonFly workstation and it’s generally working out well. It’s tiny enough to lose on a desk, in my opinion. He added performance details and a screenshot. The Specific Configs page has his notes, recorded, too.
Related laptop tip: If you have a Lenovo Yoga and can’t mount the drive after install, various sdhci modules may be the answer. Update: definitely the answer.
Sepherosa Ziehau has made some improvements to ipfw in DragonFly, moving it to per-CPU state tracking among other things. (I haven’t mentioned just ipfw in foreeeever.)
His commit message describes the improvements. Of most interest: it reduces the performance impact of running ipfw in his tests to almost nothing. Does this translate to ipfw on other BSDs? I don’t know.
Francois Tigeot is going to be giving a talk about the DragonFly graphics stack at EuroBSDCon 2017. (14:00 September 21st in Paris) Registration is already closed because I didn’t realize how soon it was happening – sorry!
Here’s a detailed writeup from Aaron LI on how to get a DragonFly system onto an IPv6 network.
Update: He also supplied an example pf ruleset that solved some IPv6 throughput problems for his VPS.
Pulled from a longer thread: x.x.1 update instructions for DragonFly.
Probably old hat to most readers, but I like to see this documented, and the hw.ncpu ‘trick’ is nice.
There will be a bootable, single-image version of HAMMER2 in the next DragonFly release. Matthew Dillon has a note about what will be in place at that point, and you can always look at the recent commits.
This happened a while ago, and I’m just catching up to it: the virtio_scsi(4) driver has been added to DragonFly; ported from FreeBSD and worked on by a number of people. ‘man virtio‘ if you want background.
“gee, we have a 6-digit PID, might as well make it work to a million!”
Here’s the first of several commits to support this, and here’s the highest load averages I’ve ever seen.
If you are running DragonFly on a Ryzen CPU, this commit will fix (work around?) a hardware bug. I have not looked at how other operating systems may be addressing it, but it may be interesting to contrast.
I should have linked this yesterday: a description of kcollect and its uses from Matthew Dillon, complete with example graph of a very busy machine.
There’s a new facility in DragonFly: kcollect(8). It holds automatically-collected kernel data for about the last day, and can output to gnuplot. Note the automatic collection part; your system will always be able to tell you about weirdness – assuming that weirdness extends to one of the features kcollect tracks. Here’s some of the commits.
The DragonFly Go builder needs a new maintainer, and an update to a newer builder. Are there any people out there interested in Go who want to do the work? I do not have time.
DragonFly 4.8 has been updated to 4.8.1, bringing in a lot of small fixes. Improved Intel video support and the virtio_scsi driver will be of most interest, I think. The 4.8.1 tag commit has all the details. You can update the normal way, and if you need an install image, I’ve uploaded them and they should appear at your local mirror.
Remember the firmware in userland idea I linked to before? Here’s the written plan/proposal.
Matthew Dillon’s found a solution to the problem of hardlinks in HAMMER2, and so moved on to dirents. The design document has a significant update to match.
If you’ve got a Skylake CPU, setting P state won’t save you as much energy as powerd(8)‘s -c option, according to Sepherosa Ziehau.
sshlockout(8) will now lock out based on number of attempts, just so that you don’t have huge logs of stubborn but stupid SSH brute force attacks.
Ján Su?an has posted some ideas about handling firmware in userland, in DragonFly. I’d like to see it happen.
If you’ve had odd behavior with node.js (which I have) on DragonFly, it may be fixed now.