Comment Dolphin secrets (Score 1) 179
I heard on the Rush Limbaugh show that it'll be good when we learn what dolphins know until they leak the location of Osama bin Laden's grave.
I heard on the Rush Limbaugh show that it'll be good when we learn what dolphins know until they leak the location of Osama bin Laden's grave.
A few years ago, my parents were shopping around for burial options. My mother wishes to be cremated and my father does not. Being frugal, my mother wanted to know if they could just buy one plot since the cremation urn doesn't take up a lot of space. The funeral planner had to check on the regulations of how many people could be buried in a single plot, and finally said that it would be possible.
I said to my father "Dad, do you realize that Mom is going to be all over your back for all of eternity?!"
The law only lists the What, it does not explicitly tell you How to implement the regulation. Kind of like the difference between a requirements spec and a design spec. The FDA also does not require you to be compliant to ISO 80001, but they will recognize your compliance certificate as a way to easily prove you are meeting the regulation. Otherwise the FDA will have to do a lot of painful digging around in your files (sans rubber gloves and lubricant) to get the proof they're after.
I find it ironic that saccharin is an artificial sweetener but reacts with bitter-sensing cells. I always knew saccharin had a weird after-taste.
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.
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.
Last year's Blizzcon was tremendously popular. So much so that their servers were unable to handle the strain of fans competing for 15,000 available tickets. This year, Blizzard was more prepared; they made an additional 5,000 tickets available and set up a queue so that the transaction servers weren't overwhelmed. CEO Mike Morhaime said during the keynote address that if you weren't able to get into the queue within 30 seconds of its opening, the tickets were sold out before your turn came. Tens of thousands more chose to order the pay-per-view coverage, demonstrating the extraordinary enthusiasm felt for Blizzard's games. Their presentations didn't disappoint. Read on for details on the status of StarCraft II, Diablo III, World of Warcraft: Cataclysm, and the new Battle.net. It's divided into sections by game in case you're only interested in one or two of them.
It's a naive, domestic operating system without any breeding, but I think you'll be amused by its presumption.