You should perform a full world and kernel install if on master.
Several people (including me) have been getting bit by a problem: when performing an installworld with a changed kernel, the vn kernel module is loaded, but it was built by the previous kernel and may cause problems when it doesn’t match up.
To fix that, vn is now built in, instead of being a separate module. The rescue initrd (which is what is being mounted when it has this problem) is now installed via a ‘make rescue‘ command that can wait until a successful installworld and reboot.
If you are tracking DragonFly master, your next kernel build should be full, not quick.
It took me a little while, but DragonFly 3.8.2 images are uploaded now to the main site. Check the 3.8.2 changelog if you didn’t before. This is a recommended upgrade for the newer OpenSSL, and should otherwise have little impact on the programs you have installed.
I’ve tagged DragonFly 3.8.2, which exists mostly to accommodate the latest release of OpenSSL. (Security fixes, which should not be a surprise.) I will build images as soon as I get a chance.
If you have a particular favorite thing in DragonFly, Damian Vincino would like to know about it.
Rust has been ported to DragonFly by Michael Neumann. His blog has implementation details, and you can pull from his repo to get a buildable version. This may be useful, as he notes, for anyone wanting to build Rust on other BSDs.
Thanks to Nicolas Thery, there’s a POSIX semaphore test suite on DragonFly, ported from FreeBSD. Anyone want to integrate it into dfregress?
There’s a recently talked about bug in SYSRET that apparently affects a lot of operating systems, including Linux and several BSDs. It looks like DragonFly is not affected, but Matthew Dillon has put in changes just in case.
The portable (meaning ready to be brought into other operating systems) version of LibreSSL is out.
Some dports packages can’t be installed in combination with others. The easy way to find the conflict without doing the install? Look for CONFLICTS= in the Makefile. If you don’t have the dports tree on disk, you can always look online.
If you’re looking to use LDAP on DragonFly, follow this thread (read the first, keep going) as people talk about implementing it, what they installed, etc. I haven’t tried it myself, yet.
ACPICA has been updated by Sascha Wildner to version 20140627, which as you can guess from the version, is the most recent. See the included changelog for what’s different.
Another ‘quiet’ week – lots of commit activity in the other BSDs, but not a lot to point at directly.
I have a backlog from stuff I missed last week while traveling, so we all benefit!
I tagged DragonFly 3.6.3, at Sascha Wildner’s suggestion. Why do that when there’s a 3.8.1 out? This way there’s a version of 3.6 that has all the fixes included, including the recent OpenSSL updates. This ‘final versioning’ should probably be done for every release. I’ll work on final images.
The 3.8.1 tag was planned for tonight; I’m waiting to find out if there needs to be a new set of binary ports for 3.8.1 before I tag.
I tagged DragonFly 3.8.1; you can see a list of the changes in the tag message. New images are built. If you are already running 3.8.0, a normal
make src-update and rebuild will get you everything.
Matthew Dillon posted a note about the next point release of DragonFly, coming within a few days. Chunks of it like the recent OpenSSL and Sendmail fixes are already on the 3.8 branch.
I assume I’ll be the one rolling it, and I plan to put together a 3.6.3 tag too, just so there’s a final version of 3.6 that has all changes rolled up.
Sascha Wildner has removed some drivers in the x86_64 config. This will only really affect you if you use a custom kernel and still have entries for those drivers in the config file.
Thanks to Markus Pfeiffer, there is now a locking(9) man page for use the next time you say, “Which is the right lock to use?” Something I see almost monthly.
There were more problems found in OpenSSL… right after release of DragonFly 3.8. OpenSSL 1.0.1h has been committed, thanks to Robin Hahling and Sascha Wildner. I’ll be rolling a 3.8.1 release soon.
If you are saying “Hey, what about LibreSSL? And do I write it LibReSSL?”, it’s not set up as a portable release yet. Also, I don’t know the correct capitalization, either. There is some debate about the lack of notification from OpenSSL to LibreSSL, though other vendors were notified days before.
BSDNow 040 has an interview with Karl Lehenbauer at FlightAware, a tutorial on OpenBSD’s packaging system, and more from BSDCan 2014.
The 3.8 release of DragonFly is out! See the release page for a changelog and check your local mirror for download first.
Binary dports packages for 3.8 have been built; they are available for download. (link goes to release versions of the packages. Future updates will be in ../LATEST)
For upgrades from 3.6: You can pull the 3.8 source normally with git:
git fetch origin
git branch DragonFly_RELEASE_3_8 origin/DragonFly_RELEASE_3_8
git checkout DragonFly_RELEASE_3_8
Assuming you are using an unmodified kernel, here’s the steps I usually do for an upgrade:
# make buildworld && make buildkernel && make installkernel && make installworld && make upgrade
After upgrading from 3.6, pkg (as designed) will download the appropriate 3.8 packages with
NYCBUG is having a meeting tomorrow night with the theme “Cloud and Colocation“. However! Suspenders, the usual restaurant location, has closed. (Aw, I liked it) This meeting is happening at the About.com offices, which means you can’t just show up – send email if you plan to attend.
I put together a second release candidate for DragonFly 3.8, and it’s uploading now. The reason is that I goofed up the pkg build - Sascha Wildner has hopefully made that harder for me to screw up now.
Release is still planned for the 4th.
Thanks to John Marino and people I don’t know the name of in the gcc project, DragonFly is now part of the gcc test suite.
“What about clang?” you say? We’re not picky; DragonFly works with either.
I’ve branched DragonFly 3.8, and tagged a release candidate. Please try the release candidate if you can. I have links in my post to users@/kernel@. Don’t forget the remaining issues! Planned release date is June 4th.
Normally I’d save this for the In Other BSDs weekend item, but the time horizon is too short: Theo De Raadt and Bob Beck are giving a last-minute LibreSSL talk tonight at the Calgary UNIX Users Group meeting at 5:30 PM. See www.cuug.ab.ca for the location.
The slides from Francois Tigeot’s talk about benchmarking DragonFly with PostgreSQL are now online – link is to a PDF.
We’re due for the next release of DragonFly. I’ve posted the two-week warning to kernel@. As I noted in that post, please look at the list of issues for the release and see what you can close.
Francois Tigeot is giving a talk tomorrow on benchmarking DragonFly using PostgreSQL, at PGCon 2014. PGCon is the PostgreSQL convention happening immediately after BSDCan in the same location, in case you didn’t know already.
Imre Vadasz is our newest DragonFly committer. Welcome, Imre!
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
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.
NYCBUG has a presentation from John Baldwin, happening on the 7th (tomorrow!), all about Bhyve, the BSD hypervisor.
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!
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.
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?
If you noticed the lack of a GUI DVD image for the 3.6 release of DragonFly, I posted a followup note on the users@ list that talks about the steps to get X installed. It’s not much work, with pkg set up.
Normally I’d save this for Lazy Reading, but I’m indirectly involved: the Rochester Institute of Technology now has a minor in Open Source and Free Culture. Here’s the press release. I taught one of the precursor classes, Humanitarian Free/Open Source Development (essentially open source development methods) last spring. Steve Jacobs was my advisor years ago and Remy Decausemaker was my (best) student from the HFOSS class. In any case, the courses are definitely worth it. (via)
bugs.dragonflybsd.org, the bug reporting site for DragonFly, uses Redmine. It’s been updated and now can take OpenID for your login.
pfi, the automated installer that nobody knows about, now supports installing an authorized_keys file as part of an install. Credit goes to Alex Hornung for adding the functionality.
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.
Recent updates to tzcode apparently fixed a long-standing time zone bug in DragonFly. POSIX says the America/New_York timezone is picked as default if nothing else has been selected. That didn’t happen in DragonFly – until recently. If your timezone seemed to suddenly jump to U.S. Eastern time, that’s because you never picked before.
Antonio Huete set up a DragonFly status page on status.io.
Address Space Layout Randomization, since 2010. Carsten Mattner asked, and Alex Hornung answered. (Set the sysctl vm.randomize_mmap to 1 to enable it.)
If you want to test out the latest (20131218) update to ACPICA, Sepherosa Ziehau’s got a patch for you.
This will be good for anyone who wants to use less electricity. (updated to reflect this doesn’t enable deeper C-states as I thought it did.)
Matthew Dillon acquired one of the Acer c720 Chromebooks recently. There were changes needed for the boot process, for the keyboard, an update from FreeBSD for the ath(4) wireless (g), smbus, and trackpad… but it works now, and he detailed exactly how to get it running, and even upgrade the drive.
John Marino has moved DragonFly from binutils 2.22 to 2.24. I think this may require a full buildworld when upgrading… not sure. Anyway, binutils has a changelog if you are curious.
This post from Konrad Neuwirth asking how to do a minimal installation of DragonFly led to this list of all the ‘knobs’ you can set to make your installation smaller, from John Marino. (And your buildworld faster, if that’s appealing to you.) I also pointed at rconfig and PFI, which are criminally underdocumented.
pkg 1.2 is coming out. This brings a number of new features, but as John Marino posted, you may want to delete your old pkg.conf to keep the new version from complaining about an old config file. This upgrade is a step on the way to signed packages, which is a Good Idea.
Remember the ‘mini roadmap’, mentioned
last week yesterday? John Marino put together a Google Docs spreadsheet to track the task status; several items are already cleared off. Take a look and tackle a task.
John Marino posted a possible ‘roadmap’ for DragonFly, now that we’re past the 3.6 release. The thread went on for some ways as it was discussed, including my crazy ideas. Notably, several suggested items have already been tackled – an iwn(4) upgrade has already happened, and an update to bmake, based on John’s vendor branch update instructions.
This is a little old, but Matthew Dillon noted the status of his Hammer2 work a little while ago. Some highlights: he’s intending Hammer2 to be usable on a single host by the time of the next DragonFly release (summer 2014), the Summer of Code project for compression has already been integrated, and he listed different parts of the work that may be interesting for anyone wanting to chip in.
Slightly related: Matt posted some Hammer2 comments on the DragonFly 3.6 release story on Slashdot that may be interesting. Don’t bother reading the other comments; they’ll make your eyeballs bleed.
Eitan Adler is the newest DragonFly committer; you may recognize his name from some previous commits added by others, where he synced up various work between the BSDs.
The 3.6 release of DragonFly is available now. I just put up those images last night, so if your favorite mirror doesn’t have it, give it a few hours.
For those updating from 3.4 to 3.6: there’s an ABI change, so you will have to upgrade all your packages. If you’re using pkgsrc and ready to switch to dports, now’s the time. If you already switched to dports on your 3.4 system, binary packages for 3.6 have already been built and you can use pkg to upgrade.
Also for upgrades from 3.4: You can pull the 3.6 source normally:
git fetch origin
git branch DragonFly_RELEASE_3_6 origin/DragonFly_RELEASE_3_6
git checkout DragonFly_RELEASE_3_6
But there’s a slight change needed for the 3.4 to 3.6 transition: an extra reboot in the build process:
# make buildworld && make buildkernel && make installkernel && make installworld && reboot
# make upgrade
This is all noted in /usr/src/UPDATING and in the release notes, but I’m taking no chances.
As noted on the kernel@ list, it’s tagged but not yet in image form.
Matthew Dillon did some more performance tuning for DragonFly. I’ll just pull a paragraph from the commit message, since that will have more impact than anything I say:
Improves fork/exec concurrency on monster of static binaries from 14200/sec to 55000/sec+. For dynamic binaries improve from around 2500/sec to 9000/sec or so (48 cores fork/exec’ing different dynamic binaries). For the same dynamic binary it’s more around 5000/sec or so.
“monster” is a 48-core machine used for testing.
DragonFly developer Francois Tigeot was interviewed on linuxfr.org. As you can probably guess from the names, it’s a French site, but don’t let that stop you if you’re an Anglophone.
The venerable (from 1979!) program, lpr, has been superseded by CUPS in many installations. Francois Tigeot suggested removing it, but it’s still directly usable in specific situations and easier to just shift out of the way. It’s staying, but it’s interesting to see how it still gets used.
Update: Predrag Punosevac has descriptions of the various tools involved.
I’m planning to branch DragonFly 3.6 this weekend. The actual release will come 2 weeks later. (Ignore what I wrote about a dports installer/image.)
Joris Giovannangeli, who worked on porting Capsicum to DragonFly for Summer of Code 2013, is continuing his work. He’s posted a detailed note on how to do capability management in a new way, with it retaining compatibility with FreeBSD’s capsicum implementation.
Matthew Dillon has gone after reducing contention and improving SMP performance as vigorously as possible, using dports builds on a 48-processor machine as a test. The machine’s building more than 1000 packages an hour, last I saw on IRC.
John Marino has updated ldns and drill to version 1.6.16.
There is a search plugin for Mozilla that searches DragonFly man pages. (Thanks Samuel Greear)
I got some PC-BSD items this week, too.
The pkgsrc repository in git for DragonFly is currently frozen. This is because many people have switched over to dports, and also because it’s a lot of work to keep it functional. If you do want to pull newer pkgsrc material, use cvs and grab it from a NetBSD server.
As the message notes, don’t go switching to DragonFly-current right now, cause there’s a lot of new material in there and it may not be quite safe. (There’s an ABI change that will require all new builds of your ports, for instance.)
BSD Now episode 4 is out, though you have to look at the episodes page to find it right now. It has an interview with Devin Teske of FreeBSD. The usual other commentary isn’t there, probably to make room for Devin’s completely awesome beard.
Antonio Huete Jimenez has added a new rconfig script that automatically mirrors the installed disks with ccd(4). You don’t remember what to do with rconfig(8)? Automatically (and headlessly) install DragonFly, of course! There’s already other examples – they’re just shell scripts.
I put together a list of what I’m thinking could be in the next DragonFly release. Going by our regular schedule, that’s a bit more than a month off. Of note: Summer of Code material and defaulting to dports. Follow the thread for more.
ZFS was originally created at Sun and open sourced. Sun was absorbed by Oracle and stopped being open (or even really existing), so ZFS was taken up by several separate groups – FreeBSD and Illumos being two examples. OpenZFS has been announced, in part to provide common reference for other platforms that might implement it and probably to avoid capability fragmentation. It’s certainly a good idea.
(If I have my history wrong, please correct me.)
DragonFly has two included compilers – GCC 4.4, and GCC 4.7. Traditionally, we switch from one compiler to the other as default, and then replace the old one with a newer release, and so on.
Until recently, dports built almost exclusively using GCC 4.4. John Marino’s switching to GCC 4.7, for a variety of reasons he lists in a recent post to users@. An interesting point that he raises: GCC 4.4 won’t necessarily be replaced with a newer GCC, but perhaps clang?