https://reddit.com/r/Genshin_Impact/s/TmSQmQEYsq

そりゃ早々に修正されるわw

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

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

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

まあ結局、「ユーザは『不可視化できても削除はできない』SNS に耐えられない (よって履歴の保持を任意にしてもいける)」と判断されたということなんでしょうね。本当の意味で削除が可能な投稿なんてほぼないのに。

Updates to Repository Sync Semantics | AT Protocol
https://atproto.com/blog/repo-sync-update

> Even though we are setting the prev field, this can be considered a “hint” and the history is no longer considered a canonical part of the repository.

あと EU 圏の人々は GDPR でサイバーノーガードできちゃうから、「法律で守られているから『本当の意味での削除』は可能だ」みたいな幻想を抱いていても不思議ではないなという気持ちがある。知らんけど。

ヒストリの保持によるストレージ圧迫については、実際どうなんだろう……そもそも SNS というサービスの性質からして権威情報源で情報が単調増加するのは本質的な制約だし、緩和が本当に意味あることなのかは情報の性質によりそうだけど…… (ヒストリ捨てずとも圧縮とか効果的な差分管理でどうにかなる可能性とか)

何を k8s クラスタの外に出すべきで何を中に含めるべきなのか、いまいち判然としない

サービスについてもそうだし、永続させたい情報やデプロイ時に与えたいデータについてもそう

すべてに k8s を使いたくなってきたけど、単に私の ansible の使い方が下手なだけという自覚があるのでどうにかしようと模索している

k8s も k8s で永続データの扱いを完全に理解していないのでベストプラクティスがまったくわからんので、いずれにせよ今の段階では満足に使いこなせない

そもそもストレージをクラスタではなく外で管理させようというあたりで ceph 的なｿﾘｭｯｼｮﾝが選択肢から外れてしまったので、単純に管理すべきものがクラスタ内外に散らばって面倒というのもある

そりゃクラスタ管理を二重にするくらいなら親の Proxmox VE だけで全てが済む方が楽なのはもちろんそうなのよ

一度どこに不便を感じているのか明文化しないと駄目だなこれは……

ansible 使いながらも手間と不便を感じているのは事実なので、まず具体的にどの部分を不便に感じているのか把握する必要がある……

@unarist
https://www.youtube.com/watch?v=MDGow_3sTwo

今更なんで解決済みだったら申し訳ないんですが、主人公と (現状の) フォンテーヌキャラ限定のモーションらしいです

Good Practices for Ansible - GPA
https://redhat-cop.github.io/automation-good-practices/

これは読むべきかもしれん

まず前提として、概念的な処理は似ているが実態としての処理は再利用があまり多くない、また横スケールさせるべきアプリも少ないというのがあるかも

SSH や DDNS を設定したりなどのシステム部分では横展開しているので共通化が便利なんだけど、アプリ単位となるとこれが微妙。

「アプリデータ用のディレクトリを作って docker-compose.yml を template から生成して、存在しなかったら初期データをデプロイして、 systemd の service も template から作って、……」みたいな感じの共通の構造はぼんやりと存在しているんだけど、具体的に必要なファイルは多様で抽象化すると複雑になりすぎそう。
たとえば docker-compose.yml が実は2つ必要な構成だったりすることもあれば、 foo.env のデプロイが必要なこともそうでないこともある、また投入すべき設定ファイルが read only でマウントできるから ansible で常に上書きしてよいこともあれば、データディレクトリで writable に保管されているから上書きは部分的だったり注意を要することもある

そういう「作業項目の名前だけ見ると同じだが内容は場合によりけり」みたいなのが小さすぎたりして role として単体で切り出しづらいので直書きし、結果、ボイラープレートが無数に増殖し……となっているのが現状。なるほど使い辛いわけだ

module とかいう感じのやつで抽象化して task のいち項目として書けると良いのかもしれないが Python が必要というわけではなく、あくまで他 task への呼び出しを集めたものに留めておきたい (というかそれもまた role なのか)

