If you’re upgrading to the latest dports, and you use tmux – don’t update that particular port yet.
Since DragonFly 6.x is a major number change, there’s no prebuilt packages that match that release number. As of this writing, the mirror master site shows 5.10 packages, which would work… if that was the next release. That’s where the number change trips it up. There should be new 6.x packages in the next few days. (Thanks to Jan Peter Vogt for the reminder)
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.
There’s commits being made in DragonFly that will break binary compatibility. If you are running DragonFly-master, that means you will need to do a full buildworld/buildkernel when updating, and you will either have to rebuild packages or wait some days until a new set are built.
If you are running the 5.6 release, you are unaffected.
DragonFly’s tcp keepalive was changed from milliseconds to seconds. This happened in both DragonFly-current and in the 5.6 release, and it changes the networking API, which means a dports rebuild is needed… or a pkg upgrade, for which happily all packages have been rebuilt. So, on your next update of the system, be sure to update packages too.
OPIE was disabled recently in DragonFly. Now that the 5.6 release is out, it has been removed. This may require manual intervention if you are on DragonFly-master (i.e. 5.5. or 5.7) and update in the next day or two. This need to fiddle with it will go away soon with changes to ‘make upgrade’; I will mention it when I see it.
This won’t affect anyone running 5.4 or 5.6. It’s only in development.
It’s possible to have data corrupted on a HAMMER2 volume during a specific combination of a bulkfree operation and a lot of writing to disk. Matthew Dillon has a potential fix already. As he announced, it’s scheduled to go into 5.4 this weekend. It’s a rare bug, but if you want to check for it, look for CHECK FAIL entries in /var/log/messages.
And because every cloud has a silver lining: some not-yet-quantified performance improvements.
It’s turned off and on by the sysctl machdep.isolated_user_pmap – and defaults to on for Intel CPUs. Buildworld tests show about a 4-5% performance hit, but that’s only one form of activity, measured, so there will surely be other effects.
Note that Spectre is not mitigated by this commit series, and as I understand it, cannot be realistically fixed in software.
Update: Matthew Dillon posted a summary to users@.
Update 2: He told us so.
SSH in DragonFly 5, by default, does not make a password authentication request on outgoing ssh sessions. You can manually add the option or change the config. Or use public keys, which is really the best idea if at all possible.
DragonFly 4.8 has been updated to 4.8.1, bringing in a lot of small fixes. Improved Intel video support and the virtio_scsi driver will be of most interest, I think. The 4.8.1 tag commit has all the details. You can update the normal way, and if you need an install image, I’ve uploaded them and they should appear at your local mirror.