There is also the occasional need for something like VNC when you absolutely, positivily have to have that remote desktop look for your visualization software.

A lot of the Russian experience, at least when I was active in Space Station stuff and the Russians were still flying Mir, had small populations, n=1-5. You cannot draw significant conclusions very easily from samples that small.

Electrophoresis is a reasonable drug delivery system for SOME agents, but not all.

While I can't speak to Kirk's problems, the Shuttle isn't a sterile environment. It is kept as clean as possible, mainly because they don't want any more particulate contamination to fly, and get circulated in microgravity than necessary, but you can't get rid of all of it, Historically, on Shuttle, they set up a fan between Middeck and Flight Deck, in the starboard access area, and used a filter on the inlet side. It captured fine particulate matter... and pens, etc., that were dropped or otherwise lost by the crew on-orbit. It all ended up, eventually, in the filter.

Also, while there's a 2-week quarantine period preflight, there are SOME diseases where the incubation period is longer than that. In those cases, isolating the crew for 2 weeks wouldn't catch the problem.

Yes. Some bacteria become mor virulent when incubated in a microgravity environment.

Um... but such changes CAN occur. One of the developments for the Crew Healthcare System included the ability to use available water supplies from stored, or recycled water, to make intravenous solutions, using fluid concentrates (we tried, but the powdered chemicals just don't disolve well and have to be manipulated). The system used a multiple-component water pass-through purification system to prodce at least 50 Mohm water that had also been subjected to ultrafiltration, to assure cellular contaminents such as endotoxins were removed. The system did not use high pressure or heat sterilization, and was demonstrated to meet US FDA and USP standards for ultrapure water for injection, and intravenous fluids.

Water reuse for long-duration spaceflight missions is already achievable, with only the stigma of using recycled water for drinking and medical uses remaining as a potential problem. The processed water is considerably cleaner than anything you'll drink in a conventional water supply, and certainly better than the tap water at Cape Kennedy.

The ability to white-noise (or pink-noise) jam GPS has been around and employed for, literally, years. And, most of the first of these I saw came from China, too. GPS is a relatively fragile system, at least n the L1-C/A world: GPS satellites have limited power budgets so signal levels are low on the ground. Receivers have high gain. Multipath in urban environments can confuse receivers. Emitting a random noise signal over the range of L1 frequencies isn't that hard, and doesn't take much power... or antenna height... to cause problems.

The article makes all of these points. Read it and take note of the fragility of the system. That's its downfall, not a $30 device.

Slack has some benefits if only because you end up having to compile from scratch in most cases, which can be instructional. However, Hook 'em and reel 'em in, then teach 'em what the tricks are for deciding on a distro, and help them do more complex things.

Not necessarily. I've been trying to find a couple of good, linux-savvy student workers, and they're rare. By the time I hear about them, someone else has generally snagged 'em. I'd have to say maybe 10% of our CS freshmen know enough about Linux to have installed it themselves on a home machine.

I'd start with a two-pronged approach.
1. GUI. Using something like Ubuntu, although I'm generally a CentOS bigot, teach them how to do all the things they know how to do in Windows: download and install software (using apt, for instance) and how to add an icon to the desktop. Teach 'em where to find applications of interest.
2. Start teaching the command line. There are times when a GUI... anyone's GUI... is too cumbersome/restrictive to do things quick and dirty.
2a. introduce them to 'script' and the concept of shell (batch) scripting.
2b. as an addendum to 2a, above, give 'em an overview of the major shells and explain why Tom Christiansen thinks csh is totally unsuited for scripting.

Don't preach about how much better Linux is than Windows... If they continue, they'll understand themselves. If they fall by the wayside, they never would have understood, anyway.

You make some good points, but also miss a couple of key elements.
1. Rather than once/day, a once per minute weather update with geopositioning data would, in fact, be useful, especially if it incorporated the standard info but simply substituted precipitation detection and identification for measurement. Otherwise, T, Td, Pbaro,wind, and solar data could readily be obtained.
2. Rather than requiring a fixed location for each measurement, consider relating geolocation to a fixed grid square. This could be very useful for verification
3. There are thousands of volunteer observers in the US, and a lot are giving their data to NWS. It's valuable, but this would be too.
4. Some work is already going on with this at NCAR. Was in a seminar recently where they talked about mobile mesonets. In fact, a major bus line has agreed to have their bus flet instrumented and the data sent to NWS.
4. Consider Homeland security...Yes, a CBRNEevent would benefit from early detection and ongoing modeling of plume release

I've been looking at mobile weather data systems for almost a decade. Getting USPS to do this would be a good thing.

The illustration behind the surgeon in the article looks a lot like an impeller-driven left ventricular assist device. It's not an artificial heart, but could, conceivably, be half of one. In the old days, when most VADs were pulsatile, they could effectively replace a non-functioning ventricle and produce pulsatile flow, very much as the heart does. However, they were bulky and had their own problems. Pulseless, continuous flow, impeller-driven pumps are less likely to develop clots on surfaces, which will help the patient in the long term.

Neither the posting nor the article were long on real facts, though. I don't recall Duschenne's dystrophy having a direct effect on cardiac muscle (but it's been a long time). Striated muscle (and some smooth muscle) degeneration, especially of the respiratory and accessory muscles tends to cause demise. If the heart was also affected by myopathy, then use of a VAD could be either a transient, or "permanent" solution. A surprising number of patients who received VADs as a bridge to allow them to live until a satisfactory donor was found, have been suficiently recovered to no longer require transplantation after weeks or months of service with a left ventricular assist device.

Although this isn't the exact device shown in the Register article, here's a similar "permanent" citation: http://www.texasheart.org/AboutUs/News/2010-01-21news_FDAapprove.cfm

One of the, if not THE, most common causes of aircraft crashes issued by the National Transportation Safety Board is "pilot error". But, there's a reason for that. There's a lot that can go wrong in an airplane, and we're trained to do things about almost all of them (having a piece of FOD penetrate your delta-wing fuel tank on takeoff and essentially render your plane a molotov cocktail looking for a place to die excluded). When a private pilot ignores worsening weather and meets cumulo-granite, that's pilot error. Continued flight into known icing conditions, ditto. Running out of fuel, yep, same thing. Now, two out out of three of those are little-airplane-related, and the third often is, but running out ouf fuel has happened to the big-iron drivers, too, and they didn't admit it to get priority or emergency handling from air traffic control. By the same token, sometimes, pilots are required by COMPANY regulations to do things a particular way, and that comes out as "pilot error" too. And that is something that should be exposed to scrutiny. But, by the letter of the law, anything that happens on a flight is the responsibility of the senior pilot on the aircraft. There's a lot more that goes into Pilot In Command structure, too, but that's for another post.

In the end, it really is all about organization, and a few basic rules.
1. Store your data first. Before you do anything to modify it, transmogrify it, or distort it.
2. Assimilate like datasets. This obviously doesn't apply to the parent's datasets, but it does to mine.
3. Normalize for rapid retrieval (CSV, ISAM, flat file, or RDMBS as appropriate; flash cards are fine with me, if that's what you like). Note that you've not done anything to the original data.
4. Process/analyze. SQL queries, process chains, whatever it takes. That's what the normalization stage allows you to do readily.

What you've described is an inredibly straightforward approach to scientific data management, and worth wading through the other comments to find.

Mod up +3. You're right on-target.