Category: Goings-on

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!

Just so nobody’s surprised: DragonFly process IDs now go an order of magnitude higher.

Sascha Wildner’s updated ACPICA to a very recent version, which happens to fix a bug in an earlier ACPICA version.

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.

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.

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.

One of the requirements to get NSS/LDAP working on (most) any unixlike system is to have dynamic binaries; meaning they are dependent on various libraries to run.  Since you’re talking about programs for login when you’re talking about NSS/LDAP, that means if the libraries aren’t available, you can’t log in.  DragonFly has static binaries just to avoid that problem.

Francois Tigeot proposed switching to dynamic binaries and building a /rescue directory with static backups, as is the case with I think FreeBSD and NetBSD.  If you follow the thread, it looks like the best path is to use initrd instead.  Initrd stands for INITial Ram Disk, and is the first volume the computer sets up to boot from BIOS.  Since initrd gives the computer enough space to load all the needed modules (like Hammer2…), it works without making the computer dependent on various libraries or having a bloated /rescue directory.

(Someone correct me if I have the details wrong.)  As long as we’re talking about things that would help DragonFly in a larger environment, can someone work on a VM balloon memory driver, too?

bugs.dragonflybsd.org, the bug reporting site for DragonFly, uses Redmine.  It’s been updated and now can take OpenID for your login.

I’ve tagged version 3.6.1 of DragonFly, and built ISO/img files of it.  They should be available by now on mirrors if you need them, or you can just upgrade as normal.   See the linked tag commit message for what’s changed.

As I mentioned on kernel@, I’m going to roll a point release of DragonFly soon.  Push in your changes if you want to get them in!

Antonio Huete put together a list of goals for the next release on the DragonFly bugtracker.  Some of them are pretty ambitious, some of them are relatively easy, but they are all very useful.

Probably because of the C-state changes, Sepherosa Ziehau wants people to use a new set of sysctls instead of the hw.cpu_mwait* ones – at least on x86_64.  This won’t affect you if you aren’t already familiar with them, probably.