Working in the medical device industry, I can tell you that making a medical device is HIDEOUSLY expensive.

The cost to produce a hearing aid (microphone, amplifier, audio tube, speaker, battery, silicone tip) is pretty tiny. If you were just producing this assembly you would probably be able to crank it out for less than $1000 with a fairly tidy profit margin - maybe as high as $500 (assuming you build them in quantity).

Now onto that cost add the FDA-Mandated record keeping (design history, a history of each device from manufacture to end-user distribution, including records of any time it came back for service/adjustment), performance testing, IEC/UL safety testing (to make sure it won't shock Mom's eardrum, or over-amplify and blow it out), IEC/UL electromagnetic compatibility testing (to make sure it won't cause Mom's pacemaker to go haywire), biocompatibility testing (what if someone is allergic to silicone?) and staff to oversee all of this, and all of a sudden your $1000 device winds up costing the consumer $3000, and you're still only making $500 in profit.
Hearing aids also aren't a growth market: There are only so many people who are hard of hearing and need the devices, and if they buy a good one and they'll keep it for years, so there's not a huge amount of recurring revenue for replacements, so now we need to make enough money off them to coast along until the next person needs to buy one.

Bottom line: Complying with regulations costs lots of money, and the cost of devices are inflated as a result.
Lest someone take this as an anti-government rant, it's not: The FDA regs do serve a purpose, though perhaps said purpose is not 100% appropriate for all classes of medical devices.

Also the FDA is not the only government agency that introduces a price-inflating regulatory burden. Consider these two identical aviation headsets:
http://www.mypilotstore.com/mypilotstore/sep/4680 (Non-TSO)
http://www.mypilotstore.com/MyPilotStore/sep/5284 (TSO)

The key difference between these headsets is a piece of paper. They are materially identical in all other respects.

... that I coat myself.

I've raised anachronism to an artform.

I like the idea of exposing your students to CFD packages, particularly the variation between experimental results & results off of a theoretical model. My concern would be that mastering a CFD package (or even become a basic user of one) is pretty time consuming. As others have pointed out you usually don't touch CFD packages until late undergrad or grad school.

Consider building the models yourself and running them as a demonstration rather than asking your students: They get the benefits of seeing what the software can do & being able to reference the theoretical data generated, but won't have to deal with the frustration/learning curve of CFD software.
If there's an interest you can offer an extra credit project where students design (or modify) a mesh & report the results.

... Because what we really need is another damn open source license. I was just thinking to myself the other day, I said "Self, what the world needs is just ONE MORE open source license. That would just make everything SO MUCH BETTER!"

And why only Chordata? It's not OK to kill cows, dogs, land-fish or sea-kittens, but killing arachnids (scorpions, spiders) or crustaceans (crabs, lobsters) is OK? Is it because they're not cute?

Morons.

Won't somebody PLEASE think of the CHILDREN!?

http://www.youtube.com/watch?v=Qh2sWSVRrmo

Tents are not particularly aerodynamic when set up, and pretty heavy when folded - might have about the same range as a laptop :)

<SARCASM>
Mmhmm, yes. I agree 1000%. Don't update your virus signatures. Because ya know, new viruses don't get created very often. You can run with signatures over a year old and still have great protection!
</SARCASM>

<SARCASM>
Yes, because distributing software for several versions of Free/Net/OpenBSD, each Linux distribution, Windows, Solaris, AIX, HP-UX, etc. is totally feasible for a free project.

It's not like they would have to fund the time, equipment and distribution bandwidth for that, or have to deal with irate admins screaming about how ClamAV breaks their change control policies by automatically installing binaries on production servers.

And software with automatic updates never ships an update that bricks production servers (*cough*Exchange*cough*), so this is a perfect solution.
</SARCASM>

Sometimes I really wonder what happened to the Slashdot crowd's common sense.

Well, you *can* configure your email system in such a way that when ClamAV goes away it still passes mail (though obviously most people, myself included, do not configure our systems that way).

That's an admin's choice to make, and like almost every choice there are tradeoffs: Potentially pass virus-laden mail, or potentially queue/defer/reject mail until the scanner comes back on line.

Tell me, do you sandbox a full environment and test every virus signature update prior to rolling it out?
If so, what is the length of your pre-deployment testing cycle? How many people are dedicated to your test team, and how do you justify their salaries?

(Not trying to be a dick, I'm genuinely curious if anyone goes to this level of overkill, and how they manage to get it approved. I had to fight uphill both ways in the snow to get a dev environment built...)

As someone who was bitten by the issue (yeah, I'll man up and admit it - my company's mail server went wonky for about a half hour while I upgraded) I agree -- they pretty much did the right thing.

There was plenty of notice -- The fact that many of us weren't on the clamav-announce list is OUR fault, not theirs.
A kill command may not be the most "polite" way of retiring an old version of software, but for a free service I certainly don't expect them to invest huge amounts of time and money in figuring out how to support the old stuff forever.

Seriously -- I got a bunch of qmail deferrals & the bounce/deferral messages were all utter shit ("451 qq error").
This guy wins 100 internets for having a FUCKING USEFUL BOUNCE MESSAGE -- I want to buy him a case of his preferred alcoholic beverage.

The method SourceFire chose to use was to encode a kill command in the ClamAV updates. If they had simply "shut down the [update] server" ClamAV would have continued to work, just without new signatures.

See their announcement at http://www.clamav.net/lang/en/2009/10/05/eol-clamav-094/