価格 - Wasabi
https://wasabi.com/ja/cloud-storage-pricing/

改めて見直してるんだけど、日次バックアップに使うにはやはり少々お高い感じがするので (数日ですぐに消しても最低30日間 [EDIT: 90日間だった] は保存しているとかの前提での価格計算になっているはず)、自宅クラスタにバックアップ保持用の minio 立ててそっちに流し込むのが正解っぽいなぁ

この mastodon サーバ (2017年10月から運用で約6年分、メディアは Wasabi で保持、 ElasticSearch 停止) の永続データが諸々込みで 7.8 GiB。

大雑把に 8 GiB として、ほとんど圧縮がかからないと仮定して毎日1回バックアップで14日保持するとすると 3360 GiB なのでざっと $20.1、¥145/USD で換算して ¥2918。

実際はメディアを外出ししてるからメインは postgresql の DB だろうし、結構圧縮効くと思うけど。

Wasabi の APAC リージョンは $6.99/TB/mo で Backblaze は $5/TB/mo だけど、 Wasabi は転送量課金がなくて (やりすぎると怒られる可能性はあるとのことだが) Backblaze ではダウンロード量課金が $10/TB/mo なのか。

となると、なるほどバックアップを置いておくだけで手元や他ホストに転送する必要がない状況なら Backblaze の方が有利だ

逆に一度公開したら基本的に消さない、かつ一般公開していたり繰り返し利用するようなリソースについては、 Wasabi がかなり有利と。

How does Wasabi's minimum storage duration policy work? – Wasabi Knowledge Base
https://knowledgebase.wasabi.com/hc/en-us/articles/360058734492-How-does-Wasabi-s-minimum-storage-retention-policy-work-

pay-go だと90日間の保持だった

Pay-go Pricing FAQs - Wasabi
https://wasabi.com/paygo-pricing-faq/#free-egress-policy

> * If your monthly egress data transfer is less than or equal to your active storage volume, then your storage use case is a good fit for Wasabi’s free egress policy
> * If your monthly egress data transfer is greater than your active storage volume, then your storage use case is not a good fit for Wasabi’s free egress policy

> If your use case exceeds the guidelines of our free egress policy on a regular basis, we reserve the right to limit or suspend your service.

月あたり active storage volume (作成から90日未満で削除したものを除いたデータ) 以下の egress しかなければ問題ない、これを超えることが常態化しているようなら対処する (かもしれない) ぞ、と

え、 *nix を知っていて factor なんて名前をコマンドに付ける人いるんだ……すごいな

素因数分解する factor コマンドは coreutils やぞ、よく衝突させる気になったな……

インタプリタっぽいし factorc とはいかなかったか

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

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

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

英語でも ", however," を主語の後に置く構文あったりするし、そっちで再輸入が繰り返されている可能性も (しらんけど)

フォーマルな文脈で使うようなものではないらしいが

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

生成AIによる「“新”証言」で物議　日赤、関東大震災100年企画の一部展示を取りやめ - ITmedia NEWS
https://www.itmedia.co.jp/news/articles/2308/24/news174.html

へえ

> 関東大震災に関心をもっていただき、少しでも防災に備える行動をとっていただくことが、本プロジェクトの一番の目的でした

いつもの「目的が正しければ手段は問わない」倫理なぁ。使命感が強いのは結構なことだが……

迫力の7インチ！？

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

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

メール、ユーザ数の割に MUA の多様性が低いように思われるし、その原因を考えてみると各種メールサービスが自前で web UI を提供しており囲い込みを試みているため、ベンダー固有機能を使いづらい独立したアプリからユーザが剥がされている、というのは確実にあると思う

するとどうなるかというと、「メールの上に (軽量なプロトコルを載せて) アプリケーションを作る」ということがやりづらくなる。そういうのはメーラが対応してなんぼのものだが、肝心のメーラが特定のメールサービスにべったりで他所の第三者が用意したオレオレ規格に自分たちのビジネスリソースで対応したがらない (なんなら囲い込みできる形で再発明してパクるインセンティブの方が高そうである) ため。

