Very slow I/O under OpenBSD i386 on qemu-kvm from RHEL7rcにあるように、OpenBSDのioapic/apicまわりの実装による問題でQEMU上で動かすとやたらと遅くなる現象が、このポストが行われた11年前から未だに続いています。UKCからdisable mpbiosとdisable acpimadtの両方を行えば解決するとはいえ（acpimadtがあればこれを優先して使い、無ければmpbiosを使うようなので、両方とも無効化する必要があります）、OpenBSD-currentでいちいちそんなことはやってらんないのでQEMU等の設定からどうにかできないかと足掻いてみました。

とりあえず

1. CONFIG_MPTABLE=yを設定しないでSeaBIOSをビルドする（make menuconfig→BIOS Tables→MPTableのチェックを外す）
2. qemu-system-i386に-machine acpi=off -bios bios.binを指定する（bios.binは1.の手順でMPTableを無効化したSeaBIOS）

という手順でマトモな速度になるものの、SeaBIOSにはAPMが無いのでhalt -pによる電源offができません。また、acpi(apic)/mptable無効化によりシングルプロセッサでの動作となります。これ以上を望むなら実機を用意する必要がありそうです。Windows10の終了まであとわずかなので、そこそこのパフォーマンスがあるRAM 4GBの程度の良いマシンが大量かつ安価にジャンク屋に並ぶことを期待してしまうのですが、どうでしょうかね。56.7kg(23:45)

17-Sep-2025の続き。Thingsup BLE Beacon Scanner and Loggerを仕込んだAndroid端末を持って税務署入口交差点にある信号機(ID:00d63bea)のログを取ってみました。今回はData=0x01ceのフィルタをかけて3分ほど放置してこんな感じ（※対象外の機器は削除しています）。思った程…データが得られない？

Raw Dataの部分、これはBluetoothのどこのレイヤの何なんでしょう。また、1b1ce00580101ce000000d63bea021ebbb9084ea711200000000001を8bit単位で切っていくと4bit余るのですが、これは一体？？とりあえず信号機と思しきMAC Address(E8:AB:4D:22:7B:EB)は得られたので、次にログを取ったらこれを中心に調べれば良いのかもしれません（表示されるデバイス名にはUTMS_PICS0001の名は無く、N/Aなデバイス名とMACアドレスの中から対象を探さないといけない…しかも交通量が多いのでよく分からないデバイスが大量に表示される以上、現場ではフィルタをかけずにログを取って後から抽出の方が良いのかも）。

県別IDも気になるのですが、現時点では東京都（15箇所）は新宿だけしか対応する信号機は無く、山梨（2箇所）は甲府、静岡（47箇所）で行けそうなのは三島か沼津といった状況なのでまずは身近なものをじっくり調べるしかなさそうです。というか、何故神奈川は80箇所もある…？（トップは宮城県の135箇所、神奈川はその次）55.2kg(06:55)

28-Sep-2025補足：税務署入口交差点にある信号機と思しきMAC addressの出すパケットを、Thingsup BLE Beacon Scanner and Loggerで10分間ほど採取してみました。なんとなくですが、UTMS_PICS0001の文字列もあるように見えます。

A1A breakerの電報モード、これって改行文字を無視すれば（空白として扱わなければ）いいんでしょー？ということA1A generatorにも実装しちゃいました。流石に本文中に「＃電報」を仕込むのではなく、コマンドラインオプションでの対応になりますが。

MojiGeneの、単語長を可変にするのはまだ開発中という扱いです。単語の生成アルゴリズムが賢ければ指定した文字数にきちっと合わせられるのでしょうが、賢く作っていないので指定された文字数を超過することがそれなりにあります。超過した場合にどうするか…多分以下のどれかになると思うんですよね。

0. 何もしない（文字数は超過することがある）
1. 最後の単語の最小文字数を優先する（文字数は超過することがあるが、0.ほどではない）
2. 文字数を優先する（最後の単語は最小文字数未満となることがある）

とりあえず1.の動作をデフォルトにして、要望があれば（無いよね？）切り替えられるようにする方向で考えています。55.7kg(23:30)

いつの間にかCanna 3.7 p5がGitHub上でリリースされていたりするので、Debian-13でビルドを試みたのですが…これが見事にできません。Porting to GCC 14にあるImplicit int types (-Werror=implicit-int)とImplicit function declarations (-Werror=implicit-function-declaration)をとにかく踏みまくっているので、片っ端から漏れなく全部直さないといけないのです。という訳でmake cannaが通る程度まで直してみました（make installは怖いのでまだやっていません）。ちょっと修正量多すぎなんですけど💢lib/canna/canna.hもなんなんですかアレは💢程度のボヤキは許してください。

Debian-13でmake cannaが通った一方で、OpenBSD-7.7ではmake cannaから実行されるmake Makefilesでは"Imakefile.c:17:2: Include file Imake.tmpl not found"が発生してしまい、Makefileが全く作れない事態が発生しています。xmkmfでimake -DUseInstalled -I/usr/local/lib/X11/configを呼び出した場合は問題なく、コマンドラインで直接imake -DUseInstalledとした場合はImake.tmpl not foundが発生することから、削除した部分…-I/usr/local/lib/X11/configをどうにかして付加できれば直せそうな気がします。とはいえ、この方法が全然分かりません。

