Jihad needs scientists
in [Design]
|
From: jmfbahciv on 10 Mar 2007 06:49 In article <1914v2lqcetq8c7nh97qcv2otk94iu9ovi(a)4ax.com>, MassiveProng <MassiveProng(a)thebarattheendoftheuniverse.org> wrote: >On Fri, 09 Mar 07 11:29:43 GMT, jmfbahciv(a)aol.com Gave us: > >>In article <n7a1v29gv894uc76qtgn35j56hl2fflu5e(a)4ax.com>, >> MassiveProng <MassiveProng(a)thebarattheendoftheuniverse.org> wrote: >>>On Thu, 08 Mar 07 11:54:26 GMT, jmfbahciv(a)aol.com Gave us: >>> >>>>Is this because disk capacities are larger than most needs? With >>>>the habits of downloading music and videos, etc. won't there be >>>>another capacity problem fairly soon? >>> >>> >>> TeraByte drives are looming on the horizon as we speak. >>> >>> And those are in 2.5" form factor. >>> >>> Keep up much? >> >>And will they survive being set next to TV or a vacuum cleaner? >> > > > What? That is just plain retarded. I don't allow a vacuum in my TTY room. It tended to wipe out modems. > > They are no different than any other hard drive for their shielding >from external influence. Do you always ask such utterly stupid >questions? I was paid very well to ask those stupid questions. It was my job and a requirement to be in any OS developement group. > Were hard drives EVER subject to being affected by nearby >TV or vacuum cleaner? None that I am aware of. JMF bought his sons a PC one Christmas. Their first action was to set the drive on top of the PC. Wipe out. And the first DO NOT instruction was to not set the drive on the TTY. > > Sheesh! > > If anything the data stored on them is MORE resilient. > > They are perpendicular recording technology, and THAT has a BETTER >retention factor than the current horizontal method. 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. /BAH
From: jmfbahciv on 10 Mar 2007 06:53 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. > > >> 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. > > >> It was more important to have >>a physical list of what we put on the tape than to have >>the checksum of TAPE.DIR be correct and as the first file >>on the tape. Your approach would open the TAPE.DIR for writing. >>This was an unacceptable risk. > >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. /BAH
From: jmfbahciv on 10 Mar 2007 07:08 In article <esrtcj$qj4$1(a)blue.rahul.net>, kensmith(a)green.rahul.net (Ken Smith) wrote: >In article <esrhir$8qk_001(a)s842.apx1.sbo.ma.dialup.rcn.com>, > <jmfbahciv(a)aol.com> wrote: >>In article <esp89d$hni$2(a)blue.rahul.net>, >> kensmith(a)green.rahul.net (Ken Smith) wrote: >>>In article <esou80$8qk_001(a)s1016.apx1.sbo.ma.dialup.rcn.com>, >>> <jmfbahciv(a)aol.com> wrote: >>>>In article <esml4r$bj2$3(a)blue.rahul.net>, >>>> kensmith(a)green.rahul.net (Ken Smith) wrote: >>>>>In article <esmalk$8qk_001(a)s1012.apx1.sbo.ma.dialup.rcn.com>, >>>>> <jmfbahciv(a)aol.com> wrote: >>>>>>In article <esjvn9$1a4$4(a)blue.rahul.net>, >>>>>> kensmith(a)green.rahul.net (Ken Smith) wrote: >>>>>[....] >>>>>>>If you know what you intend to write onto the tape, figure out what the >>>>>>>checksum will be and then write the tape as you intend there is no extra >>>>>>>effort needed. >>>>>> >>>>>>That does not give you a checksummed directory of the physical >>>>>>tape you just made. All the handwaving and blustering you >>>>>>are doing still does not satisfy the requirement. >>>>> >>>>>Yes it does. Imagine it step by step. >>>>> >>>>>(1) >>>>>You calculate the checksum of what you intend to put on the tape. >>>>> >>>>>(2) >>>>>You put exactly what you intend onto the tape >>>>> >>>>>(3) >>>>>You calculate the checksum of what you have put on the tape. >>>> >>>>The checksum of the contents of the tape is not interesting. >>>>That is a summary and doesn't help. A bit by bit verify >>>>is done instead of your checksum summary. >>> >>>Suddenly you are changing the subject. >> >>I am still talking about the same procedure and constraints that >>I had to solve. >> >>> The question is: would the >>>checksum before and after match? The answer is yes, so the method works. >> >>No. It cannot match. Your method provides a list of we intended >>to put on the tape. My method describes what was really put on the >>tape because the TAPE.DIR file was generated by examining the tape. > >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. >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. > >>> >>>>>If the checksum at step (3) doesn't match the checksum at step (1), you >>>>>haven't written what you intended onto the tape. I am really surprised >>>>>that you can't see this. >>>> >>>>I'm at a loss to try to explain what we were doing. YOu seem >>>>to be determined not to understand. >>> >>>You were making a mistake, is what you were doing. >> >>You just gotta love this illogic. Your method is not a solution >>and creates havoc. > >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. > >> It can also be extremely expensive if it >>results in customers sending in problem reports when they could >>have done preliminary checking at the time they first examine >>the tape. > >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. 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. 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". > >[....] >>>Yes it does. I have shown how you can make the checksum on this file >>>correct. This file that contains the list is the very file we have been >>>talking about. >> >>It is a faked listing. It was not generated by looking at the >>files that were really put on the tape. Not only did my method >>provide an invoice of what got packed, my method kept us from >>making blank or incomplete masters. > >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. > >You are squirming. Just admit that the extra line of text in the file >solves the whole problem. It solves nothing and creates many, many messes. > > >[....] >>>My simple case solves a problem that you said can't be solved. You said >>>it was imposible. It is not. >> >>It is impossible. Everytime you take a new directory of the tape, >>the checksum of TAPE.DIR changes. If you do another save with the >>new TAPE.DIR, another directory of the physical tape will produce >>a different checksum of TAPE.DIR. > >(1) >Is TAPE.DIR a file? Yes. > >(2) >Do you write this file onto the tape? Yes. It is the first file. > >(3) >Do you go never back and change this file after it is written? Not the one on the tape. The first save had a zero checksum TAPE.DIR file on it. > >(4) >Do you put this file at the beginning of the tape? Yes. Putting it at the end make it's purpose useless. > >If the answer to these four questions is yes, then my method as discussed >earlier works just fine. If the answer to any combination of these is no, >then my method still works. I don't want to have to try to explain to you >all posible combinations. > > >>>>You can't edit a tape. That would open such a can of Murphy's >>>>worms, even if it were possible. >>> >>>This would be a very strange drive if you really couldn't. >> >>You have never been able to edit magtape. You need two >>drives to do an edit. > >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. TW was correct when he said that God never meant for there to be magtapes. He said this every time he wrote code for a new controller or device. > >[.....] >>>The reason tapes have an IRG (Inter Record Gap) is to allow the data on >>>the tape to be edited. You may decide not to do this but the drives knew >>>how. >> >>Now that's a new one. > >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. > > >>>This file lists the names of the files on the tape. >> >>You method does not list the files on the tape. Your method >>lists the files you intend to put on the tape. These are >>two very different lists. > >Do you write your list after you have written all the files? Yes! THat is the only way to get a directory of the tape. I give up. Your brain's PDL IOWD list is 2 words long. /BAH
From: MassiveProng on 10 Mar 2007 12:26 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.
From: Ken Smith on 10 Mar 2007 12:27
In article <esu5ct$8ss_001(a)s861.apx1.sbo.ma.dialup.rcn.com>, <jmfbahciv(a)aol.com> wrote: >In article <esrqvn$n5i$1(a)blue.rahul.net>, > kensmith(a)green.rahul.net (Ken Smith) wrote: >>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. > >Why? Most user machines are used essentially as end nodes, especially >the systems used as a TTY hosted into an ISP. These should never >be doing routing. Contention and pathway changes are too high >and would be a waste of overall routing CPU time to deal with. You have only stated the current situation and not what it could be in the future. 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. > >> With the current >>situation, I agree with you that it needs to be kept on a special box just >>for that purpose. > >It's easier to fire wall also. The way things are evolving, the server/router/firewall will be just a Linux box running software. -- -- kensmith(a)rahul.net forging knowledge |