Check it out, I made an appearance on the Ship It! podcast! It was a great time chatting with Justin and Autumn and I hope this will kick start my podcast-era 😎.
Dave Eddy has learned systems programming the traditional way with books and man pages. Now he’s sharing what he’s learned, starting with bash.
Ship It! 124: You suck at programming – Listen on Changelog.com
This guide will show how to install Void Linux as a guest on OmniOS using hardware virtualization with bhyve.
To get started, first install zadm on OmniOS inside the global zone.
This tool makes creating and managing zones simple and is reminiscent of the
vmadm command on SmartOS.
Install zadm:
pkg install zadm
pkg install zones/brand/bhyve
I personally use this config for zadm (shoutouts to
@papertigers for this), but feel free to customize this as you
like.
I wrote a computer program to generate piano music on the command line. The generation is done with a simple algorithm to create patterns in MIDI format, which is then imported into my DAW to process the data and turn it into music. There is no AI or Machine Learning in this algorithm - the music is programmatically generated and this video covers the algorithm that I created in detail.
I Made a Computer Program to Generate Piano Music
Download plex-install-manager from:
https://github.com/bahamas10/plex-install-manager
Install deps:
xbps-install -S binutils tar curl xz
Create user and directories needed:
useradd -s /bin/false -d /var/empty _plex
mkdir /opt/plex /opt/plex/src /opt/plex/data
chown _plex:_plex /opt/plex/data
Install Plex:
In 2013, I wrote a program in Node.js called sshp. This was right
around the time I was investing heavily into learning node, and
honestly having a blast doing it. Node is quick and fun to write, and with
only a couple hundred lines of code, I was able to write node-sshp.
node-sshp is a command line utility that acts as a parallelizer for ssh.
It works by taking in a file containing a list of hosts to connect to and
looping over each host firing off an ssh command in parallel (with a
configurable maximum number of concurrent processes). The tool’s description
is:
sshpmanages multiple ssh processes and handles coalescing the output to the terminal. By default,sshpwill read a file of newline-separated hostnames or IPs and fork ssh subprocesses for them, redirecting the stdout and stderr streams of the child line-by-line to stdout ofsshpitself.
Writing this tool in Node was an obvious choice at the time: the company I was working for was using Node heavily, and this tool was written specifically to be used at my job. Managing multiple concurrent child processes and IO streams also made Node the obvious choice.
Super Mario 64 is one of my all-time favorite games. Last year, the source code for the decompilation project was made available to the public. I won’t go into detail on the decompilation project itself (see this post here for more information), but instead will focus on getting Super Mario 64 compiled on Void Linux.
A couple of dependencies will need to be installed that will be used throughout
the installation process. Note that root privileges are only required in
commands where sudo is used - the rest of the commands can be run as an
unprivileged user.
sudo xbps-install git
sudo xbps-install make
sudo xbps-install wget
mkdir ~/dev ~/src
For this guide, the sm64 source code will be checked out into ~/dev, and the
required dependencies that are installed manually will be in ~/src, of which
there are 2:
qemu-irixbinutils-mips64To install this package, I found it easiest to take the qemu-irix release as a
.deb file from the n64decomp GitHub organization and extract the deb
myself.
COAL, or Cloud-on-a-Laptop, is an
easy way to run and test SmartOS and the Triton
Stack in a self-contained VM meant to be run
on a laptop. The sdc-headnode
repository makes a lot of assumptions when building a COAL image about using
VMWare for virtualization on an OS X laptop. However, with some modifications
it is possible to run COAL on Linux via KVM managed through virt-manager.
To get virt-manager setup and running on Void Linux, you can follow my guide
KVM Virtualization with virt-manager on Void
Linux.
Before getting started with the COAL building process, you can choose to enable
nested virtualization if your hardware supports it. This is required if you
would like to run bhyve zones on your COAL setup. Note that this setup
assumes an Intel CPU.
You can check if your CPU supports nested virtualization by running:
$ grep ^flags /proc/cpuinfo | grep -c ' vmx '
8
Running and managing virtual machines on Linux is very easy using the virt-manager GUI program. Under the hood, the virtualization technology takes advantage of KVM (Kernel Virtal Machine) in the Linux kernel. The result of both of these together is fast and efficient hardware virtual machines with a really easy and straightforward GUI to manage them.
For this post, I’ll be using the following tools I’ve talked about in my blog post Using Void Linux as my Daily Driver:
Install the following packages to get started:
sudo vpm i virt-manager libvirt qemu
Start the services that are created by these packages:
sudo ln -s /etc/sv/libvirtd /var/service
sudo ln -s /etc/sv/virtlockd /var/service
sudo ln -s /etc/sv/virtlogd /var/service
Use vsv to check the status of the services:
sudo vsv status virt
Running a Bitcoin full node is a great way to ensure the health and integrity of the decentralized Bitcoin network. This blog post is meant to be a guide for compiling, running, and monitoring a Bitcoin full node on a server, and as such won’t delve too much into the specifics as to what the node does, or why it’s important to the network health. If you want to know more check out 6 Reasons To Run a Bitcoin Full Node.
Put simply, running a full node will add to the large number of full nodes running across the world to support the Bitcoin network. The nodes ensure the rules of the protocol and consensus algorithms in place are upheld and enforced, which is what fundamentally allows Bitcoin to work and function the way it should.
Miners create new blocks and submit them to the network for verification - it’s the job of the full nodes to verify these blocks (groups of transactions) and ultimately accept or reject them based on their validity. Every full node will verify the validity of any and all blocks submitted to the network and, for each block, decide if it will be the next new block in the chain or whether it should be thrown out in the case that it is invalid (by either a bug in the mining software or a bad actor trying to undermine the network). Full nodes are the final arbiters when it comes to determining which transactions are valid or invalid.
I provisioned a fresh SmartOS 16Q4 LTS instance with the following JSON payload:
