but it does nothing to the Napster case. If I understand what I read correctly the artists are laying claim to authorship rights of the works in question. As someone else has pointed out, this means that if they have authorship rights, the recording label can retain the copyrights to a particular instance of a work, but not all instances.
The reason the artists want this in this case is quite simple - it enables an end-run around the RIAA represented record labels. The artists could record versions of their songs specifically for things like Napster or other mediums and potentially cut the labels out of the revenue stream (the label could not claim ownership of that instance of the work). Obviously RIAA would not be very happy with that.
Again, I am not a lawyer and may be missing a few subtle points of the law.
But for the Napster case in particular it does nothing. Even if the artists' brief is upheld and the documents are amended or refiled, the labels still own the copyrights to the instances of the work (music) in question (as agreed to by contract). That means that if their claims of infringement are upheld, they can still show damages as the owner of the copyrights to that particular recording.
A decent play by the RAC. If it is successful, it will change the landscape somewhat, but I fear all it would mean for Napster would be that a different party would be suing them.
In the case of the "quirky" engineer in the article, he had misdirected capability. Maybe a manager could direct his energy toward the job, but in some cases the job itself is mismatched. Perhaps the "quirky" engineer in the story would work well in the FSF with Stallman doing Mayan calendar elisp code.
[snip]
Indeed! It's a very difficult problem for managers to tackle. I was thinking of things a bit differently though.
I was considering it in terms of the type of workload in an organization rather than as an aspect of an indivdual (altough you've made an excellent observation there as well). In particular, I liked the example cited in the "Problem with Heroics" thread. In that scenario, the guy who comes up with the amazing and elegant solution and then wanders off to tackle a different problem is your "capability guy." Without him the problem may get solved poorly or at all. Having solved that problem he now turns his attention elsewhere.
But wait! It's not done, and certainly not repeatable. Enter your capacity people. These guys may not have developed (or even been able to develop) the solution to the problem, but they understand the solution, can flesh it out into a copmlete solution, and can make it repeatable and sustainable. When you need to turn out more, you add capacity people to do it (they provide the know-how and sheer labor hours to make it happen).
Managing the two together is a tricky proposition. As you noted, if this is done poorly (by a well intentioned, but misdirected manager), you can lose your people. The surest way to lose your capability people is to saddle them with "mundane" work and bureacracy. Certianly some of the work they must do will fall into the mundane category, but if the job calls for nothing else, you will probably lose them. The surest way to lose your capacity people is to put the capability people on a pedestal and not acknowledge the valuable work they (the capacity people) do to complete the project. Morale goes down and away they go.
Getting them to work as a team will be very difficult and requires leadership. As the poster in the heroics thread noted: that person (if they're quirky) had better be able to deliver enough to be worth that effort. In most cases they are, but as you could see from the cited article, sometimes it's just not worth it.
I'd say you are correct and that in some cases, there's a job mismatch.
I've found that if you look at people and organizations closely enough you find people broadly divided into two groups (beware: sweeping generalization approaching). The groups are capability and capacity. As an organization, you need both, but it is important to recognize the roles they play.
Capability people are the people with the skills to build new things and handle complex, unknown situations in an effective manner. They are the "heavy lifters" that are capable of solving complex problems that don't have text book solutions and don't show up in the policies and procedures manuals. They enable you to do things that weren't possible before. In other words, the add capabilities to your systems (whether technological or organizational).
Capacity people are your solid performers. They are reliable and have the skills to get the job done. They make sure that the "i"s are dotted and the "t"s are crossed and do the grinding sort of work which isn't always glamorous, but keeps things running every day and distinguishes the pros from the amateurs. As an organization grows, these are the people who provide the horsepower to keep it moving.
It's crucial to recognize which group a person fits into and how their values to an organization differ. The capacity people aren't really geared toward creating new things or adding features to a system. They are valuable because they keep your organization going and free up your capability people. Capability people are usually not well suited to grind-it-out sorts of tasks, but when the going gets tough, these are the folks who pull your fat out of the fire. They also enable you to do things that simply wouldn't be possible for your organization otherwise.
So back to the question at hand: is there room for the "quirky" engineer? The answer is that there certainly is, but you need to know where to put that person and how to use them. I suspect that most of the "quirky" types will fit in the capability group. Your expectation of that person is to solve the really nasty problems that no one else can tackle. That person must also be able to communicate somewhat effectively with the rest of the team as well to enable them to fill in the blanks. Don't put them in a place where you expect them to attend lots of meetings and crank out line after line of mundane (but necessary) code. They will not do well in that environment.
As a manager, you need to ensure that the capability people communicate effectively with capacity people (who will do the leg work of getting the results out the door). You also need to ensure that the capability person is living up to his/her billing and getting the job done. In the case sited in the article this was clearly not happening. To me that has little to do with the quirks and more to do with actual performance (the two are not mutually exclusive).
Of course, it's also possible that this is the product of a completely insane train of thought on my part. But what the heck, it's Friday.
I have a friend who works at a large and reputable business school. They are quite concerned about wireless networking and the potential for cheating. The department has asked them to shut down the wireless access points during class hours to avoid that problem. They have tried to do this by a combination of perl code and cron jobs. I pointed out to them that most cards can associate with each other in ad-hoc mode. Needless to say, they didn't like that:-)
The truly entertaining part is that they provide each of their MBA students with a wireless PDA and similar gadgetry. Some of the folks pointed out that this is the business school so the likelihood of these students knowing how to work around these limitations is limited. I pointed out that there is, in fact, a computer science department and engineering school on this campus. While MBAs are not so good at technology, they excel at networking and getting other people to do their work.
The real issue is how we will deal with this in the future as technology progresses. We see the beginnings in the current arguments about giving kids calculators during tests. I imagine this will follow on into issues along the lines of "what's wrong with being able to do a web search during an exam." At some point it will be up to professors and other educators to develop problems which can't be found via a web search. Inconvenient for them, but it will be a fact of life before long.
Of course, you could just ban technology (PDAs, laptops, etc) during exams...
It might be helpful to consider what the public actually needs to know in deciding what information should be available in any form (paper or electronic). Various government agencies need to collect personal information about the consituents it serves. This is unavoidable. So the question becomes who needs to have that information and when is having that information available in the public interest.
I think you can make a case for saying that having deeds and property ownership information available is a good and necessary thing. That does not mean that complete personal information (birthdate, SSN, etc) about the owner needs to be made available to anyone who asks. I think it's time to start considering dividing records into two parts one of which will be provided to the public, and the other (which may be necessary for the agency to do its job) which will not be disclosed to a third party.
This should not be confounded with the Freedom of Information Act (FOIA). FOIA is generally a good thing. It is the hook that enables us to keep tabs on our government. This needs to be protected. However, it can be limited. It is rarely necessary for a journalist or other investigatory agency to obtain the records of specific individuals to do their jobs. It is almost never necessary to disclose this to a corporation which will typically use it primarily for marketing. Note that there is precedent for this. In most cases state universities have exemptions from FOIA for student records. This principle can be extended.
This is an old problem made even more problematic by new technology. Gotta love it.
It's quite simple, really. If you talk to marketing folks they will always talk about branding. This involves nothing more than associating an image with products and services. Technical people are phenomenally bad at this because they tend to focus on the technical aspects of any discussion (how quaint:-).
To keep this from happening in the future would require that the technical folks remember to clearly brand the problem as an MS problem when security advisories are issued, and discussions occur. Use a little logical judo on them, as it were.
So remember, from now on it's not an "internet" worm (unless it really is), it's an MS IIS worm. It's not an email virus, it's an "MS Outlook" virus. However, be sure of your facts as you may get a visit from an MS lawyer.
We usually interview in teams. Each member of the team comes up with 10 questions or so ranging in difficulty from very easy to impossible (or at least improbable). We try to avoid "memorization/certification style" questions (eg options to ls) and go for problem oriented questions (although there are some OS specific questions as part of the process).
At some point after the "get acquainted" part of the interview we start the technical part. The team members will start asking questions that escalate up the difficulty chain until they simply can't answer the questions anymore.
Purpose number one is to find an approximate level of technical skill. The second major purpose is to find out how they handle stress. Sysadmins need to be able to operate efficiently under very high stress loads. If during the interview they remain clam and composed even when they don't know the answer, they at least have a chance at handling the normal work. If they fold during the interview they probably won't handle a raving user very gracefully.
For these purposes, the particular questions are don't matter much; anything that will stump them will do. The other thing we really ask about is their home system and what sort of work they've done on it in the past. People who are sysadmin material will usually expound at great length about all the tweaks they've made to their systems. Sysadmins are compulsive tinkerers; even those with little experience or those who have left the field can't resist the urge to make the system behave as it's *supposed to*. If the candidate turns it on and forgets about it...
Finally we throw some real life "difficult user" problems at them to see how they deal with the situations. This tells us how quickly they think on their feet when there's no technical answers to the questions, and how far they'll go before looking for help. This is one of the realities of the job, so it's a good idea to check for it during the interview.
This process has generally worked pretty well. It's still possible for people to sneak through, but you at least eliminate the candidates who are obviously not right for the job.
When it comes down to it, this really isn't too surprising given what's going on in the market and what happened to CRI as it grew into middle age. The market forces are obvious: lots of computing problems that used to be in the exclusive domain of supercomputers have been assumed by much smaller computers. Budgets of large government agencies have been dramatically reduced and with them, a large customer base has disappeared. If you're trying to make money, this spells disaster.
Furthermore, like any organization, as they developed into more of a "sustained business" organization rather than a "let's build the fastest computer ever" organization, it became more and more difficult to innovate as rapidly as before (this is one of the reasons Seymour left). In the hey day of large government defense contracts, this was not a problem. However, as budgets dwindled they ran into significant difficulty penetrating new markets (a $30M machine is not an easy sell).
It's really too bad as they have done some really neat things. In some senses it was the ultimate geek environment. In the engineering tradeoffs, speed always wins (which is why the things are so darn expensive). They used different wires for memory reads and writes, high memory interleaving, the I/O subsystems are multiple computers tasked for nothing more than I/O, vector registers make large FP computation chains very fast, no virtual memory (you can't use what you ain't got). In most cases, if it was slow they threw H/W at it. And then there was materials research for cooling and lots of other cool stuff.
I don't know what Tera plans to do with them, but unless they have a good way to penetrate into the business markets (and there are opportunities), before long Cray will simply be a name for the history books. It's really too bad considering all the contributions they've made to the computing world.
> Keeping all manufacturing in the U.S. at U.S. wages. > Refusing to patent the technology. > Keeping a very expensive security lid on the entire facility. > Not releasing any details that would allow anyone with the resources of China to come up with an equivilent technology
Which is largely what Cray (for example) does. All the machines are designed and manufactured in Chippewa Falls, WI. The code is written in Eagan, MN. New employess undergo FBI background checks. However, Cray owns numerous patents and divulges plenty of detail and uses many commodity chips and parts.
So what's the point? The point is that a supercomputer is more than simply the sum of its parts. The engineers spend lots of time deciding how to arrange those parts to build the fastest possible machine. It's not that no one else could use the same parts, it's the engineering time, manufacturing/packaging techniques, S/W development and the QC efforts it takes to make the thing work. The point is to make the "unapproved" nations spend the several billion USD to replicate the facilities, engineering, development time, etc.
It may seem rather pointless, but to the defense guys it apparently makes sense.
At my site, we're tasked with creating and maintaining the archive of sattelite data for the GOES series of weather sattellites operated by NOAA. Currently the archive spans about 25 years and 150+ terabytes of data. Most of the data lives on Sony Umatic tapes (video production quality equipment). It was very cutting edge at the time and required some interesting H/W hacks to get it interfaced with the dish electronics.
Currently the system is hopelessly obsolete and the remaining units are being carefully nursed as we begin the migration effort. Furthermore much of the older tapes have becomre "read once" media, so you can't afford to miss anything.
Many of the suggestions about formats and media life ignore some of the realities and complexities of the real world. Our acrhive necessities break a large number of these assumptions (as I'm sure do many others).
1) ASCII and higher order reprsentations are not adequate for scientific data.
2) Selecting media with a longer life span only defers the problem to a later date and makes the migration process longer. It also makes it even less likely that adequate readers will be available when the migration begins
3) Raw data formats can change arbitrarily often during the lifetime of the archive.
4) There is unlikely to be adequately stable online storage media available to hold the entire archive as well as the "live" data set (data volumes will increase to match existing storage capacity).
So, what can be done? Many of the suggestions already posted are good and should be incorporated into any archive strategy. So here are some suggestions based on things we're looking at:
1) Identify what needs to be archived. As many have noted, most things don't need to be archived.
2) Build a migration strategy into the plan right away.
3) Keep source code and any auxilliary data needed to access the data available with the data itself.
4) Keep at least two copies of the archive. It's amazing how many archives exist in only one place (depressing, really).
Of course the biggest challenge is to make all that data in a meaningful form. That's really the biggest part of the problem, and it's likely to get worse as data volumes grow. Things are coming down the road that will make our current demands look pretty small. That's good and bad. On the good side, our existing problem will fit easily into any solution we come up with at that point. On the down side, it's not clear what those solutions will be.
Sorry to split hairs, but some hairs need splitting. Many in the supercomputer industry have debated for a long time what the definition of supercomputer is. The answer they've come up with is beautifully vague and that is: the biggest computer you can build to solve a problem.
If you have to ask the price, you aren't supercomputing (ie there is no price/performance, only performance).
Slashdot Mirror
I am not a lawyer ... blah, blah, blah,
but it does nothing to the Napster case. If I understand what I read correctly the artists are laying claim to authorship rights of the works in question. As someone else has pointed out, this means that if they have authorship rights, the recording label can retain the copyrights to a particular instance of a work, but not all instances.
The reason the artists want this in this case is quite simple - it enables an end-run around the RIAA represented record labels. The artists could record versions of their songs specifically for things like Napster or other mediums and potentially cut the labels out of the revenue stream (the label could not claim ownership of that instance of the work). Obviously RIAA would not be very happy with that.
Again, I am not a lawyer and may be missing a few subtle points of the law.
But for the Napster case in particular it does nothing. Even if the artists' brief is upheld and the documents are amended or refiled, the labels still own the copyrights to the instances of the work (music) in question (as agreed to by contract). That means that if their claims of infringement are upheld, they can still show damages as the owner of the copyrights to that particular recording.
A decent play by the RAC. If it is successful, it will change the landscape somewhat, but I fear all it would mean for Napster would be that a different party would be suing them.
[snip]
In the case of the "quirky" engineer in the article, he had misdirected capability. Maybe a manager could direct his energy toward the job, but in some cases the job itself is mismatched. Perhaps the "quirky" engineer in the story would work well in the FSF with Stallman doing Mayan calendar elisp code.
[snip]
Indeed! It's a very difficult problem for managers to tackle. I was thinking of things a bit differently though.
I was considering it in terms of the type of workload in an organization rather than as an aspect of an indivdual (altough you've made an excellent observation there as well). In particular, I liked the example cited in the "Problem with Heroics" thread. In that scenario, the guy who comes up with the amazing and elegant solution and then wanders off to tackle a different problem is your "capability guy." Without him the problem may get solved poorly or at all. Having solved that problem he now turns his attention elsewhere.
But wait! It's not done, and certainly not repeatable. Enter your capacity people. These guys may not have developed (or even been able to develop) the solution to the problem, but they understand the solution, can flesh it out into a copmlete solution, and can make it repeatable and sustainable. When you need to turn out more, you add capacity people to do it (they provide the know-how and sheer labor hours to make it happen).
Managing the two together is a tricky proposition. As you noted, if this is done poorly (by a well intentioned, but misdirected manager), you can lose your people. The surest way to lose your capability people is to saddle them with "mundane" work and bureacracy. Certianly some of the work they must do will fall into the mundane category, but if the job calls for nothing else, you will probably lose them. The surest way to lose your capacity people is to put the capability people on a pedestal and not acknowledge the valuable work they (the capacity people) do to complete the project. Morale goes down and away they go.
Getting them to work as a team will be very difficult and requires leadership. As the poster in the heroics thread noted: that person (if they're quirky) had better be able to deliver enough to be worth that effort. In most cases they are, but as you could see from the cited article, sometimes it's just not worth it.
I'd say you are correct and that in some cases, there's a job mismatch.
Best!
I've found that if you look at people and organizations closely enough you find people broadly divided into two groups (beware: sweeping generalization approaching). The groups are capability and capacity. As an organization, you need both, but it is important to recognize the roles they play.
Capability people are the people with the skills to build new things and handle complex, unknown situations in an effective manner. They are the "heavy lifters" that are capable of solving complex problems that don't have text book solutions and don't show up in the policies and procedures manuals. They enable you to do things that weren't possible before. In other words, the add capabilities to your systems (whether technological or organizational).
Capacity people are your solid performers. They are reliable and have the skills to get the job done. They make sure that the "i"s are dotted and the "t"s are crossed and do the grinding sort of work which isn't always glamorous, but keeps things running every day and distinguishes the pros from the amateurs. As an organization grows, these are the people who provide the horsepower to keep it moving.
It's crucial to recognize which group a person fits into and how their values to an organization differ. The capacity people aren't really geared toward creating new things or adding features to a system. They are valuable because they keep your organization going and free up your capability people. Capability people are usually not well suited to grind-it-out sorts of tasks, but when the going gets tough, these are the folks who pull your fat out of the fire. They also enable you to do things that simply wouldn't be possible for your organization otherwise.
So back to the question at hand: is there room for the "quirky" engineer? The answer is that there certainly is, but you need to know where to put that person and how to use them. I suspect that most of the "quirky" types will fit in the capability group. Your expectation of that person is to solve the really nasty problems that no one else can tackle. That person must also be able to communicate somewhat effectively with the rest of the team as well to enable them to fill in the blanks. Don't put them in a place where you expect them to attend lots of meetings and crank out line after line of mundane (but necessary) code. They will not do well in that environment.
As a manager, you need to ensure that the capability people communicate effectively with capacity people (who will do the leg work of getting the results out the door). You also need to ensure that the capability person is living up to his/her billing and getting the job done. In the case sited in the article this was clearly not happening. To me that has little to do with the quirks and more to do with actual performance (the two are not mutually exclusive).
Of course, it's also possible that this is the product of a completely insane train of thought on my part. But what the heck, it's Friday.
Best!
I have a friend who works at a large and reputable business school. They are quite concerned about wireless networking and the potential for cheating. The department has asked them to shut down the wireless access points during class hours to avoid that problem. They have tried to do this by a combination of perl code and cron jobs. I pointed out to them that most cards can associate with each other in ad-hoc mode. Needless to say, they didn't like that :-)
...
The truly entertaining part is that they provide each of their MBA students with a wireless PDA and similar gadgetry. Some of the folks pointed out that this is the business school so the likelihood of these students knowing how to work around these limitations is limited. I pointed out that there is, in fact, a computer science department and engineering school on this campus. While MBAs are not so good at technology, they excel at networking and getting other people to do their work.
The real issue is how we will deal with this in the future as technology progresses. We see the beginnings in the current arguments about giving kids calculators during tests. I imagine this will follow on into issues along the lines of "what's wrong with being able to do a web search during an exam." At some point it will be up to professors and other educators to develop problems which can't be found via a web search. Inconvenient for them, but it will be a fact of life before long.
Of course, you could just ban technology (PDAs, laptops, etc) during exams
It might be helpful to consider what the public actually needs to know in deciding what information should be available in any form (paper or electronic). Various government agencies need to collect personal information about the consituents it serves. This is unavoidable. So the question becomes who needs to have that information and when is having that information available in the public interest.
I think you can make a case for saying that having deeds and property ownership information available is a good and necessary thing. That does not mean that complete personal information (birthdate, SSN, etc) about the owner needs to be made available to anyone who asks. I think it's time to start considering dividing records into two parts one of which will be provided to the public, and the other (which may be necessary for the agency to do its job) which will not be disclosed to a third party.
This should not be confounded with the Freedom of Information Act (FOIA). FOIA is generally a good thing. It is the hook that enables us to keep tabs on our government. This needs to be protected. However, it can be limited. It is rarely necessary for a journalist or other investigatory agency to obtain the records of specific individuals to do their jobs. It is almost never necessary to disclose this to a corporation which will typically use it primarily for marketing. Note that there is precedent for this. In most cases state universities have exemptions from FOIA for student records. This principle can be extended.
This is an old problem made even more problematic by new technology. Gotta love it.
It's quite simple, really. If you talk to marketing folks they will always talk about branding. This involves nothing more than associating an image with products and services. Technical people are phenomenally bad at this because they tend to focus on the technical aspects of any discussion (how quaint :-).
To keep this from happening in the future would require that the technical folks remember to clearly brand the problem as an MS problem when security advisories are issued, and discussions occur. Use a little logical judo on them, as it were.
So remember, from now on it's not an "internet" worm (unless it really is), it's an MS IIS worm. It's not an email virus, it's an "MS Outlook" virus. However, be sure of your facts as you may get a visit from an MS lawyer.
We usually interview in teams. Each member of the team comes up with 10 questions or so ranging in difficulty from very easy to impossible (or at least improbable). We try to avoid "memorization/certification style" questions (eg options to ls) and go for problem oriented questions (although there are some OS specific questions as part of the process).
...
At some point after the "get acquainted" part of the interview we start the technical part. The team members will start asking questions that escalate up the difficulty chain until they simply can't answer the questions anymore.
Purpose number one is to find an approximate level of technical skill. The second major purpose is to find out how they handle stress. Sysadmins need to be able to operate efficiently under very high stress loads. If during the interview they remain clam and composed even when they don't know the answer, they at least have a chance at handling the normal work. If they fold during the interview they probably won't handle a raving user very gracefully.
For these purposes, the particular questions are don't matter much; anything that will stump them will do. The other thing we really ask about is their home system and what sort of work they've done on it in the past. People who are sysadmin material will usually expound at great length about all the tweaks they've made to their systems. Sysadmins are compulsive tinkerers; even those with little experience or those who have left the field can't resist the urge to make the system behave as it's *supposed to*. If the candidate turns it on and forgets about it
Finally we throw some real life "difficult user" problems at them to see how they deal with the situations. This tells us how quickly they think on their feet when there's no technical answers to the questions, and how far they'll go before looking for help. This is one of the realities of the job, so it's a good idea to check for it during the interview.
This process has generally worked pretty well. It's still possible for people to sneak through, but you at least eliminate the candidates who are obviously not right for the job.
When it comes down to it, this really isn't too surprising given what's going on in the market and what happened to CRI as it grew into middle age. The market forces are obvious: lots of computing problems that used to be in the exclusive domain of supercomputers have been assumed by much smaller computers. Budgets of large government agencies have been dramatically reduced and with them, a large customer base has disappeared. If you're trying to make money, this spells disaster.
Furthermore, like any organization, as they developed into more of a "sustained business" organization rather than a "let's build the fastest computer ever" organization, it became more and more difficult to innovate as rapidly as before (this is one of the reasons Seymour left). In the hey day of large government defense contracts, this was not a problem. However, as budgets dwindled they ran into significant difficulty penetrating new markets (a $30M machine is not an easy sell).
It's really too bad as they have done some really neat things. In some senses it was the ultimate geek environment. In the engineering tradeoffs, speed always wins (which is why the things are so darn expensive). They used different wires for memory reads and writes, high memory interleaving, the I/O subsystems are multiple computers tasked for nothing more than I/O, vector registers make large FP computation chains very fast, no virtual memory (you can't use what you ain't got). In most cases, if it was slow they threw H/W at it. And then there was materials research for cooling and lots of other cool stuff.
I don't know what Tera plans to do with them, but unless they have a good way to penetrate into the business markets (and there are opportunities), before long Cray will simply be a name for the history books. It's really too bad considering all the contributions they've made to the computing world.
> Keeping all manufacturing in the U.S. at U.S. wages.
> Refusing to patent the technology.
> Keeping a very expensive security lid on the entire facility.
> Not releasing any details that would allow anyone with the resources of China to come up with an equivilent technology
Which is largely what Cray (for example) does. All the machines are designed and manufactured in Chippewa Falls, WI. The code is written in Eagan, MN. New employess undergo FBI background checks. However, Cray owns numerous patents and divulges plenty of detail and uses many commodity chips and parts.
So what's the point? The point is that a supercomputer is more than simply the sum of its parts. The engineers spend lots of time deciding how to arrange those parts to build the fastest possible machine. It's not that no one else could use the same parts, it's the engineering time, manufacturing/packaging techniques, S/W development and the QC efforts it takes to make the thing work. The point is to make the "unapproved" nations spend the several billion USD to replicate the facilities, engineering, development time, etc.
It may seem rather pointless, but to the defense guys it apparently makes sense.
At my site, we're tasked with creating and maintaining the archive of sattelite data for the GOES series of weather sattellites operated by NOAA. Currently the archive spans about 25 years and 150+ terabytes of data. Most of the data lives on Sony Umatic tapes (video production quality equipment). It was very cutting edge at the time and required some interesting H/W hacks to get it interfaced with the dish electronics.
Currently the system is hopelessly obsolete and the remaining units are being carefully nursed as we begin the migration effort. Furthermore much of the older tapes have becomre "read once" media, so you can't afford to miss anything.
Many of the suggestions about formats and media life ignore some of the realities and complexities of the real world. Our acrhive necessities break a large number of these assumptions (as I'm sure do many others).
1) ASCII and higher order reprsentations are not adequate for scientific data.
2) Selecting media with a longer life span only defers the problem to a later date and makes the migration process longer. It also makes it even less likely that adequate readers will be available when the migration begins
3) Raw data formats can change arbitrarily often during the lifetime of the archive.
4) There is unlikely to be adequately stable online storage media available to hold the entire archive as well as the "live" data set (data volumes will increase to match existing storage capacity).
So, what can be done? Many of the suggestions already posted are good and should be incorporated into any archive strategy. So here are some suggestions based on things we're looking at:
1) Identify what needs to be archived. As many have noted, most things don't need to be archived.
2) Build a migration strategy into the plan right away.
3) Keep source code and any auxilliary data needed to access the data available with the data itself.
4) Keep at least two copies of the archive. It's amazing how many archives exist in only one place (depressing, really).
Of course the biggest challenge is to make all that data in a meaningful form. That's really the biggest part of the problem, and it's likely to get worse as data volumes grow. Things are coming down the road that will make our current demands look pretty small. That's good and bad. On the good side, our existing problem will fit easily into any solution we come up with at that point. On the down side, it's not clear what those solutions will be.
Sorry to split hairs, but some hairs need splitting. Many in the supercomputer industry have debated for a long time what the definition of supercomputer is. The answer they've come up with is beautifully vague and that is: the biggest computer you can build to solve a problem.
If you have to ask the price, you aren't supercomputing (ie there is no price/performance, only performance).