OpenBSD版Firefoxのセキュリティ強化は/etc/firefox/unveil.mainで設定

Let's note CF-SV8RDCVSにOpenBSD/amd64 7.9をインストールし、環境を構築中です。Webブラウザは、昔からFirefoxを利用しているので、OpenBSDでもFirefoxを使用しようと思います。インストール自体は「doas pkg_add firefox」するだけなので簡単でした。日本語変換は「fcitx-anthy」を入れており、こちらも問題ありません。Firefox Syncとか、Feedlyにも問題なさそうです。最後にTiddlyWiki5を利用するために「ファイルを開く」（Ctrl-O）したら、なんだか様子がおかしいです。

 

TW5のファイルが「~/Documents」 以下に置いてあるのですが、そもそもファイルダイアログで「~/Documents」が出てきません。出てこないならば、手入力で選択しようと思いましたが、それも出来ませんでした。さらに、Windows11でFirefoxを使っている感覚からすると、OpenBSDのcwmで動くFirefoxは、ウィンドウに枠もないし、「本当にこれで良いのか」と思うくらいシンプルな画面です。

 

最近はGeminiと対話を繰り返すことで問題を解決していくことが多いので、本件もGeminiに相談しました。Geminiからは、Firefoxの「about:config」で設定を調整すれば解決すると案内されましたが、全く効果はありませんでした。

 

OpenBSD版Firefoxは、パッケージから「doas pkg_add firefox」で入れています。ソースは「ports/www/mozilla-firefox」にあるので、手がかりとなるような情報がないものかと探してみました。パッチファイルなどが置かれていましたが、「たったこれだけ？」と思うくらい、僅かなファイルしかありません。Geminiに「ports/www/mozilla-firefox/Makefile」を解析してもらったところ、「mozilla.port.mk」を参照しているという情報を得ました。探してみると「ports/www/mozilla/mozilla.port.mk」にありました。

 

Geminiによると、OpenBSDは「UNVEIL(2)」によりセキュリティを強化しているという示唆が得られました。さらに「unveil.main」というファイルが重要な役割を担っているとも示唆します。しかし不思議なことに「ports/www/mozilla-firefox」以下のファイル内を探しても、「unveil()」とか「unveil.main」という文字列は見つかりません。

 

ソースを見ても分からないなら、実行ファイルを確認しようと考えました。「/usr/local/lib/bin/firefox」は「/usr/local/lib/firefox/firefox」へのシンボリックリンクになっています。このファイルをstringsにかけてみましたが、「unveil.main」という文字列がありません。こうなったら最後の手段ktraceとkdumpを試してみます。「ktrace -f ktrace.out firefox」としてFirefoxを起動し、すぐに終了させます。そして生成されたファイルを「kdump -f ktrace.out」してみます。その結果「/etc/firefox/unveil.main」にアクセスしている記録が残っていました。

 

「/etc/firefox/unveil.main」にアクセスしていることは確認できましたが、「ports/www/mozilla-firefox」以下のファイルには対応する実装が見当たりません。しかも「strings /usr/local/lib/firefox/firefox」でも「unveil.main」がありません。これは一体どういうことなのでしょうか。実装が無いのに、ktrace.outに記録されているとしたら、OpenBSDは魔術を使ったことになってしまいます。それはあり得ません。

 

Geminiの示唆によると、Frirefoxの実体は、「/usr/local/lib/firefox/firefox」ではなく、「/usr/local/lib/firefox/libxul.so」とのことです。「strings /usr/local/lib/firefox/libxul.so.162.0」として調べてみると、確かに「unveil.main」がありました。さらにktrace.outには「5489 firefox  NAMI  "/usr/local/lib/firefox/libxul.so.162.0"」が記録されていました。

 

ここまでの調査では、Mozillaが提供しているソースに対して、OpenBSDがパッチをあてているのではないかと仮定していました。しかしそういう風には見えません。そこで、Mozillaの公式サイトから「firefox-157.0.1.source.tar.xz」を入手し、「unveil」という文字列を探してみました。 その結果「firefox-157.0.1/dom/ipc/ContentChild.cpp:      OpenBSDFindPledgeUnveilFilePath("unveil.main", unveilFile);」を発見しました。この事実は何を意味しているのか考えると、要するにMozillaが提供するファイルにはOpenBSDに特化した実装が既に入っているという事です。つまりMozillaが提供するファイルに、OpenBSD側portsでパッチをあてているという仮定が間違っているのです。Mozillaが提供するファイルに、OpenBSD用の実装が最初から入っているのです。

 

Firefoxパッケージをインストールすると「/usr/local/share/doc/pkg-readmes/firefox」が入ります。これを読むと興味深い事実が判明します。

• 設定ファイル「unveil.main」は、「/etc/firefox/unveil.main」に決め打ちになっています。
• 設定ファイル「/etc/firefox/unveil.main」の内容を「disable」とすれば、セキュリティ制限が解除されるようです。
• 環境変数「MOZ_LOG=OpenBSDSandbox:5」を設定すると、ログが出力されるようです。

  

調査を始めたときの問題（Ctrl-Oのファイルダイアログの件）は、解決していません。しかし「/etc/firefox/unveil.main」がセキュリティを強化してからではないかと思われます。これを「disable」にすれば一件落着かもしれません。でもOpenBSDの「セキュリティ重視」というポリシーを無視することになってしまいます。どのように解決するのかは、これから考えてみます。

 

 

Let's note CF-SV8RDCVSでOpenBSD+cwm環境でのQtアプリケーションの表示が大きい

Let's note CF-SV8RDCVSにOpenBSD/amd64 7.9をインストールしました。xenodm経由でcwmを使おうと考えています。日本語変換にはfcitx-anthyを利用します。Ctrl-SPACEを押すと変換ウィンドウが表示されるのですが、xtermの画面に対して、大きくて、バランスが悪いように思います。これを直すには「fcitx-configtool」というツールを使うようです。インストールし起動してみたら、全体的に大きすぎるウィンドウが開いて、とてもバランスが良くありませんでした。

この「fcitx-configtool」というのはQtアプリケーションだそうです。一般にQtアプリケーションの構成を変えるには「qt5ct」というアプリケーションを使うのだそうです。そこでインストールして起動してみると、これまたバランスの悪いウィンドウが出てきました。

 

これらの問題を解決するには、設定すると効果があるとと思われる環境変数が幾つかあるようです。その一つである環境変数「QT_FONT_DPI」に「96」を設定したら、丁度よいバランスになった気がします。試しに実験として「180」を設定してみたら、環境変数設定前のバランスの悪いウィンドウが再現されました。

 

Let's note CF-SV8のディスプレイは「12.1型 WUXGA(16:10) (1920x1200) アンチグレア」ということになっています。ここで「√(1920^2 + 1200^2) 」を「12.1」で割れば約187になります。「QT_FONT_DPI=180」としたときの画面が、設定前に近かったのも、こういうことなのでしょう。

OpenBSDのxtermは環境変数「GTK_IM_MODULE」を子プロセスに渡さない

Let's note CF-SV8RDCVSを入手したのでOpenBSD/amd64 7.9を入れました。まだOSを入れただけに近い状態です。日本語環境を設定するため、環境変数「LANG=ja_JP.UTF-8」を設定し、日本語フォントにはnoto、日本語変換はfcitx-anthyを入れました。ちなみにログインシェルはパッケージからインストールしたtcshです。OpenBSDにはxenodmというディスプレイマネージャがあります。何も設定していなければfvwmが動きますが、「~/.xsession」を用意して、cwmが動くようにしておきました。

 

日本語変換としてfcitx-anthyを入れましたので、「~/.xsession」で環境変数も定義しておきます。動作確認のために、パッケージからFirefoxとLibreOfficeを入れ、日本語変換できるか確認しました。

setenv GTK_IM_MODULE fcitx
setenv QT_IM_MODULE  fcitx
setenv XMODIFIERS    @im=fcitx 

 

日本語変換を確認するため、xtermからFirefoxを起動します。Ctrl-SPACEを押すと、日本語変換できました。ところがLibreOfficeでは、日本語変換できません。いろいろと調べていると、xterm上でprintenvしたら、環境変数「GTK_IM_MODULE」が定義されていないことが判明しました。しかし「QT_IM_MODULE」と「XMODIFIERS」は、ちゃんと定義されています。

 

以前であれば、Google検索で情報を収集していましたが、最近は、Geminiに相談して解決を模索することが多くなりました。余談となりますが、Geminiは、というか生成AIは何でもそうかと思いますが、豊富な情報量をもとに回答しますが、その回答がGeminiの妄想（ハルシネーションとも言う）であることも少なくありません。はっきりと「それは、こうだ」とか「何々が原因だ」とか断言しますが、証拠の提示を求めると、「間違っておりました」と白旗をあげることも多々あります。Geminiの回答を鵜呑みにしないで、自分でも裏付けをとらないと間違った方向に進んでしまいます。

 

閑話休題。環境変数「GTK_IM_MODULE」が消える過程を調べるため、試行錯誤しました。多くの可能性を考えたり、Geminiに相談を繰り返したりしましたが、次のように調査を進めました。

1. コマンドラインから「ps -e -ww -ax -o pid,ppid,user,args」を実行してみました。するとcwmやxtermのプロセスでは環境変数「GTK_IM_MODULE」を保持しているにもかかわらず、その子プロセスとなるtcshには環境変数「GTK_IM_MODULE」がありませんでした。
2. コマンドラインから「strings /usr/X11R6/bin/xterm | grep GTK」すると、文字列「GTK_」が見つかりました。
3. OpenBSD版xtermのソース「main.c」を確認すると関数「xtermTrimEnv(void)」を発見しました。ここに「TRIM(1, GTK_),」という記述が含まれています。

 

つまりxtermは文字列「GTK_」で始まる環境変数を子プロセスに引き継がないようにロジックが組まれていたのです。ファイル「~/.xsession」で定義したはずの環境変数「GTK_IM_MODULE」が消えていたのは、バグではなく、仕様でした。

 

この問題が発生するのは、OpenBSDだけなのか、他OSも同様なのか、調べてみました。網羅的な調査はできませんが、OpenBSDだけの事象と思われます。

1. NetBSDにおけるxtermのソース「main.c」を確認しました。ファイルの最初に「/* $XTermId: main.c,v 1.930 2024/12/01 19:57:13 tom Exp $ */」とあります。この中に関数「xtermTrimEnv(void)」は存在しますが、「GTK_」に関する記述は存在しませんでした。
2. GitHubにあるxtermのソース「main.c」を確認しました。ファイルの最初に「/* $XTermId: main.c,v 1.946 2026/08/14 23:15:48 tom Exp $ */」とあります。この中に関数「xtermTrimEnv(void)」は存在しますが、「GTK_」に関する記述は存在しませんでした。
3. OpenBSDにおけるxtermのソース「main.c」の最初には「/* $XTermId: main.c,v 1.944 2026/04/07 19:22:45 tom Exp $ */」とあります。OpenBSDのCVSwebで確認すると、「TRIM(1, GTK_)」が入ったのは、2025年11月1日のrevision 1.67でした。

 

OpenBSDに限らず、FreeBSDやNetBSD、もしくはUbuntuなどでも、日本語変換を入れたら、GTK用やQt用の環境変数を設定することが「お約束」になっています。その手順を踏んだだけだと思っていたのに、OpenBSDのxtermでは環境変数「GTK_IM_MODULE」が設定されない「仕様」になっているという落とし穴があるとは、青天の霹靂でした。

 

OpenBSDのxenodmと~/.xsessionの関係

OpenBSDでxenodmを使ってログインすると、「~/.xsession」が呼ばれます。その関係は、「/etc/X11/xenodm/Xsession」の最後を見れば、よくわかります。具体的には、次のようになっています。

# The startup script is not intended to have arguments.

startup=$HOME/.xsession
resources=$HOME/.Xresources

if [ -s "$startup" ]; then
    if [ -x "$startup" ]; then
        "$startup"
    else
        /bin/sh "$startup"
    fi
else
    if [ -f "$resources" ]; then
        @XRDB_PROGRAM@ -load "$resources"
    fi
    @bindir@/xterm &
    @bindir@/fvwm
fi
do_exit 

 

まず、「~/.xsession」の有無で処理が分かれます。あれば利用するし、なければ「fvwm」が使われます。

 

もし「~/.xsession」が存在するとしても、実行可否で処理が分かれます。実行可能であれば直接実行されるし、実行可能でなければ/bin/shに解釈させます。つまり、実行可能な「~/.xsession」であれば、ファイルにシバンを書いておくことで、/bin/sh以外（例えば/usr/local/bin/tcshなど）を使うことが可能になります。

 

もしOpenBSDでcwmを使いたければ、「~/.xsession」を用意しておく必要があります。実行可否は、どちらでも構いません。ただし/usr/local/bin/tcshを使いたいのであれば、実行可能とし、さらにシバン（#!/usr/local/bin/tcsh）を書いておく必要があります。

『年貢』（渡辺尚志、中公新書2920）を読んでみた

書店で『年貢』（渡辺尚志、中公新書2920）を見かけたので、購入し読んでみました。「年貢」という言葉そのものは、学校で習いますし、時代劇などでもお馴染みです。しかし実態に詳しいわけではなく、江戸時代は領主に米を納めており、時には一揆を引き起こす場合もあったという程度の認識しかありません。

 

本書は、その「年貢」について、詳しく書かれています。とても勉強になりました。

 

江戸時代の年貢は、領主と領地との関係で成り立っています。本書を読んでいて思ったのですが、現在の政府や自治体と住民との関係のように、全国どこでも統一されたいるわけではないと思います。ある領主と、その領地の村々だけを考えれば、何らかの仕組みが出来ているでしょう。しかしながら、その仕組みが全国統一されたものとは思えません。幕領とか国替のない大名などであれば、江戸期を通じて、同じやり方だったかもしれません。しかし「鉢植え大名」という言葉があるように、国替を繰り返していた大名家もあります。また領主が次々と変化した村々もあるでしょう。年貢についての全国統一方式がないということは、領主側にとっても領地側にとっても、仕組みを再構築する必要があったということです。お互いの認識しているやり方が微妙に違っていると、わざわざ説明するのが面倒だったのではないでしょうか。仕組みが全国で統一されていれば、お国替えがあっても、領主としても、領民としても、年貢の納める方式に違いはないので、楽だったでしょう。しかし江戸時代と言うのは、徳川幕府は「全国統一政府」ではないので、各大名のやり方に口をはさめなかったと思います。

 

「鉢植え大名」で、諸国を転々とするのは、大変だったとは思います。しかし、そのように転々とすることで、年貢の収受にかかわる極端なローカルルールが淘汰される契機にもなったかもしれません。 

OpenBSD/amd64にfcitx-anthyをインストール

Let's note CF-SV8RDCVSにOpenBSD/amd 7.9を入れました。まだOSを入れただけなので、これから様々な環境設定を行うつもりです。まず最初に日本語環境を整えておこうと思います。そのためにやる事は、次のようなことだと思います。

1. 環境変数LANをja_JP.UTF-8にする。
2. 日本語フォント入れる。
3. 日本語変換できるようにする。 

 

 環境変数LANGについては、既に設定を終えています。次は日本語フォントです。旧い知識だとIPAフォントかと考えていたのですが、最近はnotoフォントが良さそうです。OpenBSDのパッケージにも、notoフォントが揃っています。ただしIPAフォントは、無くはないですが、お勧めではない雰囲気です（個人的な印象ですが）。noto関連フォントが、幾つかあり、必要なものだけに限定してインストールしても良いのですが、ディスク不足に悩んでいるわけでもないので、全て入れてしまいます。

• noto-cjk-20240730
• noto-emoji-2.051v0
• noto-fonts-2026.03.01v0
• noto-nerd-fonts-3.3.0

 

最後に日本語変換です。OpenBSDのパッケージにはmozcが無かったのでanthyにしました。以下のパッケージを入れましたが、依存関係にあるパッケージが勝手にインストールされるので、この3つだけをインストールしたのではありません。

• fcitx-anthy
• fcitx-gtk
• fcitx-qt

 

日本語変換はインストールしただけでは動きませんから、~/.xsessionにも設定をしておきます。次のようにしました。

#!/usr/local/bin/tcsh

# import env from ~/.login
if (-f ~/.login) source ~/.login

# fcitx-anthy
setenv GTK_IM_MODULE            fcitx
setenv QT_IM_MODULE             fcitx
setenv XMODIFIERS               @im=fcitx
/usr/local/bin/fcitx5 -d &

# go cwm
exec /usr/X11R6/bin/cwm
#[EOF]

 

試しにxtermでCtrl-SPACEを押したら、変換ウィンドウが出てきて、変換もできました。うまくいっているようです。ただし、xtermのフォントと変換ウィンドウのフォントのバランスが悪いので、調整が必要です。 

スマホ用Firefoxのブックマークに「指定の順序で並べ替え」という設定が存在する

スマホ用Firefoxのブックマークに「指定の順序で並べ替え」という設定がありました。以前は存在しなかったので、いつのまにか新設されたようです。Windows用Firefoxには「並べかえない」という設定が元々存在しました。ところがスマホ用には無かったので、Firefox Syncでブックマークを共用している場合に、Windosとスマホとで出現順序が違うので、戸惑っていました。

 

スマホでは「指定の順序で並べ替え」という設定項目名になり、Windowsでは「並べ替えない」という設定項目名になっています。どうして同じにしないのかと、不思議で仕方ありません。それはともかくとして、Windowsとスマホとでブックマークの出現順序が揃ったので、ありがたいことは確かです。 

「~/.xsession」を「#!/usr/local/bin/tcsh」とする

最近入手したLet's note CF-SV8RDCVSにOpenBSD/amd64 7.9を入れました。日本語環境を設定するため、環境変数「LANG」に「ja_JP.UTF-8」を指定する方法を探していました。ログインクラスを利用しようと思いましたが、思ったように動作しないので断念しました。ホームディレクトリにあるドットファイルで個別に指定するしかないようです。

