Flame graphs are a way to see what code paths are most used in a stack trace. DragonFly now has a flame_graph utility.
Jails on DragonFly can now route to loopback addresses (i.e. 127.0.0.1). Because of this, they can work like shared IPs and the jail can connect to the host.
I think this means that you no longer have to bind jail services to specific IPs as you did previously. Don’t quote me on that; I’ve run few jails in my life.
Update: I should have linked this too: the sysctl jail.defaults.allow_listen_override that makes it easier in the host system too.
On EFNet #dragonflybsd, Matthew Dillon and ‘mjg’ have been discussing various way to optimize for bulk builds. A recent update from mjg for different memory functions shaved 1.7% off bulk build time – significant, when you are talking tens of thousands of packages.
binutils 2.25 is out, binutils 2.34 is in. The binutils upgrade happened just before the 5.8 branch, so it’s in the 5.8 release – though 2.27 is still the default.
One side effect of repeated package builds is that you start looking at ways to optimize for intense, repeated, parallel software compilation.
Yes, that is ambiguously phrased for fun. Matthew Dillon committed some benchmarks inside rdrand() code to show the actual performance improvements.
This recent commit changes how random number provision is seeded on DragonFly. It sounds interesting, but I don’t know if the performance improvement translates to real-world activity.
tmpfs on DragonFly now clusters writes better, so performance is improved in high-activity environments… which is probably why you are using tmpfs anyway. The post says 2-4x improvement when paging out.
I tagged version 5.8 a few days ago. Release will be soon, but not before this weekend.
I like seeing cross-pollination, as I’ve said before. I really like it turning into informal cross-BSD standards.
Rimvydas Jasinskas has been making DragonFly world buildable on other system. I don’t know what for, but it’s interesting. There are many more commits than the ones I linked.
Random number generation on DragonFly now runs per–CPU, and a bit faster. No real user effect, but randomness is one of those endlessly complex topics that are fun to read about.
libfetch has a vulnerability, now fixed on DragonFly in current and release, plus it also affects FreeBSD.
Sometimes you get 2 nice tips: I like seeing this NetBSD->FreeBSD->DragonFly cross pollination in this commit, and also now I know I can fsck a FAT volume on BSD.
3rd bonus: that last sentence sounds terribly rude.
cpdup(1), a DragonFly copying tool that really should be more used, now uses microseconds for comparison. This is probably related to the sysctl vfs.timestamp_precision also now using microseconds.
This probably won’t affect your usage of cpdup unless you are copying some very actively modified files, but I like to mention it in case someone feels like porting it to OpenBSD/NetBSD – it’s already in FreeBSD, though I assume it’s a slightly older version.
mrouted(8) is removed from DragonFly – but it’s available as a port if you need it.
I didn’t even know the leave(1) program existed, but now it takes slightly more flexible input.
You probably type “du -sh *” reflexively when looking at disk usage, or at least I do. On DragonFly, there’s also a -t option, which gives the simple file size on disk. That’s the amount of data that would need to move when copied; that may differ from other amounts because of compression at the filesystem level.
This recent change in kernel memory use may make booting faster. If you’re running -current, time your boot before and after this change, and see what the difference is. I’m always curious.
A recent implementation of SMAP would cause a panic on some machines; that’s now fixed (including on release). So if you had a panic from ACPI between May and now – please retry.