This is minor, but I’ll mention it because it might bite you someday: if you are using powerd to minimize CPU power usage, and also trying to push a high data rate through your serial port, you might drop characters. It’s mentioned in the powerd(8) man page, which has an entertaining bugs section.
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 have an Elantech touchpad IC type 15 on your laptop (and you do if it’s a ThinkPad L480 or Huawei Magicbook), it’s now supported in DragonFly. Thanks to K Staring for the fix.
The i915(4) driver now supports some newer models of Intel GPU, thanks to Francois Tigeot.
Synth logs for dports are now located here on a new machine:
https://sting.dragonflybsd.org/dports/logs/Report/
If there’s only a short list, it’s because the most recent build was probably focused on retrying a broken-but-now-possibly-fixed package. I link both because of the utility and also because the interface is pretty.
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.
I sorta like seeing these things ricochet back and forth.
If you have newer AMD hardware, it’s a little better supported now.
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’.
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.”
Remember how I said dsynth defaults to txz (tarred, XZipped) ? I was apparently wrong and it was using tgz (tarred, gnuzipped). Now it really truly defaults to txz, for space.
There’s a vulnerability in file(1), CVE-2019-18218. It’s fixed in current and release versions of DragonFly. Update when you get a chance.
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.