The opponent is forced to pick 50% rock, but he has no limitations other than that. If you went 100% paper, you'd not beat me playing 50% rock by more than a tiny sliver of a percent it takes me to realize you are going 50% paper.

And the problem has nothing to do with the someone not just picking rock, but doing so in a very predictable manner. Otherwise, we'd not be talking about someone picking rock 50% of the time, but playing against someone that plays randomly, but tells you what he is picking half the time, never lying. That's a very, very boring brainteaser.

The first naive approach that doesn't assume idiocy on the other side's part is to assume he'll try to guess our play. If we play in a non deterministic fashion, his best options is probably random, but instead of .33/.33/.33, we get .50/.25/.25. Against an opponent doing that, you could go .25/.50/.25, and win quite a bit.

If he is forced to get at least 50% rock after a certain number of plays, then we can change our probabilities depending on how far from the standard distribution our opponent is: For instance, if we were playing to 10 throws, and he never picked rock in the first 5, we'd get him in the last 5, because his moves are forced. To avoid this, someone that has to reach that 50% will probably also change their probabilities after every throw, just to avoid such a 'free' run. One might even consider starting with an over 50% rock probability, because under that set of rules, having overplayed rock lets us play more optimally later, while underplaying rock leads to major losses.

Either way, a more detailed problem specification is required.

This is more easily handled in Mercurial's queues system. You can keep a bunch of patches in a queue like that, and those patches will just be magically applied. It's pretty useful for a whole lot of situations.

The main practical difference, past the API, is their approach to branching: A git branch is a mercurial bookmark. There are no concept like mercurial's branch in git. There's also how git has this crazy staging area that is the cause of 90% of bad commits to our git repos. Commits that are missing a file, or have an extra file, are the bane of SVN and Git repos. In hg, the expected behavior is commit everything that is not in a patch. More discipline required, less chances of shooting yourself in the foot.

As far as the interface goes, other than the well known stuff, there's the fact that default behaviors seem to be all built around pulls, not pushes, so if your typical corporate environment, where pulls are often nonsense, people get very confused when 'natural' behaviors tell them that the files that changed from a merge are the files from the upstream, that they did not edit, and things like that. To minimize it, I keep telling people to avoid git pull like the plague, and instead use git fetch, followed by git rebase as the baseline case.

Either way, both are pretty useful, and beat SVN in almost all use cases. I just think that it's easier to teach people hg than telling people to learn a bunch about git internals before they can contribute properly.

It might motivate you, but not to actually be better: Many things that make you better will be tracked to the team, not to you, and a good team still has to have a poor performer. So stack ranking motivates people to make sure some people are behind you, and to make sure that your manager actually likes you, instead of making your product better. Creating conflict for the good of the application is not great idea in a stack ranking organization, because it'll make the manager work harder, and thus not endear it to him.

I remember the last time I was in a stack ranking org. Our team was way too good: A few developers were quite a bit better at their jobs than the manager even understood. Who was getting the good review? A guy that was pretty darned average, code-wise, but that played D&D with the manager. I at least managed to avoid being called the 'bad one', but it was pretty clear that there was very little future in that kind of organization unless you managed to surround yourself by relatively bad developers.

Decisions on running a company are often a whole lot like investing in stocks: You only know if a decision is good or not way after you make it, and the reason why the decision was sound probably had very little to do with the reasoning you had at the time. This makes it extremely easy for people to think they are geniuses, when in reality, all they are is very lucky. Having picked stocks well for a few years, or having led a corporation that became huge, does not mean that your future decisions in that realm will continue to be any good.

But it doesn't matter: Imagine an unbreakable crypto: If you enter the right password, you are in. If you do not have it, infinite computer resources won't help you. Well, that environment is still an extremely dangerous environment for non-reversible transactions that cannot be manipulated by an authority, because most attacks on computer security work regardless of how good a cypher you use.

If you are attacking anything large, you just attack the keys. With no central authority, there is no way to recover keys, or ask for keys to be changed. Therefore, key management itself will be weakened due to how catastrophic it is to lose the keys. The harder you make it to lose all your bitcoins, the easier you make it to attack your keys.

So putting all the trust in the platform's security is like saying that a house is safe because you installed the best door money can buy. But there's still windows, and walls, and a roof, and a basement... Make them all perfectly secure, and you can't get into the house itself.

