Jihad needs scientists
in [Design]
|
From: jmfbahciv on 7 Mar 2007 06:59 In article <esju3h$1a4$2(a)blue.rahul.net>, kensmith(a)green.rahul.net (Ken Smith) wrote: >In article <esjjt0$8ss_003(a)s931.apx1.sbo.ma.dialup.rcn.com>, > <jmfbahciv(a)aol.com> wrote: >>In article <esij9m$9en$1(a)blue.rahul.net>, >> kensmith(a)green.rahul.net (Ken Smith) wrote: >>>In article <eshesp$8qk_004(a)s787.apx1.sbo.ma.dialup.rcn.com>, >>> <jmfbahciv(a)aol.com> wrote: >[......] >>>>And one controller could have many devices hanging off it. >>>>Apparently, that doesn't happen at the moment. From your >>>>descriptions, it appears there a 1::1 restriction. >>> >>>Yes, today, electronics is much cheaper so we can take advantage of this. >> >>This isn't a feature. This kind of restriction evolved because >>the gear was cheap. Removing the parallelism of hardware >>pathways was the trade off. > >Not providing a buggy whip holder in a car is the same sort of trade off. Giving the buggy whip to the back seat driver still makes the whip useful. >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? /BAH
From: jmfbahciv on 7 Mar 2007 07:01 In article <63ec8$45ed7ba8$4fe701c$6223(a)DIALUPUSA.NET>, "nonsense(a)unsettled.com" <nonsense(a)unsettled.com> wrote: >jmfbahciv(a)aol.com wrote: > >> In article <2snpu2dlcklvtjputnd3pd5fv75cap3l3g(a)4ax.com>, >> MassiveProng <MassiveProng(a)thebarattheendoftheuniverse.org> wrote: >> >>>On Mon, 05 Mar 07 16:01:29 GMT, jmfbahciv(a)aol.com Gave us: >>> >>> >>>>Apparently, that doesn't happen at the moment. From your >>>>descriptions, it appears there a 1::1 restriction. >>> >>> >>> More proof that you are clueless. >> >> >> I am thinking about where the biz is going to have to go >> when the only way people can do their finances is via >> computers systems installed in their abodes. > >It is an advance not unlike many before this. It is a dangerous advance if no thinking is done. There isn't much thinking going on. We certainly are not breeding people capable of thinking about both things: computer systems and banking. /BAH
From: nonsense on 7 Mar 2007 07:14 jmfbahciv(a)aol.com wrote: > In article <2dab6$45ed7ada$4fe701c$6184(a)DIALUPUSA.NET>, > "nonsense(a)unsettled.com" <nonsense(a)unsettled.com> wrote: > >>jmfbahciv(a)aol.com wrote: >> >> >>>In article <esij9m$9en$1(a)blue.rahul.net>, >>> kensmith(a)green.rahul.net (Ken Smith) wrote: >>> >>> >>>>In article <eshesp$8qk_004(a)s787.apx1.sbo.ma.dialup.rcn.com>, >>>><jmfbahciv(a)aol.com> wrote: >>>> >>>> >>>>>In article <eshe15$l1t$5(a)blue.rahul.net>, >>>>> kensmith(a)green.rahul.net (Ken Smith) wrote: >>>>> >>>>> >>>>>>In article <MPG.2055feeb3db1e22498a066(a)news.individual.net>, >>>>>>krw <krw(a)att.bizzzz> wrote: >>>>>>[....] >>>>>> >>>>>> >>>>>>>Much of the "controller" is on the chipset these days, oh >>>>>>>MassivelyWrong one. >>>>>> >>>>>>I know that appearing to agree with MissingProng is a strong indication > > of > >>>>>>error but there is a point that I would like to make here. >>>>>> >>>>>>Way back in the mists of time, there was electronics for disk drives we >>>>>>called the "controller". This electronics was much simpler than the >>>>>>electronics used related to disk drives today. >>>>> >>>>>And one controller could have many devices hanging off it. >>>>>Apparently, that doesn't happen at the moment. From your >>>>>descriptions, it appears there a 1::1 restriction. >>>> >>>>Yes, today, electronics is much cheaper so we can take advantage of this. >>> >>> >>>This isn't a feature. This kind of restriction evolved because >>>the gear was cheap. Removing the parallelism of hardware >>>pathways was the trade off. >> >>Yet there is the advantage of speed that massive parallelism >>hampers by its sheer bulk. Still a trade off however. > > > Speed is uninteresting if you don't have a way to get the > bits from here to there. :-) Having more than one path > allows the system to keep functioning even if one of the > pathways breaks. Ah yes, redundancy means something different to us than it does to the Brits.
From: nonsense on 7 Mar 2007 07:18 jmfbahciv(a)aol.com wrote: > In article <63ec8$45ed7ba8$4fe701c$6223(a)DIALUPUSA.NET>, > "nonsense(a)unsettled.com" <nonsense(a)unsettled.com> wrote: > >>jmfbahciv(a)aol.com wrote: >> >> >>>In article <2snpu2dlcklvtjputnd3pd5fv75cap3l3g(a)4ax.com>, >>> MassiveProng <MassiveProng(a)thebarattheendoftheuniverse.org> wrote: >>> >>> >>>>On Mon, 05 Mar 07 16:01:29 GMT, jmfbahciv(a)aol.com Gave us: >>>> >>>> >>>> >>>>>Apparently, that doesn't happen at the moment. From your >>>>>descriptions, it appears there a 1::1 restriction. >>>> >>>> >>>>More proof that you are clueless. >>> >>> >>>I am thinking about where the biz is going to have to go >>>when the only way people can do their finances is via >>>computers systems installed in their abodes. >> >>It is an advance not unlike many before this. > > > It is a dangerous advance if no thinking is done. There > isn't much thinking going on. We certainly are not > breeding people capable of thinking about both things: > computer systems and banking. History teaches us that we are, unfortunately, reactive instead of being pro-active when it comes to these things. The "think" signs should have been "think ahead" signs.
From: jmfbahciv on 7 Mar 2007 07:20
In article <esjvn9$1a4$4(a)blue.rahul.net>, kensmith(a)green.rahul.net (Ken Smith) wrote: >In article <esjofk$8qk_001(a)s931.apx1.sbo.ma.dialup.rcn.com>, > <jmfbahciv(a)aol.com> wrote: >>In article <esikk3$9en$4(a)blue.rahul.net>, >> kensmith(a)green.rahul.net (Ken Smith) wrote: >>>In article <eshe41$8qk_001(a)s787.apx1.sbo.ma.dialup.rcn.com>, >>> <jmfbahciv(a)aol.com> wrote: >>>>In article <eshcs5$l1t$3(a)blue.rahul.net>, >>>> kensmith(a)green.rahul.net (Ken Smith) wrote: >>>>>In article <eshaf7$8ss_001(a)s787.apx1.sbo.ma.dialup.rcn.com>, >>>>> <jmfbahciv(a)aol.com> wrote: >>>>>[.....] >>>>>>tape. And that was a PITA because a checksummed directory of the >>>>>>tape was never precisely accurate because the checksum of the >>>>>>first file (the checksummed directory of itself) always changed :-). >>>>>> >>>>>>It was one of those neat CATCH-22 problems that I liked to think >>>>>>about. It reminded me of those three-way mirrors in the clothing >>>>>>store's dressing rooms. It was turtles all the way down. >>>>> >>>>>A checksum isn't the best way to do it if but assuming a checksum is used, >>>>>the problem of the checksum including its self was solved years ago. >>>> >>>>No, it wasn't. >>> >>>Yes, it was. >>> >>>> Not with the spec I had. Remember that the >>>>directory of the tape had to be the first file on that tape. >>> >>>No problem. Was the contents you intended to put in the directory known >>>before you started to write. >> >>Sure. But you are missing the requirement that the DIR file >>was a checksummed directory of the _tape_, not of the >>contents of the tape before it was saved. > >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. > >> >>> If so this is falling off a log simple. >> >>I am aware of that one. This was a directory of the tape, >>not the files of the disk before they were copied to the >>tape. > >If you intend to put the files onto the tape and can do so you can also >figure out what the directory should look like before hand. This is so >simple that it doesn't need further discussion. You still are not getting the fact that the directory of the tape had to be on the tape--not a directory of the files on disk soon to be copied to the tape. > >The issue of what to do if you can't be sure about how much will really >fit onto the tape is worthy of further discussion if you want to know how >to solve that one. I know more about how to fit stuff on small tapes than you will ever encounter. Tape fitting still has nothing to do with the requirement of a directory of the tape prepended to the files we distributed on that tape. > > >[....] > >>You are not solving the problem I was talking about. > >I didn't solve it. It was solved by others long long ago. You can't see >the solution without further help so I will include that help below. > > >>>>>Hint: what do write you when you haven't done the checksum yet? What do >>>>>you write after you have done it. >>>> >>>>The medium was magtapes. They are not random access writable media. >>> >>>Think about the questions. I gave you a huge hint as to how to do it. >> >>You are talking about checksumming the files on the disk. That >>was not the purpose of the directory file. This directory file >>had to be done on the tape. > >Did you control what was written onto the tape or did some random >generator determine it. If you controlled what went onto the tape, you >knew before you wrote the first byte what all the bytes were going to be >so the figuring out of the checksum was not really a problem. There would be too much of a time gap between getting the disk checksums and saving the files to the tape. In addition, a customer who restores a file can do a compare with the file he has on his disk with what we actually put on the tape. It helps to know when (within the process of saving, distribution, restoring, looking and using) a file was corrupted. A customer can tell immediately if the file was bad originally (our problem fix) or became bad during shipment (his and our problem to fix) or restoring (his problem to fix). > The problem >is that you couldn't see how to make the checksum correct when the file >that contained the checksum had to be included in the checksum. Since the contents of the directory file will always change (checksummed file's checksum is the thing that will never be a constant), there will never be an accurate directory of the tape. However, no customer's system needed to use the directory-of-the-tape file's checksum to verify their restores. > >A checksum is a simple sum where carried out of th etop of the word are >discarded. For this reason you can take advantage of the observation >that: > >A+B+C+D+E+F+G+0+0 == A+B+C+D+E+F+G+(-H)+H > >The checksum is not changed if two changes that cancel each other are >made. This is not a very good sanity check. > With binary data it is very easy to implement this by simply >writing the values. If you need work in ASCII doing the (-H) part is only >slightly trickier. > >Before: > *Please ignore this line: ZZZZ > The checksum is = 0000 > >After: > *Please ignore this line: ZXYZ > The checksum is = 0210 > >See how the compensating change means that we can figure out a checksum >and then put it in without changing the very thing we just calculated. >Your problem was solved years ago. Doing the same on CRC based checking >requires a more complex routine for doing the compensating change but the >method still works. > >Some people even came up with cute ways to hide the compensating changes >so that it wouldn't look like anything funny was being done. That is not how we used checksums when packaging our materials. The program our customers used to get a checksum had to match the program we used to get the checksum we reported. > > >>>>I >>>>always used the one implemented in our DIRECT program. I'm talking >>>>about storing a file whose contents changes with each previous >>>>save. Remeber that a checksummed directory of the tape also has >>>>to include the file that contains the checksummed directory of the >>>>tape. >>> >>>Like I said solved years ago. >> >>No, it is a problem that cannot be solved. > >See above. I'd never let you package our stuff. You are more interested in fakery than in ways to assist customers to analyze stuff that goes wrong. Note that the obvious "solution" was to put the directory of the tape in a saveset at the end of the tape. But that was unacceptable because the customers did not need to have to read to the end of a serious of save sets (which could involve more than one tape) in order to "see" what was new and ID the beware files. It was also a goal, to minimize the number of times they had to physical pass the tape on a reel over the heads in order to restore what we shipped. On some sites, bit inspections were very rigorous. /BAH /BAH |