It still strikes me as odd to consider systems with less than 1G of RAM as “low-memory”.  What rich times we live in!

• Steam and Team Fortress 2 running on a BSD – PC-BSD with an NVIDIA driver, in this case, but it may apply to other cards and other games.  Using Wine is always so intricate, it seems.
• Remember how suddenly a large chunk of Internet traffic was suddenly routed through China, briefly in early 2010?  Apparently it’s happened a few more times since then.  This article at the Economist talks about that and the SCION project, in an accessible way.
• The 2011 Interactive Fiction Competition has released this year’s entries, and almost all of them can be played online.  (via)  There goes a few hours of your life.  Sorry.
• Speaking of hours, there’s apparently a civil lawsuit that has rendered timezone data unavailable.  Here’s a good summation.  It’s a frustrating scenario.  (via multiple places)
• World’s best introduction to sed.

• DragonFly morphology.  The insect, not the operating system, though that would make an interesting diagram.
• Stick your pinkie in the corner of your mouth, Dr. Evil style, and say, “One MEEELion TCP connections on BSD!“.  (via several retweets)
• Sudo vs. SSH public keys.
• The app store concept is taking over.  Not that it’s a totally bad thing!  We could implement one for pkgsrc, and should.  (via)
• A nice (OpenBSD-centric) walkthrough of routing.  (via)
• Ooh, decent disk benchmarks.  I wish there were graphs, of course.
• I think this happens to most CS grads; you sit around one day and say to yourself, “Hey, I could write an operating system!”  This forum post shows someone getting that idea and then realizing it’s not necessarily the goal he wanted.  Why do I link to it?  I appreciate the optimism.
• Or you can just build a functioning computer in Minecraft.  This sort of thing has been happening for a while – this movie is just a link to the craziest example I’ve seen so far.

Your unrelated link of the week: Scientific Illustration.  Not a comic, but still visually interesting.

• Yet another git cheatsheet, this time for KDE.  (Via TGEN on EFNet #dragonflybsd)
• What’s wrong with sort and how to fix it.  I will enthusiastically link to any article that mentions letters like þ.  (There’s others that this stupid blogging software just eats when I write out the HTML entities.)
• Did you wake up this morning and say, “I wonder if I could run some really old software.  Like 4.1c BSD?”  Well, today’s your lucky day.
• Creating new Linux base and infrastructure ports on FreeBSD.  Interesting to see just how complex it can be.
• Distributed computing at Google.  (PDF, via)  I like the description of the error/failure rates and how they escalate as an architecture scales up.

Your unrelated comic link of the week: Jack Kirby art on what would have been his 94th birthday.  I have trouble communicating how dramatic and influential his art has been.

• Ecdysis – a NAT64 gateway program.  I link to it for two reasons.  1: You will probably need to NAT 6-to-4 sooner or later, and 2: it uses PF and so is BSD-compatible. (via)
• Don’t not copy that floppy! (also via)  My original Apple ][ disk for Castle Wolfenstein is probably no longer functional.  Not that I have equipment to play it on…
• World timezones, as a visible map.  (via)   I mention time zone updates here on occasion, and this is a immediate guide to what a strange patchwork of zones it is.  You can’t even see some of the really tiny/crazy ones.
• A crappy way to start your day.  Nobody ever enjoys that call from work…

And now, a link that has nothing to do with this.

No Starch Press, the company that published all the books linked in the previous paragraph, asked if I’d read/review another book from them. This would be Practical Packet Analysis, 2nd edition.  (Review continues after the break…)

The reason: If you’ve been reading the Digest for some time, you may have noticed several trends: a liking for roguelikes, a preference for graphs, and hints that you should understand tcpdump.  Being able to tell what’s happening on the network, as it happens, is a powerful tool.

The book: Another way to describe the book is “Here’s how Wireshark works.”  It dives right in to network setup and the various parts of Wireshark.  This makes for relatively dry reading at first – book descriptions of menu options is never as fun as actually clicking on the menus and getting results.

If you aren’t immediately familiar with the OSI network model, the book includes material on the lower layers of that model.  It also talks about a number of real world scenarios – specifically on identifying speed issues and security monitoring.

As with most technical books, it works in part as narrative and in part as reference.  There’s enough background material and procedure to get a relative newcomer started.  The book also has enough detail that it’s worth coming back later to explore a new feature, or see how to solve a new problem.

My advice is to skim the book to get an idea of how Wireshark works, and then fire up Wireshark so you can see the actual live results.  Then, go running back to the book to find out what it all means.  The content matter is dry, but reading the text with a copy of Wireshark running will smooth out the process.  I’d half-expect exercises at the end of every chapter to reinforce the steps being taken, though nobody ever voluntarily writes out homework.  (I’m sure this will get a comment from someone about how much they enjoy solving random math puzzles.   Good for you.)

This book is an excellent tool for any system administrator to gain useful troubleshooting skills.  Those skills will look magical to anyone not familiar with the lower levels of how a network works.

The anecdote: Here is where I back up those statements on how important it is to use these network tools.  Some years ago, I worked for the largest (though now defunct) power line networking service provider in the US.  We had a Dell-manufactured home router device which just couldn’t acquire an IP address via DHCP on that power line network, but it worked anywhere else.

I was able to solve the problem by using Wireshark to watch the actual DHCP transaction.  The router was receiving two DHCP ACK messages from the same device, which completely confused it.  There was no way to identify this problem without looking directly at the activity on the wires (and reading RFC2131).  It made me look heroic, which is a nice break from the usual.

Back to DragonFly: Wireshark is available as net/wireshark in pkgsrc.  The later chapters on traffic types and common problems will be helpful in any case, even when the only tool handy is tcpdump.  There’s a lot of overlap between the filtering expressions used in tcpdump and the ones in Wireshark, and the capture files are interchangeable.

Disclaimer: I didn’t get anything except a copy of the book.  So, I’m either unbiased, or a horrible negotiator.

You can buy paper and electronic versions of the book.