マストドンの場合はnodeとrubyを両方使うためにやってる印象があるな

multi stage build の利点は中間生成物を最終イメージに含めなくて済むことじゃないかなあ…

Docker で multi stage build が入ったのは17.05 なので、それより古いdockerでは最近のmastodonのDockerfileは扱えないらしい

@alter095 Docker で multi stage build が入ったのは17.05だ

https://training.play-with-docker.com/ 英語のは普通にありますからね＞docker training

ええ、いたのか…

ここは高校生おらんやろ

(LTL)昔なんとなく取ったドメインを使いまわしてるだけで、特に奇術との関連はありません…

タンスの専属キャラ、うちはイラスト依頼サイトで描いてもらったりしたな。 https://mastodon.juggler.jp/@juggler さすがによそ様の版権キャラを使う気にはならなかった

速さじゃなくて仕事量の少なさを基準にするならbackgroundつけない方がする事が少ない分だけ良さそうだが、プロセス一つ占有というのはリソース的に厳しい面もあるなあ…

@hota 紙パックの方はすっきりタイプで、消費期限も短いやつだ

cygwinからssh経由でubuntu 18.04のemacsを使ったらコピペ操作の時に描画崩れが発生してつらい

@micachi_net 添付メディアのtypeを決定しているのはクライアントではなくインスタンスです。トゥートが伝播した後に非同期で添付メディアのキャッシュが行われるまでの間、typeはunknownになります。

@BoF@mstdn.fr yes. my instance has been deleted old cache of remote media. it will be re-fetch when required.

tootctl media remove 完了。うちはキュー種別ごとにsidekiqコンテナを分けてるので、トラブルは特になかった。2.5.0だとpullキューの優先度が最低になってるので他のタンスでも問題は起きない気がする

@kumasun これはデータではなくてコードの方が古いと思います。エラーログ中のコールスタックが分かればもう少し詳しいことを言えると思います。

(LTL)今回のメンテナンスは予想時間ギリギリまでかかってしまいました。いやキツかった…

タンスを動かしながらリモートメディアの削除を行う場合、オブジェクトストレージを使ってないのならbackgroundを付けない方がオーバーヘッドが少なくトータルでは効率的な気が…いや比較もしてないのに言うべきではないな

@mayaeh Rubyのスレッドの場合、IO待機が長い場合以外は並列動作の利点はありません。よってローカルファイルの削除では特に高速化しないと思います

普通に考えるとキューに乗せるより直接まとめて処理した方が(プロセス内の)キャッシュに乗りやすい分だけ早い

@mayaeh --background はコマンド終了までの時間が短いだけで、処理時間全体では速くなる理屈がないと思います

キューが捌ける速度に問題はなく、これはこれで別にいいか

オブジェクトストレージを使ってる訳でもないウチの場合、background実行は別に必要ない気がするな

$ docker-compose run --rm web bundle exec bin/tootctl media remove --days 7 --background

Scheduled the deletion of 239630 media attachments .

24万弱の待機中ジョブ

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

@miraicorp まず「メンションつき投稿の通知の有無をクライアントから制御する」というのがそもそも不可能である事を理解して頂きたいです。意図的に行う事すら不可能なのにクライアントのバグで発生するという主張は荒唐無稽です。