It's not just that it only works with Clang, but that it only works with Blocks (Apple's extension to C which basically adds closures of indefinite extent, which is pretty cool).
> Topping the list for common genes were those related to our sense of smell. One explanation for this is that people with similar olfactory genes will smell things in the same way and so be drawn to (or repulsed by) similar environments... The opposite pattern held for genes related to immunity -- friends tended to be less similar at those parts of the genome.
This makes me think of the thesis of "Sex At Dawn" by Christopher Ryan and Cacilda Jetha. If humans evolved as polyamorous foragers for whom communal bonds were more important than paternal certainty, then it makes sense that you want your friends to like the same environments and add immunological diversity to your shared gene pool.
> [T]he impact of adding a second evil ESP8266 is much greater than the first one. One possible cause is the exponentially increased probability of having the channel jammed due to simultaneous transmissions on the same channel.
The reason is that TCP connections increase their speed linearly (aka the the first derivative of packet transfer is increasing) until they experience packet loss. If many packets are lost, or if the network is congested, the speed will not increase
yeah. i saw a specialist at the university hospital who pretty much told me there are genetic factors (weaker ligaments on the inner side of my fingers) that pretty much mean i'm shit out of luck so long as i keep typing. he also suggested more cardiovascular exercise and working in warmer environments (as it is largely a blood flow issue)
diego, thanks so much for raft! i'm a student in the brown class you shout out, and i can testify as to its relative simplicity and the clarity with which you guys communicate the ins and outs.
i have a question for you, though. why is raft not concerned with byzantine failure? the focus on byzantine fault tolerance from the paxos family of algos (and a lot of the literature/educationally material on distributed consensus) makes me feel like it's important, but your approach suggests it perhaps isn't. do you think this focus is a side-effect of the ubiquity of paxos which is disproportionately concerned with this due to its roots in academia?
It's a good question, and I don't really know where the community as a whole sits on Byzantine vs non-Byzantine. A few thoughts:
Byzantine is more complex, and most people in industry aren't doing it: there are a lot of Byzantine papers out there but few real-world implementations. I think Byzantine is important for uses where the nodes really can't be trusted for security reasons, and maybe there's easier fault-tolerance payoffs elsewhere when the entire system is within one trust domain such as a single company.
Byzantine consensus is slower and requires more servers.
If you don't have independent implementations running on each of your servers, the same software bug could still take out your entire cluster. You get some benefit if the hardware fails independently, but you don't get protection from correlated software outages. Maybe the difficulty in characterizing which faults a particular deployment can handle makes it harder to sell to management.
With Raft, we were just trying to solve non-Byzantine consensus in a way people could understand, and we think it's still a useful thing to study even if your ultimate goal is Byzantine consensus. You might be interested in Tangaroa, from the CS244b class at Stanford, where Christopher Copeland and Hongxia Zhong did some work towards a Byzantine version of Raft [1][2] and Heidi Howard's blog post on it [3]. But really, Castro and Liskov's PBFT is a must read here [4].
Yes Splice uses Go for everything backend related (web APIs, file parsers/decoders, audio processing) AngularJS for the frontend, ObjC & C#, C & C++ for native desktop/mobile apps.
We are always looking for talented backend engineers to join our exceptional team.
We don't actively advertise this position, maybe we should. You or other candidates should feel free to contact me at matt/at/splice.com and dont forget to attach your challenge solution.
brad has a fairly light-weight go setup for emacs. from what i can tell, he just has gofmt run on save and the go import plugin that reads his code and adds/removes import statements appropriately.
mine includes auto-complete (that is conscious of the AST) and linting/error checking. i suspect brad has jump-to-definition and the other stuff that comes with the go emacs mode, but he doesn't use it.
https://github.com/asubiotto/cdefer/blob/master/defer.h