Hidetomo Hosono (h12o) @h12o@blessedgeeks.org

そのうち「Database index corruption」 https://docs.joinmastodon.org/admin/troubleshooting/index-corruption/#fixing 対応でもしようかと思うのだけど、
https://qiita.com/neustrashimy/items/870769d7db4d95cde238#重複データをマージ削除するfix-duplicates-v322
によると、プロセスを全て止めておく必要がある・データベースのバックアップを取らないと危険・「性質上、処理に長時間かかる」（長時間とはどのくらいか、は書いていない）・インタラクションが発生するかもしれない、というわけで、 #mastodon_tokyo ・ #blessedgeeks_org とも、サーバー移設の時にやろうと思っている。

Timelogというのもあって、これはまだ残っているのだけど、ちょっと驚いているのが、いまだにhttps非対応ということ。2007年から続いているということで徳丸本以前のウェブアプリだから仕方ない……というべきかどうか。

検索したら2017年にサービスが終わっていたらしい。
https://ja.wikipedia.org/wiki/Croudia

Croudia、初耳……（真顔で
QT: https://nemushee.net/@makinon/106395535653190737

ちなみにBlessedGeeka.Orgは他人に役務提供をしない前提で運用しているので電気通信事業者として届け出ることはない。だから、1週間近く止めたことはあるが報告する義務はない（そもそも報告先がない）。

つまり「できる限りテキトーな運営を許容したいので他人は入れない」のがBlessedGeeks.Orgで「他人を入れたいのでできる限りテキトーな運営を許容しない」のがMastodon.tokyoというふうに分けている。

https://www.soumu.go.jp/menu_seisaku/ictseisaku/net_anzen/jiko/4hanki.html

Mastodon.tokyoは1回障害を起こしているが、報告義務はないレベルでおさまっている。

イーツのことだか思い出してごらん♪

って歌がなかったっけ?（まさに「おもいでのアルバム」）
QT: https://mstdn.fujii-yuji.net/@fujii_yuji/106363606542607326

Mastodon 3.4.1で`.github/workflows/check-i18n.yml`なるファイルができていてびっくりした。

ただ、以下の通りmainブランチへのプッシュかプルリクエストのときだけ作動するようなので、いまのところmainブランチが存在しないblessedgeeks-org/mastotonとmastodon-tokyo/mastodonでは、静観することにした。

```
name: Check i18n

on:
push:
branches: [ main ]
pull_request:
branches: [ main ]

env:
RAILS_ENV: test

jobs:
check-i18n:
```

一周回って元に戻った感じがする。
https://togetter.com/li/1724934

立て込んでいて頭が追いついていないのです。
QT: https://mastodon.tokyo/@h12o/106357657168048686

https://github.com/tootsuite/mastodon/releases/tag/v3.4.1

Nemushee.Net生きてた。よかった。
#nemushee #nemushee_net

ちょうど自分の自分だけのサーバーでないと試せないことが発生した。

https://togetter.com/li/1720499