ログインシェルにはtcshを利用しています。パッケージから導入したので「/usr/local/bin/tcsh」です。環境変数を設定するなら「~/.login」を編集することになるでしょう。一方でxenodmからcwmを利用する場合には「~/.xsession」が使われ、通常は「/bin/sh」で解釈されます。

 

Bシェル系とCシェル系とでは環境変数を設定する書式が違いますので、ワンライナーか何かで変換し、一方から他方を参照しようと考えていました。Geminiに相談したら、「~/.xsessionにシバンで/usr/local/bin/tcshを指定する」という方法を教えてくれました。そうすれば「if ( -f ~/.xsession ) source ~/.xsession」で一発です。こういう発想はなかったので、目から鱗でした。

 

これで「LANG=ja_JP.UTF-8」を指定することができるようになったので、日本語環境の設定を進めていけます。

環境変数「LANG」設定にOpenBSDでログインクラスを利用するのは断念

Let's note CF-SV8RDCVSにOpenBSD/amd64 7.9をインストールしました。まだOSを入れただけですので、これから設定していくことになります。まずは日本語環境から設定します。そのために環境変数「LANG」を「ja_JP.UTF-8」にします。これを設定するなら、シェルの初期化スクリプトを使うことが多いかもしれません。今のところ、次のような形態を想定しているので、シェルの初期化スクリプトを使うのは二の足を踏みます。

1. Windows11のRLoginを使ってSSHログインする。
2. xenodmでログインしてcwmを使う。 

 

SSHログインの場合、シェルには「tcsh」を使っているので、「~/.login」に設定することになります。一方でxenodmの場合、「~/.xsession」に設定することになります。それだけではなく、Bシェル系とCシェル系とに分かれるので、両者の設定を共用できません。こうなるのでログインクラスを使いたかったのですが、OpenBSDでは、バグなのか仕様なのか不明ですが、うまくいかないのです。

 

Geminiにアドバイスを求めた結果、「~/.xsession」の設定をワンライナーで加工して「~/.login」で利用すれば良いのではないかという結論に至りました。もっと複雑な方式を構築することも出来るかもしれませんが、「KISS原則」に従おうと思います。

「/etc/login.conf.d」はOpenBSD 7.1で導入

OpenBSDではディレクトリ「/etc/login.conf.d」というものがあります。調べてみると、OpenBSD 7.1の「What's New」で次のように書かれています。

 Introduced support for storing capability databases in /etc/login.conf.d, allowing easy addition of custom login classes from packages and made rcctl(8) look for the login class in both login.conf and login.conf.d/${class}. 

 

パッケージで使われることを想定して導入されたようです。何か実例はないかと探してみると「databases/mariadb」に「mysqld.login」を見つけました。

 

またOpenBSDでは、「LOGIN.CONF(5)」で「Sites with very large /etc/login.conf files may wish to create a database version of the file, /etc/login.conf.db, for improved performance. Using a database version for small files does not result in a performance improvement.」と書かれています。OpenBSDでは「cap_mkdb」にかけるか否かはオプションです。ところがFreeBSDでは、「LOGIN.CONF(5)」では「Whenever to this, or the user's ~/.login_conf, file are made, the modifications will not be picked up until cap_mkdb(1) is used to compile the file into a database.」と書かれているように、「cap_mkdb」にかけなければなりません。

OpenBSDのログインクラスは手強い

今夏に手に入れたLet's note CF-SV8RDCVSにOpenBSD/amd64 7.9をインストールしました。OSを入れただけなので、日本語環境とか、GUIとか、これから設定していくことになります。何から手を付けようかと思いましたが、まず日本語環境として、ロケール「ja_JP.UTF-8」、日本語フォント、日本語入力などを済ませようと思います。

 

まず最初にロケールの設定です。要するに環境変数「LANG」に「ja_JP.UTF-8」を設定するわけです。ユーザのホームディレクトリにあるドットファイルでファイルで設定する方法がありますが、ここはログインクラスを使おうと思います。FreeBSDではファイル「~/.login_conf」に書くだけでした。同じようにするだけかと思ったら、これはFreeBSD独自拡張であって、OpenBSDでは参照されないことが判明しました。

 

一方でOpenBSDにはディレクトリ「/etc/login.conf.d」という拡張があります。ファイル「/etc/login.conf」との使い分けが良く分からないので、マニュアル「LOGIN.CONF(5)」を良く読んでみようと思います。せっかくなので各BSDのマニュアルに目を通しておこうと思います。

• FreeBSD
• NetBSD
• OpenBSD

 

そもそもログインクラスとは何のために存在し、どのように使うことが想定されているのか、役割がよくわかりません。マニュアルに記載されているのは、書式とか、設定できる内容がほとんどです。偶に簡単な歴史が書かれていることもありますが、様々な環境でドットファイルに何を書き、何を書かないか、詳述されていることはなさそうです。何か参考になる資料があればと思います。

NetBSD/i386+MATEのdynabook SS SX/15AからOpenBSD/amd64+cwmのLet's note CF-SV8RDCVSへ

Windows Vista時代に購入したdynabook SS SX/15AをNetBSD/i386に入れ換え、MATEデスクトップ環境にして使ってきましたが、限界を感じるようになってきました。ここ数年は、32ビット環境を対象外とするアプリケーションが増えています。また、Vistaの頃から発生していましたが、PC本体が不調で、電源投入時にOSが起動しないことがあります。そういう場合には、本体を揺すってみたり、表面や裏面から押してみたりしているのですが、末期症状です。

 

2026年8月に、代替としてLet's note CF-SV8RDCVSを中古で購入しました。BSD系のOSを入れることには迷いはなく、Linux系は避けるつもりですが、FreeBSD/NetBSD/OpenBSDのような伝統的BSDにするか、DragonFly BSD/nomadBSD/helloSystemのような新興勢力BSDにするか、迷っていました。先月から今月にかけて各種BSDを試行検討してきました。さらにデスクトップ環境として何を選択するのかも、迷っていました。

 

最終的にFreeBSDかOpenBSDかの二択となりました。デスクトップ環境としてKDE plasmaを試行したらOpenBSDは動作が不安定だったこともあり、FreeBSDを選ぼうかという気になっていましたが、ブレーンストーミングとしてGeminiに相談しました。OpenBSDは独自の拘りに満ち溢れています。FreeBSDは、Linux系ほどではありませんが、NetBSDやOpenBSDのような拘りが薄く、使いやすさを追求する指向が強いと思います。

 

相談した結果、OpenBSDを選びました。デスクトップ環境を使うのは止めて、軽量ウィンドウマネージャであるcwmを使ってみようと思います。KDE/MATE/Xfceのようなデスクトップ環境は、初期状態からリッチな画面が提供されていますが、一方で軽量ウィンドウマネージャは、初期状態では地味な画面がデフォルトです。しかし設定次第でリッチな画面にできない訳ではないようです、antiXのような画面にすることも可能のようです。方向性は固まりました。 

新興BSDを検討

Let's note CF-SV8RDCVSに伝統BSD（FreeBSD/NetBSD/OpenBSD）を評価してみました。NetBSDは、無線LANインターフェイス未対応だったため、候補から脱落しました。伝統的なBSD以外にも、次のような新興勢力のBSDがあります。これを検討してみました。

1. DragonFly BSD
2. NomadBSD
3. MidnightBSD
4. GhostBSD
5. helloSystem
6. ravynOS

 

DragonFly BSDには「HAMMER」という独自のファイルシステムがあります。helloSystemやravynOSは独自色が強い印象です。しかし新興BSDは、基本的にFreeBSDをベースにしており、それぞれに方向性は異なるものの、伝統BSDのような違いはありません。

 

Let's noteにインストールするにあたり、伝統BSDと新興BSDを等価に考えていました。しかし検討してみると、結局は、FreeBSDにするか、OpenBSDにするかの二択に絞られてきました。どちらにするにしても、GUIが欲しいので、デスクトップ環境に何を選ぶのかも決める必要があります。だいぶ絞られてきましたが、もう少し検討を続けようと思います。

OpenBSDにKDE plasmaをインストール

Let's note CF-SV8RDCVSにOpenBSD 7.9をインストールしました。FreeBSDとは違い、インストールが終わるとxenodmでグラフィカルにログインできますが、起動するのはtwmです。OpenBSDらしい硬派な環境ではありますが、デスクトップ環境を入れようと思います。FreeBSDで各種デスクトップ環境を試してみました。OpenBSDでは、FreeBSDよりは選択肢が少なくなりますが、メジャーなKDE plasmaを入れることが可能です。

 

OpenBSDでパッケージからインストールするにはコマンド「pkg_add」を使用します。OpenBSD Handbookの「Desktop Environments and Window Managers」を参考に「doas pkg_add kde-plasma」とすると、460個ほどのパッケージがインストールされました。xennodmからログインすると、KDE plasmaが起動します。FreeBSDでは「KDE plasma Version 6.6.6」でしたが、OpenBSDでは「KDE plasma Version 6.6.4」でした。

 

日本語環境として、フォント「noto-cjk」 と日本語入力「fcitx-anthy」を入れておきます。この後で、KDE設定から「Region & Language」として「日本語」を選択します。ログインし直すと、日本語環境になりました。

 

この後は更にFreeBSD同様にアプリケーションを入れて評価しようと考えていたのですが、動作が若干怪しいです。アプリケーションのアイコンをクリックしても起動せず、ホームディレクトリにはコアがあります。何が原因なのかは調べていませんが、ほぼ何もしていない段階で動作が不安定になると、使い続ける意欲が下がるのは否めません。

 

OpenBSDの評価は、ここまでにしようかと思います。FreeBSD/NetBSD/OpenBSDと伝統的なBSDをLet's noteにインストールしてきました。NetBSDは無線LANインターフェイスが未対応でしたし、OpenBSDはKDEの動作に不安があります。今後は、新興BSDを試してみようかと思います。

OpenBSDは「wpa_supplicant」を使わない

Let's note CF-SV8RDCVSにOpenBSD/adm64 7.9をインストールしました。有線LANを有効にしておいてインストールしたので、有線LANは使えますが、無線LANを有効にする設定が必要です。直前にインストールしたNetBSD/amd64 11.0では、Let's noteの無線LANインターフェイスが認識されませんでした。しかしOpenBSD/amd64 7.9は、「iwm0」として、ちゃんと認識されています。

 

無線LANの設定は、FreeBSDやNetBSDでは「wpa_supplicant」が使われます。ところがOpenBSDでは勝手が違うようです。「HOSTNAME.IF(5)」に従い「/etc/hostname.iwm0」を準備します。『OpenBSD Frequently Asked Questions』の「Wireless Networking」も参考にします。接続先が未来永劫にわたり1つしかないのであれば、それ専用の記述方法があるようですが、ノートPCですから出先で接続する可能性があります。このため「join」を使う記述方法にしました。

 

wpa_supplicant.confでは、暗号キーを暗号化してファイルに格納しましたが、hostname.iwm0ではべた書きするようです。心配なので、0600にしておきました。

 

ファイルを用意して、再起動したら、あっさり繋がりました。もう少し何かあるかと思いましたが、簡単でした。

 

OpenBSDは、まだ初期インストールして、無線LANが繋がるようになっただけです。ここから、FreeBSD同様に、各種環境を整えていこうと思います。 

Let's note CF-SV8RDCVSにOpenBSD/amd64 7.9をインストール

Let's note CF-SV8RDCVSにOpenBSD/amd64 7.9をインストールしました。このマシンには、FreeBSD/amd64 15.1-RELEASE、NetBSD/amd64 11.0をインストールしてきましたが、いろいろな伝統的BSDや新興BSDを入れてみて、気に入った環境を探そうと思っています。

 

OpenBSDのインストーラは、「硬派」です。親切なGUIではないし、NetBSDのようなテキストベースのウィンドウでもありません。コンピュータ黎明期のUIのようにも見えます。

 

インストール中に「Do you want the X Window System to be started by xenodm(1)?」という質問で「yes」としておきました。インストールに成功し、再起動したら、xenodmというディスプレイマネージャが出てきました。ログインするとtwmという、これまた「硬派な」環境が立ち上がりました。

 

今の段階では、初期インストールが済んだだけです。FreeBSDのように、いろいろな設定をしていこうと思います。 

刈払機

自宅の庭の雑草をとるのに「草刈鎌」を使ってきました。手間がかかりますが、なんとかなりました。大変なのはもちろんですが、刈り終わったところが綺麗になっているのを見るのは、爽快です。

 

何年か前から、近所には町内会がボランティアで掃除している公園があり、そこの草刈りを将来的には手伝って貰えるとありがたいと言われるようになりました。そうなると手作業では大変ですから、刈払機が必要です。刈払機があれば、自宅の庭でも使えるので、検討に検討を重ねて、先月HiKOKIのCG18DAを購入しました。本体にはチップカッターが付属していましたが、自宅の庭で使うにはナイロンカッターの方が良さそうです。HiKOKIの別売り製品は高額なので、ホームセンターで安価なものを購入しました。また、充電器などの付属品を収納するため、これもホームセンターで手ごろな工具箱を購入しました。

 

準備万端整えて、自宅の庭で初めて刈払機を使ってみました。ナイロンカッターなので、土埃が飛びますが、あっという間に雑草が無くなっていくのは驚きです。また塀際などの雑草も刈れるので、とても助かります。バッテリは30分くらいしか持ちませんでした。

 

刈払機の威力に驚きましたが、地面の上にある雑草を刈り取っているだけです。これまで手作業でやっていたときは、地中の根も取り除いていたので、同じことが刈払機で出来るわけではありません。今後は、刈払機と手作業を併用していくことになると思います。

Let's note CF-SV8RCCVSにNetBSD/amd64 11.0をインストールしたが、無線LANが使えない

Let's note CF-SV8RDCVSにFreeBSD/amd64 15.1-RELEASEをインストールし、アプリケーションを入れたり、デバイスを使えるようにしたり、いろいろと調査してきました。なかなか悪くないと思いますが、他のBSDも試してみて、最終的に何を使うか決めようと思います。そういうことで、今度はNetBSD/amd64 11.0をインストールしました。

 

インストールそのものは、普通です。NetBSDのインストーラは、地味で、Ubuntuなどに比べると不親切と評されることもあります。そういう印象はありますが、インストール自体は、問題なく終わりました。

 

無線LANを設定しようと思い、「ifconfig -a」 してみると、デバイスが出てきません。Geminiに救いを求め、「pcictl pci0 list」したところ、「000:20:3: Intel Dual Band Wireless AC 9560 (miscellaneous network, revision 0x11)」と認識されています。ところがマニュアル「IWM(4)」では「The iwm driver provides support for Intel Wireless 3160, 3165, 3168, 4165, 7260, 7265, 8260, and 8265 PCIe Mini Card Ual Band newtork adapters.」と書かれており、未対応のようです。

 

Let's note CF-SV8は、2019年頃に登場したマシンですから、それほど最新機種ということもありません。FreeBSD/amd64では無線LANが使えていましたから、故障しているわけではありません。NetBSDのポリシーとして、綺麗に設計しようとしていて、対応が遅れているのでしょう。いつかは対応されると思いますが、今は使えないのは確かです。

 

NetBSDは諦めることにします。次はOpenBSDを試そうと思います。 

Let's note CF-SV8RDCVSのFreeBSD/amd64 15.1-RELEASEの内蔵カメラ

Let's note CF-SV8RDCVSにFreeBSD/amd64 15.1-RELEASEをインストールしました。このマシンには内蔵カメラがついています。これまで所有してきたデスクトップPCやノートPCで内蔵カメラがあるのは初めてです。当面使う予定はありませんが、ちょっと試してみました。

 

設定手順は難しくありません。

1. 「pkg install webcamd」でwebcamdをインストールします。
2. 本来なら「sysrc webcamd_enable="YES"」しておいて、「service webcamd start」すべきなのですが、一時的なテスト目的ですので、以下の手順で直接起動しました。
3. 「kldload cuse」しておいて、「webcamd -d ugen0.2 -B」として起動します。ここで「ugen0.2」は内蔵カメラのデバイス番号です。ここで「/dev/video0」などのデバイスが出来ていることを確認します。
4. 内蔵カメラを使うユーザは「pw groupmod webcamd -m ユーザ名」としてグループ「webcamd」を加えておく必要があります。

これで設定できたので、内蔵カメラを使ってみます。

1. 「v4l2-ctl -d /dev/video0 --list-ctrls」や「v4l2-ctl -d /dev/video0 --list-formats-ext」で内蔵カメラの情報を取得してみます。
2. 実際のアプリケーションで内蔵カメラを使ってみます。今回は「ffmpeg -f v4l2 -input_format mjpeg -video_size 1280x720 -ss 2 -i /dev/video0 -vframes 1 test.jpg」として、静止画をファイルに落としてみました。

 

以上で、動作は確認できました。当面利用することはないのですが、何かの折に役立つのではないかと思います。

Let's note CF-SV8RDCVSのFreeBSD/amd64 15.1-RELEASEでBluetooth

Let's note CF-SV8RDCVSにFreeBSD/amd64 15.1-RELEASEをインストールしました。このマシンにはBluetoothがあります。Bluetoothを積極的に使ってみたいという訳ではないのですが、どんな風に使うのか気になったので、設定してみました。

 

設定手順は難しくありません。

1. 「pkg install iwmbt-firmware」でファームウェアパッケージをインストールします。
2. 「usbconfig | grep -i bluetooth」でデバイスの番号を確認しておきます。
3. 「iwmbtfw -d ugen0.3 -f /usr/local/share/iwmbt-firmware」でファームウェアを転送します。ここでは「ugen0.3」が前項で確認したデバイス番号です。

 

