細い回線でVNC connectとrustdeskを実行した。

細い回線で実行。

ちゃんとしたログは取っていないが、明らかにrustdeskの方が体感がよかった。

vnc connectがP2Pできずに、通信をクラウドにフォールバックしてるのかと思ったが。

そこは調べていない。

多分P2Pできてると思いたい。

GPTの回答

✅ じゃあなぜ RustDesk の方が速く感じるのか？

👉 核心は「圧縮アルゴリズムと描画エンジンの違い」

---

🔄 比較：圧縮と描画方式の違い

項目	VNC Connect	RustDesk
圧縮アルゴリズム	JPEG（画質優先）や Zlib など	Zstd / LZ4（高速 + 効率）
描画方式	RFBプロトコル準拠（ピクセル転送 + JPEG圧縮など）	Rust製ストリーム描画（差分検出 + 効率転送）
リフレッシュ	フレーム単位 or 画面全体	差分更新（動いたとこだけ送信）
入力の反応	遅くはないが「ずれ」や「じわり」が出やすい	体感ゼロラグに近い
転送サイズ	高解像度 + フル更新だと大きくなる	軽い・最小限のバイナリ転送

本当か？

本当にVNC connectも最新の転送技術を使っていないの？

ChatGPT:

良い疑問です！
結論から言うと：

---

✅ VNC Connect も最新の転送技術は使っています。

ただし、設計思想が「安定・互換・画質優先」寄りなので、RustDeskのような「超リアルタイム＆軽さ最優先」にはなっていない、というのがポイントです。

---

🧠 もう少し詳しく解説：

✅ VNC Connect が使っている最新技術（実際のところ）

技術カテゴリ	VNC Connect の対応
P2P接続/NAT越え	✅ STUN/UDP Hole Punching 対応
TLS暗号化	✅ 通信は E2E 暗号化
自動中継/フォールバック	✅ 接続できなければクラウド中継へ
圧縮転送	✅ JPEG 圧縮、Zlib 圧縮など対応
セッション再開/持続性	✅ 接続の自動再試行、解像度変更への自動対応
画面差分検出	✅ 効率的な差分転送（ただし方式は公開されていない）

---

🤔 じゃあ、なんで RustDesk の方が「速く」感じるの？

これは技術の 「世代」と「重視するもの」の違いです。

🏛️ VNC Connect（RealVNC）は：

• 長年の商用実績がある

• 企業/教育/医療など、トラブルがあってはいけない業界向け

• 安定性、互換性、画質、ログ管理、統合サポートに重きを置いている

• だからこそあえて「急ぎすぎない」描画や通信制御をしてることもある

🚀 RustDesk は：

• 新興プロジェクト（AnyDeskに近い発想）

• 「とにかく軽い・速い・即時操作」を最優先

• 最新の軽量プロトコルや圧縮方式を積極的に取り入れている（Zstdなど）

---

🧪 たとえるなら…

観点	VNC Connect	RustDesk
車でいうと	メルセデスの高級セダン（安定・信頼）	軽くて速いスポーツカー（チューニング重視）
ネット回線でいうと	QoS付きで落ちない回線	ピーク時めっちゃ速い光回線

---

✅ 結論（総まとめ）

• VNC Connect も現代的な転送・暗号・P2P技術はしっかり使っている

• ただし、設計思想が「保守的・安定寄り」

• RustDesk はリアルタイム性・転送軽さ・スピードに特化

• よって、体感としてRustDeskの方が「速く・軽い」と感じることが多い

気になったので、まとめてみた。

📊 圧縮・転送技術比較表

項目 / ソフト	Brynhildr	VNC Connect	RustDesk	AnyDesk	TeamViewer	Splashtop
🇯🇵 製作者	日本（ぺ＾）	英国 RealVNC社	中国発OSS	ドイツ AnyDesk社	ドイツ TeamViewer社	米国 Splashtop社
📡 転送方式	独自プロトコル	RFB（VNC）	独自軽量プロトコル	DeskRT	独自（TCP/UDP）	独自（UDP + H.264）
🧠 描画方式	フルフレーム or 差分推定（未公開）	ピクセル転送（JPEG/Zlib圧縮）	差分検出 + バイナリ転送	DeskRT（時間軸含む差分）	差分転送 + 転送量最適化	H.264 ハードウェア支援可
🗜️ 圧縮アルゴリズム	未公開（独自 or Zlib系）	JPEG, Zlib等	Zstd, LZ4	DeskRT（軽量 + 高圧縮）	Zlib, JPEG, その他	H.264 or VP8 (選択式)
⏱️ 遅延特性	中（ローカルは快適）	やや遅め（画質優先）	低遅延（P2P時特に）	超低遅延（<16ms）	中（安定性寄り）	低〜中（H.264支援で高速）
📶 ネット適応性	低（帯域に依存）	自動画質調整あり	可変圧縮（帯域対応）	高（帯域に応じ動的転送）	中〜高	高（細かいネット調整あり）
🔁 NAT越え	❌ 不可（VPN推奨）	✅ STUN/中継対応	✅ STUN/NAT穿孔優先	✅ 中継・直結対応	✅ 自動中継	✅ 中継・P2P両対応
📥 転送量の最適化	△ 部分的対応	△ 最小限（画質優先）	✅ 軽量転送を優先	✅ DeskRTが得意	✅ ある程度対応	✅ H.264圧縮で転送量削減
🔐 暗号化	✅ AES128程度（推定）	✅ TLS (E2E)	✅ TLS + E2E	✅ TLS + 2FA	✅ AES256	✅ TLS/SSL
💬 備考	軽量・簡単・日本語完全対応	高画質安定・老舗	OSS・高速・セルフホスティング可	超低遅延・UI快適	法人向け豊富な機能	学校・企業で人気・安定

---

💡 特筆ポイント

• Brynhildr：ローカル環境では快適だが、NAT越えや動的な画質調整、高圧縮には非対応。ローカルVPN環境での使用がベスト。

• RustDesk：超軽量・OSS・Zstd圧縮で軽快。P2P時の反応速度が驚異的に速い。

• AnyDesk：DeskRTという自社設計の次世代コーデックにより、動きのある画面も滑らか。低遅延性能ではトップクラス。

• TeamViewer：安定性・サポート・企業統合に強く、多少の遅延は気にせず信頼性重視。

• Splashtop：H.264 ハードウェア支援が強力で、リモート動画や音声転送に強い。教育現場でも好評。

• VNC Connect：画質優先設計で古典的だが安定性あり。ただし、最新の圧縮技術には遅れがち。

---

🧠 まとめ：どれが向いてる？

用途	おすすめ
ローカルで軽くて簡単	✅ Brynhildr
OSS & 自ホスティングしたい	✅ RustDesk
滑らかでプロフェッショナルな操作感	✅ AnyDesk
安定性＆法人サポート	✅ TeamViewer
動画・教育用途	✅ Splashtop
レガシー互換・保守的運用	✅ VNC Connect

VS Code Remote-SSHで初期ディレクトリをリモート側で固定する方法

VS Code Remote-SSHで初期ディレクトリをリモート側で指定する方法

SSH接続時に任意のディレクトリを開く。

WSLの場合、以下のファイルを実行権限にしシェルコマンドを記述

  nano ~/.vscode-server/server-env-setup

  cd /home/myapp

# 実サーバの場合

リモート先を開くことはできないがターミナルだけでも開いておく。

nano ~/.bashrc

# VS Code / Cursor からの接続時に初期ディレクトリを変更
if [[ "$TERM_PROGRAM" == "vscode" || "$TERM_PROGRAM" == "cursor" ]]; then
 cd /home/myapp
fi

プログラマー的、雑なコラッツ予想の証明法？

唐突にこれを思い出して、アニメーションが気に入らないのを直した。

https://collatz-conjecture-calculator.netlify.app/

GPTに聞いてみる。

コラッツ予想の証明法で、以下の反証はありますか？

任意の数を2進数のビット列に変換する。

処理１（偶数の時、n÷２は1bit目が1になるまでビットシフトと考える）

処理２（奇数の時、3n+1は1bit目に注目すると、３回ビットが変わる、つまりNOT）

自明１：二進数なので0,1以外は存在しない。

自明２：処理１では、どんな数でも必ず1bit目に1が来る。

自明３：3n+1した結果がどんなビット列であろうが0が存在する限り、列が詰まる（やべー！0を含む確率になってしまった・・・）

