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.
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.