summaryrefslogtreecommitdiff
path: root/_posts
diff options
context:
space:
mode:
authorBrian Picciano <mediocregopher@gmail.com>2018-09-03 15:32:18 -0400
committerBrian Picciano <mediocregopher@gmail.com>2018-09-03 19:36:38 -0400
commitbfefb5fa2e831e32672c2feaa844bbc1a7d41bc3 (patch)
treea53551e8cf3b061757d5f7b67f914bdd07247e69 /_posts
parent89b452fcceba6bec4f9f80b21113b90688a16406 (diff)
restarted with minima theme, but am completely revamping it to use custom theme based on getskeleton.org
Diffstat (limited to '_posts')
-rw-r--r--_posts/2013-10-25-namecoind-ssl.md25
-rw-r--r--_posts/2013-10-8-generations.md16
-rw-r--r--_posts/2013-4-9-erlang-tcp-socket-pull-pattern.md12
-rw-r--r--_posts/2013-7-11-goplus.md4
-rw-r--r--_posts/2014-1-11-clojure-diamond-square.md3
-rw-r--r--_posts/2014-10-29-erlang-pitfalls.md3
-rw-r--r--_posts/2015-07-15-go-http.md3
-rw-r--r--_posts/2015-11-21-happy-trees.md2
-rw-r--r--_posts/2015-3-11-rabbit-hole.md2
-rw-r--r--_posts/2017-9-6-brian-bars.md19
10 files changed, 56 insertions, 33 deletions
diff --git a/_posts/2013-10-25-namecoind-ssl.md b/_posts/2013-10-25-namecoind-ssl.md
index c2efcf2..2711a92 100644
--- a/_posts/2013-10-25-namecoind-ssl.md
+++ b/_posts/2013-10-25-namecoind-ssl.md
@@ -1,5 +1,8 @@
---
title: Namecoin, A Replacement For SSL
+description: >-
+ If we use the namecoin chain as a DNS service we get security almost for
+ free, along with lots of other benefits.
---
At [cryptic.io][cryptic] we are creating a client-side, in-browser encryption
@@ -18,7 +21,7 @@ from tampering in-between leaving our servers and being received by the client.
Unfortunately, SSL isn't 100% foolproof. This post aims to show why SSL is
faulty, and propose a solution.
-# SSL
+## SSL
SSL is the mechanism by which web-browsers establish an encrypted connection to
web-servers. The goal of this connection is that only the destination
@@ -31,7 +34,7 @@ be decrypted by anyone else.
SSL is what's used to establish that secret key on a per-session basis, so that
a key isn't ever re-used and so only the client and the server know it.
-## Public-Private Key Cryptography
+### Public-Private Key Cryptography
SSL is based around public-private key cryptography. In a public-private key
system, you have both a public key which is generated from a private key. The
@@ -53,7 +56,7 @@ attacker could create messages the other person would think are from you, and
the other person would encrypt messages meant for you but which would be
decrypt-able by the attacker.
-## How does SSL work?
+### How does SSL work?
SSL is at its heart a public-private key system, but its aim is to be more
secure against the attack described above.
@@ -72,7 +75,7 @@ gave you, which means you can trust it too.
There's a bit (a lot!) more to SSL than this, but this is enough to understand
the fundamental problems with it.
-## How SSL doesn't work
+### How SSL doesn't work
SSL has a few glaring problems. One, it implies we trust the companies holding
the root certificates to not be compromised. If some malicious agency was to get
@@ -87,7 +90,7 @@ few root authorities there's an effective monopoly on signatures, and there's
nothing we can do about it. For 200 bucks I know most people simply say "no
thanks" and go unencrypted. The solution is creating a bigger problem.
-# Bitcoins
+## Bitcoins
Time to switch gears, and propose a solution to the above issues: namecoins. I'm
going to first talk about what namecoins are, how they work, and why we need
@@ -101,7 +104,7 @@ still a bit of a novelty in the tech realm, but they're growing in popularity.
The rest of this post assumes you know more or less what bitcoins are, and how
they work.
-# Namecoins
+## Namecoins
Few people actually know about bitcoins. Even fewer know that there's other
crypto-currencies besides bitcoins. Basically, developers of these alternative
@@ -118,13 +121,13 @@ You spend namecoins to claim arbitrary keys (once you've claimed it, you own it
for a set period of time) and to give those keys arbitrary values. Anyone else
with namecoind running can see these values.
-## Why use it?
+### Why use it?
A blockchain based on a digital currency seems like a weird idea at first. I
know when I first read about it I was less than thrilled. How is this better
than a DHT? It's a key-value store, why is there a currency involved?
-### DHT
+#### DHT
DHT stands for Distributed Hash-Table. I'm not going to go too into how they
work, but suffice it to say that they are essentially a distributed key-value
@@ -140,7 +143,7 @@ chain, and then replicate all the work put into the existing chain into that new
compromised one so that the new one is longer and other clients in the network
will except it. This is extremely non-trivial.
-### Why a currency?
+#### Why a currency?
To answer why a currency needs to be involved, we need to first look at how
bitcoin/namecoin work. When you take an action (send someone money, set a value
@@ -163,7 +166,7 @@ In the case of namecoins, there's even more reason to involve a currency. Since
you have to spend money to make changes to the chain there's a disincentive for
attackers (read: idiots) to spam the chain with frivolous changes to keys.
-### Why a *new* currency?
+#### Why a *new* currency?
I'll admit, it's a bit annoying to see all these altcoins popping up. I'm sure
many of them have some solid ideas backing them, but it also makes things
@@ -193,7 +196,7 @@ Additionally, if for some reason bitcoins fall by the wayside, namecoin will
still have a shot at continuing operation since it isn't tied to the former.
Tldr: separation of concerns.
-# Namecoin as an alternative to SSL
+## Namecoin as an alternative to SSL
And now to tie it all together.
diff --git a/_posts/2013-10-8-generations.md b/_posts/2013-10-8-generations.md
index 38eeacb..c1c433d 100644
--- a/_posts/2013-10-8-generations.md
+++ b/_posts/2013-10-8-generations.md
@@ -1,11 +1,11 @@
---
title: Generations
+description: >-
+ A simple file distribution strategy for very large scale, high-availability
+ file-services.
---
-A simple file distribution strategy for very large scale, high-availability
-file-services.
-
-# The problem
+## The problem
At [cryptic.io][cryptic] we plan on having millions of different
files, any of which could be arbitrarily chosen to be served any given time.
@@ -25,7 +25,7 @@ file lives need to be up-to-date at all times, and even then there are
race-conditions and network failures to contend with, while at all times the
requirements of the app evolve and change.
-# A simpler solution
+## A simpler solution
Let's say you want all files which get uploaded to be replicated in triplicate
in some capacity. You buy three identical hard-disks, and put each on a separate
@@ -40,13 +40,13 @@ going to be generation 1. Repeat until you run out of money.
That's it.
-## That's it?
+### That's it?
It seems simple and obvious, and maybe it's the standard thing which is done,
but as far as I can tell no-one has written about it (though I'm probably not
searching for the right thing, let me know if this is the case!).
-## Advantages
+### Advantages
* It's so simple to implement, you could probably do it in a day if you're
starting a project from scratch
@@ -83,7 +83,7 @@ go.
replicated, or how many countries it's in, or what hardware it's being served
from (given you have easy access to information about specific drives).
-## Caveats
+### Caveats
The big caveat here is that this is just an idea. It has NOT been tested in
production. But we have enough faith in it that we're going to give it a shot at
diff --git a/_posts/2013-4-9-erlang-tcp-socket-pull-pattern.md b/_posts/2013-4-9-erlang-tcp-socket-pull-pattern.md
index 3f42b49..3e5f0af 100644
--- a/_posts/2013-4-9-erlang-tcp-socket-pull-pattern.md
+++ b/_posts/2013-4-9-erlang-tcp-socket-pull-pattern.md
@@ -1,5 +1,7 @@
---
title: "Erlang, tcp sockets, and active true"
+description: >-
+ Using `{active:once}` isn't always the best way to handle connections.
---
If you don't know erlang then [you're missing out][0]. If you do know erlang,
@@ -9,7 +11,7 @@ number of active connections is desired. Each thread can autonomously handle its
single client, greatly simplifying the logic of the whole application while
still retaining [great performance characteristics][1].
-# Background
+## Background
For an erlang thread which owns a single socket there are three different ways
to receive data off of that socket. These all revolve around the `active`
@@ -30,7 +32,7 @@ to receive data off of that socket. These all revolve around the `active`
read from using [recv/2][3] or be put in `{active,once}` or
`{active,true}`.
-# Which to use?
+## Which to use?
Many (most?) tutorials advocate using `{active,once}` in your application
\[0]\[1]\[2]. This has to do with usability and security. When in `{active,true}`
@@ -41,7 +43,7 @@ well as other messages from other erlang processes at the same time you can't
use `{active,false}`. So `{active,once}` is generally preferred because it
deals with both of these problems quite well.
-# Why not to use `{active,once}`
+## Why not to use `{active,once}`
Here's what your classic `{active,once}` enabled tcp socket implementation will
probably look like:
@@ -229,7 +231,7 @@ This time our process spent almost no time at all (according to eprof, 0%)
fiddling with the socket opts. Instead it spent all of its time in the
read_loop doing the work we actually want to be doing.
-# So what does this mean?
+## So what does this mean?
I'm by no means advocating never using `{active,once}`. The security concern is
still a completely valid concern and one that `{active,once}` mitigates quite
@@ -238,7 +240,7 @@ performance implications which have the potential to bite you if you're not
careful, especially in cases where a socket is going to be receiving a large
amount of traffic.
-# Meta
+## Meta
These tests were done using R15B03, but I've done similar ones in R14 and found
similar results. I have not tested R16.
diff --git a/_posts/2013-7-11-goplus.md b/_posts/2013-7-11-goplus.md
index e8402f6..5ee121e 100644
--- a/_posts/2013-7-11-goplus.md
+++ b/_posts/2013-7-11-goplus.md
@@ -1,5 +1,7 @@
---
title: Go+
+description: >-
+ A simple proof-of-concept script for doing go dependency management.
---
Compared to other languages go has some strange behavior regarding its project
@@ -63,7 +65,7 @@ cd "$ORIG_DIR"
exec go $@
```
-# UPDATE: Goat
+## UPDATE: Goat
I'm leaving this post for posterity, but go+ has some serious flaws in it. For
one, it doesn't allow for specifying the version of a dependency you want to
diff --git a/_posts/2014-1-11-clojure-diamond-square.md b/_posts/2014-1-11-clojure-diamond-square.md
index 6c89353..a3aee03 100644
--- a/_posts/2014-1-11-clojure-diamond-square.md
+++ b/_posts/2014-1-11-clojure-diamond-square.md
@@ -1,5 +1,8 @@
---
title: Random Terrain Generation, A Clojure Walkthrough
+description: >-
+ Tackling the problem of semi-realistic looking terrain generation in
+ clojure.
---
![terrain][terrain]
diff --git a/_posts/2014-10-29-erlang-pitfalls.md b/_posts/2014-10-29-erlang-pitfalls.md
index 416690d..32a8095 100644
--- a/_posts/2014-10-29-erlang-pitfalls.md
+++ b/_posts/2014-10-29-erlang-pitfalls.md
@@ -1,5 +1,8 @@
---
title: Erlang Pitfalls
+description: >-
+ Common pitfalls that people may run into when designing and writing
+ large-scale erlang applications.
---
I've been involved with a large-ish scale erlang project at Grooveshark since
diff --git a/_posts/2015-07-15-go-http.md b/_posts/2015-07-15-go-http.md
index 334d68a..7da7d6b 100644
--- a/_posts/2015-07-15-go-http.md
+++ b/_posts/2015-07-15-go-http.md
@@ -1,5 +1,8 @@
---
title: Go's http package by example
+description: >-
+ The basics of using, testing, and composing apps built using go's net/http
+ package.
---
Go's [http](http://golang.org/pkg/net/http/) package has turned into one of my
diff --git a/_posts/2015-11-21-happy-trees.md b/_posts/2015-11-21-happy-trees.md
index 49b3885..373f35f 100644
--- a/_posts/2015-11-21-happy-trees.md
+++ b/_posts/2015-11-21-happy-trees.md
@@ -1,5 +1,7 @@
---
title: Happy Trees
+description: >-
+ Visualizing a forest of happy trees.
---
Source code related to this post is available [here](https://github.com/mediocregopher/happy-tree).
diff --git a/_posts/2015-3-11-rabbit-hole.md b/_posts/2015-3-11-rabbit-hole.md
index bf5fe52..97c2b80 100644
--- a/_posts/2015-3-11-rabbit-hole.md
+++ b/_posts/2015-3-11-rabbit-hole.md
@@ -1,5 +1,7 @@
---
title: Rabbit Hole
+description: >-
+ Complex systems sometimes require complex debugging.
---
We've begun rolling out [SkyDNS][skydns] at my job, which has been pretty neat.
diff --git a/_posts/2017-9-6-brian-bars.md b/_posts/2017-9-6-brian-bars.md
index e36304f..d626d67 100644
--- a/_posts/2017-9-6-brian-bars.md
+++ b/_posts/2017-9-6-brian-bars.md
@@ -1,15 +1,18 @@
---
title: Brian Bars
+description: >-
+ Cheap and easy to make, healthy, vegan, high-carb, high-protein. "The Good
+ Stuff".
---
It actually blows my mind it's been 4 years since I used this blog. It was
previously a tech blog, but then I started putting all my tech-related posts on
-[the cryptic blog](cryptic.io). As of now this is a lifestyle/travel blog. The
-me of 4 years ago would be horrified.
+[the cryptic blog](https://cryptic.io). As of now this is a lifestyle/travel
+blog. The me of 4 years ago would be horrified.
Now I just have to come up with a lifestyle and do some traveling.
-# Brian Bars
+## Recipe
This isn't a real recipe because I'm not going to preface it with my entire
fucking life story. Let's talk about the food.
@@ -28,7 +31,7 @@ Brian bars:
I've worked on this recipe for a bit, trying to make it workable, and will
probably keep adjusting it (and this post) as time goes on.
-## Ingredients
+### Ingredients
Nuts and seeds. Most of this recipe is nuts and seeds. Here's the ones I used:
@@ -49,7 +52,7 @@ The other ingredients are:
* 1.5 lbs of pitted dates (no added sugar! you don't need it!)
* 2 cups oats
-## Grind up the nuts
+### Grind up the nuts
Throw the nuts into the food processor and grind them into a powder. Then throw
that powder into a bowl along with the seeds, coconuts, raisins, and oats, and
@@ -58,7 +61,7 @@ mix em good.
I don't _completely_ grind up the nuts, instead leaving some chunks in it here
and there, but you do you.
-## Prepare the dates
+### Prepare the dates
This is the harder part, and is what took me a couple tries to get right. The
best strategy I've found is to steam the dates a bit over a stove to soften
@@ -70,7 +73,7 @@ Once processed you can add the dates to the mix from before and stir it all up.
It'll end up looking something like cookie dough. Except unlike cookie dough
it's completely safe to eat and maybe sorta healthy.
-## Bake it, Finish it
+### Bake it, Finish it
Put the dough stuff in a pan of some sort, flatten it out, and stick it in the
oven at like 250 or 300 for a few hours. You're trying to cook out the water you
@@ -83,7 +86,7 @@ filling and allow for pretty small portions. Wrap em in foil or plastic wrap and
take them to-go, or keep them around for a snack. Or both. Or whatever you want
to do, it's your food.
-## Cleanup
+### Cleanup
Dates are simultaneously magical and the most annoying thing to work with, so
there's cleanup problems you may run into with them: