If you don't read the book until you have lots of experience, you will probably have reinvented most patterns, but using different names for them which will only confuse other people reading your code. Overuse of design patterns may be a necessary developmental phase;)
By the way, while it is in the GoF book, I'd argue that Singleton is actually an anti-pattern.
Analog broadcast radio would be relatively easy to pick up on a faraway planet and identify as a signal. But how much longer will we be using that? If all communication is compressed and/or encrypted digital point-to-point, if something leaks into space at all it will look like a weak noise. I think that if the radio search picks something up, it would be because an alien civilization is deliberately sending out a signal to be noticed, not because we picked up their normal means of communication.
I don't think asymmetric bandwidth is the problem: even with user-generated content, there will be more downloads than uploads: you post on a forum, multiple people read it, you share a photo, multiple people see it. Unless you advocate everyone to run home servers or a massive switch from client-server to peer-to-peer, having asymmetric bandwidth is not a bad idea.
One problem is that the big ISPs don't want to be in the business of moving network packets; they want to be in the content business, because they see more potential profit there. They see the internet as a way of delivering that content: like you said, as a broadcast medium.
Another problem is closed services. For example, every social network has their own private/instance message system, instead of using standard protocols like IMAP and XMPP. This means you have to use the same service as your friends to be able to communicate with them. So even for non-broadcast use, power is becoming concentrated. The internet is moving further and further away from its decentralized roots.
If you pay attention to recent events, you'll see what happens in practice:
Netflix subscribers complain high resolution streams don't play well.
Comcast refuses to do anything about that problem unless they're paid by Netflix.
After some protest, Netflix caves in and pays Comcast.
Soon after, high resolution streams play fine.
Netflix announces they will raise their subscription rates.
So in the end, Netflix subscribers end up paying more and Comcast receives more money.
And switching from Netflix to a smaller content provider has the problem that "smaller" doesn't just mean they have fewer subscribers, it means they have fewer content to choose from as well.
How much of the total plant bio-mass are you processing to start with when you are dealing with corn? 2%? 3%?
This research was about making biofuel from cellulose, which means that stems, leaves etc are used as well. But apparently even that is not sustainable because corn takes a lot of its carbon from the soil instead of from the air.
The main VAT rate went up from 17.5% to 21% iirc, but food falls under a special VAT rate of 6% that has stayed at the same level afaik. There is a new "packaging tax" which was supposedly introduced to discourage unnecessary packaging material, but I don't think it actually changed anything except the price.
We had something like 5% inflation for several years in a row around 2000. Many people blame this price increase on the switch to the Euro in 2002, but there were significant price increases in the years before that as well. I don't know the reasons behind those increases. In the years after, we had a "supermarket war" where the supermarkets lowered their prices one after another to attract more customers, which has reduced their profit margins significantly. So that's probably not where the high cost is either.
Even so, there are plenty of tasty dishes you can make from cheap ingredients like carrots, onions and cabbage. Meat is the most expensive ingredient, but you need hardly any meat at all from a nutricional point of view (provided you get sufficient proteins from other sources), so if we're talking about starving students then meat is optional.
Food is not that expensive in Europe, if you buy in-season vegetables and cook them yourself. Driving a car is expensive, but in many countries you can get by without a car. Typically people get their first car when they get their first full-time job. If you're studying in Europe, drive a car and don't have enough money to eat properly, I'd say you made the wrong budget choices.
When I was a student (in the Netherlands in the late 90's), housing was the largest expense. Second was the tuition costs. Food was third, but a lot below housing and tuition. Books were expensive a piece, but fortunately our university didn't require a lot of books to be bought: they tried to use books efficiently (only require a book if a lot of chapters were used; use the same book for multiple courses if possible) and offered a lot of their own material at duplication price (about 1/5th to 1/10th the price of an academic book). Looking at my bookshelf I count 14 books from my studies and I think I sold one, so 15 books for a master's degree.
The problem with SC2 is that it is actually a sport: if you don't practice regularly, your performance drops a lot. You can have a great strategy, but if you get supply blocked in the first 5 minutes because of an execution flaw or you neglect your base when you're attacking the opponent mid-game, the strategy may not matter. I play the game from time to time, but in bursts of a few weeks of playing several times a week followed by months of not playing at all.
Another factor that makes the game less attractive to players over 30 is that it is quite intense: you need to keep focused throughout the entire match. It is probably not the most attractive choice of game after you come back home from a day at the office. It is also not something you can play just before going to bed.
Give a discount on a digital download. Generate unique discount codes (random numbers) and allow each number to be used only once by keeping track of which numbers have been used.
Alternatively, accept the fact that the code will be shared and make it a small discount and/or only valid on launch day, to stimulate impulse buys. People will feel they got a good deal by outsmarting your system, while it was calculated from the start.
The computer lab in my primary school ran on C64s and I own a working MSX (home computer from the same era as the C64). I know how fast they boot. I haven't booted a Raspberry Pi yet, but I have run and built several embedded Linux systems. I'm sure booting Raspbian into X11 will take a while, but if you build a dedicated image for running a single emulator it could boot very quickly.
I'm not comparing a full XFCE/X11/GNU/Linux stack to a dedicated emulation OS, I'm comparing the Linux kernel plus a boot script to a dedicated emulation OS. Sure a dedicated OS could be more efficient, but then you'd want support for HDMI, composite video, audio, SD card, file systems, USB mass storage, USB keyboards and game controllers etc. and when all that is implemented and working reliably you've spent at least months and probably years in development. That's a lot of effort to go from a 3 second boot time to 500 ms. And then you find out that the real limit to boot time is how long it takes for your TV to switch to the right HDMI input...
Besides, you could cheat: screenshot the C64 title screen and display that as a splash screen. That's what iOS apps do to make it feel as if they launch instantly. Then run the first second or so of emulation in fast forward mode to compensate for the time the kernel took to initialize.
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.
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.)
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.
This is where the two games key comes in. You and I both recognize that 2/3 paper is the right move because 1/2 of his moves will be rock. But by playing the other half as regular RPS with a win/tie/loss of 1/1/1 you can expect the win/loss to cancel out, leaving you with your 1/3 lower bound advantage
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.
Slashdot Mirror
If you don't read the book until you have lots of experience, you will probably have reinvented most patterns, but using different names for them which will only confuse other people reading your code. Overuse of design patterns may be a necessary developmental phase ;)
By the way, while it is in the GoF book, I'd argue that Singleton is actually an anti-pattern.
Analog broadcast radio would be relatively easy to pick up on a faraway planet and identify as a signal. But how much longer will we be using that? If all communication is compressed and/or encrypted digital point-to-point, if something leaks into space at all it will look like a weak noise. I think that if the radio search picks something up, it would be because an alien civilization is deliberately sending out a signal to be noticed, not because we picked up their normal means of communication.
I don't think asymmetric bandwidth is the problem: even with user-generated content, there will be more downloads than uploads: you post on a forum, multiple people read it, you share a photo, multiple people see it. Unless you advocate everyone to run home servers or a massive switch from client-server to peer-to-peer, having asymmetric bandwidth is not a bad idea.
One problem is that the big ISPs don't want to be in the business of moving network packets; they want to be in the content business, because they see more potential profit there. They see the internet as a way of delivering that content: like you said, as a broadcast medium.
Another problem is closed services. For example, every social network has their own private/instance message system, instead of using standard protocols like IMAP and XMPP. This means you have to use the same service as your friends to be able to communicate with them. So even for non-broadcast use, power is becoming concentrated. The internet is moving further and further away from its decentralized roots.
If you pay attention to recent events, you'll see what happens in practice:
So in the end, Netflix subscribers end up paying more and Comcast receives more money.
And switching from Netflix to a smaller content provider has the problem that "smaller" doesn't just mean they have fewer subscribers, it means they have fewer content to choose from as well.
How much of the total plant bio-mass are you processing to start with when you are dealing with corn? 2%? 3%?
This research was about making biofuel from cellulose, which means that stems, leaves etc are used as well. But apparently even that is not sustainable because corn takes a lot of its carbon from the soil instead of from the air.
The main VAT rate went up from 17.5% to 21% iirc, but food falls under a special VAT rate of 6% that has stayed at the same level afaik. There is a new "packaging tax" which was supposedly introduced to discourage unnecessary packaging material, but I don't think it actually changed anything except the price.
We had something like 5% inflation for several years in a row around 2000. Many people blame this price increase on the switch to the Euro in 2002, but there were significant price increases in the years before that as well. I don't know the reasons behind those increases. In the years after, we had a "supermarket war" where the supermarkets lowered their prices one after another to attract more customers, which has reduced their profit margins significantly. So that's probably not where the high cost is either.
Even so, there are plenty of tasty dishes you can make from cheap ingredients like carrots, onions and cabbage. Meat is the most expensive ingredient, but you need hardly any meat at all from a nutricional point of view (provided you get sufficient proteins from other sources), so if we're talking about starving students then meat is optional.
Food is not that expensive in Europe, if you buy in-season vegetables and cook them yourself. Driving a car is expensive, but in many countries you can get by without a car. Typically people get their first car when they get their first full-time job. If you're studying in Europe, drive a car and don't have enough money to eat properly, I'd say you made the wrong budget choices.
When I was a student (in the Netherlands in the late 90's), housing was the largest expense. Second was the tuition costs. Food was third, but a lot below housing and tuition. Books were expensive a piece, but fortunately our university didn't require a lot of books to be bought: they tried to use books efficiently (only require a book if a lot of chapters were used; use the same book for multiple courses if possible) and offered a lot of their own material at duplication price (about 1/5th to 1/10th the price of an academic book). Looking at my bookshelf I count 14 books from my studies and I think I sold one, so 15 books for a master's degree.
The problem with SC2 is that it is actually a sport: if you don't practice regularly, your performance drops a lot. You can have a great strategy, but if you get supply blocked in the first 5 minutes because of an execution flaw or you neglect your base when you're attacking the opponent mid-game, the strategy may not matter. I play the game from time to time, but in bursts of a few weeks of playing several times a week followed by months of not playing at all.
Another factor that makes the game less attractive to players over 30 is that it is quite intense: you need to keep focused throughout the entire match. It is probably not the most attractive choice of game after you come back home from a day at the office. It is also not something you can play just before going to bed.
Give a discount on a digital download. Generate unique discount codes (random numbers) and allow each number to be used only once by keeping track of which numbers have been used.
Alternatively, accept the fact that the code will be shared and make it a small discount and/or only valid on launch day, to stimulate impulse buys. People will feel they got a good deal by outsmarting your system, while it was calculated from the start.
The computer lab in my primary school ran on C64s and I own a working MSX (home computer from the same era as the C64). I know how fast they boot. I haven't booted a Raspberry Pi yet, but I have run and built several embedded Linux systems. I'm sure booting Raspbian into X11 will take a while, but if you build a dedicated image for running a single emulator it could boot very quickly.
I'm not comparing a full XFCE/X11/GNU/Linux stack to a dedicated emulation OS, I'm comparing the Linux kernel plus a boot script to a dedicated emulation OS. Sure a dedicated OS could be more efficient, but then you'd want support for HDMI, composite video, audio, SD card, file systems, USB mass storage, USB keyboards and game controllers etc. and when all that is implemented and working reliably you've spent at least months and probably years in development. That's a lot of effort to go from a 3 second boot time to 500 ms. And then you find out that the real limit to boot time is how long it takes for your TV to switch to the right HDMI input...
Besides, you could cheat: screenshot the C64 title screen and display that as a splash screen. That's what iOS apps do to make it feel as if they launch instantly. Then run the first second or so of emulation in fast forward mode to compensate for the time the kernel took to initialize.
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.
This is where the two games key comes in. You and I both recognize that 2/3 paper is the right move because 1/2 of his moves will be rock. But by playing the other half as regular RPS with a win/tie/loss of 1/1/1 you can expect the win/loss to cancel out, leaving you with your 1/3 lower bound advantage
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.