Full access (read and write) to the PowerDNS HTTP API requires one of their generic SQL backends (via https://docs.powerdns.com/md/httpapi/README/), such as MySQL. The bind backend only supports reading from the API, changes to zones would need to be done on the file system and/or using pdns_control. Beyond that having all our records queryable via SQL has been nice for debugging and researching our own DNS records, types and etc. Lastly, backends like the MySQL one allow for things like auto generating serials and adding comments to the DNS data.
Nearly all of our internal zones are internal and not sync'd to an external provider. In a few cases we need to perform lookups of internal zones external to our network and those zones live both internal and external.
We use the mysql backend and http API, a few small nits but for our purposes it has worked very well thus far. Note that our authorities never see production traffic outside of AXFRs from our "edge" hosts so I can't say how well it works for other use cases.
This was a roughly six month project for a single engineer working around 75% of the time on it, with help from other folks along the way for code reviews and etc. The first three months was research, planning, implementation, etc and the latter three months was a very careful roll out and migration from the old system to the new and finally decommissioning the old system.
CARP and similar systems require an active/passive configuration which we did not want since it needs at least twice as many hosts, half of which are not doing any work. We had similar issues with our former Git storage system based on DRDB (http://githubengineering.com/introducing-dgit/).
pfsync, lvs and etc uses multicast to share connection state which we also wanted to avoid.
Joe from GitHub here, frankly there is a lot we want to talk about and release and it was simply too much for one post. We'd like to give it a proper treatment and single very long post won't do that. Also, it allows us to get folks interested in the project and give us time to prepare our code for release. It's a surprisingly big job.
Joe from GitHub here, we'll talk about it later posts but GLB is based on a number of open source projects including, haproxy, iptables, FoU and pf_ring.
Many existing open source solutions are optimized for short lived HTTP requests and don't address the long running connection issue (like a large git clone). We wanted something better for our use case.
IIRC the Boundary app cookbook is a pretty big divergence from the Opscode application cookbook due to their reliance on roles, environments and etc. Additionally our cookbook has a far more narrow (I think in a good way) focus. Both have their place, just probably not in the same cookbook.
He seems to assume a lot in this post, for instance his 200 vs 4 node comparison assumes that you have 200 nodes because the poor performance of your DBMS requires that many nodes. If that's the case, great, use voltdb. If not, it's perfectly reasonable to think that 200 nodes would have more network partitions than 4 nodes which is why one would pick an AP system in the first place.
One missing item is instrumentation and metrics. Understanding and debugging a complex application is made much easier by having an abundance of easily collectable metrics that describe the running or cumulative state of the system.
Admittedly I thought that AMD made more sense initially but I think the key might be that Apple isn't really a "computer company" anymore. Laptop and desktop sales aren't nearly as important as iphone, ipod and ipad sales. With that buying AMD may not be as enticing as ARM as there may be more of a future in the small devices. Not sure on the numbers but I would also imagine the margins are much better on the small devices. Small devices are also generally more tightly integrated than laptops/desktops so owning the stack may be advantageous.
I have doubts that Apple is planning to switch to ARM from Intel if for no other reason that ARM is not 64bit and from what I recall it's not in the roadmap. This works fine for small devices but obviously won't work for anything larger. I doubt a PAE-style kernel is a legitimate option.
While I generally enjoy a Cory Doctorow opinion I can't help but to think he is off on this one. The iPad is analogous to a newspaper, both used for consuming content and both gated from seeing how they work on the inside. The Apple IIgs' of today are Arduino's, FPGAs, and the like. Mostly or fully open source and customizable.