This guide is for homelab admins who understand IPv4s well but find setting up IPv6 hard or annoying because things work differently. In some ways, managing an IPv6 network can be simpler than IPv4, one just needs to learn some new concepts and discard some old ones.
Let’s begin.
First of all, there are some concepts that one must unlearn from ipv4:
Concept 1
Sometimes we need to add redundancy to some service or server which happen to be a public-facing entry point of our infrastructure. For example, imagine we want to add a high availability pair for a load balancer which sits on the edge of network and forwards traffic to alive backend servers.
┌─────────────┐
│ │
┌─────►│ Backend 1 │
│ │ │
│ └─────────────┘
I won't be updating this gist any longer. Updated versions of these notes can be found here.
The Seeed WIO Terminal is generally supported by CircuitPython, but there is no implementation for access to the WiFi or Bluetooth LE networking functions on the board. After taking a look at the Arduino support for these features, I can see that the RealTek RTL8720D is set up to be driven by a UART connection from the SAMD51 that acts as the main controller for the WIO Terminal. In other words, the RTL8720D is set up as a co-processor, similar to the ESP32 in Adafruit's Airlift modules.
The UART driver is based on an [embedded remote procedure call (eRPC) libr
note: All of these examples have been tested with the latest version of CircuitPython, which as of this writing was 7.2.4. Some of these examples may require tweaks in older or later versions, due to change in the drivers.
The Seeed Wio Terminal is a nifty connected device development kit. Built around a SAMD51 Cortex-M4 microcontroller and a Realtek RTL8720DN for WiFi and Bluetooth, plus an integrated display and a collection of handy sensors, the Wio Terminal is a great platform for IoT and smart device development.
One of the nice things about the Wio Terminal is the number of options available for developement platforms. You can choose the long-time hardware hacking favorite Arudino, MicroPython or Ardupy, an interesting blend of MicroPython and Arduino. And there's support for my
This post was adapted from an earlier Twitter thread.
It's incredible how many collective developer hours have been wasted on pushing through the turd that is ES Modules (often mistakenly called "ES6 Modules"). Causing a big ecosystem divide and massive tooling support issues, for... well, no reason, really. There are no actual advantages to it. At all.
It looks shiny and new and some libraries use it in their documentation without any explanation, so people assume that it's the new thing that must be used. And then I end up having to explain to them why, unlike CommonJS, it doesn't actually work everywhere yet, and may never do so. For example, you can't import ESM modules from a CommonJS file! (Update: I've released a module that works around this issue.)
And then there's Rollup, which apparently requires ESM to be u
| #!/bin/bash | |
| set -eo pipefail | |
| # Note to readers: this hook lives within a phabricator instance that runs from a xiimoon/phabricator docker image. | |
| # Additionally, you'll need: | |
| # - jq | |
| # - cmp | |
| # - mounting a valid conduit api token to /env_dir/PHABRICATOR_CONDUIT_TOKEN | |
| # |
See it in action (disabled vs enabled)
Apply the userscript using greasemonkey or similar to urls like https://phabricator.wikimedia.org/notification/query/unread/
| import urllib.request | |
| import re | |
| import bs4 | |
| def soup_url(url): | |
| req = urllib.request.Request(url) | |
| with urllib.request.urlopen(req) as resp: | |
| return bs4.BeautifulSoup(resp.read(), 'html.parser') |
