Why would they do this though? Why wouldn't a gene for 'cheating' (e.g. not slowing down when you reach the front) to avoid danger be favoured by natural selection? Animals with complex social structures (like us) avoid this by evolving to identify and punish cheaters, but there must be some other mechanism in these fish?
If you don’t slow down when you get to the front, you’ll end up separated from the school and more vulnerable to attack. Likewise if you don’t match the school’s speed when you’re at the back.
Staying in the middle would be advantageous, but when the whole school is cycling slowly, that’s tricky to do. The cheating behavior would need to be a little more complex so that’s an obstacle to its evolution.
Additionally, the more cheaters there are, the slower the school will move overall, which harms everybody (including the cheaters) so that limits the spread of cheating somewhat.
Overall, I’d guess that cheating could evolve, but only in a careful balance with the normal behavior. If the cheating starts to get significantly more complex, policing methods would co-evolve with it.
Interesting. So maybe it is an evolutionarily stable strategy, if you assume it's too hard for the fish to keep track globally of where they are in the shoal (and are therefore limited to strategies where they only react to what's immediately around them). It would be fun to simulate this and see if there are any other strategies that offer an advantage.
Because then you evolve societies that spend so much time fighting each other for marginal increases in individual safety that the benefit of working together is lost.
To be clear, though, there's no evolutionary function that optimizes for the overall benefit of unrelated individuals. So-called group selection has never been shown to exist in nature.
Cheating is moderated by the success rate of cheaters and non-cheaters individually. If cheating strategies come easy but counter-cheating strategies difficult, then the species success in the larger ecosystem will indeed be limited in as much as organized, goal-oriented behavior is beneficial. There's no group-wide selective pressure to favor the non-cheaters over cheaters as there's no group-wide inheritance mechanism that can accomplish that.
It's why schools of fish aren't as efficient as one might naively think they could be at evading, e.g., a giant whale. The cheaters can and do drag down the whole group because the equilibrium rate of cheaters in the school isn't responsive to the success rate of schools as a whole.
You're probably right - although saying the accusations are "nonsense, utterly ridiculous and should be ignored" isn't strictly speaking the same as saying that they're untrue. GCHQ could believe that (although they happen to be true) it's nonsense and utterly ridiculous for commentators to be asserting so without any evidence, and it would be much better for everyone to ignore the accusation.
I'm British, we don't like to overstate things. When you see GCHQ call something "nonsense" and "utterly ridiculous" you can be assured that they are denying it.
And I think there's something more. I would read into their statement that they are very angry.
It's funny how you, me and louthy (in a sibling comment) all read into this "You are a total buffoon (or similar words)". I can imagine someone sitting in Cheltenham just shaking their head.
> although saying the accusations are "nonsense, utterly ridiculous and should be ignored" isn't strictly speaking the same as saying that they're untrue.
I would think that "nonsense" implies "untrue". I.e. it is "The subset of untruths that also are logically inconsistent"
We are splitting hairs of the fine parsing of the wording from GCHQ, when words of any kind are highly unusual.
Question from someone who doesn't know much about this: is it possible to know that there is a genuine market in these MtGox bitcoins i.e. that $350 is a genuine market price and not just something made up by the exchange to conceal a complete collapse in value?
I suppose Gox could be buying up all the goxcoins less than $300. But then you'd see a decrease in future volume until the volume reaches zero. They wouldn't do that, because they're not smart enough to pull it off without anyone noticing.
So if hypothetically Gox was the only buyer for bitcoins trapped in Gox, would they be buying them with real USD, or with 'trapped in Gox' USD that may or may not turn out to have any value?
Currently (I'm in London UK) Minecraft has a huge folllowing among boys aged (roughly) 8-14. As long as that demographic remains obsessed there'll be a constant new market.
My 8yo son is obsessed, as are two of his friends.
I am really impressed that a system with simple graphics has been so successful. A more traditional games shop would have screwed it up by trying to make things look pretty.
[Java still remains a poor gaming platform. I had to fiddle with the VM settings for a while before it would even run.]
I have a question for you if you've got a moment: what part of Minecraft is your son most involved in (eg: playing with his friends, creating modifications, building cool things alone)? And if he's involving in playing online, do you know if he has any involve with Minecraft communities?
I'm getting the feeling more and more recently that Minecraft may eventually become what BBSes were to the 90s: a way for "new" to the internet people to get involved in the community side of the internet (vs. just being a "consumer") and by extension the technical side. We (the Minecraft forum) have 10s of thousands of teenagers that are now programmers contributing code and creating things just because of Minecraft, people that probably wouldn't have got involved in programming this early in life otherwise.
I'm curious if that sort of effect extends beyond those actively involved in the official Minecraft communities, but I have no real way to find out as my reach only covers the Minecraft forum.
My 8yo son, 11yo daughter, 10yo niece, and 14yo nephew all recently got into it. I set up a server for them.
My nephew I think might become an architect, he loves making real-world looking buildings, complete with furniture, rooms, bathrooms.
The daughter and niece make houses where they live with each other. My daughter in particular takes her room, and adds a panic room (for when the mobs attack).
And my son has recently taken to building redstone gadgets. He took a room and put a switch on the wall, then ran redstone on the outside up to the attic to power glowstone blocks that he recessed into the ceiling. That way he can turn the lights on and off.
They mostly use the tekkit mod, and I've been trying to get them into programming by showing the how the computercraft turtles work ... it's a work in progress :P
I think Minecraft as a programming teaching tool would be a whole lot more valuable with a proper API and hopefully that will be introduced before the game starts to fizzle. It would be one less barrier to entry for kids, as currently they have to learn Java and get thrown into a messy (deobfuscated) codebase. Not exactly the best first experience with programming.
I think Valve's Portal 2 map maker is another good example. They give you a really nice interface for the easier stuff, and then for advanced changes you can import it into Hammer.
Sorry, just noticed your query. He plays alone - I've asked him if he's interested in the multiplayer aspects, but he just likes building things like automated mines, and watching replay movies on YouTube.
I think "how many golf balls can you get in a double decker bus" is a fair question for assessing whether someone can apply basic maths to a to a real life (i.e. not perfectly defined) problem. If that's a skill the job needs it's a perfectly reasonable question.
I also think it's a fair question, but more about logical reasoning and estimating than basic maths. As an engineer, you could be asked to estimate the number of load balancers needed for X traffic with Y latency - similar problem.
In my experience of those kinds of problems the catch is finding realistic values for X and Y - often nobody is going to hand them to you on a plate and you must work out a way of estimating them - that is the real skill.
This makes me worried about hash collisions as well. The article implies that a file whose hash matches something they already have will never even reach their servers - so presumably I just have to keep my fingers crossed that the file they're synchronising to all my machines is the one I uploaded, and not some other user's completely different file that happens to have the same hash?
SHA256, which Dropbox uses, has around 10^77 possible hashes. That's 100 trillion quadrillion quadrillion quadrillion quadrillion possible values. So I wouldn't worry about hash collisions if I were you. If a hash collision happened easily in SHA256, that would be very big news for the security community, and much more serious services than Dropbox would be affected.
This is a common sentiment, but not really sensible. If you want to store (for example) another 64 bits worth of information, you would always be better off with 64 more bits of some strong hash than 64 bits of filesize.
...and if you took the same number of bits you were using to store the filesize, and instead stored that many bits of some independent secure hash, it'd be harder still.
Of course every extra bit that has to be matched makes collisions 'harder' but length bits are much weaker than other options, except insofar as they may already be available for other reasons.
And that was written before the md5 collisions were discovered. And no collision has yet been discovered for md5 for files of the same length, they are all extension attacks...
Absolutely false. Some MD5 collision-generators specifically find pairs of equally-lengthed inputs with the same hash. See for example hit #2 for [MD5 collisions]:
'Extension attacks' are something else, which let you turn one collision into more, or create valid hashes for combinations of unknown text plus a chosen extension – not find an initial collision. See:
The 'length extension' property can be helpful, once you find a collision based on 'random' nonsense, in extending that into two documents that are each meaningful-but-different and still colliding, as was done in this 2005 MD5 collision demonstration:
But still possible. Whenever the number of bits in a file is more than the number of bits in a hash, there are collisions. They could use the Chinese Remainder Theorem, but that would only go so far (maybe far enough to remove substantial doubt? The link below seems to suggest so.)
At first, that was what I thought the flaw would be -- providing a file that has a hash that collides with another file, gets you that file.
But it seems to me you would need to know the exact contents of the file in question to get that to happen, making the point moot. Perhaps I'm wrong on that.
> What are the odds of a hash collision + identical filesize?
If implemented correctly, the additional constraint on filesize being the same is irrelevant. Given one particular hash value, the probability that a second file hashes to the same value is 1/(range of hash function) if the hash function is modeled as an ideal hash function.
Given that they do chunks of updates, rather than the whole file, presumably they check multiple hashes to ensure this doesn't happen. I could be wrong, though.
This makes no sense to me. If it's really possible to "resell these domains for considerable profit" then why aren't you doing it yourself? Or, if it's not, then surely you're just preying on the greed and gullibility of those who sign up?
I am an experienced domainer and am able to acquire new quality domains on a regular basis. I'm also very busy with manging the publication, DotSauce magazine and other projects.
I wish I could sell domains full time, but I have other commitments. It takes time to market and promote domains and sales don't exactly happen over night.
There are sample domains shown on the signup page. I think it's fairly obvious good keywords and brands are worth more than $19. It's not so far fetched to think someone could resell for much more.
