From: Ken Smith on
In article <ers2eb$8qk_004(a)s1016.apx1.sbo.ma.dialup.rcn.com>,
<jmfbahciv(a)aol.com> wrote:
>In article <erppm2$c02$5(a)blue.rahul.net>,
> kensmith(a)green.rahul.net (Ken Smith) wrote:
>>In article <erpb68$8qk_001(a)s934.apx1.sbo.ma.dialup.rcn.com>,
>> <jmfbahciv(a)aol.com> wrote:
><snip>
>
>>>>> Computer usage
>>>>>by the general population requires more than this. You keep
>>>>>looking at the load balance from a naive user POV.
>>>>
>>>>No, you are just making stuff up because you've been shown to be wrong
>>>>about the real world of computers today.
>>>
>>>Keep thinking like that and you'll never learn something.
>>
>>From you! You have been shown to be wrong on this subject.
>
>You think I'm wrong only becaues you don't have my knowledge.
>Do you also think that people, who are experts in fields not
>your own, are also wrong?

It appears that what you call knowledge is in fact a bunch of
misconceptions about hardware issues. You have made several statements
that are simply false on the subject. You may know things about the
coding of some old OSes but you are out of your depth when you try to talk
about hardware.

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

From: Ken Smith on
In article <errvc2$8ss_003(a)s1016.apx1.sbo.ma.dialup.rcn.com>,
<jmfbahciv(a)aol.com> wrote:
>In article <erpqdl$c02$6(a)blue.rahul.net>,
> kensmith(a)green.rahul.net (Ken Smith) wrote:
>>In article <erpeao$8qk_001(a)s934.apx1.sbo.ma.dialup.rcn.com>,
>> <jmfbahciv(a)aol.com> wrote:
>>>In article <ermuqc$rph$3(a)blue.rahul.net>,
>>> kensmith(a)green.rahul.net (Ken Smith) wrote:
>>>>In article <ermlh8$8ss_012(a)s774.apx1.sbo.ma.dialup.rcn.com>,
>>>> <jmfbahciv(a)aol.com> wrote:
>>>>>In article <erhnfn$em5$5(a)blue.rahul.net>,
>>>>> kensmith(a)green.rahul.net (Ken Smith) wrote:
>>>>>>In article <erhd4t$8qk_001(a)s916.apx1.sbo.ma.dialup.rcn.com>,
>>>>>> <jmfbahciv(a)aol.com> wrote:
>>>>>>>In article <i70nt25k4ubuvllr029cun9ebu1e1bng0a(a)4ax.com>,
>>>>>>> MassiveProng <MassiveProng(a)thebarattheendoftheuniverse.org> wrote:
>>>>>>>>On Mon, 19 Feb 07 13:29:06 GMT, jmfbahciv(a)aol.com Gave us:
>>>>>>>>
>>>>>>>>>Not at all. OSes were handling the above problems in the 60s.
>>>>>>>>>The reason virtual memory was invented was to solve the above
>>>>>>>>>problem.
>>>>>>>>>
>>>>>>>> The swapping, in this case, CAUSES the interference.
>>>>>>>
>>>>>>>That has to do with severe memory management problems.
>>>>>>
>>>>>>No, it is just part of the overhead of doing VM.
>>>>>
>>>>>Nope. VM doesn't have to swap. Swapping is done to make
>>>>>room so a memory request by another task can be serviced.
>>>>
>>>>You said "nope" and then confirmed that my statement was correct.
>>>>Swapping needs to happen if you need more virtual RAM than there is real
>>>>RAM. To be able to swap, the code for doing the swapping must always be
>>>>in the real RAM. As a result, there is code overhead in having a VM
>>>>system. There is also a speed overhead when swapping happens. The OS
>>>>uses some amount of CPU time on the taks switching needed to make VM do
>>>>the swap.
>>>
>>>VM isn't swapping. VM allows the OS to manage smaller chunks
>>>of memory rather than segments.
>>
>>That is completely and totally worng. "Virtual memory" means quite
>>literally "memory that is not real".
>
>No. It is memory whose addressing is larger than available physical
>memory.

No, not only the addressing appears larger. The total memory appears to
be more. Merely allowing an address space that is larger is merely
address translation. You only get into virtual memory when it appears the
programs as though the machine has more memory than there is physical RAM.
This is exactly what I was telling you when I directed you to how the word
"virtual" is defined.


