Jan Lentfer’s posted details on how his update of pf is going; it builds, but he’s having some issues with that actual filtering. He’s on vacation for a short while, but his git repo of that work is available for anyone who wants to look.
Looking for DragonFly BSD in Google will occasionally turn up wierd things: the release ISOs scattered amongst other not-so-free software, or poorly cut-and-pasted documentation in a splog. This is the oddest recently: a direct copy of the Wikipedia page on DragonFly, placed on Facebook, with a big tag at the top saying “Sign up for Facebook to connect with DragonFly BSD”.
Except there’s no DragonFly on Facebook. I assume it’s a group formed by some Facebook user. The whole “sign up to connect” item rankles me a bit; signing up for Facebook isn’t going to get you more DragonFly; it’s just going to waste your time.
Venkatesh is a new committer, and he’s already helping out with the MPSAFE work.
Matthew Dillon’s outlined the exact steps for converting to coarse locking, and he’s looking for volunteers to convert files, according to the guidelines he described. If you’re looking for maybe two hours of work that would make a big difference, here’s your chance.
Matthew Dillon’s made changes again that require a full world and kernel rebuild, if you’re following the bleeding edge. There’s also discussion of the underlying principles of the token-based multiprocessor work he’s planning.
They may be low, but Sascha Wildner has documented them.
(I am making a joke that probably only makes sense to native English speakers. Sorry.)
If you’re running DragonFly 2.7, you will need to do a full rebuild on your next update. Matthew Dillon has made some changes because of his lwkt_token work. Making parts of DragonFly subsystems multi-processor safe should be much easier now.
Jan Lentfer has committed ldns and drill to DragonFly, in (unlikely) chance that you managed to delete BIND from pkgsrc (installed by default on 2.7+) and somehow couldn’t replace it.
There’s an interesting article about mandoc and mdocml up on undeadly.org, talking about its history and usage in OpenBSD. It’s present in DragonFly, though it hasn’t been set to replace anything (i.e. groff), yet, that I know of. I do like the mdocml HTML output, and I’d like to see it here.
Joe Talbott wants to write DragonFly/BSD drivers for a whole slew of wireless devices. These are also all the adapters he doesn’t physically have. You can fix this by purchasing something off that page, which will ship right to him. A bwi(4) driver is next, for instance.
www.dragonflybsd.org runs using ikiwiki, which I just updated to the latest version. Everything looks OK, but tell me if I’m wrong.
Yay, acronyms! GSoC student David Shao has an extensive page up describing the state of his work so far.
Aggelos Economopoulos posted more details on his event tracing library, accompanied by a rash of commits. He’s interested in feedback.
Some recent bugs motivated Matthew Dillon to change DragonFly’s network stack. It’s a pretty radical simplification, so things like IPv6, ICMP, pf, etc. will need to be tested. There’s already a first round of changes to try out, served in Git.
Matthew Dillon’s been running swapcache on an Intel X-25 SSD on a very busy (in terms of disk) machine for some months now. Over a long period, the disk activity will wear down the SSD, but it’s important to see if swapcache makes a significant difference with extended use. Do you have to trade disk life for speedy I/O? He reports the results in a recent email.
Dylan Reinhold has contributed a HOWTO document on setting up swapcache. Thanks, Dylan!
YONETANI Tomokazu pointed out something that could be useful in the future: when you start getting drive errors, before you throw it out, try lowering the speed. Maybe it’s a cable problem, if you’re lucky.
As described on the kernel@ mailing list, there’s several code bounties out now, formed in part from GSoC projects that didn’t get a slot. All of them have money waiting behind them. (I’d sure like to see better interrupt routing.)
As McLone points out, the filesystem comparison page on Wikipedia is missing some Hammer details. Anyone want to fill in the pertinent numbers?