Transferring Facebook usernames

I had a problem this month that appeared to run into Facebook's strict limits on username creation and transfer, and had a bumpy time figuring out whether I could do what I wanted to: transfer a Facebook username from a profile to a Facebook Page owned by the same account. My account, as it happens.

Here's a quick primer, in the hope it'll help someone, somewhere, sometime...

Word of warning: if you're trying to learn how to transfer a Facebook username between Facebook accounts, I can't help. Facebook's docs say quite clearly that it can't be done.


The Problem: transfer a FB username within an account

I've had a personal account (profile) on Facebook for some time now. Along with 800,000,000 others as of this post's timestamp. When Facebook first permitted folks to set a "username" in June 2009 -- a personalized URL to point to my presence on Facebook -- I jumped to claim stevemasover as soon as I could. I figured it beats numeric gibberish hands down.

Then I decided to create a Facebook Page. I'm preparing to have a Facebook presence as an author, for that golden moment when my novel mss. Consequence is published ... or perhaps sooner -- e.g., should I decide to self-publish short fiction in e-book formats, including those of my stories that have appeared in small literary magazines that are now difficult or impossible for readers to find.

It's pretty clear that stevemasover is the best personalized URL for my author page ... it's the name under which I publish, and if a reader were looking for me that's the name she'd seek. It doesn't matter so much what I use for a personal Facebook username: if you're a friend in analog life, it's not hard to find me.

The thing is, I couldn't assign stevemasover to my new Author page because the username was already taken. By me, yes, but username juggling turns out to be more complicated than I hoped.


The Background

Facebook usernames are 'personalized' URLs for your presence on Facebook -- either your personal account, or for Facebook Pages you own/administer. General information in FAQ form can be found in the Facebook Help Center.

There are a number of strict limits on picking usernames, mostly to avoid "username squatting" -- a term that refers to creating a username as a form of digital land grab. Facebook is also careful to preclude development of a secondary market in usernames similar to the market in domain names made possible by "cybersquatting" (domain squatting). Fair enough. Mark Zuckerberg and crew are encouraging good behavior here.

Here are some of the rules:

• If you don't like your username for your main (personal) account/profile, you can change it ... but only once.
• You can't ever transfer a username from one account to another.
• A username is meant to clearly and honestly identify the person or page with which it is associated. If Facebook thinks you're squatting on a username, or using it deceptively, or doing any other bad thing with it, they reserve the right to remove or reclaim it.

I wanted to transfer my username, stevemasover, within my account: the author page I created is owned by the same account I use for my personal profile. I was not able to find explicit statements in the Facebook Help Center that one is permitted to do this, perhaps because the company doesn't want to encourage username juggling.

Hmmmmm....


The solution that didn't seem to work ... until it did

I did find a thread on a Facebook Page run by Custom Fanpage Templates (a business external to Facebook) that described a number of users' experience doing just what I wanted: to transfer a username from a profile to a page within the same account. There was a caveat. Many experienced delays, not all for the same duration; and sometimes, some reported, the transfer doesn't work at all. In general, the users on this thread reported, on attempting to effect the change Facebook initially responds with a message that the username in question is not available for assignment to the page. But after some number of days the transfer is allowed. Usually.

I gave it a shot, and my experience mirrored those of other users. I didn't do a good job of counting, I'm afraid, but it was something on the order of nine to twelve days that I had to wait.

Here's the recipe, using my own username as an example. The assumption here is that you already have a personal account with a username assigned, and want to reassign the username to a Page owned by the same account.

