Lycolog

普通にソフトウェアを配布するだけならGitHubもForgejoも要らないし、zipを普通においておけばいい。元々GitHubからForgejoにするときにやりたかったことは自分のドメイン配下に成果物を置くことだったが、その理由は自分の所有物だとして明らかにすることで混乱を減らすことだった。外部サイトって信用しづらいじゃん？

ただ同時に、zipだけを置いておく場所も作りたいと思っていた。しかしそうするとForgejoとリソースが競合する…というのでやっていなかった。しかし今回Forgejoが消えたし、こっちの方がシンプルじゃんということで実装した。

GitHubやForgejoはソフトウェアの配布に向いているプラットフォームではない。何も知らない人がアクセスしたとしてどこにソフトウェアがあるかわからない。

ファイルとディレクトリが並んでいる謎の画面と、よく分からない長文の説明があるだけだ。リリース一覧を見てもどれがどれか探すのは面倒だし、そんなのをやりたがるのはギークだけだろう。ソフトウェアによってはGitHubと別に配布ページを設けていることも良くある。

この話題はRedditにもなぜGitHubの「リリース」セクションは見つけにくいのでしょうか？（和訳）としてあり、そこには次のような不満がつづられていた。

一般の人がGitHubからソフトウェアを入手するには横の「リリース」という項目に移動する必要があるが、事前知識がなければ見つけることができない
「リリース」がない場合、「README.md」という項目を読み、そこに指示がないか確認する
何もなければ視線をファイル一覧に向け、ソースコードのzipダウンロードを見つける
ダウンロードしても一般人には何もできない
諦めて次のアプリケーションを探すしかなくなる

この人物は数年かけて知識を得たからこれだけの行動ができるとあったが、これが正しい方法かもわかっていないという。つまりGitHubのような場所はソフトウェアを配布する場所ではないのだ。

説明書きなどをまともに用意できてないので今のところは中にまともなREADMEをバンドルしている二つのみだが、ちゃんとした個別配布ページなどを用意出来たら増やしていきたいと思う。

使う人が私以外にいるかどうか謎だし、元よりGitHubに転がしていたものなのでサポートするかどうかも怪しいが、世の中にはガラクタ置き場みたいな感じで転がしている人も見るので、そんなノリでやれればいいのかなと思った。

変えたこと

一部のページのスタイリングを共通化した

共通化のベースとしてサイト説明ページを作っていたので更新履歴ページに横展開した。

サイトトップの絵文字を変えた

元々はFont Awesomeを使っていたがMaterial Symbolsに変更した。見た目の問題。

コード上も以前はSVGをべた書きしていたが、今回はファイルに切り出している。SVGべた書きはエディタ上でコードいじりづらいからだ。

一部ページのURL変更

サイトトップは今のところ手組HTMLなのだが、URLでaboutが自己紹介でinfoがサイト説明だと編集時に混乱するので、自己紹介のURLをprofile、サイト説明をaboutにした。

あとがき

この記事を含めて今月は46記事にもなるが、今月は書きすぎだと思う。

2026/06/11の記事で記事数に言及しているが、まさか過去最多を超えて大きく上回ってしまうとは…。

しかし本来書きたかった日記のストックは消化できていないので、来月以降はその辺りも書いていけるといいなぁ…。

とはいえ、サーバーいじりもしたいし、優先度が難しい…。

コメント（0件）

2026/06/25(木)自宅サーバーの一部がダウンしたが監視を入れていてよかった話

更新日：2026/06/30
投稿日：2026/06/25

ジャンル::サイト運営ジャンル::自宅サーバーソフトウェア::Forgejo

仕事を終えて自分のサイトを見ると一部がダウンしておりGrafanaを見てみたらディスク使用率が100%になっていた。Mastodonがダウン、Grafanaも不安定な状態だった。

Prometheusのsyslog集めが強すぎてストレージパンクしたかな？と思ってPrometheusを止めてみたが効果はなかった。

ディスク占有しているやつを探す

ひとまずディスクを占有している主を突き止めるため、ディレクトリ単位の容量を出して突き止めることにした。犯人はForgejoだった。

犯人探しに使った軌跡

