ndis(4) is removed from DragonFly; it’s probably been years since it was applicable to any hardware. I don’t think it will affect anyone – but it’s an interesting tool from a historical perspective; for a while it was possible to use Windows XP drivers to create a BSD network driver, effectively.
Many, many times over the years I have tried answering problems with “… and maybe something’s wrong with the RAM?”, which is always possible but not always probable. For once, it’s really what happened in this story of strange HAMMER2 errors.
Here’s a link to a commit for dsynth that gives an idea of how huge a debug build of chromium can be.
This note from James Cook describes how to get Wireguard functioning on DragonFly; his linked patch is not necessary at this point since it’s been committed to dports – though not in the latest binaries.
Nelson H. F. Beebe posted links to two ACM articles; one about SSDs and the other about filesystem resilience. Matthew Dillon chimed in with his thoughts specifically on HAMMER2.
Thanks to yrabbit, there’s a full FPGA toolchain possible on DragonFly. It’s preliminary, but it works.
I’m actually some days late in reporting this, but there’s a new full build of packages for DragonFly 6.0; it’s following the quarterly release schedule for ports, so 2021Q2 is the base.
This goes with the recent merges from -current into 6.0. Now is a good time to update your system completely, if you have not already.
If you’ve got unshielded disk cables in a tiny PC, you can run the AHCI link a bit slower to better handle interference.
Matthew Dillon’s fixed a possible deadlock in HAMMER2, plus some optimizations that I can’t quantify, but are fun to read about.
If you like csh/tcsh, and also Emacs, there’s a eLisp file to put Emacs in csh script mode, now in DragonFly.
(Someone who uses Emacs more than me tell me if I have a wrong description.)
You may run into a setup issue with Wireguard when trying to set it up on DragonFly. Keep an eye on this Go bug report if so.
Update: here’s a solution in the works.
The drivers amdsmn(4) and amdtemp(4) have received several updates. The output still may have issues, but this is useful if you have newer AMD hardware.
It’s worth saying because people don’t realize it: In-code documentation updates, even if the code itself isn’t changed, is a worthwhile way to contribute.
If you have an AR9485 wireless adapter, this bug report notes the appropriate config for DragonFly. Might work for other hardware too?
This query had karu.pruun write a short note on how to contribute (device driver) development work to DragonFly. Don’t forget grok.
If you are one of those unlucky/foolhardy people running DragonFly with very little RAM, this maxvnodes change will help you out.
(DragonFly is not that RAM-hungry in normal circumstances, anyway; 1-2G is ‘safe’, last I knew.)