Can you spell Opteron? It's already here. In addition, no, integration of the memory controller doesn't turn it into L2. It's not caching another part of the address space without software involvement, it's not SRAM, it's not fast...
Possibly. But, what I was talking about is that some sysinternals tools overload/hook certain kernel calls. The system call tables are, IIRC, write protected even from kernel when the kernal has been loaded in the current/coming Win64 editions.
One can note that Microsoft is stopping some kinds of hooking of individual kernel functions in the AMD64 release of XP. It's motivated by the fact that it won't break binary compatibility with existing code, as it would be broken anyway, and that it leads to sounder use of the API. It makes some rootkitting harder, and tools like regmon (not filemon, as it can hook as a filesystem filter driver). It doesn't make any of it impossible, though. It should really be noted that some of the low-level tools from sysinternals use very similar techniques to what a rootkit would do, just that they do it for monitoring and not with falsification of data as intent.
The lack of censorship get a certain vaporwareness about it if you can, and will, be killed all too soon if you say certain things. Hey, they could even leave the sites online, just be expedient enough with the head chopping business and it suddenly doesn't really matter.
The right to life remains quite central, if only as a prerequisite to exercising free speech.
It is only a problem if the OS/RDBMS config won't be wise enough about what is written when and how they enforce flushing of proper parts. Or, of course, the HD blatantly ignores any hint to force a flush operation and so on.
Yeah, you have to rely on quantum computing to do that. Alternatively, you have to prove that lots of "possible" chess positions don't actually appear, no matter how the other player plays, on the way to the optimal win.
The number of chess positions is, very naively and as a significant underestimation, something like C(8, 64) * C(8,56) * C(8, 48) * C(8,40).
Even this severe underestimation gives 1.8E35, or about 2^117.
Let's say that 2^80 problems are crackable today and that we wouldn't have the non-locality problems of chess (a move consists of computing another position and then you have to see if that is already in the database of computed moves, not as parallel as just trying encryption keys 'til it works). The added 2^37 is on the scale of 13 billions. If 2^80 is done in a year now, this would require the age of the universe.
We can guess that we, if lucky, get to trust Moore for our lifetimes. Hoping that it will get better than that is a long shot, in my mind. The development of computing speed for computing machines in the Turing sense will probably rather slow down. Even if the current speed of increasing computation capacity was maintained and chess would be as simple as encryption testing (calculating moves is simpler, coordinating the effort and addressing the memory isn't), it would taket 56 years to get to the point where a run would take a year -- based on extremely optimistic assumptions.
Finally, we haven't even got to the point about how to store all that information. 6E23 hydrogen atoms weigh about a gram (Avogadro and all that). Let's say we store one bit for each atom. We would need one billion kilograms of storage to store one bit for each of the possible chess positions. To reach less than 1 bit/position seems quite hard...
I think it's a bit of both. The current weakness shown is still so computationally intensive that, IIRC, it's equal to less than two decades of Moore's observation. Ok, that's quite a lot of time, but it's not like it was thought that it could "never" be cracked (by Turing machines) before the discovery.
The problem in SHA-512, as known now, would be far more unlikely than the inherent "weakness" in the original SHA-1 hashing (i.e, you can [just about] always find a collision by trying enough combinations).
[just about] => if one hash was unique for a very specific data set with data sizes larger than the hash size, one could argue that this would also be a problem in the hashing algorithm. If you were able to backconvert to password + salt from hash, that would be minusminusgood.
You're wrong. Or, rather, "bitness" is a very silly measure. In a general purpose chip, you can measure the maximum word size for single operations.
Then, you realize that the current SSE/3Dnow etc stuff will actually handle 128-bit data.
Then, you can think that you should measure the bandwidth of the memory bus. With dual channels, that's generally 128 bits now for CPUs, but for Intel, the memory bus is of course still a part of the chipset. Most GPUs top out at 256, with lower counts and basically the same architecture for the cheaper models. The front-side bus in Intel chips is 64-bit, but running on a higher frequency. Also, most accesses, IIRC, are aligned to be the size of one cache line - 64 bytes or 512 bits. Also, note that the 8088 was an 8-bit CPU and the 80386 sx a 16-bit CPU by this definition. Obviously not what we want.
Finally, we can measure it by the addressing model. This makes some sense and then we also get to the result that AMD64 was the first x86-like ISA to achieve 64-bit flat space addressing. The "flat space" requirement is important, as we want to consider the 8086 (/8088) 16-bit and not 20-bit (16-bit segment + 16-bit offset with locked segment spacing). In this area, many GPUs are tailored to their actual memory capacity. Why should we waste addressing bits and consequentially lines on stuff we can't use?
By this definition, a modern GPU isn't "even" 32-bit, but why the heck should we care. The number of bits as a performance metric is stupid unless one has to take extra measures to avoid the boundary. That was the case in 16-bit x86 code, and is currently the case in some heavy-iron 32-bit code. The number of bits "of" a GPU is not a relevant metric.
Sorry, but AMD64/EM64T is really much more than just a fancy addition. To once again get into a situation where your virtual address space is totally superior to the amount you really need is positive. This is not without cost, though, as the memory bandwidth and space requirements increases.
8 more general purpose registers will do well to most code.
SSE3 in Prescott was an addition with very little real usage so far. The 64-bit x86-based ISA is a prime example of what you'll hate yourself for not having in a few years from now. So, now you have to wait some more time before you can get an affordable 64-bit CPU. If you're currently in love with the positive points of SMP, you will even have to wait for an affordable dual-core 64-bit chip. Good luck....
Possibly, depending on the settings. On the other hand, I've seen several benchmarks (at least on x86, not looked at AMD64) where icc gave better performance on K7/K8 CPUs than GCC and the Microsoft compiler.
Intel wants you to use their compiler for all your needs and if you can afford it (and possibly take the time for extra annotation and library usage) you get great performance on all implementations.
Also, remember that a leg is not dropping. I know you indirectly said so by mentioning the energy stores and so on, but I think it's important to make it an explicit point.
We approximate a pendulum rather than letting the foot be some kind of ball attached to a "string" (the leg) bouncing up and down. Human movements without a proper grasp of angular momentum gives strange interpretation, like that of the OP.
And, of course, fairly high performance per cycle. I think that even a Prescott will crunch out more IPC than a Cyrix C3. IPW (instructions per watt) is of course a different matter...
And, just before anyone asks me to do an ARM-to-x86 comparison of IPC, that won't work. If you have a RISC architecture, of course you'll get high IPC. Make each instruction easy and atomic and you get a lot of benefits, including bogus IPC numbers for comparisons. That's why we need MIPS (not the architecture) and MFLOPS for architecture comparisons, and it's still a matter of lying, statistics and... *shudder* benchmarking.
OTOH, the current crop of Pocket PCs are able to decode DivX in 640x480 with ARM-based chips from Intel, even without video acceleration. It's not like this kind of performance is a revolutionary breakthrough.
Also, remember that AT&T was most specifically broken up, which MS wasn't. The intended buyer of AT&T is one of the sections that were dropped off during that forced break-up.
It's like MS Office had been forced into its own company, flourished under another name and finally, twenty years later, bought the remains of the main company back. If that would have been proof of the failure of MS, I'm not sure.
At the same time by dumping all that cruft from the core OS, they can make the OS something more advanced. XP was a pretty big leap from Win2K in that direction (dropping support for CPUs below P II for example). I would have to guess that Longhorn is going to be an even bigger jump which is why it's taking so long.
What the heck are you talking about? XP works on a Pentium-I without MMX. It didn't have the FDIV bug, though, so I haven't actually tried that.
Well, isn't the interesting point that many modern "BSD-like" licenses allow GPL relicensing? (It's the matter of copyright notice or not.)
How anyone could view the possibility for yourself to choose a more restrictive license as encumbering for their use of said code is probably illiterate xor RMS.
I'm more afraid it would be the uncommon cold -- a virus that once might have pested the Earth and mammals, but which haven't been exposed to in a great while.
On the other hand, common cold corona viruses won't last for many hours outside of a host. Hopefully, they are shattered to pieces if they got there.
The possibility of remnants of ancient Earth life on Mars is, IMHO, a possibly larger threat of disease for humans getting there anything separately evolved on Mars, as that's more likely to be different enough to be harmless to us.
I don't think that's only a good thing, because that also may lock the series into certain views and themes in a bad way. The TNG episodes have a huge diversity, at the cost of consistency:-)
OTOH, I liked much of Babylon 5 and prefer it over Enterprise (but not anything that really has Star Trek in its name). I think he would certainly be able to do a good job.
First, let's just remember that ALL code that's been released now under the GPL will stay so. We won't lose what we already have.
That said, one could, in some manner, compare patents to the GPL. The ideas are in both cases that disclosure of the method is a good thing, but that you should get something back for doing so. In the case of the GPL, you get back that no one can release a product without also putting it under the GPL. Personal/development use is OK. (And inhouse commercial use, that's a difference, read on.)
A patent should, ideally, describe the method in such a way that it actually gives some insight that people in the field wouldn't have had without reading the patent. The patent holder should get protection of the method, but at the "price" of disclosure of said method. Others will be allowed to read the patent, but without being able to make money on it - AFAIK, development and research use based on existing patents is generally allowed.
Of course - the main difference is that the GPL is based on copyright, the very code used, while patents are methods. But, despite the existence of the L/GPL, disputes based on the legality of binary-only code interacting with, or ostensibly including parts of, GPL protected code is not just some imaginary concept.
I think that there can be some legitimacy in software patents. RSA was, in the light of public knowledge at the time, damn cool, for example. We also need to relate to what is patentable in other areas of technology, where the system works well enough. A description of a simple "packaging" file format is nothing more than a properly documented header file! A good compression or encryption algorithm is something quite differen. I know, we didn't like LZW/GIF, but the point there was the patent lurking. Patent in themselves on well-defined, limited things should be a rather limited problem. I am well aware that this is not how the system currently pans out.
GPL is currently limited enough in the code it covers and friendly enough to interaction with binary-only code (through proper parts being L/GPL). If the general tendency to L/GPL proper parts was abolished and GNU got dominant in a MS-like manner (or even more than MS), I would say that this could pose similar problems to people wanting to make money out of their software-based creativity in quite a similar way that the software patent practice of too-general and too-many is.
I've harder to see how a license allowing free, even commercial, use without relicensing on the same conditions, could get to such a dominant position, nor "forcingly" maintain that position. Of course, if you believe in a Free Software vision, this property of the GPL may be a good thing. And a closed-source license in such a position is of course no better.
Slashdot Mirror
Can you spell Opteron? It's already here. In addition, no, integration of the memory controller doesn't turn it into L2. It's not caching another part of the address space without software involvement, it's not SRAM, it's not fast...
Possibly. But, what I was talking about is that some sysinternals tools overload/hook certain kernel calls. The system call tables are, IIRC, write protected even from kernel when the kernal has been loaded in the current/coming Win64 editions.
One can note that Microsoft is stopping some kinds of hooking of individual kernel functions in the AMD64 release of XP. It's motivated by the fact that it won't break binary compatibility with existing code, as it would be broken anyway, and that it leads to sounder use of the API. It makes some rootkitting harder, and tools like regmon (not filemon, as it can hook as a filesystem filter driver). It doesn't make any of it impossible, though. It should really be noted that some of the low-level tools from sysinternals use very similar techniques to what a rootkit would do, just that they do it for monitoring and not with falsification of data as intent.
The right to life remains quite central, if only as a prerequisite to exercising free speech.
100 Mbps for real is not very widespread, and even when delivered, you won't, even theoretically, reach it for anything but maybe a local DC hub.
His humor is fantastically more complex than you can ever hope to be. (Or maybe you just carried it on...)
The number of chess positions is, very naively and as a significant underestimation, something like C(8, 64) * C(8,56) * C(8, 48) * C(8,40).
Even this severe underestimation gives 1.8E35, or about 2^117.
Let's say that 2^80 problems are crackable today and that we wouldn't have the non-locality problems of chess (a move consists of computing another position and then you have to see if that is already in the database of computed moves, not as parallel as just trying encryption keys 'til it works). The added 2^37 is on the scale of 13 billions. If 2^80 is done in a year now, this would require the age of the universe.
We can guess that we, if lucky, get to trust Moore for our lifetimes. Hoping that it will get better than that is a long shot, in my mind. The development of computing speed for computing machines in the Turing sense will probably rather slow down. Even if the current speed of increasing computation capacity was maintained and chess would be as simple as encryption testing (calculating moves is simpler, coordinating the effort and addressing the memory isn't), it would taket 56 years to get to the point where a run would take a year -- based on extremely optimistic assumptions.
Finally, we haven't even got to the point about how to store all that information. 6E23 hydrogen atoms weigh about a gram (Avogadro and all that). Let's say we store one bit for each atom. We would need one billion kilograms of storage to store one bit for each of the possible chess positions. To reach less than 1 bit/position seems quite hard...
I think it's a bit of both. The current weakness shown is still so computationally intensive that, IIRC, it's equal to less than two decades of Moore's observation. Ok, that's quite a lot of time, but it's not like it was thought that it could "never" be cracked (by Turing machines) before the discovery.
[just about] => if one hash was unique for a very specific data set with data sizes larger than the hash size, one could argue that this would also be a problem in the hashing algorithm. If you were able to backconvert to password + salt from hash, that would be minusminusgood.
Then, you realize that the current SSE/3Dnow etc stuff will actually handle 128-bit data.
Then, you can think that you should measure the bandwidth of the memory bus. With dual channels, that's generally 128 bits now for CPUs, but for Intel, the memory bus is of course still a part of the chipset. Most GPUs top out at 256, with lower counts and basically the same architecture for the cheaper models. The front-side bus in Intel chips is 64-bit, but running on a higher frequency. Also, most accesses, IIRC, are aligned to be the size of one cache line - 64 bytes or 512 bits. Also, note that the 8088 was an 8-bit CPU and the 80386 sx a 16-bit CPU by this definition. Obviously not what we want.
Finally, we can measure it by the addressing model. This makes some sense and then we also get to the result that AMD64 was the first x86-like ISA to achieve 64-bit flat space addressing. The "flat space" requirement is important, as we want to consider the 8086 (/8088) 16-bit and not 20-bit (16-bit segment + 16-bit offset with locked segment spacing). In this area, many GPUs are tailored to their actual memory capacity. Why should we waste addressing bits and consequentially lines on stuff we can't use?
By this definition, a modern GPU isn't "even" 32-bit, but why the heck should we care. The number of bits as a performance metric is stupid unless one has to take extra measures to avoid the boundary. That was the case in 16-bit x86 code, and is currently the case in some heavy-iron 32-bit code. The number of bits "of" a GPU is not a relevant metric.
8 more general purpose registers will do well to most code.
SSE3 in Prescott was an addition with very little real usage so far. The 64-bit x86-based ISA is a prime example of what you'll hate yourself for not having in a few years from now. So, now you have to wait some more time before you can get an affordable 64-bit CPU. If you're currently in love with the positive points of SMP, you will even have to wait for an affordable dual-core 64-bit chip. Good luck....
Intel wants you to use their compiler for all your needs and if you can afford it (and possibly take the time for extra annotation and library usage) you get great performance on all implementations.
I, for one, welcome our three-law abiding new bipedal robot overlords.
We approximate a pendulum rather than letting the foot be some kind of ball attached to a "string" (the leg) bouncing up and down. Human movements without a proper grasp of angular momentum gives strange interpretation, like that of the OP.
And, just before anyone asks me to do an ARM-to-x86 comparison of IPC, that won't work. If you have a RISC architecture, of course you'll get high IPC. Make each instruction easy and atomic and you get a lot of benefits, including bogus IPC numbers for comparisons. That's why we need MIPS (not the architecture) and MFLOPS for architecture comparisons, and it's still a matter of lying, statistics and... *shudder* benchmarking.
OTOH, the current crop of Pocket PCs are able to decode DivX in 640x480 with ARM-based chips from Intel, even without video acceleration. It's not like this kind of performance is a revolutionary breakthrough.
It's like MS Office had been forced into its own company, flourished under another name and finally, twenty years later, bought the remains of the main company back. If that would have been proof of the failure of MS, I'm not sure.
How anyone could view the possibility for yourself to choose a more restrictive license as encumbering for their use of said code is probably illiterate xor RMS.
On the other hand, common cold corona viruses won't last for many hours outside of a host. Hopefully, they are shattered to pieces if they got there.
The possibility of remnants of ancient Earth life on Mars is, IMHO, a possibly larger threat of disease for humans getting there anything separately evolved on Mars, as that's more likely to be different enough to be harmless to us.
No slash...
OTOH, I liked much of Babylon 5 and prefer it over Enterprise (but not anything that really has Star Trek in its name). I think he would certainly be able to do a good job.
That said, one could, in some manner, compare patents to the GPL. The ideas are in both cases that disclosure of the method is a good thing, but that you should get something back for doing so. In the case of the GPL, you get back that no one can release a product without also putting it under the GPL. Personal/development use is OK. (And inhouse commercial use, that's a difference, read on.)
A patent should, ideally, describe the method in such a way that it actually gives some insight that people in the field wouldn't have had without reading the patent. The patent holder should get protection of the method, but at the "price" of disclosure of said method. Others will be allowed to read the patent, but without being able to make money on it - AFAIK, development and research use based on existing patents is generally allowed.
Of course - the main difference is that the GPL is based on copyright, the very code used, while patents are methods. But, despite the existence of the L/GPL, disputes based on the legality of binary-only code interacting with, or ostensibly including parts of, GPL protected code is not just some imaginary concept.
I think that there can be some legitimacy in software patents. RSA was, in the light of public knowledge at the time, damn cool, for example. We also need to relate to what is patentable in other areas of technology, where the system works well enough. A description of a simple "packaging" file format is nothing more than a properly documented header file! A good compression or encryption algorithm is something quite differen. I know, we didn't like LZW/GIF, but the point there was the patent lurking. Patent in themselves on well-defined, limited things should be a rather limited problem. I am well aware that this is not how the system currently pans out.
GPL is currently limited enough in the code it covers and friendly enough to interaction with binary-only code (through proper parts being L/GPL). If the general tendency to L/GPL proper parts was abolished and GNU got dominant in a MS-like manner (or even more than MS), I would say that this could pose similar problems to people wanting to make money out of their software-based creativity in quite a similar way that the software patent practice of too-general and too-many is.
I've harder to see how a license allowing free, even commercial, use without relicensing on the same conditions, could get to such a dominant position, nor "forcingly" maintain that position. Of course, if you believe in a Free Software vision, this property of the GPL may be a good thing. And a closed-source license in such a position is of course no better.