From: jmfbahciv on
In article <9at0u29qgk8bq246lpi6ahft8o68qna00v(a)4ax.com>,
MassiveProng <MassiveProng(a)thebarattheendoftheuniverse.org> wrote:
>On Sat, 24 Feb 07 13:53:03 GMT, jmfbahciv(a)aol.com Gave us:
>
>>>We are talking about a backup. You can just copy the entire hard disk
>>>when it is a single PC.
>>
>>That is not a backup of the files.
>
> You're an idiot! A mirror of your drive volume whether kept on site
>or off, IS a backup, you total twit!

A mirror, as you are using the term, is a second copy of
the disk, not the files.
>>
>>YOu seem to be talking about a bit-to-bit copy.
>
> You are stupid. The mode does NOT matter.

It matters greatly. There are pitfalls in each kind of strategy.

> The finished copy is ALL that matters.

No. If you have copied the hiccup that caused the disk wipeout,
the finished copy also contains the problem.

>
>> That will also
>>copy errors which don't exist on the output device.
>
> You are too thick.
>
> Do you even know what an incremental backup is?

Yes. I maintained and developed the code we supplied on
our OS distribution tapes.


> It starts by making a FULL backup. From that point on, each
>additional backup done to the volume only adds those files that have
>changed. The volume written to follows all the standard FILE SYSTEM
>rules for one file being copied over another of the same name.

Oh, good grief. You have a serious design flaw here if you are
overwriting you backup copies.

> Again, you need to BONE UP.

I am boning up. I'm learning how pitiful the computing biz
is out there in the Real World. It's got serious problems.

/BAH
From: krw on
In article <ers25a$8qk_002(a)s1016.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv(a)aol.com says...
> In article <erpp2s$c02$4(a)blue.rahul.net>,
> kensmith(a)green.rahul.net (Ken Smith) wrote:
> >In article <erpam2$8ss_002(a)s934.apx1.sbo.ma.dialup.rcn.com>,
> > <jmfbahciv(a)aol.com> wrote:
> >>In article <ermtbj$rph$1(a)blue.rahul.net>,
> >> kensmith(a)green.rahul.net (Ken Smith) wrote:
> >>>In article <ermofh$8qk_003(a)s774.apx1.sbo.ma.dialup.rcn.com>,
> >>> <jmfbahciv(a)aol.com> wrote:
> >>>>In article <er4i05$1ln$7(a)blue.rahul.net>,
> >>>> kensmith(a)green.rahul.net (Ken Smith) wrote:
> >>>>>In article <er47qv$8qk_001(a)s897.apx1.sbo.ma.dialup.rcn.com>,
> >>>>> <jmfbahciv(a)aol.com> wrote:
> >>>>>[.....]
> >>>>>>>NT was written in the first place for a processor that didn't do
> >>>>>>>interrupts well.
> >>>>>>
> >>>>>>Nuts. If the hardware doesn't do it, then you can make the software
> >>>>>>do it. As TW used to say, "A small matter of programming".
> >>>>>
> >>>>>On the N10 there was no way to code around it. The hardware was designed
> >>>>>so that it had to walk to the breakroom and back before it picked up the
> >>>>>phone. Nothing you could say over the phone would help.
> >>>>>
> >>>>>
> >>>>>
> >>>>>>> The N10 AKA 860 processor had to spill its entire
> >>>>>>>pipeline when interrupted. This slowed things down a lot when the code
> >>>>>>>involved interrupts. When the project was moved back to the X86 world,
> >>it
> >>>>>>>was marketed as secure ... well sort of .... well kind of .... its
> better
> >>>>>>>than 98. I don't think a lot of time was spent on improving the
> >>interrupt
> >>>>>>>performance.
> >>>>>>
> >>>>>>You are confusing delivery of computing services by software with
> >>>>>>delivery of computing services of hardware.
> >>>>>
> >>>>>No, hardware sets the upper limit on what software can do.
> >>>>
> >>>>That all depends on who is doing the coding.
> >>>
> >>>If a CPU chip needs 1 hour to do a an add instruction, you can't make it
> >>>go faster by anything you code. Like I said it sets the upper limit on
> >>>the performance.
> >>
> >>Sigh! If an ADD takes an hour and the computation has to be done
> >>in less time, then you don't use the ADD instruction. You do
> >>the addition by hand.
> >
> >In other words: You need another CPU to do the operation.
>
> Not at all. You can arithmetic by hand.
>
> > No amount of
> >fancy code on a machine that takes an hour per instruction will fix it.
> >
> >This is what I have been trying to explain to you about the hardware
> >setting the upper limit on performance.
>
> Sigh! The IBM 1620 had no arithmetic instructions. Arithmetic
> was done "by hand" by looking up table entries.

