カテゴリー: Linux

PCでAndroid端末の画面転送と操作が出来るscrcpy

matoken 3件のコメント

Debian sid amd64環境ではパッケージがあるので簡単です，armhf/amd64/i386環境ではsnap版が存在します．その他幾つかのLinuxディストリビューションではパッケージがあったり，WindowsやmacOSでも動作するようです．

手元ではDebian sid amd64で動作しました．(Raspberry Pi OS armhfにsnap版を入れた環境ではエラーが発生．内容は未だ未確認)

Debian sid amd64環境だと以下のような感じで導入できました．このときAndroid端末は「開発者向けオプション」が有効になっていて，「USBデバッグ」が有効になっている状態でUSB接続されている必要があります．

Debian sid amd64環境での導入例
$ sudo apt install adb scrcpy (1)
$ lsusb (2)
  :
Bus 002 Device 013: ID 05c6:9024 Qualcomm, Inc. SDM439-MTP _SN:472BF8D8
  :
$ echo 'SUBSYSTEM=="usb", ATTR{idVendor}=="05c6" ATTR{idProduct}=="9024", MODE="0660", GROUP="plugdev", SYMLINK+="android%n"' \
| sudo tee -a /etc/udev/rules.d/51-android.rules (3)
$ sudo udevadm control --reload (4)
$ adb devices (5)
* daemon not running; starting now at tcp:5037
* daemon started successfully
List of devices attached
976d6a56        device
  1. 必要パッケージの導入
  2. AndroidのVID/PIDを確認(ここでは 05c6:9024 )
  3. adbコマンドが利用できるようにAndroid端末をudev roureに登録
  4. udev ruleを反映する
  5. adbコマンドで認識出来るのを確認

この状態で，scrcpy を実行することでAndroidの画面転送が出来ました．普通に操作も出来ます．
スリープ状態のときは画面が真っ黒ですが，マウス右クリックで解除されます．

$ scrcpy
INFO: scrcpy 1.14 <https://github.com/Genymobile/scrcpy>
/usr/share/scrcpy/s...93 bytes in 0.008s)
[server] INFO: Device: TINNO C330 (Android 9)
INFO: OpenGL shaders: ENABLED
INFO: Created renderer: opengl
INFO: Renderer: opengl
INFO: OpenGL version: 3.0 Mesa 20.2.4
INFO: Trilinear filtering enabled
INFO: Initial texture: 720x1280

20201210 21:12:59 2112960.resized20201210 21:12:31 2113779.resized20201210 21:12:30 2115127.resized

導入も簡単だしこれは便利．しかしメイン端末ではPCにUSB接続するとすぐに充電しなくなってしまうので長時間は使えません．

adb のワイヤレス接続の設定をすると別の端末や充電器で充電しながら利用できそうなので試してみました．

対象のAndroid端末をPCにUSB接続した状態で tcpip コマンドでリモート接続できるようにします．

$ adb tcpip 5555
restarting in TCP mode port: 5555

この状態でPCからAndroid端末を取り外し，Wi-Fi接続のIPアドレスを確認します．

PCでadbコマンドでAndroid端末に接続します．

$ adb connect <ANDROID_IP>>:5555

この状態で scrcpy コマンドを実行すると画面が表示され操作できます．充電器などに接続した状態でも利用できます :)

scrcpy には幾つかオプションがあります．便利そうなものとしては最大解像度を指定する -m, --max-size value で解像度を下げて表示できます，
-n, --no-control で表示だけで操作できなくします．
-r, --record file で画面を録画します．
-w, --stay-awake でscrcpyを実行中Android画面をロック，消灯しません．
-S, --turn-screen-off Android端末のスクリーンを消したまま操作できます．

ショートカットでは
Ctrl + h, マウス中キー でホームボタン，
Ctrl + r でAndroid画面回転，
Ctrl + s でアプリケーション切り替え，
辺りが便利そうです，

Ctrl + c でクリップボードのコピーなのですが，一旦Android側でコピーした後に Ctrl + c でPCへのクリップボードコピーのようです，Ctrl + v の貼り付けもAndroid感での貼り付けで，PCからAndroidのクリップボード貼り付けは Ctrl + Shift + v でした．

詳細は scrcpy --help を参照してください．

これでElectronアプリでPCで動かしているアプリをスマホで……とも思ったのですが日本語入力などはちょっと面倒．もう少し様子見しようと思います．

Raspberry Pi の温度管理をソフトウェアで頑張る

matoken コメントをする

この記事は日本Androidの会秋葉原支部ロボット部 Advent Calendar 2020 の12/07分の記事です．

内容は 日本Androidの会秋葉原支部ロボット部 第96回勉強会 で発表した内容を加筆修正したものです．

はじめに

Raspberry Pi という英国発の教育向けとして2012年に発売された安価なシングルボードコンピュータがあります．教育向けとして発売されましたが趣味にもよく使われています．OSは標準ではLinux(DebianベースのRaspberry Pi OS)が採用されています．

私はもっぱら省電力のLinuxマシンとして使うことが多いです．

トラブル

今夏空調のない部屋の自宅サーバの横でRaspberry Pi 3 model B + Raspberry Pi OS arm64(β)で計算をさせていたのですが，しばらく動かしていると固まるようになりました．

再起動すればしばらく動きますがしばらくするとやはり固まります．これをどうにか出来ないかと調べてみました．

ログの取得

まずはログを録ってみます．

crontabで1分毎に情報を記録
* * * * *       printf "`date +\%s`,`cat /sys/class/thermal/thermal_zone0/temp`,`echo "obase=2; ibase=16; \`vcgencmd get_throttled | cut -f2 -dx\`" | bc`,`vcgencmd measure_clock arm|cut -f2 -d=`\n" >> ~/.temp.log

