Anyone else see the irony in the "OpenCable" process being used to DRM TV content?
It jumped out at me. Fortunately,/. has Irony Rights Management to prevent these vicious attacks on innocent bystanders. Thank God somebody's out there Managing my Rights!
--
The universe is a figment of its own imagination.
How do they figure that colored bubbles qualify for a grand award? There might be some real applications for this technology, but somehow giving a grand award to soap bubbles seems pretty silly, to put it nicely.
--
The universe is a figment of its own imagination.
The reality is that there is no general "speedup factor" that quantum always gives.
You're abslutely right -- I'm not quite sure what I was thinking when I said that, but it was clearly wrong. My only excuse is that I must not have been entirely awake. I apologize.
--
The universe is a figment of its own imagination.
This breakthrough completely renders useles the concept of the so-called one-way function, a function which can be executed in polynomial time, but whose inverse can be executed only in exponential time. Basically, this renders just about all public-key cryptographic functions obselete on one stroke.
This is pure nonsense!
First of all, not all public-key cryptography relies on the difficulty of factoring for its security. Second, even RSA (which does) is far from being instantly rendered useless or obsolete. To make a long story short, the number of steps to do factoring on a quantum computer is approximately the square root of the number of steps required on a classical computer.
That simply means that to achieve the same level of security in the face of quantum computing, you need to use a key large enough to square the number of steps needed -- as it happens, that works out to twice as large of a key.
The largest RSA pseudo-prime that's been factored is 576 bits -- so quantum computers could (theoretically) factor about a 1152-bit pseudo-prime with about the same level of effort. Just for reference, quite a few programs (e.g. pgp, gpg) already support RSA keys much larger than this -- 2048 and 4096 bits are quite commonly supported. If you're using a 4096-bit key with PGP/GPG, you're already using a large enough key to defend against a heavy duty attack using quantum computers.
--
The universe is a figment of its own imagination.
I know you meant this humorously, but it's probably worth noting that in reality, the quantum computers that have been built are NOT in silicon either -- in fact, they're not really based on semiconductors at all.
They're currently (basically) a test-tube full of specially constructed "soup" of (for example) hydrogen and carbon-14 (yes, the same that's used for carbon dating) suspended in chloroform. The results from this are read using an NMR (Nuclear Magnetic Resonance) machine, essentially like those used in medical imaging.
Unfortunately, even the people doing research in this direction admit that there's little likelihood of building NMR based quantum computers of more than a few (half a dozen or so) qubits, which is really too small to do much -- and the NMR-based reading of the results is also quite slow. OTOH, while they may not be particularly practical, they have managed to do real quantum computation this way.
--
The universe is a figment of its own imagination.
The question is of the efficiency saving of doing all the converting in a big box against the efficiency loss of piping it around the data centre as dc, and wether you get a large total net saving (which I suspect that you do, since even inside the data centre, it's not going far)
There's more to it than that. The problem is that essentially all of these systems run on UPSs. A UPS takes the AC in and converts it to DC to charge a battery. It then takes the DC from the battery and converts it back to AC to power the computer. The computer's power supply then takes the AC and converts it back to DC again to run the computer itself. Each of these times, the voltage is also changed.
The conversions from AC to DC are reasonably efficient, but the conversion from DC to AC is a lot less so. The voltage conversions are somewhat inefficient as well.
Of course, it's probably also true that even disregarding all of the above, a single large power supply can be made somewhat more efficient than a large number of smaller power supplies. As far as distribution goes, the problem isn't really AC vs. DC -- it's one of voltage vs. current. Specifically, the size of wiring you use depends primarily on the current they need to carry, but I agree that data centers are usually small enough that having to use larger wiring for that short a distance probably isn't a major concern for most people.
--
The universe is a figment of its own imagination.
Today I was at a meeting discussing computing issues for numerical simulations of particle physics being done on computers at CERN.
[...]
Nonetheless... on all the machines I've used there,/proc/cpuinfo says they're running P4's or P4-based Xeons. Wouldn't running Athlon 64's or Opterons (in 64-bit mode, since they're all on Linux) give better performance and less heat?
That depends on their code. Numerical simulations are mostly floating point that's often quite vectorizable. In that case, they could be using SSE2 quite a bit, which generally works better on the Intel chips -- but they probably won't get much benefit from this unless they're hand-optimizing at least a few of their inner loops. Most compilers can do some automatic vectorization, but they don't make good enough use of the capability to overcome the Intel chip's shortcomings elsewhere, as a rule.
OTOH, if they're doing a lot of vector math, they'd probably get considerably better performance still by writing the code to execute on the GPU instead. The obvious shortcoming of that would be accuracy problems -- the GPU's floating point is engineered far more to maximize speed than accuracy.
--
The universe is a figment of its own imagination.
But if you read on, the idea does seem quite daft. They want to abolish leap seconds because recalibrating their clocks is a pain in the ass and keeping accurate track of time over long periods is complicated by leap seconds.
Leap seconds are a bit more than simply a pain for people trying to do precise time-keeping. As far as being daft goes, I really don't know -- it's a bit odd when one second elapses, but we change the clock by two seconds.
OTOH, compared to daylight savings time, these are fairly trivial -- in particular, leap seconds are always an extra second inserted (i.e. the clock still always moves forward -- just once in a while it goes forward faster). Daylight savings time has the distinctly different property that with it time moves backward, so (for example) the exact same date/time happens twice (with only the ST vs. DT to separate the two).
I also think the mention of astronomy is mostly a red herring. Astronomers normally use sidreal time, which differs from "normal" time by about 4 minutes a day anyway -- so changing that by a constant value of a second every few years is a fairly trivial detail to deal with.
In the end, I'm not sure I see any particularly strong reason this change should be made, but I think most of the cited reasons for keeping it the same are pretty weak too.
--
The universe is a figment of its own imagination.
I don't see why IPV6 needs to have 128 bits for addresses.
128-bit addressing isn't really necessary -- but it makes life really simple. With IPv4, you have a subnet mask (that AFAICT, 90% of people never quite understand) that tells how much of your address is devoted to the local subnet, and how much isn't. With IPv6, this has simply been fixed at 64 bits apiece, so using it, nobody ever has to figure up a subnet mask again.
A better question would be to turn this around: what would we really gain by reducing the addresses from 128 bits to 64 bits? We'd save 128 bits per packet. Even over a 28.8K dialup line, that's approximately 4 milliseconds per packet. However, IPv6 increases the maximum packet size you can reasonably use, so unless you really need to send lots of tiny packets, its addressing overhead may well be lower than with IPv4. In most cases, you gain a bit, and even in the worst case you lose very little.
If you're doing things like VoIP, IPv6 helps a lot more: in IPv4, QoS was hacked on after the fact (and has never really worked very well), but in IPv6, it's part of the base protocol.
Personally, I think we need to consider the source of TFA: Cisco and APNIC. Cisco is the leading provider of IPv4 routing (etc.) equipment by a wide margin. APNIC derives it "power" largely from the scarcity (and therefore value) of IP addresses.
A shift to IPv6 gives other router manufacturers a much better chance of gaining market share over Cisco -- about the best Cisco can hope for is to maintain their current position, but in reality they're likely to lose at least a little. Cisco has only to look at what happened to Lucent when the market shifted from ATM to IP to see how badly a technology shift can hurt even a huge market leader.
APNIC stands to lose even more: rather than a chance of losing market share, they face a near certainty that a large part of their power base simply ceases to exist.
Looking at it from this (admittedly cynical) direction, what are the chances that they were going to write an article in favor of IPv6, regardless of its merit?
--
The universe is a figment of its own imagination.
I suspect the author of the Wikipiedia article knows a bit more than he's being given credit for elsethread.
Each cell processor includes not only the multiple processors mentioned elsethread, but addressable memory, DMA controller, and a controller for what is essentially a proprietary network. The last is somewhat open to argument -- for example, current AMD CPUs include HyperTransport controllers, which are somewhat similar.
In any case, IBM does (e.g. here) talk about the Cell as a System on a Chip, though IMO, this is a stretch -- a PS3 system includes quite a few other chips, some of them pretty significant (e.g. the GPU). In fact, I find it somewhat difficult to contemplate a system that would make good use of a Cell without a pretty fair number of other chips. OTOH, as the Wikipedia article suggests, it does include a number of elements that are normally implemented in separate chips on a PC.
--
The universe is a figment of its own imagination.
Don't most government-endowed monopolies have chilling unintended consequences on the markets they're supposed to protect?
Answering this requires knowing what would have happened if the government-endowed monopoly didn't exist, and this is essentially impossible to say with any certainty.
What can be said is that before the idea of patents came along, lots of what we now take for granted as common knowledge was typically held as secrets. If you look at history books, you'll quickly notice things about how the pottery in this city, glass in that city, or steel from the other were superior.
These were rarely a consequence of that city having superior natural resources -- it was because the craftspeople in that city developed techniques for making pottery, glass, steel, etc., and carefully kept them secret from everybody else. Nowadays, techniques for manufacturing glass, steel and ceramics are low-tech, but they've gotten that way largely because patents allowed them to be.
Copyright gives incredible power to the top publishers (with a lock on book stores), the recording industry, and the movie distributors.
A copyright simply prevents others from making copies of a book, play, etc. Nothing more. If a publisher (or small group of publishers) have a monopoly on supplying books to particular stores, that's something almost completely unrelated to copyright.
While I think the RIAA, MPAA, and probably others, have abused the powers conferred on them by the DMCA, that's a whole different question from whether the basic idea of a copyright itself is valid. At least IMO, the DMCA really has little to do with the copyright itself, and is really mostly about methods of enforcing copyrights (many of which are open to abuse).
Government's monopoly on prescription drugs causes the costs to skyrocket (death sentence for the poor) and useful drugs to be delayed for years.
How do you figure that patents cause useful drugs to be delayed for years? The delays I've noticed were due to FDA approval processes, not patents.
I can't see much evidence for the idea that patents raise drug prices much either. Rather the opposite. When a patent on a valuable drug runs out, a generic company will normally produce an equivalent that's 30% cheaper or so.
First of all, the patent is exactly where the generic company goes to find out how to create their equivalent. Second, the cost saving seems related largely to reduced marketing costs (because the drug is already known) and reduced research and development costs (because they can follow the directions in the patent).
Chances are that if drugs couldn't be patented, lives would be lost. Without patents that allow them to cheaply copy others' inventions, there would be fewer generic drug companies to produce the lower-priced drugs at all. If we assume generic companies would still exist, the situation's even worse. Motivation for research and development is lost, so the drug never exists, so now everybody dies, rich and poor alike (I realize many would consider this an improvement, but I disagree).
Government's monopoly on patent licensing is no different.
I'm not sure what you even think you're talking about here. The government doesn't have a monopoly on patent licensing in the first place. A patent entitles an inventor to a monopoly on an invention for a limited period of time, in exchange for agreeing that the invention will become public domain (i.e. the property of all) after that limited period has expired.
A patent license is simply an agreement that the patent holder won't enforce that monopoly to prevent somebody else from using their patented technology. Normally the government isn't involved at all (unless it happens to be one of the parties to the transaction).
Launching the craft. How much fuel would it take to get escape velocity on something this massive? Probably not a small amount.
To put things into perspective, an empty space shuttle (just the orbiter) has roughly 5 times this mass. At liftoff a space shuttle (including the external tanks/thrusters, fuel, etc.) has a mass around 11 times what's proposed for this vehicle.
The crew. The time the crew would be away from earth would be how long?
RTFA -- this was specified as a unmanned mission, so the crew would normally be away from home about as long a most of us with normal office jobs (I've no idea what commute time on the Cape runs, but it's probably not as bad as, say, San Francisco).
Coming home. What happens when a ship this large is re-entering Earth's atmosphere? That sucker will have a lot of force coming down.
My guess is that they simply wouldn't have it reenter at all -- once it's done its job, just let it fly away. In any case, it's considerably smaller than a number of other objects that have reentered successfully.
All in all, it's easy to get caught up in a big number like 20 tons, and miss the fact that as space vehicles go, this really isn't particularly huge at all.
--
The universe is a figment of its own imagination.
That's because the phone companies manually program in "adjacencies" - which cells are near to what. It's not the handset that says "I can see Cell 1241, I'm going to move" - it's the phone company's network that tells the phone to move.
That's not really true -- while the base station is programmed with an adjacency list, it basically just acts as a crib for the handset. In particular, while a base station can detect when the signal from a handset is getting weak, it has no way to guess at the direction to the handset. The adjacency list contains some base stations closer to the handset, while others are in the opposite direction from the handset, and the base station has no clue of which is which.
So what happens during a handoff is simply that the base station gives the handset a list of other base stations it should look for, and the handset looks for which of those gives it the best signal. This restricts the search, so the handset can find other base stations quickly and easily using a minimum of power. It is true that although the handset initiates the handoff, the base stations talk directly to each other to finalize it (i.e. they coordinate between themselves to decide on the exact packet when one base station quits sending the data out over the network, and the second base station starts to do so) -- though the details of handoff vary from one type of network to another as well.
--
The universe is a figment of its own imagination.
Mesh networking is nothing like cellular networks.
Oh, I realize from a technical viewpoint they're entirely different -- but I also realize that from the viewpoint of using them, the primary differences are speed and cost; minor (!) details like who assigns addresses or how the data is routed after it gets to the ground station clearly make a big difference in how you design the network, but are (hopefully) transparent in how you use them.
Realistically, it's true that somewhere between those, you get the job of deploying the network, and here it still makes a big difference -- particularly, in most cases, Joe Blow won't be able to install a network himself if he has to program in the handoff partners manually.
Nonetheless, an awful lot of people get a professional to do at least major parts of network installation, and for somebody who has a clue of what they're doing, this wouldn't make a big difference in most circumstances -- you program them in once, and only mess with things when you have to replace something. Of course, being from Cisco these boxes will undoubtedly require at least a dozen commands to do anything, (or entries at a GUI designed specifically to make a command line seem as straightforward as possible) but that's just Cisco, and really has nothing to do with mesh networking...
--
The universe is a figment of its own imagination.
Okay, I went through TFA very quickly, but how does this differ from a simple RSS feed?
RSS requires a source that provides the RSS feed. Some RSS aggregators do screen-scraping and such to aggregate data from various sources that don't directly support RSS. Most of these, however, need to know quite a bit about a specific non-RSS web site and how it formats its data before they can do much with it.
The idea here seems to be for the tool to do a search to find all the blogs (and maybe web sites in general) that cover your chosen subject matter, and then have enough "smarts" to do screen-scraping (or something on that order) to provide you with an aggregation on all of them without requiring a lot of prior knowledge about the site and its formatting.
--
The universe is a figment of its own imagination.
It'll be interesting to see how much different this really is from a cell phone network. Cell phones have already handled (for well over a decade) things like handing an active call off from one access point to the next. Typical wireless networks, by contrast, don't handle this well at all, and until/unless they start to, they'll remain far short of their potential.
Of course, the other direction works as well: cell networks providing faster access. Unfortunately, most cell providers seem (to me) to be shooting themselves in the foot, charging far too high of prices for data access. IMO, they'd be better off trying to maximize market share in this segment by selling the service at near break-even pricing. I did a bit of math a while back, and figured that at least from one provider, each bit of "data" cost something like 5 times as much to transmit as each bit of "voice" -- strange, at least IMO.
--
The universe is a figment of its own imagination.
Presently we do not know of any methods to factor a number in polynomial time while we can create primes in polynomial time, but an algorithm may exist that can factor primes in polynomial time. If one is discovered, encryption as we know it today will be impossible...
Nonsense. First of all, factoring per se only affects RSA encryption.
It's likely that a major advance in factoring would also affect the security of Diffie-Hellman key exchange and ElGamal encryption, but it's not an absolute certainty. These are based on discrete logarithms, and while finding discrete logarithms hasn't (TTBOMK) been proven equivalent to factoring, current factoring methods can also be applied to finding discrete logarithms, and there's some theoretical basis for assuming any future ones will as well. For example, here is a paper discussing the relationship between the two (warning: quite mathematical).
Those aren't the only methods of public-key cryptography though -- for example, elliptic curve cryptography might well be unaffected. In particular, both factoring and discrete logarithms display a property called "smoothness" (about which, see the paper above) which is necessary for the various "sieve"-type algorithms to operate correctly. At least so far, nobody has shown that elliptic curves have the property of smoothness (though various mathematicians argue both for and against its likelihood). As a consequence, breaking elliptic curve cryptogaphy uses entirely different methods, and there's little reason to believe that even a major advance in factoring would necessarily have any real effect on elliptical curve cryptography at all.
Then we come to all the symmetric ciphers -- DES, 3DES, IDEA, FEAL, RC4, RC5, RC6, AES, and many, many more. The vast majority of these have little or nothing to do with prime numbers, and even the most amazing advance in factoring would be unlikely to affect any of them at all. The applicable area of mathematics is entirely different -- most symmetric algorithms are based in number theory while most symmetric algorithms are based on group theory.
Since "quantum" has been thrown around a bit, I'll try to add a bit of clarification on that subject as well. Unfortunately, there are two rather different sorts of things related to cryptography that use quantum in their names. As has been noted elsethread, what's generally called quantum cryptography would more accurately be called quantum key exchange. It's basically just a way of sendin some bits over a fiber optic cable, and the receiver can detect whether anybody has tapped into the line to see what was sent.
The second "quantum" thing is quantum computers. The Shor algorithm (due to Peter Shor) does factoring on a quantum computer in polynomial time, which is more or less the holy grail in fast factoring. The problem is that at least at the present time, there's no such thing as a practical quantum computer -- the most "powerful" quantum computers to date haven't even been sufficiently capable to replace a pocket calculator. Worse, the methods used to create quantum computers so far are widely believed to be unscalable, so there's no certainty that quantum computers can ever become practical -- though there's a great deal of research being devoted to the subject, and there's certainly a possibilty that they might.
If quantum computers were to become practical, they would also affect symmetric ciphers. Basically, searching for the key of a symmetric cipher is normally proportional to the size of the key space. For a quantum computer, the search is proportional to the square root of the size of the key space instead.
This, however, has less effect that most people realize. In particular, the size of the key space is squared by doubling the size of the key. In point of fact, many (if not most) current symmetric ciphers already use keys large enough to render attacks by quantum computers
Wouldn't the ultimate obfuscation be to write an obfuscation compiler that retranslates the C code into obfuscated code, and then run that compiler against its own source code? Repeat several hundred times. I couldn't imagine the resulting code to ever be understandable.
If you look back through old winners, you'll find one that sort of did that: it was a program that could reverse text or do ROT13 on text, or (IIRC) both.
The trick was that you could run it on its own source code (in any mode) and produce a program that did the same thing, using a different algorithm each way, no less. While all the versions were quite heinous, my recollection is that ROT13 and reversal did manage to make it marginally worse.
Unfortunately, unless my memory serves even worse than usual tonight, you need a fairly ancient compiler to make it compile at all (and C++ compilers need not apply -- I'm pretty sure it depends on undeclared functions, among other things).
--
The universe is a figment of its own imagination.
I agree. And the thing that puzzled me most is why it isn't ditched even when there is a chance to do so. For example, when AMD designed x86-64, which is incompatible with x86 by nature, they still made i t almost like x86, shortcomings and all. It has few registers (although they recognized the problem and gave x86-64 more registers), and the instructions are variable length, complex, irregular in format, and with various side effects, making them hard for compilers to target and hard for the CPU to decode.
Intel has tried to replace the x86 repeatedly -- the iAPX432, the i860 and the Itanic^Hum have all been pushed as possible replacements. Unfortunately, when you get down to it, they've all had problems that rendered them inferior to the mainstream x86 for most real use.
First of all, x86 isn't really all that hard to target -- and after umpteen years of writing compilers for it, people have gotten good enough at it, that nearly every "shortcoming" has been put to good use sometime or other. x86 is certainly trivial to target compared to VLIW/EPIC architectures.
Decoding isn't really all that big of a deal either: they (or it, in the case of P4) consume(s) less than 1% of the area of a modern chip. In exchange for that, you get an instruction set that's considerably more dense than (for example) most so-called RISCs.
This has two substantial payoffs. First, the memory bandwidth consumed to read instructions is reduced. Second, the effectiveness of the L2 cache is increased because it can store more instructions.
This is why (for example) an x86 uses only about 40-50% of the chip area for cache, where a RISC often has to devote around 60-75% of its area to cache. The investment of 1% into the decoders pays a dividend of 10-25% in the L2 cache. Now, in fairness, even though it's a small area, the decoder design is relatively difficult. Even though it's bigger, the cache area is much easier to design.
The result is that the x86 costs more to design, but (substantially) less to manufacture (assuming similar speed, manufacturing technology, etc.) This favors the x86 in relatively high volume situations, where the manufacturing cost dominates, and RISCs in lower volume where the design cost dominates.
RISC was originally developed when most CPUs had no on-board cache and most CPUs typically didn't use nearly all the available memory bandwidth. The decoders, microinstruction ROMs and sequencers, etc., consumed a substantial part of the chip, and often limited the clock speed as well. Under those circumstances, eliminating microinstructions and simplifying decoders made a lot of sense.
Those days are gone though: now, CPU clock speeds outrun bandwidth to memory by a wide margin so nearly every CPU devotes substantial chip area to caching. As a percentage of overall size, the decoder(s) and microinstruction ROMs/sequencers have shrunk nearly to insignificance. Decoding has been pipelined to the point that among production processors, x86's have higher clock speeds than RISCs, by a fairly wide margin.
Registers are a bit of a tradeoff as well. While more registers make it easier to write nice code, they also make context switches slower. On modern versions of the SPARC (for one example) they have quite a complex mechanism to handle register swapping lazily, so the registers are basically treated like an L0 cache. Data is swapped into the registers on demand, rather than all registers being loaded before a context switch is considered complete. I don't know for sure, but it wouldn't surprise me if this consumes more chip area than the decoders on an Athlon (for example).
At the same time, the L1 cache minimizes the penalty for repeated access to a small amount of data, so the gain from having the most frequently-used data in registers is much smaller than used to be common.
Anyway, the bottom line is that while most of the considerations you've raised are valid, most of them are really much more tradeoffs than a clearly inferior design.
--
The universe is a figment of its own imagination.
Without "unsigned", the signedness of char is undefined.
Nitpick of the day: not "undefined" but "implementation defined".
In C's version of standardese, "undefined" basically means something you shouldn't ever do, but the compiler isn't required to stop you from doing. "Implementation defined" means something that may vary in some way from one compiler to the next, but that it's still perfectly reasonable to do.
--
The universe is a figment of its own imagination.
Fortunately, there's also: The C Answer Book
Which obviously has all the answers.:-)
Actually, none of these is settling at all -- all three are excellent books, at least IMO. Much of Holub's book also applies about as well to Java as to C or C++, for that matter.
--
The universe is a figment of its own imagination.
Obviously. Unfortunately, they didn't have an option to show only 8 years (or anything else between "5 years" and "maximum"). I hope my assumption that readers would be able to count back 8 years wasn't misplaced...
--
The universe is a figment of its own imagination.
Slashdot Mirror
The breakdown is likely closer to:
To a modern TV producer "real depth" means "explosions and cleavage."
--
The universe is a figment of its own imagination.
It jumped out at me. Fortunately, /. has Irony Rights Management to prevent these vicious attacks on innocent bystanders. Thank God somebody's out there Managing my Rights!
--
The universe is a figment of its own imagination.
--
The universe is a figment of its own imagination.
Thanks for trying to be nice about it, but that would be a correction rather than a clarification. :-)
--
The universe is a figment of its own imagination.
Because it's not OpenBSD?
--
The universe is a figment of its own imagination.
You're abslutely right -- I'm not quite sure what I was thinking when I said that, but it was clearly wrong. My only excuse is that I must not have been entirely awake. I apologize.
--
The universe is a figment of its own imagination.
This is pure nonsense!
First of all, not all public-key cryptography relies on the difficulty of factoring for its security. Second, even RSA (which does) is far from being instantly rendered useless or obsolete. To make a long story short, the number of steps to do factoring on a quantum computer is approximately the square root of the number of steps required on a classical computer.
That simply means that to achieve the same level of security in the face of quantum computing, you need to use a key large enough to square the number of steps needed -- as it happens, that works out to twice as large of a key.
The largest RSA pseudo-prime that's been factored is 576 bits -- so quantum computers could (theoretically) factor about a 1152-bit pseudo-prime with about the same level of effort. Just for reference, quite a few programs (e.g. pgp, gpg) already support RSA keys much larger than this -- 2048 and 4096 bits are quite commonly supported. If you're using a 4096-bit key with PGP/GPG, you're already using a large enough key to defend against a heavy duty attack using quantum computers.
--
The universe is a figment of its own imagination.
I know you meant this humorously, but it's probably worth noting that in reality, the quantum computers that have been built are NOT in silicon either -- in fact, they're not really based on semiconductors at all.
They're currently (basically) a test-tube full of specially constructed "soup" of (for example) hydrogen and carbon-14 (yes, the same that's used for carbon dating) suspended in chloroform. The results from this are read using an NMR (Nuclear Magnetic Resonance) machine, essentially like those used in medical imaging.
Unfortunately, even the people doing research in this direction admit that there's little likelihood of building NMR based quantum computers of more than a few (half a dozen or so) qubits, which is really too small to do much -- and the NMR-based reading of the results is also quite slow. OTOH, while they may not be particularly practical, they have managed to do real quantum computation this way.
--
The universe is a figment of its own imagination.
There's more to it than that. The problem is that essentially all of these systems run on UPSs. A UPS takes the AC in and converts it to DC to charge a battery. It then takes the DC from the battery and converts it back to AC to power the computer. The computer's power supply then takes the AC and converts it back to DC again to run the computer itself. Each of these times, the voltage is also changed.
The conversions from AC to DC are reasonably efficient, but the conversion from DC to AC is a lot less so. The voltage conversions are somewhat inefficient as well.
Of course, it's probably also true that even disregarding all of the above, a single large power supply can be made somewhat more efficient than a large number of smaller power supplies. As far as distribution goes, the problem isn't really AC vs. DC -- it's one of voltage vs. current. Specifically, the size of wiring you use depends primarily on the current they need to carry, but I agree that data centers are usually small enough that having to use larger wiring for that short a distance probably isn't a major concern for most people.
--
The universe is a figment of its own imagination.
That depends on their code. Numerical simulations are mostly floating point that's often quite vectorizable. In that case, they could be using SSE2 quite a bit, which generally works better on the Intel chips -- but they probably won't get much benefit from this unless they're hand-optimizing at least a few of their inner loops. Most compilers can do some automatic vectorization, but they don't make good enough use of the capability to overcome the Intel chip's shortcomings elsewhere, as a rule.
OTOH, if they're doing a lot of vector math, they'd probably get considerably better performance still by writing the code to execute on the GPU instead. The obvious shortcoming of that would be accuracy problems -- the GPU's floating point is engineered far more to maximize speed than accuracy.
--
The universe is a figment of its own imagination.
Leap seconds are a bit more than simply a pain for people trying to do precise time-keeping. As far as being daft goes, I really don't know -- it's a bit odd when one second elapses, but we change the clock by two seconds.
OTOH, compared to daylight savings time, these are fairly trivial -- in particular, leap seconds are always an extra second inserted (i.e. the clock still always moves forward -- just once in a while it goes forward faster). Daylight savings time has the distinctly different property that with it time moves backward, so (for example) the exact same date/time happens twice (with only the ST vs. DT to separate the two).
I also think the mention of astronomy is mostly a red herring. Astronomers normally use sidreal time, which differs from "normal" time by about 4 minutes a day anyway -- so changing that by a constant value of a second every few years is a fairly trivial detail to deal with.
In the end, I'm not sure I see any particularly strong reason this change should be made, but I think most of the cited reasons for keeping it the same are pretty weak too.
--
The universe is a figment of its own imagination.
128-bit addressing isn't really necessary -- but it makes life really simple. With IPv4, you have a subnet mask (that AFAICT, 90% of people never quite understand) that tells how much of your address is devoted to the local subnet, and how much isn't. With IPv6, this has simply been fixed at 64 bits apiece, so using it, nobody ever has to figure up a subnet mask again.
A better question would be to turn this around: what would we really gain by reducing the addresses from 128 bits to 64 bits? We'd save 128 bits per packet. Even over a 28.8K dialup line, that's approximately 4 milliseconds per packet. However, IPv6 increases the maximum packet size you can reasonably use, so unless you really need to send lots of tiny packets, its addressing overhead may well be lower than with IPv4. In most cases, you gain a bit, and even in the worst case you lose very little.
If you're doing things like VoIP, IPv6 helps a lot more: in IPv4, QoS was hacked on after the fact (and has never really worked very well), but in IPv6, it's part of the base protocol.
Personally, I think we need to consider the source of TFA: Cisco and APNIC. Cisco is the leading provider of IPv4 routing (etc.) equipment by a wide margin. APNIC derives it "power" largely from the scarcity (and therefore value) of IP addresses.
A shift to IPv6 gives other router manufacturers a much better chance of gaining market share over Cisco -- about the best Cisco can hope for is to maintain their current position, but in reality they're likely to lose at least a little. Cisco has only to look at what happened to Lucent when the market shifted from ATM to IP to see how badly a technology shift can hurt even a huge market leader.
APNIC stands to lose even more: rather than a chance of losing market share, they face a near certainty that a large part of their power base simply ceases to exist.
Looking at it from this (admittedly cynical) direction, what are the chances that they were going to write an article in favor of IPv6, regardless of its merit?
--
The universe is a figment of its own imagination.
Each cell processor includes not only the multiple processors mentioned elsethread, but addressable memory, DMA controller, and a controller for what is essentially a proprietary network. The last is somewhat open to argument -- for example, current AMD CPUs include HyperTransport controllers, which are somewhat similar.
In any case, IBM does (e.g. here) talk about the Cell as a System on a Chip, though IMO, this is a stretch -- a PS3 system includes quite a few other chips, some of them pretty significant (e.g. the GPU). In fact, I find it somewhat difficult to contemplate a system that would make good use of a Cell without a pretty fair number of other chips. OTOH, as the Wikipedia article suggests, it does include a number of elements that are normally implemented in separate chips on a PC.
--
The universe is a figment of its own imagination.
Answering this requires knowing what would have happened if the government-endowed monopoly didn't exist, and this is essentially impossible to say with any certainty.
What can be said is that before the idea of patents came along, lots of what we now take for granted as common knowledge was typically held as secrets. If you look at history books, you'll quickly notice things about how the pottery in this city, glass in that city, or steel from the other were superior.
These were rarely a consequence of that city having superior natural resources -- it was because the craftspeople in that city developed techniques for making pottery, glass, steel, etc., and carefully kept them secret from everybody else. Nowadays, techniques for manufacturing glass, steel and ceramics are low-tech, but they've gotten that way largely because patents allowed them to be.
A copyright simply prevents others from making copies of a book, play, etc. Nothing more. If a publisher (or small group of publishers) have a monopoly on supplying books to particular stores, that's something almost completely unrelated to copyright.
While I think the RIAA, MPAA, and probably others, have abused the powers conferred on them by the DMCA, that's a whole different question from whether the basic idea of a copyright itself is valid. At least IMO, the DMCA really has little to do with the copyright itself, and is really mostly about methods of enforcing copyrights (many of which are open to abuse).
How do you figure that patents cause useful drugs to be delayed for years? The delays I've noticed were due to FDA approval processes, not patents.
I can't see much evidence for the idea that patents raise drug prices much either. Rather the opposite. When a patent on a valuable drug runs out, a generic company will normally produce an equivalent that's 30% cheaper or so.
First of all, the patent is exactly where the generic company goes to find out how to create their equivalent. Second, the cost saving seems related largely to reduced marketing costs (because the drug is already known) and reduced research and development costs (because they can follow the directions in the patent).
Chances are that if drugs couldn't be patented, lives would be lost. Without patents that allow them to cheaply copy others' inventions, there would be fewer generic drug companies to produce the lower-priced drugs at all. If we assume generic companies would still exist, the situation's even worse. Motivation for research and development is lost, so the drug never exists, so now everybody dies, rich and poor alike (I realize many would consider this an improvement, but I disagree).
I'm not sure what you even think you're talking about here. The government doesn't have a monopoly on patent licensing in the first place. A patent entitles an inventor to a monopoly on an invention for a limited period of time, in exchange for agreeing that the invention will become public domain (i.e. the property of all) after that limited period has expired.
A patent license is simply an agreement that the patent holder won't enforce that monopoly to prevent somebody else from using their patented technology. Normally the government isn't involved at all (unless it happens to be one of the parties to the transaction).
To put things into perspective, an empty space shuttle (just the orbiter) has roughly 5 times this mass. At liftoff a space shuttle (including the external tanks/thrusters, fuel, etc.) has a mass around 11 times what's proposed for this vehicle.
RTFA -- this was specified as a unmanned mission, so the crew would normally be away from home about as long a most of us with normal office jobs (I've no idea what commute time on the Cape runs, but it's probably not as bad as, say, San Francisco).
My guess is that they simply wouldn't have it reenter at all -- once it's done its job, just let it fly away. In any case, it's considerably smaller than a number of other objects that have reentered successfully.
All in all, it's easy to get caught up in a big number like 20 tons, and miss the fact that as space vehicles go, this really isn't particularly huge at all.
--
The universe is a figment of its own imagination.
That's not really true -- while the base station is programmed with an adjacency list, it basically just acts as a crib for the handset. In particular, while a base station can detect when the signal from a handset is getting weak, it has no way to guess at the direction to the handset. The adjacency list contains some base stations closer to the handset, while others are in the opposite direction from the handset, and the base station has no clue of which is which.
So what happens during a handoff is simply that the base station gives the handset a list of other base stations it should look for, and the handset looks for which of those gives it the best signal. This restricts the search, so the handset can find other base stations quickly and easily using a minimum of power. It is true that although the handset initiates the handoff, the base stations talk directly to each other to finalize it (i.e. they coordinate between themselves to decide on the exact packet when one base station quits sending the data out over the network, and the second base station starts to do so) -- though the details of handoff vary from one type of network to another as well.
--
The universe is a figment of its own imagination.
Oh, I realize from a technical viewpoint they're entirely different -- but I also realize that from the viewpoint of using them, the primary differences are speed and cost; minor (!) details like who assigns addresses or how the data is routed after it gets to the ground station clearly make a big difference in how you design the network, but are (hopefully) transparent in how you use them.
Realistically, it's true that somewhere between those, you get the job of deploying the network, and here it still makes a big difference -- particularly, in most cases, Joe Blow won't be able to install a network himself if he has to program in the handoff partners manually.
Nonetheless, an awful lot of people get a professional to do at least major parts of network installation, and for somebody who has a clue of what they're doing, this wouldn't make a big difference in most circumstances -- you program them in once, and only mess with things when you have to replace something. Of course, being from Cisco these boxes will undoubtedly require at least a dozen commands to do anything, (or entries at a GUI designed specifically to make a command line seem as straightforward as possible) but that's just Cisco, and really has nothing to do with mesh networking...
--
The universe is a figment of its own imagination.
RSS requires a source that provides the RSS feed. Some RSS aggregators do screen-scraping and such to aggregate data from various sources that don't directly support RSS. Most of these, however, need to know quite a bit about a specific non-RSS web site and how it formats its data before they can do much with it.
The idea here seems to be for the tool to do a search to find all the blogs (and maybe web sites in general) that cover your chosen subject matter, and then have enough "smarts" to do screen-scraping (or something on that order) to provide you with an aggregation on all of them without requiring a lot of prior knowledge about the site and its formatting.
--
The universe is a figment of its own imagination.
Of course, the other direction works as well: cell networks providing faster access. Unfortunately, most cell providers seem (to me) to be shooting themselves in the foot, charging far too high of prices for data access. IMO, they'd be better off trying to maximize market share in this segment by selling the service at near break-even pricing. I did a bit of math a while back, and figured that at least from one provider, each bit of "data" cost something like 5 times as much to transmit as each bit of "voice" -- strange, at least IMO.
--
The universe is a figment of its own imagination.
Nonsense. First of all, factoring per se only affects RSA encryption.
It's likely that a major advance in factoring would also affect the security of Diffie-Hellman key exchange and ElGamal encryption, but it's not an absolute certainty. These are based on discrete logarithms, and while finding discrete logarithms hasn't (TTBOMK) been proven equivalent to factoring, current factoring methods can also be applied to finding discrete logarithms, and there's some theoretical basis for assuming any future ones will as well. For example, here is a paper discussing the relationship between the two (warning: quite mathematical).
Those aren't the only methods of public-key cryptography though -- for example, elliptic curve cryptography might well be unaffected. In particular, both factoring and discrete logarithms display a property called "smoothness" (about which, see the paper above) which is necessary for the various "sieve"-type algorithms to operate correctly. At least so far, nobody has shown that elliptic curves have the property of smoothness (though various mathematicians argue both for and against its likelihood). As a consequence, breaking elliptic curve cryptogaphy uses entirely different methods, and there's little reason to believe that even a major advance in factoring would necessarily have any real effect on elliptical curve cryptography at all.
Then we come to all the symmetric ciphers -- DES, 3DES, IDEA, FEAL, RC4, RC5, RC6, AES, and many, many more. The vast majority of these have little or nothing to do with prime numbers, and even the most amazing advance in factoring would be unlikely to affect any of them at all. The applicable area of mathematics is entirely different -- most symmetric algorithms are based in number theory while most symmetric algorithms are based on group theory.
Since "quantum" has been thrown around a bit, I'll try to add a bit of clarification on that subject as well. Unfortunately, there are two rather different sorts of things related to cryptography that use quantum in their names. As has been noted elsethread, what's generally called quantum cryptography would more accurately be called quantum key exchange. It's basically just a way of sendin some bits over a fiber optic cable, and the receiver can detect whether anybody has tapped into the line to see what was sent.
The second "quantum" thing is quantum computers. The Shor algorithm (due to Peter Shor) does factoring on a quantum computer in polynomial time, which is more or less the holy grail in fast factoring. The problem is that at least at the present time, there's no such thing as a practical quantum computer -- the most "powerful" quantum computers to date haven't even been sufficiently capable to replace a pocket calculator. Worse, the methods used to create quantum computers so far are widely believed to be unscalable, so there's no certainty that quantum computers can ever become practical -- though there's a great deal of research being devoted to the subject, and there's certainly a possibilty that they might.
If quantum computers were to become practical, they would also affect symmetric ciphers. Basically, searching for the key of a symmetric cipher is normally proportional to the size of the key space. For a quantum computer, the search is proportional to the square root of the size of the key space instead.
This, however, has less effect that most people realize. In particular, the size of the key space is squared by doubling the size of the key. In point of fact, many (if not most) current symmetric ciphers already use keys large enough to render attacks by quantum computers
If you look back through old winners, you'll find one that sort of did that: it was a program that could reverse text or do ROT13 on text, or (IIRC) both.
The trick was that you could run it on its own source code (in any mode) and produce a program that did the same thing, using a different algorithm each way, no less. While all the versions were quite heinous, my recollection is that ROT13 and reversal did manage to make it marginally worse.
Unfortunately, unless my memory serves even worse than usual tonight, you need a fairly ancient compiler to make it compile at all (and C++ compilers need not apply -- I'm pretty sure it depends on undeclared functions, among other things).
--
The universe is a figment of its own imagination.
Intel has tried to replace the x86 repeatedly -- the iAPX432, the i860 and the Itanic^Hum have all been pushed as possible replacements. Unfortunately, when you get down to it, they've all had problems that rendered them inferior to the mainstream x86 for most real use.
First of all, x86 isn't really all that hard to target -- and after umpteen years of writing compilers for it, people have gotten good enough at it, that nearly every "shortcoming" has been put to good use sometime or other. x86 is certainly trivial to target compared to VLIW/EPIC architectures.
Decoding isn't really all that big of a deal either: they (or it, in the case of P4) consume(s) less than 1% of the area of a modern chip. In exchange for that, you get an instruction set that's considerably more dense than (for example) most so-called RISCs.
This has two substantial payoffs. First, the memory bandwidth consumed to read instructions is reduced. Second, the effectiveness of the L2 cache is increased because it can store more instructions.
This is why (for example) an x86 uses only about 40-50% of the chip area for cache, where a RISC often has to devote around 60-75% of its area to cache. The investment of 1% into the decoders pays a dividend of 10-25% in the L2 cache. Now, in fairness, even though it's a small area, the decoder design is relatively difficult. Even though it's bigger, the cache area is much easier to design.
The result is that the x86 costs more to design, but (substantially) less to manufacture (assuming similar speed, manufacturing technology, etc.) This favors the x86 in relatively high volume situations, where the manufacturing cost dominates, and RISCs in lower volume where the design cost dominates.
RISC was originally developed when most CPUs had no on-board cache and most CPUs typically didn't use nearly all the available memory bandwidth. The decoders, microinstruction ROMs and sequencers, etc., consumed a substantial part of the chip, and often limited the clock speed as well. Under those circumstances, eliminating microinstructions and simplifying decoders made a lot of sense.
Those days are gone though: now, CPU clock speeds outrun bandwidth to memory by a wide margin so nearly every CPU devotes substantial chip area to caching. As a percentage of overall size, the decoder(s) and microinstruction ROMs/sequencers have shrunk nearly to insignificance. Decoding has been pipelined to the point that among production processors, x86's have higher clock speeds than RISCs, by a fairly wide margin.
Registers are a bit of a tradeoff as well. While more registers make it easier to write nice code, they also make context switches slower. On modern versions of the SPARC (for one example) they have quite a complex mechanism to handle register swapping lazily, so the registers are basically treated like an L0 cache. Data is swapped into the registers on demand, rather than all registers being loaded before a context switch is considered complete. I don't know for sure, but it wouldn't surprise me if this consumes more chip area than the decoders on an Athlon (for example).
At the same time, the L1 cache minimizes the penalty for repeated access to a small amount of data, so the gain from having the most frequently-used data in registers is much smaller than used to be common.
Anyway, the bottom line is that while most of the considerations you've raised are valid, most of them are really much more tradeoffs than a clearly inferior design.
--
The universe is a figment of its own imagination.
Nitpick of the day: not "undefined" but "implementation defined".
In C's version of standardese, "undefined" basically means something you shouldn't ever do, but the compiler isn't required to stop you from doing. "Implementation defined" means something that may vary in some way from one compiler to the next, but that it's still perfectly reasonable to do.
--
The universe is a figment of its own imagination.
Would you settle for slightly different titles like these?
C Traps and Pitfalls
Enough Rope to Shoot Yourself in the Foot
Fortunately, there's also: :-)
The C Answer Book
Which obviously has all the answers.
Actually, none of these is settling at all -- all three are excellent books, at least IMO. Much of Holub's book also applies about as well to Java as to C or C++, for that matter.
--
The universe is a figment of its own imagination.
Obviously. Unfortunately, they didn't have an option to show only 8 years (or anything else between "5 years" and "maximum"). I hope my assumption that readers would be able to count back 8 years wasn't misplaced...
--
The universe is a figment of its own imagination.