自明４：処理２により必ず0が存在する

反証１：これを満たさないビット列は0,1以外で構成された数のみ。

自明４：反証１は自明１により存在しない。

1に収束することが明示的でないが・・・

証明完了？？

テレンス・タオの2019年の論文

背景：Collatz予想とは

• 基本的な操作
  任意の正の整数 $n$ に対し、

  • $n$が偶数なら $n/2$
    

  • $n$が奇数なら $3n+1$
    を繰り返すと、最終的に1に到達する、という未解決の予想です。

• 従来のアプローチ
  多くの数値実験や部分結果はありますが、すべての自然数について1に到達するという完全な証明は得られていません。

---

タオの論文の主な成果

• 「ほとんどすべての整数」についての結果
  タオは、任意の正の整数のうち、例外となるもの（もし存在するとしてもその割合が0）を除けば、ほとんどすべての整数について Collatz の軌道が「ほぼ有界」な値域に入ることを示しました。
  これは、もし Collatz予想が正しいなら「ほとんどの整数の軌道は最終的に1に収束する」とみなせる状況に近いと言えます。

• 「ほぼ有界」の意味
  論文では、どんなに小さな上界 $A$ を取っても、自然数全体の中で、その軌道が最終的に $A$ 以下に落ち込む整数の割合が 1 に近づく、という形で証明されています。
  つまり、例外の可能性がある数はあっても、その集合の自然密度は 0 であるという結果です。

---

使用された手法

• 解析的・確率論的手法
  タオは、Collatz写像の振る舞いをランダムなプロセスに近い形で捉えることで、その長期的な動きを解析しました。
  エルゴード理論や解析的手法、さらには確率論のアイデアを組み合わせ、軌道がある有界な範囲に入る確率を厳密に評価しています。

• 自然数の密度の概念
  「ほとんどすべての整数」という表現は、すべての自然数の中で例外となる数の割合がゼロである（すなわち自然密度1である）という意味です。
  このアプローチは、すべての整数について証明するのが難しい問題に対して、「例外は極めて稀である」ことを示す手法として有効です。

詳しく聞いてみる。

1. Collatz予想とその背景

• 基本的な操作
  任意の正の整数 $n$ に対し、

  • $n$ が偶数なら $n\mathrm{/}2$

  • $n$ が奇数なら $3n+1$
    を繰り返すと、最終的に1に到達するかどうかがCollatz予想の問です。

• 未解決問題としての難しさ
  数値実験では非常に多くの数が1にたどり着いているものの、すべての整数に対してこの性質が成り立つかどうかは、依然として証明されていません。

---

2. 「ほとんどすべての整数」という意味

• 自然数の密度
  ここで「ほとんどすべての整数」とは、たとえば $N$ 以下の整数の中で、この性質（軌道がある有界な領域に入る性質）を持たない整数の数を $N$ で割った極限が0になる、という意味です。
  つまり、もし $A(N)$ を $N$以下で性質を満たさない数の個数とすると、

  $$\lim_{N\to\infty} \frac{A(N)}{N} = 0$$
  

  ということになります。例外は「極めて稀」であり、全体から見れば無視できる、という意味です。

---

3. タオの論文の主張とその手法

• 主張の内容
  タオは、Collatz写像の軌道に対して、確率的・解析的な手法を用いることで、「任意に小さな上界 $A$ をとった場合に、ほとんどの整数のCollatz軌道は最終的に $A$ 以下の値に入る」という結果を示しました。
  これは、もし本当にCollatz予想が正しいならば、例外があったとしてもその割合はゼロになるという見方に対応します。

• 使用された手法の概要

  1. 解析的・確率論的アプローチ
     Collatz写像は、厳密な意味では決定論的な操作ですが、大きな数に対してはその挙動が非常に「ランダム」に見えるため、確率論的な手法で扱うことができます。タオはこの性質を利用して、軌道がどのように動くかを統計的に解析しました。

  2. エルゴード理論や停止時間解析
     数列がどのくらいの速さである有界な領域に入るかを調べるために、停止時間（ある基準値以下になるまでのステップ数）の分布など、エルゴード理論的な考察も応用されました。

  3. 「ほぼ有界」性の証明
     任意の大きな $N$ に対して、ほとんどの $n\le N$ について、Collatz写像の軌道が最終的に非常に小さな値に落ち込む（たとえば、ある固定の $A$ 以下になる）ことを示すことで、例外となる数が自然密度的に0であることを導き出しました。

