To be pedantic, the transcendentals are also countably infinite. The integers, rationals, algebraic irrationals, transcendentals, and quite a few others all fall under the heading of "computable numbers", i.e. numbers whose exact solution can be arrived at by a Turing machine given infinite time and tape. Even though it sounds like a ridiculously large set, the set of computable numbers is countable: for any Universal Turing Machine you like, each computable number maps to the natural number that encodes the initial tape for the UTM such that the UTM simulates any one of the TMs that can generate the computable number in question.

For instance, even though pi is a transcendental and has no algebraic representation, there are well-known algorithms that iteratively generate as many digits of pi as you like. The infinite series of pi digits can thus be replaced with a (finite) computer program implementing one of these algorithms, and any finite series of pi digits can be replaced by the same algorithm plus the number of digits to stop at. A finite approximation of pi is merely cached output from the computer program, and therefore {program U finite approximation} adds no new information beyond {program} to help you distinguish pi from the other real numbers, meaning you can uniquely identify pi with just the computer program and no further information.

Notwithstanding your comment about how you already have a patent license through other means, "civil disobedience" isn't the same as "doing it and not getting caught". In the original sense, "civil disobedience" means breaking the law in public, daring the police to arrest you / civil lawsuits to fly, and using the obvious injustice of the response to inflame the public against the bad law. DeCSS in your .signature is civil disobedience, downloading a gray-market codec from a non-US APT repository is merely getting away with it.

FWIW, I highly recommend setting your brightness to the minimum the OS will let you. In my experience, the Nexus One screen is useless in any amount of daylight, no matter how high it cranks up the screen's light levels, so you might as well not waste that energy and find a nice shady spot instead. My "Battery use" screen consistently shows that the display sucks down the vast majority of my power usage, even if I've only had the screen on for 30 minutes throughout the day, and I still get through the day with 40-60% of my battery remaining. In a pinch, I can go 36 hours without charging, especially if I minimize screen activity.

Also, get Watts, and try to correlate the slope of the graph with what you were doing at that time. I found it quite helpful.

Beyond the other comment about 100 miles versus 100 years, I also feel compelled to point out that Switzerland is very well connected with its neighbors via a very reasonably-priced passenger rail system. (And with schedules that are extremely... Swiss... to boot.)

It still blows my puny American mind that it's possible to ride a train and arrive in another country, and moreover to do so as a day trip.

Actually, I'm fairly sure you miscounted. When I looked over that list, I only counted 8.

Star Trek: The Motion Picture (Star Trek 1)
Star Trek II: The Wrath of Khan (Star Trek 2)
Star Trek III: The Search for Spock (Star Trek 3)
Star Trek IV: The Voyage Home (Star Trek 4)
Star Trek V: The Final Frontier FNORD (Star Trek 5)
Star Trek VI: The Undiscovered Country (Star Trek 6)
Star Trek: Generations (Star Trek 7)
Star Trek: First Contact (Star Trek 8)
Star Trek: Insurrection FNORD (Star Trek 9)
Star Trek: Nemesis FNORD (Star Trek 10)
Star Trek (2009 - Star Trek 11)

See? There's a mysterious gap between 4 and 6 that I've never been able to figure out, but you can't seriously mean that the new movie gets a +2 added to its sequel number just because it's a reboot.

Now if you'll excuse me, I have a sudden urge to go shopping.

Yes, and as I said, this is exactly what I keep hearing about as the long-term plan. The problem as I understand it is that it will require significant developer time to write an implementation. The easy part is automatically generating, mounting, and unmounting the encrypted loopbacks as needed. The hard part is changing Dalvik, the GUI, etc. so that they all do something sensible when the SD card is yanked out.

