Is there some technical reason why they stop at 3 strains, or is it purely a matter of cost? If it's just cost, why can't they offer more expensive flu shots that include more strains, to get the efficacy closer to 80%?

Or, for that matter, if vaccination for a particular strain conveys multi-year immunity, why can't they at least make two variants of influenza vaccine... one with the 3 strains they believe are likely to be the most *dangerous*, and another with the 3 worst strains that haven't been part of the cocktail for the past N years (so that if you got a flu shot every year, and it had N-year efficacy for those strains, after N-1 years you'd have some meaningful degree of immunity to at least 3n-3 different strains instead of just 3?

For what it's worth, "anchor babies" is another misleading term.

A baby born on US soil to a Mexican citizen in the US illegally enjoys automatic US citizenship, but it was established by the Supreme Court a few decades ago that being a child with US citizenship does NOT automatically convey a right to GROW UP on US soil unless at least one parent or legal guardian has US citizenship or residency. (I believe the Supreme Court's rationale was that a child needs a legal guardian, and since the constitution doesn't grant automatic citizenship to the PARENTS of US citizens, the child can't independently exercise his rights as a US citizen until he or she is legally an adult).

Under the best circumstances for the mother, her baby will be born in the US, get an official US birth certificate, then both will be deported to Mexico. 18 years later, the child can move to the US at will, but bringing his mother (or any other extended family member) will require demonstration of financial ability to support and sponsor the immigrant parent. In the end, all having an "anchor baby" really gives the mother is the ability to cut in front of other Mexican citizens and move to the front of the immigration line ahead of them.
immigration status.

[quote]But what are you going to do?[/quote]

Civil disobedience. Root your phone, reflash it to an AOSP- or AOKP-derived ROM, and configure it with an app that feeds invasive apps spoofed or sanitized data.

Quantum data transfer will probably end up succumbing to the same kind of catch-22/gotcha that plagues realtime digital filtering of analog waveforms...

a) Analog filtering introduces phase changes due to delays. When digitally-filtering a waveform, the length of time you have to sample it to get enough to analyze and transform ends up introducing basically the same phase shift an analog filter would have caused.

b) Quantum data transfer has "1 in 100 million" odds of actually working for any particular attempt. Obviously , lots of forward error correction will be needed to both detect and fix errors. My prediction is that the time the required error-correction overhead adds to the transmission time will end up being basically equal to the time it would have taken to transmit the data at the speed of light.

c) In both cases, the limit will apply primarily to realtime uses. Using the audio example, if you try to apply a digital high-pass/low-pass filter to audio for something like a subwoofer, you'll basically create the same phase shift you would have had anyway... but if you have the luxury of buffering playback so that you have time to completely analyze the signal & can delay the OTHER signals to bring them back into temporal alignment with the filtered signal, you can enjoy the best of both worlds... infinite-slope filtering with zero induced phase shift. In the context of quantum data transfer, it will fail at the goal of "faster than light" throughput, but might nevertheless find utility as a way to transport data in non-realtime under circumstances that would render "normal" electromagnetic radio modulation schemes unusable.

At some point, if there are enough consumers living beyond Earth orbit to commercially matter to normal web sites (or their future equivalent), the most logical step would be to allow web applications to bundle themselves and their data in a way that allows the web app ITSELF to be automatically deployed to a remote virtual server closer to the end user & sync its mirror of the database with the authoritative one back on earth (multicasting most of the replicated data from earth to elsewhere & caching it blindly at the local end to the greatest extent possible).

