The vi in any BSD is not the original Berkeley vi – instead it’s usually nvi. However, thanks to John Marino, DragonFly has the up-to-date, multibyte-supporting nvi2. (I know I’ve made reference to the nv/nvi difference before.)
If you are running DragonFly-master, there have been fixes for a wrong uname (my fault) and initrd image booting with encrypted drives. Update if you are running on the bleeding edge, if you haven’t already.
I’m globbing these DragonFly updates together in a single post because I’m running behind:
ACPICA was updated to Intel’s newest version: 20150717.
GCC in DragonFly was updated to the 5.2 release.
DragonFly DRM (that’s Direct Rendering) now supports ValleyView chipsets.
hostapd, for creating a wireless access point, has been included in DragonFly along with wpa_supplicant, for a long time. Like wpa_supplicant, there’s a version in dports that is the latest version and is easier to update (e.g. no system update required to get a newer version.) Unlike wpa_supplicant, there’s no chicken-and-egg installation problem if it’s not in the base system – so out it goes.
There’s yet another security problem with OpenSSL, and it’s been updated in DragonFly. I’ll probably roll 4.2.2 this weekend so that it’s in the release image.
The more eagle-eyed may have noticed a branching for DragonFly 4.2, and for DragonFly 4.0.6. The 4.2 branch is currently only a release candidate, so don’t necessarily change over yet – it’s for testing, not release. Note that packages for 4.2 are not yet built, so you’ll have to manually specify a package path to install with pkg on 4.2 – for now.. That won’t be the case for the actual release, of course. DragonFly 4.3 users will have to specify PKG_PATH manually to use 4.2 images until new ones are built. 4.2 release candidate users will be fine. (see comments for correction.)
The 4.0.6 release is mostly to get the recent OpenSSL update into a 4.0.x build.
I am working on image building for both.
Even sysctl accesses can be made to handle multiprocessor environments. This can actually make a difference when you’ve got a lot of processors building a lot of software, as in all of dports.
From IRC today:
“19:43 <@dillon> I’m bored at the moment. lemme try to speed up module builds“
Buildkernel, depending on your processor count, now may have tripled in speed.
Those changes I mentioned yesterday for text console support? They’re in DragonFly-master now, along with a loader tunable to turn it on and off.
If you’re using nginx on DragonFly, version 1.9.1 has specific DragonFly speedup options built in.
Hammer 2 now uses LZ4 compression by default. It also uses a new CRC algorithm that performs much better, and there’s numbers to prove it. It helps iSCSI too. When I say new, it appears to be from the 1980s? I may be looking at the wrong place.
Matthew Dillon has been doing a lot of Hammer 2 work lately. Well, he’s been doing it for quite some time, but the recent commits contain the sort of things that are easier to link to, like deletion speedups, freemap changes, and stats tracking/compression results.
Hammer will perform daily housekeeping tasks each night. If you’re up late enough, it may kick off while you are working. If you want to stop the process after it’s already started (since it’s disk-intensive), John Marino has added the ‘abort-cleanup‘ command.
Experimental automatic crypting of swap is now available in DragonFly-master. Recently added, though it may have been possible another way.
Sepherosa Ziehau has introduced a new sysctl:
net.link.ether.inet.log_arp_creation_failure
Set this to zero and you won’t get endless ARP events from networks you aren’t on. For example, I’m hooked up to a cable modem. I only get a public routable IP address, but the network used for the cable modem network itself bleeds ARP packets out where my DragonFly machine can see it. Since it’s on a different network segment than the address I receive through DHCP, it always fails and the system logs it. For example:
May 11 05:20:52 www kernel: arplookup 100.68.112.145 failed: host is not on local network
I can’t do much about it since that layer 2 leakiness is going to happen, but I can shut it up with this sysctl – and thank goodness, cause I’ve been seeing these messages since first using a DOCSIS modem in… 2001 or so?
Tomohiro Kusumi has been quietly making a lot of commits to Hammer. I haven’t been linking them because they don’t necessarily equate to new features, but here’s an recent exception: the -A argument will make your Hammer command run on every PFS. It only affects reblocking/rebalancing – for now.
You can now export Hammer slave volumes as NFS mounts – but since slave volumes are updated from master, you’re mounting a snapshot of that point in time. That may actually be an advantage.
DragonFly builds two compilers by default. If you weren’t interesting in building both, there were switches to build only the default, like NO_GCC47. This changed with every compiler update.
With the switch to GCC 5, the new switch is “NO_ALTCOMPILER”. That will last through compiler changes. I’m mentioning this now because sooner or later, you’ll want to gain back some time on a buildworld.
The most recent (well, this is the mostest recent) update of ACPICA for DragonFly, by Sascha Wildner, is different from the usual import: it happens to include actual upstream support for DragonFly