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.
If you’re planning to run DragonFly in KVM, remember this post from Matthew Dillon, giving the settings he uses. This will save you a bit of time.
If you’re upgrading dports (and you probably are if you are going from DragonFly 3.4 to 3.6), there’s a minor issue in dports, inherited from FreeBSD ports: you need to manually remove perl before upgrading. It’s all of one command, so it’s not a huge burden. Joris Giovanngeli spotted it first.
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:
cd /usr/src
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.
Predrag Punosevac asked for good fileserver examples. Several people answered, including me – the best answer is from Francois Tigeot, but there’s discussion of IPMI support in the thread.
Related: I wonder if the Backblaze Storage Pod would work for DragonFly?
John Marino isn’t interested in supporting the i386 architeecture for DragonFly and dports, so he’s not going to actively work on it. (Packages for DragonFly 3.6 are already built, so that’s not a problem for release.) If you feel like taking on a significant but interesting workload, check his message about the work involved.
BSDNow episode 11 is up, with conversations about OpenSSH, FUSE, building an OpenBSD router, etc… and a whole hour of me talking about the upcoming DragonFly 3.6 release and this very Digest, too!
I just finished a whole hour of gabbing on about DragonFly and BSD work in general for BSDNow. Because I am a ninny, I didn’t post something here earlier today so that people would know to watch the livestream. Sorry! However, it should be showing up in the next day or so on the BSDNow site. When it does, I’ll link it.
Not sure why, but there wasn’t a lot of things this week to pick out.
- A short discussion of Perfect Forward Secrecy on pkgsrc-users.
- PC-BSD apparently (used to) play a movie on first boot.
- FreeBSD now has a ‘mini-memstick‘ install option. (a later messages says ~200M in size.)
- FreeBSD has updated aacraid.
- OpenBSD supports the RTS5229 card reader in rtsx(4).
- OpenBSD has updated OpenSSH, and NetBSD has updated. (DragonFly has a fix for the underlying problem.)
- OpenBSD has FUSE support.
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.
Branched, not released. The release should happen in two weeks. One major bug has been squished, and remember the upgrade process from 3.4 to 3.6 is a little different from normal.
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.
Multiple transmission queues are possible for the mxge(4) driver; I’m mentioning it because Sepherosa Ziehau’s post about this describes the exact tunables to configure this.
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.)
Matthew Dillon wrote a roundup post summarizing all the changes he’s made to DragonFly to improve SMP performance in the last few weeks. He’s removed almost all contention from DragonFly. This means better performance, scaling upward depending on the number of processors.
‘monster’, the system that builds all 20,000 items in dports, can complete the run in 15 hours. Compare this to the 2 weeks it used to take me to build the 12,000 packages in pkgsrc. This is admittedly on different hardware and different packaging systems, but it gives a sense of the scale of the improvement.