A description of known problems in Satoshi Nakamoto's paper, "Bitcoin: A Peer-to-Peer Electronic Cash System", as well as notes on terminology changes and how Bitcoin's implementation differs from that described in the paper.
The longest chain not only serves as proof of the sequence of events witnessed, but proof that it came from the largest pool of CPU power.
Many users of Git are curious about the lack of delta compression at the object (blob) level when commits are first written. This efficiency is saved until the pack file is written. Loose objects are written in compressed, but non-delta format at the time of each commit.
A simple run though of a commit sequence with only the smallest change to the image (in uncompressed TIFF format to amplify the observable behavior) aids the understanding of this deferred and different approach efficiency.
Create the repo:
| var E_PREFIX_RATE = 0.25; | |
| // All of our word lists: | |
| var _word_lists = { | |
| verb : [ | |
| "implement", "utilize", "integrate", "streamline", "optimize", "evolve", "transform", "embrace", | |
| "enable", "orchestrate", "leverage", "reinvent", "aggregate", "architect", "enhance", "incentivize", | |
| "morph", "empower", "envisioneer", "monetize", "harness", "facilitate", "seize", "disintermediate", |
| # -*- mode: ruby -*- | |
| # vi: set ft=ruby : | |
| Vagrant.configure("2") do |config| | |
| config.vm.box = "generic/fedora28" | |
| config.vm.network "public_network" | |
| config.vm.synced_folder ".", "/vagrant", type: "nfs" | |
| config.vm.provider "vmware_desktop" do |v| | |
| v.ssh_info_public = true | |
| v.vmx["numvcpus"] = "2" |
#IRC Reference
Not intended as a guide for newbies, more like a "cheat sheet" for the somewhat experienced IRC user, especially one who wields some power over a channel.
##The Basics
/join #channel
/part #channel
Concurrency is a domain I have wanted to explore for a long time because the locks and the race conditions have always intimidated me. I recall somebody suggesting concurrency patterns in golang because they said "you share the data and not the variables".
Amused by that, I searched for "concurrency in golang" and bumped into this awesome slide by Rob Pike: https://talks.golang.org/2012/waza.slide#1 which does a great job of explaining channels, concurrency patterns and a mini-architecture of load-balancer (also explains the above one-liner).
Let's dig in: