Jihad needs scientists

[krw]

In article <et68m3$t53$4@blue.rahul.net>, kensmith@green.rahul.net
says...

In article <et5vdg$8qk_002@s887.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In article <et3o1m$rad$2@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
[....]
There need not be any increase in the risk. Its all a matter of starting
with a reasonable OS and not adding buffer over runs.

There will always be buffer overruns.

Only in badly written software using languages without run time checking
does it happen. We now have more than enough CPU speed that buffer
overruns should be a thing of the past.

What percentage of software over the last decade has been written in
C/C++? How much in, say, Ada?

The risk of a single system
house site configuration is the lack of redundancy. That is
what makes it dangerous. The danger is not just viral infections
but with users typing at a system which also controls vital
functions within the house.

I would never network my PC to my pacemaker.

I wouldn't connect mine to my toaster. Toast is simply too important
to trust to a PeeCee and M$ (can't drink coffee anymore, so toast
will have to do here).

That said, you are assuming that the user runs as root/superuser. I very
rarely ever do on my home system. I do it a little more often on the work
system but that is because I need to directly fiddle a few hardware things
from time to time.

M$ almost insists that users run as admin. Unix and variants are the
opposite. What's the relative population of each group?

--
Keith

 

[Ken Smith]

In article <MPG.2060b389becb9ca598a106@news.individual.net>,
krw <krw@att.bizzzz> wrote:

In article <et68m3$t53$4@blue.rahul.net>, kensmith@green.rahul.net
says...
In article <et5vdg$8qk_002@s887.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In article <et3o1m$rad$2@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
[....]
There need not be any increase in the risk. Its all a matter of starting
with a reasonable OS and not adding buffer over runs.

There will always be buffer overruns.

Only in badly written software using languages without run time checking
does it happen. We now have more than enough CPU speed that buffer
overruns should be a thing of the past.

What percentage of software over the last decade has been written in
C/C++? How much in, say, Ada?

How mush is "badly written"? Most software is truly horrid. I still have
a hope that this may change. It may take the deaths of a hundred cute
puppies live on TV, due to a bug, to get the point.

I would never network my PC to my pacemaker.

I wouldn't connect mine to my toaster. Toast is simply too important

Yes, and with real peanut butter, it is even better.

to trust to a PeeCee and M$ (can't drink coffee anymore, so toast
will have to do here).

I wouldn't trust M$ for anything.

That said, you are assuming that the user runs as root/superuser. I very
rarely ever do on my home system. I do it a little more often on the work
system but that is because I need to directly fiddle a few hardware things
from time to time.

M$ almost insists that users run as admin. Unix and variants are the
opposite. What's the relative population of each group?

With any luck, Vista will be the death of M$ and every home user will
switch to Apples. Apple should get the customers just for those great
ads.
--
--
kensmith@rahul.net forging knowledge

 

[Ken Smith]

In article <b33aa$45f6d225$4fe7292$20427@DIALUPUSA.NET>,
nonsense@unsettled.com <nonsense@unsettled.com> wrote:

Ken Smith wrote:

In article <et5v7k$8qk_001@s887.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
[....]

Did you write a TAPE.DIR onto the tape after the tape had already been
written?

No. One of my requirements was that the file be the first in
the saveset.


In other words, you created it based on what you intended to write to the
tape not what you actually wrote. This contradicts what you said earlier.

It doesn't matter because the suggested method still works. The checksum
could still have been correct.

The operative word is "could." It can never be "what was read from
the tape." Your entire argument on this matter has been silly. It
is an elementary problem in recursion.

Yes, it can be what was read from the tape. I explained elsewhere exactly
how you can make the first file on the tape be based on the contents of
the tape after it has been written. Tape drives can write to the start of
a tape without trashing the rest of the contents of the tape. The
operation is refered to as an "edit" write. It only requires that the
tape already contain a block of the same size. It has been done for
years.

There is no problem in recursion. There is no problem in making the
checksum correct. You seem to have missed the post where I filled you in
on how exactly the checksum of a file can be stored in the text of file
and be valid. Here is a hint:

checksum("0000ZZZZ") == checksum("1111YYYY")

You should be able to take it from there. When you figure it out try to
get BAH to understand.





--
--
kensmith@rahul.net forging knowledge

 

In article <et6c0m$t53$7@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:

