John Marino’s made a number of updates to contributed software in DragonFly recently, and here’s the list: libelf (not contrib as John pointed out), libexecinfo, xz, libedit, binutils, grep, tcsh, libdialog, and (tn)ftp.
I think at this point, Sepherosa Ziehau is able to improve the DragonFly network stack by just standing near his computer and concentrating for a few minutes. For example, he’s unearthed another improvement to connect rate/reduction of CPU usage.
John Marino is working on versioning libc, and as part of that process, libc is no longer loaded into executable memory. Here is I think an explanation of lib versioning that may apply, and of course moving things that aren’t supposed to execute, out of executable memory areas, is good for security. There’s more on that topic, too – W^X may be a similar example.
This is a complicated topic that I’m not part of, so suggest better descriptions in the comments, please.
I don’t note it enough, but Tomohiro Kusumi has been making constant updates to HAMMER, the version we have now. Often they are the sort of update that makes the code more readable, or fixes possible problems, and so on. Very essential, but hard to post about it. In any case, I’m using his recent improvements to hammer volume-del to note his contributions, of which there are much more than the day’s worth I link here.
Did you know that AT&T maintains a regex library and test suite? I did not, but now DragonFly has both, in part for better multibyte character support.
(corrected to note that the regex library is not from AT&T – thanks, anonymous commenter)
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.