これで設定できたので、Bluetoothを使ってみます。

1. 「hccontrol -n ubt0hci Read_BD_ADDR」でBluetooth MACアドレスを読み取ってみます。
2. 「hccontrol -n ubt0hci Inquiry」で周辺にある機器が反応するか確認してみます。

 

Bluetoothに対応した機器はスマホくらいしか所有していません。「Inquiry」で検出できたのは確認しました。しかしBluetoothを使って、何かをしようという気にはならなかったので、確認はここまでとしました。 

KB5124008の影響で「ファイル履歴が外付けドライブを認識しない」という問題が発生しているらしい

記事「Windows 11の大型アップデートKB5124008で深刻な不具合続出…「更新を遅らせるな」の直後に混乱発生」によると、「ファイル履歴(File History)がバックアップ用ドライブを認識しないという報告が多数上がって」いるそうです。私が「ファイル履歴」が動かなくなったのも、これが原因なのかもしれません。

 

マイクロソフトは「ファイル履歴」を重視していないように見受けられます。推測となりますが「OneDrive」を推しているのでしょう。

 

もしかすると、この問題が解決するパッチが出るかもしれません。しかし私自身は、「ファイル履歴」からFreeFileSyncに移行するつもりです。 

FreeFileSyncにおける「比較」の挙動

Windows11では「ファイル履歴」の動作が怪しいので、FreeFileSyncを使用して同等機能を実現しようと思います。ちょっと試したら、ほぼ期待したようになったのですが、こちらはこちらで動作が怪しいです。

 

同期元はWindows11で、同期先はFreeBSD上のSambaです。初回は同期対象ファイルを全てコピーします。これは想定しているとおりです。問題は、2回目以降の同期対象ファイルが多すぎることです。ログを残す設定にしているので、どのファイルがコピーされたのかは把握できます。しかし、全く変更していないファイルが同期対象ファイルとして選ばれています。これは、FreeFileSyncにおける「比較」処理の問題です。

 

FreeFileSyncでは、同期元と同期先のファイルを「比較」し、同期対象ファイルを選択します。この「比較」では、「変更日時とファイルサイズ」、「ファイル内容」、「ファイルサイズのみ」という手段が提供されています。よく利用されるのは「変更日時とファイルサイズ」のようです。

 

FreeFileSyncには、デバッグ用ログというものが存在しないので、挙動を観察して状況を推測するしかありません。同期対象として選択されるファイルについて、Windows11側とSamba側のタイムスタンプの精度が関係している気がします。Windows11側では秒以下の時間も記録しているようですが、Samba側では記録していないようなので、「比較」すると「差異がある」という判断になってしまうようなのです。

 

それでは「比較」を「ファイルサイズのみ」でおこなうことにしたら、うまくいくのではないかと思い、試してみました。ところが相変わらず、全く変更していないファイルが同期対象ファイルとして選択されてしまいます。「比較」には「ファイル内容」という手法もありますが、ファイルの内容を読むのは処理時間が相当長くなる恐れがあるので、試してみるのは避けようと思います。 

 

2回目以降の同期で誤って同期対象ファイルを選択していると思われるのは、全ファイルの1%弱なので、スッキリと納得はできませんが、このまま利用を続けてみようと思います。 

Windows11の「ファイル履歴」は非推奨なのか

自宅で使用しているデスクトップPCは、Windows8からWindows10に移行し、昨年にはWindows11を使っています。Windows10の頃から「ファイル履歴」を使用してきました。普段のオペレーションで、うっかりファイルを削除してしまったり、上書きしてしまったことがあり、その場合に救出するのに役立ちました。

Windows11になってから、「ファイル履歴」の動作がWindos10の頃とは違う気がしていましたが、動作はしていました。しかし数日前に動作が止まり、再実行させようとしても、「ファイル履歴のドライブに再接続してバックアップを実行するまでの間、ファイルは一時的にハードドライブにコピーされます。」というエラーがでてしまいます。解決を試みましたが、動作するようになりません。

 

Geminiに相談すると、Windows11では「ファイル履歴」を非推奨にしようとしている傾向がみられるとのことでした。そうであれば、もう「ファイル履歴」を使い続けるのは諦め、何か別の手段に移行しようと思います。FreeFileSyncというものがあるそうなので、使ってみようと思います。

FreeBSDにおいてディスプレイマネージャのパッケージは共存できない

Let's note CF-SV8RDCVSに様々なディスプレイマネージャをパッケージからインストールしてみました。最初はKDEと親和性が高いSDDM、次にGNOMEのお友達のGDM、それからLightDMなどです。全て「pkg install」でインストールしました。その時に画面をよく見ていなかったのが悪いと言われれば、その通りなのですが、これらのディスプレイマネージャは、共存できないようです。つまり、他のディスプレイマネージャをインストールしようとすると、既にインストールされているディスプレイマネージャは、自動的に削除されてしまいます。

 

ディスプレイマネージャを使うには、/etc/rc.confに「lightdm_enable="YES"」のような設定が必要です。昔はエディタで手書きしていましたが、今は「sysrc」というコマンドを使うのが推奨されているようです。

 

複数のディスプレイマネージャを入れると、/etc/rc.confに「sddm_enable="NO"」とか「lightdm_enable="YES"」のような設定が残ります。複数のディスプレイマネージャを「YES」にするのは、さすがにマズいと思いますが、どれか一つだけを「YES」にして、残りを「NO」にするのは、問題ないと思います。それでは、「YES」と「NO」を切り替えながら、複数のディスプレイマネージャを切り替えて使えるのかというと、どうも違うようです。つまり、そのYESやNOの設定とは無関係に、最後に「pkg install」したディスプレイマネージャ以外は、削除されているからです。

 

もしSDDMをインストールし、「sddm_enable="YES"」としたとします。次にLightDMをインストールし、「lightdm_enable="YES"」として、忘れずに「sddm_enable="NO"」とします。さて、再度SDDMを使う場合は、どうなるでしょうか。「sddm_enable="YES"」とするだけではダメなのです。何故ならSDDMのパッケージは、LightDMをインストールした際に削除されているからです。あらためてSDDMをインストールし直さなければなりません。

 

KDEやXfceのようなデスクトップ環境は、複数インストールしておいて、切り替えて使用できます。しかしSDDMやLightDMのようなディスプレイマネージャは、複数インストールできませんので、切り替えてるつもりなら、そのたびにインストールが必要です。

 

ディスプレイマネージャもデスクトップ環境のように、複数インストールして、切り替えて使用できても良いような気もしますが、できない「仕様」のようです。ちょっと混乱して、勘違いしてしまいました。 

KDE、GNOMEに次いで、Xfce

Let's note CF-SV8RDCVSにインストールしたFreeBSD/amd64 15.1-RELEASE環境で、KDE、GNOMEに次いでXfceを入れてみました。導入手順は、これまでと同様で、『FreeBSD Handbook』の「8.2.3. XFCE」に従いました。GNOMEでは手順通りでは動作しなくて苦労しましたが、Xfceはあっさり動作しました。

 

これまで、KDEやGNOMEをインストールしてきたので、Xfceのプログラムメニューには、KDEやGNOMEのアプリケーションも出現しています。しかも、KDEでは、note-jpやfcitx5-anthyなどの日本語環境を整えておいたので、Xfceでも日本語環境が引き継がれています。そういうものなのでしょうか。デスクトップ環境を入れるたびに、個別に日本語環境を設定する必要があると思い込んでいたので、何もしなくて済んで有難いことです。

 

ディスプレイマネージャはLightDMです。これまでインストールしたKDEやGNOMEを選ぶこともできます。その日の気分でディスプレイ環境を切り替えられるというのも、予想外なので、驚きです。 

FreeBSD 15.1のGNOMEではGDMではなくLightDMが無難

Let's note CF-SV8RDCVSにFreeBSD 15.1-RELEASEをインストールしました。X.orgを使ってデスクトップ環境としてGNOMEを入れてみました。GNOMEを使えるようにはなりましたが、GDMではなく、LightDMが必要でした。

 

FreeBSD公式サイトにある『FreeBSD Handbook』の「8.2.2. GNOME」に従って作業しました。とても簡単で、KDEの時と同様かと思いましたが、一筋縄ではいきませんでした。

1. 再起動したら、GDMの画面に切り替わりません。しかも「gdm[53250]: GLib-GIO: g_dbus_proxy_new_for_bus_sync: assertion 'g_variant_is_object_path (object_path)' failed」という不穏なメッセージがでています。
2. Geminiに相談すると、追加作業が必要でした。
1. /etc/fstabに「fdesc /dev/fd fdescfs rw 0 0」を書いておきます。
2. /etc/rc.confに追加するため「sysrc avahi_daemon_enable="YES"」を実行しました。
3. これで再起動したら、GDMは動きましたが、パスワードを入力しても無反応になってしまいます。
4. いったんGDMを無効にして、startxでGNOMEが動くか確認してみると、問題ないことがわかりました。
5. FreeBSD 15.1でGDMが動かないと判断し、GDMを止めて、LightDMに変更しました。

 

LightDMならば、ログインに問題はなく、GNOMEも動作しました。GNOMEは、先日のKDEとは大きくことなり、画面操作の感覚がつかめません。しかも、気のせいかもしれませんが、KDEよりも重い気がします。当初は、KDE同様、日本語環境の設定などをしてみようと思っていましたが、意気消沈しました。KDEに続いてGNOMEを入れた目的は、Let's noteに様々な環境を構築してみて、気に入った構成を探すためです。その一環としてGNOMEを入れましたが、候補からは外そうと思います。

 

次は、『FreeBSD Handbook』でGNOMEの次に記述されているXFCEを試そうと思います。 

KDE Plasmaと組み合わせるデスクトップマネージャ

Let's note CF-SV8RDCVSにFreeBSD/amd64 15.1-RELEASEをインストールし、デスクトップ環境にはKDE Plasmaを使いました。GUIのログイン画面をデスクトップマネージャと呼ぶようですが、KDEではSDDMを使います。デスクトップ環境とデスクトップマネージャは一心同体のように見えますが、本当に問題ないかどうか不確かですが、基本的に両者は独立していることになっています。つまりデスクトップ環境はKDEでも、デスクトップマネージャをSDDM以外にすることができることになっています。

 

いろいろなデスクトップマネージャを試してみましたが、結果として成功しませんでした。仕方ないのでSDDMに戻そうとしたら、あろうことかSDDMも動作しなくなってしまいました。どこかのログにエラーメッセージが出ているかもしれないので、それを手掛かりに復旧しても良いのですが、KDEの代わりにGNOMEを試そうかと考えています。

 

FreeBSDでデスクトップマネージャを切り替えるには、基本的にpkgからインストールし、起動するデスクトップマネージャを/etc/rc.confで有効化します。デスクトップマネージャによっては、他のファイルにも設定する場合があります。これが基本作業ですが、試したデスクトップマネージャは、次のとおりです。

• GDM
• LightDM
• LXDM
• XDM

 

うまくいかなかった状況は様々です。GDMは、エラーメッセージがでて、そもそも起動しませんでした。LXDMは、pkgにありませんでした。LightDMとXDMは、ログイン画面は出たのですが、ユーザ名とパスワードを入力してもデスクトップ環境に遷移せず、ログイン画面に戻ってしまいます。

 

ちょっと試してみて駄目だったので直ぐに諦めましたが、ログなどを参照して解決できるのかもしれません。 

 

FreeBSD/amd64の電力設定を見直す

Let's note CF-SV8RDCVSにFreeBSD/amd64 15.1-RELEASEをインストールしました。X.orgでKDE Plasma 6を入れて、日本語環境も整えました。このマシンは、dynabook SS SX/15Aの代替として使っていくつもりです。dynabookは、当初Windows Vistaでしたが、NetBSD/i386に変更しています。旧いマシンだから劣化しただけではない気がしますが、起動しているだけでもバッテリを使い切ってしまうので、ACアダプタを常時つないでいました。それに比べるとLet's noteは、バッテリがもちます。感動的です。

 

FreeBSDの電力設定を見直して、よりバッテリがもつようにしておきたいと思います。このために、以下の設定を変更しました。

1. hw.acpi.cpu.cx_lowest=Cmax
2. hw.pci.do_power_nodriver="1"

 

1番目の設定は、当初「hw.acpi.cpu.cx_lowest: C1」 でした。「sysctl dev.cpu.0.cx_usage」すると「dev.cpu.0.cx_usage: 100.00% 0.00% 0.00% last 71921us」のようになりました。この設定を「/etc/sysctl.conf」に加えると「hw.acpi.cpu.cx_lowest: C8」となり、cx_usageも「dev.cpu.0.cx_usage: 17.34% 67.87% 14.78% last 34861us」のようになりました。

 

2番目の設定は、当初「0」でした。Geminiのアドバイスでは、「1」が推奨されるとのことなので、「/boot/loader.conf」に設定を追加しました。

 

これらの設定を見直したことで、より長くバッテリがもつと良いのですが。 

FreeBSD 15.1&KDE Plasma 6では、何も設定を追加せずにLet's note CF-SV8RDCVSのSDカードリーダを使えた

Let's note CF-SV8RDCVSにFreeBSD/amd64 15.1-RELEASEをインストールしました。それからX11でKDE Plasma 6を入れ、日本語設定なども済ませました。ここまでは、一般的なインストールに過ぎません。Let's noteにはSDカードリーダが内蔵されているので、これを使ってみます。

 

まず最初にGeminiに相談してみました。すると設定方法を指南してくれたのですが、結局は何も追加設定することなく、SDカードが利用可能でした。まずpciconfでは、次のように認識されています。

sdhci_pci0@pci0:58:0:0: class=0x080501 rev=0x01 hdr=0x00 vendor=0x1217 device=0x8520 subvendor=0x1217 subdevice=0x0002
    vendor     = 'O2 Micro, Inc.'
    device     = 'OZ777 SD/MMC Card Reader Controller'
    class      = base peripheral
    subclass   = SD host controller

特に設定することもなくSDカードを挿入すると、勝手にマウントしてくれました。dmesgでは、次のメッセージが残っています。

mmc0: <MMC/SD bus> on sdhci_pci0
mmcsd0: 2GB <SD 00000 1.0 SN 75792127 MFG 11/2010 by 27 SM> at mmc0 50.0MHz/4bit/65535-block

もうちょっと何かすることがあると予想していたので、いい意味で裏切られました。

 

FreeBSD 15.1ではLet's note CF-SV8RDCVSの円形タッチパッドの特徴を活かせない

Let's note CF-SV8RDCVSにFreeBSD 15.1-RELEASEをインストールしました。このままでは、デスクトップ環境も日本語環境もありません。そこでX.org、KDE Plasma  6、fcitx5-anthy、noto-jpなどを入れて、ひととおり環境を整えました。ここまででならば、一般的なインストールにすぎません。せっかくLet's noteを使っているので、その特徴的な円形タッチパッドを有効にしてみようと考えました。

 

結論からいうと、駄目でした。

 

そもそもタッチパッドがうまく認識できていないのです。「Let’s Note CF-SZ5 のタッチパッドクルクル OK。」には「一番最後が model Generic PS/2 mouse か model Synaptics Touchpad の違いです。」とあるように、どう認識されているかが重要です。Geminiに助けてもらいながら、いろいろと試してみたのですが、うまくいきませんでした。Geminiに言わせれば、OSレベルで認識できていないので、KDEだろうがGNOMEだろうが、たぶん駄目だろうとのことです。

 

FreeBSD 15.1は、すべてのLet's noteにおいて円形タッチパッドを使えないのか、たまたまCF-SV8RDCVSが駄目なのかは不明です。当面は円形タッチパッドとして鑑賞するにとどめますが、ゆくゆくは機能するようになって欲しいと思います。 

FreeBSD 15.1-RELEASEのKDE Plasmaでfcitx-mozcが無かったのでja-fcitx5-anthyを入れた

Let's note CF-SV8RDCVSにFreeBSD/amd64 15.1-RELEASEをインストールしました。それからX.orgでKDE Plasmaを入れましたが、このままでは日本語環境がありません。日本語環境として、日本語フォントを日本語変換エンジンを入れます。

 

最初に日本語フォントを入れました。IPAexにしようかと思いましたが、調べてみるとnoto-jpが良さそうです。

1. pkg install noto-jp

 

これで日本語が表示できるようになりましたので、次は日本語変換エンジンです。ネットの情報を調べるとKDEなら「fcitx-mozc」が選ばれているようです。しかしパッケージからは消えていました。それならば「ibus-mozc」にしようかとも考えましたが、これもありませんでした。そうなると「ja-fcitx5-anthy」をインストールすることにしました。インストール中に多少手間取ったところはありましたが、ほぼ問題なくインストールし、設定を終えました。

1. pkg install fcitx5 fcitx5-configtool fcitx5-qt{5,6} fcitx5-gtk{2,3,4} ja-fcitx5-anthy 
2. 環境変数の設定が必要です。シェルの初期設定ファイルに書いても良いのですが、ログインクラスを使うことにしました。~/.login_confに次のように書いて、データベースを更新します。

   me:\
   :charset=UTF-8:\
   :lang=ja_JP.UTF-8:\
   :setenv=XMODIFIERS=@im=fcitx,GTK_IM_MODULE=fcitx,QT_IM_MODULE=fcitx:

3. ここからはKDEの設定です。「System Settings」で「System」>「Autostart」において「New Application」として「Fcitx5」を追加します。ここいったんログアウトし、再ログインします。
4. システムトレイにあるキーボードアイコンを右クリックし「Input Method Settings」を選びます。
5. 「+ Add Input Method ...」として「Anthy」を追加し、「Select System layout ...」として「Japanese (jpn)」を選択しました。
6. 以上の設定が済んだら「Apply」しておきます。

 

