やっとできた。

当時の記憶、日記付けてたとしても怪しいですｗ（えっへん、と胸を張ってみる←やめぃ）

OpenDHTのビルドがマトモになったとはいえ、mrefdに組み込んで動かしてよいものかは結構判断が難しい。組み込んじゃうとリフレクタの情報を流しちゃうので、うっかり何かやらかしてしまうのではないかという危惧が。

確かに観測者によって変わってくるのかも。UNIXワークステーション（PC-UNIXじゃなくSunとかNECとか、研究室に置いてそうな高い奴）で暮らしていた人から見ると全然違う景色になってるんだろうし。

というか今でもああいう人達から見ると、「まだそんなところで…」と言われちゃうんだろうなあ。先達の背中はまだまだ遠い…

このアカウントは、notestockで公開設定になっていません。

どっかの新書だか何だかのCMを兼ねた記事で、価値は創造できることを忘れてしまっているがために日本人は貧しくなった…と言ってる人が居たような気がするけど、何を創造するにしても最低限のリソースは要るんだよな。そのリソースが無い、という「根本的な貧しさ」の視点が抜けていると思ってる。

（まあ情けない話ではあるけれど、トップを取りに行けるだけのリソースが無い以上は「どうやって手持ちのリソースを守りながら今を食いつないでリソースを増やしていくのか」っていう防衛戦をしないといけないでしょうに）

（先陣切ってトップを取りに行く戦略は確かに必要なんだけど、皆が皆それをやってもしゃーないので、トップを狙う人達が取りこぼしたところをうまく攫うとか、トップを狙う人達に寄り添って助けていくことでおこぼれをもらうとか、立ち回りで食ってくのも一つの生存戦略なのかなーって）

まあ何を以て勝ちなのか負けなのかって問題はあるけど…多分ああいうこと言う人達の頭の中だと世界でトップシェア取れるかどうかとかそういう基準かな？

負け技術なんて言い出したらTRONもSuperHもみんなみんな負け技術になると思う。

損な役回りに見合うだけの報酬をきちんと出す、っていうならともかく…出さないだろうなあ。どこの業界だろうと、他人を安く使い潰すことを是としてきたし、それに慣れきってしまった。今更多少景気が良くなって金回りが良くなったとしても、簡単には改まらないよ。

矢面に立つ人…「嫌だよめんどくせえ」でお断りしてきそう（管理職も罰ゲーム、なんて言われるこのご時世だし）。

誰がリーダーになっても散々叩いてきたのだし、今後も叩くんだろうから…そのツケはしっかり甘受するのが筋ってもんだと思う。

ついでに、（Linuxみたいなdesktopが絡む領域になると）日本語化、というので日本人はかなりのdisadvantageが最初からあるからね。メッセージの日本語化だけじゃなく、日本語の表示と入力の問題。

…だから勝てないというつもりはないけれど。

少ないリソースをどう運用するかって問題と、リソースをどう増やすかっていう問題、どっちも下手打ってるのは確か。まあコード書けない人は黙ってよーね、で良い気はするけど…コード書けない人達がうるさいから書きたくなくなるよね。

1990～2000年代って、言うほど日本にOSS定着してたっけ？
2000年でも怪しくて、2002～2003年以降からなんとなく定着しつつあったというのが皮膚感覚なんだけど…まあオッサンの感覚なので怪しいかも。

このアカウントは、notestockで公開設定になっていません。

道交法の目的って第一条に書いてあるけど https://elaws.e-gov.go.jp/document?lawid=335AC0000000105

1. 道路における危険の防止
2. その他交通の安全と円滑を図る
3. 道路の交通に起因する障害の防止

なので意図的な低速走行というのはこの目的に反する以上ギルティ。

ミドルネーム持ってるとか、複合姓とか、いわゆる「日本人的な名前」から外れた名前を持つ人達に対して日本のシステムってものすごく冷たいよね。大して文字数の書けない「姓」「名」の項目にどう彼等の名前を記せと…収まらないケースだって少なくないのが現実だよな（なので非常に失礼な扱いをしてることになるのだが…）。

姓/名の順番を逆に登録してしまったおかげで、マイナンバーカードによる本人確認で「名前が違う」と蹴られているPayPal。どうやって直せば良いのやら…運転免許の写真貼り付けて名前の修正要望出したところで受け付けてもらえるのかどうか。

以前のPRもお塩な対応なので https://github.com/savoirfairelinux/opendht/pull/689 、多分これもお塩を投げつけられるんだろうけど一応出しとくかね https://github.com/savoirfairelinux/opendht/pull/690 。

