Matthew Dillon (re?)added a sysctl: vfs.hammer2.cluster_write. It defaults to off, since HAMMER2 already writes a large buffer size and this should, in theory, not be needed. It may improve performance in some situations where there’s a lot of file creation and deletion, but that’s my theoretical guess rather than anything I’ve bennchmarked.
If you haven’t done it before, you can use ‘make rescue’ to build a tiny base system on DragonFly, for use when /usr goes missing, for when your disk is encrypted, and other rather catastrophic problems. It should be in sync with the rest of the system, which is why ‘make rescue’ can be part of a buildworld process. I’m mentioning this because currently, ‘make upgrade’ should be done first.
DragonFly will now run on a Threadripper 2990wx. What’s more, Matthew Dillon has published some testing results showing how power, CPU use, and memory speed all interact with these things. There’s a followup, too. I imagine these are interesting CPUs to most people, since they perform well and don’t have recent Intel-specific security problems.
Intel’s ACPICA 20180810 is now in DragonFly, thanks to Sascha Wildner. Nothing really user-affecting, but it does fix some memory leaks. You can tell it’s very new just by the version number.
Aaron LI has added interface group support in DragonFly, which is mostly to replace having to name individual interfaces in your pf config. There’s more work done than just that commit, incidentally, and he has a better explanation and writeup than my measly post.
If you have a mangled HAMMER2 disk, and you have inodes that are clearly mangled (the built-in CRCs don’t match), you can now remove them manually. This seems like Hole Hawg territory…
The TRIM operation has been in DragonFly for some time, and it looks like most SSDs support it reliably, now – so it’s on by default.
I have been meaning to post this for a while: gridgenerator.com, a painting web app, is running on DragonFly. I was told this on IRC and of course lost all details since then, but that’s fine – go draw something!
A reminder: you need some loader.conf changes if you are booting with EFI/i915.
(Sort of a repost, but someone may need it.)
As part of a recent update to OpenPAM, you can now use ed25519 in pam_ssh. My perception is that ed25519 is one of the better options to pick.
BSDNow 257 (which is not as exciting a number as last week but still prime) has no interview but manages to hit all the right notes – every major BSD is mentioned and also links to recent convention reports.
This is way overdue: I’m now posting Digest notes to bsd.network/@dragonflydigest, a BSD-specific Mastodon server.
It’s bothered me for a while that I’m autoposting Digest headlines to Twitter, which is useful for Twitter users but still supporting a walled garden. Mastodon is a better implementation of a similar idea, and bsd.network nicely groups all sorts of BSD people in one place. Right now I’m just posting the Digest headlines here into the Mastodon account there, but there’s added value from the additional BSD-specific conversation around it.
I haven’t (yet) found a way to translate the local timeline on bsd.network into a RSS feed, which would be super-handy…
As part of a larger conversation about HAMMER, Matthew Dillon noted that he is planning to work on master-to-multiple-slave for HAMMER2, which would function similar to HAMMER1 mirror-stream.
Sascha Wildner has brought in the NetBSD version of mtree(8), as groundwork for some other changes. There’s little user effect at this point, but it’s worth being familiar with mtree as a tool. Take a look at the man page, especially the section on trojan horse detection under EXAMPLES.
DragonFly now has a port of the ena(4) driver from FreeBSD. If you aren’t familiar with it, it’s the Elastic Network Adapter used for running on Amazon EC2. That link for the commit message points at several dports tools useful for anyone wanting to try the next logical step.
I’ve been remiss in noting new DragonFly mirrors, so here’s the most recent: 4 new locations in Ecuador.
Sascha Wildner’s brought in a new rc mechanism that runs scripts on first boot, and only the first boot. It seems like something for an install process, but it’s also preparation for a new network interface.
A little while back I linked to an excellent deep dive into Ravenports, and added my own bit of statistical guessing at popular packages. John Marino wants to know what packages people find most useful/most required. If you have opinions, and I’m sure you do, post something on the Ravenports Google Groups page.
If you are saying to yourself “Gee, what packages did I install and what came in as a dependency?”, here’s an easy way to find out:
pkg query -a '%n %a' | grep 0 | cut -d ' ' -f 1 | less
This lists all “vital” packages, which usually means ones installed with intent, rather than automatically. This might be a useful thing to post for Ravenports…