I know I believe in nothing but it is my sweet nothing.:最新 5 日分

2022/09/26(Mon)

[宗教] ThinkPad X61とWindows 10とホットキー機能統合

ThinkPadのホットキー機能統合、X61向けの最終バージョン(8jvu43wj/3.89.0100)だとWindows 10でFn+F5キーが有効にならないのだよね。

これはOSのバージョンの問題で、Windows 7まではFn+F5キーは有効になるのだがWindows 8以降だとFn+F5キー拡張はインストールされなくなっているのである。

このホットキー機能統合はいくつかのソフトの集合体なのだが、このファンクションキーについてはOSD(オンスクリーン表示)ってのが相当する。

展開したファイル中のOSD\tphk_tp.infというセットアップファイルを覗いてみると

[DefaultInstall.LH.NTamd64]
CopyFiles=SHTCTKY.files,MKR.files,MKR.Res.files,UEFIOSD.files,OSD.files,OSD.Res.files,FnF5-OLD.files,FnF5.Res.files,FnF8.files,FnF9.files,FnF2.files,Runtime.files,AVAYA.files,FNF5.Qualcomm.Runtime.files,MicMute.files,NumLock.files,FNF6.files
DelFiles=Drivers.2KXP.files
...
[DefaultInstall.W8.NTamd64]
CopyFiles=SHTCTKY.files,MKR.files,MKR.Res.files,UEFIOSD.W8.files,OSD.W8.files,OSD.Res.files,FnF2.files,MicMute.files,FNF6.files,NumLock.files,EXTAPSUP.files

DelFiles=FnF5-OLD.files,FnF5.Res.files,FNF5.Qualcomm.Runtime.files,FnF8.files,FnF9.files
...

はい、インストールスクリプト中のLH(LongHornつまりWindows Vista)とW8(Windows 8)の差をみるとFn+F5以外にも

も消されてるもよう、前者はよくわからんけど後者はWindows 7の時点でスタートメニューの電源ボタンから解除できたから不要だねってところか。

同様に無線のOn/OffもWindows 8以降はタスクトレイから無線の機内モードの制御ができるようになったので、重複機能として消しちゃおうってなったんだろか。 ちょうど同じタイミングでWindows 7の時点でタスクトレイからアクセスポイント選べるしこれ要る?感のあったAccess Connectionも提供されなくなったしね。

ちなみに今のThinkPadを名乗るノートパソコン(絶対に許さないよ)ではFn+Fキーの割り当ては 一新したのだね、欲しいと思わんしそもそも買う金もねーからどうでもいいけど。

ところがこれで困るのがThinkPad X61のBluetoothなのだ、不思議なことにこの機種は

という謎挙動を示すので、Fn+F5キー拡張が削除されてしまうとBluetoothがどうやっても有効にできなくなってしまうのだ。 まぁワイはBluetoothデバイスひとつも持っておらんのでどうでもいいっちゃいいのだが。

この対策について最も簡単な方法は、Windows 8以前にリリースされた古いバージョン(8jvu23wj/3.81.0100)を使うこと。 OSチェックなしに問答無用でFn+F5キー拡張をインストールしやがるのでこの問題を回避できる。

ただし8jvu23wjについてはWindows 10 1903以降だと

という問題がある、前者については互換性データベースに登録されるてるようで警告ダイアログまで出てしまうのだ。

手動インストールであれば警告を無視してセットアップを続行し、インストールするアプリから両者をを除外すればいいだけである。 そもそも前者は何してるのか効果のほどがさっぱり判らん(ウインドウ位置やスクロールバーを調節するらしいが)。 後者はSystem Update経由でBIOSやドライバの更新に必要なやつっぽいけど、サポート切れのハードに更新が降ってくるわけでもないのでな。 つーかどっちも8jvu43wjで消されとるし不要なんやな。

しかしこの互換性データベースによる警告、こいつが自宅システム管理者からすると困るのだ。 というのもunattended.xmlなどで実行するサイレントインストールがこの警告ダイアログによって無効になってしまうのよね。

ホットキー機能統合のドキュメントには