(The naïve solution of "SIGSTOP the missing apps until the SD card is reinserted" could well leave the phone effectively hosed if the app was running in the foreground. There are plenty of full-screen apps that hide the notification panel, and apps can capture a surprisingly large set of keypresses — and games, the most likely candidates for installing to an SD card, are also the most likely candidates for capturing keystrokes and going full-screen. Most users won't care that adb shell still works fine.)

Disclaimer: I work at Google, but not on Android and definitely not as a spokesman for Android, and I would be quite shocked if any of this were news outside the company. I'm fairly sure the bulk of this discussion exists in the public Android bug tracking system, as I remember being pointed there when we all got our shiny ADP1s a year ago and the same question came up. At any rate, the problem space is well known since it afflicts non-Android Linux (esp. Knoppix and other removable-media distros, which solve the problem by copying the entire system image to a RAMdisk).

Why do major surgery on Linux, creating a fork that no one else would touch with a ten foot pole (open source or not), when Linux already implements everything necessary? (Namely per-process UIDs and per-file permissions.)

The SD card is FAT-formatted because the phone presents it over USB as a block device, so that PCs and Macs can pretend it's a camera or other media device. But the use of FAT means that the card lacks Unix file permissions, in particular the owner/group info that stops one app from stomping on another app's data. (The device is mounted noexec, to prevent temptation/abuse.) I've seen talk of using Linux's encrypted loopback abilities at some future point, but it's been on the wishlist since the G1 came out so I wouldn't hold my breath.

That is either physically impossible or sheer dumb luck, depending on your device.

Some explanation of GPS is in order. For a GPS receiver to work, the GPS network must send it three pieces of data: the almanac data, the ephemeris data, and the current time (to atomic accuracy). Some receivers cheat and can get by without the almanac, at the cost of slow satellite locks and inaccurate position fixes until the almanac is available.

Among other things, the almanac tells the receiver a general, fuzzy idea of where all the satellites are located, and also gives the receiver a chance to measure the amount of ionospheric distortion (the single biggest cause of GPS position errors). The fuzzy satellite positions are valid for about 6 months, but the network only transmits one full copy per 12.5 minutes. You physically can't download it faster than that via the GPS network: GPS transmits in a repeating loop at a mere 50 bits per second, slower than an ancient 300-baud modem. Worse, the ~4KB almanac is only part of the GPS data, so the download rate is even slower than that. Oh, and to add insult to injury, GPS has no error correction, so if a section is corrupted you have to wait another 12.5 minutes for a retransmit.

With the almanac in hand, the receiver next needs the ephemeris data, which provides satellite orbital parameters in detail far beyond what the almanac specifies. This is absolutely mandatory for obtaining a fix. Once downloaded, it's good for about 4 hours, but the data is specific to each individual satellite. One satellite's ephemeris takes 12 seconds to transmit from start to end, but they can be downloaded in parallel. (As with the almanac, there is no error correction. If the receiver misses part or all of an ephemeris, it has to wait 30 seconds for the next retransmission.)

The clock data is similar to the ephemeris, except that it takes only 6 seconds to transmit. It's on the same 30-second retransmit loop as the ephemeris.

With all three pieces of background information at hand, a 60-bit signal every 6 seconds keeps the clock data up-to-date. This is what the receiver is paying attention to once it has a "lock" on a satellite. 3 locked satellites gives a latitude, longitude fix by making some educated guesses. 4 locked satellites gives a far better latitude, longitude fix and adds altitude as well.

In summary, if your TomTom truly has zero almanac data and zero ephemeris data (i.e. it's a fair "first fix" fight), the time to first fix must necessarily lie in the range from 12 seconds to 30 seconds... if the TomTom can download ungarbled and pristine ephemerides from 3 or more satellites simultaneously, without a single bit error among any of them. This also assumes that the TomTom is cheating by foregoing the almanac, trying to get a fix from ephemeris only and not correcting for the ionosphere.

The only possible way you can get the claimed 2-second fix is if the TomTom (a) already has a current almanac (or is deliberately foregoing one), (b) already has current ephemerides for multiple still-visible satellites, (c) already has very fresh clock data for those same satellites, and (d) gets lucky and catches 3 or more of those still-visible satellites with known data that all just happen to be transmitting their respective 60-bit subframe headers (1.2 seconds minimum, 6 seconds maximum) within the same 2-second window. As I recall, the TomTom backs up the almanac, ephemerides, and clock data to flash RAM — you have to go out of your way to factory reset your TomTom to force a true "first fix", so (a) (b) and (c) are very likely to be known already if your TomTom has had a good fix at any time in the last 2 to 4 hours. The final step (d) is improbable but might occasionally happen.

TLDR: It's barely on the edge of what's possible, that you might have actually gotten a 2-second fix on your TomTom once. But that has more to do with luck than it has to do with the TomTom itself, and it definitely wasn't a true "first fix".

Nitpick: though this is true for the most familiar quantum algorithms, i.e. the ones in BQP (Bounded-error Quantum Polynomial-time), there are also some quantum algorithms that give exact answers with 100% certainty, such as EQP (Exact Quantum Polynomial-time).

To be pedantic, both General Relativity and Quantum Mechanics are branches of Special Relativity, not of Newtonian Relativity. Like SR, QM also assumes that Maxwell's Equations are literally true, and thus c is constant in all QM reference frames (which implies the use of the Lorentz transformation and the absence of universal clocks).

As a concrete example, muons (a heavy counterpart to the common electron) are deeply in the realm of QM, yet we observe that the half-life of a muon is affected by the muon's energy. A muon experiences a constant half-life (about 2.2 microseconds) as all particles must in QM, but the more kinetic energy it has (i.e. the faster it goes) the more intensely it sees the universe around it as "running slow" due to time dilation. Meanwhile, we see time as running normal for us, but when we look at the muon, we see the muon as "running slow", such that higher-energy muons have longer half-lives. Lest anyone think this is academic, muon decays are quite easy to create in a lab, and nature also creates them quite commonly in the particle showers that spill out when cosmic rays hit the Earth's upper atmosphere. Not only are SR's predictions of muon behavior easy to lab-confirm, but we also have the striking fact that cosmic ray muons in a Newtonian-limit QM would be limited to traveling about 0.7km/0.4mi, never reaching our detectors on the Earth's surface, yet real-world muons routinely hit our detectors by traveling much deeper into the atmosphere than that.

That said, QM doesn't include GR's deformable spacetime fabric, and thus QM uses a Newtonian approximation for acceleration. Due to SR, this means that both ourselves and the muon are "right": according to SR/QM, both our clocks are running slow, and we have no GR to properly resolve the paradox and decide what happens if the muon decelerates to match our speed. As soon as you add a relativistic treatment of acceleration and deceleration to QM, you start getting the infinities spoken of in the article, and at a fundamental level those infinities mean that QM doesn't know what happens when a particle gains or loses energy. Instead, QM says that particles gain or lose energy "instantaneously", or rather "so fast that you can't tell what happened" as per the Heisenberg uncertainty of dE*dt. This means GR is, in some sense, more complete as a mathematical theory than QM is, since we can't look GR square in the eye and watch it squirm like QM does.

Sidebar: this is also why String Theory is still considered quite promising by many, despite looking like a quagmire to an outsider: all physical theories generated by mathematical String Theory automatically include GR and generalized QM as basic assumptions, with no problematic infinities. The sole difficulty in String Theory is "merely" finding an instance of that Theory that looks like our universe.

You clearly don't know your 18th century American or European history.

America built its textile industry, and indeed its prominence in the Industrial Revolution, only by flagrantly violating the patents of established European countries, especially those of Britain (and Scotland, the Silicon Valley of the day). In fact, the blatant colonial-day flouting of patent law and the use of "industrial espionage" (i.e. brain drain) against Britain was actually a significant pain point in the years leading into America's Revolutionary War, and tangentially figured into Britain's enthusiasm for the War of 1812.

(Copyrights were violated as well, but weren't considered as important at the time. Copyright itself was still crawling out of the cradle and unfamiliar to many — the first modern copyright law, the Statute of Anne, was passed only at the start of that century in 1709. At that point in time, copyright wasn't considered an economic engine, the way that patents were.)

This is actually quite easy to answer, because momentum is conserved (in both Newtonian physics and General Relativity). In the Newtonian model, which is accurate for the masses and velocities we're dealing with, momentum equals mass times velocity. A stationary black hole has mass m_0 > 0 and velocity v_0 = 0, for a momentum of m_0*v_0 = 0. An incoming object with mass equal to the black hole has mass m_1 = m_0 and velocity v_1 > 0, for a momentum of m_1*v_1 > 0. The joint system, after the black hole has completely absorbed the incoming object, has momentum m_joint*v_joint = (m_0*v_0 + m_1*v_1) = (0 + m_1*v_1) = m_1*v_1 and mass m_joint = (m_0 + m_1) = 2*m_1. Therefore, its velocity is v_joint = (m_joint*v_joint / m_joint) = (m_1*v_1 / 2*m_1) = (v_1 / 2), or exactly half the velocity of the original incoming object, traveling in the same direction that the original incoming object was traveling. This is simply a fully inelastic collision — that is, a collision where the two colliding objects stick together instead of bouncing off each other. The fact that one object is a black hole is immaterial.

This "latest batch" has been almost six months in the making, which is roughly the same length of time it takes to develop the seasonal flu vaccine each year. Flu already requires a new vaccine every year: different strains require different vaccines, and every new year brings one or more new strains of flu, and this year's swine flu vaccine is no different from the vaccine for any other strain of flu in that respect. When a new strain arises, scientists don't have to throw away all their knowledge about making flu vaccines or treat it as a from-scratch research project. The biggest difference this year is that scientists found out about the novel H1N1 after they'd already started work on this year's seasonal flu vaccine, so it was too late to include it. This is why they're running behind on vaccine production.

Some background is required to appreciate this. Flu mutates fairly rapidly, since it's a single-stranded RNA virus. A "strain" is actually hundreds of individual mutant lines inheriting from a common ancestor but with significant differences between them. From the perspective of creating a flu vaccine, two proteins are critically important: hemagglutinin and neuraminidase, "H" and "N" respectively in "H1N1". Both of these proteins are directly involved in the cell-to-cell spreading of the virus — and thus highly conserved across mutant lines, and even across strains — and both of these proteins can be recognized by the immune system on the exterior of the virus. If you create a vaccine for one mutant line, then that single vaccine will be effective against most of the other mutants lines within the same strain. That said, there are other important proteins besides "H" and "N", and these differences mean that a vaccine for one H1N1 strain (e.g. A/Brisbane/59/2007, a target of this year's seasonal flu vaccine) will offer only a tiny amount of protection against any other H1N1 strain (e.g. the new swine flu strain).

Immunity to this year's strain will be widespread by next year, either by vaccination or by infection. This is unfortunate because some other strain (often one that already exists today) will fill the empty niche and become the "new" strain next year, and a new vaccine will be needed to protect against the "new" strain. Happily, scientists can look at this year's epidemiological data and make some pretty good guesses about which strains are likely to infect lots of people. They pick the three to five strains that look positioned to cause the most harm, and they start work on a combined vaccine against all of them for next year's flu season. This happens as the current flu season winds down in late Winter/early Spring, about six to nine months before the vaccine will be needed for the next flu season, because it will take that long to grow the flu viruses in chicken eggs, to kill the viruses, and to make doses of vaccine out of the viral remains.

Once next year's strains have been identified, all the hard research work has already been accomplished: growing the virus in chicken eggs rarely changes from year to year, killing the virus is easy and repeatable (and easy to verify before making a vaccine out of it), and making doses from the dead virus is usually trivial. When complications arise, it's almost always in the viral growth stage. If the strain is strongly bird-associated (e.g. the H5N1 "bird flu" strain from a few years back), the flu strain might kill chicken eggs too quickly. (Thankfully, viruses with this problem rarely spread well from human to human, since the virus must make a trade-off between infecting birds well or infecting humans well.) Alternately, the virus might not grow very well at all in chicken eggs, which is a pretty rare event since chicken eggs have very few defenses and even human-adapted strains usually retain the ability to infect chicken cells under such ideal conditions.

So long as the strain used in the vaccine is a good match for the strain actually infecting people in the real world, the vaccine's effectiveness doesn't vary by much. And the potential for unexpected side-effects or other safety concerns is practically zero, since the process used to make the vaccine is identical from year to year and the only difference is the virus itself. From a safety and effectiveness perspective, there's nothing at all to distinguish the swine flu vaccine from any other flu vaccine: if anything, the swine flu vaccine is slightly better, since there was no guesswork on which strain to use.

That's a very middle-school way of putting it, but basically accurate. You leave out the fact that the immune system regularly intrudes into the gut, and in fact communicates chemically with the commensal bacteria that live in your gut (because they share a joint interest in protecting the gut from hostile bacteria). From the immune system's perspective, the gut is a front line of defense, moreso even than the tonsils and adenoids, and it's critical to pay attention to what's happening inside it.

That's because your digestive system has sorted the peanut butter into separate sugars, lipids, and proteins, not to mention broken them up into tiny globules to maximize surface area and thus permit absorption within a reasonable timeframe.

But the proteins, while not fully intact thanks to the action of pepsin in the stomach, are still in very large polypeptide pieces since pepsin can only slice at predetermined weak points in the peptide chain. The remaining polypeptides are still large enough to behave as antigens and provoke an immune system response.

(This is, in fact, a piece of the immune system in action. The stomach successfully digests most bacteria hapless enough to fall into it. The digestion renders the bacterium harmless but the antigens from the bacterium's surface reach the intestine intact. Once in the gut, the antigens are absorbed by the intestine and presented to the immune system, allowing the adaptive immune system to start planning an antibody-and-T-cell directed attack at the invading bacteria in the nose/sinus/throat, before they can even successfully breach the epithelium.)

(There's an even better piece of evidence: mad cow / Creutzfeldt-Jakob disease. The disease is caused by a prion, a misfolded protein that catalyzes its own misfolding from healthy protein. If proteins were obliterated by the digestive system, it would be impossible for mad cow / CJD to spread: the fact that the protein can spread from brain to food to intestine to brain and continue the infection in another individual means that at least some proteins can be absorbed whole by the intestines, even without being digested.)