Stumbled upon an old snippet of code implementing a 32bit-word Mersenne Twister and visualizing the output space distribution using ANSI escape sequences in the terminal.
This is not very useful, but by running it with various parameters and seed one can notice some dead zones where very few values are produced (especially visible when using a 64x64 space division). Of course it is common knowledge that this PRNG is not cryptographically secure, and has otherwise very good properties for other uses. Nevertheless a bit of an intriguing curiosity.
This was originally posted in the previous version of this blog, so here it is again.
Having a look at the state of Linux namespaces from a system administration perspective, I found myself confused by incomplete or misleading examples. So here’s a breakdown of what worked for me as a test setup on Debian Sid.
The objective is simple: run a bash shell in a pid namespace with it’s own network namespace, bridged with the host’s network.
It turns out that in the current state of Debian Sid/unstable, there a few confusing package dependencies as gqrx-sdr depends on libgnuradio-*3.7.5, and not the most recent 3.7.8 versions which are installed by the gnuradio package. Furthermore it also depends on libgnuradio-osmosdr0.1.3 which depends on some libboost packages which break with the recent libstdc++6 ABI change.
To get around this without too much recompile pain, one can install gnuradio 3.7.8 (+ gnuradio-dev) and manually compile libgnuradio-osmosdr, gr-osmosdr and gqrx-sdr.
As of yesterday, the latest revisions of osmocom and the 2.3.2 source of gqrx-sdr were compiling without issues.
I haven’t had a chance to test it much yet, will edit with more notes when I do.
EDIT: It works. Just make sure to have libhackrf-dev installed before compiling the osmosdr gnuradio extension, otherwise hackrf devices won’t show up in gqrx.
Today, loading a simple VM on my Lenovo X201 (Debian Sid) turned into a wild four hour goose chase of nonsense.
So I’ll share the details here and hopefully that’ll save someone the same trouble, as this was quite obscure…
It started with a Linux amd64 VMWare disk image I wanted to load into VirtualBox and systematically got the following error:
VT-x is disabled in the BIOS. (VERR_VMX_MSR_VMXON_DISABLED).