sudo du -xh --max-depth=1 /
sudo du -xh --max-depth=1 /var
sudo du -xh --max-depth=1 /var/lib
sudo du -xh --max-depth=1 /var/lib/forgejo
sudo du -xh --max-depth=1 /var/lib/forgejo/data
sudo du -xh --max-depth=1 /var/lib/forgejo/data/repo-archive

一次対応としてForgejoへの外部アクセスを遮断

取り敢えずForgejoが攻撃されてると面倒だなと思い、nginxの設定を書き換えてForgejoへの外部接続を拒否した。

次にrepo-archiveはキャッシュらしいのでForgejoの管理画面から消すことにした。すると即座にディスクは空き、全てが元に戻った。

犯人捜し

一旦サーバーは安定状態になったので犯人を捜すことにした。

まずはForgejoのログを見たのだが役に立たなかったので、次に私はGrafanaのLokiからnginxのログを引くことにした。

そしてLokiからnginxのログを見たらすぐに分かった。meta-externalagent、つまり悪名高いFacebookのクローラーだった。過去にこのブログにやってくる海外IPのBOTの挙動を軽く調べたでも出したが、こいつはやたらアクセスしてくる。

しかし何故Facebookのクローラーがなぜ…？と思ったがURLを見てすぐわかった。アーカイブにアクセスしているのだ。

もしかしたらForgejoはアーカイブURLにアクセスされるとその都度.zipや.tar.gzを生成しているのかもしれないと思って調べたらその通りだった。そんなクソみたいな仕様ある…？と思ったが、アーカイブを作るなら他に方法はない。

ForgejoはGitHubと違ってパス単位に作れるため、パスが多いリポジトリほど大量に作れるし、過去のバージョンを参照されたら事実上ほとんど無限に生成できる。そりゃパンクする。

Forgejoはどう思っているのか？

こんなのほとんど脆弱性である。しかもディスククォーターを設定したところでどうにもならない。ダウンロードできなくなって詰むだけだ。定期的にクリアしてもいいがSSDの寿命が縮んでしまう。

そこでForgejoの人たちはどう思っているのか調べてみたら案の定課題が起票されていた。最後の奴に至ってはメインコントリビューターの一人と思われるGusted氏の起票である。

結局どうすることにしたか

リポジトリの中身をzipで落としたい需要というのはどうしても出てくるし、それは仕方がない。しかし世代ごとパスごとに作ってしまうとなると、その数は無数になりすぎてしまう。

そしてダウンロードさせる以上どこかにデータを置く必要はある。仮に定期的に消すとしてもストレージの消耗は避けられない。

結論としてForgejoは撤去し、成果物は配布ページを作ってそこでzip配信するのが無難だなと思った。

簡単なコードについてはゴミ箱みたいな場所を作ってそこに転がしておくのもいいだろう。

明らかに利用者がいるValueDomainの奴とかもあるので、ひとまず土曜日にページを作って配信しようと思った。

meta-externalagentのアクセス推移

全部で何アクセス化までは見れていないが万単位でアクセスされてそうなので無茶苦茶だなと思った。

metaは最早攻撃者にも近いと思う。

経緯とか

18時頃にメトリクスが切れているのは多分書き込めなくて一時的に死んだからと思われる。再開できた理由は不明。この時点でネットワークトラフィックも死んでおりまともにアクセスできない状態だったと思われる。

19時半頃に手当を開始したが、FacebookのクローラーはForgejoを遮断するまでダウンロード不能（statできずにエラーを吐いていた）になったURLにひたすらアクセスしていた。

あとがき

今回の障害はいい勉強になった。

ディスク容量の急増という障害があることと、単にログとメトリクスを集めているだけでも解ることがあることが知れた。

勿論、閾値を設定した上での発報や、毎回クエリを叩かなくていいダッシュボードがあればよりよいと思うが、単に監視装置を置いているだけでもこうやって知ることができるのだなというので、いい経験になった。

コメント（0件）

2026/06/18(木)第五話今日もサイトの改築をしたが、結果は控えめ

更新日：2026/06/19
投稿日：2026/06/18

ジャンル::サイト運営開発::テスト

今日のサイト改築の話第四話の続き。Forgejoを設置して公開するまでをやったログと長いあとがきは4.5話の可能性もある。

Pタグの行頭字下げをやめた

ビュー	改修前	改修後
SP
PC

上の表はやめる前と、やめた後の見た目の比較。

adiaryを導入して少ししてから今まで長らく行頭の字下げが必要な気がしていたのだが、サイトのスタイリングをしていく中で空白が出すぎることや、他のマージンやパディングとの兼ね合いの調整、Pの中に画像を入れる、入れないによる差などが気になり始め、行頭字下げを廃止することにした。

これに伴いこのブログの行頭字下げも解除されている。

Web文書ではスタイリングの観点からインデントがない方が良いと判断したため。

廃止しても良いと思った理由としては行頭開けは原稿用紙や新聞、書籍など行間が詰まった媒体で段落の頭を判別しやすくするために配置されているものと考えたところによる。

Webは紙媒体と違い、余白を自由にとることができるから段落は空行で示すことができる。このことから行頭開けをするのは過剰ではないかと思い、廃止を決定した。

勿論、行頭字下げがあることで、より段落が判別しやすくなるとかもあると思うのだが、スタイリングをするときに行頭の空白が増えすぎること、画像などを巻き込むとややこしくなること、引用時のスタイルが破綻すること、CSS同士の相互干渉により考慮すべきことが増えることから、行頭インデントを廃止することとした。

あとがき

本日の活動が減った理由の一つとしては、ForgejoのOGPで日本語が文字化けすることに対して、Issueを立てることに力を入れていたことがある。

調べたところForgejoではGo言語組み込みフォントであるGo RegularをOGPの生成に使っており、このフォントはWGL4フォントファミリしかサポートしていないらしい。WGL4というのはWindows Glyph List 4のことで、端的に言うとWindowsに搭載されている欧文向けのフォントグリフの代表的なものらしい。

つまりForgejoでは欧文の代表的な文字しか表示できないというわけだ。というわけで日本語や繁体字・簡体字・ハングルなどのアジア文字をサポートすればアジア人が助かるというIssueを立てたが、一年以上前から議論されていたようで、即クローズされた。フォント問題が複雑で難しいらしい。わかる。私も名刺のフォント選定で死ぬほど悩んだもん。

と、まぁこんなのはほとんど言い訳で、次にやることが決まっていないというのが大きい。サイトの全体レイアウトの調整をしようにも指針を決めてないし、監視などの強化についてもドラフト状態のままである。なので、次すべきはタスク整理と、ロードマップ作りになってくるだろう。

あとはいい加減溜まってるブログネタを書かないと腐るので書くべきである。

というわけでサイト改築日記シリーズはいったん打ち切りになると思う。

一応今でも速攻で成果を出せるものとしてCachetの構築があるにはあるのだが、ちょっと勢いのまま走ってきた部分もあるので、一度立ち止まりたい気がしている。いや、そう言いつつ明日にはCachet置きましたとか書いてそうだが、それはそれでまぁ…。

そういえばGitHubからForgejoに移行した関係でページフッタにあるExtendsへのリポジトリリンクを変更したのと、Gistにあった資材をForgejoに移動してきたりもした。ついでに文字数カウンタを作って以来、長らく放置していたリガチャやサロゲートペアに対応する処理のテストコードを書ききった^[1]。偉いと思う。

テストコードがあると、テストコードから、ああこれは正しい挙動なんだなというのが読み取れるので便利である。例えば👨‍👩‍👧‍👨‍👩‍👧‍👨‍👩‍👧‍👨‍👩‍👧‍あﾞﾞﾞﾞﾞﾞﾞﾞﾞﾞﾞﾞﾞﾞﾞﾞﾞﾞﾞﾞﾞﾞﾞﾞﾞﾞかﾞﾞﾞﾞﾞさﾞﾞﾞを4文字としてテストしているコードがあるが、このことからこの文字列が4文字になることが実装者の仕様として決まっていることが分かる。

Windowsでは先ほどの文字列はキャレットが四回移動するため、Windows的にも四文字の扱いだ。こういうのは決めの問題だが、テストコードがあることで、決めが分かるという話である。

但し実際のページのコードは大幅に簡略化しており、コードとしてみると別物なので、このテストコードが実際に機能しているとは言えない。このリポジトリのコードは元々別の目的で作ったもので、それを流用して例のツールを作ったという感じだ。 ↩

コメント（0件）

2026/06/17(水)Forgejoを設置して公開するまでをやったログと長いあとがき

更新日：2026/06/24
投稿日：2026/06/17