コマンド ラインによるインストール (Unattended インストール)

  この方法は、システム管理者のみが使用します。

  1.「手動インストール」の章を参照して、ファイルのダウンロードと展開を行います。
  2.「インストール」の手順 12.で「...をインストールする」に付いているチェックマ
     ークを外し、「完了」をクリックします。インストールがキャンセルされて、ファ
     イルの展開で終了します。
  3. /S オプションを追加して、コマンド ラインで setup.exe を実行します。
     (例) [パッケージを展開した先のパス]\setup /S

とあるのだけど、警告ダイアログで遮られてバッチインストールが止まってしまうんですわ。

とはいえシステム管理者がいまだにX61を使い続けて、しかもWindows 10/11のインストールに自動セットアップを用意する酔狂な真似をするはずもないのでこれは仕方無い、俺を除いてな!

ということで自動セットアップのために

という作業が必要なのだ、アークソクソ。

あと以前のThinkPadにはActive Protection Systemという本体の加速度センサーで衝撃を検知してヘッドを退避するんだかでハードディスクの損傷を防ぐソフトがあったんだけど消えちゃったんだな。 まぁ最後のバージョンが1.82.0.20/n1msk20wと判ってればLenovoのサーバーから拾ってくるのは容易いのだけど。

もうSSDが当たり前で未だにHDD使ってる貧乏人とか知るかって話なんだろうけど、ワイんちでは現役だからな ただWindows 10対応してるはずなんだがタスクトレイの通知とコントロールパネルにアイコンが表示されない問題があって動いてるのかよくわからんのだよな。 マシン揺さぶってみるとHDDのランプ消えるから動いてはいるみたいなんだけどね

ということでこのへんの非互換性もそのうち調べんとな、あーあほくさ。

2022/09/21(Wed)

[386BSD(の子孫)ソースコードシリーズ (334)] sys/cdefs.hとは何ですか?番外編 - __UNCONST()マクロとは何か?

以前書きかけてもう長いこと放置してる 連載記事をちょっとだけ復活、というのも128bitポインタ時代に備えよみたいなことを6億円振込を待つ世界緊急放送で受信したので。

要はUN*X方面だとILP32/LP64を前提としてポインタをlongとして扱うクソコードが大量に残っていて

というお話でいいんだっけ、つーかお前ら128bitポインタ時代にまだC言語使う気ですか(戦慄) intwidest_tといいもうCは捨てようぜ。

まぁワイは将来P128/LP128と呼ぶのか知らんがその頃には生きてないからどうでもよろしい、生き延びてもSandyおじさんだろうし…というか現在C2Dおじさんまで退化している(X61でこれ書いてる)。 ところで128bit CPUって命令セットはx86_128なんですかやっぱり。

ちなみにCの仕様だとint64_tは対応するbuilt-in typeが無いなら実装してはならない、なので代わりにint_{fast,least}64_tを使えが正しい。しかし世の中そんなコードはまず存在しないというのは 以前にも書いた通り。そうintN_tを使ってる時点でそれはILP32とLP64の間でしか移植性は無いのだ(無慈悲)。

ところでワイにとってはカーネルって道頓堀に沈んでたおじさんの像でしかないので、sysの下とか全く知らんからそんなに大量にポインタをlongで扱ってるコードが生き残ってるの?という感じではあるな。 クッソ適当に知識多く知恵少なきインターネットを検索すると通信用語の基礎知識の LP64の項に

ポインターをint型に代入するようなプログラムは移植できないが、long型に代入するようなプログラムは
データ長が同じため問題が顕著化せず、そのまま移植することができる。

UNIXでは伝統的にポインターをlong型変数に入れて使う傾向にある。
例えばコールバック関数の引数でunsigned longにポインターが入っており、これを(void *)などで
キャストして使う、といったこともよくある。そのため、このデータ型モデルが採用されたものと思われる。

なんて書かれてるけどさ、今年ってさぁ ISO/IEC西暦2022年だよね…

あっそうだ(唐突に本題)、ワイの知ってる範囲でもconst外し(関節外しみたいなんやなw)マクロであるcdefs.hの__UNCONST()でポインタをunsigned longで扱っとるから移植性ないよねこれ。

