Yeah, and demo writers or some scientific computing grad student will surely be able max the PS3. It's just when it comes to integrating that power into the little thing called sensible gameplay that it might still be hard, just like you won't max out the cars on real roads.
Reservation: I didn't read TFA, I've no idea about CVE numbers, but the CVE number for this issue was first listed as "reserved" over a month ago. Not two months after it was found, but still six weeks or so.
Nope, the 32-bit address space is already broken up by assumptions made long ago by library and OS writers, making the longest continuous areas available much smaller. This can be even more true in a managed environment, like Java or.NET. If you have to jump through all kinds of tricks just to be able to address all the RAM you need, then you have a real problem, and we're hitting that problem with 32-bit right now. There are lots of places where code could be made simpler if we could just mmap in all the file data we want, but that's not possible right now even for quite modest file sizes.
Will that be syntax sensitive? The point of the parent is that you can change the name of one method in one class, and make it apply to the complete project, while use of ANOTHER method, which just happens to use the same name, won't be affected. (Really, the name collision might be the original reason for implementing the change.)
OLE structure storage was present as alternate NTFS streams in NT 5 Beta 2 (and maybe also Windows 2000 beta 3, not sure anymore). Some Office files could become strange when saved on such partitions, especially when later accessed over the network. It was dropped from the actual release, but this also means that it was present, in a limited way, in Real Code. There's also a lot of support for storing keywords/properties for individual files in NTFS and exposing some of it in Explorer, but "nobody" uses it.
Win32 is not to Win16 what Win64 is to Win32. Win64 is a recompile, with a few typedefs changed and a few further changes where they were really needed.
Win32 contained lots of changes compared to Win16. Threads, overlapping I/O, lots of new controls, additions to GDI, long file names, pipes for IPC. It might seem like a joke, but access violations really had a greater chance of not taking the full machine down in Win95, versus Win 3.1.
And of course, a full driver model for all devices, with the Registry (yuck) to track the config. Yep, you could do anything in a VXD in 3.1, but there was no real structure to it. 32 bit disk I/O wasn't present in the original 3.1 either, so the difference is greater if we compare 3.1 versus 95, or the very last releases of 3.11 WfW versus 95.
Well, not really. It's almost the other way round for many things, all loaded DLLs will count as part of the work set, so in many types of measurements you'll get a much higher number than the total commit size if you sum over all active processes.
Do you have any reference for your statement of only one instruction (as defined in the ISA) per clock per core? The microops are what's actually scheduled, and if we don't have any dependencies they will certainly be run in parallel. The instruction decoder on Intel core is rather wide, as well.
Does this mean that you think that any software, written for Windows, that breaks with a new release means that the author of that software has violated the copyright of MS? Even if the developers of the binary blob never looked at the Linux source, it would be trivial to create a dependency on some behavior that eventually changes, especially as the policy of the kernel team is to be quite ignorant regarding preserving behavior that only affects kernel-mode code.
Heck, there are even hacks in Vista to fix an issue that first appeared in Samba with early beta releases. Do you want MS to take them out, because it would be a violation of the Samba license? (Note again that they don't need to read the code to get these issues in, nor to take them out.)
No, but the GPL is the only thing that stops copyright from applying "in full". This means that the legal heirs to those authors would have their say regarding relicensing for the next few decades.
16 million years ago, our ancestors were still great apes, much larger than mice. Another well-kept secret for you: a majority of the mammalian species 16 million years ago evolved into extinction.
What about it? I guess the brain might be a bit confused by the fact that the wall is suddenly translucent, but you see glass all the time. That's what it will look like, you'll think you're seeing something behind the wall.
I wouldn't even call it that unconventional. There are lots of examples of ligand-protein interactions where you can't get the experimental affinity right, unless you make the energy-minimization time-dependent and compute the mean. This is not only a matter of the fact that the protein will adapt slightly when binding the ligand, but really that we have a continuous movement going on. A conformation where one vibration would suddenly be totally fixed, although it looks fine if you look at the static average, might be quite disastrous. This will be important if we ever want to be really good at engineering new enzyme specificities, or new ligands. Creating perfumes is of course a rather useless special case of the latter, and while it might be news to the odor industry, it shouldn't raise any eyebrows in the pharmeceutical industry. (At least if TFA is anywhere close to describing the actual theory...)
All chemical bonds are quantum-level effects. You're absolutely right that this is just about the receptors, and it would have been a great surprise if those did NOT show great specificity, with far more than simple sterical relationships. On the other hand, this also applies to just about every neuron junction, where you have specific receptors for neuropeptides. Those are just as much, or as little, quantum physics as this. In addition, just about every enzymatic system with some movement going on is naturally quite dependent on effects like these (and hence a pain to model, it's hard enough to get a static structure right).
You're basically right, though: Major oscillations between groups of neurons or anything like that is something radically different than this, and this theory doesn't make that any more likely. Even in that case, there is no reason to scream "quantum" (as in: impossible to handle with good old Newtonian physics/statistical chemistry/thermodynamics), as the main effects should be the varying electrical field, which we can easily measure with EEG electrodes. Some degree of leakage/overhearing is known, but I've no idea if anyone has found that as crucial to proper function, rather than a noise effect that's generally filtered out.
Actually, major crossover events, creating a different chromosomal makeup, can be a very efficient barrier against fertile off-spring. We can observe lots of single nucleotide polymorphisms (SNPs), the "purest" mutation you can achieve, in humans. Some of them cause known phenotypical differences, far from all of them lethal. Then, we also have all those mutations that really just replace one codon for an amino-acid with another one for the same residue, with very limited effects, if any.
Because not all hardware state is CPU state. A Bluetooth card driver from 3Com would always crash when resuming from hibernation (on my machine) a few years ago. On another machine, there is the odd event of a garbled bitmap cache, probably some kind of synching error where the graphics driver is insisting on that the stuff is still in memory, while that memory was really powered down for a few hours and the content needs to be recreated.
You really do need the cooperation from drivers or hardware specific firmware to do this. Doing it in all firmware, but firmware specific to each device, is certainly possible, but it would entail saving a far more complex state to fool the OS. (In the GPU example, one would need to save a more or less complete image of the GPU memory as well, while the most reasonable solution is to recreate it properly when resuming, as that operation is simple enough and there already is code present to do that during normal use.)
Well, you really can get away get quite well without using pointers in C++. It won't be fast, it won't always be pretty, but you really can write non-trivial stuff with only references and STL containers doing the allocation. What's really hard is to do C++ without both pointers and non-trivial use of templates...
I'm still not convinced that Open Document is, in practice, that independent of the ideas behind the document storage structure in OpenOffice.org. Just the fact that it's just about impossible to represent a Word document exactly the same in ODF means that there are some orthogonalities. Not-Invented-Here gets quite relevant if it means that you are going to try to fit a square into a circle. (Of course, that's what everyone else has done with MS' formats so far. I think that relatively well-documented XML formats, even if they're quite different, will still be a step forward for interoperability, as you can apply XSLTs and other 3rd-party customized processing with much greater ease.)
802.11g is 54 Mbit, not 54 MB/s. Your calculation seems to be based on the latter. That means that this technology is a significant improvement, while not something ground-shattering. (And, for those wondering, this would also beat 802.11n, but the margin gets thinner.)
Terror balance! "I know what you did last summer, so you better keep your hands off my 419 mail side income." Naturally, this means that you shoudln't hire those bastards that come out clean in the background check, you can't blackmail those guys and gals.
The geometry of a Euclidean plane is, possibly, something that (pre-)human minds has indirectly handled for far longer than any counting beyond fingers and toes whatsoever... Real numbers aren't very fundamental, if they were, the mental resistance against irrational numbers would have been much lower.
While this is true in some cases, there are lots and lots of purely "academical" papers that are also a combination of buzz-word dropping and references. In the field of NLP, it's certainly not true. Just look at Brown et al's original paper on the IBM-1 translation model (the name was coined quite some time after the original article), or for that matter what one can find from Microsoft Research in this area. Maybe some journals feel the urge to get more in touch with "practical applications" and are therefore more lenient in what's accepted, as long as you claim it to be "real-world", but it's a great mistake to think that this applies to all corporate research.
Native hardware drivers available doesn't mean it's a piece of cake to get it working in virtualization. It might be if you, say, was ready to give up the iSight completely in OS X, and only expose it to Parallels (then you could "simply" forward the specific hardware access, instead of providing virtualized hardware), but to get it working properly, where any app, no matter what OS it's running on, can access any piece of hardware, you need much more tinkering with the hardware on the guest and/or host side than just proper native drivers for that piece of hardware in the two environments.
Yeah, and demo writers or some scientific computing grad student will surely be able max the PS3. It's just when it comes to integrating that power into the little thing called sensible gameplay that it might still be hard, just like you won't max out the cars on real roads.
Reservation: I didn't read TFA, I've no idea about CVE numbers, but the CVE number for this issue was first listed as "reserved" over a month ago. Not two months after it was found, but still six weeks or so.
Will that be syntax sensitive? The point of the parent is that you can change the name of one method in one class, and make it apply to the complete project, while use of ANOTHER method, which just happens to use the same name, won't be affected. (Really, the name collision might be the original reason for implementing the change.)
OLE structure storage was present as alternate NTFS streams in NT 5 Beta 2 (and maybe also Windows 2000 beta 3, not sure anymore). Some Office files could become strange when saved on such partitions, especially when later accessed over the network. It was dropped from the actual release, but this also means that it was present, in a limited way, in Real Code. There's also a lot of support for storing keywords/properties for individual files in NTFS and exposing some of it in Explorer, but "nobody" uses it.
Win32 contained lots of changes compared to Win16. Threads, overlapping I/O, lots of new controls, additions to GDI, long file names, pipes for IPC. It might seem like a joke, but access violations really had a greater chance of not taking the full machine down in Win95, versus Win 3.1.
And of course, a full driver model for all devices, with the Registry (yuck) to track the config. Yep, you could do anything in a VXD in 3.1, but there was no real structure to it. 32 bit disk I/O wasn't present in the original 3.1 either, so the difference is greater if we compare 3.1 versus 95, or the very last releases of 3.11 WfW versus 95.
Well, not really. It's almost the other way round for many things, all loaded DLLs will count as part of the work set, so in many types of measurements you'll get a much higher number than the total commit size if you sum over all active processes.
Do you have any reference for your statement of only one instruction (as defined in the ISA) per clock per core? The microops are what's actually scheduled, and if we don't have any dependencies they will certainly be run in parallel. The instruction decoder on Intel core is rather wide, as well.
Heck, there are even hacks in Vista to fix an issue that first appeared in Samba with early beta releases. Do you want MS to take them out, because it would be a violation of the Samba license? (Note again that they don't need to read the code to get these issues in, nor to take them out.)
No, but the GPL is the only thing that stops copyright from applying "in full". This means that the legal heirs to those authors would have their say regarding relicensing for the next few decades.
16 million years ago, our ancestors were still great apes, much larger than mice. Another well-kept secret for you: a majority of the mammalian species 16 million years ago evolved into extinction.
What about it? I guess the brain might be a bit confused by the fact that the wall is suddenly translucent, but you see glass all the time. That's what it will look like, you'll think you're seeing something behind the wall.
Not when the whole point is that those 2 " cover most of your field of view.
I wouldn't even call it that unconventional. There are lots of examples of ligand-protein interactions where you can't get the experimental affinity right, unless you make the energy-minimization time-dependent and compute the mean. This is not only a matter of the fact that the protein will adapt slightly when binding the ligand, but really that we have a continuous movement going on. A conformation where one vibration would suddenly be totally fixed, although it looks fine if you look at the static average, might be quite disastrous. This will be important if we ever want to be really good at engineering new enzyme specificities, or new ligands. Creating perfumes is of course a rather useless special case of the latter, and while it might be news to the odor industry, it shouldn't raise any eyebrows in the pharmeceutical industry. (At least if TFA is anywhere close to describing the actual theory...)
You're basically right, though: Major oscillations between groups of neurons or anything like that is something radically different than this, and this theory doesn't make that any more likely. Even in that case, there is no reason to scream "quantum" (as in: impossible to handle with good old Newtonian physics/statistical chemistry/thermodynamics), as the main effects should be the varying electrical field, which we can easily measure with EEG electrodes. Some degree of leakage/overhearing is known, but I've no idea if anyone has found that as crucial to proper function, rather than a noise effect that's generally filtered out.
Actually, major crossover events, creating a different chromosomal makeup, can be a very efficient barrier against fertile off-spring. We can observe lots of single nucleotide polymorphisms (SNPs), the "purest" mutation you can achieve, in humans. Some of them cause known phenotypical differences, far from all of them lethal. Then, we also have all those mutations that really just replace one codon for an amino-acid with another one for the same residue, with very limited effects, if any.
You really do need the cooperation from drivers or hardware specific firmware to do this. Doing it in all firmware, but firmware specific to each device, is certainly possible, but it would entail saving a far more complex state to fool the OS. (In the GPU example, one would need to save a more or less complete image of the GPU memory as well, while the most reasonable solution is to recreate it properly when resuming, as that operation is simple enough and there already is code present to do that during normal use.)
Well, you really can get away get quite well without using pointers in C++. It won't be fast, it won't always be pretty, but you really can write non-trivial stuff with only references and STL containers doing the allocation. What's really hard is to do C++ without both pointers and non-trivial use of templates...
I'm still not convinced that Open Document is, in practice, that independent of the ideas behind the document storage structure in OpenOffice.org. Just the fact that it's just about impossible to represent a Word document exactly the same in ODF means that there are some orthogonalities. Not-Invented-Here gets quite relevant if it means that you are going to try to fit a square into a circle. (Of course, that's what everyone else has done with MS' formats so far. I think that relatively well-documented XML formats, even if they're quite different, will still be a step forward for interoperability, as you can apply XSLTs and other 3rd-party customized processing with much greater ease.)
802.11g is 54 Mbit, not 54 MB/s. Your calculation seems to be based on the latter. That means that this technology is a significant improvement, while not something ground-shattering. (And, for those wondering, this would also beat 802.11n, but the margin gets thinner.)
Terror balance! "I know what you did last summer, so you better keep your hands off my 419 mail side income." Naturally, this means that you shoudln't hire those bastards that come out clean in the background check, you can't blackmail those guys and gals.
The geometry of a Euclidean plane is, possibly, something that (pre-)human minds has indirectly handled for far longer than any counting beyond fingers and toes whatsoever... Real numbers aren't very fundamental, if they were, the mental resistance against irrational numbers would have been much lower.
While this is true in some cases, there are lots and lots of purely "academical" papers that are also a combination of buzz-word dropping and references. In the field of NLP, it's certainly not true. Just look at Brown et al's original paper on the IBM-1 translation model (the name was coined quite some time after the original article), or for that matter what one can find from Microsoft Research in this area. Maybe some journals feel the urge to get more in touch with "practical applications" and are therefore more lenient in what's accepted, as long as you claim it to be "real-world", but it's a great mistake to think that this applies to all corporate research.
HTML is code, of course it is. HTML is not a programming language, though.
Native hardware drivers available doesn't mean it's a piece of cake to get it working in virtualization. It might be if you, say, was ready to give up the iSight completely in OS X, and only expose it to Parallels (then you could "simply" forward the specific hardware access, instead of providing virtualized hardware), but to get it working properly, where any app, no matter what OS it's running on, can access any piece of hardware, you need much more tinkering with the hardware on the guest and/or host side than just proper native drivers for that piece of hardware in the two environments.