• この結果の意味
  この証明は、もしCollatz予想が間違っている（つまり、1に収束しない整数が存在する）としても、そのような整数は非常に稀で、全体から見れば無視できる（自然密度0）ということを意味します。
  一方、逆に言えば、「ほとんどすべての整数」については、予想される通りの振る舞い（最終的に有界な領域、ひいては1に近づく）が実現されるということです。

---

4. この結果の意義と今後の課題

• 意義

  • 数学界においてCollatz予想は非常に有名で難解な問題ですが、タオの結果はその中でも「大多数」の場合についての理解を大きく深めたものです。

  • もし例外が存在するとしても、その反例は非常に特殊で稀なものでなければならないことが示され、Collatz予想が「ほぼ正しい」ことを裏付けています。

• 今後の課題

  • なお、タオの論文はすべての正の整数について1に到達することを証明しているわけではありません。

  • 自然密度0の例外が存在する可能性（理論上は無視できるが、厳密に否定されていない）については未解決です。

  • このため、Collatz予想そのものの完全な解決には、まだ残された問題があることになります。

---

まとめ

テレンス・タオの2019年の論文は、Collatz写像における「ほとんどすべての整数」が最終的にある有界な値域に入る、つまり軌道が「ほぼ有界」であることを証明しました。

• 自然数全体の中で、例外となる（軌道が有界にならない）数は極めて稀である（自然密度0）

• これにより、Collatz予想が間違っているとすれば、その反例は全体から見れば無視できるほど小さい集合に限られるという新たな知見が得られました。

この結果はCollatz予想の「全体解決」には至らないものの、これまでの解析とは異なるアプローチで大多数の整数に対する理解を深め、今後の完全な証明に向けた重要な一歩と考えられています。

baiduのLLM

日本の番号が登録できないので、以外を試したが無理っぽい。

https://moxile.net/blog/?p=44286

よくわかってないが、wechat loginとかしか選べなかった。

bless network

DePin

https://bless.network/dashboard?ref=YEBJY3

仮装身分捜査の厳格なガイドライン

 

仮装身分捜査の厳格なガイドライン（実施要領）

警察庁が導入した仮装身分捜査（偽の身分証を用いた潜入捜査）について、実施要領に基づく厳格なガイドラインを以下にまとめます。

1. 適用対象犯罪

• SNS等を利用した組織的犯罪に限定
  • 闇バイト型強盗
  • 特殊詐欺（振り込め詐欺、投資詐欺、ロマンス詐欺など）
  • 違法薬物・銃器取引（麻薬密売、違法銃器販売）
  • 人身売買や売春あっせん

2. 使用できる偽の身分証の範囲

• 原則として**「画像データ」**のみ（物理的な偽造証は作成不可）
• 偽名・架空の個人情報を使用可
• 捜査対象となる犯罪グループの本人確認要請時のみ提示
• 実在する個人の名前や情報を使用してはならない
• 公的機関発行の証明書の偽造は禁止（例：パスポート、マイナンバーカード）

3. 実施許可と管理体制

• 捜査員の判断ではなく**「警察本部の上級管理職」の承認が必要**
• 必要最小限の使用に限定（漫然とした潜入捜査は禁止）
• 捜査終了後は速やかにデータを削除し、不正使用を防止

4. 目的外使用の禁止

• 犯罪グループ以外の第三者に偽の身分証を提示することは禁止
• 偽の身分情報を用いて公共サービス（銀行口座開設、賃貸契約等）を利用してはならない
• 捜査目的以外での個人情報の作成・使用は禁止

5. 証拠の適正管理

• 仮装身分での会話・取引の証拠は録音・記録し、正当な捜査であることを証明
• 収集した証拠が裁判で適法と認められるよう管理を徹底

6. 捜査員の身分保護とリスク管理

• 仮装身分捜査の対象者が危険な組織に属する場合、捜査員の身元が暴露されないよう厳重な管理
• 危険を伴う場合は即時撤退の判断を可能にする
• 捜査員の精神的負担を考慮し、専門家によるメンタルケアを提供