/*
 * The following macro is used to remove const cast-away warnings
 * from gcc -Wcast-qual; it should be used with caution because it
 * can hide valid errors; in particular most valid uses are in
 * situations where the API requires it, not to cast away string
 * constants. We don't use *intptr_t on purpose here and we are
 * explicit about unsigned long so that we don't have additional
 * dependencies.
 */
#define __UNCONST(a)    ((void *)(unsigned long)(const void *)(a))

まぁマクロなのでここ一か所だけ修正すりゃ終わりなんだが、逆にマクロ使わずにconst外しをunsigned longでやられてると修正が大変になるパターンではある。

なおこの__UNCONST()マクロ、なぜダイレクトに非const型にキャストせずこんなもんを介すのかというと、gccに-Wcast-qualというオプションつけるとconstから非constへのキャストは警告の対象になってるからなんよね。 そしてNではbsd.sys.mkでWARNS>2がMakefileで指定されてると-Wcast-qualが有効になりかつ-Werrorがデフォルトで有効なのでコンパイルエラーになるのだ。

.if ${WARNS} > 2
CFLAGS+=        -Wcast-qual -Wwrite-strings
CFLAGS+=        -Wextra -Wno-unused-parameter
...
.endif

でもさ、そもそもconstから非constへのキャストは何らかのミスの可能性があるってだけで、仕様としては合法なので-Werror -Wcast-qualして警告をエラーとして扱ってるのが間違いなんじゃね?ではあるんだよね。 ということで脳死でいたずらに警告レベルを上げた結果、いらんマクロを発明してしまったんじゃねえかなぁこれ。

ちなみにOでは__UNCONSTみたいなものは用意せずそのまま非constにキャストして-Wno-cast-qualしてたはず。

とはいえ合法だがconstを外すなと古事記とセキュアコーディングガイドにも 書かれているよねって原則論が無いわけではない、しかしmalloc(3)したメモリをconstポインタに代入したけど、free(3)する時に元の非constポインタが残ってなくてconstポインタで開放したくてconstを外すなんてコードにはよく遭遇するからな。 というかそういうコードが出す警告のために__UNCONST()の99%は使われてるんですわ。

そしてNだとサードパーティー製のソフトウェアをsrc/external以下に大量に抱えてるのだけど、いちいち-Wcast-qual対策で__UNCONST入れてってるのよね。 非常にめんどくさい作業だし、バージョン上げる際にvendor importするとその部分でconflictも発生しかねないわけでさ、なるべく差分は最小にとどめたいのに。 できればオレオレN6ではOみたいに-Wcast-qualをエラー扱いにするの止めたいんというお気持ち。

そんで128bitポインタ問題に話は戻るけど、Fにおける同機能に__DECONST()マクロがあるんだけどこっちは__uintptr_t(C99のintptr_tの内部型)を使ってるのでこちらでは発生しない、ただしいちいち_types.hもインクルードする必要があってより差分が増えるのである。

#ifndef __DECONST
#define __DECONST(type, var)    ((type)(__uintptr_t)(const void *)(var))
#endif

つーか_types.hはcdefs.hをインクルードしてるので本来なら循環参照じゃねえのこれ、ガード入ってるから誰も気づかないだけで。 そもそもcdefs.hはMI/MDを扱わない *1のでこの中でintptr_tを使うのは実装として変なんだよな。

でもこのシリーズ中で以前も説明したけど、cdefs.hの役割というのは

の黒魔術、よってコンパイラの警告対応だからcdefs.hに実装するのはそれはそうであって悩ましいのである。

本来ならコンパイラ側に局所的に警告を抑制するpragmaなりattributeが欲しいとこ、lint(1)なら/*LINTED*/コメントで抑制できるんだけど。 いまだと翻訳単位(ソース単位)でしか警告オプション切り替えられないからな。

ただコードを書き換えるにつれ一度は警告を抑止した部分が突然牙を剥いたりすることもあるので、やっぱりコードそのものを正しく書き直せが正解かな。

*1:ただしa.out/ELFのようなobject formatの差異はここで扱う

2022/09/20(Tue)

[セキュリティ] doas(1)のpersistオプションはなぜOでしか有効にならないのか

昨日の件、Oのtty(4)にVERAUTHというユーザーセッションで認証が成功したかを表すフラグ持ってるんだな。

