Lycolog

コネクタを傷めないための備忘録。

死ぬほど硬いのでなかなか抜けなかったり、挿したつもりが刺さっていなかったりする。

抜き方

普通は紐をまっすぐ引っ張れば抜けるが、どうしても抜けない場合にロックを外す方法。

こう刺さっている場合、手前の凹の出っ張り部分に爪楊枝を差し込み、てこの原理で持ち上げるとロックが外れるので、この状態で紐を真っすぐに引っ張る。

挿し方

まず刺さっているかどうかの確認方法。確認環境はUbuntu 24.04.3 LTS。

1. ethtool enp1s0f0np0の出力に以下の内容が含まれることを確認

   Speed: Unknown!
   Duplex: Unknown! (255)
   Link detected: no

2. 以下のコマンドでカーネルレベルで抜けていることを確認

   sudo dmesg | grep -i 'mlx5' | grep -i 'Cable unplugged'
   

3. NICのコネクタのランプが点灯していなければ挿しなおす

ハマったので残しておく。

• 前提条件
• やり方
• トラブルシュート
  • 正常に動いていない場合
  • If the version you need is missing, try upgrading ruby-build.といわれる場合

前提条件

1. GitHubにMastodon本家をForkしたリポジトリがあり、そこをベースに運用している。
2. git remote -vの状態が以下の通りで、origin/mainが本番運用ブランチ。

   mastodon        https://github.com/mastodon/mastodon.git (fetch)
   mastodon        https://github.com/mastodon/mastodon.git (push)
   origin  https://github.com/Lycolia/lycodon.git (fetch)
   origin  https://github.com/Lycolia/lycodon.git (push)
   

やり方

1. マージブランチを作る

   git checkout -b merge-latest
   

2. 本家を取ってくる

   git fech mastodon
   

3. マージブランチにマージする

   git merge mastodon/main
   

4. セットアップする

   # swich user
   sudo su - mastodon
   # install
   bundle install
   yarn install
   # DBがアカンことがあるので叩いておく
   RAILS_ENV=production bundle exec rails db:migrate
   # いつものリビルド
   RAILS_ENV=production bundle exec rails assets:clobber
   RAILS_ENV=production bundle exec rails assets:precompile
   exit
   # 再起動
   sudo systemctl restart mastodon-web mastodon-sidekiq mastodon-streaming
   

5. 動作確認OKならgit pushしてGitHub上で自分のところのmainにマージする。デフォルトでは本家に向くので注意
6. もう一度、前述4番のセットアップコマンド一式を流し、問題なければ終わり

トラブルシュート

正常に動いていない場合

ジャーナルを見てエラー原因を特定する。新規要素がらみのパラメーターが出てたらDBが怪しいのでRAILS_ENV=production bundle exec rails db:migrateで直る可能性がある。

sudo journalctl -u mastodon-web -f

If the version you need is missing, try upgrading ruby-build.といわれる場合

以下のコマンドを叩いてruby-buildを更新するといける

cd  "$(rbenv root)"/plugins/ruby-build
git pull

なんか昔のやり方が使えなくなってたので調べたメモ。

• 確認環境
• 手順
• 検証ユーザーの作成
• フロントエンドのビルドとサーバー起動
• トラブルシューティング
  • localhostではアクセスできるが、マシンのホスト名やhoge.testのようなローカルドメインでアクセスできない
  • ActiveRecord::PendingMigrationErrorなど、ActiveRecord関係のエラーが出る
  • Unable to load application: NameError: uninitialized constant LetterOpenerWebというエラーが出る
• あとがき

確認環境

手順

DEVELOPMENT.md#dockerの手順通りにやると行ける。

docker compose -f .devcontainer/compose.yaml up -d
docker compose -f .devcontainer/compose.yaml exec app bin/setup
docker compose -f .devcontainer/compose.yaml exec app bin/dev

コンテナへのアタッチ方法

# 方法1
docker compose -f .devcontainer/compose.yaml exec app zsh

# 方法2
cd .devcontainer
docker compose exec app zsh

VSCodeがあるならDockerやRemoteほげほげ系の拡張を使い、devcontainer-appにAttach Shellしてもよい。

検証ユーザーの作成

1. 次のコマンドでユーザーを作る

   ./bin/tootctl accounts create hoge --email hoge@example.com --confirmed
   

2. ユーザーの承認を行い、必要に応じてパスワードを使いやすいものに変更する

   rails console
   user = Account.find_by(username: 'hoge').user
   user.approve!
   # PW変更ここから
   user.password = 'password'
   user.skip_confirmation!
   # PW変更ここまで
   user.save!
   quit
   

フロントエンドのビルドとサーバー起動

bin/rails assets:precompile
bin/dev

トラブルシューティング

localhostではアクセスできるが、マシンのホスト名やhoge.testのようなローカルドメインでアクセスできない

