Compare it to a game benchmark or whatever. You keep a standard, even if it's flawed, because that's the only way you get comparable results. You can't take a raw number for MIPS or millions of polygons/second or transactions per second or whatever the metric of choice is in your field (here, one is obviously ice sheath coverage) and use numbers from wildly different methods to even try to devise a historical trend. The value observed might not correlate exactly (or even very well) with old ones, but unless the flaws in the method cause great variability within that framework, the historical trends will still be accurate, or at least more accurate compared to what would happen if you changed your methodology each year and still tried to extract longer trends.
It might not be a good choice, and suggestions to run double series over the (short) timespan where overlapping data is indeed available would of course be better, but you can't just switch to the latest and greatest if you want some kind of consistency in your data.
Most multi-year warranty plans explicitly exclude the battery. Not sure if Apple is different here, and naturally you can frequently buy extra battery coverage, but they are not one and the same.
Do you detest Gigabit Ethernet and disk-based drives as well? Pure binary protocols for signals on media tend to be inefficient. The technology is still digital. Whether data integrity is a priority or not is really a matter of proper error correction, to rely on avoiding on single-bit errors is a flawed strategy.
A system call is not a full context switch overhead. You keep the same page tables. This was the point of moving some UI into the kernel, to keep shared code and data and not have a context switch per call. It's more expensive than a pure user library call, though.
On the other hand, most libraries on Linux are loaded in the address space. Heck, Mozilla used XPCOM and even started going away from that because the vtable usage and other aspects (all in-process) seemed too slow. The only relevant "library" doing things in the UNIXy way is the X server, I guess.
The proble, to some degree, is that actually using that information and turning it into useful code is sometimes a quite demanding problem. A PGO compile of C++ isn't exactly fast. There are many possibilities, but most of what I've seen/read about what's actually done in practice seems to be limited to shorting some virtual calls and doing inlining between modules.
Sometimes it is also possible to do a partial inlining, where the infrequently used codepath (like a big error handling clause that's almost never used) is forked off into a helper function, but the main part is inlined. Some virtual calls might also be replaced with static, or with a check on the address where the non-calculated call is optimized.
Any system which fails permanently due to a single bit error is unstable and not robust (in the numeric sense). If the system is really critical, you should better be ready for bit errors.
This approach is basically similar to what would be required in analog systems. After all, analog engineering was quite possible. The main of the meat in decoding MP3 is not about seeking in the stream, it's a lot of Fourier and postprocessing of the waveform -- loss there can be completely acceptable.
Two hydrogen atoms sharing one electron would just have a single orbital, which is equally shared. However, that orbital is repelling, the energy state of a free unbound hydrogen atom and one proton would be more favorable.
.NET 1.1 tends to run very well in.NET 2. However, the default is a supported way of having both installed. Microsoft got DLL hell-avoidance crazy and thought the right thing was to keep explicitly separated libraries for each point release.
Did you use the Vista driver or the native drive of the beta? The Vista driver should be more stable, but will reduce the functionality (not as drastic as using an XP video driver on Vista, which disables Aero, but GDI operations will be on par with Vista, while they will be faster in Windows 7 with a WDDM 1.1 driver).
It was always possible to run a stable video driver at Vista release, and that was the XP drivers. The reduced functionality made it a sour option.
I don't say you don't see this, but it's not seen by all users with x64. I've personally never seen it on a machine with Vista x64, dual DVI, 8600GT card. From your description in the post here and on the blog, this setup "should" see it. I guess it can be a matter of specific monitor models or something.
It is better in the 7 beta. Essentially, I think the default mode for GDI in Vista was/is a system memory buffer, a corresponding texture in video memory and finally the double/triple buffering of the viewport itself. With the right drivers, 7 removes the first of these by really doing the GDI operations on video memory. You save a bit of blitting and lots of RAM that way.
Yeah, but Wine does it by a lot of thunking against the same COM libraries. No default setup of a browser on Windows attempts to support alternative interface implementations like this, even though they could.
The complicated part is getting to the file handle in the first place (and getting a full disk handle with write permission is even more locked down since XP SP2), but it is/was really just an odd path in NT. Then it's a perfectly fine file handle. You will need something to emulate/dev/zero, though.
Note, though, that some (all?) motherboards these days tend to have a tiny region that's either ROM or not normally flashed for recovery if the checksum doesn't match up. You might need to flash that as well, or just go along fooling it with a proper checksum (I don't think they employ any real signing.)
It all depends on where the problem is. If it is in a shared library loaded in multiple processes, a reboot or true hotpatching are the only sure ways to do it. Deleting the file, replacing it with the new one and letting existing processes keep the dangling inode won't protect those processes.
Vista, from SP1 and up, has hotpatching support for some modules, but it's only used for a few patches. Doing it for general libraries that can be loaded by any user code (like netapi32.dll, which was affected in MS08-067) is tricky, to say the least. That DLL supports much of the file sharing functionality in one way or another, which also means that just about any system widget or module that's supposed to be file sharing aware will have it loaded.
Of course, in some cases the specific bug is only affecting some possible consumers of an OS library, but sometimes it might be hard to tell. If the vulnerable codepath is accessible from the public API, there is really no way to tell, so your options for this patch would have been to kill almost every GUI or server process and restarting all of them, or taking the time to develop and test a true hotpatch. The first option is awfully close to a reboot.
It seems like a proper evolutionary boon to slowly kill off teeth, since that will give you access to all the body and doesn't really hurt your chances of propagating to other people. Give me this modified strain!
Comic Sans was already in Creative Writer and Fine Artist (released around -94). And the avatar chat client is IMHO more related to V-Chat, which predates Comic Chat, as Comic Chat allowed no navigation in the "world".
Yes, Buffet pledged to donate that sum, or rather stock that at the time of the pledge were worth that sum. Gates initial endowment on the other hand was $94 million, which is also off by your numbers. Bill and Melinda Gates have actually given $28 billion and their donations constitute most of the current endowment to the foundation.
Uh, and how is that different from a Netscape plugin?
Compare it to a game benchmark or whatever. You keep a standard, even if it's flawed, because that's the only way you get comparable results. You can't take a raw number for MIPS or millions of polygons/second or transactions per second or whatever the metric of choice is in your field (here, one is obviously ice sheath coverage) and use numbers from wildly different methods to even try to devise a historical trend. The value observed might not correlate exactly (or even very well) with old ones, but unless the flaws in the method cause great variability within that framework, the historical trends will still be accurate, or at least more accurate compared to what would happen if you changed your methodology each year and still tried to extract longer trends.
It might not be a good choice, and suggestions to run double series over the (short) timespan where overlapping data is indeed available would of course be better, but you can't just switch to the latest and greatest if you want some kind of consistency in your data.
Most multi-year warranty plans explicitly exclude the battery. Not sure if Apple is different here, and naturally you can frequently buy extra battery coverage, but they are not one and the same.
Do you detest Gigabit Ethernet and disk-based drives as well? Pure binary protocols for signals on media tend to be inefficient. The technology is still digital. Whether data integrity is a priority or not is really a matter of proper error correction, to rely on avoiding on single-bit errors is a flawed strategy.
A system call is not a full context switch overhead. You keep the same page tables. This was the point of moving some UI into the kernel, to keep shared code and data and not have a context switch per call. It's more expensive than a pure user library call, though.
On the other hand, most libraries on Linux are loaded in the address space. Heck, Mozilla used XPCOM and even started going away from that because the vtable usage and other aspects (all in-process) seemed too slow. The only relevant "library" doing things in the UNIXy way is the X server, I guess.
The proble, to some degree, is that actually using that information and turning it into useful code is sometimes a quite demanding problem. A PGO compile of C++ isn't exactly fast. There are many possibilities, but most of what I've seen/read about what's actually done in practice seems to be limited to shorting some virtual calls and doing inlining between modules.
Sometimes it is also possible to do a partial inlining, where the infrequently used codepath (like a big error handling clause that's almost never used) is forked off into a helper function, but the main part is inlined. Some virtual calls might also be replaced with static, or with a check on the address where the non-calculated call is optimized.
Any system which fails permanently due to a single bit error is unstable and not robust (in the numeric sense). If the system is really critical, you should better be ready for bit errors.
This approach is basically similar to what would be required in analog systems. After all, analog engineering was quite possible. The main of the meat in decoding MP3 is not about seeking in the stream, it's a lot of Fourier and postprocessing of the waveform -- loss there can be completely acceptable.
Two hydrogen atoms sharing one electron would just have a single orbital, which is equally shared. However, that orbital is repelling, the energy state of a free unbound hydrogen atom and one proton would be more favorable.
Most 15.4 " machines would use 15-20 W with a display at 80 % or so (and light CPU use).
Gobliins!
And you haven't heard of ngen, or you don't understand it. (But, honestly, it doesn't seem like the grandparent does, either.)
.NET 1.1 tends to run very well in .NET 2. However, the default is a supported way of having both installed. Microsoft got DLL hell-avoidance crazy and thought the right thing was to keep explicitly separated libraries for each point release.
Did you use the Vista driver or the native drive of the beta? The Vista driver should be more stable, but will reduce the functionality (not as drastic as using an XP video driver on Vista, which disables Aero, but GDI operations will be on par with Vista, while they will be faster in Windows 7 with a WDDM 1.1 driver).
It was always possible to run a stable video driver at Vista release, and that was the XP drivers. The reduced functionality made it a sour option.
I don't say you don't see this, but it's not seen by all users with x64. I've personally never seen it on a machine with Vista x64, dual DVI, 8600GT card. From your description in the post here and on the blog, this setup "should" see it. I guess it can be a matter of specific monitor models or something.
It is better in the 7 beta. Essentially, I think the default mode for GDI in Vista was/is a system memory buffer, a corresponding texture in video memory and finally the double/triple buffering of the viewport itself. With the right drivers, 7 removes the first of these by really doing the GDI operations on video memory. You save a bit of blitting and lots of RAM that way.
IE is not, has never been and hopefully never will be grafted to the kernel. win32k.sys doesn't include Trident, nor did the Win9x vxds.
Yeah, but Wine does it by a lot of thunking against the same COM libraries. No default setup of a browser on Windows attempts to support alternative interface implementations like this, even though they could.
The complicated part is getting to the file handle in the first place (and getting a full disk handle with write permission is even more locked down since XP SP2), but it is/was really just an odd path in NT. Then it's a perfectly fine file handle. You will need something to emulate /dev/zero, though.
http://en.wikipedia.org/wiki/CIH
Note, though, that some (all?) motherboards these days tend to have a tiny region that's either ROM or not normally flashed for recovery if the checksum doesn't match up. You might need to flash that as well, or just go along fooling it with a proper checksum (I don't think they employ any real signing.)
Or 802.11n in 5 GHz. Quite a few n routers support it, some even do 2.4/5 at the same time.
It all depends on where the problem is. If it is in a shared library loaded in multiple processes, a reboot or true hotpatching are the only sure ways to do it. Deleting the file, replacing it with the new one and letting existing processes keep the dangling inode won't protect those processes.
Vista, from SP1 and up, has hotpatching support for some modules, but it's only used for a few patches. Doing it for general libraries that can be loaded by any user code (like netapi32.dll, which was affected in MS08-067) is tricky, to say the least. That DLL supports much of the file sharing functionality in one way or another, which also means that just about any system widget or module that's supposed to be file sharing aware will have it loaded.
Of course, in some cases the specific bug is only affecting some possible consumers of an OS library, but sometimes it might be hard to tell. If the vulnerable codepath is accessible from the public API, there is really no way to tell, so your options for this patch would have been to kill almost every GUI or server process and restarting all of them, or taking the time to develop and test a true hotpatch. The first option is awfully close to a reboot.
It seems like a proper evolutionary boon to slowly kill off teeth, since that will give you access to all the body and doesn't really hurt your chances of propagating to other people. Give me this modified strain!
Comic Sans was already in Creative Writer and Fine Artist (released around -94). And the avatar chat client is IMHO more related to V-Chat, which predates Comic Chat, as Comic Chat allowed no navigation in the "world".
Yes, Buffet pledged to donate that sum, or rather stock that at the time of the pledge were worth that sum. Gates initial endowment on the other hand was $94 million, which is also off by your numbers. Bill and Melinda Gates have actually given $28 billion and their donations constitute most of the current endowment to the foundation.