LukeHoersten

Turns out Microsoft is still accepting Bitcoin. The post was a mistake. http://www.cnbc.com/2016/03/14/microsoft-stops-accepting-bit...

Microsoft did liquidate to USD right away using a company called BitPay. BitPay would take on the short term price risk and Microsoft would get exactly what they quoted in USD. Microsoft was not subject to BTCUSD price fluctuation in this scheme.

My guess is that they gave it a try and the purchase volumes never materially compared to credit card payments. Integration was done very poorly. You had to go to a special link "commerce.microsoft.com" and click on a small, un-styled link at the bottom of the page called "Redeem bitcoins". It was never integrated in to their main purchase flow in an easy way. It couldn't be found just by chance. You had to google to figure out how to fund with bitcoin.

Edit: There are a handful of comments about price fluctuation. Microsoft liquidated to USD right away using a company called BitPay. BitPay would take on the short term price risk and Microsoft would get exactly what they quoted in USD. Microsoft was not subject to BTCUSD price fluctuation in this scheme.

Good point. The Ansible community who happened to be talking to me on IRC about this basically said that at least at this point, you have to look at all your role code no matter what anyway. Meaning scope wasn't the core issue. But lack of variable scope even hurts my own Ansible config abstractions.

Some things I really like about Ansible are:

- Super simple declarative yaml configs

- Agentless. You needed to have SSH working anyway so Ansible just uses that. With ssh pipelining it's so fast.

- The community support is huge and extensive.

- They have a module for everything and development is constant and active, much of which from the community.

- Hardware and networking equipment can be provisioned just the same as a VM or OS image.

The list goes on. Definitely give Ansible a try.

Agreed. In fact variables are scoped by "play" not by "role" which is almost weirder. For those who don't know the organizational structure from largest to smallest is playbook->plays->roles->modules/tasks. Variable scope is at the "play" level.

More than that, roles are meant to be distributable components on the Ansible Galaxy service they run. Galaxy gets almost no use because modularity and reusability is broken by having no idea how the role author namespaced their variables. Collisions happen all the time. Why we must manually manage scope with naming conventions when the computer can do it automatically with scope is beyond me.

This is Ansible's biggest downside in my opinion. I've talked with the core devs about it on IRC and they (bcoca) agreed but thought it too late to make such a pervasive change as introducing role-level scope.

As some of the other posts have mentioned, I still love Ansible despite this shortcoming.

FRP is very popular in Haskell. Reflex has had some success in production: https://github.com/reflex-frp/reflex

I've wondered that myself. I think the reason might be monads are used to represent IO computations and state mutation so people are interested in jumping straight into that. Honestly I use functor as much/more than I use monad in my day-to-day code which supports your statement here.

Something that doesn't help the Math->CS understanding of Functors is, for example, that languages like C++ use "Functor" to mean other things (function pointer in this case).

Doug Beardsley (mightybyte) is a very prominent Haskeller. A maintainer of the Snap Web Framework for Haskell and Co-organizer of the NYC Haskell group. Definitely worth reading his stuff. Great tutorial as well!

Does anyone have a success story for this type of backup and retrieval on another service?

Yeah that's exactly what I think. Software forking (and even blockchain forking) allow us to "vote with our feet" so we don't need to mandate central control.

Yeah I was using that as a transition to talk about Mike's other contributions. His bitcoinj contributions are hundreds of thousands of lines. Also I said "Lines of code are only a proxy for impact" and unfortunately there's probably no realistic measure.

I'm not a bitcoind contributor and this is more of a generic observation about how open source projects are controlled in general.

Yes good point. Thanks for the clarification.

Cross post from the NYT article comment:

In open source communities, impactful contributions yield influence. Here are the top 100 bitcoin contributors: https://github.com/bitcoin/bitcoin/graphs/contributors

Guys like Wladimir, Pieter, Gavin, Cory Fields, Gregory Maxwell and Luke Jr have a voice because they’ve contributed many thousands of lines of code. (Lines of code are only a proxy for impact).

You may have noticed Mike Hearn isn’t in the top 100 contributors list. He is the primary author of the Java implementation of a bitcoin library: https://github.com/bitcoinj/bitcoinj

He started it in 2011, definitely early. But a substantial amount of bitcoin core work had already set the path. There are also similar implementations in many different languages but they are not the primary reference implementation for full nodes.

According to Hearn’s blog post: “I’ve talked about Bitcoin on Sky TV and BBC News. I have been repeatedly cited by the Economist as a Bitcoin expert and prominent developer. I have explained Bitcoin to the SEC, to bankers and to ordinary people I met at cafes.”

Being cited by journalists is not the same as being a primary contributor.

