index.xml

<?xml version="1.0" encoding="utf-8" standalone="yes" ?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Const Volatile</title>
    <link>https://cmbrandenburg.github.io/</link>
    <description>Recent content on Const Volatile</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en-us</language>
    <lastBuildDate>Wed, 28 Jun 2017 00:00:00 +0000</lastBuildDate>
    
	<atom:link href="https://cmbrandenburg.github.io/index.xml" rel="self" type="application/rss+xml" />
    
    
    <item>
      <title>BoltDB vs LMDB (lightning talk slides for Golang Phoenix)</title>
      <link>https://cmbrandenburg.github.io/presentation/2017-06-28-boltdb_vs_lmdb_lightning_talk/</link>
      <pubDate>Wed, 28 Jun 2017 00:00:00 +0000</pubDate>
      
      <guid>https://cmbrandenburg.github.io/presentation/2017-06-28-boltdb_vs_lmdb_lightning_talk/</guid>
      <description>Title  @import url(https://fonts.googleapis.com/css?family=Yanone+Kaffeesatz); @import url(https://fonts.googleapis.com/css?family=Droid+Serif:400,700,400italic); @import url(https://fonts.googleapis.com/css?family=Ubuntu+Mono:400,700,400italic); body { font-family: &#39;Droid Serif&#39;; } h1, h2, h3 { font-family: &#39;Yanone Kaffeesatz&#39;; font-weight: normal; } .remark-code, .remark-inline-code { font-family: &#39;Ubuntu Mono&#39;; }    class: center, middle # BoltDB vs LMDB Craig M. Brandenburg c.m.brandenburg@gmail.com --- # BoltDB and LMDB similarities * Both are **local key-value stores**—i.e., server-free, schema-free, non-relational, and typically *fast*. * Both are **memory-mapped**—i.e., small databases reside in memory but databases can be bigger than the sum of physical memory and swap space.</description>
    </item>
    
    <item>
      <title>SSH jump hosts</title>
      <link>https://cmbrandenburg.github.io/post/2016-06-23-ssh_jump_hosts/</link>
      <pubDate>Thu, 23 Jun 2016 00:00:00 +0000</pubDate>
      
      <guid>https://cmbrandenburg.github.io/post/2016-06-23-ssh_jump_hosts/</guid>
      <description>Recently I learned about SSH jump hosts. Jump hosts make it easier to connect to an SSH server via an intermediate hop—i.e., connecting to an SSH server and, from there, connecting to yet another SSH server.
For years I did this “jumping” manually, by entering and running two distinct SSH commands. E.g.,
craig@myclient$ ssh proxy_host Welcome to proxy_host! craig@proxy_host$ ssh target_host Welcome to target_host! craig@target_host$ echo &amp;quot;Now I can do some work.</description>
    </item>
    
    <item>
      <title>Announcing Chill v0.1.1</title>
      <link>https://cmbrandenburg.github.io/post/2016-04-18-chill_v0.1.1/</link>
      <pubDate>Mon, 18 Apr 2016 00:00:00 +0000</pubDate>
      
      <guid>https://cmbrandenburg.github.io/post/2016-04-18-chill_v0.1.1/</guid>
      <description>Chill v0.1.1 is now available. Chill is a client-side CouchDB library for the Rust programming language.
This release adds support for executing views, meaning an application using Chill can now use CouchDB for interesting work&amp;mdash;and not merely as a document store.
This release also adds support for manipulating attachments&amp;mdash;though only indirectly, as a consequence of actions that read or update documents. For example, an application can:
 Read a document from the CouchDB server, Insert an attachment to the application&amp;rsquo;s in-memory representation of the document, and, Update the document by sending the updated representation to the CouchDB server.</description>
    </item>
    
    <item>
      <title>Rethinking CouchDB in Rust</title>
      <link>https://cmbrandenburg.github.io/post/2016-02-23-rethinking_couchdb_in_rust/</link>
      <pubDate>Tue, 23 Feb 2016 00:00:00 +0000</pubDate>
      
      <guid>https://cmbrandenburg.github.io/post/2016-02-23-rethinking_couchdb_in_rust/</guid>
      <description>My knowledge of Rust has surpassed my knowledge of CouchDB. I now think less about how to abstract the CouchDB API and more about what to abstract. Additionally, I believe my original strategy for the couchdb crate is a bad idea.
That strategy is to provide a thin abstraction whereby the application has fine-grained control over each HTTP request it sends to the CouchDB server. Here&amp;rsquo;s an example request with one query parameter:</description>
    </item>
    
    <item>
      <title>Hibernating in Debian using a temporary swap file</title>
      <link>https://cmbrandenburg.github.io/post/2015-12-24-hibernating_in_debian_using_a_temporary_swap_file/</link>
      <pubDate>Thu, 24 Dec 2015 00:00:00 +0000</pubDate>
      
      <guid>https://cmbrandenburg.github.io/post/2015-12-24-hibernating_in_debian_using_a_temporary_swap_file/</guid>
      <description>This article explains how to configure a Debian Jessie system to hibernate using swap space that&amp;rsquo;s created just before suspending and destroyed just after resuming. This trick allows hibernation on a swap-free or swap-lite system—useful on a desktop system running with enough RAM to make swap space otherwise unnecessary.
How to make it work Determine the root partition of your system $ rootdev=$(mount | grep &#39; / &#39; | awk &#39;{ print $1 }&#39;)  Important!</description>
    </item>
    
  </channel>
</rss>