The input set is problematic because it contains every number from 0 to VA.length exactly once.

This allows "algorithms" like this:

  for x in [0...VA.length]
    while (VA.get(x) > x)
      VA.swap(VA.get(x), x)

Its not a game; its a learning tool. It doesn't bother me that people can do that.

Also, that's not going to work quite right - the values are [1..VA.length] (see the bottom of the page), while the indices are [0...VA.length].

When I forced myself to learn touch-typing with a qwerty keyboard i used gtypist. I found it to be sufficient for its purpose.

The only gripe i had with it was that it required typing two spaces after a period. I found this just plain weird, so I fixed it in the tutorial files.

I guess using a blank keyboard also helped quite a bit..

Sorry, hadn't seen your comment. Gtypist did a lot for my muscle memory, yet I barely scraped the surface. It's probably time I went through the remaining tutorials.

Actually, this seems like the perfect opportunity for pharma companies to "help" in creating the database.

That's actually what they are already doing when pitching new drugs to doctors. Now they only have to convince the system designers and not thousands of practicing doctors.

Most new drugs today win on marketing, rather than efficacy. Once you have a system like watson, it's rather trivial to do the expected value calculation of "This treatment has an X% chance of working, and costs Y. The competing treatment has X'%, and costs Y'."

As long as that data is available to patients (and it should be), I'm with the parent poster, this will make it harder to pad treatments.

The customers for the software are the hospitals that people go to, not the insurance companies or the patients. I guarantee you that the hospitals will prefer whatever option results in the best possible financial outcomes for themselves.

In the end, the power is going to be with the payors, who are plenty savvy themselves, not the pharma companies.

Drugs are a relatively small part (10-15%) of the overall cost of healthcare.

My personal favorite has always been permutation sort, where you try all possible permutations of a sequence and check if it is sorted.

What's nice about it is that it is deterministic yet ridiculously slow.

It can also be really easily implemented in Prolog[1] where you simply define what a permutation and being sorted means. After that you just search for a sorted permutation.

[1] http://rosettacode.org/wiki/Sorting_algorithms/Permutation_s...

They could promote polyandry.

They could simply get a PrimeSense license. I see no reason why they wouldn't get one.

I'm admittedly not Microsoft, but if I were Microsoft, I'd pay through the nose to ensure PrimeSense keeps this stuff away from my direct competitors.

That would get them a license for the 3d sensor HW, but MS has most of the body tracking patents, as the software was developed by MS.

If the python project had something like that, the current python 3 situation could maybe have been avoided.

The python 3 situation is really the python 2.4/2.5/2.6/2.7/3 situation. I'm not sure why or how it happened, but python is brutally fragmented in the real world across OS'es, in my experience.

Python has 2to3 which is the same kind of thing

There are a lot of things 2to3 can't fix, so the user has to go back and change things by hand anyway.

That appears to be true for gofix too and probably any tool of that kind...

it's less of a problem for gofix because Go's static typing means it's easy to be much more precise about which methods and functions are actually being used.

Call me paranoid, but I don't like the idea of all my money transactions being traceable. It's less that I worry about my bank or government but about, for instance, super-market chains linking my buying-behavior to my bank account or card number.

You're not the only one. There's a sizable underground economy in this country that feels the same way about traceability. Organized crime, drug transactions, and black market goods represent an enormous amount of currency exchange. Even non-nefarious businesses like local laundromats or sidewalk vendors deal in cash with the advantage of being able to skimp on their tax reporting.

It would be interesting to see the effects on these "industries" if we were to move to a purely electronic exchange of money.

Especially in hot weather I actually prefer short-sleeved shirts to t-shirts. The tightly woven, thin fabric of a shirt does not stick as much to the body as a t-shirt. Though I have to admit, that I have never been to Australia in summer. And a suit would definitely be out of the question for me as well during the hot season. :)

"Australian summer" is a very broad term, given the size of the continent. I'm in the tropics, for example, and let me tell you: everything sticks when it's > 30C and > 70% humidity. You could make a shirt out of teflon and it would stick.

How could a program work that can detect such scam-drives? As long as we don't care about crashing the formatting, at least.

It could work by writing a specific pattern in the first few bytes of the device and then reading/writing in 2^n steps to check if the pattern cycles.

I think I have some counterfeit thumb-drives lying around. Maybe I will try writing something like that..

Select a random number known only to you(r program). Seed your generator with it. Start randomly selecting sectors to write to (directly as a block device), writing a psuedorandom sequence based on your first number and the block identifier. Store a set of what sectors you've written to. (You can bundle them into arbitrarily-large contiguous chunks if this gets too large.) As you write, periodically randomly select a sector you already wrote to and verify that when read it returns the same psuedorandom sequence. I don't just read them back in order to prevent the "save the first few chunks" attack. This will slow down detection a bit, but if I'm working my intuition math correctly it doesn't actually slow it down very much, at the gain of making it impossible for a hostile firmware to know which sectors you're going to ask for.

Using this approach, you can write arbitrarily large of data to a drive with very minimal storage requirements on your end (well within even modern-day embedded RAM availability), while still being able to demand any sector back at any moment and verifying it is correct. Theoretically your psuedorandom number generator ought to by cryptographically secure, and given that you're probably IO bound here and they aren't hard to come by, there's probably no reason to use anything less.

I'm pretty sure the only effective defense against that is to actually store all the data. If you issue a predictable read pattern, you open an attack. If linearly-sampling your previously written blocks turns out to be undesirable you could tweak the sampling distribution, but I bet you wouldn't get much improvement.

Also, come to think of it, if the drive is honest this could be done non-destructively (assuming the undo process is allowed to run to completion) by reading the sector and XOR'ing it, so you could then undo it by a second XOR operation. Further cleverness could even make this reasonably safe to half-complete the undo, then finish later, if you work at it.

It's really much simpler than that:

  cd
  head --bytes=your_card_size /dev/random > tmp
  sha1sum tmp
  cp tmp /media/your_card
  sha1sum /media/your_card/tmp

Never considered using head to get a bytestream from /dev/random. I've always used dd. Thanks for the tip!

If you are on linux, use /dev/urandom.

Since the compromised flash controller allocates the actual sectors to use, it seems like it would be difficult to make a reliable test without generating a large file and then checking it for integrity, which would take a while to run.