Anteaus said:
There is a lot of truth in what the OP says.
What in the OP's words was it? Since you're made no reference to, now
use of, the OP's query, there is nothing to compare that sentence about.
Business users see the PC as a tool to do work with.
If you drill fails, you get another drill. You don't have to buy a
complete new set of bits, or have the house rewired to make the new
drill work. Neither do you have to redrill all of the holes you've
already drilled. That is because the drill is a self-contained unit
with standard I/O interfaces (110/240vac, handgrip, chuck) the
replacement of which do not adversely impact on other tools or
services.
But drills do not have new parts sent to them periodically, which by
their nature necessitates keeping a record of what was sent, either.
Nor does a drill run another drill, peripheral or machine. A drill only
makes holes or tightens/untightens screws. But a PC does much more,
works with many perhipherals, drives them, starts them, stops them,
prints them, saves them, replies to them, etc etc etc. If you're going
to attempt to use analogies, at least pick something that relates.
Jeez.
Programmers, OTOH, see 'tight integration' as an objective in PC
software design, building-in numerous interconnections between
internal modules.
That is patently untrue. You have absolutely no concept of the
methodology of code developtment and should leave this subject alone.
The preference for interconnections as you call them is by marketing and
users; the ones doing the code (it's often several different people) are
simply following the requirements of a project's descriptions and
specifications.
Most of which are never used, but which tie-down
the software in such a way as to make it non-portable.
That would have nothing to do with portability. Portability of/for
what?? Do you even know what you said there?
This makes PC
upgrades and backup-recovery an unnecessarily traumatic process.
Nonsense. It has become so easy and so common place these days that
even non-ignorant school children can do it and others never even know
it's happening because it's reliable and automated. The most work with
a good backup strategy is put in for making periodic checks to insure
that the backups ran and that no error messages are waiting for action.
These days there are seldom any errors even. All that's needed is RTFM
and a moderate intelligence for the one implementing same. Other than
housekeeping there is nothing i have to do about/with my backup ware;
it's all automated. Once a month I make a set of DVDs for offsite
backup storage and that's all there is to do.
Different makes of drill contain very different motor designs, but
Actually, drill motors are very, very similar these days whether it's a
line or battery operated drill. You only start to see differences when
you move into the more expensive and/or commercial quality drills most
people consider too expensive to bother with. Yet, after buying two of
the cheapies you've spent more than you would have on the commercial
product and it's going to keep on running for a long time yet.
the user need not be concerned about this. This is because the
drill's external interfaces are standardised, and no outside
connection bypasses those interfaces.
Actually, there are mor differences in "interfaces" than there are
innards. Constant speed, variable speed, reversible, clutched,
slip-ringed, 3/8" max or 1/4" max or 1/2" max drill shanks, speeds from
1 to 500 or 1500 or 2500 or 150 to 2500., and several other combinations
amongst the different manufacturer's. That is THE place they can do
something they hope will distinguish their drills from the competition,
so the interfaces DO vary; a lot, from mfr to mfr.
The job of an OS should be to interface with varying hardware,
providing a standardised interface that applications can make calls
to. If it confined itself to that proper role, then we would not have
these problems.
You've chosen a very poor analogy.
Sort of true, but FALSE if one has followed the standard strategies for
backing up machines and has copies of backups on an unplugged, stored
out of sight external drive, plus another set periodically stored
off-site. If my computer were stolen or lost today, I would simply pull
my backups out of my firesafe, or go to a relative's with whom I swap
DVD sets of backups periodically, and then restore that to my new
computer. The odds of my own home and my offsite storage location both
being bomed to rubble are extremely low; so low that if that happens I'm
not going to be much worried about my backups! As long as they're
stored offsite I can take my time to put my life back together before
worrying about a restoration.
The most effective part of ANY backup strategy is having a backup
stored offsite, far away from the computer it's for, in addition to
being on say an external disk drive.
You
The very worst that could happen would be having to restore to a
different machine, in which case the registry would be no good, that's
right. But there are two possibly easy solutions:
-- Do the restore. Run a Repair Install.
or
-- Do a bare steel restore. Then it doesn't care what the hardware is;
it'll build its own registry.
In both cases, NO, you don't need the install disks, but you MIGHT need
the keycodes. And your EFS exports if you encrypt. And, in the case of
a pirated OS, here's where you get caught<g>. Or some do anyway, not
necessarily "you" in the singular sense.
Let's keep it real, folks. Do the research, then do the work. Then
relax, knowing you're set for at least 99% of the problems you could
encounter. Such as forgetting to verify the data set you stored off
line<g>. BTW, copies of your original discs should be part of a good
backup strategy, too.
HTH,
Twayne`
