>> Debian is a good example of the opposite end of Docker.
It is not fair to compare Docker with Debian. Docker Inc (who backed Docker) is a for-profit corporation and is backed by investors. It is understandable why they need to push their products into production the soonest time possible.
I use Docker a lot. I also use things like Docker volume plugins and have had to modify code due to API changes/breakages.
"Production ready" in the "container space" for me are Solaris Zones, FreeBSD Jails, and to an extent lxc (it's stable, but I've used it less). I like what Docker/Mesos/etc. bring to the table, but when working with the ecosystem, it takes work to stay on top of what is going on.
It is even harder to consult with a customer or company interested in containers and give the most accurate near/long term option. It becomes a discussion in understanding their application, what approach works now, and guidance for what they should consider down the road.
Networking and Storage are two areas with a lot of churn currently.
What does it matter how fair it is? It's neither fair to compare a monkey to a fish in terms of being able to climb trees, but that doesn't change that one of the two is most likely already sitting on a branch. And ultimately, if you need something that can climb trees, a fish simply won't do, no matter how fair you try to treat it.
JavaScript itself also need competition. I really hope the browser vendors can sit down together and start working on a better language for the future browsers.
PayPal, credit cards etc. all have their place, but for non-physical purchases from reputable parties I'm not sure how much you can improve on "pay money, receive thing."
It would have to be a very compelling argument to persuade me that transacting through a middle-man (who then holds all my personal information and card details and also takes a cut) is better than just handing over cash and getting what I want.
You don't need credit-card chargebacks until you do, but then you really need them. (And actually most of the time the threat of chargebacks keeps merchants honest).
Once you get to the point of using a reputable escrow system (which will have to charge a fee), that plus the bitcoin fees (either direct transfer fees or the implicit tax that is mining rewards) are unlikely to be cheaper than the credit card system (which doesn't have to burn immense amounts of processing power for business-as-usual). Having all participants be anonymous and untrusted adds a lot of overhead; in a civilized environment with a reasonable legal system you can shave that off by being willing to trust your counterparties (trust that is made possible by central clearing houses and verified identities).
One way to do escrow is with 2-of-3 signatures. If both parties to the transaction sign, the escrow agent doesn't have to get involved. On Ethereum it's easy to implement as a smart contract that lets the escrow agent choose who gets the money, and pays the agent a fee for the service (but nothing otherwise).
Participants aren't necessarily anonymous; if you're buying from a known vendor and having something shipped to your house, neither party is all that anonymous. People are working on adding verified identities, for people who want them.
Ethereum hopes to do away with mining by early 2017.
> One way to do escrow is with 2-of-3 signatures. If both parties to the transaction sign, the escrow agent doesn't have to get involved. On Ethereum it's easy to implement as a smart contract that lets the escrow agent choose who gets the money, and pays the agent a fee for the service (but nothing otherwise).
> Participants aren't necessarily anonymous; if you're buying from a known vendor and having something shipped to your house, neither party is all that anonymous. People are working on adding verified identities, for people who want them.
At which point why use this instead of a credit card?
> Ethereum hopes to do away with mining by early 2017.
How are they doing byzantine-fault-tolerant consensus without it?
With the escrow, you can set it up to pay a fee only if you need the judge's services, so if you don't have a problem it's free. Or you can set up whatever other arrangement you like. Either way you're paying only for the arbitration, not for stockholder dividends.
They're switching to proof of stake. Early PoS designs have some issues, like the infamous "nothing at stake" problem, but theirs addresses those. People lock up ether for several months, and bet it on which blocks will be included in the chain. The blocks that get the best odds in the betting are the ones that get included, so basically you're betting on what everybody else will do. You start with low-confidence bets that don't risk much, and as you see other people's bets you progress to high-confidence bets that pay off better, and it converges.
Miners essentially do the same thing: by choosing a block to mine on, they're betting their energy cost on that block being chosen.
> With the escrow, you can set it up to pay a fee only if you need the judge's services, so if you don't have a problem it's free. Or you can set up whatever other arrangement you like.
Sure, but that doesn't really change anything. Their service will cost a certain amount to run, and so you'll end up paying an average of x amount per transaction/per dollar spent, whichever way you slice it.
> Either way you're paying only for the arbitration, not for stockholder dividends.
And yet for-profit companies usually end up being the most effective way to get something done. If I need a tree cut down in my yard I don't try to find some non-profit tree-surgeon collective, I call a professional from a reputable company. (And I would think that anyone who supported cryptocurrencies - which are all about directly transferring money without involving a social layer - to feel this way even more strongly).
> They're switching to proof of stake. Early PoS designs have some issues, like the infamous "nothing at stake" problem, but theirs addresses those. People lock up ether for several months, and bet it on which blocks will be included in the chain. The blocks that get the best odds in the betting are the ones that get included, so basically you're betting on what everybody else will do. You start with low-confidence bets that don't risk much, and as you see other people's bets you progress to high-confidence bets that pay off better, and it converges.
> Miners essentially do the same thing: by choosing a block to mine on, they're betting their energy cost on that block being chosen.
Hmm. Doesn't that mean the reward for fraud is much higher? Can't someone just bet a massive amount that their fork will win, and then their fork wins precisely because they bet a massive amount on it?
I joked to a friend that if Google invented a time machine, the first thing they would do is travel back to remove the extension support in Chrome before it was launched - the ad blockers.
Chrome didn't support the proper method for ad blockers at launch (it could hide content but not stop the requests, if I remember it well), and they purposely added those in months after launch, clearly for the benefit of adblocking extensions writers who where complaining.
Google is a big company; I'm pretty sure not everyone there is against adblocking. Or perhaps they managed to sneak request blocking past those who were against adblocking by advocating a different use-case --- "reader mode" comes to mind.
Yes until the managements find out the they are losing Billions due to the ad blocking. IMO, not bring extension support on Chrome Android is the same reason.
But you're not storing the session there, just the key/token so you can change it. The session payload is still completely in the JSON body maintained by the client and sent with each request.
You only have to validate the token. It doesn't have to be a database-type medium because you're not writing very often in fact all you're really doing is making sure the token is not invalid. The session data could be changing on every request which would be at least one write on every request. With this system you are only writing to the central medium on a session creation or a session invalidation.
This is not entirely true. Since we talking about implementing stateful sessions, you could receive a valid token (stolen, out otherwise) after the user has logged out.
You are correct that the lookup doesn't have to be via the database. You could implement a caching system where the cache is invalidated when the user logs out and requires reauthentication. This is the notion of the session. By definition they cannot be stateless.
Stateless authentication is inherently (slightly) less secure than sessions. I think of a blind librarian who gives out keys to the library. Whoever has a key has access. You can put limitations on the timeframe someone has access to the library, but that's it. If your key gets stolen, the blind librarian can't help you as there is no way for him to tell if it's really you.
People don't realize it is not a proper comparison as JWT is only the format/spec - you can still achieve stateless client session by encrypting an XML payload (e.g. user id) in the browser cookie. Storing data in client and verify by signature is not a new thing.
