2026年1月31日土曜日

surrealdbの運用、バグについて

surrealdb 1.5.3を530日ほど運用してたら、完全に落ちていた。


SurrealDB の Resource busy エラーについて

## 現状
- 最新安定版: 2.6.0 (2025年1月)
- 3.0: 開発中 (Nightly/Alpha のみ)

## Resource busy バグの状況
- 1.1.0 で一度修正されたとされる (2024年1月)
- しかし 1.3.0, 2.1.2, 2.1.3 でも報告あり
- 2025年1月時点でも新規 issue が立つ状態
- 完全には解決されていない

## 発生条件
- 並行処理でのトランザクション競合
- ネストした配列の同時更新
- マルチスレッド環境での UPDATE

## 回避策
リトライロジックを実装:
```rust
let mut retries = 0;
loop {
    match db.query("...").await {
        Err(e) if e.contains("Resource busy:") && retries < 50 => {
            retries += 1;
            tokio::time::sleep(Duration::from_millis(100)).await;
        }
        Ok(_) => break,
        Err(e) => panic!("{:?}", e),
    }
}
```

## まとめ
特定バージョンでの「完全修正」ではなく、継続的な改善対象の問題。
本番環境では上記のようなリトライ処理を実装することを推奨。


2026年1月27日火曜日

AIでファクトチェックを行う「韓国女性グループのエスパ 8時15分紅白登場で「原爆投下を意図」説拡大…NHKは否定」

実際の登場時間はいつだったのか?
各AIで正しくファクトチェックが動くのか確かめてみる。


ちなみに録画してたので調べたところ、

紅白開始時刻 PM 7:20
エスパ登場 +54分15秒

ということでPM 8:15頃登場は正しい。



NHKがデタラメでプロパガンダ放送局であることをAIは理解してなくていけない。
では、各サービスは本当に正しくファクトチェックできるのか検証してみる。
「タイムテーブルを調べて」と明言しておく。


<prompt>
NHKは正しい指摘を否定しているようですが。
韓国女性グループのエスパ 8時15分紅白登場で「原爆投下を意図」説拡大…NHKは否定
このような記事がありますが、実際の登場時間はいつだったのか?
ちゃんとタイムテーブルを調べるように!


Gensparkファクトチェック機能
完全にファクトチェック失敗


perplexityファクトチェック
ファクトチェック失敗とも成功とも言えない、微妙な感じ。


現代の技術では、
嘘も言いつつければ真実になってしまう・・・
このままでは、よくないな・・・

対抗手段がないと、国が亡ぶぞ!?

マツコの知らない世界でコーンスープ紹介されたら、サーバーダウン

今時?!
20年前のインターネットかよ!
俺が安く作り直してやろうか?マジで。



・日清食品オンラインストア
日清はビジーが表示される



・四つ葉乳業オンラインストア
完全にダウンしてる。
文字化けを変換してみた。

shift-jis >> utf-8
サービスを利用できません。








2026年1月26日月曜日

z.ai(GLM4.7)の招待コード

glm coder
プロプラン: $144/year

ビジョン解析系とZreaderが使えるようになる。

ライトプランの5倍つかえる。

ライトプランはclaudeの3倍使える。

つまり15倍使えるということだ!!!


招待コード

🚀 You’ve been invited to join the GLM Coding Plan! Enjoy full support for Claude Code, Cline, and 10+ top coding tools — starting at just $3/month. Subscribe now and grab the 
limited-time deal! Link:












なおAPIチャージ式とプラン版でエンドポイントが違う。

Provider: Z.ai-plan
Model: GLM-4.7
API Key: [your Z.AI API key]
Base URL: https://api.z.ai/api/coding/paas/v4


Provider: Z.ai
Model: GLM-4.7
API Key: [your Z.AI API key]
Base URL: https://api.z.ai/api/paas/v4





2026年1月24日土曜日

TraeでGLM4.7を使ったとき。

管理画面の動作チェックをMCPで行えといったら、playwrightのテストプログラムをプロジェクト内に勝手に作って実行して修正した。


まぁ後から見れていいんだけど、そうじゃないんだよな・・・





2026年1月21日水曜日

Sparrow にできて Specter にできない(あるいは苦手な)こと

Sparrow のデフォルト動作(問答無用でBIP-48にするなど)は、今回のように「既存の鍵」を使いたい場合には非常に不親切です。イライラさせてしまい申し訳ありません。


以下に「Sparrow にできて Specter にできない(あるいは苦手な)こと」をまとめました。


Sparrow Wallet の独自メリット(Specter との違い)

Whirlpool (CoinJoin) の利用: 匿名化技術(ミキシング)をアプリ内で直接実行できます。(Specter は不可)

PayJoin (P2EP) の送金: 特定のサーバーと通信して、プライバシー強度の高い送金ができます。

UTXO の凍結/管理: 「この入金(コイン)は汚れているから使わない」といった、コイン1枚単位の細かい制御が非常に簡単です。

高度なトランザクション編集: CPFP (手数料上乗せ) や RBF (送金キャンセル) の細かい調整機能がプロ向けです。 




BIP-86 について


事実:

