Wandering Thoughts archives

Reliably archiving things

Reliably archiving things is a troublesome issue. There are a number of places to find numbers for how long CD-Rs, DVD-Rs, and various sorts of tapes all last, and lots of debate, and lots of people who will sell you solutions, and so on. I don't have much to add to their numbers and marketing information.

But I have been around for long enough to have burnt my fingers and seen other people's fingers burnt, and thus I have arrived at what I will modestly call:

Chris's first law of archiving: don't.

If some piece of data is important to you, the very last thing you want to do is to put it onto some piece of media and then dump it on a shelf. Sure, the media may last more than your lifetime, but will the equipment to read the media and the interface to talk to that equipment and the OS software to talk to everything and the software to read the format all exist in 20 years?

I've concluded that the most reliable way to insure that something stays accessible is to keep it on live, spinning magnetic media: keep it on disk on your system. (Ideally you'll also store the source code for something that can read it, if only for reference for what the format is.) When you change systems, don't leave the data on the old system; copy it to the new system. Always keep the data on your primary system, because it's the one you take the most care of.

This doesn't guarantee that your important archival data will stay accessible. But it vastly increases the chances that ten years from now you will still be able to do something with it, and will not be stuck trying to find an Exabyte tape drive and software to read SGI EFS filesystem dumps (for example).

People will say that this uses a lot of disk space. My reply is that most people don't have all that much important archival data, and disk space is cheap and growing cheaper every day.

Sidebar: backups versus archives

Backups are not archives; they have different goals.

Backups are what you do to make sure you can get back data if your disks melt down. Backups are tied to a particular system and only have to be durable over the short term (the length of time it takes to replace the system when it explodes).

You should definitely keep on doing backups.

The Myth of Support (Part 2)

There's a story about vendor support people like to tell: if you pay enough money, a lot of money, you'll get excellent support; but if you aren't willing to pay lots of money for support, clearly it's not really that important to you.

I don't know if paying lots of money gets you excellent support; I've never worked for an organization that was in a position to pay that sort of money. (I think you are unlikely to get it from a single vendor, for the reasons outlined in SupportMythPartI.)

But this myth really angers me, and I have recently been able to work out why: we expect things we buy to actually work, especially if they are expensive.

The myth tries to convince you that it is routine to have to pay very large sums of money so that the vendor will fix things that are its own fault. It's trying to convince you that it's right that you pay twice to get a working system. And that is why this myth angers me. I feel that people who buy expensive computer systems have a right to have them work right without spending lots more money.

Also, note that the myth creates a perverse vendor incentive: the more post-sales little problems their systems have, the more you seem to be 'getting your money's worth' from your expensive support contract, so the more it pays for the vendor to allow such little problems to exist.

I'm not likely to get a world where vendors fix problems for free. I can hope for a world where support contracts are more like insurance than prepaid consulting fees. (And this makes the vendor incentives run the right way.)

(Similarly I object to the story that one should not object vociferously when vendors stop providing much support because the expense to them of doing so has exceeded the amount you're paying them. The general rule: the vendor's screwups should be its problem, not yours.)

Sidebar: Maintenance, Support, and Consulting

Maintenance is the process of replacing breakable things as (or before) they break. I expect to pay for maintenance, since things like disk drives do wear out sooner or later. (One may have a debate about whether software can be considered 'breakable' or simply 'not working to spec'.)

Consulting is making the system do something new, outside of what you and the vendor agreed on it doing. The vendor can, should, and does charge you for this, and I have no objections to it.

Support is for when the system doesn't work the way the vendor said it would. This is unlike consulting, because the system should work right, and unlike maintenance, because it is not a breakable thing finally breaking.

Disclaimer: all resemblances are totally coincidental

Read more »

The Myth of Support (Part 1)

There is a story that salesmen like to tell you: if you buy every piece of your system from them, you'll get excellent support because there's only one vendor involved. One set of people who know everything, one place to contact, and there'll never be finger-point back and forth about whose fault something going wrong is.

This is a myth. Let's look at the reality.

Let's say that you want some front-end servers all talking to a big chunk of disk in a SAN (with hardware RAID-1, over FiberChannel) and backed up by a nice tape silo system. For purposes of illustration, you accept the proposal from a company I will call IMoon. IMoon has their own Unix variant which they run on their own servers, and sure should be able to offer you integrated support for all of this. Except:

• does IMoon make their own disk drives? Hint: no.
• does IMoon make their own SAN controller? Hint: unlikely.
• does IMoon make their own FiberChannel switches?
• does IMoon make the FiberChannel controller cards (ICs included) that they put in their servers?
• does IMoon make their own tape drives? Maybe, at best.
• does IMoon make their own tape silo robotics?

The reality is that no single company makes all of the pieces that go into a complicated server environment any more, especially since the best versions of some of those pieces come from companies that specialize in that narrow field.

While IMoon will sell this to you as an integrated system, while it will have IMoon's badge on everything you can see, and while IMoon will have tested it to a reasonable extent, the reality is that if you have a real problem IMoon cannot really provide 'all in one support'. Because IMoon did not actually make some or many of the important components, it has little or no deep technical expertise with them and thus little ability to provide real support for them in the face of complicated problems.

And almost all serious problems are complicated; the ones where something doesn't work but it's not clear where or why or what exactly is going on. This is exactly when you need that excellent support that the salesperson promised and you aren't getting because IMoon is busy trying to get the real vendor's technical people on the phone or all of the various vendors are pointing fingers at each other or what have you.

