Slashdot Mirror
Free Software, a Matter of Life and Death
ChiefMonkeyGrinder writes "Software on medical implants is not open to scrutiny by regulatory bodies. Glyn Moody writes: 'Software with the ability to harm as well as help us in the physical world needs to be open to scrutiny to minimise safety issues. Medical devices may be the most extreme manifestation of this, but with the move of embedded software into planes, cars and other large and not-so-large devices with potentially lethal side-effects, the need to inspect software there too becomes increasingly urgent.' A new report 'Killed by Code: Software Transparency in Implantable Medical Devices' from the Software Freedom Law Center points out that, as patients grow more reliant on computerized devices, the dependability of software is a life-or-death issue. 'The need to address software vulnerability is especially pressing for Implantable Medical Devices, which are commonly used by millions of patients to treat chronic heart conditions, epilepsy, diabetes, obesity, and even depression.' Will making the source code free to scrutiny address the issue of faulty devices?"
That the Pacemaker Genuine Advantage warning I got last week was a bit of a shock...
Dupe! This was covered a couple of days ago.
Custom electronics and digital signage for your business: www.evcircuits.com
Just require that all such software rigorously use formal methods to mathematically prove that it functions as intended. The manufacturer could then send their proofs to some regulatory/standards agency to verify.
To me, this is just common sense. This code doesn't necessarily have to be FL/OSS in my mind - let them keep the copyright, but it most definitely should have code available for public review. Would you be willing to take a new wonderdrug where the drug company won't tell anyone what's actually in it, but assures you that it'll work? If they must disclose the formula to their drugs, then they ought to be required to disclose the code to their software. Let existing laws like copyright ensure that no one else uses it.
"People who think they know everything are very annoying to those of us who do."-Mark Twain
The thing about this is that this is not really a question about badly written software. I think the current regulatory system provides a high enough level of protection against badly written software that making the software open source would not add a significant amount of increased security. However, a greater concern is the possibility that someone could insert code with specific triggers which could be used for malicious purposes. It is not that I believe that they would, it is that the implications for our society if someone did are so severe that some effort must be made to reduce the chances of that happening.
The truth is that all men having power ought to be mistrusted. James Madison
and maybe free as in reusable to improve it,
but not necessarily free as in beer!
People will die from shortcomings of technology, whether the tech is FOSS or not. Capitalism being the state religion in most of the developed world, I think it's safe to say that proprietary software will be with us forever. Fortunately, idealism is still a common enough human trait we can say the same of FOSS. One isn't going to "win" over the other, ever. We will simply continue to have both. And that's as it should be.
Caveat Utilitor
commonly used by millions of patients to treat chronic heart conditions, epilepsy, diabetes, obesity, and even depression.
Of course, the #1 software used to treat depression (even though it doesn't work) is Facebook. Does that mean they need to go open source?
And Facebook is also the #1 software used to cause chronic heart conditions, diabetes, obesity (and very successfully, thank you).
I need trepanation like I need a hole in the head.
I am sure I will be mod'd down for this but... Writing safety critical software requires a level of testing, documentation and traceability that I seriously doubt the open source community would tolerate. Many, if not most, open source projects don't even keep a reasonably current wiki let alone a complete set of traceable requirements, design and formal tests. I don't blame people for not wanting to do this sort of work for free - but it is very important when developing systems which need to run reliably for decades or someone will die.
The typical FOSS argument usually involves living in a perfectly ideal world. You know, the kind of world where highly qualified individuals scour the internet for code to audit. And where Russian (et al) hackers don't scour open source code looking for exploits to cash in on.
Similes are like metaphors
I'm a big fan of FOSS, but I've got my QA methodology hat on right now. Opening up the source code isn't providing better Quality Assurance coverage, it's just getting more eyes on the code, and at best a bunch of User Acceptance Testing. (Though clearly not with pace makers, I doubt people are going to line up for that Beta test. Unless maybe Blizzard claims it's part of their next big MMO.) This could be as much an argument for higher standards of quality assurance as for open source software. In face, hell, I can see companies opening up the source to reduce their liability and cut the costs of their own QA.
heartworm.
Even the best software can go completely wrong with the wrong person operating it.
Taxation is legalized theft, no more, no less.
In one experimental attack conducted in the study, researchers were able to first disable the ICD to prevent it from delivering a life-saving shock and then direct the same device to deliver multiple shocks averaging 137.7 volts that would induce ventricular fibrillation in a patient. The study concluded that there were no “technological mechanisms in place to ensure that programmers can only be operated by authorized personnel.” Fu’s findings show that almost anyone could use store-bought tools to build a device that could “be easily miniaturized to the size of an iPhone and carried through a crowded mall or subway, sending its heart-attack command to random victims.” ..
Though the adversarial conditions demonstrated in Fu’s studies were hypothetical, two early incidents of malicious hacking underscore the need to address the threat software liabilities pose to the security of IMDs. In November 2007, a group of attackers infiltrated the Coping with Epilepsy website and planted flashing computer animations that triggered migraine headaches and seizures in photosensitive site visitors.13 A year later, malicious hackers mounted a similar attack on the Epilepsy Foundation website.14
New from Apple, the iHeart, with iPod/iPhone docking station, it'll give new meaning to dancing to the beat.
ad astra per alia porci
But really what you need is established code standards, designed to substantially reduce the possibility of errors based on known faults, and an absolute rule that they not be violated, code reviews, and an independent third party auditing both the standards and the code produced to ensure it's compliant with these standards.
Making the code available for scrutiny is a double-edged sword. Sure, it might help to catch critical bugs in the software faster. But with some devices, it really raises a host of new issues. Some pacemakers out there are configurable wirelessly once they are in the patient's body. This is actually a very critical feature. But do you want to risk everyone being able to reverse-engineer the protocol used for adjusting the settings for such a device? A wrongly configured pacemaker can be deadly. Right now these things are fairly secure because they are rather rare and not interesting enough as targets for hacking.
Besides, proving that some piece of code works as intended (or at least fails gracefully in all circumstances) in an essentially uncontrolled environment is quite a feat. Embedded equipment is hard to service, has to have a longer hardware lifespan than normal hardware, is often custom designed for a single application and thus may have subtle hardware defects not reproducible on similar test systems... oh, and who says that the compiler or even the CPU is bug free? This is all common knowledge around here, but I just want to give the full list. What this means is that just opening the source code might not cut it. The validation would have to be performed on the hardware it was designed to run. So, where's the call to open up the hardware design and documentation to public scrutiny as well?
http://www.moonlight3d.eu/
With rigorous testing and regulation, I don't worry too much about a device while the company that made it is still thriving, but what if the they go out of business?
I propose that the FDA require all design data for "complex" devices, including the software" be placed into some form of escrow so it can be released if the company goes under.
Really. Finding security holes in software that runs on a plain vanilla PC is one thing, finding the cause of glitches in the nanosecond range on an embedded system is another thing entirely.
I would imagine this kind of software would be too complex and specialized to be effectively reviewed at large. And who would still be responsible if something was wrong? There would be discussions to no end on how to do things. However, some kind of vault (government or 3rd party) to store the source would be good just to prevent intentional or accidental loss of the information should long term statistics show something is not right. If the software is open source, then the whole design may have to be open.
i will overclock it. Live fast. Die young.
First of all, most device manufacturers would prefer to build based on a closed-source infrastructure so that they do not have to re-publish their source code. So it's unlikely that we will see much GPL software in medical devices. Look at how effectively threats of lawsuits over busybox completely removed Linux from consumer routers post-2005.
Second of all, the GPLv3 prevents you from signing a binary to run on a specific piece of hardware. So no GPLv3 on medical devices.
It is entirely within the rights of free software publishers to impose these restrictions. However, it is disingenuous for them to express surprise that their software is then avoided for certain applications.
The Therac-20 radiation therapy device worked reasonably well. Despite the software flaws, the hardware safeties in place prevented any deadly accidents. Problem is, because of the hardware safeties, nobody knew just how bad the software was. It had never been formally verified.
Then some numbskull decided, "Hey, let's let the software handle the safety interlocking, and we can cut down on hardware manufacturing costs!" The result was the Therac-25, which maimed and killed people.
After the machine was recalled, someone finally sat down and did a real analysis of the code, and found a whole raft of problems and bad assumptions. Nancy Leveson wrote the definitive report (PDF) on the failures in the R&D processes that made the Therac-25 so deadly.
Yet, armed with this warning (among many others), both manufacturers and purchasers keep human lives as transactions on a double-entry ledger. It simply comes down to, how many deaths per thousand uses are "acceptable"? Manufacturers and medical facilities already have so many costs. Is it worth it to add on the cost of formal code analysis?
But nobody will ask the Therac-25 victims and their families.
I decided early on in my I.T. career, that I didn't want the stress of people's lives depending on my correct code. I hadn't had any training in formal verification. In hindsight, I see my worries would have come from incompetent management, more than from myself.
No, but it makes it easier for an auditing body to do so, or for competitors to point out (and prove) that their device is safer.
Apparently the Family Heart Center will now let you overclock the Jarvik and Yamaha models, but it voids the warranty.
"I'm not a quack, I'm a mad scientist! There's a difference." - Dr. Cockroach
Some mechanical devices and most bridges and buildings require licensed engineers or architects to put their stamp of approval on the designs. They do not require publication of the engineering or architectural drawings though.
I for one would welcome professional licensing for certain "it can kill you if it goes wrong" software, particularly in isolated devices whose software can't be tampered with undetectably.
If a licensed Professional Software Engineer puts his seal on a pacemaker or airplane, and the software kills someone, he's just as responsible as the civil engineer would be if a faulty bridge design kills someone. In both cases, the licensed professional's responsibility would come back to "was the engineer acting in accordance with professional standards at the time" and "was the device built and maintained in accordance with the design."
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
Had to do it, saw them live the other day.
Official auditing bodies could have the source code any time they ask for. They don't.
, or for competitors to point out (and prove) that their device is safer.
^THIS
Implantable pacing devices, cardioverters, and pumps (life-sustaining devices) depend on complex custom hardware designs as their platform, and that hardware is *highly* interactive with the software. Many of these devices can only achieve their miraculous longevities on a primary cell by deferring functions to hardware. If you don't have access to the information re: the hardware, the code itself might as well be inscriptions in Atlantean glyphs. You'd have to bust trade-secret protection to get a public viewing of everything needed to review the code, because you'd have to see, *everything*.
From what I've seen, most FOSS projects seem to skip the QA step unless it's a dual licensed product with a company behind it.
"The problem with socialism is eventually you run out of other people's money" - Thatcher.
A friend of mine who does programming for heart-lung machines once told me about something like this. One of the radiation machines used to treat cancer patients had a multi-core processor, but its programming didn't always take this into account. So every so often, the machine would have a race condition, and administer radiation several thousand times more powerful than it was supposed to. The poor patient would go in for a routine procedure and end up in worse shape than he/she was in already. I'm not sure if this is one of those apocryphal things that floats around or if it actually happened, but it seems like it could be possible if all the software isn't carefully checked first.
But if it's made by German Engineers, you know they make good stuff!
This is a faulty argument. The layman can no more review code destined for a GPC than they can an embedded device. To suggest that there is no opportunity for peer review of other industry members and subject matter experts within the particular development community, but outside of the specific organization responsible for a given project is as ludicrous as to suggest that every single adult in the world is capable of reviewing the design for an automobile to ensure it meets safety standards. My grandmother has never carried out a security audit on Firefox, but yet its track record remains far superior to that of Internet Explorer.
"Well, do you want your pacemaker to have intuitive manageability through Group Policies, or not?"
No, just a good SNMP MIB and traps.
I was joking with an ex-sys-admin friend of mine who just underwent open heart valve replacement, and commenting on the idea that the wireless ECG gear needed SNMP to alert when it detected a loose lead. She laughed - not good when you were doing a good impression of an Aztec sacrifice just a couple of days previously.
www.eFax.com are spammers
Although that's a legitimate concern, and relates to my suspicion that Open Source is a bit of a red herring here, I don't think it's always true. I work for an institution that has both outsourced and done in house QA on open source projects before implementing them. Some of the larger Open Source projects have had extremely extensive QA work done and have great community support for it. And of course, some do not.
Dude check it out! The developers released the source code to my heart monitor! I am going to mod it so that it makes my heart beat 10 times faster. It's going to be awesome.
A panel of industry professionals could certainly do a credible job reviewing this stuff. A problem would lie in the affiliations of these experts; they had to get "professional" somehow. The big med companies have a lot of work invested in their devices and guard their secrets jealously. Even with good NDA protection or other guarantees I doubt there would be trust.
Given the ability to create such a panel, a sort of "consumer reports" for the implants industry, I think regulatory agencies would welcome this but the industry would have to be forced into it.
I don't like the idea of tossing out the pacemaker and getting a new one.
If the unit fails, it's hardly likely to do so when I'm near a pacemaker replacement shop, is it.
And if OSS is so immune to bugs, how come Firefox has so many problems? How come they patch tons of security updates with each release? This isn't just an OSS project, it is a popular, well funded one. And it has bugs left and right.
So, if OSS is so good, what's going on?
Or maybe, just maybe, is the real trick the quality of the review and the methods for writing code, which can be done closed or open?
I'd rather keep writing my software for embedded avionics to the RTCA DO-178B standard http://en.wikipedia.org/wiki/DO-178B
While I think public review may provide some defect discovery, the complex nature of embedded software in purpose built hardware is beyond the skills of the casual observer. Besides, DO-178B provides a process and set of rules for developing safety critical software. There are documentation and testing rules that go well beyond anything that consumer grade software developers even contemplate. It has been this way for decades specifically because the FAA determined a long time ago that bad software on airplanes can kill people. So they have been making avionics companies develop to a higher standard for a very long time.
I really doubt that making the source code public would add any real safety.
It is pure fantasy that there are tons of people with tons of time on their hands who will work diligently to solve the boring and difficult problems (which bugs are) in software. In reality, many OSS projects get almost no help at all from anyone but the core developers.
My favourite example, since I use it all the time and it annoys me, is Firefox. This is a major OSS project. It has financial backing, and large status. None the less it is riddled with bugs. Many are annoyances (like all the plugin trouble recently) others are security issues (look at the number of critical fixes per release). It is an ideal case for open source, in that there's people who can work on it full time, the source is open to all, and it has the popularity that people know about it, and yet it is problematic.
Part of the problem is just what I said, that finding bugs is boring. It is tedious work to try and peg where a bug is, especially with elusive ones that aren't something like a crash where you can look at the dump file. It is even harder when you don't know if there is a bug at all, when you are just straight out auditing code, hoping you see something that someone else missed. It is hard, boring work and thus many of the "freelance OSS" types don't do it. For that matter, those that do may be no good at it. They look over the code and say "Yup, is fine," just assuming they are so brilliant they'd see any bugs in it.
The "Many eyes equals no bugs" hypothesis just doesn't hold up in real life.
...that OSS update you need NOW for your ailing grandma's pacemaker to some basement dwelling Linux freak who will get to it "when I'm done compiling the latest kernel"?
As there is no professional certification for so-called software engineers nor for programmers, such "other industry members and subject matter experts" are neither. Who is to say who is an expert and what is to stop Joe Wannabe from claiming to be an expert programmer because he took C and Assembler 10 years ago in community college?
There is no "-1 offended" or "-1 you don't agree with me" mod options for a reason.
This is simply one more instance of a larger problem. I once heard a brilliant observation; "If uncertain, you can always discover the game you're actually playing (vs. the one you think you're play) by whichever game you happen to be winning." Our society is predicated on a game called "PROFIT". Period, end of discussion. There are a lot of other games... satisfaction, fulfillment, sustainability, quality of life, or even personal freedom. All of these other games we say we're playing. All these other games fall short and are being lost, because the game we're actually playing is the game called "PROFIT". You really want to get, the human enterprise of this culture measures only one thing. If for example you had a company that saved the world, and lost the "PROFIT" game, it would be out of business tomorrow by 9:00 AM.
Said another way... We measure Gross National Product. Disasters are great for the GNP, it skyrockets when cities are destroyed, families broken, houses burn down and children are killed in car crashes. If you think I'm mistaken, look at what Katrina's impact on New Orleans did for the economy, house value shot up like a rocket. This is the game we are winning. If instead, we were to get interested in a different game, for instance the Gross Domestic Satisfaction, or perhaps the Gross National Quality of Life, then perhaps dumping toxic waste into other people's drinking water would instantly become a problem, instead of a solution. When Halliburton fracs shale to get at natural gas, and oh by the way, just happens to poison an entire town by releasing toxic horrors into their ground water, then proceeds to cover it up, hide the facts, tie the town up in litigation, and it can do this in the first place because it got laws passed that exempted it from the Clean Air Act, Clean Water Act, and virtually any other national law preventing environmental destruction and abuse to human safety, you can be very certain its doing great business. In fact, its making making a mountain of profit. Its happy, because its winning the game its playing.
Mr. Cheney is truly an honest man, he wins the games he plays, and he's very good at it. It just happens that the game he's playing is: "Rape the planet in the name of PROFIT". When our current Vice President is a hit man for the RIAA, or the entire Republican party can barely restrain itself from collectively smooching the behind of British Petroleum, or when we put judges into the Supreme Court, who's only reason for being, is to rubber stamp laws designed to give the Profit Makers what they want, no matter how obscene, or what the cost to the future, or how egregious the assault to the dignity and humanity of the other 6.8 billion people on the planet might be, it must be clear to everyone. We are gleefully winning the "PROFIT" game. You could get mad, or self righteous, or even subversive, but until we as a society demand that we begin to play other games instead, it would be silly to expect a different outcome. You simply can't hit a home run if you're shooting hoops (unless you're playing Base-ket Ball)
On rethinking public funding: http://www.pdfernhout.net/on-funding-digital-public-works.html
"An outdated scarcity perspective in the non-profit community is still manifesting itself, however. There remains a continued emphasis on charitable projects which include plans for restricting access to the resulting publicly funded digital works now, in the hopes of creating revenue streams later. The funded organization usually proposes continuing to improve the work itself under its solitary control using money derived from selling licenses to the work. Contrast this with, for example, the post-scarcity development of the GNU/Linux operating system, made by thousands of volunteers contributing improvements to an initial base contributed by Linus Torvalds and the Free Software Foundation (FSF) GNU project.
The old scarcity criterion towards selecting what makes a viable project (based on a recurring royalty stream for static content) is completely at odds with the new post-scarcity model (based more on streams of attention, status, service, and customization). The new collaborative development process made possible by the internet (resulting in a work made by sharing licenses to copyrights made by a distributed network of authors funded indirectly by other means) is fundamentally different than the old process (resulting in a work made by centralized copyright ownership with a development process funded by selling licenses to the result)."
A 21st century issue: the irony of technologies of abundance in the hands of those still thinking in terms of scarcity.
But really - will it improve things? You get a bunch of eyes on the code that spot dumbshit mistakes like an undefined variable... But how many eyes will understand the code, and the specialized hardware it runs on, and the medical factors that go into determining how the software and hardware must work in the first place.
This isn't yet another web browser or word processor running on a vanilla PC. This is a highly specialized problem domain running in an unusual environment on nonstandard hardware.
Once again, people forget the benefits that capitalism has. Requiring medical devices to have open source software will completely ruin the benefits of capitalism, and instead advance the negatives of capitalism.
The world of capitalism revolves around reputation. If a medical device has a software problem, and it kills 3 people, 3 million people will know about it -- the media works that way with life-and-death products really really well. The media also eliminates propeganda in a capitalist society.
Now, if 3 million people know that ACME medical just killed 3 people, the question is simply: who's fault is it?
It can be ACME's fault, it can be the software's fault, it can be the government's fault, it can be the users' fault.
If the software is proprietary, it's ACME's fault, plain and simple. No one else is to blame, we blame ACME. ACME's stock plummets. ACME either goes out of business, or is super-safe for decades to regain any semblance of trust. Either is good. That's what we want -- accountability, and and improved industry either by elimination or by improvement.
If the software's open, then the fault lies with whomever approved the software for public use. So you can trust your government safety regulation inspectors -- trust me, it's good to have them but they don't do anything. And no one pays them enough to be accountable for anything.
Alternatively, you can fault the software -- that being the operating system or the platform, or the borrowed code, or the licenced code, or whomever. The problem is, you now have thirty companies contributing to the software, and the problem is usually with the interaction between them, not with any one of them. So there's no one to actually blame.
It can be the user's fault. Sure. They used their cruise control in the rain, and it accellerates when hydroplaning -- they do that by the way. You're not supposed to use cruise control when the ground is even a little bit wet. But relying on users to not screw themselves really isn't going to be successful in saving their lives.
So what you're left with is a big complex situation where everyone and no one is at fault. And so you're left with no one caring any more. So much so that an airline considers broken airplanes an act of god, and are no longer accountable for delays due to poor aircraft maintenance.
Make companies responsible for their actions, so you can then hold them accountable for their actions. You'll find that just like people, they act to improve their own situation only when it matters.
So tell me, who's at fault when your baby falls off of the changing table and hits his/her head on the edge of the table?
The table manufacturer for leaving a sharp edge?
The changing-table manufacturer for not putting a lip high enough to stop a rolling baby?
The manufacturer's safety inspector?
The government's safety inspector?
The baby for rolling?
The adult for not child-proofing the edge of the table?
The adult for not increasing the lip of the changing-table?
The adult for not strapping the baby to the changing table?
The parent for entrusting their baby to an adult who clearly is too stupid to be anywhere near a baby?
Let's hope you got it right. Let's hope you picked someone who did something actively negative, and not someone who didn't do something positive. Welcome to decision-making 101. Act.
I'll dupe my reply to this dupe, but only because I have a clue of what I'm talking about.
I work for a medical device manufacturer. We don't make a life-essential device, but all the laws apply to us as well as the manufacturers that make critical devices. The FDA already has the power to examine a manufacturer's source code. When they come in to perform an inspection, the inspectors have the same powers as federal marshals. They can look at anything - just time and resources are the limiting factors. When a device is submitted for FDA clearance, there is a lot of software documentation that has to be included in the application. Our software section is one of the thicker sections in an application. Depending on the level of concern of the device, a manufacturer has to submit all test results, software detailed design, etc. The stuff we have to do during development here is incredible and we're a minor level of concern.
Regulation requires that all designs be periodically, formally reviewed. It requires that the review includes an independent reviewer and that reviewers are just as (if not more) technically competent than the designer. The FDA may not have the resources to review every line of code, but they do have the resources to look at the documentation from the reviews and to look at the documentation listing the qualifications of the reviewers.
Manufacturers are required to conduct risk assessments for their devices and identify any/all reasonably foreseeable hazards and to mitigate those hazards until they are as low as reasonably practicable or the clinical benefit to the patient outweighs the risk. The risk assessment must be conducted by clinical and technical experts. Each mitigation (or fix or change to a line of code) has to be re-evaluated for risk and possible repercussions to the rest of the device. Testing is also quite rigorous and safety and reliability are the top priorities. Our testing takes months. Changes that affect safety may have to be tested in expensive clinical trials on human subjects and the results resubmitted to the FDA for clearance.
Perhaps by having the public look at source code there will be some bugs found. But I'm sure that the bug has already been considered as part of the manufacturer's risk assessment, and any fixes for that bug will not be fast in coming considering the heavyweight nature of the development process.
--The Programming goddess from Gorflaz
Some of my old friends work writing software for medical devices, like pace makers and defibrillators. They use a development method similar to that used by the GN&C code in the space shuttle flight software. We all worked together writing shuttle software. It is certified CMM-5. At this point in time, there is no safer way to produce software, IMHO. Real-time software is very different from the crap placed into PCs. Man-rated software gets added hardware redundancy, in addition to the extremely cautious development techniques. For real-time software, there are considerations beyond what 99% of the software writers out there understand. It is a big deal and the developers understand what life and death mean. At least 50 people see, review, test, and otherwise validate this software before it ends up inside grandma.
The entire team knows about grandma and takes every precaution possible to ensure the software works as designed. It is hard to explain unless you've worked in that type of environment. Safety trumps every other concern. EVERY OTHER CONCERN. For the team I was in, we didn't worry about monetary loss or harm to the company. We didn't care about that. We worried about the people who would die if any tiny mistake got into the software. We worried about hardware errors that could tell the software to do something wrong - killing people. We worried a bunch, then we wrote the software defensively. Dangerous decision trees were affirmed, not defaulted. All variables were initialized to known values - never left dangling with unknown, random data (like FOSS software often does). We weren't allowed to use dynamic memory allocations and using pointers required an exception approval. They were deemed dangerous, so the use was limited.
Software used in other medical devices ... well, I have no idea about it. I've heard claims that x-ray machine software was using double the recommended dose due to a software error, but that was 10 yrs ago.
I don't worry about the software in pace makers at all. I worry about the idiot mech tech running the x-ray machine or the scientist that hates computers using some custom code written in a 4GL that wasn't designed to be used in the way they are using it now. And I worry about hospital computers having internet access, viruses, spyware and people inside emergency rooms watching the world cup on PCs that shouldn't be on a network at all.
...then please explain this to me.
Why does PulseAudio exist?
What is the rate of death and injury due to software bugs?
Before proposing a solution, first show there is a problem. There could *definitely* be a problem if people figure out how to "hack" the source code of a pacemaker or other device which, keep in mind, have EM interfaces of one type or another.
(-1: Post disagrees with my already-settled worldview) is not a valid mod option.
it's more important than that.
as seen by the Unreal trojan that sat undetected for almost a year. http://www.webupd8.org/2010/06/linux-trojan-goes-unnoticed-for-year.html