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.
The “Institut de Recherche et Coordination Acoustique/Musique” is mirroring DragonFly – it’s on the mirrors page or you can just go right to it if a French mirror is useful to you.
I’m planning to tag the 3.0.1 release of DragonFly this weekend. There’s still a few bugs, so if you are able to help, please do. Otherwise, they will be errata.
Will Backman interviewed me for BSDTalk, talking about DragonFly 3.0 and all the stuff around it. I can’t listen to it it’s my own voice do I really sound like that aaaargh.
For the curious and technically oriented, Hammer 2 development can be watched directly by looking for any commits marked ‘hammer2’. There’s been a lot, and if you want to see the code as it flows in, here’s your chance.
If you’ve noticed the main dragonflybsd.org website being down, that’s because both network connections (on different networks!) serving it are down. This makes the website unavailable, and the source code, but you can still pull down images, packages, and the like from avalon.dragonflybsd.org. Hopefully this warning will be out of date soon.
Note: It’s back.
There’s 7 bug reports to close before releasing DragonFly 3.0. Most of them have dumps to go with them, so each one should be solvable. Please take a look if you have the time and inclination,
John Marino has added support for preinit, init, and fini arrays. DragonFly is the first BSD to do so, apparently. What are they for? I’m not sure. The commit message points to more documentation, but not simple enough for me.
There’s a Hammer 2 branch in the DragonFly git repo now, for the next generation of DragonFly’s native file system. Don’t get too excited; as Matthew Dillon explains, it won’t be operational for months, and features won’t get added until much later this year. It’s neat to see the work happening, though, and there’s a new design document to show what’s coming.
Sascha Wildner has brought in improvements to the mps(4)driver from FreeBSD. It’s for LSI Logic Fusion-MPT 2 SAS controllers, and apparently didn’t work very well… until now. Sascha’s commit message details what’s new, including RAID support that is not yet mentioned in the man page.
Nick Prokharau’s project for Google Summer of Code last year was “Port PUFFS from NetBSD/FreeBSD”. Sascha Wildner has now committed that to DragonFly. It’s experimental, so the normal caveats apply.
John Marino has made it possible to build world and kernel on DragonFly using GCC 4.6 in the form of gnat-aux. (We’re currently on GCC version 4.4) Note that version 4.6 isn’t included with DragonFly, so you would need to download and compile GCC 4.6 a very recent version of lang/gnat-aux, and set CCVER=gcc46 before building world and kernel to try this out.
Update: John Marino points out in comments that you need to set WORLD_CCVER, not CCVER as his original message said.
It’s on, again! Not that there was any doubt. I need to collect potential mentor names before DragonFly can be involved, so you can guess what I’ll say next…
Edward Berger found that using a LG/Hitachi DVD drive kept him from successfully booting a DragonFly install CD. Using other manufacturers worked out fine. What causes the problem? I don’t know, but it’s worth mentioning it out loud in case someone else gets bit by it.
There’s a NetBSD Hackathon going on February 10th through 12th, mostly online. I mention this because it may have some effect on pkgsrc, used by both NetBSD and DragonFly. Hackathons for pkgsrc usually happen separately, but no harm in keeping an eye out for any positive benefits.