Even if equipment existed to read that AOL cd in 20 years, let alone 200 years,
You underestimate how clever people can be. Even if the equipment doesn't exist, I have little doubt that they'll figure out how the CDs work and build new equipment. From there they'll attempt a cryptographic analysis on the data to decode the ASCII character scheme. Once enough ASCII data is retrieved, they'll have enough information to tackle the binary data. So on and so forth. The retrieval won't get everything, but they will manage to recover a LOT of data.
it would be useless as corrosion makes them useless.
Nonsense. Corrosion makes a CD useless for regular purposes. It does NOT make the CD completely unreadable, nor does the entire surface disappear at once. Some of the data will survive on corroded CDs, and some CDs will probably avoid corrosion all together. Remember that pressed CDs (especially the earlier CDs in the 90's) hold together far better than their burnable counterparts.
I mean who would want a permanant record that can last for thousands of years and can still be read even if it becomes stained and worn unlike a CD?
Newspaper will *not* last thousands of years without proper archival procedures. Even trying to get them to last more than a hundred years can be problematic, thus the practice of transcribing them to microfilm. Even books wouldn't last as long as they do if it wasn't common practice to put them in long term storage. (i.e. A library shelf in a cool, dry place.)
In all reality, we're probably leaving far better records in the form of optical plastic disks than we are in newspaper. I just get a kick out of how many AOL CDs historians will have to sort through!
I have four words for you: C M Y K Until then, shut the hell up.
Go Here. It probably needs some work still, but it's a good start. A few people should try converting some stuff for print and see if they can spot any bugs. The more you know about RBG->CMYK conversion, the more useful you'll be in testing.
Re:Wouldn't it have been better...
on
From Bash To Z Shell
·
· Score: 2, Informative
when I first encountered it nearly two decades ago, it was installed as "ash".
If you're referring to the original script version as opposed to the C port, then the shell name was "ash.sh". Someone might have copied or symlinked it to just "ash" on your system. Here's the original Adventure Shell from Usenet. Note the 1987 timestamp.
The data was three dimensional, but the slice was 2D. I don't remember what the 3rd dimension of data was. We did have some 2D bits of data, but those were only a few hundred K. We actually had data that was four or five dimensions, but I really have little clue what the heck they were stashing in there.
Plus, what were they doing putting it in a database? That seems rather... bizarre.
That was my thought. Not to mention that the DB server only had 2GB of RAM to run both DB2 and the CORBA server. Things got slightly better when they put another 2GB stick in there, but it was not a good design.
Were they shoving, say, whole DICOM files in there, or raw data in some particular format?
Raw data. I had to split the file between records to fit the large files. I wrote code to unwrap the array into a 1D array, then rewrap it when it left the database.
it would just be acting like an inefficient filesystem.
That was exactly what they were doing with it. Their thought was that using the database would improve things by not having to write code to handle RAID-type data management. i.e. The database would automatically spread the data across disks. The fact that they picked the *worst* database possible for handling BLOBs unfortunately escaped them.
Most images that we deal with (without time-series data) don't go much higher res than, say, 256x256x192, with 8 bits of precision. As you can see, that's only 12 megs of data.
You're lucky then. The last MRI program I worked on needed to do a detailed analysis of the data. The physicists were still working out how much precision they wanted when I left, but suffice it to say that each slice was over 20 megs. And they were storing it in a DB2 database. And transferring it over CORBA. It wasn't pretty, trust me.
SPARC hardware may not be fast relative to an x86 box,
Speed is relative anyway. My Ultra 5 didn't run individual programs as fast as its PC contemporary, but it's multi-processing ability was worth it's weight in gold. Windows absolutely choked on my workload, whereas my Sun kept chugging no matter what I threw at it. Program loading? No problem! Just minimize, keep working, and come back to it when it's loaded. Windows would thrash on that sort of thing.
Got three compiles, two remote X sessions, four netscape windows (in each session), and a StarOffice document open? Pff! As if that will slow an UltraSparc down!
It scares me that I need a modern Windows machine with 50 times the power to produce anywhere near the same experience...
The "standard" is to alias ls to 'ls -F'. This appends * to executables, / to directories, @ to symlinks, = for sockets, and | for FIFOs. Works on any terminal.
Except for the fact that I absolutely hate that output. It drives me nuts seeing those characters there. IMHO, it looks worse than colors. Give me a Solaris terminal any day.
We've been moving away from Sun with our MRI-analysis software where I work
Eh? Doesn't MRI analysis involve tons of Voxel data, which can take gigabytes of memory to properly process? Why would they move *away* from the machines best suited to the job?
Sometimes I do not understand the medical industry.
I like SunRays too, but unfortunately they can be unsuitable for development. Users who need to write a simple HTTP server, for example, can't use SunRays because they'll collide.
That being said, Sun tends to charge an arm and a leg for SunRays as well. You have to be very shrewd not to wind up with something more expensive.
True. But I'm mostly looking for the distribution rather than the tweaking ability. Have you ever tried getting Solaris from Sun? First it's free, then it's not, then it is again, then it's "free" with a $50 download charge, then it requires a fax-back form, then it requires the Sun Download Manager(TM), then it doesn't. Not to mention the lengthy contracts you have to wade through on their site, and the links that take you all over creation before you finally get to the "Purchase" page (with a value of $0.00, WTF?).
Just give me a Bittorrent of all the disk, and I'll be happy.:-)
and with the OpenSolaris project, it would seem that Sun might be leaning towards the open source world,
You know, with all the buzz about the OpenSolaris project, you'd think it had already been released. Especially all the reports from Universities which have had early access to it. (Look, we did XYZ with OpenSolaris! Does that rock or what!?)
I don't know about anyone else, but I'm getting kind of itchy waiting for it. I just hope that Sun maintains enough controls to keep the OS rock-solid and pleasant to use while still actively working with the community. Time will tell...
Its nothing like Sun's.... its really odd.. on my Indy it can refer to disks in two notations, one's very NT style
Aren't the Indy's the machines that ran Windows NT MIPS Edition? That would explain why it accepts both formats. You could get the machine equipped with either OS.
Am I misremembering, or did SGI used to use OpenPROM?
I have to say, one part of me wants to scream out at the loss of such awesome hardware. (I *love* the graphical console on Suns, the coolness of OpenPROM, the finely crafted window XDMCP management, etc.) The other part of me realizes that there's no need for expensive Sun hardware for public terminals, and that PCs are more cost effective. *sigh* The end of an era.
but nooooo it uses the same syntax and commands even as the PROM monitor uses, except sash can read XFS volumes unlike the boot PROM and list the contents of directories.
Huh. You'd think SGI would just improve the OpenPROM code instead. Maybe they felt that would be "too much like Sun". No wonder they fell by the wayside.
Has anyone actually found this to be useful? I've always found it to be more annoying than anything. The alternative standard (for those of us with purdy graphical terminals on our UltraSparcs) of using Bold and Italics is much easier on the eyes and conveys just as much information.
Long answer: I don't think most tcsh users use it for its programming ability. Instead, it tends to be useful as a solid interactive shell. Its general "feel" tends to be more solid than bash, owing partly to the fact that bash has a lot of built in key-shortcuts that tcsh doesn't. Of course, once you're used to being able to double tab for a directory listing, it's kind of hard to give up.
Did anyone ever actually argue over ZShell? I thought the primary arguments were always the BASH vs. KSH arguments (i.e. general users vs. hardcore unix admins) and the TCSH vs. BASH arguments (there is *some* validity to TCSH being a bit more professional, but BASH is just more useful).
Slashdot Mirror
Even if equipment existed to read that AOL cd in 20 years, let alone 200 years,
You underestimate how clever people can be. Even if the equipment doesn't exist, I have little doubt that they'll figure out how the CDs work and build new equipment. From there they'll attempt a cryptographic analysis on the data to decode the ASCII character scheme. Once enough ASCII data is retrieved, they'll have enough information to tackle the binary data. So on and so forth. The retrieval won't get everything, but they will manage to recover a LOT of data.
it would be useless as corrosion makes them useless.
Nonsense. Corrosion makes a CD useless for regular purposes. It does NOT make the CD completely unreadable, nor does the entire surface disappear at once. Some of the data will survive on corroded CDs, and some CDs will probably avoid corrosion all together. Remember that pressed CDs (especially the earlier CDs in the 90's) hold together far better than their burnable counterparts.
I mean who would want a permanant record that can last for thousands of years and can still be read even if it becomes stained and worn unlike a CD?
Newspaper will *not* last thousands of years without proper archival procedures. Even trying to get them to last more than a hundred years can be problematic, thus the practice of transcribing them to microfilm. Even books wouldn't last as long as they do if it wasn't common practice to put them in long term storage. (i.e. A library shelf in a cool, dry place.)
In all reality, we're probably leaving far better records in the form of optical plastic disks than we are in newspaper. I just get a kick out of how many AOL CDs historians will have to sort through!
I have four words for you: C M Y K Until then, shut the hell up.
Go Here. It probably needs some work still, but it's a good start. A few people should try converting some stuff for print and see if they can spot any bugs. The more you know about RBG->CMYK conversion, the more useful you'll be in testing.
when I first encountered it nearly two decades ago, it was installed as "ash".
If you're referring to the original script version as opposed to the C port, then the shell name was "ash.sh". Someone might have copied or symlinked it to just "ash" on your system. Here's the original Adventure Shell from Usenet. Note the 1987 timestamp.
Try again. The Adventure shell compiles to advsh, not ash. ASH is, and always will be, the Almquist shell.
Each 2d slice or 3d slice (time slice)?
:-/
The data was three dimensional, but the slice was 2D. I don't remember what the 3rd dimension of data was. We did have some 2D bits of data, but those were only a few hundred K. We actually had data that was four or five dimensions, but I really have little clue what the heck they were stashing in there.
Plus, what were they doing putting it in a database? That seems rather... bizarre.
That was my thought. Not to mention that the DB server only had 2GB of RAM to run both DB2 and the CORBA server. Things got slightly better when they put another 2GB stick in there, but it was not a good design.
Were they shoving, say, whole DICOM files in there, or raw data in some particular format?
Raw data. I had to split the file between records to fit the large files. I wrote code to unwrap the array into a 1D array, then rewrap it when it left the database.
it would just be acting like an inefficient filesystem.
That was exactly what they were doing with it. Their thought was that using the database would improve things by not having to write code to handle RAID-type data management. i.e. The database would automatically spread the data across disks. The fact that they picked the *worst* database possible for handling BLOBs unfortunately escaped them.
Let's just say I didn't work there very long.
Most images that we deal with (without time-series data) don't go much higher res than, say, 256x256x192, with 8 bits of precision. As you can see, that's only 12 megs of data.
You're lucky then. The last MRI program I worked on needed to do a detailed analysis of the data. The physicists were still working out how much precision they wanted when I left, but suffice it to say that each slice was over 20 megs. And they were storing it in a DB2 database. And transferring it over CORBA. It wasn't pretty, trust me.
Already answered here.
when they could get along perfectly fine with:
} else {
*shudder*
SPARC hardware may not be fast relative to an x86 box,
Speed is relative anyway. My Ultra 5 didn't run individual programs as fast as its PC contemporary, but it's multi-processing ability was worth it's weight in gold. Windows absolutely choked on my workload, whereas my Sun kept chugging no matter what I threw at it. Program loading? No problem! Just minimize, keep working, and come back to it when it's loaded. Windows would thrash on that sort of thing.
Got three compiles, two remote X sessions, four netscape windows (in each session), and a StarOffice document open? Pff! As if that will slow an UltraSparc down!
It scares me that I need a modern Windows machine with 50 times the power to produce anywhere near the same experience...
The "standard" is to alias ls to 'ls -F'. This appends * to executables, / to directories, @ to symlinks, = for sockets, and | for FIFOs. Works on any terminal.
Except for the fact that I absolutely hate that output. It drives me nuts seeing those characters there. IMHO, it looks worse than colors. Give me a Solaris terminal any day.
Umm, yeah. What did you think I was referring to?
We've been moving away from Sun with our MRI-analysis software where I work
Eh? Doesn't MRI analysis involve tons of Voxel data, which can take gigabytes of memory to properly process? Why would they move *away* from the machines best suited to the job?
Sometimes I do not understand the medical industry.
I like SunRays too, but unfortunately they can be unsuitable for development. Users who need to write a simple HTTP server, for example, can't use SunRays because they'll collide.
That being said, Sun tends to charge an arm and a leg for SunRays as well. You have to be very shrewd not to wind up with something more expensive.
True. But I'm mostly looking for the distribution rather than the tweaking ability. Have you ever tried getting Solaris from Sun? First it's free, then it's not, then it is again, then it's "free" with a $50 download charge, then it requires a fax-back form, then it requires the Sun Download Manager(TM), then it doesn't. Not to mention the lengthy contracts you have to wade through on their site, and the links that take you all over creation before you finally get to the "Purchase" page (with a value of $0.00, WTF?).
:-)
Just give me a Bittorrent of all the disk, and I'll be happy.
and with the OpenSolaris project, it would seem that Sun might be leaning towards the open source world,
You know, with all the buzz about the OpenSolaris project, you'd think it had already been released. Especially all the reports from Universities which have had early access to it. (Look, we did XYZ with OpenSolaris! Does that rock or what!?)
I don't know about anyone else, but I'm getting kind of itchy waiting for it. I just hope that Sun maintains enough controls to keep the OS rock-solid and pleasant to use while still actively working with the community. Time will tell...
Its nothing like Sun's.... its really odd.. on my Indy it can refer to disks in two notations, one's very NT style
Aren't the Indy's the machines that ran Windows NT MIPS Edition? That would explain why it accepts both formats. You could get the machine equipped with either OS.
Am I misremembering, or did SGI used to use OpenPROM?
I have to say, one part of me wants to scream out at the loss of such awesome hardware. (I *love* the graphical console on Suns, the coolness of OpenPROM, the finely crafted window XDMCP management, etc.) The other part of me realizes that there's no need for expensive Sun hardware for public terminals, and that PCs are more cost effective. *sigh* The end of an era.
IIRC, the standard is:
1 44 589.htmli /Colour-ls
Directories are bold
Links are italic
I think there were also underlines for something, but hell if I can remember what.
Here's some links to help you on your way:
http://www.webservertalk.com/archive109-2004-3-
http://sunsite.nus.sg/pub/LDP/HOWTO/min
but nooooo it uses the same syntax and commands even as the PROM monitor uses, except sash can read XFS volumes unlike the boot PROM and list the contents of directories.
Huh. You'd think SGI would just improve the OpenPROM code instead. Maybe they felt that would be "too much like Sun". No wonder they fell by the wayside.
Dude, you rock! I just cured my Mac of one of it's longest standing failings! (Yes, I'm too lazy to switch the default shell to BASH.)
Ummm... no. That would be a different thing. Ash is the Almquist Shell, an open source replacement for /bin/sh (the bourne shell).
-color code
Has anyone actually found this to be useful? I've always found it to be more annoying than anything. The alternative standard (for those of us with purdy graphical terminals on our UltraSparcs) of using Bold and Italics is much easier on the eyes and conveys just as much information.
"From Almquist to Z Shell"
If that were true, then the original title would have been "From Bourne Again to Z Shell".
Short answer: Yes
Long answer: I don't think most tcsh users use it for its programming ability. Instead, it tends to be useful as a solid interactive shell. Its general "feel" tends to be more solid than bash, owing partly to the fact that bash has a lot of built in key-shortcuts that tcsh doesn't. Of course, once you're used to being able to double tab for a directory listing, it's kind of hard to give up.
Did anyone ever actually argue over ZShell? I thought the primary arguments were always the BASH vs. KSH arguments (i.e. general users vs. hardcore unix admins) and the TCSH vs. BASH arguments (there is *some* validity to TCSH being a bit more professional, but BASH is just more useful).