Hardware and Software

We're a mostly BSD and Mac shop here at home. Kirk and I each have a BSD box (he runs PC-BSD, I run FreeBSD) that are at least theoretically our "main machines". I say theoretically because over the years I find that I do most of my keyboard and mouse interaction with Macs. None the less, my FreeBSD box remains my primary file and email server, and is where I do most of my programming. I also have a Linux box for testing and some work for/with third parties. Kirk and I each have a Mac laptop and I also have a Mac Mini. Our web/DNS server is a Soekris 5501, a very sweet box indeed, especially since it draws minimal power. Our tenant also has a couple of Linux machines on the net. I occasionally run Windows 7 in a virtual machine on my Mini, usually only when I'm doing my finances.

The theme over the last couple of years has been minimizing power consumption, especially since we had solar installed with time-of-day metering. Having the biggest baddest machine isn't as interesting to me now than it used to be.

Networking

Although overkill, we have four networks here: a WAN connection (of course), a LAN that contains most of the main machines, a DMZ for the publicly exposed servers, and a net dedicated to WiFi. It's probably overkill, but hey.

These are all connected together with a Soekris 4801 running m0n0wall. I've been very happy with it.

Our ISP is Sonic.net (Fusion service). They aren't perfect, but as the tee shirt at ISPcon said, "my ISP sucks less". They don't have native IPv6 support yet, but they do have a 6in4 gateway. More about Sonic here and in a later post.

Telephony

Although not strictly "computing", we do have a Panasonic KX-TD1232 phone switch. We don't have a house so large that we really need multiple extensions, but we do have five (yes, five) phone lines coming in, and it has proven to be very useful. What can I say, I have a phone fetish. I may post about that in the future.

From: Jim Bradford <(deleted)@(deleted).com>
Subject: programming isn't fun anymore
Date: August 23, 2011 4:19:31 PM -0600

I used to enjoy writing programs. I could write lines of code, compile them, link them and run them and they would do things. Useful things. They would solve problems. Or they could take input and produce output. Now all that is ancient history.

I don't write code. I learn tools. Or try to learn tools. Problem is, there are more tools than anyone can keep track of. Some people know some tools and so they can get work done. These people are called "architects" and they expect everyone will know the same tools they know. Or everyone should. If they don't, those people are stupid and should be shunned and ignored. We programmers know a few tools but not the ones the architect knows. That's ok - we've learned lots of tools over the years so we keep quiet and think to ourselves "I don't know what this guy is talking about but I can learn these tools". So when the architect says "exclude slf4j from the library's build sequence or modify the pom file dependency list" we don't say "what the hell are you talking about". We don't say anything. We go to google and spend the next two weeks learning slf4j and Ivy and Maven, and RESTful WebServices and Grails, and the proper syntax for the BuildConfig file. Then we reboot the computer three or four times for good measure; download security patches for the IDE; get the latest version of the JDK; clone a few repositories from GitHub; study the Artifactory website; look for new docs on the wiki; and hope to god someone has figured out why the WAR file doesn't deploy to the 3.2 version of the app server. In all this time no code has been written. No problems have been solved. No user interfaces have been created. But everyone has been terribly busy. And the architect has been studying newer, better versions of the three or four tools we have now almost learned, but which have become obsolete. Eventually, the project is cancelled. Management decides to continue using the prototype version written in Objective-C, even tho the source code has been lost and it doesn't use any of the company-standard tools, because it does 80% of what the one customer wants, and no one else really needs the application anymore.

That's the story of my professional career. Trying to learn things fast enough to create programs to solve problems that go away by themselves or weren't worth spending time on in the first place. Sisyphus had more job satisfaction.

Now, I think Jim is a bit harsh. But only a bit. As a long term architect, I can say that we (well, at least the ones that I've known) don't sit around trying to figure out how to make programmers' lives more difficult. But as someone who, after a decade spent primarily in management, PR, marketing, finance, nearly anything except actual coding, found that I was completely and utterly lost, I can affirm at least some of what Jim says.

When I was a coder, we worked on algorithms. Today, we memorize APIs for countless libraries — those libraries have the algorithms. Section 3 of the Unix manual used to fit comfortably in a small binder; today the BOOST library has hundreds (if not thousands) of APIs. It used to be that the tools were helpers (i.e., optional but useful) and relatively minimal and well-defined — the build tool was make, etc. Now I've worked on a project that used make, ant, cmake, and a couple of others I never did identify, not to mention a series of scripts written in sh, bash, perl, etc., with UML used to generate interface descriptions. In fact, most projects I've seen in the last few years seem to resemble Dr. Frankenstein's monster. There is no way you can work with such a mess without using eclipse or some similar tool.

But let me go further. I used to be enamored of object-oriented programming. I'm now finding myself leaning toward believing that it is a plot designed to destroy joy. The methodology looks clean and elegant at first, but when you actually get into real programs they rapidly turn into horrid messes. I will assert that you simply can't program any non-trivial program in Java or C++ without an "Environment" to help you. You need this to figure out WTF is going on with all those library calls that differ in very subtle ways. Debugging has turned into an exercise in figuring out why the methods you are calling don't do precisely what you anticipated. Engineers spend long meetings debating whether to upgrade to the latest version of (fill in favorite library name) out of fear that it will break things in unexpected ways. DLL Hell has turned into CLASSPATH Hell.

And who managed to convince the world that a malloc call was cheap, so you should do arbitrary numbers of them at every procedure (method) invocation? Memory management is expensive. Even the best algorithm blows the cache. Get used to it, at least until memory becomes so fast that we don't need caches any more. Wait, I hear a voice in the back of the room — no, garbage collection does not fix the problem; in fact, it makes it worse.

We spent years working on software reusability. We have now succeeded, and have to pay for that. Be careful of what you wish for.

The good news is that programming will become easier for people with good memories but not so great analytical capabilities. Unfortunately I fall into the opposite camp. Alas, if I had only memorized my times tables instead of thinking about Boolean logic, base 8 arithmetic, etc. I am a product of the "New Math", and it served me very well.

I have some hopes for Go, which Rob Pike specifically said was partially designed to make programming fun again (see about three minutes in). Similarly, Lua is a rather interesting language. I haven't tried to code anything significant in either language, so I can't speak from experience, but they do look interesting.

I don't have a solution. In fact, I'm probably just getting old enough that I'm not adapting to the new reality. I grew up when it was important to understand NAND gates and flip-flops. Now it's a different world. I can take some satisfaction that I rode a wonderful wave.

Back in March 1982, Peter Denning wrote (President's Letter, CACM 25, 3, pp 163-165) about "Electronic Junk". I stumbled across this article recently and was struck by both how much and how little has changed in the intervening 27 years, at least as regards electronic mail.

The Conference on Email and Anti-Spam (CEAS) is coming up August 21-22. I've gone to this conference since the beginning, and so far as I know it's the only conference on the topic that is practical without being arm-wavy. Good stuff if you're in the business, and there's a lot of interesting work there. IIRC that's the first time I heard definitive research showing that CAPTCHAs have essentially been defeated (using algorithms, not presenting them to other humans), and that was at least three years ago. The rest of the world is just figuring that out.

Another good conference is the MIT Spam Conference. However, I don't find it as rigorous as CEAS. Unfortunately I managed to miss the MIT conference this year. Although I'm on leave and hence don't have a travel budget, I probably would have tried to go.