ハッキングおやすみして鍋煮込んどる
For those who wants information about Yuito, subscribe my English posts only (available on account profile, Mastodon v4 or above).
くだらないこと言ってる人格は わんせた 、コード書いてる人格は kyori
呼ぶときは わせたん でもよし。たんってついてればかわいいので
Manages: https://odakyu.app https://nitiasa.com
Maintains: https://accelf.net/yuito (fork of Tusky)
when these instances down see here: @ars42525 @ars42525
Server Status: https://graph.accelf.net
ステルスゲーでイライラしてきてしまう質なんだけど、そもそもステルスゲーだと思って作られていないものを勝手にステルスゲーにしてしまう性質がある可能性が浮上してきた
大規模鯖を複数に切るの、多少のコストを犠牲にする策としてなしではないのかなと思ってたが、性能限界があるなら妥協案として良い策に見える
VSCodeでGit: Stage Selected Rangesコマンドが出てくる条件がようやく特定できた
開始点と終了点がともに変更のあった行にある場合だ
Error: が追加されてるしwrapperの方のerror codeにすり替わった?
なんでメッセージが変わるのかはようわからんが
GitHub Actions のエラー
Annotations「buildx failed with: ERROR: failed to solve: process "/bin/sh -c mix release" did not complete successfully: exit code: 139」
log「Error: buildx failed with: ERROR: failed to solve: process "/bin/sh -c mix release" did not complete successfully: exit code: 135」
なんで終了コード違うの??????
RubyGemsにアップロードするCDでTOTPを計算させてるやつ修正しなきゃと思ってはいるもののやってない
そもそも同じ投稿を配信するのに複数アカウントでAnnounceしてたらActivity数が爆発するのは目に見えているので、例えばひとつのActivityのTo,CCを正しく設定することで受信サーバー側に配信負荷を引き受けてもらうのも手かと
これがどれだけ実際の配送における負荷削減に貢献していたかは調べなきゃいけないと思う
配信先が多すぎてコネクションプールが溢れていたせいで意味をなしていなかったとか全然ありえる
このアカウントは、notestockで公開設定になっていません。
ほぼ配送専用の超大規模鯖向けの大規模配送ソリューションは考えたほうがいいのかもね
とくにnervの配送は1つの投稿が複数のActivityに分離する性質のせいで悪化している可能性が高い
このアカウントは、notestockで公開設定になっていません。
圧倒的な配送力を求められるサーバーに金掛けておかなきゃいけないのよね
当然オートスケールなどは考えられるがそれを構築して維持しておく費用がある