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?
Francois Tigeot’s rescue ramdisk work is ready for testing. You can pull it directly from his repo and try it out. It’s surprising how small the ramdisk can be crunched.
Note: he now has a newer branch than what is in that linked message.
You know what always makes me happy? When someone shows up out of the blue and says “Here; I did this cause I needed it; everyone can share.” The latest example of that is Imre Vadasz porting bwn(4), for the Broadcom BCM43xx wireless chipset over from FreeBSD to DragonFly.
In a thread about video cards on DragonFly, Francois Tigeot listed good ATI cards to try, and pointed out the VESA driver is probably your best bet right now with NVidia cards.
The acpi_thinkpad module (section? code?) has been updated. Update if you are on DragonFly 3.7, or be patient if you are on 3.6.
I wrote up some thoughts for the next release of DragonFly. There’s some project work in there for anyone interested. The next release should be near the end of May.