I'd expected something funny or at least insightful.

Sadly it seems neither.

But then neither is the actual situation. It is sad to see Nokia essentially go (yes, the corporation lives on, but without what had become the heart). And it is hard to see how there is an upside for Microsoft in this. A lose-lose, with bad actors taking home lots of cash.

Oh well, perhaps someday someone will turn it into a great play. It has all the seeds of a classic Greek tragedy (Hubris, fate, etc.)

A wide variety of medical devices currently use Windows (often XP) to provide the client interface. Most Doctors have smart phones, so getting the buggy, unreliable, insecure Windows box out of the picture may appeal to some ... and leveraging the technology that the staff already have is not unreasonable (yes, there's some OTHER computer actually monitoring the flow. But setting the rates? Receiving alerts? ... why not use the smartphone?).

As to whether the FDA does a good or bad job (or a bit of both), it neither seems odd that some people would want to leverage the control (think Cochlear implant devices and programming adjustments) that folks already have, to manage their devices (durable, not just hospital based). Nor, if one accepts that the FDA has a role of any sort, why they should not be involved JUST because something is a software app as opposed to the software running in the otherwise regulated device.

Folks who fly ICBM's need very accurate masscon (mass concentration) maps for guidance. So I'll bet that various governments militaries have more accurate maps. They do, after all, have a bevy of satellites whose orbit perturbations allow the computation of such things to any degree of accuracy desired ;>

Whether they make displays as nice, I don't know.

While such plans do have potential practical value, isn't the usual thrust "what new pet program do our sponsors want funded?"

The way we create vaccines is overly calendar time long (but sidesteps questions about safety of new techniques).Also our general anti-viral stocks are low.

Sponsors from either (or both) camps may be influencing both the generation and now the distribution of the report.

If memory serves, at that point we had a semi-custom Z80 (actually it was a three processor system) S-100 bus based system running TurboDOS (at a blazing 8MHz per processor), an 8086+8087 off on daughter box connected to the main Z80 processor (running MS-DOS 1.x, for some value of x that I forget) fronted by a televido terminal with a switch (so I could speak to any of the Z80's directly, the 8086/7 was only available via software from the lead Z80) with a pair of Epson MX-80s being tortured into destruction (typesetting math documents using "Fancy Font" which was essentially a troff style derivative) and a MacPlus with a LaswerWriter.

I'm not sure how using those things would be better than an iPad for a child. Just the raw metal bits on the S-100 system (not inherent, just my suboptimal metalworking skills) makes me cringe to think of it as a child's toy. Oh, and the DecWriterII that we used for printing labels. Heavy enough to cause serious damage if toppled...

We did have a variety of language processors (but who really wants to teach a 2 year old how to program in Pascal, Fortran (any dialect, but especially the mutant that was Microsoft's ... until we got Lahey's much better product). Indeed, JRT systems Pascal (the first $29.95 compiler I found) computed x*0.0 !=0.0*x (one returned 0, one x). So it wouldn't even be a good tool for teaching math (however, a great tool for teaching the proper distrust of blindly assuming computers are correct).

OK, not everyone programmed up Kalman filtering software at home and wrote memos and reports. But the technology was there, and affordable if you compared it with, say, renting all the time on a Univac (or CDC, no one who had a choice picked an IBM 360 family for its numerics, but we did have clients who had them, so the code had to be portable to those platforms as well ...UTS on an Amdahl anyone?).

Personally, I prefer to have my kids playing with the iPad than, say, power tools.

I suppose the other clever (but non-electrical) approach would be to use a turbo charger. Pumping some of the exhaust gas back in and using it's thermal and kinetic energy to power the blower would do away with the need for a battery or external fan.

But when the basis against which solutions are compared against is three rocks under the cookpot it is hard to compete on the basis of simplicity.

Reading some of the other citations (cooking stove treatise, etc.) it seems that lessons from the 5th century haven't propagated yet.

http://heritageofjapan.wordpress.com/following-the-trail-of-tumuli/rebellion-in-kyushu-and-the-rise-of-royal-estates/village-settlement-patterns-the-homestead-emerges/the-kamado-stove-innovation-improves-home-life/

The key benefits of using "high" technology are cleaner burning and electricity generation for upfront investment (which presumably is being donated).

The southern japanese solution does deal with a lot of the household air pollution but doesn't address the global impact.

But it does beg the question about why traditional ceramic solutions aren't the basis for sustainable solutions. Even with an additional blower (which could be pedal powered) it does seem a lot more deployable (but not nearly as much engineering fun)

http://www.biolitestove.com/homestove/overview/ for the "homestove" which is intended for folks who need it "full time". Yes, it is more expensive, but they are working on funding sources.

One of the funding sources is us outdoor geeks, on their website you can find the campstove, the campgrill and the upcoming pot. Some of their profits go towards their homestove work.

I've got the campstove, it does a very nice job. Perhaps by next summer I'll invest in the grill.

Surely someone at the NSA knows about multi-level security, SELinux, and the like. No one should have had root access. Having architected the system so poorly, it hardly took a genius to walk off with their secrets.

http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html "What Every Computer Scientist Should Know About Floating-Point Arithmetic", by David Goldberg, published in the March, 1991 issue of Computing Surveys

I don't know why anyone thought this was surprising (it would have been surprising if they didn't get different results, given that some use GPUs, some don't, etc.). What does tend to get "amusing" is that even with the same processor folks get different results (sometimes due to software issues, chip rev issues, or actual hardware bugs that go undetected ... but are minor enough to remain so unless someone gets really careful and whips out the old logic analyzer).

To get a ruling on whether you may do what you want. Otherwise, as others have noted, you may be very deep waters (not only will you be in violation, but anyone in the organization using the service will be, and you will have induced them to do it. Think serious civil as well as criminal consequences).

From a technology angle, it may be "possible" if the folks in charge sign off.

"All" you need to do is encrypt the data before it goes offsite, encrypt it well enough that the data is protected commensurate with its value, etc.

For commercial users, https://jungledisk.com/ provides a very usable interface and GUI. Of course, if the client isn't trustworthy (and you have to take their word for it ;>) that goes out the window even if the algorithms are secure themselves ;>

I use it for some SOHO confidential data; it wouldn't be the end of the world if the data were disclosed, but we have committed to make good faith effort(s) to keep it secure, so we do (rather than moving files to subs via email, etc.). Not all subcontractors could handle sftp and friends.

Yes, as many have noted.... client organization unhappiness and excess spend are objective metrics which call into question what's going on.

But ... dig deeper.... are the client organizations behaving rationally or are they constantly asking for change after change? Obviously the organization is dysfunctional ... but is it the IT director, the entire IT department or the organization as a whole?

If it IS the IT director... I imagine the issue he's(or she) has been there for a long time; HR will want "proof" that replacing them isn't age discrimination or any such thing. If the client organizations are healthy and have reasonable expectations and your impression of the "line worker" IT folks is good, perhaps you need to have a heart to heart with the IT director. If he is "parroting" what his staff tell him, he's made some poor hires. He may even understand that, but lack clues as to how to hire better. See if they are rational, and self-aware enough to recognize their limitations and work with he/she/it to hire someone to be the "technical honcho" ... chances are the IT director wouldn't have gotten the job and kept it so long if they didn't have good relationships with the executive staff. That DOES have value. Leverage it, and help them improve ... if they are capable of it.

Just sacking someone is seldom enough; they will have built up an empire of mixed wood (some dead, some living, some actually thriving) and you need to help them prune and fertilize ... not just toss the whole tree away (unless, of course, their entire IT department really could be replaced with SaaS and IaaS and have done with it).

The details of the organization and people matter.

As earlier posters noted, if this is all news to you, you might not be the right consultant.

By not getting through to you ;>

As Blackstone put it, and our Founding "Fathers" enshrined into actionable text, "It is better that ten guilty persons escape than that one innocent suffer". The entire US legal system is based on this notion. It is hard for the State to prove Guilt (beyond a reasonable doubt, hands tied in various ways, etc.). Yes, you could have probably developed a vast complex of rules that could exist without the 5th amendment and still accomplish its ends, but unlike the legislature of today, back then they sought brevity and relative simplicity of rules.

Even with all the rules stacked in favor of the defendant, innocents get convicted.

Imagine that there was not 5th amendment, then the likelihood of government focus on getting "lie detectors" ruled legitimate in court. Since all they actually measure is stress, they'd pepper the suspect with questions and convict of things they were nervous about (objective evidence no longer required). Just one of many probable outcomes of removing this protection.

That your gripe is with differential equations suggests that your department is just using the Math courses as a screening process (eliminate the chaff). Statistics (parametric and non-parametric), linear algebra, number theory, numerical methods ... these all have direct application to real world problems folks face in applying computers to business or engineering problems.

Number theory is the basis for cryptosystems. You probably won't be developing your own, but understanding a bit of why they work (or don't) is an example of how advanced mathematics impacts our day to day life in CS applications.

Even if you don't become a "data scientist" understanding statistics (correct and incorrect usage) are key to performance analysis, system tuning, etc.

Numerical methods help one appreciate entire classes of errors which computers make by design; not critical for an OS developer (no fp in kernels) but someday, somehow you may find yourself dealing with floating point computations ... learning about the fine points (see, for example, the Goldberg paper "What Every Computer Scientist Should Know about Floating Point Arithmetic" http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html).

The list goes on. But differential equations really shouldn't be part of it. Pity that few CS departments work closely with Math departments to craft courses where the subject matter not only matters, but the linkage is made explicit.