A running description of activity related to DragonFly BSD.
If you’re trying DragonFly 3 in a virtual machine, you may have noticed some issues in booting in (for instance) Qemu. Sepherosa Ziehau committed a change that sets the sysctl hw.ioapic_enable to 0 in virtual environments. It can always be turned back on, but the recent MSI/MSI-X improvements seem to cause trouble in some virtual environment. You can also set that tunable at boot to get an initial install going.
(I haven’t had trouble in Virtualbox or VMWare, so you may or may not need this.)
As several people have told me, there’s benchmarks of DragonFly 3.0 vs. 2.10, available on Phoronix. CPU performance shows a significant improvement, in tests that actually test it. (I’d think a file compression test would be disk-limited, for instance.) Disk performance isn’t as great, but that may be in part because Hammer no longer will starve reading to benefit writing; that makes benchmarks look worse but improves real-world interactivity. I’m sure there’s more quibbling to do, since it’s lies, damn lies benchmarks.
If for some reason you needed DragonFly 2.6 ISOs, or older, there’s a mirror.
It’s now possible to specify a jail ID when using pgrep and pkill(1), to capture processes specific to a jail. It’s similar to the same option in FreeBSD, except no compatibility issues since this option did not previously exist in DragonFly.
If you want to build Firefox 10 out of pkgsrc, make sure your DragonFly system is up to date; there’s a recent fix needed to make that happen.
This is the week where I remember to actually write introductory text. I also didn’t think I was going to have anything good this week, but The Internet came through for me at the last minute. Thanks, Internet! It’s also the week where I mis-schedule this post for Friday, temporarily.
Your unrelated link of the week: Welcome to Muppet Labs, where the future is being made today!
I tagged these when they happened in previous months, but I forgot to post them:
“peeter” got wip/jdk16 to build normally on DragonFly, and listed how to do it. I don’t know if it still applies.
Sascha Wildner updated the isp(4) driver from FreeBSD, adding new supported chipsets and making it able to load as a module.
Also from Sascha Wildner, we’re now using one source only for PCI IDs. Think of that next time you are looking at dmesg, and it makes sense.
If you’re in New York City or the UK, there’s two new DragonFly mirrors for your downloading pleasure. Check the mirrors page for details.
Matthew Dillon’s CPU bug hunt has scattered its way across various news sites, some more accurate than others. He’s posted a followup that is probably a more valuable read than any of the news reports.
Have you ever tried to run a service and realized you forgot to make an entry in rc.conf to enable it? It’s mildly annoying. There’s now a “one’ keyword (via NetBSD) that lets you enable a service, once. It still apparently performs sanity checks, unlike the otherwise-similar ‘force’ keyword.
The March issue of BSD Magazine is out, as a free PDF as always. It’s a real grab-bag of topics this time, so there should be something to interest you. This time, it might be an article on DragonFly and Beowulf clusters. (I was totally not expecting that.)
Notice how the 2.12 release never really happened, and 3.0 came out about 6 months later than usual? A lot of that delay was caused by a vigorous search for a weird bug. Multi-threaded buildworlds would crash, seemingly randomly and rarely. It turns out we have confirmation from AMD that it is, indeed, a CPU hardware bug.
The organization application for DragonFly is in for Google Summer of Code. If you are thinking of working as a mentor or as a student, please let me know soon! We will know if we’re accepted (for the 5th time!) on the 16th.
If you said “Yes!”, you’re in luck. Markus Pfeiffer got ghc to compile on DragonFly, and his fixes (for DragonFly at least) to enable it are already committed.
Here’s an interesting side effect that came up in Hammer 2 development: deleting files can potentially require modification of only one parent element. If I’m reading it right, that means deletion always takes about the same time, independent of the amount of data being deleted. Your ‘rm -rf /largedrive’ could complete, removing multiple terabytes of data before you realize it. I suppose it’s silly to complain about speedy results. Of course, being Hammer, it would still be available in history.
Is it possible to boot with only 48M of RAM in a DragonFly system? Probably not. 128M would be better. I usually talk about the lower memory limit for Hammer, since it’s so relatively low for a snapshotting file system, but the converse applies here. 128M is probably the comfortable lower limit, though it’s pretty hard to find a system that would limit you that way without doing it on purpose. 128M sticks of RAM are practically disposable these days, really.
Thanks to John Marino’s work, it’s now possible to build the DragonFly kernel and world using gold, and have it work. You just have to set WORLD_LDVER to make it work. I don’t think there’s any user-visible change from this, other than a tiny speedup in building. I don’t know if any other BSD is using gold yet.
Alex Hornung added support for rdrand(4), the random number generator built into some Intel CPUs. That would be Ivy Bridge CPUs, which aren’t released yet, so it hasn’t been tested… but you’re covered for that day in the future when they arrive.
See the release page for details. This release took longer than normal because of a crazy bug hunt, but the payoff is that this version performs better than ever.
Note: The x86_64 GUI ISO image had a problem due to file size (over 2G); redownload if you’ve had trouble booting it.