.env.developmentにALTERNATE_DOMAINS=hoge.testの行を追加することで他のドメインでもアクセスできる。

この設定があるとMastodonを別環境で動かしててリモートからドメインアクセスする場合に便利。

ActiveRecord::PendingMigrationErrorなど、ActiveRecord関係のエラーが出る

コンテナの中でrails db:setupを叩くことで解決する。

Unable to load application: NameError: uninitialized constant LetterOpenerWebというエラーが出る

リポジトリルートにあるdocker-compose.ymlを使うと発生するので、.devcontainer/compose.yamlを使う事で解決する。

あとがき

検証用にバニラなMastodon環境が欲しくて作ってみたが昔と変わっていて地味にハマった…。

こんな感じにフォーカスが当たるとOS標準の枠が出て、矢印キーの左右で選択状態を切り替えられる<input type="radio" />要素の作り方。

大まかには<label><input type="radio" /></label>の構造にして、UI上はラベルを疑似要素的に表示し、ラジオボタン本体はUI上見えなくするが、display: none;にせず、画面に残すことによってタブ遷移できるフォーカス可能要素として設計する内容。

サンプルコード

デモページ

CSS

/* ラジオボタンを等間隔に整列し、左右に余計な空白を持たせない */
.radio-container {
    display: flex;
    column-gap: 0.25rem;
}

.hidden-radio {
    /* チェックを消す */
    appearance: none;

    /* 非推奨要素を使っているが、iOS Safari対策 */    
    position: absolute;
    clip: rect(0, 0, 0, 0);
    pointer-events: none;
    
    /* デフォルトマージンがチェックボックスの位置にあるので消す */
    margin: 0;
}

.radio-label {
    /* 文字列要素を綺麗に中央寄せする */
    display: flex;
    justify-content: center;
    align-items: center;

    /* 枠装飾、基本的にフォーカス枠が角丸であり、違和感がないようにborderも角丸にしておく */
    padding: 5px;
    border: 1px solid #60bce9;
    border-radius: 4px;

    /* 見かけ上ボタンなのでカーソルをボタン用にする */
    cursor: pointer;
}

/* ラジオチェック時にラベルの背景色を変化させる */
.radio-label:has(.hidden-radio:checked) {
    background-color: #60bce9;
}

/* ラジオフォーカス時にラベルのフォーカス枠を出す */
.radio-label:has(.hidden-radio:checked):focus-within {
    outline: auto;
}

HTML

<form>
    <div class="radio-container">
        <label class="radio-label">
            <input name="r2" type="radio" class="hidden-radio" value="1" checked />
            <span>道明寺</span>
        </label>
        <label class="radio-label">
            <input name="r2" type="radio" class="hidden-radio" value="2" />
            <span>長命寺</span>
        </label>
    </div>
</form>

久々にPC構成を大刷新してから三ヶ月ほど経過しているが、ローカルLLMを叩いたときのパフォーマンスが前回と比べてどれほど上がるか計測してみた。

• 環境の現新比較
• ベンチマーク結果
  • gpt-oss:20b
  • gemma3:27b
  • lucas2024/mistral-nemo-japanese-instruct-2408:q8_0
  • qwen3:30b
  • qwen3:32b
• 雑感

環境の現新比較

ベンチマーク結果

前回はストップウォッチで計測していたが、今回はOpenWebUIのメタ情報から確認した。

gpt-oss:20b

今回新規で追加。なんかこいつが標準っぽいので測ってみた。

gemma3:27b

前回は出力に3分半程度かかっていたが、今回は一分半程度と、良好な結果となった。

lucas2024/mistral-nemo-japanese-instruct-2408:q8_0

前回は出力に1分程度かかっていたが、今回は14秒程度と、非常に良好な結果となった。

qwen3:30b

今回新規で追加。悪くない品質で、そこそこ早いのでこれは良さそうだ。

qwen3:32b

今回新規で追加。流石に秒間5.66トークンは厳しい。

雑感

前回と比べるとかなり高速化されており、生成速度だけを見れば十分実用ラインに上がっていているように感じた。しかし回答の品質がそこまでよくなく、そのままでは使えないと感じた。恐らくRAGなどとして使えるようにカスタムしてやっと使えてくるみたいなところがあるのだろうか？

実用性で見ると、日本語文書作成ではgemma3:27bが一番よさそうに思えた。これはqwen3シリーズは単純な質問では結構いい感じなのだが、複雑な条件を付けると期待通りの結果を出してくれなかったからだ。lucas2024/mistral-nemo-japanese-instruct-2408:q8_0も、一見よさそうに見えるがよろしくない発言はできないように細工されているようで、微妙に感じた。

何はともあれ、現実的な速度でローカルLLMが動くようになったのはうれしい。