The real question is why a C64 emulator would require a dedicated OS instead of just running it under Linux. If you want to reduce boot time, just turn off all unnecessary features in the kernel config and put the emulator in the initrd, you should be able to have a C64 BASIC prompt in less than 3 seconds.

I'm enjoying Hearthstone as well.

Something some players may not realize is that when you're playing other humans in a ranked system, if you win half your matches, you're doing OK. You can win more if you're new or if you're improving rapidly, but then your ranking gets adjusted and you'll face tougher opponents.

It's a collectable card game, so having more cards will give you more options. If you want to be able to compete with people who have been playing for months on your first day, you'd have to spend a lot of money. But you wouldn't be able to build a good deck out of those purchased cards with so little experience, so it's a rather pointless criticism. If you play now and then for a few weeks you'll get a decent set of cards and you'll learn how to use them. And every level of rarity has good cards, you don't need a lot of rare cards to make a good deck.

Reading the forum posts about Gelbin Mekkatorque (a promo card given to people who purchased something during beta) was hilarious. Some people complained that handing out a promo card like that was pay2win. Others complained that the card was seriously underpowered and they felt ripped off. So in the end it shows that you simply cannot make everyone happy. (In my opinion, the card is way too random to be used in a competitive deck, but it is quite funny.)

Now that it's been in the news, it might become a trend...

As far as I know, ISPs were forced to implement the data retention. For them, even if they aren't opposed to it on privacy grounds, it's additional infrastructure costs that they would rather get rid of.

Another possible strategy for the opponent is to play the first round with each move at 1/3 chance. That leads to an expected win of 0 for the first round. For the second round, if he played rock in the first round he has no obligations and gets an expected win of 0 again, but if he didn't play rock (2/3 chance) he'll be forced to play rock and lose, so an expected win of -2/3 for the two rounds.

In fact, any opponent first round strategy with scissors 1/3 and rock between 1/3 and 2/3 will lead to an expected win of -2/3 for the opponent (by the player always playing paper on the first round).

Yes, that's what I meant. I originally though the stronger claim might be true but it is not: as Reaper9889 pointed out in another post, you should never play scissors. If you stick to that and are not so greedy to play 100% paper (to be exact: 1/2 < paper < 1, optimum at 2/3), you make a profit no matter how the opponent responds.

You're right about never playing scissors. Since the perfect opponent will know you're never going to play scissors, he won't play rock any more than is required, so 50% of the time. This leads to an overall win frequency (profit) of (1 - 3 * Rp) * Po + Rp / 2, where Rp is how often you play rock and Po how often the opponent plays paper.

With 1/3 rock, the profit becomes 1/6 no matter what the opponent does. If you play less than 1/3 rock, Po is positive for your profit, so the opponent will opt to never play paper: 1/2 rock and 1/2 scissors, leading to a Rp / 2 profit, which is less than 1/6. If you play more than 1/3 rock, Po is negative for your profit, so the opponent will play as much paper as possible: 1/2 rock and 1/2 paper, leading to 1/2 - Rp in profit, which is again less than 1/6.

If you're playing 2/3 paper and 1/3 rock vs 1/2 rock and 1/2 paper, the regular RPS subgame is 2/3 paper and 1/3 rock vs paper, which has an expected result of 1/3 loss for the subgame, or a 1/6 loss contribution to the total game. It won't cancel out: you can't get a consistent 0 result from the regular RPS subgame since you play paper more than 1/3 of the time and the opponent can take that into account by not playing rock in the subgame at all.

Versus 2/3 paper and 1/3 rock, it actually doesn't matter in which frequency the opponent plays paper and scissors, the result is always 1/6 overall win for you, assuming the opponent never voluntarily plays more than 1/2 rock.

I listed the chances in the context of the opponent move ("if the opponent plays rock"). The chance of playing rock or playing scissors is 1/2 each (the coin toss), so if you list it as overall chances you get 1/3 win and 1/12 loss (same as you wrote) due to the opponent playing scissors and also 1/3 loss and 1/12 win due to the opponent playing rock; the expected result result is still 0.

The opponent could respond to this by playing scissors on all non-forced-rock turns. If the opponent plays rock, you win 4/6 of the time and lose 1/6 of the time, but if the opponent plays scissors you lose 4/6 of the time and win 1/6 of the time, so overall you'd be even.

First, make sure you read TFA, since it explains what the summary doesn't: how the 50% is determined and how the opponent can play in the non-forced turns.

If you play using a deterministic algorithm, for example always play paper, the opponent can figure it out and beat you on all the non-forced turns. At best you'll get an even result.

If you play using a random algorithm, the opponent can figure out the frequencies you're using and compensate for that. For example, if you decide to play paper 50% of the time and rock and scissors 25% of the time, you'd win against an opponent playing rock 50% of the time and paper and scissors 25% of the time. However, if the opponent decides to play rock 50% of the time and scissors the other 50%, the result is even again. If the opponent would be forced to play rock more than 50% of the time, there is no room to compensate and you would win consistently with 100% paper. I think that with 50% rock, there is enough room to respond to any frequency distribution you can come up with, although I have no proof for that.

You could change your algorithms during play, but if there isn't any algorithm that results in an advantage when playing it consistently, gaining an advantage from changing your algorithm would depend on how well your opponent responds to your changes. In other words, you're playing mind games. I don't think the 50% rock restriction is going to be of any help here.

The summary says the replication slaves are now crash free, but TFA says they are crash-safe. My database knowledge doesn't go very deep, but I think the latter means they won't lose data on crashes, not that they never crash.

A Ren'Py story does need graphics to shine. A possible alternative if you want to create a text-based interactive story is Twine. The editor (1.4 series) is written in wxPython, stories are created using wiki syntax and optionally CSS and JavaScript. It packages stories as HTML files for playing.

Code quality in the Linux kernel varies a lot per individual driver or subsystem. Many interfaces are under-documented: you have to read the implementation code and make an educated guess at what the intended interface was. And a lot of the error handling paths contain bugs, since those are rarely exercised when testing manually.

The Linux kernel might seem elegant if you just read the code superficially. Once you start making changes and have to know exactly how it works, you'll see the problems that many parts of the kernel code have. While there is certainly a lot worse code out there, I wouldn't use the kernel as a shining example of elegant code.

There is one thing I learned from the Linux coding style though: avoiding typedefs and just writing "struct blah" in full helps make code accessible to new readers: the less indirections, the sooner you find what you're looking for. The same thing holds for avoiding typedef aliases for integer types and using macros sparingly.

The door lock analogy works best, I think: if there is something really valuable in the house, a door lock won't stop a thief, but for an average house a good lock could make it not worth the effort. Likewise, if my government (the Netherlands has a population of almost 17 million) can afford to spy on a thousand people, I won't be among them, but if they can afford to spy on a million people, I might be. So if you want privacy, make sure mass spying does not become too easy.