TIOCSETVERAUTH int *secs
	Indicate that the current user has successfully authenticated to this session.
	Future authentication checks may then be bypassed by performing a TIOCCHKVERAUTH check.
	The verified authentication status will expire after secs seconds.
	Only root may perform this operation.

TIOCCLRVERAUTH void
	Clear any verified auth status associated with this session.

TIOCCHKVERAUTH void
	Check the verified auth status of this session.
	The calling process must have the same real user ID and parent process as the process which called TIOCSETVERAUTH.
	A zero return indicates success.

そりゃOにしかない機能だからFやNでは動かんですわ、ってかdoas.conf(5)のマニュアルのpersist周りの記述にちゃんと書いておいてほしい。

ただこいつをオレオレN6で取り込んでもダメ、というのもVERAUTHのチェックとセットをやってるのがBSD/OS由来の認証システムであるBSD Authを呼び出す関数の中に入ってるから。 なおFやNはBSD Authを採用せず、Linuxなどでも使われてるよりメジャーなPAMのBSDL実装である OpenPAMを採用してるのでこの部分のコードは通過しないのやな。

224 #if defined(USE_BSD_AUTH)
225 static void
226 authuser(char *myname, char *login_style, int persist)
227 {
228         char *challenge = NULL, *response, rbuf[1024], cbuf[128];
229         auth_session_t *as;
230         int fd = -1;
231
232         if (persist)
233                 fd = open("/dev/tty", O_RDWR);
234         if (fd != -1) {
235                 if (ioctl(fd, TIOCCHKVERAUTH) == 0)
236                         goto good;
237         }
238
239         if (!(as = auth_userchallenge(myname, login_style, "auth-doas",
240             &challenge)))
241                 errx(1, "Authorization failed");
...
263 good:
264         if (fd != -1) {
265                 int secs = 5 * 60;
266                 ioctl(fd, TIOCSETVERAUTH, &secs);
267                 close(fd);
268         }
269 }
270 #endif

上記の235行目、もしdoas.confにpersistが含まれていればtty(4)にVERAUTHフラグが立ってたら認証済みとして認証を行わない。 そして266行目、5分間のタイムアウトを指定してVERAUTHフラグを立てるちゅー感じ。

機能としては独立したものなのでBSD Auth vs PAM関係ないのだけども、いちいちtty(4)をかってに改造(尻穴に乾電池感)して新機能を追加するのも手間だなぁという。

ちょっと調べたら Oのdoas(1)ではなくそのfork版の OpenDoasはPAMでもpersistをサポートしているもよう、というかforkしてOとは無関係なのにさらにOpenがつくのでもはやOpenとは何かという宇宙猫の顔になる。

というかOpenをforkしたら次はLibreってのも意味わからんけどな!(OpenOffice/LibreOfficeやOpenSSL/LibreSSLの方を見ながら)

こっちの認証済チェックの実装は/var/run/doas以下に一時ファイル作ってそのタイムスタンプを確認という方法なもよう、詳しくは これ、かつてsudo(1)でも散々認証バイパスの脆弱性やらかした不安を感じる方式だけど、妥当な実装かはまた次回sudo(1)と共にコードちゃんと読みますかね。

余談であるがPAMとBSD Authの最も大きな違いは

である、Oは基本的に

あたりでPAMを採用する理由が一ミリもないと考えてると思われる。ちなみにOがCitrus XPG4DLを採用しなかった原因も同じ。 正直言ってパラノイアすぎるがまぁ部外者がどうこういってもしゃーないので以下略。

ちなみにNの場合full dynamicaly linked rootだけど、/libを消してしまったみたいな事故が起きても/rescue以下にcrunch binary化(すべて単一の実行ファイルにしてハードリンクで呼ばれた名前で動作を変える)された/binおよび/sbinのコマンドがあるので困ることは無いはず。

2022/09/19(Mon)

[セキュリティ] sudo(1)からdoas(1)へ

かつてPOSIX:2008で導入されたopenat(2)などのcwd race condition回避のsyscall、なぜかN6だと単にENOSYSを返すというクソ迷惑な実装になっているのである。