内容はこんな感じです．(外気温度も録ればよかった)

UNIX Time
date +%s
SoC温度
/sys/class/thermal/thermal_zone0/temp
スロットリング周りのフラグ
vcgencmd get_throttled
arm周波数
vcgencmd measure_clock arm

ログがファイルに書かれる間にフリーズしてデータが失われるのを防ぐために /etc/fstab のマウントオプションに sync オプションも付けておきます．(再起動かremountで反映)

ログを取得している状態で負荷を掛けます．今回は /dev/urandom をcatすることで計算させました．今回のRaspberry Pi 3 model Bは4coreあるので4つ動かしています．

今回のテストで使った負荷(いつもはvanity address/vttとかとか)
$ cat /dev/urandom > /dev/null &
$ cat /dev/urandom > /dev/null &
$ cat /dev/urandom > /dev/null &
$ cat /dev/urandom > /dev/null &

熱が原因?

しばらく動かしてRaspberry Piが固まった後にログを確認してみます．
SoCの温度が85度を何度か記録した後に固まっているようです．
85度というのはRaspberry Pi OSでの標準のSoC制限温度のようです．この温度の5度前(標準では80度)からサーマルスロットリングが始まるようです．

サーマルスロットリングでクロックが下がって温度が下がれば問題無さそうだけど80度からクロックが下がっても85度を超えて固まってしまっているようです．
ベータ版のRaspberry Pi OS amd64を使っているせいかもしれないと思い，標準のRaspberry Pi OS armhf(32bit)版に変更して同様に試してみましたが同様の動きのようです．

正攻法としてはヒートシンク，ファンの増設や空調を入れるとよさそうですが，金欠なのでとりあえずソフトだけでどうにか出来ないかと試しました．

SoC制限温度を下げる

まずSoCの制限温度ですが，公式フォーラムで70度以下にしたほうがいいという書き込みを見かけました．逆に100度でも大丈夫という人も居るのですが安全側の70度にしてみます．

この設定は /boot/config.txt でパラメータを設定できます．以下は70度に設定たときの例です．この状態で再起動すると反映されます．

temp_limit=70

再起動後以下のコマンドで設定が反映されているか確認が出来ます．

$ vcgencmd get_config int | grep ^temp_limit=
temp_limit=70

この状態で負荷を掛けると70度を越えるくらいで固まりました．やはり制限温度を越えると固まってい舞うようです．

SoCの最大周波数を下げてみる

Raspberry Pi 3 model B のSoCは最大周波数1.2GHzです．これを下げてみます．

/boot/config.txt の arm_freq= で設定できます．以下は800MHzに設定したときの例です．再起動で反映されます．

arm_freq=800

再起動後に設定が反映されているか確認します．

$ vcgencmd get_config int | grep ^arm_freq=
arm_freq=800

この状態で負荷を掛けるとやはり固まります．まあサーマルスロットリングが効いても固まるので仕方がない感じです．

SoCの最小周波数を下げてみる(これが効くのでは?)

次にSoC最小周波数を下げてみます．既定値は600MHzで，サーマルスロットリングでもここまで下がっているのでこれを更に下げると温度が下がりそうな気がします．

/boot/config.txt の arm_freq_min= で設定できます．以下は400MHzに設定したときの例です．再起動で反映されます．

arm_freq_min=400

しかし再起動後に確認してみると600MHzより下には設定できないみたいで600MHzになってしまいます．

$ vcgencmd get_config int | grep ^arm_freq_min=
arm_freq_min=600

この状態で負荷を掛けるとやはり600Mhzまでしか下がらず固まります．

残念ながらRaspberry Pi のスロットリングでは無理そうです．

maxcpusでコアを制限してみる

Linuxのブートパラメータで maxcpus を指定することでコアを制限できます．Raspberry Pi の場合は /boot/cmdline.txt で設定できます．

設定後以下のコマンドで確認できます．

$ grep -o -E 'maxcpus=.{0,9} ' /proc/cmdline
maxcpus=1
$ grep ^processor /proc/cpuinfo | wc -l
1

これでCPU core1津で動作しています．しかし最大周波数を600MHzかつ1coreでも同様にフリーズしてしまいました．

cpufreqでクロック制御

IntelCPUのNotePCなどではcoufreqを使ってこのあたりの制御をするのですが，これでも600mHzより下には下げられないようで駄目でした．

LimitCPUで指定プロセスの制限を行う

LimitCPUは指定プロセスを監視し，CPU利用率や%で制限するプログラムです．Linux, MacOS, *BSDなどのUNIX-Likesystemで利用できます．
Raspberry Pi OSではcpulimitパッケージとしてパッケージングされており，コマンドもcoulimitです．

cpulimitの導入
$ sudo apt install cpulimit

cpulimitコマンドに制限したいプロセスIDやプロセス名と制限を指定することで動作します．

cat からはじまるプロセスを50%に制限
$ pgrep ^cat | xargs -n1 -I{} sh -c "cpulimit -p {} -l 50 -v &"

cpulimitで50%に制限してみたt頃温度が下がるのを確認できました．数日動かしても固まらなくなったようです．
定期的にSoCの温度を確認して制限を変更していくと良さそうでうs．

参考URL

LimitCPUはCPUlimitの開発が止まった後のフォークですが，その後CPUlimitが新しく開発が始まっているようです．詳細は以下のページを参照してください．

cgroupでCPUリソース制限(未確認)

LimitCPUが効いたので恐らくcgroupでのCPUリソース制限でも大丈夫そうです．(未確認)

おわりに

現在は気温も下がり制限などしなくても問題ありません．でもきっと来夏にまた起こると思うのでそこでまた確認するつもりです．

