Jihad needs scientists
in [Design]
|
From: MassiveProng on 17 Feb 2007 12:42 On Sat, 17 Feb 07 12:13:32 GMT, jmfbahciv(a)aol.com Gave us: >In article <aaict21nu9t1faaiodh912qu7en2240379(a)4ax.com>, > MassiveProng <MassiveProng(a)thebarattheendoftheuniverse.org> wrote: >>On Fri, 16 Feb 07 12:25:03 GMT, jmfbahciv(a)aol.com Gave us: >> >>> Other >>>than instrumentation, there usually isn't any computing task that >>>has to have the CPU pay attention to it *right now*. >> >> >> A/V stream decoding does. Hell, even MP3 stream decoding does. >> >> When I watch Lost episodes on ABC.com, those streams get a LOT of >>CPU time slices simply because the stream MUST be processed >>continually. > >Son, it is time you learned about buffered mode I/O. > You're an idiot. It doesn't stream directly to the video card. It has to be processed first. The discussion isn't about how the stream may or may not be being buffered, dipshit. It was about CPU time slice priorities.
From: MassiveProng on 17 Feb 2007 12:46 On Sat, 17 Feb 07 12:22:57 GMT, jmfbahciv(a)aol.com Gave us: >When Linux can be installed and used with very little relearning >by any computer owner, then it will cease to be a toy and become >a general purpose tool. It hasn't reached that maturity..yet. >It is getting there rapidly. You're an idiot. I can boot Linux from a DVD and RUN it all day long, and I don't need to do ANY installation! I'd say that that is mile above the rest when the entire OS can be configured at runtime from an autodetection routine. I'd also say that that pretty much makes you an uninformed bullshit artist, at best.
From: MassiveProng on 17 Feb 2007 12:49 On Sat, 17 Feb 07 12:26:44 GMT, jmfbahciv(a)aol.com Gave us: >In article <t3jct2h2m7upjn9dho5vsppe4hb02ukvib(a)4ax.com>, > MassiveProng <MassiveProng(a)thebarattheendoftheuniverse.org> wrote: >>On Fri, 16 Feb 07 14:07:30 GMT, jmfbahciv(a)aol.com Gave us: >> >>> >>>There is a huge difference between tasking and being able to >>>interrupt any task at any time and resuming it seamlessly >>>later and not being able to start another task until the >>>previous one is completely finished including EOFing the >>>files. >> >> >> Batch process mentality bullshit. > >Quite the contrary. Your style of thinking is single-use >concentration of gear. That has been clear since you tried >to correct your elders. > The only thing about your that even comes close to being elder is your resemblance to a dried turd. Aged, yes. An "elder"... not in any way, shape, or form.
From: MassiveProng on 17 Feb 2007 12:49 On Sat, 17 Feb 07 12:29:49 GMT, jmfbahciv(a)aol.com Gave us: >In article <er4gcr$1ln$6(a)blue.rahul.net>, > kensmith(a)green.rahul.net (Ken Smith) wrote: >>In article <er45hl$pkf$1(a)jasen.is-a-geek.org>, >>jasen <jasen(a)free.net.nz> wrote: >>>On 2007-02-15, Ken Smith <kensmith(a)green.rahul.net> wrote: >>> >>>> The DOS mind set was to only do one thing at a time. Some bits of later >>>> versions looked like multitasking was intended but abandoned. Even very >>>> later versions save registers into code space instead of onto the stack. >>> >>>I read that there was a multitasking dos released by Microsoft in >>>Europe. and then there's Deskview and I think Digital Research had >>>a go at multitasking dos too. >>> >>>I played with something called multidos (I think it) was shareware or >>>freeware and faked multitasking somehow. >> >>If you call two tasks "multi", > >I don't :-). > >> I wrote one that worked quite nicely. It >>allowed the user interface task to run while disk I/O and printing etc >>also ran. It was very special purposed so it wouldn't be something to >>market. >> >>It really isn't that hard to create a multitasking system if only one task >>is allowed to touch a given bit of hardware. Mostly you just have to >>change the stack pointer and return from the timer interrupt into the >>other task's context. > >You have a very big IF in that sentence. ;-) As if you would even know.
From: MassiveProng on 17 Feb 2007 12:55
On 17 Feb 2007 15:15:20 +0200, Phil Carmody <thefatphil_demunged(a)yahoo.co.uk> Gave us: >I'm currently running a 500MB LLL reduction on my G5 with 512MB RAM. >I have 72 such reductions to perform. Care to tell me how I could run >all 72 without any of them interfering with the other? Or even 2. Run one on one CPU and one on the other. I used to with SETI at home all the time, and it most certainly DOES double the number of units a day that machine churned out. If you only have a single CPU machine, however, you will not be able to do this. I have been running dually machines (at the personal level) for over 6 years now. They are awesome! |