Or it could be that they no longer support IE 5 and 6 and so won't release a patch even if they are affected?
The other possibility is that the bug is in the code responsible for the much better standards compliance in IE7, in which case IE5 and IE6 are only more secure because they don't support the feature, which doesn't really count.
The "M" of ATM only stands for "Machine" when you're talking about "Automated Teller Machines". Saying "ATM machine" isn't redundant, because it clarifies which "ATM" expansion you mean, without you having to say the entire expanded form of the acronym.
sovereignty - ownership of solar systems ISK - in-game currency cyno-jammers - stops enemy capital ships jumping in to the system director - has full access to everything about the corporation/alliance. Only the owner is above.
Someone once said: "You can't blame the API for the actions of the programmer who uses it" or something like that. I think they're probably right there.
I think we've reached the end of this conversation. Nice meeting you, I'll stick you in my friends so I see you around:)
Swap is a bit of an outdated concept, it's from an age when CPUs were slow, ram was really slow, and really expensive. Swap was required for a machine to be usable.
Now it's more of a hindrance, at least to those of us who don't have an OEM machine with 256MB of ram and 300MB of OEM startup crap. Especially due to that quirk of the Windows API that allows programs to insist on swap and fail to run if you have it turned off. "ABC requires at least 64MB of swap" -> "I have 4GB of ram, and 3GB of that is unused, use that" -> "No, I want 64MB of swap" grrr.
There is no way that a cpu doing nothing for 5ms would be giving you more performance than one that switched to doing something else. 5ms is a hell of a lot of cpu time, especially if you're swapping several times a second, it could really add up.
If it turns out that the thread it switches to needs to swap too a little later, it should just queue it and switch to yet another thread that isn't waiting on a swap.
Of course, running swap on an SSD wouldn't suffer from the same latencies, it's more like 0.1ms. Swapping at the rate that would kill an SSD would probably not damage a hard-disk (unless it's in a portable device and being moved...) but that level of swapping only happens when your current working set of memory pages doesn't fit in ram, so you have to do swap after swap after swap just to switch to the next program, so your performance would be completely gone anyway. So it's a choice between slowly killing a disk and having a pc that makes a 386 look speedy...
Or, you could just put enough ram in the box in the first place.
The biggest concern with using an SSD is making sure that writes are done in a multiple of the SSD's erase block size, so that you don't make it read the data around where you're writing, erase it all and then write it back again.
Hopefully the disk isn't tying up the memory controller when it's not actually transferring data, so you'd get 5ms of execution of another thread before the disk seek is done and it starts reading.
Not saying it would actually work, but it would be nice if it did.
Presumably it copied everything in ram to the swap allow the pages still in ram to be discarded without waiting to write them to disk if your ram usage suddenly spiked and you needed to swap.
Any decent OS would dispatch the read request and switch threads to one that didn't need to swap. Of course, that only works if your "active set" of ram pages actually all fit in ram, and you don't need to swap code pages just to run.
Much like what happens on a cpu with multiple threads supported by one physical core (like "hyperthreading") and a cache miss is encountered.
I can easily imagine crap controllers recalculating the parity by reading the whole stripe instead of doing a delta change (subtract old add new as you put it).
I did say "average" time between failures. It could of course vary between multiple failures at once (0 seconds) and no failures ever (though proving that one could take a while).
The length of the warranty quip was semi-serious, in that the length of the warranty is set at a point where the manufacturer would still make a profit, so odds are in favour of the drive not failing within warranty.
If the bits get fubar'ed on one drive, that will propagate across the rest - leaving you with no data.
Nope, if the bits get foobar'ed the sector checksum fails and the data from the "OK" drive is used.
The disks themselves can protect against minor errors. Raid protects against small to medium amounts of hardware failure. Backups protect against large amounts of hardware failure, and limited amounts of stupidity.
If you have 1000 drives with MTBF 200,000 hours, then on average you'll have one fail every 200 hours (200,000 / 1,000). In other words it helps you predict the parts cost of maintaining a datacenter.
With a small number of drives the MTBF is obviously longer than the drive's lifetime, but the MTBF is not meant to help you predict the life of a single drive. That's what the length of the warranty is for.
If you're writing kernel mode software yourself, then the DRM guys can't trust you not to be hooking in a ripping the video out from under the DRM. Do you blame them? It's not like they know what your program does.
This would be why you have separate entertainment (DRM-supporting) and work (development) environments.
No, you can choose between custom kernel mode software, and watching blu-ray / HD-DVD.
I don't know about you, but I wouldn't want to take some random bloke's word for it that their kernel mode software isn't going to trash my Windows kernel or use kernel hooks to keylog or spy on me etc. I'd much rather trust the people who made the kernel itself to say what's safe. On Linux that would mean only installing kernel stuff from distro repros, on Windows it means driver signing.
Not that I'm expecting to watch blu-ray or HD-DVD on my pc for quite some time.
Of course, they aren't twice as slow. (i.e. They don't run at half the speed, for the pedants.)
The slowdown is a few percent, because most applications aren't bound by memory speed of instruction fetching.
But who really cares if the OS is a few percent slower? It uses ~0% of my cpu anyway. Most applications I run are still 32-bit, even though my OS is XP x64.
Don't think so, as Server 2003 and XP x64 are still yet to get XP x86's 3rd service pack.
Their release version was roughly XP SP1, their SP1 was roughly XP's SP2, and they've had a random SP2 since which ISN'T XP's SP3. They're still separate.
Presumably that is talking about while the content is playing.
Plus, it's only checking the kernel for tampering (pretty sensible with the threat of viruses forever hanging over Windows's head), not scanning your mp3 collection.
Slashdot Mirror
Or it could be that they no longer support IE 5 and 6 and so won't release a patch even if they are affected?
The other possibility is that the bug is in the code responsible for the much better standards compliance in IE7, in which case IE5 and IE6 are only more secure because they don't support the feature, which doesn't really count.
Except they actually don't care, because they were already running the Windows client in Wine instead, because it ran better.
Go ask someone if they've heard of an "AT machine". I bet you'll either get a "no?", or "do you mean an ATM?"
The "M" of ATM only stands for "Machine" when you're talking about "Automated Teller Machines". Saying "ATM machine" isn't redundant, because it clarifies which "ATM" expansion you mean, without you having to say the entire expanded form of the acronym.
sovereignty - ownership of solar systems
ISK - in-game currency
cyno-jammers - stops enemy capital ships jumping in to the system
director - has full access to everything about the corporation/alliance. Only the owner is above.
Someone once said: "You can't blame the API for the actions of the programmer who uses it" or something like that. I think they're probably right there.
I think we've reached the end of this conversation. Nice meeting you, I'll stick you in my friends so I see you around :)
Swap is a bit of an outdated concept, it's from an age when CPUs were slow, ram was really slow, and really expensive. Swap was required for a machine to be usable.
Now it's more of a hindrance, at least to those of us who don't have an OEM machine with 256MB of ram and 300MB of OEM startup crap. Especially due to that quirk of the Windows API that allows programs to insist on swap and fail to run if you have it turned off. "ABC requires at least 64MB of swap" -> "I have 4GB of ram, and 3GB of that is unused, use that" -> "No, I want 64MB of swap" grrr.
Also, is it 17% less of the 33% improvement of the other group (83% of 33)%, or (33-17)%?
Ah, the old realism vs. gameplay argument.
You should try playing some of the thief games, dead bodies provoke quite a reaction in that.
There is no way that a cpu doing nothing for 5ms would be giving you more performance than one that switched to doing something else. 5ms is a hell of a lot of cpu time, especially if you're swapping several times a second, it could really add up.
If it turns out that the thread it switches to needs to swap too a little later, it should just queue it and switch to yet another thread that isn't waiting on a swap.
Of course, running swap on an SSD wouldn't suffer from the same latencies, it's more like 0.1ms. Swapping at the rate that would kill an SSD would probably not damage a hard-disk (unless it's in a portable device and being moved...) but that level of swapping only happens when your current working set of memory pages doesn't fit in ram, so you have to do swap after swap after swap just to switch to the next program, so your performance would be completely gone anyway. So it's a choice between slowly killing a disk and having a pc that makes a 386 look speedy...
Or, you could just put enough ram in the box in the first place.
The biggest concern with using an SSD is making sure that writes are done in a multiple of the SSD's erase block size, so that you don't make it read the data around where you're writing, erase it all and then write it back again.
Hopefully the disk isn't tying up the memory controller when it's not actually transferring data, so you'd get 5ms of execution of another thread before the disk seek is done and it starts reading.
Not saying it would actually work, but it would be nice if it did.
Presumably it copied everything in ram to the swap allow the pages still in ram to be discarded without waiting to write them to disk if your ram usage suddenly spiked and you needed to swap.
I think it's called "pre-emptive swapping".
Any decent OS would dispatch the read request and switch threads to one that didn't need to swap. Of course, that only works if your "active set" of ram pages actually all fit in ram, and you don't need to swap code pages just to run.
Much like what happens on a cpu with multiple threads supported by one physical core (like "hyperthreading") and a cache miss is encountered.
I can easily imagine crap controllers recalculating the parity by reading the whole stripe instead of doing a delta change (subtract old add new as you put it).
I did say "average" time between failures. It could of course vary between multiple failures at once (0 seconds) and no failures ever (though proving that one could take a while).
The length of the warranty quip was semi-serious, in that the length of the warranty is set at a point where the manufacturer would still make a profit, so odds are in favour of the drive not failing within warranty.
If the bits get fubar'ed on one drive, that will propagate across the rest - leaving you with no data.
Nope, if the bits get foobar'ed the sector checksum fails and the data from the "OK" drive is used.
The disks themselves can protect against minor errors.
Raid protects against small to medium amounts of hardware failure.
Backups protect against large amounts of hardware failure, and limited amounts of stupidity.
MTBF is only useful for larger samples.
If you have 1000 drives with MTBF 200,000 hours, then on average you'll have one fail every 200 hours (200,000 / 1,000). In other words it helps you predict the parts cost of maintaining a datacenter.
With a small number of drives the MTBF is obviously longer than the drive's lifetime, but the MTBF is not meant to help you predict the life of a single drive. That's what the length of the warranty is for.
I've run Windows 7 in VirtualBox. I told it it was "Vista", because it didn't know about 7 yet.
No update needed.
Actually you get massive speed gains if you use SSE assembly (and your app benefits from SSE) because the compiler often doesn't produce it willingly.
SSE-intrisinc functions are much better though.
If you're writing kernel mode software yourself, then the DRM guys can't trust you not to be hooking in a ripping the video out from under the DRM. Do you blame them? It's not like they know what your program does.
This would be why you have separate entertainment (DRM-supporting) and work (development) environments.
No, you can choose between custom kernel mode software, and watching blu-ray / HD-DVD.
I don't know about you, but I wouldn't want to take some random bloke's word for it that their kernel mode software isn't going to trash my Windows kernel or use kernel hooks to keylog or spy on me etc. I'd much rather trust the people who made the kernel itself to say what's safe. On Linux that would mean only installing kernel stuff from distro repros, on Windows it means driver signing.
Not that I'm expecting to watch blu-ray or HD-DVD on my pc for quite some time.
Of course, they aren't twice as slow. (i.e. They don't run at half the speed, for the pedants.)
The slowdown is a few percent, because most applications aren't bound by memory speed of instruction fetching.
But who really cares if the OS is a few percent slower? It uses ~0% of my cpu anyway. Most applications I run are still 32-bit, even though my OS is XP x64.
Don't think so, as Server 2003 and XP x64 are still yet to get XP x86's 3rd service pack.
Their release version was roughly XP SP1, their SP1 was roughly XP's SP2, and they've had a random SP2 since which ISN'T XP's SP3. They're still separate.
Presumably that is talking about while the content is playing.
Plus, it's only checking the kernel for tampering (pretty sensible with the threat of viruses forever hanging over Windows's head), not scanning your mp3 collection.
I hope you realize, you've just argued for Clippy, as did those who modded you up.
No, no, he argued for "Kitty". There is a subtle difference.