しかし，今回の解決方法はCPUのリソースを制限して温度を下げて居るので計算量は減っています．空調を入れたりCPUファンを導入するのが正攻法になるのかなと思います．
CPUファンはサードパーティーから各種発売されているのでそれらを使うかDIYする感じになると思います．

そういえば最近Raspberry Pi OSの設定コマンドの raspi-config の中に Set behaviour of GPIO fan というメニューが出来たり，Raspberry Pi 4には公式のCPUファンが発売されているのでこれらを使うのが良さそうです．

IFTTTで過去に設定したアプレットを参照する

matoken コメントをする

IFTTTからお知らせメールが届きました．(同じものが2通!)

Hey there,

As of today, your current IFTTT Standard plan no longer supports creating more than 3 Applets from scratch. You still have access to enable unlimited published Applets.

All but 3 of your recently active Applets have been archived. Sign in to view your Applets.

You may unarchive all of your archived Applets by upgrading to IFTTT Pro. Upgrading to Pro also unlocks our best tools for creators and unlimited Applet creation.

Upgrade

For more information, see What happens if I do not upgrade to Pro?

Or reply to this email and we’ll do our best to answer your questions.

—The IFTTT Team

無償アカウントの制限が始まったようです．

そんなに大事なものはもう無かったはずだけどと思いながら確認に行くとアプレットは3つだけしか操作できず，2つだけがアクティブで1つは非アクティブになっていました．非アクティブなアプレットは有効にすることが可能でした．

4つ目以降のアプレットはアーカイブされていてアーカイブページで一覧が確認でします．

しかし，タイトルくらいしか見えなくて中身が見えなくて内容が確認できません．

20201115 06:11:43 2814050

どうにか中が見えないかなと「Account settings」 → 「Export my data」でエクスポートを試してみました．

20201115 05:11:44 2769448

するとメールでjsonデータが飛んできました．
早速jqに食わせてみるとエラー．

$ jq . ~/Downloads/matoken.json
parse error: Invalid string: control characters from U+0000 through U+001F must be escaped at line 2, column 3

このメッセージは改行があったりするパターンぽいてことで削ってみます．また違うエラー．

$ cat ~/Downloads/matoken.json | tr -d '\n' | jq .
parse error: Invalid escape at line 1, column 18812

ファイルをよく見ると改行コードは \r\n で更にその後ろにスペースが入っているようです．

$ od -xc --endian=big ~/Downloads/matoken.json | lv
0001720    222c    226e    616d    6522    3a22    4946    5454    0d0a
          "   ,   "   n   a   m   e   "   :   "   I   F   T   T  \r  \n
0001740    2054    227d    7d2c    7b22    6465    7669    6365    5f74
              T   "   }   }   ,   {   "   d   e   v   i   c   e   _   t

てことでこんな感じでパースできました．