1. Release the username that you want to transfer by changing it to something else. In my case, I changed my personal profile's username from stevemasover to another variant of my name. Remember, you only get one chance, so be sure you're going to like the 'something else' forever, or until you quit using Facebook -- whichever comes first.
2. Try to assign the 'released' username to the Page to which you want the username to point. In my case, I tried to assign stevemasover to my newly-created Facebook Page Steve Masover (Author).
3. Check the availability of the username you want to transfer/assign (there's a button to click). You're going to get a very dissapointing message, something like this: Username stevemasover is not available.
4. Don't despair. Try again in a couple of days. Then again in a week. Then again a few days later. Etc. As I mentioned, it took 9-12 days after I performed step #1, above, for stevemasover to become available.
5. When the joyous day comes that your desired username is available to assign to your page, STOP. Make really, really SURE you spelled it right. Once you assign a username to a page, you're stuck with it. If you make a mistake, you're out of luck.
6. Confirm that you want to assign the username to your page.
7. Voilà!

Why the delay?

I don't know for sure, and neither (it seems to me) does the fellow answering questions on the thread I referenced earlier. His theory is that a periodic purge of old files is performed every 14 days on Facebook's servers.

I suspect something slightly different, but only slightly: Facebook supports a lot of users, and therefore uses a lot of distributed, redundant servers to store and serve data. When a change is made to a large array of servers of this sort, it takes time for the change to replicate across the entire system. In order to avoid problems that arise from storing conflicting data on different parts of its vast array of servers, Facebook may enforce a delay. The delay might be for a fixed period of time, giving changes time to propagate throughout the network before a username is released for reassignment; or there may be a process that tests or tracks completion of propagation throughout the network. Same net result, in either case: if my theory is correct, once all the servers have recorded that the 'old' username is no longer used to point to an account profile, its owner is permitted to reassign the username to a Page.

There's nothing much to see yet on my Facebook author page. But stay tuned ... and feel free to "Like" Steve Masover (Author) in the meantime!

Migrating Palm to iPod: a dinosaur evolves

The Cretaceous era

I'm never the first to lunge for the bright and shiny. My apartment building dates from the 1920s. My car is a '91 Subaru.

I started using a Palm T|X a little more than halfway through the gadget's 3.5 year production run. I've been using it for about four years, until last week. What happened last week? I bought an iPod Touch 4G.

(Why not a smart phone -- an iPhone or an Android? Simple. I don't like to get sucked into screens when I'm out and about, and I hate talking on the phone. So why pay a monthly data plan fee only to suffer always-on internet and always-available phone service? Look, that's a plane ticket to Paris, each and every year. Think about it. Anyway, you can run Skype on the Touch 4G over a wireless connection, if you've got one. That's good enough for me.)

When I first got a Palm T|X I migrated the data from my Palm Tungsten T, a device I used for the previous four or five year. Mostly calendar, contacts, and a categorized pile of notes, everything from poems I like to carry in my pocket, to the battery type used in my desk clock, to New York restaurants that friends recommended, to my novel manuscript.

A novel manuscript, you ask? On a PDA? What ever for? Well, backup for one. Also, I have an infrared keyboard that works with the T|X, and software from DataViz called DocumentsToGo that lets me create and edit Word documents on the device. It's a handy way to work in a cafe, lighter than a laptop.

But I'm not selling Palm PDAs today, I'm talking about getting from point A to point B.

See, migrating from an old Palm to a new Palm is one thing. Palm had me covered, it was a cakewalk. Getting data from a Palm device into an iThing? That's another story altogether.

Warning to readers: this is going to get pretty geeky. More than anything it'll be useful to folks migrating from Palm to iPod themselves.


What to migrate?

With eight or nine years of accreted information in my latest Palm device, I was determined that before I made a switch I had to know I could get the important stuff moved over without undue pain. For me the important stuff included my old calendar data (which functions, essentially, as an electronic diary -- a record of what happened when); contact info that includes personal and work-related people and businesses; and all those notes, to which I've more-or-less outsourced long term memory.

A look around the web wasn't encouraging. I found little in the way of one-stop solutions. Those who claimed to have easy-to-use synch software that would migrate everything sold it at a cost (i.e., it wasn't freeware), which would have been fine ... but the fine print revealed that the products don't quite do everything after all.

Some of the solutions were cloud solutions. I wasn't looking for a cloud solution. The "P" in "PDA" stands for "Personal." Personal Digital Assistant. I didn't put information about who I met when, what I need to tell my doctor, and so on, into my P-as-in-personal D A only to upload it to some corporate-owned server and have Sergei Brin or Steve Jobs datamine it, or hand it over to the government. Nein danke.

What I really wanted was to use my new device's built-in synchronizing capability to migrate the big ticket items, and to keep a copy of that same data current on my home computer. If I could do that I'd be happy to let the little stuff go. Setting low expectations, in my experience, is the surest path when it comes to getting machines to do one's bidding. Did I mention that I work in Information Technology? Shoot yourself in the foot enough times, you learn a thing or two.

So what were the most likely options? Outlook. iCal. Address Book.

I'd never used any of these programs before. I've owned and worked on Microsoft computers since the early DOS days, but have avoided Outlook like the plague. I'd always figured the Mac's calendar and contact tools were for those who use Apple bit boxes as their primary machines. My Macbook is far from primary, it's a carry-to-meetings machine (a plague on meetings, with or without a sleek little laptop).

Nonetheless, Outlook, iCal, and Address Book looked like the most complete, ready-to-roll options for desktop synchronization of my new iPod Touch.

Since my main machine is a Windows 7 box, it looked like Outlook was going to have to replace Palm Desktop as my home computer's repository of the stuff I carry in my pocket device. I installed Outlook 2010 reluctantly -- I'd unchecked it when I first installed the MS-Office suite, because I had no interest in using the application. So it goes.


The pain

But neither the export capabilities of any one version of Palm Desktop, nor the iPod-friendly import and synch capabilities of any one desktop app or suite were up to the task. Not solo.

Palm Desktop 6.2.2 on my Win 7 machine would happily export all my notes, and keep the categories straight; and Outlook 2010 would happily import them. But that version of the Palm software wouldn't export all my old calendar data in a single go, or my contacts either. And one-at-a-time was a non-starter.

Palm Desktop 4.2.2 on the Mac, on the other hand, would export calendar data and contacts (as vCal and vCard data sets), which could be imported into iCal and Address Book on my MacOS 10.6 laptop ... but I didn't see a way to move the notes over using the Mac software.

I needed all the bit boxes I could get my hands on. And two versions of Palm Desktop. The migration was going to be a hack. Pity the schlub trying to juggle this stuff on one operating system.


How I migrated

First I exported my data from the desktop-synched copies of what I had on my Palm device, and into desktop software to which the iPod Touch 4G could synch:

• Calendar: From Palm Desktop 4.2.2 on MacOS 10.6, I exported all calendar items as vCal. Then I imported them into iCal (included w/ Mac OS 10.6).
• Contacts: From Palm Desktop 4.2.2 on MacOS 10.6, I exported all contact items as vCard. Then I imported them into Address Book (also included w/ Mac OS 10.6).
• Notes: From Palm Desktop 6.2.2 on Win 7, I exported all notes as Tab-separated values. Then I imported them into Outlook 2010. While I was there, I moved categories of notes into folders I created using the category names. This was a waste of time as far as the iPod is concerned, but it keeps the notes more organized on my desktop.

Next, I did a double-synch trick.

When I first started the new iPod Touch 4G I synched to iTunes on my Win 7 machine. That became my "home" iTunes instance, but the first synch was all about music, not about moving PDA data into the iPod.

Once I had all my Palm data exported and imported properly into iTunes-compatible desktop software, it was time to port it to the new device via synchs to iTunes on both my Mac and Win 7 computers:

• First I synched the iPod to iTunes on the Mac. I had to be sure to specify that I did not want to overwrite the iPod with the music in my Mac instance of iTunes -- I wanted to keep my Win 7 desktop as the machine to which I would normally and primarily synch. But on the "Info" tab of iTunes, I specified that I wanted to synch Contact and Calendar data between the Mac and the iPod. Voilà. Palm data migrated.
• Second, I synched again to iTunes on my Windows machine, this time specifying on the "Info" table that I wanted to sync Contact, Calendar, and Notes data with Outlook. Voila, Palm notes from Outlook to the iPod, iPod calendar and contacts from the (Mac synched) iPod to Outlook.

Then it was time to look at what got screwed up.


What I lost

Nothing worked perfectly. But, remember, I'd set my expectations low...

• Calendar: This was the most painful migration. A lot of repeating events didn't migrate at all, I can't say why. Others migrated ... weirdly (all day events that ended up spanning two calendar days). And notes associated on my Palm T|X with repeating events that did migrate were nowhere to be found in Outlook or the iPod (they'd made it only as far as iCal). I had a fair few repeating events, many of which had notes, so that was disappointing. Repeating events are handled weakly in the iOS calendar app, so it's not so surprising that the migration dropped data at the iCal-to-iPod step. Alas. On the other hand, much of my calendar data did migrate, including future events which are the ones that matter most, so I'm just sucking it up, copy-pasting the future-essentials from Palm Desktop to Outlook, and letting the past remain archived in my Palm Desktop software. For a few more years, anyway, then it'll be bye-bye forever.
  
• Contacts: So far I haven't found any lost data. On the other hand, custom fields are labeled in a pretty ugly way: X-Palm-Custom1: blah blah blah. Ditto for categories (X-Palm-Category1:...). Okay, I'll live with that. Over time, if I get really bored, I'll manually edit out the field names.
  
• Notes: Notes on the iPod are weak too. There are no tags or categories, it's just a big old pile of stuff. The good news is that iOS makes it easy to search through big piles of stuff. Still. Bummer.
  

I didn't mention ToDo lists. I used them on the Palm, but iOS doesn't have a native ToDo app (that'll change in the Fall, it is said, with the rollout of iOS 5's "Reminders" app). I'm planning to copy-paste the ones that matter manually, assuming I upgrade to iOS 5. Yeah, I could download an app and have it now ... one friend recommended Toodledo, which is practically free at $2.99. Maybe I'll try it as I settle into the new device.


What I gained

So far I like the iPod Touch well enough. The wireless works great, and the Safari Browser is a better web experience by leagues than what the Palm T|X had to offer. The calendar is underpowered compared to the Palm device, but I'm learning to live with it. Skype can call phone numbers from the Contacts app if you have Skype credit or a subscription that pays for calling land lines: I do, and that's convenient. Handling music, of course, is what the iPod is really built for even though it's not my main interest in the device -- for me that's a nice to have. Ditto for the camera, with which I'm not impressed, but maybe I'll get the hang of it and come to depend on that more over time. The display is awesome.

Maybe the most dramatic gain is among the most mundane: because the Palm T|X is essentially a dead device, I couldn't get an up-to-date app to keep a schedule for the BART system -- the Bay Area's regional rail -- to carry in my e-pocket. Problem solved, thanks to iBART, with a big shout-out to the Pandav team.


Anybody want to buy a used Palm T|X?




Related posts on One Finger Typing:
Rock, Paper, Digital Preservation
Safeguarding cloud ephemera Part I: the big picture






Thanks to Stefano Palazzo for the Palm T|X image on the Wikimedia Commons.

Early review of changes to Google Groups

The old Google Groups is dead. Long live the new Google Groups?

In November I wrote about upcoming changes to Google Groups that, it seemed to me, signaled Google's next moves in social-media space. Those changes have arrived, as of last week.

Google Groups no longer permits upload of files or pages. One can view preexisting files and pages, and the last "welcome message" at the top of the old-style home page as it was published prior to the Jan 13th changeover date. But no new pages, files, or edits to the "welcome message" are permitted. This is precisely as the Googleplex forewarned.

But the new discussion forum interface permits inclusion and update of a welcome message -- not a feature that I understood to be in the pipeline -- and files can be attached to any post in a forum discussion thread (this feature can be restricted to managers-only).

Posting files in discussion threads is a double-edged sword. In many forums (including the one I am active in) most participants elect to receive updates to discussions via e-mail. For many, receiving large attachments is unwelcome ... smaller e-mails in which links are given to files that can be downloaded when and where needed don't eat up as much local disk space or webmail storage quota. It's possible to avoid this problem by engaging with a forum only through visits to its website, but for those who prefer e-mail notifications and don't like receiving attachments this feature may prove annoying.

One of my chief complaints in November was that Google Sites didn't have a supported gadget to embed a Groups forum in one of its pages. Setting up a Google Site to host a Group's web pages -- and to serve as a location to which files may be uploaded -- is one reasonably clean way to replace functionality that is unavailable in Google Groups as of last week. I hoped to use that option for my Google Group, but without a supported gadget the option was pretty much a non-starter.

The good news is that Google now provides a Sites integration gadget.

As I mentioned in a comment on the original post, Jiten Bhardwaj was first in a thread I started in the Google Sites forum to point out the new, embeddable Groups widget rolled out for Google Sites. For info on how to use it, check out the new Groups UI help article on the topic.

Also noted in a comment on my original post, the new UI for Google Groups includes elements that do seem designed to support the Groups offering's alignment with Google's social-media strategies, such as "lightweight comments." These are tweet-sized riffs that can be added to any regular post to a Discussion Forum; however this feature only works for groups that conduct all business in the Groups interface (e.g., that have e-mail delivery disabled). The new Groups UI is explained in a set of Help articles for those who want more info.

My on-line writer's group has been using the new interface embedded in our Google Site for several weeks now, and I have no serious complaints.

On the other hand, I do wish it were easier to extract a thread from the Google Groups forums. Data portability matters, even if all that means is an ability to easily download a post or a whole thread for preservation or re-use elsewhere. For example, I like to keep sometimes-long threads of my fellow writers' comments on a story or chapter for future reference without wading through our group's archives, or so I can consult it off-line. Copy paste will do in a pinch, but something cleaner would be a nice feature.

It's worth remarking that in the Getting Started screen for the new UI, the Googleplex warns that "The new Google Groups user interface represents the first in a series of updates to Google Groups..."

So we'll see where this offering goes....

Safeguarding cloud ephemera Part II: keeping your blog alive

Last week I wrote about the vastness of the information universe and how unlikely it is that most, let alone all of it, will last.

To recap from last week: Artist, poet, and longtime friend Leah Korican commented on a recent post with this suggestion:

"Here's something I wondered about that you might write about...the longevity of these blog posts and other internet publishing. In other words is it important that they are preserved? Do you print them out and save them? What is their lifespan? Will they still be around in 10 years or 50? I have printed email and saved it occasionally but wonder if all the digital stuff will vanish."

This week I'll take a look at a smaller problem Leah asked about: the longevity of blog posts.

Getting Practical: Preserving Your Own Blog Posts

So leaving aside the grandiose questions for a moment, let's suppose you post to one or more blogs and don't want to lose what you write. A reasonable and reasonably common desire? Okay, then. There are a few problems to think about and address:

1. If your current blog platform goes away, how can you migrate your stuff to a new blog platform? I'll write mainly about Blogger and Wordpress in this post.
2. How can you preserve blog posts in more general formats, to have a reusable record (digital or otherwise) of the work you did creating them?
3. Who's going to care after you're dead?

Technology folderol aside, if you're blogging you know that the effort and the value in the exercise is in the posts you write, including the research that undergirds your posts; the synthesis, often in the form of hyperlinks, that points to sources of your research; and your brilliantly crafted prose.

That you rely on, say, Goggle's Blogger, or Wordpress.com, or TypePad as the venue by which to publish your work is really secondary to the effort you put into blogging. If you have downloaded Wordpress or Movable Type software to run yourself, as part of your own website, these are infrastructural efforts you have taken on in order to publish your blogging work, but are not the work itself.

To protect your blogging investment -- as opposed to your blog publishing investment -- you'll want to be able to easily save the blogs you create in a format that (1) won't disappear; and (2) can survive disruptions your to publishing platform (from platform failure to your change of heart about which you wish to use)

You don't want to lose your hard work, and you want to be able to keep it available on the internet.

1. Migrating between blogging platforms

Whatever platform you use to publish your blog, a key consideration is whether and how you can get your stuff -- the blogs you've researched, written, linked, tagged, illustrated, and decorated -- and upon which your bazillions of faithful readers have extensively commented -- off the original publishing platform and onto another, if you choose to or need to.

I'm going to talk about how this works with Goggle's Blogger or Wordpress.com because those are two widely used and popular platforms, and I know more about them than I know about others. The same ideas apply to any other platform, and you'll want to look into ability to export your blogs -- and what you can do with the export files once you've got them on your hot little disk -- no matter what platform you use. Ideally, you'll know something about how this works before you make a decision to invest a lot of blogging time on a platform ... because you're going to have to live with the consequences of your choice. Try before your buy.

The short story for Blogger and Wordpress is this:

• Either of these platforms permits export of your blogs in a fairly complete way, including the text, links, tags, embedded images, and comments
• Wordpress software can import a blog exported from Blogger, directly and without special tweaking or processing
• It's possible to migrate to Blogger from Wordpress, but this isn't as easy as the other way around

To export or import a Blogger blog to/from "Blogger export file" format, follow the instructions on the Blogger help site. The export file is a structured data document in XML format, but that's probably not important to you. The point is that you can take data exported in this format and either (a) create (or re-create) a Blogger blog with it; or (b) create a Wordpress blog with it. (Presumably you can create a Movable Type or TypePad blog from a Blogger export file too, but I haven't tried this so caveat emptor.)

To export your blog from Wordpress.com, follow instructions on the Wordpress Export support page. With the export file -- also an XML file in what Wordpress calls "WordPress eXtended RSS or WXR" -- you can create another Wordpress blog, either on Wordpress.com or on an installation of Wordpress software that you manage. If you want to migrate your blog content from a Wordpress platform to Blogger, you can try out the WordPress2Blogger web service as explained in this article ... I haven't tried this, so I can't say whether or how well it works.

Wordpress.com claims to make it simple to import a blog you have created on Blogger, LiveJournal, Movable Type, Typepad, Posterous, Vox, and Yahoo! 360 -- in theory, you "Simply log into your WordPress.com blog dashboard, then go to Tools -> Import, choose your previous platform and follow the instructions presented." I can tell you from personal experience that import to Wordpress.com from a Blogger export file is a snap. Works like a charm, just as advertised.

Remember that just because you exported posts from your blog once doesn't mean later blog posts are saved! Export as often as you need to in order to maintain a safe, portable, reasonably current copy of your work. Back up your back up files, storing them someplace safe; or, better yet, store them in several someplaces!


2. Keeping stable copies safe

Moving between blogging platforms may not be enough to satisfy. You might also want to save your work in some usable, accessible, shareable format that's independent of whether or not blogging platforms exist. Maybe you'll want to do something else with your magnificent material next year, or ten or twenty years into the future. Technologies die, as I wrote last week.

There are a number of strategies you can take to preserve your blog's content.

One idea is to create your blogs using an independent tool, saving the created content independent of your blog's publishing platform, and copying it to the platform when you're ready to publish. For example, you could create your blog using a word processing program, or with Google Docs, then do the old copy-paste. If you use a word processing program on your own machine, you know how to save files, and your backups can include digital copies stored on multiple devices or disks and stored in multiple safe places; and/or printed copies, also stored in multiple safe places. More copies and safer places leads to better likelihood that you won't lose your stuff. If you use Google Docs, you can save copies of the cloud-stored files (on Google's servers) to your own disks, DVDs, flash drives, etc., in a variety of formats, such as HTML, OpenOffice, PDF, RTF, Text, or Word. Of these, HTML, text, and RTF are probably the safest (longest lasting, most independent of particular software tools). Plain text doesn't let you keep any formatting.

