SVX日記

　 SVXとは全然関係ないのだが、私は自分のWindowsPCにcygwinという擬似Linux環境を入れて使用している。開発(RubyやPICアセンブラ等)を行う場合、GUIでウダウダやるより、CUIでバッチやヒストリを活用したほうが早くて効率的だからである。

　 ところがこのcygwinというやつ、インストールやアップグレードするたびに必ず問題を起こす。ある日、cygwinインストーラを使って全パッケージの最新バージョンへの更新を行ったら、秋月のPICライタ付属のアセンブラpa.exeが、起動時にパーミッションエラーを出すようになり起動しなくなってしまった。どうも、WIN32バイナリ全部が起動しなくなっているらしい。なんじゃそら。

　 他にも、postgresqlによるDBアプリが名前解決できなくなったり、apache経由のcgiでだけtcp接続ができなくなったりしたことがある。どれも別のマシンで発生しているが、共通しているのは最新版のインストール後というタイミングだ。

　 毎度cygwin.dllのみを元のバージョンに戻すと再び動き出すので、問題は間違いなくcygwinのベースパッケージにあるハズなのだが……。

　 ただ、救いはこのcygwinのインストーラのデキが大変によいコト。マウスでポチポチするだけでインストールやアップグレード自由自在。インストール元にローカルファイルを指定すればダウングレードもバッチリ。個人的にはDebianのapt-getに匹敵するデキだと思う。

　 と、いうわけでcygwinをお使いの諸兄はなにかヘンだと思ったら、インストーラを利用してダウングレードしてみよう。解決するかもしれない。ちょっと再起動が面倒だけどね。

　 今日はガシガシとハンダ付けである。例によって、トランジスタのベースへの制限抵抗を忘れていたので、追加する。と、いつものように、基板の上がゴチャゴチャしてきた。まー、部屋が散らかっているオイラにとっては、少しゴチャゴチャしているくらいが、落ち着くのだけれども。

　 3端子レギュレータはトランジスタ型のパッケージを使う予定であったが、3.3Vの表面実装しか手持ちになかったので、それを使う。配線のレイアウトが変わるが、適当にアドリブをきかせながらハンダ付け。よっしゃ。完成。

　 一応、実態配線図に実際の配線状況をフィードバックする。うー、もっとサクサクと進めないと、期限に間に合わんではないか。

　 遂に、自作のパドルコントローラが完成した。早速「アルカノイド」をプレイしてみる。うんうん、ちゃんとパドルが動くぞ。なかなかのフィーリング。しかし……

　 2面が抜けられない

　 ……そッ、そんなバカな……いくらなんでも、オイラ、こんなにヘタだったっけ？ 4年前には、ワンコインで5面まで行ったという記録があるぞ。ほ、本気を出すか……

　 20回以上コンティニューしても2面が抜けられない

　 ……なッ、なぜだッ!! いくらなんでもおかしい。しかし、バウスはちゃんと動いている。ちょっと動きが鈍い？ いや、感覚として鈍くはない。エミュレーションだから？ 液晶ディスプレイだから？ USB接続だから？ いろいろ考えても、コレという理由は見つからない。パドルの感度を上げてもやっぱりダメ。正直、かなり、ツマらんッ!!

　 不思議なことに、何がどうおかしいとはコトバで表現できないが、確かに何かがおかしいのは間違いないのだ。

　 よく、液晶テレビだから、とか、無線コントローラだから、とかで、遅延がどうこうで(格闘ゲームの)技が決まらない、などというコメントを読んだことがあるが、正直、ホンマかいな、と思っていた。しかし、もしかすると、現在の状況がそれなのかもしれない。

　 せっかく、コントローラを自作までしたのに、こんな結末かよぉ……なにげに「アルカノイド Revenge of Doh」に切り替えてみる……

　 ワンコイン12面ッ!!

　 ……え。えぇぇ!? なんだそりゃ!? そんなに気合いを入れたわけでもないのに、ビシバシとエナジーボールをハジき返せてしまった。PCの仕様上、かなりひどいプチフリが出るのだが、にもかかわらず、である。正直、かなり、楽しいッ!!

　 不思議なことに、何がどうマトモだとはコトバで表現できないが、確かに何かがマトモなのは間違いないのだ。

　 いやはや、結局、どうにもコトバで表現できなくても「操作感に影響している要素というのは実在する」ということがわかった。なんにせよ、これだけ露骨な結果が出ているコトは認めざるを得ない。

　 ホントは元祖をやりこみたかったが、せいぜいRevenge of Dohの方を楽しむことにしよう。改めて、目指せッ!! 大山のぶ代ッ!!

　 あ、今日はコトバにもできない内容なので、絵にもできるワケもなく、写真はなしで。

　 昨日に引き続き、2匹が同時に羽化した。

　 昨日は、1分間隔の撮影だったこともあり、ポンと出てきてしまった感じだったので、今回は30秒間隔で撮影。ホントは10秒くらいで撮りたかったが「Caplio G4 wide」は30秒が限度だった。