今度はOpenBSDマシンが突然落ちたんだが…何が起こってるんだろう

Linuxの#!/bin/shってshじゃなくbashとかdashなケースがあるから…（震え声）

ふむ、やはりその都度$save_CPPFLAGSしてという…まあダーティなのかもしれないけど汎用性を求めるならそうしないといかんだろう。このconfigure.acみたいに。 https://github.com/NanoComp/meep/blob/master/configure.ac

基本的にCPPFLAGS += "hogefuga" は使わないで、saved_CPPFLAGS = $CPPFLAGSしてからCPPFLAGS = "$saved_CPPFLAGS hogefuga"しないとダメってことか。

なにそれ…
./configure MsgPack_CFLAGS=-I/usr/local/include MsgPack_LIBS=-L/usr/local/lib JsonCpp_CFLAGS=-I/usr/local/include JsonCpp_LIBS=-L/usr/local/lib
これだとダメで、
bash ./configure MsgPack_CFLAGS=-I/usr/local/include MsgPack_LIBS=-L/usr/local/lib JsonCpp_CFLAGS=-I/usr/local/include JsonCpp_LIBS=-L/usr/local/lib
これなら大丈夫っていうの。

なんかCPPFLAGS += "xxxx"っていうのが気に入らないらしいってのは分かったんだけど。

./configure[3224]: CPPFLAGS+= -DOPENDHT_BUILD: not found
./configure[3237]: CPPFLAGS+= -Dopendht_EXPORTS: not found
:
./configure[18229]: CPPFLAGS+= -DOPENDHT_JSONCPP: not found

なんだこれは

（ダメ親やってます、ごめんなさいってこの場を借りて子供達には謝っておこう）

（一応二児の父らしいです…あまりこういう話、しませんけど）

ああああああマシンの再起動と共にSlackwareの仮想マシン巻き込みやがった…💢

ああそうだ打ち込んでる途中でなんか再起動しちゃったから忘れてたけど…実名プレイなネット生活って実際マゾだと思います。「実名プレイしてる人間の顔にどう泥を塗って社会的に殺してやろうか」って視線、結構感じますし。今後も増えるよきっと。

とはいえ社会人になってから実名プレイ続けてるからなあ…20年は経ってるんじゃないか。なので今更仮面を被れっていうのもなんかめんどくせえなって。

ドライバは2024/2/26版以降新しいのがでてないというのもまた気になるところだな。

おおお、いきなりVIDEO_TDR_FAILUREが発生してブルースクリーンになったぞWindows11（とはいえそこから障害情報収集中→再起動まで画面がそれなりに表示されてるのがすごい）。

しっかし、ここまでArc A770の機嫌が悪いというのはなかなか珍しいな。どうしたんだろう。

このアカウントは、notestockで公開設定になっていません。

お前か！
openbsd-current-vm$ grep CPPFLAGS Makefile
CPPFLAGS =
openbsd-current-vm$

uaa@slackware-vm2:~/opendht-3.1.7$ grep CPPFLAGS Makefile
CPPFLAGS = -DOPENDHT_BUILD -Dopendht_EXPORTS
uaa@slackware-vm2:~/opendht-3.1.7$

これじゃあどう頑張っても-fvisibility=hiddenの縛りから抜けられないよ。

__attribute__((visibility("default")))とかの類は定義できてる

やはり旧来のrc(.d)な作法と、systemdな作法との違いで起こった不幸な事故と考えるのが適当なのかも。とはいえ、世界はLinuxとsystemdだけのものじゃないよ、ということを訴えておかないと面倒なことになるというのも事実なんだろうなあ…

（「だよな」って打ったはずなのに「だよん」って…まあ面白いから良いや）

initにdebug print仕込んでもinitがSIGHUP送ってなくて、OpenBSDカーネルの https://github.com/openbsd/src/blob/master/sys/kern/kern_proc.c#L412 から飛んできてることは分かっていて、デーモン化すればSIGHUP食らわない（回避してる）んだろうなーとなると、多分セッションリーダかどうかで判断してるのかなって気はしてる。

とはいえ、init→/bin/sh→nohupでバックグラウンドプロセスを動かしても死ぬ、ということについての説明がこれだと付かないんだよん。

initの配下で/bin/shによるrcの実行が行われ、その/bin/shの配下でバックグラウンドプロセスが起動すると。で、rcの処理が終わる→/bin/shの処理が終わるので、バックグラウンドプロセスに対しSIGHUPが飛ぶってことか。

なので、動作としては全く間違ってない。間違っているのはバックグラウンドプロセスを動かし続けたいというその考え（だからデーモン化しろと何度言えば💢って怒られそうな話、と）。

