You're wrong. A bad sector is caught by any read. A recoverable read error that's bad enough will cause the disk to remap it internally for future use. This means that things are really bad if you get a lot of bad sectors reported by the file system. A scandisk or some other complete sweep of the disk will of course be triggering those reads of every sector, and so SMART stats for a drive might change after such a sweep.
I love hibernation. BUT, putting the first 256 MB or so on flash, together with a BIOS which could initiate booting before the disk is done spinning up, would be even better.
You have one significant problem with turning off cores completely: just as you say, the demand is very "bursty". You need to have some latency in turning on a completely stopped chip, no matter that it will be slow when it's first coming "alive", since the cache is empty. We're even seeing this today, to some degree: the most irritating consequence of SpeedStep/Cool'n'Quiet is that some (poorly written) apps really lose in responsiveness, simply because you want an immediate response at the very moment you click on a button. The fact that the CPU was idle one ms before is irrelevant. (Note that most AMD and Intel chips today never go below 800 MHz/1 GHz, but if you add some other throttling, or force them to go even lower, you'll really notice this.)
My solution? In UI tasks, always keep one step ahead. We have lots of cycles. Use them to predict the next action by the user and do whatever needs to be done to perform it quickly when the command is actually given. Lots of cores can help a little there, but 8 would be hard to feed. It's easier to spread out the speculative load of many possible future actions on the cores, to create a seemingly fast response, than to split up a very serial burst to 8 cores, where most of them will have a powering delay.
But, if your harddrive was part of an evolving system of self-replicating harddrive, it's fully possible that it would evolve irregularities in the sector markings, as there is no specific "penalty" into moderating a bad gene in that way versus any other, more direct, "method".
(Not the original poster, but what the heck:) I think they might stay as ULV, and possibly for some low end. You can still buy quite a lot of Pentium Ms, as well. Some things going against keeping Yonah is that it's using the same 65 nm technology, and that the stocks aren't as huge as for the desktop parts (leaner operations all the way as they mainly go directly to OEMs). The platforms are compatible, so the switch wouldn't be too complicated for most vendors.
Probably, as the current Meroms are close to compatible with Yonah, for which you can already buy ITX equipment. A new socket ("socket P"), FSB frequency and so on is coming in January.
Of course you're right in the battery being an added source of heat. Batteries are not that inefficient, so it's in a comparable range to the power usage, which is just about equivalent to the heat put out by the circuit. The actual transmitting power is also not that efficient from an antenna, you get a lot of localized heat in the antenna itself, so if you actually hold the object, I would think that the direct heat transfer through conduction is lower than the radiative absorption.
If you find a crash with an automated fuzzler, you can then track it back to the source and come up with an exploit easier, even if the bug itself is highly non-obvious. Just an observation. You obviously need to do some reverse engineering on the MS Office binaries to do the same thing today.
Of course, for OOo, just about anyone is theoretically free to track the complete bug down and provide the fix, while we can just report it in the MS case. It goes both ways, but having access to the source doesn't mean that reading the source is your starting point when finding the exploit. It might still help you crack the hole wide-open.
I wouldn't totally agree. There is some utility in discussing simultaneous events in relativity, it's just not very intuitive. It's even less intuitive to consider everything that you can observe by arriving EM as "now", though.
Well, the highly dynamical typing of Python means that you can't get performance similar to a properly compiled language without really clever tricks. The same holds for javascript. Make every call a virtual call and every object kind of like the VARIANT that was used for everything in Visual Basic.
On the other hand, even "obviously" serial tasks can be made faster if you let other threads handle highly speculative precalcing/prefetching/whatever. In a UI context, latency is king. If you can write your code so that processing starts in a background thread twenty ms before the actual click (when the mouse only hovered over the button/menu item), you'll still get the results of faster response. Try to make the processing that actually depends on the input from the previous task as low as possible. Try to guess, if you'll otherwise just be idle. Reindex your DB on another thread, even if it will only save 2 % on your main thread(s). Given, of coures, that performance and latency is what you care about.
It's certainly not been done for humans, as the cell count is already staggering at the age of a month (versus around 1000 cells in total for C. elegans), you can't study the process properly in vitro, and of course ethical issues at some point. AFAIK, it's not been done for mice either, and that would probably be a more reasonable start, although still much more demanding than C. elegans.
There are a few drivers that add their own usermode services (not just tray apps, but "real" services), for example. I'm not sure from the question if the intent is to get a lean system, or an attempt to identify unwanted - as in possible malware - processes. Googling individual process file names generally gives a pretty good picture of what it is and whether it's needed, or at least where it comes from.
What he aimed at is irrelevant. The V1s and V2s were not even close to being inter-continental. Besides, without a nuclear warhead, you would need immense amount of fuel relative to the damage caused. London from France/Belgium is a quite different thing than the Eastern Europe-US trip, in either direction.
You can wait years before releasing your malware (depending on your source of funding). For AV to be worth a damn, they want to release a signature update within hours or possibly days when a virus has come to their attention.
Well, this is an interesting story. You can be sure that you share (roughly) 50 % with your biological parents. A brother might, highly theoretically, share only the mitochondrial DNA with his sisters.
From 32-bit XP to Vista is 5.1 to 6.0. XP 64 is special, as it is the only "client" version of Windows 5.2 (alias Windows Server 2003)... I think that the actual new components and changed features of the kernel were more relevant than the version number.
New audio stack, new networking stack, transactional NTFS. ("Rollback" of arbitrary file system operations done within a context you set up before you started them.) Better cancellation of I/O, one of the main reasons why it can be hard to kill a NT process these days - one thread belonging to the process is actually stuck waiting on an I/O operation in the kernel which never times out or completes.
Related to the graphics stuff is a new driver model for graphics, with a "true" miniport scheme again, lots of the code residing in usermode. There is also almost-arbitrary support for usermode drivers for devices where latency and performance is not as important. This requires a thunking layer on the kernel side.
There won't be a beta 3, unless they radically admit further delays. Next in line is RC0 or RC1, I think it's most likely that the next public release is called RC1. Not that it really matters what it's called...
If MS got a one time payment of n billion dollars to make the source for everything up to and including Vista available, I'm sure they would agree. It's just a matter of what n is. It's not like you can't get a license to the Windows source today, if you're the right OEM/university/nation. Likewise, these companies can certainly gain profit as long as they're paid well to do this research.
Another matter is what's really made available. Analogies are hard, but source tells a damn lot about your methodology and thinking, more so than formal articles, results or even lab protocols.
The fact that the two dies (with two cores on each) will communicate over the FSB is of course limiting, but we also have to remember that each of those dies will have 4 MB of L2, 8 MB in total. We've already seen what the Core 2 prefetching can do in hiding the memory controller latency, so if things are good it will work equally well in prefetching data from the L2 on the other die. Then, the memory bandwidth is irrelevant, while the FSB bandwidth is still relevant. I seem to remember reading that either Kentsfield or Clovertown would carry some kind of dual-bus solution (with support in chipset), but maybe that was further ahead.
Let's also not forget that the NUMA properties of the AMD solution, with less advanced prefetching, can actually be a more significant latency problem in latency-sensitive applications. The bandwidth, on the other hand, will absolutely be there.
Slashdot Mirror
You're wrong. A bad sector is caught by any read. A recoverable read error that's bad enough will cause the disk to remap it internally for future use. This means that things are really bad if you get a lot of bad sectors reported by the file system. A scandisk or some other complete sweep of the disk will of course be triggering those reads of every sector, and so SMART stats for a drive might change after such a sweep.
I love hibernation. BUT, putting the first 256 MB or so on flash, together with a BIOS which could initiate booting before the disk is done spinning up, would be even better.
Well, the "ask the CPU for memory values" scheme is already what AMD does. And, yeah, they do NUMA, for better or for worse.
My solution? In UI tasks, always keep one step ahead. We have lots of cycles. Use them to predict the next action by the user and do whatever needs to be done to perform it quickly when the command is actually given. Lots of cores can help a little there, but 8 would be hard to feed. It's easier to spread out the speculative load of many possible future actions on the cores, to create a seemingly fast response, than to split up a very serial burst to 8 cores, where most of them will have a powering delay.
I can't help thinking about BOFH and PFY when you mention mentoring a younger sysadmin...
Yeah, beta 2 "leaked" to www.microsoft.com. So it's been public since at least then. You could download it without signing up for anything.
But, if your harddrive was part of an evolving system of self-replicating harddrive, it's fully possible that it would evolve irregularities in the sector markings, as there is no specific "penalty" into moderating a bad gene in that way versus any other, more direct, "method".
(Not the original poster, but what the heck:) I think they might stay as ULV, and possibly for some low end. You can still buy quite a lot of Pentium Ms, as well. Some things going against keeping Yonah is that it's using the same 65 nm technology, and that the stocks aren't as huge as for the desktop parts (leaner operations all the way as they mainly go directly to OEMs). The platforms are compatible, so the switch wouldn't be too complicated for most vendors.
Probably, as the current Meroms are close to compatible with Yonah, for which you can already buy ITX equipment. A new socket ("socket P"), FSB frequency and so on is coming in January.
Of course you're right in the battery being an added source of heat. Batteries are not that inefficient, so it's in a comparable range to the power usage, which is just about equivalent to the heat put out by the circuit. The actual transmitting power is also not that efficient from an antenna, you get a lot of localized heat in the antenna itself, so if you actually hold the object, I would think that the direct heat transfer through conduction is lower than the radiative absorption.
Of course, for OOo, just about anyone is theoretically free to track the complete bug down and provide the fix, while we can just report it in the MS case. It goes both ways, but having access to the source doesn't mean that reading the source is your starting point when finding the exploit. It might still help you crack the hole wide-open.
Will the radiation turn us into mega-agile mutants before we die? Wow!
I wouldn't totally agree. There is some utility in discussing simultaneous events in relativity, it's just not very intuitive. It's even less intuitive to consider everything that you can observe by arriving EM as "now", though.
Well, the highly dynamical typing of Python means that you can't get performance similar to a properly compiled language without really clever tricks. The same holds for javascript. Make every call a virtual call and every object kind of like the VARIANT that was used for everything in Visual Basic.
On the other hand, even "obviously" serial tasks can be made faster if you let other threads handle highly speculative precalcing/prefetching/whatever. In a UI context, latency is king. If you can write your code so that processing starts in a background thread twenty ms before the actual click (when the mouse only hovered over the button/menu item), you'll still get the results of faster response. Try to make the processing that actually depends on the input from the previous task as low as possible. Try to guess, if you'll otherwise just be idle. Reindex your DB on another thread, even if it will only save 2 % on your main thread(s). Given, of coures, that performance and latency is what you care about.
It's certainly not been done for humans, as the cell count is already staggering at the age of a month (versus around 1000 cells in total for C. elegans), you can't study the process properly in vitro, and of course ethical issues at some point. AFAIK, it's not been done for mice either, and that would probably be a more reasonable start, although still much more demanding than C. elegans.
There are a few drivers that add their own usermode services (not just tray apps, but "real" services), for example. I'm not sure from the question if the intent is to get a lean system, or an attempt to identify unwanted - as in possible malware - processes. Googling individual process file names generally gives a pretty good picture of what it is and whether it's needed, or at least where it comes from.
What he aimed at is irrelevant. The V1s and V2s were not even close to being inter-continental. Besides, without a nuclear warhead, you would need immense amount of fuel relative to the damage caused. London from France/Belgium is a quite different thing than the Eastern Europe-US trip, in either direction.
You can wait years before releasing your malware (depending on your source of funding). For AV to be worth a damn, they want to release a signature update within hours or possibly days when a virus has come to their attention.
Well, this is an interesting story. You can be sure that you share (roughly) 50 % with your biological parents. A brother might, highly theoretically, share only the mitochondrial DNA with his sisters.
From 32-bit XP to Vista is 5.1 to 6.0. XP 64 is special, as it is the only "client" version of Windows 5.2 (alias Windows Server 2003)... I think that the actual new components and changed features of the kernel were more relevant than the version number.
Related to the graphics stuff is a new driver model for graphics, with a "true" miniport scheme again, lots of the code residing in usermode. There is also almost-arbitrary support for usermode drivers for devices where latency and performance is not as important. This requires a thunking layer on the kernel side.
There won't be a beta 3, unless they radically admit further delays. Next in line is RC0 or RC1, I think it's most likely that the next public release is called RC1. Not that it really matters what it's called...
Another matter is what's really made available. Analogies are hard, but source tells a damn lot about your methodology and thinking, more so than formal articles, results or even lab protocols.
Let's also not forget that the NUMA properties of the AMD solution, with less advanced prefetching, can actually be a more significant latency problem in latency-sensitive applications. The bandwidth, on the other hand, will absolutely be there.