From one of the articles:

The spin ice state is argued to be well-described by networks of aligned dipoles resembling solenoidal tubesâ"classical, and observable, versions of a Dirac string. Where these tubes end, the resulting defect looks like a magnetic monopole.

They've managed to create the microscopic equivalent of a long skinny magnet or a long bendy solenoid: a set of dipoles aligned end-to-end, which acts just like a string with two "monopoles" at the ends.

While this is an interesting microscopic state of matter, from the "discovering monopoles" point of view it doesn't seem fundamentally different than the macroscopic description of magnet "poles" that has been well understood for over a century (and observed for a lot longer than that). I call hype.

Terahertz sources don't require particle accelerators. See my post above ("Terahertz generation is an interesting problem".)

Generating terahertz radiation, especially coherent Terahertz radiation, is hard because the frequency (around 300GHz - 20THz) is too low for conventional solid-state laser technology and too high for conventional electronic antennas. And it is potentially useful for a range of applications such as nondestructive high-resolution imaging (for e.g. materials, medical, and security applications), spectroscopy, or opening up new communications bandwidths. (Google "terahertz applications" and you'll find a lot of links.)

There are a number of terahertz sources that are becoming available, from optical rectification schemes to free-electron lasers, but they have a tendency to be bulky and inefficient, so a lot of researchers are looking for alternative generation schemes.

That being said, I suspect that the terahertz radiation produced by sticky tape is incoherent, which would severely limit its utility in practical applications. (Quite apart from the efficiency, which sounds like it is currently very low.) That doesn't mean that it isn't interesting from a basic science perspective, of course.

First of all, you don't understand the meaning of "non-radiative". Whether or not there is power transfer, it is in the near field, not the far field, and hence it is not radiative. Second, it's not sufficient to have the same resonant frequency; you also have to be impedance-matched. The combination of the two is unlikely in the extreme.

Not that you'd learn it from this non-technical news report, but the energy transfer in WiTricity is non-radiative for this and other reasons. Indiscriminately radiating power not only will interfere with other devices (and violate FCC regulations), but also wastes power by dumping it into the environment, not to mention that people tend to dislike the idea that power is being dumped into their brains. See my other post below.

There are several very different schemes currently being explored for wireless power transfer, with different strengths and weaknesses.

• Radiative transfer: send a directed beam of energy from a source to a receiver. The advantage is that this can work over long distances, the disadvantage is that you need to either have fixed locations or some active tracking system to keep pointing at the receiver as it moves around, and you need some kind of automated kill switch to make sure you don't accidentally fry anything that walks between the transmitter and receiver or waste power when the receiver is not there. It looks like PowerCast and PowerBeam fall into this category.
• Traditional inductive, non-radiative power transfer. This works well, and does not transfer power when the receiver is absent, but is extremely short-range if you want any kind of efficiency; typically, the device to be charged must be sitting directly on or adjacent to the charger. The Wireless Power Consortium is pursuing this kind of approach.
• Resonant, non-radiative power transfer. This relies on the source and receiver being electrical resonators at the same frequency, so that they preferentially transfer energy to one another rather than to other objects in the environment via resonant coupling. This is the approach being pursued by WiTricity, where they additionally rely on resonators that couple primarily via magnetic fields (the electric-field energy is mostly in capacitors inside the devices), which have the advantage that most materials are non-magnetic at these frequencies so the power source dissipates very little energy into extraneous objects (or people). (In contrast, Tesla coils produce strong electric fields external to the device, which interact much more strongly with matter; it's no coincidence that Tesla coils are used as lightning generators.) This operates efficiently at mid-range distances although not as far as radiative transfer (meters at most), does not transfer or dissipate power when the receiver is absent, and is not directional so does not require active "pointing" of the power at the receiver. But it is more complicated than the short-range non-resonant inductive transfer, and requires careful impedance-matching of the source and receiver.

Full disclosure: I know Prof. Soljacic at MIT, who founded WiTricity, although I personally have no financial interest in the company; all of the above information is public and published, however.

It's called copyright law. Yes, it is a pain, but that's not Wikipedia's doing.

The problem is, getting permission just to "use" an image on Wikipedia is not enough. You need to get permission to use it under a license compatible with Wikipedia's goals: it has to permit the image not only to be used, but also to be redistributed, modified, even sold (although you can require redistribution under the same terms allowing free redistribution etc.). Furthermore, you need to get permission from the owner of the copyright - as other posters have noted, this is often the photographer, not the subject of the photo.

I'm sorry you had difficulty contributing to Wikipedia, but don't blame Wikipedia for diligently attempting to follow copyright law, or for your own ignorance thereof.

I was thinking of the (thinly disguised) flat file system that shipped on the original Macintosh in 1984.

As pointed out in this review:

You can move whole directories but the Kindle flattens them out listing every file (by file name) separately on the main home page.

You can't organize PDFs into directories on the Kindle, which makes accessing a large number of PDFs a serious problem. It's like 1984.

(The lack of PDF annotation capability is also a headache.)

I haven't seen those benchmarks, and I'm quite skeptical of your claim that ZFS is CPU-bound by 64-bit integer operations. The only times I've heard of where filesystems are CPU-bound are when they are using compression and/or encryption, and both of those problems can operate on narrower integers (possibly in 128-bit vectors ala SSE).

As for simulations, the overwhelming majority of scientific simulations rely on floating-point arithmetic.

You've got to be joking. Filesystem operations use 64-bit integer calculations, sure, but that is not even close to their being performance limiting. Do you realize how many orders of magnitude slower the disk is than the CPU?

64-bit integer calculations are rarely if ever a performance bottleneck (not including address calculations). And in applications where 32-bit integers were already wide enough for you, there is no benefit to going 64-bit integers (and it is actually slower because of increased cache pressure).

Name one real-world application in which 64-bit integer calculations (not including address calculations) are a significant performance bottleneck, and 32-bit integers are too narrow.

In 32-bit mode, PowerPC and SPARC registers are 32-bit (on 64-bit systems they're just sign-extended when running 32-bit code).

I can't believe how much total nonsense is being propagated on this thread. To quote the IBM PowerPC Instruction Set Architecture manual:

Implementations of this architecture provide 32 floating-point registers (FPRs). [...] Each FPR contains 64 bits that support the floating-point double format.

So, you have it completely backwards: there are no 32-bit single-precision registers on PowerPC, whether in 32-bit or 64-bit mode. It only has 64-bit double-precision registers. Single-precision floating-point operations (not including AltiVec) are done with the double-precision hardware, and are rounded to single-precision when they are spilled. So, storing a 64-bit floating-point value does not "halve" the number of available registers: it uses exactly the same (double precision) registers as for single-precision math.

The situation is very similar on x86: single and double precision use exactly the same hardware registers (which are actually 80-bit extended-precision registers on 32-bit x86 machines); going from 32-bit to 64-bit fp types does not halve the number of physical registers available. (And thanks to hardware register renaming, the instruction set's nominal limitation on the number of registers is not really a practical limitation; the hardware lets you exploit the much larger set of real physical registers.)

Judging by this thread, the "64-bit CPUs can process data twice as quickly as 32-bit CPUs" hooey has been circulating for so long that people have begun to invent works of fiction to justifiy it in their minds.

Sorry, you're still wrong.

What the document you are referring to is about is the support for Intel SIMD extensions on AMD. Originally, AMD supported their own 64-bit SIMD operations called 3DNow! which could do two single-precision fp operations at once. Intel, on the other hand, had 128-bit SIMD instructions called SSE which could do four single-precision fp operations at once. Then AMD added support for SSE to their processors, but essentially emulated it with 3DNow! so that one SSE instruction would really use two 3DNow! instructions and take two cycles. Intel also had SSE2 instructions that could do 2 double-precision fp instructions in a cycle, which AMD emulated by doing it in 2 cycles with their ordinary fp unit. The document you are linking describes the fact that AMD eventually dropped 3DNow! and added true hardware support for SSE/SSE2 so that they could do all four/two fp operations in a cycle.

This happened to coincide with their switch to amd64, since they took advantage of the change in instruction set to drop their old 3DNow! instructions. But it has nothing to do with "64-bit" per se. Moreover, on Intel 32-bit CPUs, the 128-bit SSE instructions did execute in a cycle because they were supported in hardware. And even the old 32-bit AMD cpus did 64-bit floating-point and 3DNow! operations in a cycle.