ジャンル::自宅サーバーソフトウェア::Gitジャンル::サイト運営ソフトウェア::Forgejo

ここしばらくGitHubに思うところがありすぎて、GitHubを使い続けることに悩ましさを感じていたが、折角自宅サーバーの運用が軌道に乗ってきたのだし、それならGitHubもセルフホストしちゃおう！というのでやってみたログ。

あとがきに熱が入りすぎて異様な長さになってしまったので、この記事はあとがきが本体な可能性がある。

構築条件

Dockerを使わずバイナリ直運用
nginxからのリバースプロキシ
内部か外部かを問わずIPv6を使用する
unixsocketを利用する
GitのSSH操作にForgejo組み込みのSSHを利用する

確認環境

Env	Ver
Forgejo	11.0.15+gitea-1.22.0

やり方

基本は公式のインストールガイドの通り。

バイナリの配置～デーモンの配置を行う

# Forgejoバイナリの入手
wget https://codeberg.org/forgejo/forgejo/releases/download/v11.0.15/forgejo-11.0.15-linux-amd64
# Forgejoバイナリの配置
sudo cp forgejo-11.0.15-linux-amd64 /usr/local/bin/forgejo
sudo chmod 755 /usr/local/bin/forgejo
rm forgejo-11.0.15-linux-amd64
# gitとgit-lfsのインストール（gitは既に普通あると思うが）
sudo apt update
sudo apt install git git-lfs
# Git操作用ユーザーの追加
sudo adduser --system --shell /bin/bash --gecos 'Git Version Control' \
  --group --disabled-password --home /home/git git
# Forgejoディレクトリの作成
sudo mkdir /var/lib/forgejo
sudo chown git:git /var/lib/forgejo && sudo chmod 750 /var/lib/forgejo
sudo mkdir /etc/forgejo
sudo chown root:git /etc/forgejo && sudo chmod 750 /etc/forgejo
# Systemdの入手と配置
sudo wget -O /etc/systemd/system/forgejo.service https://codeberg.org/forgejo/forgejo/raw/branch/forgejo/contrib/systemd/forgejo.service
# デーモンの開始（設定ファイルとかを作らせるためにしている）
sudo systemctl daemon-reload
sudo systemctl enable forgejo.service
sudo systemctl start forgejo.service
# 設定ファイルのパーミッションを変える
sudo chmod 640 /etc/forgejo/app.ini

/etc/systemd/system/forgejo.serviceを開き[service]セクションに以下を追記する
```
RuntimeDirectory=forgejo
RuntimeDirectoryMode=0755
AmbientCapabilities=CAP_NET_BIND_SERVICE
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
```
下二行はケイパビリティの設定で、これをしておくと22番ポートが使えるようになる

nginxからリバプロする

server {
  listen [::]:443 ssl;
  server_name  git.example.com;

  ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

  client_max_body_size 100M;

  location / {
    proxy_pass http://unix:/run/forgejo/forgejo.sock;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-Proto $scheme;
  }
}

/etc/forgejo/app.iniを開き、適当に設定を書く。設定系はConfiguration Cheat Sheetに全部書いてある。

# Webページのタイトルの一部が変わる
APP_NAME = Forgejo
# Webページのタイトルの一部が変わる
APP_SLOGAN = Beyond coding. We Forge.
# 実行ユーザー
RUN_USER = git
# 本番
RUN_MODE = prod
# 実行パス
WORK_PATH = /var/lib/forgejo

[server]
# unixsocketを使う
PROTOCOL = http+unix
# Forgejoを置いているドメイン
DOMAIN = git.example.com
# unixsocketのパス
HTTP_ADDR = /run/forgejo/forgejo.sock
# unixsocketのパーミッション
# www-dataがアクセスできるように666にしているがwww-dataをgitグループに入れてもいいかも？
UNIX_SOCKET_PERMISSION = 666
# 組み込みSSHを起動する
START_SSH_SERVER = true
# IPv6でListenさせる
SSH_LISTEN_HOST = ::

[repository]
# リポジトリを格納するルートパス
ROOT = /var/lib/forgejo/data/forgejo-repositories

# アップロード制限、とりあえず公式のコピペ
[repository.upload]
; ; max size for files to the repo via web interface, in MB,
; ; defaults to 3 (this sets a limit of about 4GB)
FILE_MAX_SIZE = 4095
; ; by default 5 files can be uploaded at once, increase to 20
MAX_FILES = 20