The disagreement between Hearn and the other developers isn’t about whether to increase capacity, it’s about how. Many of the primary full-node contributors believe a hard-blockchain-fork is a risky approach. Lots of work is being done to explore better options, like segregated witness (http://gavinandresen.ninja/segregated-witness-is-cool).

Mike Hearn tried to (very aggressively) push the idea of increasing the block size with a hard fork. In fact the patch allows node operators to vote and 75% adoption is needed. When it looked like that wasn’t going to pan out, he created Bitcoin XT where “Decisions are made through agreement between Mike and Gavin, with Mike making the final call if a serious dispute were to arise.”

So the claim that Hearn not being able to take over decision making power for the bitcoin community is evidence that bitcoin has failed seems to show something slightly different. It shows that open source software methodology of forking and adoption lets the best implementation win and prevents hostile takeovers.

Mike Hearn is not as impactful to bitcoin development as he or recent news would indicate. Mike leaving the bitcoin community has little impact on the future success or failure of bitcoin.

In open source communities, impactful contributions yield influence. Here are the top 100 bitcoin contributors: https://github.com/bitcoin/bitcoin/graphs/contributors

Guys like Wladimir, Pieter, Gavin, Cory Fields, Gregory Maxwell and Luke Jr have a voice because they’ve contributed many thousands of lines of code. (Lines of code are only a proxy for impact).

You may have noticed Mike Hearn isn’t in the top 100 contributors list. He is the primary author of the Java implementation of a bitcoin library: https://github.com/bitcoinj/bitcoinj

He started it in 2011, definitely early. But a substantial amount of bitcoin core work had already set the path. There are also similar implementations in many different languages but they are not the primary reference implementation for full nodes.

According to Hearn’s blog post: “I’ve talked about Bitcoin on Sky TV and BBC News. I have been repeatedly cited by the Economist as a Bitcoin expert and prominent developer. I have explained Bitcoin to the SEC, to bankers and to ordinary people I met at cafes.”

Being cited by journalists is not the same as being a primary contributor.

The disagreement between Hearn and the other developers isn’t about whether to increase capacity, it’s about how. Many of the primary full-node contributors believe a hard-blockchain-fork is a risky approach. Lots of work is being done to explore better options, like segregated witness (http://gavinandresen.ninja/segregated-witness-is-cool).

Mike Hearn tried to (very aggressively) push the idea of increasing the block size with a hard fork. In fact the patch allows node operators to vote and 75% adoption is needed. When it looked like that wasn’t going to pan out, he created Bitcoin XT where “Decisions are made through agreement between Mike and Gavin, with Mike making the final call if a serious dispute were to arise.”

So the claim that Hearn not being able to take over decision making power for the bitcoin community is evidence that bitcoin has failed seems to show something slightly different. It shows that open source software methodology of forking and adoption lets the best implementation win and prevents hostile takeovers.

Mike Hearn is not as impactful to bitcoin development as he or recent news would indicate. Mike leaving the bitcoin community has little impact on the future success or failure of bitcoin.

Do you have connection pipelining enabled?:

[ssh_connection] pipelining = True

Ansible 2 is extremely fast for me.

Same here. Ansible has been added to my short list of life changing programs in my tool belt along with Mercurial and Emacs. These types of applications come along every 10+ years or so for me.

I was an avid Xmonad user on my Linux desktop but never was able to get it working quite right on OS X. I would love if that would change. Unfortunately I don't see anything new on the link posted here.

I've never seen that before. Thanks for pointing to the revision. Very cool.

Stripe's tech and customer service was unparalleled for the small business I had. Other guys like Braintree were just so far behind. If I hadn't used Stripe, I would have assumed the hype was over-hype as well. I don't think it is though.

I didn't realize when first looking at it but this is an official Amazon application. The github account is "awslabs" and it's linked right at the top of the docs: https://aws.amazon.com/cli/

Agreed. For those who didn't read to the end of the post they tacked this on the end:

"Vagrant 1.8 is our first major Vagrant release since releasing Otto. There was a lot of concern around the future of Vagrant since announcing Otto as the "successor to Vagrant". Many of the features of Vagrant 1.8 are the result of Otto needing them to reach that goal. Vagrant 1.8 is an example of how Vagrant will continue to improve – in major ways – alongside Otto."

Great points. I can attest to the fact that low-latency Java code looks nothing like idiomatic Java. Ironically, the techniques for writing low latency Java are the same in Haskell (avoiding object creation, boxing, garbage collection, etc). High performance C and C++ are a league of their own with direct control over memory layout and alignment etc. Haskell has some amazing work on that front as well though: http://www.doc.ic.ac.uk/~dorchard/publ/icfp-2013-simd-vector...

I prefer to work for smaller companies because of the way work and responsibility are divided. At large companies I've worked for, work gets divided into much smaller chunks so each developer is working on a very small sliver of the total product. At a smaller company, your typically solving a smaller, more focused problem as a group, but also, you get a much bigger chunk of the work as a developer. It's easier to have ownership over a whole project. It's why the term "full-stack developer" is so common in the startup world and basically unused in the enterprise/corporate world. Of course all of this lies on a gradient of headcount vs. total workload so I'm sure there are great counter examples out there.

Haskell's learning curve is certainly steeper than other popular general programming languages. But my view on that is best explained with an analogy: calculus is certainly harder to learn than arithmetic approximations but once learned, the complexity of calculus is factored out of all the problems suited for solving with it. Haskell is excellently suited for solving extremely complex problems and why it's so desirable for concurrency and parallelism tasks.

On your second point, while it seems nice to have Haskell features slowly percolate into other languages, I urge caution in thinking that's a panacea for not learning more complex languages. Haskell is greater than the sum of all it's features. It's power comes from the combination of everything working together in a very well thought-out way.

So I don't necessarily disagree with your tone, just some additional commentary from someone who knows C++, Python, Java, and Haskell equally well (and perhaps equally bad ;) ).

Easily one of the best articles I've read on Medium or for free online in a long time. Funny and in-depth analysis of incumbent competition with great supporting evidence.

Other comments here on HN are about the forced analogy or verbosity of the article but I think the point was to be entertaining and insightful. And I think it was artfully executed.

Thanks for posting the link!

Same here. ML-family languages are my favorite. Haskell seems to be the most popular though I may be biased considering I consider myself a Haskeller.

This is a surprisingly clear and articulate explanation of digital currency mining and how it was used to mask a ponzi scheme by over-issuing securities against it. Well done SEC.

awesome