int
sys_openat(struct lwp *l, const struct sys_openat_args *uap, register_t *retval)
{
	/* {
		syscallarg(int) fd;
		syscallarg(const char *) path;
		syscallarg(int) flags;
		syscallarg(int) mode;
	} */
	return ENOSYS;
}

一応ヘッダファイルでは_INCOMPLETE_XOPEN_C063というガードをかけて不可視にしてはいるんだけどね。

/*
 * X/Open Extended API set 2 (a.k.a. C063)
 */
#if defined(_INCOMPLETE_XOPEN_C063)
int     linkat(int, const char *, int, const char *, int);
int     renameat(int, const char *, int, const char *);
int     mkfifoat(int, const char *, mode_t);
int     mknodat(int, const char *, mode_t, uint32_t);
int     mkdirat(int, const char *, mode_t);
int     faccessat(int, const char *, int, int);
int     fchmodat(int, const char *, mode_t, int);
int     fchownat(int, const char *, uid_t, gid_t, int);
int     fexecve(int, char * const *, char * const *);
ssize_t readlinkat(int, const char *, char *, size_t);
int     symlinkat(const char *, int, const char *);
int     unlinkat(int, const char *, int);
#endif

しかしlibcにはopenat(2)のシンボルは存在しとるのでな。

$ nm /usr/lib/libc.so.12.181 |grep openat
0000000000039e50 T openat

よってautoconfのAC_CHECK_FUNCS([openat])だけで雑な存在チェックするお行儀の悪いconfigureスクリプトだと動かないopenat(2)を使おうとして盛大に壊れるのだよね。

そんでつい最近もsudo(1)がopenat(2)を使うようになってあえなく爆発四散するようになったので表題のイベントなのである。 まぁ本来なら

なのだが、難易度は易いがとにかく気分的にめんどくせえ。 それに前から興味があったのでsudo(1)からdoas(1)へスイッチことにした。

このdoas(1)ってのはOpenBSDがどんどん複雑になるsudo(1)に見切りをつけて書いた車輪の再発明、まぁほとんどのsudo(1)の機能いらないのでよりシンプルなやつで。 それにしてもpersistオプションが有効なのOだけで毎回パスワード入力求められるの何故なんですかね、そのうちソース読むか

これでパスワード間違えてもsudo(1)に罵倒されることが無くなるのは寂しいですね、というか今では罵詈雑言メッセージって--with-all-insultsつけないとならんから若い人は知らんか。

今の時代あの海兵隊ですら罵倒は厳禁なので、sudo(1)メッセージをお嬢様化して刺々しさをなくす sudo(1)お嬢様部なんてものが存在するのである、ほんのちょっとだけおハーブ生えましたわ。

ところでdoas(1)の文字をみてInfinityって勝手に脳内補完されるのって結構な高齢者ですよね、名前だけは知ってるけど曲はまったく聴いたことないです。

[自宅死捨無管理者] 無線LANあれこれ

我が家の無線LANはいまだに NETGEAR R6300v2なのだがこの子をDNSサーバーにするとなぜかMS EdgeでDNS_PROBE_FINISHED_NXDOMAINが頻発するのだよな、というかMS Edgeの問題でなく普通にnslookupが失敗しとるなこりゃ。 以前は問題なかったのだがどっかの時点でファームウェア更新かWindows Updateいずれかでおかしくなったと思われる。

もう購入後10年近いしサポートもとっくにEOLゆえ新しいファームも出そうもないのでWireSharkとか持ち出して原因調べる気にもならん。 とはいえ11axも高いし来世で買うわだし、そもそも子機がどいつもこいつも11acすら対応しておらずいいとこ11nなのでR6300v2ですらオーバースペックなんやな。

一番いいのを頼むといって出てくるのが Intel Ultimate-N 6300なので802.11nで450Mbpsだもん、いやー11ac 1300Mbps機なんかまるで生かされてねえ!

そもこのR6300v2を買った理由は11acよりもUSB3.0ポートがついてて簡易NASに使えるかと思ったのが理由なんだが、まったくUSB3.0の速度が出なくて実用にならんかったのでちゃんとしたNAS買ったのだ、やっぱり金ドブじゃねえか。 それどころかDLNAサーバーとしても使い物にならなかったのは 以前書いた通りなのである。