# Gitのタイムアウト制限、とりあえず公式のコピペ
[git.timeout]
; Git operations default timeout seconds
DEFAULT = 3600
; Migrate external repositories timeout seconds
MIGRATE = 6000
; Mirror external repositories timeout seconds
MIRROR = 3000
; Git clone from internal repositories timeout seconds
CLONE = 3000
; Git pull from internal repositories timeout seconds
PULL = 3000
; Git repository GC timeout seconds
GC = 600

デーモンの再起動
```
sudo systemctl restart forgejo.service
```
https://git.example.comにアクセスし適当に設定する
基本的に初期設定そのままで大きな問題がないものばかりだった気がする
SSH鍵を作成し、Forgejoで自分のアカウント設定ページを開き、公開鍵を登録する
クライアントになる環境にSSHに繋ぐための設定(~/.ssh/config)を書く
```
Host git.example.com
  HostName git.example.com
  IdentityFile /path/to/forgejo.sec
```
疎通確認。WindowsでもLinuxでも同じ
```
ssh -T git@git.example.com
```

GitHubのリポジトリを一括でForgejoに移行する方法

GITHUB2FORGEJOを使うとできる。

以下は移行のコマンド例。マニュアルが親切なのでマニュアルを読めばわかる。

一個でも外すとこのオプションどうする？と聞かれるが、何も指定しなければウィザードを流してくれるので、環境変数を指定せずに叩いても動く。

以下のコマンドではGitHubと決別し、完全にForgejoに移行する前提の設定としている。

wget https://github.com/PatNei/GITHUB2FORGEJO/archive/refs/heads/main.zip
unzip main.zip
rm main.zip
cd GITHUB2FORGEJO-main
GITHUB_USER=YourGitHubUserName \
    GITHUB_TOKEN=ghp_XXXXXXXXXXXXX \
    FORGEJO_URL=https://git.example.com/ \
    FORGEJO_USER=YourForgejoUserName \
    FORGEJO_TOKEN=XXXXXXXXXXXXXXXXX \
    STRATEGY=clone \
    MIRROR_DIRECTION=pull \
    PUSH_MIRROR_INTERVAL=8h \
    PUSH_MIRROR_SYNC_ON_COMMIT=no \
    MIGRATE_ARCHIVE_STATUS=yes \
    MIGRATE_FORKS=no \
    VISIBILITY=both \
    SORT=pushed \
    SORT_DIRECTION=desc \
    FORCE_SYNC=no \
    DRY_RUN=no \
    ./github-forgejo-migrate.sh

どうやらリポジトリ本体は持ってこれるもののIssueやWikiは持ってこれないようだ。

forgejo dump-repoというGitHub系サービスの中身をダンプするコマンドがあったので試してみたが、こちらは引っ張ってはこれるっぽいもののForgejoのDBやディレクトリ構造と合わないようで、移行用途では使えなかった。

gh repo list Lycolia --limit 1000 --json name --jq '.[].name' \
    | while read url; do
        echo sudo -u git forgejo dump-repo --git_service github --auth_token XXXXXXXXXXXXXXXXXX--clone_addr https://github.com/Lycolia/$url --config /etc/forgejo/app.ini --repo_dir /var/lib/forgejo/data/forgejo-repositories/lycolia/$url
    done

GitHubのアカウントエクスポートも試してみたが、中身が省略されているように見える.gitディレクトリの山がパッケージされており、ググった感じGitHub間のアカウント移行に使う物らしかったので、諦めた。

あとがき

あとがきが長すぎて、実はこっちが記事の本体という可能性が…ｗ

構築していて思ったこと

SSHの穴をあけるのは危険か？と思ったが組み込みのSSHであればgitユーザーが出来ること以外できないだろうし、任意のコマンドが実行されたところで、精々リポジトリの全消し以上のリスクはなさそうなので開けることにした。理由としてはHTTPはパフォーマンスが悪いらしいからだ。

構築していて思ったがForgejoのマニュアルは親切で比較的解り易く、構築が楽だったのが良かった。

unixsocketの利用について

