A running description of activity related to DragonFly BSD.
Apparently a commit that I can’t find (“e8de9e9“?) disabled acceleration for R5 240 Radeon cards, but causes an error for R7 models. If you’ve got an R5 and you want accelerated video, try taking it out – assuming it’s not working already. Any other Radeon model, it may not make a difference.
Update: Pierre Alain-TORET found the correct commit.
If you think about the name, you’ll realize what it does: libpasswdqc(8) does quality checks on passwords via PAM, and now it’s in DragonFly.
The headline says almost everything, in this case. There’s a HOWTO for DragonFly NVMM which should get most of what you want to do, and I’m sure it will be updated.
Here’s something I just learned: If you are running dma(8), /etc/dma.conf will contain MAILNAME. If your email server is somewhere else, but you set MAILNAME as your domain – dma will deliver locally.
I had /etc/dma.conf set with MAILNAME shiningsilence.com – so dma kept delivering overnight periodic results to root, which was aliased to justin@shiningsilence.com in /etc/mail/aliases and so it was delivered to ‘justin’ locally on the machine.
Changing MAILNAME to www.shiningsilence.com – the host you are reading right now – fixed the problem. Now, whether this was an automatically set config or something I misconfigured some years ago… I can’t tell.
boot and libstand directories are moved to src/stand/boot on DragonFly. This won’t affect most people, as you’ll upgrade and build the same way as always, but if you were specifically looking for it in the old locations of sys/boot and lib/libstand, you’d be surprised.
I didn’t know about this, but there’s a daily/weekly/monthly/security_show_badconfig option in periodic.conf that is now defaulting to “yes” in DragonFly. This I assume means you’ll get the output of erroring periodic scripts sent to you. Useful, especially if you find out about an error you hadn’t seen before.
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.