>>>> In the days before networks and hard disks were common even in small >>>> firms, there was an issue with media - I know that we have programs from >>>> our company's early days that are effectively lost because they are on >>>> old 5 1/4" floppies. You can also get in trouble if you use tape for >>>> your primary archive media. But other than that, media should not be an >>>> issue. >>> The old server has gone done and this hard drive uses an interface >> Interfaces older than IDE were very rare, and if you have to use >> something like older SCSI interfaces, you can still get the cards. The >> PC world is pretty good at backwards compatibility.
>>> and file system no longer supported by new system(s), is more common a >> I'd be impressed if you can think of a file system that is a realistic >> candidate for such a situation, and which is not supported by Linux.
> [%X]
> Wonder how many remember as far back as the Kansas City Tape Standard for > Data Recording onto Audio Cassettes. If really pressed I could still cobble
<grin> Or folks who used "VCR data recorders" manufactured iin somebody's garage...
> one of those up. However, if it was really important data to keep, then it > should have been subject to a migration policy so that it was appropriately > transferred to modern media.
*This* is the key issue here! 20 years ago I spent several weeks takiing everything that I had archived (floppies of various sizes, 9 track tape, a slew of other oddball tapes, etc.) and copied it onto "modern media". Since then, every project has been added to the pool.
I keep backups on a RAID5 array, additional copies on my regular workstation (for more recent work or anything that I want to "have a look back at"), other copies on CD's and DVD's (these are POOR choices, IMO) and on DLT. The most vulnerable of these are those on rotating media as you can lose it *all* in a single ohnosecond! If possible, find an external drive that has a hardware write protect switch if you want to go that route...
The *good* thing about archives is they don't change often. So, you (i.e., *I*) don't have to repeat this process very often -- just incrementally update it.
D Yuniskis wrote: > Paul E Bennett wrote: >> David Brown wrote:
>>> Paul Carpenter wrote:
>> [%X]
>>>>> In the days before networks and hard disks were common even in small >>>>> firms, there was an issue with media - I know that we have programs >>>>> from >>>>> our company's early days that are effectively lost because they are on >>>>> old 5 1/4" floppies. You can also get in trouble if you use tape for >>>>> your primary archive media. But other than that, media should not >>>>> be an >>>>> issue. >>>> The old server has gone done and this hard drive uses an interface >>> Interfaces older than IDE were very rare, and if you have to use >>> something like older SCSI interfaces, you can still get the cards. The >>> PC world is pretty good at backwards compatibility.
>>>> and file system no longer supported by new system(s), is more common a >>> I'd be impressed if you can think of a file system that is a realistic >>> candidate for such a situation, and which is not supported by Linux.
>> [%X]
>> Wonder how many remember as far back as the Kansas City Tape Standard >> for Data Recording onto Audio Cassettes. If really pressed I could >> still cobble
> <grin> Or folks who used "VCR data recorders" manufactured > iin somebody's garage...
>> one of those up. However, if it was really important data to keep, >> then it should have been subject to a migration policy so that it was >> appropriately transferred to modern media.
> *This* is the key issue here! 20 years ago I spent several weeks > takiing everything that I had archived (floppies of various > sizes, 9 track tape, a slew of other oddball tapes, etc.) and > copied it onto "modern media". Since then, every project > has been added to the pool.
> I keep backups on a RAID5 array, additional copies on my > regular workstation (for more recent work or anything that > I want to "have a look back at"), other copies on CD's > and DVD's (these are POOR choices, IMO) and on DLT. The > most vulnerable of these are those on rotating media > as you can lose it *all* in a single ohnosecond! If > possible, find an external drive that has a hardware write > protect switch if you want to go that route...
You /can/ lose data on hard disks fairly quickly, but typically you have to be very unlucky (assuming you make your backups write-protected for normal use). It's a good idea to have two independent copies on different computers, in different locations - you are not going to have hard disk fails, fires, or human error on both systems at once.
> The *good* thing about archives is they don't change > often. So, you (i.e., *I*) don't have to repeat this process > very often -- just incrementally update it.
You don't have to repeat it too often, but you /do/ need to check your restoration procedures regularly. This is particularly true if you rely on tape and/or specific backup programs - have you tested the tapes on an independent system (hardware and software)?
David Brown wrote: > D Yuniskis wrote: >> Paul E Bennett wrote: >>> David Brown wrote:
>>>> Paul Carpenter wrote:
>>> [%X]
>>>>>> In the days before networks and hard disks were common even in small >>>>>> firms, there was an issue with media - I know that we have >>>>>> programs from >>>>>> our company's early days that are effectively lost because they >>>>>> are on >>>>>> old 5 1/4" floppies. You can also get in trouble if you use tape for >>>>>> your primary archive media. But other than that, media should not >>>>>> be an >>>>>> issue. >>>>> The old server has gone done and this hard drive uses an interface >>>> Interfaces older than IDE were very rare, and if you have to use >>>> something like older SCSI interfaces, you can still get the cards. The >>>> PC world is pretty good at backwards compatibility.
>>>>> and file system no longer supported by new system(s), is more common a >>>> I'd be impressed if you can think of a file system that is a realistic >>>> candidate for such a situation, and which is not supported by Linux.
>>> [%X]
>>> Wonder how many remember as far back as the Kansas City Tape Standard >>> for Data Recording onto Audio Cassettes. If really pressed I could >>> still cobble
>> <grin> Or folks who used "VCR data recorders" manufactured >> iin somebody's garage...
>>> one of those up. However, if it was really important data to keep, >>> then it should have been subject to a migration policy so that it was >>> appropriately transferred to modern media.
>> *This* is the key issue here! 20 years ago I spent several weeks >> takiing everything that I had archived (floppies of various >> sizes, 9 track tape, a slew of other oddball tapes, etc.) and >> copied it onto "modern media". Since then, every project >> has been added to the pool.
>> I keep backups on a RAID5 array, additional copies on my >> regular workstation (for more recent work or anything that >> I want to "have a look back at"), other copies on CD's >> and DVD's (these are POOR choices, IMO) and on DLT. The >> most vulnerable of these are those on rotating media >> as you can lose it *all* in a single ohnosecond! If >> possible, find an external drive that has a hardware write >> protect switch if you want to go that route...
> You /can/ lose data on hard disks fairly quickly, but typically you have > to be very unlucky (assuming you make your backups write-protected for > normal use). It's a good idea to have two independent copies on > different computers, in different locations - you are not going to have > hard disk fails, fires, or human error on both systems at once.
<grin> *I* used to think that way! I kept backups on external SCSI drives that were neither "on-line" (mounted) nor *spinning* (powered up).
On one occasion, I needed to restore a file from one of these "offline archives". I spun-up the drive, mounted the filesystem and the drive *crashed*!
OK, bad luck.
But, I have a *second* backup drive (drives are cheap insurance). So, I pulled that drive out, spun it up, mounted it ... and watched *it* crash!
Turns out there was a bug in the driver that this model of drive tickled. Very reliably. I.e., I could have had *20* such drives and it would have dutifully scrambled *all* of them!
Note that the only thing I "did wrong" here was not using the write-protect jumper on the drive before installing it in its enclosure.
Undaunted, I moved on to my CD archive and was able to restore the file from a CD. If that had failed, I would have fallen back to tapes.
And, then turned my attention to the "computer" to see what the problem was, there.
Point is, if you *assume* things, you get bitten. My assumption was that I could NEVER have two hard drives fail at the same time. And, *neither* of them did! I later re-copied the portion of my archive that resided on these two (duplicate) drives *back* onto them.
>> The *good* thing about archives is they don't change >> often. So, you (i.e., *I*) don't have to repeat this process >> very often -- just incrementally update it.
> You don't have to repeat it too often, but you /do/ need to check your > restoration procedures regularly. This is particularly true if you rely > on tape and/or specific backup programs - have you tested the tapes on > an independent system (hardware and software)?
Of course! The windows system is (as always) the PITA. So, I just backup it from one of the UN*X boxen so I'm just dealing with "files" and not some stupid proprietary "backup format" (been there, done that, t-shirt to prove it).
I have six or seven DLT's here so I am not dependant on "working hardware". And several different machines that can read and write the archives portably. Instead of chasing the latest and greatest "PC hardware", I'd rather invest in having duplicates of *everything*!
Andrew <asm...@blackstone.biz> wrote: > Jon Kirwan wrote: > > On Fri, 6 Nov 2009 23:00:15 +0000 (UTC), Andrew Smallshaw > > <andr...@sdf.lonestar.org> wrote:
> >> On 2009-11-05, Paul Carpenter <p...@pcserviceselectronics.co.uk> > >> wrote: > >>> Despite C, being free format, avoid too much free format, > >>> remembering that at some time it may well be printed, 300 > >>> character lines wrap very interestingly, if they wrap. Choosing > >>> indentation matching can make following the code easier, even if > >>> you have managed to get the function to fit on one page. > >> I keep getting criticism for ignoring an imagined 80 column limit. > >> Yes, I'll keep it under 132 columns but not 80 - it just gets too > >> restrictive and demands either less indentation of cyptically short > >> variable names which are a much bigger problem. 132 (sometimes > >> 136) is of course how long a line can be printed on a wide carriage > >> printer, so it is largely historical now, although is does > >> approximate what enscript -r can fit on a sheet of A4 with default > >> settings. With modern text editors under GUIs you are typically > >> not limited to anythign like 80 column views so I see no practical > >> reason to stick to such a narrow limit.
> > I stay with a strict 79 column limit. It turns out that I also > > print my listings on the laser printer in portrait mode and that > > with the use of commonly available fixed-pitch fonts like Courier > > or Prestige Elite I get just about the right font size for > > readability, as well.
> > I couldn't possibly consider 132 columns as acceptable anymore. I > > still have the boxes of printer paper designed for that, but long > > since lost printers with the sprockets to feed the paper. Use it > > for scratch paper, now. And printing landscape, while acceptably > > printing at 132 columns fixed-pitch, puts too few lines on the > > page. Readable code requires that the basic idea is presented (as > > well as possible) on a single page (or perhaps two.) The few lines > > that I wind up wrapping do NOT add anywhere near enough extra > > vertical lines to cause a problem. While printing landscape would > > lose way too many lines and would definitely become a readability > > problem for me.
> > I guess different people come to different, strongly held > > conclusions.
> > Jon
> Its pointless to print out code today due to lack > of tractor feed printers. What happened to them? > To me, a stack of non-contiguous > sheets has very little value.
Tractor feed printers are still decidedly available. There's a pretty regular stream of HP Quietjets on eBay for cheap, though you can go broke buying the teensy little ink bullets for them. Or if you're doing real volume, I've seen some tractor fed lasers. They're the size of a Mini Cooper, horrifically expensive, and move whole forests of paper through.
-- Rob Gaddi, Highland Technology Email address is currently out of order
Andrew wrote: > Its pointless to print out code today due to lack > of tractor feed printers. What happened to them?
Nothing unusual: their typical application range reduced from near-universal to a rather small niche. My car mechanic's shop, e.g., still relies on needle printers(!) with tractor feeds.
> To me, a stack of non-contiguous sheets has very little value.
>> Its pointless to print out code today due to lack >> of tractor feed printers. What happened to them?
>Nothing unusual: their typical application range reduced from >near-universal to a rather small niche. My car mechanic's shop, e.g., >still relies on needle printers(!) with tractor feeds.
One of the local office supply stores here still carries them, though I'll admit to having been surprised to see one on display.
Somewhere, in some box or other, I still have one of those motorized ribbon re-inker gadgets and most of a pint of ink (or, what's left after the vehicle has evaporated).
Rich Webb wrote: > On Mon, 09 Nov 2009 18:10:23 +0100, Hans-Bernhard Bröker > <HBBroe...@t-online.de> wrote:
>> Andrew wrote:
>>> Its pointless to print out code today due to lack >>> of tractor feed printers. What happened to them? >> Nothing unusual: their typical application range reduced from >> near-universal to a rather small niche. My car mechanic's shop, e.g., >> still relies on needle printers(!) with tractor feeds.
> One of the local office supply stores here still carries them, though > I'll admit to having been surprised to see one on display.
> Somewhere, in some box or other, I still have one of those motorized > ribbon re-inker gadgets and most of a pint of ink (or, what's left after > the vehicle has evaporated).
> Ahh... those were the days. ;-)
For many applications in business, a dot matrix printer is still the only solution, especially if you use multipart forms for receipts, local and accounts copies etc. It's also the cheapest and least complicated solution as well.
I don't print much code listings now, but always use laser printer in landscape mode to get 132 column width, to match the output of the editor. If you use meaningfull, english like variable names, it doesn't take long to exceed 80 col width, even with 4 space indent...
|
