Notices by きゅーけー (tojoqk@mastodon.tojo.tokyo), page 34

定期的に停止するWebサービス、公共サービスとか銀行であるあるだけどあれは楽だなあと思う。
定期的に停止する時間があるならそのタイミングでインフラとかの更新できるし、停止時間を最小にする努力とか、無停止でするための工夫とかそういったことを考えなくていい。

これはずるい。うらやましい話。

今後これから円高に進んだらメディアは「国力回復！」とかいって喜ぶのだろうか。

@graywolf
忠告ありがとうございます。
SRFI-180 は最悪時間計算量が大きいのですね。guile-json について覚えておきます。

worst case performance の日本語訳についてですが、「最悪時の性能」や「最悪時性能」が自然な訳だと感じます。ただ、実際には「ワーストケース性能」や「ワーストケースパフォーマンス」でも通じます。

個人的には SRFI-197 のインパクトが大きくて、これの chain-lambda と cond の => のシナジーが素晴しくてよい。また SRFI-180 で JSON を扱えるのも大きい。

GNU Guile で使えるいい感じの SRFI が Guix で簡単にインストールできるのを確認してから、R7RS で開発するモチベが上がっている。

CA 立てて証明書を生成するの面倒なの分かる。面倒だけどやってる…。

外部サービスを利用するのがなんとなく嫌だったので
うちは wireguard で運用してる

一長一短だし

4kディスプレイにしたらむしろ Emacs と別にコンソールを開くのがわずらわしくなってきたので、Emacs の multi-term を活用していくことにした。
これでだいたい代用できると思っているけど、昔 multi-term を使うのをやめた理由が何かありそうなので分からない。

(基本は shell バッファを使っていて、shell バッファで実行すると厳しいタスクだけ別のコンソールを使っていたのだけど、これを multi-term に変えるという話)

4k ディスプレイ、趣味では Emacs を3等分して作業するのがメインになりそう。ブラウザは以前からあった縦型ディスプレイでやって、ノートパソコンで Mastodon をしている。

こういうことがあるとなんの情報を Google だけが勝手に使っているのかわかったものではないので、Chrome を回避するモチベーションが上がるな。

https://mstdn.jp/@Linda_pp/112759282587012797

@yamad 自分は password-store というソフトウェアでパスワードと otp を gpg で暗号化して管理しています。いままでリカバリーコードもそこで管理していたのですが、何らかの理由でパスワードとotpの管理システムにアクセスできなくなった場合にリカバリーコードにもアクセスできなくなってしまう可能性を考えていて、保管手段を冗長化しようと考えた結果、リカバリーコードについては紙に書くでいいかなとなっています。。。

面倒だけど紙に書いて保管するか。メールアドレスでパスワードまではリセットできてもワンタイムパスワードの方は復元できなそうなので。というかだから二要素認証になるのか。リカバリーコード重要な気がしてきた。

共通のパスワード管理ツールにリカバリーコードを記録するの意味がない気がする。
万が一の場合を考えてリカバリーコードは別のところで管理した方がいいのかもしれない。

まあセキュリティ強化のためにあらゆるサービスで二要素認証を有効にしていこうと思う。

通信路でパスワードとワンタイムパスワードを盗まれた場合に場合に助かるというのはあるか。

パスワードも二要素認証の認証アプリに登録するシークレットも同じパスワード管理ツールで管理するようになったので二要素とはとはいったい?となっている。

Authy のアカウント削除した

4kディスプレイ最高だな。これは生産性上がるわ。

会社のやつ以外は全部 pass-otp に移行した。明日会社のやつも引越して Authy 依存を脱却してアカウント削除する。

冷静に考えたら VPN いらないわ。 ssh できるサーバーがあるだけでいい。自分が ssh を直接公開しない派だったので普通はこんなコストがかからないことについて忘れてた。