Tag Archives: cadt

Learn to suffer

I would really appreciate it if someone could explain to me why I shouldn’t just say “screw it” and spend $24.95 on a Flickr account instead of fighting with locally installed software. Because it’s the manly thing to do? Because struggling with someone else’s design choices builds character? Because I need to rebuild my sysadmin cred? I realize that I will quite rapidly devolve into one of Those People with a Flickr account, and that the true He-Man solution is templating and scripting and a lot of little HTML files and some more scripting glue to hold it all together and publish… but life is short, and so is my patience.

What to do, what to do?

The creepiest parallels

Jack Hitt wrote a fabulous article in Rolling Stone last month about missile defense, made all the more fabulous because it contained information relating to a defense or aerospace project that was new to me. As they say, read the whole thing. If you’re like me, though, and have spent a significant portion of your life around computers and the open source movement, the most striking this about this article is the horror you’ll feel when you realize that the United States Department of Defense has adopted the CADT model of weapons system development.

I’m not joking. Hitt might as well have been writing about any large scale OSS project:

This kind of thinking does wonders for the speed with which you can deploy weapons. Take the shield’s interceptor missiles. In the old way of building things, a few missiles would have been built and tested repeatedly until it was clear they could reliably launch, sync up with central command, interact with radar, intercept a test missile that shrouded itself in decoys, make the necessary discriminations and blow the proper target from the sky. But under the new way of building things, all you have to do is have the whole thing worked out on paper, in simulated computer run-throughs and a few limited real-world tests. That’s why fields of interceptor missiles are already up and, in a capability-based way, running in both Alaska and California.

Of course, the “deploy now, test later” approach has its drawbacks. During a 2005 run, the interceptor couldn’t get out of the silo because the retraction arm — which hadn’t been tested properly in real-world conditions — didn’t fully retract, causing the entire system to shut down. In the old knowledge-based world, that probably would have been worked out before deployment. But in the capability-based world, each interceptor had to be removed, a new retractor system designed and installed, and the interceptors put back into the silos. …

If the old question was whether or not the technology worked — and it still has not been satisfactorily answered — there now appears to be a new question: Even if the technology is found to work, given the current schedule, will missile defense be fully operational anytime in the next half-century? …

That’s not the best part, though:

Last year, three weeks of heavy rain did what no invading army could pull off: It penetrated Fort Greely’s defenses and took out a quarter of the missiles. The silos and the electronics vaults adjacent to them were flooded — one silo was filled with sixty-three feet of water. Boeing blames the military, the military blames Boeing. According to the Missile Defense Agency, it is not cost-effective to repair the damage. Moreover, it is now considered too dangerous to work near missiles in the undamaged silos. The latest budget has a line in it to start from scratch: The government plans to build a completely new field of twenty missiles.

Tell me there’s a difference between this mentality and:

This is, I think, the most common way for my bug reports to open source software projects to ever become closed. I report bugs; they go unread for a year, sometimes two; and then (surprise!) that module is rewritten from scratch — and the new maintainer can’t be bothered to check whether his new version has actually solved any of the known problems that existed in the previous version.

Let’s see. Obsession with new and shiny stuff? Check! Belief that technology will conquer all? Check! More interested in releasing product than actually having a product that works? Check! Complaints from other developers about fundamental flaws in methodology unsound ignored? Check! Poorly articulated design goals with no clear roadmap to achieve those goals? Check! Wow, that’s really disturbing — the new and improved Department of Defense really does look like a CADT software project.

I weep, but I don’t know why.

(We will, for the sake of politeness, ignore the geopolitical implications of missile defense. Gwynne Dyer had it right almost a generation ago: “Star Wars won’t help people survive, only missiles.” The issue isn’t — and has never been — one of defending friendly lives, but ensuring that American weapons can be delivered without fear of retaliation; back in the cold war this was more about preventing a counterforce first-strike, today it probably has more to do with having the ability to blow the shit out of Tehran or Pyongyang without worrying a hidden launch site might get overlooked.

On a totally unrelated note, Jack Hitt is a fantastic writer who desperately needs a frickin’ Web site or something so he can point to his latest articles and say, “hey, go read!”)

Linux, free, time, worthless

So in the process of trying to make my desktop box marginally more useful while I await the arrival of a replacement power supply for my notebook (moral: I should not be allowed to play with electricity lest I make things go sparky-spark), I decided to try installing some software. Naturally, this involved upgrading stuff. Naturally, this involved looking for six packages to install one, and ensuring I had the dependencies for the dependencies. Naturally, me being me, I gave up and said “screw it” within about an hour. It wasn’t worth it.

Especially after I discovered that, oh, by the way, at some point in the last three years we changed glibc versions.

I don’t know if you’ve ever had a machine with an obsolete shared library, but it’s a lot like being in hospice care. You know you’re going to have to face the horrible truth at some point in the future, but you can put it off by patching stuff up or taking high-test analgesics. Eventually you’ll reach a point where you decide it just isn’t worth it anymore, and give in. Basically, nothing new will compile. Which means you’re SOL if you want anything fun or interesting.

I am told that Slackware’s upgrade path is marginally less painful than it used to be, inasmuch as it is theoretically possible to get away with updating everything to the latest versions without actually rebooting. (I’ll believe that when I see it, thanks.) And I guess I’m going to have to plunge in and do the upgrade, which is a dangerous thing for a guy who can’t update his kernel without hosing LILO and spending half an afternoon trying to remember which magic incantation makes LILO happy again. (I’ve forgotten again — really worrying.)

And yes, I fully understand that whatever hacker cred I used to have is fully gone by this point, and I am totally fine with that. This was driven painfully home the other day when I realized a Microsoft product was the most reasonable solution to a problem I was trying to solve, and it didn’t make me want to cry.. and that the “open source software” alternative made me want to think about buying a shotgun.