　 なお、前半は輝度を無理に持ち上げてある。輝度の持ち上げには、当然convertを使う。

mkdir brighten05; for i in R00243[6789]?.JPG; do echo $i; convert -level 0%,5% $i brighten05/$i; done
mkdir brighten10; for i in R00243[6789]?.JPG; do echo $i; convert -level 0%,10% $i brighten10/$i; done

　 さて、今日はオイラの書斎というか工房に、机を作り付ける工事日だ。自宅を新築した際、なんとなく2階に作り付けた机が、妙に気持ちよくて、同じものが欲しくなったのだ。自宅を新築した、同じ工務店の、同じ大工さんがやってきて、据え付けてくれた。

　 大きさは、幅140cm、奥行き70cm弱、高さ70cm。机の奥には2カ所の穴があり、電源等の配線が引き出せるようになっている。机の下には、棚板があり、そこにも3カ所の穴が空いている。アダプタ等を置くのに便利。

　 椅子もまた、新築の際に工務店からオマケでもらったもの。ホントは脚立なのだが。

　 木はイイ。人が木の横にいて「休」という漢字ができたというが、確かに気が休まる。んが、木の方の気持ちはどうなんだろうな。牛や豚と同じかもしれん。牛や豚の気持ちとてどんなものかは、よくわからんが……。

　 机の据え付けには、丸一日かかったが、その間、XBeeをイジる……と、いうか、先日、ループバックに成功した直後、親側が動作しなくなったので、その復旧。

　 いや、事前に「ファームウェアが飛んだ場合の復旧方法」というページはあらかたチェックしており、面倒なことにならないよう、細心の注意を払っていたつもりなのだが……

　 特に心当たりもないのに飛んでいる

　 ……っつーのは、いったいどういうことだ。しかも、10時間以上も試行錯誤しても復旧できないっつーのは、いったいどういうことだ。おかしいだろ。マトモではないだろ。そもそも、Web上に「ファームウェアが飛んだ」というレポートが多すぎるのこと自体が異常だ。

　 DTRもRTSもつないでいる。X-CTUからブレーク信号を送ると、XBeeからは「OK」という応答が9600bpsで返ってくるから、壊れているわけでもないらしい。でも、ファームウェアの再ロードをガンとして受け付けない。

　 10時間も「単なる無駄な作業」をすることになんだったら、予備を買っておけばよかったわい。時給5000円なら、5万円以上もドブに捨てていることになる。せめて、オイラの作業のどこかにミスがあり「単なる無駄な作業」でなかったという結果になるといいが……というのも、しばらく触る気にならん。

　 キュゥべえ(QB)もなんとかいってよ……仲間(XBee)でしょ……。

　 改めて、キャノンボール。一応、ゲームとしての体裁までキッチリと整えて完成させてみた。気づけば前回の試作版から、丸1ヶ月もかかってしまった。

　 ググったら、当時の原作のスクリーンショットが出てきたので、パターンをそのままパクって、画面のイメージまで忠実に再現してみた。なんとも8bit感たっぷりだ。

　 とりあえず、3DSでちゃんと遊べるレベルに持っていけたのは、我ながら大きな成果だな。なんといっても、ウチのガキがそれなりに熱中して遊んでくれたのがなんとも嬉しい。今回のノウハウを生かせば、結構なレベルのゲームまで作り出せそうだ。

　 というわけで、ゼヒ一度プレイしてみてほしい。これは3DS用にチューニングしてあるが、HTML5+JavaScriptなので、パソコンやスマフォでも動かせる。後日、パソコン用にチューニングしたバージョンも公開する予定。

　 プレイしてみる。

　 なお、3DSのブラウザに対応させるノウハウのほとんどは、こちらのサイトの内容を大いに参考にさせていただいた。

　 同じことをRHELでやる場合には問題なくできるはず、なので、職場の環境でやってみることにした。が、RHELのコンテナイメージって、どうやって提供されているのだろう……Red Hatのサイトに置いてあったっけ？ ログインしてダウンロードしてdocker importするとか？ と、思ったら、なんと一般に公開されているので普通にdocker pullできるらしい。「ubi」で検索すると出てくるのがそれだ。「Universal Base Image」の略らしい。特段の契約なしに使ってもライセンス上の問題はないようだ。太っ腹だな。

# docker search ubi | grep 'ubi9[ -]'
docker.io    docker.io/redhat/ubi9                            Red Hat Universal Base Image 9
docker.io    docker.io/redhat/ubi9-minimal                    Red Hat Universal Base Image 9 Minimal
docker.io    docker.io/redhat/ubi9-micro                      Red Hat Universal Base Image 9 Micro
docker.io    docker.io/redhat/ubi9-init                       Red Hat Universal Base Image 9 Init
redhat.com   registry.access.redhat.com/ubi9                  rhcc_registry.access.redhat.com_ubi9
redhat.com   registry.access.redhat.com/ubi9-init             rhcc_registry.access.redhat.com_ubi9-init
redhat.com   registry.access.redhat.com/ubi9-micro            rhcc_registry.access.redhat.com_ubi9-micro
redhat.com   registry.access.redhat.com/ubi9-minimal          rhcc_registry.access.redhat.com_ubi9-minimal