積極的に使い始めたのはUbuntuのadiaryをlibfcgi-perlで動かす方法が初めてだが、unixsocketはTCP通信をしないのでポート管理が不要になるのが利点なのと、TCPのオーバーヘッドがない分処理が速いというのをどっかで見たので、使うことにした。

内部通信のポートが被らないように管理するのは地味に大変なのでアプリケーション間の通信は極力unixsocketに倒したいなと思った。

Forgejoを使おうと思った理由

GitHub周辺のセキュリティ事情の変化と、それに伴う対応

最大の理由は、ここ数年でGitHubやnpm周辺のサプライチェーンリスクを強く意識せざるを得なくなったからだ。

例えばSecrets漏れなどの事故はここ数年で非常に聞くようになったし、npmjsからGitHubのToken奪取などの問題もあったと思う。

そしてその関係でセキュリティが面倒なことになり、GitHub Actionsからnpm publish出来なくなってたのを対応したみたいなことをする羽目になったこともあり、非常に煩わしさを感じていた。

Value-DomainでcertbotのDNS Challengeをやるスクリプトを書き直した理由の一つも、npmjsから手を引きたい思いが実はあり、そもそも別にリポジトリから拾えばいいじゃんと思い、パッケージ化しなかったというのもある。だって別にPerlでもnpmレジストリに入れることはできるからね。

そして昨日npmjsのアカウントを消そうと思い立ちログインしようとしたらロックアウトされてしまった。私はホビープログラマとしてやっているだけなので、こういった変化についていくのに疲れてしまった。

GitHub離れの加速

例えば最近GitHub離れが進んでいることも理由の一つだ。

理由にはいろいろあると思う、例えばここ最近GitHubは不安定で、GitHub Actionsが失敗する、Webページが開けない、APIがダウンしているのは最早日常といってもいいだろう。少なくとも私はそう思っている。

他にもCopilotなどのAI化の推進や、UXの悪いPR、行儀の悪いソフトウェアの排除もある。

CopilotなどのAI化の推進についてはGitHubのWebページ上でコミットを打つと解るのだが、LLMによって勝手にコミットメッセージが補完される。あのメッセージに意図などなく、変更内容を文字列にしただけだ。これを避けるためにはAIが書き切るより早く書き起こしてコミットするか、或いは書き終わるのを待って上書きするか、何も考えず即座にコミットボタンを押しUpdate hoge.mdのようなメッセージにするかしかない。個人的にはこれが非常に煩わしく、避けたいと思っている。

そして、もしこれを回避する設定があるとしてもGitHubの設定は既に増えすぎており、もう探す気も起きない。

UXの悪いPRについては、PRを作ったときにベースリポジトリに更新が走ると更新するボタンが出てくるが、これを押すと中身のない空のマージコミットが作られることや、GitHubのバグとしか思えないよく解らない差分が出ることがあるのも挙げられる。こうやってやらなくていいことを増やすだけのシステムはUXが悪いと思う。

そして行儀の悪いソフトウェアの排除だ。行儀の悪いソフトウェアとは何かというと、もっぱら権利侵害を目的に利用されているのではないかと疑われているようなものである。

かつてGitHubでホスティングされていたyoutube-dlというソフトウェアがDMCA侵害でGitHubから消されることがあり、当時は結構騒がれた話だったと思う。その後、紆余曲折ありyoutube-dlは現在は再公開されているが、最近はほとんど更新されていない。恐らくフォークであるyt-dlpに開発が移ったと思われる。

そして今年に入ってからFAKKU, LLCが大規模なDMCAを通告した。これによりGitHubから多くのダウンローダー系ツールが削除されて祭りとなった。

この対応を受け、gallery-dlはCodebergへの移行を決めた。

個人的にはTwitterの画像を落とすのにHitomi-Downloaderをよく使っていたのだが、これもDMCAに含まれており削除の憂い目にあった。Hitomi-DownloaderはTwitterがXになり、APIが有料化してからもTwitterのメディアをバルクで落とせるので重宝していた人が多くいたと思う。なおHitomi-Downloaderについては移転したとかはなく、単に消えてそうだ。バイナリはググれば出てくるが、APIが変わってるので、もう動かないと思う。余談だが、現在Twitterの画像をバルクで落とせる無料のソフトウェアはgallery-dlくらいだと思う。

