その他のメモ

初回掲載：04/10/27（だったっけ？）
最終更新：24/11/02
上が新しい記事、下が古い記事、一部（短い水平線で区切った続きものの記事とか）例外あり

24年9月27日、おそらく午後11時30分くらい、Google検索がJavaScriptを無効にしたブラウザを弾くようになった。なぜかわからないが、Vivaldiだと弾かれるのに、Firefoxだと（JavaScriptオフでも）弾かれない。一時的なものですぐ元に戻るのかもしれないし、ずっとこのままなのかもしれないが、まあこんな日も来るんだろうという気はしていた。

いまのところFirefoxを使えば普通に検索できているが、乗り換え先は検討しておくべきなのだろう。現状、Ecosia、DuckDuckGo、Bingは似たような検索結果を返し、見た目とか使い勝手なんかを考えるとDuckDuckGoかなという感じ（BingはJavaScript必須なので落選）。これらと比べてStartpageは検索精度がよいが、どうせJavaScript必須ならGoogleの方がより優秀で、積極的に採用する動機に欠ける。ちょっとした穴場になっているのがYahooで、Googleにかなり近い検索結果を返す。

ここで「検索精度」と呼んでいるものは、筆者独自の非常に偏ったテスト方法で評価したもので、たとえば「"SD小K"」とか、このサイトでは嫌になるほど多用しているが一般的にはまず使わないような語をいくつか検索してみて、引っ掛かるかどうかというのを基準にしている。もちろん筆者もサイト持ちなので自分のトコが引っ掛からない検索エンジンは心証が悪いというのもあるが、マイナーな調べ物をすることが多いため「存在している情報ならば取りこぼさない」性能を優先したいというのが理由。たしかにあるorあったはずの情報を、サーチエンジンがヘボなために取りこぼすのは嫌である（まータダで使っておいてその言い様はどうかという批判はあるにしても、嫌なものは嫌である：動画系のサービスみたく、月額でカネ払ったらうっとおしい機能オフにしてくれる選択肢があったらいいのにね、ガチガチゴテゴテの支払い方法強制でさえなければ）。

話を戻そう。Yahooのクエリはhttps://search.yahoo.co.jp/search?p=検索語（オプションがqじゃなくてp：これで筆者は5分くらい悩んだ）なので、ローカルHTMLに

<form method="get" action="https://search.yahoo.co.jp/search">
<input type="text" name="p" value="">
<input type="submit" value="検索">
</form>

24年6月27日、Windowsマシンのsambaが突然繋がらなくなった。調べたところ、イジった覚えはまったくないが、共有フォルダの設定がおかしくなっていた（普段使っているsamba用ユーザーのアクセス権限が削除されていた）。さらに、VNCも外からのSSHも繋がらない。こちらはWindowsファイアーウォールが（それまで通していた）インバウンド通信をブロックしているせいだった。一瞬ウイルス感染も疑ったが、こんな奇妙な設定変更を加えるマルウェアはありそうにないし、理由がサッパリわからない。追記：この少し前に、ルーター（かもしかしたらNIC）が（おそらく熱暴走で）エラーを出して、ネットワーク関連の設定をイジってはいるが、少なくともsambaとファイアーウォールには手を触れていない（どこかしらが連動して設定が変わったのだろうと思う）。

世の中の流行がどうかはいざ知らず、FreeBSDを愛好している人の中には、この手の「やれと言ってもいないことをやる」コンピュータが大嫌いな人はけっこう多いのではないかと思う。もちろん、FreeBSD上で動くアプリの中には勝手なことをやるものも普通にあるが、FreeBSDというシステム自体は、ユーザーが（本当に意図したかどうかはともかく）やれと指示したこと以外はしないし、root権限を持つ人ならシステムのあらゆる所を読み取り変更できる。これは実に貴重な特徴だと思う。

もうひとつ、このところVivaldiをメインブラウザにしていたのだが、このアプリ、アップデートがあって「再起動」ボタンを押すと「前回クラッシュした直前に開いていたタブ」を開き直す（いつからこういう挙動になったのか覚えていないが、半年くらいは前だったんじゃないか：もちろん「ブラウジングデータを削除する」機能で全削除してもダメ）。筆者はアクセスログなんかをローカルプロクシで別途管理するポリシーなので、ブラウザの履歴類はすべてオフにしているのだが、なぜかどこかにタブのリストが保存されていて、それを管理する方法がわからない。筆者はこういうのも嫌いである。2024年7月追記：どうやら直った模様。2024年8月1日追記：と思ったら直ってなかった模様、なんじゃこりゃ。

元はといえば拡張の豊富さで選んだブラウザで、このところ筆者は拡張機能をほとんど使わないスタイル（JavaScriptのオンオフ以外だと、文字コード変更のボタンをごくまれに使うくらい）に落ち着きつつあるため、乗り換えてしまおうかと思い、ブラウザのラインナップを軽く調べてみた。

エンジンはほぼBlink系（KHTML＞WebKit＞Blinkという流れ：SafariといくつかのブラウザのMac版はWebKit）に落ち着いているようで、非主流派で目立つのはFirefoxのGecko＋Servoくらい（QtにQtWebEngineというのがあるがマイナー：KHTMLベースなのか新たに書かれたのか不明、QtWebKitというのもあるそうな）。もしBlink系から選ぶとしたら、下モノはほぼ似たようなものになるわけだから、上モノがどれだけスッキリしているかというのが基準になる。Chrome、Edge、Opera、Vivaldi、Braveと、調べてみたらSleipnirも今はBlinkなのだとか。

うーむ、改めて眺めてみても、上で挙げた中ではVivaldiなのかなぁ。とするとvs Firefoxでどちらが、ということになるのだが、筆者はもともとインターネット用とローカル用でブラウザを分ける習慣が（ネスケとIEの時代からずっと）あり、既に両方とも常用している。ならば、Firefoxに一本化するか、他にローカル用ブラウザを見繕ってFirefoxをインターネット用にするか・・・後者の方が理想に近そうなので少し探してみよう。

久々にCGIをイジる機会があったのだが・・・いやぁ、すっかり不人気になったねぇ、Perl。そもそもが、ウェブコンテンツに「アプリ化」の波が押し寄せているようで、CGI自体がフェードアウト寸前みたい（とするとFlashは先進的だったんだねぇ）。しかしその引き潮がかえって、CGIといえばPerlかPHPという状況を温存してもいる模様（憶測だけど）。CGI用途に限定せずプログラミング言語としての人気ランキングをいくつか眺めてみたところ、C系とJavaScript以外ではPython・Java・PHPあたりが人気で、少し離れてRubyくらいの感じだった。

がしかし思い返すに、CGIでの活躍が派手だっただけでそれ以外の用途では、Perlの役回りってそんなに華々しいものではなかったような気がしないでもない。テキスト処理が手軽なことを利用して検索置換とか、ベースシステムへの組み込みが進むにつれてシェルスクリプトの代替を担ったりとか、そういう地味なタスクをそれなりにこなせるのが、そもそもの美点だったように思える。そのいっぽうで、sedやawkを駆逐し尽すほどの勢いを持てなかったあたりも、PerlらしいといえばPerlらしいのかもしれない。

注意：以下は2023年12月19日現在に筆者が聞き齧った断片的な情報です。実際のセキュリティ対策に際しては一次情報を確認してください。
影響は限定的なようだが、SSHにTerrapin attackという攻撃への脆弱性が見つかり、OpenSSH 9.6/9.6p1 (2023-12-18)で修正された模様（https://www.openssh.com/releasenotes.html）。筆者はこれをTera Termに関する窓の杜の記事（https://forest.watch.impress.co.jp/docs/news/1555812.html）で知ったのだが、opensshについては19日現在日本語の注意喚起（セキュリティホールmemoさんもまだみたい）が見つけられなかったので、いちおう記事にしておいた。

