Lazy Reading for 2014/01/12

There’s a lot this week, so let’s get started:

Git Reference.  Not that there isn’t a lot of other documentation out there, but much of what you find is people asking specific questions rather than explanations of procedure.  (via)

Movie Code.  At least most of these are using legit code, even if it’s often the wrong application.  It’s been worse.  (See ‘state of the art video’ item)  (via)

Unix: 14 things to do or stop doing in 2014.  These tips are actually useful and contain no buzzwords.

TrewGrip, another item in my quest for interesting keyboards I don’t use.

4043 bytes to recreate a mid-80s IBM PC.  There are less bytes of data in the program than there were transistors in the CPU that it emulates.  It can run MS Flight Simulator.  It was for the International Obfuscated C Code Contest, which should surprise you not at all.  (via)

The World’s Most Pimped-Out ZX81.  I don’t think it can run Doom, though.

The Unix Shell’s Humble If.  For once, an article that doesn’t just pretend bash is the only shell that exists.  (via)

Unix Shell RPG Tutorial.  It’s exactly what that combination of words means.  (via)

Scientists tell their favorite jokes.

Best programmer jokes, found here where there’s more.

I find these animations slightly hypnotizing.  (via)

Technology used to suck even when it was cutting-edge, and we’ll still feel that way in the future.  (via)

How did we end up with a centralized Internet?

Software in 2014.  The summary is: server side is great, client is not.  (via)

Able to be turn on, and that is it.  Sci-fi movies ignore where technology comes from.

True Nuke Puke Story.  My mine coworkers once did something similar to a copier repairman; got him so worried about going underground that he had a panic attack when he had to step on the hoist.  We had to get a new repairman.

Your unrelated link of the week: BIG ENDING FACES!  (via)

My DragonFly 3.6 upgrade adventure

Here’s how my upgrade from DragonFly 3.4 to 3.6 for this server went.

The system install went normally.  I rebooted before performing ‘make upgrade’, as noted in UPGRADING and elsewhere.

I already have dports installed, so a binary upgrade should be possible.  I had heard of people with older version of pkg, having trouble getting it to notice upgrades.  I rebuilt pkg, and ran ‘pkg upgrade’.  A number of the updates coredumped.  Here’s one example:

[156/160] Upgrading gtk2 from 2.24.19 to 2.24.19_2...Segmentation fault 
(core dumped)

After the upgrade, I had two problems: PHP wasn’t working for the website, and some programs would segfault.

The random segfault was fixable by forcing a binary upgrade of all packages.  Since there were some programs on the system that were still new enough that the version number was the same as on the remote repository, pkg didn’t upgrade them.  Those packages were linked against old versions of system libraries that predated the locale changes in DragonFly 3.6, so they’d crash.  Forcing the update for all packages fixed the issue.

The other problem, PHP on the web server, is not new to me.  The binary package for PHP does not include the module for Apache.  The solution is to build from source with that option selected.  I understand that pkg is destined to support (some?) port options in the future.  There’s also an immediate workaround for locking it.

However, the port would not build because of a security issue.  The binary package installed without any warning.  This, I am told, will change to pkg giving you the option to install if you are aware of the security problem, and whether it really affects you.  (which is just what I want, yay!)

Anyway, other than the system changes biting me because I didn’t realize some packages weren’t updated, it went very quickly.  That is the reason for binary updates through pkg, or at least a major one.

Lazy Reading for 2013/12/22

Still quiet out there, but I found some good reading.

PHP functions originally named for string length and sorting.  Yeesh.  (via)

A great old-timey game programming hack.  There’s an initial speed hack in this story, and then there’s another clever trick to fix memory corruption.  (via)

My hardest bug.  This was a pretty fiendish problem.  (via)

Gitdown: don’t commit when drunk.  I’ve done that.  Actually will use an Arduino-based breathalyzer.  (via)

Another Perl One-Liners review.

Zeno of Elea, a game.  It’s based on a classic… (via)

Vim plugins you should know about.  From that One-Liners author.

Speaking of Perl, here’s a Larry Wall interview.  An old-school hacker – he wrote patch, too.

Moonpig: a billing system that doesn’t suck.  An in-depth review of system design.  More Perl, too.

Three Books You Should Read…  Mostly BSD content.

How to use Tor wrong, in multiple ways.  It’s not for petty crimes, and it’s not any use when you’re using it from a monitored network.  (via)

Your unrelated comics link of the week: Cookie Puss.

Who’s for an OpenPF?

Things are very quiet this week; I’ve had nothing to post for some days – DragonFly or even for other BSDs.  The end of the year has most people distracted, I think.  This makes it a good time to bring up something that’s been bothering me: the state of software firewalls in BSD.  The pf utility is a BSD advantage; I’ve heard people say “I used iptables on Linux and pf is a much better alternative.”  I know that’s anecdotal, but there it is.  Here’s the question, and the reason I’m writing this: which pf?

DragonFly has a version of pf equivalent to what was shipped in OpenBSD 4.4.  FreeBSD has a version equivalent, I think, to OpenBSD 3.8 4.5’s pf, and it has been further modified.  NetBSD has a similar, older pf, but there’s people working on a NetBSD-specific version called npf, which isn’t yet ready.  And of course, OpenBSD has its version of pf.  If you feel good about these different alternatives, you call it divergence.  If you don’t feel good about it, you call it fragmentation.

Compare this to OpenSSH – it works the same on each platform.  There’s no confusion on how to configure it, or interoperability problems.  It would be wonderful to have the equivalent for pf, where other BSD platforms would import a portable version.  This software firewall is a strength, and it’s much easier to tout it when there’s only one.

I doubt there’s a way to bring it all back to one source tree.  There’s a lot vested in the different forks out there.  You know what would take a lot less effort: a compatibility test suite.  Agreeing on a common syntax and set of functions would make life easier for every end user.  It would incidentally make vendors a lot happier, too.  Even if a user or vendor wasn’t hoping to move between BSD flavors, a test suite would still guarantee a certain known level of functionality for any BSD release.

How likely is this?  I don’t know.  But I want to bring up the notion before it gets missed.  Now is a good time, with each pf version still being relatively close to one another.

Update/note: Henning Brauer is willing to help.