それじゃ子機を先に買い替えるかといっても、今やmini-PCIeではなくM.2の時代なので、X220に Intel AX200あたり載っけるには変換下駄履かせてとなるのであまり気が進まない。 かといってmini-PCIe最後の世代である Intel 7260もBluetooth4.0のコンボカードなのだよな。

いちおうX220は Intel Advanced-N + WiMAX 6250というUSBコンボカードが標準でご用意されてたのでmini-PCIeスロットにUSBの線も来てるとは思うのだが、ネットの先行者によるとピンマスクなどの細工をしないと正常動作しないらしい、やっぱ気が進まんな。

つか一番最初にどうにかしないとならんのはThinkPad X61に刺さってる Intel 4965AGNなのよね、こいつは最終版のドライバがバグっとるのでWindows 8以降だとサスペンド復帰後ネットワーク繋がらなくなるなどの不具合があるので有名。 ちなみにデバイスのプロパティから「電源の節約のために、コンピューターでこのデバイスの電源をオフにできるようにする」のチェックを外すとこの問題は回避できる。

ところがこいつ別の問題も抱えていて、やっぱりWindows 8以降だとおよそ数時間おきにDRIVER_IRQL_NOT_LESS_OR_EQUAL NETwLv64でBSoDしてくれやがるのだ。 いちおう回避策として802.11nモードを無効にする方法もあるのだが、さすがにただでさえ遅いネットがこれ以上遅くなるとか死ねと申すか。

それとは別の回避策に 古いドライバを使う方法もあるのだが、ネットサーフィン程度では落ちなくなるけどちょっと大きなファイル扱うと刺さるのだクソが。

そもそもこのカード、本来は40Mhz/300Mbps可能なんだが電波法の改正絡みで日本向けだけ20Mhz/144Mbpsでしか繋がらんようにロックかかってるのよな。 ということでカード自体を窓から投げ捨てたいのである、まぁBIOSのホワイトリスト問題とかあるけどそこはまぁ以下略するとして

とりあえずしばらくはX220を修理するまではそこから引っこ抜いた Intel Advanced-N 6205を流用するって感じで。

2022/09/12(Mon)

[宗教] ThinkPad X220 3号機が壊れた

もう夏も終わりというのに動画流した程度でフリーズするので、CPUファンのグリス不良かなと思い解体して再塗布したのだが一向に改善しない。 そもそも熱暴走ならサーマルスロットリングあるいは最悪でも強制シャットダウンなのに、フリーズする自体が札幌ドーム(何か変だな)なんよな。

このフリーズが発生すると画面が白一色とか緑一色とか清一色あるいは九蓮宝燈あンた背中が煤けてるぜ状態になるので、電源ボタン長押ししてシャットダウンさせ再起動するのだが通電はするのだけど起動ロゴが出ないのよね。 よく筐体が冷えるまで放置すると何事もなかったように起動するのだが。

もうおわかりですね、どう見てもBGAはんだのクラックです本当にありがとうございました。BGAってベックボガート&アピスっぽい(ここで「迷信」のイントロが流れる)。 そもそも買った時から動作不安定ジャンクだったし前オーナーの頃からアカンかったんやなきっと。

そいやフリーズする前からもキーボードの左右中央クリックが効いたり効かなかったりで不安定だったのもシステムボード原因だったんだなぁとようやく思い至る。 このマシンだけ頻繁にキーボードがブリックる(動詞)こと多かったけど、ずっと怪しい中華業者に不良品掴まされたんだと思ってたわ、うわー金ドブ。

つい先日も一枚英語キーボードダメにして新しいの買うのも円安で財布がツライさんなので、中古で本体買ったときについてたボロボロの日本語キーボードで英語配列入力してたのだ。 つーかもう純正のX220用の英語キーボードって入手難しくて、eBayやAliexpressで売ってるのだいたい怪しい中華業者がわざわざ工場ライン作った互換品もとい偽造品なので品質があまりよくないらしい。

他にもX220はパームレストなんかも偽造品ばっかで、ひどい業者にあたると型ガタガタでチリ合わないし交換したその日にパーツ割れるしなんなら到着時にはすでに割れてるくらい脆かったりする、先日そういう業者にあたって返金させたぞ。