これで日本語入力もできるようになりました。以前にdynabook SS SX/15AにNetBSD/i386をインストールした時は、そうとう苦労して日本語環境を整えましたが、あまりにも簡単なので、驚きです。 

FreeBSD 15.1-RELEASEでKDE Plasmaをインストール

Let's note CF-SV8RDCVSにX.orgをインストールしました。twmが使えるようになりましたが、素朴すぎます。『FreeBSD Handbook』の「Chapter 8. Desktop Environments」に従ってデスクトップ環境を入れようと思います。まずは「KDE Plasma」を入れてみます。

 

インストールは簡単です。以下のコマンドを入力するだけです。

1. pkg install kde
2. sysrc dbus_enable="YES"

 

これだけでも良いようなのですが、ディスプレイマネージャ「SDDM」も入れてみます。

1. pkg install sddm
2. sysrc sddm_enable="YES"

 

ここで再起動したら、SDDMのログイン画面が出ました。しかしパスワードを入力しても、入力を間違っているわけでもないのに、ログイン画面に戻ってしまいます。ログファイル「/var/log/sddm.log」をGeminiに見てもらったところ、「Plasma (Wayland)」として動作しようとしているとのことでした。ログイン画面の左下をよく見ると「デスクトップセッション: Plasma (wayland)」と表示されています。ここで「Plasma (X11)」に変更して、改めてパスワードを入力すると、KDE Plasmaが使えるようになりました。Geminiによると、FreeBSDでpkgでインストールすると、初期状態が「Plasma (Wayland)」になっているそうです。

将来的にはWaylandに一本化されるのかもしれませんが、現状ではX.orgの方がトラブルが少ないようです。

FreeBSD 15.1-RELEASEのX.orgインストール

中古で先月購入したLet's note CF-SV8RDCVSにFreeBSD 15.1-RELEASEのインストールを済ませました。これだけではXが使えないので、『FreeBSD Handbook』の「Chapter 5. The X WIndow System」に従って、X.orgをインストールしました。

 

手順に従い、次のコマンドを入力しました。

1. pkg install drm-kmod
2. sysrc kld_list+="i915kms"
3. pkg install xorg
4. pw groupmod video -m 一般アカウント名

 

このあと「一般アカウント名」でログインし、startxしてみましたが、エラーになりました。インストールしたドライバが読み込まれていないようなので、再起動してから改めてstartxしたらtwmが動作しました。

 

xtermでキーしてみたら、どうもキー配列がASCIIになっているようです。設定を調整する必要がありそうなのですが、twmを常用するわけではないので、デスクトップ環境のインストールに進みたいと思います。  

amd64移植におけるテーブル構造

東大版Palo Alto Tiny BASICをWSL2のUbuntu環境に移植しようと作業を進めています。BASICというのは、プログラム編集機能とインタプリタ機能が統合されています。オリジナル版は、SDK-80のシリアルポートにASR-33が接続された環境を想定していますから、プログラム編集機能といっても簡単なものです。amd64移植にあたり、機能的な拡張は全くおこなわない方針です。今日の水準から見れば貧弱そのものですが、移植する過程を学ぶのが主目的なので、本格的な機能は求めないことにします。

 

ひとまず編集機能はできあがりましたので、次はインタプリタ機能です。ここで問題となるのが、入力された文字列を認識して、対応する機能に分岐するロジックです。オリジナル版は、i8080というものに強く依存しているので、そのままamd64に対応させるのはよくないと考えています。基本的な構造は「CASEマクロ」にあります。

CASE   .macro STR,ADRS
       DB    &STR
       DB    (&ADRS SHR 8)+80H
       DB    &ADRS AND 0FFH
       .endm

このマクロを使って次のようなテーブルが作られます。例えば「LIST」という文字列だったら、LISTルーチンに飛ぶことになります。

CMDKW: CASE  'LIST',LIST
       CASE  'RUN',RUN
       CASE  'NEW',NEW
STMKW: CASE  'NEXT',NEXT

ここで注目すべきは、文字列の終端を認識するために、ルーチンのアドレスのMSBをONにしている点です。しかもi8080はリトルエンディアンなのに、ビッグエンディアンのように逆転させて配置しています。これはi8080の事だけを考えて組み立てるのであれば、秀逸なアイディアと言えます。しかしamd64に移植しようとするなら、あまりよろしくありません。しかも、amd64への移植が済んだら、他の環境にも移植したいと考えているので、なおさらです。

 

どうしたらよいか、これから検討します。Geminiに相談してみようと思います。 

 

sudo、doas、opendoas

最近購入したLet's note CF-SV8RDCVSにFreeBSD 15.1-RELEASEをインストールしました。個人で使用するだけですが、昨今のセキュリティ事情を踏まえると、いい加減な運用は避けた方が良いだろうと思います。rootの他に一般ユーザを作るのは当然ですが、その一般ユーザをwheelグループに入れるか否かは慎重に考える必要があります。一般ユーザがWheelグループに入れば「su」でrootになれますが、セキュリティ的には注意が必要です。 

 

最近はrootアカウントを使わず、「sudo」を使うのが一般的です。しかし「sudo」は、多機能すぎて肥大化していることが問題視されており、代替としてOpenBSD由来の「doas」があります。

 

FreeBSDにもdoasをインストールしようと思いましたが、doasの他にopendoasが存在することに気づきました。何が違うのかと言うと、「persist」オプションがあることです。これがあれば、sudoのように、またはOpenBSD上のdoasのように、いったん認証に成功したら一定時間は認証を省略できるようになります。

 

FreeBSDに限りませんが、一般ユーザが「su」で直接rootになれるのは、セキュリティ的には避け、sudoやdoasを用いるようにした方が良さそうです。 

FreeBSD 15.1-RELEASEの無線LAN設定

Let's note CF-SV8RDCVSにFreeBSD/amd64 15.1-RELEASEをインストールしました。インストール中は有線でネットワークに繋ぎました。今後デスクトップ環境を入れていくつもりですが、その前に無線LANの設定を済ませておこうと思います。

 

『FreeBSD Handbook』では「7.4. Wireless Networks」として設定手順が説明されています。それに従って作業すると、次のようになります。

1. 接続先となるSSIDとPSKを入手しておきます。
2. 「/etc/wpa_supplicant.conf」を作成します。ひな形が示されているので、そこに入手したSSIDなどの情報を入れます。
3. 「/etc/rc.conf」に無線LANの情報を追加します。これも示された手順のとおりです。ただし設定ファイルを直接編集せずに、「sysrc」というコマンドを使っているのを初めて知りました。
4. 以上で設定が済んだので「service netif restart」とすれば、繋がるはずです。

 

ところが繋がりませんでした。これまではdynabook SS SX/15AのNetBSD/i386で接続できていたので、何が違うのか確認してみました。私の自宅ではステルスSSIDとしていたため、「network」の設定の中に「scan_ssid=1」を入れておく必要があるようです。これを追加したら、繋がるようになりました。しかしGeminiと相談した結果、ステルスSSIDはセキュリティ的に望ましくないという意見だったので、ステルスSSIDを止めて公開設定に変更しました。そうなると「scan_ssid=1」は不要です。

 

さらに「/etc/rc.conf」に「create_args_wlan0="country JP regdomain JAPAN"」という設定も追加しました。『FreeBSD Handbook』が英語版であるからなのか、日本特有の設定については記述がありません。これもまたGeminiとの相談の結果ですが、この設定は必須とのことでしたので、追加しました。

 

以上で無線LANが使えるようになりました。若干トラブルがありましたが、とても簡単でした。 

「FreeBSD-15.1-RELEASE-amd64-memstick.img」に入っているのは「PkgBase」

最近入手したLet's note CF-SV8 RDCVSにFreeBSD/amd64 15.1-RELEASEをインストールしてみました。公式サイトから「FreeBSD-15.1-RELEASE-amd64-memstick.img」を入手し、RufusでUSBメモリに書き込みます。ハンドブックの「2.3.1. Prepare the Installation Media」に「-memstick.img: This file contains all of the files needed to install FreeBSD, its source, and the Ports Collection. 」と書かれているように、インストールに必要なファイルは全て入っています。つまりインストール中にネットワークアクセスは必要ありません。もし「-bootonly.iso」や「-mini-memstick.img」を使うと、必要なファイルをネットワーク越しに取得することになります。

 

インストール中の選択肢に「Select Installation Type」があります。これまでのFreeBSDで使われてきた「Distribution Sets」か、FreeBSD 16からデフォルトになると言われている「Packages (Tech Preview)」のどちらを使うか選ばなければなりません。PkgBaseがデフォルトになるのは次のバージョンからですので、今回は「Distribution Sets」でインストールしようと考えました。ところが、ネットワークへのアクセスは不要なはずなのに、ネットワークからファイルを取得しようとするのです。

 

ネットワークに接続せずにインストールを完了させたかったので、ネットワークへのアクセスが発生すると困ります。ここで気づきましたが、「-memstick.img」にはインストールに必要なファイルが全て入っているとは言っても、「Distribution Sets」と「Packages」の双方が入っているわけではないようです。入っているのは「Packages」の方だけで、「Distribution Sets」を選んでしまうと、ネットワーク越しに取得しにいくのでしょう。

 

案の定、「Packages (Tech Preview)」を選択したら、ネットワークへのアクセスする事なく、インストールが完了しました。インストール完了後に改めて起動させたところ、Let's note CF-SV8RDCVSでFreeBSD/amd64 15.1-RELEASEが無事に起動しました。 

「LBUF EQU VTOP+0037H」が0036Hではない謎

共立出版の『マイクロコンピュータのプログラミング』に掲載された東大版Palo Alto Tiny BASICについて調査しています。アセンブラで書かれたプログラムの先頭では、以下のようにメモリ配置が定義されています。

;  MEMORY MAP
ITOP   EQU   0000H
ISIZE  EQU   0800H
LTOP   EQU   1000H
VTOP   EQU   5000H
LBUF   EQU   VTOP+0037H        ;0037H?
LBFSZ  EQU   80
MSTK   EQU   LBUF+LBFSZ
TMSTK  EQU   MSTK+30        ;30?
STACK  EQU   6000H

 

本文では「図3 メモリマップ」として説明されています。VTOPとLBUFの間は「変数エリア」になっています。Tiny BASICですから、プログラムで使える変数は「A」～「Z」と配列「@」の27個に制限されています。また変数に格納できるのは16ビット整数だけです。つまり27種類×2バイト=54バイトあれば良い計算になります。これは、16進数ならば0036Hです。

 

ところがLBUFは、「VTOP+0037H」として定義されています。何故「0036H」ではないのでしょうか。プログラムを解析してみると、ロジックの都合ではないかと思われます。

 

LBUFからLBFSZ（=80）は、「行バッファ」です。キー入力される文字列を格納する領域です。この処理は、次のようになっています。

EDITR: MVI   A,'>'
       CALL  GETL
       PUSH  D
       LXI   D,LBUF
       CALL  GINT
       CALL  SKPBL
       MOV   A,H
       ORA   L
       POP   B
       JZ    KWCPR
INSRT: DCX   D
       MOV   A,H
       STAX  D
       DCX   D
       MOV   A,L
       STAX  D

 

GETLルーチンで入力された文字列は、先頭に数字があるかをGINTルーチンで判断しています。つまり「10 PRINT A」のように入力すると、先頭の数字をバイナリに変換し、数字文字列と置き換えます。また空白も取り除くので、入力された行は、「<0A><00>PRINT A」としてメモリ上に置かれることになります。数字文字列をバイナリに変換した結果を格納しているのが、INSRTで始まる処理です。

 

このようなロジックになっているので、現代的な書き方であるインデントを使用としても、全て取り除かれてしまいます。「10         PRINT A」のように空白を入れても、内部構造は「<0A><00>PRINT A」になります。さらに当時の厳しいメモリ事情の為なのか、Tiny Trekのプログラムでわかるように、意味がとおるなら空白文字を省くことができます。つまり「10PRINT A」としてもエラーではありません。

 

ここで考えなければならないのは、数字文字列をバイナリに変換して格納している点です。バイナリは16bitなので、2バイト必要です。数字文字列が「10」であったり、例え一桁であったとしても「1 PRINT A」のように空白が入っていれば、2文字あるので、16bitのバイナリを格納することができます。ところが「1PRINT A」のような記述を認めているので、数字文字列が1文字しかない場合、16bitのバイナリを格納するには領域が不足してしまうのです。プログラムでは例外処理がありません。どうしているかというと、LBUFの直前にある「変数エリア」に踏み込んでしまうのです。これが「0036H」ではなくて「0037H」になっている理由と思われます。

 

試しに「LBUF EQU VTOP+0036H」としてアセンブルしたプログラムで実験してみました。変数「Z」に何か値を代入しておいて、「1PRINT Z」を入力すると、変数「Z」の値が変わってしまいました。やはり変数「Z」の領域を壊してしまうのです。

 

こうならないようにするため、あえて「LBUF EQU VTOP+0037H」として1バイト分ずらして領域を確保しているのですが、極めて技巧的です。 

東大版Palo Alto Tiny BASICのGETIルーチンをamd64に移植するとLEA命令を使う

SDK-80のシリアルポートにASR-33が接続された環境を想定している東大版Palo Alto Tiny BASICをWSL2Ubuntu環境に移植しています。Geminiと相談しながら作業しています。BASICというものは、編集環境と実行環境が統合されているところに真髄があるのですが、まず編集環境の方から移植を進めています。数字文字列を2進数に変換するために「GETI」というルーチンがあります。これをamd64にしてみます。

 

オリジナルは次のようになっています。

GINT:  LXI   H,0000H        ;GET INTEGER
       MOV   B,H
       CALL  SKPBL
GETI1: CPI   '0'
       RC                    ;RETURN INTEGER IN HL
       CPI   '9'+1
       RNC
       MVI   A,0F0H
       ANA   H                ;IF INTEGER＞#0FFF ERHOW
       JNZ   ERHOW
       INR   B
       PUSH  B
       MOV   B,H            ;HL HL+10
       MOV   C,L
       DAD   H
       DAD   H
       DAD   B
       DAD   H
       LDAX  D                ;HL HL+(DE)&#0F
       INX   D
       ANI   0FH
       ADD   L
       MOV   L,A
       MVI   A,00H
       ADC   H
       MOV   H,A
       POP   B
       LDAX  D
       JM    ERHOW
       JMP   GETI1

 

Geminiの指導を受けながらamd64に移植したら、次のようになりました。

.equ    GINT_DIGIT_MAX,        (NINE-ZERO)
.equ    GINT_MAX_BEFORE_X10,    0x0FFF
gint:    xor    eax,eax
    xor    ecx,ecx
    call    skpbl
geti1:    movzx    edx,byte ptr [rdi]
    sub    edx,ZERO
    cmp    edx,GINT_DIGIT_MAX
    ja    geti9
    cmp    ax,GINT_MAX_BEFORE_X10
    ja    erhow
    inc    cx
    # amd64の真骨頂: LEA命令による AX = (AX * 10) + DX
    lea    eax,[rax + rax*4]
    lea    eax,[rdx + rax*2]
    inc    rdi
    test    ax,ax
    js    erhow
    jmp    geti1
geti9:    ret

amd64と比べるのは卑怯かもしれませんが、i8080は命令が貧弱です。レジスタの内容を10倍するのも、簡単にはできません。一方amd64は、IMUL命令で簡単に10倍できるはずですが、Geminiが提示してきたのはLEA命令を使う方法でした。なぜIMUL命令を使わないでLEA命令なのかとGeminiに問うと、内部処理の都合上この方が速いのだそうです。ここがボトルネックという訳ではないので、微妙に速くなっても全体としては速さを意識できないと思います。しかし、いかにもamd64チューニングされているという感じにはなりました。 

セキュアブートとUSB起動

Let's note CF-SV8RDCVSを中古で購入しました。Windows11が入っていたので、HWiNFOやCrystalDiskInfoなどで、情報を収集しておきます。また自宅の無線LANに接続してみて、問題ないことを確認しました。これで、ひととおり初期状態の確認が済んだので、Windows11とはお別れして、BSD系OSに入れ換えてみようと思います。

 

これまで使っていたdynabook SS SX/15AではNetBSD/i386を使っていました。せっかくなので各BSDを試してみて、気に入ったものを選ぼうと思います。まずは、FreeBSD/amd64 15.1を試してみます。公式サイトからUSBのためのIMGファイルを取得し、RufusでUSBメモリに書き込みます。これを使って起動しようとしたら、ちょっと問題が発生しました。

 

dynabookの頃には存在しませんでしたが、最近は「セキュアブート」というものがあります。これが有効になっていると、FreeBSDのインストーラが起動しません。しかもLet's noteは、USBメディアの起動順位が低いので、ただ挿しただけでは起動してくれません。

 

「セキュアブート」を無効にするには、電源投入時にF2キーを押し、設定画面に入ります。「セキュアブート」の項目を「無効」に設定して、保存すれば完了です。

 

USBメディアの起動順位を上げるのも、同様に設定画面で出来そうに見えます。しかし設定しても、USBメディアを抜くと優先順位が最下位に戻ってしまうようです。これはセキュリティ上の考慮なのかしれません。USBメディアから勝手に起動できてしまうと、不審者が勝手に操作できてしまうのを避けようとしているのかもしれません。理由は定かではありませんが、できないものは仕方ないので、USBから起動させたい場合は、いちいち設定画面に入ることになりそうです。 

Let's note CF-SV8RDCVSを購入

20年ほど前に購入したdynabook SS SX/15Aは、当初Windows Vistaがインストールされていました。10年ほど前にサポート終了したので、NetBSD/i386に入れ換えて使ってきました。しかし近年、ソフトウェアの32ビット対応が無くなりつつあります。さらにハードウェア本体も劣化の傾向が見られ、電源を入れてても起動しなくなることが増えてきました。起動しなくても、揺すったり、叩いたりして、何度も電源投入を試みると起動します。いったん起動してしまえば、途中で落ちることはありません。ハードウェア的にも、ソフトウェア的にも、限界が迫ってきている気がするので、新しいPCを調達することにしました。

 