Ironically, you are probably better off if IMoon serves as an honest system integrator instead. Then you would have the phone numbers of all the real vendors, and hopefully have support contracts with them (arranged as a bundle through IMoon).

Sidebar: how many IMoons are there?

Not very many. To provide true end to end support a prospective IMoon needs to supply both the hardware and the operating system, for the obvious reasons, which sort of narrows the field down. (I believe there are three remaining candidates, one of which doesn't really sell big servers.)

Companies that just provide hardware and bundle someone else's operating system may be able to provide good support; they may be big enough to get the OS vendor's attention and prompt action, and mobilize a lot of powerful high-level people. But they are not providing end to end support, and they are explicitly at the mercy of the operating system supplier if something goes wrong.

Disclaimer: all examples purely illustrative

Read more »

How AMD killed the Itanium

I've been telling people versions of this story for a while, so I figure I might as well write it down for posterity (or at least entertainment).

When Intel started Itanium development work in the mid 1990s, it had a straightforward story: the x86 architecture was about to run into a performance cap, because of all the ugly warts it had inherited from its predecessors (a very limited supply of registers, a highly irregular instruction format, etc). To get the future performance that customers wanted, a modern warts-free RISC-oid architecture was needed: the IA-64.

This was no different from the stories all the other CPU vendors were telling at the same time. Unlike those CPU vendors, Intel realized something important: very few people buy new CPUs to run only new software. Even in the mid 1990s, most people were using Intel x86 CPUs to run their programs, so that was where the big CPU dollars were.

So Intel promised that there would be a magic x86 part glued on the side of the first few generations of Itaniums that would run all of your existing important programs. Because very few people are ever interested in upgrading to a computer that runs their existing programs slower, Intel needed this magic x86 part to run at least as fast as their real x86 chips.

Intel could get away with this for two reasons. First, x86 chips were relatively simple compared to the design that Intel was planning, so it should be easy to glue the core of one on the side of the new CPU. Second, Intel could make the x86 performance story come true simply by moving most of their CPU design manpower (and money) to the IA-64.

Then AMD showed up to ruin Intel's party by competing directly with them. It didn't matter that AMD didn't have faster CPUs to start with; AMD's existence meant that if Intel left them alone, AMD would surpass Intel and kill Intel's main revenue source. Intel had to crank up x86 performance to make sure that didn't happen. This probably had three effects:

• people got diverted from IA-64 CPU design back to x86 CPU design;
• because x86 got faster, Itanium had to get faster too;
• the only way to make x86 faster was to make it more complicated, which made it harder to integrate a current-generation x86 into Itanium.

Naturally, the schedule for delivering a faster, more complicated Itanium slipped. Which kept making the problem worse, especially when making x86 chips go really fast started to require serious amounts of design talent. Instead of designing one high-performance CPU and doing a small amount of work on another CPU architecture, Intel was trapped in an increasingly vicious race to design two vastly different high-performance CPUs at the same time, and one of them had to be backwards compatible with the other.

It's no wonder the Itanium shipped years late, with disappointing performance and very disappointing x86 compatibility performance. (And heat issues, which didn't help at all.)

With AMD's recent x86-64 64-bit extension of the x86 architecture, Intel couldn't even claim that Itanium was your only choice if you needed 64-bit memory space and suchlike. Intel's capitulation to making its own almost 100% compatible x86 64-bit extension was inevitable, but probably the final stake in Itanium's heart. (And likely a very bitter pill for Intel to swallow.)

And that's how AMD killed the Itanium.

What RSS can learn from Usenet

If you look at it in the right light RSS is a lot like Usenet, with RSS feeds taking the place of newsgroups and entries taking the pace of articles. And they both have similar issues of organizing, selecting, and filtering massive amounts of information.

The big difference is that decent Usenet newsreaders have much better tools for dealing with this than RSS readers seem to. At one level this isn't too surprising, since Usenet newsreaders have been around a lot longer than RSS readers. At another level it really disappoints me, because it means that authors of RSS readers are failing to learn from history.

Here's some things I wish feed readers would take from Usenet newsreaders (and soon):

• handling 'crossposts'. I read a number of aggregated RSS feeds, and some people's entries appear in several of them; I would really like to only read them once, the first time. (Atom entries and I believe RSS entries as well have what is supposed to be a globally unique identifier for the entry, so this is certainly possible.)
• 'killfiles': even in non-aggregated feeds there may be some categories of entries that you aren't interested in reading, and in multi-author blogs or aggregated feeds you may want to filter on author. (Feed software authors should make this as flexible as possible, since the feed may not have explicit category labels and you'll have to infer them from things like entry URLs.)
• don't immediately jump to the next unread entry after I finish all of the unread entries in one feed. Newsreaders get this right; when you exhaust a newsgroup, the next newsgroup is only the default choice for where you go next; you get a chance to jump around instead.
• selection filters, to prioritize messages that match various criteria (the reverse of killfiles). One obvious filter might be 'entries that link to my blog'.

In the longer term it would be nice if feed readers could thread related entries together. Unfortunately they have their work cut out for them, as RSS entries don't have the sort of relationship markers that Usenet articles do; however, they can make deductions from things like links in entries.

With threading, the feed reader can then apply selection filters to entire threads instead of just single entries. Imagine being able to see at a glance if there's a new entry related to a cross-blog discussion that you've found interesting, for example.

(None of these features are futuristic or over the top; good Usenet newsreaders have had equivalents of them for years.)