Simple way to setup an arm chroot for building packages for your arm devices. This is an alternative to cross-compiling where you are limited to only linking against the libs in your toolchain.
You can store the chroot wherever you like. I choose to store it in a disk-image which I mount to my filesystem.
Recently, there had been a call for blog posts reflecting 2017 and about which path Rust should choose in 2018.
First a few words about me. I was and still am a student, and most of my coding is for learning and because it is fun. Also, coding is a great excuse for procrastinating something more important :). Having contributed to open source codebases has helped me determine that I want to do this in a day job once I'm done with my studies.
I've heard about Rust somewhere around the 1.0 release in 2015. I don't know the details any more, but most likely it was a German tech news website. I've then read on about what Rust is and its promises like zero cost abstractions, fearless concurrency or the concept of safety really stood out. My background was C++ so I also quite liked the syntax. A bit later I decided to read the the book (first edition, back then
WAYLAND_PROTOCOLS=/usr/share/wayland-protocols | |
# wayland-scanner is a tool which generates C headers and rigging for Wayland | |
# protocols, which are specified in XML. wlroots requires you to rig these up | |
# to your build system yourself and provide them in the include path. | |
xdg-shell-protocol.h: | |
wayland-scanner server-header \ | |
$(WAYLAND_PROTOCOLS)/stable/xdg-shell/xdg-shell.xml $@ | |
xdg-shell-protocol.c: xdg-shell-protocol.h |
#!/usr/bin/python3 | |
from functools import partial | |
def colors16(): | |
for bold in [0, 1]: | |
for i in range(30, 38): | |
for j in range(40, 48): | |
print(f'\x1b[{bold};{i};{j}m {bold};{i};{j} |\x1b[0m', end='') | |
print() |