2023-08
知った
みた
いやなんで GUI だと scope 使えないんすか，ありえなさすぎる
Git のコンフィグって includeIf を使って色々な条件で読み分けられるらしい やった
洗濯
映画
買い物
料理
↑で一日終わったのありえなさすぎる
https://scrapbox.io/files/64dcf37bdc757c001cdfee30.png
やる
若干リソース消費が心配ではあるが……
やった
HTTP Proxy が不安定すぎてメトリクスが飛んでた
これできてしまうんだよな，人数制限とか頑張ってかけてるけど意味ないんじゃないか
バイナリビルドもしてるので「containers」ではなくなってきた気もしている
build とかになっちゃう
Nix はまあ便利ではあるのだが，ビルドに関しては明らかに Earthly に分があるという気持ちに キャッシュ機構とかまあかなり微妙な部分ではある
ビルドツールがキャッシュ機構を持っている場合，buildkit のキャッシュマウント機構が使える Earthly のほうが強い Nix は derivation 以外を分解点にできないので1つの derivation の計算時間が大きいとそれに引きずられる あれは基本的に弱くて揮発性のノードを大量に起動して分散させるというアプローチなので
可能な限り1ステージに1ノードを持たせて Artifact やキャッシュとして分散させてほしいんだよな
それらの書き込みが意外と重いみたいな問題はあるにせよ
ライナーノーツを読むとわかるがインタラクティブなトラックの導入をしようとしていたり(流行りだ)するので長くなっているみたいな側面はありそう
仕様変更によるボツ曲もあったらしい
さらに言えば終盤における諸々を考えればもっと長くなる気があったんじゃないかと思ってしまう
もしかして BIRD が同一 L2 セグメント内なら next hop を直接到達できるものにして送ってくるのって L3 ルーティング容量が足りないオタクのためじゃなくて IX の Route Server のため？ そりゃそうだろ
実は RPKI 有効にしてビルドしてたつもりが libssh に依存できていなかったのでなおす RPKI は様々な transport protocol をサポートしているらしい
なぜ？
め，めんどくさい……
依存関係がハチャメチャに壊れる
別物っぽい
そもそもこの周辺のコードが2004年(!)からアップデートされてない
誰も RPKI SSH transport なんて使ってないんじゃないか？
どこかのタイミングで libssh なしで rpki 有効(=tcp transport しか使わない)にできるようになったらしくて……
昨日の試行から，クロスコンパイル自体より古い環境に向けてビルドすることのほうが難しいことがわかった
こうなってしまった場合，nix はあんまり役に立たない nixpkgs はパッケージリストであり，NixOS というディストリビューションを構成している
Nix の表現力をもって古い nixpkgs からパッケージを引っ張ってくることもできるが古いドキュメントは無いので単純なこと以上のことをする(e.g. クロスコンパイル)は難しい ↑の余談
C/C++ のエコシステムは configure make make installする(=コンパイルした環境の上で動かす)ことを前提にしている
クロスコンパイルの概念を持ってきたとしても基本概念は同じで，コンパイル時に入っているバイナリと同じ(正確には互換性がある)バイナリがその位置に配置されている環境で動かさないと動いてくれない
この問題に真面目に取り組む(配置先でのバイナリの配置とかを頑張って考えたりする)のは無理があるので，ディストリみたいな概念を導入して共有ライブラリの依存関係と配置を固定してしまうことで解決しているという理解
debian だとアーキテクチャ非依存みたいな入り方をしていて，なんかそういうことするためにすごい大きいパッチセットを管理しているという話を聞いたことがある 真面目に取り組むという方向もあって，共有ライブラリをバンドルするみたいな
2020年代に生きる我々としては理解しがたい前提と運用だとは思う
やる
birdc (クライアント)が readline を要求するので他ライブラリが絡むクロスビルドになる BIRD も readline も nixpkgs にあるので pkgs に対して stdenv を置き換えてビルドする方向でなんとかならんか？ 外部ライブラリに依存する場合，多分 mips-linux-gnu に対してコンパイルする必要があって
環境に存在する so は当然環境に存在する libc を動的リンクすることを前提にコンパイルされているので
多分シンボル名が衝突しておしまいになってしまう
古〜い glibc をターゲットにするやつ
zig は glibc >= 2.33 じゃないと死ぬ？
2.33 という数字はおそらくこのあたりと関連している
詰んでね？
mips64 はさらに壊れているので本当に使いものにならん
諦めて，Nix の持つ環境分離機構を使って gcc の MIPS 向けツールチェインを用意して頑張ってビルド cross compiling w/ old glibc，むずすぎる
知った
Sway - For showing how 2 do stuff the overkill way
なんか前見た気がする
ウィンドウ共有をサポートする？
このへんで wayland のプロトコル拡張をしてやっていってるらしい みた
はやE
考えている
VyOS のコンテナ立てる機構は雑に使えて便利なんだが，イメージ管理であったり(VyOS 全体に言えることだが)独善的なラッピングがしんどかったりするので自力でサービス管理したほうが究極的には楽なのかもしれない コンテナで立ててユーザスペースモードになってることの弊害はそれなりにある
それはそれとして各ノード上において自前で管理するべきものが増えていっているのは何とかしたい
様々な事情により付属の FRR (系列の何か)ではなく BIRD を使っているので管理するべきものが増えている rsync で /config/user-data/bin にバイナリを放りこみ，mitamae で systemd unit と，それらのファイルを適切な場所にリンクするスクリプトを配置するという運用をしているが，もうちょっとマシにならんか？という話ではある VyOS (と EdgeOS)のコンフィグ管理もうまいこと自動化できないか……と思っているが色々と難しいし root 相当で動かさないと何もできないが root 相当では動かしたくなくない？といった悩み
おもった
エンジニアが組織とか言い出す前の最期の輝き
組織の話というのは半分くらいはスケールアウトのたのしみなのではないかという仮説を持っているが，それをするのはスケールアップの限界を知ってからにしたいし，そうなっていてほしいという信条に近い
上の表現は露悪的すぎるが……
まあなんか「気付いたら一人ぼっちになってた」みたいなのは普通にあるよな
「お、おい…みんな、(以下略)」と思うことがないわけではない
それはまあ各自専門性な方向に進んでるわけで文脈共有のコストは日々上がっていくし，人がやっていることにいちいち口を挟むのも微妙だし，分かっている者同士なら語らずとも通じ合えるのではみたいなことを考えて易きに流れがちだけれど(後者2つは主に自分のことだ)，最近はこれをやってて面白いとか，そういう話を時間も考えずにやるみたいな努力を払ったほうがいいのではないのか
時間も日々高価になっていくのでつらい，どうしてそんな……
人間関係における老いから逃れようとする足掻きとして
しかしまあ一方的なコミュニケーションをしがちでして……
接続方式変更
IPsec で繋いでいたが VTIトンネルの IPv6 LLA が時間経過で消滅する(!)謎現象が起きていたので 監視
こいつにそれぞれのノードのメトリクスを記録
https://scrapbox.io/files/64ce57f2979d17001bb5d9a1.png