Jihad needs scientists
in [Design]
|
From: jmfbahciv on 21 Feb 2007 07:31 In article <erf2nv$39q$7(a)blue.rahul.net>, kensmith(a)green.rahul.net (Ken Smith) wrote: >In article <ereo6m$8ss_009(a)s883.apx1.sbo.ma.dialup.rcn.com>, > <jmfbahciv(a)aol.com> wrote: >>In article <87irdym3zz.fsf(a)nonospaz.fatphil.org>, >> Phil Carmody <thefatphil_demunged(a)yahoo.co.uk> wrote: >>>Eeyore <rabbitsfriendsandrelations(a)hotmail.com> writes: >>>> MassiveProng wrote: >>>> >>>> > I can boot Linux from a DVD and RUN it all day long, and I don't need to >>do >>>> > ANY installation! >>>> >>>> That sounds interesting. >>>> >>>> Where can I get one ? >>> >>>Ubuntu, Kubuntu, Xubuntu all come as live CDs >>>Gentoo does too. >>>Knoppix was the original popular live CD. >> >>What does the OS, running from a CD, use for its scratch pad? >><snip> > >It uses the RAM of the computer. They like to have quite a lot of RAM. A RAM can't be the scratchpad. That would slow down processing enormously. /BAH
From: jmfbahciv on 21 Feb 2007 07:35 In article <ergbsm$jtg$4(a)blue.rahul.net>, kensmith(a)green.rahul.net (Ken Smith) wrote: >In article <ereobj$8ss_010(a)s883.apx1.sbo.ma.dialup.rcn.com>, > <jmfbahciv(a)aol.com> wrote: >>In article <ercret$dg2$1(a)blue.rahul.net>, >> kensmith(a)green.rahul.net (Ken Smith) wrote: >>>In article <erc8n2$8ss_006(a)s942.apx1.sbo.ma.dialup.rcn.com>, >>> <jmfbahciv(a)aol.com> wrote: >>>>In article <877iufp05h.fsf(a)nonospaz.fatphil.org>, >>>> Phil Carmody <thefatphil_demunged(a)yahoo.co.uk> wrote: >>>[....] >>>Unfortunately the hardware in the x86 series of processors makes it hard >>>to do a general purpose VM that doesn't thrash a lot. If the problem is >>>too big to fit in real memory, doing the disk I/O in the program instead >>>of letting the VM take over usually make for a faster result. >> >>A solution is to invent a software GETSEG if the hardware can't >>give help. > >You can usually work out before hand what needs to be in memory when. You can do this only if the directives are in a script or the machine is dedicated to one task and the process has been debugged. You can not ever predict what will be required if any human has access to the system. >This way, the swapping action is always the best one instead of pot luck. >A simple case is when you are sorting a huge file. The first step is to >sort the biggest hunks that will fit into RAM, after that the code is a >classic merge operation. For each part it is fairly easy to see what >needs to be in RAM. You are still thinking in single-use mode. That situation is becoming rarer even on PCs. I've been trying to point that out throughout this particular thread drift. > /BAH
From: jmfbahciv on 21 Feb 2007 07:36 In article <9NydnaIENPhTkkbYnZ2dnUVZ8vidnZ2d(a)pipex.net>, "T Wake" <usenet.es7at(a)gishpuppy.com> wrote: > >"Ken Smith" <kensmith(a)green.rahul.net> wrote in message >news:erf1cd$39q$3(a)blue.rahul.net... >> In article <ereol0$8ss_011(a)s883.apx1.sbo.ma.dialup.rcn.com>, >> <jmfbahciv(a)aol.com> wrote: >> [....] >>>Tell me which newsgroup should be deleted. The poster didn't say. >> >> I think it was alt.the.big.whiners > >and alt.unable.to.ignore.threads Since you are the one who has been adding them, I suggest dropping the stones. /BAH
From: jmfbahciv on 21 Feb 2007 07:43 In article <erf0g5$39q$1(a)blue.rahul.net>, kensmith(a)green.rahul.net (Ken Smith) wrote: >In article <ereron$8qk_010(a)s883.apx1.sbo.ma.dialup.rcn.com>, > <jmfbahciv(a)aol.com> wrote: >[......] >>>The reason almost all PCs aren't dually is not because PCs >>>can't be dually, it's because that's what the market wants. >> >>That's not the reason. Devices aren't multi-ported. To have >>an effective multi-CPU general purpose system, all CPUs should >>have hardware access to all devices. > >That is not true. You can have single ported devices in a multiprocessor >system with no problem. Go back and read my analogy about the pop bottle. > Since the device is usually a physical thing, it >can only do one thing at a time and is always slower than the processor. No, this 'always slower than the processor' has been a new phenomena. >A well written OS can deal with this issue with no big problem. I know the problems. An OS can spend 25-50% of its available compute time switching contexts to the CPU that has the physical access to a device. > >> Another limitation is >>no PC systems are sold that can have multiple ttys connected to it. > >The PC I'm typing on can have 2 ttys connected. The one at work can have >4. This isn't the real problem. And the predecessor to NT could deal with a thousand. It is the real problem. The biz has been reduced to small computer thinking in a world that is already doing large computer usage. > >> >>> >>>Those who strive for more than mediocrity in their PC have >>>been able to find duallies quite easily for a decade. >> >>But are the device drivers reentrant? If they aren't, the >>multi-CPU systems aren't as useful as they could be. > >Reentrant drivers are not the issue when the hardware they connect to >isn't. A well written OS will deal with it by letting one or the other >CPU have control of the device while its operations are going on and make >sure the other CPU is doing something elese useful. A well written OS cannot create new hardware paths. It is software and limited to the hardware configurations it runs on. /BAH
From: MassiveProng on 21 Feb 2007 07:56
On Wed, 21 Feb 2007 08:21:38 +0000, Eeyore <rabbitsfriendsandrelations(a)hotmail.com> Gave us: > > >MassiveProng wrote: > >> kensmith(a)green.rahul.net (Ken Smith) Gave us: >> >Eeyore <rabbitsfriendsandrelations(a)hotmail.com> wrote: >> >>Ken Smith wrote: >> >>> <jmfbahciv(a)aol.com> wrote: >> >>> >> >>> >>The reason almost all PCs aren't dually is not because PCs >> >>> >>can't be dually, it's because that's what the market wants. >> >>> > >> >>> >That's not the reason. Devices aren't multi-ported. To have >> >>> >an effective multi-CPU general purpose system, all CPUs should >> >>> >have hardware access to all devices. >> >>> >> >>> That is not true. You can have single ported devices in a multiprocessor >> >>> system with no problem. Since the device is usually a physical thing, it >> >>> can only do one thing at a time and is always slower than the processor. >> >>> A well written OS can deal with this issue with no big problem. >> >> >> >>It'll probably do it better too. It makes no sense at all to hold up a fast CPU >> >>to negotiate I/O commands. >> > >> >That is only true for some meanings of the word "fastest". A special >> >purpose processor may do I/O very fast and could then be said to be the >> >faster one although it is the right one to use for I/O. >> >> Are there not "processor" subsections in the northbridge and >> southbridge chipsets that do this very thing? > >I was just wondering the very same thing. > >Where does a memory controller fit into this scenario for example ? > >Graham VSIS: Very Small Instruction Set. I just made that up, BTW. |