Yep, it's called refuge. And that's why you will find, today, that the recommendation is to do exactly as you say. You'll even find Monsanto, BASF and Pioneer telling you to do that, and even selling the seeds for both. If you find a farmer that doesn't know that, he's not paying attention.

Now, good luck finding people that know this unless they have farmers or agronomists in the family.

JavaFX is still rather component poor, just like Swing was. It's ultimately Swing's biggest problem IMO: To do anything even mildly interesting, you have to build your own components, or do major extensions on the base ones. How much pain have people inflicted on themselves extending JTable? And no mention of the layout manager mess, only solved by third parties, back when Swing was already considered semi-dead: I'd trade every single layout option built into JavaFX for MigLayout.

Not really. We had Macho Man Randy Savage. He was both noble and a Savage. When Q'uq'umatz was going to destroy the world, at the end of the Mayan Calendar, Macho gave his life to wrestle the world away from the grip of the great creator snake. What can be nobler than that?

Well, it's just as illegal to download an episode than is 1 year old, than it is to download one that is 50 years old. If the punishment is the same, why wouldn't you download the latest stuff?

He'd be voicing the concern no matter what, because he believes he is better served by infinite copyright.

It's not an uncommon belief. If the code is well factored, and has a good narrative, comments can actually be harmful. This is because comments have a very major problem: They can be updated, and are often updated, at a different time the code does. So it's not rare to find comments that are downright deceitful: They don't say what the code does: But what the code used to do, years ago, before the system worked. So making the code agree with the comments will break the app.

We have the same problem with most specifications: They are instantly out of date.

So what do we do? We want something that helps us explain what the code does, and yet cannot deceive us on whether it's true or not. We call those executable specifications and unit tests. If the tests don't pass, they don't reflect reality, and we have to figure out which one is right. If the Executable specs stopped running, then we know what broke them.

So I'd leave comments down to situations where I am stuck doing a level of language trickery that I do not expect my average reader to understand, but that I cannot actually avoid. So maybe a comment on a performance optimization, or on some crazy type conversion trickery in Scala. But every time I feel like commenting is necessary, I know my code is doing something I am not happy about.

Or if you have it on a hot wallet, and your computer is infected by a trojan. Or you have it all stored in a medium that fails. Or if you use it to buy something, and that something never arrives. Or you give it to non-shady people to hold if for you, and they are big enough to be a target for hackers.

So it's all good as long as computers don't lose data, and the entire meatspace around computer security has no flaws. Good luck with that.

User Friendly feels extremely dated now, but that's not because it was a bad comic back then, but because it was trying to capture the geek mindset of the time. It's a bit like Dilbert, a comic that only really makes sense when you've spent enough time in a megacorp's big cubicle farm. The main difference is that User Friendly came from an upbeat world that, frankly, does not exist anymore, so today it just can't be funny.

It was more than just sensical: They were using it to locate a server that was vulnerable to a real exploit for a real exploit for a real(if old) version of SSH1:

http://nmap.org/movies/

It's always disappointing when terrible movies mix total nonsense with very real information, as it raises expectations too much. Other examples of somewhat correct lingo mixed with nonsense is the scene in Hackers where they go through real books that actual hackers from way back then would find useful. But even if I bring my old college book on compiler design to work, risk getting called into Human Resources by riding on a skateboard through the building, and telling everyone that we should start hacking the Gibson, it'd still not make any of my female coworkers actually look like Angelina Jolie.

All those movies, full of lies.

Did you read the entire post? Do a software update, and you still need the blocks to be sent and received. And while all clients do not need the entire blockchain, while you still have a single one, you will have problems. In architectural terms, a blockchain behaves like a single, tightly synchronized queue. There are good reasons for doing that: It's not as if the people designing the system are incompetent. However, the design decisions that make sure that no coin is spent twice make scaling very inefficient. Any cryptocurrency that still retains the same properties as Bitcoin will be prohibitively expensive to run, in both power and bandwidth.

We have transaction systems that support the necessary loads: They are useful in many Big Data applications. But to achieve linear scaling, we make sacrifices that would be unacceptable for bitcoin. Even the best solutions out there, which would soften things to guaranteeing ordering for each specific wallet, would only produce moderate improvements over the blockchain: They still would not be able to handle the transaction numbers we'd need.