Category: review

Posted on

Reviews and Murder

First, an independent review of PAM Mastery, from nixCraft. The book took bloody forever to write, but from the reviewer’s comments like “Once again Michael W Lucas nailed it,” apparently the end result was decent.

Not sucking is good. I like not sucking.

Next up: something I can see myself linking back to in the future.

I normally don’t link to Amazon reviews here, but a review on a short story compels me to make a general comment.

This story is billed as “a DevOps murder mystery.” I’m writing another, a novel called $ git commit murder. (Yes, the dollar sign is part of the title–otherwise, git might be running as root, and when you’re trapped into using git you don’t do it as root. Sheesh!)

I mention a lot of different software in these pieces. Some of it’s real. Some of it’s imaginary, or clear plays off of stuff that exists. It’s pretty easy for readers in the software world to figure out where SkyBSD and CoreBSD fall in the open source ecosystem.

But here’s the important thing about murder mysteries:

People kill other people in them. Most often, deliberately.

Real people killing each other… is not funny.

I’m not going to write something where a developer on a real project goes on a killing spree. That’s happened in the real world. Projects don’t come back from that. And yes, it has to be a spree. Novels require more than one murder.

Plus, I know a lot of people in these communities. Many of them are my friends, and I respect most of the remainder. (Sorry, HB.) The characters in these pieces are like people I know, but they are not those people.

Wearing my fiction author hat, I sometimes need organizations to behave in ways that the real organizations don’t. Murder requires strong motivation. One of the earmarks of successful real-world open source projects is that they’ve learned how to get along without literally killing each other.

I mean, imagine if I wrote a piece of fiction claiming that OpenBSD was contemplating a switch to GPLv3? You’d either throw the book across the room or laugh until you soiled yourself. Neither is the appropriate reaction for a murder mystery.

I have to invent new projects, so they can behave as the story needs.

So I invent projects much like real projects. These projects have different areas of focus than the real projects, so that they’re not just a renamed Debian. They need different focuses and different purposes while retaining enough that the reader will believe they’re a real open source project in a parallel universe.

And then my imaginary friends wander in and pick the project that suits them.

And then they kill each other.

Because, despite the rumors, I’ve never killed a real person. There’s no evidence to say otherwise, at least.

Posted on

First review of “FreeBSD Mastery: Specialty Filesystems”

Sunday Morning Linux Review episode 184 discusses FreeBSD Mastery: Specialty Filesystems.

While SMLR is always worth listening to, if you want to cut right to the review (or, alternately, if you’re me coming back to look for good quotes to steal for publicity purposes), the review starts about 30 minutes in.

It’s about 1:11 into the unedited video.

Summary: the book does not suck. And some parts are actually interesting. Which is nice. The book did expose Mary to new ideas and sent her running for the manual and Wikipedia a few times, but learning is good for you, so that’s okay.

I should also note that while I offer free review copies to podcasters, SMLR insists on purchasing books for review. They say it keeps them unbiased. I won’t argue.

Posted on

Sunday Morning Linux Review on “Tarsnap Mastery”

The Sunday Morning Linux Review crew has reviewed Tarsnap Mastery in episode 148. From the review:

“If you use any nix-type system, and need offsite backups, then you need Tarsnap. If you want to use Tarsnap efficiently, you need Tarsnap Mastery.”

The whole episode is worth listening to, but the review itself starts about 1:27 in the unedited video.

They also review me as an author. All I can say to that is: “Eeep!” Fortunately they didn’t review my personality, so I come out okay.

Posted on

Book Review: Book of PF, 3rd Edition

No Starch Press was kind enough to send me a review copy of the new 3rd edition of Peter Hansteen’s Book of PF. The first two editions are the standard reference work on the OpenBSD packet filter, and this is a topic I’ve written about in some depth before, so I’m fully prepared to eviscerate Hansteen if he screwed up.

Third edition, huh? So how does this stack up?

Let’s get the obvious out of the way. All three editions have yellow covers, but the first edition had blue trim; the second edition, pumpkin; the third, a kind of fern green.

Once you open the cover, you find that the third edition works much like the earlier editions, starting with a simple packet filter setup and building upon it. Building upon success is perhaps the best education technique, and it fits the topic quite well.

Structurally, BoPF3 is very similar to the earlier editions. CARP and redundancy now gets its own chapter, which is a welcome addition.

The real meat of this book is in the examples, tutorials, and explanations. PF has changed since the second edition, notably with more flexible traffic management and some syntax changes. Not all BSDs have remained synchronized with OpenBSD’s PF, so he has the unenviable job of documenting the differences between OpenBSD, NetBSD, and FreeBSD. He’s done an excellent job of this by combining information where appropriate, but breaking out some topics by operating system. For example, if a topic needs a sysctl, he lists them for each operating system. When a topic requires more in-depth explanation, such as traffic prioritization, he breaks out OpenBSD’s new priority system into one section and FreeBSD/NetBSD’s older altq prioritization scheme in another. This makes it very easy to find what you’re looking for. This book teaches you how to use PF to filter packets just as well as a million dollar appliance, with more insight and control.

One impressive thing is that this book is very clear. Giving a section a title like “Things You Can Tweak and What You Probably Should Leave Alone” gives you very definite ideas about what’s in this part of the book. Hansteen explicitly describes how PF works. He also discusses what happens when the real world impacts your firewall. He hasn’t just got PF up and running in his lab: he actually uses this stuff in the real world, with all its malformed packets and stupid protocol implementations and worse protocols, and keeps services running despite all that.

Complaints with this edition?

As with the earlier editions, the footnotes contain actual facts. It’s like Hansteen wants you to be able to go look up actual sources to verify what he says, instead of requiring us to trust him. As a writer, I prefer assuming blind faith and unyielding obedience from my readers.

If you use PF on any platform, buy this book. You can get it from Amazon (of course), and also get a combined print/DRM-free ebook deal direct from No Starch Press.

This ends the actual review. But someone is going to ask a couple things in the comments, so I’m jumping ahead of them here.

First: my general thoughts on authors writing reviews.

Second: Why hasn’t FreeBSD imported the latest PF?

The FreeBSD and OpenBSD network stacks have massively diverged in the last twenty years. OpenBSD’s kernel uses the Big Giant Lock model. FreeBSD’s kernel is much more finely locked, and the network stack can be in multiple CPU cores simultaneously. Despite their common heritage and licenses, FreeBSD and OpenBSD are different operating systems. They have different use cases. They are designed for different uses. They target different hardware.

FreeBSD’s previous PF import required a lot of work to make it fit its network stack. The FreeBSD Foundation invested a fair chunk of change in thrashing PF in the network test cluster and on high-performance customers so that it didn’t slow down the network stack. (It’s not that OpenBSD is slow, it’s just designed differently than FreeBSD.)

A “new import” is not trivial.

FreeBSD has a flexible firewall system, however. A new PF could be imported as, say, pf56.ko, without impacting the older PF import. You could use mailwrapper-like functionality to transparently assign the proper userland programs to the PF version in use. This can be done.

Nobody has done the work.

I suggest you get coding.