There is current no support for the NanoPi R2S in ArchLinuxArm, but it's possible to run it using the generic aarch64 installation.
dd (sectors 32 to 32767) everything before the partition, except the partition table)./dev/mmcblk0p1 at offset of 32768 sectors (16384 KiB):Device Boot Start End Sectors Size Id Type
| #!/bin/bash | |
| # Update on 2024/05/29 | |
| # 1. use wget to fetch latest frp version when curl was not installed | |
| # 2. Remind users that frp will be run in non-root user | |
| # 3. Add CI | |
| # | |
| # Update on 2024/04/13 | |
| # 1. Improved OS compatibility: try wget and then curl for downloading files. | |
| # | |
| # Update on 2024/01/26 |
| git clone --single-branch --depth=1 https://github.com/emacs-mirror/emacs.git | |
| cd emacs/ | |
| sudo apt install -y autoconf make gcc texinfo libxpm-dev \ | |
| libjpeg-dev libgif-dev libtiff-dev libpng-dev libgnutls28-dev \ | |
| libncurses5-dev libjansson-dev libharfbuzz-dev | |
| ./autogen.sh | |
| ./configure --with-json --with-modules --with-harfbuzz --with-compress-install \ | |
| --with-threads --with-included-regex --with-zlib --with-cairo --without-rsvg\ | |
| --without-sound --without-imagemagick --without-toolkit-scroll-bars \ | |
| --without-gpm --without-dbus --without-makeinfo --without-pop \ |
Install Docker CE and nftables:
| set -eu | |
| set -x | |
| # create a `cmake` directory and extract cmake into there | |
| # build cmake in there, and install to prefix | |
| PREFIX=$HOME/software/cmake-3.17.0-rc3 | |
| wget -SL https://github.com/Kitware/CMake/releases/download/v3.17.0-rc3/cmake-3.17.0-rc3.tar.gz | |
| mkdir -p cmake-3.17.0-rc3.src |
I tried the WSL and it isn't quite seamless enough for me. I ran in to problems when editing in VSCode and having watchers on my files (ng serve, dotnet watch run, etc.). In addition, I kept running in to problems that only manifest themselves when running in WSL. For example, this issue with doing production builds and the terser plugin has made many a developer rage-quit on using WSL. Just figuring out that it was an issue with the WSL took a lot of time.
That terser plugin issue was never resolved and I ended up having to keep a git bash window open in addition to my WSL console window so I could do production builds. To make matters worse, my npm packages were platform-dependent so I couldn't use the same project folder. So, my procedure was: commit whatever changes to test branch, push to repo, git pull on my "windows" project folder, and do a production build there
This is a bit of a thought exercise. I doubt it’s perfect and I’m hoping for opinions and corrections with the goal of a well reasoned practical approach.
One way to look at type declarations in a static language is as a test which picks up potential incompatible code paths. E.g. data passed is incompatible with code.
In static languages the effort to write the test is reduced by virtue of being declared inline with the code and inference allows a few annotations to permeate - having said that we can achieve a similar results in Clojure.