In article <et5un4$8ss_002@s887.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In article <et3pbr$rad$7@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
In article <et39hp$8ss_003@s948.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In article <et1957$ki3$2@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
In article <et0oi0$8qk_003@s776.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In article <esuqfn$ds3$5@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
[....]
No, you are making the same mistake over and over. As I stated before,
if
you know what you are going to put into TAPE.DIR, you can make its
checksum correct. No editing of a magnetic tape was needed by the
method.

Then that TAPE.DIR was not made by taking a directory of the
tape. That was not the purpose of the file. If I had to do
it the way you suggested, I wouldn't put the file on the tape
since it would be a waste of tape space.

So now you are suddenly changing your story and saying that editing of
the
tape was done.

There was no tape editing done.

In that case. The tape had to be written with the TAPE.DIR in place and
correct on the first pass.

This is the point. It will never be "correct" because the file
contains a checksummed listing of itself.

snip

Do the exercise. Then you will see what I'm talking about.

Bin thar, dun that, got t-shirt, wore out t-shirt.

I've done it. The idea wasn't new when I did. You just haven't
understood a very simple concept.

I understood you just fine. You didn't put a directory of the
tape onto the tape.

/BAH

 

In article <et7ljd$bq1$5@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:

In article <b33aa$45f6d225$4fe7292$20427@DIALUPUSA.NET>,
nonsense@unsettled.com <nonsense@unsettled.com> wrote:
Ken Smith wrote:

In article <et5v7k$8qk_001@s887.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
[....]

Did you write a TAPE.DIR onto the tape after the tape had already been
written?

No. One of my requirements was that the file be the first in
the saveset.


In other words, you created it based on what you intended to write to the
tape not what you actually wrote. This contradicts what you said earlier.

It doesn't matter because the suggested method still works. The checksum
could still have been correct.

The operative word is "could." It can never be "what was read from
the tape." Your entire argument on this matter has been silly. It
is an elementary problem in recursion.

Yes, it can be what was read from the tape. I explained elsewhere exactly
how you can make the first file on the tape be based on the contents of
the tape after it has been written. Tape drives can write to the start of
a tape without trashing the rest of the contents of the tape.

It will trash the rest of the tape. We shipped the files within
savesets.

The
operation is refered to as an "edit" write. It only requires that the
tape already contain a block of the same size. It has been done for
years.

But your edit write would not include the directory of the tape
after you wrote it.

There is no problem in recursion. There is no problem in making the
checksum correct. You seem to have missed the post where I filled you in
on how exactly the checksum of a file can be stored in the text of file
and be valid. Here is a hint:

checksum("0000ZZZZ") == checksum("1111YYYY")

You should be able to take it from there. When you figure it out try to
get BAH to understand.

/BAH understands your method just fine. First of all the editing
method would have trashed the first saveset. Second of all,
the file would not have been a directory of the tape after you
wrote the file to the tape.

/BAH

 

In article <et68m3$t53$4@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:

In article <et5vdg$8qk_002@s887.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In article <et3o1m$rad$2@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
[....]
There need not be any increase in the risk. Its all a matter of starting
with a reasonable OS and not adding buffer over runs.

There will always be buffer overruns.

Only in badly written software using languages without run time checking
does it happen. We now have more than enough CPU speed that buffer
overruns should be a thing of the past.

You are ignoring hardware glitches, among other things. There will
always be buffer overruns. There should not be OSes who implement
them as a feature.

The risk of a single system
house site configuration is the lack of redundancy. That is
what makes it dangerous. The danger is not just viral infections
but with users typing at a system which also controls vital
functions within the house.

I would never network my PC to my pacemaker.

But that is how the computing biz is going. I'm also thinking of
heating, security, and cooking.

That said, you are assuming that the user runs as root/superuser.

I am assuming that, if it is possilbe to run privileged, there
will be a security gap. Allowing the possibility should not
be done by a system which cannot crash without serious side effects.

I very
rarely ever do on my home system. I do it a little more often on the work
system but that is because I need to directly fiddle a few hardware things
from time to time.

Then your systems aren't secure from all human hands.

/BAH

 

In article <87slc9jje1.fsf@nonospaz.fatphil.org>,
Phil Carmody <thefatphil_demunged@yahoo.co.uk> wrote:

jmfbahciv@aol.com writes:
In article <et3o1m$rad$2@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
There need not be any increase in the risk. Its all a matter of starting
with a reasonable OS and not adding buffer over runs.

