Jihad needs scientists
in [Design]
|
From: jmfbahciv on 15 Mar 2007 07:14 In article <et8v9c$6oi$1(a)blue.rahul.net>, kensmith(a)green.rahul.net (Ken Smith) wrote: >In article <et8hie$8ss_001(a)s787.apx1.sbo.ma.dialup.rcn.com>, > <jmfbahciv(a)aol.com> wrote: >>In article <et6c0m$t53$7(a)blue.rahul.net>, >> kensmith(a)green.rahul.net (Ken Smith) wrote: >>>In article <et5un4$8ss_002(a)s887.apx1.sbo.ma.dialup.rcn.com>, >>> <jmfbahciv(a)aol.com> wrote: >>>>In article <et3pbr$rad$7(a)blue.rahul.net>, >>>> kensmith(a)green.rahul.net (Ken Smith) wrote: >>>>>In article <et39hp$8ss_003(a)s948.apx1.sbo.ma.dialup.rcn.com>, >>>>> <jmfbahciv(a)aol.com> wrote: >>>>>>In article <et1957$ki3$2(a)blue.rahul.net>, >>>>>> kensmith(a)green.rahul.net (Ken Smith) wrote: >>>>>>>In article <et0oi0$8qk_003(a)s776.apx1.sbo.ma.dialup.rcn.com>, >>>>>>> <jmfbahciv(a)aol.com> wrote: >>>>>>>>In article <esuqfn$ds3$5(a)blue.rahul.net>, >>>>>>>> kensmith(a)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. The file you put on the tape did not contain a directory of the tape. It was an edited file that you think may match the tape. /BAH
From: jmfbahciv on 15 Mar 2007 07:20 In article <et90pt$6oi$7(a)blue.rahul.net>, kensmith(a)green.rahul.net (Ken Smith) wrote: >In article <et8oqh$8qk_006(a)s787.apx1.sbo.ma.dialup.rcn.com>, > <jmfbahciv(a)aol.com> wrote: >[....] >>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. > >The fact that you say "the magic incantation is recursion", is further >proof that you can't deal with it and therefor think that the problem >can't be solved. So far it can't be solved. If I do think of a solution, I'll be the darling of the comm people and revered by the physics people. It's a fun to think about. /BAH
From: jmfbahciv on 15 Mar 2007 07:29 In article <et90d1$6oi$4(a)blue.rahul.net>, kensmith(a)green.rahul.net (Ken Smith) wrote: >In article <et8hr5$8ss_002(a)s787.apx1.sbo.ma.dialup.rcn.com>, > <jmfbahciv(a)aol.com> wrote: >>In article <et7ljd$bq1$5(a)blue.rahul.net>, >> kensmith(a)green.rahul.net (Ken Smith) wrote: >>>In article <b33aa$45f6d225$4fe7292$20427(a)DIALUPUSA.NET>, >>>nonsense(a)unsettled.com <nonsense(a)unsettled.com> wrote: >>>>Ken Smith wrote: >>>> >>>>> In article <et5v7k$8qk_001(a)s887.apx1.sbo.ma.dialup.rcn.com>, >>>>> <jmfbahciv(a)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. > >What I said was correct. No. It does not put a directory of the tape onto the tape. > I have explained how to make TAPE.DIR have the >right checksum for all posible cases of how you did things. Your methods require a human intervention which is called editing. The minute you close the file, that file is no longer a directory of the tape; it is a file that you think is a directory of the tape. > This is just >responding to unsettled further incorrect statement about how tape drive >operate. > >When you disagreed with my suggestion that TAPE.DIR is list of what you >intended to write onto tape, I could see that there was a way that you >could actually have done what you at that point were claiming. You have >now changed the claim. You no longer say that it is the directory of what >is on the tape What!?? You need reading comprehension eye glasses. >but is as I had suggested the directory of what you >intended to write onto tape. The script that creates the tape is already a list of what I intended to put on the tape. What is needed is a directory of the tape on the tape. To be useful, it has to be the first file of the saveset of the tape. Your methods don't do this. > > >> >>> 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. > >Oooops!!!! There you go again. Which is it. Is it (A)the directory of >what you wrote or (B) the directory of what you intend to write. > >This is getting silly because your story changes back and forth on this. You are interpreting my posts as going back and forth because that is the nature of the problem. unsettled called this recursion. > >>> >>>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. > >You *still* haven't understood. > >BTW: It isn't my method in that I did not invent what was done. It was >already old when I learned it. It was used on many tapes before I got >near one. It wasn't used on our distribution tapes. Nobody would put a hand edited file on the tape and expect it to be a directory of the tape. /BAH
From: jmfbahciv on 15 Mar 2007 07:35 In article <et8vtn$6oi$3(a)blue.rahul.net>, kensmith(a)green.rahul.net (Ken Smith) wrote: >In article <et8nid$8qk_001(a)s787.apx1.sbo.ma.dialup.rcn.com>, > <jmfbahciv(a)aol.com> wrote: >>In article <1173870480.508596.143930(a)n76g2000hsh.googlegroups.com>, >> "Martin Brown" <|||newspam|||@nezumi.demon.co.uk> wrote: >>>On Mar 13, 10:34 am, jmfbah...(a)aol.com wrote: >>>> In article <et3pbr$ra...(a)blue.rahul.net>, >>>> kensm...(a)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. Wrong. [awed emoticon here] /BAH
From: jmfbahciv on 15 Mar 2007 07:38
In article <f539$45f813cb$4fe71d4$28601(a)DIALUPUSA.NET>, "nonsense(a)unsettled.com" <nonsense(a)unsettled.com> wrote: >jmfbahciv(a)aol.com wrote: > >> In article <1173870480.508596.143930(a)n76g2000hsh.googlegroups.com>, >> "Martin Brown" <|||newspam|||@nezumi.demon.co.uk> wrote: >> >>>On Mar 13, 10:34 am, jmfbah...(a)aol.com wrote: >>> >>>>In article <et3pbr$ra...(a)blue.rahul.net>, >>>> kensm...(a)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? > >Technicians and engineers are trained to problem solving >regardless of method. I realize this. >They consider it "inventive" to do >things the way they go about it; the way answers they have >provided in this subthread. So how does the human race go from this "inventive" solution methods into production? Is there a name for the work which eliminates this requirement to tweak each item that comes off the production line? /BAH |