7. 事後報告と監査

• 捜査終了後、警察内部で事後検証を実施
• 運用が適切だったかどうか監査委員会が審査
• 法律に基づいた適正な運用がされていたか、第三者機関による監視も導入

8. 違法収集証拠の排除

• 捜査の手続きに違反があった場合、収集した証拠は裁判で違法収集証拠として排除される可能性あり
• 違法捜査が発覚した場合、関係者の処分を含めた対応を行う

---

このように、日本では仮装身分捜査の運用を厳格に管理し、**「目的外利用の禁止」と「適正手続きを守ること」**を強調しています。
特に、偽の身分証を「物理的に偽造」することは認められず、画像データに限定されている点が特徴です。

Bunの組み込みCSSトランスパイラを使う

もともとnodeでviteで作っていたものをbunにしたら、lightningcssとpkgでエラーでまくった。

最近のbunには組み込みトランスパイラがあるのでそれを使う。

ランタイム「Bun」の最新版「バージョン1.1.30」

オープンソースの「Lightning CSS」パーサーを取り込んだ。Lightning CSSはRust言語で記述してあるが、これをZig言語で書き直して、BunのCSSパーサーとして実験的に採用した。使用するにはビルド時に「--experimental-css」フラグを付ける必要がある。

​Bun 1.2以降のバージョンでは、CSSパーサおよびバンドラが正式に組み込まれています。​これにより、CSSのトランスパイルやバンドリング機能を利用する際に、以前必要だった--experimental-cssフラグを指定する必要がなくなりました。​したがって、これらの機能を使用する際に--experimental-cssオプションは不要です。

github action上でコンパイルエラーになり、微妙になやんだ。

      - name: Setup Bun

        uses: oven-sh/setup-bun@v1

        with:

          bun-version: latest

1

Run bun run build:server

16$ bun build server/index.ts --target=node --outdir=dist

1717 | module.exports = require(`../pkg`);

18 ^

19error: Could not resolve: "../pkg"

20 at /home/runner/work/souzoku-AI-reader/souzoku-AI-reader/node_modules/lightningcss/node/index.js:17:28

21error: script "build:server" exited with code 1

22Error: Process completed with exit code 1.

バージョンが古かったらしい。

      - name: Setup Bun

        uses: oven-sh/setup-bun@v2

        with:

          bun-version: latest

windsurfが超絶バカになった winsdurf v 1.4.4

簡単に言うと完全に制御すると頭いい、デフォが超バカになった。

デフォでいい感じに動くのがwindsurfの売りだったのに・・・

cursorかclineかどっちか忘れたが、毎回急ハンドル切るモードになってる・・・

これトークンを無駄遣いするからイヤなんだよね。

一回スイッチが入ると、毎回これ言ってくる。

多分これ書かないと、まともにならないかも。

https://codeium.com/windsurf/directory

これじゃあほとんどcursorと変わらんのでは？

俺みたいに同時にいろんな言語を扱う奴にとって、これは致命的だ。

全ての環境で制御しないといけないなんて・・・

定期的にゴミが入る仕様で、この処理はtransformer系だと辛い・・・

この仕様、拡散系のモデルだと問題が起きにくいような気がするが

https://chat.inceptionlabs.ai/

一応聞いてみた。

結論

条件	トランスフォーマー系	拡散モデル
ゴミがランダムな場合	自己注意で無視しやすい	ノイズ除去で無視しやすい
ゴミが定期的な場合	学習時に影響を受けやすい	ある程度は無視できるが、解釈される可能性あり
出力の精度	文脈を維持しやすいが、ゴミが多いと影響を受ける	文脈の再構築能力が高いが、特定のキーワードとして扱われる可能性

どちらが適切か？

• ゴミの影響をできるだけ無視したい場合 → 拡散モデルの方が適している
  • 本来のデータ分布を学習し、ノイズを除去する仕組みなので、「定期的なゴミ」があっても無視できる可能性が高い。
• 言語処理（自然言語のプロンプト）なら → トランスフォーマーの方が意味を保持しやすい
  • ただし、定期的なゴミを意識してしまう場合があるので、事前にクリーンなプロンプトを作る工夫が必要。