和文モールスのリハビリは少し方法を見直して、LCWO.netのmorse machineに頼ることにしました。とはいえ、符号を聞く→キーボードを打つのに時間がかかるため（ローマ字入力なので大抵は二文字打つ）、25WPMの速度で符号を認識できても紙への書き取りは18WPMでも厳しく、また濁点や記号類は別途練習しないといけません。とりあえず「ざっくりとイロハ48文字を思い出す」練習を気軽に行う用途としては便利なので、もうしばらく続けるつもりです。今の進捗だと一/二総通レベルは当然無理として三総通レベルだったらあと少しの努力で手が届くかどうか…？という感じに見えるので、三総通を受けてみる、という目標を立ててみても良いのかもしれません（ただし受験するとはまだ言っていない）。

以前作ったMojiGene（A1A breakerの乱文生成を自分なりにアレンジするやつ）は、固定長だけでなく可変長の単語も生成できるよういじっているところです。MojiGene.iniのパラメータだけでなく、コマンドラインオプションも過去との互換性を無視した変更を加えています。これに絡んでA1A breakerの「＃電報」による電報モードを見てみましたが、これは改行文字を空白とみなさないモード、のことなんですね…現時点のA1A generatorで再現するとしたら、こんな風に<>で改行文字をエスケープすることになるのでしょうか。和文電報における数字の略体への対応についても、考える必要があります。

21日恒例の、JMH電波予報@13988.5kHz。20-Jul-2025以来です（20-Aug-2025にも受信はしているのですが、とても載せられるような受信状況ではなかったので記事にしていません）。

去年(21-Sep-2024)の方が綺麗に受信できています。PC/無線機周りは何も変えていないので、綺麗に受信できるかどうかはコンディション次第（なので祈りましょう）と結論づけることになりそうです。55.9kg(23:55)

信号の時刻表を作る 2025（デイリーポータルZ）から高度化PICS整備交差点なるものを知り、神奈川県相模原市では市役所通り周辺にあることが分かったので早速行ってみました…って、会社帰りに通っただけなんですけどね。

デイリーポータルZの記事には、Software Design 2025年7月号に解析プログラムについての記事が掲載されているとありますが、手っ取り早く体験するなら信GO!なるアプリを入れれば良さそうなのでこれを使ってみることにしました。Android版、iOS版両方ともあります。

・相模原署前 （愛樹之碑・ラーメン魁力屋側 BLE40-1 ID:00d5af21 MAC:F6:1A:BF:DA:D4:05）

・市役所前 （相模原市体育館跡地側 BLE40-20 ID:00d63bd4 MAC:D3:A4:09:06:F4:4F, DE:EC:A3:12:CC:20）

・市民会館前 （市民会館側 BLE40-164 ID:00d63c64 MAC:CE:80:08:59:CF:6C）

・税務署入口 （山久第1ビル側 BLE40-42 ID:00d63bea MAC:E8:AB:4D:22:7B:EB）

相模原市役所西（ストリートビューの画像からは判別できず）と裁判所前(BLE40-253)は未攻略です。相模台小学校前(BLE44-92)…場所は何となく分かりますがちょっと気軽に行ける場所じゃないです。

信号が点滅すればアプリの信号も点滅し、押しボタン式であれば押しボタンのステータスが取れる（試してはいませんがスマホを押しボタン代わりにすることもできるようです）。当たり前だと言われてしまえばそうなのですが、信号機とBluetooth越しにやり取りできるというのはちょっと感動しますね。

なお、信GO!に対応する信号機が無い場合と、対応する信号機のあるエリアに近付いた場合はこんな画面になります。

「交差点ID:00d63bea」は税務署入口のIDです。IDが表示された状態のスクリーンショットを撮るのは本当に大変なので、ID集めはBluetoothを搭載したノートPCでうにゃうにゃする方が楽な気がします（やんないとダメ？）。55.5kg(23:00)

25-Sep-2025補足：交差点IDについて調べたので、追加しました。でも変ですね…高度化PICS運用ガイドライン（令和2年10月16日、有効期限は令和8年3月31日まで）にはこう書かれているのですが

都道府県コードの部分が00になっています。まだ実験段階（本運用ではない）、ということなのでしょうか？

26-Sep-2025補足：裁判所前・相模原市役所西についても追記します。

・裁判所前 （ローソン相模原裁判所前店側 BLE40-253 ID:00d63cbd MAC:D4:68:CB:82:6D:93）

・相模原市役所西 （パン工房ブンブン相模原店側 BLE40-160 ID:00d63c60 MAC:EF:30:DC:AE:65:9A）

何か情報を得られるかと思いスマホにBluetooth Devices Infoを入れて信号機の脇へ寄ってみましたが、何も情報は得られません。ペアリングされたデバイスの情報を示すソフトを使っても意味が無く、Thingsup BLE Beacon Scanner and LoggerといったBLEビーコンスキャナを持っていく必要がありそうです。