Yep! The 1620 was known as the CADET (Can't Add, Didn't Even Try).

--
Keith
From: Eeyore on


jmfbahciv(a)aol.com wrote:

> Doesn't it bother you that electronic checks can be applied against your account
> without
> any physical permission written by you?

You mean a debit ?

I could hardly live without it.

Graham

From: Ken Smith on
In article <ers25a$8qk_002(a)s1016.apx1.sbo.ma.dialup.rcn.com>,
<jmfbahciv(a)aol.com> wrote:
>In article <erpp2s$c02$4(a)blue.rahul.net>,
> kensmith(a)green.rahul.net (Ken Smith) wrote:
[......]
>>>>If a CPU chip needs 1 hour to do a an add instruction, you can't make it
>>>>go faster by anything you code. Like I said it sets the upper limit on
>>>>the performance.
>>>
>>>Sigh! If an ADD takes an hour and the computation has to be done
>>>in less time, then you don't use the ADD instruction. You do
>>>the addition by hand.
>>
>>In other words: You need another CPU to do the operation.
>
>Not at all. You can arithmetic by hand.

You will say anything to avoid admitting that you missed the point when I
said that the hardware is what sets the upper limit on the performance.

>
>> No amount of
>>fancy code on a machine that takes an hour per instruction will fix it.
>>
>>This is what I have been trying to explain to you about the hardware
>>setting the upper limit on performance.
>
>Sigh! The IBM 1620 had no arithmetic instructions. Arithmetic
>was done "by hand" by looking up table entries.

..... and that set a limit on the performance didn't it.
--
--
kensmith(a)rahul.net forging knowledge

From: Ken Smith on
In article <4f62c$45e0c567$cdd08488$22846(a)DIALUPUSA.NET>,
nonsense(a)unsettled.com <nonsense(a)unsettled.com> wrote:
>Ken Smith wrote:
[...]
>>>You are not talking about swapping; you are talking about the
>>>working set of pages. You do NOT have to swap code if the
>>>storage disk is as fast as the swapping disk.
>>
>>
>> What the devil are you talking about? You were sort of making sense until
>> you got to this. The "swapping" under discussion is between the swap
>> volume and the physical RAM. The swap volume can never be anything like
>> as fast as the RAM. A VM system makes it appear that there is more RAM
>> than is physically there by using the swap volume.
>>
>> Do you think that computers still use drum storage or mumble tanks for the
>> memory.
>
>It could just be her shorthand but she still talks about
>"core" which I remember well, and differing speeds of
>hard drives, diskpacks, and so on. I wonder if she is still
>using an 80ms full sized hard drive on her home system.

It was "high speed" drum drives that were used for swap space in the
distant past. They were much faster than the disk drives of the era.


>That being said, a great deal of what she has been writing
>attaches to really elementary computer and OS design which,
>offhand, reading both of you going at it, she seems to
>understand better. It seems to me you're a level or few away
>from the sots of internals she worked with during her career.

She doesn't have the grasp of hardware and when she tries to get into that
area, she doesn't realize that she is outside her area of knowledge.
Remember that most of this has been about device drivers and VM
implementations etc. In these areas you have a large insection between
the hardware and software.

[....]
>Most of those essentials haven't changed all that much. AFAIK
>the linux systems we're running continue to organize the hard
>drives much as early Unix organized tape magnetic storage.

Do you mean the hardware or the logical content. In either case you are
wrong about how things are done on most Linux boxes today. The Reiser
file system is what is used for the logical contents. The hardware is
typically SATA.

The partitioning is still as it was in DOS days partly because the Linux
folks want to be able to work with DOS/Windows drives.


--
--
kensmith(a)rahul.net forging knowledge