Sepherosa Ziehau has enabled GSI target CPU auto selection, by default, on x86_64. He says to let him know if there’s problems. I’m not sure what form the problems would take, cause I’m not sure what this does.
Matthew Dillon brought in Adrian Chadd’s sleep state changes for the ath(4) driver from FreeBSD to DragonFly; you may see reduced power usage if you have the appropriate hardware.
libpcap has been updated in DragonFly by Matthew Dillon, and file has been updated by Peter Avalos.
I’ve seen Atlassian Confluence, a Java-based wiki program, in a few places. Atlassian apparently offers their software at a discount (free?) to qualified open source projects. I set up Confluence 5.4 on DragonFly as a test run, and it generally worked. That’s great! I tried to set up version 5.5, and it will not start.
May 08, 2014 7:24:41 PM org.apache.catalina.core.ContainerBase startInternal
SEVERE: A child container failed during start
java.util.concurrent.ExecutionException: java.lang.InternalError: platform not recognized
at java.util.concurrent.FutureTask.report(FutureTask.java:122)
This is annoying. DragonFly (or any BSD) is not supported by Atlassian for Confluence, so it’s not a surprise… but I was so close! Their product has a very nice interface and I was planning to replace Mediawiki at my workplace with it, for some internal documentation. This FreeBSD bug report is the closest fix I can find, but it’s old enough it shouldn’t matter now.
Wojciech Puchar noted with some surprise that DragonFly uses less CPU than expected for high-packet-rate traffic. This has been going on for a while, and apparently Sepherosa Ziehau has even more improvements planned.
The reaction I have heard a number of times from new DragonFly users: hey, this runs really fast, even when I try to load it down!
ATM support is gone in DragonFly, and frankly, I’m surprised it was still there.
Sascha Wildner’s updated ACPICA to version 20140424. Will that help you? Perhaps with newer motherboards; otherwise check the changelog.
The pkg tool, used in DragonFly (and FreeBSD) for ports, is at version 1.2. Version 1.3 will apparently be able to solve the problem where one port is ended and replaced with another. This is a problem that’s been around forever, and I don’t just mean with pkg. I don’t know how soon 1.3 will be out, or what version FreeBSD is at.
Just so nobody’s surprised: DragonFly process IDs now go an order of magnitude higher.
If you’re using DragonFly in qemu, virtualbox, whatever – but not VMWare – there’s a new virtio-net driver to try out.
The March issue of BSD Magazine is out, and this month has an article written by Siju George about how his company is using DragonFly and Hammer for backups.
Remember: If you have a particular port that’s not building in DragonFly, there may be a patch in pkgsrc that could be brought over, as John Marino points out.
Sascha Wildner’s updated ACPICA to a very recent version, which happens to fix a bug in an earlier ACPICA version.
Here’s the announcement from Francois Tigeot: DragonFly now uses dynamic binaries in the root filesystem. You will need to do a full buildworld/buildkernel if on 3.7 and upgrading.
DragonFly now has a ‘rescue’ system added in, which also functions as a way to mount encrypted filesystems. Does PAM work yet? I don’t know; I may be linking to this earlier than I need to.
Release 3.6.2 of DragonFly has been tagged, and ISO/img files are available. This includes an updated OpenSSL for Heartbleed problems. Here’s the changelog. You can, if you haven’t already, update your existing 3.6 systems the normal way.
All the dragonflybsd.org sites (www, bugs, gitweb, lists, leaf) should be available via https now, thanks to a wildcard certificate from InterNetX. Also, all the machines have an up-to-date version (1.0.1g) of OpenSSL installed to prevent the Heartbleed issue.
I’ve wanted more support for virtualized DragonFly systems. Sascha Wildner put together an experimental balloon memory driver to test out, and I ran it on two virtual machines separately, one with it loaded and one without, on the same host system. The problem is, I can’t tell what it does. The two machine reported almost the exact same RAM usage during a buildworld.
Any VMWare/virtualization experts out there able to tell me what needs to be tested to verify this?