30-Sep-2025補足：裁判所前→市役所前→相模原署前→相模原市役所西→市民会館前→市役所前を歩いてログを取り、UTMS_PICS0001の部分だけ抽出することで得られたMAC addressを追記してみましたが…市役所前が二つということは、おそらく他の交差点も二つありそうな気がします。もう少し調査が必要です。

01-Oct-2025補足：相模原署前交差点、警察署→16号を渡る→スルガ銀行→ラーメン屋の順番でぐるりと回ってみましたが、ここはF6:1A:BF:DA:D4:05だけでした。

02-Oct-2025補足：その他交差点についても調べてみました。MACアドレスの確定と、送信機が複数あるかどうかを知ることが目的です。

税務署入口

E8:AB:4D:22:7B:EBだけです。市民会館前の信号も受信できています。

市民会館前

CE:80:08:59:CF:6Cだけです。市役所前の信号も受信できています。

裁判所前

D4:68:CB:82:6D:93だけです。市役所前の信号も受信できています。

市役所前

D3:A4:09:06:F4:4F, DE:EC:A3:12:CC:20の二つです。相模原市役所西、市民会館前、裁判所前の信号も受信できています。あじさい会館側にD3:A4:09:06:F4:4F、市役所側にDE:EC:A3:12:CC:20があるように見えます。

相模原市役所西

EF:30:DC:AE:65:9Aだけです。市民会館前、市役所前の信号も受信できています。

信号強度、送信機のそばだと-60dBm台、交差点エリアは-70〜-80dBm、近隣の交差点は-90〜-100dBmくらいな感じです。

当然ですが将来における機器更新などに伴い、MAC addressは変わる可能性があります。

07-Oct-2025補足：BLE送信機については07-Oct-2025にまとめました。

とりあえず、Slackware-currentに一縷の望みを託してみようかなって。逆襲のSlackwareに詳しい話が書かれていて、https://bear.alienbase.nl/mirrors/slackware/slackware-current-iso/等からslackware-current-mini-install.isoを書き込んだUSBメモリで起動することはできたけど…

• SOURCE MEDIA SELECTIONでは「5 Install from FTP/HTTP server」を選ぶ
• FTP/HTTPサーバのURLは「http://203.178.137.135/」
• パスは「/pub/Linux/slackware/slackware-current」

考え方としては、https://mirrors.slackware.com/mirrorlist/にあるAvailable http mirrors（https mirrorではありません）から適当なのを選び、サーバのIPアドレスを指定してそのサーバの適切なパスを設定するということです。

インストール時におけるマシンのIPアドレスは手動割当で、ゲートウェイの設定は行えるもののネームサーバの指定はできません（気を利かせてGoogle Public DNSを使ってくれたりもしません）。なので、インストールするためのファイルを取ってくる相手たるサーバもIPアドレスで指定する必要があります。上の記述は、http://ftp.nara.wide.ad.jp/pub/Linux/slackware/slackware-current/を使うためのもの。国内のhttpミラーサーバはhttp://ftp.riken.jp/Linux/slackware/slackware-current/もありますが、内容が古いためftp.nara.wide.ad.jpを勧めます。55.1kg(22:25)

Debian-13(trixie)、5.1.2. Reduced support for i386にあるようにthere is no official kernel and no Debian installer for i386 systems.という状況で。i686機ではDebian-13のインストール自体ができませんし、Debian-12(bookworm)からは一部分のアップグレードはできたとしてもカーネルのサポートは無いと考えるしかなさそうです。となると…残るはGentoo, Void, Slackwareくらいでしょうか。目的を絞りに絞れば、buildrootで頑張るなんていう選択肢もあるのかもしれませんけど。

*BSDについては、DragonFlyBSDは既にamd64専用で、FreeBSDはFreeBSD-15でarmv7以外の32bit環境を切ると言っています（そのarmv7もFreeBSD-16では廃止予定）。OpenBSDについては分かりませんが切るときはさくっと切るでしょうから、"Of course it runs NetBSD"…NetBSDが最後の拠り所になります。とはいえ、OSが動いたとしてもバイナリパッケージで提供されるアプリケーションがどの程度信用できるかという問題はあります。Linux distroであってもそうですが、NetBSDの方が使う人間の数が圧倒的に少ないので、アプリケーションの挙動を見る「目」の数も当然不足します（dpboxがアレだったからなあ）。

そのような状況で、HAIKUがどこまで頑張るかというのは気になります。x86版BeOSとバイナリ互換を謳う以上、そう簡単に32bitサポートを切らないのではないか？と考えてしまうのですが、これはそうあってほしいというただの願望です。

結論としては、x86-64対応プロセッサが登場してから20年以上の時間が経過し、ここまで続いてきたx86(32bit)の終焉もとうとう間近。おそらく終わる時はあっという間に終わる、ということです。32bit専用機がまだ手元にありそれをゴミにするつもりが無ければ、（セキュリティの問題などがあるので取扱いには注意が必要ですが）当時物のLinux distroなりソフトウェアなりは手放さずに持っておいた方が良いのかもしれません。55.8kg(23:45)