Gergo Szakal asked some questions on usage scenarios for Hammer; Matt Dillon answered the questions with enough details that I’m linking to it.
Matthew Dillon’s posted another Hammer update, this one looking forward to pseudo file systems and mirroring, and perhaps a bit farther.
Here’s some BSD and Linux comparisons that happened to come up recently:
First, NetBSD is moving to a 2-clause BSD license. Hubert Feyrer has mention of this, along with a small graph contrasting the word count of the GPL vs. the BSD license used in NetBSD, over time.
KernelTrap has a post up about a position statement from the Linux Foundation that “urge[s] vendors to adopt a policy of supporting their customers on Linux with open-source kernel code.” Compare that to the OpenBSD position on binary blobs.
The @Play column at GameSetWatch has another article on roguelikes. This covers early roguelike software that has become lost; a strange concept in today’s world where everything is saved somewhere out there on the Internet. For an added bonus, the column has a link to a newspost from Moria’s original author, which includes this interesting quote:
I plan to download it and Angband and play them… Maybe something has been added that will surprise me! That would be nice… I never got to play Moria and be surprised…
Is that perhaps the worst part of game development? You always know how the story ends.
The June issue of the Open Source Business Resource is out, with Security being this month’s theme. There’s an article that covers a presentation on my favorite topic, “Building Technical Communities“. The Coverity Report is also interesting as it talks about the Coverity open source analysis and what the parts mean. And it has infoporn, in the form of graphs!
Mayur Bhosle has added a short writeup to the wiki on how to boot a modified DragonFly kernel in VMWare. Appropriate, given his Summer of Code project. There’s always vkernels, too.
More conversations about Hammer capabilites has been going on, on the kernel@ mailing lists, including where Matthew Dillon describes where Hammer’s mirroring concept came from, and the possibilities of growing and shrinking filesystems. (Read to the end.) Also, he’s put up a preliminary paper describing Hammer – what it does, how to use it, and future plans. There’s a section on porting for those who might be interested.
KernelTrap’s still tracking progress, too.
(Apparently Hammer does not need to be in all caps as I’ve been writing it, going by the paper.)
Matthew Dillon’s latest HAMMER update warns of the usual need for a newfs, but says that the last change requiring this will go in today. Performance is on a par with UFS; this would be interesting for someone to benchmark and graph…
Aggelos Economopoulos has updated his NetMP page on the wiki with a link to recent instructions on testing his changes. For those who haven’t noticed, he’s working on removal of the Big Giant Lock from DragonFly’s networking code.
I have a number of links to dump:
Dru Lavigne has found that Verio is offering BSD hosting (specifically, FreeBSD). She’s also got her own recent linkpile which mentions this odd thing, plus a Federico Biancuzzi BSD interview I think I missed.
KernelTrap has a DragonFly B-Tree summary similar to mine, plus a writeup on POHMELFS benchmark, that filesystem being mentioned on this site a few days back.
“FreeBSD – the unknown Giant” has changed domains to www.freebsdnews.net.
There’s been more talk about HAMMER; the June 13th update led to some discussion of B-Trees, along with HAMMER updates for the 16th and 17th, with some nice performance gains and the normal requirement to newfs if you’re using it.
Peter Avalos has updated libarchive in DragonFly to 2.5.4b. Thanks, Peter!
If you’ve been wanting to really tax the heck out of your filesystem – whether or not it’s HAMMER – here’s a good way to do so.
On a similar tangent, Dimitri Nikulin and Aggelos Economopoulos mentioned several other filesystem projects that may be fun to read about: POHMELFS, Btrfs, and CRFS.
KernelTrap has a summary up of recent HAMMER development, though if you’ve been reading here, it’ll already be familiar in a more truncated format.
Also! There’s a June 13th HAMMER update From Matthew Dillon, just to continue the trend. Recompile and re-newfs, as usual.
Following some of the article tags at KernelTrap creates an interesting topic-specific DragonFly history, incidentally.
BSDTalk has a 12 minute interview with Michael W. Lucas, author of a number of BSD books and the Big Scary Daemons column at OnLAMP. His writing is excellent.
Matthew Dillon’s posted daily updates for the past three days, so I’ll link them all here:
- June 9th: bugs fixed
- June 10th: Another newfs’ing required
- June 11th: Surprisingly good performance numbers
“Building OpenSolaris Communities“, found on an OpenSolaris blog, is a generally excellent guide on how to build an open-source community. It’s based around OpenSolaris, which isn’t a surprise, but almost everything discussed applies equally well to DragonFly or other projects without a corporate source. (via… I lost track, sorry!)
Hasso Tepper recently completed a bulk build of pkgsrc on DragonFly 1.13. He’s posted the end result, and it’s looking much better than it did at the last quarterly release: 87% complete, and only 5% of the remaining amount were actual build failures – the rest were dependencies on those failed items.
Aggelos Economopoulos, who is working on making the network stack multiprocessor safe, has a page up on the DragonFly wiki describing his work. Normally I’d link to his recent conversations about this on the kernel@ mailing list, but he’s already done a nice job describing/linking it on the wiki.
Benchmarks would be good. I bring this up because Hubert Feyrer has a post about various NetBSD happenings, which includes some interesting benchmark work. It doesn’t include DragonFly, but it’s a good model from which to work. Notice the hint there? Was it too subtle?
Most of the benchmarking work these days seems to focus on multi-cpu scalability… I would like to just see comparative numbers, especially since there’s still plenty of single-cpu systems around.