Wandering Thoughts archives

Why I don't rip my CDs

From a comment here:

I would suggest that you rip [your CDs], though.

I have no interest in ripping my CDs for a number of reasons:

• I listen to whole albums at a time, cycling through my collection in an essentially fixed order. This means that at any given time I'm only really interested in the next few CDs and having everything sitting on disk is of no particular benefit.

  (Cycling through my collection this way avoids the twin perils of burning out on albums that I really like and forgetting neat stuff.)

• although disk storage is getting cheaper and cheaper, I have enough CDs that ripping my entire CD collection would still take enough disk space to be annoying. I just don't feel like dedicating that much space to something I already have perfectly good copies of.

• I listen to my music at both home and work, which would require either replicating the entire collection or dealing with sloshing data back and forth. (Transporting actual CDs back and forth is much easier; I just grab the top few from the 'to listen to next' stack.)

There is something to be said for ripping CDs for archival purposes (digital data can be more durable than silver platters that are now out of print, and I have already had a couple of CDs succumb to disc rot). However, that would require a lot of disk space, since I am neurotic enough to insist on ripping in a lossless format if I'm doing it as an archive.

(If you do want to rip CDs, though, current Linux software seems to make this pretty effortless. I have been pleasantly impressed, since the last time I tried this it involved manual usage of cdparanoia and similar things.)

Should you care about whether you can upgrade hardware?

An online discussion I was in today touched tangentially on the question of how important it was to be able to upgrade the hardware on non-server machines (and how upgradeable various sorts of them are). My view is more and more that it probably isn't all that important.

(To be clear, I'm talking about post-purchase expansion down the road, not being to add necessary stuff at purchase time. If the machine doesn't do what you need at the start, you just don't buy it.)

Historically, we've almost never expanded or upgraded machines. We buy them in the configuration we want, usually with some extra margin in things like RAM and CPU power, run them for BIGNUM years, and then replace them wholesale. By the time a hardware upgrade seems necessary and can be sold to the powers that be, you usually can't get the necessary hardware bits any more.

(And even if you can, the assumptions that you built the machine on may seem quaint and outdated, like 'SCSI drives are the way to go' or 'it's too early to trust SATA, we'll stay with IDE'.)

So, how often are real machines actually expanded or upgraded? My own suspicion is that most machines that actually get upgraded were underconfigured when they were bought, for whatever reason. (Price is one obvious one.)

(Thinking about it more, part of my lack of interest in upgrading machines is because I like to keep old machines in an operable state, either as backups or to be used for various undemanding things.)

People aren't suspicious

Here's a lesson that in retrospect I first absorbed from seeing people fall for what were really rather bad forgeries on Usenet, way back when:

Most people aren't suspicious.

Most people see what they expect to, and don't notice what they don't expect to. If something is missing, people fill it in automatically; if something is vaguely off, people ignore it. You don't need to be good to fool people; you just need to not be bad enough to force them to notice.

We suspicious people find this hard to believe, because to us the faults are so glaring and obvious; how could anyone fall for it? But we're a rarity, and even then we're probably not suspicious outside our sphere of reflexive expertise. (People who are suspicious about everything in their life look at least more than a little bit obsessive.)

(There are some fascinating psychology of perception experiments that suggest that this is in fact more or less innate; people just don't notice things that they consider unimportant at the time. See also here and here, for example.)

This is ultimately not very surprising. Almost all of the time, being suspicious is just extra work, and evolution has been very good at training us to be lazy.

This does a lot to explain the success of phish spams, for example; after all, most of them have obvious problems that are easily picked up by an alert nine year old, yet they still work.

(This makes me think that the only anti-forgery and anti-phish technique that will really work is to figure out what people actually read and then make it glaringly different from what they normally see.)

Some ways to break your syndication feed

To follow up my previous entry, here's the sort of thing I mean by the term 'broken feeds', as taken from things I've been frustrated by in the wild:

• advertise a feed on your site, but never update it.
• silently stop updating your feed because it's moved to another URL.
• put in partial entries that look like full entries.
• don't include all of the new entries from your site in your feed.
• include entries in your feed that aren't actually there on the site. Bonus points are awarded if they are partial entries or otherwise require content from your site that isn't there.
• stutter: have your feed repeatedly show the same entry as a new entry by doing things like changing the Atom <id> of blog entries.

Technically I should count things like removing your feed or having a feed that doesn't validate or has mangled formatting, but I don't really; those are relatively easy for me to see and deal with. The kind of stuff that I really consider broken is stuff that either causes silent information loss (the first four) or makes me do extra work for nothing (the latter two).

(I have actually seen feeds that had both missing entries and extra entries, with the net effect that I had to read both the feed and the site to get a full picture.)

Broken syndication feeds are worse than no feed

Over the time I've been using syndication feeds a lot, I've had to deal with various sorts of feed problems. And I've come to a conclusion: broken feeds are usually worse than no feed at all.

Broken feeds invite you to trust them, but then betray that trust; you wind up doing extra work to make sure that you're actually seeing everything and what you're seeing is actually there. (Broken feeds are also frustrating; if only they weren't broken, they would be so useful. A shiny thing is being dangled in front of you that you can't have.)

Or to put it another way: if a site has no feed, at least I don't have to waste my time trying to use it and get annoyed at its problems.

So, if you've got an incomplete, erroneous feed, please do everyone a favour and shut it off (with a notice about it!) until you can make it work reliably. How can you detect that your feed's got problems? Well, let me suggest that you read your feed.

As a corollary: if you are going to shut down your feed or stop updating it while your site keeps going, please do put up a final entry in the feed about it. Don't assume that just removing your feed URL will be noticed by everyone, because there are any number of online feed reader interfaces that don't show that to the user.

A thought about disaster recovery planning

Disaster recovery planning is famously difficult, and not just because it's a hard subject. In fact there seems to be a kind of repulsion field that makes people either shy away from thinking about it or dismiss it as something that they can't do anything about anyways. (The latter is the 'if we have a serious fire the organization's dead anyways, so why worry about the backups?' mindset.)

I've come to think that one significant reason for this is that when you plan realistically, you wind up with a list of disasters that you are deliberately and consciously not going to be able to recover from. The problem with this is that choosing to lose data and systems in some circumstances never sits very well with people, sysadmins especially; we feel that our job is to save data, not to callously throw it away because we didn't want to try hard enough.

However, if you don't tackle the issue, you're not choosing to lose data in cold blood, you're losing data because you never thought about the problem. It's a lot easier to contemplate losing data through ignorance than through apparent choice.

(And even if we accept that we can't do anything, actually thinking about it makes us feel helpless, which people generally dislike.)