There will always be buffer overruns.

Don't judge all programmers based on your own inadequacy as one.

I'm stating this fact based on experience working with bit gods
and hardware that had the proper tweaks to help prevent
these problems.

I never wrote a buffer overrun. My bug specialty was off by
ones on loop counts.

/BAH

 

In article <45F6AAD4.8DD34AFE@hotmail.com>,
Eeyore <rabbitsfriendsandrelations@hotmail.com> wrote:

Ken Smith wrote:

Dan Bloomquist wrote:
MassiveProng wrote:

Note that TTL was the requisite defining element.

No, it is, 'Jihad needs scientists'

The thread has drifted. The Jihad isn't getting any scientists from
around here so we have gone onto more important issues like why the
republicans hate America so much, whether Dick Cheney is Satan or merely
his agent and whether GWB should be hung or given life in prison.

You are correct but the thread title hasn't been changed hence any reference
to
same must surely be 'on topic'.

I'm still on topic. I don't see how any president has been
able to get a general population to understand even simple
concepts. The drift about getting a directory of a tape onto
the tape describes how people skip the main point and try
to make the "problem" something completely different.

There doesn't seem to be any way to correct the skip.

/BAH

 

[nonsense@unsettled.com]

jmfbahciv@aol.com wrote:

In article <et7ljd$bq1$5@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:

In article <b33aa$45f6d225$4fe7292$20427@DIALUPUSA.NET>,
nonsense@unsettled.com <nonsense@unsettled.com> wrote:

Ken Smith wrote:


In article <et5v7k$8qk_001@s887.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
[....]


Did you write a TAPE.DIR onto the tape after the tape had already been
written?

No. One of my requirements was that the file be the first in
the saveset.


In other words, you created it based on what you intended to write to the
tape not what you actually wrote. This contradicts what you said earlier.

It doesn't matter because the suggested method still works. The checksum
could still have been correct.

The operative word is "could." It can never be "what was read from
the tape." Your entire argument on this matter has been silly. It
is an elementary problem in recursion.

Yes, it can be what was read from the tape. I explained elsewhere exactly
how you can make the first file on the tape be based on the contents of
the tape after it has been written. Tape drives can write to the start of
a tape without trashing the rest of the contents of the tape.


It will trash the rest of the tape. We shipped the files within
savesets.


The
operation is refered to as an "edit" write. It only requires that the
tape already contain a block of the same size. It has been done for
years.


But your edit write would not include the directory of the tape
after you wrote it.

There is no problem in recursion. There is no problem in making the
checksum correct. You seem to have missed the post where I filled you in
on how exactly the checksum of a file can be stored in the text of file
and be valid. Here is a hint:

checksum("0000ZZZZ") == checksum("1111YYYY")

You should be able to take it from there. When you figure it out try to
get BAH to understand.


/BAH understands your method just fine. First of all the editing
method would have trashed the first saveset. Second of all,
the file would not have been a directory of the tape after you
wrote the file to the tape.

I almost hate to say this, but I think that understanding
the problem is beyond him.

 

[Martin Brown]

On Mar 13, 10:34 am, jmfbah...@aol.com wrote:

In article <et3pbr$ra...@blue.rahul.net>,
kensm...@green.rahul.net (Ken Smith) wrote:

In that case. Thetapehad to be written with theTAPE.DIR in place and
correct on the first pass.

This is the point. It will never be "correct" because the file
contains a checksummed listing of itself.

snip

Do the exercise. Then you will see what I'm talking about.

You really are determined to parade your ignorance. File checksums are
trivial to make internally consistent.

At the simplest conceptual level you could define all files to have
checksum=0 and add some fluff to the end of each one to make it so. In
this case you only need to adjust the TAPE.DIR and since you know the
effect of changing the bytes in the checksum representation on the
checksum it is relatively easy to program a self consistent solution.

CRC offers a much higher chance of detecting tape bitrot. But it is a
lot harder to tweak a file to contain its own CRC (but still not
impossible). Matching an MD5 is beyond present computational power.

But for a simple checksum it can be done trivially by writing the
master TAPE.DIR file claiming any arbitrary checksum you like and then
adjusting the final file with a chunk of your favourite nonsense rhyme
or saying of the day until the statement "this files checksum = 1234"
is true. Checksum is invariant under permutations of the characters in
the file so you don't have to work very hard to do it by brute force.
Even if as seems likely the TAPE.DIR contains both length and checksum
then self consistent solutions can be found by SMOP.

