Jihad needs scientists
in [Design]
|
From: jmfbahciv on 11 Mar 2007 07:10 In article <2hq5v2l75ejk6l5eg4j181ksavs8id9v41(a)4ax.com>, MassiveProng <MassiveProng(a)thebarattheendoftheuniverse.org> wrote: >On Sat, 10 Mar 07 11:40:07 GMT, jmfbahciv(a)aol.com Gave us: > >>In article <oo04v2d5ubfqmd07mgaqe6fssbav3g66th(a)4ax.com>, >> MassiveProng <MassiveProng(a)thebarattheendoftheuniverse.org> wrote: >>>On Fri, 9 Mar 2007 14:29:11 +0000 (UTC), kensmith(a)green.rahul.net (Ken >>>Smith) Gave us: >>> >>>>In article <esrg7f$8ss_001(a)s842.apx1.sbo.ma.dialup.rcn.com>, >>>> <jmfbahciv(a)aol.com> wrote: >>>>>In article <2v91v2pjpp3qdcn8mv70t5rk21t7g1oeem(a)4ax.com>, >>>>> MassiveProng <MassiveProng(a)thebarattheendoftheuniverse.org> wrote: >>>>>>On Thu, 08 Mar 07 11:48:40 GMT, jmfbahciv(a)aol.com Gave us: >>>>>> >>>>>>>As I said above, our OS philosophy was to provide multiple pathways. >>>>>>>Multiple pathways...do you understand what that means? So why >>>>>>>are you demeaning the OS philosophy with an argument about networks? >>>>>> >>>>>> >>>>>> Networking is a MAJOR part of a modern OS, dingledorf. >>>>> >>>>>It shouldn't be. Routing should be kept off user machines. >>>> >>>>If more effective ways of breaking up the routing problem were found, >>>>routing could be spread across the user machines. With the current >>>>situation, I agree with you that it needs to be kept on a special box just >>>>for that purpose. >>> >>> Funny... I said NETWORKING, NOT ROUTING. >>> >>> Do you two have reading comprehension issues or what? >> >>Which layer of the NETWORKING were you talking about? >> > > From your stupid posts, I was unaware that you knew anything about >layers. > > And, it is a COMPUTING model they refer to, not a networking model. So why are you arguing about an OS philosophy that tried to allow multiple pathways? /BAH
From: jmfbahciv on 11 Mar 2007 07:18 In article <esuqfn$ds3$5(a)blue.rahul.net>, kensmith(a)green.rahul.net (Ken Smith) wrote: >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. 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. > > >[.....] >>>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. TAPE.DIR is written by taking a directory of the tape. Since magtapes were not a directory device I could not type DIR MTA1:TAPE.DIR=MTA1:*.*/CHECKSUM. > >I have tried to explain how but you just don't seem to be able to >understand the issue. It is you who do not understand the purpose of the file. It is made by taking a physical directory of the magtape and never touched by human hands. The last was THE requirement. /BAH
From: jmfbahciv on 11 Mar 2007 07:39 In article <ac547$45f316dd$49ecf63$21139(a)DIALUPUSA.NET>, "nonsense(a)unsettled.com" <nonsense(a)unsettled.com> wrote: >Ken Smith wrote: >> In article <esu74a$8qk_001(a)s861.apx1.sbo.ma.dialup.rcn.com>, >> <jmfbahciv(a)aol.com> wrote: > >massive snip > > >>>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. > >BAH is right. > >You run a checksum of the tape. > >You write the checksum to the tape. > >The checksum of the tape has changed and is therefore now incorrect. >Every time you change the checksum data, the checksum changes. > >There's no way around it, other than putting a listing with >the correct tape checksum on some other media. Printing a label >with the checksum and sticking it to the reel would have worked, >but that probably wasn't geeky enough a solution. It can be lost. And if you knew the procedures of putting another part on the BoM list (bill of materials) you would circumvent having to pack another listing, too. There was also the problem that our product manager had wood for a head and was nixing anything I wanted to do; this had to do with my refusal to play internal politics and had nothing to do with customers' needs. /BAH
From: jmfbahciv on 11 Mar 2007 07:41 In article <pq66v2h0lsjevcgnacb4oq5n8rq77nccc1(a)4ax.com>, MassiveProng <MassiveProng(a)thebarattheendoftheuniverse.org> wrote: >On Sat, 10 Mar 2007 14:36:46 -0600, "nonsense(a)unsettled.com" ><nonsense(a)unsettled.com> Gave us: > >>The checksum of the tape has changed and is therefore now incorrect. >>Every time you change the checksum data, the checksum changes. > > > The checksum test tests the body of data on the tape, and does NOT >include the added checksum at the end, you idiotic, devoid of logic >twit. You are wrong. The word containing the checksum of the file is included in the checsum of the tape. /BAH
From: jmfbahciv on 11 Mar 2007 07:58
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. > 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. > >Given this, the method of making the checksum of TAPE.DIR is done very >easily. I have already explain how several times. I know you've explained ad nauseum. You keep ignoring the point of the file. IOW, you implemented something that wasn't in the spec. In fact, your implementation is 100% contrary to the spec. > > > >>>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. But you don't fulfill the requirement that the file is a directory of the tape, untouched by editing hands. > > >>>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. Nobody assembled the file called TAPE.DIR. It listed the files that were on the tape when we made the master. If the tape they received didn't match the ones listed in the file, then they knew they got a bum tape and could alert us that our manufacturing process has a problem. It was quite possible that SDC (software distribution center) had an order of tapes that were a lot less than 2400'. If the master was longer than the physical lenght of those tapes, then customers would get a distribution that didn't have the end of the save set. Not putting a directory of the tape onto the tape would create risks. > >[....] >>>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. No, there is no gap. > 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. You do not understand how tapes and savesets worked. > > >> 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. Yes. It was an error that was acceptable. The error had no side effects. Not shipping the file would have caused expensive side effects. > 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. I thought about this problem for months before I decided that it was OK to have one 36-bit word incorrect on that tape. I've thought about the CATCH-22 problem often since then because those are neat puzzles. > > > >>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. We had to do this on a master tape. You simply have no concept of the problems in a manufacturing environment when the products produced were OSes and the computers they were installed on. > >[..........] >>>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. No, it doesn't. Your method says what we think it should be like. That is very different from what it really is like. > >[....] >>>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 didn't know because the magtape had not been made yet. > 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. The first TAPE.DIR on the tape was a zero block file. > > >[....] >>>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. Humans made everything. Humans told the computers what to 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. YOur method does not provide a directory of what is on the tape. The whole point was to document what was on the tape when we made it. /BAH |