My point was the somewhat muddy origin of exactly how closely (some parts of) CP/M was copied into MS-DOS, née QDOS. There's some quote attributed to Kildall during the mid-80s where he claimed that there were certain pecularities in the code, that he bet no person at MS could explain, pecularities that "shouldn't" have been there in a clean reversee engineering process.
There are lots of patents on refined procedures for ready-made food, some of which are little more than recipes. As they are written for the scale of mass production, they're naturally often related to how to keep the process stable and efficient at that scale, but it's still nothing more than a very detailed description on how to make tasty/healthy/durable food.
Are you saying that we don't get energy out of the H bomb? Or do you state that it's inherently fram from breakeven? I mean, you could envision just creating enormous amounts of steam or something, by successive detonations. It wouldn't be practical, but I don't think thermodynamics will bite you.
On the other hand, the real payoff of low latency won't surface if every operation means going through a driver, which only then realizes "oh, I have a single instruction for this thing, let's head back to the caller". This means that game writers will either still need to batch up complex operations, that the driver will then translate into batches of suitable instructions, or that we'll see games/applications with radically different codepaths. Any attempt to benefit optimally from the integrated approach will perform badly on a separate card, while code tuned to a separate card won't come close to harnessing the good points of an underpowered, but lower latency, local graphics implementation.
It's almost like they would add L3 in a non-transparent manner, that is, expecting the developers to write the code moving suitable data into the cache and addressing that data in a radically different manner, while still also supporting the normal style of memory access, where you of course need to care about the cache, but not so explicitly. (The Cell's explicit local RAM for each unit, and the whole design of that beast, comes to mind. At least ALL PS3s will have one, but the expected target market for Fusion-only adaptations is much less clear cut.)
And, yeah, this is quite like the situation almost ten years ago, when 3D cards were hot and new. Writing a pipeline to feed those cards was quite different from rolling your own hacked-up software rendered. (And with T&L and shaders, the move has been even greater.)
But maybe then I'm just speculating a bit too much here. It would make sense that AMD is designing these instructions to fit into the existing driver model (or at least the DX10 one), so that you can get pretty good performance by just doing the relevant translation there.
The real problem is of course, as with all code-protection/signing schemes: what about valid uses for modifying the hardware, to allow overclocking, fixing some bug. What might make sense in some configs would be a common physical "write-enable" switch on the machine. Sensible cards could be made to read that switch, while not attempting to verify the code itself.
(This could of course be developed further, allow flashing properly signed material even with write disabled, but let the hackers go ahead when they've confirmed it by a physical action.)
Viral transfer is not that common, from our current understanding. Yes, it happens quite frequently, but the chances of it entering the germ line nearly means that you need to be infected while you are still a fetus in the womb of your mother, and it is still a matter of chance that the integration should go well, and that the gene would be carried away at all. There is very little hard evidence on basic factors, like chromosome count, of Neanderthals. We have the mtDNA results, which could indicate infertility when the mother was non-sapiens. But, IF even one in a thousand attempts was fertile (a suitable chromosome "defect" in the Neanderthal contribution might fix that), that "freak" individual would carry thousands of Neanderthal genes into the gene pool, while each retroviral integration event would carry one or two, and possibly be far more unlikely to happen altogether.
That basically tells us that neanderthal females didn't bear children from human (I mean Homo sapiens sapiens, obviously the neanderthals were also human in a somewhat different manner) fathers, or at least that those children don't have any descendents nowadays. Neanderthal males swinging around wouldn't effect our mtDNA.
On the other hand, we already know that GPUs and CPUs separate pretty well. The APIs are rather batch-based, right now out of necessity, so you can separate them. When we already have some airflow within the HTPC system, it's not too obvious that it's a good thing to integrate even more processing power onto the same die. Cooling that one might actually be harder than cooling the discrete components. At the very least, it makes sense to keep integrated graphics in the chipset, rather than the CPU.
I guess someone will start shouting about the glorious benefits of sharing the cache. I don't think that's too relevant, since a CPU cache is designed to be great at associativity and random accesses (and accepting writes to just about any data, ignoring the instruction cache). GPU caches is a tightly hold secret, but while they exist, they are rather small relative to the enormous bandwidth requirements of refreshing a frame buffer umph times per second, and there is probably a quite strict distinction of read-only and RW. It's not just a matter of adding "GPU instructions" to the existing instruction set, we already have SIMD. GPUs are extremely scalable SIMD machines, with a very different design tradition.
One significant problem when doing game code is that you have to keep that > 50 FPS frame rate. In such an environment, context switches can be a killer on their own. If you just go ahead and write a schoolbook threaded design, it might work on a quad-core chip, but it will perform far worse on a single-core chip compared to the single-threaded design. You can naturally avoid the context switcehs by serializing the calls again, but then you realize that you don't really need to copy around all that data for synchronization of a problem that isn't there.
I would hazard to guess that the transition would be faster if noone felt the need to target single-core chips. Synchronization is not simple, but it's not hard. Good response times without jittering is not simple, but it's not hard. Combining the two over different processing power layouts, that's hard. Or at least harder.
I was wondering the same thing, but I think your quote makes it quite clear. The enhanced configuration is basically an IE which won't allow scripts, won't allow ActiveX and by consequence won't be affected. It's fully possible to turn off that protection in Windows 2003, and the default in XP64, being a client operating system, is the normal client settings. Hence, we would be vulnerable. OTOH, when you are running the 64-bit build of IE, I would suppose that the existing exploits won't work. As the stack layout is also different (in addition to the instruction set), it might be very hard/impossible to directly transfer this exploit to those systems. Of course, the 32-bit IE on 64-bit XP still seems just as vulnerable, then.
I was under the impression that the same MSXML code is still used under the hood (any JScript object in IE is a COM/ActiveX object, you just create them or get references to them in different ways), so depending on the actual exploit, I wouldn't be so sure that your bandaid will solve it. It should solve it for IE6SP2, though, but at the cost of disabling all AJAX.
That was the last one that really corrupted my documents badly. It was a rather significant rewrite from the 95 suite. The range up to 2003 contains minor tweaks, and I've never found a reason to prefer a previous release in that series, unless performance/workset size has been a real issue. On the other hand, one line of improvement that won't affect U.S. users is the overall quality of the non-English lingual resources, where some very significant improvements have been made(/acquired) for some languages.
However, IQ is a rather accepted method to quantify intelligence, and some definitions of IQ contain the normal distribution as a totally inherent part of the definition. If we wouldn't get a normal distribution in the end, for the complete population, then the test is not calibrated correctly.
A Pocket PC can certainly download a few MBs worth without hurting the uptime that badly, given that you turn it (the wifi) off afterwards. It's a bit like having a HD in the iPod in the first place, it sucks power, so keep it on only when needed.
It makes sense if your swap is significantly faster than the original store for your code, which I think was the point of the parent. This includes scenarios with net-booted clients (/blade servers) that still have some kind of local secondary storage for exactly swap and other temporary uses.
On the other hand (which I guess was the grandparent's original intent), wonn't human casthrates, just like many other mammals, frequently develop obesity, or at least a significant shift in the distribution of fat, compared to healthy/normal males?
From what? Nuclear reactions? The very point is that they think that the amounts found here are consistent with inorganic extraction from minerals. You can of course stipulate that the conditions that made those reactions favorable were created by life, but there is nothing that indicates that. If there was life with a different chemistry, the current results make it just as likely that this form of life was indifferent to phosporus.
What do you have in mind? You might do separate heaps on a per-socket basis, rather than per-thread or common to all (the most common options today), but the JVM itself is not exactly something you easily make parallel.
Well, the previous IE team was basically disbanded, with people going to work on Office, Visual Studio and WPF/Avalon/XAML. Two of these are very popular and can, in their own way, surely be considered on par or superior to the competition. (Visual Studio is a nice IDE even for non-Windows development.) It's not a matter of trying for six years and failing, but rather starting quite late, with a team that's still smaller than it was when Trident was first developed. This of course only shifts the blame within MS, from developer incompetence to management incompetence, or arrogance.
OTOH, the Earth, from space, is not unaffected by the reflections and absorptions through the atmosphere, i.e. things might well tend to be more bluish.
Slashdot Mirror
My point was the somewhat muddy origin of exactly how closely (some parts of) CP/M was copied into MS-DOS, née QDOS. There's some quote attributed to Kildall during the mid-80s where he claimed that there were certain pecularities in the code, that he bet no person at MS could explain, pecularities that "shouldn't" have been there in a clean reversee engineering process.
Does that include the 180 day (or whatever it is) timebomb?
You can't sell CP/M if you don't own it. *mutter*Gary Kildall*mutter*unexplainable dollar sign*mutter*
Ehum, only if sound travelled 1 meter per second in air. Hint: it doesn't. It's more like 340, hence the frequency is 50 * 340 = 17,000 Hz.
He wants M5 transported back to the 23rd century, on the double.
There are lots of patents on refined procedures for ready-made food, some of which are little more than recipes. As they are written for the scale of mass production, they're naturally often related to how to keep the process stable and efficient at that scale, but it's still nothing more than a very detailed description on how to make tasty/healthy/durable food.
Are you saying that we don't get energy out of the H bomb? Or do you state that it's inherently fram from breakeven? I mean, you could envision just creating enormous amounts of steam or something, by successive detonations. It wouldn't be practical, but I don't think thermodynamics will bite you.
It's almost like they would add L3 in a non-transparent manner, that is, expecting the developers to write the code moving suitable data into the cache and addressing that data in a radically different manner, while still also supporting the normal style of memory access, where you of course need to care about the cache, but not so explicitly. (The Cell's explicit local RAM for each unit, and the whole design of that beast, comes to mind. At least ALL PS3s will have one, but the expected target market for Fusion-only adaptations is much less clear cut.)
And, yeah, this is quite like the situation almost ten years ago, when 3D cards were hot and new. Writing a pipeline to feed those cards was quite different from rolling your own hacked-up software rendered. (And with T&L and shaders, the move has been even greater.)
But maybe then I'm just speculating a bit too much here. It would make sense that AMD is designing these instructions to fit into the existing driver model (or at least the DX10 one), so that you can get pretty good performance by just doing the relevant translation there.
The real problem is of course, as with all code-protection/signing schemes: what about valid uses for modifying the hardware, to allow overclocking, fixing some bug. What might make sense in some configs would be a common physical "write-enable" switch on the machine. Sensible cards could be made to read that switch, while not attempting to verify the code itself. (This could of course be developed further, allow flashing properly signed material even with write disabled, but let the hackers go ahead when they've confirmed it by a physical action.)
Why can't we postulate that some famous advances in room-temperature superconductors will have been made at the when the cable itself is feasible?
That basically tells us that neanderthal females didn't bear children from human (I mean Homo sapiens sapiens, obviously the neanderthals were also human in a somewhat different manner) fathers, or at least that those children don't have any descendents nowadays. Neanderthal males swinging around wouldn't effect our mtDNA.
I guess someone will start shouting about the glorious benefits of sharing the cache. I don't think that's too relevant, since a CPU cache is designed to be great at associativity and random accesses (and accepting writes to just about any data, ignoring the instruction cache). GPU caches is a tightly hold secret, but while they exist, they are rather small relative to the enormous bandwidth requirements of refreshing a frame buffer umph times per second, and there is probably a quite strict distinction of read-only and RW. It's not just a matter of adding "GPU instructions" to the existing instruction set, we already have SIMD. GPUs are extremely scalable SIMD machines, with a very different design tradition.
I would hazard to guess that the transition would be faster if noone felt the need to target single-core chips. Synchronization is not simple, but it's not hard. Good response times without jittering is not simple, but it's not hard. Combining the two over different processing power layouts, that's hard. Or at least harder.
I was wondering the same thing, but I think your quote makes it quite clear. The enhanced configuration is basically an IE which won't allow scripts, won't allow ActiveX and by consequence won't be affected. It's fully possible to turn off that protection in Windows 2003, and the default in XP64, being a client operating system, is the normal client settings. Hence, we would be vulnerable. OTOH, when you are running the 64-bit build of IE, I would suppose that the existing exploits won't work. As the stack layout is also different (in addition to the instruction set), it might be very hard/impossible to directly transfer this exploit to those systems. Of course, the 32-bit IE on 64-bit XP still seems just as vulnerable, then.
I was under the impression that the same MSXML code is still used under the hood (any JScript object in IE is a COM/ActiveX object, you just create them or get references to them in different ways), so depending on the actual exploit, I wouldn't be so sure that your bandaid will solve it. It should solve it for IE6SP2, though, but at the cost of disabling all AJAX.
That was the last one that really corrupted my documents badly. It was a rather significant rewrite from the 95 suite. The range up to 2003 contains minor tweaks, and I've never found a reason to prefer a previous release in that series, unless performance/workset size has been a real issue. On the other hand, one line of improvement that won't affect U.S. users is the overall quality of the non-English lingual resources, where some very significant improvements have been made(/acquired) for some languages.
However, IQ is a rather accepted method to quantify intelligence, and some definitions of IQ contain the normal distribution as a totally inherent part of the definition. If we wouldn't get a normal distribution in the end, for the complete population, then the test is not calibrated correctly.
A Pocket PC can certainly download a few MBs worth without hurting the uptime that badly, given that you turn it (the wifi) off afterwards. It's a bit like having a HD in the iPod in the first place, it sucks power, so keep it on only when needed.
It makes sense if your swap is significantly faster than the original store for your code, which I think was the point of the parent. This includes scenarios with net-booted clients (/blade servers) that still have some kind of local secondary storage for exactly swap and other temporary uses.
On the other hand (which I guess was the grandparent's original intent), wonn't human casthrates, just like many other mammals, frequently develop obesity, or at least a significant shift in the distribution of fat, compared to healthy/normal males?
From what? Nuclear reactions? The very point is that they think that the amounts found here are consistent with inorganic extraction from minerals. You can of course stipulate that the conditions that made those reactions favorable were created by life, but there is nothing that indicates that. If there was life with a different chemistry, the current results make it just as likely that this form of life was indifferent to phosporus.
What do you have in mind? You might do separate heaps on a per-socket basis, rather than per-thread or common to all (the most common options today), but the JVM itself is not exactly something you easily make parallel.
Well, the previous IE team was basically disbanded, with people going to work on Office, Visual Studio and WPF/Avalon/XAML. Two of these are very popular and can, in their own way, surely be considered on par or superior to the competition. (Visual Studio is a nice IDE even for non-Windows development.) It's not a matter of trying for six years and failing, but rather starting quite late, with a team that's still smaller than it was when Trident was first developed. This of course only shifts the blame within MS, from developer incompetence to management incompetence, or arrogance.
OTOH, the Earth, from space, is not unaffected by the reflections and absorptions through the atmosphere, i.e. things might well tend to be more bluish.