Scott A. Crosby wrote this short paper over on cryptome.org, which seems to cover an attack that is very much like the one in the post. Especially the number of devices required in the post (50) matches the number of keysets required by the attack described on cryptome.org (40-50). Coincidence?
Actually firewalls did protect some machines from the attack. There are actually firewalls that will enforce the HTTP protocol specification and hinder buffer overflows. Thereby actually doing their duty as bastion hosts, instead of naively sending packets through.
Sadly glorified routers pass off as firewalls these days.
When you arrive at the destination star with the strong solar wind, you have a lot of speed built up from when you left the source star. The source star will be far away, so its wind will be negligible. Therefore you just fold your sails, and suddenly the wind from the destination star will not affect you all that much. Just unfold them a little if you need to brake.
Actually the real solution would be for the home directory to turn into the root directory for each logged in user. Unfortunately classical Unix cannot do that, but other systems (e.g. HURD) can.
Or just kill the damn filesystem. Databases aren't exactly new technology.
Some of the genetically engineered plants that require less pesticide spray simply produce pesticides themselves. While that is no doubt very good for the workers who will not have to produce pesticides, the advantage for the environment seems much more dubious.
Also, plants are generally not sprayed with pesticide for some weeks before they are harvested, thereby ensuring that there will be little of it left when the plant reaches the consumer. If the plants produce the pesticide themselves, it is hard to make them stop at the appropriate time.
The whole point of RISC is to simplify the decoder. CISC chips always "decoded" complex instructions into multiple "micro-ops". Back in the good old days it was done with microcode, nowadays they have fancier words for it.
CISC and RISC are as different now as they always were. It just turned out that decode speed isn't all that important anymore, so the advantage of RISC is pretty much history. The increased code density of CISC code is much better on the memory bandwidth and the cache.
You can also combine the disadvantages of both architectures. Say by having to have a slow complex decoder and then wasting lots of cache memory by storing the large decoded instructions.
I'm sure no chip producer which has been in the industry for a long time would do such a thing.
And remember, two cpus running in parellel enjor a greater performance boost (on some tasks) then a single processor with twice the speed of either of the dual processors.
That is highly unlikely to happen in practice. For almost all workloads you're happy to scale linearly with the number of processors, and often logarithmic scaling is considered ok. Only jobs with peculiar communication requirements (e.g. where not having to context switch between each communication gives an advantage) or cache requirements (the extra cache on the extra processors keeps a job in cache that otherwise would have hit main memory) exhibit better than linear scalability.
Women are not generally hydrophobic. It is possibly easier and more reliable to bring one into the shower, instead of exposing sensitive electronics to water.
That G4 benchmark looks bogus. It is made with a 400MHz G4 and scores 1233.33; the second best Mac is a 500MHz G4 and scores 360.98.
The only explanation for that is if POVray suddenly got support for ALTIVEC. If that was the case I would have expected that more Mac-users would flock to the site and submit benchmarks.
One reason bandwidth charges are common outside the US is that the US ISP's charge the rest for peering. I.e., a European ISP has to pay both for the use of the undersea cable between US and Europe, and then by the byte for the traffic going to and from the US part of the Internet.
The US ISP's typically do not pay for the traffic that flows to Europe, or for the lines connecting to Europe. I would imagine that the problem would be worse in Australia. Every few years a new cable is added between Europe and the US; whereas laying cable between the US and Australia might be a bit more expensive.
Contrary to popular belief, and contrary to what most people will think after reading the article, Unicode can contain all characters in the world. What the article actually says, in its own roundabout way, is that the UCS-2 encoding of Unicode cannot encode all Unicode characters, and that some of the characters it cannot encode are fairly important.
I can only agree with that. UCS-2 is a silly idea, and UTF-16 is a bad bandaid for it. UTF-8 is great, and if you really must have an encoding with equally much space used by all characters, use UCS-4. UTF-8 is infinitely extendable and will never run out of characters, not even theoretically. UCS-4 can encode millions of characters; the measly 170,000 characters mentioned in the article do not create a problem for UCS-4.
The only problem Unicode has, is that Microsoft chose UCS-2 for some important things in Windows and Office. They are fairly alone in that stupidity.
I have read the agreement. It says that if TrollTech fails to keep making QT available under the Free Edition license, the Foundation is allowed to distribute it under the BSD-like license.
However, there is no obligation that I can see that forces TrollTech to keep a GPL-licensed version around. Since the Free Edition license is not GPL-compatible, the agreement is fairly useless.
Since SETI is most likely purely CPU intensive, there is very little the OS can do to make it faster or slower (apart from deliberately getting in the way, of course). On the other hand, the compiler makes a tremendous difference, and so do the compilation options. Since we do not know which compiler was involved, and which options it was given, the benchmark is fairly useless.
But no, you're not pure after all! You moan about a decent commercial product, and a brilliant GPL one -- and you're using Windows 2000! Hypocrite, hypocrite, hypocrite.
I run Win2k because if I don't I'll have to find another job. Opera and Konqueror are not required for my job.
I don't run Opera because I prefer to use free software when possible. I also prefer to use software that comes neatly packaged with RawHide. As to Konqueror, that is dependant on QT. I avoid QT for religious reasons.
I fail to see where I am moaning though. I have not said that either Opera or Konqueror are bad; if I had technical reasons for avoiding them I would have stated them. My reasoning is political/religious. I am also a little surprised that you think I am not using Linux. I use RedHat Linux because I like the product and because I feel that RedHat is operating in a way that allows me to escape them if they go bankrupt. (I avoid TrollTech by the same reasoning. If TrollTech disappeared, only applications with GPL-compatible licenses could use the QT toolkit.)
I'm feeling the same way. I recently downloaded a Mozilla nightly to the Win2k partition because I was sick and tired of IE crashing. Much to my surprise, it tends to render complicated pages faster than IE 5.5. I have used Mozilla on Linux for a long time since I do not run Konqueror or Opera for religious reasons, but I had sort of given up on Mozilla on Windows. Not anymore.
Before all the GPL stalwarts start getting their flamethrowers out and attempt to give me a good roasting - the GPL prohibits charging for software under its license (except for duplication costs)
The GPL does no such thing. As an example, XEmacs was at one point used in a commercial GPL'd project whose name I have forgotten. It was an IDE on steroids. (Who knows, maybe it's still around?). Anyway, the company behind it charged significantly more than 1kUSD for it.
The GPL only limits how much you can charge for the source if someone you provided with only binaries asks you for it. If you charge 1kUSD there is a risk that RMS will buy a copy and distribute it, of course. Due to the general distrust of software that you don't have to pay for, that is a very minor problem.
A lot of providers have multiple separate IP address blocks. With IPv6 every provider would have more address space than they could ever use, so they would never be assigned more than one block. Just one route per provider would help things a lot.
Actually, the whole SMT thing is so new that people aren't agreeing on what exactly it means.
Some think it means multiple cores on one chip, a la the new POWER4 from IBM. Apparently IBM doesn't think so, since they don't call that SMT themselves. If you go by that definition, then yes, you have just increased CPU power without increasing the overall bandwidth of the system, and that gives you sucky performance.
However, the other definition of SMT is a single core capable of keeping multiple contexts and switching between them without software help. To software they look (almost) like two regular CPU's, and so e.g. linux would assign two processes or threads to each core. The idea is that the core will execute the instructions from virtual CPU #1 until it hits a cache miss. Then it switches to executing instructions from virtual CPU #2, until it hits a cache miss... and so on.
In the second scenario you have a CPU with the same MIPS as before, but suddenly you are not wasting as much CPU power waiting. In the context of the PC industry that means you can get away with smaller caches and memory with higher latency (hello RAMBUS).
It's the same girl every week.
PS: The answer is no, I don't cheat on her.
Constants aren't.
Scott A. Crosby wrote this short paper over on cryptome.org, which seems to cover an attack that is very much like the one in the post. Especially the number of devices required in the post (50) matches the number of keysets required by the attack described on cryptome.org (40-50). Coincidence?
Actually firewalls did protect some machines from the attack. There are actually firewalls that will enforce the HTTP protocol specification and hinder buffer overflows. Thereby actually doing their duty as bastion hosts, instead of naively sending packets through.
Sadly glorified routers pass off as firewalls these days.
32-bit machines should use long long at least for trivialPatentCount.
When you arrive at the destination star with the strong solar wind, you have a lot of speed built up from when you left the source star. The source star will be far away, so its wind will be negligible. Therefore you just fold your sails, and suddenly the wind from the destination star will not affect you all that much. Just unfold them a little if you need to brake.
RAID-5 in hardware kills you, unless you go to very very expensive hardware. Expensive as in more than $5k for the RAID controller alone.
Actually the real solution would be for the home directory to turn into the root directory for each logged in user. Unfortunately classical Unix cannot do that, but other systems (e.g. HURD) can.
Or just kill the damn filesystem. Databases aren't exactly new technology.
Some of the genetically engineered plants that require less pesticide spray simply produce pesticides themselves. While that is no doubt very good for the workers who will not have to produce pesticides, the advantage for the environment seems much more dubious.
Also, plants are generally not sprayed with pesticide for some weeks before they are harvested, thereby ensuring that there will be little of it left when the plant reaches the consumer. If the plants produce the pesticide themselves, it is hard to make them stop at the appropriate time.
On the M68000 the execution units didn't know M68000-instructions, all they handled were micro-ops.
The original 8086 was a weird mix of hard-coded instructions and microcode though.
The whole point of RISC is to simplify the decoder. CISC chips always "decoded" complex instructions into multiple "micro-ops". Back in the good old days it was done with microcode, nowadays they have fancier words for it.
CISC and RISC are as different now as they always were. It just turned out that decode speed isn't all that important anymore, so the advantage of RISC is pretty much history. The increased code density of CISC code is much better on the memory bandwidth and the cache.
You can also combine the disadvantages of both architectures. Say by having to have a slow complex decoder and then wasting lots of cache memory by storing the large decoded instructions.
I'm sure no chip producer which has been in the industry for a long time would do such a thing.
They would have marketed it as "cold, dead fish". s/Commodore/DEC/ to make it on-topic, but I heard it about Commodore first.
Women are not generally hydrophobic. It is possibly easier and more reliable to bring one into the shower, instead of exposing sensitive electronics to water.
That G4 benchmark looks bogus. It is made with a 400MHz G4 and scores 1233.33; the second best Mac is a 500MHz G4 and scores 360.98.
The only explanation for that is if POVray suddenly got support for ALTIVEC. If that was the case I would have expected that more Mac-users would flock to the site and submit benchmarks.
One reason bandwidth charges are common outside the US is that the US ISP's charge the rest for peering. I.e., a European ISP has to pay both for the use of the undersea cable between US and Europe, and then by the byte for the traffic going to and from the US part of the Internet.
The US ISP's typically do not pay for the traffic that flows to Europe, or for the lines connecting to Europe. I would imagine that the problem would be worse in Australia. Every few years a new cable is added between Europe and the US; whereas laying cable between the US and Australia might be a bit more expensive.
Contrary to popular belief, and contrary to what most people will think after reading the article, Unicode can contain all characters in the world. What the article actually says, in its own roundabout way, is that the UCS-2 encoding of Unicode cannot encode all Unicode characters, and that some of the characters it cannot encode are fairly important.
I can only agree with that. UCS-2 is a silly idea, and UTF-16 is a bad bandaid for it. UTF-8 is great, and if you really must have an encoding with equally much space used by all characters, use UCS-4. UTF-8 is infinitely extendable and will never run out of characters, not even theoretically. UCS-4 can encode millions of characters; the measly 170,000 characters mentioned in the article do not create a problem for UCS-4.
The only problem Unicode has, is that Microsoft chose UCS-2 for some important things in Windows and Office. They are fairly alone in that stupidity.
I have read the agreement. It says that if TrollTech fails to keep making QT available under the Free Edition license, the Foundation is allowed to distribute it under the BSD-like license.
However, there is no obligation that I can see that forces TrollTech to keep a GPL-licensed version around. Since the Free Edition license is not GPL-compatible, the agreement is fairly useless.
Since SETI is most likely purely CPU intensive, there is very little the OS can do to make it faster or slower (apart from deliberately getting in the way, of course). On the other hand, the compiler makes a tremendous difference, and so do the compilation options. Since we do not know which compiler was involved, and which options it was given, the benchmark is fairly useless.
I run Win2k because if I don't I'll have to find another job. Opera and Konqueror are not required for my job.
I don't run Opera because I prefer to use free software when possible. I also prefer to use software that comes neatly packaged with RawHide. As to Konqueror, that is dependant on QT. I avoid QT for religious reasons.
I fail to see where I am moaning though. I have not said that either Opera or Konqueror are bad; if I had technical reasons for avoiding them I would have stated them. My reasoning is political/religious. I am also a little surprised that you think I am not using Linux. I use RedHat Linux because I like the product and because I feel that RedHat is operating in a way that allows me to escape them if they go bankrupt. (I avoid TrollTech by the same reasoning. If TrollTech disappeared, only applications with GPL-compatible licenses could use the QT toolkit.)
I'm feeling the same way. I recently downloaded a Mozilla nightly to the Win2k partition because I was sick and tired of IE crashing. Much to my surprise, it tends to render complicated pages faster than IE 5.5. I have used Mozilla on Linux for a long time since I do not run Konqueror or Opera for religious reasons, but I had sort of given up on Mozilla on Windows. Not anymore.
The GPL does no such thing. As an example, XEmacs was at one point used in a commercial GPL'd project whose name I have forgotten. It was an IDE on steroids. (Who knows, maybe it's still around?). Anyway, the company behind it charged significantly more than 1kUSD for it.
The GPL only limits how much you can charge for the source if someone you provided with only binaries asks you for it. If you charge 1kUSD there is a risk that RMS will buy a copy and distribute it, of course. Due to the general distrust of software that you don't have to pay for, that is a very minor problem.
PS Why doesn't blockquote type="cite" work here?
A lot of providers have multiple separate IP address blocks. With IPv6 every provider would have more address space than they could ever use, so they would never be assigned more than one block. Just one route per provider would help things a lot.
Benny
Actually, the whole SMT thing is so new that people aren't agreeing on what exactly it means.
Some think it means multiple cores on one chip, a la the new POWER4 from IBM. Apparently IBM doesn't think so, since they don't call that SMT themselves. If you go by that definition, then yes, you have just increased CPU power without increasing the overall bandwidth of the system, and that gives you sucky performance.
However, the other definition of SMT is a single core capable of keeping multiple contexts and switching between them without software help. To software they look (almost) like two regular CPU's, and so e.g. linux would assign two processes or threads to each core. The idea is that the core will execute the instructions from virtual CPU #1 until it hits a cache miss. Then it switches to executing instructions from virtual CPU #2, until it hits a cache miss... and so on.
In the second scenario you have a CPU with the same MIPS as before, but suddenly you are not wasting as much CPU power waiting. In the context of the PC industry that means you can get away with smaller caches and memory with higher latency (hello RAMBUS).
Going AC->DC->AC is getting fairly cheap these days with power electronics. Of course it would be much nicer if we just got rid of AC.