People with classical Downs syndrome (trisomy 21, the most common, and the one discussed here) are sterile -- they can't have children. One reason is that it's just too difficult to recombine and split three chromosomes two ways during meiosis.

It is possible that someone with a partial syndrome could be fertile (i.e. a duplication of some portion of chromosome 21), but I don't recall any cases of this when it was discussed in lectures.

human genome project

Of course. Pat Buchanan talked about this recently at NetHui in New Zealand:

Video link here, which also explains how the GCSB gets around not being able to spy on NZ citizens via contracting their staff out to other agencies. Also, 80-90% of intelligence is gathered from freely available sources (e.g. facebook, twitter), so terrorism is a 10% of 10% sort of thing in terms of surveillance laws.

An RNASeq run, either targeted to the ribosome or total (given that rRNA takes the lion's share) is a little bit quicker than culture, as long as the bioinformatics side of it is appropriately set up (e.g. massively parallel mapping, and automated count summarisation).

Sample preparation will take a few hours, and there are sequencers that will get results out in a few hours -- the mythical Oxford nanopore sequencers will speed both of these things up as well.

... <chirp, chirp>

Oh well, they can canola Nature then.

That's what they're trying to do. Unfortunately, NZ judges want this other stuff dealt with before the extradition trial.

From the email:

So they start off with what they think they need, then become more like APT as they need to add more features.

In other words, this is something to be used in addition to APT (i.e. post-install), rather than instead of APT.

Just like Debian has an implicit dependency on the base system (except for base packages, which have more complicated rules). In other words, this system will only accept a single dependency, the Click-Base-System. I'm not quite sure why this is different from only accepting applications that only depend on Click-Base-System.

And note that the "each package will install to its own directory" bit is on the to-do list:

...

That doesn't sound like an obselete thing to me, because you suggest that the described features do make sense. It just sounds like there are multiple ways to do these things. I like the idea of having multiple paths to get something done, but I also like the idea of having a single path that can be used to do many different things — menu systems have this ability.

There are some glue-free structures involving enclosed internal parts (moving or non-moving) that can't be created on a milling machine (or similar equivalent machine such as what you have enumerated), but can be printed on a layered additive printer.

It also has a "one-tool for everything" advantage, allowing you to rapidly prototype and evolve things in a fairly short space of time.

We're unfortunately not at 'atoms of the universe' complexity, so this might be a limiting factor in the future.

Consider a game that uses bitcoin for microtransactions, such that in-game money is bitcoin, and the transactions happen twice every development cycle (e.g. an accelerated day's worth of farm production, one transaction from user to game company, another from the company to the user). Assume these cycles happen roughly once every two seconds -- 3600 transactions per hour, or 86400 per day -- even if someone isn't actively playing the game (i.e. life continues after they leave). Round it up to 10^5 for the sake of simplicity.

A single person carries out 10^5 of these microtransactions per day in their game. With a game population of 10^5 (i.e. 100,000 users), that's 10^10 microtransactions per day for this game. With a transaction size of 100 bytes, this game will generate about 10^12 bytes of transaction data each day (presumably about half shared among all the users, and the other half recorded with the game company's account).

It would be silly to set up a game that did that, but it is probably within the realms of what is possible.

More like saying you can smoke weed without legal worries because the US government hasn't busted anyone yet.

It's more difficult to bribe computers, so I'd doubt this is what big pharma wants. A properly designed diagnosis system (open source, or government-managed) should offer the cheapest efficacious drug, rather than the latest drug that has been shown to be more effective than a placebo (but curiously untested in effectiveness against the most effective generic drug).

How does this compare with peltier cooling? Is there some obvious reason (e.g. no airflow) why peltier won't work in space?

Sending a hash of the file pre-encryption for a file encrypted differently for each person would not be particularly useful for deduplication at all, because it would give no indication as to the content of the file. The only people it would help would be groups interested in file usage statistics. You could do the block-level deduplication mentioned previously and hope that by random chance some blocks are similar, but that would be a tiny amount of space saved in comparison to the method I have outlined.

To aid deduplication, every file would be encrypted with its own key (different for each file, based on a hash of the file name). You would be able to obtain / decrypt the original file (assuming a sufficiently random / secure encryption key) under the following two situations:

• Access to the original file, so that you could generate the encryption key
• Access to the encryption key for that file, presumably obtained from someone who has access to the original file