Jihad needs scientists
in [Design]
|
From: nonsense on 15 Mar 2007 08:49 jmfbahciv(a)aol.com wrote: > 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? Sure. It is called the factory worker who is paid to rush through production while ignoring flaws. That's why we now have lemon laws.
From: jmfbahciv on 15 Mar 2007 07:48 In article <et90ti$6oi$8(a)blue.rahul.net>, kensmith(a)green.rahul.net (Ken Smith) wrote: >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? Some times I did; usually at dawn. Other times I patted them on the head. Once in a great while, I kicked their butts. I was the one they showed their stuff to; they called it the den mother test because it invariably would crash the system. There is some aspect of life that, when you think you're ready to show off your brand new invention, doing so will cause it to immediately turn belly up and die a horrible death. I also participated in a lot of the preliminary bullshit sessions which usually ended up in major products. I also could predict where and when the axles would need greasing and applied the grease before anybody heard a squeak. All of the above was done in my spare time.
From: Ken Smith on 15 Mar 2007 09:40 In article <etb9rf$8ss_002(a)s881.apx1.sbo.ma.dialup.rcn.com>, <jmfbahciv(a)aol.com> wrote: >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. Now at least you seem to perhaps have started to get a slight glimmer of understanding. I was not suggesting a file that was manually edited. You have claimed to be a developer so this part should have been obvious, but now lets discuss this file you put on tape. It is also not a directory of the tape. It was not made from the tape. It was made from what you intended to write onto the tape. You wrote this file onto the tape before you wrote the files it claimed were there. Unless you then checked the tape to make sure that all the files you claimed to have written were actually there, this file you wrote could not be said to be a correct directory of the tape. The method I suggested way back at the start involved exactly this sort of check to make sure that the file I was suggesting was also a true and correct directory. You seem at least to have finally settled on a claim about when you created the TAPE.DIR. -- -- kensmith(a)rahul.net forging knowledge
From: Ken Smith on 15 Mar 2007 09:41 In article <etbb22$8qk_002(a)s881.apx1.sbo.ma.dialup.rcn.com>, <jmfbahciv(a)aol.com> wrote: >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] Ok so you haven't yet figured out that you were wrong. > >/BAH -- -- kensmith(a)rahul.net forging knowledge
From: Ken Smith on 15 Mar 2007 09:48
In article <etbb6t$8qk_003(a)s881.apx1.sbo.ma.dialup.rcn.com>, <jmfbahciv(a)aol.com> wrote: [....] >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? That process is called "engineering" or in some cases "manufacturing engineering". Once the solution is found, procedures, script files and software is written. In large scale manufacturing, whole new machines are designed to do produce the product. -- -- kensmith(a)rahul.net forging knowledge |