Jihad needs scientists
in [Design]
|
From: Ken Smith on 13 Mar 2007 09:24 In article <et5vdg$8qk_002(a)s887.apx1.sbo.ma.dialup.rcn.com>, <jmfbahciv(a)aol.com> wrote: >In article <et3o1m$rad$2(a)blue.rahul.net>, > kensmith(a)green.rahul.net (Ken Smith) wrote: [....] >>There need not be any increase in the risk. Its all a matter of starting >>with a reasonable OS and not adding buffer over runs. > >There will always be buffer overruns. Only in badly written software using languages without run time checking does it happen. We now have more than enough CPU speed that buffer overruns should be a thing of the past. > The risk of a single system >house site configuration is the lack of redundancy. That is >what makes it dangerous. The danger is not just viral infections >but with users typing at a system which also controls vital >functions within the house. I would never network my PC to my pacemaker. That said, you are assuming that the user runs as root/superuser. I very rarely ever do on my home system. I do it a little more often on the work system but that is because I need to directly fiddle a few hardware things from time to time. -- -- kensmith(a)rahul.net forging knowledge
From: Ken Smith on 13 Mar 2007 10:16 In article <c55a1$45f5eebb$49ecfae$14595(a)DIALUPUSA.NET>, nonsense(a)unsettled.com <nonsense(a)unsettled.com> wrote: >MassiveProng wrote: > >> On Mon, 12 Mar 2007 14:34:47 +0000 (UTC), kensmith(a)green.rahul.net >> (Ken Smith) Gave us: >> >> >>>In article <45F4CF7A.BD6428AD(a)hotmail.com>, >>>Eeyore <rabbitsfriendsandrelations(a)hotmail.com> wrote: >>>[....] >>> >>>>So Mr Expert. Why isn't TTL made on a 40 Volt process ? >>> >>>Thats obvious. Its so there is a market for MOSFET drivers. I still want >>>a PIC made with Supertex's HV CMOS. [....] >Here's a clue for you. High clock rates and complex >high density chips have a significant problem with >heat, When you get up to large CMOS chips, heating is a major issue. I didn't ask for a pentium. Supertex'es process makes for a low leakage current at largish supply voltages. The PIC has PWM outputs. When making a power supply you usually have alreeady put in a heat sink. > the main reason for the ever lowering voltages >in CPU's. Long leads, the essence of distributing >heat sources, slows things down significantly. Actually, I think the heating from leakage current has become a bigger issue. The static leakage current on a Blackfin is over 90mA when running at 1.4V. -- -- kensmith(a)rahul.net forging knowledge
From: Ken Smith on 13 Mar 2007 10:21 In article <et5un4$8ss_002(a)s887.apx1.sbo.ma.dialup.rcn.com>, <jmfbahciv(a)aol.com> wrote: >In article <et3pbr$rad$7(a)blue.rahul.net>, > kensmith(a)green.rahul.net (Ken Smith) wrote: >>In article <et39hp$8ss_003(a)s948.apx1.sbo.ma.dialup.rcn.com>, >> <jmfbahciv(a)aol.com> wrote: >>>In article <et1957$ki3$2(a)blue.rahul.net>, >>> kensmith(a)green.rahul.net (Ken Smith) wrote: >>>>In article <et0oi0$8qk_003(a)s776.apx1.sbo.ma.dialup.rcn.com>, >>>> <jmfbahciv(a)aol.com> wrote: >>>>>In article <esuqfn$ds3$5(a)blue.rahul.net>, >>>>> kensmith(a)green.rahul.net (Ken Smith) wrote: >>>>[....] >>>>>>No, you are making the same mistake over and over. As I stated before, if >>>>>>you know what you are going to put into TAPE.DIR, you can make its >>>>>>checksum correct. No editing of a magnetic tape was needed by the >method. >>>>> >>>>>Then that TAPE.DIR was not made by taking a directory of the >>>>>tape. That was not the purpose of the file. If I had to do >>>>>it the way you suggested, I wouldn't put the file on the tape >>>>>since it would be a waste of tape space. >>>> >>>>So now you are suddenly changing your story and saying that editing of the >>>>tape was done. >>> >>>There was no tape editing done. >> >>In that case. The tape had to be written with the TAPE.DIR in place and >>correct on the first pass. > >This is the point. It will never be "correct" because the file >contains a checksummed listing of itself. > ><snip> > >Do the exercise. Then you will see what I'm talking about. Bin thar, dun that, got t-shirt, wore out t-shirt. I've done it. The idea wasn't new when I did. You just haven't understood a very simple concept. -- -- kensmith(a)rahul.net forging knowledge
From: Ken Smith on 13 Mar 2007 10:33 In article <et5v7k$8qk_001(a)s887.apx1.sbo.ma.dialup.rcn.com>, <jmfbahciv(a)aol.com> wrote: [....] >>Did you write a TAPE.DIR onto the tape after the tape had already been >>written? > >No. One of my requirements was that the file be the first in >the saveset. In other words, you created it based on what you intended to write to the tape not what you actually wrote. This contradicts what you said earlier. It doesn't matter because the suggested method still works. The checksum could still have been correct. > >> >>If the answer is yes, you edited the tape. In this case the method works. >> >>If the answer is no then you can no longer argue that the TAPE.DIR is the >>list of what is actually on the tape. It must be the list of what you >>intend to put on the tape. You have claimed that this is not allowed, but >>the method still works for this too. > >The file was made by doing a directory of the tape. >> >>No matter which you did, the checksums can be correct. > >No, they cannot. The requirement was that TAPE.DIR be a directory >of the tape and not a made-up list. Yes they can, it can and once again you are contradicting what you said above. Either the TAPE.DIR was made after the tape was written or it was not. If it was not, then it was not a list of what was actually written. In that case is must be a list of what you intend to write. If the list existes before the write is done, then it is not a list of what was written. It simply can't be unless you have a time machine. It doesn't matter which order it was done in because, as I pointed out earlier, I have explained how the TAPE.DIR can have the correct checksum in all cases. You have just not understood the point. >>You have changed what you have claimed. Suddenly, the TAPE.DIR is not a >>file on the tape and is a part of the contents of a file on the tape, > >TAPE.DIR is a file on the tape AND it is part of the contents >of the saveset (which is the physcial magtape file). Are you saying there are two copies or are you saying that you wrote everything in one big file? It really doesn't matter because in either case, the checksum could be correct but I am curious. > ><snip. > >>I see that I can and have done exactly that in the past. > >No, you have not done a similar thing. Actually yes I have. >> I have explained >>how to do it a few times. You seem unable to graps it. I've used it. >>Remember I have written tapes too. > >You may have copied files to tapes but you have not made a distribution >according to the spec we used. Perhaps I have never made a tape based on the spec you used but I have explained how you could have made one that followed that spec that had a correct checksum. >>[....] >>>Then that file was saved along with all the other files onto the tape. >> >>Wait a minute! Suddenly TAPE.DIR is the list of what you intend to write >>onto the tape. Your story has changed. You earlier asserted that it must >>be made from what you actually wrote. Which is it? > >It is both. That is why a CATCH-22 exists. There is no CATCH-22. The checksum could have been right. >>Not that it matter which it was because as I have already stated, I have >>explained how you can get it right in either case. > >Your method had each disk file copied to the tape. That is not >how our files were shipped. A saveset was the tape's file. There >were no EOFs between the files we distributed. This doesn't change a thing. I was and still am trying to explain to you how the checksum could have been correct on those tapes. In fact, you composed the TAPE.DIR based on what you intended to write. when you made this TAPE.DIR it could have had a correct checksum in it, for each file. The checksum for TAPE.DIR can be correct as I have explained. -- -- kensmith(a)rahul.net forging knowledge
From: Phil Carmody on 13 Mar 2007 10:41
jmfbahciv(a)aol.com writes: > In article <et3o1m$rad$2(a)blue.rahul.net>, > kensmith(a)green.rahul.net (Ken Smith) wrote: > >There need not be any increase in the risk. Its all a matter of starting > >with a reasonable OS and not adding buffer over runs. > > There will always be buffer overruns. Don't judge all programmers based on your own inadequacy as one. 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./. |