Jihad needs scientists
in [Design]
|
From: MassiveProng on 10 Mar 2007 12:27 On Sat, 10 Mar 07 11:49:59 GMT, jmfbahciv(a)aol.com Gave us: >I don't allow a vacuum in my TTY room. It tended to wipe out >modems. You're an idiot. You tend to attribute failure modes to unrelated events a lot?
From: MassiveProng on 10 Mar 2007 12:30 On Sat, 10 Mar 07 11:49:59 GMT, jmfbahciv(a)aol.com Gave us: >I guess you can never lay down with one in your pocket then. >Credit cards magnetic strips of the males were always getting wiped out >whenever they leaned against a disk drive. Bullshit. Credit card mag stripes are VERY resilient, and abrasive scratches are about the only thing that fucks them up. Your brain got wiped out when you refused to move beyond TTY access to the world.
From: Ken Smith on 10 Mar 2007 12:32 In article <esu5o4$8ss_003(a)s861.apx1.sbo.ma.dialup.rcn.com>, <jmfbahciv(a)aol.com> wrote: >In article <esrr8b$n5i$2(a)blue.rahul.net>, > kensmith(a)green.rahul.net (Ken Smith) wrote: [....] >>>These used to be called private packs. The concept has existed since >>>the 60s. >> [....] >> The operator allocated them >>after you paid large amounts of money. > >That depended on the site. You seem to be talking from an IBM >operational POV. Yes, an IBM environment > Ours was designed differently. It was easy >to redirect any spooling to a pack reserved for that purpose. >Video downloads, etc. could be in a similar category. Who did the "reserved for that purpose"? That would be the point where money would be needed. [....] >>Where you evolve to depends a lot on where you start. In this case, there >>is a large factor from the seemingly unimportant choices made in the early >>days. > >Those weren't unimportant choices. They were deliberately made with >certain goals and non-goals in mind. No development was an >accident. Sure it was. In both hardware and software design there are often choices that look identical today but won't in the future. For a long time logic has run on 5V. The selection of 5V can be traced in part to the heater voltage on tubes. -- -- kensmith(a)rahul.net forging knowledge
From: Ken Smith on 10 Mar 2007 12:39 In article <esu670$8ss_005(a)s861.apx1.sbo.ma.dialup.rcn.com>, <jmfbahciv(a)aol.com> wrote: >In article <esrrjh$n5i$3(a)blue.rahul.net>, > kensmith(a)green.rahul.net (Ken Smith) wrote: >>In article <esrgkf$8ss_004(a)s842.apx1.sbo.ma.dialup.rcn.com>, >> <jmfbahciv(a)aol.com> wrote: >>[.... me .....] >>>>..... and it includes its own checksum. This checksum can be made to be >>>>correct by the method I suggested. >>> >>>Only by fakery. >> >>No "fakery" was needed if you know beforehand the names of the files that >>will be written. > >Your method is still not a physical directory of the tape that is >going to be sent out. Yes it is! Yes it is! Yes it is! Stop thinking that and you may start to see your mistake. I have tried repeatedly to simplify the question and re-explain the issue. You keep coming back to this mistake. I have explained how the checksum of the TAPE.DIR file can be correct in several different ways but you seem to be unable to grasp what I've said. >>> To fake it would open up many opportunities >>>for Murphy's Law to strike. >> >>Nothing I suggested leaves any extra room for Murphy and provides a >>correct checksum which closes one door he may use. > >Editing a number into the middle of a magtape is not asking >for major Murphy events? You are definitely not thinking well. 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. [.....] >>You have to write to TAPE.DIR if you want it to exist. In the case where >>the names going into TAPE.DIR is known, the method I suggested did not >>require any other write actions than the method you suggested. It only >>required that you think about what you intend to write before you wrote >>it. This I assume you would already have to do some amount of because you >>need to conpose the contents of that file based on what you intend to >>write. >> >> >>You just missed something that is all. > >You still are missing the requirement of having a directory of the >tape on the tape. TAPE.DIR is the first file on the tape TAPE.DIR lists the checksums of all the files on the tape. TAPE.DIR's checksum in this list can be correct when written. I have tried to explain how but you just don't seem to be able to understand the issue. -- -- kensmith(a)rahul.net forging knowledge
From: Ken Smith on 10 Mar 2007 12:55
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. You wrote one file and then wrote something different in its place. Given this, the method of making the checksum of TAPE.DIR is done very easily. I have already explain how several times. >>I don't think so. You objected to opening it for writing. This means >>that you only could have put it onto the tape before the others. You must >>therefor have known what you intended to write. You also would have >>checked when you were done that you really had written what you intended. >>If what you actually wrote did not match what you intened to write, you >>would have taken some action. Most likely you would make a new tape. > >A second save exercise had to be done. Howver, the checksum of >the file TAPE.DIR in the file TAPE.DIR would never be correct. >We could live with that. It would not generate any SPRs nor >create problems in the field. As I explained, the claim that it can't be correct it wrong. The method I explained makes it correct. There is no problem. >>No, what I suggested solves the problem you had cleanly and without adding >>any problems. You just seem not to be able to grasp what it does. > >I know what it does. And the solution would cause more problems than >it fixed. If your solution was the only one, I'd punt the idea. You don't seem to be able to understand the idea so yes, I guess you would punt the idea. leaving the tape incorrect and your customers at an extra risk. [....] >>Nothing I suggested would result in that. The net result of what I have >>suggested is one line of text in the TAPE.DIR file if it is an ASCII text >>file and an extra byte if it is binary. > >Since the medium is a magtape, inserting one tiny bit would make a >mess of the save set and cause it to not be restorable. No, it would not, You just need to think about what I really said. When you first made the tape, you left a gap for the file. You then write this file after. Before you write this TAPE.DIR, you think for about 3 seconds and then write a TAPE.DIR that is completely correct instead of one with an error in it. > This >was the master cut of the tapes that would soon be made to ship >to all customers. It had to be perfect and copyable. ..... and yet you shipped it with a mistake on it. This means it was not perfect at the instant you created it. The checksum was wrong because you didn't think for about 3 seconds. >Another trick that had to done was to save files to tapes that >had been physically logically "shortened". That was done by >moving the silver strip to make a "short tape". This has nothing to do with the question at hand. The strips on the ends of tapes were moved on ones that were being used as scratch. You would never do this on a production tape. [..........] >>Once again what you are saying contradicts what you suggested earlier. >>You had to check that you really did put onto the tape what you intended >>to put onto the tape. My method makes no change to that requirement. > >Your method does not put a director _OF_ the tape onto the tape. Yes it does! You can do exactly all the same steps as what you did plus a very small amount of thinking and get it right. [....] >>WRONG! You have always been able to edit magnetic tape. You can't cause >>the lengths of things to change but you can overwrite a file with one of >>the same size. > >But it isn't the same size. You cannot predict the size of any >record on a magtape. You wrote something onto the tape called TAPE.DIR. I have not suggested anything that makes its size change in anyway that you did not have. Either you knew before hand its size or you didn't. I assume you did because you had to write something to take up that much space. Nothing in what I suggested makes that any sort of a problem. [....] >>Hardly new. Reel to reel tape isn't used much anymore. Even very stone >>aged reel-to-reel drives like the Kennedy 9700 could do it. You being >>unaware of this contradicts statements you made earlier. > >I was never aware that the purpose of IRGs was so a human could >edit directly to the tape. We are not talking about humans doing things we are talking about what computers could do. >Yes! THat is the only way to get a directory of the tape. Then as I have explained, the method works the checksum did not need to be wrong. -- -- kensmith(a)rahul.net forging knowledge |