また前述したGitHubの不安定さや、AIの存在を理由にGitHubを離れたものとしてプログラミング言語のZigがある。ZigはGitHubの現状に失望し、痛手を負ってでもCodebergに移行した。現在のGitHubは更新されておらず、移行のメッセージが残されている。

また玄人向けのLinuxディストリとして知られるGentoo LinuxもGitHubのLLM方針に反発し、Codebergへの移行を発表している。

Gentooの2025年振り返りでは、「Goodbye Github, welcome Codeberg」という言葉も見られ、Planet Gentooでは開発者からLLMに対する鬱憤ともいえる批判が多く寄せられている。

個人的に強く共感したものには次のものがある。

They start using LLMs because they don’t want to maintain their code anymore. Software turns into slop, which burns out even more people.
(ja: 彼らは、もうコードのメンテナンスをしたくないという理由で、LLMを使い始める。その結果、ソフトウェアはずさんなものとなり、さらに多くの人々が燃え尽きてしまう。)

LLMを使う理由はコードを書きたくないから、メンテしたくないから、動いている風に見えればよいからだというのは私も思う。バイブコーディングで出てきたものがまともに動く保証はない。

公私ともにLLMを使ってコーディングしているが、本当にそう思うし、仕事ではLLMに毒されすぎたのか判断能力を失ってしまった人も見かける。

Gentoo aims to be made by humans

We banned LLM contributions two years ago, and never regretted it. We didn’t “wait and see”, we took decisive action, and if we got left behind, it’s only for the better. I can’t give you a 100% guarantee that no tainted code slipped through, but we’re doing our best to stay vigilant. In the end, it’s all about trust, and trusting one another is what builds our community.
(ja: 私たちは2年前にLLMによる投稿を禁止しましたが、その決断を後悔したことは一度もありません。「様子を見る」のではなく、断固たる措置を講じました。もし他者に遅れをとったとしても、それはむしろ良いことなのです。不適切なコードが混入していないことを100％保証することはできませんが、私たちは警戒を怠らないよう最善を尽くしています。結局のところ、すべては信頼にかかっており、互いを信頼し合うことこそが、私たちのコミュニティを築き上げるのです。)

この人間らしさには非常に共感した。特に「もし他者に遅れをとったとしても、それはむしろ良いことなのです。」の部分だ。誰かより早くある必要はない、誰かと比べて遅れていても問題ではない。何故なら競技ではないし、そもそもベクトルが違うと私は思う。

他にもAutodesk Fusion 360 for Linuxも同様の理由でCodebergへの移行を行い、GitHubは既にアーカイブされている。

GitHubでホストする意味がなかった

lycolia.info、つまりサイトトップを触っていて思ったのだが、自分が作ったソフトウェアを見てもらうのに外部サイトにアクセスしないといけないというのが癪だと思った。

ソフトウェアの配布なら最悪自分のサイト上でzip配布でもすりゃあいいじゃんという話だ。

ただまぁ事はそう単純でもなく、リポジトリをWebサイトに置いておくと、出先からスマホでちょろっといじりたいとか、テキストとして転がして置き、一々ダウンロードせずコピペしたいみたいな絶妙な需要を満たせるので、セルフホストでかつ、GitHubの様な機能を満たせるものというところでForgejoを採用したのである。

勿論、先述したようなGitHubへの信頼性問題もあるが、私がDMCAでどうにかなる可能性は今のところないので、まぁ宗教みたいな話ではある。

そういえば以前WSL2のUbuntu 20.04にGiteaを生やすという記事を書いたし、Giteaにはコントリビュートしたこともあるが、GiteaのフォークであるForgejoでこんなことを始めるとは夢にも思わなかったので、めぐりあわせだなぁと思うのであった。

GitHubの個人用アカウントと業務用アカウントがどうのこうのを解決する糸口として

業務用と個人用でGitHubの無料アカウントを分けるは、このブログで二番目にアクセスの多い記事だが、Forgejoに完全に移行すれば、こういったことも解消できる。

なお現状ではGitHubのアカウントそのものはOSSのコントリに使うことが稀にあるため保持しておくつもりだが、いつ消し去っても良いくらいの温度感では持っておきたい所存である。

Forgejoに対する思い

分散型という諸刃の剣

Forgejoは、その構造上、各ホスト上でアカウントを作らないとコントリビューションができないと思うので、特定のプラットフォームからの支配や思想を回避できるのが利点だが、同時に欠点だとも感じている。

