Left to its own devices in a natural environment, it's actually a quite hard question to answer if a majority of fertilised human eggs develop into born children. Quite a lot fail to even integrate into the wall of uterus, and a lot will also cause a spontaenous abortion within the first few weeks. The exact numbers are hard to get at, but if all those cell bundles are to be considered human beings, we have a death toll that makes just about anything else seem like a joke.
If the vast majority did in fact result in a child if unattended, then your argument would make more sense. Having an embryo, in a uterus, is a necessary but far from sufficient condition to get a child within a few months, even with the mother kept alive and (overall) healthy.
Even if the Wifi bandwidth can sustain it, high Wifi usage is a battery killer on many devices... Higher compression or some features provided locally can actually make it lighter while still useful. It's a tradeoff and I note that you didn't mention battery life at all. P4 laptops were also quite cheap and they had those wonderful fans and > 90 W chargers:-)
Consider seek time vs. bandwidth. Note, I have not studied what ReadyBoost and whatever does in detail, but consider that just about any piece of code in memory is really backed by a file on disk. Not the swap space, but the real file. This is quite ingenious, loading a binary "only" means loading the header, mapping in the code from all linked libraries, and calling the entry points. You do not need to load all code or other resources in the exe. If it's swapped out, you don't need to allocate space for it twice, it happily sits in the actual file.
Naturally this requires that the exe is not using some proprietary compression scheme, and that no relocations have been needed (rebase is your friend).
Anyway, this means that loading something that's been swapped out from disk can require accesses all over the place. Putting that data in a medium with basically zero additional penalty for random access, like a flash drive, can make a lot of sense. This would apply to all swap data, as the access patterns are rather random, but if you want to be able to jack the flash drive out at any moment, you need to have some second backing for the data in case of such an event. Where do we find that? In the real binaries, of course!
Optimizing defragmentation tries to achieve this by putting relevant binaries close together, but you still have to seek within that area, and seek back to some place in the real swap (to load volatile data back). By moving some of those operations over to a device with good random access behavior, you'll even get higher performance out of those operations that are still handled by the HD. All in theory...
Python also allows on-the-fly redefinitions, which is blamed here. Generally, the choice of scripting language is not the problem here. Most "Javascript" bugs translate directly into VBScript if you're IE-masochistic (or Perlscript, if you've managed to install that and trick IE into running the engine for it). The problem is in the DOM, what objects might theoretically be exposed, and how it's crucial that some part of the browser can access them, while others should not. After all, in Mozilla, the whole UI is held together by Javascript, running in basically the same engine, but a different sandbox. The situation with the IE scripting environment is quite comparable.
Well, ever since Word 97, there have been features intended to let the user disable auto-running macros. That's also been the default. This is not really a problem, as most Word files should not contain macros. Even if they do, most files are still useful without them, and are probably used within the context of a controlled intranet (with code signing in place). If the view that Javascript is inherently impossible to make secure would gain ground, AJAX would go the way of ActiveX controls.
Now, I know you said vulnerabilities, but I wanted to point out that some parts of the Office functionality has already been removed this way. Javascript off by default for unknown sites has so far been a "geeky" attitude, the web would certainly change if that attitude would turn into norm.
It's naturally also a matter of paper quality. My impression was that the material for bills in most countries is frequently cotton-derived, quite dense and also lacking more volatile contaminants (high-cellulose content, suitable inks). They are, after all, washable...
Well, as the ovaries are not directly connected to the invagination of yours, the inner of the abdomen is actually exposed. The topology is hence quite different (in a highly theoretical sense no clear definition of inner vs. outer surface). Or, to quote Trek: "For the world is hollow and I've touched..."
If you don't know how to access command history, autocompletion and aliases in cmd.exe, that's bad for you. They are there. Some of it has been there ever since DOSKEY entered in MS-DOS 4.0 (or was it 3.x? never mind...). It sounds like you have started command.com, not cmd.exe if you claim that autocompletion is missing from a default XP. Just a guess...
Vista supports a rerouting of driver calls to user mode drivers for some device types (even I/O devices like HDs could theoretically use it). This carries a performance penalty (so normal HD controllers won't). It could be used for quick hacks. And, yeah, I know about Linux user mode file systems and devices. I'm just saying MS has done work in this direction.
The new video driver model also includes a much large user mode part. In essence, the "miniport" in kernel is back to maybe actually being a thin layer doing the real HW interaction, while the user mode part is loaded in process. (While the other Vista user mode drivers I mentioned are separate processes.)
As others have noted, OS and hardware specific features (that nonetheless are following the specs) can get cheap consumer routers to behave strangely. DLink DI-624+ routers (at least those sold in some regions) couldn't handle multiple Centrinos with adaptive power management, for example. A temporary instruction to disable the setting was released (hurting battery life), finally followed by a firmware update. Maybe the Intel implementation is really in error, but if so, D-link never bothered to make that accusation.
It's just the nagging fact that the second biggest problem, next to users damaging/losing data/configuration/software is when they THINK that they've deleted something (be it their porn cookies, an angered email draft or some nasty spyware), but it's still there, in plain sight or somewhat hidden. A complete undo stack, stored in files, is just the thing that you wouldn't want to carry when others access the same file, but you still want it if you access it yourself over the network... even if you happen to use a different username. There are conflicting interests here, and total persistence is not the answer. That's even ignoring the real problem of (a considerable portion of) users filling up disks whatever we throw at them.
Long, and variable, but deterministic, is also quite ok. However, it should still be stored serverside, since it seems (to me) that the only point of including the hash in a production system would be to avoid storing the session information. Then, the creative hacker will naturally switch the hash value and add a matching input string when the form is posted.
ReadyBoost is just a mirror of what's frequently kept as memory-mapped files fragmented over the drive (or possibly swap on drive sometime). The point is that you can benefit from reading from the flash sometimes, if the HD is busy, but you NEVER put anything only on the flash. You can take that USB key out any time, and it shouldn't hurt (in theory). Needless to say, that's not true of general swap.
There are plenty of vaccines that are giving too great side-effects to be administered generally, when the risk is low. Some guesses in this case might involve some pretty aggressive adjuvant to get the body to target a protein that you won't get immunity against after a normal infection. (Simple test: have a lot of people been infected with Influenza A twice in the last hundred years? Yep. So, obviously, the protein itself makes quite a lousy target and we need to provoke the immune system to actually recognize it. Such provocation can sometimes be quite nasty.)
Vista doesn't stop you from using just-about-any software to rip to MP3. I think it might have changed the default (easily accessible) behavior for WMA ripping to be a bit more restrictive, but overall, the DRM features aren't intended to stop things you can do in XP. It's rather targeted at content no XP user will be allowed to decode at all at full quality (unless/until it's cracked).
It's the detection methods and the connection to breast cancer, not the nucleotide sequence itself, that's covered by the patent. Compare this with the original discovery of blood groups for transfusions, that was patentable as well. Coming up with good protocols for inducing the proper antibodies in animals (one way to do it), for example.
In this case, the specific sequences connected to the disease was not common knowledge beforehand. In addition, you have to come up with relevant primers to amplify the relevant sequence in a specific, yet reproducible, manner to aid detection. I don't think anyone has really tried to challenge the exact scope of the patent, as it might be possible to circumvent it by changing the method or even trying to purify and detect the protein product instead. (However, that would NOT be a trivial thing to do, much harder than the current genetic test.)
It really depends on the heap (the specific data structures keeping track of the blocks) in use, but it can result in other blocks also beeing freed incorrectly. If you are able to replace the first block at the address with another, during the relevant timespan, you can get THAT one freed, which then can cause some other part of the kernel, relying on that new data, to crash. As the buffers involved here are all allocated in-kernel, I would think you need to do some tricky timing-dependent work to get a real exploit going. If you don't have debugging privileges, you won't know the address used yourself, and you'll need to trick some other API to choose to allocate that very same memory, unless, of course, the data structures are severly damaged by just the double-free event, without any new allocation between the two.
A C-based API with a quirky event handling model, obscene attempts to preserve backward compatibility and somewhat loyal developers? Hmmm... I've never heard of that before.
Slashdot Mirror
If the vast majority did in fact result in a child if unattended, then your argument would make more sense. Having an embryo, in a uterus, is a necessary but far from sufficient condition to get a child within a few months, even with the mother kept alive and (overall) healthy.
Postfix, not prefix. It even applied to functions. LEFT$, RIGHT$, MID$, CHR$. Oh, the joy of (MS) BASIC...
Even if the Wifi bandwidth can sustain it, high Wifi usage is a battery killer on many devices... Higher compression or some features provided locally can actually make it lighter while still useful. It's a tradeoff and I note that you didn't mention battery life at all. P4 laptops were also quite cheap and they had those wonderful fans and > 90 W chargers :-)
Hey, setjmp/longjmp and/or OS/library support for fibers could solve that! (and/or a separate thread...)
Naturally this requires that the exe is not using some proprietary compression scheme, and that no relocations have been needed (rebase is your friend).
Anyway, this means that loading something that's been swapped out from disk can require accesses all over the place. Putting that data in a medium with basically zero additional penalty for random access, like a flash drive, can make a lot of sense. This would apply to all swap data, as the access patterns are rather random, but if you want to be able to jack the flash drive out at any moment, you need to have some second backing for the data in case of such an event. Where do we find that? In the real binaries, of course!
Optimizing defragmentation tries to achieve this by putting relevant binaries close together, but you still have to seek within that area, and seek back to some place in the real swap (to load volatile data back). By moving some of those operations over to a device with good random access behavior, you'll even get higher performance out of those operations that are still handled by the HD. All in theory...
Python also allows on-the-fly redefinitions, which is blamed here. Generally, the choice of scripting language is not the problem here. Most "Javascript" bugs translate directly into VBScript if you're IE-masochistic (or Perlscript, if you've managed to install that and trick IE into running the engine for it). The problem is in the DOM, what objects might theoretically be exposed, and how it's crucial that some part of the browser can access them, while others should not. After all, in Mozilla, the whole UI is held together by Javascript, running in basically the same engine, but a different sandbox. The situation with the IE scripting environment is quite comparable.
Now, I know you said vulnerabilities, but I wanted to point out that some parts of the Office functionality has already been removed this way. Javascript off by default for unknown sites has so far been a "geeky" attitude, the web would certainly change if that attitude would turn into norm.
It's naturally also a matter of paper quality. My impression was that the material for bills in most countries is frequently cotton-derived, quite dense and also lacking more volatile contaminants (high-cellulose content, suitable inks). They are, after all, washable...
Well, as the ovaries are not directly connected to the invagination of yours, the inner of the abdomen is actually exposed. The topology is hence quite different (in a highly theoretical sense no clear definition of inner vs. outer surface). Or, to quote Trek: "For the world is hollow and I've touched..."
If you don't know how to access command history, autocompletion and aliases in cmd.exe, that's bad for you. They are there. Some of it has been there ever since DOSKEY entered in MS-DOS 4.0 (or was it 3.x? never mind...). It sounds like you have started command.com, not cmd.exe if you claim that autocompletion is missing from a default XP. Just a guess...
The new video driver model also includes a much large user mode part. In essence, the "miniport" in kernel is back to maybe actually being a thin layer doing the real HW interaction, while the user mode part is loaded in process. (While the other Vista user mode drivers I mentioned are separate processes.)
As others have noted, OS and hardware specific features (that nonetheless are following the specs) can get cheap consumer routers to behave strangely. DLink DI-624+ routers (at least those sold in some regions) couldn't handle multiple Centrinos with adaptive power management, for example. A temporary instruction to disable the setting was released (hurting battery life), finally followed by a firmware update. Maybe the Intel implementation is really in error, but if so, D-link never bothered to make that accusation.
It's just the nagging fact that the second biggest problem, next to users damaging/losing data/configuration/software is when they THINK that they've deleted something (be it their porn cookies, an angered email draft or some nasty spyware), but it's still there, in plain sight or somewhat hidden. A complete undo stack, stored in files, is just the thing that you wouldn't want to carry when others access the same file, but you still want it if you access it yourself over the network... even if you happen to use a different username. There are conflicting interests here, and total persistence is not the answer. That's even ignoring the real problem of (a considerable portion of) users filling up disks whatever we throw at them.
No templates, no multiple inheritance, no C syntax compatibility (although some things are quite trivial to translate between C and Pascal).
Agriculturalism leads to technology.
Long, and variable, but deterministic, is also quite ok. However, it should still be stored serverside, since it seems (to me) that the only point of including the hash in a production system would be to avoid storing the session information. Then, the creative hacker will naturally switch the hash value and add a matching input string when the form is posted.
Because as-of-yet relatively uncommon hardware isn't "allowed" to even play the material (in full quality).
.mil
ReadyBoost is just a mirror of what's frequently kept as memory-mapped files fragmented over the drive (or possibly swap on drive sometime). The point is that you can benefit from reading from the flash sometimes, if the HD is busy, but you NEVER put anything only on the flash. You can take that USB key out any time, and it shouldn't hurt (in theory). Needless to say, that's not true of general swap.
There are plenty of vaccines that are giving too great side-effects to be administered generally, when the risk is low. Some guesses in this case might involve some pretty aggressive adjuvant to get the body to target a protein that you won't get immunity against after a normal infection. (Simple test: have a lot of people been infected with Influenza A twice in the last hundred years? Yep. So, obviously, the protein itself makes quite a lousy target and we need to provoke the immune system to actually recognize it. Such provocation can sometimes be quite nasty.)
Vista doesn't stop you from using just-about-any software to rip to MP3. I think it might have changed the default (easily accessible) behavior for WMA ripping to be a bit more restrictive, but overall, the DRM features aren't intended to stop things you can do in XP. It's rather targeted at content no XP user will be allowed to decode at all at full quality (unless/until it's cracked).
In this case, the specific sequences connected to the disease was not common knowledge beforehand. In addition, you have to come up with relevant primers to amplify the relevant sequence in a specific, yet reproducible, manner to aid detection. I don't think anyone has really tried to challenge the exact scope of the patent, as it might be possible to circumvent it by changing the method or even trying to purify and detect the protein product instead. (However, that would NOT be a trivial thing to do, much harder than the current genetic test.)
It really depends on the heap (the specific data structures keeping track of the blocks) in use, but it can result in other blocks also beeing freed incorrectly. If you are able to replace the first block at the address with another, during the relevant timespan, you can get THAT one freed, which then can cause some other part of the kernel, relying on that new data, to crash. As the buffers involved here are all allocated in-kernel, I would think you need to do some tricky timing-dependent work to get a real exploit going. If you don't have debugging privileges, you won't know the address used yourself, and you'll need to trick some other API to choose to allocate that very same memory, unless, of course, the data structures are severly damaged by just the double-free event, without any new allocation between the two.
This has nothing to do with Visual Basic. It's the plain and simple Win32 API. The demo just happens to be written in VB.NET using .NET Interop.
A C-based API with a quirky event handling model, obscene attempts to preserve backward compatibility and somewhat loyal developers? Hmmm... I've never heard of that before.