Jihad needs scientists
in [Design]
|
From: Ken Smith on 9 Mar 2007 09:33 In article <esrgdi$8ss_002(a)s842.apx1.sbo.ma.dialup.rcn.com>, <jmfbahciv(a)aol.com> wrote: >In article <esp7m9$hni$1(a)blue.rahul.net>, > kensmith(a)green.rahul.net (Ken Smith) wrote: >>In article <esothi$8ss_002(a)s1016.apx1.sbo.ma.dialup.rcn.com>, >> <jmfbahciv(a)aol.com> wrote: >>>In article <esmj7c$bj2$1(a)blue.rahul.net>, >>> kensmith(a)green.rahul.net (Ken Smith) wrote: >>>>In article <esm9f6$8ss_002(a)s1012.apx1.sbo.ma.dialup.rcn.com>, >>>> <jmfbahciv(a)aol.com> wrote: >>>>>In article <esju3h$1a4$2(a)blue.rahul.net>, >>>>> kensmith(a)green.rahul.net (Ken Smith) wrote: >>>>[.....] >>>>>>Having multiple disks connected to a single disk drive controller >>>>>>electronics gives absolutely no advantage and a few disadvantages. >>>>> >>>>>I know that one can have multiple structures on one drive. Has >>>>>the need of having one structure on multiple drives gone away? >>>> >>>>No, it hasn't gone away completely. There is a lot less need for logical >>>>volumes to span multiple disks today. >>> >>>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? >> >>This may happen some time in the slightly distant future. Modern OSes >>allow what the user sees as a directory to be a different disk drive. >> >>MS-DOS did this with the "join" command. When Windows 95 was brought out, >>the "join" command went away. On Linux and OS-X, the command is "mount". >> >>It isn't much of a stretch of the imagination to see some OS automatically >>assigning an entier drive to things like videos. > >These used to be called private packs. The concept has existed since >the 60s. They weren't assigned automatically though. The operator allocated them after you paid large amounts of money. [....] >>>The last reason was valid in the olden days. JMF visited an insurance >>>company site and saw a disk farm of [can't remember the number] >>>hundreds, I think. He was awed because it was all one file. >>>There was no way our products could deal with >>>that kind of a data base. IBM knew how to handle those. >> >>IBM's design of the logical structure was very good from this point of >>view. The Volume Table Of Contents told you where the Data Extent Blocks >>were. The DEBs formed a chain. Extending this chain to include which >>physical drive the next things were on wouldn't be hard to do. > >IBM evolved based on data base usage. We didn't. Our trade offs >were guided by delivering computing to people who did science and >engineering. 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. -- -- kensmith(a)rahul.net forging knowledge
From: Ken Smith on 9 Mar 2007 09:39 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. > 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. > 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. -- -- kensmith(a)rahul.net forging knowledge
From: Ken Smith on 9 Mar 2007 10:10 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? 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. >> >>>>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. > 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. [....] >>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. You are squirming. Just admit that the extra line of text in the file solves the whole problem. [....] >>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? (2) Do you write this file onto the tape? (3) Do you go never back and change this file after it is written? (4) Do you put this file at the beginning of the tape? 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. [.....] >>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. >>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? If yes, then my method works. If no then your method isn't any more a list of files actually on the tape than mine is. In either case, my method will make a correct checksum. You were needlessly shipping tapes with an error on them. >>>>There is absolutely nothing in what I suggested that changes this. I will >>>>suggest you go back over the subject again. >>> >>>I don't have to; my methods worked and provided enough data >>>for sanity checks on both ends of the distribution system. >> >>You said the checksum was published as wrong > >Only the checksum of the file TAPE.DIR was incorrect. The first >save of the tape had the checksum as 0. I have proven that it didn't need to be. No matter what order you did things, the checksum could have been right. You have made claims that contradict each other about what you did. -- -- kensmith(a)rahul.net forging knowledge
From: krw on 9 Mar 2007 10:30 In article <irg1v2lu3uks9ekle3gf1qdipd9acbnkbf(a)4ax.com>, MassiveProng(a)thebarattheendoftheuniverse.org says... > On Thu, 8 Mar 2007 20:56:15 -0500, krw <krw(a)att.bizzzz> Gave us: > > >Can't even put a sentence together, eh Dimbulb? "Us" is not > >singular. > > > It is a song title, retard boy. Doesn't change the fact that there is only *one* Dimbulb, Dimmie. > > Try to keep up, dumbfucktard. With you? Don't make me laugh (harder). -- Keith
From: MassiveProng on 9 Mar 2007 20:00
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? Sheesh! |