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.
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.
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.
If you’ve ever been left watching a “press any key…” line at shutdown of your DragonFly system, there’s now a fix. It’s committed to release, too, so it’s available now.
While you’re at it, there’s a HAMMER2 bugfix that will also be brought in by updating.
It hasn’t been updated or used for some time, but libc_r was 20+ years old. Now it’s gone. You know someone younger than this code, or maybe even younger than the last time I talked about it.
If you are like me, you’ve typed “make buildworld && make buildkernel && make installkernel …” about a zillion times. Now, you can encapsulate that process in a shorter statement: ‘make build-all install-all‘. The real benefit is these new steps also run in parallel to match the number of CPUs present, and logs to file instead of the console, automatically.
Some of the larger application sets on DragonFly have had trouble building, and inconsistent problems with that build. i.e. rust would fail, but in different parts of the build process, every time. It looks to be a problem with signal interaction, and there’s now much safer ways to do that on DragonFly.
That is going to require a full buildworld/buildkernel if you are on DragonFly-master, 5.7. Release/5.6 users are unaffected.
I link because they are good: 10% speedup. Or, because they made me laugh: “Basically, don’t use this.”