Jihad needs scientists
in [Design]
|
From: Ken Smith on 14 Mar 2007 10:28 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. -- -- kensmith(a)rahul.net forging knowledge
From: Ken Smith on 14 Mar 2007 10:30 In article <et8i9q$8ss_004(a)s787.apx1.sbo.ma.dialup.rcn.com>, <jmfbahciv(a)aol.com> wrote: >In article <87slc9jje1.fsf(a)nonospaz.fatphil.org>, > Phil Carmody <thefatphil_demunged(a)yahoo.co.uk> wrote: >>jmfbahciv(a)aol.com writes: >>> In article <et3o1m$rad$2(a)blue.rahul.net>, >>> kensmith(a)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. Did you bring these "bit gods" coffee? -- -- kensmith(a)rahul.net forging knowledge
From: nonsense on 14 Mar 2007 12:20 Martin Brown 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. ALLEGED file checksums are. > 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. As she stated early on, editing and manipulation aren't permitted. > CRC offers a much higher chance of detecting tape bitrot. But it is a > lot harder to tweak Editing is not permitted. > a file to contain its own CRC (but still not > impossible). Matching an MD5 is beyond present computational power. Now tell me about any theoretical scenario where you can. > 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. Still, it isn't the checkum as read from the tape itself which *is* the specification. People who learned the technician approaches to solving problems appear to be willing to cheat and to argue strongly in favor of cheating. That wasn't the point of the subthread.
From: nonsense on 14 Mar 2007 12:25 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. They consider it "inventive" to do things the way they go about it; the way answers they have provided in this subthread.
From: nonsense on 14 Mar 2007 12:42
jmfbahciv(a)aol.com wrote: > In article <5a788$45f7cdfe$4fe707e$27037(a)DIALUPUSA.NET>, > "nonsense(a)unsettled.com" <nonsense(a)unsettled.com> wrote: > >>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. >>> >>> >>> >>>>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? Looks like you found a new word. :-) The answers we've seen over the months seem to me in retrospect to have been rather linear with a lot of semi-concealed "they're just like us" worldview. With that premise being wrong, all that follows is as well. Dammit, we don't even appreciate the difference between the Russian mind (semi-oriental) and ours. The US and the CIA have, for many decades, been accused of all sorts of underhanded stuff. Still, no one has tied together anything like the recent anti-leader dieoffs we can clearly see happening. Factually we consider the Russians "just like us" and clearly they're not. The middle eastern mindset is still another sort of critter yet. I've personally known some Russians, and they were very nice. But where power, money, and their natural habitat are concerned, things are rather different. It didn't seem to take a whole lot to herd the Jim Jones bunch into a situation where ~1000 murder/suicides were the end of the journey and achieved in the matter of a few hours at most. One is amused at the thought that it was socialist/communist/liberal thinking that led to that debacle, as sad as the outcome was. I don't see societal power and control as linear functions. I do see them as recursive, yes, with significant potential for runaway positive feedback (for the electronics design bunch to chew on.) |