Regards,
Martin Brown

 

In article <1173870480.508596.143930@n76g2000hsh.googlegroups.com>,
"Martin Brown" <|||newspam|||@nezumi.demon.co.uk> wrote:

On Mar 13, 10:34 am, jmfbah...@aol.com wrote:
In article <et3pbr$ra...@blue.rahul.net>,
kensm...@green.rahul.net (Ken Smith) wrote:

In that case. Thetapehad to be written with theTAPE.DIR in place and
correct on the first pass.

This is the point. It will never be "correct" because the file
contains a checksummed listing of itself.

snip

Do the exercise. Then you will see what I'm talking about.

You really are determined to parade your ignorance. File checksums are
trivial to make internally consistent.

At the simplest conceptual level you could define all files to have
checksum=0 and add some fluff to the end of each one to make it so. In
this case you only need to adjust the TAPE.DIR and since you know the
effect of changing the bytes in the checksum representation on the
checksum it is relatively easy to program a self consistent solution.

CRC offers a much higher chance of detecting tape bitrot. But it is a
lot harder to tweak a file to contain its own CRC (but still not
impossible). Matching an MD5 is beyond present computational power.

But for a simple checksum it can be done trivially by writing the
master TAPE.DIR file claiming any arbitrary checksum you like and then
adjusting the final file

Now the file is no longer a directory of the tape. By modifying
the file on the tape, you have changed the tape. There is no
longer a directory of the tape on the tape.

with a chunk of your favourite nonsense rhyme
or saying of the day until the statement "this files checksum = 1234"
is true. Checksum is invariant under permutations of the characters in
the file so you don't have to work very hard to do it by brute force.
Even if as seems likely the TAPE.DIR contains both length and checksum
then self consistent solutions can be found by SMOP.

It isn't a goal to have the checksum of TAPE.DIR correct. It was
a mandatory goal to have a directory of the tape on the tape. The
tradeoff to accomplish this goal was to have the checksum of
the file TAPE.DIR not match the checksum of TAPE.DIR reported
in TAPE.DIR.

Query: Is the ability to think about this concept (Mr. unsettled
called it recursion) a rare ability?



/BAH


/BAH

 

In article <5a788$45f7cdfe$4fe707e$27037@DIALUPUSA.NET>,
"nonsense@unsettled.com" <nonsense@unsettled.com> wrote:

jmfbahciv@aol.com wrote:
In article <et7ljd$bq1$5@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:

In article <b33aa$45f6d225$4fe7292$20427@DIALUPUSA.NET>,
nonsense@unsettled.com <nonsense@unsettled.com> wrote:

Ken Smith wrote:


In article <et5v7k$8qk_001@s887.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
[....]


Did you write a TAPE.DIR onto the tape after the tape had already been
written?

No. One of my requirements was that the file be the first in
the saveset.


In other words, you created it based on what you intended to write to the
tape not what you actually wrote. This contradicts what you said
earlier.

It doesn't matter because the suggested method still works. The checksum
could still have been correct.

The operative word is "could." It can never be "what was read from
the tape." Your entire argument on this matter has been silly. It
is an elementary problem in recursion.

Yes, it can be what was read from the tape. I explained elsewhere exactly
how you can make the first file on the tape be based on the contents of
the tape after it has been written. Tape drives can write to the start of
a tape without trashing the rest of the contents of the tape.


It will trash the rest of the tape. We shipped the files within
savesets.


The
operation is refered to as an "edit" write. It only requires that the
tape already contain a block of the same size. It has been done for
years.


But your edit write would not include the directory of the tape
after you wrote it.

There is no problem in recursion. There is no problem in making the
checksum correct. You seem to have missed the post where I filled you in
on how exactly the checksum of a file can be stored in the text of file
and be valid. Here is a hint:

checksum("0000ZZZZ") == checksum("1111YYYY")

You should be able to take it from there. When you figure it out try to
get BAH to understand.


/BAH understands your method just fine. First of all the editing
method would have trashed the first saveset. Second of all,
the file would not have been a directory of the tape after you
wrote the file to the tape.

I almost hate to say this, but I think that understanding
the problem is beyond him.

Definitely. I'm studying the phenomena. I have encountered this
before but it was rare in my area. I don't think one can do
comm and OS development without being able to breathe recursion
and live to tell about it .