>
>>MVT360 managed memory on a IIRC 4K
>>page basis. This certainly did not qualify as a virtual memory system.
>>
>>
>>>>>I don't know why but people often confuse virtual memory
>>>>>addressing with swapping. The two are separate.
>>>>
>>>>No, you are confused on the issue of needing to swap.
>>>
>>>No, I'm not. You are.
>>
>>It seems that your confusion runs much deeper than that. You seem not to
>>understand what "virtual" means.
>
>I know how OSes consider it. I was there when it was first implemented
>on our architectures. JMF, my other half, did the work.

You have confused address translation with virtual memory. You have been
trying to argue hardware issues you don't understand. Just because you
where standing in the same room and saw something happen doesn't mean you
understand it.

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

From: Ken Smith on
In article <ers29b$8qk_003(a)s1016.apx1.sbo.ma.dialup.rcn.com>,
<jmfbahciv(a)aol.com> wrote:
>In article <erpmth$c02$1(a)blue.rahul.net>,
> kensmith(a)green.rahul.net (Ken Smith) wrote:
[.....]
>>It isn't a corral. A corral implies a loss of freedom. I can still write
>>a check or see a teller if I want.
>
>For now.

.... and thus it will remain.

>
>>I can pay a bill while I'm at work of
>>on vacation. I have lost nothing.
>
>You have lost the physical paper trail. Doesn't it bother you
>that electronic checks can be applied against your account without
>any physical permission written by you?

The physical permission can be forged more easily than the electronic one.
When it gets to the bank, they do all the work electronically. As a
result, whether I do on line banking or not, the actual work is done
electronically. If the security in the bank and broken, not using on line
banking will not protect me.


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

From: Ken Smith on
In article <45E1B4F4.1B7C7FA2(a)hotmail.com>,
Eeyore <rabbitsfriendsandrelations(a)hotmail.com> wrote:
>
>
>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.

Even if you did try, at the bank the check causes an electronic transfer
of money. These days, the checks don't travel. It has been a long time
since physical money went from bank to bank in reaction to a check.

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

From: Ken Smith on
In article <errvlm$8ss_004(a)s1016.apx1.sbo.ma.dialup.rcn.com>,
<jmfbahciv(a)aol.com> wrote:
>In article <erpnd5$c02$2(a)blue.rahul.net>,
> kensmith(a)green.rahul.net (Ken Smith) wrote:
[....]
>>No, if the copy checks the dates, you can load the backups in any order.
>>What you do in practice is mount the complete backup and then the newest
>>incremental. You then mount the previous incremental and then the one
>>before that.
>
>This is one way to do a full restore. Note that it may also restore
>the cause of the problem.

It only restores things to as they were. It doesn't fix any buggy code in
the process. This is as much as you can ask of a restore. Repair
software is another issue.


>>If your software is any good, it will let you know when you can stop. All
>>that's needed is to record the dates on all of the files. A fairly simple
>>script can tell you if you have more to do.
>
>Software cannot tell you if the file you want is no longer on
>storage.

What the heck do you mean by that? Obviously software can tell you if a
file exists or not. All it needs is a list of all the files that do
exist.


>>
>>
>>>Another method was to do a full backup save each day. This will
>>>work until you find that you lost a source file sometime in the
>>>last 12 years. Now how do you find the last save of that file?
>>
>>This is not a problem in practice if the copy is smart about dates.
>
>AFAIK, only our system had enough dates stored in each file's
>RIB (retrieval information block) that could do this.

On a Linux machine, there is enough information to do it.


>>The usual practice is to do a full backup every so often and incremental
>>ones in between.
>
>Yes but only for static storage. This will not cover data
>that is transaction-based.

Yes it does cover transaction based data. Take the example of banking
information. The account balances as of, lets say, midnight are stored.
From that point forwards, you have the transaction records. The
transaction records for a given account contains not just the movement of
the money but other information such as the new total. In this case one
needs only look back in time for each account to the last time there was a
break in the transactions. In a real time system, when you are doing
rapid transactions, the totals are always out of date. The first
transaction after a break, has a correct total.


>
>/BAH


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