そんな満身創痍状態でも懲りずに信仰を続けていたのだが、昨日ついにセンサー拾えないのかCPU温度が0になってファンが回らなくなったのでtpfancontrolで強制的にフル回転させてたのだが、ついには映像出力に赤い縞ノイズがのりはじめたので運用を諦めた。

最後のあがきとしてお決まりのリフロー試みたかったのだけど、一家に一台ヒートガンなんてあるわきゃないのでヘアドライヤーで温めてみたのだが、まぁ溶融温度に達するわけもなく余計にクラックが進行させただけのようで完全に起動しなくなった、ち~ん(笑)。

困ったことにちょっと前まではX220のシステムボードの中古はようけ出品されとったけど今はほとんど無いのよねぇ、X230ならそこそこタマあるけどX220用のキーボードを使うにはいろいろ加工しないとならんのがネック。 かといってX230のキーボードを買うってーとベゼルとパームレストも流用できんから新規購入になるしそんな予算は無いのでな。

なおX220とは別にX200sもお冷のコップを落下させて液晶水没とかやらかしてるのだ、泣きながらLCDユニットバラし反射板を洗浄して汚れ落としたのだけど、落下のショックで白い帯状の圧迫痕だらけになってしまってな。 この圧迫痕ってやつは反射板のいちばん最後尾にあるアクリル板が細かくひび割れた状態になってるからなので、他から移植するくらいしか直しようがないのよね。 そんな偏光板や液晶だけダメだけど反射板は運よく生きてるジャンクを探す方が難しい、運よくX201の上半身をお安く入手できたのでそいつと交換する予定。

あとX201もHDDが死んどるのだよね、10年使って使用時間4万時間超でバッドセクタは無くてもしばしば異常な速度低下も起きてたしお前の辞書に予防交換の文字は無いので?案件なのだが。 でもさーSSD普及でHDDは遅いものと刷り込まれてたし、無理矢理Windows 11なんぞ入れてたからどうせバックグラウンドでろくでもねえ情報収集でもやってんだろうと思って放置してたのが災いした。 ヘッド死んで起動しなくなりました、根性で一度だけ再起動させフォトショのアクチ解除には成功したし、データはほぼNAS上だったので被害自体は最小限だったのが幸い。 だがもう手持ちの2.5inch SATA HDDの在庫が無いので、余計な出費はやーのやーのなのでまたいずれどっかで部品余るまで放置。

ということでこうなると空いてるマシンがX60sしかなくなるのだが、こいつはそこらのスマホより非力なのでネットサーフィンすら厳しい状態。 しかたないので音楽マシン用のX61を一台潰してしまった(つーかX220の1・2号機は2013年クライマックスシリーズ能見さんのように温存する意味が自分でもわからん)。

音楽マシンもそろそろCore2Duoだと動かないVSTプラグインとかあるのだが(SONiVOXのEssential Keyboard Collectionがそれ)、サウンドカードがE-MU 1616mといういまどきCardbusのやつなのがね。 もうE-MU PatchMix以外の新しいソフト覚える気が無いのであの不格好なExpressCard/Cardbus変換アダプタ買うしかないんですかね、というかもうそれすらも入手が難しいかもしれん。

そういや富士通LIFEBOOKは日本企業のレガシーに寄り添いCardbus/PCMCIAスロット搭載の機種をSandyだかIvyだかの頃までご用意してたんだよな、さすがに現行機種では無くなったようだが。 トラックポイントでなくタッチパッドなのとサイズと重量は我慢するにしても、いくらなんでもあのひっどい筐体デザインだけはねーわなので買わないけど。 つかほんとCardbus/PCMCIA資産はどんずまりでなぁ、せいぜいモデムカードがUSBアタプタで使えるくらいか。 その一方でExpressCardなんぞ元から使い道がないのでThinkPadもLIFEBOOKを見習うべきだったね、なおかつて私はExpressCardの事を「喪女穴」と呼んでたわけですが今だと普通にポリコレでアウトですね、死刑。

ちなみにEPSONはスリムデスクトップでも構成でPCI ExpressでなくPCIスロットのライザーを今でも選ぶことができるのでレガシーに縛られた人には優しいのだが、ノーパソとCardbus/PCMCIAにも救いの手をくれませんかね。