そもそもinitから起動する物は「制御端末を持たないデーモン」「処理が完結する各種必要な物」を旨とし、「（制御端末を必要とするかどうかはさておき）バックグラウンドプロセス」ではないような気がする。rcのドキュメントを見てると。

ちょっと途中まで読んで挫折したけどこれなのかなあ、initとかSIGHUP周りの話。
技術/UNIX/なぜnohupをバックグランドジョブとして起動するのが定番なのか？(擬似端末, Pseudo Terminal, SIGHUP他) (2010/11/29) https://www.glamenv-septzen.net/view/854#id3d4712

お金に余裕があったら、86Duino Educakeをもう一台記念に買っておきたいと思っているけどなかなかそんな余裕は無いんだよね…っていうか、まだ在庫あるのか。 https://www.switch-science.com/products/1661

（以前の繰り返しになるけど）あんなTLB bug突っ込んでおいて、何故当時のAMD/Cyrix機でWindows9xが動いていたのかというのは本当に気になる。実はちょっとだけ（誤差と感じられる範囲かもしれないがしかしそこには確実なものとして）Intelよりも不安定だったという事実があったとかそういうことだったんだろうか。

確かめてみたい気がしなくもないけど、もうその時代のマシンは手元に無いんだ…Cyrixの石、再び動く日を見てみたいと思っていても。

※元Cyrix使いでした

なのでpatcher9x( https://github.com/JHRobotics/patcher9x )を使えばAMDなマシンでの仮想環境下でWindows9xが動くという話ではあるんだけど…当時の自分はこれの存在を知らなかったので。

Intel vs AMDか…Windows9xを仮想マシンで使う可能性が少しでもあるならIntel一択って気がする（AMDでも動かせなくはないけど面倒）。

その用途を一切考えなければAMDに行けるんだけど…Bulldozer使ってた頃にこの問題で散々痛い目にあったので今はIntel使い。

The Design and Implementation of the NetBSD rc.d system http://www.mewburn.net/luke/papers/rc.d.pdf これを見てもrc.localから呼び出したコードにSIGHUPを投げつける理由は見当たらず。

今はfork()でゴリゴリやらなくても、daemon()を呼ぶだけでデーモン化可能なのか。何と便利な時代なんだ。

sj3の時はptyを使うのでclose(stdin)とかdup2()とかうだうだする代わりにlogin_tty()に回したとかそういう経緯だったんだっけ。今回はpty要らないしむしろ標準入出力から切り離す必要もあるしってことでその辺のことは考えなくて良いかね。

結局、「作法に則って記述せよ、手抜きは認めぬ」という問題だったということかね。

その「作法」ってのがよー分からんし、時代に即しているか（守るだけの合理性があるのか）という問題はあるけれど。

とりあえず、killjobc()でセッションリーダに対してSIGHUPが飛んでくる→セッションリーダでないこと、が条件となるとデーモン化しか思いつかないんだけどね。

これってsj3とかのコードでも出てきた、プロセスグループとか端末のdetachとかその辺の問題に関係してたりする…？

なんとなくなんだけど、ちゃんとfork()使ってデーモン化したものを/etc/rc.localから呼び出せよ？という意図だったりする？テキトーにhogefuga &で逃げんな、って。

killobjcじゃなくて、killjobcか。sp->s_ttyvpが非NULLの物にSIGHUPを投げつけてると。

signal_checkを3つ起動していて、全てSIGHUP食らって落ちてる。何故killobjcを呼び出したかを追う必要があるか。

Mar 17 09:05:00 openbsd-current-vm signal_check: signal 1
Mar 17 09:05:00 openbsd-current-vm last message repeated 2 times
Mar 17 09:05:00 openbsd-current-vm /bsd: killobjc: SIGHUP 0xfffffd813d879f00

でもまあよく考えてみればnohup越しに起動してもSIGHUPが飛んでくる以上、initが絡んでいる可能性は低いと読むべきなのか。カーネルがプロセス番号をしっかり握っている訳なのだし。

このアカウントは、notestockで公開設定になっていません。

カーネルの起動～init辺りを起動する前後までの動作を追うのってどうするのが手っ取り早いんだろう。とりあえずprintf()仕込みまくりで、で対応できそうな気がしなくもないんだけど（エレガントではないのは分かってる）。

※割り込みとか扱う場合だとprintf()デバッグ以外の方法を考えないと困るケースはある…

initにdebug print仕込んでみたけどSIGHUP投げつけた形跡はない…ってことは、カーネルの仕業なんだろうなあ。