I'm beginning to wonder if this lack is a common trait.
Consider the original thread subject matter. Weren't a lot
of the problems due to not being able to think recursively?

/BAH

 

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

On Wed, 14 Mar 2007 05:27:07 -0600, "nonsense@unsettled.com"
nonsense@unsettled.com> Gave us:

jmfbahciv@aol.com wrote:
In article <et7ljd$bq1$5@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:

In article <b33aa$45f6d225$4fe7292$20427@DIALUPUSA.NET>,
nonsense@unsettled.com <nonsense@unsettled.com> wrote:

Ken Smith wrote:


In article <et5v7k$8qk_001@s887.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
[....]


Did you write a TAPE.DIR onto the tape after the tape had already been
written?

No. One of my requirements was that the file be the first in
the saveset.


In other words, you created it based on what you intended to write to
the
tape not what you actually wrote. This contradicts what you said
earlier.

It doesn't matter because the suggested method still works. The
checksum
could still have been correct.

The operative word is "could." It can never be "what was read from
the tape." Your entire argument on this matter has been silly. It
is an elementary problem in recursion.

Yes, it can be what was read from the tape. I explained elsewhere exactly
how you can make the first file on the tape be based on the contents of
the tape after it has been written. Tape drives can write to the start of
a tape without trashing the rest of the contents of the tape.


It will trash the rest of the tape. We shipped the files within
savesets.


The
operation is refered to as an "edit" write. It only requires that the
tape already contain a block of the same size. It has been done for
years.


But your edit write would not include the directory of the tape
after you wrote it.

There is no problem in recursion. There is no problem in making the
checksum correct. You seem to have missed the post where I filled you in
on how exactly the checksum of a file can be stored in the text of file
and be valid. Here is a hint:

checksum("0000ZZZZ") == checksum("1111YYYY")

You should be able to take it from there. When you figure it out try to
get BAH to understand.


/BAH understands your method just fine. First of all the editing
method would have trashed the first saveset. Second of all,
the file would not have been a directory of the tape after you
wrote the file to the tape.

I almost hate to say this, but I think that understanding
the problem is beyond him.


All you EVER make are whimpy little peanut gallery comments, and even
those are pretty sad. Do you ever make a post where you tell anyone
the right answer if they are so wrong? NO.

You are pathetic.

Mr. unsettled did write a summary of the behaviour and why it
can't be solved. He did it in 25 words or less. The magic
incantation is recursion.

/BAH

 

[MassiveProng]

On Wed, 14 Mar 07 10:20:42 GMT, jmfbahciv@aol.com Gave us:

In article <87slc9jje1.fsf@nonospaz.fatphil.org>,
Phil Carmody <thefatphil_demunged@yahoo.co.uk> wrote:
jmfbahciv@aol.com writes:
In article <et3o1m$rad$2@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
There need not be any increase in the risk. Its all a matter of starting
with a reasonable OS and not adding buffer over runs.

There will always be buffer overruns.

Don't judge all programmers based on your own inadequacy as one.

I'm stating this fact based on experience working with bit gods
and hardware that had the proper tweaks to help prevent
these problems.

I never wrote a buffer overrun. My bug specialty was off by
ones on loop counts.

You are locked in a recursive loop of being wrong all the time!

 

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

On Wed, 14 Mar 07 10:20:42 GMT, jmfbahciv@aol.com Gave us:

In article <87slc9jje1.fsf@nonospaz.fatphil.org>,
Phil Carmody <thefatphil_demunged@yahoo.co.uk> wrote:
jmfbahciv@aol.com writes:
In article <et3o1m$rad$2@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
There need not be any increase in the risk. Its all a matter of
starting
with a reasonable OS and not adding buffer over runs.

There will always be buffer overruns.

Don't judge all programmers based on your own inadequacy as one.

I'm stating this fact based on experience working with bit gods
and hardware that had the proper tweaks to help prevent
these problems.

I never wrote a buffer overrun. My bug specialty was off by
ones on loop counts.

You are locked in a recursive loop of being wrong all the time!

Thus, you are stating that you think I'm perfect?

I wish I were.

/BAH

 

[MassiveProng]

On Wed, 14 Mar 2007 05:27:07 -0600, "nonsense@unsettled.com"
<nonsense@unsettled.com> Gave us:

jmfbahciv@aol.com wrote:
In article <et7ljd$bq1$5@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:

In article <b33aa$45f6d225$4fe7292$20427@DIALUPUSA.NET>,
nonsense@unsettled.com <nonsense@unsettled.com> wrote:

Ken Smith wrote:


In article <et5v7k$8qk_001@s887.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
[....]


Did you write a TAPE.DIR onto the tape after the tape had already been
written?

No. One of my requirements was that the file be the first in
the saveset.


In other words, you created it based on what you intended to write to the
tape not what you actually wrote. This contradicts what you said earlier.

It doesn't matter because the suggested method still works. The checksum
could still have been correct.

The operative word is "could." It can never be "what was read from
the tape." Your entire argument on this matter has been silly. It
is an elementary problem in recursion.

Yes, it can be what was read from the tape. I explained elsewhere exactly
how you can make the first file on the tape be based on the contents of
the tape after it has been written. Tape drives can write to the start of
a tape without trashing the rest of the contents of the tape.


It will trash the rest of the tape. We shipped the files within
savesets.


The
operation is refered to as an "edit" write. It only requires that the
tape already contain a block of the same size. It has been done for
years.


But your edit write would not include the directory of the tape
after you wrote it.

There is no problem in recursion. There is no problem in making the
checksum correct. You seem to have missed the post where I filled you in
on how exactly the checksum of a file can be stored in the text of file
and be valid. Here is a hint:

checksum("0000ZZZZ") == checksum("1111YYYY")

You should be able to take it from there. When you figure it out try to
get BAH to understand.


/BAH understands your method just fine. First of all the editing
method would have trashed the first saveset. Second of all,
the file would not have been a directory of the tape after you
wrote the file to the tape.

I almost hate to say this, but I think that understanding
the problem is beyond him.

All you EVER make are whimpy little peanut gallery comments, and even
those are pretty sad. Do you ever make a post where you tell anyone
the right answer if they are so wrong? NO.

You are pathetic.

 

[MassiveProng]

On Wed, 14 Mar 07 11:54:56 GMT, jmfbahciv@aol.com Gave us:

In article <5a788$45f7cdfe$4fe707e$27037@DIALUPUSA.NET>,
"nonsense@unsettled.com" <nonsense@unsettled.com> wrote:
jmfbahciv@aol.com wrote:
In article <et7ljd$bq1$5@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:

In article <b33aa$45f6d225$4fe7292$20427@DIALUPUSA.NET>,
nonsense@unsettled.com <nonsense@unsettled.com> wrote:

Ken Smith wrote:


In article <et5v7k$8qk_001@s887.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
[....]


Did you write a TAPE.DIR onto the tape after the tape had already been
written?

No. One of my requirements was that the file be the first in
the saveset.


In other words, you created it based on what you intended to write to the
tape not what you actually wrote. This contradicts what you said
earlier.

It doesn't matter because the suggested method still works. The checksum
could still have been correct.

The operative word is "could." It can never be "what was read from
the tape." Your entire argument on this matter has been silly. It
is an elementary problem in recursion.

Yes, it can be what was read from the tape. I explained elsewhere exactly
how you can make the first file on the tape be based on the contents of
the tape after it has been written. Tape drives can write to the start of
a tape without trashing the rest of the contents of the tape.


It will trash the rest of the tape. We shipped the files within
savesets.


The
operation is refered to as an "edit" write. It only requires that the
tape already contain a block of the same size. It has been done for
years.


But your edit write would not include the directory of the tape
after you wrote it.

There is no problem in recursion. There is no problem in making the
checksum correct. You seem to have missed the post where I filled you in
on how exactly the checksum of a file can be stored in the text of file
and be valid. Here is a hint:

checksum("0000ZZZZ") == checksum("1111YYYY")

You should be able to take it from there. When you figure it out try to
get BAH to understand.


/BAH understands your method just fine. First of all the editing
method would have trashed the first saveset. Second of all,
the file would not have been a directory of the tape after you
wrote the file to the tape.

I almost hate to say this, but I think that understanding
the problem is beyond him.

Definitely. I'm studying the phenomena. I have encountered this
before but it was rare in my area. I don't think one can do
comm and OS development without being able to breathe recursion
and live to tell about it .

I'm beginning to wonder if this lack is a common trait.
Consider the original thread subject matter. Weren't a lot
of the problems due to not being able to think recursively?

You are BOTH recursively pathetic, lost, wrong, and bullheaded.

Also too old not to be hard wired wrong which means you will never
learn.

 

[Ken Smith]

In article <et8hie$8ss_001@s787.apx1.sbo.ma.dialup.rcn.com>,
<jmfbahciv@aol.com> wrote:

In article <et6c0m$t53$7@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
In article <et5un4$8ss_002@s887.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In article <et3pbr$rad$7@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
In article <et39hp$8ss_003@s948.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In article <et1957$ki3$2@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
In article <et0oi0$8qk_003@s776.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In article <esuqfn$ds3$5@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
[....]
No, you are making the same mistake over and over. As I stated before,
if
you know what you are going to put into TAPE.DIR, you can make its
checksum correct. No editing of a magnetic tape was needed by the
method.

Then that TAPE.DIR was not made by taking a directory of the
tape. That was not the purpose of the file. If I had to do
it the way you suggested, I wouldn't put the file on the tape
since it would be a waste of tape space.

So now you are suddenly changing your story and saying that editing of
the
tape was done.

There was no tape editing done.

In that case. The tape had to be written with the TAPE.DIR in place and
correct on the first pass.

This is the point. It will never be "correct" because the file
contains a checksummed listing of itself.

snip

Do the exercise. Then you will see what I'm talking about.

Bin thar, dun that, got t-shirt, wore out t-shirt.

I've done it. The idea wasn't new when I did. You just haven't
understood a very simple concept.

I understood you just fine. You didn't put a directory of the
tape onto the tape.

That *proves* you didn't understand. I have explained how to make the the
directory have correct checksum no matter how you actually want to do it.
You seem to constantly fail to understand that you can creat a file that
has its own correct checksum. It has been done many times on many tapes
and on many disks.


--
--
kensmith@rahul.net forging knowledge

 

[Ken Smith]

In article <1173870480.508596.143930@n76g2000hsh.googlegroups.com>,
Martin Brown <|||newspam|||@nezumi.demon.co.uk> wrote:
[....]

CRC offers a much higher chance of detecting tape bitrot. But it is a
lot harder to tweak a file to contain its own CRC (but still not
impossible). Matching an MD5 is beyond present computational power.

For an 8 bit CRC, as was used on tapes, a table was used.

But for a simple checksum it can be done trivially by writing the
master TAPE.DIR file claiming any arbitrary checksum you like and then
adjusting the final file with a chunk of your favourite nonsense rhyme

Actually it was done using a string of characters with a modestly high
ordinal value like the "Z" or the ":". These were then changed when the
checksum was produced.

If the file contains:
The checksum = 0000
The checksum = ::::

When you first create it, changing both lines to have the checksum in it,
works very nicely. People never suspect that there is a reason while the
directory's title part contains the checksum.


--
--
kensmith@rahul.net forging knowledge

 

[Ken Smith]

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

In article <1173870480.508596.143930@n76g2000hsh.googlegroups.com>,
"Martin Brown" <|||newspam|||@nezumi.demon.co.uk> wrote:
On Mar 13, 10:34 am, jmfbah...@aol.com wrote:
In article <et3pbr$ra...@blue.rahul.net>,
kensm...@green.rahul.net (Ken Smith) wrote:

In that case. Thetapehad to be written with theTAPE.DIR in place and
correct on the first pass.

This is the point. It will never be "correct" because the file
contains a checksummed listing of itself.

snip

Do the exercise. Then you will see what I'm talking about.

You really are determined to parade your ignorance. File checksums are
trivial to make internally consistent.

At the simplest conceptual level you could define all files to have
checksum=0 and add some fluff to the end of each one to make it so. In
this case you only need to adjust the TAPE.DIR and since you know the
effect of changing the bytes in the checksum representation on the
checksum it is relatively easy to program a self consistent solution.

CRC offers a much higher chance of detecting tape bitrot. But it is a
lot harder to tweak a file to contain its own CRC (but still not
impossible). Matching an MD5 is beyond present computational power.

But for a simple checksum it can be done trivially by writing the
master TAPE.DIR file claiming any arbitrary checksum you like and then
adjusting the final file

Now the file is no longer a directory of the tape. By modifying
the file on the tape, you have changed the tape. There is no
longer a directory of the tape on the tape.

That is just silly word games, but at least you now obviously must see
that you have been wrong.

--
--
kensmith@rahul.net forging knowledge