Markus Kobler markuskobler

Basics

B-trees and CPU Caches

Example Python development environment with Nixpkgs

This project requires Python 3.6.

This project isn't packaged, and traditionally uses:

$ python -m venv venv
$ source venv/bin/activate
$ pip install "${pypi_deps[@]}"

Raspberry 4B - Boot from SD and rootfs on USB

Update

RPi4 now supports booting directly from USB. First update to get an eeprom which supports USB Boot, then configure the bootloader to boot from USB.

Original guide

Download Raspbian from the official site

Download the latest ugw3 package from https://github.com/Lochnair/vyatta-wireguard/releases and install it on your USG using dpkg -i wireguard-ugw3-<version>.deb.

cd /config/auth
umask 077
mkdir wireguard
cd wireguard
wg genkey > wg_private.key
wg pubkey < wg_private.key > wg_public.key

React recently introduced an experimental profiler API. This page gives instructions on how to use this API in a production release of your app.

Table of Contents

Profiling in production
- Create React App
- Webpack 4

Profiling in production

React DOM automatically supports profiling in development mode for v16.5+, but since profiling adds some small additional overhead it is opt-in for production mode. This gist explains how to opt-in.

Looking into the `Future`

futures-rs is the library which will hopefully become a shared foundation for everything async in Rust. However it's already become renowned for having a steep learning curve, even for experienced Rustaceans.

I think one of the best ways to get comfortable with using a library is to look at how it works internally: often API design can seem bizarre or impenetrable and it's only when you put yourself in the shoes of the library author that you can really understand why it was designed that way.

In this post I'll try to put down on "paper" my understanding of how futures work and I'll aim to do it in a visual way. I'm going to assume you're already somewhat familiar with Rust and why futures are a useful tool to have at one's disposal.

For most of this post I'll be talking about how things work today (as of September 2017). At the end I'll touch on what's being proposed next and also make a case for some of the changes I'd like to see.

If you're interested in learning more ab

Rationale

This snippet is a sample showing how to implement CloudWatch Logs streaming to ElasticSearch using terraform. I wrote this gist because I didn't found a clear, end-to-end example on how to achieve this task. In particular, I understood the resource "aws_lambda_permission" "cloudwatch_allow" part by reading a couple of bug reports plus this stackoverflow post.

The js file is actually the Lambda function automatically created by AWS when creating this pipeline through the web console. I only added a endpoint variable handling so it is configurable from terraform.

	<!DOCTYPE html>
	<html lang="en">
	<head>
	<meta charset="UTF-8" />
	<meta name="viewport" content="width=device-width, initial-scale=1.0" />
	<title>Document</title>
	</head>
	<body>
	<div id="app"></div>
	<script type="module">

	// cc -g2 example_journal_reader.c -lsystemd
	#include <stdio.h>
	#include <time.h>
	#include <errno.h>
	#include <sys/poll.h>
	#include <stdlib.h>
	#include <string.h>
	#include <assert.h>
	#include <systemd/sd-journal.h>