"In short, a timing attack uses statistical analysis of how long it takes your application to do something in order to learn something about the data it’s operating on" -- great read.. my mind is blown for today...
Between the firms fighting its zero-sum. Everyone spends a lot of money acquiring a large patent portfolio for defense. No one wins or loses. But overall it is a misallocation of capital. All that money and human resources could be spent on further innovation.
Zero-sum means that the payoff matrix in any outcome, across all players, sums to zero. Between the firms fighting, assuming that they are in fact just buying patents for defense, the sum across all players is profoundly negative.
If you define the payoff matrix as: [I win = 1, I loose = -1], then you'll have a zero-sum game.
The problem here is that this kind of mechanics can suck up unlimited amounts of money for little absolute value, as you're paying for the relative - to just get better than your opponent. It's the same problem as with political campaigns - a ridiculously huge waste of resources with no theoretical upper bound, just to influence how people choose between few available options.
I don't follow the first bit. The second is absolutely true - many sorts of arms races follow a similar pattern, where the marginal cost of beating out your rivals may be less than the marginal gain, but the total cost you're collectively paying winds up enormous.
"Now, here, you see, it takes all the running you can do, to keep in the same place. If you want to get somewhere else, you must run at least twice as fast as that!"
It is still a loss, because you are spending capital on patents you should be spending on innovation. It is a complete black hole of investment because nothing positive comes out of software patents, in the end they just feed lawyers, who are producing no benefit to society as a result of it.
It is the same reasoning why paying people to dig holes and fill them in isn't actually economically stimulating. If the fruits of labors expended serve no practical purpose, they are an effective money sink that slows down the economy.
Regarding the first part, that is very much true for money spent litigating patents. It is not necessarily the case for money spent to purchase patents, which in theory is going (directly or indirectly) to people who are innovating (assuming the patents are actually innovative and useful).
> money spent to purchase patents, which in theory is going (directly or indirectly) to people who are innovating (assuming the patents are actually innovative and useful).
unfortunately, the patents purchased are not likely to be useful (in the sense that the creation of that patent brought value), and i think this is especially true in software patents. I say so because i expect that those patents purchased are already used by various software engineers (probably unknowingly). The creation of those patents did not add value, due to the fact that no creative forces were involved.
In a real arms race, the race to produce weapons might induce economic activity because metal needs mining, manufacturing and jobs. This does stimulate the economy, and you can construe that theres some benefit to be had.
For software patents, it does not stimulate anything! Perhaps lawyers who gets paid drafting it, but actual creative output isn't there, and so it is a net drain to even create the patent.
"[U]nfortunately, the patents purchased are not likely to be useful (in the sense that the creation of that patent brought value), and i think this is especially true in software patents."
That may very well be the case; I was clarifying the incompleteness of the argument, not advocating software patents.
"In a real arms race, the race to produce weapons might induce economic activity because metal needs mining, manufacturing and jobs. This does stimulate the economy, and you can construe that theres some benefit to be had.
"For software patents, it does not stimulate anything! Perhaps lawyers who gets paid drafting it, but actual creative output isn't there, and so it is a net drain to even create the patent."
Please explain the difference between paying a lawyer to write a patent that adds nothing, and paying someone to dug up and manufacture a bullet that sits in a chest somewhere, serving as a deterrent.
Two things I can see are 1) the people being paid to mine and machine are probably less well off than the lawyer, so there may be an (arguably) helpful redistributive effect; 2) mines and machine shops have huge fixed cost - having invested that, other tasks may be able to piggyback. I am slightly hesitant in concluding 2 - while the effect itself seems reasonable, I may simply be unaware of useful infrastructure supporting the patent process. Is there something additional that I am missing?
I hate to be so negative but I have to agree. I know many people (including myself) who've already written libraries similar to Meteor (derby comes to mind).
This is ridiculous. Meteor hasn't even gotten any real adoption and it has no business model. Why create a business when you can just get investment on promises alone?
Meteor works a lot like Heroku, and that's the monetization strategy.
Currently you can push your Meteor apps to their servers and host/run them for free. But eventually they're going to charge, have add-on services, etc. Just like Heroku, but because these are the guys who built Meteor, it should be better.
It will be interesting to see if anyone else tries to host Meteor apps at all, Heroku/Salesforce should be watching closely.
I might be reading this wrong, but from the slides it seems like JOINs are only fast when they are on the same machine. Their own ORM library avoids using JOINs all together. Doesn't that defeat the point of using an RDBMS?
If you look at the example tables, what they're doing is sharding based on customerID, so sections of those tables with the same customerID "stick" together and are guaranteed to be stored together, on the same machine(s) (plural because of replication). Their workload is such that the workload is dominated by JOINs that do not mix customerIDs, hence the JOIN is run on a single machine, inside the database process, which is fast. They do support JOINs across customerIDs, but it probably involves the client (or a proxy process) fetching rows and merging/sorting them, ie. it happens outside the server process, probably on another machine, and is much slower.
The same trade-off also happens with transactions: if all the WRITEs are for the same customerID, it will be fast with almost no performance hit compared to issuing the same commands without transactions. They also support transactions across customerIDs, which involves an expensive 2-phase commit (2PC) round across the machines (across the Paxos quorums, really), which will be much slower.
Disclaimer: I wrote a distributed database with similar design decisions.
au VimEnter * highlight clear SignColumn