Jihad needs scientists
in [Design]
|
From: Ken Smith on 3 Mar 2007 11:34 In article <esboom$8qk_001(a)s977.apx1.sbo.ma.dialup.rcn.com>, <jmfbahciv(a)aol.com> wrote: >In article <es9f0f$q95$6(a)blue.rahul.net>, > kensmith(a)green.rahul.net (Ken Smith) wrote: >>In article <es98ds$8qk_001(a)s1006.apx1.sbo.ma.dialup.rcn.com>, >> <jmfbahciv(a)aol.com> wrote: >>[....] >>The other stuff I've spoken to elsewhere. >> >>>The case that I brought up was database; with databases, the data >>>is always a moving target that can never be snap-shot with accuracy. >> >>This is not always true. In a multidisk mirroring system, you can do a >>commit and unmount one drive. It will be an image of what was there at >>the time the commit happened. Disks are fast enough that this option can >>be used for most applications. The delay caused by the OS's commit >>operation is not very long. > >I know this is one strategy. One kind of implementation was called >striping. For a reservation system, this may not be the best >technique because data entry and maintenance is over a wide >geographical area; the speed of light is very slow. You said "never". You now admit that the method I stated does exist. The speed of light issue is only a slight delay on the commit process. >>[....] >>>> Normal OS file rules prohibit file "co-edit" sessions. >>> >>>Nope. It can be done but you really have to know what you're >>>doing. We implemented a system calls that would help different >>>programs "share" files. >> >>Note his word "normal" in the above. > >I was talking about normal. Windows is not normal. Note his word "normal". You have just suggested that yours was a special case ie: not normal. >> You can have multiple streams of >>data going to a file even on a Windows machine. All that is needed is to >>have one task that does the actual write operations. This is usually >>combined with "event based" recording where the transactions are recorded >>with time stamps so that the correct order is insured. > >That's not very effiecient if your app is writing a lot. There >will be a bottleneck at the timekeeper's point in the execution. What do you mean by "timekeeper". I have to ask because there is no such problem in any part I can think of as the "timekeeper". >Contention also needs handling because two events could have >the same time stamp. Contention is only an issue if you have multiprocessing and events that can't be commuted. -- -- kensmith(a)rahul.net forging knowledge
From: Ken Smith on 3 Mar 2007 11:53 In article <esc02o$8qk_001(a)s977.apx1.sbo.ma.dialup.rcn.com>, <jmfbahciv(a)aol.com> wrote: >In article <es9g64$q95$7(a)blue.rahul.net>, > kensmith(a)green.rahul.net (Ken Smith) wrote: [.... intel ....] >>>>I still can't find it. I searched the PDF version of the report for word >>>>"division" and nothing like that came up. Do you have a page number? >>> >>>You have to read the whole report and then compare the different >>>product areas. >> >>I have read the damn thing. Now tell me where these number are. > >You'll have to wait for this answer. Last year's had separate >sections discussing the PC biz and the embedded controller biz. >The embedded piece took in a lot more money but I don't recall >the percentage. I do recall it was significant. I think you are misrembering it. [.....] >>>Not for data bases such as SABRE. Airline reservation systems >>>don't care about data that is already in the past. >> >>That is completely wrong. If I make a reservation right now: >>..... time passes ..... >>and now I go to the airport, they'd better still remember that I made it. >> >>So now what did you really mean. > >Now consider the scenario: Ok but you have to go back and say that you were wrong when you stated "Airline reservation systems ...." > >You make a reservation. >Time passes.... >System gets corrupted causing a rebuild of the system from >a snapshot made just before your reservation was made. >Time passes.... >You go to the airport and find that somebody has your seat. Someone forgot to replay the transactions. This is obviously Jet Blue you are talking about. >>> It's too >>>complicated to go into detail. >> >>Obviously the above isn't. > >Your scenario assumes no errors nor corrections. No it doesn't. > Your scenario >assumes that somebody will notice if your reservation disappears. Not it doesn't. >Using your backup approach will never notice. Also untrue. >>>Again, if you do a bit by bit type of backup, you also save the >>>bad spots of the disk. >> >>Yes, exactly. When will you stop pretending that it is a new idea? This >>is exactly what you want a back up to do. > >Not a backup. You don't want a backup to save the junk. Oh, yes I do. A backup is a record of exactly how things were. > You want >a clean save so you don't have to deal with errors you've already >eliminated. No, you want an exact image. >> You don't want a back up >>program to pretend it knows what is not important enough to save. > >You want the backup program to be versatile enough so that the >person issuing the commands to the program can have the choices >of what and how a backup should be done. Absoulutely not. People are always morons. You never trust them to decide what should be saved. They will always save the wrong stuff and then whine about it later. >> You >>want a complete record. > >Not always. Always. [....] >>Now we are getting to the subject of repair. This is a more complex >>subject than just making backups. This is why I suggested that the data >>be on a different disk. This means you know most of what needs to be >>copied right away. For programs you may be in for a lot of work. On the >>Windows OS, the installed programs step all over each other. If you have >>been a good person, you will still have the install disks and know which >>order they got installed to make a running system. > >Look, either you're doing a file backup or you're doing a 100% bit-to-bit >copy of the disk. Your last paragraph has just switched to the >file backup. You seem still not to understand that a 100% bit for bit copy is a backup. It is the best backup to do all others are incomplete. [....] >>>It can be many things. The OS has a bug; the network has a bug; >>>your apps created an environment that causes the glitch in cooperation >>>with timing, the phase of the moon, and other events. >> >>You mean a bug, a bug, a bug and perhaps a hardware problem. > >Or a software aspect that breaks the hardware. Like I said: a bug, a bug, a bug and perhaps a hardware problem. Hardware does certain things when told to do so by software. If the software told it to do something the documentation said it should not be asked to do then this is a bug, if the hardware did not do what the documentation said it would this is a hardware problem. [....] >>Now you are just being silly. You haven't been able to say how it is more >>complex because it isn't it is the speed that has increased. > >If rates of events increase, you have enormous complexity. Nope. > An analogy >is automobile traffic. Bad analogy. A better analogy is a giant squid. > If the road capacity is filled 100%, getting from >here to there becomes extremely complex. If the road has no traffic >on it, the trip isn't difficult at all. The driving analogy is a bad one and leads to wrong conclusions. A better one is that when a giant squid swims faster, it doesn't grow any extra eyes. [....] >>You think you see that. Now what is it that is really happening? You saw >>a light blink on your modem, I assume. > >Yes. and I didn't request downloads. So if stuff is happening without >my permission, I throw the power switch. The light blinked without your permission. Beyond that point you are just assuming. [....] >>>I am talking about the application I referred to in another post. >>>It was called SABRE. It was probably the first computer aided >>>transaction processing system. >> >>What was the date? There was one that I know of in 1972. > >I think it was around that time. Watching that application >and how it evolved would be intersting. I believe that it is where much of what the banks use today got its start. At that time it was all going down dedicated phone lines. >>Like I thought you have none at all. The reason I asked you to name two >>was because I thought I detected the usual blowing smoke trick where you >>imply that you have already proven something at some earlier point in the >>thread. > >I've been discussion three problems, specifially. Anybody who >understood those could think of scenarios in the thousands. > >1. A snapshot of data is useless in restoring a system; example SABRE. No, you are wrong in this. >2. The backup used to restore the system contains the cause of >the system's original demise. This is exactly what a backup should contain if that is what was on the disk. > >3. A file disappears with no detection until long after the backup >tapes have been written over. You are wrong in this too. -- -- kensmith(a)rahul.net forging knowledge
From: Tony Lance on 3 Mar 2007 11:54 Big Bertha Thing pathos Cosmic Ray Series Possible Real World System Constructs http://web.onetel.com/~tonylance/pathos.html Access page JPG 12K Image Astrophysics net ring access site Newsgroup Reviews including uk.rec.cycling Detail from painting of captive musketeers. Caption:- Porthos took hold of a bar (foot rail) with both hands From the book Twenty Years After by Alexandre Dumas Published by George G.Harrup & Co.Ltd., 1923 Reprinted 1929 (C) Copyright Tony Lance 1998 Distribute complete and free of charge to comply. Big Bertha Thing poem Some Days, Then Some by Tony Lance I've had better days, he thought and said. When I could get my sorry butt out of bed. When I wasn't mistook for as good as dead. When they didn't fill my boots with all that lead. There are days sometimes, of sunshine on my head. Windswept shores viewed from along a beachy-head. Carefree larks, in a clearly blue sky, over-head. Then of course, I became a headmaster, the old man said. Tony Lance judemarie(a)bigberthathing.co.uk Sunday, November 16, 1997 05:19:05 PM Message From: Tony Lance Subject: Re(2): Fwd: Big Bertha Thing 5 To: FC Mods Discussion First Big Bertha posting was to first aid tent in CP Conf. to provide aid and comfort to victims who had been set upon by unnamed thugs. There was no way to make direct contact, with shell shocked victims. The trick worked and first victim is well again. Since then she has developed a life of her own and actually caught some thugs in the act. Children will be children. The full set of Big Bertha can be found on CP Conf. Thank you, Tony Lance
From: Ken Smith on 3 Mar 2007 11:55 In article <esbqel$8qk_010(a)s977.apx1.sbo.ma.dialup.rcn.com>, <jmfbahciv(a)aol.com> wrote: >In article <es9g7v$q95$8(a)blue.rahul.net>, > kensmith(a)green.rahul.net (Ken Smith) wrote: [.....] >>>>This is part of the "complex issues" skipped to keep the list short. >>> >>>Do you think that a swapper moves pages from the RAM to the >>>swap file? >> >>If you think otherwise, you don't know what you are talking about. This >>is what "swapping" in a VM system implies. > >It didn't in any VM system JMF implemented. Then JMF was not implementing VM as the term is commonly used in the industry. He obvious implemented something that he called VM. > I'm unaware of >any other OS that used the term in that wasy. In which way? Do you mean correctly as those of us in this argument have been or do you mean is some special JMF way. -- -- kensmith(a)rahul.net forging knowledge
From: Phil Carmody on 3 Mar 2007 12:17
kensmith(a)green.rahul.net (Ken Smith) writes: > In article <esbpio$8qk_004(a)s977.apx1.sbo.ma.dialup.rcn.com>, > <jmfbahciv(a)aol.com> wrote: > >In article <es9djf$q95$3(a)blue.rahul.net>, > > kensmith(a)green.rahul.net (Ken Smith) wrote: > [....] > >>>You are in error. Last access is an important datum. > >> > >>Please explain exactly how you thing the last access is important. > > > >[This is the piece I inadventently deleted] > > > >> What > >>do you do with this information? > > > >I, the BACKUP programmer, will save all files during an incremental > >that has an access date after the date-time argument of the /SINCE > >switch. > > This makes it no longer an "incremental". I missed that sentence before. BAH's principle seems to be: "Oh no - someone's looked at my holiday photos on my webserver since I last did a backup - I'd better back them up again." How stupid is that? There is no-one in the real world who uses the ill-formed logic that BAH seems to have come up with. I'm amazed that she's still capable of surprising me at how stupid she is. A palooka of the worst sort. Phil -- "Home taping is killing big business profits. We left this side blank so you can help." -- Dead Kennedys, written upon the B-side of tapes of /In God We Trust, Inc./. |