Jihad needs scientists

In article <esmj7c$bj2$1@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:

In article <esm9f6$8ss_002@s1012.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In article <esju3h$1a4$2@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
[.....]
Having multiple disks connected to a single disk drive controller
electronics gives absolutely no advantage and a few disadvantages.

I know that one can have multiple structures on one drive. Has
the need of having one structure on multiple drives gone away?

No, it hasn't gone away completely. There is a lot less need for logical
volumes to span multiple disks today.

Is this because disk capacities are larger than most needs? With
the habits of downloading music and videos, etc. won't there be
another capacity problem fairly soon?

It is still done in cases where
something will be truly huge. It is also done in the name of speed where
the data must be moved on and off the disk at speeds that are impractical
for hardware.

The last reason was valid in the olden days. JMF visited an insurance
company site and saw a disk farm of [can't remember the number]
hundreds, I think. He was awed because it was all one file.
There was no way our products could deal with
that kind of a data base. IBM knew how to handle those.

/BAH

 

In article <esml4r$bj2$3@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:

In article <esmalk$8qk_001@s1012.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In article <esjvn9$1a4$4@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
[....]
If you know what you intend to write onto the tape, figure out what the
checksum will be and then write the tape as you intend there is no extra
effort needed.

That does not give you a checksummed directory of the physical
tape you just made. All the handwaving and blustering you
are doing still does not satisfy the requirement.

Yes it does. Imagine it step by step.

(1)
You calculate the checksum of what you intend to put on the tape.

(2)
You put exactly what you intend onto the tape

(3)
You calculate the checksum of what you have put on the tape.

The checksum of the contents of the tape is not interesting.
That is a summary and doesn't help. A bit by bit verify
is done instead of your checksum summary.

The record of the checksums of each file on the tape is
the needed information. That itemized record is put into
a file which is the first file on the tape.

If the checksum at step (3) doesn't match the checksum at step (1), you
haven't written what you intended onto the tape. I am really surprised
that you can't see this.

I'm at a loss to try to explain what we were doing. YOu seem
to be determined not to understand.

[....]

If you intend to put the files onto the tape and can do so you can also
figure out what the directory should look like before hand. This is so
simple that it doesn't need further discussion.

You still are not getting the fact that the directory of the tape
had to be on the tape--not a directory of the files on disk
soon to be copied to the tape.

Why the devil can't you understand this!!!!!! Go back and look at what I
wrote above.

Your solution does not provide a list of all files on the tape.

I have told you how to do it when you know what will end up
on the tape. You were talking about tapes that will contain code to be
sent to others. If you don't know what that tape will contain, you are
not ready to make it.

I also pointed out but did not cover that there is a method for tapes
where the contents are not known before hand. The fact that you haven't
been able to understand the simple case makes it nonuseful to get into
that subject right now.


The issue of what to do if you can't be sure about how much will really
fit onto the tape is worthy of further discussion if you want to know how
to solve that one.

I know more about how to fit stuff on small tapes than you will ever
encounter. Tape fitting still has nothing to do with the requirement
of a directory of the tape prepended to the files we distributed
on that tape.

The tail end of this is wrong in a way that I won't try to explain to you
until you understand the simpler case. The start of it is evidence that
haven't yet understood the simple case.

Your simple case doesn't address any of the issues. All it does
is create extra work in the procedure with no usefulness.

<snip>

The problem
is that you couldn't see how to make the checksum correct when the file
that contained the checksum had to be included in the checksum.

Since the contents of the directory file will always change (checksummed
file's checksum is the thing that will never be a constant),
there will never be an accurate directory of the tape. However,
no customer's system needed to use the directory-of-the-tape file's
checksum to verify their restores.

This is wrong in two way. The checksum can in fact be put in place after
all the data has been saved.

You can't edit a tape. That would open such a can of Murphy's
worms, even if it were possible.

The contents of the directory on the tape
doesn't change once the tape is created and is ready to ship.

A tape is not a directory medium. The file I am talking about
is part of the save set.

<snip>

That is not how we used checksums when packaging our materials.
The program our customers used to get a checksum had to match
the program we used to get the checksum we reported.

There is absolutely nothing in what I suggested that changes this. I will
suggest you go back over the subject again.

I don't have to; my methods worked and provided enough data
for sanity checks on both ends of the distribution system.

<snip>

/BAH

 

In article <esou80$8qk_001@s1016.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com wrote:

In article <esml4r$bj2$3@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
In article <esmalk$8qk_001@s1012.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In article <esjvn9$1a4$4@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
[....]
If you know what you intend to write onto the tape, figure out what the
checksum will be and then write the tape as you intend there is no extra
effort needed.

That does not give you a checksummed directory of the physical
tape you just made. All the handwaving and blustering you
are doing still does not satisfy the requirement.

Yes it does. Imagine it step by step.

(1)
You calculate the checksum of what you intend to put on the tape.

(2)
You put exactly what you intend onto the tape

(3)
You calculate the checksum of what you have put on the tape.

The checksum of the contents of the tape is not interesting.
That is a summary and doesn't help. A bit by bit verify
is done instead of your checksum summary.

The record of the checksums of each file on the tape is
the needed information. That itemized record is put into
a file which is the first file on the tape.

Let me try to explain using different lingo.

The first file on the tape, TAPE.DIR, is the invoice of the
distribution and contains a list of each item on the tape,
including that item's checksum.


<snip>

/BAH

 

[nonsense@unsettled.com]

jmfbahciv@aol.com wrote:

In article <vsnuu2587pd2ap5r5ibut3qfbueoorvfkb@4ax.com>,
MassiveProng <MassiveProng@thebarattheendoftheuniverse.org> wrote:

On Wed, 07 Mar 07 13:33:40 GMT, jmfbahciv@aol.com Gave us:


In article <f5etu2huta97pm9kqgu8d2g4tehvemr00h@4ax.com>,
MassiveProng <MassiveProng@thebarattheendoftheuniverse.org> wrote:

On Wed, 07 Mar 07 12:33:51 GMT, jmfbahciv@aol.com Gave us:


Our OS philosophy used all available pathways and never mothball
any of them. It is still a computer system truth that says
"Use or lose it." This aspect of gear sure can make one
superstitious.


We are approaching reliable, secure 10Gb/second networks now... where
have you been?

Now I suggest that you count the pathways and the number of "nodes"
required to keep the appearance of extreme capacities and
infallibility.


Hahahaha! We are running servers that are accessed by the pentagon
on a daily basis. 100% secure, IP encrypted in hardware, and NOBODY
but the recipient gets ANY useable data, as well as giving up there
locale, resulting in them getting busted.

Try again.


What the fuck do you think I've been talking about?

Alzheimerish blather.


Single pathways
cannot be used in network (that's why it has the root net in it).
The same thing is true with computer systems.

EVERYTHING is becoming networked. Haven't you even heard of
"network attached storage" yet? No computer there. Just plain old
access for those given it. None for those that are NOT given it.


As I said above, our OS philosophy was to provide multiple pathways.
Multiple pathways...do you understand what that means? So why
are you demeaning the OS philosophy with an argument about networks?


Similar to you and your capacity to learn about all of this. More
and more I simply find you as Peter Gabriel said...

"You're not one of us"


I am very glad to not be in your category.

Double!

 

[Ken Smith]

In article <esothi$8ss_002@s1016.apx1.sbo.ma.dialup.rcn.com>,
<jmfbahciv@aol.com> wrote:

In article <esmj7c$bj2$1@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
In article <esm9f6$8ss_002@s1012.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In article <esju3h$1a4$2@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
[.....]
Having multiple disks connected to a single disk drive controller
electronics gives absolutely no advantage and a few disadvantages.

I know that one can have multiple structures on one drive. Has
the need of having one structure on multiple drives gone away?

No, it hasn't gone away completely. There is a lot less need for logical
volumes to span multiple disks today.

Is this because disk capacities are larger than most needs? With
the habits of downloading music and videos, etc. won't there be
another capacity problem fairly soon?

This may happen some time in the slightly distant future. Modern OSes
allow what the user sees as a directory to be a different disk drive.

MS-DOS did this with the "join" command. When Windows 95 was brought out,
the "join" command went away. On Linux and OS-X, the command is "mount".

It isn't much of a stretch of the imagination to see some OS automatically
assigning an entier drive to things like videos.

It is still done in cases where
something will be truly huge. It is also done in the name of speed where
the data must be moved on and off the disk at speeds that are impractical
for hardware.

The last reason was valid in the olden days. JMF visited an insurance
company site and saw a disk farm of [can't remember the number]
hundreds, I think. He was awed because it was all one file.
There was no way our products could deal with
that kind of a data base. IBM knew how to handle those.

IBM's design of the logical structure was very good from this point of
view. The Volume Table Of Contents told you where the Data Extent Blocks
were. The DEBs formed a chain. Extending this chain to include which
physical drive the next things were on wouldn't be hard to do.

--
--
kensmith@rahul.net forging knowledge

 

[Ken Smith]

In article <esou80$8qk_001@s1016.apx1.sbo.ma.dialup.rcn.com>,
<jmfbahciv@aol.com> wrote:

In article <esml4r$bj2$3@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
In article <esmalk$8qk_001@s1012.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In article <esjvn9$1a4$4@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
[....]
If you know what you intend to write onto the tape, figure out what the
checksum will be and then write the tape as you intend there is no extra
effort needed.

That does not give you a checksummed directory of the physical
tape you just made. All the handwaving and blustering you
are doing still does not satisfy the requirement.

Yes it does. Imagine it step by step.

(1)
You calculate the checksum of what you intend to put on the tape.

(2)
You put exactly what you intend onto the tape

(3)
You calculate the checksum of what you have put on the tape.

The checksum of the contents of the tape is not interesting.
That is a summary and doesn't help. A bit by bit verify
is done instead of your checksum summary.

Suddenly you are changing the subject. The question is: would the
checksum before and after match? The answer is yes, so the method works.

If the checksum at step (3) doesn't match the checksum at step (1), you
haven't written what you intended onto the tape. I am really surprised
that you can't see this.

I'm at a loss to try to explain what we were doing. YOu seem
to be determined not to understand.

You were making a mistake, is what you were doing.

You still are not getting the fact that the directory of the tape
had to be on the tape--not a directory of the files on disk
soon to be copied to the tape.

Why the devil can't you understand this!!!!!! Go back and look at what I
wrote above.

Your solution does not provide a list of all files on the tape.

Yes it does. I have shown how you can make the checksum on this file
correct. This file that contains the list is the very file we have been
talking about.

I have told you how to do it when you know what will end up
on the tape. You were talking about tapes that will contain code to be
sent to others. If you don't know what that tape will contain, you are
not ready to make it.

I also pointed out but did not cover that there is a method for tapes
where the contents are not known before hand. The fact that you haven't
been able to understand the simple case makes it nonuseful to get into
that subject right now.


The issue of what to do if you can't be sure about how much will really
fit onto the tape is worthy of further discussion if you want to know how
to solve that one.

I know more about how to fit stuff on small tapes than you will ever
encounter. Tape fitting still has nothing to do with the requirement
of a directory of the tape prepended to the files we distributed
on that tape.

The tail end of this is wrong in a way that I won't try to explain to you
until you understand the simpler case. The start of it is evidence that
haven't yet understood the simple case.

Your simple case doesn't address any of the issues. All it does
is create extra work in the procedure with no usefulness.

My simple case solves a problem that you said can't be solved. You said
it was imposible. It is not.

The problem
is that you couldn't see how to make the checksum correct when the file
that contained the checksum had to be included in the checksum.

Since the contents of the directory file will always change (checksummed
file's checksum is the thing that will never be a constant),
there will never be an accurate directory of the tape. However,
no customer's system needed to use the directory-of-the-tape file's
checksum to verify their restores.

This is wrong in two way. The checksum can in fact be put in place after
all the data has been saved.

You can't edit a tape. That would open such a can of Murphy's
worms, even if it were possible.

This would be a very strange drive if you really couldn't. But if you
know the names of the files to be put onto the tape, it is obvious that
you don't need to do it. If you don't know the names before hand, you
can't write a file containing those names so your suggested problem is
meaningless if the editing can't be done.

The reason tapes have an IRG (Inter Record Gap) is to allow the data on
the tape to be edited. You may decide not to do this but the drives knew
how.

The contents of the directory on the tape
doesn't change once the tape is created and is ready to ship.

A tape is not a directory medium. The file I am talking about
is part of the save set.

This file lists the names of the files on the tape. This is a
"directory". It is also sometimes called a manifest.

snip

That is not how we used checksums when packaging our materials.
The program our customers used to get a checksum had to match
the program we used to get the checksum we reported.

There is absolutely nothing in what I suggested that changes this. I will
suggest you go back over the subject again.

I don't have to; my methods worked and provided enough data
for sanity checks on both ends of the distribution system.

You said the checksum was published as wrong and that doing it right was
not posible. I worry about your customers.

--
--
kensmith@rahul.net forging knowledge

 

[Ken Smith]

In article <esp193$8qk_002@s1016.apx1.sbo.ma.dialup.rcn.com>,
<jmfbahciv@aol.com> wrote:

In article <esou80$8qk_001@s1016.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com wrote:
In article <esml4r$bj2$3@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
In article <esmalk$8qk_001@s1012.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In article <esjvn9$1a4$4@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
[....]
If you know what you intend to write onto the tape, figure out what the
checksum will be and then write the tape as you intend there is no extra
effort needed.

That does not give you a checksummed directory of the physical
tape you just made. All the handwaving and blustering you
are doing still does not satisfy the requirement.

Yes it does. Imagine it step by step.

(1)
You calculate the checksum of what you intend to put on the tape.

(2)
You put exactly what you intend onto the tape

(3)
You calculate the checksum of what you have put on the tape.

The checksum of the contents of the tape is not interesting.
That is a summary and doesn't help. A bit by bit verify
is done instead of your checksum summary.

The record of the checksums of each file on the tape is
the needed information. That itemized record is put into
a file which is the first file on the tape.

Let me try to explain using different lingo.

The first file on the tape, TAPE.DIR, is the invoice of the
distribution and contains a list of each item on the tape,
including that item's checksum.

..... and it includes its own checksum. This checksum can be made to be
correct by the method I suggested.

--
--
kensmith@rahul.net forging knowledge

 

[MassiveProng]

On Thu, 08 Mar 07 11:48:40 GMT, jmfbahciv@aol.com Gave us:

As I said above, our OS philosophy was to provide multiple pathways.
Multiple pathways...do you understand what that means? So why
are you demeaning the OS philosophy with an argument about networks?

Networking is a MAJOR part of a modern OS, dingledorf.

Ever seen a VME chassis stuffed with SMBs and fiber channel, and
ethernet net cards?

Or do you even know what an SMB is, much less fiber channel?
Would you have to look up what "FDDI" means?

Oh, that's right... you are still stuck in RS-232 mindset.

Do you have ANY USB devices? DO you even own an ethernet patch
cable or have a machine with an ethernet port on it?

 

[MassiveProng]

On Thu, 08 Mar 07 11:54:26 GMT, jmfbahciv@aol.com Gave us:

Is this because disk capacities are larger than most needs? With
the habits of downloading music and videos, etc. won't there be
another capacity problem fairly soon?

TeraByte drives are looming on the horizon as we speak.

And those are in 2.5" form factor.

Keep up much?

 

[MassiveProng]

On Thu, 08 Mar 2007 08:10:30 -0600, "nonsense@unsettled.com"
<nonsense@unsettled.com> Gave us:

jmfbahciv@aol.com wrote:
In article <vsnuu2587pd2ap5r5ibut3qfbueoorvfkb@4ax.com>,
MassiveProng <MassiveProng@thebarattheendoftheuniverse.org> wrote:

On Wed, 07 Mar 07 13:33:40 GMT, jmfbahciv@aol.com Gave us:


In article <f5etu2huta97pm9kqgu8d2g4tehvemr00h@4ax.com>,
MassiveProng <MassiveProng@thebarattheendoftheuniverse.org> wrote:

On Wed, 07 Mar 07 12:33:51 GMT, jmfbahciv@aol.com Gave us:


Our OS philosophy used all available pathways and never mothball
any of them. It is still a computer system truth that says
"Use or lose it." This aspect of gear sure can make one
superstitious.


We are approaching reliable, secure 10Gb/second networks now... where
have you been?

Now I suggest that you count the pathways and the number of "nodes"
required to keep the appearance of extreme capacities and
infallibility.


Hahahaha! We are running servers that are accessed by the pentagon
on a daily basis. 100% secure, IP encrypted in hardware, and NOBODY
but the recipient gets ANY useable data, as well as giving up there
locale, resulting in them getting busted.

Try again.


What the fuck do you think I've been talking about?

Alzheimerish blather.


Single pathways
cannot be used in network (that's why it has the root net in it).
The same thing is true with computer systems.

EVERYTHING is becoming networked. Haven't you even heard of
"network attached storage" yet? No computer there. Just plain old
access for those given it. None for those that are NOT given it.


As I said above, our OS philosophy was to provide multiple pathways.
Multiple pathways...do you understand what that means? So why
are you demeaning the OS philosophy with an argument about networks?


Similar to you and your capacity to learn about all of this. More
and more I simply find you as Peter Gabriel said...

"You're not one of us"


I am very glad to not be in your category.

Double!

It's true. You're not one of us... either.

 

[nonsense@unsettled.com]

MassiveProng wrote:

On Thu, 08 Mar 2007 08:10:30 -0600, "nonsense@unsettled.com"
nonsense@unsettled.com> Gave us:


jmfbahciv@aol.com wrote:

In article <vsnuu2587pd2ap5r5ibut3qfbueoorvfkb@4ax.com>,
MassiveProng <MassiveProng@thebarattheendoftheuniverse.org> wrote:


On Wed, 07 Mar 07 13:33:40 GMT, jmfbahciv@aol.com Gave us:



In article <f5etu2huta97pm9kqgu8d2g4tehvemr00h@4ax.com>,
MassiveProng <MassiveProng@thebarattheendoftheuniverse.org> wrote:


On Wed, 07 Mar 07 12:33:51 GMT, jmfbahciv@aol.com Gave us:



Our OS philosophy used all available pathways and never mothball
any of them. It is still a computer system truth that says
"Use or lose it." This aspect of gear sure can make one
superstitious.


We are approaching reliable, secure 10Gb/second networks now... where
have you been?

Now I suggest that you count the pathways and the number of "nodes"
required to keep the appearance of extreme capacities and
infallibility.


Hahahaha! We are running servers that are accessed by the pentagon
on a daily basis. 100% secure, IP encrypted in hardware, and NOBODY
but the recipient gets ANY useable data, as well as giving up there
locale, resulting in them getting busted.

Try again.



What the fuck do you think I've been talking about?

Alzheimerish blather.



Single pathways
cannot be used in network (that's why it has the root net in it).
The same thing is true with computer systems.

EVERYTHING is becoming networked. Haven't you even heard of
"network attached storage" yet? No computer there. Just plain old
access for those given it. None for those that are NOT given it.


As I said above, our OS philosophy was to provide multiple pathways.
Multiple pathways...do you understand what that means? So why
are you demeaning the OS philosophy with an argument about networks?



Similar to you and your capacity to learn about all of this. More
and more I simply find you as Peter Gabriel said...

"You're not one of us"


I am very glad to not be in your category.

Double!



It's true. You're not one of us... either.

Damn proud of it too!

 

[krw]

In article <4e5ee$45f0ba3c$4fe71c7$4989@DIALUPUSA.NET>,
nonsense@unsettled.com says...

MassiveProng wrote:

On Thu, 08 Mar 2007 08:10:30 -0600, "nonsense@unsettled.com"
nonsense@unsettled.com> Gave us:


jmfbahciv@aol.com wrote:

In article <vsnuu2587pd2ap5r5ibut3qfbueoorvfkb@4ax.com>,
MassiveProng <MassiveProng@thebarattheendoftheuniverse.org> wrote:


On Wed, 07 Mar 07 13:33:40 GMT, jmfbahciv@aol.com Gave us:



In article <f5etu2huta97pm9kqgu8d2g4tehvemr00h@4ax.com>,
MassiveProng <MassiveProng@thebarattheendoftheuniverse.org> wrote:


On Wed, 07 Mar 07 12:33:51 GMT, jmfbahciv@aol.com Gave us:



Our OS philosophy used all available pathways and never mothball
any of them. It is still a computer system truth that says
"Use or lose it." This aspect of gear sure can make one
superstitious.


We are approaching reliable, secure 10Gb/second networks now... where
have you been?

Now I suggest that you count the pathways and the number of "nodes"
required to keep the appearance of extreme capacities and
infallibility.


Hahahaha! We are running servers that are accessed by the pentagon
on a daily basis. 100% secure, IP encrypted in hardware, and NOBODY
but the recipient gets ANY useable data, as well as giving up there
locale, resulting in them getting busted.

Try again.



What the fuck do you think I've been talking about?

Alzheimerish blather.



Single pathways
cannot be used in network (that's why it has the root net in it).
The same thing is true with computer systems.

EVERYTHING is becoming networked. Haven't you even heard of
"network attached storage" yet? No computer there. Just plain old
access for those given it. None for those that are NOT given it.


As I said above, our OS philosophy was to provide multiple pathways.
Multiple pathways...do you understand what that means? So why
are you demeaning the OS philosophy with an argument about networks?



Similar to you and your capacity to learn about all of this. More
and more I simply find you as Peter Gabriel said...

"You're not one of us"


I am very glad to not be in your category.

Double!



It's true. You're not one of us... either.

Can't even put a sentence together, eh Dimbulb? "Us" is not
singular.

Damn proud of it too!

Wouldn't have it any other way!

--
Keith

 

[nonsense@unsettled.com]

krw wrote:

In article <4e5ee$45f0ba3c$4fe71c7$4989@DIALUPUSA.NET>,
nonsense@unsettled.com says...

MassiveProng wrote:


On Thu, 08 Mar 2007 08:10:30 -0600, "nonsense@unsettled.com"
nonsense@unsettled.com> Gave us:



jmfbahciv@aol.com wrote:


In article <vsnuu2587pd2ap5r5ibut3qfbueoorvfkb@4ax.com>,
MassiveProng <MassiveProng@thebarattheendoftheuniverse.org> wrote:



On Wed, 07 Mar 07 13:33:40 GMT, jmfbahciv@aol.com Gave us:




In article <f5etu2huta97pm9kqgu8d2g4tehvemr00h@4ax.com>,
MassiveProng <MassiveProng@thebarattheendoftheuniverse.org> wrote:



On Wed, 07 Mar 07 12:33:51 GMT, jmfbahciv@aol.com Gave us:




Our OS philosophy used all available pathways and never mothball
any of them. It is still a computer system truth that says
"Use or lose it." This aspect of gear sure can make one
superstitious.


We are approaching reliable, secure 10Gb/second networks now... where
have you been?

Now I suggest that you count the pathways and the number of "nodes"
required to keep the appearance of extreme capacities and
infallibility.


Hahahaha! We are running servers that are accessed by the pentagon
on a daily basis. 100% secure, IP encrypted in hardware, and NOBODY
but the recipient gets ANY useable data, as well as giving up there
locale, resulting in them getting busted.

Try again.




What the fuck do you think I've been talking about?

Alzheimerish blather.




Single pathways
cannot be used in network (that's why it has the root net in it).
The same thing is true with computer systems.

EVERYTHING is becoming networked. Haven't you even heard of
"network attached storage" yet? No computer there. Just plain old
access for those given it. None for those that are NOT given it.


As I said above, our OS philosophy was to provide multiple pathways.
Multiple pathways...do you understand what that means? So why
are you demeaning the OS philosophy with an argument about networks?




Similar to you and your capacity to learn about all of this. More
and more I simply find you as Peter Gabriel said...

"You're not one of us"


I am very glad to not be in your category.

Double!



It's true. You're not one of us... either.


Can't even put a sentence together, eh Dimbulb? "Us" is not
singular.

What would you expect? He's a ProngHead.

Damn proud of it too!


Wouldn't have it any other way!

 

[MassiveProng]

On Thu, 8 Mar 2007 20:56:15 -0500, krw <krw@att.bizzzz> Gave us:

Can't even put a sentence together, eh Dimbulb? "Us" is not
singular.

It is a song title, retard boy.

Try to keep up, dumbfucktard.

 

In article <2v91v2pjpp3qdcn8mv70t5rk21t7g1oeem@4ax.com>,
MassiveProng <MassiveProng@thebarattheendoftheuniverse.org> wrote:

On Thu, 08 Mar 07 11:48:40 GMT, jmfbahciv@aol.com Gave us:

As I said above, our OS philosophy was to provide multiple pathways.
Multiple pathways...do you understand what that means? So why
are you demeaning the OS philosophy with an argument about networks?


Networking is a MAJOR part of a modern OS, dingledorf.

It shouldn't be. Routing should be kept off user machines.

Ever seen a VME chassis stuffed with SMBs and fiber channel, and
ethernet net cards?

Or do you even know what an SMB is, much less fiber channel?
Would you have to look up what "FDDI" means?

Oh, that's right... you are still stuck in RS-232 mindset.

That doesn't look familiar.

Do you have ANY USB devices? DO you even own an ethernet patch
cable or have a machine with an ethernet port on it?

You might try to read the listings of ANF-10.

/BAH

 

In article <esp7m9$hni$1@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:

In article <esothi$8ss_002@s1016.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In article <esmj7c$bj2$1@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
In article <esm9f6$8ss_002@s1012.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In article <esju3h$1a4$2@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
[.....]
Having multiple disks connected to a single disk drive controller
electronics gives absolutely no advantage and a few disadvantages.

I know that one can have multiple structures on one drive. Has
the need of having one structure on multiple drives gone away?

No, it hasn't gone away completely. There is a lot less need for logical
volumes to span multiple disks today.

Is this because disk capacities are larger than most needs? With
the habits of downloading music and videos, etc. won't there be
another capacity problem fairly soon?

This may happen some time in the slightly distant future. Modern OSes
allow what the user sees as a directory to be a different disk drive.

MS-DOS did this with the "join" command. When Windows 95 was brought out,
the "join" command went away. On Linux and OS-X, the command is "mount".

It isn't much of a stretch of the imagination to see some OS automatically
assigning an entier drive to things like videos.

These used to be called private packs. The concept has existed since
the 60s.

It is still done in cases where
something will be truly huge. It is also done in the name of speed where
the data must be moved on and off the disk at speeds that are impractical
for hardware.

The last reason was valid in the olden days. JMF visited an insurance
company site and saw a disk farm of [can't remember the number]
hundreds, I think. He was awed because it was all one file.
There was no way our products could deal with
that kind of a data base. IBM knew how to handle those.

IBM's design of the logical structure was very good from this point of
view. The Volume Table Of Contents told you where the Data Extent Blocks
were. The DEBs formed a chain. Extending this chain to include which
physical drive the next things were on wouldn't be hard to do.

IBM evolved based on data base usage. We didn't. Our trade offs
were guided by delivering computing to people who did science and
engineering.

/BAH

 

In article <n7a1v29gv894uc76qtgn35j56hl2fflu5e@4ax.com>,
MassiveProng <MassiveProng@thebarattheendoftheuniverse.org> wrote:

On Thu, 08 Mar 07 11:54:26 GMT, jmfbahciv@aol.com Gave us:

Is this because disk capacities are larger than most needs? With
the habits of downloading music and videos, etc. won't there be
another capacity problem fairly soon?


TeraByte drives are looming on the horizon as we speak.

And those are in 2.5" form factor.

Keep up much?

And will they survive being set next to TV or a vacuum cleaner?

/BAH

 

In article <esp8c8$hni$3@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:

In article <esp193$8qk_002@s1016.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In article <esou80$8qk_001@s1016.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com wrote:
In article <esml4r$bj2$3@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
In article <esmalk$8qk_001@s1012.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In article <esjvn9$1a4$4@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
[....]
If you know what you intend to write onto the tape, figure out what the
checksum will be and then write the tape as you intend there is no extra
effort needed.

That does not give you a checksummed directory of the physical
tape you just made. All the handwaving and blustering you
are doing still does not satisfy the requirement.

Yes it does. Imagine it step by step.

(1)
You calculate the checksum of what you intend to put on the tape.

(2)
You put exactly what you intend onto the tape

(3)
You calculate the checksum of what you have put on the tape.

The checksum of the contents of the tape is not interesting.
That is a summary and doesn't help. A bit by bit verify
is done instead of your checksum summary.

The record of the checksums of each file on the tape is
the needed information. That itemized record is put into
a file which is the first file on the tape.

Let me try to explain using different lingo.

The first file on the tape, TAPE.DIR, is the invoice of the
distribution and contains a list of each item on the tape,
including that item's checksum.

..... and it includes its own checksum. This checksum can be made to be
correct by the method I suggested.

Only by fakery. To fake it would open up many opportunities
for Murphy's Law to strike. It was more important to have
a physical list of what we put on the tape than to have
the checksum of TAPE.DIR be correct and as the first file
on the tape. Your approach would open the TAPE.DIR for writing.
This was an unacceptable risk.

/BAH

 

In article <esp89d$hni$2@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:

In article <esou80$8qk_001@s1016.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In article <esml4r$bj2$3@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
In article <esmalk$8qk_001@s1012.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In article <esjvn9$1a4$4@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
[....]
If you know what you intend to write onto the tape, figure out what the
checksum will be and then write the tape as you intend there is no extra
effort needed.

That does not give you a checksummed directory of the physical
tape you just made. All the handwaving and blustering you
are doing still does not satisfy the requirement.

Yes it does. Imagine it step by step.

(1)
You calculate the checksum of what you intend to put on the tape.

(2)
You put exactly what you intend onto the tape

(3)
You calculate the checksum of what you have put on the tape.

The checksum of the contents of the tape is not interesting.
That is a summary and doesn't help. A bit by bit verify
is done instead of your checksum summary.

Suddenly you are changing the subject.

I am still talking about the same procedure and constraints that
I had to solve.

The question is: would the
checksum before and after match? The answer is yes, so the method works.

No. It cannot match. Your method provides a list of we intended
to put on the tape. My method describes what was really put on the
tape because the TAPE.DIR file was generated by examining the tape.

Anybody who has done any grocery shopping would know the difference
between the two. Just because dog food is on your shopping list
never guarantees that dog food will be in your car when you get home.
The only listing that shows you were successful in putting
dog food in the shopping cart is the cash register receipt.

If the checksum at step (3) doesn't match the checksum at step (1), you
haven't written what you intended onto the tape. I am really surprised
that you can't see this.

I'm at a loss to try to explain what we were doing. YOu seem
to be determined not to understand.

You were making a mistake, is what you were doing.

You just gotta love this illogic. Your method is not a solution
and creates havoc. It can also be extremely expensive if it
results in customers sending in problem reports when they could
have done preliminary checking at the time they first examine
the tape.

You still are not getting the fact that the directory of the tape
had to be on the tape--not a directory of the files on disk
soon to be copied to the tape.

Why the devil can't you understand this!!!!!! Go back and look at what I
wrote above.

Your solution does not provide a list of all files on the tape.

Yes it does. I have shown how you can make the checksum on this file
correct. This file that contains the list is the very file we have been
talking about.

It is a faked listing. It was not generated by looking at the
files that were really put on the tape. Not only did my method
provide an invoice of what got packed, my method kept us from
making blank or incomplete masters.

I have told you how to do it when you know what will end up
on the tape. You were talking about tapes that will contain code to be
sent to others. If you don't know what that tape will contain, you are
not ready to make it.

I also pointed out but did not cover that there is a method for tapes
where the contents are not known before hand. The fact that you haven't
been able to understand the simple case makes it nonuseful to get into
that subject right now.


The issue of what to do if you can't be sure about how much will really
fit onto the tape is worthy of further discussion if you want to know how
to solve that one.

I know more about how to fit stuff on small tapes than you will ever
encounter. Tape fitting still has nothing to do with the requirement
of a directory of the tape prepended to the files we distributed
on that tape.

The tail end of this is wrong in a way that I won't try to explain to you
until you understand the simpler case. The start of it is evidence that
haven't yet understood the simple case.

Your simple case doesn't address any of the issues. All it does
is create extra work in the procedure with no usefulness.

My simple case solves a problem that you said can't be solved. You said
it was imposible. It is not.

It is impossible. Everytime you take a new directory of the tape,
the checksum of TAPE.DIR changes. If you do another save with the
new TAPE.DIR, another directory of the physical tape will produce
a different checksum of TAPE.DIR.

The problem
is that you couldn't see how to make the checksum correct when the file
that contained the checksum had to be included in the checksum.

Since the contents of the directory file will always change (checksummed
file's checksum is the thing that will never be a constant),
there will never be an accurate directory of the tape. However,
no customer's system needed to use the directory-of-the-tape file's
checksum to verify their restores.

This is wrong in two way. The checksum can in fact be put in place after
all the data has been saved.

You can't edit a tape. That would open such a can of Murphy's
worms, even if it were possible.

This would be a very strange drive if you really couldn't.

You have never been able to edit magtape. You need two
drives to do an edit.

But if you
know the names of the files to be put onto the tape, it is obvious that
you don't need to do it. If you don't know the names before hand, you
can't write a file containing those names so your suggested problem is
meaningless if the editing can't be done.

The reason tapes have an IRG (Inter Record Gap) is to allow the data on
the tape to be edited. You may decide not to do this but the drives knew
how.

Now that's a new one.

The contents of the directory on the tape
doesn't change once the tape is created and is ready to ship.

A tape is not a directory medium. The file I am talking about
is part of the save set.

This file lists the names of the files on the tape.

You method does not list the files on the tape. Your method
lists the files you intend to put on the tape. These are
two very different lists.

This is a
"directory". It is also sometimes called a manifest.

That is not how we used checksums when packaging our materials.
The program our customers used to get a checksum had to match
the program we used to get the checksum we reported.

There is absolutely nothing in what I suggested that changes this. I will
suggest you go back over the subject again.

I don't have to; my methods worked and provided enough data
for sanity checks on both ends of the distribution system.

You said the checksum was published as wrong

Only the checksum of the file TAPE.DIR was incorrect. The first
save of the tape had the checksum as 0.

and that doing it right was
not posible. I worry about your customers.

You don't have to worry. My methods solved a couple problems with
two swell foops and prevented waste of time and money of both
us and our customers.

/BAH