購入するのを決意したのは今春です。dynabook SS/SX15Aの後継ですから、いわゆるサブノートが候補です。Microsoft Windowsがインストールされていたとしても、それは捨てて、伝統か新興のBSDに入れ換えるのが、当初からの方向性でした。新品を購入することは考えず、中古を探そうと考えていました。ただし中古PCを店頭で探すにも、秋葉原に気軽に行ける場所に住んでいる訳ではないため、通販かオークションなどを使うしかありません。いろいろな販売店やサイトを探せば、何かしら中古サブノートPCは見つかりますが、新品を買うのと違って、中古は一期一会ですから、石橋を叩いて渡る気持ちで探しました。

 

数か月前に、通販で購入可能なショップからひとつに絞り込み、さらに機種もLet's noteに決めて、定期的に出品と値段を確認するようになりました。この時点ではLet's noteには決めたものの、CF-SV7にするか、CF-SV8かCF-SV9にするか、まだ流動的でした。出品や値段をウォッチしつつ、中古で値段が安いとは言ってもCF-SV7では性能が劣り、CF-SV9は値段が多少上がってしまうので、最終的に機種はCF-SV8に決めました。

 

ショップも決まり、機種も決まったとしても、Let's note CF-SV8は、様々な状態の中古が出品されていて、それを絞り込むのがまた一苦労です。絞り込むための条件として、次のようにしました。

1. 中古の状態が悪いことが明記されているものは、候補から外す。
2. 画面の状態に問題があることが明記されているものは、候補から外す。
3. SSDが新品に換装されているものを、候補とする。
4. ACアダプタは、純正でなくても構いませんが、純正の方を優先する。
5. 使用時間は、5,000時間以下とする。 

 

このような条件で、先月までショップをウォッチし続け、今月に入り実際に購入するため最終確認をしたところ、候補が数件まで絞り込まれました。今週頭に、条件に合う候補をひとつに絞り、注文し、今日到着したところです。

 

Windows11 Professionalがインストールされていましたが、これは捨てて、BSDに入れ換えるつもりです。その前に、HWiNFOやCrystalDiskInfoなどを使って、ハードウェアの状態を記録しておきました。BSD系をインストールし、ハードウェア状態を知る必要が出てきた時には役立つでしょう。PC本体は中古ですが、SSDは新品に換装されていました。またACアダプタも純正でした。自前で換装したりすることは可能ですが、その手間もお金もかけずにすみました。さらにPC本体は、若干擦り傷はあるものの、基本的に綺麗で、ディスプレイもキーボードも新品同様です。またBIOSで使用時間を確認すると3,000時間でした。送料がかかりましたが、値段も安かったので、お買い得でした。

 

次は、どのBSDにするか決める必要があります。dynabook SS/SX15Aの流れを引き継いでNetBSD/amd64でも構わないのですが、FreeBSDやOpenBSDにするか、DragonFly BSDやNomadBSDにするとか、helloSystemやravynOSでも面白いかもしれません。いろいろインストールしてみて、決めていくつもりです。 

東大版Palo Alto Tiny BASICをamd64環境に移植するための入力ルーチン

東大版Palo Alto Tiny BASICをamd64環境に移植してみるため、出力ルーチンが出来たので、引き続き入力ルーチンも書いてみました。WSL2のUbuntuを使っていますが、端末をRAWモードに設定する必要があります。プログラムを動かす前にsttyで設定を変えておくことにして、プログラム内部ではロジックを組みません。

 

オリジナルの入力ルーチンは次のようになっています。

GET:   IN    IFLG
       NOP
       ANI   IMSK
       RZ
       IN    ITTY
       ANI   7FH
       CPI   0FH
       JNZ   TTYI2
       LDA   OMASK
       CMA
       STA   OMASK
       JMP   GET
TTYI2: CPI   03H
       JZ    START
       RET

Geminiに教えてもらいながら、入力ルーチンを書いてみました。動作確認には、既にできている出力ルーチンを使いました。

# as get.s -o get.o
# ld get.o -o get
# stty raw -echo ; ./get ; stty sane
.intel_syntax noprefix
.global _start

.equ    CTRL_C,        0x03
.equ    CTRL_O,        0x0F
.equ    CR,        0x0D
.equ    LF,        0x0A
.equ    SYS_READ,    0
.equ    SYS_WRITE,    1
.equ    SYS_IOCTL,    16
.equ    STDIN,        0
.equ    STDOUT,        1

.equ    TC_MAGIC,    'T'
.equ    FIONREAD_CMD,    27
.equ    FIONREAD,    (TC_MAGIC << 8) | FIONREAD_CMD

.equ    OMASK_TOGGLE,    0x01

_start:    call    get
    call    put
    jmp    _start
    
done:
    # プログラム終了 (sys_exit = 60)
    mov rax, 60         # システムコール番号 (sys_exit)
    xor rdi, rdi        # 第1引数: 終了ステータスコード (0)
    syscall             # Linuxカーネル呼び出し

put:    cmp    byte ptr [rip+omask],0
    jne    ttyo0
    ret
ttyo0:    cmp    al,CR
    jne    ttyo1

    call    ttyo1
    push    rax
    mov    al,LF
    call    ttyo1
    pop    rax
    ret

ttyo1:    push    rax
    mov    rax,SYS_WRITE
    mov    rdi,STDOUT
    lea    rsi,[rsp]
    mov    rdx,1
    syscall
    pop    rax
    ret

get:    push    rbp
    mov    rbp,rsp
    sub    rsp,16

    mov    rax,SYS_IOCTL
    mov    rdi,STDIN
    mov    rsi,FIONREAD
    lea    rdx,[rbp-4]
    syscall
    test    eax,eax
    js    ttyi8
    cmp    dword ptr [rbp-4],0
    jz    ttyi8

ttyi1:    mov    rax,SYS_READ
    mov    rdi,STDIN
    lea    rsi,[rbp-5]
    mov    rdx,1
    syscall
    cmp    rax,1
    jl    ttyi8

    movzx    eax,byte ptr [rbp-5]
    cmp    al,CTRL_O
    jne    ttyi2

    xor    byte ptr [rip+omask],OMASK_TOGGLE
    mov    rsp,rbp
    pop    rbp
    jmp    get

ttyi2:    cmp    al,CTRL_C
    je    done
    jmp    ttyi9
ttyi8:    xor    eax,eax
ttyi9:    mov    rsp,rbp
    pop    rbp
    ret

.data
omask:    .byte 1        # 出力フラグ（0: 出力抑制 / 0以外: 出力許可）

東大版Palo Alto Tiny BASICをamd64環境に移植するための出力ルーチン

東大版Palo Alto Tiny BASICをamd64環境に移植してみようと思います。基本方針としては、オリジナル版の仕様を再現することに主眼をおき、C言語で書き直すとか、整数16ビットを拡張するなどはおこなわないつもりです。プログラムのデータ構造やサブルーチン構成も変更しないつもりですが、i8080とamd64の違いでやむを得ない場合は、変更します。

 

またオリジナル版は、SDK-80のシリアルポートにASR-33が接続された環境を想定していると思われます。amd64環境としては、WSL2のUbuntuとかFreeBSD/amd64などを考えていて、少なくともOSの管理下で動作するようにします。まずは入出力ルーチンを移植してみようと思います。

 

オリジナル版の出力ルーチンは、次のようになっています。

PUT:   PUSH  PSW                ;PUT CHARACTER IN A REG
       LDA   OMASK
       ORA   A
       JNZ   TTYO0
       POP   PSW
       RET
TTYO0: IN    OFLG
       ANI   OMSK
       JZ    TTYO0
       POP   PSW
       OUT   OTTY
       CPI   0DH
       RNZ
       MVI   A,0AH
       CALL  PUT
       MVI   A,0DH
       RET

 Geminiの助けを借りながら、オリジナルと同じ動きになるような出力ルーチンを書いてみました。動作確認のため「Hello World」を出力させてみましたが、うまくいっているようです。

# as put.s -o put.o
# ld put.o -o put
# ./put
.intel_syntax noprefix
.global _start

CR        =    0x0D
LF        =    0x0A
SYS_WRITE    =    1
STDOUT        =    1

_start: lea    rbx,[rip+msg]
loop:    mov    al,[rbx]
    cmp    al,0
    je    done
    call    put
    inc    rbx
    jmp    loop
    
done:
    # プログラム終了 (sys_exit = 60)
    mov rax, 60         # システムコール番号 (sys_exit)
    xor rdi, rdi        # 第1引数: 終了ステータスコード (0)
    syscall             # Linuxカーネル呼び出し

put:    cmp    byte ptr [rip+omask],0
    jne    ttyo0
    ret
ttyo0:    cmp    al,CR
    jne    ttyo1

    call    ttyo1
    push    rax
    mov    al,LF
    call    ttyo1
    pop    rax
    ret

ttyo1:    push    rax
    mov    rax,SYS_WRITE
    mov    rdi,STDOUT
    lea    rsi,[rsp]
    mov    rdx,1
    syscall
    pop    rax
    ret
    
.data
omask:    .byte 1        # 出力フラグ（0: 出力抑制 / 0以外: 出力許可）

.section .rodata
msg:    .asciz    "Hello World\r"

東大版Palo Alto Tiny BASICをamd64環境に移植できるだろうか

simhのAltair 8800シミュレータ上で東大版Palo Alto Tiny BASICが動作し、Tiny Trekも動きました。ひとまず区切りがつきましたが、これを他の環境に移植してみても面白いのではないかという気がします。他の環境というのは、具体的にはつぎのようなものを思い描いています。

• amd64環境として、WSL2のUbuntuかFreeBSD/amd64
• PDP-11/40のUNIX v6
• OpenVMS vax
• OpenVMS alpha 

 

いずれの環境であっても、アセンブラで書いてみようと思います。オリジナルはOSを意識しておらず、シリアルポートの先にASR-33が接続されているのを想定しています。しかし入出力はOSのが提供する機能を利用しようと思います。それでも、行編集のような便利な機能はつかわず、ASR-33並みの原始的な行入力にしておこうと思います。

 

またオリジナルの8080版では、整数16ビットを想定しています。amd64なら整数32ビットにすることもできるかもしれませんが、そういうTiny BASICの仕様を拡張するようなことはしない方針です。できるだけオリジナルと同じ仕様にしておきつつ、動作環境が8080ではないという方向で考えています。

 

データ構造やサブルーチンなども、オリジナルの東大版Palo Alto Tiny BASICと同じようにしようと考えています。発表当時の時代背景を踏まえて、BASICソースは、メモリ上に単純に置かれています。ソフトウェア工学的には、メモリ上の持ち方を変えればスマートかもしれませんが、そういうこともしないつもりです。所詮はTiny BASICなので、大規模と言ってもTiny Trekのような高々200行弱のプログラムで十分です。何千行もあるようなプログラムになることは考えず、最適化されたアルゴリズムを採用しません。

 

いろいろな環境を考えているとはいっても、いきなり全てはできません。まずはamd64環境から始めようと思います。 

東大版Palo Alto Tiny BASICでTiny Trekが動いたけど、遊び方が分からない

simhのAltair 8800シミュレータを使って東大版Palo Alto Tiny BASICが動いています。またAutoHotkeyを使って、長いBASICソースを入力させることが出来るようになりました。そしてTiny Trekを動かしてみたところ、あっさり動作しました。それは嬉しいことなのですが、遊び方が分かりません。

>RUN
DO YOU WANT A DIFFICULT GAME?  (Y OR N):N
STARDATE 3200:  YOUR MISSION IS TO DESTROY 8 KLINGONS IN 30 STARDATES.
THERE ARE 2 STARBASES.
ENTERPRISE IN Q-65 S-83
CAPTAIN:G
ENTERPRISE IN Q-65 S-83
COMPUTER DISPLAY OF GALAXY MAP

1:   0   0   0   0   0   0   0   0

2:   0   0   0   0   0   0   0   0

3:   0   0   0   0   0   0   0   0

4:   0   0   0   0   0   0   0   0

5:   0   0   0   0   0   0   0   0

6:   0   0   0   0   0   0   0   0

7:   0   0   0   0   0   0   0   0

8:   0   0   0   0   0   0   0   0
    ..  ..  ..  ..  ..  ..  ..  ..
     1   2   3   4   5   6   7   8

CAPTAIN:R
STATUS REPORT:
STARDATE      3200
TIME LEFT     30
CONDITION     GREEN
POSITION      Q-65 S-83
ENERGY        4000
TORPEDOES     10
KLINGONS LEFT  8
STARBASES     2
CAPTAIN: 

クリップボードの限界とAutoHotkey

simh上のAltair 8800シミュレータ上で東大版Palo Alto Tiny BASICが動作するようになりました。「Hello World」程度の簡単なプログラムを動かすなら何とも思いませんが、Tiny Trekのような（比較すれば）大きなプログラムを動かそうとすると、いちいちプログラムを入力するのは大変です。そもそもTiny BASICにはsaveやloadコマンドが存在しません。

 

本来のPalo Alto Tiny BASICでは、ASR-33の紙テープを使って、事前に作成済みの紙テープを使うことで、大きなプログラムを動かすことができたようです。simh上のAltair 8800シミュレータでは、紙テープのためのPTR/PTPデバイスは備えられていますが、本家も東大版も対応していません。対応できるように改造するという方法は考えられますが、まずは別の方法で対処しようと思います。

 

まず考えたのはクリップボードを利用する方法です。プログラムを事前にクリップボードに入れておけば、Altair 8800シミュレータ上で動作中の東大版Palo Alto Tiny BASICにクリップボードからコピーすれば、うまくいくと思いました。ちょっと試してみたところ、うまくいくようです。ところが、Tiny Trekのような大きなプログラムでは、クリップボードからのコピーが早すぎて、途中で文字の取りこぼしが発生してしまいました。

 

解決策を探していたら、AutoHotkeyというものが使えそうという感触を得ました。ちょっとしたスクリプトを作成することで、指定したファイルの内容を、あたかもキー入力したかのように、アプリケーションに送ることができるようです。以下に示すようなスクリプトをGeminiに作ってもらいました。試行してみたところ、うまくいったようです。

 

 #Requires AutoHotkey v2.0

waitMs := 1000
selectedFile := FileSelect(16, A_MyDocuments . "\PaloAltoTinyBASIC\Altair8800", , "BASファイル (*.bas)")
if (selectedFile == "")
    return

try {
    Loop read, selectedFile, "UTF-8"
    {
        currentLine := A_LoopReadLine
        SendText(currentLine)
        Send("{Enter}")
        Sleep(waitMs)
    }
} catch as err {
    MsgBox("処理中にエラーが発生しました: " . err.Message, "エラー", "Icon!")
}

Palo ALto Tiny BASICとTiny Trek

Palo Alto Tiny BASICを開発したLi-Chen Wangは、Tiny Trekも発表しています。Tiny BASICが流行った当時、なぜかスタートレックのゲームも流行していました。 Tiny Trekは、People's Computer Company Jul. 1976、Vol. 5、No.1に掲載されています。Tiny BASICで動作するTiny Trekだからなのか、とれも短いプログラムです。

 

印刷されているものを参照して電子ファイル化しようと思いましたが、文字が潰れていて読みにくいです。頑張る気力がなかったので、ネットを調べてみたら、テキスト化されたファイルを見つけました。これがあれば、自分で文字を起こす必要がありません。

 

ただし、PCCに掲載されたものとは、若干異なっていました。Palo Alto Tiny BASICでは「PRINT」を「P.」と省略できるようなのですが、それが全て「PR.」に変更されています。どのような理由で変更したのかは不明です。

 

また、BASICは入力されたプログラムをメモリ上に置くので、それを極限まで切り詰めるためか、空白を入れるのを避けているようです。例えば「205 PR.;F.I=U-1TOU+1;F.J=V-1TOV+1;M=8*I+J-9,A=0」のようになっています。もし省略形を用いず、空白を入れるなら、「205 PRINT;FOR I=U-1 TO U+1;FOR J=V-1 TO V+1;M=8*I+J-9,A=0」のようになるでしょう。他にも「IFH-K>9PR.」のような箇所もあり、メモリが少なかった当時の努力を感じます。

IMEで「いま」を現在時刻に変換できるらしい

「日本語力ソフトで郵便番号から住所入力、Googleは大口事業所個別番号対応」という記事を読んだら、「例えば、「いま」と入力すると、現在時刻が変換候補に現れる（図1）。」と書かれていました。「いま」以外にも、「あす」や「ことし」なども受け付けるようです。では、受け付けてくれる候補は何があるのか、一覧はないのでしょうか。

 

Geminiに相談したら、気軽に「ここにありますよ」と答えてくれたのですが、そんなリンクはありませんでした。こういう雑な反応は、Geminiらしいところです。

 

受け付けられる文字列が分かっているなら、入力時に意識しようとも思います。しかし何が受け付けられるのかわからないのであれば、「ことし」が「2026年」に変換される機能があったとして、最初から「2026年」と入力するだろうと思います。

 

 

再生鉄

ネットを見ていたら「自動車に「再生鉄」、トヨタも採用　東京製鉄トップが語る変化の兆し」という新聞記事が目に入りました。スクラップを再生した鉄を使用することでリサイクルを目指すようです。

 

