Jihad needs scientists
in [Design]
|
From: nonsense on 2 Mar 2007 10:32 Ken Smith wrote: > In article <e569b$45e79d2a$49ecf5e$12334(a)DIALUPUSA.NET>, > nonsense(a)unsettled.com <nonsense(a)unsettled.com> wrote: > >>Ken Smith wrote: >> >> >>>In article <5685e$45e760f9$4fe7431$8325(a)DIALUPUSA.NET>, >>>nonsense(a)unsettled.com <nonsense(a)unsettled.com> wrote: >>> >>> >>>>Phil Carmody wrote: >>>> >>>> >>>> >>>>>kensmith(a)green.rahul.net (Ken Smith) writes: >>>>> >>>>> >>>>> >>>>>>>ls -lu >>>>>> >>>>>>I assume you had a point. >>>> >>>>snip blather >>>> >>>> >>>> >>>>>So his point wasn't worth getting. >>>> >>>>Every time you touch a file it is written to. >>>> >>>>Touching a file is sufficient to introduce error. >>> >>> >>>The backup method I have been suggeting has no such problem. Making an >>>image of a drive does not risk changing its contents. >>> >>>BTW: Since the time is not stored within the body of the file, the >>>sectors that contain the body of the file are not written. It is only the >>>directory information that is updated. You can have an error in that >>>sector. >> >> >>So directory all errors are of no concern to you then. > > > No, I didn't say this. Remember that my suggested method of doing a > backup is to image the entire drive. The error that is the hardest to > spot is a file that now has different contents than before but not the > correct contents. > > Changes to the directory information that matter are easily detected and > aren't cancerous like errors in databases can be. The directory *is* a database. Scribble your pointer and have fun finding your file. Even more fun if it points to the middle of some other similar database file.
From: Ken Smith on 2 Mar 2007 10:34 In article <es9csr$8qk_001(a)s793.apx1.sbo.ma.dialup.rcn.com>, <jmfbahciv(a)aol.com> wrote: >In article <es848a$2hl$4(a)blue.rahul.net>, > kensmith(a)green.rahul.net (Ken Smith) wrote: >>In article <es6mqn$8qk_001(a)s985.apx1.sbo.ma.dialup.rcn.com>, >> <jmfbahciv(a)aol.com> wrote: >>>In article <es0bs3$joa$1(a)blue.rahul.net>, >>> kensmith(a)green.rahul.net (Ken Smith) wrote: >>[....] >>>>Where in the anual report? I can't find any such statement in there. >>> >>>Intel is divided into divisions. Compare each division. The one >>>that has the controller product line does more business than the >>>one that has the PC product line. >> >>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. [.....] >>Now we can perhaps start to talk about repairing a system. Problems are >>often like cancers. A problem with a file can cause a database to get >>worse over time. If you back up to the one where the damage is limited, >>you can then repair the file at fault and start working forwards. You >>also have the option of going back to an even earlier version and starting >>there. > >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. > It's too >complicated to go into detail. Obviously the above isn't. > Now consider that a virus is >in the midst of your files you are going to restore. Yes, I've considered it. The statements I've made have all been checked and are still correct with this consideration. [....] >>For a Microsoft system, the only option that works is a bit by bit image >>of the hard drive made by some non-Microsoft code. > >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. You don't want a back up program to pretend it knows what is not important enough to save. You want a complete record. >>The OS refuses to let >>you back up some of the important stuff. Since it is Windows and not >>Linux, we know that the system was not in the state it should be for the >>get go. The best you can do is put the mess back the way it was. > >And what if the source of the problem is the way it was? Then you have restored the system to the way it was. This is what "restore" means. It is a different word from "repair" or "correct". >> >>On a Windows system, you always want to keep your data on a different >>drive than the OS. This make backing up the good stuff much easier. > >How do you separate the data from the OS when windows has the >annoying habit of merging both? Go read what I wrote. You can direct all well written Windows programs about where to put their data. There are very few that won't let you. I am not arguing that Windows is less than a dreadful OS. I am suggesting how to make the best of a bad situation. >>When a Microsoft system goes very bad the first thing to try is restoring >>to the previous image. This doesn't mean that you have really fixed the >>problem but it does let you see if the previous version would work at all. >>You may have one of those rare cases where the hardware has failed. >> >>Very often you are forced to reinstall a bunch of software and then copy >>the data back in from the backup. > >How are you going to choose which files to copy from the backup if >it's bit-by-bit save of the disk? You can't. 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. [....] >>> What if it >>>is a problem that you can't control? >> >>What do mean by that? > >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. > >> Assuming you mean some bit of software that simply >>takes it in its head to mess things up from time to time, there are still >>things that you can do. All such things are very ugly. > >Some days, problems can happen with the position of a certain pattern >of bits in a particular location of memory. Yes, this is what I said. [....] >>This doesn't increase complexity. It only increases speed. > >How quickly can you stop a semi truck going at the speed of light >in a vacuum? Start your timing just notice a 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. >>> Most of the time we could hit the >>>panic button and physically shut down a runaway system. >> >>That was always a near useless option. > >You are telling me that this was useless? I still pull the plug >when I see somebody sniffing my bits over the net. You think you see that. Now what is it that is really happening? You saw a light blink on your modem, I assume. [....] >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. >>>oh, jezusfuckinghchrist. Go back and read the posts. >> >>Like I thought. You don't have 2. > >We had thousands. 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. -- -- kensmith(a)rahul.net forging knowledge
From: Ken Smith on 2 Mar 2007 10:35 In article <es92nu$8ss_004(a)s1006.apx1.sbo.ma.dialup.rcn.com>, <jmfbahciv(a)aol.com> wrote: >In article <es84ft$5ks$1(a)blue.rahul.net>, > kensmith(a)green.rahul.net (Ken Smith) wrote: >>In article <87y7mhb0fx.fsf(a)nonospaz.fatphil.org>, >>Phil Carmody <thefatphil_demunged(a)yahoo.co.uk> wrote: >> >>[.... swapping ...] >>>Wrong. If it's not moved onto the swap medium, it's lost. >>>My kind of computing doesn't like losing data, yours might, >>>but as we know BAH computing is BAD computing. >> >>This is almost exactly right. The write to the swap volume is only needed >>if the page is dirty (ie: has been written to) >> >>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. > >/BAH -- -- kensmith(a)rahul.net forging knowledge
From: Ken Smith on 2 Mar 2007 10:39 In article <b6eee$45e843a7$49ecfd0$19214(a)DIALUPUSA.NET>, nonsense(a)unsettled.com <nonsense(a)unsettled.com> wrote: >Ken Smith wrote: >> In article <e569b$45e79d2a$49ecf5e$12334(a)DIALUPUSA.NET>, >> nonsense(a)unsettled.com <nonsense(a)unsettled.com> wrote: >> >>>Ken Smith wrote: >>> >>> >>>>In article <5685e$45e760f9$4fe7431$8325(a)DIALUPUSA.NET>, >>>>nonsense(a)unsettled.com <nonsense(a)unsettled.com> wrote: >>>> >>>> >>>>>Phil Carmody wrote: >>>>> >>>>> >>>>> >>>>>>kensmith(a)green.rahul.net (Ken Smith) writes: >>>>>> >>>>>> >>>>>> >>>>>>>>ls -lu >>>>>>> >>>>>>>I assume you had a point. >>>>> >>>>>snip blather >>>>> >>>>> >>>>> >>>>>>So his point wasn't worth getting. >>>>> >>>>>Every time you touch a file it is written to. >>>>> >>>>>Touching a file is sufficient to introduce error. >>>> >>>> >>>>The backup method I have been suggeting has no such problem. Making an >>>>image of a drive does not risk changing its contents. >>>> >>>>BTW: Since the time is not stored within the body of the file, the >>>>sectors that contain the body of the file are not written. It is only the >>>>directory information that is updated. You can have an error in that >>>>sector. >>> >>> >>>So directory all errors are of no concern to you then. >> >> >> No, I didn't say this. Remember that my suggested method of doing a >> backup is to image the entire drive. The error that is the hardest to >> spot is a file that now has different contents than before but not the >> correct contents. >> >> Changes to the directory information that matter are easily detected and >> aren't cancerous like errors in databases can be. > >The directory *is* a database. Scribble your pointer and have >fun finding your file. Even more fun if it points to the middle >of some other similar database file. This is a lot easier to detect than a byte somewhere in the file being wrong. The problem in doing a repair is usually more of a question of finding the defects than correcting them. -- -- kensmith(a)rahul.net forging knowledge
From: MassiveProng on 2 Mar 2007 12:05
On Fri, 02 Mar 2007 05:30:34 -0600, "nonsense(a)unsettled.com" <nonsense(a)unsettled.com> Gave us: >Phil Carmody wrote: > >> "nonsense(a)unsettled.com" <nonsense(a)unsettled.com> writes: >> >>>Phil Carmody wrote: >>> >>> >>>>kensmith(a)green.rahul.net (Ken Smith) writes: >>>> >>>> >>>>>>ls -lu >>>>> >>>>>I assume you had a point. >>> >>>snip blather >> >> >> i.e. you didn't understand. >> >> >>>>So his point wasn't worth getting. >>> >>>Every time you touch a file it is written to. >> >> >> a) We weren't talking when you touch a file, assuming you know >> what 'touch' is, which isn't likely given your general ignorance. >> b) You're wrong, for one of the reasons explained clearly in the >> 'blather' that you didn't understand. >> >> >>>Touching a file is sufficient to introduce error. >> >> >> See 'b' above. > >Your blustering arrogance has no foundation. Too bad, you >do the verbiage so well. > Face it. You are wrong, dumbass. |