Intel has stated that they target a similar TDP relative to Yonah, but with about 20 % higher performance. This, of course, means that the ratio desktop : laptop is lowered. The aggressive improvements might mean that the power consumption when idling is going below Yonah, but it will be hard to keep it that way when they raise the FSB in early 2007, as it's harder to downclock that dynamically.
The reports today (Anandtech among others) seem to indicate that their supposedly normal production chips can enter the 3.5 - 4.0 GHz range. As the Core chips totally wipes out Pentium D clock-by-clock, the results are obvious.
The Oblivion tests show all things wrong with this, E6700 and X6800 getting identical (more or less) numbers indicate a GPU bound test, AND they use different settings for the AMD test - as they state that the game was not playable if the higher quality settings were used there.
This MSDN blog post was an interesting read to me. As the writer notes, image processing is a kind of virtual task. But it shows some pretty interesting stuff, IMHO, like the fact that the gap between AMD and Intel (Intel winning in the end) is much smaller at 64-bit. Maybe that should be no surprise, with AMD designing the AMD64 instruction set in tandem with the K8. It's also interesting as it might indicate trends regarding tight loop performances in JITed environments in general. This, like it or not, is becoming more common.
Well, for now, the yields of the fastest Core CPUs is probably low enough that the average price of manufacturing could be higher for the cheapest chips, as they are a necessary part of the process, anyway. On the other hand, I think that the pure manufacturing costs for a (desktop) CPU tend to be quite a bit lower than this -- the big costs are the onetimers in development and investing in fab infrastructure. When that's already in place (for the current chip generation), it makes sense to use the resources available fully.
In beta 2 of NT5/2000, OLE compound files (basically any Office file) could be saved in several streams, but it was removed. I think the main reason was that it didn't work too well with too many applications (like old network clients) assuming only a single stream.
There is no full list of "keywords" for the same reason there is no complete list of file name extensions, any program can choose their own. The only special thing about $DATA is that this is (generally) the default mapping. The IIS bug had little to do with ADS per se, but more to do with how you detect what file a reference goes to, and what you do by default. A possible similar bug would be using the case insensitiveness of the file system, if there was a bug not realizing this in the server. Other bugs that DID exist in IIS at one point were relative paths, including../ in the path would enable to you to go above the virtual root in some situations. I remember reading some unofficial best practice of placing your virtual root on a separate partition, to add a minimal additional protection against any additional bugs of this type.
As UN*X systems have a single file system root, one has to ask: are relative paths a UN*X backdoor?
I think a lot of what you request have been done, to some degree. For example, already in XP SP2, there are automated canaries to reduce the risk of buffer overruns, even if there is a overrun-style bug in the code. IE in Vista runs with a reduced security token (more reduced than other apps in the new type of non-admin login), by default. Some services also runs in a more limited environment than before, reducing the effects of that service being compromised. The firewall is outbound, as well.
A non-admin user has never been able to add keys in any part of the registry. For that matter, as admin, there is also the oddity of for example CurrentControlSet\ENUM, which you've to tweak to get into.
However, I think it's important to recognize that while security in depth is a good thing, it is important to shield at the very entry point as well. Take IE again, as an example. It's nice if an exploit can't install a rootkit or modify your home directory, but if an exploit would even be able to read all your cookies, web cache and favorites, that might be bad enough. This latter option will still happen, as these are perfectly valid operations for a web browser, even if you've a kind of sandbox shielding it from the rest of the system. We can protect system integrity by depth, but protecting user data is much harder, and just about as important in many settings.
I think you make one, big, error: the risk for nuclear warhead detonations might be higher. The risk for global, immediate, and complete retaliation is, IMHO, lower. For example, a nuclear conflict between India and Pakistan was unthinkable 30 years ago. It could happen today, but I can hardly see it escalating to a global scale. The results would be devastating, but not that devastating. The same might be said about the risk for a nuclear or terrorist attack against any single metropolitan area in the western world, versus obliteration of "all" (with some definition of all) of them.
But you still can't CreateRemoteThread yourself into kernel mode. On the other hand, if you have debug and admin rights, you can of course add a driver or poke the memory directly to run kernel code (note: not so easily in XP 64/Vista 64, but that's another story...). So you're basically saying: "nah, nah, I can't tell you anything, but as user with default security settings is root, and root can load drivers, and drivers run in kernel mode, every application is running at a kernel level".
"The emperor is nude, as he can, in fact, take off his own clothes, or at least has the privilege needed to ask one of his servants to do it for him. The fact that he wears clothes all the time is irrelevant."
Please enlighten me how the web browser has kernel level permissions in Windows NT-based systems. It was certainly not a VXD in Win9x (defining only VXD code as kernel might be problematic, but the real problem is that 9x had no well-defined central kernel). I know that IIS does have a kernel part these days (but not back when it was even less secure), to shorten roundtrips for cached requests or something, but that's the server side, not the browser. I actually think Sun tried to advertise a similar addition when Solaris 10 was released.
Regarding DNS, I'm not sure what you actually mean here. The DNS client and DNS server are services, but they are not in kernel. A Windows service does not mean it's in kernel mode. Winsock itself has some kernel thunking, and as name resolution is generally done through Winsock, that might be what you mean.
On the other hand, we always hear our own voice partly through bone-conduction (and that's why this works), so it wouldn't be that drastic to put in external vibrations that way, as well.
Just FYI, if you tried to translate the Swedish way of saying it into English, without much thought, it would come out exactly like that. I would imagine that this can be true for at least some more European languages. The majority of Western civilization (me included) does not produce perfect written English.
IAmTheDave, meet Congo. Congo, meet IAmTheDave. Hint: brutal civil war. Sure, there are some muslims, but they are certainly not a major player. The main conflict in Uganda these days is also a weird "Lord's Resistance Army". No, not on the scale of attacking targets on other contintents, but a major source of suffering under the flag of Christianity. At the very least, they aren't any more muslim than christian. The Rwandian genocide is over a decade ago now, but let me just remind you that the possible religious connection there is again not related to Islam.
Islam might be the fastest growing religion, but it's still generally considered smaller than the Roman Catholic churc alone, and much of the silent and under-reported suffering in sub-Saharan Africa has no connection to it. You're not only non-PC, you're blatantly wrong.
(For the record: I consider my religious beliefs, if any, to be Lutheran.)
When the level is so unacceptable that North Korea receives food aid from the "enemy", something is a bit off. Iran is wealthy and self-sufficient in a completely different way (it isn't that hard to be wealthy if DPRK is your standard), so that's certainly a more complex issue. Regarding nuclear weapons, I would certainly prefer a good enough deal that could deafen Iranian pride, and give access to reactors for power production, but not warheads. They certainly would not be alone in (more or less) voluntarily choosing not to pursue nuclear weapons.
Even after the already mentioned K6, there certainly were times where the only affordable and performant chipset was a VIA offering with definite problems. The 686C southbridge problem, for example, was naturally completely out of control for AMD, and was also used with Intel chips, but it was more common on the AMD ones. I'm mostly mentioning it now as that was also a performance and data corruption problem showing up much more easily in RAID configs and HD-HD transfers in non-RAIDed systems. The Inquirer articles are mentioning Southbridge problems in one sentence, but they do not elaborate conclusively on what chipsets have been tried this time.
(And, yeah, while Intel was most heavily touting RAMBUS, VIA was the primary source for those who were more afraid to overclock 440BX like crazy on the Intel side, as well.)
The actual opcodes are certainly also more compact, which means more room in the L1 instruction cache. I'm not sure how relevant the speed argument itself would be these days, I would have guessed that they would use 1 cycle on average in any case, but maybe with different characteristics regarding register file usage and whatnot. As XOR has been "The" way to do it on x86, I guess it should continue to work well. On the other hand, Netburst suddenly made shifts relatively expensive. As this (XOR y, y) is so common, I would guess that the register dependency analyzer will class this as a "non-dependency". A naive parsing of the instruction would otherwise naturally conclude that CX was an operand used for both reading and writing, and that the instruction would be dependent on any earlier store to CX.
If there is special handling to fix the register assignment, then it's reasonable to guess that the execution of the instruction is never really done as an actual XOR, either. To speculate even further, one could start imagining all kinds of bad things happening if a "pre-parsing" treats all XORs as "reset register" with some kind of pipeline stall taking place when the XOR actually has to be executed. Quite unlikely, but an entertaining idea, at least to me, right now.
My personal "analysis", is that this sounds much more like a DMA issue, either in chipsets, in the processors, or in OSes. Core 2 is doing some speculative prefetching and a quite different cache management scheme, so some naive ideas would be that some piece of code or hardware got away with doing things improperly before, a very rare race condition might have become commonplace. If that's the reason, it might be easy to fix. Of course, it might also mean that the prefetching or cache sharing between the cores (or a couple of other things) are actually faulty...
There are personal vehicles. There should be personal computers. The most fascinating thing is, of course, that quite a lot of people DO play the equivalents of GTA or watch HDTV for far more hours a day than they use Word or Excel.
Ghosting an image, with local storage (maybe some network-based backup) would also make manual sysadmin-like work for home users unnecessary. Good OSes shouldn't need any "support services", and I can accept if the OS itself it then instead offered in a pay-per-month manner*. What I do NOT want is my local processing power taken away. The number 1 problem is latency. As long as we don't have FTL communication, that is a real problem. We can of course put the servers in just every telephone station or something, but then we lose the point, don't we?
* I didn't say I would like it, but it's not overly harmful.
Not necessarily. For example, PostScript is a very bad format for distributing documents that are to be consumed in any other way than as a graphical document. A naively created PDF can be quite bad, a properly annotated one not so bad. HOW you represent the data is relevant. I would imagine that most formats that are suitable for further editing in a structured manner should be quite good from an accessibility standpoint as well, but you can certainly choose to code things like text flow in a manner that makes a good UI, but where the semantics are lost. The app can only present and persist what's allowed in the format.
DISCLAIMER: This is general obvious facts. I don't recommend the current or future MS Office XML formats as any example of how things should be done.
Slashdot Mirror
Intel has stated that they target a similar TDP relative to Yonah, but with about 20 % higher performance. This, of course, means that the ratio desktop : laptop is lowered. The aggressive improvements might mean that the power consumption when idling is going below Yonah, but it will be hard to keep it that way when they raise the FSB in early 2007, as it's harder to downclock that dynamically.
The reports today (Anandtech among others) seem to indicate that their supposedly normal production chips can enter the 3.5 - 4.0 GHz range. As the Core chips totally wipes out Pentium D clock-by-clock, the results are obvious.
Ah, I just thought about my general scenario: transcoding to fit the storage of a suitable portable device (laptop or smaller). :)
What codec, or drives, do you use if the drives are limiting for video transcoding?
With salted hashes, your O(N+M) number is replaced by O(NM). Kind of the point of salting the hashes.
The Oblivion tests show all things wrong with this, E6700 and X6800 getting identical (more or less) numbers indicate a GPU bound test, AND they use different settings for the AMD test - as they state that the game was not playable if the higher quality settings were used there.
This MSDN blog post was an interesting read to me. As the writer notes, image processing is a kind of virtual task. But it shows some pretty interesting stuff, IMHO, like the fact that the gap between AMD and Intel (Intel winning in the end) is much smaller at 64-bit. Maybe that should be no surprise, with AMD designing the AMD64 instruction set in tandem with the K8. It's also interesting as it might indicate trends regarding tight loop performances in JITed environments in general. This, like it or not, is becoming more common.Well, for now, the yields of the fastest Core CPUs is probably low enough that the average price of manufacturing could be higher for the cheapest chips, as they are a necessary part of the process, anyway. On the other hand, I think that the pure manufacturing costs for a (desktop) CPU tend to be quite a bit lower than this -- the big costs are the onetimers in development and investing in fab infrastructure. When that's already in place (for the current chip generation), it makes sense to use the resources available fully.
In beta 2 of NT5/2000, OLE compound files (basically any Office file) could be saved in several streams, but it was removed. I think the main reason was that it didn't work too well with too many applications (like old network clients) assuming only a single stream.
As UN*X systems have a single file system root, one has to ask: are relative paths a UN*X backdoor?
It's stated as a requirement, but you can run non-Aero basic graphics in a completely unaccelerated frame buffer driver, if you are so inclined.
A non-admin user has never been able to add keys in any part of the registry. For that matter, as admin, there is also the oddity of for example CurrentControlSet\ENUM, which you've to tweak to get into.
However, I think it's important to recognize that while security in depth is a good thing, it is important to shield at the very entry point as well. Take IE again, as an example. It's nice if an exploit can't install a rootkit or modify your home directory, but if an exploit would even be able to read all your cookies, web cache and favorites, that might be bad enough. This latter option will still happen, as these are perfectly valid operations for a web browser, even if you've a kind of sandbox shielding it from the rest of the system. We can protect system integrity by depth, but protecting user data is much harder, and just about as important in many settings.
I think you make one, big, error: the risk for nuclear warhead detonations might be higher. The risk for global, immediate, and complete retaliation is, IMHO, lower. For example, a nuclear conflict between India and Pakistan was unthinkable 30 years ago. It could happen today, but I can hardly see it escalating to a global scale. The results would be devastating, but not that devastating. The same might be said about the risk for a nuclear or terrorist attack against any single metropolitan area in the western world, versus obliteration of "all" (with some definition of all) of them.
"The emperor is nude, as he can, in fact, take off his own clothes, or at least has the privilege needed to ask one of his servants to do it for him. The fact that he wears clothes all the time is irrelevant."
Regarding DNS, I'm not sure what you actually mean here. The DNS client and DNS server are services, but they are not in kernel. A Windows service does not mean it's in kernel mode. Winsock itself has some kernel thunking, and as name resolution is generally done through Winsock, that might be what you mean.
To bet nitpicky, not exponentially smaller: r^2, not x^r. (where x is any constant)
On the other hand, we always hear our own voice partly through bone-conduction (and that's why this works), so it wouldn't be that drastic to put in external vibrations that way, as well.
Just FYI, if you tried to translate the Swedish way of saying it into English, without much thought, it would come out exactly like that. I would imagine that this can be true for at least some more European languages. The majority of Western civilization (me included) does not produce perfect written English.
Islam might be the fastest growing religion, but it's still generally considered smaller than the Roman Catholic churc alone, and much of the silent and under-reported suffering in sub-Saharan Africa has no connection to it. You're not only non-PC, you're blatantly wrong.
(For the record: I consider my religious beliefs, if any, to be Lutheran.)
When the level is so unacceptable that North Korea receives food aid from the "enemy", something is a bit off. Iran is wealthy and self-sufficient in a completely different way (it isn't that hard to be wealthy if DPRK is your standard), so that's certainly a more complex issue. Regarding nuclear weapons, I would certainly prefer a good enough deal that could deafen Iranian pride, and give access to reactors for power production, but not warheads. They certainly would not be alone in (more or less) voluntarily choosing not to pursue nuclear weapons.
(And, yeah, while Intel was most heavily touting RAMBUS, VIA was the primary source for those who were more afraid to overclock 440BX like crazy on the Intel side, as well.)
If there is special handling to fix the register assignment, then it's reasonable to guess that the execution of the instruction is never really done as an actual XOR, either. To speculate even further, one could start imagining all kinds of bad things happening if a "pre-parsing" treats all XORs as "reset register" with some kind of pipeline stall taking place when the XOR actually has to be executed. Quite unlikely, but an entertaining idea, at least to me, right now.
My personal "analysis", is that this sounds much more like a DMA issue, either in chipsets, in the processors, or in OSes. Core 2 is doing some speculative prefetching and a quite different cache management scheme, so some naive ideas would be that some piece of code or hardware got away with doing things improperly before, a very rare race condition might have become commonplace. If that's the reason, it might be easy to fix. Of course, it might also mean that the prefetching or cache sharing between the cores (or a couple of other things) are actually faulty...
Ghosting an image, with local storage (maybe some network-based backup) would also make manual sysadmin-like work for home users unnecessary. Good OSes shouldn't need any "support services", and I can accept if the OS itself it then instead offered in a pay-per-month manner*. What I do NOT want is my local processing power taken away. The number 1 problem is latency. As long as we don't have FTL communication, that is a real problem. We can of course put the servers in just every telephone station or something, but then we lose the point, don't we? * I didn't say I would like it, but it's not overly harmful.
Out of interest, what fundamental choices are you referencing? On a fundamental level, NT is quite non-UNIX in several ways, but how is it broken?
DISCLAIMER: This is general obvious facts. I don't recommend the current or future MS Office XML formats as any example of how things should be done.