つまり、ゴミのパターンが予測できるなら、前処理を行えばトランスフォーマーも問題なく扱えるが、前処理なしで頑丈な処理を求めるなら、拡散モデルの方が適している可能性が高い。

vscodeのrust拡張機能がおかしい

署名がおかしい。

ただ切れてるだけなのか？

それぞれの、拡張機能を個別に入れても問題は発生しないので、

rust (1YiB)を削除し、以下を個別で入れた。

・rust-analyzer

・Rust Syntax

・crates

デカいコードをリファクタリングしてみる

bolt.newで作って、boltじゃ処理しきれなくなった（コードを破壊する）ので、

ローカルに持ってきていじって、かなり大きくなってしまった。

クソゴミコードをwindsurfのエージェントやmadgeで削ったが、一向によくならない。

以前作ったすべてのソースを１ファイルにする奴で、o1 proに頼んだら、改善点を見つけてくれた。

それをAIエージェントで修正するのが大変なんだが・・・

UIと機能を壊さないように指示をした。

すべてcluade 3.7 sonnet(thinking)

cursor --- たぶん3.7 sonnet(thinking)でダメな気がするから、やってない。もしかしてcursorが一番リファクタが得意だったりするか？

Devin --- めんどうなのでやってない。

WindSurf --- いつのまにかUIを壊した。

RooCline --- 完全放置で３０分かかった、わずかに小さくなったが、追いにくいバグが発生したので、捨てた

ClaudeCode --- こいつリファクタリング最強っぽい

そういえば、新調してからWSL2もdockerもpodmanも入れてなかった・・・

ちょっと面倒なので、powershell7.5でやってみたが、無理だった。

以下メモ書き。

wsl上のubuntuで実行しているのに下記のエラー。

npm error code 1 npm error path Claude Code is not supported on Windows. npm error Claude Code requires macOS or Linux to run properly. npm error If you are using WSL (Windows Subsystem for Linux): npm error 1. Make sure you are running npm install from within the WSL terminal, not from PowerShell or CMD npm error

WSL 内で npm config get prefix を実行し、出力が Windows のパス (になっていないか確認してください。

Windowsのパスが出てしまう場合: npm が Windows 側の node_modules を見ているため、WSL 用に変更する。

方法１

npm config set prefix ~/.npm-global

export PATH="$HOME/.npm-global/bin:$PATH"

方法２

npm config set prefix /usr/local

export NPM_CONFIG_PREFIX=/usr/local

そして、シェルを再読み込み

source ~/.bashrc

replit agent v2 eraly access

replitのエージェントは、もともと結構賢い。

さらに調整された様子。

なんならdevinより賢い、開発の記述ルールは設定できないけど。

賢いというのは、提案とか考え方が割とイケてる。

https://docs.replit.com/replitai/agent-v2

今回、依頼した内容がエラーハンドリングの強化なので、全然よくなっているかわからんかったが・・・

だが、遅いなコイツ・・・

完全に決まりきった事をするなら、RooClineが超絶早いんだよな。

エッジサービスでPHP実行できるサーバ屋

WASMER

まず、名前が好き！

wasmは軽く触ったぐらいなんだが・・・

z80, x86, 6502, 68000, V30MZ, armなど直いじりしてた俺には激刺さる！！

githubから直接デプロイできる。

テンプレートでwordpress入れられる。

↑これ内部的にwasmで動いている

無料でも使える。

cloudflare pages/workers 見たいな使い方で、無料でPHP動くのはすごいな！

https://wasmer.io/

https://wasmer.io/pricing

ここが作ってる静的配信サーバ。ベンチ見るとlight speedとかnginxとかとほぼ変わらない。

なのにマルチプラットフォームでAndroidで動く・・・

https://static-web-server.net/

このサーバ屋自体が、コンテナ的な処理をWASMで動かしているっぽい。

やったことないから知らんが、初回起動のオーバーヘッドが大きそうな気がする。

どっかでWASMでos動かしてるの見たんだよな。

でも安全で早くて安いんだろうな。

claude-3-7-sonnet-20250219のAPI料金

claude-3-7-sonnet-20250219

3.5 sonnetと同じ。

直にAnthropicのAPIを使えば、拡張思考モードも同じ値段。

バッチ処理モードだと50% OFF

API料金

https://www.anthropic.com/pricing#anthropic-api