QRコードによる「リンク」の仕様について。ブックマークレットというjavascriptを使っており「javascript:void(window.open(%27アドレス);」とか「javascript:(function()%7B window.open(アドレス);」といった形になる。またたとえばWifiの場合、 WIFI:S:アカウント;T:WPA;R:1;P:パスワード;; のようになるらしい。エスケープは値の中の「コロン、セミコロン、コンマ、バックスラッシュ、二重引用符」。

以下、断片的に集めた仕様情報を孫引き。

vCard

MECARD形式（iモード用） - カンマで区切ってある項目は、カンマで区切らずひとまとめに記述してもよい。

MECARD:N:<姓>,<名>;SOUND:<姓カナ>,<名カナ>;NICKNAME:<ニックネーム>;TEL:<電話番号1>;TEL:<電話番号2>;TEL-AV:<テレビ電話(FOMA)の電話番号>;EMAIL:<メールアドレス1>;EMAIL:<メールアドレス2>;URL:;ADR:<私書箱>,<部屋番号>,<番地>,<市町村>,<都道府県>,<郵便番号>,<国名>;BDAY:<誕生日 西暦で8桁>;NOTE:<メモ>;;

MEMORY形式（au・ソフトバンク用）　- 電話番号では、* # - P（ポーズ機能）も使用できる。

MEMORY:<メモ>NAME1:<名前>NAME2:<名前カナ>MAIL1:<メールアドレス1>MAIL2:<メールアドレス2>MAIL3:<メールアドレス3>TEL1:<電話番号1>TEL2:<電話番号2>TEL3:<電話番号3>ADD:<住所>

BEGIN:VCARD

VERSION:2.1

N:Gump;

FN:

ORG:

TITLE:

TEL;WORK;VOICE:

TEL;HOME;VOICE:

ADR;WORK:;;

ADR;HOME:;;

LABEL;HOME;ENCODING=QUOTED-PRINTABLE:

EMAIL;PREF;INTERNET:

REV:

END:VCARD

定時処理をWindows上でやるためのメモ。タスクスケジューラーをcronの代わりに、バッチファイルをシェルスクリプトの代わりに使う。

またまたFreeBSDと無関係な話題なのだが、常時起動のサーバを用意できないままdDNSを使う必要が出てきた。Hyper-V上のLubuntuを常時起動はしたくないし、WSL2を（たかがdDNSの更新のために）追加で入れてcronを回すというのもオーバーヘッドがデカい。DiCE for Windowsという選択も有力ではあるが「ProfessionalVersion」でないとサービスとして実行できないようで、どうせスクリプトを書くなら自前でHTTPsアクセスしてもいいかな、と考えて調べたのがキッカケ。

実は、WindowsでもPowerShellにwgetコマンド（に見えるもの）があり、Invoke-WebRequestコマンドレットへのエイリアスになっている。またWin10時代の途中から「curl.exe」（curlコマンドのMS独自実装）が標準でインストールされるようになったらしい（2023年現在は、本家cURLもWindows用のcurlの配布を継続している）。別にどれを使っても大差なさそうだが、手作業インストールだとアップデートが面倒だし、本家のcurlと挙動が異なる（のだと思う、多分）コマンドを使うのもうっとおしいので、単純にPowerShellからInvoke-WebRequestを使うことにした。

そのPowerShellは、PowerShellスクリプト（ps1ファイル）の直接実行で起こそうと思うとメンドクサそうで、パワーじゃない普通のシェル（コマンドプロンプト）から呼ぶのが手っ取り早いよう。

https://learn.microsoft.com/ja-jp/powershell/module/microsoft.powershell.core/about/about_scripts?view=powershell-7.3
https://blog.treedown.net/entry/2019/01/21/010000

https://learn.microsoft.com/ja-jp/windows-server/administration/windows-commands/schtasks-create

schtasks /create /sc minute /mo 分数 /tn "名前" /tr パス

実行可能ファイル、スクリプト ファイルまたはバッチ ファイルの完全修飾パスとファイル名を入力します。 パス名は 262 文字を超えない必要があります。 schtasks パスを追加しない場合、ファイルは <systemroot>\System32 ディレクトリにあると見なされます。

ともかくまとめると、

タスクスケジューラー＞バッチファイル（＞ps1ファイル）＞PowerShell＞Invoke-WebRequestコマンドレット

PowerShell -command "Invoke-WebRequest -O \"ログファイルのフルパス\" \"https://f5.si/update.php"?"domain=ユーザー名"&"password=パスワード\""

schtasks /create /sc minute /mo 15 /tn "タスク名" /tr "バッチファイルのフルパス"

Hyper-V上のゲストOSを、KubuntuからLubuntuに乗り換えることにした。ネックはメモリで、ゲストマシン上にVivaldiを立ち上げてちょっとサイトを開いただけで、Lubuntuでも物理メモリ（8GB）を9割がた使い切ってしまう（いやー、イマドキはそんなに使うんだねぇ：まあメモリなんて余らせても無駄なので、あるならあるだけ使い切って速度に変えるのが王道なんだろうけど）。マシンが速くて画面がデカければPlasmaの方が快適なのかもしれないが、そもそもの話として、パソコンを使っている時間のほとんどはアプリケーションの画面を見ているわけだし、KDEアプリでなんでもかんでもという時代でもなくなっているので、筆者の手元の仮想マシンではLXQtのメリットが勝った。

ということでゲストLubuntu（22.04.2 LTS (Jammy Jellyfish)）の細かい設定を進めたい。自動ログインは、/etc/sddm.confで

[Autologin]
Session=Lubuntu

[Autologin]
Session=Lubuntu
User=ユーザー名

ここでセキュリティについて少し考えておこう。Ubuntuに限らずUnix系OSの多くは「コンソールにアクセスできる人は何でもできてしまう」設計のものが多い（FreeBSDなんかは/etc/ttysでconsoleの設定をinsecureにしておけば、シングルユーザーモードのログインにrootパスワードを要求できるが、物理でHDDなりSSDなりを引っこ抜かれると、暗号化していないデータは読まれるし、平文の設定ファイルは書き換えることもできるだろう）。ユーザーデータを守りたいならシステムとは別の鍵が必要で、Ubuntuのkeyringはその手段を手軽に提供してくれる点で優れている。もちろん、下で紹介したKeePassみたいなソフトを使うのも一案ではあるものの、keyringはシステムと統合されているため（ちゃんと動けば）利便性の面で優位性がある。しかしどちらも仮想マシン上で使うには注意が必要で、たとえば「鍵が開いた状態」のスナップショットをうっかり残してしまうと、鍵管理システムがいかに堅牢でも意味がなくなってしまう。ここは「注意深く運用」ではなく、仮想マシン上には最初から重要なアカウント情報を置かないのが、よりよい対策だと思う（せいぜいホストマシン上のsambaフォルダへのアクセス情報くらいに留め、かつ盗まれるリスクが（少なくとも相対的に）高いことを前提に繰り入れた運用が必要だろう）。

さらに、ちょっとした重箱の隅つつき。たとえば、ファイルにhoge、システムにmogeというパスワードを使うのと、ファイルにだけhogemogeというパスワードをかけてファイルにアクセスできる人は無条件で信用するのとで、どちらが安全かという疑問がある。言い換えると、パスワードを人間が覚えて入力するという前提があるなら、その合計ワード長（と単純化して考えているが、現実的にはパスワードの更新頻度も含めて考える必要があろう）には自ずと限界があり、限られた資源を集中的に使うのと分散させるのとでどちらがよいかという問題である。もちろん、とても優秀な記憶力によりランダムで長いパスワードを正確に記憶できる人なら、認証ごとにユニークでかつ長いキーを短いサイクルで変更しながら使うこともできるだろうが、そんな人はめったにいない。おそらくは入り口に一点張りするのが技術的には正解なのだろうが、実用上はリスクがデカい。このバランスを用途に合わせて取るのは、そうそう簡単ではなさそうに思える。

筆者はこれまでずっとエレコムのM-XGL10UBという5ボタンマウス（EX-Gシリーズの有線Lサイズ）を愛用しており、デフォルトで「進む」と「戻る」になっているボタンに「PageUp」と「PageDown」を割り当てて使っていた。ナビゲーションはほとんどこの2つのボタンでやっており、とくにPageDownのボタンはウェブサイトを閲覧するときもターミナルでmoreやlessを使うときも酷使しまくるため、手元の個体はそろそろボタンがヘタレてきた。で同じ機種に買い替えたのだが、エレコム マウスアシスタント５という補助ソフト（配布パッケージで90MB近い超巨大アプリ）のバージョンが上がって「PageUp」と「PageDown」を割り当てができなくなってしまった（Win11マシンに入れてもダメ）。

いやー、これは悲しい。同じエレコムでM-DUX30という10ボタンマウスも持っており、こちらはハードウェア割り当てでどんなボタン（やキーボードマクロ）でも登録できるのだが、マウスとしての持ちやすさと操作性ではどうしてもM-XGL10UBに軍配が上がる（エクセルやドローソフト使うときなんかはすっごい便利だけど、これまで普段はサブ機扱いだった）。仕方なくM-DUX30をメインにして新しく買ったM-XGL10UBは予備に回すことになってしまった。うーむ、世の中の多数派は「進む」と「戻る」の方が便利なんだろうか。

と思っていたらなんとコレ（M-XGL10UB）、筆者のレガシーマシン（PS/2端子がついてたギリギリ最後の世代の機種、たぶん2011年の夏に買った）に繋いでおくと、起動時にBIOSが立ち上がらなくなる。マシンがあまりに古いため、BIOS前でコケている画面を見て「マザーが死んだか」と早合点したのだが、何のことはなくマウスを外せば普通に起動する（他のマシンでなら大丈夫だし、OSが起動した後で挿せばレガシーマシンでも使える）。たかがUSB機器じゃないかとは思ったものの、よく考えると、USBキーボードやUSBマウスでBIOSの操作ができるということは、BIOSをコケさせることもきっとできるということになる。うーん、考えてみたらそりゃそうか。

有線マウスの代替品を探してみたところ、TeckNet（公式サイトのContact Usにはリバプールの住所が記載されているが、ABOUT OUR STOREの記載は香港のCHATHAM COURT（漆咸囲）で、アメリカにも拠点があるみたい：https://tecknet.com/）とDELUX（深センの企業らしい：https://www.deluxworld.com/en/）というベンダーのものが、そこそこの価格で多機能っぽいが・・・マウスはやはり手に取って選びたいし、ヨドバシあたりに足を運べる機会があるまでM-DUX30で保留かなぁ。

Lubuntuがすっかり気に入ったので、もう少し試してみたい。デフォルトファイラーがPCManFM-Qtというソフトでそれなりに便利（機能は十分充実しており、23年5月現在のバージョンでは、詳細表示でのフォルダへのドロップも可能だし、sambaクライアント機能はデフォルトで有効、もちろんデスクトップにファイルも置ける：ぱっと思いつくところで「ああこれできないのか」というのは、タブへ直接のドラッグアンドドロップくらい）。筆者の手元ではなぜか、画面上と左に数十ドットくらいの余白ができるのだが、Hyper-Vだとこの余白にちょうどメニューバーが重なってとても都合がよい。

制限事項として、ゲストOSからはサウンドデバイスが使えない。RDPでならサウンドを飛ばせる（AndroidでもaRDP proならイケる）し、Hyper-Vでも拡張セッションならパススルーしてくれるらしい（https://learn.microsoft.com/ja-jp/virtualization/hyper-v-on-windows/user-guide/enhanced-session-mode）のだが、筆者の用途だとゲストOSの音が出ないからといってどうということはないので無視した。もうひとつの制限としてクリップボード共有（これも拡張セッションなら共有できるらしい）があり「クリップボードから入力」機能も動作しない（Kubuntuでは動いてたと思う）。深く追求する気もないので、samba上に空のテキストファイルを置いてテキストデータを受け渡している（ホスト＜＞ゲスト間でIRCとか、Qlipperの保存先をsambaに同期させるとか、バカ技も考えはしたが試してはいない）。ホストWindowsへのログインは、パソコンからもAndroid端末からもRDPとVNCの併用とした。ホストWinとゲストLubuntuのモニタ解像度は、1600*900で行くか1920*1080のHDに戻すかまだ悩み中（追記：どうやら、Lubuntuは画面の余白が功を奏して1920*1080が快適みたい）。

なお拡張セッションというのは、ようするにRDP接続の亜種のようで、ゲスト側にRDPサーバを立てて少しツールを揃え、ホスト側で設定してやればWindows以外のゲストOSでも使えるそうな（筆者が試したことはない）。
https://learn.microsoft.com/ja-jp/virtualization/hyper-v-on-windows/user-guide/enhanced-session-mode
https://kb.seeck.jp/archives/12477
https://github.com/Microsoft/linux-vm-tools/
https://nishy-software.com/ja/dev-sw/hyper-v-extended-session-signin/
というかこれ、ホストWindows上のRDPクライアントからゲストOSのRDPサーバに接続するのと何が違うのかわからないのだが、たんにネットワーク絡みの設定が抽象化されているだけなら、わざわざお仕着せの機能でなくてもいいような気がする（もしかすると、ゲストの側で省ける処理を省いて動作を軽くしているのかもしれないが、まったく未確認）。

さて上モノを検討していきたいのだが、ファイル共有はやはりsambaにした。ホストが増えてきたのでそろそろファイル同期を検討しようかと思い、ネットストレージもいくつか眺めてはみたのだが、クライアントサイドでの暗号化が面倒そうで諦めた。サプライヤー側でノリ気じゃない機能だからか対応が限定的なようで、Google driveなんかも、

この機能に対応しているエディション: Enterprise、Education Standard、Education Plus、Enterprise Essentials Plus。
（https://support.google.com/a/answer/10741897?hl=ja）

ブラウザはVivaldiにした。現状でモダンブラウザを比較すると、拡張機能の質と量でchromeが一歩抜け出ていると思うが、そのchromeの拡張機能を利用しながら「静かに」利用できるのがVivaldiのいいところ。Vivaldiと同じChromiumベースでBraveというのもあり、広告料の分配ポリシー（閲覧しているユーザーにも分配される：Brave Rewardsというそうな）が斬新なのだが、今回は斬新さを求めていないので無難な選択にした。メーラーはなし。その気になればウェブメールはどんな種類のものでも使えるが、ゲスト上のxrdpではなくホスト上のRDPかVNCを使うことにしたので、メールくらいホストマシンのWindowsでやり取りすれば十分間に合う。

筆者はずっと、htmlファイルに関連付けるブラウザとhttpプロトコルに関連付けるブラウザを分けてきたので、今回もfirefox（せっかく入ってるし、EdgeやChromeよりは格段にうっとおしくない）をローカル用に使い回すことにした。firefoxはsnap版がプリインストールされており、23年5月現在はまだこなれていない（https://gihyo.jp/admin/serial/01/ubuntu-recipe/0714）ような話も目にしたが、手元ではとくに問題は起きていない。

GUIエディタはmeditにしようかと思ったが、2017年にリリースが止まって以降パッケージがメンテナンスされていないみたい（センスよかったのになぁ）。Lubuntuデフォルトのfeatherpadも十分使えるが、fcitx-mozcの表示がなんだかおかしい（未確定文字列の配色がとても見えにくいのと、すでに確定した文字列が未確定文字列の色で表示される）。うーーーん、featherpadのダークカラーテーマ（上記症状が少し緩和される）でいいや。もし困ったらnanoでもviでも使えるわけだし、GeditとかKateとかをわざわざ入れるほどじゃないと思う。

いったん環境はできたのだが、VirtualBoxも試しておきたい。このソフトはバージョン4.0からGPL2版とPUEL版のダブルラインナップをやめ、現在（バージョン7から）はGPL2の本体＋PUELのプラグインという形になっている（以前はできなかったが、現在は本体だけでのUSB2.0対応などもできるようになっている）。PUELというのはVirtualBox Extension Pack Personal Use and Evaluation Licenseの略らしく、License version 11, 21 May 2020によると

“Personal Use” is noncommercial use solely by the person downloading the Product from Oracle on a single Host Computer, provided that no more than one client or remote computer is connected to that Host Computer and that client or remote computer is used solely to remotely view the Guest Computer(s).

ついでにKDE Windows Project（https://community.kde.org/Windows）の成果物も眺めてみたのだが、23年5月時点で、さすがにPlasmaは移植されていなかった（https://www.microsoft.com/en-us/search/shop/Apps?q=KDE+e.V.）。仮想マシンを用意しなくてもWindowsで動いてくれるならそれがラクではあるのだが、Qtだけ動けばいいってものではないのだろうし、そう簡単ではないのだろう。それはそうと、Kubuntuの他にも、KDE NeonやManjaro KDEといったディストリビューションがあるので、もう少し選んでから試せばよかったかもしれない（最初から本命はKubuntu以外考えてなかった）。WikipediaJPによるとNeonは、

Kubuntuと同じようなユーザーをターゲットとしているが、より短いタイムフレームでQtやKDEのアップデートをユーザーに提供する

いよいよこれで、Kubuntu on WindowsにLANのどこからでもアクセスでき、WANからもSSHでログインできる環境が整った。いやー、元はといえば出先のMacにリモートしたくて実験で始めただけだったのだが（そのMacへのリモートは、実は途中で必要なくなった）。あとはHyper-VマネージャーからゲストOSの設定で自動停止と自動起動を設定しておけば、ホストを起動してすぐに使える（Hyper-Vマネージャーは単なるマネージャで、終了してもゲストOSは動き続ける：自動起動もゲストOSだけ立ち上がるので、リモート接続でなくホストの窓から操作するなら、Hyper-Vマネージャーから操作窓を立ち上げる操作は必要）。

もともと非力なマシンに仮想化のオーバーヘッドも乗っているので、動作はそんなに機敏ではないのだが、当然ながらAndroid端末の独力よりはよほど大きな計算力がある。パソコンからのアクセスだとVNCよりもRDPが軽いものの、クライアント側の処理が重いらしく、Android端末でのアクセスだとVNCの方が扱いやすかった（筆者の端末が非力すぎるというのも要因だと思う）。普段使い用であれば、携帯端末の負荷を最小化する接続方法でリモート先が足を引っ張っていないなら、ログインした先のマシンにそれ以上の軽快さは必要ない。

もしRDPを使うなら、Ubuntuの最初のログインをCUIだけ（> sudo systemctl set-default multi-user.target）にした方が軽いのかもしれないが、xrdpは単純にrc.dとかrc.confとかで起こせばいいのか、先に起こしておくものがあるのか筆者は知らない（軽くは調べてみたのだが、その際偶然、cronで@rebootを指定したときの挙動がOSごとに違うらしいことを初めて知った：https://www.xmisao.com/2013/04/24/cron-reboot-implementations.html）。ホストへのVNCしか使わないなら、ゲストUbuntuで> sudo systemctl disable xrdp.serviceでもやっておけばよさそう。

KDEはさすがの使い勝手で、筆者としてはWinよりもMacよりも親しみやすい（ターミナルがbashだからtcshは入れてもいいけど、デスクトップLinuxでシェルを使う機会もそんなにはないかな、という認識でまだ手を付けていない）。あとはファンレスPCを調達してきてFreeBSDでサーバを立て、そちらにSSHdとマジックパケットを任せて・・・というのはまだまだ先の話になりそう。

注意：自分でもちゃんと理解していないことを書いているので、この項の情報を鵜呑みにしないでください
Hyper-V上にKubuntuを立ち上げることはできたので、実用的な設定に入る。まずファイル交換は、ホストのsambaを使うことにした。ローカルにFTPd（LANの内側で使う分には今でも便利な道具だと思う）が立っているならそれを使ってもいいのだろうし、イマドキな環境の人ならインターネット上のストレージを使う手もあるのかもしれないが、ゲスト＜＞ホスト間のやり取りだけで完結できるのはメリットだと思う。

しかし、Hyper-Vの設定が泥沼だった。機能として仮想スイッチと仮想NICというのがあり、どう考えても別物なのだが、扱いがごちゃごちゃになっているようにしか見えない（いやー、これこそWindowsだ：思い出したくはないが、それでも懐かしい）。デフォルトの状態ですでに「Default Switch」という名前の特別な仮想スイッチがあり、ゲストUbuntuからNAT越しにインターネットは見えるしLAN内のホストにもpingは届くが、筆者の環境では物理LANのサブネットを使ったsambaアクセスはできなかった。Hyper-Vマネージャーの右上ペインにある仮想スイッチマネージャーを使って「内部仮想スイッチ」という種類の「スイッチ」を新規作成（ここでは名前も「内部仮想スイッチ」にした）すると、Hyper-V上のゲストとホストだけが接続できる仮想スイッチが追加される（と同時に、このスイッチへの接続専用の仮想NICがホストに追加され、ゲストに追加可能になる）。この内部仮想スイッチは本当に単純なスイッチングハブ（リピーター）として振舞うようだ（何かしら設定が可能そうな書き方の紹介記事が多かったし、Default Switchはスイッチという名前ながらNATを提供していたので、最初はルーターっぽいものなのかと思ったが違ったよう）。MACアドレスの管理もひとクセあり、先にホストWindowsの仮想スイッチマネージャーでグローバルネットワーク設定ペインからMACアドレスの範囲を指定しておかないと、Hyper-Vマネージャーで仮想マシン＞設定＞ネットワークアダプター＞高度な設定＞MACアドレスで「静的」を選択できない（理由はまったくわからない）。とてもうっとおしい話ではあるのだが、もしゲストマシンでネットワーク関連のトラブルがあったら、真っ先にこのデバイス設定を再確認するのがよい。

Default Switchと内部仮想スイッチの2つが存在している状態で、ホストWindowsのコントロールパネルからネットワークと共有センターを開くと「vEthernet(内部仮想スイッチ)」という名前の接続が見える。またPowerShellからipconfigすると「vEthernet (内部仮想スイッチ)」と「vEthernet (Default Switch)」が見えて、それぞれにローカルIPを持っている。PowerShellからGet-NetAdapterすると「vEthernet (内部仮想スイッチ)」が見える。ようするに、Default Switchという名前の仮想スイッチは、Default Switchという名前の仮想NICと仮想接続され、ローカルIPアドレスも持ってはいるが、コントロールパネルやGet-NetAdapterからは見えない。これを理解するのにかなり時間がかかった。そしてまた、ホスト側で、コントロールパネル＞ネットワークと共有センター＞vEthernet(内部仮想スイッチ＞プロパティと選んで、共有タブで共有を有効にしてやると、筆者の環境ではなぜか、Default Switchの仮想NICが繋がっている先の物理NICのローカルIPを勝手に変更された（ヘッドレスで運用しているのでマウスとキーボードを探して挿すのにけっこう手間取った）。話を戻すとようするに、物理LAN、ホストWinがゲストUbuntuにNATを提供するデフォルト接続（仮想：ゲストはこれを使ってWANに出る）、ホスト＜＞ゲスト間を単純にLANケーブルで繋いだ内部接続（仮想：間にスイッチはあるがリピート以外何もしていない、はず）の3つを併用する格好になる。

筆者がやりたいことは、ゲストUbuntuからホストWindowsのsambaフォルダへのアクセスで、ホストWinのローカルIPは固定されていないと不便で仕方ない。どうやら、PowerShellからRemove-NetIPAddressとNew-NetIPAddressを使ってアドレスを固定する方法（https://qiita.com/TomoyukiSugiyama/items/8ec60c8accef21540708）もあるようなのだが、Default Switchは設定が特殊っぽいのでできればこちらには触りたくない。どうせなら簡単に作って消せる方をイジりたい。ということで、ホストのネットワークと共有センターでvEthernet(内部仮想スイッチ)（という名前の仮想NIC）のIPアドレスを固定して、ゲストOSの仮想ハードウェアとして内部スイッチ用のネットワークアダプタを追加、KDEで接続メニューから有線イーサネットを選択、先ほど設定した（ホストの）内部スイッチ用NICと同じサブネットで固定IPを指定、KDEのDolphin（ファイラー）でネットワークを選びsambaフォルダにアクセスし、場所を登録しておく（普段英語版を使ってるので、メニューの名前とか微妙に違ってたらゴメン）。普通にやればKDEウォレットの設定を促されてパスワードを管理してくれるはずだが、別に自分の頭で覚えてもいいし、smb://ユーザー名:パスワード@ホストWinのIP/の形で入力しても受け付けてくれる（ウォレットが安心だとは思うけど）。

さてお次は直接のリモートログイン。その前にLAN上の他の（ホストWin以外の）マシンからゲストにアクセスできる経路を作っておく。やり方は2つあって、どちらも管理者権限のPowerShellから、Add-NetNatStaticMappingで仮想スイッチのNATを設定する方法と、netshを使ってホストOSのネットワーク設定として登録する方法を選べる模様。NetNatはなんとなく大変そうなので、今回はnetshを使った。コマンドは、

netsh interface portproxy add v4tov4 listenport=転送元ポート listenaddr=転送元アドレス connectport=転送先ポート connectaddress=転送先アドレス

> sudo systemctl enable xrdp.service
> sudo systemctl start xrdp.service

[Allow Colord all Users]
Identity=unix-user:*
Action=org.freedesktop.color-manager.create-device;org.freedesktop.color-manager.create-profile;org.freedesktop.color-manager.delete-device;org.freedesktop.color-manager.delete-profile;org.freedesktop.color-manager.modify-device;org.freedesktop.color-manager.modify-profile
ResultAny=no
ResultInactive=no
ResultActive=yes

[Management all Users]
Identity=unix-user:*
Action=org.freedesktop.packagekit.system-sources-refresh
ResultAny=yes
ResultInactive=yes
ResultActive=yes

RDPでは多重ログインができない（サーバがWinだと先に入っていた人が追い出され、xrdpだと後から入った人が真っ黒画面に飛ばされる）ので、リモート用にテキトーなアカウントを作っておく（KDEとかfirefoxとか丸ごと設定し直すことになるからメンドーだけど：作ったアカウントをxrdpのグループに入れる作業が必要、という解説もあったが、手元では必要なかった）。ひとつのアカウントでも、xrdpのログイン画面だけ先に出して、普通のアカウントはログアウトして、それからxrdpでログインすることはできるみたい。

追記：WindowsでのRDPによる複数接続は、技術的な問題とライセンス上の問題（RDP接続は「Windowsログイン」の一種と見なされる）があって、とてもメンドクサイ。技術的には、

RDP Wrapper Libraryを使う（https://github.com/stascorp/rdpwrap）
termsrv.dllに手パッチを当てる（内容不明）
レジストリの、コンピューターの構成＞管理用テンプレート（＞Windowsコンポーネント）＞リモートデスクトップサービス＞リモートデスクトップセッションホスト＞接続から「リモート デスクトップ サービス ユーザーに対してリモート デスクトップ サービス セッションを1つに制限する」を無効にする。

/etc/pam.d/password-authに「session required pam_limits.so」を記述
/etc/security/limits.confで「maxsyslogins」「maxlogins」などを設定
/etc/limitsに設定を書くディストリビューションもあるのだとか何とか

連休（執筆時点は23年5月初め）だし、ハードを増やす前に仮想マシンを試す。候補は、WSL2、Hyper-V、VirtualBOX、VMWareくらいか。

とりあえずWSL2＋Ubuntu（22.04.2 LTS、以下断りがなければ同様）から。まずvGPU用ドライバ（https://learn.microsoft.com/ja-jp/windows/wsl/tutorials/gui-apps）を入れ、Winの設定でLinuxベースシステムと仮想マシンを有効にしたら、WSL2用カーネルをMSのサイトから落として、PowerShellでwsl --update（公式から落としたのに最新版じゃないのかよ）。Microsoft Storeのなんだか端っこの方からUbuntu22を探し出してインストール。ファイルさえ落としたらあっという間。systemd=trueは最初から設定されていたし、タイムゾーンもちゃんと日本。だいたいの流れはこんな感じ（$がPowerShell、>がUbuntu、何もないのはWindowsの設定など）

$ wsl --set-default-version 2
$ wsl --update

> sudo apt update -y
> sudo apt upgrade -y
> sudo apt install -y libgl1-mesa-dev xorg-dev xbitmaps x11-apps
> sudo apt -y install ubuntu-desktop
> echo 'export DISPLAY=$(cat /etc/resolv.conf | grep nameserver | awk '\''{print $2}'\''):0.0' >> ~/.profile
> exit

$ wsl.exe -t Ubuntu

VcXsrv＞XLaunch
Disable access control
firewall

> sudo service x11-common start && sudo service dbus start && gnome-shell --x11 -r

Failed to start x11-common.service: Transport endpoint is not connected See system logs and 'systemctl status x11-common.service' for details.

次はHyper-V＋Ubuntu。これは単なる仮想マシンなので、FreeBSDももちろんインストールできるが、筆者がデスクトップで使いたいのはKDEであって下がLinuxでもBSDsでも関係ないため、おそらくはこなれているであろうUbuntuを選んだ。コントロールパネル＞プログラムと機能＞Windowsの機能の有効化または無効化＞Hyper-Vを有効にして、再起動を促されるので再起動。さらに、スタートボタン＞すべてのアプリ＞Windowsツール＞Hyper-V クイック作成＞デバイスへの変更を許可＞オペレーティングシステムを選択＞仮想マシンの作成、というのがよく紹介される手順だが、なんとこれ、単にインストールディスクのイメージを取ってくるためだけの作業らしい（なんてアホらしいんだ）。しかも通信が激遅で、2.31GBのイメージファイルが落ちてくるまでに、筆者の環境だとざっくりで9時間くらいかかる（普通にhttps://jp.ubuntu.com/downloadから落とせば2時間くらい：本当に同じファイルなのかどうかは確認していないので、カスタムが入っている可能性は否定しない）。ダウンロードしたファイルはセキュリティビットが立っているので、ファイルを右クリックしてプロパティからセキュリティのチェックを入れておく。余談というか愚痴だが、最近のWindows（10以降？）はコントロールパネル（%SystemRoot%\System32\Control.exeと.cplファイル群）と設定（%SystemRoot%\ImmersiveControlPanel\SystemSettings.exeをms-settings:スキームから使う）の役割が錯綜していて、実に分かりにくい。

ともあれインストールのためのイメージを入手したら、スタートボタン＞すべてのアプリ＞Windowsツール＞Hyper-Vマネージャで操作＞新規作成。ウィザードが出るので、名前、保存場所、世代（第2世代にする）、メモリ（あまり欲張ると起動でコケる）、ネットワーク（仮想スイッチを使うか否か）、イメージファイルがあるならそれを指定、完了。これらの設定は右画面の「設定」から変更でき、自動でチェックポイントが作成され起動時に「戻る」を選択できる。他の項目に問題がなくても、セキュリティのセキュアブートだけは「Microsoft UEFI 証明機関」に変更しないとUbuntuはブートできない。もとの画面に戻り、右画面からUbuntuの起動を選ぶと起動する。メニューの接続を選ぶか画面のサムネイルをダブルクリックするとウィンドウが表示される。さすがはUbuntuでディスクから起動した時点でGUIが立ち上がる。あとは普通にセットアップ。最初の再起動までが意外と時間がかかる（もちろんマシンスペックと回線次第）。

インストールが終わって再起動ボタンを押すと、インストールメディアを取り除くよう指示が出るのだが、筆者の環境では何もしなくても取り出し状態になっていた（設定＞SCCIコントローラー＞DVDドライブで確認or変更できる）。オンラインアカウントやらUbuntuPro（有料サービス）の選択があって、インストールメディアから入れたソフトウェアを更新するかどうか聞かれる（これを裏でやってる間にほかの設定をやってしまうと手っ取り早い）。インストールメディアで古いパッケージをインストールしてからアップデートするというやり方は、多少非効率な面があるのかもしれないが、インストール最中でのコケにくさ（万が一相性問題などがあっても「起動はできていた」状態を把握できていれば話が早い）に寄与しているので、これはこれでアリだと思う。最小インストールを選んだのだが、Xはもちろん、FirefoxやLibreOffice（んー、Apacheが好きなんだけど入れ替えるほどじゃないや）まですでにセットアップされていた。

rootのパスワードを設定していない（！）はずだが、ターミナルから sudo passwd rootで設定できる（うわー、キモチワルイ、キモチワルイ）。右上のネットワークアイコンから設定を選び、有線接続（これがホストにつながっている）の設定ボタンをクリック、設定を確認and修正しておく。筆者の環境では、172.x.0.1（xは都度変わる）というデフォルトルートにぶら下がった状態になっていた。左下のアプリケーションを表示するから設定を選び、こちらも確認and修正。アップデートのタブのESMというのはProサービス絡みの更新サービスみたい。ということで

> sudo apt-get install numlockx
> sudo apt-get install kde-full

さてさていよいよ本命。やはりKDEを使いたいならKubuntuだろう。サーバが強いのか利用者が少ないのか、インストールイメージは爆速でダウンロードできる（自分の回線が速ければ）。単なるバリエーションパッケージかと思いきや、インストーラーもUbuntuとはかなり違う（筆者はKubuntuの方が好き）。何か書こうと思ったが、アッサリとKDEが立ち上がってしまい特にネタがない。最初の再起動のときだけ、もしどうしても固まったらホストのWinごと再起動かけてやれば直る、ということくらいかな。それからおそらくなのだが、Hyper-Vのチェックポイント機能、これ、ゲストを操作する窓の上部メニューから操作＞チェックポイントで「サブフォルダを作ってそこにカレントを移す」動作をしてるように思えるのだが・・・どうやって管理するのかメンドクサイので調べていない。Hyper-VマネージャーのゲストOSの設定＞チェックポイントで「自動チェックポイントを使用する」を無効にしておかないと、せっかく手動でチェックポイントを作っても後から後から上書きされてしまう。またそのすぐ上にある「統合」機能は（ちゃんと調べる気はないがどうせゲストがWinでないとマトモに動かないんだろうという当て推量で）全部OFFにしておいた。

注意：自分でもちゃんと理解していないことを書いているので、この項の情報を鵜呑みにしないでください
リモートアクセスはできるようになったので、運用についてさらに検討する。まず手を付けたいのが鍵の管理。クライアント側で秘密鍵を持つというSSHの仕様から、モバイル機器からのログインは据え置きマシンからのログインよりもリスクが大きい。丸ごと紛失したのが明らかならまだしも、うっかり端末がロックされない状態でメシ屋のテーブルにでも置いて、見ていない間に誰かに触られていないとも限らないような状況はとても困る（その場で鍵を破るのは困難でもファイル送信の手段は豊富なので、秘密鍵をどこかにアップロードして端末だけコッソリ戻すようなことは可能なはず：すぐに気付けば何分前にどのアプリを使ったかはわかるが、それで安全を確認できるかといえば疑問）。秘密鍵を持ち歩かないわけにはいかないのだとしたら、端末の扱いには慎重を期すとしても、実効性の高い対策はパスフレーズを強力なものにするしかない。しかしもうひとつの問題として、スマートフォンのスクリーンキーボードはやはりショルダーハックに弱い。

この両方に対応するワークアラウンドとしてパスワードマネージャの導入が考えられ、オフラインでも使えるオープンなものとしてはKeePass形式がある（この手のソフトとしては珍しくオリジナル（KeePass）がWindowsアプリだが、バージョン2からクロスプラットフォーム化された：互換クライアントとしてはKeePassXCが有名で、もとはLinuxへの移植としてQt版のKeePassXというのがあったのだが、2016年を最後にリリースが停滞してforkしたのがKeePassXC、らしい）。
https://laboradian.com/keepass-key-file/
https://tonahazana.com/keepass-setting/
Android用クライアントとしては、KeePass2Android Password Safe（以下KeePass2）やKeePassDXなどがあって、どちらも生体認証と仮想キーボード機能（クリップボードを経由せず自前の文字入力機能でパスワードを入力してくれる：KeePass2は最初アクセシビリティツールを使っていたらしいのだが、OS機能の目的外使用ということでG様にニラまれてやめたそうな）に対応している。しかしどちらも、生体認証を使うと1要素通っただけでフルアクセスを認めてしまう（23年5月現在、生体認証をキャンセルしてから、KeePass2はCLOSE DATABASEボタンで、KeePassDXは鍵の無効化アイコンで、再びマスターパスワードを要求するようになる：もちろんパスワードのみの運用もできる）。キーファイルの利用はできる（毎回マスターパスワードを使うようにすれば2要素にはなる）ものの、据え置き機ならUSBメモリなどにファイルを保存して必要なときだけマウントできるが、Android端末ではそういう運用はしにくいし、キーファイルをリムーバブルディスクで持ち歩くと紛失のリスクが増える。もし「アンロックした端末に触れる＝キーファイルも盗める」なのであれば、キーファイルを使うよりも労力のコストパフォーマンスが高い方法があるかもしれない。どちらにしても、普段からKeePass形式を使っているのであれば、モバイル用のデータベースは普段使いのデータベースと分けておくのが無難だろう（絶対的な強度はともかく、PC版よりは脆いのが明らかなので：たとえばKeePassXCはパスワード＋キーファイル＋ハードウェアキーの3要素を強制できる）。

ワークアラウンドとしては、SSHパスフレーズの最初ないし最後だけ頭で覚えておき、パスワードマネージャからの入力と合わせて使う方法がある（気合を入れるなら、自力1、マネージャ1、マネージャ2、自力2、マネージャ3のように複数回混ぜてもよい：手間と安全性のトレードオフ）。どうせSSHに使うなら、通知機能だのオートフィル機能だのは全部OFFにして仮想キーボードからの文字入力だけにしても十分（というかかえってトラブルが少ない）なので、前後や間に文字を足すのは簡単にできる。これなら生体認証＋PINくらいの強度にはなるし、単純にパスフレーズのビット数を増やせる効果もある。オンラインストレージへのログインを補助的な認証として使えないかとも思ったのだが、筆者はうまくやる方法を見つけられなかった（オフライン志向のKeePassDXやKeePass2のオフライン版も、ファイルオープンをfilesアプリに丸投げするのでGoogle Driveのファイルにアクセスすることはできるが、files（ログイン部分はcontactsアプリに丸投げ）がログイン情報を覚えてしまい都度の認証ができない：仮にできたとしても、パスフレーズの自力入力部分を長くするのと同じ効果しかないので、あまり熱心にはワークアラウンドを探していない）。

重要な注意：この段落の情報はよりいっそう怪しいので決して鵜呑みにしないでください
多段SSHのやり方には複数あるが、その前にsshコマンドの書式（これも複数あるけど）を確認しておく。
> ssh 接続先
これで普通のSSHログインになる（同じことをリモート接続先（ゲートウェイホスト）でもう一度やれば、他のホストにアクセスできる）。もし実行するのが単発コマンド（やセミコロンなどで繋いだ一連のコマンド）だけでシェルへのログインが必要ないなら
> ssh 接続先 コマンド
でよいのだが、このときSSHdはコマンドの戻り値しか返さない（> echo $?で確認）。標準入出力もリダイレクトさせるには、-tオプション（強制的に仮想端末を割り当てる、とmanには書いてあるが、ようするにローカルのttyをリモートのものに入れ替えてしまう＝手元のキーボードとディスプレイが、あたかもリモートマシンにつながったものであるかのように振舞う）を使って
> ssh -t 接続先 コマンド
とすれば、実行したコマンドの出力（本来接続先の標準出力に渡されるもの）を手元の端末に表示できる。もしcronなど自前のttyを持たない環境から実行する場合は-tt（ないし-t -t）としてやると、強制的に仮想端末があるかのように振舞える（/etc/sudoersでrequirettyを指定した環境でsudoするときなんかに使うそうな）。ということで、ゲートウェイにいったんログインして改めて接続先にログインするのではなく、一度にコマンドを打ってしまいたいときは
> ssh -t ゲートウェイ ssh 接続先
となる。またポートフォワードの場合、たとえば192.168.1.[1-4]まで順にリレーするならこんな感じ。
> ssh -t -L 1001:192.168.1.1:10002 192.168.1.2 ssh -t -L 1002:192.168.1.2:10003 192.168.1.3 ssh -t -L 1003:192.168.1.3:10004 192.168.1.4
-Lオプションをつけてもつけなくても、-tオプションでttyを前へ前へと送っていくのは変わらない。この2つの方法（ログイン2回と-tオプション）では、ゲートウェイに置いた秘密鍵や~/.ssh/configを使う。ゲートウェイ用と接続先用の両方の鍵を手元に置いておきたい場合は、ProxyCommandを使って、
> ssh -o ProxyCommand='ssh -W %h:%p ゲートウェイ' 接続先
とするか、同じ内容を~/.ssh/configに書く（ProxyCommandの引数になっているコマンド（太字部分）が接続を完了してから本来のコマンド（斜体部分）が実行されることに注意）。ProxyCommandは、引数のコマンド（プロセス）をプロクシにするオプションで、%h:%pには接続先のホストとポートが展開されて読み替えられる。-Wオプションはクライアント（この場合は手元の端末）の標準入出力を引数で指定した先に転送する（SSHdでAllowTcpForwarding=yesになっていないと使えない）。manによるとさらに「-N、-T、ExitOnForwardFailure、ClearAllForwardingsも指定したのと同じ」になるらしいから、ようするに入出力の転送以外はなにもするなという指示になる（はず）。ProxyCommandでは、ssh以外のプロセスに転送させることもできる（manには「ProxyCommand /usr/bin/nc -X connect -x 192.0.2.0:8080 %h %p」という例が示されている）。ひとつややこしいのは、秘密鍵や~/.ssh/configはゲートウェイ用と接続先用ともにローカルにあるものを使うが、接続先のIPアドレス（または名前）指定はゲートウェイ（というかSSH接続をイニシエイトするホスト）から見たものでなくてはならないということ。ポートフォワードの場合は、たとえば192.168.1.[1-4]まで順にリレーするなら、
> ssh -o ProxyCommand='ssh user2@192.168.1.2 -p 222 -L 221:192.168.1.4:224 -W %h:%p' user3@192.168.1.3 -p 223 -L 221:192.168.1.4:224
などとなる（太字＞斜体＞下線の順に処理される：1から、2につないで、3につないで、1のポートを4につなぐ）。1回目の-Lオプションがなにをしているのかよくわからない（他にも悩んでいる人がいた：https://neos21.net/blog/2019/11/08-01.html）のだが、見た目の感じでは、ClearAllForwardingsを相殺しているのかなという気がしないでもない（あてずっぽう）。一応、2段でいいならこんな感じになる。
> ssh -L 221:192.168.1.3:223 user2@192.168.1.2 -p 222
-Lオプションが「SSH接続をした後でポートも接続」という意味であることに注意。また上の書き方が（とくに何段もプロクシを噛ますときに）長ったらしいと感じるなら、
> ssh -J ゲートウェイ 接続先
とするとスッキリする（比較的新しいオプションらしい）。-Jオプションは-o ProxyJumpのショートカットで、ゲートウェイにsshポートフォワードをさせる（実装上は継ぎ足しであってトンネルの中にトンネルを重複させてはいないのだろうが、概念としてはssh over sshみたいなイメージなのだろうと思う、多分）。たとえば192.168.1.[1-4]まで順にリレーするなら、
> ssh 192.168.1.4 -J 192.168.0.2,192.168.0.3 -L 1234:192.168.0.4:5678
とカンマ区切りで足すだけでよい（~/.ssh/configに個々の接続を書いておけば）。以上はあくまで筆者の理解なのでどこまで正確かわからないが、とにかく、-tオプションだとゲートウェイの鍵が使われて、ProxyCommandはsshじゃないプロセスもプロクシにでき、ProxyJumpは書き方がスッキリする。なおControlPersistオプションはちょっと手ごわい（https://blog.kyanny.me/entry/2021/07/18/031231）ので筆者は使っていない。

Wake-On-LANが意外とメンドクサイ。BIOS（UEFI）の設定はまあ常識的なもので、スリープに落ちてもNICへの給電を続けるようにしておく。のだが、手元のマシンでは設定項目がなく、何もしなくてもWake-On-LANできるようになっていた（いざ動かないときに、ストレスフルだよねこういうの）。NICの設定は本当に紛らわしい。まず、デバイスマネージャのNIC（ネットワークアダプタ）のプロパティから電源の管理タブを開き「電力の節約のために、コンピューターでこのデバイスの電源をオフにできるようにする」という設定を有効にしなければならない。これはデバイスの電源管理を「高度化」するためのスイッチらしく、無効にするとスリープに入ったときNICの電源が完全に落ちてしまう。さらに、詳細設定タブで「Wake On Magic Packet」などの項目を有効にして、NIC自身がマジックパケットで起きる（もしくは受け取るという意味なのかも）ように設定。さらにさらに電源の管理タブに戻って「このデバイスで、コンピュータのスタンバイ状態を解除できるようにする」を有効にして初めてOS全体がWakeできる。もうひとつオマケに「Magic Packetでのみ、コンピュータのスタンバイ状態を解除できる」を有効にすると、おそらく、Wake On Pattern MatchやWake On Linkで起きなくなる（後者の誤作動が多いらしく、マジックパケットだけにしておくのを推奨する解説が多い）。余談だが筆者の環境では、電源オプション＞プラン設定の変更＞詳細な電源設定の変更にあるUSBのセレクティブサスペンデッドがデフォルトで有効になっており、USBキーボードからもスリープ復帰できずしばらく悩んだ。

マジックパケット（UDPでHxFFFFFFFFFFFFに続けてNICのMacアドレス16回：ポートは9が標準らしいがどこでもよい）を目的のホストに届かせる部分も面倒で、LANにブロードキャストする必要がある（でないと、ルーターのARPテーブルから目的のアドレスが消えてしまったときに届かない）。やり方は大きく分けて2通り。ひとつは、ルーターにマジックパケットを送って、ポートフォワードさせるパターン。これはルーターがブロードキャストのポートフォワードに対応していないとできない、が素直なやり方。もうひとつは、LAN内に何かしら「常に起きているホスト」を立てて中継させるパターン。これはさらに細かく分かれる。LAN内で常に起きているホストというと、真っ先に挙がるのがルーター自身である。マジックパケットを転送できない（orさせない）ルーターはたいてい、ルーター上にHTTPdを立ち上げて、ルーター「を」リモートコントロールしてマジックパケット送信させる機能を持っている。このとき、中継役のルーターがLANの根元にある必要はなく、LAN内にブロードキャストができる機種でさえあれば、ブリッジモードのサブルーターであってもよい（というか、ルーター自身へのポートフォワードを拒否する機種の場合、上位に親ルーターを置いてやらないとHTTPdがインターネットから見えない）。もちろん、常時起きているのならサブルーターではなく普通のホストでもいいわけで、LAN内にwebサーバやらmailサーバやら立てている場合は、そのサーバマシンを使うこともできる。ただしブロードキャストでパケットを飛ばす必要があるため、同じサブネットでかつDMZでないというのが条件。

中継役が普通のホストならさらに、インバウンド通信を待ち受けるのではなく、WANのどこかをポーリングしてトリガーが入ったらマジックパケットを飛ばす方法も可能になる。たとえばウェブサイトにCGIか何かで書き換えられるページを作っておき、中継ホストがそれを定期的に読みに行って、何かしらのMACアドレスが書いてあったらマジックパケットをブロードキャストする（dDNSの更新用スクリプトなんかが流用できると思う）。もっと頑張れば、マジックパケットだけでなく、SSHもポート開放せずに使えるはず（リモート操作の対象マシンが起きたらトリガー（リモート操作元のアドレスも書いておく）を読むように設定しておき、リモートされる側から接続させる：ただし今度はリモート接続元のホストにWAN経由で到達できる必要が出てくる）。しかしこれも、そこまでやるなら最初からスリープに落とさない運用でいいじゃないと言われると、ソッチの方が合理的な気がしないでもない。

結局、マジックパケットを届かせる部分はルーターの機種やLANの構成に左右されるため「これでよし」の方法がない。そしてどれを採用しても、せっかくSSHでセキュアにやっているのに、別の穴を開けるような形になって鈍臭い。ここはやはり、LAN内に常時稼動のホストを用意して、そこにSSH接続してマジックパケットを飛ばさせるのが正攻法に思える（もちろん、VNCもこのホストに中継させる：主目的が省エネの場合はホスト増やすとアレなんだろうけど、自宅設置で夏場の発熱対策のためにスリープさせるなら選択肢にはなると思う）。またWake-On-LANとはいうものの、ここでいう「LAN」はNICが介在する有線LANを想定しており、Wi-fi接続しかない場合は利用できないのが普通（WAN側wi-fi対応のサブルーターと、必要ならWake-On-LAN対応のUSB-NICを追加すればイケるけど）。無線LANだけで同じことをやりたい場合は、WoWLAN（Wake on Wireless LAN）という拡張された仕組み（とそれに対応したWi-fiアダプタ）が必要になり、とてもメンドクサイらしい。

なおマジックパケットを送る手段としては、FreeBSDならWOL(1)かWAKE(8)かWAKEONLAN(1)が使える。wakeonlanコマンドはLinuxなんかでも同じもの（どっちもperlスクリプトだけど中身が完全に同じなのかどうかは知らない）を使うようで、ether-wakeというコマンドを用意しているディストリビューションもあるようだが、詳細は調べていない。ただ、やることはヘッダとMacアドレスをAsciiのHex表記からビット列に変換して192.168.x.255に飛ばすだけなので、自前でスクリプトを書いている（またはwakeonlanあたりを改造して使っている）人も多いよう。Androidだと（Termuxでperlやrubyやpythonは動くものの）パケットを送るところがややこしそうだが、別途でマジックパケットを送るだけのGUIアプリがいくつか公開されている。

それにしても、電源関連は本当にメンドクサイ。大雑把にはACPIの稼働状態で表現され、S0が通常稼動、S1が省電力モード、S2でCPUへの給電が止まり、S3でチップセットへの給電が止まり、S4でデータを退避させてメモリへの給電が止まり、S5でソフト的に電源オフ状態になる。S1がスタンバイ、S2がサスペンド、S3がスリープ、S4がハイバネーションと呼ばれることもあるが、こともあるというだけでまったく確実でない。デバイスの状態（D-State）はD0の完全動作からD3の停止まで4段階。Windowsの場合、Win8で「シャットダウン」のデフォルト動作がクラシックシャットダウン（S5）からハイブリッドシャットダウン（S4）に入れ替わったらしく、ハイブリッドシャットダウンはWOLに応答しないが、休止（S4）なら起こすことができる（はずなのだが、手元ではシャットダウン状態からでもマジックパケットで起きる）。MacのハイブリッドスリープはS4とS3の中間くらいと説明されている例が多く、WinとMacともにスリープがS3相当（らしい）。

FreeBSDはサスペンドやハイバネーションが伝統的に弱く、2000年代に入っても苦戦する人が多かった模様（https://paperzz.com/doc/6515726/freebsd%E3%81%AB%E3%81%8A%E3%81%91%E3%82%8B-%E3%82%B5%E3%82%B9%E3%83%9A%E3%83%B3%E3%83%89%E3%83%BB%E3%83%AC%E3%82%B8%E3%83%A5%E3%83%BC%E3%83%A0%E3%81%AE%E4%BA%8B%E6%83%85とかhttp://vega.pgw.jp/~kabe/bsd/fb7-nosusp.htmlとか：20年代に入ってもhttps://running-dog.net/2021/05/post_2439.htmlとか）。もともと「ずっと起きてるホスト」志向が強く、サーバとして動かす人なんかはまったく必要としない機能だからなのだと思う。

どうにも、Androidの「シングルユーザー前提だけど自分はrootじゃない」という設計思想は、筆者みたいな使い方には不便に思える（というか、UIの中心にシェルがあって実行者の権限を切り替えながら動かすというUnix系のやり方が便利すぎる）。せめてPIN/パスワード/生体認証から2要素を選んで使えれば少しは安心なのだろうが、方法が見つからなかった（なんというかこの、ウェブサービスのログインなど都度Androidスマホを使わせたいところはゴリゴリに2要素認証を押してくるのに、根元にあるはずのAndroid本体の認証はぜんぜん省みられていないあたりが、実に未成熟かつ悪意に満ちているように感じられる：iCloudの方が酷いという意見には同意するにしても）。またこれは後から気付いたのだが、Androidには高性能なファイアーウォールが（筆者がざっと探してみた限り、特定の相手やポートや方向の通信だけ選んで通せるようなものは、サードパーティのアプリにも）なく、いわゆる3大キャリアを含む大多数のSIM（23年4月現在）はNAT越しにインターネット接続する仕様で、もちろんエンドユーザーはキャリアのルーターには触れない。そうすると、インターネット越しにインバウンドの通信を待ち受けるには、それが可能なホストをどこかに用意してリモートポートフォワードしてやる必要がある。さらに、Wi-fi接続をしているときは（ローカルルーターで許可していれば）LAN内のホストから端末のポートに直接アクセスできる（グローバルIPは持ったことがないので、どうなるのか知らない）。

そもそもモバイル機器をネットに繋ぐ手順自体が昔と違い、アクセスポイントとプロバイダがほとんど一体化していることが多い（ので、グローバルIPが欲しいときにプロバイダだけ替えるようなことができない）。うろ覚えだが、WS011SH（Advanced/W-ZERO3 [es]：アドエス）を使っていた頃は、W-SIMからAIR-EDGEのアクセスポイントにPPPダイヤルアップ、そこからプロバイダ（単体の場合はウィルコムのAIR-EDGE PHONEセンターも使える）を介してインターネットに接続していたのだと思う。現在のいわゆるテザリングは、インターネット接続されたスマートフォンが（モデムではなく）ローカルルーターとして振舞う。エンドユーザーの立場では、ローレベル層がW-OAMか4Gか5Gかとか、アクセスポイントを探すのに電話番号を使うかAPNを使うかなんてのは大きな問題ではないが、インターネットの向こう側や通信中のホストから自分が誰に見えているか、ローカルホストとの間に何台のルーターがあって誰がコントロールしているかというのは、ある程度押さえておかないと混乱の元だと思う。

うーむ、ますますローカルサーバが欲しくなってきたが、これはどうしたものか。ローカルサーバ＞あれば便利、普通のWindowsマシン＞1台は欲しい、既存のミドルタワー機＞レガシー機器のためにオフライン運用し続けたい、モバイル＞今使っているAndroidファブレットで十分な気がしてきた、FreeBSDデスクトップ＞必要かどうかでいえば必要ないけどKDE使いたい（のが目的ならUbuntuとかでもいいのかも：WSL2という仮想マシンでお手軽に動かせるようになったそうな）・・・ということは、ローカルサーバ用にミニパソコンを用意して、Win機に仮想環境立てるのが近い感じか。その場合、仮想化はWindowsのHyper-Vでやることになりそう。FreeBSDにもbhyveというモダンな（VT-xとEPTやAMD-VとNPTなどプロセッサの仮想化支援機能をゴリゴリ使い、LinuxのKVMのようにベースシステムとの融合が進んだ）ハイパーバイザー型の仮想化システムがあるのだが、WindowsはゲストOSとしてサポートされていない。Hyper-VにFreeBSDを入れる場合については、ちょっと調べたら詳しい解説が見つかった（https://qiita.com/nanorkyo/items/d33e1befd4eb9c004fcd）。こういう情報の探しやすさでは、FreeBSDは今なお（相対的に）最高の環境だと思う（いや、NetBSDの人たちとか、相変わらず濃いめの情報発信してるけど、あれはあれでまた別物というか）。

冷静に考えてみるとそもそも、筆者はどうやって現行Windowsをクリーンインストールするのか知らない（Win機を買ったとき、Windowsはプリインストールされていたがインストールメディアはついてこなかった：MSのサイトだかMicrosoftStoreだかから、ダウンロードで入手できるらしい）。これって凄いことだよなぁ。なんかパソコンじゃなくて携帯電話みたいなノリじゃないか。

ハードウェア関連に改めて触れておきたい。VNCによるリモートデスクトップは十分実用的で、17インチHDディスプレイ（1920*1080）に出していた画面を手元の6.5インチAndroidに飛ばすと、予想通り縦横各半分くらいまでが快適に使える限度だが、ピンチ動作で拡大縮小ができるため画面サイズは思ったほど気にならない。Windowsマシンの解像度を1280*720に落としてやるとさらに使い勝手がよくなり、Android（手元の機種はちょうど短辺が720dot）からでもフルスクリーンモードのアプリを操作できるし、別のWinからVNCでログインしたときに（ローカルのVNCクライアントを）フルスクリーンにしなくても画面の隅まで操作できる（クライアント側で画面サイズの要求もできるが、ネイティブでやった方が何かと便利だと思う）。

調子に乗ってLENTIONのCB-C13という、USB PDに対応したTypeCルートのハブも買ってみたのだが、さすがにフルサイズのキーボードを持ち歩く気にはならないので、これは家用になりそう。USB Power Deliveryは、充電元と充電先で情報交換しながら大電力を送ろうという仕組み（どちらかが非対応機器だと電流も電圧も増えないので、従来のUSB給電と同様に振舞う）。スマートフォン本体がPD非対応なせいか、給電ソケットにPD対応充電器を接続してもホスト役のスマートフォンは充電されない。給電ソケットにスマートフォンの純正充電器（5V2AのUSB給電）をつないでもホスト役のソケットには通電しないので、おそらくハブのところでも給電が遮断されているのだろう（クライアント役のソケットには、PD充電器からも純正充電器からも給電できる）。

このハブはTypeCルートなのでUSB On-The-Go（OTG）にも対応している。OTGは、ホストを固定せずに（というか普段USBクライアントとして使われるデバイス同士、たとえばウェブカメラとプリンターの間などで）接続を行うための規格で、スマートフォンをUSBホストであるかのように振舞わせたいときにも使われる。USB Type-Cが登場する前は、Micro-ABレセプタクルと、片方のプラグだけ4番ピン（ID）が5番ピン（GND）に落ちたケーブル（USBホストケーブル）を使って、短絡している側がホストになる約束で運用していたが、Type-CではUSB Type-Cポートコントローラー（レセプタクルのすぐ後ろにある物理的なIC）で動的に落とす落とさないを選択できるようになり、専用ケーブルは必要なくなった（というのが筆者の理解）。

現状で、スマートフォンからのリモートログインも耐え難いほどシンドいものではない。ただやはりマウススクロールと中クリックは使いたいのと、ドラッグ動作（普段あまり意識しないがWindowsの右ドラッグってけっこう便利）のスムーズさが意外と快適性に響くので、できるならハードウェアポインティングデバイスは使いたいところ（なにしろ操作対象がパソコンだからねぇ）。携帯性重視でbluetoothモデルを探してみたところ、エレコムのモバイルトラックボールM-MT1BRSBKとM-MT2BRSBK（単4*1本）、エレコムのハンディトラックボールM-RT1BRXBK（単4*2本：平面に置かず片手で持って使う）、サンワサプライの単品タッチパッド400-MABT128（充電式）、サンワサプライのリングマウス400-MABT156BK（充電式）、VRリモコンを名乗る片手用アナログスティックみたいな機種とbluetoothリモコンを名乗る下位機種っぽいもの、人差し指貫通のトラックボールマウス（ごろ寝マウス）タイプ、タッチパッドを片手用にしたようなエアマウス（空中マウス）タイプなど、けっこう面白そうなギミックが出ているよう。単に小さいマウスとしては、エレコムのM-CC2BRSシリーズとM-BT21BBシリーズのほか、折りたたみマウス（実際には「平らに伸ばせる」機能だけど）を名乗るものも複数メーカーが出している（サンワサプライのMA-BTIR116シリーズは生産終了になった模様：直販サイトには400-MABT1205Wが掲載されているが2023年4月末時点で本家サイトには紹介がない）。

他に面白そうなものとして、矢印キーつきの独立テンキーがある。モノとしてはサンワサプライのNT-BS1BKみたいなのが筆者の理想だが、残念ながらこれは有線。BluetoothのものではiCleverがKP10というのを出していて、見た感じにはまあまあ普通っぽい。サイズ感としては畳んだTK-FLP01と大差ないくらいで厚みの分コンパクト。Windows専用にするなら、num lockキーが使えるからもっとコンパクトな機種を選べるのだが、Macの事情がよくわかっていない（昔のMacにはnum lockあったんだけど、と思って探したらこんなページをみつけた、懐かしい：https://zariganitosh.hatenablog.jp/entry/20120706/num_lock）。テンキー側の仕様として、システムのNumLock機能と連動するものと、自機の中だけでキーを切り替えるものがあって、なおさらややこしい。なお、無線接続嫌いの（というか端末入力用としてはUSBも信用していないので、古いマシンではいまだにPS/2キーボードを使っている）筆者がBluetoothにこだわるのは、マルチペアリングが便利だというのもあるが、持ち運ぶときにコードが邪魔で断線もしやすいから。

別にフル機能のマウスでなくても、左手の指を2本くらい使って（たとえばFn1とFn2という仮のキーに割り当てたうえで）、Fn1＋タップで左クリック、Fn2＋タップで右クリック、Fn1＋Fn2＋タップで中クリックとか、その程度のサポートで十分なのだが（現在メジャーなリマップソフトのKey MapperとかButton Mapperなんかは、あくまでリマップメインでそこまでのことはできない模様：端末メーカーのカスタムで指紋認証デバイスを特殊キーとして使える機種はあるみたい）。というか、現状でスマートフォンの背面ってすごくムダだから、ボタンの2つや3つつけてくれてもバチは当たるまいに（と思う筆者は少数派の模様：みんなどうしてカバーかけたがるんだろなぁ）。軽く調べてみたら、ウェアラブルグローブ（ウェアラブルじゃないグローブってどんなだよ、とツッコまずにはいられない）とかいうギミックもあるようなのだが、ジェスチャー中心っぽい設計思想のものが多く、筆者が考えるようなごく単純な機能のものは探せなかった。Android14で入力機器を大幅見直しする予定はあるそうな。

結局、キーボードはTK-FLP01がそれなりの落としどころっぽく、今すぐ乗り換えたい候補はない。マウスはbVNCの機能で（スクロールアップ/ダウンの感度がよすぎるのをホスト側の設定でカバーすれば）なんとかならなくはないが、マウス（かポインティングデバイス）を外付けして普通にポインタで操作した方がラクなのは間違いない。リモートホストがWindowsの場合、タスクバー（Win10の頃は上下左右に動かせたのに、Win11になってレジストリをイジらないと動かせなくなった）が下にある関係でmultiVNCの3ボタンモードは常用しにくく、タップモードやbVNCを使うにしても真ん中下の拡大縮小ボタンとソフトウェアキーボード表示ボタンは消えないので、Winのタスクバーを左寄せにしておいた方が無難（上でもいいけど）。

ひとまず、AndroidからVNC over SSHでWindowsにインターネット越しでリモートログインする環境はできた（dDNSないからIP手打ちだけど）。後から気付いたのだが、bVNCもmultiVNCも自前でssh機能を持っている。だからCUIシェルから> ssl -L とかやる必要はなかった（今更）ようなのだが、考えてみるとこれ秘密鍵が大変そう。BSDsやLinuxではファイル管理は「ユーザー」が基準で、操作しているのが同じ人であれば（というか権限が同じなら）どのアプリケーションからも同じファイルを開ける。しかしAndroidは（G様の特権アプリ以外）すべてのアプリがjailされたような動き方をするので、もし3種類のアプリで秘密鍵を使いたいなら、3箇所に3つの鍵を置く必要がある。いやー、これはメンドクサイし効率が悪い（みんな鍵交換のときどうしてるんだろうね：3種類の別の鍵を置くのがいいのか、同じものを3つにコピーするのがいいのかも、一長一短に見える）。

ワークアラウンドとしてはまあ、sshはTermuxに任せて、VNCアプリは鍵だの何だの気にしないで接続だけやってもらうような使い方が妥当そうに見える。bVNCは鍵の管理までガッチリサポートしてくれるようなのだが、multiVNCは何しろ軽いので物理マウスがあるときには使いたいし、リモートマシンをCUIで使いたいとき（あまりないとは思うけど）は間にVNCを噛ますよりTermuxからsshログインした方が間違いなく早い。折衷案として見つけたのがConnectBotというsshマネージャー（Unix系の環境なら、sshuttleというもっと本格的なプロクシがある模様）。単にTermuxを使うのと比べると、ターミナルとしての使い勝手が劣るのがデメリット（まあ筆者の場合、WinのCUIシェルでやる作業なんてたかが知れてるけど）、接続をキープアライブ（接続ごとの設定ではなくアプリ全体の設定なので注意）してくれたり、アプリを終了するまでの間パスフレーズを覚えておいてくれたり（切断してもアプリが起きたままなら大丈夫）するのがメリットになる。鍵は普通に（Androidにログインできさえすれば触れる場所に）持たなければならないが、これがTermuxにchrootしなくては見えないところになったとしても、セキュリティに大差はないと思う。なおTermuxの~/strageは親プロセス（シェルに見えるモノ）からしか見えないようで、sshなどの子プロセスからはアクセスできない（のだと思う：実行権限によって「絶対」パス（というかroot）が変わるのは不便だが、そこがTermuxの軽さの源なのだろうからしゃあない）。外部ストレージ（~/strage/external-1/以下）にハードリンクを作ろうとしてもcross-drive linkだと言われて拒否されるし、シンボリックリンクを張ろうとしてもOperation not permittedで失敗する。

ついでなのでRDPも試してみたところ、VNCよりも軽い。サーバ（操作される）側はWindows標準のリモートデスクトップ、クライアント（操作する側のAndroid）ではaRDPというアプリケーションを使った（bVNCと同じIordan Iordanov (Undatech)のプロダクト）。aRDPはpro版なら音声転送にも対応しており、リモートされるWindowsのグループポリシーエディタ（gpedit.msc）で、\Windows コンポーネント\リモート デスクトップ サービス\リモート デスクトップ セッション ホスト\デバイスとリソースのリダイレクト\オーディオおよびビデオ再生リダイレクトを許可するを有効にするとリダイレクトできるらしいのだが、オーディオデバイスを使うのにレジストリの「HKEY_CLASSES_ROOT\AudioEngine\AudioProcessingObjects」以下で許可を設定する必要があるそうで、メンドクサイので試していない（手元ではWindows同士のRDPだと音声も飛んでたけど、何か設定したかどうか記憶が定かでない：必要性があるかどうかはともかく、VNCにも、ごく一部に音声を転送できるモノがあり、たとえ機能がなくても音声だけボイスチャットで送るワークアラウンドがある）。

Windows同士のRDP接続でクライアントに「リモートデスクトップ接続」を使っているなら、ファイル転送も（クライアント側の設定で）可能なのだが、samba（リモート接続先の445番ポートにSSHでローカルポートフォワードしてやればよい）の方が手軽だしパフォーマンスもよいので、ムリにRDPで送る必要はない。SSHさえ繋がっていれば、FTP over SSHという手もあるし、SCPも使える（しかしまあ結局は、sambaが手軽というか、Cx File Explorerが偉大すぎると思う：sambaやFTPやSFTPのほか、HTTPベースのWebDAVにも対応している）。クラウドストレージを使うという方法もあるのかもしれないが・・・自分が管理してるホスト同士でファイル交換するのに、わざわざWANにファイルを出す必要性がないよねぇ。地震とか落雷とか火災とか洪水なんかで自宅が壊滅したときにデータが助かるというのは、まあわかるっちゃわかるけど、だったら外部記憶装置にバックアップ取って実家にでも郵送しときゃよさそう。

VNCとRDPで比べると、接続先がWindowsならRDPの方が軽くて多機能ではあるのだが、RDPはWindowsアカウントと結びついている（RDPで接続するとWindowsでログイン、切断するとWindowsでログアウトになる）のが面倒で、たとえば重い作業をやらせるときに最初と最後だけリモートするような使い方ができない（わけではないが制限がありメンドクサイ）。

SSHの鍵交換でドハマリしたので追記：

改行コードやらUTFのBOMやらは、PowerShellで

> ssh-keygen -t ed25519
>>> C:\ProgramData\ssh\authorized_keys
（またはC:\ProgramData\ssh\administrators_authorized_keys）

> icacls.exe "パス" /inheritance:r /grant "Administrators:F" /grant "SYSTEM:F"

AuthorizedKeysFile .ssh/authorized_keys
（略）
AuthorizedKeysFile __PROGRAMDATA__/ssh/administrators_authorized_keys

しばらくほったらかしていたリモートデスクトップだが、諸事情で使う必要が出てきた。最終目的は出先のMacに自宅のWindowsからログインすることなのだが、イキナリ出先でMacをイジってもラチがあかなさそうなので、まずは手元のAndroidからWindowsへのリモート接続を確立して、出先で自宅のWindowsを操作しながらMacの設定をしたい、と目論んでいる（3時間では往復できない距離なので）。WinでもMacでもと考えるとVNCが妥当そうで、Windows用には定番のultraVNC、Android用にはbVNCというオープンソースソフトウェアを選んだ。Androidの環境は結局、Termux＋Blutoothキーボード（＋hacker's keybord）に落ち着いている。

Termuxの使い勝手は気に入っており、あえて難を挙げるとしても > pkg update に時間がかかるくらい（upgradeはすぐ終わる）、それもテキトーな空き時間にやれば苦にはならない。キーボードも、今使っているTK-FLP01で（さすがにフルサイズと同じようには使えないし、やっぱりBの位置が気にはなるが）大きな不満はない。ultraVNCは素晴らしい性能で、repeaterという面白い機能がある。これはリモートに建てたHTTPdを経由してwebminみたいなノリでブラウザからリモートマシンを操作してしまうというモノで、今回はSSHを使うため不要だし、オリジナルのアイディアがどこのものなのか知らないが、よく考えたと思う。VNCクライアントは優秀なものが他にもあり、bVNCと比べると、AVNCは多機能で簡潔操作（ツールバーが端スワイプで出てくるのに戸惑うくらい）だが重く、multiVNCは軽いがマウス周りの機能がやや非力（ただこのソフトが採用している3ボタンナビゲーション風のクリックボタンは面白いアイディアで、ホイールスクロールさえ何とかなれば有望そうではある）。筆者の環境は貧弱なのでbVNCでもけっこう重く、他の2つもインストールだけはしてある。

必要な通信は、ローカルWin＞VNCクライアント＞SSH＞（インターネット）＞SSHd＞VNCサーバ＞リモートMac。SSHセッションをずっとkeep aliveにできるならリモートポートを空ける必要がないのだが、それだとセッションが切れたとき再接続できなくなってしまう。だから結局、リモートサイトのグローバルIPアドレスがわかること（固定IPでなければdDNSを使うことになる）、リモートMacのローカルIPを固定するか名前解決できるようにすること、リモートルーターでSSHdの待ち受けポートを開けること、リモートルーターでNAT（というかIPマスカレードというかポートフォワーディング）を設定すること、リモートMacにSSHdとVNCサーバが常時立ち上がっていること、ローカルWinに秘密鍵・リモートMacに公開鍵を置いてSSHセッションを確立すること、ローカルSSHからローカルポートフォワードでトンネルを作ることが必要になる。この中で毎回作業が必要なのは（VNCクライアントの立ち上げを除けば）SSH部分だけなので、
ssh -L localhost:port:remotehost:port
とかなんとか書いたシェルスクリプト（かバッチファイル：令和の時代にんなモン書くことになるとは思わなかったけど）でも用意しておけば手間を減らせる（サンブルは後で）。リモートMacで必要な設定は、システム環境設定＞共有＞画面共有など、システム環境設定＞省エネルギー＞ネットワークアクセスによるスリープ解除（シャットダウンではなくスリープさせる運用になるが、今回そこは問題なかった）。ディスプレイの色設定で問題が出る（ローカルの設定がハイファイでないとMacに拒否される）こともあるようだが、普通の環境なら問題なかろう。ログインパスワードは使わず、SSHの公開鍵認証を使うのが無難だろう。これまた心底どうでもいい余談ではあるが、今回サブマシンにVNCを導入したことで、2台づつ接続していた有線のマウスとキーボードがワンセットで済むようになった。今更過ぎて自分でも呆れるが、とてもスッキリしたのでよしとしておきたい。

まずはAndroidをクライアント（接続元）、Windowsをホスト（接続先）にしてSSH接続を試してみる。Windowsにもいつのバージョンからか「OpenSSHサーバー」が標準搭載されるようになったが、設定＞アプリ＞オプション機能で有効化しなければならない。これがまたクセモノで、BSDsやLinuxなら/etc/ssh/ssh_configを設定して~/.ssh/に公開鍵を置けばそれでいいのだが、WinだとC:\ProgramData\ssh\に設定を置くようになっており、すると公開鍵に「どのユーザーの鍵なのか」という情報を付加する必要が出てくる。公開鍵の最後に「ユーザー名@ホスト名」をつければいいようなのだが、筆者はこれでハマった。Win上のPowerShellから > ssh-keygen -t ed25519 とかなんとかやって、秘密鍵の方をクライアントに持っていくのがワークアラウンド（上の記事を参照）になるが、これだとPuttyは受け付けてくれなかった（秘密鍵の書式が独特なので：もしかしたらなんとかできるのかもしれないが、WinからWinへのSSHは今のところ必要ないので無視した）。Termuxの方では、ssh-agentが教えてくれる環境変数をシェルに設定しないとshh-addが「could not open a connection to your authentication agent」というエラーで止まるという都合があって、.cshrcに「eval `/data/data/com.termux/files/usr/bin/ssh-agent`」を追記し、

#! /data/data/com.termux/files/usr/bin/tcsh
/data/data/com.termux/files/usr/bin/ssh-add ~/.ssh/秘密鍵の名前

設定名
HostName アドレス
User ユーザー名
IdentityFile 秘密鍵ファイル

#! /data/data/com.termux/files/usr/bin/tcsh
eval `/data/data/com.termux/files/usr/bin/ssh-agent`
/data/data/com.termux/files/usr/bin/ssh-add ~/.ssh/秘密鍵の名前
ssh -L localhost:123456:192.168.123.456:123456 設定名

最近、Macを使う必要が出てきた。いやしかしこれはなかなか慣れない。筆者の場合、漢字Talk7～OS9くらいまでの間は（Windowsほどではないが、おそらくUnix系のマシンよりは）頻繁に使っていたのだが、ブランクが長すぎたのか苦労することが多い。一番大変なのがファイラー（ファインダー）で、ディレクトリツリーを無視した（というか意識させないようにした）構成がかえって不便に感じる。思えばAndroidのファイラーもこういうフィールのものが多いし、Winのエクスプローラーもそういう傾向が強まっており、筆者にとっては大変悩ましい。もうひとつ苦戦しているのが文字入力で、日本語と直接入力の切り替えがグローバルなのはまあそういう文化なのかと納得するとしても、IMEは正直「ことえり」の方がマシだった気がしてならない（バージョンYosemiteのときにJapaneseIMというオリジナルのエンジンに変わったらしい：一瞬だけcannaを採用していたこともある）。

それから、いいのか悪いのかはわからないが戸惑ったこととして、GUIのMacにはtouch（相当の機能）がない。BSDsに限らず、Unix系のシステムでrootをやっている人たちは普通、

# cd ~/.myconf/
# touch important.conf
# chmod 0600 important.conf
# myeditor important.conf
# cp important.conf /etc/mydaemon/

自分で使ってみようという気はないけれど、調べてみて「へー」と思ったソフトウェアたち。

DebianベースのLinuxにQ4OSとMX Linuxというのがあるらしい。紹介記事を見ただけの印象だと、Q4はWinXPアゲインみたいなノリの軽量級、MXはGUIに寄せて軽さはほどほど、といった印象。

Discordという、IRCにボイスチャットを乗っけたようなサービスも人気らしい。どーも、最初（サービス開始は2015年だそう）はゲーム用みたいな扱いだったのが、2020年にビデオ会議機能がついて他用途での利用が加速したみたい。筆者の周りでも「Lineとか煩わしいしIRCの方が便利だったよね」という声はあったが、こんな安直な形で代替サービスが広まるとは思わなかった。

Mastodonという分散型のクローズドSNSがあって、Twitterから溢れ出たユーザーの受け皿になっているらしい（有名なクライアントにTusky for Mastodonなどがある）。分散型というのは、サービス全体が「野良サーバの集合体」みたいな構造になっており、サーバ同士の連携（アクセスの許可拒否など）で横断的なアクセスを実現している模様。日本だと、ニコニコ（古くから有名なサーバの管理者がドワンゴに入社したのがキッカケらしい）やpixiv、海外ではウェブブラウザのVivaldi TechnologiesなんかがMastodonサーバ（なぜか知らないが、サーバのことをインスタンスと呼ぶのが公式なんだそうな）を立ち上げている。でさらにその上にかぶさるように、Fediverseというプロトコル群があって、GNU socialやWordPressなんかとも連携が取れるそうな。

TermuxにTmux（名前は似てるけどまったく別のソフト）というのを入れている人が多いらしい。どうもこれ、FreeBSD（最初から仮想コンソールで動いてる）でAlt+F1～F8とかやる機能にレジュームなんかを追加したものみたい。

調べてみて愕然としたのだが・・・Androidにはメーラーがない。いや、ビルトインでGmailは使えるのだが、筆者がイメージする「メーラー」ってのはPOPとSMTPが話せてローカルディスクにメールを溜めてくれるモノであって、あんなごちゃごちゃしたものは使いたくない（ThunderbirdのAndroid版と言われるK-5も入れてはみたが、Gmailと大差があるようには感じなかった）。しかもなんと、Termuxにも> mailがない（pkgにもない）。いやー、そういうモンなのか。調べてみたところmsmtpというソフトでSMTPはできるらしいが、単純にPOPサーバとお話してメールの中身をもらってくれるソフト（maildirに記録しておいて欲しいけど、最悪標準出力でもいい）は見つけられなかった。perlとかpythonで動くものならきっとあるんだろうけど、いやー驚いた。

スマートフォンの入出力についてまた少し（ぜんぜんBSDの話題にならんなぁ）。メインにしているエレコムのTK-FLP01は、CUIやテキストエディタの入力が断然ラクではあるが、やはり持ち歩くにはデカいのと、アプリによってはハードウェアキーボードの使い勝手が悪いものがあり、活躍の機会が減っている。一番ストレスになっているのは予測変換で、カーソルキーで候補を選ばなくてはならないのは仕方ないとしても、物理キーボードで入力していると予測変換候補が邪魔なところに出てくるアプリがある。LINEなんかは最悪で、今打っている文字の上に変換候補を被せてくる。筆者はover the spot（入力中の文字列が既存文字列の上に被さる：長い文章を編集しているときでも、いちいち文字がずれることなく編集できる）派だが、ブラウザのテキストボックスなんかがon the spot（入力中の文字列が既存文字列に順次割り込む）になっていても気にせず使うし、ワープロでタイピングを覚えた世代なのでoff the spot（ウィンドウ内の別の場所で変換してから本文に反映させる：同じことを別窓でやるのをとくにroot Windowということがある）でもガマンはできるが、目隠しされるのはどうにも不便でならない。その点、閲覧用のメインで使っているcxのテキストエディタや編集用のメインで使っているsimple text editorは優秀で、どちらも入力自体はon the spot、予測変換をbelow the spot（入力中の文字列が入力箇所のすぐ下：ただし候補が多くページ移動するとcxは表示が被さる）で出してくれる。

スマートフォンを平らなところに置いたときにスクリーンのオートローテーションが誤作動する問題は意外とアッサリ解決した。オートローテーションを無効にしていても「回転ボタン」なる（とっても地味な）ボタンが3ボタンナビゲーションの右端に出てきて、手動ローテーションできる。しかしこれ、加速度センサーでやってるんだろうから、切り替えの閾値だけ設定させてくれれば、オートローテーションのままでも不自由なく使えそうな気がしてならない（回転制御アプリなんかもあるようだが、単にオートローテーションを無効化する以上の便利さを得られそうなものは見つからなかった）。TK-FLP01のケーススタンドに立てかけたとき、ナビゲーションボタン（3ボタンナビゲーションを使っている）がスタンドのヘリにかかってしまうのももどかしい。画面狭くなってもいいから、ボタンの位置をもうちょっと上にあげられないものか。スマートフォンは手に持って使うものと、ハードもソフトも決めてかかっているのはしゃあないとして、もう少し簡単にイジりたいところをイジれれば、少数派もここまで不便な思いをしなくて済むんじゃないかなぁ（まあ難しいのかもね、昔の「パソコン」みたいにはいかないだろうし）。

キーボードのデカさについては、ちょっと面白そうな案を見つけた。思えば筆者はアドエスのキーボードを大変便利に使っていたわけで、親指タイプもそう不便ではないんじゃないのと思いスマートフォンサイズ（7*15cmくらい）のキーボードを探してみたところ、エアリア（area）というブランドでSD-KB24GBTという機種があった。サイズは「15.5 x 8.9 x 1.6 cm」でちょっとデカいものの、ストレスフルだった「画面をタッチさせられる問題」に（出来がどうなのかはまったく知らないが）上半分に配置されたタッチパッドが回答を出してくれている。キーもちゃんとズラし配列で、端のキーを横長に取ってあり、音引きや「ろ」キーや鍵括弧の位置にも苦心の跡が見て取れる（写真を見る限りFn+EnterにCtrl+Alt+Delが割り当てられているようだが、これはお茶目とかではなくロールオーバーの問題なのかも）。サイズもネックになるほどはデカくないというか、親指は太いため爪で押す感じになりやすく、一般的にはもう少し小さい方がよさそうな気もするが、幸い筆者は手がデカく、このくらいでもまあ不便ではなさそう。この手の機種はドングル付きの2.4GHzワイヤレスばっかりが並ぶ中、SD-KB24GBTはBluetoothとの両対応なのだそう。ただまぁ・・・ケースに入れたTK-FLP01と比べても、短辺が1cmくらい短く厚さが5mmくらい薄いだけなので、買い換えてまで使いたいかというと・・・10本指タイプの快適さは他と比べられないし、なんだかんだ言って便利なのよねあのケース。

余談だが、上で触れたエアリアという会社は、この手のベンダーには珍しく、公式サイトでちゃんとした商品説明（https://www.area-powers.jp/product/others/4580127694994/）をしており、キーのテスト結果も（OSのバージョンは古いが）掲載している。主力っぽいインターフェースカードやインターフェースアダプタのほか、紙とペンタブレットを融合させた「アナログデジタルノート KOJIRO」という面白デバイスも扱っているらしい。もうひとつ（まったく欲しくはないが）面白いと思った製品にスリーイー（3E）というブランドの3E-BKY6というキーボードがあって、これはなんと縦に折り畳める。そんなことができて何が嬉しいのかいまひとつピンとこないものの、とにかく畳むと4.5*20cmくらいになる（6.5インチスマートフォンと合わせるなら長辺が長いし、8インチタブレットと合わせるなら畳まないサイズのままで十分な気がするのだが）。この会社も商品説明が比較的親切で、キー配列にコダワリがあるみたい。

QWERTYとフリック以外の入力法を眺めていたところ、Gboadで使えるゴダン入力というのが便利なことに気付いた。ゴダンはおそらく五段の意で「フリックでローマ字入力」するようなイメージ（母音5種と子音9種を5段3列の15マスに並べ、濁音や記号などをフリックで補う：残り1つのキーは中央下で可変キーになる）。筆者の場合、横画面ならQWERTYの仮想キーボードの方が速いし（少なくともhacker's keybordなら）確実だが、縦画面ではやはりキー数の少なさが強く、トグル入力（ガラケー式）や普通のフリックと比べてもスムーズにできた。ということで入力方法の選択を見直して、縦画面日本語用にGboadのゴダン、横画面にしたらQWERTYに差し替わるように設定、英語は横画面ならhacker's keybordが変わらずファーストチョイスだが、縦画面ではGboadの英語キーボード（PC配列）でグライド入力を有効にした。現在のバージョンのGboadでは長押しがグライドよりも優先されるので、長押し判定基準を450msと遅くしてある（ちなみにhacker's keybordでは240ms）。

ぶっちゃけ、縦画面の英語入力はどれでもいいというか、日本語を入力しながら途中に英単語が出てきたくらいなら、日本語キーボードを3ステートモードで使っても間に合うのだろうが、数字モードを挟み3ステップでトグルさせるのがかったるいのと、グライド入力がそれなりに使えそうな感じだったので、とりあえず入れてみた格好。横画面での日本語入力も（縦画面でそれなりの入力が可能になったおかげで）重要度が下がっており、物理キーボードを使うほどではないがゴダンではかったるい、という微妙な作業だけこなせればよくなったため、かなり気楽になった。

いわゆるDeGoogle（脱グーグル：2022年8月現在、WikipediaEN（となぜかペルシャ語）には記載があるので、それなりに一般的な語ではあるのだろう）を検討している。といっても、完全脱却を目指すつもりはなく、あまりにもうっとおしいものから距離を置ければそれでよい。下で触れたように、FreeBSDが入っていたサーバマシンが壊れて以来、デスクトップ用のWindowsと、後から導入したAndroidスマートフォンでやりくりしている。

まずは検索。google的にはここが本命本丸のはずだが、世界中のspamerに狙われ続けているハンデが大きいのか、DuckDuckGoの品質がそれなりに上がってきているのもあって、少なくとも一強状態ではなくなったように感じる（ちょうど、ふた昔くらい前のMSが世界中のクラッカーに狙われるハンデを背負っていたことが思い出される：Search Console導入の動機のひとつとして誘導サイトの大量複製を食い止めたいという目論見がおそらくあったのだろうし、フィルタバブルを反対側から見ればユーザーをspamから守る手段がそれしかなくなったのだとも受け取れる）。とりあえず筆者は、googleとDuckDuckGoの2本立てにして、都度選べるようにしておいた。少し使ってみた感じでは、普通のウェブ検索ならDuckDuckGoがファーストチョイスで、結果に不満があるときやニュース検索など特殊な探し方をしたいときにGoogleを使う形になりそう。

ブラウザは、Windows用にvivaldiというのを入れてみた（Chromiumベースで、Chromeウェブストアの拡張機能にも対応したブラウザが、DeGoogleツールになるとはなんとも皮肉）。筆者の主観だとChromeよりは快適だが、firefoxと入れ替えるほどではないかなと感じる（トシなので慣れを捨てるコストがデカいのも、あまり気持ちよく認められることではないが、きっと影響しているのだろう：以前Mozillaが激重だった頃、半年くらいだがOperaを常用していたことがあるので、雰囲気自体にぜんぜん馴染めないというほどではない）。Android版も試してみたが、こちらはChromeと同じくらいうっとおしく、firefoxの圧勝に終わった。

メールは・・・べつにGmailでいいというか、ウェブメールなんて何を使っても大差ないというか、ローカルで動かしていたpostfixの後釜をどうするかが優先課題で、それ次第で他を考えるしかなさそう。それに、各種Web認証の類でどうせGmailは使わされるわけだから、雑用アドレスとしても使い回した方が効率がいい。地図はOpenStreetMapのものが使いやすく、LeafletというJavaScriptライブラリを使って複数地点をマークアップできるサイトなんかもある。
https://tizu.cyou/sirusiizu/
ただこれも、双方に一長一短があるので当面は併用し、ファーストチョイスはGoogleMapにする予定。カレンダーは、Win上では昔（たぶん15年くらいは前）から使っている常駐アプリがあるものの、スマートフォンと連携しようという意思はまったくない。いちおうAndroid環境にもMinCal Widgetというウィジェットタイプを入れてみたが、パーミッションか何かの設定（覚えてない）をしたあと設定画面を開けなくなった（曜日と日付は表示できているので、筆者には何の不満もない）。コンタクトリストはもともとcsvで管理しており、Windows上で編集すれば何の問題もなく、仮にスマートフォンからイジるとしてもテキストエディタとperlがあるので、csvエディタがぜひ欲しいとは思わない。Officeスイートは、Windows用ならapacheで間に合っているし、一応android用にCollabora Officeというのもあるようだけど・・・要らんよねぇスマートフォンにオフィススイート（PDFは、デフォルトでDrive PDF readerとかいうgoogle製のリーダーが入ってたらしく、普通に読める）。

こう考えてみると、そんなに頑張らなくてもよさそうな感じ。

GoogleのアプリケーションやAPIをまとめたものにGoogle Mobile Service（公式サイト曰く「Android オープンソース プロジェクト（AOSP）ではメールや電話といった端末レベルの一般的な機能を提供していますが、GMS は AOSP には含まれていません」だそうな：ファーウェイがアメリカで制裁を受けたときにHuawei Mobile Serviceという代替ソフトを出したらしい）とGoogle Play Services（これ自体が「Google Playのアプリ」として配布されており、日本語だとなぜか「Google Play開発者サービス」という意味のわからない訳語が当てられている：microGという代替プロジェクトがあるそうな）がある。名前からして前者の方がローレベルな印象を受けるが、後者がサブセットであるかのような説明もあって、違いがよくわからない。Google検索が（おそらくは筆者自身も）元気だった頃は、こういう情報も探せば見つかったものだし、今だって詳しい情報発信をしている人はきっといるのだろうが。

自宅環境にsshで繋いでXを飛ばす環境を作れないかなぁ、と企んでいるので、端末（入出力装置のセット）としてのスマートフォン/タブレット/ノートPCについて、もう少し考えてみたい（ただこれねぇ、ハードウェアも難しいけど日本語入力がネックになることもあって、やってみないとわからんトコがあるのよねぇ）。パソコンの普及品ディスプレイでよくある、24インチのフルHD（物理ピクセル1920*1080、アスペクト比16：9、画面サイズ53.1*29.9cm、91ppiちょっと）を基準に、デスクトップ画面をリモートから操作することを想定してみる。筆者の習慣に過ぎないが、最大化しないウィンドウは25*15cmくらい（タテヨコ半分）のサイズで使うことが多い。一方キーボードは、手元のデスクトップ用（ミツミ製）の「タブからエンターまで*5列」をメジャーで雑に採寸したところ、キートップ部分で280*95mm、キー枠部分で288*100mmくらいだった（ストロークは4mmが（「深め」と表現されることもあるが実際上）普通みたい）。そこに外枠（5mmだとしてタテヨコ各10mm）と、Fキーを追加して6列にするなら縦がもう10mmくらい伸びる（カーソルキーはスペースキーの列、DelキーはFキーの列に繰り入れ、Endキーなどは削ってしまうてしまう機種が多い：いわゆる87キー）。この数字から考えると、297*120mm（だいたい30*12cm）くらいが、19mmピッチ6列キーボードの限界近いサイズだとわかる。ポインティングデバイスは、タブレット（だとしてもホームポジションのままポイントできるならメリットあると思うんだけど）を意識しているせいなのか、コンパクト系の無線機種に内蔵されている例はまれ。テンキーは、必要になったら別付けすればいいだろう（テンキーだけ膝の上とか、レイアウトが自由になるので）。

実際の単体キーボードでは、ロジクールのMX KEYS MINIが295.99*131.95mm（タテは突起物があるので、実質29.6*12cmくらい）、操作性を妥協せずに作るとこのくらいになるのだろう（よくわかんないメディアキーじゃなく、Home/EndキーとUp/Downキーを上に置いてくれれば、実用的な製品になっただろうに）。パームレストがないポインティングデバイス一体型機種だと、たとえばThinkPad トラックポイント キーボード IIの日本語モデルが305.5*164mm（キーの配列と取捨選択はさすが）。トラックボール内蔵のものは、有線モデルだがサンワサプライのSKB-TR05が291*179mmでSKB-TR03が303*159mm（同じく有線モデルのSKB-TP01は291*197mmで13.3インチノートPCと似たようなサイズ、というかキーボード部分をそっくり外したような見た目）。折り畳みキーボードは（横が30/2で15cmとすると、縦は10cmくらいにしたいらしく）縦方向に狭いものが目立ち、どうせ縦に狭いならと横のピッチも相応にしてスペースを他（切り替えスイッチなど）に使っているものもある。ワンサイズ上げてかつ折り畳みの製品は、オウルテックのOWL-BTKB7801（US配列の78キー）が展開時291*120*13mmの折り畳み時166*120*15mm、EWINのEW-AM022は「フルサイズ」がウリで展開時342*115*11mm（タッチパッドつき）で折り畳み時182*115*19mm。なお、折り畳みキーボードの「2つ折り」「3つ折り」は折り目が1箇所か2箇所かだけの違いで、3つ折り機種でも横幅が3分の1になるわけではない（ただ、テンキーレスでも記号キーの分右手範囲のキーがより多く、2つ折だと左端に余白ができてしまいがちになる：フルサイズキーボードの文字キー部分だけとか、HHKの60キーモデルなんかだと、YとUの間＝7の真ん中くらいが中央になる）。以前は、山陽トランスポート（イーサプライ）のEEA-YW0499や、もとpalm用だったらしいThink OutsideのSTBT01や、サンコーの有線モデル「USB折り畳み式ミニキーボード」など、本当に4つ折りできる（13*9*2cmくらいになる）機種があったが、2022年夏に筆者が探した限り現行品は見つからなかった（極限コンパクト収納というよりは、広げたときに大サイズになるのがウリだった模様）。

お次は画面の話。Android系デバイスの場合dip（density-independent pixels：密度非依存ピクセル）という値を使うことが多く、ざっくりといえば、物理密度をクラス分けしてクラスごとに倍率（CSSピクセルでいうデバイスピクセル比みたいなもの）を掛けてやり、表示されたときの物理サイズを大まかに決め打ちできるようにしてある。しかしこれはデザインする側の事情であって、エンドユーザーの使い勝手を決めるのは結局物理サイズである（パソコンディスプレイと比較すると2倍以上のピクセル密度はほぼ間違いなくあるので、距離が半分だったとしても解像度は余裕で足りる）。また画面を本体サイズいっぱいにする技術にも左右されるが、物理的な横幅の上限を3インチ（7.62cm）とするなら、画面幅は7cmくらいまでが限度だろうから、アスペクト比16：9のままだと5.6インチくらい（画面側にカメラとかUBS端子とかつけなかったとしても縦13cmくらい）、縦長にして20：9でも6.7インチくらい（同様に縦16cmちょい）が上限になる。ここの苦しさがあるので、7インチファブレット（下で触れたように最大でも17.5*8cmくらい）と8インチタブレット（19*13cmくらい：フルHDだとして画面サイズ17.7*10.0cmくらい）のサイズ感はかなり違う。職場で使っている8インチタブレットの画面は、x端末にしてどうかは別として、タブレット出力としてはそこそこ不満なく（というかスマートフォンの互換品としてより快適に）使えている。画面出力をモバイルに合わせて、電話機能は別機種に任せ、折り畳みキーボードもいいのが探せたらという条件付ではあるが、これは選択肢になるのかもしれない。追記：アップルが「超ビッグ」と称して160.8*78.1*7.80mmのiPhone14plusを出した。

細かい事情はさておき、じゃあどのくらいの物理サイズが欲しいかというのは個人差があるが、筆者の場合、たとえばパソコンでフルスクリーン表示していた地図（文字と図形が両方書き込まれた画面の例として挙げただけで、他意はない）を6.5インチのスマートフォンで見るなら、タテヨコ各2倍くらいには拡大したい（この辺の事情を汲んだのか、cxの内蔵画像ビューアは2倍くらいのズームに対応していて、たいへんありがたい）。タテヨコ半分のウィンドウで見ていた画面なら、ズームなしでも（縦に少し狭くして、かつソフトウェアキーボードとか出てこなければ、操作せずにただ見る分には）それなりに見られる。まあ、ノートPCが13.3インチ/15.6インチ/17.3インチで住み分けしてるくらいだから、6.5インチ画面には2倍くらいのズームは必要なのだろう。タブレットは単画面だと10.5インチくらいが上限になって、それ以上は2in1が主流みたいだが、これはマルチメディア機としてのホットゾーンであって、X端末としては微妙なライン。入出力を両方考えると分水嶺になりそうなのは13.3インチだろう。このクラスはタブレットを名乗っていてもたいていコンバーチブル（＝折りたたみ式）で、ノートPC寄りの性格が強い（キーボードを取り外せるセパレート式が主流なのは、画面の支持がしやすく一体型だとキーレイアウトが制限される10インチクラスまで）。持ち運びの利便性まで考えると、15.6インチはかなり大掛かりになるので、13.3が落としどころとして有力なのは間違いなさそう。なお、ノートPCを名乗っている機種にAndroidを採用したものはほとんどなく、ChromeOSを採用した単画面タブレットはいくつかあった（AcerのD651N-F14MとかAsusのCT100PAとか：HPあたりはノートを名乗ってる）がほぼ絶滅、Androidを採用した大型タブレットも皆無ではない（サムスンのS8 Ultraとか）が例外的。

うーーーん、とすると有力候補はChromeBookかぁ？これ以上Gさんに侵食されるのイヤだよなぁ。かといってWindowsノートがいいのかと言われると・・・いやでもこの間書いた「ようはWindows機が『ない』と不便なだけ」の解決案としては使えるような・・・とすると、FreeBSDワークステーション（ハードはコンパクトPCで妥協：基本デスクトップマシンで考えてるけどサーバと共用でもいい）＋Winタブレット（13か14インチ：家ではリモートサーバ、出先ではリモート端末にする）＋Androidスマートフォン（極力小さいの：出先ではタブレットにテザリングを提供する）ってことか？なんかムダがあって鈍臭いよなぁ、台数減らすならタブレットをSurfaceにしなきゃダメなのかな？うぅーむ。

スマートフォン（Android10）からWindowsの共有フォルダ（smb）にアクセスするときのメモ＋Cx File Explorerのバッドノウハウ＋余談。

共有フォルダの設定自体は簡単で、Windows側でテキトーなアカウントを作りパスワードを設定、フォルダの共有を設定、共有先のフォルダ（仮にsmbとしよう）にアクセス権を付与、cxのホーム画面一番右のページからNew location＞remote＞SMBを選択してアカウント情報を揃えてやればアクセスできる。リモートのルートはjailされており、アクセス可能なディレクトリ（上記ならsmbディレクトリと、パブリックフォルダーの共有を有効にしているならUsersディレクトリ）だけが見える。Users以下はpublic属性のオブジェクトしか見えないが、読み書きができるので、ドライブ割の都合やパブリックフォルダの共有に問題がないなら、専用ディレクトリ（上記のsmb）は作成しなくてもよい。

ずっと挙動がおかしいと思っていたcxの外部アプリ連携だが、どうやら、デフォルトアプリを指定しているとエラーになるよう。リモートに「test」というファイルを作ってopenしようとするとopen withで普通に開けるが、同じファイルを「test.txt」にリネームすると「the file can not be opened using file system name, do you want to select this file using media manager?」というメッセージが出て開けなくなる。もう一度「test」に名前を戻すか、cxの設定でデフォルトアプリの指定を解除してやると、open withないしopen asで普通に開けるようになる（ただしhtmlファイルは、デフォルトアプリを設定していてもcx本体からは開けるし、ホームスクリーンのショートカットからはopen withでもエラーになった）。ちょっとかったるいが、open asからは普通に開けてるわけだから、そのうち直るだろうと思う。筆者の想像に過ぎないが、open asで開いたファイルはCUIのテキストエディタのように、バッファを渡して編集結果を返させてファイル入れ替え（元ファイルに触るのはシェルだけ）みたいな手順を踏んでいるのかもしれない。

反対向きでWindowsからスマートフォンへのアクセス（cx内蔵のFTPd：Access from network機能）も試したところ、接続自体は簡単にできるのだが、どうやらリモートルートがスマートフォンの/になっているようで、パーミッションがないため何もできない。代わりにprimitive ftpdというのを入れてみたところ、リモートルートは/storage/emulated/0/になっており、ナビゲーションに問題（plain old filesystem設定でディレクトリを登ろうとするとルートに上がってしまい身動き取れなくなる：フルパスを手打ちしてやれば戻れるので筆者は気にしていない）はあるものの、Downloadディレクトリあたりを作業場所にすれば問題なさそう。最初は、ファイルもらうだけならスマートフォンからfetchすりゃええんでないとも思ったのだが、Termuxにはfetchがインストールされておらず、pkgからinstallしようとしても「Unable to locate package fetch」と言われて失敗する（wgetとかはtermux-change-repoでインストール可能になるという報告があったが、22年7月に筆者が試した限りfetchはムリだった：限りなく余談だがeeもない）。うむーぅ、x68kの人が「もしかしたら FreeBSD にしか存在しないコマンドかもしれない」と言っていたのは本当だったのか（筆者はLinuxをCUIで触ることはまずないし、Linuxでwgetが主流らしいことは知っていたものの、aptすればfetchも使えるだろうと思ってた）。ちょっと調べてみたら最近はcurlというのもけっこう使われているよう（初版は97年らしい：上でまた触れるがMSの独自実装版がWinでも使える）。

なお、マルチメディアファイルであれば、Windowsのメディアストリーミング（DLNA）機能でも共有できる（接続の種類がプライベートネットワークであればデフォルトで有効なはず：エクスプローラで「ネットワーク」を開いたときに「メディア機器」として表示されてるアレ）。スマートフォンからでも、VLCあたりを入れておけば「ローカルネットワーク」上のファイルとして参照できる（はず）。

2022年7月に調べたメモ。

最近の> startxしないシステムも、xinitに.xinitrcを渡して.xsessionやらなにやら読ませながらGUIを立ち上げるか、/etc/ttysからdisplay managerを呼んで同様に立ち上げさせるのが普通・・・とは限らないらしく、流儀はいろいろのよう。現在UbuntuのデフォルトディスプレイマネージャはGDM3（ほかにXDMやKDMなどがメジャー）で、本体は/usr/sbin/gdm3以下、起動はsystemctl（自動で立ち上がるデーモン）がランレベルに従いetc/X11/default-display-manager（手編集はせずdpkg-reconfigureを使うのが普通っぽい）を読んで実行する、ということらしい。環境によりgrubの下準備などが必要になることもあるが、ここで# systemctl set-default multi-user.targetとしておけばCUI、graphical.targetを選ぶとGUIが選ばれる寸法（読みに行くディレクトリ（というかシンボリックリンク）を変更するコマンド）。

Termuxでホームディレクトリから> pwdすると/data/data/com.termux/files/homeが見える。システム全体から見ると、ここは/Android/data/com.termux/files/home（SIMのルートが/になる）のはずで、chrootなりjailなりされていないわけではないが、けっこう上まで見えている。cdコマンドでは/data/data/com.termuxまで昇れるが、このディレクトリではファイルにもフォルダにも触れない（パーミッションでエラーになる）。files以下はtermux専用のようで、普通のファイラーから見ても空フォルダに見える。ローカルシステム用のファイルは/data/data/com.termux/files/usr以下。

おそらく10年ぶりくらいで.cshrc（別に.tcshrcでもいいんだけど：cshなんて使ったこともないし）を書いた。

set autolist
set complete
set savehist = (100 merge)
set path=($path ~/myscript)
setenv EDITOR nano
umask 022
bindkey -k up history-search-backward
bindkey -k down history-search-forward
alias ll ls -lFa
alias rm rm -i
alias mv mv -i

イマドキのスマートフォフォンの電池（リチウムイオン電池）の使い方について、ITmediaがキャリアに質問する企画が面白かった。
https://www.itmedia.co.jp/mobile/articles/2108/19/news070.html
それぞれ言っていることが微妙に異なる部分もあるが、スッカラカン（0％）と高電圧（100％）と高温を避けましょうというのは共通している。ナルホド。ちなみに筆者自身は「使わないときは電源を切っておく」という画期的な方法によって、電池持ちを飛躍的に伸ばすことに成功している（電話機はガラケー、ハンドヘルドコンピュータはAndroidとハッキリ分けているからできる技）。追記：電波を使う機能（携帯電話機能とWi-fiとbluetooth）を全部オフにすることでも、連続スタンバイ時間を数倍程度には伸ばせる模様。やっぱ相手を探しながらの無線通信って電池使うんだね。

今使っているスマートフォンは、ネットでたまたま見つけた新品ジャンク（という言葉も聞かなくなったな）で、そんなに長く使うつもりはないため、買い換えたらroot化でもしようかと思い調べてみたのだが、google起点で探すと「iSkysoft」という会社の、とくに「Dr.Fone」という製品がやたら持ち上げられている。どういう会社なのかなと思い、公式サイト（2022年7月現在）の「特定商取引に基づく表記」を確認すると、所在地や責任者の表示はない（法律上は「消費者からの請求によって、これらの事項を記載した書面（インターネット通信販売においては電子メールでもよい）を『遅滞なく』提供することを広告に表示し、かつ、実際に請求があった場合に『遅滞なく』提供できるような措置を講じている場合には」一部の表示事項を省略できる：特定商取引法 第十一条 ただし書き）。ドメイン「iskysoft.jp」は「Wondershare Technology Group Co.,Ltd」という中国（深セン）を本拠にする企業の日本支社が持っているらしい。

数年に1度くらいの周期で企んでは諦めている「メインデスクトップをFreeBSDで」計画だが、ようはWindows機が「ない」と不便なだけで、サブマシンクラス2台構成とかでイケるんじゃないか・・・と思うようになった。というか、BTO関連のサイトを調べて回ったところ、ミドルタワーのパソコンがほぼゲーム用になってしまい、サイズと引き換えにコストパフォーマンスを追及できるようなモデルがなくなってしまったよう。そんな中たまたま見つけたFreeBSDユーザーの方のブログが面白かった。

約一年くらい前に ThinkPad X13 AMD が届いて、苦労して FreeBSD をインストールしつつもなんとか使っている状態ですが、ちょっと古い PC で動かすと、もっと楽できるんじゃね？ みたいな・・。
例えば ThinkPad X13 AMD は default で NIC が付いてないので USB NIC を接続したり suspend/resume できなかったり、AC アダプタ引っこ抜くとリブートしてしまったり・・。やっぱりまだまだ FreeBSD を動かすにはちょっと早い。
（略）さすがに古い PC はと、いうか Intel 系 CPU 搭載の NotePC はデバイスが色々動いて良いですねぇ;-)。
https://running-dog.net/category/cat_freebsd/cat_desktop

下の記事でTermuxについて触れたのだが、筆者がインストールしたのは古いバージョンだった模様。なにやらゴタゴタがあったらしく、Google Playにはメンテされていない旧版が置いてあり、最新版はF-Droid（インストールしようとすると、サードパーティーのアプリ信用して何があっても知らんぞ！という警告が、これでもかというくらい出てくる）にあるということのよう。さらにこれ、AndroNixとかubuntu-in-termuxとか、LinuxディストリビューションをTermux上に構築するためのスクリプトが用意されている。そのうちAndroNixを試してみたところ、なんとデスクトップ環境つきのUbuntuをインストールできた。できたのだが、Termux上のUbuntuでXサーバ（中身は知らないがディレクトリ名はX11だった：もちろんXクライアントも立ち上がっているが、問題は端末に繋がってる方）を立ち上げても出力できるディスプレイが（あるように見えるけど）ない。そこでどうするのかというと、VNCアプリを別途立ち上げて、ローカルからリモート接続してしまう（意味がわからない言い方だが、LAN線だけ繋いだキーボードもディスプレイもないマシンにリモート接続するときと要領は同じ）。実用上は・・・もしbluetoothのマウスが使えたとしても画面の小ささはいかんともしがたく、筆者にはちょっと切なすぎる（上の記事でパソコンへのリモートログインに触れているが、Ubuntuで大画面出力をしながらVNCや他のアプリもサクサク動かせるマシンパワーがあれば、解決する問題なのかもしれない）。

なお、筆者が試したバージョンだとdpkgが"Failed to scan devices: permission denied"というエラーを吐いてコケたので、
> mv /var/lib/dpkg/info/udisks2.postinst /var/lib/dpkg/info/udisks2.postinst.bak
としてから
> dpkg --configure -a
で設定を読み直した（rootの概念がないのでsuとかsudoとかはしない）。また（Termux上ではもちろんできるがUbuntuに（CUIで）ログインすると）psができない仕様で、これがvncserverの挙動と相性が悪い。エラーメッセージによると/procがマウントできないのが理由らしいのだが、筆者が探した限り簡単な解決方法は見つからなかった。短時間触ってみた印象に過ぎないが、2022年現在は、GUIだとまだ不便なところが多い環境のようだ（その代わり、他と比べると速度は速い：とくにファイルアクセス）。なお、上で出てきたVNC（RFBプロトコルを使ってスクリーンキャプチャを送りまくる：Virtual Network Computingの略）はリモートにデスクトップを飛ばすためのプロトコルで、いわゆるXサーバー/クライアント（X-Windowの描画コマンドを全部送る：俗にX11転送とも）よりも帯域に優しい。他にxorgxrdp（MSのRDPをxで実装したもの：RDPはRemote Desktop Protocolの略で、いわゆる「Windowsのリモートデスクトップ」がコレ）というのもあり、xrdpではバックエンドとしてXvncとxorgxrdpのどちらかを選べる。

次に試したのがUserLAndという環境で、こちらはprootという仕組みを使う（速度が犠牲になるが、仮想環境内でrootになったかのように振舞える）。そもそもが、ネイティブアプリでさえサクサクとは動かない環境なので、GUIで云々という期待はしていなかったのだが、モノは試しとUbuntuを入れてみた。ファイルアクセスがボトルネックになるため、インストール自体がとても遅い。遅い上に、給電しながら作業しているにも関わらずバッテリーがジリジリと減っていったので、よほど大変な処理なのだろう（けど数時間オーダーなので、昔々デスクトップに扇風機を当てながら> make worldとかやってた頃に比べればマシではある：2015年版のFreeBSDハンドブックでは「make world は使わないこと」とboldの朱書きで注意されているチョー危険コマンドなので、よい子といい大人は「17.6. world の再構築」の指示に従おう）。コッチは、ファイルアクセスが遅いだけあって起動にやたら時間がかかる（使ってみれば最初に気付く欠点だと思うのだが、言及している説明がなかった：マシンスペックの問題もあるのだろうとは思う）。筆者は結局、GUIのUbuntuを一度も起動できなかった（一晩置いたら止まったままコケていたが、まだ作業中なのか起動できなかったのかインストールが失敗していたのか、わからないし確認する気力も起きなかった）。

ただまあ、GUIで使おうと思ったら端末（＝ディスプレイとキーボードとポインティングデバイスのセット）としてのスマートフォンの貧弱さがネックになるのは避けようがないわけで、ここまでは「そんなもんだろうね」といったところ。UserLAndでもCUIのUbuntuならサクっとインストールでき、内部でssh扱いらしい接続でのログインはUserLAnd単体で（外部のsshクライアントを必要とせずに）できた。しかしこれ、やはりファイルアクセスが遅く、> apt upgradeなんかでモタつく。アップグレードの際に権限で怒られたので> suしてみると、パスワードなしで昇格できた。tcshもインストールできたが、> chsh -sの挙動がよくわからない（なんかPINコードとか求められるが、そんなの設定した覚えがない）。うーん、Ubuntuのパッケージを使えるがモッサリ挙動のUserLAndと、入手先が独自サービスだがそれなりに動くTermuxなら、筆者はTermuxを使うかなぁ。SDカードの中身に触れるのもプラスだし。

スマートフォンのキーボードについて思ったこと。ソフトウェアキーボードにも使えるものはあるというのは下で触れたとおり、IMEと一体化していて引き剥がせないのも上の通りだが、じゃあどうすると快適なのかと考えると実に悩ましい。そもそも、QWERTYキーボードってのは横幅の要求が大きく、タッチスクリーン上のソフトウェアキーボード（ハードウェアキーボードと違って、キーに触ってから押す2段階操作にできず、触っただけで入力されてしまう）だと隣のキーとの誤入力がうっとおしい。俗にファブレットと呼ばれる大画面スマートフォンでも、単画面のスマホ寄り機種だと7インチで80*175mmくらいが最大サイズで、筆者の感覚だとソフトウェアキーボードで快適にQWERTY入力するには微妙に足りない（この辺が、英語圏でblack berryの人気が根強かった理由だと思う：最終機種のKey2が72mm幅、1世代前のKEYoneが73mm幅らしく、ハードウェアキーボードでかつ一本指入力が前提なら、筆者としては納得できるサイズ）。なお画面幅には歴史的な紆余曲折があり、日本だと、2010年ごろは6～7cmが主流、15年ごろに7～8cmが主流になって、20年くらいには70mm前後に収斂してきたそうな。

余談ながら、一本指でのソフトウェアキーボード入力には、一筆書きでキーをなぞる方法（メーカーやベンダーにより、グライド入力とかスワイプ入力とかジェスチャー入力とか、バラバラの呼称で呼ばれる）もあるのだが、日本語入力では一般的でない（入力修正が（かな化と漢字化で）2段になるからという説明も見たが、筆者が予想するに、促音や撥音の入力が不便だというのも理由のひとつではないか）。日本語向けには、フリック入力とグライド入力を折衷した（ように見える）アルテ入力とか、よりフリックに近く促音・撥音・濁音などの入力だけ補ったターンフリック入力なんかがあるらしい（追記：上で紹介するように、縦長画面で日本語しか打たないなら、ゴダン入力というのがけっこう便利）。しかし現実問題として、音声入力も含め、これらの「人間の入力はエラー山盛りが前提で、機械がなんとなく直す」やり方は、コンソール（ないしCUIシェル）の操作や他人に（＝仲間内以外にも）見せる文章と絶望的に相性が悪い（筆者が試した時点＆環境では、Turmax上だとグライド入力が自動で無効化された）。メールアドレスやらファイルパスやらを入力するのも相当面倒だろう（だからそれを極力ユーザーに「やらせない」設計にしてるのだろうけど）。また、このページもそうだが、漢字とかなだけでなく英単語や大文字言葉が多く出現する文章だと、日本語だけに特化した入力は使いにくくなる。

両手持ち親指操作前提のものではやはり、アドエスのキーボードが傑作で、筆者も長いこと愛用した。キー部分幅10.3cmくらい（実測キーピッチ幅8.5ｘ縦5.0mmくらい）、電話機本体が13.5cmくらいと左右に適度な余白（端までボタンを置かれても、横幅が広くなりすぎても、親指で押しにくくなる）があり、上半分をしっかり支持できるスライド式で両手持ちが安定し、縦画面用のキーも左手で操作できる（おかげで数字をファンクション入力に回してカーソルキーを入れられた）レイアウト、という絶妙なバランスが、あの使い勝手を実現していたのだろう。似たようなサイズの外付けキーボードを使うのとは比較にならないほど快適だった（ついでに、画面も小さかった（41ｘ67mmくらい）が不便ではなかったように思う）。

こうして見ると、縦画面QWERTYで自然なのは一本指タイプで、そうすると画面の縦サイズが割を食う（上で挙げたKEYoneやKEY2は4.5インチ）一方、両親指操作だとスライド式が順当だが、安定して持てる機構と本体サイズand重量のバランスが難しい、というジレンマがある（ATOKのソフトウェアキーボードでは、左右分割機能を持たせてレイアウト問題を緩和しているそうな）。もう一点アドエスが有利だったのは国産機種だった点で、海外製の機種でありがちな「長音記号・音引き（ー）がファンクション入力で日本語が打ちにくい」だとか「半角/全角や直接/ローマ字の切り替えが面倒」だとかいったイライラに巻き込まれることがなかった（英語圏の人だって「ls -l」とか「rm -r」とか使うと思うんだけど：termuxでは縦画面でも最上列に「-」や「esc」や矢印系のキーが付加されるが、あんないいものをなぜみんなパクらないのか不思議でならない）。

10本指タイプがしたいなら、どうやっても外付けキーボードに頼らざるを得ないだろう。いまメインにしているエレコムのTK-FLP01（公称キーピッチ17.0mm：ケース付きとマグネットレス仕様でこれを選んだのだが、SKB-BT30とか、いっそYXB-07とかでもよかったのかも、ケース便利だけど）が筆者のギリギリサイズで、開いた状態の「キーボード部分」は256*97mmくらいだった。しかしまあやはりデカいし狭いし、キーの分割ラインにクセがある（一般的な中央セパレートのキーボードは、マイクロソフトもロジクールもサンワサプライも「6TGB」が左で「7YHN」が右、KinesisやMistelも一部の機種で「6」が右に行く以外はこのパターンなので、それが普通だと思っていたのだが、TK-FLP01は「5TGV」が左で「6YHB」が右）。折り畳んだ状態で収納できるプラスチックのケースが付属しており、実測で10ｘ15ちょいｘ2cmくらいある。本来はタブレット（8インチクラスで13ｘ19cmとか12ｘ20とか、10インチクラスで18ｘ25cmくらい、13インチクラスで22ｘ28cmなど）用みたいなので、スマートフォンと組み合わせること自体にムリがあるのかもしれないが、しかし入力の速さと正確さが（フルサイズのキーボードとは比較にならないが、モバイル機種の中で）ブッチギリなのも間違いない。そうするとセパレートの強みを生かして、ある程度の分量を打つときは外付け、簡単な入力はソフトウェアということにしたいのだが・・・ここで先に触れたIMEの話に戻ることになる。具体的なモノはまだ試していないのだが、老舗のATOKのほか、Wnn系（なんか派生がやたらある）やAquaMozc（ただし本来はBlackBerry用）あたりが使えるそうな。

ようやくこのコーナーらしい名前が出てきた。筆者はCanna＋Kinput2派だったので、Wnnはほとんど触ってないのだが、名前を聞いただけでもなんとなく感慨がある。商用版の販売元であるオムロン（オリジナル版の共同開発者でもある）曰く「iWnn IME for Android」というのが「国内スマートフォン端末搭載実績No.1の商用版IME」らしい。そのiWnnの先行開発版の公式ページにあった注意書きには、

・Lab-256以降の追加辞書の格納場所について
追加辞書へのアクセスがOSバージョンによっては制限されてしまうため、2020年9月リリースのLab-256より辞書ファイルの格納場所を変更させていただきました。
引き続き追加辞書をご使用になる場合は 内部ストレージ/android/data/jp.co.omronsoft.wnnlab/files/ の配下に「wnnlab」フォルダを新規作成し、/sdcard/wnnlab/ 配下にある既存の辞書ファイルをすべて移動させてください。
なお移動後はWnn Keyboard Labをアンインストールすると辞書ファイルも消去されてしまいます。事前に辞書ファイルのコピーを別途保管しておいてください。

ちょっと前の回想日記だが、2022年のはじめに、ローカルサーバがついに動かなくなった。ハードは2010年7月に新品購入したEPSONのEndeavor NP11-Vで、24時間365日運用に11年ちょっと耐えたことになる（同時に買ったもう1台は2016年3月に再起不能になった）。どちらもハードディスクが読めなくなったのがクラッシュの原因で、ディスクさえ元気だったら今もまだ動いていたかもしれない（やるなエプソン：廃棄したのは、ハードディスクを単品で買ってきてまで延命する気力がなかったから）。1～2年前に以前言及したさくらのVPSなんかも（1年分だけ）試してみたのだが、SSLが使えるようになるまでがかったるすぎて諦めた（独自ドメインなんていらんというか、Adamみたいな共有SSLで十分なんだけど、そういうサービスは探せなかった：最近のITサービス企業がみんな「ブランドもののO塚商会」になりたがってるように見えるのは、筆者の心が汚れているからなんだろうか）。2022年現在はサーバの運用を中断してしまっている。
補足：SSLの導入and維持自体はLet's Encrypt＋certbotなどを利用すれば可能だが、そもそもドメイン持ってないし取る気もないので、運用が変則的になりそうな気がする（ちゃんと調べるつもりなしに書いているので、もしかしたら簡単にできるのかもしれないけど）。

メインマシンも寿命が迫っていそうな感じなのと、下の記事で紹介したようにスマートフォンを導入したので、メディア環境をゼロから再構築してみようかと思っている・・・のだが踏ん切りがつかない。サーバをローカルマシンで立てるとしたら極小PCとかなんだろうか（NP11-Vくらいのサイズでもぜんぜん不満はないんだけど）。いっそのこと、自宅にサーバ兼ワークステーション的なFreeBSDマシンを1台常時稼動させて、xrdp over sshとかでスマートフォンをdam端末化した方が幸せなのかもしれない（けどなぁ、そうすっと今度は固定IPじゃないのがアレだし、サーバとデスクトップでマシンを共有するのもキモチワルイし、jailでなんとかと思っても速く動いて欲しいのはデスクトップの方だし、そもそもスマートフォンとデスクトップじゃ物理的な画面サイズが違いすぎるしなぁ）。

なお、SSHのポードフォワーディング（ポート転送、SSHトンネル）についてはいろいろな説明があるが、FreeBSDのman（この手の調べ物ではもっとも信用している）によると、
> ssh -L [bind_address:]port:host:hostport
がいわゆるローカルポートフォワードで、ローカルマシンのSSHがportで待ち受けた通信を、リモートマシン（host）のSSHdに転送し、SSHdがリモートマシンのhostportへさらに転送する（と筆者は理解している：sshの外にある通信を無視した図解が多いが、なんだか違和感がある）。同様にリモートポートフォワードは、
> ssh -R [bind_address:]port:host:hostport
として、リモートマシン（host）のSSHdがhostportで待ち受けた通信を、ローカルマシンのSSHに転送し、SSHがローカルマシンのportへさらに転送する（リモートマシンがインターネットにポートを開放していれば、NATの下にあるホストがルーターに頼らずにインバウンド通信を受け入れられる：ノリとしてはpassiveFTPみたいな感じ）。SSHで守られているのはトンネル部分だけなので、宛先ポートへの外部からのアクセスを遮断したい場合はルーターなどで制御する（ということのはず）。上の方の記事でまた詳しく触れる。

アドエスを手放してから5年以上経ち、仕事の都合でついに「イマドキの」スマートフォン（Android）を買ったのだが・・・心底性に合わない。まず、設定項目がバラバラに散らばっている「オートなんちゃら」とつく機能と、ナントカと連携しますとかカントカと紐付けますみたいな機能を、全部offにして回るのに2～3日。謹製のブラウザ（買った当初はクロームでも別に構わないつもりだったのだが、Google関連の機能やらサービスやらとやたら絡み合ってるのに辟易して、firefoxに逃げた）やメール（なんか同期だかバックアップだかうるさく言われて、ひとまずfirefoxからブラウザ版のGmailを使う形にした：そのうちメーラーも探して、できるならGmailからも逃げたい）なんかを隅に追いやるのに1日ちょっと。ターミナル（Termuxというのを入れたけどJailに閉じ込められててなにもできない、と思ったら設定（termux-setup-storageコマンドを実行）でSDカード内のjailedファイルにも触れるようになった：上の記事で触れるように、古いバージョンのものを誤って入れたらしい）やテキストエディタ（Docsとかいうワープロソフトは入っていたけどこれがまた（以下略）で、普通そうなのを探した：その前のごく短期間は、コマンドラインでnanoとかcatとか使ってた）なんかを揃えるのにまた半日ちょい。この間に、トンチンカンな日本語の説明に業を煮やして、表示言語を英語に切り替えた。

悩んだのがファイラー（ディスクのクリーンアップとか頼んでないから、普通にファイルを管理させて欲しかった）。ひとまずCx（他のファイラーがとにかく「ファイルのパスを教えてくれない」中、これだけは「親ディレクトリを開く」というコマンドを持っていた：地味にsmbプロトコルにも対応していて高性能）というのを入れて人心地ついたと思ったら・・・なんと外部アプリにデータを渡せない、というかテキストファイルをテキストエディタに読ませることもできない。ファイラーの内部エディタがまるでダメではないがやはり頼りないので、連携のためのプラグインを見つけて入れてみるもパスがおかしいだかのエラーでコケる。他の部分の設定をガチャガチャいじったり、files（google files というデフォルトアプリのほかに、filesというサードパーティのアプリがあり、どうもOSの機能を呼び出すだけのランチャーっぽい：アプリ名はどちらも「files」で、アイコンだけ違う・・・）をインストールした後間違ってアンインストールして再インストールしたり、外部ストレージを再マウントしたりしてから、なんとなくもう一度ファイルオープンを試したら、理由はわからない（もしかしたら裏でアップデートとかあったのかもしれないが、筆者は知らない）もののアッサリ動いた（上の記事でまた触れるが、デフォルトアプリの指定を解除することでもっと快適になった）。htmlファイルをfirefoxに読ませることもできるが、127.0.0.1:10021以下へのアクセスになる（ちなみにfilesのopen withにはfirefoxは挙がらず、chromeから開くとcontent://なんか内部アドレスっぽいの/という奇妙なURLになる：fileスキームの類似品だろうとは思う）。おそらく、firefoxがローカルファイルに触れないから臨時でhttpdを動かしてるのだろうが、おかげさまでローカルhtmlをホームスクリーンに送ってもショートカットからはアクセスできない。

当面はCxをメインにして、files（感覚的にだが、システムへの食い込み度合いが深いような気がする）も残しておく使い方にした。カレンダーとかメディアビューア（筆者が所有するもっとも画面が大きなモバイル機器になったので、使い道を探してみたい）も、他サービスとの連携がガッチリしていない、アナタの情報をバッチリ守り抜かない、ヨソの端末からアクセスするたびに「怪しいアクセスがあああぁぁぁ」と大騒ぎspamを送ってこない、ごく普通の単機能のものが見つかったら試してみる予定。・・・しかしなんだろうねぇ、Android端末を使えば使うほど、Googleのサービス（検索だけは今でもメインにしてるし、メールも最小限は使わざるを得ないけど）から遠ざかりたくなるってのは、本末転倒じゃないのか。アプリへのアクセス許可設定に「今回だけ許可」（もしくは「許可して次回以降も問い合わせ」）がないあたりにも、明確で強烈な悪意を感じる。

もうひとつアレなのがソフトウェアキーボード。メインはハードウェアキーボード（Bluetoothの外付け）なので大した問題ではない・・・だろうと思っていたが、これインプットメソッドと一体化してるらしい（MS並にシレっと、アップル並にゴリっと、こういうことをする企業に「成長」したんだねぇ、グーグルも：むしろ両方のヤバいところを兼ね備えつつあるようにすら見える）。デフォルトのGboadはキーレイアウト（配列じゃなくボタンの物理的な位置）がアレで、メインキーボードを出すまでもないちょっとした入力もストレスフルなため、hacker's keybord（アドエスのハードウェアキーボードほど快適ではないものの、これはこれでいい感じ：縦画面でファンクションキーなしの7列になるのが秀逸）というのを入れたのだが、ソフトウェアキーボードを切り替えたままだとハードウェアキーボードから日本語入力ができなくなる。多分だが、アプリ間のデータ通信が制限されすぎてるからだろう。お前んトコのは勝手にガチャガチャ触りまくるのに、サードパーティには（ハードウェアにすら）その仕打ちかよ。ああもう、IMEも取っ替えたいというか、いっそのことKDEとか丸ごと移植されないモンだろうか（Googleワールドの中から出られなくなるのはまっぴら御免だが、KDEワールドなら完結して住むのもそうは悪くはない）。

でまあ、そんなこんなの悪戦苦闘の末に筆者が手にした機能とは「ファイルの送受信ができる」「共有のテキストファイルにアクセスできる」の2つ。なんだか、世の中どんどん不便になっていくように思えてならないが、ひとつ気付いたこともあった。それは、90年代末のマイクロソフトは（製品はグダグダだったけど）無能な会社ではなかったのではないかということ。あのGoogleでさえこうなんるんだと思えば、結果的に踏みとどまった（かどうか微妙な部分もあるが、ともかくNT系への統合だけはやった）Microsoftは、実はかなり健闘していたのかもしれない。まあともあれ、最後は筆者の悲しいポエムでシメよう。
Asisstant
I said DO NOT DO NOTHING until I say to do.
Replyed that searched for "don't do nothing".

以下は20/12/31以前の古いメモです。

2020年末に調べてみたメモ。PC-BSDは2006年にiXsystemsというNASベンダーに会社ごと買われてTrueOSになり、デスクトップ部門をProject Tridentが引継いだが、Tridentは2019年にVoid Linuxへの乗換えを決め、放棄される形になった（おそらく後述のGhostBSDにいくらか引き継がれているのだろう）。DesktopBSDは2015年のバージョン2.0公開以降沈黙、2019年末に数人の有志が「復活させようよ」的な相談を始めたが2020年末時点では動きなし。アクティブなのは、2018年にFreeBSDベースからTrueOSベースに変わったらしい（今後は不明）GhostBSDと、まだマイナーで開発途上のMidnightBSDのよう。ReactOSや Gentoo/BSDもいまだに活動を続けているらしい。Wineのバージョンが5になったそうな。筆者が理解しているWindows10のサポート期限はようするに、手持ちのハードをMicrosoftが見捨てるまでということで、実際には困るほど短くはないんだろうと思う。

よくわかんないのがデスクトップ環境。KDE Plasmaは5.20が出て、Wayland（後述）対応改善やGTK3アプリのと親和性向上など。Qtは20年5月のQt 5.15 LTSが「最後のfeature release」で、20年9月にQt6がFeature Freezeに入った。GNOMEは周辺アプリのGTK3化（GIMPが移行するというニュースが20年11月に流れた）を進めつつ、GTK4も準備中。そのGNOMEにUbuntuのデフォルト環境を譲ったUnityはLomiriに改称（Unity Techという別ソフトとの混同を避けたんだそうな）、個人的にはけっこう好きなんだけど不評だったらしい。XfceはGTK3化、LXシリーズはLXQtがメインで残った。TDK（Trinity Desktop Environment：KDE3.5からのフォーク）はまだ頑張っているようだが、Cinnmaonは様子がわからない。他に元気そうなのはEnlightenment（EFLという独自のツールキットを使っている）、pantheon（GTK3）、box系ではLXシリーズにデフォルト採用されているopenbox、といったあたりか。

実際的な選択としては、KDE、GNOME、Xfce、LXQtがやはり有力、ムリしてひとつに絞ることもないのだろうし、イマドキはGTKもQtもなんやかんやで入るので、どれでもいいっちゃどれでもいい。インプットメソッドは、フレームワークがFcitx、IBus、エンジンがMozc、kkcといったあたりで、ibus-kkcがデフォルト（ディストリビューターが差し替えていることはある）のGNOME以外ではfcitx-mozcが主流になりつつある（SCIM、UIMやanthy、SKKあたりはメジャーでなくなった）ようだ。上で出てきたWaylandはいわゆるディスプレイサーバで、ポジション的にはX11相当＋コンポジットということらしい。2020年末時点で対応が進んでいるのはGTK+3系とQt5系だけのようで、デスクトップ環境の勢力図が動くキッカケになるかもしれない。GNOMEは2019年9月から2020年5月までShotwellというソフトの特許訴訟があったらしい。Qtもメジャーバージョンが変わるにあたってSoftware license agreementをどうしようかという議論があった模様。

2022年追記：GhostBSDは順調らしいがFuryBSDというのも出てきたようで、どちらにもJoe Maloneyさんという方が中心的に関わっているそうな。ベースがTrueOSなのは共通で、GhostBSDが「FreeBSD＋追加機能」なのに対し、FuryBSDは「FreeBSD＋デスクトップ用プリセット」ということみたい（2022年2月現在、FuryBSDは本家サイトのドメインが失効しているよう）。ポータブルではNomadBSDというのが出てきた。KDEがUbuntuベースのLinuxディストリビューションKDE Neonを出したそうなのだが、これってKubuntuと丸カブリじゃないのか。そのUbuntuはけっこう面白い動きをしていて、21.04でx.orgからWaylandにデフォルトを変更し、22.04ではGnome42を採用してGTK4は回避、UbuntuStudioは21.10からKDE Plasmaを採用。

引越しの目処が立ってきたのでサーバ移転も真面目に考えなければならないのだが、FreeBSD11のリリースが今年7月（これを書いているのは2016年4月）なのでちょっと間が悪い。10.3もリリース間近（おそらく今月中）だが、11以降はサポート期間が5～6年（最低5年）になるので、どうせサーバを立てるのなら最初から11で立てたい。古い回線を3カ月くらいキープしておいて、リリース直後に移行しようか。7以降はそんなことないんだと思うけど、FreeBSDの奇数バージョンって、なんかコワモテな印象があるのよね。

FreeBSDと関係ない話題ばかりだが、また「インターネットが安くor速くなります」系の勧誘電話が増えてきた。いい加減頭にきたので最近は意地悪く対応している。定型問答になっているのが「モデムは何を使ってますか」「オムロンのを持ってますが使ってません」で、決まって「インターネット接続にはモデムが必要」だというご高説を賜る。

もちろん、イマドキのインターネット接続にモデム（Modulator/Demodulator）なんぞ必要ない（当然ながらONUは筆者も使っている）わけで、オムロンのモデム（56KでFaxも対応のやつ）を持っているのも事実だし、嘘は言っていない（ついでにNTT-MEのISDN用TAも持っている）。一応断っておくと、ONUの中に変調器や復調器が入っていないかといえば多分入っているだろうが、変調器や復調器が入っている機器全部を「モデム」と呼ぶわけではない（そんなこと言ったら無線機もデジタルレコーダーもモデムになる）。

用語を真面目に考えるとけっこう面倒な話で、DCE（データ回線終端装置）が「通信網の最外縁」を想定するのに対し、TA（ターミナルアダプタ）は「インターフェイス」を主眼に置く。ONU（という呼び方は日本ローカルらしい）は両方に当てはまり、キャリアのFTTH網の終端になっており（だから光回線終端装置と呼ばれる）、かつプロトコルを跨ぐためのインターフェイスを提供している。

Ubuntuで「古いカーネルで/bootがいっぱいになる」というトラブルに遭遇。半自動で消せるコマンドもすぐ見つかったが少し怖かったので、結局は
> uname -r
> dpkg -l linux-image*
> dpkg --purge linux-image-hoge
みたいな作業で消した。Ubuntuを持ち上げた矢先でアレだが、なんで古いカーネル/bootに置くかなぁ。軽く調べたところ「イマドキ/bootなんて必要ないよね」という設計思想らしいが、だったらデフォルトで/bootを切らないようにしてくれればいいのに。

まあなんというか、筆者も甘く見すぎていたというか、あまりにユーザーフレンドリーな第一印象に「バッドノウハウなんて必要ないよね」と安易に考えたところがある。しかしこれどうやって管理しようかしらね。やっぱ半自動ツール入れてcronで回すのが正攻法かな。

キーリングの抑制（システム＞設定＞自動起動するアプリでSecret Storage Serviceの自動起動を無効化するのが手っ取り早そう）とかsamba上のショートカットを辿れない問題（fstabにusername=hoge,password=mogeとか書いて、fstab自体を隠して、自動マウントしたうえでローカルにシンボリックリンクを置くのがいいのかな）とかも近いうちに何とかせねば。

10年以上ぶりにLinuxを試した。Ubuntu StudioとかKnopix系とかをチョコっと触ってはいたが、普通に使える環境を作ったのはFreeBSDを入れる前に半年ちょっと使っていたGentoo以来。仕事でとうしても「パソコンの増設」が必要で、古いハードウェアはいくつか倉庫に転がっていたがソフトウェアの予算が下りないという状況で、筆者が自分で使うならもちろんFreeBSDを入れるところだが、まったく知識のないユーザーが使うものだったので少しでもメジャーなものを、という配慮からUbuntuにした。FreeBSDには自分なりに少しは貢献しているつもりでいるが、Ubuntuは完全なフリーライドになってしまうので、せめて紹介でも書いてみようと思い立ったというわけである。

悩んだのはフレーバー（というかソフトウェアディストリビューションだよね、以前のFreeBSDの感覚からすれば）で、ハードウェアが非力なことからUbuntu MATEかLubuntuを検討したのだが、まったくの初心者でもある程度自分好みに変更できるようにと考えると少し躊躇われた（ただ使うだけなら問題ないと思うが、イジろうとしたときにGUIだけでかつヘルプを読まずに（！）でき、日本語の入出力や日本語ファイル名の扱いがこなれている必要があった）。結局はUnityを使うことに決めたもののやはり重く、ローカルサーバ用にFreeBSDを入れていたマシンをUbuntu用に回して、古いマシンにFreeBSDを入れ直すという作業になった。手間はかかったもののどうやら普通に動きはしたようで、現場でもトラブルなく利用されている模様。Linuxも使いやすくなったもので、Windowsが8～8.1～10とすったもんだしている間に性能や機能や使い勝手の面ではほぼ遜色がなくなったんじゃないかと思う。筆者の導入作業もWindowsよりラクだったし、使用者の評判としても「Windows8よりは親しみやすい」らしい。

デスクトップ環境もいろいろ試したり眺めたりしたが、ようするにこれって、Qt系がKDEとLXQtで、ライブラリレベルでGnome2系なのがXfce、Gnome3系（関連度はともかく）がCinnamonとかLXDEとか、2と3の折衷がMate、ウロウロしてる（Gtk＞Nux＞Qt：NuxはもともとGtkベース）のがUnity、独自路線がEnlightenment（EFL）とかXmonad（よくわかんないがHaskellで書かれているらしい）とか、という理解でいいのかな？個人的には、快適に動くハードさえあればKDEで何の不満もなく、Qt系の環境が増えるのは歓迎だが、Gtkと違いKDEあってこそのQtなので自分では手を出さないと思う（Unityがあの取っ付きやすさのままQtに移行してくれたら、ビギナーユーザー向けに勧めることはあると思う）。Gnome3は言われるほど悪くないというか「筆者が嫌いだったあのGnome」ではなくなっている印象でむしろ好感が持てる（Gnome系から選べと言われたらCinnamon使うけど）。軽量系は、将来性も考えるとMateが安定チョイスなのかなぁ。

上に乗っかるソフトは、オフィススイートはWindowsでも自宅用はApacheに移行してしまいとくに問題も感じていないし、ブラウザもここ最近Firefoxしか使ってないし、WindowsでもLinuxでもFreeBSDでも、環境に大差ないんじゃないかと思えてきた（DTMソフトなんかは替えがきかないのでWindowsは使い続けるし、サーバを立てるならFreeBSD以外使う気にならないが、デスクトップ用途なら）。まあこれでタブレット（けっこう欲しい）でも持ったら連携面とか考えなきゃならないから、また見方も変わるんだろうけど。

FreeBSDとは直接関係ないが、サーバのハードウェアについて。元はといえば下に書いたLANディスクのクラッシュと、トップページで告知したdyndns.comのアカウント失効が発端。コストパフォーマンスが悩みどころ。

まず考えるべきはdnsをどうするかで、dyndns.comにお金を払う（サービス内容はすばらしいと思うが、1回きりならまだしも、ドル建ての海外送金を毎年欠かさずにというのは、ちゃんと維持できる自信がない）、niftyのダイナミックDNSを使う（安定したチョイスではあるし、もう15年以上使っているのでそうそうプロバイダ乗り換えもしないだろうが、今まで無料で使っていたのより鈍臭いサービスに金を出すのも抵抗がある）、他の無料ダイナミックDNSサービスを使う（国内のはどこも似たり寄ったりだし、海外のはまた有料化されると同じ状況になるし、ドメインが変わると設定ファイルの更新が思いのほか面倒なので、手を出しにくい）、サーバ自体を自宅設置からホスティングに変更する（ハードディスクを買い直すつもりだった予算と、今借りているadamのサーバ代を合わせれば費用は出るが、セットアップが終わった直後のサーバをお役御免というのも口惜しい）、といったところか。

費用面では、2TBクラスの外付けHDDを買い直すと1万円弱、dyndns.comが35ドル/年、niftyが200円/月、さくらのVPSの一番安いコース（メモリ1GBのディスク100GBの仮想2コアなので、今のサーバとほぼ同じスペック）が1万強/年or1000円/月。現実的に考えるとさくら（FreeBSDも選べるが、2014年5月現在はFreeBSD 9.2のi386とamd64で、FreeBSD10.0はオプションにない：端の方にコッソリ「3.2GB以上のメモリを認識させる場合はお客様にてPAE対応カーネルを導入ください」なんて書いてあるのでカーネル入れ替えは好きにできるのだろうが、freebsd-updateが利くのかどうか気になるところ）が一歩リードしているのだろうか。どうせNASは欲しいのでセットアップしたサーバをローカル専用にして、浮いた容量をファイルサーバ用に使うのが妥当かなぁ。気になるのはいったん使い始めると（今のところ）プラン変更ができないのと、面倒になる管理もある（たとえば「LAN内部からの接続のみ許す」なんていう設定が意味を持たなくなるし、手元のマシンからサーバまでの通信にもより気を使う必要が出てくる）ことくらいだしなぁ。adam＋nifty＋新HDDだと初期投資で1万円＋月400円くらい、さくらだと月1000円弱だから2年でトントン・・・いやさくらを使うにしてもHDDは欲しいか・・・しかし引越ししても停電してもサーバは動き続けてくれるというのはいいよなぁ・・・うーむ。

USBハードディスク（というか、LANディスクのはずがLAN接続時の応答がやけに悪く、仕方なくUSB接続で使っていたらそっちも応答鈍化、ディスクチェックで大量の論理エラーが見つかったころにはLAN接続はまったく無応答、データの大半は（Windowsマシンのディスク修復で）救出したがこの際NAS機能は捨て、動いたらラッキー程度でUSBディスクとしての復活を目指している：中身はSumsungのHD204UIらしく、容量2TB）の物理フォーマット（というか初期化）をしようと思ったのだが、ツールがよくわからない。

scsiならcamcontrol(8)が使えるはずで、どうにかしてコマンドを捻り込めないかなと少し考えたが、作業が作業だけにちょっと怖い。DosブートでDiskinitやFORMAT、CDブートでMaxtorのPowerMaxという手もあるが、サーバマシンは止めたくないしデスクトップ用のサブマシンを占有されるのも困る。サーバマシンを動かしたままフォーマットできるなら、終わったらrootにメールをくれるようにスクリプトを組んでほったらかしにしたかったのだが。

WindowsからはバッファローのDisk Formatterがあるが、フォーマット速度がいくらなんでも遅く1カ月コースになる（Disk Formatter2は「BUFFALO製 USB HDD/USBメモリに対応」で使えなさそう）。ということでHDDGURUのHDD LLF Low Level Format Toolを採用、こちらはWindowsから20MB/s前後で動くので、丸1日くらいあれば終わる見当。実行前に電源オプションでスリープモードに落ちないようにしておく。

この際に、ディスク先頭にあった領域（Linux＋sambaをディスク上に置いているらしいので、おそらくそれ：ためしにLANモードで起こして半日放置してみたが起動中のままなので、カーネルパニックでコケっぱなしになっているのだろう）も巻き添えでフォーマットされるが、代替システムを入れる手段が（軽く調べたところ、ディスクを取り外して他システムからインストールとか、ゴムタイなことをやっている人はいたがカジュアルなものは）ないので、LAN機能は捨てということになる。

とりあえずフォーマットはできたようなのでbsdlabelとnewfsを実行してfsckを走らせてみる。エラーは出てこないが読み書きが異常に遅い。仕方ないので
> dmesg | grep da0
でブロック数を拾って（shから）
> nohup dd if=/dev/da0a of=/dev/null bs=512 count=3894156000 conv=noerror,sync 1>>dd.log 2>&1 0</dev/null &
として、数回SIGINFO（kill -INFO プロセス番号）を送り様子を見るも、読み書きとも速度が1.3～1.4MB/s程度とお話にならない（数字的にUSB1.1で動作しているのかと思い> usbconfig listしたところspd=HIGH (480Mbps)だった：> diskinfo -t /dev/da0してみたところ100MBの読み書きでは30MB/s近く出ていたので、ブロックサイズが小さいのが原因だと思われる）。

数時間で諦めてWindowsから再フォーマット。sambaも当面お蔵入りになった。フォーマットに丸1日、ディスクチェックにもう半日くらいかかった。すったもんだを繰り返し最終的に、半日がかりで350GBほどのバックアップファイルを読ませて（書き込み速度は15MB/sちょい：ファイルシステムが異なるので単純比較はできないが、これが「書いて（チェックサムを取るために）読んで」の結果なら、シーケンシャルの読み書きはfreeBSDよりやや速い）展開を試みたところ、CRCエラーが出て展開できず、このディスクは捨てることにした。円盤なり針なりが物理的に壊れているなら仕方ない。

余談というか愚痴：LAN接続時の動作がおかしかった時点でいちどメーカーに問い合わせをしている。USB接続では元気で、LAN接続でも下り（PCからLANディスク）の転送には問題なかったのでネットワーク障害だと思い、仕様を教えてもらおうと思ったのだが、たかが「仕様は教えません」というだけの情報を引き出すためにものすごく時間がかかった（「教えろ」「教えない」で押し問答していたのではなく、電話がつながるまでにえらく待たされたのと「OSは何ですか」「BSEって何ですか」という古いコントをじっくり繰り広げていただけ：「セキュリティソフトは何が入っていますか」とか「ファイアーウォールを使用していますか」なんてことも訊かれたが、たいへん返答に困った）。パッケージに「ムズカシーイ」って書いておいてくれればわざわざ電話しなかった（というか購入候補に入れなかった）のに。

サーバマシンを10.0系にアップデートしてメモを別ファイルにまとめた。今回はハードウェア（デスクトップ用サブとサーバ用で同じ機種を使っているのだが、サブマシンのビデオ出力がどうも怪しく、この機会にデスクトップ用とサーバ用を入れ替えることにした）の都合でクリーンインストール。インストーラーやパッケージ管理の変更には戸惑ったが作業自体は順調で、ソフトウェアのトラブルはほとんどなかった。

しかしなんだろうね、サーバをしばらく止めて復旧したあと、spamメールが入り始めると「ああ、ちゃんと動いてるな」と実感する。

以下は09/12/10（筆者の手元のマシンはバージョン8.0）以前の古いメモです。

freebsd-updateで7.0から8.0にアップデートしてみたが、一部のportsがベースシステムの更新に追いついていないようだ。

たとえば2009年12月10日現在のportsではPureFTPdが「/lib/libz.so.4」「/lib/libcrypt.so.4」「/usr/lib/libpam.so.4」などの古いライブラリを参照しようとしてコンパイルエラーを吐くが、ライブラリには互換性があるようで、新しいファイル（「～so.5」）へのシンボリックリンクを古いファイル名（「～so.4」）で作ってやれば動く。

作業としてはたとえば
# ln -s /lib/libz.so.5 /lib/libz.so.4
などとする（互換性が完全かどうか筆者は知らないし、上記ライブラリを使用するすべてのプログラムが以前と同じ動作をする保証は多分ない）。

portsが更新されて新しいライブラリを参照するようになれば、このワークアラウンドは必要なくなるはずである。

もっと重要な追記：ntpdなどデフォルト設定が変わったデーモンがあるようで、/etc/defaults/rc.confの確認はしっかりやった方がよさそう。

8.0になってportsの構成方針が変わったような印象（確認したわけではない）。どうも依存ソフトの指定が「広め」になった気がする。

電源コードとLANケーブルしか挿さってないマシンにXとかプリンタドライバとか入れてもしゃあないのだが、portupgradeするとなぜかインストールしようとする。

もしかすると「オレのマシンにゃXなんぞ入ってねぇ」というユーザーは自前でtar玉落としてインストールしろという時代になったのかもしれない。Linuxならともかく、FreeBSDの場合「X入れない使い方」もまだ多いんじゃないかと勝手に思っていたが、そうでもなくなってきたのだろうか。

追記：/etc/rc.confに「postfix_enable="YES"」を書いておらず自動起動していなかった。前はどうしてたんだっけ・・・Sendmailを起こすスクリプトで起動してたんだっけか？よく覚えてないや。

さらに追記：SMTPやPOPで叩いてやれば問題なく動くのに、普通にUnixログインして
> mail hoge < moge
とやると動かない（ただし、maildir形式の場合mailでメールが「読めない」のは異常ではない）。

一般ユーザーでmailすると/tmpに一時ファイルを作れずにコケる（「/tmp/mail.ランダム文字列: Permission denied」というエラーを吐いて止まる）。/tmpのパーミッションが1777になっていなかったので直す（記憶にないがいつか何かの拍子に誤設定したのだろう）。

しかしmailがちゃんと動くようになってもやはりローカルからのメールが届かない。ローカルユーザーがシェルからメールを送れなくても別にどうということはないが、デーモン君からのメールを受け取れないのは困る。

とりあえず/etc/defaults/rc.confを読んでみるが別に変なことはやっていない。/etc/rc.confも読むがこれも無問題。けっこう前にsendmail_enable="NONE"が使えなくなったが、インストール時の表示通り

To enable postfix startup script please add postfix_enable="YES" in your rc.conf

If you not need sendmail anymore, please add in your rc.conf:

sendmail_enable="NO"
sendmail_submit_enable="NO"
sendmail_outbound_enable="NO"
sendmail_msp_queue_enable="NO"

And you can disable some sendmail specific daily maintenance routines in your
/etc/periodic.conf file:

daily_clean_hoststat_enable="NO"
daily_status_mail_rejects_enable="NO"
daily_status_include_submit_mailq="NO"
daily_submit_queuerun="NO"

If you are using SASL, you need to make sure that postfix has access to read the sasldb file. This is accomplished by adding postfix to group mail and making the /usr/local/etc/sasldb* file(s) readable by group mail (this should be the default for new installs).

fatal: open /usr/local/etc/postfix/header_checks: No such file or directory

今更ながらportsnapを導入（実は今までtar玉で更新していた）。 crontabに生書きするとちょっと長くなるので

#! /bin/sh
/usr/sbin/portsnap cron
/usr/sbin/portsnap update
/usr/local/sbin/portversion

以下は04/12/7（バージョン5.3当時）以前のとても古いメモです。

PC/AT互換機にi386用のFreeBSD5.3RELEASEを最小構成のブートCDでインストールしてみた。

今回使ったマシンはセレロン1.2GHｚ＋メインメモリ512MBで、以前デスクトップ用にFreeBSD4.9を入れたのと同じもの（HDDやIDEケーブルを交換するなどの小変更は行っている）。

パッケージは
/pub/FreeBSD/ports/i386/packages-5.3-release/
にあるので、PACKAGESITEに/pub/FreeBSD/ports/i386/packages-5.3-release/Allを設定した。

CD-RDが不調だったため、最初はFDブート＋FTP経由でのインストールを試みたが、NIC（貧乏なのでもちろん蟹さん印）を認識してくれず、失敗した。その後CD-RDを2ndマシンにつなぎ替えたところ、なんとか動いたため、CDブート＋FTP経由でのインストールを試したら普通にインストールできた。FDブートの場合とCDブートの場合で、適用されるドライバが違うのかもしれない。

理由はわからないが、pkg_addで入れたportupgrade（というかportsdb）がうまく動かなかった。
% cvsup
% pkgdb -fu
% pkgdb -aF
とやってみたけどダメ。いったんdeinstallしてからportsでインストールしてもダメ。

xorgを入れてから再度
% pkgdb -F
を実行して試したら、なぜかあっさり動いた。依存関係に問題があったのかな？

xorgに変わったからなのか、5.3になったからなのか、最小構成でインストールしてからXをportsで入れると、同じ条件で4.9にXFree86を入れたときよりもずいぶん時間がかかった（perlがデフォルトで入らなくなったのが大きいのかな？）。pkg_addでとりあえずインストールしてから、必要に応じてportsでバージョンアップしたほうが楽かも（portupgradeを使わないとしても）。

gettextのインストール以外に入力が必要になる場面はなかったので、それだけ先にいれてしまえば、寝る前にmakeを始めて放置しておいてもOK（のはず）。portupgradeのオプションに、依存関係で入るソフトウェアもぜんぶひっくるめて、configだけ先に済ませてからコンパイルとインストールを行ってくれるモードがあったらいいのになぁ。

KDE3のインストールは、最初にKDEとQTの設定画面が出て、依存環境がバシバシ入り、KDE基本コンポーネントの設定画面が出て、KDEのコンポーネントがズンドコ入り、その後GhostscriptやPythonの設定画面が出て、さらにその後kdepimの設定画面が出る。

お出かけ前にインストール開始、昼休みにいったん帰宅してKDEの基本コンポーネントを設定、夜家に帰ったらkdepimの設定をして晩飯＆風呂、などというスケジュールが理想的かも（GhostscriptとPythonは先に入れておく）。

KDEのコンパイルにも思いのほか時間がかかり、丸1日くらいでは終わらない勢い（4.x系の時はもっとサックリ終わったような記憶がある）。どうも/usr/X11R6/bin/moc（「QtによるC++の拡張を扱うメタオブジェクトコンパイラ」らしい）がソースコードをいじってlibtoolがコンパイルをしている部分が時間を食っているようだが・・・？

libkspreadpart.soがportableでないとかlibkarbonbase.soにリンクがどうとかlibkarbonsvgexpart.la（ファイル名違うかも）がなんとかといった警告もけっこう目に付く（「unset parameter 云々」という警告は以前もよく見た気がするが）。

Kofficeのコンパイルなんかはやけにアッサリと終わったので、筆者の設定がどこかおかしいのかもしれない（といっても、/etc/make.confでCPUをi686に指定したくらいで、あとはportinstallを-Rオプションで実行しただけなのだが）。

最小構成に、cvsup全部盛り（外国語のドキュメントのみrefuse）とlinuxエミュレーション（base-7.1_7のみ）とxorg-6.7.0_1を入れて、その他ちょこちょことしたツールを入れてからportscleanしたところ、/usrの消費ディスクは1211MB。

そこに、kde-3.3.1（とqt-3.3.3）を、開発ツールとゲーム以外全て（アクセシビリティツールや教育関連プログラムは、多分使わないけれどせっかくなので入れておいた）のコンポーネントを選択してportinstallで入れたところで2GB弱。

最近pya!をよく見るので、マルチメディアローダーを一通り入れておく。xine、mplayer、xmms（と周辺ソフト）を入れ、kdemultimediaとkmplayerも入れておく。xineとmplayerの再生能力はなかなか高く、どちらか片方入れておけば、たいていの動画は再生できそう。

最初、mplayerが起動しなかったが、ビデオドライバを（デフォルトの）xvからx11に変更したら直った。また、mplayerの画面サイズが変更できないが、どこをいじればよいのかよくわからない。

現在のところ、xineをラッパーなしで動かすのが一番快適な気がする（noatunはうっとおしいし、kmplayerからxineを呼ぶとなぜかうまく動かない）。ラッパーなしでもあまり不自由はしていないが、今度kaffeineを試してみようか。あとはフラッシュをローカルで再生できれば言うことがないのだが、たしかそういうソフトもあったような気がする（思い出せない）。

PDFビューアとしてXpdfとgvを入れたが、gvの方は相変わらず使い方がよくわからない。Xpdfは普通に動いてくれているが、Windows上でAcrobatReaderを使うのに比べるとやや重たいか。

ブラウザはFirefox1.0_1,1を入れた。Konquerorに不満があるわけではないが、ローカル用のファイラ兼ファイルビューアと、グローバル用のWebブラウザでは、やって欲しいことが食い違うことがけっこうある。いろいろなファイルを自前で開こうとするKonquerorはローカル向きだし、拡張を入れてタブブラウズを強化できるFirefoxはグローバル向きだと思う。

Firefoxの拡張は、Tabbrowser Extension、ContextMenu Extensions、Go up、Pref Bar、Right Encoding を入れた。IE＋タブブラウザ拡張（＋proxomitron）on Windows に比べると、使い勝手は多少見劣りする（ワンクリックでクリップボードのURLを新規タブで開いてくれたり、タブロックしたgoogleの「検索オプション」画面から次々と検索ができたり、エディタやIRCクライアントからURLを送って新規タブで開いてくれたり、といった機能はやはり便利だ）が、そこそこは使える。Mozilla Archive Format とdown THEM all! も入れたが、今のところ使っていない。

Tabbrowser Extension の設定で、タブのダブルクリックでタブロック、リンクをたどるとき以外は新しいタブで開く（アドレスバーから開くと、カレントタブに上書きされてしまうが）、複数起動を許可しない、コンテキストメニューを大幅に減らす、などの設定をした。Firefox本家としては非推奨の拡張らしいが、これを入れないと（少なくとも筆者にとっては）マトモなブラウズができないのだから、入れる以外に選択肢がない。

複数起動云々に関しては、nautilusやroxにも同じことが言えるが、ウィンドウをたくさん開くのが好きな人と1つのウィンドウでなんでも解決したい人で好みが分かれるのだろう。

Firefoxは、KDEの「セッションを保存」に登録できない（これは仕方ないか）とか、設定がわかりにくい（フォーム送信の際、「次回も確認する」チェックをうっかり忘れたが、どうやって元に戻すのかいまだにわからない）など、Konquerorと比べてもちょっと不便なところがある（筆者の知識が不足しているだけかもしれないが、予備知識なしでも設定が楽だったKonquerorと比べて見劣りするのは確かだろう）。

入れている拡張が悪いのか、Firefoxが重いのか、Geckoの力不足なのかわからないが、同じマシン上のKonquerorやIEに比べるとレンダリングが遅い。感覚的にはKonqueror＞IE＞＞Firefoxといった感じ。ビジーになると他の操作まで重くなるのもやや減点。

たとえばFreeBSDのports一覧を開いて「skim」を検索するとか、ports一覧の目次をタブロックしてjapaneseセクションとwwwセクションとnetセクションを次々に開くなどといった作業をする場合、かなりもたつく感じになる。

KonquerorやIEと違って、レンダリング処理がすべて終了するまで停止した状態になることも（体感的な待ち時間に）影響しているのだろうが、絶対的な待ち時間も明らかに長い。設定やコンパイルオプションでなんとかなるものなのだろうか？

筆者はド近眼なので、Windowsでは17インチのCRTモニタを800x600の解像度で使っているが、これだと少し画面が狭い（解像度を1280x960程度に上げて、「特大のフォント」で表示させる手もあるが、そうすると一部の表示が小さいままになって目が疲れる）。

KDEの場合フォントの設定が楽なので、解像度を1024x768と少し大きめにして使っている（1280x960でもよいのだが、ビデオボードが弱いらしく画面が乱れる）。動画などが見やすくなり便利。

エディタはkateとkwriteを併用している。EMACSは入れていないし、viにもデフォルト状態から手を入れていない。KDE用のエンコード自動認識ライブラリを製作している人もいるようだが、今のところ、kateはEUCコード＋unix改行、kwriteはSJISコード＋Dos改行として、ファイルによって使い分けている。本当はkateとkwriteの役割分担を逆にしたい（unixネイティブなプレーンテキストって、ちょこっとしたものの方が多いので）のだが、そうするとデフォルトのエディタをkwriteに変えなくてはならず、面倒なのでやっていない。

一部のファイル（たとえばセットアップつまみぐいその5）が（kateでもkwriteでも）文字化けするが、もしかすると最初に出てくる漢字が「常」なのがマズイのかもしれず。ためしに1行目に「入口」のおまじないを入れてみたところ、正常に表示された。さらにそのファイルから1行目を削って再度kwriteから別名保存してまた開いてみると、これまた正常に表示される。

バイナリエディタで開いたところ元のファイルと違いはないようだし、diffを使ってもmd5sumをとってももちろん同じファイル。FreeBSD上のFirefox（言語の自動選択を有効にしている）でも、Windows上のエディタやブラウザでも、両方のファイルが正常に表示される。

いろいろ試したところ、これも理由がわからないのだが、ファイル名を「setup5.txt」から「setup5_.txt」などに変更すると正常に表示され、いったん元のファイルを削除してから別名保存してあったコピーを「setup5.txt」に変名すると、やはり文字化けがおこる。非常に謎。

IRCクライアントは、とりあえずX-Chatを入れている。本当はKSircを使いたいが、チャンネル名が日本語だとjoinできないのであきらめた（kopeteもダメ、chatzillaについては試していないがFreeBSD4.xのころに試したらダメだった）。日本語メッセージの送受信は可能なのだが、（たとえばfriend.td.nuがそうだが）コンソールに日本語を流されると文字化けするのも以前と同様。

これ以外にも、KSircには文字化けの問題がある模様で、解決策はあるらしいが、いずれにせよKSircは捨てだと言っている人もいる。実際のとこはどうなんだろなぁ。

世間ではIRCatが人気のようだが、portsには入っていない模様（googleのキャッシュから、以前はportsがあったらしいことはわかったが）。そこでIRcat-Liteをfetchしてきて
% ./configure --with-gtk-config=gtk12-config
としたところまでは問題なかったのだが、いざmakeしようとすると「strcmp: "has not been declared"」というエラーメッセージが出た。

という経緯でインストールしたX-Chatだが、ちゃんと動くという意味では満点の動作をしている。が、日本語入力に癖があり、筆者にはなんともつらい（On the spot で変換できない？し、変換確定までに押すエンターの回数が他のアプリと違う）。乗り換え先を検討中。

htmlファイルの関連付けは、Konqueror＞kate＞kwrite＞Firefoxの順に優先している。KDEにも、Windowsでいう「送る」機能があれば便利なんだけどなぁ（パテント関係で採用できないのかしら？）。音声データはxmms優先、それ以外のマルチメディアファイルはxine優先で設定した。kmplayer（というかmplayer）とnoatunはほとんど使っていない。

マルチメディアローダー各種とFirefoxをインストールした時点での/usrの消費ディスクは2.5GB弱。大物ソフトウェアとしてはOOoとGnomeが残っているが、入れる予定はないので3GBは超えないだろう。

スラドJで話題になっていたのでskimをインストールしてみたが、まだ使っていない。anthy＋uim＋scimという重ね方（uimとscimの間にはscim-uimを噛ませる）が快適らしいが、Canna＋Kinput2に比べてどの程度アドバンテージがあるのか楽しみだ。skimのみtextprocセクション、その他はjapaneseセクションにある。

また、フィルタリング用にローカルプロクシを入れようと思っているが、PrivoxyとMiddlemanが有名どころみたいだ。どちらもportsから入れられる。

いずれも緊急性はないので、他の部分の設定が煮詰まってから手をつけることになりそう。

uimをispellサポートつきでインストールしようとしたところ、スペルチェック辞書がないと怒られた。辞書を入れるのが面倒なので、いったんportscleanして再度portinstallしたところなぜかコンフィグ画面が出ない（05/11/21加筆：筆者が/var/db/ports/以下のファイルを消し忘れていただけ）。portsのディレクトリに降りてmake clean したあとmake configure してみるが、やはり辞書がないというエラーで止まる。仕方がないのでsysinstallから辞書を入れたらすんなりmakeできた。本当はanthy＞skim＞uim＞scim-uimという順番で入れた方が楽なのかもしれない（?）が、適当な順番で入れた（覚えていない）。

scim-panel-kdeを実行するとエラーが出るのでwhereisしてみると、/usr/local/bin/scim-panel-kdeに本体（シェルスクリプト）がある。エディタで開くと、インタープリタ行が#!/bin/bashになっているので、とりあえず#!/bin/shに直してみたところ、どうやら起動した模様（タスクトレイにアイコンが出るだけなので、すぐには気づかなかったが）。

全般設定＞SCIM全般でモジュール設定をkconfigに変更、詳細チェックボックスをチェックしてロケールを日本語に。プラグインの設定でメインツールバーを消し、Xウインドウの設定からXimをOn the spot に変更。入力ウインドウの設定で候補ウインドウを縦表示にした。全般設定＞Xウインドウ＞ショートカットキーでKanjiを開始に割り当てた。

F10による英数変換、F7や無変換キーによるカタカナ変換、BackSpaceによるひらがな変換（できなくはないが、連文節がまとめてひらがなになってしまう）、数字キーやテンキーによる候補選択はできない模様（そういう機能があるのかどうか自体不明）。テンキーから「/*-+.」を入力した場合直接入力扱いになるようで、日本語入力中にこれらの入力を挟むと変な動きをする。急に直接入力しかできなくなる症状が何度か現れたが、変換エンジンの切替えを行うとなぜか直る。全角英数モードがないせいか、全角英数字の入力方法がわからないのと、中黒が出せない（全角/半角のスラッシュになる）。全角括弧などは普通に変換可能。

Anthyについては、Cannaとさほど変わらない印象。SCIMについては、直接入力/日本語入力の切替えと安定度以外はおおむねkinputよりも好印象（というか、AnthyもCannaも「好印象」をさくっと変換できないのね）。他のアプリでは大きな差は感じないが、X-Chatでの日本語入力はかなり楽になった。

PrivoxyとMiddlemanを両方インストールしてみたが、Privoxyの方はそこそこ普及しているらしく、日本語の解説が見つかったので、Middlemanに手をつけずにPrivoxyのみ利用している（ものぐさなので）。フィルタがPerlっぽいので、Proxomitronよりもすっきりとした印象を受ける。

portsからインストールした直後の状態だと、.xinitに
/usr/local/sbin/privoxy /usr/local/etc/privoxy/config
と書いておけば起動する（privoxyコマンド自体はデーモンを起動するだけですぐに終了するようなので、バックグラウンド指定は必要ないようだ）。デフォルトのlogdir（/usr/local/etc/privoxy/configで指定）が/tmp/（公式ページには/var/log/privoxyがデフォルトだと書いてある）なので、これは変更しておいた方がよいだろう。logdir配下のファイル（デフォルトだとlogfileとjarfile）には、privoxyを実行するユーザーの書き込み権限が必要。

デフォルトで動かしているだけでそこそこの仕事をしてくれているようだが、面倒なのでProxomitronのフィルタの移植にはまだ手をつけていない。

アーカイバの使い勝手にちょっと戸惑っている。zipもlhaも展開できることはできるのだが、自己展開書庫は圧縮形式を決め打ちしなくてはならない（圧縮形式がわかっていれば、unzipコマンドやlhaコマンドで展開可能）。ヘッダを見て圧縮形式を自動判別してくれるアーカイバがあるといいのだが（まあ、自己展開書庫なんてWindows用のドライバソフトやオンラインソフトを入手するときくらいしか使わないので、問題ないといえば問題ないのだが）。

また、書庫内のファイルに表示できない文字が含まれている場合も困る。Ark（KDEに付属する、アーカイバソフト用のラッパー）がもう少し賢ければ嬉しいのだが。

1/20ごろ、KDEを立ち上げてブラウザを開いたあたりでフリーズした。FreeBSDを常用し始めて半年くらいになるが、初めてCtrl+Alt+Delもきかない状況を目にした（Ctrl+Alt+BackSpaceがきかない状況は何度かあったが）。なにをやってもダメなので、仕方なく電源ボタン長押しで強制終了してから再起動するが、カーネルパニックでコンソールが立ち上がらない。

シングルユーザーモードを試してみたところ起動に成功し、/usrパーティションも見えた。fsckをかけたところ/varパーティションで大量の破損ファイルがみつかった。酷使に酷使を重ねたディスク（IBMのDTTA-371010で、多分98年製造のもらいもの）だったので、ファイルの破損がフリーズを引き起こしたのか、強制終了によってファイルが破損したのか、その両方が入り混じっているのか、判断がつかない。ディスクラベルも破損したのか、FDISKから見るとマウントポイントがおかしくなっている（上書きもできない）。/varパーティション以外のデータは無事で、なぜかXも立ち上げ可能。

データ救出などを行ってもよいのだが、ちょうどパーティションを切り直したかったところだし、一度丸ごとフォーマットしてしまおうと考えている（普通に考えるとさっさと捨てた方がよいのだが、まだ動くものを捨てるのもなんなので）。

2008年12月メモ再開。pkgdbの仕様が変わったようで、アップグレードの際に「unexpected file type or format」というエラーが出ることがある。
# rm -f /usr/ports/INDEX*.db /var/db/pkg/pkgdb.db
# pkgdb -fu
（要するに古いのを消して再構築）でいいらしい。詳しくはportsディレクトリ内のUPDATEを参照。