> I think the ability to eject the tape and take it home is "Tape backup's" only good thing.
That is a good thing but if your needs are modest enough, IDE can do that too:
Turn off backup machine, eject the disks, put in
new disks and turn on backup machine. Take disks
home.
The backup machine is in a different rack than the fileserver. The disks I use for removeable backups are straight IDE mounted in removeable cartridges.
About all I lose are I need to more careful with the media regarding shocks and I have to turn off the backup computer to change the media.
If I were using USB 2 or Firewire external disks I wouldn't even have to turn off the backup computer (but the cost would have been higher).
For 10 year storage, IDE may well have an edge. I realize that is somewhat heretical.
I've been in this business a long time now. I can usually get a disk drive from 10 years ago to work with something.
Reading a tape from 10 years ago has been more problematical.Even finding a device to read a 10 year old tape has been problematical.
That assumes the bits are even still readable which is often not the case for a tape.
In our situation (modest backups, modest hold times) IDE (not even RAID, but all in removable jackets for offsite storage) came out ahead. I do have to shut down the machine to swap the drives out once a week.The drives are used as 120GB tapes.
IDE was about double the cost of tape (per byte) but no pair of tape drives was needed, just an extra IDE card.
Since tapes and tape drives tend to change a lot over time, buying "just one" is rarely an option.
There are many scenarious where tape beats out disks in backup, ours just wasn't one of them.
Marks also made very very clear that the thing that
drove him the most crazy was the certain knowledge
that whatever Skinnarland sent was usually important and time critical.
"Silk and Cyanide" is a GREAT book by the way; a book about making codes more than breaking codes. It also has a lot of agent stuff (including the poor agent who couldn't lie)
and an interesting take on one of my favorite books and films:
84 Charing Cross Road. It was a small war in
some ways.
The robots didn't work as well as some hoped and
there has been some backing off from them.
They do what they do very well but GM in particular tried to do everything with robots, getting
rid of those pesky workers. GM doesn't do that any more.
Those were the cars that tried mens souls. If a human does a crappy job, at least they know it.
That said, I imagine between better bots and experience designing cars with automated production in mind, fewer people are needed to build cars every decade but people are still quite
involved on most lines.
DOS 1.0 was HEAVILY (I'm using a polite term here) influenced by CP/M-80 and this
made moving CP/M-80 code to DOS 1.0 less painful than it would otherwise be.
With DOS 2.0 a lot of things were changed with some
Unixy features and commands added....in somewhat
incompatable ways at that.
At the time of DOS 2.x I believe Microsoft was still selling a Un*x with their logo on it.It cost
more than DOS.
Actually that was invented earlier. IBM used to have that kind of clout and I have little doubt someone before IBM did as well.
...and Microsoft has innovated. Maybe not in the sense of inventing the basic stuff but I have to give them points for running with a good thing when they see it: a mouse that could run off existing serial ports, first microcomputer BASIC on the Altair, the OS of the Tandy Model 100 laptop, etc.
It won't be uncommon for a University to, at minimum, restrict P2P bandwidth
between dorms and off-campus.
At the University I work at, the school pays money for our nonacademic links...both lines and for traffic. A lot of money. The state budget is a mess, tuitions are rising.
P2P peaked at something like 30% of our commercial traffic last year and it would have been higher this year.
So this would mean an extra very highend router, extra traffic costs and
an extra line at the local GigaPOP just for P2P.
(Good news for the suffering telcom industry at
least).
Remember, it's not just the content, it's the queries queries queries that put the load on.
IBooks are just enough different to be a little fun yet still manage to be useful and
reliable.
That combination doesn't happen every day.
I work on Linux and Windows machines mostly. I like Linux a lot. There are things I like in Windows. Solaris is in there too and pleasant enough (and before
that: BSD on Vaxen, Primos, CP/M and even CDC and
IBM card walloping).
The thing is: After dealing with Linux, Solaris and Windows all day, they just aren't that amusing.
The iBook I'm using is reasonably fast with Jaguar, small, light, reliable, has a decent screen, a
keyboard/touchpad I can live with (and
I usually dislike touchpads). It can run most of what I need and most of what
I want and it has just enough difference to be fun.
I find I had missed fun.
That "It Just Works" means I can carry around
a machine I find fun. Neat.
Eventually it may stop being fun but for now, I like it a lot.
The language has been used to write compilers (e.g. The original Pascal), screen editors, memory management (for large scale matrix manipulation) and even whole operating systems such as PRIMOS (albeit with some serious libraries added) as well as things like S and numeric libraries.
Most of this stuff was eventually rewritten in other languages and programming them wasn't necessarily an entirely pleasant experience but all of the above were done with Fortran 66 [often with a ratfor preprocessor], all were successful in their niches and the things in that list I used were pretty reliable. Note also that, by using the popular compiler of the day, most of these projects were also fairly portable.
There are some advantages to a sparse environment
and Fortran (at least until recently) certainly qualified!
PRIMOS was a particuarly interesting case. Prime had a similar idea to Unix: They wrote it in a language accessable by their target users of scientists and engineers: Fortran IV (Later it
was rewritten in PL/1 subset G).
It's not an actively used technology but wasn't the
first comsat to be used for a transatlantic TV signal Echo Ia?
It certainly launched before Telestar I.
For those of you too young to know: It was a great
big silvered balloon. They blew it up when it reached orbit and bounced (as opposed to relayed)
signals off it.
Thin clients can be a wonderful tool but a classroom often violates a basic working assumption: that people won't all whomp on the server and network at the exact same moment.
Consider: 20 students, 1 server. The instructor says: All right, let's all open Autocad (or some other heavyweight app with big datasets) now.
Depending how the lab is used this may not be an issue. Teacher awareness can mitigate the problem somewhat.
Many of these tools are examples of Literate Programming Tools but
I haven't seen much mention of
CWeb. Web and later Cweb were among the first of these and are quite nice in my opinion.
In any case: The idea of keeping documentation and code next to each other in the same file, makes it much easier to document changes as they occur. How that is done is argueably a matter of taste (doxygen, POD, cweb, etc.).
The canonical example of the technique is probably the source code for TeX.
That is a good thing but if your needs are modest enough, IDE can do that too:
Turn off backup machine, eject the disks, put in
new disks and turn on backup machine. Take disks
home.
The backup machine is in a different rack than the fileserver. The disks I use for removeable backups are straight IDE mounted in removeable cartridges
About all I lose are I need to more careful with the media regarding shocks and I have to turn off the backup computer to change the media.
If I were using USB 2 or Firewire external disks I wouldn't even have to turn off the backup computer (but the cost would have been higher).
I've been in this business a long time now. I can usually get a disk drive from 10 years ago to work with something. Reading a tape from 10 years ago has been more problematical.Even finding a device to read a 10 year old tape has been problematical.
That assumes the bits are even still readable which is often not the case for a tape.
In our situation (modest backups, modest hold times) IDE (not even RAID, but all in removable jackets for offsite storage) came out ahead. I do have to shut down the machine to swap the drives out once a week.The drives are used as 120GB tapes.
IDE was about double the cost of tape (per byte) but no pair of tape drives was needed, just an extra IDE card.
Since tapes and tape drives tend to change a lot over time, buying "just one" is rarely an option.
There are many scenarious where tape beats out disks in backup, ours just wasn't one of them.
So it's "broken" but it's there.
"Silk and Cyanide" is a GREAT book by the way; a book about making codes more than breaking codes. It also has a lot of agent stuff (including the poor agent who couldn't lie) and an interesting take on one of my favorite books and films: 84 Charing Cross Road. It was a small war in some ways.
They do what they do very well but GM in particular tried to do everything with robots, getting rid of those pesky workers. GM doesn't do that any more.
Those were the cars that tried mens souls. If a human does a crappy job, at least they know it.
That said, I imagine between better bots and experience designing cars with automated production in mind, fewer people are needed to build cars every decade but people are still quite involved on most lines.
DOS 1.0 was HEAVILY (I'm using a polite term here) influenced by CP/M-80 and this made moving CP/M-80 code to DOS 1.0 less painful than it would otherwise be.
With DOS 2.0 a lot of things were changed with some Unixy features and commands added....in somewhat incompatable ways at that.
At the time of DOS 2.x I believe Microsoft was still selling a Un*x with their logo on it.It cost more than DOS.
At the University I work at, the school pays money for our nonacademic links...both lines and for traffic. A lot of money. The state budget is a mess, tuitions are rising.
P2P peaked at something like 30% of our commercial traffic last year and it would have been higher this year.
So this would mean an extra very highend router, extra traffic costs and an extra line at the local GigaPOP just for P2P. (Good news for the suffering telcom industry at least).
Remember, it's not just the content, it's the queries queries queries that put the load on.
That combination doesn't happen every day.
I work on Linux and Windows machines mostly. I like Linux a lot. There are things I like in Windows. Solaris is in there too and pleasant enough (and before that: BSD on Vaxen, Primos, CP/M and even CDC and IBM card walloping).
The thing is: After dealing with Linux, Solaris and Windows all day, they just aren't that amusing.
The iBook I'm using is reasonably fast with Jaguar, small, light, reliable, has a decent screen, a keyboard/touchpad I can live with (and I usually dislike touchpads). It can run most of what I need and most of what I want and it has just enough difference to be fun.
I find I had missed fun.
That "It Just Works" means I can carry around a machine I find fun. Neat.
Eventually it may stop being fun but for now, I like it a lot.
Most of this stuff was eventually rewritten in other languages and programming them wasn't necessarily an entirely pleasant experience but all of the above were done with Fortran 66 [often with a ratfor preprocessor], all were successful in their niches and the things in that list I used were pretty reliable. Note also that, by using the popular compiler of the day, most of these projects were also fairly portable.
There are some advantages to a sparse environment and Fortran (at least until recently) certainly qualified!
PRIMOS was a particuarly interesting case. Prime had a similar idea to Unix: They wrote it in a language accessable by their target users of scientists and engineers: Fortran IV (Later it was rewritten in PL/1 subset G).
For those of you too young to know: It was a great big silvered balloon. They blew it up when it reached orbit and bounced (as opposed to relayed) signals off it.
Just for the record: There is nothing preventing an NFS administrator from keeping all the NFS servers behind locked doors.
You can also keep the user login data off the workstations for the most part.
That said, Kerberos/AFS (or decendents like CODA) are far more secureable out-of-the-box than NFS is. Maybe more secure than NFS can be.
Consider: 20 students, 1 server. The instructor says: All right, let's all open Autocad (or some other heavyweight app with big datasets) now.
Depending how the lab is used this may not be an issue. Teacher awareness can mitigate the problem somewhat.
In any case: The idea of keeping documentation and code next to each other in the same file, makes it much easier to document changes as they occur. How that is done is argueably a matter of taste (doxygen, POD, cweb, etc.).
The canonical example of the technique is probably the source code for TeX.