The basic technology already exists today (think: .war files and databases with replication, load-balancing, and hot failover), but the number of users (say, passengers on a cruise ship) is too small relative to the expense & currently-insurmountable licensing barriers (Oracle isn't going to start making "replicant" licenses for Oracle and MySQL available that would be remotely cost-effective anytime soon).

A lot of people forget that the annoying habit some websites have of using AJAX to send data nonstop keystroke-by-keystroke is a plague of fairly recent origin. There's no reason why web applications HAVE to be written that way. If latency is high, but bandwidth is abundant, it makes more sense to satisfy the request by bulk-sending everything the requestor is likely to want anytime soon, and do it in a way that allows it to be cached locally for the benefit of others who might make the same request later.

The thing is, if cable/satellite went to true a-la-carte, any short-term savings would be rapidly neutralized by skyrocketing per-channel costs. Instead of paying $89.95/month for 200-300 channels, you'd be paying $84.99/month for 17 specific channels. Someone who literally watched only one or two channels might come out ahead, but the cable industry would make sure that most of us were at least as fucked as we are now, and would use it as an opportunity to fuck other customers just a little bit harder. It's depressing, but deep down inside, we all *know* it's true.

There's another category nobody in the industry even wants to TALK about (besides complaining about the costs, then passing them straight along to customers) -- the fees paid to local channels that insist on payment in lieu of "must-carry". IMHO, the FCC should amend the "must-carry" rule to REQUIRE cable/satellite providers to break out the total amount they'd otherwise have to collectively pay the local channels, and allow customers to opt out of paying that fee in return for having to use an antenna to watch local channels. The probably couldn't get away with demanding a breakdown of channel-by-channel fees due to nondisclosure rules, but if they disclosed their aggregate cost, it wouldn't really reveal much. I can almost *guarantee* that cable/satellite customers who don't live in New York City would begin opting out EN MASSE if they started seeing line items on their bills like "Local Affiliate Rebroadcast Fees - $17.47 (optional)". In the short terms, the local affiliates would probably raise prices for the remaining customers who don't want to bother with an antenna... but the higher they raised them, the more cable/satellite customers would be motivated to opt out of the fees and switch to OTA reception for them.

> And why shouldn't we count satellite and wireless?

Satellite is broadband for the damned & desperate.

I really wish cable/satellite would adopt "Chinese Menu" pricing for their mid-tier, and allow people who don't care about Disney*.* or ESPN*.* to pay the same price, but substitute HBO and/or Showtime instead (ie, pick two out of four... Disney, ESPN, HBO, Showtime... 3 for $10 more, all 4 for $18 more). I believe it would mostly be revenue-neutral for the cable/satellite companies, and would go a long way towards softening the sting of my monthly cable bill by letting me substitute two channels I don't currently pay for, but would LOVE to get instead of two expensive blocks of channels I never watch.

The problem with many of OCZ's drives (like the Vertex2 and Agility2) was that traditional RAID wouldn't save you because whatever killed drive #1 could (and often did) kill one or more of your OTHER drives, too.

The fault lies 100% with OCZ. They omitted the supercapacitor that Sandforce's engineers intended to keep it powered up if it unexpectedly lost power during a write, and they compiled their drivers to NOT use the multi-step write strategy that a drive without backup power needed in order to write safely and recover gracefully from power loss (because multi-step writes killed performance).

I don't know about him, but in my case, I happen to like having 5GHz 802.11ac with beamforming. The last time I checked, every open firmware in existence for the AC68U has broken support for 5GHz 802.11ac and its advanced radio features.

It's not so much "tough" as "the goddamn solder paste has to be kept refrigerated until you're ready to use it, then goes bad within a few days of warming it up to room temperature". Throwing away mostly-full syringe after syringe of solder paste after you used maybe 0.5mL of it to solder one chip gets expensive after a while.

LOL, if you think Digikey and Mouser are expensive, check the prices (including shipping) from Newark or Farnell. Jesus God naked on a Harley, Newark absolutely *rapes* you on the shipping charges. I can't even count the number of times I *almost* bought something from Newark, then called it off once they revealed their criminally-expensive shipping charges at checkout time.

DigiKey's shipping is expensive, but they have a huge advantage -- if you absolutely MUST have something tomorrow, their cutoff time for next-day delivery is something like 10pm most nights, and they'll happily ship via USPS Overnight so you can order on Friday night or Saturday and get your part by Saturday or Sunday.

Mouser's shipping isn't *cheap*, but their rates for Priority Mail are relatively reasonable & they don't have a minimum order amount like DigiKey does.

I still have occasional fantasies about Radio Shack closing MOST of their retail stores, but keeping at least one store per metro area open that's well-stocked with just about any component hobbyists might want to buy (say, everything that SparkFun and AdaFruit sells). Back in the 80s (when Radio Shack's parts department occupied the rear third of the store), people paid INSANE prices for components because you could walk in, grab what you needed, and go home with it in hand.

Ah... but were they able to do it with a chip that was available in DIP form, with useful amounts of flash & ram, and relatively relaxed power & I/O design on a breadboard?

We've gotten spoiled by $7 Arduino knock-off boards from China, and a lot of us have forgotten that just 5 years ago, Atmel literally couldn't make the ATmega644p fast enough for stores like DigiKey and Mouser to reliably keep it in stock. For those who weren't into AVR microcontrollers a few years ago, the 644p was Atmel's beefiest AVR that you could buy in DIP form. The next step up from a 644p was a 1280 or 2560 (the 2560 is used in the reference design for Android ADK), and they easily cost $30-50 (~$30 for a board that was literally just a bare chip soldered to a breakout board, $50 for one that had most of the same hardware that's the norm for an Arduino board). The 1280 and 2560 themselves were fairly cheap... I think the 1280 was around $10-12, and the 2560 was around $15. But the act of having someone solder it to a board to make it something YOU could deal with (unless you had a hot air rework station & didn't object to buying solder paste that had to be kept refrigerated, warmed to room temperature over the span of a day, and went bad a few days later when the flux separated out) basically doubled or trebled the purchase price.

Back in the same era, it was almost UNHEARD of for people to buy breakout boards for Atmel's smaller chips, like the Mega168 (unless they were rank n00bs buying their first one), because a DIP Mega168 cost around $4, but a Mega168 soldered to a dev board with Arduino-like hardware ran about $25.Back then, the hardest problem every N00b had to solve was "how the fuck do I connect the 3x2 or 5x2 header from the AVRISP to MISO/MOSI/SCK/~RST/Vcc/Gnd on the breadboard (I used to endlessly wish somebody would make a breadboard whose pins from one side were extended by one into the middle , so you could stick a 2xN header straight into the breadboard and wire away (for some inane reason, breakout boards to convert 3x2 and 5x2 headers to breadboard-spacing were always outrageously expensive, and stayed that way until about the eBay floodgates from China opened about 2 years ago).

As a thought experiment, how much linear resolution/sample bandwidth would you need to capture a VHS videotape "straight through" in a way that allowed you to digitally-reconstruct the path of virtual rotating heads AFTER the raw linear capture was completed? Say, if you had the means to somehow fabricate a custom high-density matrix of read heads that massively oversampled the tape as it followed a linear path... assuming such a beast doesn't already exist for something like DLT?

Why? Because all present restoration technologies that involve rotating heads produce results that are very much dependent upon the player's ability to iaccurately track the helical paths at capture time. What I'm proposing is capturing a linear 2-D signal map of the tape that's so precise, you could analyze it & synthesize an optimal virtual path & instantaneous velocity to extract higher-order data in non-realtime that's not even visible when played back via normal means.