If they aren't already doing this, an open source product should make it a bit easier for the malware writers to test out how well hidden their product is (or how closely it represents the noise experienced during a normal day of computing).

If you're taking a paranoid view, a slight clarification is needed here. Your ISP does not see the unencrypted information you transmit if it's encrypted, or email, chat, etc., as long as they do not have the means to decrypt that data.

I agree that it's perhaps not the best idea for cancer genome sequencing, but current 2nd-generation sequencing should be beneficial for the standard human genome. Even at a cost of $10,000 per person, you may be able to substitute a single expensive drug for a substantially cheaper generic when knowing that a person has (or doesn't have) a particular mutation. As long as the sequencing is high enough quality (as you should get from a long paired-end Illumina run), it only needs to be done once, and then can be re-used for whatever new genetic discoveries come your way.

I've wondered for a couple of years now why drug companies aren't already doing this (or at least subsidising the cost of sequencing). Some drugs have been brought back from the brink of rejection via genetic tests, and given the high cost of drug research it makes sense to do a relatively cheap genome sequencing if it hasn't been done on a person previously. The cost of whole-genome (and whole-transcriptome) sequencing is now in the range where research institutes are starting to consider it as a routine operation, and it won't be long before it falls into the price range of a cost-conscious consumer.

Reading that article kept bringing forward more "oh no" realisations, stemming from the following points:

1. like time, the SCN cannot decrement. It must always tick forward
2. when Oracle databases link to each other, maintaining data consistency requires them to synchronize to a common SCN. This is necessarily the highest SCN carried by any participating Oracle database
3. If the soft limit [16384 times the number of seconds since 00:00:00 01/01/1988] is exceeded, the database can become unstable and/or unavailable.

The "recovery" for exceeding the soft limit is to shut down the databases until the SCN goes below the soft limit. From then on, you just have to hope that no databases you're synchronising with will have a SCN that is close to (or beyond) this soft limit.

Repapetilto was asking about epigenetic effects. I don't think there's enough evidence to suggest that epigenetic effects are transferred through to offspring, but I was giving an example that was almost this situation.

The current belief is that epigenetic effects occur within a generation and do not get carried through to children:

http://en.wikipedia.org/wiki/Epigenetics#Evolution

This section suggests that any epigenetic marks transferred to sperm are removed at fertilisation:

http://en.wikipedia.org/wiki/Transgenerational_epigenetics#Removal_of_epigenetic_marks

While this TED talk is not talking about transfer to gametes, it indicates that exposure to different environmental factors while in the womb can have an impact on development later in life:

http://www.ted.com/talks/annie_murphy_paul_what_we_learn_before_we_re_born.html

Simon Tatham has a good writeup about bug reporting. It's a great article, well worth the read.

http://www.chiark.greenend.org.uk/~sgtatham/bugs.html

But, if you won't read it, here are some one/two-sentence points from that article:

• Give the programmer some credit for basic intelligence: if the program really didn't work at all, they would probably have noticed
• One of the very best ways you can report a bug is by showing it to the programmer.
• If you have to report a bug to a programmer who can't be present in person, the aim of the exercise is to enable them to reproduce the problem.
• Describe what happened. Tell them exactly what you saw. Tell them why you think what you saw is wrong; better still, tell them exactly what you expected to see.
• When something goes wrong, immediately stop doing anything. Don't touch any buttons at all. Look at the screen and notice everything out of the ordinary, and remember it or write it down.
• Using your intelligence to help the programmer is fine. Even if your deductions are wrong, the programmer should be grateful that you at least tried to make their life easier. But report the symptoms as well, or you may well make their life much more difficult instead.
• Say "intermittent fault" to any programmer and watch their face fall.
• Be specific. Be verbose. Be careful of pronouns. Read what you wrote.

Or Simon's summary:

• The first aim of a bug report is to let the programmer see the failure with their own eyes. If you can't be with them to make it fail in front of them, give them detailed instructions so that they can make it fail for themselves.
• In case the first aim doesn't succeed, and the programmer can't see it failing themselves, the second aim of a bug report is to describe what went wrong.

• Describe everything in detail. State what you saw, and also state what you expected to see. Write down the error messages, especially if they have numbers in.

• When your computer does something unexpected, freeze. Do nothing until you're calm, and don't do anything that you think might be dangerous.
• By all means try to diagnose the fault yourself if you think you can, but if you do, you should still report the symptoms as well.
• Be ready to provide extra information if the programmer needs it. If they didn't need it, they wouldn't be asking for it. They aren't being deliberately awkward. Have version numbers at your fingertips, because they will probably be needed.
• Write clearly. Say what you mean, and make sure it can't be misinterpreted.
• Above all, be precise. Programmers like precision.

It doesn't matter

Here's my list:

http://user.interface.org.nz/~gringer/iopencd/browser/home.html

Which reminds me... I should update that CD and replace OpenOffice with Libreoffice.

Better learn cricket or hockey then. Those games have nice soft balls that are completely armless.