John Marino has created something very useful: a graphical tool for Hammer file history.  It's called 'Slider', and it uses curses to work in a terminal.  It shows historic versions of files and can restore those old versions as needed.  This was already possible in Hammer, of course, but it required a sequence of commands that were not straight-forward.  I've been slow enough posting it that version 2.0 is already out, offering a way to see files that no longer exist, but are still in history.  (i.e. deleted some time ago)  'Time Machine' sounds like the best name, but that seems to be taken.
I'm going to dive right in with an anecdote: As is normal for anyone in systems administration, I'm busy at work.  I've been short an employee for some time, and I brought in a managed service provider to do some work.  This included a revamping of the network equipment and layout, as it has been growing organically rather than in a planned fashion. I received the formal assessment from the provider a few weeks ago, and it mentioned that we were using a non ICSA-certified firewall: pf, in the form of pfSense.  This was accompanied by some rather drastic warnings about how open source was targeted by hackers! and implied that ICSA certification was a mark of quality rather than a purchasable certification.  All bogus, of course. The reason I'm starting this review with this little story is to note that while open source has become well-accepted for system and application software, there's still a lot of people that expect commercial hardware to be exclusively handling data once it leaves the server.  That's been valid for a long time, but software like pf represents a realistic option, or even an improvement, over many commercial and proprietary options.  Since pf exists in one form or another on all the BSDs, it's a tool you should be at least somewhat familiar with. Peter N. M. Hansteen has written about pf first online, and then in printed form, for some time.  The Book of PF is in its third edition, and that's what I have to read.  (Disclosure: No Starch Press gave me the book free, without requirements) The book is excellent, and easier to read than I expected for a book about network processing.  It can be read in linear form, as it takes the reader from simple to more complex network layouts.  It works as a reference book, too, as it focuses on different tools around pf and what they are used for. It covers the different pf version in OpenBSD, NetBSD, and FreeBSD, and DragonFly gets at least a partial mention in some portions of the book.  For example, OpenBSD recently removed ALTQ, but the other BSDs still use it.  With- and without-ALTQ scenarios are covered every place it applies.  You're going to get the most mileage out of an OpenBSD setup with it, though. The parts where the book shines are the later chapters; the descriptions of greylisting and spamd, the traffic shaping notes, and the information on monitoring pf will be useful for most anyone.  It's quite readable; similar in tone to Peter's blog.  If you enjoy his in-depth online articles, the book will be a pleasant read. It's available now from Amazon and directly from No Starch Press.  It's linked in the book slider currently running on the right side of this site, too.
Last of the year! Your unrelated link of the week: UpDog, a revolutionary communications platform.  (via)  
The list is shorter this week; I blame the Christmas holiday.  
BSDNow isn't slowing down for Christmas, cause there's a new episode up.  There's two interviews this time - Erwin Lansing, about BSD in Europe, and Cristina Vintila, about BSD conferences.  The rest of the episode is a bunch of "How did you get into BSD?" stories from viewers, both in text (i.e. read out from email) and the occasional video answer.
One way to keep file history on an very active Hammer disk from eating up all the space: more snapshots.  This may seem counterproductive, but disk pruning eliminates historical data between snapshots, so you can keep older data at the cost of some temporal accuracy.
BSDTalk 249 is an 11 minute interview with Scott Long, who is involved with Netflix's FreeBSD-based local caching appliances.  This conversation is from MeetBSD 2014, though I heard Scott talk about the same subject at the last NYCBSDCon - it's an astounding amount of data flowing through those machines.
I am slightly confused about which day it is.
I sort of lost a day this week because of an accidental 20-hour workday, but I still have the links: Note: corrected VPS hosting link.
If you really, really want to make sure you aren't pulling in any parts of X when installing dports, and you're building from source, there's a few options you can set to keep X11 off your system.  You can even go farther.
Minimal link text this week.  It just happened that way.  
Get ready for some reading.
It's possible, if you are several releases (years) behind, to end up with a DragonFly system that can't compile and install the current release, due to incremental changes over time.  It's rare, but it could happen now between, say, version 3.4 and 4.0.  The usual solution would be to incrementally upgrade in order, which is a lot of building and updating.  The alternative is the new installworld-force option from Matthew Dillon that forces a new set of binaries into place.  Use as a last resort.
If you want to help I/O performance when DragonFly is virtualized, here's a short checklist of what to work on.  I haven't noticed any problems - but I'm not taxing any of my VMs that heavily.
BSDNow's episode this week focuses on the just-released Bitrig 1.0, and has an interview with Patrick Wildt of that project.  There's also coverage of other topics, including the new poudriere release - that's the tool that bulk builds packages for DragonFly and FreeBSD, though I don't know if it's unified across both operating systems yet.
bycn82's rewrite of IPFW2 is available as a git branch to try out; he's posted the link.  Please try, especially if you are still working with the original ipfw. (note: remember, 'ipfw' in DragonFly is what was called 'ipfw2' years and years ago because it was a replacement of the original 'ipfw' in FreeBSD.  It was called ipfw2 but referenced as ipfw so that the same commands worked.  Technically, this branch bycn82 is working on would be ipfw3, but he keeps referring to it as ipfw2.  Confused?  Good.)