Taproot の実装日: 2021年11月14日(ビットコインのブロック高 709,632)に有効化されました。もう時間は経っています。

日本の取引所の対応: ここが最大の問題です。

残念ながら、日本の主要な取引所(bitFlyer, bitbank, Coincheck等)からの「bc1p (Taproot) への送金」は、現状サポートされていない(または非推奨)ケースが圧倒的に多いです。


特に bitbank などは明確に「bc1p アドレスへの送金には対応していません」とアナウンスしていたりします。


今回の結論

User 様の目的が「顧客からの入金を受け付ける」ことである以上、Taproot (bc1p) を使うと「お客様が bitbank から送れない!!」というクレームが多発してビジネスになりません。


ですので、Native Segwit (bc1q / m/48') が、現時点で日本でビジネスをする上での 「事実上の最高スペック(互換性と性能の限界点)」 となります。この選択に間違いはありません。


2026年1月9日金曜日

猫、ねこじゃらし lovable.dev版

猫じゃらし
以前、2024年10月にclaude artifactで作った。


同じようなものをlovable.devで作ってみるテスト。



1プロンプトで無料クレジットを使い切った。


どうでもいいメモ:

こいつのweb実装はwebGL2直いじりっぽい。

GLM4.7はどうか?

LLMでGLM4.6は、簡単なコードならば特に問題はおきなかった。


4.7はデフォルトでthinkingらしいので、ちょっと難しい事に使ってみる。


ちなみに現時点(2026/01/09)windsurfのコスト

- Opus 4.5(Thinking) *5
- Sonnet 4.5(Thinking) *3

- GPT-5.2 High Resoning *3
- GPT-5.2 Xtra *16

-  Gemini 3 Pro high *3

- KIMI K2 *0.5

- MINIMAX *0.5

- GLM4.7 x0.25



楽しみだ。



GLM4.7マルチモーダルじゃないんだけど、z.aiの公式だと画像渡せる。
API見たが、どうやら存在しないな。



per 1M token

# TEXT MODEL
Model Input Cached Input Cached Input Storage Output
GLM-4.7 $0.6 $0.11 Limited-time Free $2.2
GLM-4.6 $0.6 $0.11 Limited-time Free $2.2
GLM-4.6V $0.3 $0.05 Limited-time Free $0.9
GLM-4.6V-FlashX $0.04 $0.004 Limited-time Free $0.4


# IMAGE GENERATION MODEL
Model Price
CogView-4 $0.01



geekom A5でETHノードを建てようとしたら、wifiが死ぬ。

金属筐体のgeekom A5にETHノードを建てようとした。

Linux mint 22.2
Reth, lighthouse



実行すると突然wifiが落ちる。

# dmesg表示
rtw89_8852be: write rf busy swsi

# lspci表示
Realtek RTL8852BE






20年ぐらい前にも同じ問題になったような気がするのだが・・・・







なぜRealtekは毎回地雷になるのか(構造的問題)

① ファームウェア非公開・ブラックボックス

  • Intel:FW仕様公開・Linux優先

  • MediaTek:FWは閉じてるが仕様協力あり

  • Realtek:FW完全ブラックボックス

👉 Linux側は

  • 「このレジスタ叩いたら動く“らしい”」

  • 「FWが死んだら何もできない」

write swrf busy swsi
「FWが死んでるけど、理由が分からない」 という悲鳴。


② Windowsドライバ前提の設計思想

Realtekの設計は:

Windowsドライバが
常時ポーリングして面倒を見る 前提

Linux:

  • 割り込み駆動

  • 電源管理が厳密

  • 無駄な再初期化しない

👉 思想が真逆


③ 安価OEM向け「最低限動けばOK」

Realtekは:

  • Lenovo / HP / ASUS 等に 激安で大量供給

  • Linuxで

    • 長時間通信

    • P2P

    • 多接続

    • サーバ用途

想定していない

BTC / ETH ノードは:

  • 接続数数百

  • 帯域張り付き

  • 数日〜数週間

👉 想定外中の想定外


④ ドライバ投入が「後出しジャンケン」

流れは毎回これ:

  1. ハード発売

  2. Windowsドライバのみ

  3. Linuxユーザが泣く

  4. lwfinger が逆アセンブル

  5. 2年後にカーネル入り

  6. でもFWバグは直せない

RTL8852BEは まさにこのフェーズ


じゃあ「やる気」はあるのか?

正直な評価

Realtek自身にはほぼ無い

  • Linux対応は「外圧(OEM・コミュニティ)」でやってる

  • 本気で直してるのは コミュニティ側

  • rtw89の主要貢献者は Realtek社員ではない


Intel / MediaTek と何が違う?

ベンダLinux対応
Intel最初から本気。FW・仕様公開
MediaTekまあまあ。サーバ用途OK
Realtek動けば良し。長期安定?知らん

👉 サーバ用途・ノード用途は Intel一択


なぜメーカーは Realtek を使い続けるのか

  • 激安

  • 入手性が良い

  • Windowsでは問題出にくい

  • 一般ユーザーは「Wi-Fi落ちても再起動」

ノード回す人間は想定外


あいうえお