Francois Tigeot has made a number of updates to the ttm and radeon code, bringing it line with the Linux 4.9 kernel version. If you have a radeon(4)-using video card, you may find this useful.
Also, evergreeen and radeonsi chipset users have acceleration disabled. You may not notice depending on your workload.
There’s been a fresh binary build of dports – and then some more updates to cover a variety of security issues in some of those ports. Now is a good time for a ‘pkg upgrade’.
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.
As an example of how old design decisions have lasting effects, the POSIX standard still calls for terminal output to accommodate mechanical delay, as noted in this DragonFly commit – i.e. if output was still a line printer instead of a glass TTY, or, as it is 99.9% of the time today, xterm or puTTY or etc. etc.
After 56k, I stopped paying attention, but apparently there’s stated baud rates of 460,800 and 921,600. And your DragonFly terminal can handle them, too.
This may be of most interest to me, since I’m usually the one building DragonFly releases. nrelease(7), which is used to build each release of DragonFly, now sticks to the default kernel config, and may use binary packages in the future. There’s some other changes but these are the ones I can describe most exactly; there might be more on the way.
As anyone who has been running HAMMER1 or HAMMER2 has noticed, snapshots and copy on write and infinite history can eat a lot of disk space, even if the actual file volume isn’t changing much. There’s now an ‘emergency mode‘ for HAMMER2, where disk operations can happen even if there isn’t space for the normal history activity. It’s dangerous, in that the normal protections against data loss if power is cut go away, and snapshots created while in this mode will be mangled. So definitely don’t leave it on!