　 双方に各4タイプあるが本家の無印を使っておけばいいだろう。

# docker pull registry.access.redhat.com/ubi9

　 とりあえず、自分が一番良く使うsinatra_skeltonのベースイメージを「fedora:39」から「ubi9:latest」に置き換えてビルドしてみるか……て、アレ？ なんだか素でもdnfの処理が速くないか？ 100以上のrpmパッケージを導入するってのに、なんだかサクサクな気がするぞ。

# docker-compose build --no-cache
  :
Red Hat Universal Base Image 9 (RPMs) - BaseOS  1.1 MB/s | 515 kB     00:00    
Red Hat Universal Base Image 9 (RPMs) - AppStre 2.6 MB/s | 2.0 MB     00:00    
Red Hat Universal Base Image 9 (RPMs) - CodeRea 784 kB/s | 274 kB     00:00    
  :
Total                                           5.6 MB/s | 116 MB     00:20     
  :
real	1m34.461s

　 まぁでも、せっかくなのでslairを使うパターンも試してみよう。repoを置き換えるスクリプトはこんな感じに。

#!/bin/sh
 
rm /etc/yum.repos.d/*.repo
 
cat <<EOF >/etc/yum.repos.d/slair.repo
[Slair-BaseOS]
name=Red Hat Enterprise Linux 9.4 - BaseOS
baseurl=http://hostname/slair/indexes/discs/rhel-9.4-x86_64-dvd/BaseOS/
gpgcheck=0
[Slair-AppStream]
name=Red Hat Enterprise Linux 9.4 - AppStream
baseurl=http://hostname/slair/indexes/discs/rhel-9.4-x86_64-dvd/AppStream/
gpgcheck=0
EOF

　 Dockerfileの冒頭はこんな感じに。

FROM ubi9:latest
 
ADD http://hostname/slair/indexes/misc/setup_repo_rhel94.sh /setup_repo_rhel94.sh
RUN bash /setup_repo_rhel94.sh
 
RUN set -x \
	&& dnf install -y \
		ruby \
		rubygem-bundler \
		ruby-devel \
		redhat-rpm-config \
  :
  :

　 おぉ、速い。けど、ほとんど変わらない。ダウンロードは少し速いが、ビルド全体だと何秒か遅い。が、誤差程度だ。slairいらんやん。

# docker-compose build --no-cache
  :
Red Hat Enterprise Linux 9.4 - BaseOS           4.2 MB/s | 2.1 MB     00:00    
Red Hat Enterprise Linux 9.4 - AppStream        6.3 MB/s | 7.0 MB     00:01    
  :
Total                                           6.3 MB/s | 120 MB     00:19     
  :
real	1m38.762s

　 ubiのコンテナでubiのリポジトリにアクセスするのは問題ないが、RHELのオフィシャルISOを食わせる場合は、ライセンス上サブスクリプション契約が必要になる。上記は職場環境での試行なので問題ないが、自宅では実施できない。ということで自宅では素のubiを試してみた。

# docker-compose build --no-cache
  :
Red Hat Universal Base Image 9 (RPMs) - BaseOS  1.2 MB/s | 515 kB     00:00    
Red Hat Universal Base Image 9 (RPMs) - AppStre 3.5 MB/s | 2.0 MB     00:00    
Red Hat Universal Base Image 9 (RPMs) - CodeRea 479 kB/s | 274 kB     00:00    
  :
Total                                           9.2 MB/s | 116 MB     00:12     
  :
real	1m21.979s

　 自宅でも、むしろ速いやんけ。やっぱ、slairいらんやん。こんなことなら、これからベースイメージにはubiを使おうかしらん。

　 改めてFedoraのdnfが遅い理由を確認してみると、ダウンロード速度が遅いのもあるが、リポジトリのカタログが大きいことが主たる原因のようだ。まぁ、Fedoraでしか使えないパッケージは多いからこれは仕方ない。

Fedora 39 - x86_64                              2.1 MB/s |  89 MB     00:41    
Fedora 39 openh264 (From Cisco) - x86_64        1.4 kB/s | 2.6 kB     00:01    
Fedora 39 - x86_64 - Updates                    2.5 MB/s |  39 MB     00:15    

　 つうわけで、これからはubiメインで、不足する場合はfedoraを使うというのがよさそうである。プシュー。

　 どうでもいいが、直前の記事を書いた時点では、特段UBIの存在を意識していなかったのに、今回の記事に奇跡的なネタ表題が付けられて満足……つっても、このネタを拾える人がどれだけいるのか……。