どうしたことか「再生鉄」という文字を見たら、鉄道ファンの新しいジャンルかと勘違いしました。近年は、鉄道ファンという表現をすることは少なくなり、「乗り鉄」とか「撮り鉄」などと呼ばれます。それだけではなく、「座席鉄」や「顔鉄」などというニッチな表現もあるようです。「あなたは、何鉄ですか？」と問われることもあるらしいのですが、その質問自体がナンセンスというか、何故それほどまでに細分化したがるのか謎です。元々は「鉄道ファン」と呼ばれた愛好家は、「鉄道マニア」とも呼ばれ、「鉄道オタク」とも「鉄ちゃん」とも呼ばれましたが、この頃は「鉄道全般の愛好家」という意味であって、特定の一部を強調することはありませんでした。写真も撮るし、乗車して旅行もするし、模型も作るという、何でも屋でした。 

 

閑話休題。あまりにも細分化され過ぎた表現を見過ぎたせいか、「再生鉄」を見たとき、「おっ、新しい鉄道ファンのジャンルか？でも「再生」の鉄って何？」と、ズレた疑問を抱いてしまいました。 

Squad Leader CLASSIC Revised Rules Book Version 1.2

1980年代にAvalon Hillから発売された「Squad Leader」というゲームがありました。とても人気があり、「Cross of Iron」、「Crescendo of Doom」、「GI: Anvil of Victory」という拡張版も発売されました。ところが、当初のルールが拡張版で追加変更され、さらに追加されたはずのルールが後続した拡張版で変更され、複雑怪奇なルール体系になってしまいました。

この問題はAH側でも意識しており、ゲーム全体を仕切り直した「Advanced Squad Leader」が登場しました。SLとASLは、似ているとは言っても、ゲーム体系として別物です。本来のSquad Leaderのルールは「増築を重ねた旧い旅館」のようになってしまっていて、とても見通しが悪いです。

 

ルール体系を整理したいと考えている人は少なくないようで、「Squad Leader Rules (Includes All Gamettes)」という存在を知りました。自分で整理するよりも、この成果を使わせてもらう方が、何かと有難いと思っています。 

「還暦間際のオッサンが8Bit時代に戻って不完全燃焼をやり直す話」とフォレストガンプ

「還暦間際のオッサンが8Bit時代に戻って不完全燃焼をやり直す話」という小説がネットで連載されているのを偶然知りました。小説なので、当時の時代の状況を正確に反映しているわけではなく、天才的な(?)主人公が、周囲の人間を巻き込み（翻弄し）ながら、テクニカルな成果を次々にあげていくという内容です。とても楽しく読んでいます。

 

Z80が全盛だった頃からAT互換機が出現する時期のパソコンに、次々の（当時としては）新機能を実装する主人公に周囲の人間が驚き呆れるのです。ふと思ったのですが、これはトム・ハンクス主演の映画「フォレストガンプ」に似ているのではないでしょうか。

 

「フォレストガンプ」は、第二次大戦後におけるアメリカの歴史的な出来事（例えば公民権運動とかベトナム戦争）に、主人公のフォレストガンプが常に登場するストーリ仕立てになっています。フォレストガンプが歴史的な出来事に一回くらい遭遇するだけならまだしも、いつでもどこでも、常に顔を出すのは、娯楽映画だからこそ許される展開です。

 

コンピュータ技術に爆走する少年と、米国史に立ち会うフォレストガンプは、話の展開が似ていると思うのです。 

紙テープとクリップボード

DDJで発表されたPalo Alto Tiny BASICは、ASR-33のようなテレタイプを入出力装置として想定しています。その派生である東大版Palo Alto Tiny BASICをsimhのAltair 8800シミュレータで動作するようになりました。さて、Tiny BASICが一世を風靡した頃には「Hello World」というプログラムを書いてみるという習慣はありませんでした。テスト的に簡単なプログラムを入力し、実行できるようにはなりましたが、Palo Alto Tiny BASICには、saveやloadというコマンドはありません。しかし、入力したプログラムを保存できないのは、困ります。さらに、過去に作成したプログラムを読み込めないのは、もっと困ります。

 

ここで当時の状況を思い起こすと、ASR-33のようなテレタイプには、紙テープのリーダーやパンチャーがついていたという事実です。ASR-33の操作方法は分かりませんが、あたかもキーボードから入力しているかのように紙テープを入力装置としたり、あたかも印字するかのように紙テープを出力したりすることが出来たようです。つまりPalo Alto Tiny BASICから見ると、入力がキーボードなのか紙テープなのか区別できませんし、出力がプリンタなのか紙テープなのか区別できません。こういう機構があれば、Palo Alto Tiny BASICにsaveやloadコマンドがなくても、紙テープを記録メディアとして利用できることになります。

 

それでは、Altair 8800シミュレータでPalo Alto Tiny BASICの場合、「紙テープ」の代替は何でしょうか。いろいろな手法が考えられるかもしれませんが、「クリップボード」が使えそうです。あらかじめエディタか何かで、プログラムを編集しておき、その全てをクリップボードにコピーしておきます。次にAltair 8800シミュレータで動作しているPalo Alto Tiny BASICにペーストすれば、いかにもキーボードから入力したかのように、プログラムが一気に入力される（はず）です。つまり現代のクリップボードは、当時の紙テープを再現していると言えるでしょう。

 

Palo Alto Tiny BASICが流行した当時は、何故かStar Trekゲームも流行していました。Palo Alto Tiny BASICを開発したLi-Chen Wangは、Tiny Trekも発表しています。Tinyなので130行ほどしかありませんが、ゲームを遊ぶたびに、いちいちキーボードから入力しなければならないのは嬉しくありません。当時は紙テープから一括入力したようですが、現代ならクリップボードの出番です。これで一括入力できるはずです。

PLANとSIMPLE

共立出版の『マイクロコンピュータのプログラミング』におさめられている「マイクロPLANのプロセッサ」という記事では、参考文献として雑誌「bit」の記事が参照されています。国立国会図書館のデジタル資料に雑誌「bit」があるので、確認してみました。

 

1974年8月号～12月号までは、PLAN言語の連載記事があります。ただしデジタル資料は館内限定公開と指定されているので、読みたければ国立国会図書館に行くしかありません。

1. ミニ言語PLAN（8月号）
2. 構文解析（9月号）
3. 記号の処理・宣言と定義の処理（10月号）
4. 目的プログラム（11月号）
5. 目的プログラムの生成（12月号）

 

1977年1月号～1978年3月号までは、SIMPLE言語の連載記事があります。雑誌「bit」は館内限定公開のデジタル資料です。しかし、この連載を単行本化した『やさしいコンパイラの作り方』（中西正和・大野義夫、共立出版、1980年）は、デジタル資料になっており、個人送信も可能として指定されているので、アカウントがあれば自宅でも読めます。 

Firefox 153では「ユーザーのコンピューター上のローカルファイルへのアクセス」の無効がデフォルトになっている。

Firefoxを更新して153にしたら「 File Backups - For TiddlyWiki」が動かなくなりました。何が原因なのか分からずに焦りましたが、「PSA: If you’re using Timimi with Firefox 153+ (or an equivalent fork)」という情報がありました。これは、Timimiというプラグインの場合ですが、対処方法は同じでした。

 

Firefox 153では、プラグインの管理メニューに「ユーザーのコンピューター上のローカルファイルへのアクセス」が 追加され、デフォルトでは「無効」になっています。これによりプラグインがバックアップできなくなってしまったようです。

 

この設定を「有効」としたら、問題は解決しました。 

東大版Palo Alto Tiny BASICのメモリマップ

共立出版の『マイクロコンピュータのプログラミング』に掲載されている「東大版Palo Alto Tiny BASIC」は、DDJに掲載されたオリジナルのPalo Alto Tiny BASICを拡張したものです。しかし記事に書かれているように、「Palo Alto版のオブジェクト・プログラムを、独自に逆アセンブル、変更を加えたもの」です。いろいろな変更が加えられていますが、メモリマップも違っているようです。

 

記事では「図3 メモリ・マップ」として開設されています。プログラム本体は、0000番地から始まるメモリに配置されていて、0786番地まで続くので約2Kバイトです。作業領域、BASICプログラム格納領域、スタックなどは、1000番地から1400番地までなので、たかだか1Kバイトです。

 

一方でDDJに掲載されているオリジナル Palo Alto Tiny BASICは、プログラム本体が、0000番地から074E番地までの約2Kバイトで、作業領域などが、0800番地から2000番地までの6Kバイトです。東大版に比べると、作業領域などに割り当てているサイズが大きく違います。

 

これらが発表された当時のハードウェア状況を考えれば、 メモリが1Kバイトしかないとしても、やむを得ないでしょう。しかし割り当てが少なすぎて、例えばStar Trekなどを動かすのは、おそらく無理でしょう。

 

SimHのAltair 8800シミュレータを使うなら、64Kバイトのフル実装するのも簡単なことです。そこまで大きく拡げないとしても、東大版Palo Alto Tiny BASICのソースプログラムで指定されている値を変更しておきたいと思います。

Firefox 153.0で「File Backup Utility For TiddlyWiki」が動作しない

TiddlyWikiをFirefoxで利用しています。2026年7月22日にFirefox 153.0がリリースされたのですが、アドオン「File Backup Utility For TiddlyWiki」が動かなくなりました。ブラウザがバージョンアップすることでアドオンが動かなくなるという事例があるようです。「File Backup Utility for TiddlyWiki」が今後動作しなくなるのか、対応版がリリースされるのか、現時点では情報がありません。

 

昔からFirefoxでTiddlyWikiを使ってきました。このアドオンも相当前から利用しています。ハノイの塔方式でバックアップしてくれるのも有難いですが、最も助かっているのは、TiddlyWikiでTiddlerの編集が終わると自動的に保存処理をしてくれるところです。

 

このアドオンを使い始めた頃は他に選択肢はありませんでした。しかし今は「timimi」もあります。状況によっては、アドオンを乗り換えるかもしれません。 

Altair 8800対応「東大版Palo Alto Tiny BASIC」が動いた

共立出版の『マイクロコンピュータのプログラミング』に掲載されている「東大版Palo Alto Tiny BASIC」をSimHのAltair 8800シミュレータで動くように変更を加えてみました。共立本に掲載されているプログラムの実行環境が不明ですが、SDK-80だろうと思います。本文にはテレタイプと書かれていますが、その入出力はi8251を使っています。一方で、Altair 8800では、シリアルインターフェイスはMC6850が使われています。

 

Altair 8800に対応させるには、i8251を意識している箇所を、MC6850に対応させる必要があります。具体的には、次のようにします。

1. 入出力データは、0FAHとなっているのを、011Hに変更します。 
2. ポーリングのために参照するレジスタは、0FBHとなっているのを、010に変更します。
3. i8251の「TxRDY」は、D0です。MC6850の「Transimit Data Register」は、D1です。このため、OMSKの定義を、001Hから002Hに変更します。
4. i8251の「RxRDY」は、D1です。MC6850の「Receive Data Register」は、D0です。このため、IMSKの定義を、002Hから001Hに変更します。

 

定義を変更するだけで、とりあえず動いてくれました。

Altair 8800 simulator V3.9-0
sim> load KYORITSU-ALTAIR8800.rom
4118 Bytes loaded.
sim> run

OK
>10 INPUT A,B
>20 PRINT #3,'A+B=',A+B,' A-B=',A-B,' A*B=',A*B,' A/B=',A/B
>30 STOP
>RUN
A:10
B:2
A+B= 12 A-B=  8 A*B= 20 A/B=  5

OK
>

 

 

SimH Altair 8800で「Hello World」

K&Rの『プログラミング言語C』以来、「Hello World」とは「最初の一歩」という意味を持つようになりました。SimHのAltair 8800シミュレータを使い、「Hello World」を出力するプログラムを動かしてみようと思います。ここで重視しておくのは、CP/MとかDOSのような実行環境を一切使わないということです。

 

まずプログラムはアセンブラで書きます。入出力は、Altair 8800のSIOポートを使います。「Hello World」という文字列の各文字をSIOポートに出力し、HALTするだけ、というプログラムです。Geminiに作成してもらいました。アセンブラはzasmです。オプションとして「-uw --asm8080」を指定しました。 アセンブルした結果は、Rawバイナリ形式のファイルになります。オプションを指定すれば、インテルHEX形式や、モトローラS形式にも出来るようです。

 

SimHのAltair 8800シミュレータを起動し、プロンプトが出たところで「load hello.rom」のようにして、Rawバイナリ形式のファイルを読み込みます。そして「go 0」したら、文字列「Hello World」が出力されました。文字出力できました。

 

さらに、文字入力も確認しておきます。文字入力ができることを確認するだけなので、数字キーをおしたら、その回数だけ「Hello World」を出力するプログラムとしました。これもGeminiに作ってもらいました。アセンブルし、実行する手順は、同じです。これもうまくいったので、文字入力も大丈夫です。

 

Altair 8800が想定している入出力装置は、ASR-33のようなものなので、とても原始的です。使いやすくはありません。当時の時代の息吹が感じられるとも言えるかもしれません。

共立版「東大版Palo Alto Tiny BASIC」のソースコード

「東大版Palo Alto Tiny BASIC」と呼ばれるものは、共立出版の『マイクロコンピュータのプログラミング』に掲載されているものと、雑誌アスキーに掲載されているものがあります。両者の違いを詳しく確認したわけではありませんが、ちょっと見ただけでも違いがあります。

 

共立版の方には何も情報がないのですが、アスキー版には「8080 MACRO ASSEMBLER, VER 2.0」という文字があり、また「FOR SDK-80 VERSION」とも書かれています。「東大版Palo Alto Tiny BASIC」を学ぶため、どちらを使うか迷うところです。共立版の方が内部構造の説明が詳しいので、共立版を使おうと思います。

 

ひとまず書籍に掲載されているソースコードを入力したファイルを作成しました。これをアセンブルしようと思いますが、Windows11で利用可能なzasmを使おうと考えています。アスキー版にある「8080 MACRO ASSEMBLER」というのが、どういうものなのか分かりませんが、共立版も同じなのでしょう。zasmを使うなら、変更しておく箇所があります。

1. 文字列をくくるのに「シングルクォート」が使われています。文字列中にシングルクォートが現れると、文字を重ねて対応するようですが、シングルクォートが多すぎて見にくいところがあるので、直そうと思います。
2. マクロの構文がzasmとは違うようなので、対処が必要です。
3. 「\」という文字が使われていますが、「$」のことのようなので、変更します。 

 

もう一つ考えておく必要があるのは、実行環境です。おそらくSDK-80を想定していると思われます。私は、SimHのAltair 8800エミュレータを使おうと考えています。文字入力や文字出力に関わる部分を変更する必要があるでしょう。

ケトル

薬缶とは呼ばずに、ケトルと呼ぶのは、なぜだろうかと思いますが、ドリップコーヒーを淹れるのに使われることが多いケトルが壊れたので買い替えました。いつ買ったのか覚えていませんが、30年くらい前なのかもしれません。握り手を本体に溶接してあるところが外れてしまいました。それ以外は何の問題もないので修理して使い続けたいと思いますが、どうしようもないので、買い替えることにしました。

 

下見したところ、ニトリでは1,790円、CAINZでは1,480円でした。微妙にデザインは違いますが、その違いに拘ることもないと思いました。最終的には値段で決め、CAINZの方を買いました。結局は薬缶ですから、コンロにかけてお湯になればよいだけです。

 

使ってみて気づきましたが、CAINZのケトルは、握り手の部分がプラスチック製です。一方のニトリの方は、木製のようです。大した違いではないかもしれませんが、コンロにかけるとプラスチック製の握り手は熱くなるのに気づきました。また握り手が短いような気もします。

 

もし次に買い替えることがあれば、ニトリの方にしようと思います。しかし当分買い替える必要はないでしょう。仮に買い替える時が来たとしても、ニトリにしろCAINZにしろ、違う商品になっているでしょう。 

Palo Alto Tiny BASICとRST N

Palo Alto Tiny BASICは、様々なテクニックを駆使してプログラムサイズを小さくしていると言われています。そのテクニックの一つが「RST N」を多用している事です。プログラム先頭には「ZERO PAGE SUBROUTINES」として、次のように書かれています。

THE 8080 INSTRUCTION SET LETS YOU HAVE 8  ROUTINES IN LOW MEMORY THAT MAY BE CALLED BY RST N. N BEGIN 0 THOUGH 7. THIS IS A ONE BYTE INSTRUCTION AND HAS THE SAME POWER AS THE THREE BYTE INSTRUCTION CALL LLHH.

 

インテルの8080は、RST 0からRST 7が実行されると、0000番地、0008番地・・・と固定されたアドレスに制御が移ります。普通にサブルーチンコールをCALL foobarすれば3バイトになるところを、RST Nなら1バイトなので、インテルがこのような使いかたを想定しているわけではないと思いますが、メモリの節約になります。その代償として、0000番地付近をPalo Alto Tiny BASICの管理下におく必要があります。Palo Alto Tiny BASICが登場した頃は、メモリマップを制約するOSのようなものが無く、自由だったので、このようなアプローチも許されました。

 

しかしメモリマップを変更することができなくなります。Palo Alto Tiny BASICでは、Version 2.0というのはプログラムのインストラクションをインテル互換に変更しただけですのでRST多用になっていますが、Version 3.0ではRST多用と決別したようです。また東大版はPalo Alto Tiny BASICの流れをくむことになっていますが、以下のように説明されており、RSTを使わないようになっています。

(v) システムやバッファをそれぞれのキットに合わせて任意のアドレスから始まるように変更することが容易である。（これは、筆者の変更による。） 

Microsoft Flight Simulator 2002において、ジョイスティック応答をキーボードでどのように操作するのだろうか

長年放置していたMicrosoft Flight Simulator 2002を今さらながら取り組んでいます。マイクロソフト的にはジョイスティックで操作して欲しいのかもしれませんが、所有していないので、キーボードを使うしかありません。ジョイスティックの操作が、どのようにキーボード操作にマッピングされているのか、付属していた文書類には書かれていません。

 