端的に言うとそれぞれのForgejoサーバーには何ら繋がりがない。あるForgejoサーバーでアカウントを作ったとしても、別のForgejoサーバーでは使えない。これはForgejoサーバーが増えれば増えるほど難しくなっていく問題かもしれない。私の様なサーバーでは問題にならないので別にいいが…。

但しFediverseにあるActivityPubのようにオープンプロトコルを作り連合を作る計画はあるようで、将来的には各ホスト同士での疎通が実現するかもしれない。

とはいえ、連合は連合で問題である。Fediverseも連合制をとっていて様々なサーバーが連合しているがMastodonとMisskeyには互換性の問題があるし、連合は数が増えれば増えるほど負荷が大きくなる問題もある。例えばA Forgejoサーバーの変更が10の連合先に伝播し、そこから更に各サーバーの先にある10に連合…となれば伝播する時間もリソースも無駄になってくる。

設計次第ではあるものの相互に繋がった数千のサーバーがやり取りを始めたらDoS攻撃に匹敵する負荷が発生するかもしれないし、様々な分散サーバーに同一の情報が保存されるのはストレージの無駄である。

この辺りはMisskeyの開発者であるsyuiloさんや、.ioの運営者である村上さんも話しているし、連合のコストについてはfedibird管理人ののえるさんも話している。

分散型はプラットフォーマの支配を受けず、独自性を出しやすい代償に、スケールしづらいのだ。ただ、DMCAの通報がされるようなソフトウェアにとってはそっちの方が都合がいいかもしれない。とはいえ、GitHubにBANされなくとも、次はAWSやVPSからBANされたり、ドメインが差し押さえられたり、自宅サーバーであってもISPから契約解除されるなどのリスクはあるので、程度問題ではある。

そういえば、この手の話をまさにしているスレッドがRedditにあったので、記録に残しておく。

今回設置した物体が見れる場所

エクスプローラー - LycoGit: Lycolia's Git Hostingで公開リポジトリの一覧が見れる。

ドメイン直下にアクセスすると「自分で立てる、超簡単 Git サービス」という強めのおもしろアピールが出てくる。

今のところはGitHubのリポジトリを丸ごと移しただけなので、中身的には同じものである。

コメント（0件）

2026/06/16(火)今日のサイト改築の話第四話

投稿日：2026/06/16

ジャンル::サイト運営

今日のサイト改築の話とかadiary改造の話とかの続き。5日ぶりの更新。

トップページのスリム化

単純比較するための画像をとってなかったので、画像では前回と今回の比較となっている。

トップページのバナーリンクからページ説明を削除

改修前	改修後

前のレイアウトではバナーリンクの下に説明文を書いていたが、別に自明だなと思ったので消した。

これによってSPビューで1画面に出せるリンクの数が1.3倍くらいになったのでだいぶ良かった。

トップページから更新履歴を削除

改修前	改修後

「このサイトの歴史」の部分を削除した。削除したものは後述する「更新履歴ページ」に移設している。

このサイトについてページの作成

このサイトについてページを作成した。内容的にはこのブログにある「このサイトについて」と大差ない内容だ。

比較的シンプルなページであることもあり、それなりにスタイリングしている。今後はこのスタイリングをベースに全体展開していきたい感じだが、まだ詰め切れていないので一旦仮である。

更新履歴ページの作成

こんな感じの更新履歴ページを作成した。

内容的にはトップページ下部にあった「このサイトの歴史」にある更新履歴ボックスの中身の移植だが、以前は<pre>を使ったプレーンテキストだったのを<section>, <h3>, <ul>, <dl>などを使うことでセマンティックなものに変更している。ほぼ手動で移植しているので、微妙に壊れている可能性がある。

スタイリングはほぼ皆無だが、全体方針が決まったら当てていきたい。それなりの構造にはしてあるので、比較的容易に反映できると思う。

更新履歴を別ページに分離するアイデアはフィーネ・ラグザスさんのFeathery Instrumentのサイトの作りから着想を得ている。

余談だがFeathery Instrumentは古のサイト探究～駄文同盟のID上位100サイトを巡り、今までのネット人生や自サイトの過去を振り返ってみるでは以下の状態で、消滅サイトの側のカウントだったが、現在は精力的に更新されている。