An ongoing way to export your blog is to e-mail it to yourself. Then you can use the same methods you use to assure that your e-mail is backed up (you do back up your e-mail, right?) to back up your blog's content. Blogger allows you, as the blog owner, to choose a small number of addresses to which each post will be e-mailed as they are published; to do this, go to your blog's Settings | Email & Mobile page and type in the e-mail address(es) to which you want the posts sent (as I write this post, Blogger's help page on this is more-or-less correct, but the illustration is a little bit out of date). Wordpress.com enables Blog Subscriptions that permit people (including yourself) to receive e-mail copies of blogs as they are published.

(What if your e-mail itself is "in the cloud" -- i.e., if you use Gmail or Microsoft Live? You might consider setting up a local e-mail client that downloads your remotely-stored e-mail to your local computer. I use Thunderbird myself, which is an open-source e-mail client from the Mozilla Foundation, the folks who make Firefox. You'll have to open/use the client to effect the downloads. Make sure you're downloading full e-mails, and test that it's working as expected by disconnecting your machine from the internet and making sure your mail is still available. You'll want to back up the local e-mail files, of course.)

And there's always paper. Paper has a better track record than digital media for long-term preservation (in large part because we humans invented paper a long time ago, digital media not so much). The downside? It's more tedious to reuse and revise paper copies of your work. You have to scan it into digital format, losing content and/or format in the conversion; or retype from scratch; or -- imagine! -- transcribe it with ancient twentieth-century instruments, like ball point pens. Still, that's easier than resurrecting something you wrote years before from wetware (a.k.a. your natural memory), at least for most of us.

Whatever way you save your blog posts, backup matters. For your digital copies -- whether in blog export format, e-mail, word processing formats, etc. -- be sure you take the same kinds of precautions with the data that you would with any other file(s) you hope to keep beyond the life of your current computer's hardware. Back it up. Save it in a safe place, on a device that you will be able to read into the future. When technology changes, it's your responsibility to move data to a format or device that the new technology can read. If you delay this chore, it can become onerous or impossible, as my experience converting a pile of near-obsolete 5.25" floppy diskettes showed me earlier this year. There are no magical solutions to this problem ... letting a "cloud" provider safeguard your data works until it doesn't; and that nifty floppy / CD / DVD / Zip disk / external hard disk / flash drive will become obsolete in two or five or ten or fifteen years. Bank on it.


3. But ... will my work be immortal?

You can do your best to preserve the things you research, write, and link -- and the comments people make about them -- but that's no guarantee of immortality, or even continued existence for a few human generations. Publishing your work in a format someone else (like a librarian) is likely to archive, and having it widely read is your best bet, because it spreads the task of saving your stuff to a broader set of people who care -- a situation many aspire to, but few achieve.

Even so...

Libraries fail. Unsold books are pulped every day. Boxes saved in the attic might last a few years or fifty or a hundred before whoever has custody of them loses interest or loses track.

With respect to archiving blogs -- as Leah put it, "is it important that they are preserved?" -- I suppose the best way to answer that question is with another: important to whom?

I ended Part I of this series with a nod to George Harrison's All Things Must Pass. How about a little T.S. Eliot today, from the opening of the second of his Four Quartets, "East Coker":

In my beginning is my end. In succession
Houses rise and fall, crumble, are extended,
Are removed, destroyed, restored, or in their place
Is an open field, or a factory, or a by-pass.
Old stone to new building, old timber to new fires,
Old fires to ashes, and ashes to the earth
Which is already flesh, fur and faeces,
Bone of man and beast, cornstalk and leaf.
Houses live and die: there is a time for building
And a time for living and for generation
And a time for the wind to break the loosened pane
And to shake the wainscot where the field-mouse trots
And to shake the tattered arras woven with a silent motto.

(This post is the second in a two-part series. The first, Safeguarding cloud ephemera Part I: the big picture, was published on 2 September 2010.)


Related posts on One Finger Typing:
Breaking technology: Google's Blogger outageMoving one's life to the cloud
Safeguarding cloud ephemera Part I: the big picture