ジョイスティックを前後に動かすことは、キーボードなら「8」キーや「2」キーであるとは書かれていますが、それだけです。マイクロソフトのフライトシミュレータは、かなり精密にシミュレートしているとは言われますが、そうだとしてもパイロット資格を取得する目的で作られているわけではないですし、結局はゲーム性を重視しているはずです。

 

ジョイスティックを所有していませんが、噂で聞くところによると、ジョイスティックを前後に倒しても、手を離すと自動的に中立に復元するそうです。それは、キーボード操作では、実現されているのでしょうか。例えば、ジョイスティックを手前に倒し、その後で手を離したとすると、ジョイスティックは中立に戻ります。これと同じ状況を再現するには、キーボード操作では、どのようにしたらよいのでしょうか。

 

ここで問題になるのが、相反する情報があることです。ひとつは、「キーボード操作においては、勝手に中立に戻る」から、「2」キーを押すだけでよく、「2」キーから手を離せば（ジョイスティックが勝手に中立に戻るように）何もしなくてよいという情報です。もうひとつは「キーボード操作においては、ジョイスティックとは異なり、押したキーの方向に固定された状態になる」から、ジョイスティックを傾け続ける状態に相当するので、「5」キーを押さないと中立に戻らないという情報です。

 

さらによくわからないのは、ジョイスティックを少し傾けた場合と、最大限に傾けた場合とは、キーボード操作では、どのように変わってくるのかです。例えば「2」キーを押し続けたとすれば、それはジョイスティックを最大限に傾けた場合と等価だろうとは想像できます。もしジョイスティックを1.5cmくらい手前に引いたのと等価にしたいなら、キーボードをどのように操作すれば良いのでしょうか。「2」キーを0.5秒くらい押した後で離すだけで良いのでしょうか。それとも「2」キーを0.05秒くらい押して離すという行為を数回繰り返せば良いのでしょうか。

 

「難しく考えずに、やってみてうまくいけば、それでいいんだよ」という意見もあるでしょう。結局はゲームなので、それで良いのだと思います。キーボード操作に失敗すれば、失速して墜落するだけです。ゲームですから墜落しても生死につながりません。結局は「慣れるしかない」が答えなのかもしれません。

Googleマップのタイムラインで「乗馬」が何故必要なんだろう

Androidのスマホを利用しています。Googleマップのタイムラインを有効にしているので、移動の軌跡が記録されます。このアプリには、相当不満はありますが、目安になればよいという程度の認識なので、利用を続けています。最も大きな不満は、精度が酷すぎることで、Google謹製のアプリとは思えないほど悪いです。そこは我慢するとして、謎な仕様もあります。

 

賢いというべきなのか、ある場所から別の場所に移動すると、勝手に移動手段を認識して「徒歩」とか「電車」などとラベルをつけてくれます。もし移動手段を認識できないと「移動」となりますし、認識された移動手段が間違っている場合もありますので、修正が必要になります。修正すると言っても、予め用意されている選択肢から選ぶしかありません。「自転車」とか「バス」という選択肢は理解できます。「スケートボード」という選択肢もありますが、これを予め選択肢に用意しておく必要があるか疑問ですが、まあ良いとしましょう。しかし「水泳」とか「手こぎボート」とか、あろうことか「乗馬」などという選択肢も用意されているのですが、これは必要ですか。 

 

「乗馬」という選択肢を利用する人がいるかもしれませんが、何人いるんでしょうか。そういう選択肢を用意しておくくらいなら、もっと他に用意しておくべき選択肢があるのではないかと、しみじみと思います。 

東大版PALO ALTO TINY BASICのバリエーション

Palo Alto Tiny BASICは、DDJ Vol.1 No.5 (May, 1976)で発表されました。これに派生するのが東大版PALO ALTO TINY BASICです。しかしDDJに掲載されているソースプログラムを基にしているのではなく、オブジェクトを独自に逆アセンブルし、改良を加えたとのことです。

 

東大版が掲載されているのは、『マイクロコンピュータのプログラミング』（共立出版、昭和53年）と、「2K BASIC」（ASCII 1977年8月号初出、エンサイクロペディア・アスキー Vol.1再録） です。これらは、同じものなのでしょうか。全体を確認するのは大変ですが、先頭を見ただけでも違いがありました。

 

『マイクロコンピュータのプログラミング』に掲載されている方は、次のようになっています。

;

;

;  PALO ALTO TINY BASIC

;

;

; MEMORY MAP

ITOP EQU 0000H

ISIZE EQU 0800H

LTOP EQU 1000H

VTOP EQU 1300H

LBUF EQU VTOP+0037H

LBUFSZ EQU 80

MSTK EQU LBUF+LBFSZ

（以下略） 

一方ASCII掲載の方は、次のようになっています。

;

;

; PALO ALTO TINY BASIC

;

;

; FOR SDK-80 VERSION (1977/03/23,ONO)

;

STACK EQU 1400H

VTOP EQU 1300H

LBUF EQU 1337H

MSTK EQU 13A7H

（以下略） 

 

目につくのは、ASCII版には「FOR SDK-80 VERSION (1977/03/23,ONO)」があり、『マイクロコンピュータのプログラミング』版には無いことです。推測となりますが、ASCII版にある表記を、『マイクロコンピュータのプログラミング』版で削除したというのは考えにくいと思われます。『マイクロコンピュータのプログラミング』の出版が昭和53年（=1978年）ですが、原稿を書いていた時期は、その前でしょう。最初はリリース日付を入れていなかったものの、どこかのタイミングで入れるようになり、それがASCII掲載版になったのではないかと想像します。

 

上述した箇所だけではなく、プログラム本体を見ても、『マイクロコンピュータのプログラミング』版とASCII版は、違いがあります。東大版が最終的にどうなったのかは不明ですが、何かしら改良を加え続けていたのだろうと思います。

 

そもそも東大版は、オリジナルのPalo Alto Tiny BASICのオブジェクトを逆アセンブルしているということです。最初の段階では、DDJに発表されたものと同一だったはずです。DDJに掲載されているアセンブラソースと比較すれば、どの辺りを変更しているかが分かるのではないかと思います。

 

Palo Alto Tiny BASICのバリエーション

まだマイコンと呼ばれていた時代に様々なTiny BASICが存在しました。COMPUTOPIAの1977年10月号の「"Tiny BASIC"のすすめ(2)」という記事の中には「表3 各種Tiny BASICの言語仕様・性能比較表（東京大学理学部 小野芳彦氏、同学石田晴久助教授の調査による）」という一覧表があります。

 

これらのTiny BASICの中で人気があったのが何だったのか不明ですが、個人的にはPalo Alto Tiny BASICに最も馴染みがあります。今さらTiny BASICを必要とする時代ではありませんが、内部構造を学ぶのは、技術的な興味があります。基礎的調査として、Palo Alto Tiny BASICのバリエーションを調べてみました。

 