HTTP (web) はサイトとクライアントが独立している結果、クライアントで (スクリプト言語の対応含めて) 拡張への対応が加速し、 HTTP の上に様々なプロトコルを載せることができるようになった。
メールはサービスとクライアントがべったりになった結果、メールの上にプロトコルを載せづらくなり、メッセージングや通知サービスとしての潜在的な需要を LINE やら Slack やらに奪われることになった。

教訓としては、「オープンなプロトコルを策定しただけでは、さまざまな応用のベンダー中立な利便性向上はクライアント・サーバ同時提供によって事実上阻害されるので、サービス提供側とクライアントは独立している方がユーザを利する」とかですかね。

その代償が「通知対象デバイスや通知配信プラットフォームのベンダーに中立な通知プロトコルの欠如」なので、なかなか重い

一応 ntfy とかあるけどね。

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

その「『通知が来た』の後にどういう UX を提供するか」の部分で遅れを取ったというのがある。たとえば通知をタップしてすぐにスケジュールを追加したり、通知をタップしてすぐに何らかの監視ダッシュボードに飛んだり、そういうインタラクションの拡張がベンダー中立にできなかった。
ハイパーテキストと添付ファイルの伝達という原型以上の応用を形にしづらかった

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

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

そもそものプロトコルが時代遅れ気味で諸々のオーバーヘッドが気になるというのは、まあそうかも…… (うっかりするとオープンリレーになるリスクとか……)

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

これはそもそも分散システムの本質的な問題なので (fediverse でも全く同じ問題がある)

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

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

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

テープに記録したドライブ映像、これが本当のテープドライブ……ってこと！？

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

「捕獲するだけは申し訳ない」で “有効活用” (おいしく食べる) 方向に行くの、ある種のサイコパスみがあって大変よい。これこそ人間でなく自然という脅威と向き合うスタンスよな。

検証可能・可読な仕様の明示としてのテストというのもあるので

その目的ならカバレッジ至上主義やってもしょうがないかもしれないけど。

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

長期間使う構造体で参照を持つのは基本的に筋が悪いような……

https://doc.rust-lang.org/std/sync/struct.Arc.html#method.into_raw

Box::leak や Arc::into_inner などを使って生ポを取り出し 'static な参照にするというテクがあります。
開放するときは Box::from_raw や Arc::from_raw に渡して生ポから Box や Arc を復元してから drop する。

もちろん過剰にやってしまうとリークやメモリ破壊になるので unsafe だし、復元と破棄が足りなくてもリークになるけど。

しかし async なあたりを見ると途中で drop される可能性があるから最後の復元フェーズが実行されない可能性あるし、真面目にやるなら Arc は持ちつつ as_ptr からライフタイムが自由な参照を錬成して、みたいな流れにしておかないとリークするリスクが高いな

async 想定で参照をフィールドに持つのはどういう想定での設計なんだ……？ となっている

API 対応に注力していて実用アプリにおける利便性が見えていないみたいなことはあるのかなという気がする。これは issue 立てていい案件

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

まあフル機能使うでもなければ自分で書くのはアリかなという…… いやこの流れは良くない、ここ十数年で俺はそれをよく知っている

Rust での XML 体験については総合的にかなり不満があるので手元に燻っているアイデアとコードと PoC があるんだが、いかんせん他にやることが無限にあって進捗が牛歩

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

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

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

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

たぶん「コストのかかる処理は (奥深くに隠されるより) そのものの存在が明示されるべき」などの信念から必然的に導出されるやつ

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

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

これ本当に悔しいので non-allocating fmt::Display::fmt の実装しがち

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

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

これなぁ、悩ましい。

New release - more complete, safer – gtk-rs
https://gtk-rs.org/blog/2019/06/22/new-release.html

https://users.rust-lang.org/t/what-would-be-the-correct-way-of-wrapping-an-api-with-optional-parameters/32495/7?u=nop_thread