I know, on /. we don't need to. But it seems to me that the point that the Fuller appears to be making is that the current environment (presumably in the UK where he practices) is that a very large number of people are diagnosed with "mental illness" which is fine if they are continuing to be largely functional, seeing a therapist of their choosing, etc. The problem is that when someone is arrested the question of "mental illness" has two different dimensions ... is the person legally responsible for their actions (the legal dimension) vs. is the person undergoing treatment (or has ever undergone treatment).

People who are not responsible for their actions are a tiny minority. But IF someone has been identified as not responsible for their actions, why are they left roaming the streets? That isn't fair to them or to society.

Admittedly, there is always the question of "who is to say" and that begs the question to appropriate due process (clearly, it shouldn't just be some random doctor or family member has nominated them for commitment). And clearly there were abuses in the past. I don't think Fuller is the first to notice that the current situation is arguably worse (fraction of homeless people who are seriously ill ... of course, that begs the question of whether their mental condition caused the homelessness or the other way around :).

I'm far from sure that I agree with Fuller, but the vast majority of the comments seem to be missing his core argument.

The short answer is no. The long answer is no ... and a very long list of reasons why.

Start with reading Goldbergs classic paper "What Every Computer Scientist Should Know About Computer Arithmetic" Sun's floating point group made some improvements to the paper and paid for rights to redistribute. Oracle continues to do so. http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html

If that isn't depressing enough, and you use trig functions, read http://www.scribd.com/doc/64949170/Ng-Argument-Reduction-for-Huge-Arguments-Good-to-the-Last-Bit you can get the source from netlib for "fdlibm" which is under a BSD flavor license.

If the purely software issues haven't made you realize that you haven't got much of a prayer, please note that different revs of the same intel chips sometimes provide slightly different results (sometimes intentionally, sometimes as a result of tweaking the order of execution in the out of order execution engine). Older x87 arithmetic was 80-bit, newer x64 arithmetic is pure 64-bit, providing no end of fun. Using the SSE instructions provides more variation.

If the pretty much (in principle) "simple" and potentially deterministic software issues aren't enough consider the reality of hw. Chessin has a very good, yet amusing, explanation of the key problems http://queue.acm.org/detail.cfm?id=1839574

Lest you think they only apply to a particular generation of boutique processor, most HPC ensembles are now built out of standard server motherboards and chips.

http://www.csm.ornl.gov/srt/conferences/ResilienceSummit/2010/pdf/michalak.pdf The issue of undetected soft errors is big and growing, as can be seen from the activity in the literature. SC13 "ACR: Automatic Checkpoint/Restart for Soft and Hard Error Protection" (which has lots of good citations of earlier work, including field data such as 27 soft errors per week leading to fatal node failures (that is, wrong enough results that while the hw didn't detect any problem, the issue caused the node to crash) on just one ensemble (ASC Q). its going mainstream in that HPCwire caught wind and in 31 Oct 2013 had a nice tabloidesqe writeup entitled "Addressing the Threat of Silent Data Corruption"

Neutron's don't only disrupt memory elements, but can hit logic as well. See the upcoming issue (already available via IEEE xplorer for member/subscribers) JOURNAL OF SOLID-STATE CIRCUITS, VOL. 49, NO. 1, JANUARY 2014 The 10th Generation 16-Core SPARC64 Processor for Mission Critical UNIX Server" which details the lengths some (but not many) go to ensure that there are no undetected errors (wide range of techniques, ranging from where wires are placed on the chip, ECC, parity, residue arithmetic, automatic retry, etc.). No doubt there are some good (similar) papers in the IBM Technical Journal.

No doubt a good literature search would turn up dozens of other papers, and circuit design textbooks cover some of the territory.

In principle, interval arithmetic could provide a solution (you might not get the same interval, but if the intervals nest, you have consistent results and if they are disjoint you have a bug ... and if they nest, the narrower one is "sharper" which is better). In practice, most algorithms haven't been reworked for good interval implementation, languages don't provide very good support, nor does most hardware. All fixable in principle, but unlikely to be the solution you seek for todays off the shelf virtual systems available cheaply.

http://www.weibull.com/hotwire/issue21/hottopics21.htm

The behavior described is just what we should expect.

Of course, in many installations the failures aren't random but correlate to power, cooling or batch issues. Especially important to beat in mind in disk arrays with long RAID rebuild times. The 2nd or even 3rd failure may come a lot quicker than you'd expect.

This is why even with reliable storage arrays one needs backups.

The last word from the USPS was that ending Saturday delivery was the key to staying solvent. Now opening on Sunday is the key to survival?

While I personally would appreciate their taking Saturday off and bringing me just goodies on Sunday, the underlying cognitive dissonance seems awfully loud this morning.

I'd say something like a lastpass(tm no doubt) account, on the employer's nickel, so that each and every server could have a secure password (or class of server if its deemed more sensible to have all the servers in a rack or a room have the same password). Then the only thing the "magic envelope" has to be the username and password of the lastpass account.

No doubt folks with the responsibility for hundreds or thousands of servers have some better ideas about "best practice" ... so please share.

This is "scalable" in that admins could share (or not).

The tradeoff between ease of use, security, and ease of transfer to the next responsible party(ies) is not always a trivial one.

https://www.jungledisk.com/

I suppose it all depends on ones level of paranoia and which risks you fear most. Having all the data securely encrypted but in private homes means a couple of natural disasters and the data is gone.

One can layer encryption on top of theirs (as folks propose above with Dropbox) for an extra level of complexity.

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.