• Palo Alto Tiny BASIC VERSION 1.0 (Dr. Dobb's Journal, Vol. 1, No. 5, May. 1976)
• Errata/additions to Palo Alto Tiny BASIC (Dr. Dobb's Journal, Vol. 1, No. 6, June/July, 1976)
• TINY BASIC FOR INTEL 8080 VERSION 2.0 BY LI-CHEN WANG, MODIFIED AND TRANSLATED TO INTEL MENMONICS BY ROGER RAUSKLOB 10 OCTOBER 1976 (INTERFACE AGE, Dec. 1976)
• Palo Alto Tiny BASIC Version Three (PCC'S REFERENCE Book of PERSONAL and HOME COMPUTING, Jul. 1977)
• PALO ALTO TINY BASIC FOR SDK-80 VERSION (1977/03/23, ONO) (エンサイクロペディア・アスキー Vol. 1)
• PALO ALTO TINY BASIC FOR TK-80用バージョン (1977/03/23, ONO) (エンサイクロペディア・アスキー Vol. 1)
• PALO ALTO TINY BASIC (『マイクロコンピュータのプログラミング』石田晴久編)

 

エンサイクロペディア・アスキーなどに掲載されているのは「東大版」と呼ばれており、Palo Alto Tiny BASICのバリエーションです。ただし、記事にも書かれていますが、DDJを参照して変更を加えたのではなく、「オブジェクトを独自に逆アセンブルし、変更を加えた」ものとのことです。

 

インターネットが存在しない時代ですから、発表媒体は雑誌などに限られると思います。想像となりますが、Palo Alto Tiny BASICを個人的に修正したり拡張したりした事例は、少なくないと思います。さらに、オリジナルはi8080版ですが、x86など他のCPUに移植したものも存在するのではないかと思います。技術的な関心として、取り組んでみたいと考えています。

「マイクロPlan」というプログラミング言語

共立出版から1978年に出版された『マイクロコンピュータのプログラミング』（石田晴久編）という書籍が手元にあります。昭和57年6月12日付のレシートが挟んでありました。この中に「マイクロPlanのプロセッサ」（戸村哲）という記事があり、以下のように書かれています。

マイクロPlanはその名前のとおり、ミニコン用のミニ言語であるPlan系のマイクロ言語である。

 

「皆さんもよくご存じのPlan系言語」という書き方ですが、ミニコン用のミニ言語である「Plan」というのが全くわかりません。例示として掲載されている「図2 8-Queenのプログラム」を見ると、Pascal風だと感じました。しかし「Pascal系」ではなくて「Plan系」だというのですから、Pascalの流れをくんでいないのでしょう。

 

数年前であれば「Google検索」をしたところですが、今は「Geminiとの対話」の時代です。Geminiに問いかけてみましたが、全く知らないと言われてしまいました。ハルシネーションで適当な話をでっちあげることもなく、完全にギブアップしています。

 

先ほどの記事の参考文献には「武市正人：ミニ言語のミニ・コンパイラ、bit、1974年8月号～12月号」とあります。bitが廃刊になって久しいですが、図書館で閲覧できるところもあるでしょう。機会をみつけて、読んでみようと思います。 

白いウィンドウ

ネットで「Windows 10/11で起動時に白いウィンドウが出る不具合、原因はChromeかもしれない」という記事を目にしました。この記事と同じような「白いウィンドウ」が最近出るようになったので、これは何だろうかと思っていたところです。

 

ただし記事では「起動直後」に表示されるとありますが、私の場合「画面ロック」を解除すると表示されます。

 

このような現象が現れているのは自分だけなのだろうか、解決方法はないだろうかと、Googleで検索してみました。しかし適切なキーワードが思いつかず、困っていたところです。「白いウィンドウ」というキーワードだと、全く関係ない記事がヒットしてしまうので、この現象をいったい何と表現するのだろうと悩んでいました。

 

現象は確認されているようなので、そのうち修正されるのを期待しています。 

TW5においてプラグインが動作しない問題が解決した

TW5.4.0に更新したらプラグイン「a simple calendar macro」が動作しなくなった問題が解決しました。自前で調査するつもりでしたが、JavaScriptのロジックを解析した経験がないので、Geminiにデバッグ方法を教えてもらうつもりでした。

 

Geminiと対話していたら、Geminiからプラグインのソース一式を見せてくれと要求されました。TW5のファイルからJSON形式でエクスポートし、Geminiにアップロードしたら、問題の原因を突き止め、解決方法を提示してくれました。解決するには「<<calendar>>」と記述していた箇所を「<<calendar state:"$:/state/sidebar/my-calendar">>」のようにすることでした。Geminiの指示どおりに書き換えたら、無事に動作しました。自分で解析しなくて済みました。

 

TW5本体かプラグインのいずれかのロジックに何か問題があるのだろうと思っていたので、自分でデバックするしかないと思っていましたが、その必要はありませんでした。TW5.4.0がリリースされ、カレンダープラグインが動作しないことが明らかになったので、手元にある数多くのTW5ファイルはTW5.3.8のまま更新しないで止めていました。しかし、若干記述を変更する必要があるものの、TW5.4.0に更新できます。 

TW5.4.0に更新したらプラグインの動作がおかしい

TiddlyWiki5の5.4.0がリリースされました。直前のバージョンは5.3.8でした。もう随分前からTW5を利用しています。あまり凝った使い方はできていませんが、いろいろな目的のために便利に利用しています。

 

何かのために新しくTW5ファイルを作る際は、プラグイン「Calendar - a simple calendar macro」を入れています。シンプルと銘打っているだけあって、カレンダーの特定の日をクリックすると、その日付のTiddlerが開くだけです。ところが、TW5.4.0に更新したら、このプラグインの動作がおかしくなりました。

 

具体的には、カレンダーで表示されている月の前後に移動できなくなったのです。「＜」や「＞」で前後の月へ、「≪」や「≫」で前後の年へ移動できるはずなのですが、まったく反応しません。TW5.3.8なら問題ないのです。このプラグインはタグ「$:/tags/SideBar」を指定したTiddlerで利用しています。サイドバーに表示されているカレンダーでは不具合がありますが、Tiddlerを単独で表示させると、問題ないことがわかりました。

 

TW5.4.0は、過去との互換性を断ち切ったところがあるようです。何が原因なのか不明ですが、ほんのちょっとした対処をすれば、解決できるかもしれません。挑戦してみようという気はあるのですが、TW5はJavaScriptを駆使して作られています。問題を突き止めるために、何をどうしたら良いのかも、よくわからない状態です。

 

Geminiに相談したら、デバッグ手法をアドバイスしてもらえるでしょうか。 

「便利なツールを享受しつつ依存しすぎない生活」と「喉元過ぎれば熱さを忘れる」

「「モバイルSuica」復旧後も続く混乱…「物理カード最強説」再浮上　今さら聞けない自衛策を解説」というWeb上の情報によると、通信障害が原因で様々なトラブルが発生したとのことです。この問題で影響を被ったのは、それなりにいたとしても、鉄道利用者の一部だと思います。鉄道系ICカードが全て使えなくなったのではないし、物理カードのSuicaなら影響を被りませんでした。

 

今回の問題は、あるサービスを利用するということは、それに依存しているのだという側面を露わにしました。スマホが普及し、過去に存在した物理カードを代替するスマホアプリが増えています。所有している物理カードを使うのを止めて、何でもスマホアプリに置き換えてしまえば、「スマホで何でもできるようになった。便利になった」という側面があることは否定しません。

 

スマホに何でも集中させることのメリットばかり強調されますが、デメリットを考えないのは片手落ちだと思います。スマホを落としてしまうこともあるでしょうし、盗難に遭うこともあるでしょう。それ以外にも様々な障害が考えられますが、どう対処するかを予め考えておくことはリスク管理ではないでしょうか。「卵は一つのカゴに盛るな」という格言もあります。

 

今回のようなトラブルが発生すると、「物理カード最強説」ということが言われたりしますが、「喉元過ぎれば熱さを忘れる」も忘れないで欲しいと思います。

初めて最初のフライトに成功した

Microsoft Flight Simulator 2002をWindows 11で動かしています。購入したのは20年以上も前でした。サポートはとっくに終わっていますが、Windowsを新しくするたびにインストールしていました。Windows 10までは、インストールすれば問題なく動作していました。ところがWindows 11では、インストールできるのですが、フライトを始めると異常終了してしまいます。なんとかならないかとGeminiに相談したところ、dgVoodooを使えば何とかなるかもしれないという助言をもらいました。試してみたら問題なく動くようになりました。

 

MSFS2002以外は、「ようこそ！」というメニューがあります。動画による簡単な説明が行われた後、いきなりですが、初飛行をします。MSFS2002購入依頼、この「初飛行」を何度となく試みました。操作もよくわかっていないし、飛行機の操縦も不慣れなので、酷いものです。シミュレータなので命は無事ですが、そうでなければ何十回も死んでいたところです。墜落こそしないものの、飛行場を遥かに離れた場所に着陸するとか、建物を突き破るなど、なんでもありです。

 

何度も「初飛行」していて慣れてきたのか、今日ようやく、まともなフライトに成功しました。離陸した飛行場に戻ってこられましたし、滑走路のすぐ傍に着陸できました。

 

これで、やっと「フライトレッスン」に進級できそうです。 

CF-SV9か、CF-SV8か、それともCF-SV7か

Windows Vistaの頃に購入したdynabook SS SX/15Aを使っています。Windows Vistaは既にサポート終了していますから、NetBSD/i386に入れ替えています。日常的に使っている訳ではなく、旅行などに持っていくだけですが、ハードウェア的にもソフトウェア的にも限界を感じるようになってきました。

 

新しいPCを購入しようと思いますが、BSD系のOSに入れ替えるつもりですし、最新型である必要はないので、中古で探そうと思います。今使っているdynabookと形状が近いLet's note CF-SV9にしようかと考えていました。

 

秋葉原に気軽に行ける場所には住んでいないので、通販で買うことになると思います。新品ならいざ知らず、中古を通販で買うのは多少の不安があります。新品同様の美品を期待している訳ではありませんが、部品取りにしかならないジャンクでは困ります。中古を扱っているサイトを調べていると、CF-SV9の底値は2万円くらいのようです。

 

ちょっとグレードを落としてCF-SV8にすると底値1万5千円くらいになり、さらにグレードを落としCF-SV7ならば底値1万円でした。どれであっても現状のdynabook SS SX/15Aと比べれば、快適に使えそうです。迷ったので、Geminiに相談してみました。中古なので、何を買ったとしても博打となる側面は避けられませんが、CF-SV7を選ぶよりは、CF-SV8かSV9を勧めるとのことでした。

 

Let's noteのこれらのモデルはSSDですが、入手してみないとSSDの劣化の程度が不明です。まだまだ十分使えるかもしれませんし、劣化が酷く交換した方が良いかもしれません。仮にSSDを交換するのであれば、その費用を考えれば、CF-SV8を選んでおく方が良いかもしれません。

 

何を選ぶにせよ、今夏には購入しようと思います。 

Inkscapeの文字が太い

文書に添付する図を描くときにInkscapeを使うことがあります。きちんとしたトレーニングを受けずに使っているので、常に試行錯誤しています。英文の「初心者用ガイド」が付属していますが、かなり膨大です。PDF版は241頁でした。これに目を通しておいた方が良いのだろうと思います。

 

簡単な図を描くだけなら、手探りで試行錯誤しても、なんとかなります。ただし綺麗な図にはなりません。簡単な図を描いてみたのですが、文字が太くなってしまいました。別に太字として設定したわけではありません。それなのに、太字で、完全にメタボです。

 

解決策をGoogleで検索したら、「テキストにもフィルとストロークがある」が見つかりました。この記事のとおりに設定を見直したら、文字がスッキリしました。ダイエットに成功した感じです。 

NHK「世界ふれあい街歩き」の謎

NHKで放送が続いている「世界ふれあい街歩き」という番組があります。放送されるときにはナレーションを担当する芸能人が会話しているように編集されていますが、収録時は現地のコーディネーターが会話しています。これはウィキペディアに記載があります。しかも相手とは偶然の出会いのように会話していますが、事前に打診があるようです。ただしそれを「仕込み」と考えるかどうかは、ウィキペディアとオンラインのQ&Aサイトの回答とで見解が分かれています。

 

人が集まっているところで「何をしているんですか」と声をかけるシーンが度々現れますが、それが偶然なのか、事前に打ち合わせ済みなのかは、放送を見ているだけでは判断つきません。全部仕込みに決まっているだろうという主張もあり得ますが、番組の性格上、通りすがりの人に声をかける場面もあるので、そこまで仕込みとは思えません。仕込みが全くないとは主張しませんが。

 

放送では、朝から夜まで散策したかのように編集していますが、実際には2日間撮影しているようです。通りすがりの人に声をかけてみたものの、思ったような反応が返ってこないこともあるでしょうし、NGシーンもあるでしょう。それを編集して、あたかも1日で歩いてみたという設定にしているのだと思います。ただ、初日と二日目の天気が大きく違っていたらどうするのだろうと思います。

 

事前に打ち合わせ済みの場所を撮影する場合は、いかに自然な出会いであるかのように見せるかが腕の見せ所なのだと思います。NHKには「ブラタモリ」 という街歩き番組もあります。この番組では、街を紹介する担当者が、不自然な様子で待機しているシーンがよく登場します。偶然出会ったという風にする必要はないので、あえて不自然な待ち方にしているのかもしれません。

 

formailは便利

これまで知りませんでしたが「formail」というコマンドがあるようです。procmailが提供しているようです。procmailは以前から利用していましたが、formailは知りませんでした。

 

話の発端は、MH形式でローカルに保存していたメールファイルが、様々な問題をかかえていたので、修正しようとして考えており、その調査のためにメールヘッダを網羅的に検証する必要がでてきたことでした。例えばContent-typeに「iso-2022-jp」と書かれているのに、「nkf --guess」で確認するとEUC-JPだったりするのですが、この他にも、多種多様な問題がありました。

 

やっかいなのは、メールヘッダの各項目は、一行ですむとは限らないことです。メールヘッダのある項目が、複数行に別れている場合があります。そうなると、単純にgrepしただけでは、検出できない場合が考えられます。そこで、複数行に別れているなら1行に結合する前処理をおこなえば、grepでも対処可能なので、そうしようと考えていました。その前に、念のためにGeminiにお伺いをたてたら、「formail」の存在を教えてもらいました。

 

formailは、まさに求めていたものです。これを使えば、自前で前処理をする必要がなくなります。なんと便利なものがあるものかと、これまでの無知を恥じ入るばかりです。

dynabook SS SX/15Aの後継としてLet's note CF-SV9を検討中

Windows Vistaが搭載されていたdynabook SS SX/15AをNetBSD/i386に入れ替えて使ってきましたが、ハードウェア的にもソフトウェア的にも、限界を感じるようになってきました。

 

そもそも電源を入れてても、NetBSDのブートメニューが出てこない場合があります。そういう時は、筐体を揺すってみるとか、表面とか裏面から押してみるなど悪あがきを何度か繰り返すと、そのうちに起動するようになります。起動してしまえば、途中で落ちたりはしませんが、どう見ても故障しているとしか考えられません。

 

また近年32ビット対応がなくなりつつあります。NetBSD/i386で利用できるFirefoxは、10年くらい前にリリースされたものしか入手できないので、単純にWebを見るくらいしか使いものにならなくなってきています。

 

新しいマシンを入手しようと思いますが、BSD系OSに入れ替えるつもりなので、Windowsは必要ありません。中古で十分ですし、状態のよいジャンクでも構いません（まともに動作しない、部品取りレベルのジャンクは、流石に願い下げです）。最新型である必要はありませんが、値段が変わらないなら、新しいモデルの方が有難いのは間違いありません。さらに、遠出する際に持ち運ぶ都合上としてB5サイズのサブノートを希望します。

 

このような条件で中古を探すとLet's note CF-SV9が候補にあがりました。中古ですから、状態も様々ですし、値段も様々です。安いものを探せば、2万円前後のようです。今すぐ購入することは可能ですが、もうちょっと様子をみようと思います。

古いドライブレコーダーで64GのmicroSDXCを使うためにFAT32にする

10年ほど前から車にドライブレコーダをつけています。購入時に付属していたのは4Gのメディアでしたが、録画時間を延ばすため、32Gに換装して使ってきました。つい先日、車のエンジンをかけたら警告音が鳴りだしました。何のエラーなのかと心配になりましたが、帰宅してからSDカードを確認したら、メディアが壊れていました。数か月前にも、スマホで使っていたSDカードが壊れてアクセスできなくなった経験があるので、多分同様の現象なのだと思います。

 

ドライブレコーダにメディアが入っていないことには、ドライブレコーダの機能を果たせませんから、急遽家電量販店に走りました。世間の噂によるとSDカードが品薄で値上がりしているとのことで、家電量販店でも在庫が少なかったし、値段も上がっている印象でした。

 

これまで32Gのメディアを使っていたので、同容量のものが欲しかったのですが、在庫がありませんでした。128Gとか、もっと大容量のメディアはありましたが、値段が高いのも困りものです。何か買わないことにはドライブレコーダが使えるようにならないので、64Gのメディアを買いました。

 

購入したばかりのSDカードをドライブレコーダに装着してみましたが、警告音が鳴りやみません。もしかすると壊れたのはメディアではなく、ドライブレコーダ本体の方なのかという不安がよぎりました。しかしネットで情報を集めてみると、古いドライブレコーダは、FAT32しか対応していない可能性があるが、64GのメディアはexFATが使われるので、FAT32でフォーマットしなおす必要があるという結論を得ました。

 

Windows11の標準機能では、64GのメディアをFAT32でフォーマットすることができないので、代替品を探しました。いろいろあるようですが、「I-O DATA ハードディスクフォーマッタ」を利用しました。さっそく利用してみましたが、FAT32でフォーマットしたつもりなので、Windows11で確認するとexFATのままです。またしてもネットで情報を集めると、「管理者として実行」しないとフォーマットできないことがわかりました。あらためて「管理者として実行」したら、今度はFAT32でフォーマットできました。

 

FAT32でフォーマットした64GのmicroSDXCカードをドライブレコーダに装着したら、警告音が止まりました。他にエラーもないようですので、ドライブレコーダとしての機能が復活したようです。 

殿上人卅余人

数年前から語り本系平家物語を最初から暗誦できるように読み進めています。『新日本古典文学大系 44 平家物語 上』を使っていますが「吾身栄花」の途中まで覚えました。ここは、平清盛だけでなく一門が繁栄したことを語る場面です。そこには、つぎのような一節があります。

すべて一門の公卿十六人、殿上人卅余人、諸国の受領・衛府・諸司都合六十余人なり。

 

ここで殿上人は「卅余人」（さんじゅうよにん）とあります。「三十四人」ではありません。「30人+α」ということです。公暁は「十六人」と人数をぼかしていないのに、殿上人は実際の人数を明らかにしていません。

 

『平家物語』には、語り本系と読み本系があり、これは語り本系です。印刷されたものを読むこともあるでしょうけど、本来は琵琶法師とかが語るのを聴くものです。「さんじゅうよにん」と語られたら、聞いている方としては、「三十四人」と理解するのか、「三十余人」と理解するのか、どちらなのでしょうか。

dynabook SS SX/15Aの代替を探したい

20年ほど前に購入した「dynabook SS SX/15A」には「Windows Vista」がインストールされていましたが、2017年にサポート終了となったので「NetBSD/i386」に入れ替えて使い続けてきました。メモリは4Gなので、32bit CPUとしてはフル実装ですが、HDDが60Gしかないので、窮屈です。換装しようにも、1.8インチHDDが使われているため、代替品を入手するのが困難です。

 

さらに昨今はソフトウェア側で32bit CPU対応を止めるものが多くなってきています。日常的に使用しているわけではないので、最新版を使いたいわけでもないのですが、利用可能なバージョンが古くて不便な状況に追い込まれてきました。

 

しかも、電源を入れても素直にOSが起動しない場合があります。そういう場合は、ノートPCごとを揺すってみたり、表面とか裏面から手で押してみるとかを繰り返すと、起動できるようになります。いったん起動してしまえば、動作中に落ちることはありません。大昔の家電製品は故障したら叩けば直ると（嘘か真か）言われていましたが、それに近いものがあります。

 

このままダマしダマし使い続けるのは可能だと思いますが、そろそろ代替品を探して、移行しようと思います。次もNetBSDにしようと考えています。新品である必要はないので、中古かジャンク品を入手しようと思っています。2万円くらいで入手できないかと思い探しています。通販でもよいのですが、現物を確認して買いたいところです。

CSVを操作するための「Miller」というツールがあるらしい

ローカルにMH形式で持っているはずのファイルを確認したら、いろいろな意味で問題があることが分かりました。2000年前後のものなのですが、メールヘッダには「iso-2022-jp」とあるのに、本文を「nkf --guess」したら「EUC-JP」と訴えています。これだけなら変換すれば良いのですが、文字化けという意味ではなく、種々雑多な問題が潜んでいそうです。しかも、そのようなメールが9万ファイル弱あって、簡単には修復できそうもありません。

 

Geminiに相談したら、ファイルごとの情報を整理したCSV形式ファイルを作ってから、対処方法を考えるべきだとのアドバイスをもらいました。それでCSV形式ファイルを作ってみましたが、ここから問題のパターンを整理しなければなりません。

 

これまでCSV形式ファイルを調査するには、AWKなどのコマンドラインツールを駆使してきました。今回もそれでいこうと思ったのですが、ちょっとGeminiに相談したところ、「Miller」というツールを紹介してもらいました。パッケージから簡単にインストールできましたが、使い勝手が手強そうです。公式サイトから「Miller 6.18.1 Documentation」を見つけました。まずは、これを読んで勉強してみようと思います。

花山院の左大臣殿の御台盤所にならせ給ひて、君達あまたましましけり

数年前から語り本系の平家物語を暗誦しようと思い、少しずつ覚えています。「祇園精舎」から始まり、「殿上闇討」、「鱸」、「禿髪」と進み、今は「吾身栄花」を覚えているところです。

 

ここには、「一人は、桜町の中納言重教卿の北の方にておはすべかりしが、八歳の時、約束計にて、平治の乱以後、ひきちがへられ、花山院の左大臣殿の御台盤所にならせ給ひて、君達あまたましましけり。」という一節があります。「花山院の左大臣殿」とは藤原兼雅のことです。二男一女をもうけたようですが、「君達あまたましましけり」というほどでもないかという気がします。 

 

平清盛には18人の子がいたようですので、ここまでいれば「ましまし」という感じはします。現代では「マシマシ」と言うとラーメンの注文のようですが、ニュアンスは同じのように思います。

GNUSを諦め、Wanderlustに復帰するかもしれない

10年ほど前から、メールを読むのにGNUSを使ってきました。ここ最近になって（それでも今年とか、去年とかではありませんが）、サマリー表示が「[nobody](1970-01-01 09:00)(none)」のようになっているのに気づきました。当初は、これはGNUSのバグだと考えていたので、いずれバグフィックスされるだろうと思っていました。いつまで経っても直らないので、GNUSの利用者が少ないか、開発者が少なくて、問題が発覚しないか修正されないのかと、見当はずれなことを思っていました。いい加減に業を煮やしてGeminiに相談したところ、対策を編み出してくれました。

 

そもそもメールを読むのに、FreeBSDを使っています。プロバイダからfetchmailでローカルに取り込み、procmailで振り分けてから、GNUSで読んでいます。Geminiに相談した結果、fetchmailやprocmailの設定誤りが発覚しました。その対処を済ませたので、もう大丈夫だろうと思っていたのですが、相変わらず、同様の現象が発生します。Geminiに言わせれば、ヘッダが大きすぎるので、GNUSの解析が途中で打ち切られてしまうのが原因だろうと推測しているようです。そうなのかもしれません。試しにヘッダを加工して、大きすぎるエントリを削除してみると、うまく解析できているようです。そうであれば、ヘッダが悪い可能性は高いと思います。

 

しかしメールのファイルをWindows11上のThunderbirdで読ませてみると、別に問題が発生しないので、GNUS側でなんとかならないのだろうかという気になります。Geminiに相談を持ち掛けてみたのですが、いろいろと試してみましたが、どうにも解決に至りそうにありません。

 

GNUSに拘るわけではありません。しかしEmacs上で動くこと、MH形式ファイルを扱えることが必要です。この条件にあうのは、GNUS、Mew、Wanderlustが候補となります。しかし、もともとはWanderlustを使っていたのです。ところが2013年3月頃、emacs24でエラーが多発するようになり、GNUSに移行したのでした。しかしGNUSでのメール送信方法がわからなかったので、メール送信にはMewを利用してきました。

 

GNUSを諦めるとすると、MewかWanderlustが候補です。Wanderlustの使用を止めようと思った頃にもMewにしようかと考えました。しかしMewは、メールの未読管理ができなかったのです。つまりMewの管理外、すなわちprocmailで振分けられてしまうメールを、Mewは未読か既読か認識できなくなってしまうのです。それでGNUSを選択したのでした。

 

2013年3月以降GNUSを使ってきて、サマリー表示が変にならなければ、このままGNUSを使い続けていたところです。しかしそういうわけにもいかなくなってきたので、懐かしのWanderlustに復帰しようかと考え始めました。

 

いきなり移行してしまうのも性急に過ぎると思います。まずは、現状のGNUSを使い続け、その裏ではWanderlustを試行しようと思います。そしてWanderlustでも大丈夫だと確信できたら、その時はGNUSを諦め、Wanderlustに復帰することになります。

NHKの見逃し配信は「本放送」終了後1週間

NHKのテレビやラジオは、ネット配信が行われています。視聴できるのは、テレビ（またはラジオ）で放送されてから1週間なのです。ただし注意が必要ですが、正確に言えば、視聴できるのは「本放送」から1週間です。「再放送」は関係ありません。

 

例えば「100分 de 名著」の場合、本放送は「毎週月曜　午後10時25分」で、再放送は「毎週金曜　午後３時５分」です。この場合ですと、本放送が終わってから1週間は見逃し配信がありますが、再放送は見逃し配信の期間に影響しないので、再放送からカウントすると数日間しかありません。

 

本放送とか再放送とか言う区分は、「放送」における区分に過ぎず、「ネット配信」とは別概念なのです。当たり前かもしれませんし、この違いは著作権の扱いによるものですが、少なからず専門的な概念ともいえるのではないかと思います。テレビやラジオを視聴している人にとって、それが本放送なのか再放送なのか気にしていないと思いますが、内部の放送関係者にすれば大問題なのです。だからこそ「見逃し配信はいつまで見られますか？」という問いに対して「見逃し配信は、放送の終了から1週間視聴できます。」と答えていますが、その真意は伝わっていないかもしれません。

視聴者からすれば、放送もネット配信も同じだと思っているのでしょうけれども、現時点では違うものです。しかしそれが未来永劫そうだとも限りません。未来は変わっていることを願いたいと思います。

 

SIMHのPDP-11エミュレータのメモリ参照は、16bitアドレス? 18bitアドレス? 22bitアドレス?

SIMHのPDP-11エミュレータを利用し、PDP-11/40上で動作するUNIXv6について学ぼうと考えています。まずは「m40.s」のラベル「start」から起動するプロセスを見ていこうと思います。ここではMMUが無効になっていますが、管理レジスタを設定し、MMUを有効にするための準備をおこないます。

 

「mov    $77406,(r1)+」のような箇所でMMUのレジスタに値を設定しています。ここでR1には「KISD0」が入っており、具体的には「172300」です。これは16bitアドレスとしての表現です。PDP-11/40のメモリ管理装置である「KT11-D」では、マニュアルの「Table 3-1 PAR/PDR Address Assignments」において「772300」のように定義されています。これは18bitアドレスです。ところがSIMHのPDP-11エミュレータでは、「17772300」のような22bitアドレスで参照しなければならないようなのです。

 

デバッガ機能を利用してメモリを参照した例を以下に示します。このように、16bitや18bitアドレスではMMUレジスタを参照できず、22bitアドレスで参照すると、格納されている値が参照できます。

Step expired, PC: 003370 (MOV #77406,(R1)+)
sim> s
Step expired, PC: 003374 (ADD R4,R2)
sim> e R1
R1:     172302
sim> e 172300
172300: 000000
sim> e 772300
772300: 000000
sim> e 17772300
17772300:       077406 

 

ちなみに、CPUは次のように定義しています。

sim> sh cpu
CPU, 11/40, NOFIS, idle enabled, stability wait = 20s, autoconfiguration enabled, 256KB 

エミュレーションするモデルを11/70としているのであれば、22bitアドレスでも納得するところです。しかし11/40として設定しているはずなの、22bitアドレスなのは、ちょっと不可解です。ただしSIMHが、そのような挙動なのは、そうなのですから、それを受け入れるしかありません。