OT: paging MAC expert(s) --- What's a Performa?

From: Richard Erlacher <edick_at_idcomm.com>
Date: Tue Nov 20 16:35:39 2001

Well, remember that M$ is in the business of making money, which they seem to do
really well. Lots of folks have drawn the erroneous conclusion that they're in
the business of writing software. That's not the case. They're in the business
of SELLING software. It's not their job to protect the consumer. It's the
consumer's job to protect himself. The consumer's been falling down on the job,
hence, he keeps on buying that Microsoft product line. If he were smart, he'd
stick with the devil he partially knows, and let M$ go under. SO much for
Billy-bashing ...

I'd like to see someone write a chunk of software that does as much as this one
in 20 minutes, BTW. I don't think something this size will even link in 20
minutes.

Image recording was OK when one had a firm grasp of what the controller did with
the bits from the drive and what the OS did with them afterward. That's no
longer the case. In fact, so much wierd stuff goes on internally to the drive,
since the controller function is dedicated on each drive, that it's hard to know
what is different between two drives.

Dick

----- Original Message -----
From: "Christopher Smith" <csmith_at_amdocs.com>
To: <classiccmp_at_classiccmp.org>
Sent: Tuesday, November 20, 2001 1:28 PM
Subject: RE: OT: paging MAC expert(s) --- What's a Performa?


> > -----Original Message-----
> > From: Richard Erlacher [mailto:edick_at_idcomm.com]
>
> > It's the "quite a bit of extra work" that concerns me, as the
> > boys at M$ haven't
> > managed to do it right yet, and they've been at it to the
> > tune of 100K man hours
> > per year for a decade or so. Recording a bitwise image of
>
> Well, I haven't got much faith in them to begin with. They could work for
> 1000 years on a 20 minute job and still mess it up. I'm not saying that it
> might not actually take that long, just that m$ aren't competent enough to
> be a good indicator.
>
> > what you receive from
> > the disk may or may not give you all the information you need
> > to recreate the
> > files, since you may or may not know how the OS deals with
> > them. What's more,
>
> I was assuming you'd know the filesystem type at the time of the backup. I
> don't suppose it would be absolutely necessary. You might also recognize a
> filesystem by magic number/signature, or the like.
>
> [snip]
>
> > which you write such an image must be an EXACT duplicate of
> > the one from which
> > the image was recorded. The second drive may otherwise claim
> > to be identical
> > but have a different number of sectors per physical track,
> > use different mapping
> > arrangements, etc, and, especially, have different bad
> > blocks. Since you're
>
> Well, "otherwise identical" is dangerous territory at any rate. :) You're
> right, though, in that depending on the way the software components interact
> with the drive, one or more of these things might really screw things up. I
> suppose that would require one to know the internals of each system with
> which you plan to use this method.
>
> > going to send data that goes to where the drive sends it and
> > not necessarily to
> > the same physical location from which you got it because the
>
> ... which may be ok, depending on how the system interacts with the device
> in question. Of course, if you find that the system depends on the data
> being in some physical location, rather than in a logical location, you'd
> have to correct for that or _just not do it_ ;)
>
> [snip]
>
> > sent, you may be disappointed with the results because IDE
> > drives hide too many
> > details from the end-user.
>
> Yep. Tell me about it.
>
> [snip]
>
> > absolutely for certain, what
> > the drive does with the data you send it, and what the OS
> > does to process data
> > to and from the drive, you're on thin ice.
>
> That depends. For instance (This will now get very hypothetical), if the
> O/S handles data in logical blocks, and doesn't care too much the actual
> geometry of the drive, you might be ok with not knowing about the device.
> That is, with the exception of bad blocks. (Really I guess I'm talking
> about faking a standard interface even when it doesn't exist here)
>
> [snip]
>
> > all. Since SCSI is well established as to how it operates
> > its data management,
> > it yields more hope that you can process an image, though the
> > vagaries of the OS
> > are still a limiting factor.
>
> On the other hand, as some friends of mine are wont to say: "Neither S in
> SCSI means standard."
>
> > Image recording should work fine with MFM- and RLL-encoded
> > drives, even on a
> > track-by-track basis, and those offer some hope that one
> > could substitute one
> > sort of drive for another but hte ones which use BOTH CHS and
> > LBA addressing
> > won't tolerate the sort of operations to which an
> > incrementally developed OS
> > like Windows could create.
>
> Can't argue with that.
>
> Chris
>
> Christopher Smith, Perl Developer
> Amdocs - Champaign, IL
>
> /usr/bin/perl -e '
> print((~"\x95\xc4\xe3"^"Just Another Perl Hacker.")."\x08!\n");
> '
>
>
>
Received on Tue Nov 20 2001 - 16:35:39 GMT