$ cat ~/Downloads/matoken.json | tr -d '\r\n ' | jq . | head
{
  "data": {
    "me": {
      "login": "matoken",
      "email": "matoken@gmail.com",
      "id": "126299",
      "profile_image_url": "https://fastly.4sqi.net/img/user/220x220/2608683-JGYT1JCMXPVUF2KL.jpg",
      "profile_username": "KenichiroMatohara",
      "timezone": "Osaka",
      "bio": null,

しかしWebから見るよりはいいけど詳細は載っていないようです．例えばアプレットの利用するモジュール名などはわかるけど，その詳細はわからない感じです．
でもだいたい何をやっていたかはわかるかな?

というのはIFTTTに止められる前にやるべきでしたね……．

環境
$ dpkg-query -W jq coreutils lv
coreutils       8.32-4+b1
jq      1.6-1
lv      4.51-7
$ lsb_release -dr
Description:    Debian GNU/Linux bullseye/sid
Release:        unstable
$ uname -m
x86_64

GNU Bashのbracketed pasteの設定

matoken 2件のコメント

Debian sid amd64環境で最近Bashにテキストを貼り付けると貼り付けた文字列が反転して即時反映されないようになっていました．
何らかの操作をすると反転は解除されて反映されます．改行の含まれた文字列を貼り付けて誤って実行されるというようなことが抑制できていい感じです．でも貼り付けただけで実行されたつもりになってしまうこともあったり．

便利だけどこれなんだろうと確認してみました．

Changelogを見てみます．
/usr/share/doc/bash/changelog.Debian.gz は殆どUpstreamへの追従．
/usr/share/doc/bash/changelog.gz を見るとそれらしいものが載っていました．

bash-4.4-alpha, bash-4.3-release.から Bracketed paste mode が入ったようです．
そしてbash-5.1-alpha, bash-5.0-releaseから既定値になたようです．(そして気づいた)

bash-4.4-alpha, bash-4.3-release.

b. There is a new bindable variable, `enable-bracketed-paste’, which enables
support for a terminal’s bracketed paste mode.

bash-5.1-alpha, bash-5.0-release.

h. Bracketed paste mode is enabled by default.

infoを見ると enable-bracketed-paste という項目で設定できるようです．

info bash
enable-bracketed-paste (On)
       When set to On, readline will configure the terminal in a way that will enable it to insert each paste into the editing buffer as a single string of characters, instead of treating
       each character as if it had been read from the keyboard.  This can prevent pasted characters from being interpreted as editing commands.
info bash
Readline Variables
    Readline has variables that can be used to further customize its behavior.  A variable may be set in the inputrc file with a statement of the form
       set variable-name value
or using the bind builtin command (see SHELL BUILTIN COMMANDS below).

実際に叩いてみます．こんな感じでoff/onできました．

$ bind 'set enable-bracketed-paste off'
$ bind 'set enable-bracketed-paste on'

~/.bashrc 辺りに書いておくと次回のbash起動時に反映されます．

その他
  • byobu-screenでは enable-bracketed-paste on しても利用できない?
  • tmuxでのCtrl+b Ctrl + ] での貼付け時には無視される?
  • Ubuntu 20.10 amd64の5.0-6ubuntu2では既定値で無効になっているけど enable-bracketed-paste on で有効に出来る
環境
$ dpkg-query -W bash
bash    5.1~rc2-1
$ lsb_release -dr
Description:    Debian GNU/Linux bullseye/sid
Release:        unstable
$ uname -m
x86_64

Byobu tmuxでファンクションキーを無効にする

matoken コメントをする

アドホックに切り替える

Ctrl+b shift + F12 でトルグ

設定ファイルに設定する

~/.byobu/keybindings.tmux の1行目に
source /usr/share/byobu/keybindings/f-keys.tmux.disable を追記．

Byobu tmuxを起動し直すか，Ctrl+b : :source-file ~/.byobu/keybindings.tmux で反映する．

Byobu GNU screenの場合はこちら

環境
$ dpkg-query -W byobu tmux
byobu   5.133-1
tmux    3.1b-1
$ lsb_release -dr
Description:    Debian GNU/Linux bullseye/sid
Release:        unstable
$ uname -m
x86_64

DebianでVSCodiumがアップデートできなくなって困る

matoken コメントをする

VSCodeのMicroSoftのバイナリブロブ等を除外したVSCodiumを使うのに以下のリポジトリを利用しています．Debianだとamd64, i386, arm64, armhfのArchtectureに対応していて便利です．

しかし最近アップデートに失敗します．

apt update に失敗する
Err:7 https://gitlab.com/paulcarroty/vscodium-deb-rpm-repo/raw/repos/debs vscodium InRelease
  429  Too Many Requests [IP: 192.168.1.102 3142]
  :
  :
W: Failed to fetch https://gitlab.com/paulcarroty/vscodium-deb-rpm-repo/raw/repos/debs/dists/vscodi
  :
  :

apt-cacher-ng を挟んでいるのでそこのキャッシュがおかしいのかなとか思いましたが https なのでキャッシュしていません．念の為デーモンを再起動しても変わらず．
直にアクセスしても同じステータスです．

proxyなしで直にアクセス
$ HTTP_PROXY='' w3m -dump_head https://gitlab.com/paulcarroty/vscodium-deb-rpm-repo/raw/repos/debs/dists/vscodium/InRelease | grep ^HTTP
HTTP/1.1 429 Too Many Requests

429 Too Many Requests ってことはサーバ側の問題かな?少し待てば復旧する?と思ったけど1日経っても状況は変わらず．

てことでsiteを見に行くと導入手順のsource.listのurlが変わっているようです．

Add the repository:

echo 'deb [signed-by=/etc/apt/trusted.gpg.d/vscodium-archive-keyring.gpg] https://paulcarroty.gitlab.io/vscodium-deb-rpm-repo/debs/ vscodium main' | sudo tee /etc/apt/sources.list.d/vscodium.list

これに合わせて自分のsource.listを書き換えました．( /etc/apt/sources.list, /etc/apt/sources.list.d/codium.list 等)

apt edit-sources <sourcefile>
-deb https://gitlab.com/paulcarroty/vscodium-deb-rpm-repo/raw/repos/debs/ vscodium main
+deb https://paulcarroty.gitlab.io/vscodium-deb-rpm-repo/debs/ vscodium main

鍵は変わっていないようでurlを書き換えてupdate&&upgradeを行うとOKでした．

apt updateが成功
Get:8 https://paulcarroty.gitlab.io/vscodium-deb-rpm-repo/debs vscodium InRelease [3,828 B]

最新になりました :)

$ codium --version
1.48.1
3dd905126b34dcd4de81fa624eb3a8cbe7485f13
x64

アイコンも変わったようです．

vscodium old 100 → vscodium 100

そいてこの記事を書くためにsiteを見直すと以下の記述に気づきました．はじめからこれを見ていれば……．

Warning: repository migrated to Gitlab Pages, update your configs

環境
$ dpkg-query -W codium apt dpkg
apt     2.1.10
codium  1.48.1-1598037458
dpkg    1.20.5
$ lsb_release -dr
Description:    Debian GNU/Linux bullseye/sid
Release:        unstable
$ uname -m
x86_64

SteamのOSごとのアプリケーション数を確認してみる

matoken コメントをする

あるPodcastでSteamのLinuxアプリは1割位ではという話があったのですが，そんなに少なくないだろうでもどのくらいだろう?と実際のところ知らなかったので確認してみました．

確認にはSteam検索の検索結果を使いました．
https://store.steampowered.com/search/

こんな感じのscriptを用意して，

steamcount.bash
#!/bin/bash

# Steam検索
# https://store.steampowered.com/search/
# ignore_preferences=1 個人設定に基づいたタイトルの除外の無効化
# https://store.steampowered.com/search/?ignore_preferences=1
# Windowsの検索
# https://store.steampowered.com/search/?ignore_preferences=1&os=win
# Mac OS Xの検索
# https://store.steampowered.com/search/?ignore_preferences=1&os=mac
# SteamOS + Linuxの検索
# https://store.steampowered.com/search/?ignore_preferences=1&os=linux

SERCH="https://store.steampowered.com/search/?ignore_preferences=1&os="
OSTYPE=("all" "win" "mac" "linux")
MATCH="results match your search."
declare -A COUNT

for OS in "${OSTYPE[@]}"
do
  COUNT[$OS]=$(LC_ALL=en_US.UTF-8 w3m -dump "$SERCH$OS" | grep "$MATCH" | cut -f1 -d' ' | tr -d ,)
  echo $OS,${COUNT[$OS]},$(awk "BEGIN { print ${COUNT[$OS]}/${COUNT[all]}*100 }")%
done

実行します．

$ bash ~/src/steamcount.bash
all,79831,100%
win,79654,99.7783%
mac,25443,31.8711%
linux,15673,19.6327%

Linuxの検索結果は15673本で，全体の19.6%でした．もっと多いと思いましたが案外少ないですね．
恐らく検索する範囲を近年にしたり，Windows用のアプリケーションをLinux環境で動かすProtonに対応したアプリケーションも入れるともっと多くなるのではないかと思うのですが，Steam検索ではその検索方法がわかりませんでした．

ちなみに以下は2015年3月の記事ですが，この記事によると2013年には50本，2014年に500本，(恐らく)2015年3月には1004本．このときに比べると現在の15673本というのはすごく増えている感じです．

SteamOSが大きな節目に到達…ゲームタイトル数1000に | TechCrunch Japan

SteamがこのLinuxベースのゲームOSをローンチしたのは2013年で、そのときはわずか50のゲームがあり、1年後には500タイトルに達した。今現在、ゲーム数は1004で、DLCなどのダウンロードするコンテンツや拡張パックも含めると1835になる。

新しいゲームならLinux対応が多いと思いリリースが新しい順にソートしてみるとWindowsのみ対応のアプリが多いですね．今見ると最新から14本はWindowsのみ対応．15本目にやっとWindows/Mac/Linuxに対応したゲームがでてきました．

https://store.steampowered.com/search/?sort_by=Released_DESC

Windows専用アプリケーションでもLinux版SteamのProtonで動かせたり，Protonで動かないのもでも別途Wine経由で動かせるものもあります(Lutrisを使うと便利)．

関連記事

basE91で少し効率よくバイナリをテキストに変換

matoken コメントをする

バイナリを利用できない環境でのデータ転送時にUNIX環境では古くは uudecode, uuencode が，日本のパソコン通信では ish などが使われていました．近頃は base64 がよく使われているように感じます．

これらのツールではバイナリをASCIIで表現するためサイズが大きくなってしまいます．でも全てのASCIIを使っていません．

今回見つけたbasE91はASCIIの0x21-0x7Eのうち -, \, ' を除いた91文字を使ってデコードすることで効率よくするもののようです．

早速試してみます．Debianパッケージがないかなと探しましたがありませんでした．

(以前要望されたことはあるよう #706078 – RFP: base91 — base91 encoder/decoder – Debian Bug report logs )

sourceを貰ってきてmakeします．
※hashは「 basE91 – Browse /basE91/0.6.0 at SourceForge.net 」で確認できる．

$ wget http://downloads.sourceforge.net/base91/base91-0.6.0.tar.gz
$ md5sum base91-0.6.0.tar.gz
e227841d900cc463a162bd79775aeb54  base91-0.6.0.tar.gz
$ sha1sum base91-0.6.0.tar.gz
00cfd573ec8b3d0160dbf53e2c7a49b99a1aa720  base91-0.6.0.tar.gz
$ tar tvf base91-0.6.0.tar.gz
-rw-r--r-- 0/0             575 2005-06-25 00:00 base91-0.6.0/AWK/README
-rwxr-xr-x 0/0             727 2006-11-02 05:13 base91-0.6.0/AWK/b91dec.awk
-rw-r--r-- 0/0             932 2006-09-04 03:00 base91-0.6.0/PHP4/README
-rw-r--r-- 0/0            1513 2006-11-02 05:13 base91-0.6.0/PHP4/base91.php
-rw-r--r-- 0/0             149 2006-09-04 03:00 base91-0.6.0/test/Makefile
-rw-r--r-- 0/0            4265 2006-11-02 05:13 base91-0.6.0/test/test.sh
-rw-r--r-- 0/0             332 2006-08-25 17:00 base91-0.6.0/DOS-asm/readme.txt
-rw-r--r-- 0/0            3487 2006-11-02 05:13 base91-0.6.0/DOS-asm/b91enc.asm
-rw-r--r-- 0/0            5034 2006-11-02 05:13 base91-0.6.0/Java/b91cli.java
-rw-r--r-- 0/0            3297 2006-11-02 05:13 base91-0.6.0/Java/basE91.java
-rw-r--r-- 0/0            1526 2006-11-02 05:13 base91-0.6.0/Java/license.txt
-rw-r--r-- 0/0             793 2006-11-02 05:13 base91-0.6.0/Java/readme.txt
-rw-r--r-- 0/0             112 2006-09-04 03:00 base91-0.6.0/Java/manifest.mf
-rwxr-xr-x 0/0             178 2006-11-02 05:13 base91-0.6.0/Java/build_jar.sh
-rw-r--r-- 0/0            7502 2006-11-02 05:13 base91-0.6.0/cli.c
-rw-r--r-- 0/0            5066 2006-11-02 05:13 base91-0.6.0/base91.c
-rw-r--r-- 0/0            1501 2006-11-02 05:13 base91-0.6.0/LICENSE
-rw-r--r-- 0/0             561 2006-11-02 05:13 base91-0.6.0/base91.h
-rw-r--r-- 0/0            2360 2006-11-02 05:13 base91-0.6.0/README
-rw-r--r-- 0/0            1762 2006-11-02 05:13 base91-0.6.0/base91.1
-rw-r--r-- 0/0             903 2006-09-04 03:00 base91-0.6.0/Makefile
-rw-r--r-- 0/0            2330 2006-11-02 05:13 base91-0.6.0/NEWS
$ tar xf base91-0.6.0.tar.gz
$ cd base91-0.6.0
$ make
$ ./base91 -h
Usage: base91 [OPTION]... [FILE]
basE91 encode or decode FILE, or standard input, to standard output.

  -d, --decode          decode data
  -m SIZE               use SIZE bytes of memory for buffers (suffixes b, K, M)
  -o, --output=FILE     write to FILE instead of standard output
  -v, --verbose         verbose mode
  -w, --wrap=COLS       wrap encoded lines after COLS characters (default 76)
  --help                display this help and exit
  --version             output version information and exit

With no FILE, or when FILE is -, read standard input.

encodeしてdecodeしてみます．
当たり前ですが，encode, decodeしてもdiffもhashも同じです．

$ ./base91 ./base91 -o ./base91.base91
$ ./base91 -d ./base91.base91 -o ./base91.tmp
$ diff ./base91 ./base91.tmp
$ sha512sum ./base91
bc903be7c5b694841a9d0303351846f80f4798ad8848e8f298cf2c4818c68a2270b065db495b969503b25cdf672632e1cced18094f935fed47b75718c3c3e976  ./base91
$ ./base91 ./base91 | ./base91 -d | sha512sum
bc903be7c5b694841a9d0303351846f80f4798ad8848e8f298cf2c4818c68a2270b065db495b969503b25cdf672632e1cced18094f935fed47b75718c3c3e976  -

basE91, base64, base32, uudecode で変換してみます．
basE91 が一番小さいですね

$ ls --block-size=1 -s ./base91
16384 ./base91
$ ./base91 ./base91 | wc -c
17340
$ base64 ./base91 | wc -c
19615
$ uuencode ./base91 - | wc -c
20024
$ base32 ./base91 | wc -c
23538

圧縮すると大分小さくなります．圧縮のほうがずっと効きますね．

$ xz -c ./base91 | wc -c
4528
$ xz -c ./base91 | ./base91 | wc -c
5640
$ xz -c ./base91 | base64 | wc -c
6120
$ xz -c ./base91 | uuencode - | wc -c
6260
$ xz -c ./base91 | base32 | wc -c
7344

他のファイルも試してみます．/usr/bin 以下のファイルを適当に見繕って比較x5です．

#!/bin/bash

XZ=`mktemp`
for i in `seq 1 5`
do
  CMD=`find /usr/bin -type f | shuf -n 1`
  echo $CMD
  echo -n "raw  "
  stat -c %s $CMD
  xz -9 -c $CMD > $XZ
  echo -n "xz "
  stat -c %s $XZ
  echo -n "xz.uu  "
  uuencode $XZ - | wc -c
  echo -n "xz.base64  "
  base64 $XZ | wc -c
  echo -n "xz.base91  "
  base91 $XZ | wc -c
done
rm $XZ
$ bash ./bin2ascii.bash | column -t
/usr/bin/lxc-snapshot
raw                          27632
xz                           6756
xz.uu                        9328
xz.base64                    9127
xz.base91                    8418
/usr/bin/dh_installtmpfiles
raw                          3263
xz                           1540
xz.uu                        2144
xz.base64                    2084
xz.base91                    1917
/usr/bin/pbmtogo
raw                          10384
xz                           3164
xz.uu                        4380
xz.base64                    4276
xz.base91                    3942
/usr/bin/chartread
raw                          3966528
xz                           772956
xz.uu                        1064980
xz.base64                    1044169
xz.base91                    963047
/usr/bin/spamassassin
raw                          29898
xz                           9608
xz.uu                        13258
xz.base64                    12981
xz.base91                    11971

おまけ?armelでstatic linkなバイナリを作ってみました．Sipeed Lichee Nano で動かないかな?と．

$ git diff HEAD~~ Makefile
diff --git a/Makefile b/Makefile
index 246aede..129acff 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
-CFLAGS = -Wall -W -O2
-LDFLAGS = -s
+CFLAGS = -static -Wall -W -O2
+LDFLAGS = -static -s

-CC = gcc
+CC = arm-linux-gnueabi-gcc
 INSTALL = install
 INSTALL_DATA = $(INSTALL) -m 444
 INSTALL_PROGRAM = $(INSTALL) -m 555

qemu-arm-static では動くのを確認したけど実機では未確認です．

$ file ./base91
./base91: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, BuildID[sha1]=88ec4ccbf69c4bb41640b5de63b6b5373b7e5365, for GNU/Linux 3.2.0, stripped
$ ldd ./base91
        not a dynamic executable
$ echo 😺 | qemu-arm-static ./base91 | pee cat "qemu-arm-static ./base91 -d"
=~m6xHA
😺

以下にバイナリとuuencodeしたものが置いてあります．

blog元のmemo

環境
$ dpkg-query -W gcc-10-arm-linux-gnueabi qemu-user-static gcc coreutils sharutils
coreutils       8.32-3
gcc     4:10.1.0-1
gcc-10-arm-linux-gnueabi        10.2.0-3cross2
qemu-user-static        1:5.0-13
sharutils       1:4.15.2-5
$ lsb_release -dr
Description:    Debian GNU/Linux bullseye/sid
Release:        unstable
$ uname -m
x86_64

Raspberry Pi OS/Debian/Ubuntuでの既定のPython切り替え

matoken コメントをする

最近使うPythonアプリはPython3が多くなっています．Python2のEoLが迫っているので正しいのですが，手元の環境では python コマンドは python2 に向いています．python3 コマンドを叩けばいいのですが，これを python3 に向けられないかなと試してみました．

Raspberry Pi OS arm64(busterベース)でのPython確認してみます．python コマンドは python2.7 を呼ぶようになっています．

$ python --version
Python 2.7.16
$ ls -l `which python`
lrwxrwxrwx 1 root root 7  3月  5  2019 /usr/bin/python -> python2
$ ls -l `which python2`
lrwxrwxrwx 1 root root 9  3月  5  2019 /usr/bin/python2 -> python2.7
$ ls -l `which python3`
lrwxrwxrwx 1 root root 9  3月 26  2019 /usr/bin/python3 -> python3.7

update-alternatives で管理されてるのかな?と思いましたが設定がなさそうです．

$ update-alternatives --get-selections|grep -i ^python

update-alternatives を手動で設定してみます．
これで python コマンドが python3.7 を呼ぶようになりました．

$ sudo update-alternatives --install /usr/bin/python python /usr/bin/python2.7 1
update-alternatives: /usr/bin/python (python) を提供するために自動モードで /usr/bin/python2.7 を使います
$ sudo update-alternatives --install /usr/bin/python python /usr/bin/python3.7 2
update-alternatives: /usr/bin/python (python) を提供するために自動モードで /usr/bin/python3.7 を使います
$ ls -l `which python`
lrwxrwxrwx 1 root root 24  7月 28 08:47 /usr/bin/python -> /etc/alternatives/python
$ python --version
Python 3.7.3
$ update-alternatives --query python
Name: python
Link: /usr/bin/python
Status: auto
Best: /usr/bin/python3.7
Value: /usr/bin/python3.7

Alternative: /usr/bin/python2.7
Priority: 1

Alternative: /usr/bin/python3.7
Priority: 2

切り替えたいときはこんな感じで選択肢なおせばok．

$ sudo update-alternatives --config python
alternative python (/usr/bin/python を提供) には 2 個の選択肢があります。

  選択肢    パス              優先度  状態
------------------------------------------------------------
* 0            /usr/bin/python3.7   2         自動モード
  1            /usr/bin/python2.7   1         手動モード
  2            /usr/bin/python3.7   2         手動モード

現在の選択 [*] を保持するには <Enter>、さもなければ選択肢の番号のキーを押してください:

Debian asid amd64, Ubuntu 20.04 LTS amd64 でも設定してみました．

Debian sid amd64
$ update-alternatives --query python
Name: python
Link: /usr/bin/python
Status: auto
Best: /usr/bin/python3.8
Value: /usr/bin/python3.8

Alternative: /usr/bin/python2.7
Priority: 1

Alternative: /usr/bin/python3.7
Priority: 2

Alternative: /usr/bin/python3.8
Priority: 3
Ubuntu 20,04 LTS amd64
$ update-alternatives --query python
Name: python
Link: /usr/bin/python
Status: auto
Best: /usr/bin/python3.8
Value: /usr/bin/python3.8

Alternative: /usr/bin/python2.7
Priority: 1

Alternative: /usr/bin/python3.5
Priority: 2

Alternative: /usr/bin/python3.8
Priority: 3

てことで python コマンドが python3 になりました．しかしシステムワイドな設定なのでシステムのプログラムなどで問題が出るかもしれないですね．
問題が起こったらpython2に戻しましょう．

Rasoberry Pi OS amd64
$ dpkg-query -W python python3
python  2.7.16-1
python3 3.7.3-1
$ lsb_release -dr
Description:    Debian GNU/Linux 10 (buster)
Release:        10
$ uname -m
aarch64
$ cat /proc/device-tree/model&&echo
Raspberry Pi 3 Model B Rev 1.2
Debian sid amd64
$ dpkg-query -W python python3 python3.7
python  2.7.17-2
python3 3.8.2-3
python3.7       3.7.7-1+b1
$ lsb_release -dr
Description:    Debian GNU/Linux bullseye/sid
Release:        unstable
$ uname -m
x86_64
Ubuntu 20.04 LTS amd64
$ dpkg-query -W python python3 python3.7
python  2.7.17-1
python3 3.8.2-0ubuntu2
python3.7
$ lsb_release -dr
Description:    Ubuntu 20.04.1 LTS
Release:        20.04
$ uname -m
x86_64

Sipeed Lichee Nanoでhello world

matoken 1件のコメント

2020-07-23低レベル勉強会に参加しました．Zoom.usでの開催でした．

内容はLinux名刺的なものを開発しようという内容で，リファレンスとしてSDカードサイズの小さなLinuxの動作するarmコンピュータのSipeed Lichee Nanoを使いました．

欲しい場合は1000円ちょいくらいからで入手できそうです．

Lichee Nanoを持っていない人はリモートで触れるようにしてあったので持っていない私も楽しめました．

このリモート開発の仕組みはLichee NanoとRaspberry PiをUSB経由のUARTで接続し，Raspberry PiでGNU screenを起動，ssh経由でGNU screenに繋いで操作という感じです．
GNU screenをGotty等にするとウェブブラウザで参加できてちょっと便利かもと思ったりも．(GoTTYは開発止まってるように見えるから別のもののほうがいいかもしれない)

Lichee Nanoで何かを動かしたい．armだけどarmhf動くのかな?とりあえずなにか転送して動かしてみようと．

とりあえずDebianのarmhfバイナリをuuencodeしてコピペで転送してみます.これが動けばDebianのパッケージ群が利用できるかもだけど……．

まずは簡単そうなfortuneを試します.

Debian sidでfortune-modパッケージのarmhfバイナリパッケージをダウンロードして展開(add archtecture armhfしてある環境)
$ apt download -t armhf fortune-mod
$ unar fortune-mod_1.99.1-7+b1_armhf.deb
$ cd fortune-mod_1.99.1-7+b1_armhf
$ tar xf data.tar.xz
$ cd usr/games

Lichee Nanoはserialで接続されていて，Internetには繋がっていないのでバイナリファイルの転送にはuudecode/uuencodeを使いました．久々です．
手元のGNU sharutils 4.15.2のuudecodeにはbase64を使う -m, --base64 があるので良さそう．と思ったけどLichee Nanoの方はbusyboxのもので非対応でした．

ローカル端末で圧縮してuuencodeしてクリップボードへ
$ gzip -c fortune | uuencode fortune.gz > fortune.gz.uu
$ cat fortune.gz.uu | xclip
リモートで伸張して解凍
# cat | uudecode    #ここでクリップボードから貼り付け
# zcat fortune.gz > fortune
# rm fortune.gz

そして…​…​

# ./fortune
-sh: ./fortune: not found
# ldd ./fortune
checking sub-depends for 'not found'
checking sub-depends for '/lib/libc.so.6'
/lib/ld-linux.so.3 (0xb6fa0000)
librecode.so.0 => not found (0x00000000)
libc.so.6 => /lib/libc.so.6 (0x00000000)
/lib/ld-linux.so.3 => /lib/ld-linux.so.3 (0x00000000)

これを動かすのはダイナミックリンクされているものを用意してあげないといけないのでストレージの容量的に難しいですね．

ここではgzipで圧縮しましたが，Lichee Nanoのbusyboxにxzがありました．gzipよりxzにしたほうが小さくなりますね．試してみるとこんな感じでした．$ xz -c fortune | uuencode fortune.xz > fortune.xz.uu

サイズ比較
-rw-r--r-- 1 matoken matoken 22368 Jul 23 15:11 fortune #元ファイル
-rw-r--r-- 1 matoken matoken 30844 Jul 23 14:58 fortune.uu #uudecode
-rw-r--r-- 1 matoken matoken 14975 Jul 23 15:08 fortune.gz.uu #zip + uudecode
-rw-r--r-- 1 matoken matoken 13047 Jul 23 15:47 fortune.xz.uu #xz + uudecode

そういえばあまり有名ではないですがbasE91なんてものもあります．base64よりサイズが小さくなりますが導入からやらないといけないのでちょっと面倒．

Hello worldを試してみます．適当にプログラムを用意してスタティックリンクでコンパイルしてみます．

$ cat hello.c
#include <stdio.h>
int
main(void)
{
    printf("Hello, world!\n");
    return 0;
}
$ gcc -static ./hello.c
$ ./a.out
Hello, world!
$ ls -l a.out
-rwxr-xr-x 1 pi pi 571120 7月 23 16:18 a.out

でかい…​…​

とりあえずでかいのはおいといてこれだとarm64なので動くはずがない．ということでクロスコンパイル環境を用意します．

今回試したホストはDebian sid amd64/Ubuntu 20.04 LTS arm64/Raspberry Pi OS arm64です．いずれも同じ手順でOKでした．

crossbuild-essential-<arch> パッケージで各種アーキテクチャの環境が導入できるようです．

$ apt-cache search crossbuild-essential-
crossbuild-essential-amd64 - Informational list of cross-build-essential packages
crossbuild-essential-arm64 - Informational list of cross-build-essential packages
crossbuild-essential-armel - Informational list of cross-build-essential packages
crossbuild-essential-armhf - Informational list of cross-build-essential packages
crossbuild-essential-i386 - Informational list of cross-build-essential packages
crossbuild-essential-powerpc - Informational list of cross-build-essential packages
crossbuild-essential-ppc64el - Informational list of cross-build-essential packages
crossbuild-essential-s390x - Informational list of cross-build-essential packages
crossbuild-essential-mips - Informational list of cross-build-essential packages
crossbuild-essential-mips64 - Informational list of cross-build-essential packages
crossbuild-essential-mips64el - Informational list of cross-build-essential packages
crossbuild-essential-mips64r6 - Informational list of cross-build-essential packages
crossbuild-essential-mips64r6el - Informational list of cross-build-essential packages
crossbuild-essential-mipsel - Informational list of cross-build-essential packages
crossbuild-essential-mipsr6 - Informational list of cross-build-essential packages
crossbuild-essential-mipsr6el - Informational list of cross-build-essential packages

沢山あります．今回はarmlf/armhfの crossbuild-essential-armel, crossbuild-essential-armhf を導入しました．

$ sudo apt install crossbuild-essential-armel crossbuild-essential-armhf

gccだけでいい場合はarmlfは gcc-arm-linux-gnueabi，armhfは gcc-arm-linux-gnueabihf だけでOKです．

まずは arm-linux-gnueabihf-gcc を使ってarmhfのバイナリを作ります．

$ /usr/bin/arm-linux-gnueabihf-gcc -static ./hello.c
$ strip a.out
$ xz -c a.out | uuencode a.out.xz > a.out.xz.uu

armhfは駄目そうです．

# cat | uudecode
^d
# xzcat ./a.out.xz > ./a.out
# chmod +x ./a.out
# ./a.out
Segmentation fault

次は gcc-arm-linux-gnueabi でarmlfのバイナリを作って試すと動きました．

$ /usr/bin/arm-linux-gnueabi-gcc -static ./hello.c
$ strip a.out
$ xz -c a.out | uuencode a.out.xz > a.out.xz.uu
# cat | uudecode
^d
# xzcat ./a.out.xz > ./a.out
# chmod +x ./a.out
# ./a.out
Hello, world!
# /usr/bin/time -f "%M KB" ./a.out
Hello, world!
2144 KB

この辺りで今回は時間切れ．次回の同じような感じになりそうです．興味のある方は以下のページから．

とりあえずarmelのバイナリが動くようなのがわかったので面白そうな小さなプログラムを試そうかなと思っています．cowsayとか好きなんだけどこれはPerlなので容量的に難しそう．とりあえずfortuneあたりかな?

以前PQI Air PenでやったようにSD cardを用意してそこにDebian armlf環境を展開してchrootとかもできそうです．