Rimvydas Jasinskas has added a few options to the buildworld process in DragonFly. These options let you skip rebuilding the compiler and binutils rebuilds, for a significant speedup: buildworld times cut in half.
See his excellent commit message for all the numbers. Note that this is for development work, so it’s not advisable for regular upgrades.
New DragonFly installs are chmod 700 for /root, not 755, from this recent change. Change your existing installation if desired.
If you’ve ever wondered what packages are needed to build a DragonFly release: here they are in one dports metapackage.
I’ve tagged a x.x.1 release – DragonFly 5.2.1, available now. It includes the recently-mentioned fix for CVE-2018-8897 and some other minor updates. See my email to users@ for the details.
Sascha Wildner has brought in the last 9 months of ACPICA updates to DragonFly. This may mean better power or motherboard support for your hardware in DragonFly. I always have a hard time pointing directly to ACPICA updates and how they benefit, but looking at the changelog update may help.
This commit from Bill Yuan says “highspeed lockless in-kernel NAT”, and lists a huge number of changes for ipfw3. How much of a change is it? I don’t know; there isn’t a matching documentation update and I don’t have a way to test.
I like pointing out how political world events push their way into computer updates.
Thanks to Rimvydas Jasinskas, GCC 8.0 has been imported into DragonFly. It’s not built by default, so you’ll need to set WORLD_ALTCOMPILER to get it. Rimvydas mentions this is part of a 3-year upgrade cycle.
Note that he went the extra mile and made sure dports could handle it too.
A recent and new CPU bug, CVE-2018-8897, is fixed in DragonFly. THis applies to both Intel and AMD processors. I’m happy to see that the CERT page lists equal notification timing for a whole lot of operating systems, rather than the few that heard about Spectre/Meltdown early.
Following that topic, Matthew Dillon has “fleshed out” Spectre mitigations, and his commit message details the current state. The sysctl ‘machdep.spectre_mitigation’ will tell you what’s set at any given point.
You can now use Wake On LAN functionality with igb(4) cards in DragonFly.
(I like acronymic titles a little too much, I know.)
systat in DragonFly has gained some new fields when using -pv. Read up on the tool if you have not used it before.
Matthew Dillon’s made some changes to the scheduler, with the result that nice(1) is really vigorous now about enforcing priority.
Here’s something that doesn’t have an immediate impact now, but will be useful down the road: Francois Tigeot has been working on DRM support in DragonFly, and has been quite successful with Intel video support. His strategy has been to adopt Linux methods where possible, to reduce the amount of support work. The payoff has been excellent, and prompt, accelerated video support in DragonFly. The most recent work is “git: drm: Implement parts of the Linux irq subsystem“, which is going to come in handy for someone, I’m sure.
Sascha Wildner has ported FreeBSD’s driver, for LSI Fusion-MPT 3/3.5 SAS controllers. It includes mpr(4), mps(4), and the mpsutil(8)/mprutil(8) management program. It’s in the kernel by default, in fact.
I did not encounter this at all, but if you did: there was an issue in DragonFly around the time of the 5.2 release where device duplication would lead to a machine locking up at boot. It’s fixed.
The short answer: if you have an Areca card (in this case, a model 1222) and multi-terabyte drives, they will work on DragonFly.
IPSEC hasn’t been maintained in basically forever in DragonFly, so it’s been removed. It was only still mentioned in the VKERNEL configs, so if you have a custom VKERNEL config file, remove any mention of IPSEC, IPSEC_ESP, or IPSEC_DEBUG. Otherwise, nothing to worry about.
Reduce, the “second oldest computer algebra system”, has been ported to DragonFly (and there’s work on other BSDs). The post about this has lots of links to more information; if you’re a Maple or Mathematica user, this will definitely interest you.
A ‘dirty’ vnode is a disk data reference that has changed but hasn’t yet been committed to disk. This pair of commits adds a syncing threshold, useful for anyone with slower disk resources. Remember, disks lie.