Notices by らりお・ザ・何らかの🈗然㊌ソムリエ (lo48576@mastodon.cardina1.red)

https://smartlife99.netlify.app/nature-remo-e-lite%E3%82%92%E8%B3%BC%E5%85%A5%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F

> Local APIで取得できればそれに越したことはありませんが、今の所実装されていないようです。

Nature Remo E lite 、local API は提供されないのか。道理で皆 curl 叩いてるわけだ。がっかり。

描画方式で見れば極めて具体的だし、ハードウェアやドライバが何をすべきか、何をしているかにほとんど目を向けずに済むところを見れば極めて抽象的

「特定の描画方式を多様なハードウェアで同様に記述できるよう抽象化を済ませた形」と表現するのが正確かなというお気持ちです

まああれは典型的に「GPU がすべき処理は決まっているから我々は (処理ではなく) データを流し込みます」みたいなアーキテクチャですよね

で、これは私の中途半端な理解なので正しさは保証しないけど、 Vulkan (あるいは新しめの DirectX とかも？ 知らんけど) は「ハードウェアごとに機能に多様性があるしそれに合わせて最適化したい」とか「並列実行したい」とか「GPU 側でも汎用計算をすることがある」とか諸々の要件を前提に、「GPU というある種の計算機にコマンドを投げて、その結果を待つ」みたいな非同期かつ IPC 的なモデルになっている。
グローバル変数を設定して関数を同期実行して……みたいなモデルから脱却して、処理ごとの文脈なり依存リソースなり処理の内容なりを全部コマンドに同梱してパッケージとして投げるようになった。すると、ドライバ側がいい感じに効率的に状態を管理できるようになったり、「他の誰かが状態を変更していたらどうしよう」みたいな悩みから開放されたり、パッケージを通信で送れればいいから複数スレッドから同時にコマンドを投げても安全にできたりとか、いろいろ恩恵がある

OpenGL は「ハードウェア (やドライバ) が状態を持っていて、 API はその状態を変化させるもの」というモデルなんだけど、まあ言ってみればグローバル変数をあちこちから弄るようなものなので、並列プログラミングしづらいとか、状態が別所で変化させられている可能性があるので管理が面倒とか、そういう嫌な面があって近年では好まれていない

OpenGL は現代用ではないわね

まあそりゃあらゆる業界が自浄作用を発揮できるとも思わないけど、有害な †同業者† を非難する役目を放棄したら、そりゃ外部から十把一絡げに叩かれることもあるだろうよ

ｾｵは大事やぞ！ とイキったところで、問題とされているのはそこではなくクソみてえな方法論がのさばっている状況なので、結局 “わかってない” じゃんとなってしまう

ｾｵが批判されるのはユーザ体験の向上や機械可読で嘘のないメタデータの提供といった本質的な価値を無視してクソくだらない表層的な †最適化† で悦に入る連中が目に付きやすいからであって、端的には業界の下の方のレベルが低すぎるせいでは

一応 (暗黙か明示的か知らんけど) 規約として start stop restart reload 系のものを引数に取るスクリプトを /etc/init.d みたいなところに置いとくみたいな感じではあったけど、これだと依存関係の管理とか並列実行の可否の管理とかが面倒だよねとか、スクリプト実行ごとに bash がパースするから起動が遅くなるよねとかの話があり、 systemd が台頭したのもそのため

@cmplstofB man page の HTML に特にありがちなパターンですが

@cmplstofB 何らかのソース形式 (TROFF とか) で半角80文字幅ごとに強制改行を入れていたりするのが空白にされているなどの可能性

たとえば自身で描いたイラストについての部分、

> ただし、メンバーのイメージダウンにつながるようなもの、見たひとが不快になってしまうようなものはお控えください。

たぶんこれは法的な拘束力ないやつですよね。しらんけど。 (IANAL, TINLA)

おまけの話をすると、 OTP 生成のためのクレデンシャルを (本来の理想的な用法に反して) バックアップ/エクスポート可能なアプリなんかも普通に存在したりするので、その点でもｽﾏﾋｮでの OTP は使い方を誤るとイマイチ (かつ誤った使い方をするインセンティブが強い) という落とし穴もある

だから「セキュリティレベルは確かに向上するが、それがｽﾏﾋｮに比べてどの程度であるかは (ｽﾏﾋｮの) 環境や用法次第ではあるし、標準的な人にとってはどちらも十分ではある」くらい？

まあ脱獄するなそれはそう、なんだけど、そういうことがデバイスとして可能であるというのとそもそも不可能であるというのにはやはり差がある

あとはハードウェアトークンは電池不要かつ耐タンパー性のあるデバイスであることが一般的なので、 rooted device になると信頼性を失うスマートフォン上のアプリよりは可用性が高く攻撃もしづらいというのもある

TOTP 発行機器との比較でいうと、ハードウェアトークンを第2要素として使う場合は OTP とかの入力が不要になるので attack surface が小さくなる、とかかな

PHP の mt_rand() は一貫して壊れている(consistently broken)らしい - 唯物是真 @Scaled_Wurm
https://sucrose.hatenablog.com/entry/2016/02/19/235506

これを思い出したりした