Jihad needs scientists
in [Design]
|
From: jmfbahciv on 13 Mar 2007 06:34 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. /BAH
From: jmfbahciv on 13 Mar 2007 06:43 In article <et3q4u$rad$8(a)blue.rahul.net>, kensmith(a)green.rahul.net (Ken Smith) wrote: >In article <et39vo$8qk_001(a)s948.apx1.sbo.ma.dialup.rcn.com>, > <jmfbahciv(a)aol.com> wrote: >>In article <et1a4q$ki3$3(a)blue.rahul.net>, >> kensmith(a)green.rahul.net (Ken Smith) wrote: >>>In article <et0qsp$8qk_002(a)s776.apx1.sbo.ma.dialup.rcn.com>, >>> <jmfbahciv(a)aol.com> wrote: >>>>In article <esurfc$ds3$6(a)blue.rahul.net>, >>>> kensmith(a)green.rahul.net (Ken Smith) wrote: >>>>>In article <esu74a$8qk_001(a)s861.apx1.sbo.ma.dialup.rcn.com>, >>>>> <jmfbahciv(a)aol.com> wrote: >>>>>>In article <esrtcj$qj4$1(a)blue.rahul.net>, >>>>>> kensmith(a)green.rahul.net (Ken Smith) wrote: >>>>>[....] >>>>>>>In other words, you wrote the TAPE.DIR after all the other files were >>>>>>>written. This means you had to write a file of that size and then the >>>>>>>data and then open TAPE.DIR for writing. >>>>>>> >>>>>>>If this is what you did then my method of putting a correct checksum >>still >>>>>>>works. If you wrote the TAPE.DIR before the other files and never >>changed >>>>>>>it, my method still works. >>>>>>> >>>>>>> >>>>>>>[....] >>>>>>>>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. >>>>>>> >>>>>>>Does this mean you wrote TAPE.DIR after the other files were all written? >>>>>> >>>>>>Yes. TAPE.DIR was created after the files were written to the tape. >>>>>>That is how you get a directory listing of the tape onto the tape. >>>>>> >>>>>>The first cut of the tape had a zero block TAPE.DIR for a place holder >>>>>>on the tape. Then a DIRECT DSK:TAPE.DIR=TAPE:/CHECKSUM was done. >>>>>>Then another save was done; this time TAPE.DIR that was on the >>>>>>tape contained a checksummed directory of the tape. >>>>> >>>>>In other words, you "editted" the tape. >>>> >>>>No. >>> >>>How yes you did. You did exactly the action called editing when speaking >>>of a tape. >> >>We don't call saving a saveset editing. > >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. > >If the answer is yes, you edited the tape. In this case the method works. > >If the answer is no then you can no longer argue that the TAPE.DIR is the >list of what is actually on the tape. It must be the list of what you >intend to put on the tape. You have claimed that this is not allowed, but >the method still works for this too. The file was made by doing a directory of the tape. > >No matter which you did, the checksums can be correct. No, they cannot. The requirement was that TAPE.DIR be a directory of the tape and not a made-up list. > > > >>>>> You wrote one file and then wrote >>>>>something different in its place. >>>> >>>>No. I wrote the whole save set. In magtape terms, the saveset >>>>was the file on the tape. >>> >>>Now what the heck are you claiming? >> >>I'm still talking about the same thing. > >You have changed what you have claimed. Suddenly, the TAPE.DIR is not a >file on the tape and is a part of the contents of a file on the tape, TAPE.DIR is a file on the tape AND it is part of the contents of the saveset (which is the physcial magtape file). <snip. >I see that I can and have done exactly that in the past. No, you have not done a similar thing. > I have explained >how to do it a few times. You seem unable to graps it. I've used it. >Remember I have written tapes too. You may have copied files to tapes but you have not made a distribution according to the spec we used. > >[....] >>Then that file was saved along with all the other files onto the tape. > >Wait a minute! Suddenly TAPE.DIR is the list of what you intend to write >onto the tape. Your story has changed. You earlier asserted that it must >be made from what you actually wrote. Which is it? It is both. That is why a CATCH-22 exists. > >Not that it matter which it was because as I have already stated, I have >explained how you can get it right in either case. Your method had each disk file copied to the tape. That is not how our files were shipped. A saveset was the tape's file. There were no EOFs between the files we distributed. I'm getting technical here with reservations because I did not want to have to explain tape formats to you. /BAH
From: jmfbahciv on 13 Mar 2007 06:46 In article <et3o1m$rad$2(a)blue.rahul.net>, kensmith(a)green.rahul.net (Ken Smith) wrote: >In article <et3a41$8qk_002(a)s948.apx1.sbo.ma.dialup.rcn.com>, > <jmfbahciv(a)aol.com> wrote: >>In article <et15r5$h35$2(a)blue.rahul.net>, >> kensmith(a)green.rahul.net (Ken Smith) wrote: >>>In article <et0umt$8qk_018(a)s776.apx1.sbo.ma.dialup.rcn.com>, >>> <jmfbahciv(a)aol.com> wrote: >>>>In article <esuppf$ds3$3(a)blue.rahul.net>, >>>> kensmith(a)green.rahul.net (Ken Smith) wrote: >>>[.....] >>>>>In my house there is a network that links two fast machines. These are >>>>>linked to the internet by a single high speed pathway. At some future >>>>>time, my house may have more than one path to the rest of the world. When >>>>>the city puts in its 802.11 system, it will start to make sense for my >>>>>computer to start to choose between the two paths for my packets. This >>>>>puts routing inside my house. >>>> >>>>Sure. If you have an sense of self-preservation, your router is >>>>going to be seperated from your user machines. All homes >>>>will have their own server which will not be on the same hardware >>>>as their data. >>> >>>I doubt this is where it will end up. The router software will just be >>>another task in the home machine. The code for doing rounting doesn't put >>>the user's data at risk. The firewall is the place where the danger is if >>>at all. >> >>That would be a cheap and dangerous configuration. > >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. 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. /BAH
From: jmfbahciv on 13 Mar 2007 06:49 In article <5b9a2$45f55682$4fe7735$10616(a)DIALUPUSA.NET>, "nonsense(a)unsettled.com" <nonsense(a)unsettled.com> wrote: >jmfbahciv(a)aol.com wrote: > >> In article <et15r5$h35$2(a)blue.rahul.net>, >> kensmith(a)green.rahul.net (Ken Smith) wrote: >> >>>In article <et0umt$8qk_018(a)s776.apx1.sbo.ma.dialup.rcn.com>, >>><jmfbahciv(a)aol.com> wrote: >>> >>>>In article <esuppf$ds3$3(a)blue.rahul.net>, >>>> kensmith(a)green.rahul.net (Ken Smith) wrote: >>> >>>[.....] >>> >>>>>In my house there is a network that links two fast machines. These are >>>>>linked to the internet by a single high speed pathway. At some future >>>>>time, my house may have more than one path to the rest of the world. When >>>>>the city puts in its 802.11 system, it will start to make sense for my >>>>>computer to start to choose between the two paths for my packets. This >>>>>puts routing inside my house. >>>> >>>>Sure. If you have an sense of self-preservation, your router is >>>>going to be seperated from your user machines. All homes >>>>will have their own server which will not be on the same hardware >>>>as their data. >>> >>>I doubt this is where it will end up. The router software will just be >>>another task in the home machine. The code for doing rounting doesn't put >>>the user's data at risk. The firewall is the place where the danger is if >>>at all. >> >> >> That would be a cheap and dangerous configuration. > >Fine for a purely hobby machine. Folks are making serious use of >home machines these days, including doing their own finances on >a machine they connect to the internet. Some of them leave that >machine connected 24/7. > >I keep a separate machine for such stuff. There is that piece of usage. There will also be the usage of house maintenance getting done by the "house computer". YOu don't want kiddies access to that system. There is also the redundancy issue. If a system has to be up 24x7 then our crude implementation done in the late 70s will have to be done again but hopefully, with more experience behind it. /BAH /BAH
From: jmfbahciv on 13 Mar 2007 08:35
In article <2fef3$45f57c0a$4fe760d$11460(a)DIALUPUSA.NET>, "nonsense(a)unsettled.com" <nonsense(a)unsettled.com> wrote: >Dan Bloomquist wrote: > >> MassiveProng wrote: >> >>> >>> Note that TTL was the requisite defining element. > >Actually "the reason TTL was designed for 5 volts BCC" >was the requisite defining element. As usual, when >beaten to a logical pulp, one side attempted to shift >the goalposts. > >That's another version of what amounts to the Godwin >alert, the discussion (as intended) is dead. No, it's not. I'm still planning to do my homework so I can answer one your questions. <snip> /BAH |