https://westantenna.com/%E6%8A%80%E8%A1%93/mastodon/2408/
あったあった。鉄道系インスタンスの一覧。
#theboss_tech
誤解のないように述べておくとこのアカウントの本質は :jre_js: から :jre_jk: まで幅広くターゲットとするシコ猿であり、政治的なことを言う青髪メイドさんではありません
少なくとも、"インスタンスのイメージを悪く" するような "一人の身勝手なToot" をした "某アカウントをサイレンス処分にしました" という情報公開だけでは、決して話は進まんよ。ただの横暴にしか見えない。だって判断基準が曖昧どころか一切説明されてないんだぜ?
カスタム絵文字としての適切なサイズはどのくらいか気になる
@TaiseiMiyahara 連合するためのAPとしては文字列なんだろうけど、丼クライアントの丼APIとしては数値だし、数値であり続けるべきだったんじゃないかと思う
ぱっとTLみて各トゥートが見事にバラバラなインスタンスなの、分散〜って感じるだ #theboss_tech
これまで内部DBやカラム設定などに数値でIDを保持していた部分が全滅である。かといって放置していたらPleromaユーザのクズどもから「APIの規約はこうだから対応しないアプリが悪い」と言われるのだ。
この変更にはオイゲンさんは関わっておらず、Mastodon開発者の一部がPleromaと敵対したくないという理由で定義を変更してしまった。それで割を食うのはアプリ作者である。要するに「Pleromaでも動くようにIDの扱いを丸ごと変えろ」というお話。ひどい。
マストドンでのIDの取り扱いは余計面倒な方向に進んだらしい。 https://source.joinmastodon.org/mastodon/docs/commit/e086d478afa140e7b0b9a60183655315966ad9ff これ結局アプリ作者に面倒を強いる方向だなあ…。
病気で休むと仕事が終わるの、会社の、社会の仕組みが狂ってるのは間違いないんだけども、偉い人に生存バイアスがかかっていてどうしようもない場合もあるのかな
予稿からでは提案手法の利点が解らん
ファクシミリ合成符号を用いたミクストモード通信の一手法
情報学広場:情報処理学会電子図書館 https://ipsj.ixsq.nii.ac.jp/ej/?action=pages_view_main&active_action=repository_view_main_item_detail&item_id=116409&item_no=1&page_id=13&block_id=8
本質的にSNSって放言の繰り返しなんだから、過去の投稿をアップグレードしたその瞬間から参照できる必要があるのか?という話になる。流石に永久に失われてしまうのは困るけれども、n日も投稿できなくてn日経過後にすぐに見られるのと、すぐに投稿できるがn日見られない事とを考えたらねえ。過去ログに関してはダウンタイムが同じか増える一方だけど、投稿に関してはダウンタイムが減る事となる。
巨大インスタンスは膨らみ続けるといつか死ぬ.Mastodonの単独インスタンスでのユーザー数方向のスケーラビリティは最初っから担保されてないし,設計思想の段階からそんなこと考えられてない.
アップデートのためのDBマイグレーションで時間がかかると言ってアップデートをサボっていると死ぬし、かといって停止が延々と続けば "ぜつぼうハード" 扱いされて死ぬ。従ってDBのマイグレーションを段階的に行う仕組みを気合いで実装するか、はたまたQuick and Dirtyに、予行練習を何度かした上で手動実行するしかないだろう