技術文書 on KnightLiブログ

Windows Secure Boot証明書が2026年に期限切れ：一般ユーザーと管理者はどう更新すべきか

Wed, 20 May 2026 23:15:08 +0800

Microsoftは、Windows Secure Boot証明書の期限切れとCA更新に関する説明を更新しました。重要なのは「証明書が切れたらPCが起動しなくなる」という話ではありません。2011年に発行された一連のSecure Boot証明書が2026年6月から順次期限切れになり、Windowsデバイスは2023年の新しい証明書へ移行することで、今後の起動初期段階のセキュリティ保護更新を受け続ける必要がある、という点です。

原文：Microsoft Support: Windows Secure Boot certificate expiration and CA updates。

今回の更新は何を意味するのか

Secure BootはUEFIファームウェア内のセキュリティ機能です。OSが起動する前に、ブートローダー、UEFIドライバー、Option ROMなどのコンポーネントの署名を検証し、bootkitやrootkitのような起動初期段階のマルウェアを防ぐことを目的としています。

この検証は、ファームウェア内のいくつかのデータベースと鍵に依存しています。

KEK：キー登録鍵。Secure Bootデータベースの更新を承認するために使われる。
DB：許可された署名データベース。どの起動コンポーネントを信頼するかを決める。
DBX：失効署名データベース。信頼できない、またはリスクがあると判明した起動コンポーネントをブロックする。

Microsoftの説明によると、Windowsデバイスで長年使われてきた2011年の証明書群が期限切れに近づいており、対応する新しい証明書は2023年版になっています。これには、DB / DBX 更新の署名に使われるKEK証明書、Windowsブートローダーの署名に使われるWindows UEFI CA、サードパーティのブートローダー、EFIアプリ、Option ROMに使われるUEFI CAが含まれます。

起動に影響するのか

多くのユーザーが気にするのは、2026年に証明書が期限切れになったあと、PCが突然起動できなくなるのかという点です。

Microsoftの結論は比較的明確です。2023年の新しい証明書を受け取っていないデバイスでも、起動と通常利用は継続でき、標準的なWindows更新も引き続きインストールされます。ただし、これらのデバイスは、Windows Boot Manager更新、Secure Bootデータベース更新、失効リスト更新、新たに見つかった起動レベル脆弱性への緩和策など、起動初期段階に関わる新しい保護を受け取れなくなります。

つまりこれは、単純な「システムがすぐ使えなくなる」問題ではなく、「セキュリティ保護の連鎖が古くなる」問題に近いものです。短期的には機器は普通に動くかもしれません。しかし長期的には、新しいbootkit、起動チェーンの脆弱性、失効されたコンポーネントに対する防御力が下がります。

一般ユーザーがすべきこと

一般ユーザーがSecure Bootの鍵を手動で編集する必要はありません。BIOS / UEFIで証明書を不用意に削除、リセット、インポートすることもおすすめしません。

より安全な対応は次の通りです。

Windows Updateを有効にし、累積更新を適用する。
PCメーカーが提供するファームウェア、BIOS、UEFI、ドライバー更新をインストールする。
一時的な互換性問題のためにSecure Bootを長期間無効にしない。
BitLockerを有効にしている場合は、ファームウェアやSecure Boot関連の変更前に回復キーを確認する。
msinfo32 で「Secure Boot State」を確認し、Secure Bootが有効になっているか見る。

家庭用PCでの主なリスクは、多くの場合「操作がわからないこと」ではなく、ファームウェアを長期間更新しないことです。多くのノートPCやメーカー製PCのSecure Boot関連変更は、最終的にOEMファームウェアの対応に依存します。

企業管理者が注意すべきこと

企業環境で難しいのは単体のPCではありません。デバイスモデル、ファームウェアバージョン、暗号化ポリシー、展開ツール、サードパーティの起動コンポーネントが混在していることです。

まず次の四つから始めるのがよいでしょう。

デバイスモデル、Windowsバージョン、Secure Boot状態、ファームウェアバージョン、BitLocker状態を棚卸しする。
代表的な機種で小規模にテストし、段階的に展開を広げる。
Windows更新、OEMファームウェア更新、回復キーのバックアップ、PXE / MDT / ConfigMgr / Intuneの流れを一つの変更計画にまとめる。
回復メディア、イメージングツール、サードパーティのセキュリティソフト、デュアルブートのブートローダーが正常に起動するか検証する。

Microsoftのドキュメントには、IT管理デバイス向けにレジストリ、グループポリシー、WinCS API、Intune、監視例などの手段も示されています。企業では、今回の証明書更新を普通のパッチとして扱うべきではありません。ファームウェアレベルの変更として、テスト、段階的展開、ロールバック計画と一緒に扱うべきです。

デュアルブートとサードパーティ起動ツールは特に注意

Linuxのデュアルブート、サードパーティのブートローダー、独自署名のEFIアプリ、古い回復USB、オフライン展開ツールを使っているデバイスでは、今回の更新を早めに検証する価値があります。

理由は、Microsoftが従来の信頼の一部をより細かく分けたためです。たとえば、サードパーティのブートローダーとOption ROMに対応する信頼は、以前のように完全には一体化していません。これは信頼範囲を狭めるうえで有効ですが、古い起動コンポーネント、未更新のshim / GRUB、古い回復メディア、独自起動ツールが、将来署名の信頼問題に遭遇しやすくなる可能性もあります。

原則は単純です。証明書が期限切れになってから、回復USBも起動できないと気づくのは避けるべきです。重要な機器では、少なくとも一度は実際の回復手順を事前に検証しておくべきです。

やるべきでないこと

この種の問題は「証明書の期限切れ」に見えるため、BIOSに入って手動で鍵を変更したくなりがちです。しかし、メーカーやMicrosoftのドキュメントが明確に求めていない限り、それはおすすめしません。

Secure Bootを長期間無効にしないでください。本番デバイスでSecure Boot keysを直接消去しないでください。あるデバイスのファームウェア設定を、別モデルのデバイス群にそのままコピーしないでください。Windowsだけを更新し、OEMファームウェアを更新しないまま、問題が解決したと考えるのも危険です。

より適切な見方は、Windows更新がOS側を処理し、OEMファームウェア更新がプラットフォーム側を処理し、企業の展開ポリシーが大規模な一貫性を処理する、というものです。この三つのどれかが欠けると、後で原因を追いにくい起動問題になる可能性があります。

まとめ

今回のWindows Secure Boot証明書期限切れの実際の影響は、2026年のある日にすべてのPCが同時に起動不能になることではありません。古い証明書のデバイスが、今後のSecure Bootセキュリティ更新を徐々に受けられなくなることです。

個人ユーザーはWindowsとファームウェアを最新に保ち、Secure Bootを不用意に無効化しないことが重要です。企業管理者は、棚卸し、テスト、段階的展開を早めに始めるべきです。2026年6月に近づくほど、ファームウェア互換性、回復手順、まとめて戻すための計画に使える時間は少なくなります。

Hugo aliases の使い方：古い URL の自動リダイレクトと 404 修正ガイド

Sun, 17 May 2026 20:00:17 +0800

Hugo の aliases は、ページの古い URL に対してリダイレクトを作るための機能だ。

記事の URL を変更したとき、ページを統合したとき、ブログを移行したとき、またはよくある誤った URL を救済したいとき、記事の Front Matter に aliases を追加できる。Hugo はそれらの古いアドレス用にリダイレクトページを生成し、訪問者を現在の記事の新しいアドレスへ送る。これにより、古いリンクがそのまま 404 になるのを避けられる。

aliases が役立つ場面

よくある場面は三つある。

一つ目は記事 URL の整理だ。

たとえば、元の記事 URL が次のようなものだったとする。

`1`	`/posts/tech/2023-01-01-hello/`

後から、より短い URL に変えたい場合がある。

/hello/

このとき、新しい記事に古いアドレスを alias として追加する。すると検索エンジン、外部リンク、SNS 上の古いリンクからも内容へ到達できる。

二つ目はページの統合や移行だ。

複数の古い記事を一つの新しい記事にまとめる場合や、Hexo、Typecho、WordPress などから Hugo に移行する場合、古いプラットフォームの URL 構造は新しいサイトと一致しないことが多い。aliases を使えば、それらの古いアドレスを新しいページへ一つずつ向けられ、移行後の 404 を減らせる。

三つ目はスペルミスの処理だ。

URL を過去に誤って書いたり、外部サイトが間違ったパスにリンクしていたりすることがある。その誤ったリンクにアクセスがあるなら、専用の alias を設定して、ユーザーを正しいページへ誘導できる。

基本的な書き方

記事の Front Matter に aliases フィールドを追加するだけでよい。

YAML の例は次の通り。

---
title: "新しい記事タイトル"
date: 2026-05-17T12:00:00+09:00
url: /new-path/my-new-article/
aliases:
  - /old-path/old-article/
  - ../old-version/
---

ここで /old-path/old-article/ はサイト相対パスだ。../old-version/ は現在のページからの相対パスになる。

実際には、/ で始まるサイト相対パスを優先する方が分かりやすい。直感的で、記事ディレクトリ構造が変わったときにも誤解が起きにくい。

url フィールドとの関係

url は現在ページの新しいアドレスを決める。

aliases は、どの古いアドレスをその新しいアドレスへリダイレクトするかを決める。

例：

1
2
3

url: /new-path/my-new-article/
aliases:
  - /old-path/old-article/

ビルド後、ユーザーが /old-path/old-article/ にアクセスすると、/new-path/my-new-article/ へリダイレクトされる。

記事で url を明示していない場合、Hugo はサイトの permalinks 設定、記事の日付、slug などのルールから現在ページのアドレスを生成する。aliases はその最終的に生成されたページを指す。

Hugo のデフォルト実装

デフォルトでは、Hugo は alias ごとに独立した HTML ファイルを生成する。

その HTML ファイルは通常、次のタグを使う。

`1`	`<meta http-equiv="refresh">`

これにより、ブラウザが古いアドレスを開いたあと自動的に新しいアドレスへ移動する。

この方式はシンプルで、プラットフォームを問わず使いやすく、一般的な静的ホスティングに向いている。ただし本質的にはブラウザ側のリダイレクトであり、サーバーが返す 301 / 302 リダイレクトではない。

小規模サイトなら、通常はこれで十分だ。古いアドレスが開けて、最終的に新しい記事へ到達できるなら、目立つ 404 問題は避けられる。

サーバーサイドリダイレクトを検討する場面

サイトを Netlify、Cloudflare Pages、Vercel など、リダイレクトルールをサポートする環境で運用しているなら、サーバーサイドリダイレクトを検討できる。

サーバーサイドリダイレクトには次の利点がある。

中間の HTML リダイレクトページを返さず、より直接的に応答できる。
301 または 302 ステータスコードを明示しやすい。
大量の移行ルールを集中管理しやすく、監査と保守が楽になる。
SEO 移行をより制御しやすい。

よくある方法は、Hugo のデフォルト alias ページ生成を無効化し、ホスティング環境が必要とするリダイレクトルールファイルを出力することだ。Netlify では _redirects がよく使われ、Cloudflare Pages でも _redirects やプラットフォーム側のルールを使える。

この方針を取る場合は、Hugo の disableAliases とカスタム output format を確認する必要がある。単に aliases を削除してはいけない。そうすると古いリンクはそのまま 404 になる。

aliases を使うときの注意点

第一に、aliases を URL を気軽に変更する口実にしない。

URL は一度公開されると、検索エンジン、RSS、SNS、ブックマーク、外部リンクに入っていく。頻繁な URL 変更は保守コストを生む。aliases は、パスを頻繁に変えるためではなく、過去の問題を修正するために使うのがよい。

第二に、alias の循環を避ける。

古いアドレスは現在の記事の新しいアドレスへ向けるべきだ。A が B に飛び、B がまた A に戻るような構成や、複数ページが同じ alias を奪い合う構成は避ける。

第三に、多言語サイトでは言語プレフィックスに注意する。

Hugo の多言語サイトでは、言語パスが自動処理されることが多い。ある言語版の記事内で alias を書く場合、/en/ や /zh-tw/ のようなプレフィックスを手動で付けなくてよい場合がある。付けてしまうと /en/en/... のような重複パスが生成されることがある。具体的な挙動はローカルビルド結果で確認する。

第四に、変更後は生成ディレクトリを確認する。

alias を追加したら一度サイトをビルドし、public ディレクトリに古いパスに対応する index.html が生成されたか確認する。さらに、その中のリダイレクト先が正しいかを見る。

実用的な確認手順

記事の Front Matter を編集したら、次の流れで確認するとよい。

現在の記事の新しい URL を確認する。
aliases に古い URL を書く。
Hugo ビルドを実行する。
public ディレクトリで古い URL に対応する index.html が生成されたか確認する。
生成された HTML を開き、リダイレクト先が新しい URL か確認する。
多言語ページでは、言語プレフィックスが重複していないか特に確認する。

これで、デプロイ前に多くのパス問題を見つけられる。

まとめ

aliases は、Hugo で古いリンクを扱うための軽量な仕組みだ。

記事 URL の変更、ブログ移行、ページ統合、誤ったパスの修正に向いている。一般的な静的サイトなら Hugo がデフォルトで生成する HTML リダイレクトページをそのまま使える。サイト規模が大きい場合や SEO 移行をより厳密に扱いたい場合は、サーバーサイドリダイレクトルールへ進むとよい。

大事なのは、新しいリンクをきれいにすることだけではない。すでに存在する古いリンクも守ることだ。古い URL を新しいページへ滑らかに連れていけるサイトは、移行やリニューアルで過去の流入を失いにくい。

参考資料

FreeRTOS、RT-Thread、Zephyr の選び方：3 大 RTOS のアーキテクチャ差と適用場面

Sun, 17 May 2026 12:32:06 +0800

FreeRTOS、RT-Thread、Zephyr はよく同列で比較されますが、実際には同じ抽象レベルの製品ではありません。

問うべきなのは「どれが一番良いか」ではなく、プロジェクトに必要なのが軽量なスケジューリングカーネルなのか、国内 MCU に強い RTOS エコシステムなのか、それともクロスプラットフォームの組み込み OS なのかです。

大まかには次のように整理できます。

FreeRTOS：広く使われるスケジューリングカーネルと AWS 管理の IoT ライブラリ群。
RT-Thread：カーネルに加えて豊富なコンポーネントを持ち、中国語コミュニティと長尾 MCU に強い RTOS。
Zephyr：Linux Foundation 管理の RTOS で、統一サブシステム、デバイスモデル、Devicetree、アプリ再利用を重視する。

まず結論

タスク、キュー、セマフォ、タイマーだけで十分で、リソースも厳しいなら FreeRTOS は今でも安全な選択です。

中国系 MCU を多く使い、BSP、中文資料、ENV、コンポーネントを重視するなら RT-Thread が実用的です。

複数チップ、複数ボード、複数ベンダーでアプリケーションコードを再利用したいなら、学習コストを払ってでも Zephyr を検討する価値があります。

FreeRTOS：軽量で成熟したカーネル

FreeRTOS の強みは、小さく、よく知られ、非常に普及していることです。

FreeRTOS-Kernel はカーネル、移植層、タスク、キュー、セマフォ、イベントグループ、ソフトウェアタイマー、メモリ管理に集中しています。多くの現場で本当に使うのもこの部分です。

AWS による買収後は coreMQTT、coreHTTP、OTA、Device Shadow などの IoT ライブラリも整備され、LTS も用意されています。

ただし FreeRTOS は完全な OS プラットフォームではありません。GPIO、UART、I2C、ピン制御、ボード抽象、HAL 統一は基本的にベンダー SDK またはチーム側の仕事です。

これは欠点ではなく設計選択です。柔軟ですが、チップやボードを変えるとアプリケーション層まで影響を受けやすくなります。

RT-Thread：国内 MCU とコンポーネントに強い

RT-Thread は FreeRTOS より完全な RTOS に近い存在です。

スケジューラだけでなく、ファイルシステム、ネットワーク、デバイスフレームワーク、USB、センサー、パッケージ、ツールが揃っています。AT32、HC32、N32、APM32、HT32、合宙、HPMicro などの長尾 MCU で特に実用的です。

一方で、多くの BSP はまだボード固有、ベンダーライブラリ依存の色が強く、Zephyr のように Devicetree と統一ドライバモデルでアプリを横断的に保つ仕組みとは異なります。

Zephyr：RTOS というより組み込みシステム基盤

Zephyr は複雑ですが、その複雑さは単なる機能追加ではありません。

ベンダー SDK、BSP、HAL、手書きドライバ、設定スクリプト、アプリコードに散らばりがちな要素を、1 つの OS 工程にまとめようとしています。

中心になるのは Kconfig、Devicetree、統一 drivers、subsys、west、CMake、Board / SoC / shield 抽象です。これは小さな組み込み Linux 的な設計思想に近いものです。

Devicetree が重要な理由

Linux では DTB を起動時に渡し、カーネルが runtime に解釈して probe します。MCU では重すぎます。

Zephyr は DTS / overlay をビルド時に処理し、devicetree_generated.h と DT_ マクロに展開します。多くのハードウェア選択がコンパイル時に決まるため、runtime の負担は小さくなります。

これにより、ハードウェア記述とアプリコードが分離され、ボード変更は主に DTS 側で済みます。

アプリケーションコードがきれいになる理由

従来の MCU 工程では、初期化、ピン番号、割り込み、デバウンス、状態機械、イベントキュー、業務ロジックが同じ層に混ざりがちです。

Zephyr では、ハードウェア接続は DTS、機能スイッチは Kconfig / prj.conf、ドライバは主線または module、アプリはイベント処理に寄せる設計になります。

これが多ボード、多チップ、長期保守のプロジェクトで効いてきます。

資源コストは文脈で見る

Zephyr は最小 FreeRTOS より Flash が増えることがあります。ただしそれは統一ドライバ、input、log、device object などの基盤コストです。

機能が少なくボード固定なら FreeRTOS が有利です。外設やボードが増えるほど、Zephyr の基盤コストは再利用されます。

どう選ぶか

固定ハードウェアで、軽量なスケジューリングだけ必要なら FreeRTOS。

国内 MCU、中文資料、BSP、コンポーネントを重視するなら RT-Thread。

複数ボード、複数ベンダー、長期保守、統一ドライバ、Linux 的な設計思想を重視するなら Zephyr。

Zephyr を選ばない方がよい場合

単一ボードで機能が小さい、チームに学習時間がない、対象チップの Zephyr 主線対応が弱い、閉じたベンダー SDK に強く依存している、すでに量産済みで安定している場合は、無理に移行する必要はありません。

まずは主線対応の良い開発ボードで LED、UART、GPIO、input、I2C / SPI を試すのが安全です。

まとめ

FreeRTOS はスケジューリングを解決し、RT-Thread はコンポーネントと国内 MCU エコシステムを補い、Zephyr は MCU ソフトウェア工程そのものを統一しようとします。

小型固定機器なら FreeRTOS、国内 MCU 製品ラインなら RT-Thread、複数プラットフォームと長期保守なら Zephyr が有力です。

参考リンク：

2023-2026年の大規模モデルアーキテクチャ総復習：トークナイザ、位置エンコーディング、注意機構、MoE、正規化、活性化関数

Sun, 17 May 2026 08:53:29 +0800

2023 年から 2026 年にかけて、大規模モデルのアーキテクチャは多くの面で変化しました。トークナイザは大きくなり、位置エンコーディングは RoPE が主流になり、注意機構は MHA から GQA、スライディングウィンドウ、MLA へ広がりました。MoE も再び主流となり、正規化や活性化関数も RMSNorm や SwiGLU のような組み合わせへ移っています。

ただし一言でまとめるなら、この数年の主役は「Transformer が置き換えられた」ことではありません。Transformer の中核は残ったまま、より長いコンテキスト、低い推論コスト、高い訓練効率、強い多言語対応のために周辺部品が最適化された、という流れです。

まず全体像をつかむ

大規模モデルは、おおまかに次の部品に分けられます。

トークナイザ：文字列をモデルが理解できる token に分ける。
位置エンコーディング：各 token が文のどこにあるかを伝える。
注意機構：各 token がどの文脈を見るべきかを決める。
フィードフォワードネットワーク：各位置でより複雑な非線形変換を行う。
正規化：訓練を安定させる。
活性化関数：ネットワークに非線形表現力を与える。
MoE：フィードフォワード部分を複数の専門家に分け、毎回一部だけを使う。

2023-2026 年の進化は、これらの部品が順番に最適化されてきたものだと考えると分かりやすいです。

トークナイザ：「分けられる」から「token を節約する」へ

トークナイザの役割は、自然言語を token 列に変換することです。モデルは文章そのものではなく、token ID の列を見ています。

初期のトークナイザは英語に強く、中国語、コード、多言語テキストでは token 効率が悪いことがありました。同じ文章でも細かく分かれすぎると、コンテキストウィンドウを余計に消費し、訓練と推論のコストも増えます。

近年の明確な傾向は、語彙サイズの拡大と多言語対応の強化です。Llama 3 は 128K token の語彙を使い、Meta はそれによって言語をより効率よくエンコードし、性能向上につながると説明しています。Qwen や DeepSeek も、中国語、コード、多言語の token 効率を重視しています。

初心者向けに言えば、良いトークナイザほど同じ文章を無駄に細かく分けず、同じコンテキスト長により多くの有用な情報を入れられます。

位置エンコーディング：RoPE が主流に

言語には順序があります。同じ単語でも、並びが変われば意味も変わります。位置エンコーディングは、その順序情報をモデルに入れる仕組みです。

初期の Transformer は絶対位置エンコーディングを使い、位置 1、位置 2、位置 3 にそれぞれ専用のベクトルを持っていました。その後、多くの大規模モデルは RoPE、つまり Rotary Positional Embedding を使うようになりました。RoPE は位置情報を注意計算の中に組み込み、長いコンテキストへの拡張に向いています。

Llama 系列から多くのオープンモデルまで、RoPE は事実上の標準の一つになっています。さらに長いコンテキストを扱うために、RoPE の base frequency を調整したり、RoPE scaling を使ったり、スライディングウィンドウやチャンク化された注意機構と組み合わせることもあります。

簡単に言えば、RoPE はモデルを急に賢くする魔法ではありません。長い文章の中で相対的な位置関係を扱いやすくするための重要な部品です。

注意機構：MHA から GQA、スライディングウィンドウ、MLA へ

注意機構は Transformer の中核です。各 token が、現在のタスクに必要な文脈中の token に注目できるようにします。

古典的なのは MHA、つまり Multi-Head Attention です。複数の attention head があり、それぞれ異なる注目の仕方を学びます。問題は、モデルが大きくなり、コンテキストが長くなるほど KV cache の消費が増え、推論コストが高くなることです。

そのため 2023 年以降、注意機構の主な最適化方向は推論コストの削減になりました。

GQA、つまり Grouped-Query Attention は重要な一歩です。複数の query head が少数の key/value head を共有することで、KV cache の負担を減らします。Meta は Llama 3 で GQA を採用し、推論効率を高めたと説明しています。

Mistral 7B は別の方向を示しました。スライディングウィンドウ注意です。すべての token が全履歴を見るのではなく、主に近くのウィンドウを見ることで、長い系列の計算負荷を減らします。多くのタスクでは、局所的な文脈だけでも十分に有用です。

DeepSeek-V2/V3 はさらに踏み込んで、MLA、つまり Multi-head Latent Attention を採用しました。重点は KV cache を圧縮し、推論時のメモリ負担を下げることです。DeepSeek-V3 技術報告では、MLA と DeepSeekMoE が中核アーキテクチャとして示されています。

まとめると、次のように理解できます。

MHA：古典的で強力だがコストが高い。
GQA：表現力を大きく落とさず、KV cache コストを下げる。
スライディングウィンドウ注意：長文での全域注意の計算負荷を減らす。
MLA：注意キャッシュをさらに圧縮し、高効率推論を狙う。

MoE：「パラメータは多いが、毎回使うのは一部」

MoE は Mixture of Experts の略です。

通常の Dense モデルは、各 token に対してすべてのパラメータを活性化します。MoE はモデル内に多くの専門家を置き、各 token を少数の専門家だけにルーティングします。これにより、総パラメータ数を大きくしながら、1 回の推論で活性化されるパラメータ数を抑えられます。

2023 年末の Mixtral 8x7B は、MoE が再び広く注目される重要なきっかけでした。Mistral の論文では、Mixtral 8x7B は基本的に Mistral 7B のアーキテクチャを踏襲しつつ、各層のフィードフォワードブロックを 8 個の専門家に置き換え、疎なルーティングで一部の専門家だけを計算に使うと説明されています。

その後、DeepSeek-V3 は MoE を中核路線にしました。総パラメータ数は非常に大きい一方、各 token では一部のパラメータだけを活性化し、DeepSeekMoE によって訓練と推論のコストを抑えます。Qwen3 なども Dense と MoE の両方の系統を用意しており、MoE が研究上の技巧から主流のエンジニアリング選択肢になったことが分かります。

初心者向けに言えば、Dense モデルはどんな問題でも全社員が会議に出る会社のようなものです。MoE は専門チームに分かれ、問題ごとに関連するチームだけを呼ぶ会社に近いです。

MoE には難しさもあります。

ルーターが token を適切な専門家に送る必要がある。
一部の専門家に負荷が集中しないようにする必要がある。
分散訓練と推論がより複雑になる。
総パラメータが大きいことは、毎回の推論が安いことを意味しない。

正規化：RMSNorm が一般的に

正規化は、ニューラルネットワークの中間値の分布を安定させるための仕組みです。大規模モデルの訓練では、値の揺れが大きいと収束が難しくなり、不安定にもなります。

初期の Transformer では LayerNorm がよく使われました。その後、多くの Llama 系モデルは RMSNorm を採用しました。RMSNorm は LayerNorm より簡潔で、平均を計算せず、二乗平均平方根のスケールに注目します。計算が軽く、実用上は十分安定です。

式を覚える必要はありません。RMSNorm は軽量な安定化装置だと理解すれば十分です。単独でモデル能力を決めるものではありませんが、訓練の安定性、速度、実装に影響します。

活性化関数：ReLU/GELU から SwiGLU へ

活性化関数は、ニューラルネットワークに非線形性を与えます。活性化関数がなければ、多層ネットワークは線形変換に近づいてしまいます。

以前の Transformer では GELU がよく使われていました。Llama、Mistral、Qwen、DeepSeek などの現代的な大規模モデルでは、SwiGLU や類似の GLU 変種がより一般的です。SwiGLU は通常フィードフォワードネットワーク内にあり、ゲート機構で情報の流れを制御します。

ざっくり言うと、普通の活性化関数は固定スイッチに近く、SwiGLU は学習可能なバルブに近いです。情報を通すかどうかだけでなく、どの情報を強めるべきかも学習できます。

SwiGLU はフィードフォワード層を少し複雑にしますが、大規模モデルでは高性能アーキテクチャの一般的な部品になっています。

2023-2026 年の全体傾向

時系列で見ると、次のように整理できます。

2023：Llama、Mistral 7B、Mixtral などのオープンモデルによって、RoPE、RMSNorm、SwiGLU、GQA、スライディングウィンドウ、MoE の組み合わせが普及した。
2024：Llama 3、Qwen2.5、DeepSeek-V2/V3 などが語彙を拡大し、長文コンテキストと推論効率を改善し、MoE と高効率注意を重要テーマにした。
2025：DeepSeek-V3/R1 によって、MLA、DeepSeekMoE、FP8、MTP などの訓練・推論効率設計が注目され、アーキテクチャ最適化とシステム工学の結びつきが強くなった。
2026：傾向は引き続き効率化とエンジニアリング成熟。Dense モデルは安定した汎用性を追求し、MoE は容量拡大を担い、高効率注意が長文コストを下げる。

重要なのは、Transformer を置き換える単一部品が登場したことではありません。パラメータを増やすだけでは足りず、アーキテクチャ、データ、訓練システム、推論サービスを一緒に最適化する必要がある、という理解が広がったことです。

初心者はどう学ぶべきか

ゼロから学ぶなら、最初からすべての論文を読む必要はありません。おすすめの順序は次の通りです。

Transformer の基本構造を理解する：token、embedding、attention、FFN。
RoPE、RMSNorm、SwiGLU がなぜ一般的になったかを理解する。
GQA と KV cache を見て、推論がなぜメモリを多く使うかを理解する。
MoE を学び、「総パラメータ」と「活性化パラメータ」の違いを押さえる。
最後に DeepSeek-V3、Mixtral、Llama 3 などのモデル報告を読み、部品を実際のモデルの中で理解する。

これらの用語を孤立した知識として覚える必要はありません。ほとんどは同じ問いに答えています。つまり、どうすればモデルを強くしつつ、訓練可能で、デプロイ可能で、高速に動かせるか、という問いです。

まとめ

2023-2026 年の大規模モデルアーキテクチャの進化は、Transformer のエンジニアリング成熟期と見ることができます。トークナイザは token の無駄を減らし、RoPE は位置をよりよく表現し、GQA、スライディングウィンドウ、MLA は注意コストを下げ、MoE は容量を広げながら活性化計算を抑え、RMSNorm と SwiGLU は訓練と表現をより安定かつ効率的にします。

初心者にとって大切なのは、用語を暗記することではありません。現代の大規模モデルの変更は、ほとんどがコスト、効率、コンテキスト長、スケーラビリティのトレードオフをめぐるものだと理解することです。

参考リンク：

Ubuntu 26.04 LTSでAndroidアプリを動かす：Waydroidの導入と注意点

Sat, 16 May 2026 17:34:59 +0800

Ubuntu 26.04 LTSでAndroidアプリを動かすなら、現実的な選択肢は今でもWaydroidです。

Waydroidは従来型のAndroidエミュレーターではありません。LineageOSベースのAndroid環境をLinuxコンテナ内で動かす仕組みです。軽く、デスクトップ統合もしやすい一方で、Wayland、カーネル機能、GPUドライバー、各アプリの相性に強く左右されます。

軽いAndroidツールをたまに使う、APKをテストする、F-Droid系アプリを動かす、といった用途なら試す価値があります。重いゲーム、銀行アプリ、Googleサービス依存の強いアプリを常用したい場合は、期待値を下げた方が安全です。

まず適性を確認する

Ubuntu 26.04 LTSは2026年4月23日にリリースされました。公式のデスクトップ要件は2GHzデュアルコアCPU、6GB RAM、25GBストレージ以上です。Waydroidは追加でディスク、メモリ、グラフィック資源を使うため、実用上は次の程度を見ておくと安心です。

8GB以上のRAM
10GB以上の空き容量
正常に動作するWaylandセッション
比較的新しいIntel、AMD、NVIDIAドライバー
一部アプリの互換性問題を許容できること

Waydroid公式ドキュメントでも、Ubuntu 22.04以降ではWayland Sessionが必要とされています。Ubuntu 26.04 LTSはWayland寄りのため、この点では旧環境より扱いやすいです。

Waydroidをインストールする

まず基本パッケージを入れます。

`1`	`sudo apt install curl ca-certificates -y`

Waydroid公式リポジトリを追加します。

`1`	`curl -s https://repo.waydro.id \| sudo bash`

Waydroidをインストールします。

`1`	`sudo apt install waydroid -y`

インストール後はアプリメニューから起動しても、端末から起動しても構いません。

Android環境を初期化する

初回起動時にはAndroidシステムイメージの初期化が必要です。通常はデフォルトのイメージで十分です。

GUIが出ない場合は、先にコンテナを起動します。

`1`	`sudo waydroid container start`

ユーザーセッションを開始します。

`1`	`waydroid session start`

AndroidのフルUIを開きます。

`1`	`waydroid show-full-ui`

Androidタブレットに近い画面が表示されます。インストールしたアプリはWaydroid内から起動でき、Ubuntuのアプリメニューに現れる場合もあります。

APKをインストールする

APKファイルがある場合は直接インストールできます。

`1`	`waydroid app install app.apk`

インストール済みアプリを確認します。

`1`	`waydroid app list`

パッケージ名でアプリを起動します。

`1`	`waydroid app launch com.example.app`

F-Droid、オープンソースアプリ、テスト版、自作APKに向いています。出所不明のAPK、特にアカウント、決済、連絡先、SMS権限を要求するアプリは避けるべきです。

マルチウィンドウ

Waydroidは標準ではAndroid全体を1つのウィンドウとして扱います。アプリごとにデスクトップウィンドウとして表示したい場合は、マルチウィンドウを有効にします。

`1`	`waydroid prop set persist.waydroid.multi_windows true`

セッションを再起動します。

1
2

waydroid session stop
waydroid session start

ただし表示品質はアプリ、デスクトップ環境、GPUドライバーに依存します。

Google Playは必要か

WaydroidはGoogle認証済み端末ではありません。

Google Play、Google Play Services、Googleフレームワーク依存アプリを使う方法はありますが、安定した前提にはしない方がよいです。

Googleサービスには端末認証やアカウントリスク判定があります。
SafetyNet、Play Integrity、root、仮想環境、端末フィンガープリントを確認するアプリがあります。
銀行、決済、ゲーム、動画配信アプリは失敗しやすいです。

普通のツールなら、F-Droid、オープンソースAPK、Googleサービス不要版を優先した方がトラブルは少なくなります。

よくある問題

起動後に黒画面になる場合は、X11ではなくWaylandを使っているか確認します。

`1`	`echo $XDG_SESSION_TYPE`

通常は次のように表示されます。

wayland

コンテナが起動していない場合：

`1`	`sudo waydroid container start`

セッションが固まった場合：

1
2

waydroid session stop
waydroid session start

ログ確認：

`1`	`waydroid log`

NVIDIA環境ではグラフィックスタックやドライバー相性の問題が出やすいです。Ubuntu 26.04 LTSのWayland/NVIDIA対応は以前より成熟していますが、Waydroidは通常のネイティブアプリではないため、描画やウィンドウの問題は起こり得ます。

エミュレーターやVMとの違い

Waydroidは完全な仮想マシンではなく「コンテナ内のAndroid」に近いものです。

方式	向いている用途	主な問題
Waydroid	軽量アプリ、APKテスト、Linuxデスクトップ統合	Googleサービスと一部アプリの互換性
Android Studio Emulator	開発、デバイスシミュレーション	リソース消費が大きい
仮想マシン	隔離テスト、実験環境	グラフィックと性能が弱くなりがち

参考資料

GPT-5.5 Prompt 移行ガイド：古いプロンプトはまず削ってから直す

Fri, 15 May 2026 01:25:27 +0800

OpenAI は API ドキュメントで GPT-5.5 prompting guide を更新しました。このガイドで最も価値があるのは、さらに長いプロンプトテンプレートを示していることではありません。GPT-5.5 へ移行するとき、多くの古い prompt はむしろ短くすべきだ、と示している点です。

公式ドキュメント：https://developers.openai.com/api/docs/guides/prompt-guidance

一言でいうと、GPT-5.5 の prompting の方向性は次の通りです。プロセスを減らし、結果を書く。ルールを積み上げるより、受け入れ条件を定義する。always や must を乱用せず、いつ止めるか、いつ検証するか、いつ証拠を補うかを書く。

古い prompt をなぜ書き直す必要があるのか

多くの本番システムの prompt は、層を重ねるように作られています。モデルが不安定ならルールを 1 つ足す。ツール呼び出しで失敗したら禁止事項を足す。出力が長すぎたらフォーマット指定を足す。時間が経つと、system prompt は重い運用マニュアルになります。

この書き方は古いモデルでは役に立つこともありました。モデルが逸れないように、より細かい手順制約が必要だったからです。しかし GPT-5.5 では、OpenAI の推奨は明確です。古い prompt stack をそのまま持ち込まないことです。

プロセスを指定しすぎると、いくつかの副作用があります。

ノイズが増え、モデルが大量の古いルールから本当に重要な制約を探す必要がある。
探索空間が狭くなり、モデルがより効率的な解法を選びにくくなる。
出力が機械的になり、問題解決というよりスクリプト実行のように見える。
古いルール同士が衝突し、ツール呼び出しも最終回答も悪くなる。

GPT-5.5 には、各手順を固定するより、目標状態、制約、利用可能な証拠、最終出力を説明する prompt のほうが向いています。

outcome-first：まず完了条件を定義する

公式ドキュメントは、GPT-5.5 には outcome-first prompt が向いていると繰り返し強調しています。

つまり、prompt ではまず次を明確にすべきです。

目標とする結果は何か。
何をもって成功とするか。
どの制約を破ってはいけないか。
現在利用できるコンテキストは何か。
最終回答にどのフィールドやセクションが必要か。
証拠が不足しているときにどうするか。

あまり推奨されない書き方：

まず A を確認し、次に B を確認し、その後すべてのフィールドを比較し、すべての例外を考え、どのツールを呼ぶか決め、ツールを呼び、最後に完全な過程を説明する。

GPT-5.5 により向いた書き方：

ユーザーの問題を解決する。成功条件：
- 利用可能なポリシーとアカウントデータに基づいて判断する
- 操作が許可される場合は、返信前に操作を完了する
- 最終出力には completed_actions、customer_message、blockers を含める
- 重要な証拠が不足している場合は、最小限必要なフィールドだけ質問する

これは prompt を曖昧にすることではありません。制御点を「手順の順番」から「結果と境界」へ移すことです。モデルは検索、推論、ツール呼び出しの経路を自分で選べますが、成功条件には責任を持つ必要があります。

絶対ルールを減らし、判断ルールを書く

古い prompt では ALWAYS、NEVER、must、only が大量に出てきがちです。これらの言葉は使ってはいけないわけではありません。ただし、安全ルール、必須フィールド、禁止アクションのように、本当に破れない制約にだけ残すべきです。

「いつ検索するか」「いつユーザーに聞くか」「いつ続けるか」「いつ止めるか」のような判断には、GPT-5.5 では decision rule のほうが向いています。

たとえば、こう書くだけでは不十分です。

`1`	`常に最初に 3 回検索する。`

こう書くほうがよいです。

まず中核問題をカバーする検索を 1 回行う。最初の数件の結果で重要事実を支えられるなら、検索を止めて回答する。証拠が矛盾している、不足している、または結論を支えられない場合だけ、検索を続ける。

この書き方はモデルに判断余地を与え、同時に停止条件も与えます。Web 検索、retrieval、ファイル検索、データベース問い合わせを使うプロダクトでは重要です。ツール呼び出しが 1 回増えるたびに、遅延とコストが増えるからです。

retrieval budget を設定する

GPT-5.5 prompt に単独で追加する価値があるルールの 1 つが retrieval budget です。

これは金額の予算ではありません。検索をいつ止めるかのルールです。証拠がいつ十分なのか、いつ探し続けるべきか、いつ証拠不足を認めるべきかをモデルに伝えます。

実用的な書き方：

通常の Q&A では、短く識別しやすいキーワードでまず広めに 1 回検索する。最初の数件の結果が中核リクエストを支えられるなら、その結果に基づいて回答し、検索を続けない。結果が矛盾する、重要事実が欠けている、または結論を支えられない場合のみ追加検索する。

このルールは、よくある 2 つの問題を減らします。

検索不足で、証拠のない回答を出す。
検索しすぎて、ツールループで時間を浪費する。

さらに重要なのは、証拠が見つからないことを、事実上の「いいえ」として扱うべきではないという点です。正しい挙動は、証拠不足を明示すること、またはより小さい問いに分けて確認することかもしれません。

reasoning effort を最初から上げない

GPT-5.5 は推論効率が高いため、OpenAI は low と medium を再評価することを勧めています。品質が足りないと感じたときに、すぐ reasoning effort を上げるべきではありません。

より安定した順序は次の通りです。

まず prompt が目標、出力形式、停止条件を明確にしているか確認する。
テスト、引用、レビュー、レンダリング確認などの検証ループを追加する。
ツール呼び出しに持続性ルールと完了基準を追加する。
それでも足りない場合に reasoning effort を上げる。

言い換えると、reasoning.effort は最後の調整つまみに近いものです。明確な prompt 設計の代わりにすべきではありません。

短い分類、フィールド抽出、サポートチケット振り分け、形式変換なら、低い推論コストから始められます。長文書の統合、複数ソースの衝突判断、戦略作成、複雑な調査では、medium 以上を検討します。

text.verbosity は出力を制御するが、思考を制御するわけではない

GPT-5.5 は出力形式をかなり制御できます。公式ドキュメントは、prompt 内の出力要件と合わせて text.verbosity を使うことを勧めています。

デフォルトの text.verbosity は medium です。より短く、よりすっきりした返信が必要なプロダクトでは low を使えます。ただし、すべてを短くすべきという意味ではありません。

典型的な使い方：

ユーザー向けの状態更新と最終要約は短くする。
コード、設定、構造化結果では、引き続き可読性を求める。
「短くする」ために、フィールドの完全性、引用、必要な caveat を犠牲にしない。

これはコード系プロダクトで特に有用です。チャット返信は短くしつつ、生成コードには読みやすい変数名、明確な構造、必要なコメントを求められます。

preamble と phase：長いタスクを見えるようにする

GPT-5.5 は複雑なタスクで、可視テキストを出す前に推論、計画、ツール呼び出し準備を行うことがあります。ストリーミングプロダクトでは、ユーザーは最初の token までの待ち時間を感じます。

公式の推奨は、多段階、ツール密集、長時間実行のタスクでは、モデルに短い preamble を先に出させることです。完全な計画を説明する必要はありません。「まず何をするか」だけを伝えれば十分です。

例：

`1`	`まず関連ファイルと既存設定を確認し、その後で変更案を出します。`

Responses API の長いタスクやツール密集ワークフローでは、assistant item の phase にも注意が必要です。アプリが previous_response_id を使う場合、API は前の assistant 状態を自動で保持します。アプリが assistant 出力を手動で再生する場合、元の phase 値を保持する必要があります。

一般的な約束：

phase: "commentary"：中間状態の更新。
phase: "final_answer"：最終回答。
user message には phase を付けない。

これは低レベル実装の細部に見えますが、ツール呼び出し、状態更新、最終回答を持つプロダクトでは重要です。手動再生時に phase を失うと、モデルが途中経過と最終結論を混同しやすくなります。

モデルに自分の作業を検証させる

GPT-5.5 guide には非常に実用的な点があります。検証可能なタスクでは、モデルに検証ツールと検証ルールを与えることです。

コード Agent には、明確に次を要求できます。

変更後に関連する単体テストを実行する。
必要なら type check や lint を実行する。
影響するパッケージが大きい場合は build を実行する。
全量検証が高コストなら、少なくとも最小の smoke test を行う。
検証できない場合は、理由と次善の確認方法を説明する。

視覚やページ成果物では、まずレンダリングし、レイアウト、切り抜き、余白、欠落内容、視覚的一貫性を確認するよう求められます。

エンジニアリング計画では、要件との対応、関連ファイル/API/システム、状態遷移、検証コマンド、失敗時の挙動、プライバシーとセキュリティ、実装に影響する未決事項を含めるよう求められます。

この種のルールは「もっと注意して」よりずっと効果的です。「注意」を実行可能なチェックに変えるからです。

GPT-5.5 に向いた prompt 骨格

OpenAI ドキュメントの構造は、簡略化すると次のようになります。

Role:
あなたの役割と、作業する文脈。

# Personality
口調、協力スタイル、温度感や視点が必要かどうか。

# Goal
ユーザーに見える目標結果。

# Success criteria
最終回答前に満たすべき条件。

# Constraints
安全、ビジネス、証拠、権限、コスト、副作用の境界。

# Output
出力構造、長さ、口調、必須フィールド。

# Stop rules
いつ続けるか、再試行するか、降格するか、質問するか、停止するか。

この骨格のポイントは、すべての prompt が同じ見出しを持つべきということではありません。複雑なタスクの prompt は、モデルに目的地、境界、成果物を伝えるべきであり、すべての手順をハードコードすべきではないということです。

古い prompt を移行する実際の順序

GPT-4.1、GPT-4o、GPT-5.2、GPT-5.4 向けの古い prompt がある場合、一度に大きく変えるのはおすすめしません。

より安定した移行順序：

まずモデルだけ切り替え、現在の reasoning effort と出力パラメータを固定する。
既存 eval または実例を実行し、挙動の変化を見つける。
明らかに古い、重複する、衝突するプロセスルールを削除する。
「手順要求」を「成功基準」と「停止条件」に変える。
retrieval budget、引用ルール、証拠不足時の挙動を追加する。
ツールタスクに検証ループを追加する。
最後に reasoning.effort と text.verbosity を調整する。

eval がない場合でも、少なくとも代表的なタスクを用意します。簡単な Q&A、複雑な検索、ツール呼び出し、フォーマット出力、拒否/降格、長いタスクの完了です。1 つの demo case だけで prompt の良し悪しを判断しないことです。

古い prompt 移行チェックリスト

実際に移行するときは、まずこのチェックリストを通します。目的は単に prompt を短くすることではなく、無効な制約を削除し、重要な制約を検証可能な形にすることです。

チェック項目	よくある問題	推奨対応
重複ルール	同じ指示が複数箇所にあり、表現が一致しないこともある	1 つの明確なルールに統合し、最終版だけ残す
絶対語	`ALWAYS`、`NEVER`、`must`、`only` が everywhere	安全、コンプライアンス、権限、必須フィールドにだけ残す
停止条件なし	検索、分析、修正を続けるよう要求するが、いつ止めるかがない	証拠十分、検証成功、ターン数やコスト上限など stop rules を追加
検証コマンドなし	「正しくする」と書くだけで、テスト、lint、引用、確認方法がない	テスト、型チェック、build、引用、smoke test など具体化
プロセスが細かすぎる	すべての手順を固定し、モデルがよりよい経路を選べない	目標、成功基準、境界、出力要件に書き換える
古いモデル用補丁	古いモデルの弱点向け制限が残っている	まず削除し、eval で本当に必要か判断する
ツールルールが曖昧	「必要ならツールを使う」だけ	いつ呼ぶか、いつ止めるか、失敗時にどう降格するかを書く
出力形式が漂う	形式指定はあるが、フィールド完全性のルールがない	必須フィールド、任意フィールド、証拠不足時の出力を定義

1 つだけやるなら、「停止条件なし」と「検証コマンドなし」を優先します。この 2 つは、GPT-5.5 を無限ツールループにしたり、証拠なしで整った回答を出させたりしやすいからです。

GPT-5.5 prompt 例：旧 vs 新

以下は完全な system prompt ではなく、移行時によくある部分的な書き換えです。

例 1：検索 Q&A

旧：

`1`	`回答前に必ず 3 回以上検索する。関連するすべての結果を読む。完全な説明を出す。`

新：

まず中核問題をカバーする検索を 1 回行う。最初の数件の結果で重要事実を支えられるなら、検索を止めて回答する。結果が矛盾する、または重要事実が不足している場合は追加検索する。最終回答では根拠を説明し、証拠不足なら明確にそう述べる。

新しい書き方では、「検索回数」を「証拠が十分か」に変えています。モデルに続ける理由と止める理由の両方を与えます。

例 2：コード変更

旧：

`1`	`慎重にコードを修正する。既存ロジックを壊さない。完了後に変更点を教える。`

新：

ユーザー要求に対する最小限必要なコード変更を行う。成功基準：
- タスクに関係するファイルだけを変更する
- ユーザーが明示しない限り、既存の公開 API 互換性を保つ
- 変更後に関連単体テストを実行する。実行できない場合は理由と次善の検証方法を説明する
- 最終要約には変更点、検証結果、残るリスクを含める

新しい書き方は、ただ「慎重に」と言うのではなく、ファイル範囲、API 互換性、テストコマンド、リスク説明に慎重さを落とし込んでいます。

例 3：構造化出力

旧：

`1`	`JSON を出力する。余計な内容は出さない。フィールドは完全にする。`

新：

Markdown なしの厳密な JSON を出力する。必須フィールド：
- status: "ok" | "needs_more_info" | "blocked"
- answer: string
- evidence: string[]
- missing_info: string[]
証拠が不足している場合、status は "needs_more_info" にし、evidence を捏造しない。

新しい書き方は JSON を求めるだけでなく、証拠不足時の合法的な出力経路も定義しています。モデルは「完全なフィールド」と「証拠不足」の間で情報を作る必要がなくなります。

パラメータの組み合わせ

reasoning.effort と text.verbosity は別々に考えるべきではありません。前者はモデルがどれだけ推論するか、後者は出力の詳しさを左右します。よくある誤解は、品質が足りなければ reasoning.effort を上げ、出力が長ければ prompt を強く書くことです。より安定するのは、タスク種別で組み合わせることです。

場面	reasoning.effort	text.verbosity	説明
フィールド抽出、分類、短い形式変換	`none` または `low`	`low`	低遅延を重視し、schema を明確にする
サポート振り分け、簡単なツールルーティング	`low`	`low` または `medium`	ルールが明確なら高推論は不要
通常 Q&A、軽い検索要約	`low` または `medium`	`medium`	判断は必要だが、高推論をデフォルトにしない
複数文書統合、衝突判断	`medium`	`medium`	まず証拠ルールと引用を整え、その後 effort を検討
複雑なコード変更、長い Agent タスク	`medium` または `high`	ユーザー返信は `low`、コード出力は明確に	チャット更新は短く、コードと diff は可読に
戦略、計画、リスク分析	`medium` または `high`	`medium` または `high`	トレードオフ、リスク、仮定の説明が必要

多くのアプリでは、まず low または medium から始めます。prompt が成功基準、停止条件、検証ルールをすでに明確にしていて、それでも重要制約を落とす場合にだけ、reasoning.effort を上げます。

text.verbosity も低ければよいわけではありません。低 verbosity は状態更新、短いサポート返信、操作結果要約に向いています。一方、コード、設定、移行計画、監査説明では、短すぎる出力はレビューしづらくなります。

残すべきルール

GPT-5.5 へ移行することは、古い prompt をすべて削ることではありません。次のルールは通常残すべきであり、より明確に書くべきです。

安全ルール：実行できないアクション、生成できない内容、拒否または降格すべき場面。
コンプライアンスルール：業界ポリシー、地域制限、年齢制限、監査要件、承認要件。
プライバシールール：個人情報処理、機密データのマスキング、ログ制限、データ外部送信の制限。
出力フィールド：API 応答、JSON schema、表フィールド、フロントエンドコンポーネントが必要とする固定構造。
業務境界：返金ルール、アカウント権限、サービスレベル、契約範囲、有人サポートへのエスカレーション条件。
ツール権限境界：呼べるツール、確認が必要なツール、禁止ツール。
引用と証拠ルール：いつ出典が必要か、証拠が衝突したときにどうするか。

これらは古い荷物ではなく、プロダクト契約です。違いは、移行時には長いスローガンから実行可能な制約へ書き換えることです。

例：

`1`	`ユーザーのプライバシーを漏らさない。`

これは次のようにできます。

最終回答に完全な電話番号、身分証番号、access token、API key、内部ユーザー ID を出力しない。参照が必要な場合は、電話番号の下 4 桁だけを残すなど、マスク済み形式だけを表示する。

誤って削ってはいけないもの

prompt を削るときに一番危険なのは、不要な文章を削ることではなく、本物のシステム境界を一緒に削ることです。次の内容は、古く見えても軽く消すべきではありません。

プライバシーとデータ処理要件：特にログ、エクスポート、システム間転送、第三者ツール呼び出しに関するルール。
安全と権限制限：データ削除、送金、メール送信、権限変更、shell コマンド実行など高リスク操作の確認ルール。
引用形式：プロダクトが citation、脚注、出典一覧、監査チェーンに依存しているなら、場所を取るだけで削らない。
ツール呼び出し境界：読み取り専用ツール、書き込み可能ツール、ユーザー確認が必要なツール。
失敗時の挙動：API タイムアウト、データ欠落、検索失敗、権限不足時の降格方法。
業務上の厳格ルール：価格、返金、停止、リスク管理、コンプライアンス審査など、モデルが自由に判断すべきでないルール。

簡単な判断方法は、削っても出力スタイルが少し変わるだけなら削除候補にする。削ると越権、漏えい、誤操作、誤った約束、監査断絶につながるなら残し、より精密に書き換える、というものです。

まとめ

GPT-5.5 prompting guide の核心は、「より高度なプロンプトを書く」ことではありません。古い prompt にある、プロセスを指定しすぎた部分を削ることです。

GPT-5.5 に向いた prompt は次を満たすべきです。

手順ではなく目標を優先する。
「うまくやる」ではなく成功基準を明確にする。
無限検索や無限ツールループではなく停止条件を持つ。
証拠なしに答えたり検索し続けたりせず、証拠予算を持つ。
モデルの自覚だけでなく検証ルールを持つ。
最初から reasoning effort を上げず、パラメータ調整は後にする。

古い system prompt がすでに長いなら、GPT-5.5 への移行の第一歩は内容を追加することではなく、削ることかもしれません。本当に破れないルールを残し、プロセスの細部を結果、境界、チェック項目へ変えるほうが、さらに prompt を積み上げるより効果的です。

参考資料

OpenAI Prompt guidance：https://developers.openai.com/api/docs/guides/prompt-guidance
OpenAI Using GPT-5.5：https://developers.openai.com/api/docs/guides/latest-model

コンピューター用語を平易に言うと：TTS、STT、API、RAG、Agent は何を指すのか

Tue, 12 May 2026 22:15:34 +0800

コンピューター分野には、初めて聞くと難しそうに感じる用語がたくさんあります。しかし平易な言葉に置き換えると、日常のとても単純な動作を指していることが多いです。

たとえば AI が話せることは TTS、AI が人の話を聞けることは STT と呼ばれます。複雑なシステムに見えますが、分解すると「文字を読み上げる」と「音声を書き起こす」です。

参考リンク：https://www.zhihu.com/question/267978646/answer/2035405228460201515

この記事では、その視点からよくある用語をつなげて説明します。用語自体は残しつつ、意味を平易に言い換えます。

TTS と STT：文字と音声の相互変換

TTS は Text-to-Speech、つまりテキストを音声に変換することです。文字を入力すると、システムがそれを音として再生できる形にします。ナビの音声案内、電子書籍の読み上げ、AI カスタマーサポートの音声、音声アシスタントなどで使われます。

STT は Speech-to-Text、つまり音声をテキストに変換することです。スマートフォンに話しかけると、まず音声が文字に変換され、その後のプログラムに渡されます。音声入力、会議の文字起こし、自動字幕、スマートスピーカーには欠かせません。

多くの音声 AI 製品は、実際には次の流れです。

STT：あなたの発話を文字に変換する。
LLM：その文字から回答を生成する。
TTS：回答を音声として読み上げる。

自然に会話しているように見えても、内部では複数のモジュールが順番に処理しています。

OCR：画像から文字を写し取る

OCR は Optical Character Recognition、日本語では光学文字認識です。

平易に言えば、画像の中の文字を抜き出すことです。請求書を撮影する、本のページをスキャンする、身分証の名前や番号を読む、といった処理はすべて OCR です。

昔の OCR は「文字の形から推測する」ものに近かったですが、現在は深層学習を組み合わせ、複雑な背景、傾いた文字、手書き文字、低解像度画像にも強くなっています。それでも本質的な問いはシンプルです。画像の中にどんな文字があるのか、です。

NLP と LLM：機械に人間の言葉を扱わせる

NLP は Natural Language Processing、自然言語処理です。分かち書き、翻訳、要約、感情分析、質問応答、分類など、人間の言葉を扱います。

LLM は Large Language Model、大規模言語モデルです。テキストを理解し生成できるため、現在では多くの NLP タスクが LLM によって処理されています。

平易に言うと：

NLP：人が話したり書いたりする言葉を機械に処理させる。
LLM：多くの言語タスクを受け止められる大きなテキストモデル。

AI に記事を要約させる、メールを書かせる、タイトルを直させる、コードを説明させる、といったことはすべてこの方向に含まれます。

API と SDK：一方は窓口、一方は道具箱

API は Application Programming Interface です。

平易に言えば、相手が機能を呼び出すための入口を用意してくれている、ということです。天気 API は都市を渡すと天気を返し、決済 API は注文情報を渡すと決済結果を返します。

SDK は Software Development Kit です。

平易に言えば、API を呼び出しやすくするために、公式がよく使うコード、型、サンプル、ツールをまとめたものです。API がレストランの窓口なら、SDK は注文アプリのようなものです。窓口に直接伝えることもできますし、アプリを使えばより楽に注文できます。

CRUD：作成、読み取り、更新、削除

CRUD は Create、Read、Update、Delete の略です。

平易に言えば、追加、表示、編集、削除です。

多くの管理画面、業務システム、データベース操作は CRUD を中心に回っています。ユーザー管理、記事管理、注文管理、在庫管理は業務としては違って見えますが、内部ではフォームと CRUD の組み合わせであることがよくあります。

プログラマーが「また CRUD を書いた」と言うのは、それが本当に頻出するからです。

Cache：よく使うものを手元に置く

Cache はキャッシュです。

平易に言えば、よく使うものを手元に置いておき、次回は探し直したり計算し直したり問い合わせ直したりしない、ということです。

Web ページでは画像やスクリプトをキャッシュできます。遅いデータベースクエリでは人気の結果を Redis に置けます。モデル推論が高価な場合は、同じ質問への回答をキャッシュできます。

キャッシュの難しさは「コピーを置くこと」ではなく、「いつ更新するか」です。データが変わってもキャッシュが変わらなければ、古い情報が表示されます。多くのキャッシュ問題はそこから生まれます。

Queue：タスクを並べて順番に処理する

Queue はキューです。

平易に言えば、やることが多すぎるので、いったん並べて一つずつ処理することです。

たとえばユーザーが動画をアップロードしても、変換がすぐ終わるとは限りません。システムはタスクをキューに入れ、バックグラウンドサービスで後から処理できます。SMS 送信、メール送信、レポート生成、注文コールバック処理にもよく使われます。

キューが解決するのは、すべての重い処理を現在のリクエスト内で待たせないことです。ユーザーには先に応答し、時間のかかる処理は後ろで行います。

Index：データベースに目次を作る

Index はインデックスです。

データベースのインデックスは、本の目次のようなものです。目次がなければ最初のページから最後まで探す必要がありますが、目次があれば目的の場所に早くたどり着けます。

ただしインデックスは多ければよいわけではありません。検索は速くなりますが、書き込みや更新は遅くなることがあります。データが変わるとインデックスもメンテナンスする必要があるからです。

そのためデータベース最適化では「遅いクエリはまずインデックスを見る」と言われます。ただし実際に作るときは、検索条件、ソート項目、データ量、書き込み頻度も見る必要があります。

RPC、REST、Webhook：システム同士の話し方

RPC は Remote Procedure Call、リモート手続き呼び出しです。

平易に言えば、ローカル関数を呼ぶように、別のマシン上の関数を呼ぶことです。

REST は Web API でよく使われます。URL と HTTP メソッドでリソース操作を表します。たとえば GET /users はユーザー取得、POST /orders は注文作成です。

Webhook は逆方向の通知です。こちらが「終わった？」と何度も聞くのではなく、相手が処理完了後にこちらの URL へ通知します。

簡単に覚えるなら：

RPC：遠隔の関数を呼ぶ。
REST：HTTP でリソースを管理する。
Webhook：出来事が起きたら相手から知らせてもらう。

CDN と Load Balancing：近くに置く、負荷を分ける

CDN は Content Delivery Network、コンテンツ配信ネットワークです。

平易に言えば、静的リソースをユーザーに近いノードへ置くことです。画像、動画、CSS、JS にアクセスするとき、毎回オリジンサーバーまで行く必要がなくなります。

Load Balancing は負荷分散です。

平易に言えば、アクセスが多すぎるときに一台のサーバーだけに背負わせず、複数のマシンへリクエストを分けることです。

一方は「ユーザーに近づける」、もう一方は「一台を疲れさせない」ための仕組みです。大規模サイトでは通常どちらも使われます。

Docker、Container、Kubernetes：パッケージ化、実行、配置

Docker は代表的なコンテナツールで、Container はコンテナです。

平易に言えば、プログラムと依存環境をまとめてパッケージ化し、別のマシンでもできるだけ同じように動かす仕組みです。「自分の PC では動くのにサーバーでは動かない」問題を減らします。

Kubernetes はよく K8s と書かれる、コンテナオーケストレーションシステムです。

平易に言えば、コンテナがたくさんあるときに、どこで動かすか、落ちたらどう再起動するか、トラフィックをどう分けるか、バージョンをどう更新するかを管理します。

小さなサービスが一つだけなら Docker で十分なこともあります。多くのサービス、マシン、レプリカがある場合に K8s の価値が出ます。

CI/CD：自動ビルド、自動リリース

CI は Continuous Integration、継続的インテグレーションです。

平易に言えば、コードがコミットされると、システムが自動でコードを取得し、テストし、ビルドして、早めに問題を見つけることです。

CD は Continuous Delivery または Continuous Deployment を指します。

平易に言えば、ビルドが通った後、コードをより安定して自動的にテスト環境や本番環境へ届けることです。

これは「コードを書く」問題ではなく、「書いた後にどう少ないミスでリリースするか」の問題を解決します。

Serialization：オブジェクトを送れる形式に詰める

Serialization はシリアライズです。

平易に言えば、プログラム内のオブジェクトを保存・送信できる形式に変えることです。JSON、XML、Protobuf などが例です。

逆に Deserialization は、それらの形式をプログラムで使えるオブジェクトに戻すことです。

フロントエンドとバックエンドが JSON をやり取りするとき、サービス同士が Protobuf を使うとき、どちらもシリアライズが関わっています。

Token、Embedding、Vector DB：文字をモデルが扱える形にする

大規模モデルにおける Token は、テキストを分割した基本単位を指します。必ずしも漢字一文字や英単語一つではなく、モデル内部でテキストを処理する粒度のようなものです。

Embedding は埋め込みベクトルです。

平易に言えば、文字、画像、その他の内容を数字の列に変換し、モデルが類似度を比較できるようにすることです。

Vector DB はベクトルデータベースです。

平易に言えば、それらのベクトルを保存し、「意味が近い」内容を素早く探せるデータベースです。

たとえば「ルーターをリセットする方法」と聞くと、システムはベクトルデータベースから「工場出荷状態に戻す」「Wi-Fi パスワードを忘れた」「管理画面にログインできない」といった近い内容を探し、モデルに参考資料として渡します。

RAG：先に資料を調べてから答える

RAG は Retrieval-Augmented Generation、検索拡張生成です。

平易に言えば、モデルが答える前に、まず資料庫から関連内容を探し、その資料を持って回答することです。

これは大規模モデルが記憶だけで適当に答えてしまう問題を和らげます。企業文書、ナレッジベース、製品マニュアル、コード片をつなぐことで、モデルは学習時の記憶だけでなく、あなたが与えた最新資料を参照できます。

典型的な流れは：

ユーザーが質問する。
システムが質問を Embedding に変換する。
Vector DB から関連文書を探す。
文書片と質問を一緒に LLM へ渡す。
モデルが回答を生成する。

つまり RAG は難しそうに聞こえますが、本質は「先に資料を調べてから、言葉を組み立てる」です。

Agent：タスクを分解できる自動化フロー

AI 文脈での Agent は、しばしばエージェントや智能体と呼ばれます。

平易に言えば、単に一文を返すだけでなく、目標をステップに分け、ツールを呼び出し、結果を観察し、次の行動を決められるものです。

たとえば「このリポジトリのテストが失敗する理由を分析して」と頼むと、通常のチャットモデルは助言だけを返すかもしれません。Agent なら、ファイルを読み、テストを実行し、エラーを確認し、コードを修正し、再度テストを走らせる可能性があります。

もちろん Agent は必ず信頼できるという意味ではありません。実態は「モデル + ツール呼び出し + 状態ループ」です。使いやすさは、ツール権限、タスク境界、エラー処理、人間の確認設計に左右されます。

まとめ

多くのコンピューター用語が難しそうに見えるのは、英語の略語、アーキテクチャ図、製品文言に包まれているからです。分解すると、多くは素朴な動作を表しています。

TTS：文字を読み上げる。
STT：音声を書き起こす。
OCR：画像から文字を写す。
API：呼び出し口を公開する。
SDK：呼び出し用の道具をまとめる。
CRUD：作成、読み取り、更新、削除。
Cache：よく使う結果を保存する。
Queue：タスクを並べて後で処理する。
Index：データに目次を作る。
CDN：コンテンツをユーザーに近づける。
Load Balancing：リクエストを分散する。
Docker：実行環境をパッケージ化する。
CI/CD：テストとリリースを自動化する。
Embedding：内容を数値ベクトルにする。
RAG：先に資料を調べてから答える。
Agent：モデルにツールを使わせて段階的に作業させる。

用語は検索、コミュニケーション、ドキュメント参照に便利なので残すべきです。ただし理解するときに怖がる必要はありません。まず平易な言葉に訳し、それから技術的な細部へ戻ると、多くの概念はずっと分かりやすくなります。

参考

Zhihu 回答：https://www.zhihu.com/question/267978646/answer/2035405228460201515

Dirty Frag CVE-2026-43284：Linux ローカル権限昇格のリスクと緩和ガイド

Sat, 09 May 2026 07:25:55 +0800

Dirty Frag は、2026 年 5 月に公開され、実際の悪用の兆候も報告されている Linux kernel local privilege escalation 脆弱性群である。Microsoft は、攻撃者がすでに低権限の code execution を得た後に root へ昇格する post-compromise risk として説明している。Ubuntu も CVE-2026-43284 を High として扱っている。

この種の脆弱性で危険なのは、「remote から一発で侵入される」ことではない。「侵入後に権限を一気に広げられる」ことだ。攻撃者が弱い SSH account、WebShell、container escape、低権限 service account、phishing 後の remote access などで local execution を得ると、Dirty Frag を使って root を取得し、security tooling の停止、credential の読み取り、log 改ざん、lateral movement、persistence につなげる可能性がある。

Dirty Frag に関係する CVE

現在の公開情報では、Dirty Frag は主に二つの番号と関係している。

CVE-2026-43284：Linux kernel の xfrm/ESP path に関係する。Microsoft が言及する esp4、esp6 はこのリスク領域に含まれる。
CVE-2026-43500：Microsoft は rxrpc に関連すると説明しているが、2026 年 5 月 8 日時点では NVD にまだ正式公開されておらず、patch status も変化中である。

したがって、実際の確認では一つの CVE だけを見るべきではない。esp4、esp6、rxrpc、関連する xfrm/IPsec 機能が有効か、必要か、distribution kernel patch があるかをまとめて確認するのが安全だ。

技術的な概要

Microsoft と Ubuntu の説明によると、CVE-2026-43284 は Linux kernel の networking と memory-fragment handling、特に ESP/IPsec path における shared page fragments の扱いに関係する。

簡単に言えば、data page は splice などの仕組みで network buffer に attach されることがある。その後の kernel path が、それらの fragment を privately owned data とみなして in-place modification できるものとして扱うと、本来書き込むべきでない場所で in-place decrypt や modification が起きる可能性がある。攻撃者はこれを利用して page cache behavior を操作し、最終的に local privilege escalation を達成し得る。

これは以前公開された CopyFail（CVE-2026-31431）と背景が似ている。どちらも Linux page cache、kernel data path、local privilege escalation を中心にしている。Dirty Frag が危険なのは、追加の attack path を持ち、狭い race window に依存する従来型 LPE より安定しやすい可能性がある点だ。

優先的に見るべき環境

Dirty Frag は local privilege escalation なので、攻撃者がすでに対象 machine 上で code を実行できることが前提になる。優先的に確認すべき環境は次の通り。

SSH を公開している Linux server。
WebShell を書き込まれる可能性がある Web application server。
multi-user login host、bastion、developer machine、CI/CD runner。
container host、Kubernetes node、OpenShift node。
IPsec、VPN、xfrm、RxRPC 関連機能を使う system。
Ubuntu、RHEL、CentOS Stream、AlmaLinux、Fedora、openSUSE など主要 distribution を動かす server。

local multi-user、container、露出した application path がまったくない server ではリスクは低めだ。しかし「攻撃者が low-privileged shell を得る可能性」がある system では、高優先度の kernel vulnerability として扱うべきである。

まず patch を優先する

最も確実な修正は、distribution が提供する kernel security update をインストールし、新しい kernel で reboot することだ。

Ubuntu の CVE page では、CVE-2026-43284 は 2026 年 5 月 8 日に公開され、priority は High とされている。Microsoft も Linux Kernel Organization が CVE-2026-43284 の修正を公開しており、できるだけ早く patch を適用するよう促している。

まず system を確認する。

1
2

uname -a
cat /etc/os-release

distribution に合わせて kernel を更新する。

`1`	`sudo apt update && sudo apt full-upgrade`

または：

`1`	`sudo dnf update`

更新後は、新しい kernel で起動していることを必ず確認する。

`1`	`uname -r`

kernel package をインストールしただけで reboot していない場合、古い kernel が動き続けるため、脆弱性は残る可能性がある。

暫定緩和：関連 module を無効化する

patch がまだない、または production をすぐ reboot できない場合は、関連 module を一時的に無効化できるか評価する。Ubuntu の緩和策は、esp4、esp6、rxrpc の loading を block し、すでに loaded なら unload するというものだ。

modprobe block rule を作成する。

1
2
3

echo "install esp4 /bin/false" | sudo tee /etc/modprobe.d/dirty-frag.conf
echo "install esp6 /bin/false" | sudo tee -a /etc/modprobe.d/dirty-frag.conf
echo "install rxrpc /bin/false" | sudo tee -a /etc/modprobe.d/dirty-frag.conf

early boot で module が load されないよう initramfs を更新する。

`1`	`sudo update-initramfs -u -k all`

すでに loaded な module を unload する。

`1`	`sudo rmmod esp4 esp6 rxrpc 2>/dev/null`

module がまだ loaded か確認する。

`1`	`grep -qE '^(esp4\|esp6\|rxrpc) ' /proc/modules && echo "Affected modules are loaded" \|\| echo "Affected modules are NOT loaded"`

module が業務で使われている場合、unload に失敗することがある。その場合、block rule は reboot 後に有効になる可能性が高い。

無効化前に業務影響を確認する

上の緩和コマンドをそのまま貼り付けてはいけない。esp4、esp6、xfrm/IPsec 関連機能は、VPN、tunnel、encrypted networking、Kubernetes/container networking、企業 network configuration で使われている可能性がある。rxrpc も、その protocol に依存する workload に影響する。

production で実行する前に、少なくとも次を確認する。

1
2
3

lsmod | grep -E '^(esp4|esp6|rxrpc|xfrm)'
ip xfrm state
ip xfrm policy

IPsec VPN や関連 kernel networking に依存している場合、module 無効化で接続が切れる可能性がある。その場合は、module block に長く頼るより、kernel patch と maintenance reboot を早めに計画するべきだ。

侵害後確認を省かない

Microsoft は、緩和策だけでは成功した exploit による変更を元に戻せない可能性があると強調している。攻撃者がすでに root を得ていた場合、persistence、file modification、log tampering、session data access が残っている可能性がある。

少なくとも次を確認する。

journalctl -k --since "24 hours ago" | grep -Ei "dirty|frag|exploit|segfault|xfrm|rxrpc|esp"
last -a
lastlog
sudo find /tmp /var/tmp /dev/shm -type f -mtime -3 -ls
sudo find / -perm -4000 -type f -mtime -7 -ls 2>/dev/null

特に次を見る。

異常な su、sudo、SUID/SGID process launch。
最近追加された ELF executable。
Web directory 内の怪しい PHP、JSP、ASP file。
SSH authorized_keys の変更。
systemd service、cron、rc.local に追加された persistence。
container host 上の異常な privileged container や mount。

悪用が疑われる場合は、host を isolate し、evidence を保存し、credential を rotate してから cleanup する。module unload や cache clearing だけで安全になったと考えてはいけない。

drop_caches について

Microsoft は、一部の post-exploitation integrity verification で cache clearing を検討できると述べている。

`1`	`echo 3 \| sudo tee /proc/sys/vm/drop_caches`

これは vulnerability fix でも incident cleanup command でもない。cache clearing は追加の disk I/O と production performance への影響を起こし得る。影響を理解したうえで補助操作として使うべきだ。本当の修正は patch、reboot、integrity verification、persistence check である。

推奨対応順序

production environment では、次の順序が比較的安全だ。

Linux asset と kernel version を棚卸しする。
exposed SSH、Web workload、container host、multi-user system を優先する。
reboot できる system は早急に patch して新 kernel で起動する。
まだ patch または reboot できない system は、esp4、esp6、rxrpc の無効化を評価する。
su、SUID/SGID、異常 ELF、WebShell、container escape indicator の監視を強化する。
悪用が疑われる host では侵害後確認と credential rotation を行う。

まとめ

Dirty Frag は「remote one-click」脆弱性ではないが、侵害後のリスクを大きく高める。攻撃者が local で低権限 code execution を得るだけで、CVE-2026-43284 と関連する rxrpc attack surface を使って root へ昇格できる可能性がある。

管理者にとって重要なのは PoC 研究ではない。kernel が影響を受けるかを確認し、distribution security update をインストールして reboot すること。patch window 前には関連 module の無効化を評価すること。そして露出している system や疑わしい system では integrity と persistence を確認することだ。

参考リンク：

Btrfs Scrub 使用ガイド：データ検証、自動修復、定期メンテナンス

Sat, 09 May 2026 07:11:01 +0800

Btrfs scrub は、Btrfs の日常メンテナンスで最も重要で、同時に誤解されやすい機能の一つである。これは伝統的な意味の fsck ではない。filesystem data と metadata を読み、checksum、superblock、metadata block header、disk read error を検証し、信頼できる replica がある場合に修復を試みる online validation pass である。

NAS、home server、backup disk、multi-device array で Btrfs を使っているなら、scrub は定期メンテナンスに入れるべきだ。価値は「壊れてから修理する」ことではなく、disk がまだ読めて、array に good replica が残っている段階で silent corruption を早期に見つけることにある。

scrub は何を確認するのか

Btrfs の公式ドキュメントによると、scrub は filesystem data と metadata を走査し、主に次を確認する。

data block checksum error。
basic super block error。
basic metadata block header error。
disk read error。

RAID1 のような replicated block group profile を使う filesystem では、read-write mount 上の scrub が一部の損傷を自動修復できる。修復は魔法ではない。別の replica から検証済みの good data をコピーするだけである。

ここが重要だ。scrub の修復能力は「利用可能な good copy が存在すること」に依存する。single disk に data が一つしかない場合、scrub は checksum error を検出できても、元の内容を自力で復元することは通常できない。

よく使うコマンド

mount point に対して scrub を開始する。

`1`	`sudo btrfs scrub start /`

foreground で実行し、結果を手動で観察する。

`1`	`sudo btrfs scrub start -B /`

status を確認する。

`1`	`sudo btrfs scrub status /`

実行中の scrub を cancel する。

`1`	`sudo btrfs scrub cancel /`

中断された scrub を resume する。

`1`	`sudo btrfs scrub resume /`

Btrfs の mount path を指定すると、その filesystem 内の全 device を並列に scrub する。device を指定した場合は、その device だけを scrub する。ただし指定 device 上の replica が読めない、または検証に失敗した場合、Btrfs は他の device から good copy を読むことを試みる。

scrub は fsck ではない

最もよくある誤解がこれだ。scrub は btrfs check ではなく、伝統的な filesystem checker でもない。

scrub ができること：

checksum を使って data または metadata corruption を検出する。
他に信頼できる replica がある場合に自動修復する。
disk read error と一部の基本構造 error を検出する。

scrub ができないこと：

good replica がない data を再構築する。
offline filesystem check を置き換える。
複雑な tree structure corruption をすべて修復する。
application-level file content が必ず正しいと保証する。

filesystem structure が深刻に壊れている場合、専門家の助言のもとで btrfs check などの tool が必要になることがある。scrub を万能修復コマンドとして扱ってはいけない。

NOCOW file のリスク

Btrfs 公式ドキュメントは重要な注意点を挙げている。chattr +C で file に NOCOW attribute を設定すると、現在の実装では暗黙に NODATASUM が有効になる。つまり、その file data 自体には checksum がない。

scrub はこれらの file の metadata を検証し修復できるが、file data の内容は検証できない。multi-replica setup では特に問題になる。ある NOCOW file の一つの copy が壊れても、Btrfs にはどの replica が正しいか判断する data checksum がないため、壊れた内容を user space tool に返す可能性がある。

一部の application は performance のために +C を default で使う。systemd journal や一部の libvirt storage pool が代表例である。VM image、database、log directory では性能上の理由があるが、普通の COW file と同じように scrub が data content を守ってくれるとは期待できない。

read-only scrub でも書き込みが起こり得る

もう一つ直感に反する点がある。read-write mounted filesystem で read-only scrub を実行しても、いくつかの write が発生する可能性がある。

公式ドキュメントによると、これは block group を read-only として mark することと block group items を write back することの race を避けるための design limitation である。完全に write のない scrub を望むなら、read-only mounted filesystem 上で read-only scrub を実行する必要がある。read-write mount に read-only scrub option を付けるだけでは不十分だ。

一般ユーザーにとっての意味は次の通り。

日常の online scrub は read-write mount 上で実行できる。
forensic、failure analysis、非常に保守的な read-only check では、先に mount state を確認する。
read-only scrub を絶対に zero-write だと解釈しない。

中断と再開

新しい kernel では、scrub は suspend、hibernate、filesystem freezing、cgroup freezing、pending signals などで中断されることがある。中断後、実行中の scrub は cancel されるが、btrfs scrub resume で保存位置から再開できる。

scrub status は次の場所に記録される。

`1`	`/var/lib/btrfs/`

file name は通常次のようになる。

1
2

scrub.status.UUID
scrub.progress.UUID

status file は定期的に更新される。resume した scrub は、完全に最初からではなく、最後に保存された位置から続行する。

どれくらいの頻度で実行するか

公式の推奨は月 1 回である。実際には data の重要性と disk 状態に合わせて調整する。

よくある schedule：

Home NAS：月 1 回。
Backup disk：長時間接続した後、または月 1 回。
重要な multi-device array：月 1 回、必要ならより頻繁に。
New disk migration や disk 不良の疑い：migration 後すぐに実行。

scrub は idle filesystem でも device bandwidth の約 80% を使う可能性があるため、peak workload 中に実行しないほうがよい。HDD array では scrub 中に latency がかなり上がることがある。SSD でも read amplification と background pressure は増える。

scrub の bandwidth を制限する

以前は ionice で foreground I/O への影響を下げる方法がよく使われた。しかし公式ドキュメントは、すべての I/O scheduler で同じように support されるわけではないと注意している。CFQ はすでに一般的ではない。BFQ は関連 priority behavior を support するが、使う前に理解しておく必要がある。mq-deadline のような一般的 scheduler では、cgroup2 I/O controller や Btrfs 専用の limit のほうが適している。

systemd で read bandwidth を制限する例：

`1`	`sudo systemd-run -p "IOReadBandwidthMax=/dev/sdx 10M" btrfs scrub start -B /`

Linux 5.14 以降では、Btrfs 専用の sysfs interface で device ごとの scrub limit を設定できる。

`1`	`echo 100m \| sudo tee /sys/fs/btrfs/FSID/devinfo/DEVID/scrub_speed_max`

現在の limit を表示する。

`1`	`sudo btrfs scrub limit /`

この設定は永続化されず、filesystem を unmount すると失われる。実際の system に合わせて FSID と DEVID を置き換える必要がある。まず次を確認する。

1
2

sudo btrfs filesystem show /
ls /sys/fs/btrfs/

実用的なメンテナンス手順

堅実な Btrfs メンテナンス手順は次のようにできる。

sudo btrfs scrub start -B /
sudo btrfs scrub status /
sudo btrfs device stats /
dmesg -T | grep -Ei "btrfs|checksum|i/o error|read error"

scrub が corrected errors を報告した場合、Btrfs は good replica から data を修復したという意味だが、無視してよいわけではない。disk SMART、cable、power、controller、Btrfs device stats を続けて確認するべきだ。

scrub が uncorrectable errors を報告した場合、Btrfs は good copy を見つけられなかった。まだ読める data をできるだけ早く backup し、affected file または device を特定し、必要に応じて disk replacement や backup からの restore を行う。

まとめ

Btrfs scrub の役割は明確だ。online data verification と replica repair の tool であり、fsck ではなく、backup でもない。

checksum と redundant replica がある Btrfs filesystem で、silent corruption を定期的に見つけ、good copy から復元する用途に最も向いている。checksum のない NOCOW file data は保護できず、good replica がない場合に壊れた内容を復元することもできない。

重要な data を Btrfs に置くなら、月 1 回 scrub を実行し、SMART、device stats、backup、alerting と組み合わせるべきだ。信頼できる data safety は、checksum、redundancy、monitoring、backup が一緒に働くことで実現する。単一の command に依存するものではない。

参考リンク：

Btrfs 公式ドキュメント：Scrub

F2FS が HC620 SMR HDD を固まらせる？Linux SMR ディスクのトラブルシュート

Fri, 08 May 2026 22:34:39 +0800

HC620 のようなヘリウム封入 SMR HDD を F2FS と組み合わせたとき、システムが固まる、アプリが応答しない、iowait が長時間高い、といった症状が出る場合、原因は一つの設定ミスではないことが多い。デバイス特性とファイルシステムの方針が衝突している。

Western Digital Ultrastar DC HC620 は Host-managed SMR である。順次書き込み、zoned を意識したワークロード、底層制約を理解したソフトウェアスタックに向いている。一方 F2FS はフラッシュストレージ向けに設計されたログ構造ファイルシステムだ。多くのランダム書き込みを順次書き込みに寄せられるが、空き容量が少ない、GC が頻繁、metadata 更新が多いと、機械式 SMR HDD を長い内部整理周期へ引きずり込むことがある。

まずこの問題か確認する

最初に次を確認する。

1
2
3

iostat -x 1
iotop -oPa
dmesg -T | grep -Ei "f2fs|blk|zoned|reset|timeout|I/O error"

ディスクの %util が長時間 100% 近く、await が高く、多数のプロセスが D 状態に止まるなら、ボトルネックはブロックデバイス I/O と見てよい。

次に、HDD が zoned device として見えているか確認する。

1
2

lsblk -o NAME,MODEL,SIZE,ROTA,ZONED,SCHED,MOUNTPOINTS
cat /sys/block/sdX/queue/zoned

Host-managed SMR であれば、通常のファイルシステムや通常のランダム書き込み負荷では性能が大きく落ちる可能性がある。一般的な drive-managed SMR のように、複雑さを HDD firmware が完全に隠してくれるわけではなく、ホスト側ソフトウェアが書き込み規則を理解する必要がある。

F2FS が停止を増幅しやすい理由

SMR の問題は、任意の場所を自由に上書きできない点にある。容量を増やすために隣接トラックを重ねるため、ランダム書き込みや頻繁な上書き、キャッシュ枯渇が起きると、追加のデータ移動と整理が必要になる。

F2FS はもともと NAND flash 向けだ。ログ構造書き込みを使い、segment cleaning と garbage collection で空間を回収する。この設計は SSD では自然だが、機械式 HDD、特に SMR HDD では、GC による読み書きの移動が大きな tail latency になる。

F2FS の background GC、foreground write、checkpoint、metadata 更新、HDD 自身の SMR cleanup が重なると、I/O キューが長時間埋まり続ける。ユーザーから見ると、ファイルコピー、ディレクトリ削除、ダウンロード、展開、データベース書き込みでシステム全体が固まったように見える。

まず保守的な mount option から調整する

すぐにファイルシステムを移行できない場合は、/etc/fstab の mount option から調整する。

`1`	`UUID=xxxx /data f2fs defaults,nodiscard,active_logs=2,gc_merge,flush_merge,lazytime 0 0`

各 option の意味は次の通り。

nodiscard：リアルタイム discard を無効にする。機械式 HDD は SSD のように頻繁な TRIM/discard を必要としないことが多い。
active_logs=2：F2FS は 2、4、6 個の active logs をサポートし、既定は通常 6。2 に下げると、同時ログによる seek 圧力を減らせる。
gc_merge：background GC thread に一部の foreground GC request を処理させ、プロセスが遅い GC を直接踏んだときの停止を軽減する。
flush_merge：cache flush request をまとめる。下位デバイスの flush が遅い場合に有効なことがある。
lazytime：一部のアクセス時刻更新による metadata 書き込みを減らす。

checkpoint=disable を通常の性能改善策として使うのは勧めない。checkpoint の負荷は減る可能性があるが、異常終了や停電時のリスクが高くなる。kernel documentation でも、checkpoint を無効にしている間も空き領域を確保するために GC が必要だと説明されている。代償を理解していないなら、長期運用の性能スイッチとして使うべきではない。

I/O scheduler を調整する

機械式 HDD と SMR HDD では、request merge と遅延制御が重要になりやすい。まず現在の scheduler を確認する。

`1`	`cat /sys/block/sdX/queue/scheduler`

mq-deadline への切り替えを試せる。

`1`	`echo mq-deadline \| sudo tee /sys/block/sdX/queue/scheduler`

デスクトップ用途なら bfq も試す価値がある。順次スループットだけで判断せず、停止が減るか、await が下がるか、操作感が安定するかを見る。

F2FS の background GC を制限する

F2FS の sysfs path は実際のデバイス名に依存する。まず確認する。

`1`	`ls /sys/fs/f2fs/`

対応する mount device に対して GC interval を調整する。

1
2

echo 60000 | sudo tee /sys/fs/f2fs/sdX/gc_min_sleep_time
echo 120000 | sudo tee /sys/fs/f2fs/sdX/gc_max_sleep_time

ここでの sdX は例であり、実際には sda1、dm-0 などになることがある。GC sleep time を増やすと background GC が I/O を奪う頻度は下がるが、空間回収は遅くなる。ディスクが満杯に近いほど foreground GC が再び発生しやすいため、十分な空き容量を残す必要がある。

長期的には別の選択がよい

重要データを保存しているなら、最も安定した方針はバックアップ後にファイルシステムを変えるか、より適した HDD に変えることだ。

大容量の機械式 HDD では、次を優先して検討する。

XFS：大きなファイル、バックアップ、メディアライブラリ、アーカイブ、順次書き込み負荷に向く。
EXT4：互換性が高く、挙動が安定し、トラブルシュート資料も多い。

Host-managed SMR の場合は、kernel、controller、filesystem、application stack が zoned block device の使い方を本当にサポートしているかも確認する。そうでなければ、普通のランダム書き込み HDD として扱ったときに、予測しにくい長時間停止が起きやすい。

実用的な勧め

この種の HDD は、cold data、アーカイブ、バックアップ、メディアファイル、順次書き込みに向いている。download cache、container image、VM disk、database、頻繁な展開、小ファイルのランダム書き込みには向かない。

どうしても F2FS を使い続けるなら、少なくとも次を行う。

リアルタイム discard を無効にする。
active_logs=2 で同時ログを減らす。
gc_merge と flush_merge を有効にする。
十分な空き容量を残し、満杯に近づけない。
download directory、database、VM image をこのディスクに置かない。
平均速度だけでなく iostat -x 1 を定期的に見る。

まとめると、HC620 + F2FS の停止は、SMR の書き込み制約、F2FS GC、機械式 HDD の tail latency が重なった結果である。短期対策は mount option、scheduler、background GC の調整。長期対策は XFS/EXT4 への移行、または SMR HDD を本来向いている順次書き込みアーカイブ用途に戻すことだ。

参考リンク：

DeepSeek V4のローカル私有化デプロイ：国産チップとコンシューマーGPUクラスターの選び方

Fri, 08 May 2026 09:39:35 +0800

DeepSeek V4の公開後、多くの企業が一つの問題に注目し始めた。外部APIを使わず、自社のデータセンター、プライベートクラウド、専用クラスターにモデルを配置できるのか、という問題だ。

この需要は非常に現実的だ。金融、医療、政府・企業、製造、法務、研究開発チームは、社内文書、コード、契約書、チケット、顧客データをそのままパブリッククラウドのモデルへ送れないことが多い。こうした場面でDeepSeek V4が魅力的なのは、モデル能力だけではなく、企業に「制御可能なLLMインフラ」に近い選択肢を与える点にある。

ただし、DeepSeek V4のローカルデプロイは、モデルをダウンロードしてGPUを数枚用意すれば動く、という話ではない。特にProのような超大規模MoEモデルでは、総パラメータ規模、アクティブパラメータ、コンテキスト長、KV cache、同時実行数、推論フレームワークがそのままハードウェアコストを左右する。企業が本当にやるべきことは、フルスペック版を盲目的に追うことではなく、まず業務に必要なデプロイ形態を確認することだ。

まずデプロイ目標を明確にする

企業がローカル私有化デプロイを行う目的は、主に三つある。

データを域外に出さない：社内文書、コード、顧客資料、ログ、ナレッジベースを企業環境の外へ出さない。
安定して制御できる：モデルサービス、権限、監査、ログ、アップグレードのペースを企業自身が管理する。
長期コストを下げる：高頻度に呼び出す場合、ローカル推論は外部APIを長期購入するより制御しやすい可能性がある。

少数の従業員がたまに質問するだけなら、ローカルデプロイは必ずしも割に合わない。私有化に本当に向いているのは、高頻度で、安定していて、データが敏感で、フローが明確な場面だ。例えば次のようなものがある。

社内ナレッジベースQ&A。
コードレビューと開発アシスタント。
カスタマーサポートチケットの要約。
契約書、カルテ、レポートなどの文書分析。
データベース問い合わせアシスタント。
Agentワークフロー自動化。

これらの共通点は、データが敏感で、呼び出しが安定しており、権限とログを通じて企業ガバナンスに組み込めることだ。

最初からフルスペックのProを追わない

DeepSeek V4の一般的なバージョンにはProとFlashがある。公開資料では、Proはより強い推論や複雑なAgentタスク向け、Flashはコストと応答速度を重視するものとされている。企業が選定するとき、すべての業務をProに載せる前提にすべきではない。

タスクの複雑度に応じて分けるとよい。

簡単なQ&A、要約、分類、タグ生成：Flashまたはより小さいモデルを優先する。
社内ナレッジベースの検索拡張：Flashで多くの場面をカバーできる。むしろRAG、権限、検索品質が重要だ。
コードAgent、複雑な推論、長文コンテキスト分析：その段階でProを評価する。
高価値・低頻度タスク：Proを使ってよいが、高い同時実行数が必要とは限らない。
一般的なオフィスアシスタント：最も高価な推論リソースを長時間占有する必要はない。

MoEモデルの利点は、各推論で一部のパラメータだけをアクティブにすることだ。しかし、それはハードウェア負荷が小さいことを意味しない。重みの保存、エキスパート並列、ネットワーク通信、コンテキストキャッシュ、同時実行スケジューリングは依然として重い。特に1M token級の長文コンテキストでは、単一の回答よりも、長いコンテキスト、多人数同時利用、継続セッションがリソースを消費しやすい。

国産チップ路線：企業向けプライベートクラウドに向く

企業がすでに国産計算資源プールを持っている場合、または信創、コンプライアンス、サプライチェーン要件がある場合は、Ascend、Cambriconなどの国産チップ路線を優先的に評価できる。

この路線の利点は次の通りだ。

国産化とサプライチェーン制御の要件に合いやすい。
企業データセンター、専用クラウド、政府・企業向けプロジェクトに入りやすい。
権限、監査、リソース分離、運用を統一しやすい。
長期的に安定したサービスに向いている。

ただし、国産チップ路線では三つの現実的な問題を見る必要がある。

第一に、フレームワーク適配だ。モデルが動くかどうかは、チップの計算力だけでは決まらない。推論フレームワーク、演算子、通信ライブラリ、量化形式、MoEエキスパート並列、長文コンテキスト最適化が成熟しているかも重要だ。

第二に、エンジニアリング経験だ。企業が必要とするのは「起動に成功した」だけではなく、安定したサービスだ。マルチテナント、レート制限、監視、障害復旧、段階的リリース、ログ監査、権限分離をすべて補う必要がある。

第三に、エコシステム差だ。同じモデルでも、NVIDIA、Ascend、Cambriconなどのプラットフォームでは、性能、精度、量化対応、デプロイツールが完全には一致しない。本番投入前には、名目上の計算力だけでなく、実際の負荷テストが必要だ。

したがって、国産チップは、予算が明確で、コンプライアンス要件が高く、プラットフォームエンジニアリングに投資できる企業に向いている。最も手軽な路線ではないが、長期ガバナンスには最も合う可能性がある。

コンシューマーGPUクラスター：試験導入と中小チームに向く

まず業務価値を検証したいなら、コンシューマーGPUクラスターの方が始めやすい。RTX 4090、RTX 5090、RTX 3090、RTX 3060 12GBなどのGPUは、コミュニティツール、量化モデル、ローカル推論フレームワークの情報が多く、試行錯誤のコストが低い。

コンシューマーGPU路線が向くのは次のような場面だ。

研究開発チームの社内試験導入。
中小企業のナレッジベースQ&A。
低同時実行のコードアシスタント。
オフライン文書処理。
SLA要求が高くない社内ツール。

ただし、制約も明確だ。

VRAMが小さく、完全な大規模モデルを直接載せにくい。
マルチGPU通信が弱く、複数マシン間通信はさらに面倒になる。
コンシューマー向けハードウェアは、長期フルロード時の安定性がサーバー方案に劣る。
ケース、電源、冷却、ドライバ、運用が隠れたコストになる。
最初から企業級の高可用性を約束する用途には向かない。

より現実的なのは、まずコンシューマーGPUでFlash、蒸留版、量化版、小規模モデルを動かし、業務フローを通すことだ。その後、呼び出し量、効果、データガバナンスを検証してから、サーバーGPUや国産計算基盤へ移行するかを決める。

想定されるデプロイ構成

比較的安定した企業向け私有化構成は、六つの層に分けられる。

モデル層：DeepSeek V4 Pro、V4 Flash、またはタスクに応じて選ぶ小さな蒸留モデル。
推論層：SGLang、vLLM、llama.cpp、ベンダーNPU推論スタック、または企業の自社サービス。
ゲートウェイ層：統一認証、レート制限、監査、モデルルーティング、呼び出しログ。
ナレッジ層：ベクトルDB、全文検索、文書解析、権限フィルタリング、RAG。
アプリケーション層：カスタマーサポート、コードアシスタント、文書分析、レポートQ&A、Agentワークフロー。
運用層：監視、アラート、コスト集計、段階的リリース、ロールバック、セキュリティ監査。

ここで最も過小評価されやすいのは、ゲートウェイ層とナレッジ層だ。多くのプロジェクトが失敗するのは、モデルがまったく使えないからではなく、権限、検索、ログ、コンテキスト管理、プロンプトテンプレート、業務フローが整っていないからだ。

企業内でLLMをデプロイするときは、モデルを孤立したチャットページではなく、基礎能力として扱うべきだ。本当の価値は、モデルがフローに入り、企業自身のデータとタスクを安定して処理できるようになったときに生まれる。

ハードウェア選定の考え方

ハードウェアは「動くか」だけでなく、「安定してサービス提供できるか」も見る必要がある。

段階ごとに選ぶとよい。

検証段階

目的は、その業務に取り組む価値があるかを証明することだ。

1-4枚のコンシューマーGPUを使う。
Flash、小モデル、蒸留モデル、量化モデルを優先する。
同時実行要求は低くし、タスク完了率を見る。
高可用性は約束しない。

この段階で大規模ハードウェアを早く買いすぎない。まず従業員が本当に使うか、業務が本当に時間を節約できるか、回答がフローに入るかを確認する。

試点段階

目的は、一つの部門または一つの業務ラインで安定して使うことだ。

4-16枚のGPU、または国産NPUノード一式を使う。
統一ゲートウェイ、ログ、権限制御を追加する。
RAG、文書解析、モデルルーティング、キャッシュを作る。
token、同時実行、遅延、失敗率を記録し始める。

この段階では運用が重要になる。モデル効果は一部にすぎず、安定性、コスト、データガバナンスも同じくらい重要だ。

本番段階

目的は企業級サービスに入ることだ。

サーバーGPU、国産計算クラスター、またはプライベートクラウド資源プールを使う。
複数レプリカ、レート制限、フェイルオーバー、容量計画を整える。
タスクごとにモデルをルーティングする。簡単なタスクは軽量モデル、複雑なタスクはProに送る。
企業IDシステム、監査システム、セキュリティポリシーと接続する。

本番段階では、すべてのリクエストを最強モデルに送るべきではない。適切なモデルルーティングは、ハードウェアを積み増すよりもコストを抑えやすい。

推論フレームワークの選び方

DeepSeek V4のようなモデルは、推論フレームワークへの要求が高い。特にMoE、長文コンテキスト、スパースアテンション、量化、マルチGPU並列が関わる場合、フレームワークの成熟度が速度と安定性に直結する。

一般的な選択肢は次のように理解できる。

SGLang：高性能推論、Agent、多ターンのツール呼び出し、複雑なサービス編成を重視するチームに向く。
vLLM：エコシステムが成熟しており、汎用LLMサービスに向く。ただし具体的な対応はバージョンとモデル適配の進捗を見る必要がある。
llama.cpp：小モデル、量化モデル、エッジデプロイに向く。フルスペックの超大規模MoEを直接載せる用途には向かない。
国産NPU推論スタック：信創や国産計算環境に向くが、演算子、量化、長文コンテキスト対応を重点的に検証する必要がある。

フレームワーク選びではbenchmarkだけを見ない。企業は自社の実データで試すべきだ。社内文書の長さ、同時実行数、平均出力長、RAG命中率、Agentのツール呼び出し回数、失敗時のリトライ回数を見る必要がある。

データ安全性はモデルの外側で作る

私有化デプロイは自動的に安全になるわけではない。モデルをローカルで動かすことは、「データが企業の外へ出るか」という問題の一部を解決するだけだ。

さらに次を補う必要がある。

アカウントと権限：部門ごとに自分のナレッジベースだけを参照できるようにする。
ログ監査：誰が何を聞き、どのモデルを呼び、どの文書にアクセスしたかを記録する。
データマスキング：顧客情報、身分証番号、電話番号、契約金額などの機微情報を処理する。
プロンプト安全性：ユーザーがプロンプトで権限を回避したり、システムプロンプトを漏らしたりしないようにする。
出力レビュー：重要な場面では人手レビューまたはルールレビューを入れる。
データライフサイクル：アップロード文書、ベクトルインデックス、キャッシュ、会話記録を削除できるようにする。

企業がローカルLLMを作るとき、アルゴリズムチームだけに任せてはいけない。セキュリティ、法務、運用、業務責任者も参加する必要がある。そうしないと、リリース後にリスクが一気に露出する。

コストはGPUだけではない

ローカルデプロイのコストは過小評価されがちだ。GPUやNPU以外にも、次のものを計算に入れる必要がある。

サーバー、ラック、電源、冷却、ネットワーク。
ストレージとバックアップ。
推論フレームワーク適配とエンジニアリング開発。
運用監視と障害対応。
モデルアップグレード、ロールバック、互換性テスト。
セキュリティ監査と権限システム。
業務側のプロンプト、RAG、ワークフロー構築。

呼び出し量が少ないなら、外部APIの方が安い可能性がある。呼び出し量が多く、データが敏感で、フローが安定している場合に、ローカルデプロイはコストを薄めやすい。

比較的合理的なのはハイブリッド構成だ。

高機密データはローカルモデルへ送る。
低機密の汎用タスクは外部APIを使ってもよい。
簡単なタスクは小モデルへ送る。
複雑なタスクはDeepSeek V4 Proへ送る。
高頻度タスクでは、キャッシュ、検索、モデルルーティングを優先して最適化する。

推奨される導入手順

企業は次の順序で進めるとよい。

まず高価値な場面を2-3個選び、全社展開しない。
コンシューマーGPUまたは小規模計算資源でPoCを行う。
まずFlash、蒸留モデル、量化モデルを動かし、RAGと権限をつなぐ。
複雑なタスクにProを導入して比較テストする。
実際の呼び出し量、遅延、失敗率、人手削減時間を記録する。
その後、国産チップクラスターまたはサーバーGPUを調達するか決める。
本番前にゲートウェイ、監査、監視、レート制限、ロールバックを補う。

この手順は、最初から大規模クラスターを買うより安定している。企業にとって最も怖いのは、モデルが弱いことではなく、多くの費用を使った後で、業務フローがモデル能力を受け止められないと分かることだ。

まとめ

DeepSeek V4は、企業のローカル私有化デプロイに大きな想像余地を与えた。しかし、それは単なる「ローカル版ChatGPT」ではない。本当の難点はエンジニアリングにある。ハードウェア、フレームワーク、モデルルーティング、権限、RAG、監査、監視、コスト制御をまとめて考える必要がある。

国産チップ路線は、コンプライアンス要求が高く、長期的にプライベートクラウドを構築する企業に向く。コンシューマーGPUクラスターは、試験導入や中小チームの迅速な検証に向く。Proは複雑な推論とAgentに向き、Flashや小モデルは大量の一般タスクに向く。

一文だけ覚えるなら、DeepSeek V4の私有化デプロイはハードウェア調達から始めるべきではない。業務シーン、データ境界、呼び出し規模から始めるべきだ。まずシーンを通し、その後で大モデルを使うか、どれくらいの規模にするか、どの計算基盤に載せるかを決める。

参考資料

RTX 3060 で動かしやすいローカル LLM モデルおすすめ

Fri, 08 May 2026 09:25:24 +0800

RTX 3060 で最もよく見かけるのは 12GB VRAM 版だ。最上位の AI GPU ではないが、ローカル LLM を動かすにはかなり実用的で、特に 7B、8B、9B、12B クラスのモデルに向いている。

すぐ選びたいなら、まず次の一文を覚えておくとよい。

RTX 3060 12GB では、8B 前後のモデルを Q4_K_M または Q5_K_M 量子化で選ぶ。安定重視なら Q4、品質を少し上げたいなら Q5 を試す。

最初から 32B や 70B を追う必要はない。低ビット量子化や CPU offload で動かせる場合もあるが、速度と体験は日常利用向きではないことが多い。

まず VRAM の上限を見る

RTX 3060 12GB でローカル LLM を動かすとき、本当の制約は VRAM だ。

モデル規模	推奨量子化	3060 12GB の体験
3B / 4B	Q4、Q5、Q8	とても軽く、速い
7B / 8B / 9B	Q4_K_M、Q5_K_M	最もおすすめ。品質と速度のバランスがよい
12B / 14B	Q4_K_M	試せるが、コンテキストを大きくしすぎない
30B 以上	Q2 / Q3 または一部 offload	試せるが、日常利用には非推奨
70B 以上	極低量子化または大量の CPU/RAM	実験に近い

ローカル LLM はモデルファイルだけが VRAM を使うわけではない。コンテキスト長、KV cache、バッチサイズ、推論フレームワーク、GPU ドライバもリソースを使う。

そのため、12GB VRAM があるからといって、12GB のモデルファイルをそのまま安全に読み込めるわけではない。システムとコンテキスト用に余裕を残すほうが安定する。

おすすめ1：Qwen3 8B

主に中国語を使うなら、Qwen3 8B は RTX 3060 で最初に試す価値が高い。

向いている用途：

中国語の質問応答。
要約とリライト。
日常的な知識アシスタント。
簡単なコード解説。
ローカル RAG。
軽量 Agent フロー。

おすすめ：

1
2
3

Qwen3 8B GGUF
Q4_K_M：最初のおすすめ
Q5_K_M：品質は上がるが、VRAM負荷も上がる

Qwen 系列は中国語に強く、日常の文章作成、資料整理、中国語指示の理解が比較的安定している。最初の中国語ローカルモデルに迷うなら、ここから始めるとよい。

おすすめ2：Llama 3.1 8B Instruct

Llama 3.1 8B Instruct は安定した汎用モデルで、英語能力とツールエコシステムが成熟している。

向いている用途：

英語の質問応答。
軽量なコード支援。
一般チャット。
文書要約。
プロンプトテスト。
推論ツールの比較。

おすすめ：

1
2
3

Llama 3.1 8B Instruct GGUF
Q4_K_M：速度とVRAMの安定性重視
Q5_K_M：回答品質重視

英語資料を主に扱う場合や、チュートリアルが多く互換性の高いモデルが欲しい場合、Llama 3.1 8B は今もよい基準モデルになる。

おすすめ3：Gemma 3 12B

Gemma 3 12B は RTX 3060 12GB の実用上限に近い選択肢だ。

8B モデルより VRAM を使うが、Q4 量子化なら 3060 12GB でも動かせる可能性がある。単一 GPU でもう少し大きいモデルを試したい人に向いている。

向いている用途：

より高品質な一般質問応答。
英語コンテンツ処理。
やや複雑な要約と分析。
8B モデルに物足りなさを感じたときの試行。

おすすめ：

1
2
3

Gemma 3 12B GGUF
Q4_K_M または公式 QAT Q4
コンテキストを大きくしすぎない

VRAM 不足になる場合は、まずコンテキスト長を下げるか、8B モデルに戻す。3060 にとって 12B は「試せる」選択肢であり、常に最初に選ぶモデルではない。

おすすめ4：DeepSeek R1 Distill Qwen 8B

ローカルで推論系モデルの雰囲気を試したいなら、DeepSeek R1 Distill Qwen 8B のような 8B 蒸留モデルが候補になる。

向いている用途：

簡単な推論問題。
段階的な分析。
推論モデルの出力スタイル学習。
低コストなローカル実験。

おすすめ：

1
2

DeepSeek R1 Distill Qwen 8B GGUF
Q4_K_M

この種のモデルは推論過程を長く出力することがあり、普通の指示モデルより速度やコンテキスト使用量が重く感じられる場合がある。日常チャットでは Qwen3 8B のほうが使いやすいこともあるが、推論実験には向いている。

おすすめ5：Phi / MiniCPM / 小型モデル

RTX 3060 が 8GB 版だったり、PC のメモリが少なかったりする場合は、3B、4B クラスのモデルから試すとよい。

向いている用途：

高速な質問応答。
簡単な要約。
ローカル小型ツールへの組み込み。
低遅延チャット。
古い PC でのテスト。

これらのモデルは 8B や 12B ほどの品質ではない場合もあるが、軽く、速く、導入しやすい。

量子化の選び方

ローカルモデルでは GGUF 形式がよく使われ、Q4、Q5、Q6、Q8 などの量子化がある。

量子化	特徴	向いている人
Q4_K_M	小さく速い。品質も十分	3060 の第一候補
Q5_K_M	品質が上がるが、使用量も増える	8B モデルで試す
Q6 / Q8	元品質に近いが大きい	小型モデルや VRAM に余裕があるとき
Q2 / Q3	VRAM を節約するが品質低下が大きい	大型モデルの実験

RTX 3060 12GB では、実用的には次の選び方になる。

1
2
3

8B モデル：Q4_K_M または Q5_K_M
12B モデル：Q4_K_M 優先
それ以上：日常主力には非推奨

どのツールで動かすか

初心者は Ollama から始めるとよい。インストールと実行が簡単だからだ。

よく使うコマンド例：

1
2

ollama run qwen3:8b
ollama run llama3.1:8b

GGUF ファイル、GPU layers、コンテキスト長を細かく制御したい場合は、llama.cpp や llama.cpp ベースの GUI ツールを使う。

主な選択肢：

Ollama：最も簡単。初心者向け。
LM Studio：GUI が使いやすく、モデルのダウンロードと切り替えが簡単。
llama.cpp：細かい制御ができ、性能調整向け。
text-generation-webui：機能が多く、バックエンド比較向け。

ローカルチャットと簡単な質問応答だけなら、Ollama か LM Studio で十分だ。

コンテキストを大きくしすぎない

多くのモデルは長いコンテキスト対応をうたっているが、RTX 3060 では最大値まで上げないほうがよい。

コンテキストが長いほど KV cache の使用量が増え、VRAM 負荷も高くなる。モデルが読み込めても、長いコンテキストでは生成速度が落ちることがある。

目安：

1
2
3

普通のチャット：4K から 8K
文書要約：8K から 16K
長文書 RAG：まず分割し、全文を一度に詰め込まない

3060 は「中程度のコンテキスト + 良いモデル + 良い検索」に向いており、数十万 token を一度に入れる用途には向かない。

用途別の選び方

主に中国語を書く場合：

1
2

優先：Qwen3 8B Q4_K_M
候補：DeepSeek R1 Distill Qwen 8B

主に英語を書く場合：

1
2

優先：Llama 3.1 8B Instruct Q4_K_M
候補：Gemma 3 12B Q4_K_M

速度重視の場合：

1
2
3

3B / 4B モデル
8B Q4_K_M
コンテキストは 4K から 8K

品質重視の場合：

1
2
3

8B Q5_K_M
12B Q4_K_M
速度低下は受け入れる

コード用途の場合：

1
2

8B コードモデルは解説や小さな修正に使える
複雑なエンジニアリング作業はクラウドの強いモデルを使う

ローカル 3060 モデルは、コード解説、関数補完、小さなスクリプト生成、オフライン支援に向いている。大規模リファクタリング、難しい bug、ファイル横断の Agent タスクでは、Claude Sonnet や GPT-5 レベルを期待しないほうがよい。

RTX 3060 ローカル LLM への現実的な期待

RTX 3060 12GB は、ローカル LLM を「おもちゃ」から「日常的に使える道具」に近づけるカードだ。ただし、自宅で最上位クラウドモデルを再現するものではない。

強み：

コストが低い。
8GB カードより VRAM に余裕がある。
8B モデルの体験がよい。
オフライン利用できる。
プライバシーに敏感な資料をローカル処理できる。

制約：

大型モデルは滑らかに動かしにくい。
長いコンテキストは VRAM を消費する。
推論速度は上位 GPU に劣る。
小型ローカルモデルの複雑推論は限界がある。
マルチモーダルや Agent ワークフローはさらに重い。

安定した使い方は、8B モデルを日常ローカル助手にし、12B モデルを品質確認用に試し、複雑な作業はクラウドモデルへ任せることだ。

まとめ

RTX 3060 12GB でおすすめのローカル LLM は次の通り。

中国語汎用：Qwen3 8B Q4_K_M
英語汎用：Llama 3.1 8B Instruct Q4_K_M
高品質の試行：Gemma 3 12B Q4_K_M
推論実験：DeepSeek R1 Distill Qwen 8B Q4_K_M
低 VRAM 高速体験：3B / 4B 小型モデル

量子化はまず Q4_K_M を選び、8B モデルなら Q5_K_M も試せる。ツールは Ollama または LM Studio から始めるのがよい。

3060 を大規模モデルサーバーとして扱わないほうがいい。ローカル知識助手、プライバシー文書処理、軽量コード支援、モデル実験用カードとして使うほうが、実際の能力に合っている。

参考リンク

Qwen3 8B GGUF：https://huggingface.co/Qwen/Qwen3-8B-GGUF
Llama 3.1 8B GGUF：https://huggingface.co/macandchiz/Llama-3.1-8B-Instruct-GGUF
Gemma 3 12B GGUF：https://huggingface.co/unsloth/gemma-3-12b-it-GGUF
llama.cpp：https://github.com/ggml-org/llama.cpp
Ollama：https://ollama.com

AIで点線・矢印・曲線を描く方法、キャンバスサイズを変更する方法

Fri, 08 May 2026 09:18:53 +0800

ここでの AI は一般的なベクターデザインソフトを指し、人工知能による画像生成ではない。

AIソフトを使い始めた人がよく検索するのは、AIで点線を描く方法、矢印を描く方法、曲線を描く方法、キャンバスサイズを変更する方法だ。どれも基本操作だが、入口は線、ペンツール、線分ツール、アートボードツールに分かれている。

実際の使用順に整理する。

AIで点線を描く方法

AIソフトでは、点線は単独のツールではなく、通常は「線」パネルで設定する。

手順：

線分ツール、ペンツール、または 図形ツール で線やパスを描く。
その線を選択する。
ウィンドウ -> 線 を開く。
線パネルで 破線 をオンにする。
線分 と 間隔 の数値を設定する。

よく使う考え方：

線分：実線部分の長さ。
間隔：実線同士の空き。
線幅：点線全体の太さ。

均等な点線にしたい場合は、まず次を試す。

1
2

線分：8
間隔：8

丸いドットのようにしたい場合は、線端を丸型にし、線分を小さくする。

1
2
3

線分：0
間隔：8
線端：丸型

これで丸い点が並んだように見える。

点線が表示されないとき

破線をオンにしても変化が見えない場合は、次を確認する。

オブジェクトに線色があるか。
線幅が小さすぎないか。
正しいオブジェクトを選択しているか。
線分 と 間隔 の数値が小さすぎないか。
塗りだけで、線がないオブジェクトではないか。

多くの線の問題は、「パスはあるが線がない」ことが原因だ。

AIで矢印を描く方法

矢印も通常は単独で描くのではなく、パスの線に矢印スタイルを追加する。

手順：

線分ツール で直線を描く。
直線を選択する。
ウィンドウ -> 線 を開く。
線パネル下部の 矢印 を探す。
始点または終点に矢印スタイルを選ぶ。
矢印の倍率を調整する。

矢印の向きが逆の場合は、次のどちらかで処理する。

線パネルで矢印を始点から終点へ移す。
パス方向を反転するコマンドを使う。

もっと簡単なのは、線を描き直すことだ。矢印の尾から先端へドラッグすれば、終点が矢印方向になる。

両矢印を描く方法

両矢印は、始点と終点の両方に矢印を設定するだけでよい。

手順：

線分を選択する。
線パネルを開く。
1つ目の矢印位置に矢印を選ぶ。
2つ目の矢印位置にも矢印を選ぶ。

矢印が大きすぎる、または小さすぎる場合は、倍率 を調整する。

一般に、矢印の大きさは線幅に合わせる。細い線に大きすぎる矢印は不自然で、太い線に小さすぎる矢印は見づらい。

AIで曲線を描く方法

AIで曲線を描くとき、最もよく使うのは ペンツール だ。

基本手順：

ペンツール を選ぶ。
キャンバス上で一度クリックし、最初のアンカーポイントを作る。
2つ目の位置では、クリックだけでなく押したままドラッグする。
ドラッグすると方向ハンドルが出て、曲線ができる。
さらにクリックとドラッグを続け、連続した曲線を作る。

ポイントは単純だ。直線はクリック、曲線はクリックしてドラッグする。

初心者が曲線を描けない原因は、多くの場合、毎回クリックだけして方向ハンドルをドラッグしていないことだ。

曲線をなめらかに調整する

曲線を描いた後は、次のツールで調整できる。

ダイレクト選択ツール：アンカーポイントを選び、点やハンドルを動かす。
アンカーポイントツール：角点とスムーズポイントを切り替える。
スムーズツール：パスをより滑らかにする。
曲率ツール：より簡単に滑らかな曲線を作る。

自然な曲線を描きたいだけなら、曲率ツール はペンツールより初心者向きだ。多くの方向ハンドルを手で引かなくても、いくつかの点をクリックするだけで滑らかなパスが作れる。

曲率ツールで曲線を描く

曲率ツールは「点を置くと、曲線が自動でついてくる」感覚に近い。

手順：

曲率ツール を選ぶ。
キャンバス上で最初の点をクリックする。
2つ目の点をクリックする。
3つ目の点をクリックすると、ソフトが自動的に曲線を作る。
既存の点をドラッグして曲線の形を変える。

角を作りたい場合は、点をダブルクリックして、スムーズポイントと角点を切り替える。

初心者は、まず曲率ツールで大まかな形を作り、後からダイレクト選択ツールで微調整するほうがやりやすい。

AIでキャンバスサイズを変更する方法

AIでいう「キャンバスサイズ」は、多くの場合 アートボードサイズ を指す。書き出し範囲、デザインサイズ、ページサイズを変えたい場合は、アートボードを変更する。

手順：

左のツールバーから アートボードツール を選ぶ。
現在のアートボードをクリックする。
上部のプロパティバーに幅と高さを入力する。
アートボードの端をドラッグして手動調整することもできる。

よく使うサイズ例：

WeChatカバー：900 x 383 px
小紅書カバー：1242 x 1660 px
Instagram正方形：1080 x 1080 px
A4用紙：210 x 297 mm

単位が px でない場合は、ドキュメントまたはプロパティパネルで単位を切り替える。

アートボードパネルでサイズを変える

アートボードツール以外にも、アートボードパネルで複数のアートボードを管理できる。

手順：

ウィンドウ -> アートボード を開く。
変更したいアートボードを選ぶ。
アートボードオプションを開く。
幅、高さ、位置を入力する。

1つのファイルに複数ページ、複数のポスターサイズ、複数の書き出し画像がある場合は、直接ドラッグするよりアートボードパネルのほうが分かりやすい。

アートボードサイズを変えると図形も変わるか

アートボードサイズだけを変更しても、中の図形は通常自動では拡大縮小されない。

つまり：

アートボードを大きくしても、図形サイズは変わらない。
アートボードを小さくしても、図形サイズは変わらないが、範囲外にはみ出すことがある。
書き出し時は通常、アートボード範囲内の内容だけが出力される。

図形も一緒に拡大縮小したい場合は、図形を選択して手動で拡大縮小するか、拡大縮小ツールや変形パネルを使う。

よく使う入口

覚えておくと便利な入口：

線パネル：ウィンドウ -> 線
アートボードパネル：ウィンドウ -> アートボード
アートボードツール：Shift + O
ペンツール：P
ダイレクト選択ツール：A

バージョンによって画面は少し違うことがあるが、基本ロジックは同じだ。点線と矢印は線パネル、曲線はパスツール、キャンバスサイズはアートボードで調整する。

まとめ

AIで点線を描く：パスを選択し、線 パネルで 破線 をオンにし、線分と間隔を設定する。

AIで矢印を描く：線を描き、線 パネルで始点または終点に矢印を追加する。

AIで曲線を描く：ペンツール でクリックしてドラッグする。初心者は 曲率ツール を使うと滑らかな曲線を作りやすい。

AIでキャンバスサイズを変更する：アートボードツール または アートボード パネルでアートボードの幅と高さを変える。

これらを覚えると、基本的な線、フローチャート、注釈図、ページサイズ調整の多くを扱えるようになる。

2026年の Linux デスクトップディストリビューション選び：Ubuntu、Deepin/UOS、Linux Mint、Fedora 比較

Thu, 07 May 2026 21:17:11 +0800

2026年に Linux デスクトップディストリビューションを選ぶとき、重要なのはどれが最も「純粋」か、どれが最も「先進的」かではありません。毎日気持ちよく使い続けられるかです。

デスクトップはサーバーとは違います。サーバーではライフサイクル、パッケージ安定性、運用規約が重要です。デスクトップではさらに、インターフェース、ドライバ、アプリストア、入力方式、オフィスソフト、GPU、Bluetooth、音声、タッチパッド、外部ディスプレイ、日常的な細かい不具合も効いてきます。

あまり手間をかけたくないなら、まず Ubuntu、Linux Mint、Deepin/UOS を見ます。開発者で、新しいソフトウェアスタックと速い技術サイクルを受け入れられるなら、Fedora も注目に値します。

早見表

ディストリビューション	最適な用途	主な利点	注意点
Ubuntu 26.04 LTS	初心者、開発者、主力デスクトップ	ドキュメントが最も多く、エコシステムが広く、ハードウェアとソフトウェア対応が強い	標準 GNOME には慣れが必要。Snap 方針を好まない人もいる
Deepin / UOS	中国語ユーザー、国産化環境、見た目を重視する人	美しく使いやすい。中国語ローカライズが強く、国産ソフトや政企環境との互換性が高い	コミュニティ版と商用版の位置付けが違う。更新方針を分けて見る必要がある
Linux Mint	Windows からの移行、安定優先ユーザー	親しみやすい UI、非常に使いやすい、Cinnamon が安定	新技術の導入は遅め。標準スタックは攻めていない
Fedora	開発者、Linux 新技術を試したい人	新しいカーネル、新しい GNOME、新技術の導入が速い	更新頻度が高く、安定保守派には LTS より落ち着かない

一言で言えば次の通りです。

初心者と主力デスクトップ：Ubuntu 26.04 LTS。
中国語・国産化体験：Deepin / UOS。
Windows からの滑らかな移行：Linux Mint。
開発者と新技術の先取り：Fedora。

Ubuntu 26.04 LTS：万能型デスクトップ

Ubuntu 26.04 LTS Resolute Raccoon は 2026年4月にリリースされました。LTS 版として、長期的な主力デスクトップに向いています。

Ubuntu の利点は非常に分かりやすいです。資料が最も多く、チュートリアルも最も多く、問題が起きたときに答えを検索しやすいです。VS Code、Docker、NVIDIA ドライバ、Steam、Chrome、Slack、JetBrains、CUDA、Python、Node.js などを入れる場合、Ubuntu はベンダーとコミュニティが優先して対応する対象であることが多いです。

Ubuntu 26.04 LTS に向く人：

初めて本格的に Linux デスクトップを使う人。
長く使える主力システムを探している人。
開発に安定した Linux 環境が必要な人。
多くのチュートリアル、ドライバ、商用ソフトウェア対応が必要な人。
デスクトップ、サーバー、WSL エコシステムをつなげたい人。

利点：

LTS ライフサイクルが長い。
公式イメージとドキュメントが成熟している。
GNOME デスクトップが現代的で、タッチパッドと複数ディスプレイ体験が比較的良い。
ドライバ、クラウド、コンテナ、開発ツールのエコシステムが広い。
問題発生時の検索コストが最も低い。

注意点として、Ubuntu は標準で GNOME を使います。Windows のデスクトップ操作とは違うため、初心者は Activities Overview、Dock、ワークスペース、アプリランチャーに慣れる必要があります。また Ubuntu は Snap を長く推進しており、起動速度、パッケージ管理方式、エコシステム方針を好まないユーザーもいます。

私の判断では、どのデスクトップディストリビューションを選ぶべきか分からないなら、Ubuntu 26.04 LTS は今でも最も安全なデフォルト回答です。すべての方向で最先端ではありませんが、総合点が最も高いです。

Deepin / UOS：中国語デスクトップ体験と国産化互換

Deepin と UOS の強みは、中国語デスクトップユーザーをよく理解している点です。

Deepin 25 は 2025年にリリースされ、2026年も deepin 25.1 などで更新が続いています。公式説明では、deepin 25 の重点として DDE デスクトップ環境の改善、UOS AI、Solid immutable system、Linyaps アプリ互換方式、Distrobox subsystem、Treeland window compositor preview などが挙げられています。

これらは Deepin/UOS が単なる「きれいな Linux スキン」を作っているのではなく、中国語デスクトップの長年の課題を解こうとしていることを示します。

アプリインストールと依存関係の衝突。
国産ソフトウェア互換性。
デスクトップの美しさと使いやすさ。
システム更新失敗時のロールバック。
中国語入力、オフィス、政企ソフトウェアエコシステム。
Windows アプリ互換と移行。

Deepin / UOS に向く人：

中国語 UI、入力方式、オフィス、本地化体験を重視する人。
開封後すぐ使え、見た目の良い Linux デスクトップが欲しい人。
国産化されたソフトウェア・ハードウェア環境で使う必要がある人。
政企オフィス、国産ソフト、国産 CPU、互換認証が必要な人。
GNOME/KDE を一から設定したくない人。

Deepin の利点：

DDE インターフェースが統一され、美しい。
中国語ユーザー向けの細部がよい。
アプリストアとシステム設定が一般ユーザーの感覚に近い。
Linyaps、Distrobox などが Linux アプリ互換問題の緩和に役立つ。
UOS 商用版は国産化シナリオで現実的価値が高い。

注意点として、Deepin コミュニティ版と UOS 商用版は完全に同じ位置付けではありません。Deepin は個人体験とコミュニティユーザー向けです。UOS は政企、国産化、商用サービス、認証環境寄りです。本番のオフィス環境では、インターフェースだけでなく、ハードウェア、ソフトウェア、組織要件を見る必要があります。

私の判断では、中国語ユーザーで、特に見た目、入力方式、国産ソフト、オフィス体験を重視するなら Deepin/UOS は魅力的です。ただし、標準的な上流 Linux エコシステムに強く依存する重い開発者なら、Ubuntu や Fedora の方が自然に感じるかもしれません。

Linux Mint：最も Windows に近く、最も安心

Linux Mint の位置付けは一貫しています。普通のユーザーが Linux を簡単に使えるようにすることです。

2026年時点で、Linux Mint の主系列は 22.x 系を中心に進んでおり、Ubuntu 24.04 LTS をベースにしています。Linux Mint 22.3 Zena は 2026年初めにリリースされました。これは最新技術の展示台ではなく、安定しており、慣れやすく、学習コストの低いデスクトップシステムです。

Linux Mint は Windows から移行するユーザーに特に向いています。特に Cinnamon デスクトップです。

左下メニュー。
タスクバー。
システムトレイ。
ウィンドウの最小化/最大化の動作。
設定パネル。
ファイルマネージャ。
更新マネージャ。

これらの細部は、伝統的な Windows デスクトップに近い感覚を作ります。GNOME ワークフローに慣れたくない人には、Linux Mint は Ubuntu より始めやすいです。

Linux Mint に向く人：

Windows から Linux へ移行する人。
親、家族、非技術ユーザーに Linux を入れる人。
新技術を追わず、安定したデスクトップが欲しい人。
主な用途がブラウザ、オフィス、動画、ファイル管理、軽い開発の人。
GNOME が好きではなく、KDE も調整したくない人。

利点：

Cinnamon デスクトップが直感的。
更新マネージャが分かりやすい。
システムが保守的で安定している。
古い PC に比較的優しい。
コミュニティ資料が多く、問題が比較的少ない。

注意点として、Linux Mint は新技術優先ではありません。Wayland、PipeWire、最新 GNOME/KDE、最新カーネル、最新 Mesa などは、通常最前線で導入されません。目指しているのは「今日安定して動くこと」であり、「最新の Linux デスクトップ技術を最初に使うこと」ではありません。

私の判断では、Windows ノート PC を Linux にしたいが多くの概念を説明したくないなら、Linux Mint は最も安定した選択肢の一つです。Ubuntu ほど商用エコシステムが強いわけでも、Fedora ほど新しいわけでもありませんが、日常体験は非常に堅実です。

Fedora：開発者と新技術優先

Fedora はデスクトップ Linux 新技術の前線の一つです。

2026年5月時点で、Fedora の current mainline は Fedora Linux 44 です。Fedora Workstation は、GNOME、Wayland、PipeWire、Mesa、カーネル、systemd などの新技術が比較的早く入るディストリビューションの一つです。

Fedora に向く人：

Linux 開発者。
GNOME ユーザー。
新しいカーネル、新しい Mesa、新しいコンパイラ、新しいツールチェーンを早く使いたい人。
Wayland、PipeWire、Flatpak などの現代的 Linux デスクトップスタックを体験したい人。
半年ごとのアップグレードを怖がらない人。

Fedora の利点：

新技術の導入が速い。
標準システムが比較的クリーン。
GNOME 体験が上流に近い。
開発ツールチェーンが新しい。
Flatpak とオープンソースデスクトップエコシステムの結び付きが強い。
現代的なハードウェア対応が比較的積極的。

注意点も明確です。

ライフサイクルが短く、定期的なアップグレードが必要。
システムをまったく保守したくない人には向かない。
NVIDIA、プロプライエタリコーデック、一部商用ソフトには追加リポジトリが必要。
「インストールして 5 年放置したい」なら、Fedora は LTS ディストリビューションほど向きません。

私の判断では、Fedora は開発者、Linux 愛好者、新技術を試したい人に向いています。普通の人にとって最も手間の少ないデスクトップではありませんが、Linux デスクトップの未来がどうなるかを早く見ることができます。

四つをどう選ぶか

初めて Linux を入れる初心者

Ubuntu 26.04 LTS または Linux Mint を優先します。

Ubuntu の強みは資料とエコシステムです。Linux Mint の強みは Windows に近く学習コストが低いことです。GNOME に慣れる気があるなら Ubuntu。できるだけ Windows に近い方がよいなら Linux Mint です。

中国語オフィスと国産化環境

Deepin / UOS を優先します。

国産オフィスソフト、国産ブラウザ、政企システム、国産 CPU、組織が求める互換環境が必要なら、UOS の実用価値が高いです。個人ユーザーが美しい中国語デスクトップを求めるなら Deepin を見ます。

開発者の主力機

Ubuntu 26.04 LTS と Fedora はどちらも候補です。

安定性、チュートリアル、商用ソフトウェア対応を重視するなら Ubuntu。新しいカーネル、新しい GNOME、新しいツールチェーン、オープンソース技術の前線を重視するなら Fedora です。

古い PC や家庭用 PC

Linux Mint がより合います。

伝統的なインターフェース、比較的優しいリソース使用、低い保守負担があります。古い PC、家庭用ブラウジング機、軽いオフィス用途では、新技術重視の Fedora より Mint の方が安定します。

AI/GPU/開発ツールチェーン

Ubuntu を優先します。

NVIDIA ドライバ、CUDA、PyTorch、TensorFlow、Docker、VS Code、JetBrains などのツールは、公式説明やチュートリアルで Ubuntu が最もよく登場します。Fedora でも使えますが、問題解決にはより多くの Linux 経験が必要になることがあります。

選ぶ前に見るべき点

デスクトップ Linux はスクリーンショットだけで選ぶべきではありません。実際の体験を左右するのは次の細部です。

GPU ドライバが安定しているか。特に NVIDIA。
Wi-Fi、Bluetooth、指紋、カメラが正常に動くか。
外部ディスプレイ、スケーリング、複数画面が快適か。
中国語入力方式が使いやすいか。
よく使うソフトに公式パッケージまたは Flatpak があるか。
システム更新が理解しやすいか。
問題が起きたときに解決策を検索できるか。
標準デスクトップワークフローを受け入れられるか。

Linux への移行に失敗する人の多くは、カーネルが弱いからではありません。入力方式、スケーリング、WeChat、オンラインバンキング、プリンタ、GPU ドライバのような日常的な細部が合わないからです。

私のおすすめ

場面	推奨
初心者の主力デスクトップ	Ubuntu 26.04 LTS
Windows ユーザーの移行	Linux Mint
美しい中国語デスクトップ	Deepin
国産化オフィス/政企環境	UOS
開発者の安定環境	Ubuntu 26.04 LTS
Linux 新技術体験	Fedora Linux 44
古い PC の軽いオフィス用途	Linux Mint
AI/GPU 開発	Ubuntu 26.04 LTS

短い結論

Ubuntu 26.04 LTS は 2026年で最も無難な万能デスクトップ選択です。初心者、開発者、主力機に向きます。

Deepin/UOS は中国語体験、美しいインターフェース、国産化互換に強く、本地化や政企環境を重視するユーザーに向きます。

Linux Mint は非常に使いやすく安定しており、特に Windows からの滑らかな移行に向きます。

Fedora は新技術と開発者体験に強く、Linux デスクトップの前線を追いたい人に向きます。

デスクトップシステムの良し悪しは、最終的には毎日 PC を開いたときに使い続けたいと思えるかで決まります。紙の上で最も良く見えるディストリビューションより、長く快適に使えるディストリビューションの方が重要です。

fdupesで削除順を制御する方法：ディレクトリ優先度で重複ファイルを残す

Wed, 06 May 2026 09:23:09 +0800

fdupes で重複ファイルを削除するとき、a、b、c の3つのディレクトリがあり、優先的に a を残し、次に b を残し、c の重複ファイルから削除したい場合、重要なのは複雑なルールではない。ディレクトリの入力順だ。

fdupes は非対話の削除モードでは、各重複グループで最初に見つかったファイルを残し、後から見つかった重複項目を削除する。そのため、ディレクトリ引数は「保持優先度が高いものから低いものへ」の順に並べる。

つまり、「先に c を削除し、次に b を削除し、できるだけ a を残す」には、次のように書く。

`1`	`fdupes -rdN a b c`

スキャン順は a -> b -> c になる。3つのディレクトリに同じファイルが存在する場合、a のファイルが先に見つかって保持され、b と c の重複ファイルが削除される。b と c だけに重複がある場合は、b が保持され、c が削除される。

パラメータの意味

よく使うパラメータは次の通り。

-r：サブディレクトリを再帰的にスキャンする。
-d：重複ファイルを削除する。
-N：-d と組み合わせて使い、対話確認を行わず、各重複グループの最初のファイルを残して残りを削除する。

そのため、重複ファイルを自動削除する基本形式は次のようになる。

`1`	`fdupes -rdN 目录A 目录B 目录C`

ディレクトリが前にあるほど保持優先度が高い。後ろにあるほど、重複ファイルが削除されやすくなる。

削除前にプレビューする

-dN を直接使うとファイルが削除されるため、まず重複ファイルのグループを確認するのがよい。

`1`	`fdupes -r a b c`

出力は重複ファイルごとにグループ化される。各グループで前に表示されるファイルが、非対話削除時に保持されやすいファイルだ。

統計情報を見ることもできる。

`1`	`fdupes -rm a b c`

データが重要な場合は、結果を保存して手動で確認する。

`1`	`fdupes -r a b c > duplicates.txt`

各重複グループの並び順が期待通りであることを確認してから、次を実行する。

`1`	`fdupes -rdN a b c`

サブディレクトリの扱い

-r を有効にすると、fdupes は渡されたディレクトリ配下のすべてのファイルを再帰的にスキャンする。保持優先度を決めるのは、やはりコマンド内でパスが登場する順序だ。

例えば次のように実行する。

`1`	`fdupes -rdN dir_a dir_b dir_c`

これは次の意味になる。

dir_a の優先度が最も高い。
dir_b がその次。
dir_c が最も低い。

dir_a/sub1/file.txt と dir_c/sub1/file.txt の内容が同じなら、dir_a 配下のファイルが保持される。dir_a/x/y/file.txt と dir_c/file.txt の内容が同じ場合も、dir_a 配下のファイルが優先される。fdupes が比較するのはファイル内容であり、ファイル名やディレクトリ階層が完全に一致する必要はない。

サブディレクトリの優先度を細かく制御する

親ディレクトリだけを渡す場合、サブディレクトリ内部のスキャン順は fdupes の走査ロジックに従う。多くの場合はこれで十分だ。ただし、特定のサブディレクトリにより高い優先度を与えたい場合は、そのサブディレクトリを明示的に前へ書く。

例えば、まず dir_a を残し、次に dir_b/special を残し、その後 dir_b の残りを処理し、最後に dir_c を処理したい場合は次のようにする。

`1`	`fdupes -rdN dir_a dir_b/special dir_b dir_c`

これにより、dir_b/special は dir_b より先にスキャンされる。その後 dir_b がスキャンされる時点では、special 内のファイルはすでに記録されているため、dir_b の他の部分より高い優先度を持つ。

この書き方は次のような需要に向いている。

a が最も重要な基準ディレクトリ。
b の中の特定サブディレクトリが、b の他の内容より重要。
c は主に低優先度のバックアップディレクトリ。

パス順はさらに拡張できる。

`1`	`fdupes -rdN a b/important b c/keep-first c`

ルールは変わらない。前にあるほど優先的に保持される。

ディレクトリが多い場合はリストを使う

ディレクトリやサブディレクトリが多い場合、長いコマンドを手で書くと間違えやすい。優先度順にパスを folders.txt のようなテキストファイルへ書いておくとよい。

/path/to/dir_a
/path/to/dir_b/sub_important
/path/to/dir_b
/path/to/dir_c/sub_1
/path/to/dir_c

その後、xargs で fdupes に渡す。

`1`	`cat folders.txt \| xargs fdupes -rdN`

パスに空白が含まれる可能性がある場合は、NULL文字区切りを使うほうが安全だ。

`1`	`tr '\n' '\0' < folders.txt \| xargs -0 fdupes -rdN`

注意すべき境界

第一に、fdupes が比較するのはファイル内容であり、ファイル名ではない。ファイル名が完全に違っていても、内容が同じなら重複ファイルとして扱われる。

第二に、a ディレクトリ内部に重複ファイルがある場合、fdupes -rdN a b c によって a 内部で後から見つかる重複項目も削除される可能性がある。このコマンドが表すのは「全体のスキャン順で最初に出たファイルを残す」ということであり、「a の中のファイルを絶対に削除しない」という意味ではない。

第三に、デフォルトでは fdupes はシンボリックリンクをたどらない。シンボリックリンク関連のファイルを処理する必要がある場合は、-s が必要かどうか、またそれがデータ安全上の期待に合うかを確認する。

第四に、fdupes は重複ファイルだけを削除し、空ディレクトリは削除しない。削除後に b や c に空フォルダが残った場合は、次を実行できる。

`1`	`find b c -type d -empty -delete`

より安全な操作習慣

ディレクトリ内のデータが重要な場合、いきなり -rdN を実行するのは避けたい。より安全な流れは次の通り。

まず fdupes -r a b c を実行して重複グループを見る。
各グループで先頭にあるファイルが本当に保持したいファイルか確認する。
その後 fdupes -rdN a b c を実行して自動削除する。
削除後、空ディレクトリの整理が必要か確認する。

a 内のファイルを誤って削除するのが非常に心配な場合は、低優先度ディレクトリだけを小さい範囲で先に整理するか、結果を出力して手動で絞り込むとよい。fdupes のディレクトリ順は便利だが、権限分離ルールではない。スキャン対象に含まれたパス内の重複ファイルは、削除判断に参加する可能性がある。

まとめ

fdupes で優先度に従って重複ファイルを削除する核心は、「残したいディレクトリ」を前に置き、「優先的に削除したいディレクトリ」を後ろに置くことだ。

a を残し、次に b を残し、c を優先的に削除するなら次のようにする。

`1`	`fdupes -rdN a b c`

特定のサブディレクトリの優先度を高くしたいなら、親ディレクトリより前に単独で書く。

`1`	`fdupes -rdN a b/important b c`

覚えることは一つでよい。fdupes -dN は先に現れた重複ファイルを残し、後に現れた重複ファイルを削除する。ディレクトリ順こそが保持優先度だ。

2026 年 5 月の Edge 高危険度脆弱性 CVE-2026-2441：悪意あるページの閲覧でリモートコード実行の恐れ

Wed, 06 May 2026 08:30:17 +0800

Microsoft Edge は最近、Chromium プロジェクトおよび Edge コンポーネントに由来する複数のセキュリティ問題を修正するため、複数回のセキュリティ更新を公開しました。そのうち CVE-2026-2441 は、Chromium チームにより実際の攻撃で悪用されていると報告されており、Microsoft Edge の Stable Channel と Extended Stable Channel の両方で修正が提供されています。

日常的に Edge で Web を閲覧している場合、特に Windows デバイスでアカウントログイン、メール、オンラインバンキング、管理画面、企業システムを扱う場合は、ブラウザーが最新バージョンへ更新済みか早めに確認してください。

脆弱性のリスク

CVE-2026-2441 は、攻撃者に注目され、すでに悪用が確認されている高リスクの脆弱性です。ブラウザー脆弱性の典型的な悪用方法は、特別に細工されたコンテンツを含むページへ利用者を誘導し、レンダリングエンジンや関連コンポーネントの欠陥を発火させるものです。

実際の攻撃では、この種の脆弱性により次のようなリスクが生じる可能性があります。

悪意あるコードを実行したり、他の脆弱性と組み合わせてサンドボックス制限をさらに突破したりする。
一部のセキュリティ制限を回避し、攻撃範囲を拡大する。
ブラウザー内の機密データ、セッション情報、ページ内容を窃取する。
ブラウザーのクラッシュ、ページ異常、サービス拒否を引き起こす。

注意すべき点として、ベンダーは通常、パッチ公開直後に完全な攻撃詳細を公開しません。脆弱性の再現を容易にしないためです。そのため、一般ユーザーにとって最も有効な対策は、速やかに更新することです。

影響範囲

Microsoft Edge は Chromium をベースにしているため、関連する脆弱性は Windows、macOS、Linux、モバイル版を含む複数プラットフォームの Edge バージョンに影響する可能性があります。修正を含むバージョンより古いブラウザーはリスクが残ります。

Microsoft Edge のセキュリティ更新リリースノートによると、2026 年 2 月 14 日に公開された Edge Stable Channel 145.0.3800.58 には CVE-2026-2441 の修正が含まれています。また、2026 年 2 月 17 日に公開された Extended Stable Channel 144.0.3719.130 にも同修正が含まれています。以後のバージョンにも Chromium プロジェクトのセキュリティ修正が継続的に取り込まれています。

2026 年 5 月 6 日時点で、Edge セキュリティ更新ページに掲載されている Stable Channel の最新セキュリティバージョンは、2026 年 4 月 30 日公開の 147.0.3912.98 です。手元のバージョンがこれらより明らかに古い場合は、すぐに更新してください。

Edge を今すぐ更新する

一般ユーザーは次の手順で確認と更新ができます。

Microsoft Edge を開きます。
アドレスバーに edge://settings/help と入力して Enter を押します。
ブラウザーが自動的に更新を確認するまで待ちます。
更新完了後、「再起動」をクリックします。

企業環境では、管理者がエンドポイント管理ポリシー、WSUS、Intune、グループポリシー、またはサードパーティのパッチ管理システムを確認し、Edge 更新が長期間遅延していないことを確認してください。すぐに更新できない端末については、不明な Web サイトへのアクセスを減らし、高リスクユーザーグループの外部 Web アクセスを優先的に制限するべきです。

防御の推奨事項

Edge をできるだけ早く更新し、更新後にブラウザーを再起動する。
出所不明のメールリンク、チャットリンク、広告リダイレクトをクリックしない。
古いブラウザーで管理画面、決済、メールなどの機密ページにアクセスしない。
Windows、ウイルス対策ソフト、ブラウザー拡張機能を最新状態に保つ。
長期間使っていない、または出所が不明なブラウザー拡張機能を削除する。

参考情報

まとめ

CVE-2026-2441 で重要なのは、脆弱性の詳細がどれほど複雑かではなく、実際の攻撃で悪用されていると報告されている点です。個人ユーザーと企業端末にとって最も直接的な対処は、edge://settings/help を開き、Edge の更新が完了していることを確認してブラウザーを再起動することです。

Snap、Flatpak、apt は何が違うのか

Sat, 02 May 2026 11:22:26 +0800

Ubuntu でソフトウェアをインストールするとき、apt、Snap、Flatpak という三つの名前をよく見ます。どれもアプリをインストールできますが、解決している問題は異なります。

簡単にまとめると次の通りです。

ツール	主な位置づけ	向いているもの
`apt`	Ubuntu/Debian の従来型パッケージマネージャー	システムコンポーネント、CLI ツール、ディストリビューションが管理するソフトウェア
Snap	Canonical が推進するアプリ包装形式	Ubuntu デスクトップアプリ、サーバーツール、自動更新したいソフトウェア
Flatpak	デスクトップアプリ向けのクロスディストリビューション形式	GUI アプリ、サンドボックス化アプリ、Flathub エコシステム

apt：システムの一部

apt は Debian/Ubuntu 系の従来型パッケージマネージャーです。ディストリビューションのリポジトリから .deb パッケージをインストールし、依存関係もディストリビューション側で管理されます。

よくあるインストール方法です。

`1`	`sudo apt install firefox`

apt の特徴は次の通りです。

システムとの統合が最も深い。
依存関係はディストリビューションが一元管理する。
ソフトウェアのバージョンは通常、ディストリビューションのリリース周期に従う。
システムライブラリ、ドライバー、CLI ツール、サーバーコンポーネントに向いている。

弱点も明確です。ソフトウェアのバージョンが古めになることがあります。ディストリビューションは安定性を重視するため、常に上流の最新版をすぐ出すわけではありません。

Snap：アプリと依存関係を一つのパッケージにする

Snap は Canonical が推進するパッケージ形式です。アプリと多くの実行時依存関係をまとめて梱包し、システムライブラリのバージョン差への依存を減らします。

インストール方法は似ています。

`1`	`sudo snap install firefox`

Snap の利点は次の通りです。

同じパッケージを複数の Ubuntu バージョンで動かしやすい。
アプリ更新をシステム更新から独立させられる。
標準で一定の隔離と権限制御がある。
速い更新が必要なデスクトップアプリや一部のサーバーツールに向いている。

よくある不満は、起動が遅い、容量を多く使う、テーマ統合が自然でない、更新のタイミングを apt ほど細かく制御しにくい、といった点です。

Flatpak：よりデスクトップアプリ向け

Flatpak もクロスディストリビューションのアプリ包装方式ですが、より Linux デスクトップアプリに寄っています。多くの Flatpak アプリは Flathub から入手できます。

よくあるインストール例です。

`1`	`flatpak install flathub org.mozilla.firefox`

Flatpak の特徴は次の通りです。

クロスディストリビューション対応が強い。
デスクトップアプリ配布に重点を置いている。
runtime を使って基礎依存関係を共有する。
サンドボックスと権限モデルが分かりやすい。
Flathub には多くのソフトウェアがある。

Flatpak も追加の容量を使います。特に初回に runtime を入れるときは目立ちます。ただし複数アプリが同じ runtime を共有すると、無駄は少なくなります。

最大の違い：依存関係の扱い

apt は「システムに組み込む」方式に近いです。アプリはシステム内のライブラリに依存し、複数のソフトウェアが同じ依存関係を共有します。

Snap と Flatpak は「アプリが自分の実行環境を持つ」方式に近いです。アプリが必要な依存関係の一部を持ち歩くため、システムバージョン差による問題を減らせます。

ここには取捨選択があります。

方式	利点	欠点
`apt` がシステム依存関係を共有	省容量、統合が良い、保守が一元化される	バージョンがディストリビューションに縛られる
Snap/Flatpak が実行環境を持つ	バージョン差に強い、複数ディストリビューションで使いやすい、更新しやすい	パッケージが大きい、起動が遅いことがある、統合感が弱いことがある

隔離と権限

apt で入れたソフトウェアは、通常システム環境で直接動きます。統合は自然ですが、隔離は少なめです。

Snap と Flatpak はどちらもサンドボックスの考え方を持っています。アプリは標準ではすべてのシステム資源へ自由にアクセスできず、ファイル、カメラ、ネットワーク、デスクトップ通知などには権限インターフェースを通じてアクセスします。

これは絶対安全という意味ではありませんが、より明確な権限境界を提供します。出所がさまざまなデスクトップアプリでは重要です。

更新方式の違い

apt は通常、システム更新に従います。

1
2

sudo apt update
sudo apt upgrade

Snap は自動更新されます。これは便利ですが、議論もあります。ユーザーはバージョン管理を気にしなくて済みますが、制御感は減ります。

Flatpak は手動で更新できます。

`1`	`flatpak update`

そのため、いつ更新するかを重視するなら、apt と Flatpak のほうが制御しやすく感じます。アプリを自動で新しく保ちたいなら、Snap のほうが楽です。

どれを使うべきか

用途で選ぶと分かりやすいです。

システムツール、ドライバー、サーバーコンポーネント：apt を優先。
Ubuntu が標準で推奨するデスクトップアプリ：Snap でもよい。
新しめのデスクトップソフト、特にクロスディストリビューションアプリ：Flatpak が合うことが多い。
同じソフトが三方式すべてにある場合：安定性、起動速度、テーマ統合、更新ニーズを見る。

保守的には、システム層は apt、デスクトップアプリは必要に応じて Snap と Flatpak から選ぶ、という使い分けで十分です。

まとめ

apt、Snap、Flatpak は、どれかがどれかを完全に置き換えるものではありません。配布モデルが違います。

apt はシステム保守に向き、Snap はアプリ同梱依存関係と自動更新を重視し、Flatpak はクロスディストリビューションのデスクトップアプリとサンドボックス配布に向いています。

日常利用なら、どれが最高かに悩みすぎる必要はありません。システムソフトは apt、デスクトップアプリはディストリビューションの推奨と自分の体験で選びます。安定して動き、更新を把握でき、権限が分かりやすければ、それが合った選択です。

参考：

https://www.reddit.com/r/Ubuntu/comments/9awvip/eli5_snap_and_flatpak_how_are_they_differ_from_apt/

Linux 7.0 と 7.1 における NTFS ドライバー変更の整理

Sat, 02 May 2026 10:46:20 +0800

Linux 7.0 の公開後、7.1 は次の機能マージ期間に入りました。そこで注目される変更の一つが、新しい NTFS カーネルドライバーです。

ここでいう「新しい」は、Linux が初めて NTFS に対応するという意味ではありません。また、ntfs3 が置き換えられるという意味でもありません。より正確には、Linux 7.1 に新しい任意のカーネル内 NTFS 読み書きドライバーが追加されます。これは昔からあるカーネル内 ntfs ドライバーを整理し直し、より完全な書き込み機能を補ったものです。

まず結論

Linux での NTFS 対応は、現在おもに三つのルートがあります。

方式	場所	読み書き	向いている場面
`ntfs-3g`	ユーザー空間 FUSE	読み書き	安定性優先。長く使われてきたディストリビューション標準
`ntfs3`	カーネル空間	読み書き	より直接的なカーネル統合と性能を求める場合
新 `ntfs`	カーネル空間	読み書き	Linux 7.1 で追加される任意の実装

今回の変更は強制移行ではなく、選択肢が一つ増えるという話です。普通のユーザーは、当面ディストリビューションの標準設定に従えば十分です。

7.0 と 7.1 の関係

Linux 7.0 は、カーネルのバージョンが 7.x 系列に入ったことを示します。7.0 で NTFS 対応が突然書き換えられたわけではありません。NTFS に関する新しい変更は、7.1 の機能マージ段階で入ります。

NTFS は Linux デスクトップユーザーにとって避けて通れないファイルシステムです。デュアルブート、外付けドライブ、USB メモリ、Windows データディスクでよく使われます。問題は、NTFS の書き込み経路が複雑なことです。ファイルシステムドライバーにバグがあると、ユーザーデータへ直接影響します。そのため、カーネルコミュニティは NTFS ドライバーの変更に慎重です。

`ntfs-3g`、`ntfs3`、新 `ntfs`

ntfs-3g はユーザー空間の FUSE ドライバーで、Linux 上の NTFS 読み書きを長く担ってきました。常に最速とは限りませんが、成熟しており、互換性が高く、情報も豊富です。

ntfs3 は Paragon Software が提供し、Linux メインラインに入ったカーネル内 NTFS ドライバーです。経路が短く、VFS との統合も直接的で、理論上の性能も高くなります。ただし、ファイルシステムドライバーには高い保守品質が求められるため、ntfs3 のマージ後も保守ペースやコード品質について議論がありました。

Linux 7.1 で追加される ntfs ドライバーは、Namjae Jeon が保守しています。ゼロから作られたものではなく、古いカーネル ntfs ドライバーを現代化し、読み書き能力を補った別の任意実装です。ntfs3 と併存します。

三者の関係は次のように考えると分かりやすいです。

ntfs-3g：保守的で成熟したユーザー空間実装。
ntfs3：すでにメインラインにあるカーネル内実装。
新 ntfs：7.1 で追加されるカーネル内実装。安定性は今後の観察が必要。

どれを使うべきか

日常利用で急いで切り替える必要はありません。保守的には次の順番が無難です。

重要なデータでは、ディストリビューション標準の方式を使う。多くの場合は ntfs-3g、または検証済みの ntfs3。
性能が必要な場合は ntfs3 を試す。
新しい ntfs ドライバーは、まずテスト用ディスク、一時データ、復旧可能なデータで試す。
重要な NTFS パーティションへ書き込む前にバックアップする。

ntfs3 を手動で使う場合の一般的なマウント例です。

`1`	`sudo mount -t ntfs3 /dev/sdX1 /mnt/ntfs`

一時的に読み取りだけしたい場合は、読み取り専用でマウントできます。

`1`	`sudo mount -o ro /dev/sdX1 /mnt/ntfs`

現在どのドライバーでマウントされているかは、次のように確認できます。

1
2

findmnt -T /mnt/ntfs
mount | grep ntfs

デュアルブート環境での注意

NTFS パーティションが Windows のシステムディスク由来の場合、書き込む前に Windows が完全にシャットダウンされていることを確認してください。高速スタートアップや休止状態は NTFS ボリュームを未完了の状態に残すため、Linux から書き込むと整合性問題が起きることがあります。

確認したい項目は次の通りです。

Windows の高速スタートアップを無効にする。
パーティションが hibernation 状態でないことを確認する。
BitLocker などの暗号化がアクセスを妨げていないことを確認する。
外付けドライブは Windows で正しく取り外す。

これは ntfs-3g、ntfs3、新しい ntfs のどれを使う場合でも同じです。

なぜ複数の NTFS ドライバーが必要なのか

同じファイルシステムに複数の実装が存在することは、Linux では珍しくありません。古い実装、新しい実装、ベンダー実装、コミュニティ実装がしばらく併存し、保守状況と実利用のフィードバックによって主流が決まっていきます。

NTFS では特に保守的な扱いが必要です。

ユーザーデータへのリスクが高い。
互換性の場面が複雑。
実装ごとに性能と安定性の取捨選択が異なる。
ディストリビューションが標準設定を検証する時間が必要。

そのため、Linux 7.1 の新 ntfs ドライバーは、ntfs-3g や ntfs3 をすぐ不要にするものではありません。カーネルコミュニティに、もう一つ保守可能な選択肢を与えるものです。

まとめ

Linux 7.1 で追加される ntfs ドライバーは、任意で使えるカーネル内 NTFS 読み書き実装です。ntfs-3g や ntfs3 と併存し、どちらかを直接置き換えるものではありません。

普通のユーザーは、引き続きディストリビューション標準の方式を使えば十分です。性能や新しいファイルシステム実装を試したい場合は、ntfs3 と新 ntfs の今後の安定性を見ながら、重要データでは必ずバックアップを取ってから切り替えるのが安全です。

sudo と sudo-rs の違い：Rust 版 sudo は何を変えるのか

Fri, 01 May 2026 19:27:08 +0800

sudo は Linux ユーザーにとって最もなじみ深いコマンドの一つである。通常ユーザーが、許可された範囲で一時的により高い権限でコマンドを実行できるようにする。たとえば、ソフトウェアのインストール、システム設定の変更、サービスの再起動などで使われる。

最近 sudo-rs が注目されているのは、Ubuntu 25.10 が従来の sudo を置き換える形で、Rust 実装の sudo-rs をデフォルトで使い始めるためだ。一般ユーザーから見ると、表面上は引き続き sudo と入力する。本当に変わるのはシステムの内側で、実行される実装が Rust 版 sudo になっている可能性がある。

この話では、自然に二つの疑問が出てくる。

従来の sudo に何か問題があるのか。
sudo-rs は日常利用やサーバー設定に影響するのか。

簡単に言えば、普通のデスクトップユーザーはほとんど心配しなくてよい。ただし、サーバーを管理している、複雑な sudoers ルールを書いたことがある、または特殊な sudo の挙動に依存している場合は、きちんとテストする必要がある。

sudo-rs とは

sudo-rs は Rust で書かれた sudo / su の実装である。完全に別物の新しいコマンドを作ることが目的ではなく、従来の sudo の主要機能を再実装しつつ、Rust のメモリ安全性を利用して一般的なセキュリティリスクを下げることを目指している。

従来の sudo は主に C 言語で書かれており、歴史が長く、機能も非常に充実している。その成熟度は安定性をもたらす一方で、保守上の負担にもなる。多くのコードはかなり古い Unix/Linux の利用場面に由来し、その後、大量の互換ロジック、拡張、境界処理が重ねられてきた。

sudo-rs が再実装を選んだ理由には、次のようなものがある。

Rust によりメモリ安全性の問題を減らす。
より現代的なコード構造で保守難度を下げる。
一部の歴史的機能やリスクのあるデフォルト挙動を削る。
Rust に慣れた新しい貢献者を呼び込む。
将来の権限昇格ツールに、より監査しやすい土台を提供する。

ただし、sudo-rs は従来の sudo と 100% 互換の置き換えではない。現在も開発中であり、一部の従来機能はまだ実装されておらず、別の一部は今後も実装されない可能性がある。

一般ユーザーが感じる変化

一般ユーザーにとって、変化はかなり少ない。

これまで通り次のように使う。

`1`	`sudo apt update`

または：

`1`	`sudo systemctl restart nginx`

Ubuntu 25.10 では、sudo が sudo-rs を指す。ユーザーが入力するコマンドを sudo-rs に変える必要はなく、スクリプト内の一般的な sudo 呼び出しも、コマンド名の変更で即座に壊れるわけではない。

見えやすい変化は、パスワード入力時のフィードバックである。 sudo-rs はデフォルトで、パスワード入力時にアスタリスクを表示する。従来の sudo でも設定により同様の挙動にできるが、多くのディストリビューションでは何も表示しない設定がデフォルトだった。

また、一部のエラーや警告メッセージの文面が変わる可能性がある。たとえば、パスワード誤り、権限不足、設定の非互換などでは、以前とまったく同じ文面ではないことがある。人間のユーザーにとって大きな影響はないが、sudo のエラー出力を解析するスクリプトがある場合は確認が必要だ。

管理者が注意すべき違い

本当に注意が必要なのは、システム管理者と上級ユーザーである。

従来の sudo のエコシステムは大きく、多くのサーバーには複雑な sudoers 設定がある。これらの設定には、コマンド引数のマッチング、環境変数の制御、ログ、メール通知、PAM の挙動、ホストグループごとのポリシーなどが含まれることがある。

sudo-rs には現時点で従来の sudo との違いがある。たとえば、元記事では sudo-rs が従来 sudo の sendmail サポートを含まないことに触れている。過去に sudo 使用通知を sendmail で送っていた環境では、移行時に別の方法を用意する必要がある。

認証面では、sudo-rs は PAM を使う。そのため、リソース制限や umask などの挙動は、sudoers ファイルだけに頼るのではなく、より PAM 側で設定する必要がある。以前 sudoers で多くの細部を扱っていた場合、切り替え前にそのルールが今も有効か確認するべきである。

もう一つ重要なのは、コマンド引数位置でのワイルドカード対応だ。 sudo-rs は sudoers ファイルでありがちな設定ミスを避けるため、コマンド引数位置でのワイルドカードをサポートしない。これはセキュリティ上は良いことだが、既存ルールに影響する可能性がある。

Ubuntu で sudo と sudo-rs はどう扱われるか

Ubuntu 25.10 以降、システムはデフォルトで sudo-rs を使う。ユーザーは引き続き sudo と入力し、その下で Rust 実装が動く。

従来の sudo がすぐ消えるわけではない。 Ubuntu の移行設計では、従来の sudo は sudo-ws という形で残される。どうしても従来実装が必要な場合は sudo-ws を使うか、alternatives の仕組みでデフォルト sudo を切り替えられる。

切り替えコマンドは次のような形になる。

`1`	`sudo update-alternatives --config sudo`

ただし、普通のユーザーが積極的に従来 sudo へ戻すことは勧めにくい。 sudoers をカスタマイズしておらず、特殊な挙動にも依存していないなら、ディストリビューションのデフォルトに従うほうが楽である。

古い Ubuntu バージョンで試したい場合、sudo-rs は Ubuntu 24.04 以降 universe リポジトリから入手できる。他のディストリビューションでもパッケージが提供されている可能性はあるが、コマンド名や統合方法は同じとは限らない。

なぜ sudo-rs は Rust を選ぶのか

sudo は高権限ツールである。この種のツールに脆弱性があると、通常のコマンドよりも深刻な結果につながることがある。歴史的にも、sudo には複数の権限昇格脆弱性が存在した。

Rust の強みはメモリ安全性にある。所有権、借用チェック、型システムにより、ダングリングポインタ、境界外アクセス、use-after-free などの一般的な問題を減らせる。これでプログラムが絶対に安全になるわけではないが、C/C++ プロジェクトでよく見られる一群の脆弱性を減らせる。

sudo のように長くセキュリティ上重要な位置にあるツールでは、より安全な言語で書き直すことには現実的な意味がある。これは単なる「Rust を使いたいから Rust」ではなく、保守と監査のコストを下げようとする試みである。

もちろん、言語がすべてのセキュリティ問題を解決するわけではない。権限チェックロジック、設定解析、PAM 連携、環境変数処理、ログ、ユーザー体験は、今後も慎重な設計と長期的なテストを必要とする。

sudo-rs は唯一の選択肢ではない

sudo エコシステムには、もともと他の代替ツールも存在する。

比較的よく知られているのは doas である。 OpenBSD 由来で、より単純で小さな設定を目指している。 sudo ほど複雑ではない点を好むユーザーもいる。

ほかにも、RootAsRole や systemd の run0 など、Rust や systemd 関連の代替案がある。ただし、これらのツールの目的や適用場面は完全には同じではない。

多くの Linux ディストリビューションでは、sudo は今でもデフォルトの選択肢である。 sudo-rs の意味は、ユーザーの習慣を保ちながら、内部実装をより現代的なコード基盤に置き換えようとしている点にある。

移行前に確認すべきこと

個人のデスクトップユーザーなら、ディストリビューションのデフォルト設定に従えばよい。

サーバーやワークステーションを管理している場合は、次の点を確認したい。

複雑な /etc/sudoers または /etc/sudoers.d/ ルールがあるか。
コマンド引数のワイルドカードを使っているか。
sudo のメール通知に依存しているか。
sudo のエラー出力を解析するスクリプトがあるか。
sudoers で umask、リソース制限、環境変数を制御しているか。
LDAP、PAM、SSSD などの認証連携があるか。
automation やデプロイスクリプトが従来 sudo の挙動を前提にしているか。

まずテスト機で確認できる。

sudo -l

その後、重要な保守コマンドを実行し、権限、環境変数、ログ挙動が期待通りか確認する。

sudo-rs へ自分で切り替えるべきか

ディストリビューションがすでにデフォルトで切り替えているなら、普通のユーザーはそのまま受け入れてよい。サーバーや本番環境では、試したいという理由だけで手動置き換えするのは勧めにくい。

より安全な進め方は次の通り。

テスト環境に sudo-rs をインストールする。
既存の sudoers 設定を項目ごとに検証する。
PAM、ログ、監査、automation スクリプトを確認する。
ロールバック方法を確認する。
ディストリビューションが安定した統合を提供してから移行する。

この種のツールは権限チェーン上にあるため、「いくつかのコマンドが動く」だけで安全とは判断しにくい。本当に確認すべきなのは、境界条件と異常系である。

まとめ

sudo-rs は従来 sudo の Rust 実装であり、より現代的で安全なコード基盤で sudo の中核機能を担うことを目指している。 Ubuntu 25.10 がデフォルトで有効化することは、主要ディストリビューションがこの方向を本格的に進め始めたことを示している。

一般ユーザーにとって、変化は小さい。引き続き sudo と入力するだけで、内部実装が sudo-rs になっている可能性があるだけだ。気づくとしても、パスワード入力時にアスタリスクが表示されることや、エラーメッセージが少し変わることくらいである。

システム管理者にとって、重要なのは互換性だ。複雑な sudoers ルール、sendmail 通知、PAM 連携、引数ワイルドカード、sudo 出力に依存するスクリプトがある場合は、アップグレード前にテストすべきである。

Rust による書き直しは万能薬ではない。それでも sudo のようなセキュリティ上重要なツールでは、メモリ安全性リスクと保守の複雑さを減らす方向として、真剣に検討する価値がある。

参考ソース：

X11 と Wayland の違い、長所・短所、選び方

Fri, 01 May 2026 19:23:01 +0800

Linux デスクトップでは、X11 と Wayland という二つの名前をよく目にする。どちらもグラフィック表示に関係しているが、設計された時代、アーキテクチャの考え方、使い勝手はかなり違う。

簡単に言えば、X11 は旧世代のディスプレイプロトコルとエコシステムである。機能は成熟しており互換性も高いが、アーキテクチャは複雑で、セキュリティモデルは古い。 Wayland は新世代のディスプレイプロトコルで、中間層を減らし、セキュリティと滑らかさを高めることを目指している。ただし、一部のソフトウェアやワークフローはまだ適応が必要だ。

日常利用だけを考えるなら、結論は次の通り。

新しく Linux デスクトップを入れるなら、まず Wayland を試す。
古いソフトウェア、複雑なリモートデスクトップ、特殊な入力デバイス、一部の専門ツールが必要なら、X11 のほうがまだ安定しやすい。
ゲームや通常のオフィス用途では、Wayland はかなり実用的になっている。
互換性の問題が出たら X11 に戻せばよい。これは信条の問題ではない。

X11 とは

X11 は X Window System や Xorg とも呼ばれ、Linux や Unix デスクトップで長年使われてきたグラフィックシステムである。その設計思想は、プログラムをあるマシンで実行し、ウィンドウを別のマシンに表示するという、初期のネットワークコンピューティング環境に由来する。

X11 の典型的な構造は次のようになる。

アプリケーションがウィンドウ内容を描画する。
X Server が表示、入力、基本的なウィンドウ操作を管理する。
ウィンドウマネージャーが枠、移動、重なり順を担当する。
コンポジターが影、透明効果、アニメーション、ティアリング制御などを担当する。

この構造は柔軟で、X11 は大量のツールと拡張を蓄積してきた。しかし時間が経つにつれて、問題も明確になった。コンポーネントが多く、経路が長く、権限境界が緩く、現代的なデスクトップ要求の多くを拡張やパッチで支えている。

Wayland とは

Wayland は、従来型の完全なディスプレイサーバーというより、より現代的なディスプレイプロトコルである。 Wayland では、コンポジターが同時にディスプレイサーバーの役割を担うことが多い。 GNOME の Mutter、KDE の KWin、wlroots 系のコンポジターはいずれも Wayland compositor として動作できる。

Wayland の典型的な構造はより短い。

アプリケーションが自分でウィンドウ内容をレンダリングする。
コンポジターがアプリケーションから送られた buffer を受け取る。
コンポジターがウィンドウ、入力、ディスプレイ出力、合成を一元管理する。
最終的な画面はカーネルのグラフィックスタックへ直接渡されて表示される。

この設計により、従来の X11 にあった X Server、ウィンドウマネージャー、コンポジター間の遠回りが減る。また、権限制御も明確になる。アプリケーションはデフォルトで他のウィンドウ内容を自由に読めず、グローバルなキーボード入力も勝手に監視できない。

アーキテクチャの違い

最も大きな違いは、責務の分け方にある。

X11 では、X Server が中心にあり、多くのアプリケーションがそれとやり取りできる。ウィンドウマネージャー、コンポジター、入力メソッド、スクリーンショットツール、リモート制御ツールも、X11 のオープンなインターフェースを通じて多くの情報を取得できる。これは高い互換性をもたらす一方で、セキュリティ上の問題も生む。

Wayland では、コンポジターが中心である。アプリケーションは他のウィンドウ内容を直接取得できず、すべてのキーボード入力をデフォルトで監視することもできない。スクリーンショット、録画、画面共有、グローバルショートカット、リモート制御などは、デスクトップポータル、PipeWire、またはコンポジターが提供する制御されたインターフェースを通す必要がある。

整理すると次のようになる。

比較項目	X11	Wayland
設計時代	古い	新しい
中心コンポーネント	X Server	Compositor
コンポジターの役割	任意または追加コンポーネント	中核コンポーネント
アプリ間の隔離	弱い	強い
リモート表示	元から強い考え方	新しいツールチェーンに依存
互換性	非常に強い	まだ補完中
現代的なデスクトップ体験	拡張とパッチに依存	設計上、現代的な要求に近い

X11 の長所

X11 最大の長所は成熟度である。長年動いてきたため、ほぼすべての Linux グラフィカルアプリケーションが X11 で動作する。古いツール、専門ソフトウェア、特殊な入力メソッド、リモート制御、 automation スクリプトも、X11 を優先してサポートしていることが多い。

もう一つの長所は操作しやすさである。多くのツールはウィンドウの読み取り、入力のシミュレーション、画面キャプチャ、ウィンドウ移動、キー入力監視を直接行える。これは automation、リモート支援、ウィンドウ管理スクリプト、特殊なワークフローに便利だ。

次のような用途があるなら、X11 は今でも現実的な選択肢である。

古い GUI ソフトウェアを使う。
xrandr、xinput、xdotool、wmctrl に依存している。
従来型のリモートデスクトップやウィンドウ転送を使う。
特殊なスクリーンショット、録画、キーボード/マウスマクロツールが必要。
あるアプリが Wayland ではまだ不安定。

X11 の短所

X11 の短所は主に歴史的な負担から来ている。

まず、セキュリティモデルが古い。従来の X11 セッションでは、通常のアプリケーションが他のウィンドウ入力を監視したり、画面内容を取得したり、キーボードやマウス操作をシミュレートしたりできることが多い。現代的なデスクトップセキュリティの観点では、これは受け入れにくい。

次に、レンダリング経路が複雑である。 X11 は Composite、GLX、DRI、RandR、Present など、多くの拡張を経てきた。これらの拡張により現代的なデスクトップを支え続けられたが、グラフィックスタックも複雑になった。高リフレッシュレート、マルチモニター、異なるスケーリング、混在 DPI、低遅延入力などでは、X11 は細かな問題が出やすい。

さらに、X11 の保守の重点は徐々に互換性へ移っている。主要なデスクトップ環境は今でも X11 をサポートしているが、新機能や新しい最適化は Wayland に先に入ることが多い。

Wayland の長所

Wayland の利点は、主に現代的なデスクトップ体験にある。

レンダリング経路がより直接的である。アプリケーションが buffer をレンダリングし、コンポジターが一元的に合成して表示するため、従来の X11 アーキテクチャにあった遠回りが減る。アニメーション、ウィンドウ移動、高リフレッシュレート、マルチモニター、タッチパッドジェスチャー、分数スケーリングなどでは、Wayland のほうがきれいに実装しやすい。

セキュリティも Wayland の重要な長所である。アプリケーションはデフォルトで他のウィンドウを自由にキャプチャできず、グローバルなキーボード入力も無条件には監視できない。スクリーンショット、録画、画面共有にはユーザー許可が必要で、通常はデスクトップポータルと PipeWire を通じて処理される。

Wayland は現代的なハードウェアにも向いている。タッチパッドジェスチャー、HiDPI、可変リフレッシュレート、モニターごとの異なるスケーリングなどは、Wayland のほうが自然に扱いやすい。 GNOME と KDE も近年、多くのデスクトップ体験改善を Wayland セッションへ投入している。

Wayland の短所

Wayland の問題は「使えない」ことではなく、エコシステムがまだ移行中であることだ。

一部のツールは、グローバルキー監視、ウィンドウ列挙、自動クリック、画面取得、ウィンドウ移動など、X11 のオープンな機能に依存していた。 Wayland ではこれらをそのまま持ち込めず、ポータル、コンポジタープロトコル、またはデスクトップ環境 API を通す必要がある。そのため、一部の古いツールは動かなくなったり、特定のデスクトップ環境でしか動作しなかったりする。

リモートデスクトップも典型的な問題である。 X11 にはネットワーク透過性という歴史的な設計があり、現代の使用体験が常に良いとは限らないが、多くのツールが成熟している。 Wayland でリモートデスクトップを使うには、PipeWire、RDP、VNC、デスクトップポータル、またはコンポジターのサポートが必要で、体験は GNOME、KDE、Sway などの実装に依存する。

入力メソッドもかつては痛点だった。現在は Fcitx5 や IBus が主要な Wayland デスクトップでかなり改善されているが、一部の Electron アプリ、古いプログラム、特殊な組み合わせでは、候補ウィンドウの位置、フォーカス、ショートカットに問題が出ることがある。

NVIDIA も長く Wayland の障害の一つだった。近年は NVIDIA ドライバとデスクトップ環境のサポートが大きく改善したが、古い GPU、古いドライバ、特殊なマルチモニター構成では、まだ X11 のほうが安定する場合がある。

Xwayland の役割

Wayland に切り替えると X11 アプリがまったく使えなくなる、と思っている人も多い。実際にはそうではない。

Wayland デスクトップは通常、Xwayland を使って古い X11 アプリケーションを互換実行する。アプリケーションは自分が X11 上で動いていると思い、実際のウィンドウ内容は Wayland コンポジターへ渡されて表示される。

これにより移行はかなり滑らかになる。

ネイティブ Wayland アプリは Wayland を使う。
古い X11 アプリは Xwayland を使う。
ユーザーは一つのデスクトップセッションで両方の種類のプログラムを同時に使える。

ただし、Xwayland は万能ではない。グローバル入力監視、ウィンドウ管理スクリプト、低レベルの X11 拡張に依存するツールは、やはり制限を受けることがある。

性能はどちらが良いか

Wayland が必ず X11 より速い、または X11 が必ず安定している、と単純には言えない。実際の挙動は、デスクトップ環境、グラフィックドライバ、アプリの種類、使用場面に依存する。

一般的には次のように考えられる。

通常のデスクトップアニメーションや高リフレッシュレート表示では、Wayland のほうが滑らかに感じやすい。
混在 DPI やマルチモニターのスケーリングでは、Wayland に利点がある。
古いアプリや特殊なツールでは、X11 のほうが問題が少ない。
ゲームでは、Xwayland とネイティブ対応により Wayland はかなり成熟しているが、一部のゲームやキャプチャツールはまだ X11 を好む場合がある。
専門的なグラフィック、リモート制御、automation スクリプトは、具体的なツールごとに確認する必要がある。

多くの一般ユーザーにとって、性能は最大の違いではない。実際の体験を左右するのは、互換性、セキュリティ境界、モニター構成、入力デバイス対応である。

スクリーンショット、録画、画面共有

これは Wayland で最も誤解されやすい部分である。

X11 では、スクリーンショットや録画ツールが通常そのまま画面を取得できる。これは便利だが、悪意あるプログラムが画面を盗み見しやすいという意味でもある。

Wayland では、アプリケーションが自由に画面を取得することはできない。スクリーンショット、録画、配信、会議での画面共有は、通常デスクトップポータルと PipeWire を通り、ユーザーの許可を必要とする。これはより安全だが、アプリケーション側が新しいインターフェースをサポートしている必要がある。

そのため、ある会議ソフト、録画ツール、スクリーンショットツールが Wayland でうまく動かない場合、それは Wayland が「対応していない」という意味とは限らない。むしろ、そのアプリがポータルや PipeWire に十分適応していない可能性が高い。

ゲームではどちらを選ぶべきか

現在の Linux ゲームは、もはや X11 専用ではない。 Steam、Proton、Mesa、KDE、GNOME、Gamescope、Xwayland により、Wayland でのゲーム体験は大きく改善している。

AMD または Intel GPU を使っているなら、Wayland は日常のゲーム環境として十分使えることが多い。 NVIDIA の場合も新しいドライバではかなり実用的になっているが、ドライバとデスクトップ環境は新しめに保つのがよい。

ゲーム用途では次のように選べる。

通常の Steam / Proton ゲーム：まず Wayland を試す。
録画、配信、オーバーレイ、入力遅延に問題が出た場合：X11 と比較する。
Gamescope を使う場合：Wayland エコシステムのほうが合う。
古い GPU や古いドライバを使う場合：X11 のほうが楽なことがある。

リモートデスクトップと automation

ワークフローがリモートデスクトップ、ウィンドウ automation、グローバルなキーボード/マウス制御に依存している場合は、より慎重に考える必要がある。

X11 はこうした場面でツールが多く、挙動も直接的である。たとえば、スクリプトでウィンドウを制御する、クリックをシミュレートする、特定ウィンドウを取得する、といった操作は X11 のほうが簡単なことが多い。

Wayland は安全設計上、通常のアプリケーションが他のウィンドウを自由に制御することを許さない。そのため、automation ツールはデスクトップ環境が提供するインターフェースを使うか、専用のリモートデスクトップ実装を使う必要がある。 GNOME と KDE はこうした機能を補っているが、デスクトップ間の一貫性はまだ X11 ほどではない。

普通のデスクトップユーザーなら Wayland で問題ない。リモート制御、automation テスト、ウィンドウ管理スクリプトを重用しているなら、X11 のほうが合う可能性がある。

自分がどちらを使っているか確認する

現在のセッション種別は、環境変数で確認できる。

`1`	`echo $XDG_SESSION_TYPE`

出力が次なら：

wayland

現在は Wayland セッションである。

出力が次なら：

x11

現在は X11 セッションである。

GNOME や KDE などのデスクトップでは、ログイン画面の歯車メニューやセッション選択から X11 / Wayland を切り替えられることが多い。

選び方

次のように判断できる。

場面	推奨
新しいPC、主要ディストリビューション、通常のオフィス用途	Wayland 優先
最新の GNOME / KDE	Wayland 優先
マルチモニター、HiDPI、高リフレッシュレート	Wayland 優先
古いソフトウェア、古い GPU、古いドライバ	X11 優先
リモートデスクトップ、ウィンドウスクリプト、automation テスト	X11 優先、または Wayland を個別検証
ゲーム	まず Wayland、問題があれば X11
会議の画面共有、録画	ソフトウェアの PipeWire / ポータル対応次第
セキュリティ重視、マルチユーザーデスクトップ	Wayland 優先

Wayland は今後の方向性だが、X11 がすぐ消えるわけではない。両者はしばらく共存し続ける。

まとめ

X11 の強みは成熟、互換性、豊富なツールである。古いソフトウェア、リモートデスクトップ、ウィンドウ automation、一部の特殊なワークフローに向いている。弱点はセキュリティ境界が弱く、アーキテクチャが複雑で、現代的なマルチモニター、高リフレッシュレート、混在スケーリングに対してすっきりしない点だ。

Wayland の強みは、より現代的なアーキテクチャ、より良いセキュリティ、より直接的な表示経路である。 HiDPI、タッチパッドジェスチャー、マルチモニター、現代的なデスクトップ体験にも向いている。弱点は、一部の古いツール、リモート制御、スクリーンショット/録画、入力メソッドでまだ適応コストがあることだ。

一般ユーザーは Wayland をデフォルトの選択肢として考えてよい。特定のアプリや周辺機器が正常に動かない場合だけ、X11 に戻して確認すればよい。 Linux デスクトップにとって、これはどちらかを信じる話ではなく、ハードウェア、ソフトウェア、ワークフローに合うほうを選ぶ話である。

参考ソース：

Copy Fail 脆弱性 CVE-2026-31431：Linux カーネルのファイルコピー経路におけるコンテナエスケープリスク

Fri, 01 May 2026 18:42:34 +0800

Copy Fail は Linux カーネルのファイルコピー経路に影響する脆弱性で、CVE-2026-31431 として管理されている。 Bugcrowd の分析では、これは注意すべきカーネルレベルの問題とされている。特定の条件下で、非特権ユーザーがファイルコピー関連のロジックを悪用し、不正な書き込みを引き起こせる可能性があり、その結果として権限昇格やコンテナエスケープにつながる。

リスクの観点では、これは通常のアプリケーション層の脆弱性ではない。問題はカーネルがファイルコピーとページキャッシュを処理する経路で発生するため、影響はコンテナ、共有ホスト、CI/CD Runner、PaaS プラットフォーム、マルチテナント Linux 環境にまで及ぶ。攻撃者がすでにシステム内で低権限コードを実行できる場合、この脆弱性は隔離境界を突破するための足がかりになり得る。

脆弱性はおおよそどこで発生するのか

Copy Fail は Linux カーネルのファイルコピー機能に関係している。現代の Linux には、copy_file_range、splice 系の経路、異なるファイルシステム間のデータコピー最適化など、複数の効率的なコピー経路がある。これらの仕組みは、ユーザー空間とカーネル空間の間のデータ移動を減らし、大きなファイルコピーの性能を高めるために用意されている。

問題は、高性能なコピー経路がページキャッシュ、ファイルオフセット、権限チェック、ファイルシステムコールバックを再利用することが多い点にある。どこかの境界条件の処理が厳密でない場合、カーネルが誤った権限コンテキストで書き込みを行ったり、本来攻撃者が変更できないデータページを制御できる形で露出したりする可能性がある。

Copy Fail の主なリスクは次のように整理できる。

攻撃者は root 権限を必要としない。
攻撃入口は一般的なファイルコピー機能にある。
影響点はカーネル空間にある。
コンテナ環境では、namespace やマウント隔離を迂回する可能性がある。
悪用に成功すると、コンテナが変更できないはずのホスト上の内容へ書き込める可能性がある。

これが Copy Fail が大きく取り上げられる理由である。コンテナセキュリティは Linux カーネルが提供する隔離機能に依存している。カーネル経路そのものに不正書き込みがあると、コンテナ境界は脆くなる。

なぜコンテナ環境でより敏感なのか

コンテナは仮想マシンではない。コンテナ内のプロセスとホストは同じ Linux カーネルを共有しており、namespace、cgroup、capability、seccomp、AppArmor/SELinux などの仕組みによって隔離されている。

脆弱性がユーザー空間サービスにある場合、通常は一つのコンテナや一つのプロセスに影響が限定される。しかし脆弱性がカーネルにあり、しかも非特権ユーザーからトリガーできる場合、攻撃者はコンテナ内部からホストへ影響を及ぼす可能性がある。

Copy Fail の危険性はここにある。多くのプラットフォームでは、ユーザーがビルドジョブを投入したり、スクリプトを実行したり、コンテナを起動したり、プラグインを動かしたりできる。攻撃者がコンテナ内でコードを実行できるだけで、カーネルのファイルコピー経路を利用して隔離を突破しようとする可能性がある。

高リスクな環境には次のようなものがある。

Kubernetes クラスター内の信頼できないワークロード。
CI/CD プラットフォームの共有 Runner。
ユーザーがコードをアップロードして実行できるサンドボックス。
マルチテナント Linux ホスト。
コンテナ化された PaaS。
サードパーティ製プラグインや拡張を実行するシステム。

これらの環境で影響を受けるカーネルが使われており、追加の制限が不足している場合、リスクは明らかに高まる。

影響範囲はカーネルのパッチ状態を見る必要がある

この種の脆弱性は、ディストリビューション名だけでは判断できない。同じ Ubuntu、Debian、RHEL、Fedora、Arch であっても、影響を受けるかどうかは実際に実行中のカーネルパッケージと、ディストリビューションが修正をバックポート済みかどうかに依存する。

調査では、まず次の三点を確認する。

現在実行中のカーネルバージョン。
ディストリビューションのセキュリティアドバイザリに CVE-2026-31431 が含まれているか。
クラウドベンダーやマネージドプラットフォームがホストカーネルを修正済みか。

まずシステム上でカーネルバージョンを確認する。

`1`	`uname -a`

そのうえで、ディストリビューションのセキュリティアドバイザリ、カーネル changelog、クラウドプラットフォームの告知を確認する。多くのエンタープライズディストリビューションは古いカーネルブランチへセキュリティ修正をバックポートするため、メジャーバージョンだけで安全かどうかを判断してはいけない。

一時的な緩和策

最も確実な修正はカーネル更新である。ただし、すぐにパッチを展開できない環境では、まず露出面を下げることができる。

一般的な緩和の方向性は次の通り。

信頼できないユーザーに特権コンテナを実行させない。
コンテナへ機密性の高いホストパスをマウントしない。
コンテナの capability を絞り、特に不要な CAP_SYS_ADMIN を付与しない。
seccomp、AppArmor、SELinux で危険なシステムコールとファイルアクセスを制限する。
信頼できないワークロードを、より隔離の強い仮想マシンへ移す。
CI/CD Runner はジョブごとに破棄し、同じホストを長期間使い回さない。
異常なファイル書き込み、権限変更、コンテナエスケープの兆候を監視する。

これらの対策はパッチの代替にはならない。目的は、パッチが本番環境に届くまでの間、悪用成功率と影響範囲を下げることである。

修正の優先順位

環境のリスクに応じて優先順位を付けるのがよい。

優先して修正すべきもの：

外部にコンテナ実行機能を提供するプラットフォーム。
信頼できないコードを実行する CI/CD ノード。
マルチテナント Kubernetes ノード。
ユーザー定義プラグインやスクリプト実行機能を持つシステム。
共有開発機、教育用マシン、実験環境。

相対的に優先度が低いもの：

単一ユーザーのデスクトップ。
信頼済みサービスだけを実行する内部ホスト。
信頼できないコードをすでに仮想マシンで隔離している環境。

リスクが低い場合でも、ディストリビューション経由でカーネルを更新することを推奨する。カーネル脆弱性はより複雑な攻撃チェーンに組み込まれることが多く、パッチを遅らせる利点はあまりない。

運用チーム向けチェックリスト

次の順序で対応できる。

すべての Linux ホストとコンテナノードを棚卸しする。
信頼できないコードを実行するマシンを特定する。
現在のカーネルバージョンとディストリビューションのセキュリティアドバイザリを確認する。
高リスクノードを優先して更新する。
すぐに更新できないノードには一時的な隔離ポリシーを適用する。
コンテナランタイム設定を確認し、不要な特権とホストマウントを削除する。
更新後にノードを再起動し、新しいカーネルが実際に有効になっていることを確認する。
後続の監査に備えて変更記録を残す。

カーネルパッケージをインストールしただけでは、システムが新しいカーネルで動いているとは限らない。更新後は必ず再起動し、再度確認する。

`1`	`uname -a`

まとめ

Copy Fail / CVE-2026-31431 の要点は、どこかのアプリケーションがクラッシュすることではなく、Linux カーネルのファイルコピー経路に権限境界の問題があることだ。非特権コードが、より高い権限のデータ書き込み経路へ触れる機会を持つため、コンテナ環境やマルチテナント環境では特に注意が必要である。

この種の脆弱性に対応するうえで重要なのは次の二点だ。

ディストリビューションまたはクラウドベンダーが提供するカーネルパッチをできるだけ早く適用する。
パッチ展開前は、信頼できないコード、特権コンテナ、機密性の高いホストマウントを制限する。

個人デスクトップでは、すぐに慌てる必要がある問題ではないかもしれない。しかし、コンテナプラットフォーム、CI/CD、サンドボックス、共有ホストを運用しているチームにとっては、高優先度のカーネルセキュリティ更新として扱うべきである。

参考ソース：

Linux Kernel 7.0 更新内容の整理

Fri, 01 May 2026 14:46:07 +0800

Linux カーネルのバージョン番号は、以前からセマンティックバージョニングではない。メジャーバージョンの上昇は、主にメンテナンス周期上のロールアップに近い。 Linus Torvalds もリリースメールで 7.0 を通常のリリースとして説明しており、最後の週はネットワーク、アーキテクチャ、ツール、セルフテスト、ドライバまわりの小さな修正が中心だった。

本当に注目すべきなのは、この増分更新の中身である。 Linux 7.0 は、ファイルシステム、メモリ管理、ハードウェアサポート、セキュリティ分離、Rust サポート、ドライバ整理など、複数の領域にまたがっている。

ファイルシステム：XFS、EXT4、NTFS3 に変更

Linux 7.0 で最も体感しやすい更新の一つはファイルシステムだ。

XFS には自己修復に関連する機能が入った。新しい汎用ファイルシステムエラー報告の仕組みと組み合わせることで、ファイルシステムは metadata の破損や I/O エラーを、より統一された方法でユーザー空間へ伝えられる。適切なシステムサービスと連携すれば、XFS はファイルシステムをマウントしたまま一部の修復処理を自動で扱える。すべてのディスク破損を無痛で直せるという意味ではないが、サーバーや長時間稼働するシステムでは、エラー検出から修復までの経路がより整う。

EXT4 は並行 direct I/O 書き込み性能を引き続き改善している。バックアップ、ビルド、ダウンロード、データベース、ログ処理などが同時にディスクへ書き込む環境では、こうした最適化により並行書き込み経路がより安定する。すべてのデスクトップユーザーがすぐ体感する変化ではないが、高 I/O の場面では意味がある。

NTFS3 も比較的大きなドライバ更新を受けている。内容には delayed allocation、iomap ベースのファイル操作、大きなディレクトリを走査する場面での readahead 改善が含まれる。 Linux から Windows パーティションや外付け NTFS ディスクをよく使う場合は、注目してよい更新だ。

さらに exFAT は複数 cluster の順次読み取りを改善しており、一部の小さな cluster のデバイスでは順次読み取りが速くなる。

メモリと swap：メモリ圧迫時の挙動を引き続き改善

Linux 7.0 は、ここ数バージョンで進んできた swap サブシステムの整理を継続している。今回の重点の一つは、swap からメモリへ読み戻す経路の改善だ。特に、複数のプロセスが同じスワップアウト済みページを共有している場合、スループットが向上する。

デスクトップユーザーにとっては、「急にシステムが速くなった」と感じる種類の変化ではないかもしれない。しかし、メモリが厳しい環境、コンテナが密集したホスト、永続化を有効にした Redis 系サービス、または zram とバックエンドディスクを組み合わせた構成では、メモリ圧迫時の揺れを減らす助けになる。

zram 関連の経路も最適化されている。以前は一部のケースで、カーネルが zram ページをいったん展開してからバックエンドデバイスへ書き込む必要があった。新しい経路では圧縮データを直接書き込めるため、不要な処理を減らせる。

CPU と性能：Intel TSX auto、スレッドとファイル操作の高速化

Linux 7.0 は Intel TSX のデフォルト方針を調整した。過去のセキュリティ問題により、多くのプロセッサでは TSX がデフォルトで無効化されていた。現在のカーネルはより細かい auto 方針を採用し、影響を受ける CPU では引き続き無効化し、影響を受けない、または有効化に適した CPU では自動的に有効化できる。

これは一部のマルチスレッドワークロード、特にトランザクショナル同期拡張に依存するアプリケーションに役立つ可能性がある。ただし、汎用的な高速化スイッチではない。実際の効果は CPU 型番とアプリケーションがその機能を使うかどうかに依存する。

また、Linux 7.0 には PID 割り当て、スレッドの作成/破棄、ファイルの open/close 経路の最適化も含まれる。これらは単独で大きく宣伝される機能ではないが、システム応答性や高並行サービスでの小さな改善として積み上がる。

ハードウェアサポート：新プラットフォームの準備と既存デバイスの改善

Linux 7.0 は大量のハードウェア有効化作業を継続している。この種の更新は、まだ広く出回っていない新プラットフォームへの準備と、すでにユーザーの手元にあるデバイスの改善に分けられる。

新プラットフォームでは、Linux 7.0 に Intel Nova Lake、Intel Crescent Island、AMD の新しいグラフィックス IP、AMD Zen 6 に関する準備がさらに含まれる。普通のユーザーにとってすぐ役立つとは限らないが、新しいハードウェアが登場した後に、より早くメインラインカーネルで対応できるかを左右する。

ARM64 とシングルボードコンピュータでは、Rockchip RK3588/RK3576 の H.264/H.265 ハードウェア動画デコードがメインラインサポートの範囲に入った。これは Orange Pi 5 や Radxa ROCK 5 などのデバイスが、ハードウェアデコード体験のためにベンダー BSP カーネルへ完全に依存しなくてよくなることを意味する。

ノートPCや周辺機器にも細かな更新が多い。

ASUS WMI は ROG、TUF 機種のバックライト、キーボードライト、ファンホットキー対応を改善。
HP WMI は一部 Victus 機種の手動ファン制御を追加し、音声インジケーターライトを修正。
Lenovo WMI は Legion デバイス向けにより多くの HWMON 監視情報を公開。
Intel Xe グラフィックスドライバはより多くの温度センサーを公開。
Intel Arc B シリーズのディスクリートGPUは、より深い PCIe 省電力状態へ入れる。
Rock Band 4 Bluetooth ギターと Logitech K980 Bluetooth キーボードのカーネルサポートが改善。

一つ一つは小さな変更だが、ノートPC、ゲームデバイス、開発ボード、周辺機器のユーザーにとっては、メインラインカーネルでの対応が進むほど、その後のディストリビューション保守が楽になる。

セキュリティと分離：io_uring で BPF フィルタリングが可能に

Linux 7.0 は io_uring に BPF フィルタリング機能を追加した。これはコンテナ、サンドボックス、高いセキュリティ要件を持つ環境で重要になる。

以前は攻撃面を減らすため、管理者が io_uring を丸ごと無効化することがあった。現在は BPF フィルタリングにより、許可する操作をより細かく制限できる。つまり、「全開」か「全停止」だけを選ぶ必要がなくなる。

これで io_uring のセキュリティリスクが自動的に消えるわけではない。しかし、システム管理者やランタイムフレームワークにとって、より制御しやすい分離手段が増える。

Rust サポートは単なる実験ラベルではなくなった

Linux 7.0 では、Rust for Linux の状態がさらに安定した。これはカーネルが大規模に Rust へ書き換えられるという意味ではなく、C が置き換えられるという意味でもない。

より正確には、カーネル内で Rust を使うための基盤が、より正式な段階に入ったということだ。今後、新しいドライバ、新しいサブシステム、または一部のセキュリティに敏感なコードでは、適した場面で Rust を選べる。これは段階的な道筋である。まずインターフェース、ビルド、ドキュメント、保守プロセスを安定させ、その後で具体的なコードを少しずつ増やしていく。

古い機能の整理：laptop_mode の削除

Linux 7.0 は laptop_mode を削除した。これは長い歴史を持つ省電力機能で、主に機械式ハードディスク時代のノートPCを対象に、ディスクのスピンアップを減らして電力を節約するものだった。

現在のノートPCは SSD が主流であり、カーネル内のメモリ回収、ブロックデバイス、ファイルシステム経路も大きく変化している。この古い仕組みを残し続けると保守コストが増え、テストカバレッジも理想的ではない。削除により、古いコードが現代的な経路へ与える影響を減らせる。

AI 関連キー：新世代のキーボード操作に向けた準備

Linux 7.0 は、コンテキスト AI 操作向けにいくつかの新しい HID keycode を追加した。たとえば、選択中の内容に対して操作を実行する、コンテキスト生成内容を挿入する、コンテキスト検索を開始するといった用途である。

これはカーネルに AI 機能が組み込まれたという意味ではない。将来のノートPCキーボードや周辺機器のために入力イベント定義を用意し、デスクトップ環境、アプリ、ベンダーツールがそれらのキーを認識できるようにするものに近い。実際に何ができるかは、ディストリビューション、デスクトップ環境、アプリケーション層の統合に依存する。

すぐにアップグレードすべきか

ローリングリリース系のディストリビューションを使っている場合、Linux 7.0 は通常のシステム更新として自然に入ってくる可能性が高い。 Ubuntu 26.04 LTS のような新しいディストリビューションでは、7.0 がデフォルトまたは主要なカーネルバージョンとして採用されることもある。

ただし、対象のマシンが本番環境、NAS、仮想化ホストである場合、またはクローズドソースドライバや独自カーネルモジュールに依存している場合は、バージョン番号が 7.0 になったという理由だけで手動アップグレードするのは勧めにくい。より安全な進め方は次の通り。

ディストリビューションが正式なカーネルパッケージを提供するのを待つ。
GPU、ネットワークカード、ZFS、VirtualBox、VMware、DKMS モジュールの互換性を確認する。
テスト機またはスナップショット環境で先に検証する。
7.0.x のポイントリリースでの修正状況を追う。

kernel.org の v7.x ディレクトリを見る限り、7.0.1、7.0.2、7.0.3 はすでに順次公開されている。手動でビルドまたはテストするなら、最初の 7.0 tarball だけを見るのではなく、最新の安定版 7.0.x を優先したほうがよい。

まとめ

Linux Kernel 7.0 は、「メジャーバージョンが上がったからすべてを書き換えた」リリースではない。むしろ、範囲の広い通常のカーネル更新に近い。ファイルシステムはより信頼性を増し、swap と I/O 経路は引き続き最適化され、新しいハードウェア対応は前進し、Rust、io_uring の分離、HID 入力定義も長期的な進化に必要な基盤を補っている。

一般的なデスクトップユーザーにとって、最も実用的な変化はハードウェアサポート、グラフィックスドライバ、省電力、ファイルシステム修復にあるかもしれない。サーバーや開発者にとっては、XFS のエラー報告、自己修復、io_uring BPF フィルタリング、swap 最適化、新プラットフォーム対応がより注目に値する。

参考ソース：

hackingtool：オールインワン security toolkit の用途、リスク、学習境界

Fri, 01 May 2026 03:45:00 +0800

hackingtool は、多数のセキュリティツールを一か所に集めた toolkit プロジェクトです。

README の説明を見ると、匿名化ツール、情報収集、脆弱性分析、Web 攻撃、無線ネットワーク、フォレンジック、payload、リバースエンジニアリング、DDoS、リモート管理、フィッシング関連ツールなど、幅広い方向を含んでいます。単一問題を解決する小さなツールというより、セキュリティツールのナビゲーターに近いものです。

この種のプロジェクトは誤解されやすいため、最初に境界を明確にします。セキュリティツールは、許可された環境、ラボ、演習環境、CTF、自分のシステムでのみ使うべきです。未承認の対象に使ってはいけません。この記事はプロジェクトの位置づけと学習ルートを整理するだけで、攻撃手順、悪用コマンド、回避方法は提供しません。

解決する問題

サイバーセキュリティを学び始めると、多くの人が「ツールが多すぎて、どこから始めればよいか分からない」という問題に直面します。

聞いたことがあるかもしれません。

情報収集ツール
Web 脆弱性スキャンツール
パスワード監査ツール
無線ネットワークテストツール
フォレンジック分析ツール
リバースエンジニアリングツール
payload 生成ツール
匿名化とプロキシツール

各カテゴリだけでも多くのプロジェクトがあります。問題は、初心者がそれぞれ何をするのか、どの場面に向いているのか、リスクがどこにあるのかを判断しにくいことです。

hackingtool の価値は、これらのツールをカテゴリごとにまとめ、学習者がまずセキュリティツールの大まかな地図を見られるようにすることです。

すべてのツールにとって最良のインストール方法とは限らず、本番環境向けとも限りません。しかし、初期理解を作るには役立ちます。サイバーセキュリティは 1 つのツールではなく、目標、方法、境界の集合です。

ツール集合の利点

この種の集合プロジェクトには明確な利点があります。

第一に、初心者の検索コストを下げます。

最初からすべてのツール名を知る必要はありません。カテゴリを通じて、セキュリティ学習にどのような方向があるかを先に把握できます。

第二に、ラボ構築に向いています。

ローカル仮想マシン、Kali、Parrot、Ubuntu の実験環境、または CTF 演習環境で学ぶ場合、toolkit は一般的なツールを素早く揃える助けになります。

第三に、同種ツールを比較しやすくなります。

同じ方向にも複数のツールがあります。情報収集、Web テスト、パスワード監査、フォレンジック分析には、それぞれ異なる実装と適した場面があります。並べて見ることで、初心者は横断的に観察できます。

第四に、セキュリティの流れを理解しやすくなります。

実際のセキュリティテストは「1 つのツールを実行して終わり」ではありません。通常は資産識別、情報収集、脆弱性検証、影響評価、修復提案、レポート整理を含みます。ツール分類は、各段階にどの能力が対応するかを理解する助けになります。

リスクも見る必要がある

ツール集合が大きいほど、リスクも真剣に見る必要があります。

第一に、ツール品質は一定ではありません。

集合プロジェクトは多くの第三者ツールを収録している場合があります。それぞれの保守状態、コード品質、依存関係の安全性、互換性、ライセンスは異なります。すべてのツールが安全で信頼できると考えてはいけません。

第二に、インストールスクリプトにはサプライチェーンリスクがあります。

セキュリティツールは高い権限、ネットワークアクセス、システム依存、外部ダウンロードを必要とすることが多いです。インストールスクリプトを実行する前に内容を読み、出所を確認し、できれば隔離環境でテストするべきです。

第三に、一部のツールには明確な攻撃的性質があります。

README には DDoS、payload、フィッシング、リモートアクセスなどの方向が含まれています。これらは許可されたラボで攻防原理を学ぶためには使えますが、実際の対象に悪用すると重大な法律上および倫理上の問題になります。

第四に、ツールは基礎知識を置き換えられません。

ツールを実行できるだけで、ネットワークプロトコル、OS 原理、Web セキュリティ、権限モデル、ログ分析を理解していないと、誤った判断をしやすくなります。ツール出力には誤検知や見逃しもあります。

どう学ぶべきか

この種のプロジェクトでセキュリティを学ぶなら、一度にすべてをインストールするのではなく、テーマごとに分けて学ぶことをおすすめします。

次の方向から始められます。

ネットワーク基礎：IP、ポート、DNS、HTTP、TLS
Linux 基礎：権限、プロセス、ファイルシステム、サービス管理
Web セキュリティ：認証、認可、入力検証、セッション、一般的な脆弱性
情報収集：資産識別と公開情報整理
脆弱性検証：ローカル演習環境または許可されたシステムのみ
フォレンジック分析：ログ、ディスク、メモリ、トラフィック証拠
防御視点：検知、強化、パッチ、レポート

この方が安定して学べます。

ツールは知識に従うべきであり、ツールに学習を引きずられるべきではありません。

向いている利用場面

hackingtool は次のような場面に向いています。

セキュリティ初心者がツール分類を理解する
CTF や演習環境用のツールを準備する
隔離ラボを構築する
異なるセキュリティ分野のツール生態を学ぶ
セキュリティテストの流れを研究する
同種ツールの用途差を比較する

向いていない場面は次のとおりです。

未承認対象をスキャンまたは攻撃する
本番マシンに大量のツールを無計画にインストールする
ツール出力をそのまま安全結論として扱う
スクリプト内容を知らずに高権限で実行する
攻撃系ツールを実ネットワーク環境で使う

一括インストールをおすすめしない理由

多くの toolkit は「一括インストール」の考え方を提供しますが、実際には慎重であるべきです。

問題は次のようなものです。

依存関係の衝突
システム環境の汚染
ダウンロード元を制御しにくい
使わないツールを大量に入れてしまう
保守と更新が難しい
各ツールが何をしたか監査しにくい

より良い方法は、学習テーマごとにインストールすることです。

今日は情報収集を学ぶなら関連ツールだけを入れます。来週 Web セキュリティを学ぶなら Web テストツールを追加します。フォレンジック実験をするなら、そのときフォレンジックツールを準備します。環境はきれいに保たれ、学習目標も明確になります。

安全に使う方法

第一に、隔離環境を使うことです。

仮想マシン、コンテナ、専用の実験マシンで使うことをおすすめします。メインの作業システムを直接汚染しない方がよいです。

第二に、許可された対象にだけ接続することです。

対象はローカル演習環境、CTF プラットフォーム、自分で立てたテストサービス、または明確に許可されたセキュリティテスト範囲に限ります。

第三に、スクリプトを読んでから実行することです。

README のコマンドをコピーしてそのまま実行しないでください。インストールスクリプト、依存元、権限要求、ネットワークアクセスを確認します。

第四に、実験過程を記録することです。

セキュリティ学習はツール実行だけではありません。入力、出力、判断根拠、誤検知の理由、修復提案を記録してこそ能力が伸びます。

第五に、防御視点を学ぶことです。

攻撃面を 1 つ学ぶたびに、対応する防御も理解するべきです。どう検知するか、どう強化するか、どう証拠を残すか、どうレポートを書くかです。

Kali Linux との違い

Kali Linux は、ペネトレーションテストとセキュリティ研究向けのディストリビューションで、多数のセキュリティツールを内蔵し、保守しています。

hackingtool はツールのインストールと分類の集合に近いものです。ツール生態を理解する助けにはなりますが、完全なセキュリティディストリビューションではなく、Kali の保守体系と同じではありません。

初心者なら、Kali、Parrot、Ubuntu 仮想マシンに演習環境を組み合わせる方が、ホストに toolkit を一括インストールするより安定しています。

すでに自分のラボ環境があるなら、hackingtool はツール索引として参考になります。

利用境界

セキュリティツールの境界は非常に重要です。

合法的な場面には次があります。

自分の実験環境
CTF と演習環境
会社が許可したセキュリティテスト
授業実験
ローカル研究と防御検証

不適切な場面には次があります。

未承認で公開インターネット上の対象をスキャンする
第三者サイトに脆弱性試行を行う
フィッシング、アカウント窃取、アクセス制御回避
サービス可用性を妨害する
許可なく他人のデータを収集または利用する

判断基準は簡単です。明確な許可がなければ、テストしないことです。

向いている人

hackingtool は学習目標を持つ人に向いています。「クリックすれば何かをハックできる」と考える人向けではありません。

向いているのは次のような人です。

サイバーセキュリティ初心者
CTF 学習者
セキュリティラボ構築者
ツール分類を理解したい人
攻防知識とツールを対応づけたい人

Linux、ネットワーク基礎、Web 基礎、権限概念にまだ慣れていないなら、まず基礎を補ってからこの種の toolkit を使う方がよいです。そうしないと、コマンドだけ覚えて結果を理解できない状態になりやすいです。

参考

Z4nzu/hackingtool

最後に

hackingtool はサイバーセキュリティツール生態への入口になり得ますが、境界なく使う攻撃ツール箱として扱うべきではありません。

本当に価値のあるセキュリティ学習とは、許可された環境で原理を理解し、リスクを検証し、防御を学び、ツール出力を説明可能で修復可能な安全結論に変えることです。

auto-editor とは何か: 無音部分を自動で削って Premiere や Resolve に渡す

Thu, 23 Apr 2026 13:31:27 +0800

動画編集で本当に時間を取られやすいのは、トランジションやカラー調整、字幕付けよりも、長い素材を最初から最後まで見て、誰も話していない部分、動きがない部分、情報量が薄い部分を手で削っていく作業だったりします。

auto-editor が解決しようとしているのは、まさにその工程です。これは一般的な GUI の編集ソフトではなく、動画や音声を解析してから、無音区間や動きの少ない区間のような「死に時間」を自動で切り落とすコマンドラインツールです。最初のラフカットをかなり速く終わらせやすくなります。

次のような素材を扱うことが多いなら、この種のツールはかなり相性がいいです。

画面収録
チュートリアル動画
ポッドキャストやトーク中心の動画
長時間の配信アーカイブ
ラフカットを先に済ませてから細かく仕上げたいインタビュー素材

いちばん重要な価値は何か

auto-editor の考え方は、ひと言で言えばこうです。

退屈な最初の 1 パスを自動化し、その結果を人間に返す。

公式 README でも強く押し出されているのは、よくある “dead space” を先に削ることです。特に代表的なのが無音です。長尺素材では、この部分がいちばん機械的で、いちばん時間を食いやすい工程になりがちです。

最も基本的な使い方はとてもシンプルです。

`1`	`auto-editor path/to/your/video.mp4`

実行後の結果は、最初のふるい分けを一度やってくれたものだと考えると分かりやすいです。最終的な演出判断を代わりにしてくれるわけではなく、明らかに情報量の少ない区間を先に取り除いてくれる、という位置づけです。

無音だけでなく、動きでも切れる

「自動編集」と聞くと、無音検出しかできないと思う人も多いです。

しかし auto-editor の判定方法は 1 つではありません。公式ドキュメントでよく出てくる代表的な方法は次の 2 つです。

audio: 音量やラウドネスを基準に判定する
motion: 画面内の動きを基準に判定する

たとえば:

`1`	`auto-editor example.mp4 --edit motion:threshold=0.02`

これが意味するのは、「誰も話していなければ切る」という素材だけに向いた道具ではないということです。内容の進行が音声ではなく画面変化に強く依存する動画にも向いています。

公式例では、複数の方法を組み合わせる使い方も示されています。音声条件と動き条件を一緒に使えば、「どこを残してどこを切るか」を単一の閾値よりも実際の要件に近づけやすくなります。

`--margin` は見た目の自然さにかなり効く

自動ラフカットが破綻しやすいのは、無音を削れないときではなく、切り方がきつすぎるときです。

話し始めの一音目が削られたり、語尾が不自然に切れたりすると、映像全体が機械的に見えてしまいます。そこで役立つのが auto-editor の --margin です。

これは、切る境界の前後に少し余白を残すための指定だと考えると分かりやすいです。公式例ではデフォルトが 0.2s で、カットの前後にわずかな余白を残すことでテンポを自然にします。

たとえば:

1
2

auto-editor example.mp4 --margin 0.2sec
auto-editor example.mp4 --margin 0.3s,1.5sec

このオプションは、出力が雑な自動切断に見えるか、人間が先にざっと整えたラフカットに見えるかを左右しやすいポイントです。

完全な NLE の代替ではなく、最初の処理に向く

auto-editor を評価するうえで、ここがいちばん重要です。

これは完全なノンリニア編集環境というより、自動ラフカット機に近い存在です。強みは次のようなところにあります。

長尺素材を素早く処理できる
空白削除のような反復作業を自動化できる
明らかに価値の低い区間を本編集前に圧縮できる

一方で、次のような作業になると、結局は従来の編集ソフトに戻ることが多いはずです。

リズムの細かい詰め
残すべき見どころの手動選別
字幕、トランジション、B-roll の追加
カラー、音の仕上げ、最終パッケージング

だから現実的な見方は、「Premiere や Resolve が不要になる」ではなく、「単純作業を先に auto-editor に任せて、その後に本格的な編集ソフトで仕上げる」です。

そのまま書き出すことも、他の編集ソフトへタイムラインを渡すこともできる

ここも実用上かなり大きい点です。

無駄な区間だけを削った版をすぐ作りたいなら、そのままメディアとしてレンダリングできます。さらに後で細かく仕上げたいなら、公式 README では一般的な編集ソフト向けのタイムライン書き出しもサポートされています。

README に載っている主な出力先は次の通りです。

Adobe Premiere Pro: --export premiere
DaVinci Resolve: --export resolve
Final Cut Pro: --export final-cut-pro
Shotcut: --export shotcut
Kdenlive: --export kdenlive
個別クリップ列: --export clip-sequence

たとえば:

`1`	`auto-editor example.mp4 --export premiere`

この設計のおかげで、auto-editor は閉じた独自環境というより、前処理ツールとして使いやすくなっています。

手動ルールも足せるので、完全自動に縛られない

自動化ツールは、一度判断を間違えると一気に扱いにくくなることがあります。

その点で auto-editor は比較的柔軟です。ある区間を必ず削る、あるいは必ず残すといった指定を明示的に入れられます。公式例でよく出てくるのは次の 2 つです。

--cut-out: 必ず削る
--add-in: 必ず残す

たとえば:

1
2

auto-editor example.mp4 --cut-out 0,30sec
auto-editor example.mp4 --add-in 0,30sec

つまり、判定をすべてプログラムに委ねる必要はありません。自動ルールで大枠を処理しつつ、手動ルールで端のズレを補正できます。

公式の推奨インストール方法は、今はバイナリ配布

公式のインストールページを見ると、現在の推奨方法は pip ではなく、GitHub Releases から配布されているバイナリです。

大まかな流れはこうです。

Releases ページから自分の環境向けバイナリをダウンロードする
auto-editor、Windows なら auto-editor.exe にリネームする
ターミナルから実行する
auto-editor --help で導入確認をする

パッケージマネージャ経由の方法として、公式ページでは次も案内されています。

macOS: brew install auto-editor
Ubuntu / Debian 系: apt
Arch 系: yay -S auto-editor

加えて覚えておきたいのは、公式ページが「新しいバージョンはもう pip に継続的には公開していない」と明記している点です。pip install auto-editor という手段自体は残っていますが、優先度は下がっています。

`yt-dlp` があれば URL を直接入力にできる

インストールページには、便利なオプション依存関係の説明もあります。yt-dlp が導入されていれば、auto-editor は URL を入力として直接受け取れます。

これは、オンライン素材を先に取得してから自動ラフカットに回すような流れでは便利です。つまりローカルファイル専用というわけではありません。

ただし実務的には、素材の出所や利用権を確認したうえで、自分の編集フローに組み込むのが前提になります。

どんな人に向いているか

強い物語性、ショット構成、細かな人間の判断が重要な編集をしているなら、auto-editor はいちばん難しい部分を肩代わりしてくれるわけではありません。

それでも、次のような作業が多いなら、実際かなり時間を削れます。

1 時間の画面収録から大量の間を削る
トーク音声から無音部分を先に落として編集ソフトへ持っていく
講座動画を先に粗く整えてから字幕を入れる
構造が似た長尺素材をまとめて処理する

価値があるのは、人よりセンスよく切れるからではありません。いちばん反復的で、いちばん退屈で、いちばん根気を削る最初の工程を自動化できるからです。

まとめ

auto-editor が面白いのは、編集を魔法のような AI ブラックボックスに変えるからではありません。かなり限定された問題を、きちんと現実的に解いているからです。つまり、最初のラフカットをどう速く終わらせるか、という一点です。

無音削除、空白削除、タイムライン書き出しのための前処理ツールとして見ると、このツールの役割はかなり明確です。

最終的な編集の美意識までは担当しない
長尺素材の 1 パス目に向いている
Premiere や Resolve の代わりではなく、そこへつなぐための補助になる

チュートリアル、画面収録、トーク中心の動画、長尺コンテンツのワークフローでは、こういうツールは派手ではなくても、地味に作業時間を削ってくれる存在になりやすいです。

rsync --delete パラメータの詳細な説明とディレクトリのクリアの実践

Sun, 29 Mar 2026 11:00:00 +0800

rsync --delete の中心的な機能は、ターゲットディレクトリ内の「ソースディレクトリが存在しない」ファイルを削除して、ターゲット側とソース側の一貫性を保つことです。

一般に、次のシナリオで使用されます。

同期中にターゲット側の過去の冗長ファイルをクリーンアップする
空のディレクトリを使用してターゲットディレクトリをすばやくクリアします

基本的な文法

`1`	`rsync -a --delete 源目录/ 目标目录/`

-a: アーカイブモード、権限やタイムスタンプなどの属性を保持します。
--delete: ターゲット上の余分なファイルを削除します

重要な注意事項: 源目录 の最後に / があるかどうかは、同期動作に影響します。 / を使用すると、ディレクトリの内容を同期することを意味し、/ を使用しない場合は、ディレクトリ自体を同期することを意味します。

ターゲットディレクトリを空のディレクトリですばやくクリアします

「ディレクトリ構造は保持するが、中身は空にする」ことが目標の場合は、空のディレクトリをソースとして同期できます。

# 1) 创建空目录
mkdir -p /tmp/empty_dir

# 2) 同步并删除目标目录中的内容
rsync -a --delete /tmp/empty_dir/ /path/to/target_dir/

通常、この方法は、大規模なディレクトリのシナリオで 1 つずつ削除するよりも効率的であり、自動スクリプトの作成も簡単です。

よく使用される拡張パラメータ

--delete-before: 最初に削除してから送信します。これは、シナリオによってはより効率的です。
--progress: 送信と処理の進行状況を表示

例 (クリーンな Nginx ログディレクトリ):

`1`	`rsync -a --delete --progress /tmp/empty_dir/ /var/log/nginx/`

使用方法の提案

--dry-runでプレビューし、削除範囲を確認してから実行します
本番環境で使用する前に、対象ディレクトリのバックアップを作成することをお勧めします。
クリティカルパスを実行する場合は、オフピーク時間帯の操作を優先する

Git がファイルの実行可能権限を追跡する方法 (+x)

Sun, 29 Mar 2026 10:00:00 +0800

Linux 環境では、Git はファイルの実行可能ビット (+x) を追跡します。スクリプトを「実行可能ファイル」としてリポジトリに保持したい場合は、この権限の変更を Git で明示的に記録する必要があります。

ファイルに実行可能権限を追加する

1
2
3

git update-index --chmod=+x script.sh
git commit -m "chore: mark script.sh as executable"
git push

このコマンドは、script.sh の実行可能ビット変更を一時記憶領域に追加します。送信してプッシュした後、他のユーザーがリポジトリをプルまたはクローン作成するときに、この権限ステータスが保持されます。

ファイルの実行可能権限を削除する

1
2
3

git update-index --chmod=-x script.sh
git commit -m "chore: remove executable bit from script.sh"
git push

効果があるかどうかを確認する

次のコマンドを使用して、ワークスペースの権限を確認できます。

1
2

git clone xxxxxxxxxxxxxxx
ls -l script.sh

-rwxr-xr-x のようなものが表示された場合は、ファイルに実行可能アクセス許可が含まれていることを意味します。 -rw-r--r-- の場合は、実行可能ではないことを意味します。

説明する

git update-index --chmod=+x/-x は、Git によって記録されたファイルモードのみを変更し、ファイルコンテンツ自体の変更を置き換えることはありません。
チームコラボレーションでは、レビューとバックトラックを容易にするために、このような権限の調整を個別に送信することをお勧めします。

Hugo ショートコードの練習: バンドルファイル (複数言語のファイルと添付ファイルは同じページバンドルディレクトリに配置されます)

Sun, 29 Mar 2026 00:00:00 +0000

多言語サイトでは、記事の本文に同じ添付ファイル (PDF、設定ファイル、スクリプトなど) が含まれることがよくあります。ダウンロードリンクが言語バージョンごとに手動で管理されている場合、後でリンクの不一致やファイルの損失が簡単に発生する可能性があります。

この記事では、この問題を解決するために、直接再利用可能な Hugo ショートコード bundle-file を提供します。

ターゲット

同じ記事の多言語ファイルと添付ファイルを同じページバンドルディレクトリに配置します。次に例を示します。

content/post/2026/03/09/01/
  index.zh-cn.md
  index.zh-tw.md
  index.en.md
  demo.pdf
  script.sh

これにより、リソースの再利用を最大限に高め、重複コピーを減らすことができます。 Hugo がそれを HTML に変換すると、コピーを繰り返すことなく、複数の言語が同じ添付ファイルをポイントできることが期待されます。

ショートコードの実装

ファイル:layouts/shortcodes/bundle-file.html

{{- $name := .Get "name" -}}
{{- $text := .Get "text" | default $name -}}

{{- $res := .Page.Resources.GetMatch $name -}}
{{- if not $res -}}
  {{- range .Page.AllTranslations -}}
    {{- if not $res -}}
      {{- $tmp := .Resources.GetMatch $name -}}
      {{- if $tmp }}{{ $res = $tmp }}{{ end -}}
    {{- end -}}
  {{- end -}}
{{- end -}}

{{- if $res -}}
<a href="{{ $res.RelPermalink }}">{{ $text }}</a>
{{- else -}}
<span>Missing file: {{ $name }}</span>
{{- end -}}

bundle-file の動作は単純です。

現在のページのリソースからのファイルの検索を優先します。
現在の言語が見つからない場合は、他の翻訳ページに移動して、同じ名前のファイルの検索を続けます。
見つかった場合はダウンロードリンクが出力されます。見つからない場合は、見つからないファイル名を入力するよう求められます。

パラメータの説明

name: 添付ファイル名、必須。
text: リンク表示テキスト、オプション。送信されない場合は、デフォルトで name が表示されます。

使用例

`1`	`Missing file: demo.pdf`

text が渡されない場合:

`1`	`Missing file: demo.pdf`

公開前に確認してください

添付ファイルは記事と同じページバンドル内にあります。
name は実際のファイル名とまったく同じです (大文字と小文字を含む)。
リンクをクリックしてローカルでプレビューし、アクセスできることを確認します。

要約する

bundle-file は、多言語記事の添付リンク管理を「パスの手動管理」から「ルールに従った自動検索」に変更します。ナレッジベースや技術ブログの長期メンテナンスの場合、これによりリンクエラー率が大幅に削減され、リリース前のトラブルシューティングのコストが削減されます。

スキルの作成方法と使用方法: SKILL.md の仕様と実践原理

Sat, 28 Mar 2026 16:30:00 +0800

この記事では、次の 2 つの問題に焦点を当てます。

SKILL.mdの書き方と構造の設計方法。
高品質で保守可能、再利用可能なスキルを作成する方法。

1. SKILL.md仕様の詳細説明

SKILL.md は、スキルのコア記述ファイルです。通常、次の 2 つの部分で構成されます。

YAML Frontmatter: スキルのメタ情報を定義します。
マークダウンテキスト: 実行命令と実践的なメソッドを定義します。

1.1 前付の例

---
# === 必需字段 ===
name: skill-name
# 技能的唯一标识符，建议使用 kebab-case 命名

description: >
  简洁但精确地说明：
  1) 这个技能做什么
  2) 什么时候应该使用它
  3) 核心价值是什么
# 注意：description 通常是智能体选择技能的关键依据，必须写清楚

# === 可选字段 ===
version: 1.0.0
allowed_tools: [tool1, tool2]
required_context: [context_item1]
license: MIT
author: Your Name <email@example.com>
tags: [database, analysis, sql]
---

1.2 推奨されるテキストの構成

# 技能标题

## 概述
（技能介绍、适用场景、技术背景）

## 前置条件
（运行环境、依赖项、权限要求）

## 工作流程
（分步骤说明：输入、处理、输出）

## 最佳实践
（经验总结、注意事项、常见陷阱）

## 示例
（典型任务示例，便于快速上手）

## 故障排查
（常见问题与解决方案）

2. 高品質のスキルを書くための原則

公式文書とコミュニティの実践を組み合わせて、次の 4 つの原則に従うことが推奨されます。

2.1 説明は正確でなければなりません

description は、スキルマッチングへの重要な入り口です。次のことを行うことをお勧めします。

適用範囲を明確にし、「データの処理を支援する」などの一般的な説明は避けてください。
ユーザーの意図の一致を容易にするトリガーキーワードが含まれています。
独自の価値を説明し、他のスキルとの境界線を形成します。

悪い例:

`1`	`description: 处理数据库查询`

推奨される例:

description: >
  将中文业务问题转换为 SQL 查询，并分析 MySQL employees 示例数据库。
  适用于员工信息查询、薪资统计、部门分析、职位变动历史等场景。
  当用户询问员工、薪资、部门相关数据时使用此技能。

2.2 モジュール性と単一責任

スキルは明確なタスク領域に焦点を当てる必要があります。スキルがあまりにも多くの機能をカバーしようとすると、通常は次のような結果になります。

記述範囲が広くなり、マッチング精度が低下します。
命令が長くなり、コンテキストの負荷が増加します。
メンテナンスと反復コストが増加します。

「一般的なスキル」を次のような複数の特殊なスキルに分割することをお勧めします。

mysql-employees-analysis
sales-data-analysis
user-behavior-analysis

2.3 確実性を優先する

複雑で正確なタスクの場合は、LLM テキスト生成のみに依存せず、「スクリプトの実行」を優先してください。

たとえば、データエクスポートのシナリオでは、LLM に Excel バイナリコンテンツを直接生成させるのではなく、専用のスクリプトを使用して処理する方が良いでしょう。 SKILL.md はトリガー条件と呼び出し方法を記述するだけです。

2.4 段階的な開示

非効率なコンテキストを避けるために、重要性と頻度によって情報を階層化します。

SKILL.md 本体: コアワークフローとコモンモード
追加ドキュメント (advanced.md など): 高度な使用法とエッジシナリオ
データファイル: 大規模な参照データ、スクリプト経由でオンデマンドで読み取る

要約する

高品質のスキルの目標は、「より多く書く」ことではなく、「明確な境界、正確なトリガー、安定した実行、持続可能なメンテナンス」を持つことです。

標準化された SKILL.md から始めて、単一の責任と段階的な開示を組み合わせることで、より効率的なスキルセットを構築できます。

IEEE 802.3af/at/bt（PoE）の違いを詳しく解説

Sat, 28 Mar 2026 00:00:00 +0000

IEEE 802.3af、802.3at、および 802.3bt は、PoE (Power over Ethernet) の 3 つの主流規格です。それらの主な違いは、供給される電力、使用されるワイヤペアの数、および適切な機器のタイプです。

簡単な結論

802.3af (PoE): 最大電源電力は低く (15.4 W)、基本的な機器に適しています。
802.3at (PoE+): 電力が 30 W に増加し、中電力消費デバイスに適しています。
802.3bt (PoE++ / 4PPoE): 最高電力 (タイプ 3 は 60W、タイプ 4 は 90W ～ 100W)、高電力消費デバイスに適しています。

詳細な比較

标准	常见名称	PSE 最大输出功率	PD 可用功率（约）	供电线对	典型场景
IEEE 802.3af	PoE	15.4W	12.95W	2 对	普通 VoIP 电话、基础摄像机
IEEE 802.3at	PoE+	30W	25.5W	2 对	高清 IP 摄像机、高级网络终端
IEEE 802.3bt	PoE++ / 4PPoE	Type 3: 60W；Type 4: 90W-100W	更高（随类型提升）	4 对	Wi-Fi 6/6E AP、视频会议终端、楼宇自动化设备

各規格の説明

IEEE 802.3af（PoE）

最大出力電力: 15.4W (受電装置側で約 12.95W)
ケーブルペアの使用: 4 ペアのネットワークケーブルのうち 2 ペア
該当するシナリオ: 古いカメラ、通常の VoIP 電話

IEEE 802.3at（PoE+）

最大出力電力: 30W (受電装置側で約 25.5W)
ケーブルペアの使用: 4 ペアのネットワークケーブルのうち 2 ペア
該当するシナリオ: HD IP カメラ、HD ネットワーク監視

IEEE 802.3bt（PoE++ / 4PPoE）

最大出力電力: タイプ 3 最大 60 W、タイプ 4 最大 90 W ～ 100 W
ワイヤペアの使用: 4 ペアのワイヤすべてを電源に使用し、より強力な電源供給能力を実現します。
該当するシナリオ: 高出力ワイヤレス AP、ビルディングオートメーション、ビデオ会議システム

互換性に関する注意事項

3 つの標準には下位互換性があります。

802.3bt は、802.3at および 802.3af と互換性があります。
802.3at は 802.3af と互換性があります

規格の高度化により電源供給能力が大幅に向上し、より多くの高消費電力の端末機器をカバーできるようになりました。

エージェントスキルとは: 設計コンセプトから状況に応じた最適化まで

Sat, 28 Mar 2026 00:00:00 +0000

エージェントスキルは、手順的な知識を標準化してカプセル化する方法です。つまり、解決するのは「ツールがあるかないか」ではなく、「ツールを正しく上手に使う方法」なのです。

1. 核となる設計コンセプト

エージェントスキルの中核となる価値は、「方法論」の蓄積にあります。

特定のシナリオでツールを組み合わせて呼び出す方法をエージェントにガイドするためのドメイン知識を提供します。
実行パスを制限し、試行錯誤のコストを削減し、タスク完了の一貫性を向上させます。
複雑なプロセスを再利用可能かつ反復可能にし、徐々に安定した SOP を形成します。

ツールの機能を「ハードウェアインターフェイス」に例えると、スキルは「やり方」を定義する「操作説明書」や「ベストプラクティス集」に似ています。

2. 進歩的開示: 状況のジレンマを解決する

エージェントスキルの中核となる革新は、プログレッシブディスクロージャです。つまり、コンテキストウィンドウに一度に大量のコンテンツが詰め込まれないように、オンデマンドで情報をロードします。

2.1 最初の層: メタデータ

通常、各スキルは別のフォルダーにあり、コアファイルは SKILL.md です。ファイルは、スキルの基本情報を定義する YAML Frontmatter で始まります。

エージェントが起動すると、すべてのスキルのフロントマターのみが読み取られ、システムプロンプトワードが挿入されます。実際の経験に基づいて:

1 つのスキルメタデータは約 100 tokens を消費します
50 スキルのコストは約 5,000 tokens

2.2 第 2 レベル: スキル本体 (指示)

スキルが現在のタスクとの関連性が高いと判断された場合、エージェントは完全な SKILL.md を読み取り、詳細な手順、注意事項、例をロードします。

トークン消費のこの部分は通常、スキルの複雑さに関連しており、一般的な範囲は次のとおりです。

1,000 ～ 5,000 tokens

2.3 3 番目の層: 追加リソース (スクリプトとリファレンス)

複雑なスキルは、SKILL.md のスクリプト、構成、参照ドキュメントを参照し、必要な場合にのみそれらをロードできます。

ディレクトリ構造の例:

skills/pdf-processing/
├── SKILL.md                 # 主技能文件
├── parse_pdf.py             # PDF 解析脚本
├── forms.md                 # 表单填写指南（仅在填表任务时加载）
└── templates/
    ├── invoice.pdf
    └── report.pdf

一般的な呼び出し方法:

PDFを解析する必要がある場合は、parse_pdf.pyを実行してください。
フォーム入力タスクが発生した場合は、forms.md を再度ロードします。
テンプレートファイルは、ドキュメントを特定の形式で出力する場合にのみアクセスされます

3. この設計が機能する理由

3.1 スケーラブルな知識能力

「スクリプト + 外部ファイル」を使用すると、スキルによってコンテキストウィンドウの容量をはるかに超える知識を得ることができます。たとえば、データ分析スキルには 1GB データファイルとクエリスクリプトが付属しており、エージェントはデータセット全体をコンテキストに直接接続するのではなく、スクリプトを実行することによってデータにアクセスします。

3.2 より強い確実性

複雑な計算、データ変換、および形式解析をコード実行に処理することで、プレーンテキスト生成における LLM の不確実性と幻覚リスクを大幅に軽減できます。

4. 実際の効果: 16,000 から 500 トークンまで

コミュニティの実践では、段階的な開示により、初期コンテキストのオーバーヘッドが大幅に削減できることが示されています。

従来の MCP 方式: 多数のツール定義を含む MCP サービスに直接接続し、16,000 tokens について初期化します。
スキルのパッケージ化後: 最初に軽量スキルを「ゲートウェイ」として使用し、Frontmatter を通じてのみ機能を記述し、500 tokens について初期化します。

タスクが本当に必要な場合は、詳細な手順と追加のリソースがオンデマンドでロードされます。これにより、初期コストが削減されるだけでなく、会話中のコンテキスト管理がより正確になります。

要約する

エージェントスキルの重要な意義は、「利用可能なツール」を「再利用可能な機能」にアップグレードすることです。段階的な開示を通じて、システムは機能の深さを維持しながら、トークンのコストと実行の安定性を大幅に最適化できます。

Western Digital HC620 シングルディスクの誤解と正しい使い方

Fri, 27 Mar 2026 00:00:00 +0000

はじめに: ストレージコストの高騰に伴う新しいオプション

現在のストレージ市場は、前例のない価格の嵐に見舞われています。一般消費者や家庭用 NAS ユーザーのストレージコストは急増しています。かつては 1,000 元未満で入手できた大容量の機械式ハードドライブは、現在では 2 倍以上の価格になっており、予算が限られている多くのユーザーは利用できません。しかし、このような市場背景の中でHC620は価格があまり上がらない数少ない製品となっております。この記事は HC620 だけでなく、他の同様の SMR シングルパン製品にも当てはまります。

HC620 に関するよくある誤解

多くの人は、HC620 のデータストレージが安全か安全でないかと考えています。これは典型的な誤解です。 HC620はエンタープライズレベルのディスクであり、ディスク本体の品質は悪くありません。不安の錯覚は、SMR シングルディスクや、SMR ディスクの不適切な配置と使用によって生じます。 SMR ディスクは、データの書き込みと削除が頻繁に行われる場所では使用しないでください。原則として、これによりデータ転送、パフォーマンスの低下、さらにはフリーズが発生します。しかし実際には、これは不適切な使用シナリオによって引き起こされます。エンタープライズストレージテープドライブと同様に、シーケンシャル書き込みのみに使用される場合は、シーケンシャル読み取りに問題はありません。 HC620 は、シーケンシャル書き込みおよびランダム読み取りシナリオにも適しています。同時削除と書き込みシナリオには適用されません。このようなシナリオでは、HC620 が非常にうまく機能します。

HC620 の使用シナリオ

具体的には、次のシナリオに適用されます。

大容量コールドデータストレージバックアップ（データバックアップ・アーカイブ後のコールドストレージ）
映画やテレビのデータベースなどは、一度書き込めば、オンラインで検索して読むことができます。 (データを読み取る際にシーケンシャルリードの必要はありません。データ自体に対する磁気ヘッドの位置はランダムです)

不適切なシナリオ:

頻繁な読み取りと書き込みが必要なアプリケーション (データベース、ダウンロード、ワークスペースは適していません)
Windows、Mac、その他のオペレーティングシステムはサポートしません (ネットワークアクセスを除く)

HC620の使用要件

HC620 の最大の問題は、特に初心者にとって不便で使いにくいことです。

ハードウェア要件

USBハードディスクエンクロージャ接続は使用できません。
通常のコンピュータのマザーボードの SATA インターフェイス接続は通常問題ありませんが、さまざまな拡張カードの場合はそうとも言えません。さまざまな問題が発生する可能性があります。 LSI 9300 以降の sas3008 カードは、パススルーカードのファームウェアを更新した後にサポートされるようになります。 JMB585チップは対応していますが、対応していない例もあります。状況はさらに複雑です。
M2からSATA、私のM2からJMB585は使用できますが、BIOSまたはファームウェアに関連している可能性がある互換性のない例がたくさんありました。

ソフトウェア要件

Windows、Mac はサポートしません、Linux はサポートします
フェイニウナスのサポート

要約する

初心者にとって、最も簡単な使用方法とシナリオは、Feiniu NAS を使用し、HC620 を外部ストレージとしてマウントすることです。ディスク全体がデータのバックアップまたはムービーライブラリとして使用されます。

NAS スペースがいっぱいのユーザーは、使用頻度の低いデータを HC620 ディスクに移動して、NAS 用のスペースを確保することもできます。

一般の人がAIに仕事をさせる方法：写真から図形や数式を抽出する（実践例）

Thu, 26 Mar 2026 00:00:00 +0000

前提条件

VS Code をインストールし、Codex プラグインをインストールします。 VS Code Codexの使い方についてはこちらの記事をご覧ください。
これらのツールを使用するためにプログラミングの経験は必要ありません。 VS Code はここでは主にファイルを整理するために使用されます。要件を提示するだけで、AI が自動的にプログラムを作成して実行します。
この記事では、完全な操作プロセスを記録します。その目的は、AI のより実用的な方法を模索し、より多くの一般の人々に利益をもたらすことです。

ミッションの目的

数式と回路図の両方を含む画像を準備します。

私たちは次の 3 つのことを達成したいと考えています。

グラフをきれいな小さな画像に切り取ります。
数式を特定し、後で簡単に修正できるように LaTeX に変換します。
グラフを対応する数式に関連付けます。

プロセス

まず画像を特定し、Markdown ドキュメントを生成し、数式を LaTeX に変換します。

変換結果:

# 1.png 识别结果

## 几何公式（LaTeX）

1. 三角形面积（边长与外接圆半径）：

$$
S = \frac{abc}{4R}
$$

2. 三角形面积（内切圆半径与半周长）：

$$
S = pr
$$

3. 圆台体积：

$$
V = \frac{\pi\left(r^2 + Rr + R^2\right)h}{3}
$$

4. 圆台侧面积：

$$
S = \pi a(R + r)
$$

5. 圆柱体积：

$$
V = \pi r^2 h
$$

6. 圆柱侧面积：

$$
S = 2\pi rh
$$

7. 球体积：

$$
V = \frac{4}{3}\pi R^3
$$

8. 球表面积：

$$
S = 4\pi R^2
$$

9. 正弦定理：

$$
\frac{a}{\sin A}=\frac{b}{\sin B}=\frac{c}{\sin C}=2R
$$

10. 余弦定理：

$$
a^2=b^2+c^2-2bc\cos A
$$

$$
b^2=a^2+c^2-2ac\cos B
$$

$$
c^2=a^2+b^2-2ab\cos C
$$

数式は認識され、AI が自動的に数式の名前を追加しました。これは非常にうまく機能します。ただし、小さな画像のトリミングはまだ完了していません。

AI に画像をトリミングさせてみる

# 1.png 识别结果（图文并排，精修裁图）

<table>
  <tr>
    <td>![](crops/01_triangle_circum.png)</td>
    <td>

$$
S = \frac{abc}{4R}
$$

</td>
  </tr>
  <tr>
    <td>![](crops/02_triangle_incircle.png)</td>
    <td>

$$
S = pr
$$

</td>
  </tr>
  <tr>
    <td>![](crops/03_frustum.png)</td>
    <td>

$$
V = \frac{\pi\left(r^2 + Rr + R^2\right)h}{3}
$$

$$
S = \pi a(R + r)
$$

</td>
  </tr>
  <tr>
    <td>![](crops/04_cylinder.png)</td>
    <td>

$$
V = \pi r^2 h
$$

$$
S = 2\pi rh
$$

</td>
  </tr>
  <tr>
    <td>![](crops/05_sphere.png)</td>
    <td>

$$
V = \frac{4}{3}\pi R^3
$$

$$
S = 4\pi R^2
$$

</td>
  </tr>
  <tr>
    <td>![](crops/06_laws.png)</td>
    <td>

$$
\frac{a}{\sin A}=\frac{b}{\sin B}=\frac{c}{\sin C}=2R
$$

$$
a^2=b^2+c^2-2bc\cos A
$$

$$
b^2=a^2+c^2-2ac\cos B
$$

$$
c^2=a^2+b^2-2ab\cos C
$$

</td>
  </tr>
</table>

結果：画像はトリミングされ、対応する位置に配置されていますが、干渉領域がまだあり、トリミングされたエッジは十分にきれいではありません。

「過剰トリミング」問題を修正します。まず完全なグラフィックスを保持してから、余分な部分を手動で削除します。
このステップの効果はまだ安定していません。それがプロンプトの言葉の問題なのか、それともモデルの視覚的な位置の変動なのかはまだわかりません。

要約する

Codex を使用する場合と、chatgpt.com で直接話す場合では、エクスペリエンスが大きく異なります。
chatgpt.com では、AI が作業を完了するようにガイドするようなものです。 Codex では、AI が要件に従って作業を実行するようなものです。
リクエストを行うと、AIがプログラムを生成し、実行してタスクを完了します。「AIに仕事を指示している」ということがより明確に感じられるでしょう。
プロセス全体で高度なプログラミングの基礎は必要なく、一般の人でも徐々に始めて結果を出すことができます。

VS CodeでCodexを使う方法（インストールから効率的な実践まで）

Fri, 20 Mar 2026 00:00:00 +0000

Codex は、コードの作成、バグの修正、プロジェクトの説明、VS Code サイドバーでのコマンドの直接実行に役立ちます。

1. 準備

始める前に、次のことを確認してください。

VS Code は新しい安定バージョンに更新されました。
OpenAi Web サイトには通常どおりアクセスできます
プロジェクトコードはローカルで開かれています (Git リポジトリが推奨されます)。

2. 拡張機能をインストールする

VS Code 拡張機能マーケット (Extensions) をオープンします。
Codex - Codex - OpenAI's coding agent を検索してインストールします。
インストールが完了したら、プロンプトに従ってログイン認証を完了します。

3.コーデックスのサイドバーを開きます

任意の方法で開くことができます。

エディターの右上隅にある Open Codex Sidebar をクリックします。
コマンドパネル (Ctrl + Shift + P) を使用して、Codex を検索して開きます。

Codex を開いた後、現在のワークスペースコンテキストを読み取り、会話状態に入ります。

4. 一般的な使用方法

4.1 コードを解釈させる

プロンプトの単語の例:

`1`	`请解释这个文件的核心逻辑，并指出最可能出错的 3 个地方。`

古いプロジェクトを引き継ぐ場合に、グローバルな理解を迅速に確立するのに適しています。

4.2 機能させる

プロンプトの単語の例:

1
2

在现有 API 里新增一个 /healthz 健康检查接口，
要求返回版本号和数据库连接状态，并补上基础测试。

生成される結果がより安定するように、「入力制約」と「受け入れ基準」を一緒に明確に記述することをお勧めします。

4.3 問題を解決してもらう

プロンプトの単語の例:

1
2

这个接口在并发下偶发 500，请先定位根因，再给出最小改动修复方案，
最后列出回归测试点。

最初に「位置を特定」してから「修復」することで、誤った修正や過度の再構築を減らすことができます。

5. 高品質のプロンプト Word テンプレート

次の構造を直接再利用できます。

背景：这是一个 <技术栈> 项目，当前目标是 <目标>
约束：不改动 <模块/接口>，兼容 <版本/平台>
输出：
1) 修改文件列表
2) 关键代码说明
3) 验证步骤
4) 风险与回滚方案

このテンプレートは、「複数人でのコラボレーション + 大規模プロジェクト」に非常に役立ちます。

6. よくある質問

6.1 無料割り当てについて

ダイアログボックスに「\」と入力し、ステータスを選択します。クォータ、リセット時間などの関連情報が表示されます。

6.2 変更が期待どおりにならない

変更が完了したら、「レビュー」ボタンをチェックして変更の詳細を表示します。満足できない場合は、「元に戻す」ボタンを選択して変更を元に戻します。次のステップでは、要件を複数のステップに分割して個別に実行できます。 git などのコード管理ツールを使用して、小さなステップでコミットを維持し、ロールバックを容易にします。

AI ラージモデル (LLM) API リソースインベントリ (無料でコスト効率が高い)

Thu, 12 Feb 2026 00:00:00 +0000

Google Gemini API (最強のフリーランチ)

Gemini シリーズを促進するために、Google は現在市場で最も寛大な無料割り当てを提供しています。
モデルと価格については、https://ai.google.dev/gemini-api/docs/pricing?hl=zh-cn を参照してください。

モデル: Gemini 3 Flash プレビュー、Gemini 2.5 Pro。 2026-02-12対応モデルです。一般に、無料ではない最新の Pro モデルを除き、他のモデルには無料の割り当てがあります。
クォータ: モデルによって制限は異なります。詳細については、上記のリンクを参照してください。
利点: 無料の低レベルモデルのみを備えた他の Web サイトとは異なり、Google のトップモデルには無料の割り当て、巨大なコンテキストウィンドウ (100 万以上のトークン)、およびマルチモダリティ (写真/ビデオのアップロード) の完全なサポートもあります。
欠点:
データプライバシー: 無料利用枠からの入力データは、モデルを改善するために Google によって使用される場合があります (運用環境では注意して使用してください)。
IP 制限: 非常に厳格です。サポートされているリージョンで IP ノードを使用する必要があります。使用しないと、エラー 403 またはユーザーの場所がサポートされていないことが報告されます。

Groq (キング・オブ・スピード)

Groq は自社開発の LPU (Language Processing Unit) チップを利用して、驚くほど速い推論速度を提供します。
モデルと価格については、https://groq.com/pricing を参照してください。

モデル: GPT OSS / キミ K2 / ラマ 3,4 / Qwen3
割り当て: 無料ではありませんが、価格は低くなります
利点: 非常に高速で、最初の単語の遅延 (TTFT) は通常 200 ミリ秒以内で、リアルタイムの会話や音声アシスタントに非常に適しています。
欠点:
モデルの制限: オープンソースモデルのみがサポートされ、GPT-4 や Claude はサポートされません。

SiliconCloud（国産光・シリコン系モバイル）

中国の新興推論加速プラットフォームには、多数の優れた国内オープンソースモデルが集まっています。
モデルと価格については、https://siliconflow.cn/pricing を参照してください。

モデル: Qwen 2.5 (7B/14B/72B)、DeepSeek-V2、Yi-1.5、Kimi K2。
割り当て: 現在、一部のモデル (Qwen 7B、GLM-4-9B など) に対して永久無料通話が提供されています。
アドバンテージ：
国内直結：高速で特別なネットワーク環境は不要。
新しいモデル: 国内のオープンソースモデルは非常に迅速に更新されます。
短所: 無料は中小規模のパラメータモデルに限定されており、上位モデル (72B/DeepSeek 236B など) は通常支払いが必要です。

JD Cloud Wireless Bao ax6600 Athena の 2.5G ネットワークポートを Openwrt の Lan に変更し、WAN と Lan1 を交換する方法

Mon, 19 Jan 2026 00:00:00 +0000

導入

Dongyun Wireless Treasure ax6600 Athena には 2.5G ネットワークポートがあり、Openwrt の lede および libwrt バージョンで Wan ポートとして使用されます。多くの場合、この 2.5G ポートはイントラネット上に配置され、イントラネットサーバー、NAS、およびその他のネットワークデバイスの接続に使用され、より大きな価値を提供できます。 2.5Gネットワークポートを社内LANに変更する方法です。

方法

Openwrt 管理インターフェイスでは、このネットワークポートの WAN および LAN 設定を調整する方法はありません。これは、dts ファイルを変更することで実現できます。

LAN1ポートとWANポートを交換しました

修改前
	switch_lan_bmp = <(ESS_PORT1 | ESS_PORT2 | ESS_PORT3 | ESS_PORT4)>;
	switch_wan_bmp = <ESS_PORT5>;
  ...
  &dp1 {
	status = "okay";
	phy-handle = <&qca8075_24>;
	label = "lan1";
  };
  ...
  &dp5 {
    status = "okay";
    phy-handle = <&qca8081>;
    label = "wan";
  };

修改后
	switch_lan_bmp = <(ESS_PORT5 | ESS_PORT2 | ESS_PORT3 | ESS_PORT4)>;
	switch_wan_bmp = <ESS_PORT1>;
  ...
  &dp1 {
    status = "okay";
    phy-handle = <&qca8075_24>;
    label = "wan";
  };
  ...
  &dp5 {
    status = "okay";
    phy-handle = <&qca8081>;
    label = "lan1";
  };

変更前と変更後のファイルをダウンロードする

libwrtのdtsファイル：
変更前のipq6010-re-cs-02.dts
変更された ipq6010-re-cs-02.dts

lede の dts ファイル:
修正前のipq6010-re-cs-02.dts
変更された ipq6010-re-cs-02.dts

C言語で構造体を初期化するいくつかの方法

Fri, 13 Jun 2025 00:00:00 +0000

定義時に割り当てます

struct InitMember
{
    int first；
    double second；
    char* third；
    float four;
};

struct InitMember test = {-10,3.141590，"method one"，0.25}；

対応する順序を間違えないよう注意する必要があります。

定義後に値を一つずつ代入する

struct InitMember
{
    int first；
    double second；
    char* third；
    float four;
};

struct InitMember test；

test.first = -10;
test.second = 3.141590;
test.third = "method two";
test.four = 0.25;

割り当ては一つずつ決まっていくので、順番は関係ありません。

定義時のアウトオブオーダー代入 (C スタイル)

この方法は、第 1 の方法と第 2 の方法を組み合わせたものに似ています。初期化中に値を割り当てることも、順序を考慮しないこともできます。

struct InitMember
{
    int first；
    double second；
    char* third；
    float four;
};

struct InitMember test = {
    .second = 3.141590,
    .third = "method three",
    .first = -10,
    .four = 0.25
};

この方法はよく使われており、非常に良い方法です。

定義時の順序外の代入 (C++ スタイル)

この方法は、インターネット上で C++ スタイルと呼ばれる、前の方法に似ています。これはキーと値のペアの方法に似ており、順序も考慮されません。

struct InitMember
{
    int first；
    double second；
    char* third；
    float four;
};

struct InitMember test = {
    second：3.141590,
    third："method three",
    first：-10,
    four：0.25
};

GNU C attribute メカニズム

Fri, 13 Jun 2025 00:00:00 +0000

attribute の構文形式

attribute ((attribute-list))

属性の前後には 2 つのアンダースコアが続き、その後に 2 組のメタ括弧が続きます。 attribute-list は、属性のカンマ区切りのリストです。 attribute ((attribute-list)) は「;」の前に配置されます。宣言の最後に。

共通のプロパティ

packed

コンパイラがコンパイル中に構造体のバイト最適化アライメントをキャンセルし、実際に占有されているバイト数に応じてアライメントします。

Pack は変数が占めるメモリ空間を圧縮できます。
パックは構造体またはクラス定義に基づいて動作します。
Pack の機能は、構造体またはクラス内のメンバー変数の配置規則を変更することです。
特定の構造体のデフォルトのパックが n で、パックで指定された整列規則 m が n より大きい場合、そのパックは無視されます。
ルールを指定する場合、パックは 2 の n 乗である必要があります。

たとえば、ソースコードで 2 つの構造が定義されているとします。

struct unpacked_str
{
  uint8_t x;
  uint16_t y;
};

struct packed_str
{
  uint8_t x;
  uint16_t y;
}__attribute__ ((packed));

struct unpacked_str strupkd;
struct packed_str strpkd;

int main(void)
{
  printf("%d", sizeof(strupkd));
  printf("%d", sizeof(strpkd));
}

Clang を使用してコンパイルすると、実行時の出力はそれぞれ 4 と 3 になります。

aligned

変数または構造体メンバーの最小アライメント形式をバイト単位で指定します。変数を何バイト配置するかをユーザーが決定できるようにします。

aligned既可以作用于结构体或类的定义，也可以作用于变量的声明。
aligned只是建议编译器对指定变量或指定类型的变量分配内存时的规则。
若某一个结构体的默认pack为n，若aligned指定的对齐规则s大于n,则此时结构体的大小一定为s的整数倍。
aligned指定规则时都必须为2的n次幂。

aligned が変数に作用する場合、その機能は、変数にメモリを割り当てるときに、その変数に指定されたメモリに割り当てる必要があることをコンパイラに指示することです。変数を操作しても、変数のサイズは変わりません。

32 ビット変数はコードで定義されています。

`1`	`uint32_t var_in_8bytes __attribute__((aligned(8)));`

変数 var_in_8bytes のメモリ開始アドレスは 8 の倍数です。

aligned が型に作用する場合、その役割は、その型で宣言されたすべての変数が指定されたアライメントでメモリに割り当てられる必要があることをコンパイラに伝えることです。この属性が構造体の宣言に適用されると、構造体のサイズが変更される可能性があります。

struct Test{
  char a[3];
} __attribute__((aligned(8)));

int main() {
  //8
  std::cout << sizeof(Test);
}

上に示したように、align が構造定義に適用されると、構造のサイズが変更されます。構造体の最終的なサイズは、aligned で指定されたサイズの整数倍になります。

section

セクションは、コンパイル時に変数または関数のセクション名を制御します。組み込みソフトウェア開発で広く使用されています。たとえば、外部フラッシュまたは RAM がある場合、変数または関数を外部ストレージ領域に配置する必要があります。リンクスクリプトにセグメント名を指定して動作させることができます。 MPUを使用してMCUをプログラミングする場合（メモリ保護）、メモリを領域に分割し、対応する領域に変数やコードを配置する必要があります。これは通常、セグメント操作によって実現されます。

1
2

const int identifier[3] __attribute__ ((section ("ident"))) = { 1,2,3 };
void myfunction (void) __attribute__ ((section ("ext_function")))

上記のコードをコンパイルすると、配列と関数が配置されるセクションはそれぞれ「indent」と「ext_function」になります。

unused

これは、関数または変数が使用されない可能性が高く、コンパイラーはこの関数に対して警告を生成しないことを意味します。これは、関数の実装で使用されないパラメーターで宣言できます。次に例を示します。

`1`	`int main(int argc __attribute__((unused)), char **argv)`

used

この属性は、静的ストレージを持つ変数に付加されます。つまり、参照されていないように見える場合でも変数を保持する必要があります。それ以外の場合、リンク時にリンカは変数が参照されていないことを検出し、変数を最適化します。

weak

2 つ以上のグローバルシンボルが同じ名前であり、そのうちの 1 つが弱いシンボルとして宣言されている場合、これらのグローバルシンボルは再定義エラーを引き起こしません。通常のシンボルが存在する場合、リンカは弱いシンボルを無視します。通常のシンボルが存在しない場合は、弱いシンボルが使用されます。オーバーロードやコールバックなどの関数を実装できます。

Ubuntuのpyocdが一部の自作DAPLinkを認識できない問題を解決

Thu, 17 Apr 2025 00:00:00 +0000

DAPLink ハードウェアとファームウェア

https://oshwhub.com/xivn1987/daplink のハードウェア
ファームウェアはhttps://github.com/XIVN1987/DAPLink/tree/masterから来ています

他の非公式ファームウェアでも同様の問題が発生するはずです

現象の説明を認識できません

$ pyocd list
  #   Probe/Board               Unique ID    Target  
-----------------------------------------------------
  0   Segger J-Link (unknown)   4294967295   n/a

pyocd は正常にインストールされており、他の Jlink デバッガーは正常に認識できます。

1
2

$ pyocd list
No available debug probes are connected

しかし自作DAPLinkが認識できない

同時にこのDAPLinkもKeilでは普通に使われています。

処理

USB デバイスが存在するかどうかを確認する

$ lsusb
Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 002: ID 0e0f:0003 VMware, Inc. Virtual Mouse
Bus 001 Device 003: ID 0e0f:0002 VMware, Inc. Virtual USB Hub
Bus 001 Device 007: ID 2e3c:5021 XIVN1987 XV-Link CMSIS-DAP
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

デバイスが正しく識別されていることがわかります XIVN1987 XV-Link CMSIS-DAP

Udev ルールを追加する https://github.com/pyocd/pyOCD/tree/main/udevを処理するこのURLを参照してください

カタログダウンロード

$ git clone https://github.com/pyocd/pyOCD.git
Cloning into 'pyOCD'...
remote: Enumerating objects: 18824, done.
remote: Counting objects: 100% (507/507), done.
remote: Compressing objects: 100% (166/166), done.
remote: Total 18824 (delta 416), reused 341 (delta 341), pack-reused 18317 (from 3)
Receiving objects: 100% (18824/18824), 29.53 MiB | 9.65 MiB/s, done.
Resolving deltas: 100% (13713/13713), done.

udev ルールの場所。公式ファームウェアのDAPLinkは上記ファイルを直接利用できます。

cd pyOCD/udev/

$ ll
total 40
drwxrwxr-x  2 knightli knightli 4096 Apr 17 21:26 ./
drwxrwxr-x 11 knightli knightli 4096 Apr 17 21:26 ../
-rwxrwxr-x  1 knightli knightli  540 Apr 17 21:26 49-stlinkv2-1.rules*
-rwxrwxr-x  1 knightli knightli  450 Apr 17 21:26 49-stlinkv2.rules*
-rwxrwxr-x  1 knightli knightli 1007 Apr 17 21:26 49-stlinkv3.rules*
-rw-rw-r--  1 knightli knightli   89 Apr 17 21:26 49-vtlinkii.rules
-rw-rw-r--  1 knightli knightli  699 Apr 17 21:26 49-wch-link.rules
-rw-rw-r--  1 knightli knightli 2836 Apr 17 21:26 50-cmsis-dap.rules
-rw-rw-r--  1 knightli knightli  445 Apr 17 21:26 50-picoprobe.rules
-rwxrwxr-x  1 knightli knightli 1685 Apr 17 21:26 README.md*

自作版は修正が必要です。実際には、次の行を追加するだけです

1
2

# 2e3c:5021 XIVN1987 XV-Link CMSIS-DAP
SUBSYSTEM=="usb", ATTR{idVendor}=="2e3c", ATTR{idProduct}=="5021", MODE:="666"

上の最初の行はコメントです

$ lsusb
Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 002: ID 0e0f:0003 VMware, Inc. Virtual Mouse
Bus 001 Device 003: ID 0e0f:0002 VMware, Inc. Virtual USB Hub
Bus 001 Device 007: ID 2e3c:5021 XIVN1987 XV-Link CMSIS-DAP
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

2 行目の数字は lsusb の数字に対応します。

対応する変更されたファイルを /etc/udev/rules.d にコピーします。

1
2

$ sudo udevadm control --reload
$ sudo udevadm trigger

変更されたルールをロードする

$ pyocd list
  #   Probe/Board                  Unique ID      Target  
----------------------------------------------------------
  0   XIVN1987 XV-Link CMSIS-DAP   1F75F4F81CA2   n/a

変更が成功すると、DAPLink が表示されます。

Microsoft Office Word文書docxを圧縮する

Mon, 14 Apr 2025 00:00:00 +0000

docxドキュメントの構造

docx ファイルは基本的に圧縮パッケージであり、Content_Types.xml で定義されたコンテンツタイプ、.rels ファイルで維持される関係、document.xml のドキュメントコンテンツ、styles.xml のスタイル定義、numbering.xml のリストスタイルが含まれます。これらのコンポーネントは連携して、ドキュメントの構造とスタイルを構築して表示します。ファイル名の拡張子 docx を zip に変更すると、次のディレクトリ構造に解凍できます。

│  [Content_Types].xml
├─docProps
│      app.xml
│      core.xml
│      custom.xml
│
├─word
│  │  document.xml
│  │  endnotes.xml
│  │  fontTable.xml
│  │  footer1.xml
│  │  footnotes.xml
│  │  settings.xml
│  │  styles.xml
│  │  webSettings.xml
│  │
│  ├─media
│  │      image1.jpg
│  │      image10.emf
│  │      image11.emf
│  │      image12.emf
│  │      image13.png
│  │      image14.emf
│  │      image15.emf
│  │      image16.emf
│  │      image17.emf
│  │      image2.jpg
│  │      image3.jpg
│  │      image4.jpg
│  │      image5.png
│  │      image6.png
│  │      image7.emf
│  │      image8.png
│  │      image9.png
│  │
│  ├─theme
│  │      theme1.xml
│  │
│  └─_rels
│          document.xml.rels
│
└─_rels
        .rels

docx ファイルを圧縮する

多くのスペースを占めるファイルは通常、word/media ディレクトリ内のファイルであり、圧縮は主にこれらのファイルを対象としています。 Docx は現在、JPEG XL、AVIF、WebP 2 などの最新の画像圧縮形式をサポートしていないため、一般的な jpg、png、およびその他の一般的な形式を使用する必要があります。

1.解凍する

拡張子を zip に変更して解凍します

def unzip(file):
    docname = file[0:-5]
    if os.path.exists(docname) :
        print('os.path.exists! remove!')
        shutil.rmtree(docname)

    with pyzipper.PyZipFile(file, "r") as zf:
        zf.extractall(docname)

2. jpg、png、その他のファイルを圧縮する

直接圧縮するだけです。圧縮にセシウムを使用すると、より優れた圧縮効果が得られます。コマンドラインツールを使用します。

def compress_image(
    input_path: str,
    quality: int = 80
):
    command = 'caesiumclt.exe --same-folder-as-input --quality ' + str(quality) + ' ' + input_path
    print(command)

    try:
        os.system(command)
    except Exception as e:
        logging.error(f"An error occurred: {str(e)}")

通常、品質を重視して 50 を選択します。圧縮された画像でも見栄えは良くなります。良い結果を得るために 20 を選択することもできます。より高い品質 80 を選択した場合でも、圧縮ファイルははるかに小さくなります。

3.emfファイルを圧縮する

emf は通常比較的大きく、jpg png に変換すると通常はさらに小さくなります。 imagemagick を使用して形式を変換し、圧縮することができます。ファイル名の拡張子が emf から jpg png に変更されるため、word_rels\document.xml.rels ファイルを変更する必要があります。

4. 梱包

変更したファイルをそのままパッケージ化し、圧縮方法として ZIP_DEFLATED を選択するだけです。

def zip(folder, zipfile):
    print('zip:', folder, ' -> ', zipfile)
    with pyzipper.PyZipFile(zipfile, "w",compression=pyzipper.ZIP_DEFLATED) as zf:
        for root,dirs,files in os.walk(folder):
            for file in files:
                abs_path = os.path.join(root,file)
                rel_path = os.path.relpath(abs_path,folder)
                # print(abs_path, rel_path)
                zf.write(abs_path, rel_path)
    
    shutil.rmtree(folder)

5. プロセスコード全体

def compress_docx(indir, outdir):
    for root,dirs,files in os.walk(indir):
        #    print(root,dirs,files) 
        for file in files:
            if file.endswith('.docx'):
                docfile = os.path.join(root, file)
                unzip(docfile)
                docname = file[0:-5]
                imgpath = os.path.join(root, docname, 'word/media/')
                # print('imgpath=', imgpath)
                compress_image(imgpath, 50)

                outfolder =  os.path.join(outdir, os.path.relpath(root, indir))
                if not os.path.exists(outfolder):
                    os.mkdir(outfolder)
                zip(os.path.join(root, docname), os.path.join(outfolder, file))

要約する

上記の方法、品質 = 50 によれば、docx ファイルは通常、元のサイズの約 1/3 になります。

JTAGとSWDの長所と短所の比較

Mon, 07 Apr 2025 00:00:00 +0000

JTAG (Joint Test Action Group) と SWD (Serial Wire Debug) は、一般的に使用される 2 つのデバッグインターフェイス標準です。この記事では、JTAG と SWD について詳しく調査し、その特性、利点と欠点、適用可能なシナリオを比較します。

JTAG: 従来のデバッグインターフェイス

JTAG の概要

JTAG はもともと回路基板のテストに使用される規格でしたが、その後、組み込みシステムのデバッグに広く使用されるようになりました。これは、通常、TCK (クロック)、TMS (モード選択)、TDI (データ入力)、および TDO (データ出力) の 4 つの主要なラインで構成されるパラレルインターフェイスです。 JTAG はステートマシンを使用して一連の操作を制御し、レジスタの読み取りと書き込み、メモリへのアクセス、操作命令の実行などを可能にします。

JTAGの利点

幅広いサポート: 多くの組み込みチップとプロセッサが JTAG インターフェイスを提供しているため、広範なハードウェアサポートが提供されます。

豊富な機能: JTAG インターフェイスは通常、レジスタの読み取りと書き込み、メモリへのアクセス、ハードウェアブレークポイントなどを含む豊富なデバッグ機能を提供します。

複雑なシステムに最適: 複雑な組み込みシステムには、より多くの制御と機能が提供される JTAG の方が適していることがよくあります。

JTAGの欠点

複雑さ: JTAG インターフェイスの並列性と制御ラインの増加により、JTAG インターフェイスのハードウェアと実装は一般的により複雑になります。

速度制限: JTAG にはデータ送信速度に一定の制限があり、一部のシリアルインターフェイスほど高速ではありません。

SWD: シンプルで効率的なシリアルインターフェース

1.SWDの紹介

SWD は、デバッグインターフェイスの複雑さを軽減し、通信速度を向上させるために設計された比較的新しいデバッグインターフェイスです。必要なのは、SWDIO (データとクロック)、SWDCLK (クロック)、および SWDNRST (リセット) の 3 本のメインラインだけです。 SWD は、より単純なステートマシンを使用してデータをシリアルに送信します。

SWDのメリット

簡素化されたハードウェア: SWD に必要なピンは数個だけであるため、ハードウェア設計がより単純になります。これにより、リソースに制約のあるシステムへの統合が容易になります。

高速通信: SWD はシリアル通信を使用するため、一般に JTAG よりも高速であり、通信オーバーヘッドが軽減されます。

低消費電力: SWD は、ピンの数が少なく、効率的な通信方法を備えているため、一般に消費電力が低くなります。

3.SWDのデメリット

限定的なサポート: SWD は多くの新しい組み込みチップでサポートされていますが、すべての古いチップや低コストのチップが SWD インターフェイスをサポートしているわけではありません。

機能制限: SWD は、特に一部の複雑なシステムのデバッグにおいて、JTAG ほど豊富な機能を提供しない場合があります。

JTAG と SWD: 選択方法は?

JTAGまたはSWDを選択してください

1.ハードウェアサポート

まず、ターゲットチップが必要なデバッグインターフェイスをサポートしているかどうかを確認します。チップがいずれかのインターフェイスのみをサポートしている場合は、サポートされているインターフェイスを選択するのが賢明です。

2.性能要件

より高い通信速度とより低い消費電力が必要な場合は、SWD がより良い選択となる可能性があります。ただし、豊富なデバッグ機能が必要な場合は、JTAG の使用が必要になる場合があります。

システムの複雑さ

より複雑なシステム、特に複数のプロセッサコアまたは FPGA を含むシステムの場合は、より多くの制御と機能が提供される JTAG の方が適していることがよくあります。

コストの考慮事項

ハードウェアのコストと複雑さを考慮してください。 SWD は一般に単純であるため、リソースに制約のあるシステムではコスト効率が高くなります。

開発ツール

開発ツールとデバッガーが選択したインターフェイスをサポートしていることを確認してください。最新のデバッグツールのほとんどは、JTAG と SWD の両方をサポートしています。

結論は

JTAG と SWD は両方とも重要な組み込みシステムデバッグインターフェイスですが、それぞれに独自の長所と短所があります。どのインターフェイスを選択するかは、プロジェクトのニーズ、ハードウェアのサポート、およびパフォーマンス要件によって異なります。複雑なシステムの場合、より多くの制御と機能を得るために JTAG を使用する必要がある場合がありますが、リソースが限られているシステムの場合は、SWD の方が適している場合があります。これらの要素を考慮すると、より効率的な組み込みシステムの開発とデバッグのための情報に基づいた選択が可能になります。

CMake の入門、サンプルとテンプレート

Fri, 28 Mar 2025 00:00:00 +0000

CMakeとは何ですか

CMake を使用すると、開発者はプラットフォームに依存しない CMakeList.txt ファイルを作成してコンパイルプロセス全体をカスタマイズし、ターゲットユーザーのプラットフォーム (Unix Makefile や Windows Visual Studio プロジェクトなど) に応じて必要なローカライズされた Makefile およびプロジェクトファイルをさらに生成できます。これにより、「一度書けばどこでも実行できる」を実現します。

CMake を使用して Makefile を生成し、Linux プラットフォームでコンパイルするプロセスは次のとおりです。

CMake 構成ファイル CMakeLists.txt を書き込みます。
コマンド cmake PATH または ccmake PATH を実行して Makefile を生成します (ccmake と cmake の違いは、前者は対話型インターフェイスを提供することです)。このうち、PATH は CMakeLists.txt が配置されているディレクトリです。

# 一般是创建一个build目录进行编译，CMakeLists.txt在build目录的上一层
mkdir ./build
cd build
cmake ..
make

makeコマンドを使用してコンパイルします。

テンプレート 1 つの単一ソースファイル

特定のディレクトリにある指定されたソースファイル (test01.cpp) を、サードパーティのライブラリを呼び出すことなくコンパイルし、最終的に実行可能ファイルにコンパイルする場合に適しています。

# 1,设置工程名称，叫“Demo1”，在Linux下可以随便设置
project( Demo1 )

# 2,设置 CMake 最低版本号，我电脑装的是3.5
cmake_minimum_required( VERSION 3.5 )

# 3,设定编译参数
set(CMAKE_CXX_STANDARD    11)  # 指定 C++ 版本
set(CMAKE_BUILD_TYPE "Release")  # 调试使用Debug，可以查看中间变量；发布使用Release，运行速度快

# 4，把源码编译成一个可执行文件，文件名为test01（可以随便取名），会保存在当前目录下
add_executable( test01 test01.cpp )

1
2
3

├── template1
│    ├── CMakeLists.txt
│    └── test02.cpp

実行中のプロセス

cd template1
mkdir ./build
cd build
cmake ..
make

buildディレクトリに実行ファイルtest01が生成されます。

テンプレート 2 1 つのディレクトリ内の複数のソースファイル

サードパーティのライブラリを呼び出さずに同じディレクトリ内の複数のソースファイルをコンパイルし、最終的に実行可能ファイルにコンパイルするのに適しています。ソースファイル .c .cpp .cc およびインクルードファイルはすべて 1 つのディレクトリに配置されます。ディレクトリは 1 つだけあり、サブディレクトリはありません。

# 1,设置工程名称，叫“Demo2”（在Linux下可以随便设置）
project( Demo2 )

# 2,设置 CMake 最低版本号，我电脑装的是3.5
cmake_minimum_required( VERSION 3.5 )

# 3,设定编译参数
set(CMAKE_CXX_STANDARD    11)  # 指定 C++ 版本
set(CMAKE_BUILD_TYPE "Release")  # 调试使用Debug，可以查看中间变量；发布使用Release，运行速度快

# 4，把当前文件夹下的源码列表（文件后缀匹配的那些文件）存到变量 SRCS 中
file( GLOB SRCS *.c *.cpp *.cc *.h *.hpp )

# 5，把源码编译成一个可执行文件，文件名为test02（可以随便取名），会保存在当前目录下
add_executable( test02 ${SRCS} )

├── template2
│    ├── CMakeLists.txt
│    ├── test02.cpp
│    └── test02.h

1 つのディレクトリに配置されている限り、ソースファイルとインクルードファイルはさらに存在することができます。

実行中のプロセス

cd template2
mkdir ./build
cd build
cmake ..
make

buildディレクトリに実行ファイルtest02が生成されます。

テンプレート 3 のソースファイルとインクルードファイルは別のディレクトリにあります

これは、cpp ファイルが 1 つのフォルダー (src/) にあり、ヘッダーファイルが別のフォルダー (include/) にあり、サードパーティのライブラリが呼び出されず、最終的に実行可能ファイルにコンパイルされる状況に適しています。

# 1,设置工程名称，叫“Demo3”，在Linux下可以随便设置
project( Demo3 )

# 2,设置 CMake 最低版本号，我电脑装的是3.5
cmake_minimum_required( VERSION 3.5 )

# 3,设定编译参数
set(CMAKE_CXX_STANDARD    11)  # 指定 C++ 版本
set(CMAKE_BUILD_TYPE "Release")  # 调试使用Debug，可以查看中间变量；发布使用Release，运行速度快

# 4,设定源码列表,查找指定目录下的所有源文件,并将名称保存到 DIR_SRCS 变量中
aux_source_directory(./src/ DIR_SRC)

# 5,设定头文件路径
include_directories(./include/)

# 6，把源码编译成一个可执行文件，文件名为test03（可以随便取名），会保存在当前目录下
add_executable( test03 ${DIR_SRC} )

ディレクトリ構造

├── template3
│   ├── CMakeLists.txt
│   ├── include
│   │   └── count.h
│   └── src
│       ├── count.cpp
│       └── test03.cpp

実行中のプロセス

cd template3
mkdir ./build
cd build
cmake ..
make

buildディレクトリに実行ファイルtest03が生成されます。

テンプレート 4 のソースファイルとインクルードファイルは別のディレクトリにあり、システムにインストールされているサードパーティライブラリを呼び出します。

これは、cpp ファイルが 1 つのフォルダー (src/) にあり、ヘッダーファイルが別のフォルダー (include/) にあり、サードパーティのライブラリ (システムに既にインストールされている opencv など) が呼び出され、最終的に実行可能ファイルにコンパイルされる状況に適しています。

# 1,设置工程名称，叫“Demo4”，在Linux下可以随便设置
project( Demo4 )

# 2,设置 CMake 最低版本号，我电脑装的是3.5
cmake_minimum_required( VERSION 3.5 )

# 3,设定编译参数
set(CMAKE_CXX_STANDARD    11)  # 指定 C++ 版本
set(CMAKE_BUILD_TYPE "Release")  # 调试使用Debug，可以查看中间变量；发布使用Release，运行速度快

# 4,设定源码列表,查找指定目录(都放在./src/中)中的所有源文件,并将名称保存到 DIR_SRCS 变量中
aux_source_directory(./src/ DIR_SRC)

# 5,设定头文件路径（还可以增加其他第三方库的头文件路径）
include_directories(./include/)

# 6,查找并添加OpenCV的头文件目录
find_package(OpenCV REQUIRED)  
# message( STATUS "    version: ${OpenCV_VERSION}" )  # 我电脑上装的是opencv3.3.1
# message( STATUS "    include path: ${OpenCV_INCLUDE_DIRS}" )
include_directories(${OpenCV_INCLUDE_DIRS})

# 7，把源码编译成一个可执行文件，文件名为test04（可以随便取名），会保存在当前目录下
add_executable( test04 ${DIR_SRC} )
target_link_libraries( test04 ${OpenCV_LIBS} )  # 可执行文件名 链接 OpenCV库

├── template4
│   ├── CMakeLists.txt
│   ├── include
│   │   └── test04.h
│   └── src
│       └── test04.cpp

実行中のプロセス

## 要先安装 opencv ubuntu下
sudo apt install libopencv-dev
cd template4
mkdir ./build
cd build
cmake ..
make

buildディレクトリに実行ファイルtest04が生成されます。

テンプレート 5 は複数のサブモジュールに分割されています。各サブモジュールには独自の CMakeLists.txt があり、実行可能ファイル、静的ライブラリ、および動的ライブラリを生成します。

cmake を使用してプロジェクトをビルドします。各サブモジュールには独自の cmakelist があります。プロジェクトは 2 つの静的ライブラリと 1 つの動的ライブラリを作成し、これらのライブラリを呼び出す実行可能ファイルも生成します。 CMakeLists.txt

cmake_minimum_required(VERSION 3.5)  # cmake版本最低要求
project(test5)  # 设置工程名称

set(CMAKE_CXX_STANDARD 11)  # 指定 C++ 版本
set(CMAKE_BUILD_TYPE Release)  # 调试使用Debug，可以查看中间变量；发布使用Release，运行速度快

message("${PROJECT_SOURCE_DIR}=" ${PROJECT_SOURCE_DIR})

# 这里设置好路径后，进入子模块的cmake时不用再次设置
SET(EXECUTABLE_OUTPUT_PATH ${PROJECT_SOURCE_DIR}/bin)  # 设置可执行文件的输出目录
SET(LIBRARY_OUTPUT_PATH ${PROJECT_SOURCE_DIR}/lib)	   # 设置库文件的输出目录

ADD_SUBDIRECTORY(${PROJECT_SOURCE_DIR}/source/add)     # 会调用该目录中的CMakeLists.txt进行编译生成静态库
ADD_SUBDIRECTORY(${PROJECT_SOURCE_DIR}/source/sub)     # 会调用该目录中的CMakeLists.txt进行编译生成静态库
ADD_SUBDIRECTORY(${PROJECT_SOURCE_DIR}/source/mul)     # 会调用该目录中的CMakeLists.txt进行编译生成动态库
ADD_SUBDIRECTORY(${PROJECT_SOURCE_DIR}/source/main)    # 会调用该目录中的CMakeLists.txt进行编译生成可执行文件

add/CMakeLists.txt

# 编译成静态库, libadd.a
# 方法一：逐个添加cpp源文件，适用于文件数量少的情况
# add_library(add ${CMAKE_CURRENT_SOURCE_DIR}/add.cpp ${CMAKE_CURRENT_SOURCE_DIR}/add3.cpp)

# 方法二：搜索有的cpp源文件，并将列表存储在一个变量中，适用于文件多的情况
aux_source_directory(${CMAKE_CURRENT_SOURCE_DIR} SRC_LIST)
add_library(add ${SRC_LIST})

# 方法三：递归遍历目录，获取所有的CPP文件，适用于多级目录的情况
# file(GLOB_RECURSE cpp_files  ${CMAKE_CURRENT_SOURCE_DIR}/*.cpp)  # GLOB是不递归
# add_library(add ${cpp_files})

mul/CMakeLists.txt

1
2

# 编译成动态库libmul.so
add_library(mul SHARED ${CMAKE_CURRENT_SOURCE_DIR}/mul.cpp)

sub/CMakeLists.txt

1
2

# 编译成静态库, libsub.a
add_library(sub ${CMAKE_CURRENT_SOURCE_DIR}/sub.cpp)

main/CMakeLists.txt

# 添加头文件路径，会检索目录中的所有头文件
include_directories(${CMAKE_CURRENT_SOURCE_DIR}/../add
                    ${CMAKE_CURRENT_SOURCE_DIR}/../sub
                    ${CMAKE_CURRENT_SOURCE_DIR}/../mul
                    ${CMAKE_CURRENT_SOURCE_DIR}/../main)

# 把源码编译成一个可执行文件
add_executable(main ./main.cpp)
# 添加链接库，动态和静态都行
target_link_libraries(main add sub mul)

ディレクトリ構造

├── template5
│   ├── CMakeLists.txt
│   ├── readme.md
│   ├── run.sh
│   └── source
│       ├── add
│       │   ├── add3.cpp
│       │   ├── add3.h
│       │   ├── add.cpp
│       │   ├── add.h
│       │   └── CMakeLists.txt
│       ├── main
│       │   ├── CMakeLists.txt
│       │   └── main.cpp
│       ├── mul
│       │   ├── CMakeLists.txt
│       │   ├── mul.cpp
│       │   └── mul.h
│       └── sub
│           ├── CMakeLists.txt
│           ├── sub.cpp
│           └── sub.h

実行中のプロセス

cd template5
rm -rf build
mkdir build
cd build/
cmake ..
make  
cd ../bin
./main

テンプレート 6 は複数のサブモジュールに分割されており、実行可能ファイル、静的ライブラリ、および動的ライブラリを生成する CMakeLists.txt が 1 つだけあります。

cmake を使用して複数のサブモジュールを含むプロジェクトをビルドしますが、サブモジュールには独自の cmakelist がありません。プロジェクト全体には CMakeLists.txt が 1 つだけあります。プロジェクトは 2 つの静的ライブラリと 1 つの動的ライブラリを作成し、これらのライブラリを呼び出す実行可能ファイルも生成します。

cmake_minimum_required(VERSION 3.5)  # cmake版本最低要求
project(test6)  # 设置工程名称

set(CMAKE_CXX_STANDARD 11)  # 指定 C++ 版本
set(CMAKE_BUILD_TYPE Release)  # 调试使用Debug，可以查看中间变量；发布使用Release，运行速度快

message("${PROJECT_SOURCE_DIR}=" ${PROJECT_SOURCE_DIR})

# 这里设置好路径后，进入子模块的cmake时不用再次设置
SET(EXECUTABLE_OUTPUT_PATH ${PROJECT_SOURCE_DIR}/bin)  # 设置可执行文件的输出目录
SET(LIBRARY_OUTPUT_PATH ${PROJECT_SOURCE_DIR}/lib)	   # 设置库文件的输出目录

# 编译add，生成静态库
aux_source_directory(${CMAKE_CURRENT_SOURCE_DIR}/source/add ADD_SRC_LIST)
add_library(add ${ADD_SRC_LIST})

# 编译sub，生成静态库
aux_source_directory(${CMAKE_CURRENT_SOURCE_DIR}/source/sub SUB_SRC_LIST)
add_library(sub ${SUB_SRC_LIST})

# 编译mul，生成动态库
aux_source_directory(${CMAKE_CURRENT_SOURCE_DIR}/source/mul MUL_SRC_LIST)
add_library(mul SHARED ${MUL_SRC_LIST})

# 添加头文件路径，用于编译可执行文件
include_directories(./source/add
                    ./source/sub
                    ./source/mul)

# 编译main，生成可执行文件
add_executable(main ${CMAKE_CURRENT_SOURCE_DIR}/source/main/main.cpp)
target_link_libraries(main add sub mul)  # 链接所有库

ディレクトリ構造

├── template6
│   ├── CMakeLists.txt
│   ├── readme.md
│   ├── run.sh
│   └── source
│       ├── add
│       │   ├── add3.cpp
│       │   ├── add3.h
│       │   ├── add.cpp
│       │   └── add.h
│       ├── main
│       │   └── main.cpp
│       ├── mul
│       │   ├── mul.cpp
│       │   └── mul.h
│       └── sub
│           ├── sub.cpp
│           └── sub.h

実行中のプロセス

cd template6
rm -rf build
mkdir build
cd build/
cmake ..
make 
cd ../bin
./main

共通コマンド

# Note：cmake中不区分大小写。

# 设置变量，方便后面自动配置，进入子模块的cmake时不用再次设置
SET(EXECUTABLE_OUTPUT_PATH ${PROJECT_SOURCE_DIR}/bin)  # 设置可执行文件的输出目录
SET(LIBRARY_OUTPUT_PATH ${PROJECT_SOURCE_DIR}/lib)	   # 设置库文件的输出目录

# 设定源码列表,查找指定目录下的所有源文件,并将名称保存到 DIR_SRCS 变量中
aux_source_directory(./src/ DIR_SRC)

# 设定头文件查找路径，可以将所有头文件路径都添加到这里面
include_directories(./include/
                    ./source/sub)

# 查找并添加OpenCV的头文件目录，在target_link_libraries()中需要进行动态链接
find_package(OpenCV REQUIRED) 

# 编译子模块，会自动调用子模块中的Cmakelists.txt进行编译
add_subdirectory(sub)

# 将${ADD_SRC_LIST}中的所有源码编译生成静态库add
add_library(add ${ADD_SRC_LIST})

# 将${SRCS}中的所有源码编译成一个可执行文件，文件名为main
add_executable( main ${SRCS} )
# 编译可执行文件之后，添加动态链接库，会链接静态库subadd和opencv库
target_link_libraries(main subadd ${OpenCV_LIBS})

# 打印一些日志信息
message("PROJECT_SOURCE_DIR=" ${PROJECT_SOURCE_DIR})

よく使用される変数

# Note：cmake中不区分大小写。

# 工程顶层目录
${CMAKE_SOURCE_DIR} ${PROJECT_SOURCE_DIR}

# 当前处理的 CMakeLists.txt 所在路径
${CMAKE_CURRENT_SOURCE_DIR}

# 返回Cmakelists.txt开头通过 PROJECT 指令定义的项目名称
${PROJECT_NAME}

# 分别用来重新定义最终结果（可执行文件、动静态库文件）的存放目录
${EXECUTABLE_OUTPUT_PATH} ${LIBRARY_OUTPUT_PATH}

追加 1 クロスコンパイル CH32V203

set(CMAKE_SYSTEM_NAME Generic)
set(CMAKE_SYSTEM_VERSION 1)
set(CMAKE_TRY_COMPILE_TARGET_TYPE "STATIC_LIBRARY")
cmake_minimum_required(VERSION 3.20)

# 工具链设置
set(TOOLPATH  D:/0wch/toolchain/RISCVEmbeddedGCC/bin/riscv-none-embed-)

if (WIN32)
	MESSAGE(STATUS "Now is windows!")
    set(CMAKE_C_COMPILER ${TOOLPATH}gcc.exe)
    set(CMAKE_CXX_COMPILER ${TOOLPATH}g++.exe)
    set(CMAKE_ASM_COMPILER ${TOOLPATH}gcc.exe)
    set(CMAKE_AR ${TOOLPATH}ar.exe)
    set(CMAKE_OBJCOPY ${TOOLPATH}objcopy.exe)
    set(CMAKE_OBJDUMP ${TOOLPATH}objdump.exe)
    set(SIZE ${TOOLPATH}size.exe)
elseif (UNIX)
	MESSAGE(STATUS "Now is UNIX-like OS!")
    set(CMAKE_C_COMPILER ${TOOLPATH}gcc)
    set(CMAKE_CXX_COMPILER ${TOOLPATH}g++)
    set(CMAKE_ASM_COMPILER ${TOOLPATH}gcc)
    set(CMAKE_AR ${TOOLPATH}ar)
    set(CMAKE_OBJCOPY ${TOOLPATH}objcopy)
    set(CMAKE_OBJDUMP ${TOOLPATH}objdump)
    set(SIZE ${TOOLPATH}size)
else ()
    MESSAGE(STATUS "Unsupported system!")
endif ()

# 项目设置
project(ch32v203-ninja C CXX ASM)
set(CMAKE_CXX_STANDARD 11)
set(CMAKE_C_STANDARD 99)

# 编译参数 一般不用改
add_compile_options(-march=rv32imac -mabi=ilp32 -mcmodel=medany -msmall-data-limit=8 -mno-save-restore)
add_compile_options(-fmessage-length=0 -fsigned-char -ffunction-sections -fdata-sections -fno-common)

# 编译等级
add_compile_options(-O2)

# 编译信息等级
add_compile_options(-Wall)

# 头文件路径
include_directories(APP
                    Core
                    Debug 
                    Peripheral/inc)

# 宏定义
# add_definitions(-DDEBUG=1)

# 源码文件
file(GLOB_RECURSE SOURCES 
                "APP/*.c"
                "Core/core_riscv.c" 
                "Debug/debug.c"
                "Peripheral/src/*.c" 
                "Startup/startup_ch32v20x_D6.S"
                )

# 链接参数
set(LINKER_SCRIPT  ${CMAKE_SOURCE_DIR}/Ld/Link.ld)
add_link_options(
                -march=rv32imac -mabi=ilp32
                -nostartfiles 
                -Xlinker --gc-sections  
                -Wl,--print-memory-usage
                -Wl,-Map,${PROJECT_NAME}.map 
                --specs=nano.specs 
                --specs=nosys.specs)
add_link_options(-T ${LINKER_SCRIPT})

# 编译可执行文件
add_executable(${PROJECT_NAME}.elf ${SOURCES} ${LINKER_SCRIPT})

# 链接静态库
# target_link_libraries(${PROJECT_NAME}.elf printfloat)

# 输出hex和bin
set(HEX_FILE ${PROJECT_BINARY_DIR}/${PROJECT_NAME}.hex)
set(BIN_FILE ${PROJECT_BINARY_DIR}/${PROJECT_NAME}.bin)
set(LST_FILE ${PROJECT_BINARY_DIR}/${PROJECT_NAME}.lst)
add_custom_command(TARGET ${PROJECT_NAME}.elf POST_BUILD
        COMMAND ${CMAKE_OBJCOPY} -Oihex $<TARGET_FILE:${PROJECT_NAME}.elf> ${HEX_FILE}
        COMMAND ${CMAKE_OBJCOPY} -Obinary $<TARGET_FILE:${PROJECT_NAME}.elf> ${BIN_FILE}
        COMMAND ${CMAKE_OBJDUMP} --all-headers --demangle --disassemble $<TARGET_FILE:${PROJECT_NAME}.elf> > ${LST_FILE}
        COMMAND ${SIZE} --format=berkeley $<TARGET_FILE:${PROJECT_NAME}.elf>
)

Link.ld ファイル

ENTRY( _start )

__stack_size = 2048;

PROVIDE( _stack_size = __stack_size );


MEMORY
{  
/* CH32V20x_D6 - CH32V203F6-CH32V203G6-CH32V203K6-CH32V203C6 */
	FLASH (rx) : ORIGIN = 0x00000000, LENGTH = 32K
	RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 10K

/* CH32V20x_D6 - CH32V203K8-CH32V203C8-CH32V203G8-CH32V203F8 */
	/* FLASH (rx) : ORIGIN = 0x00000000, LENGTH = 64K
	RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 20K */
 
/* CH32V20x_D8 - CH32V203RB
   CH32V20x_D8W - CH32V208x
   FLASH + RAM supports the following configuration
   FLASH-128K + RAM-64K
   FLASH-144K + RAM-48K
   FLASH-160K + RAM-32K

	FLASH (rx) : ORIGIN = 0x00000000, LENGTH = 160K
	RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 32K
*/
}


SECTIONS
{

	.init :
	{
		_sinit = .;
		. = ALIGN(4);
		KEEP(*(SORT_NONE(.init)))
		. = ALIGN(4);
		_einit = .;
	} >FLASH AT>FLASH

  .vector :
  {
      *(.vector);
	  . = ALIGN(64);
  } >FLASH AT>FLASH

	.text :
	{
		. = ALIGN(4);
		*(.text)
		*(.text.*)
		*(.rodata)
		*(.rodata*)
		*(.glue_7)
		*(.glue_7t)
		*(.gnu.linkonce.t.*)
		. = ALIGN(4);
	} >FLASH AT>FLASH 

	.fini :
	{
		KEEP(*(SORT_NONE(.fini)))
		. = ALIGN(4);
	} >FLASH AT>FLASH

	PROVIDE( _etext = . );
	PROVIDE( _eitcm = . );	

	.preinit_array  :
	{
	  PROVIDE_HIDDEN (__preinit_array_start = .);
	  KEEP (*(.preinit_array))
	  PROVIDE_HIDDEN (__preinit_array_end = .);
	} >FLASH AT>FLASH 
	
	.init_array     :
	{
	  PROVIDE_HIDDEN (__init_array_start = .);
	  KEEP (*(SORT_BY_INIT_PRIORITY(.init_array.*) SORT_BY_INIT_PRIORITY(.ctors.*)))
	  KEEP (*(.init_array EXCLUDE_FILE (*crtbegin.o *crtbegin?.o *crtend.o *crtend?.o ) .ctors))
	  PROVIDE_HIDDEN (__init_array_end = .);
	} >FLASH AT>FLASH 
	
	.fini_array     :
	{
	  PROVIDE_HIDDEN (__fini_array_start = .);
	  KEEP (*(SORT_BY_INIT_PRIORITY(.fini_array.*) SORT_BY_INIT_PRIORITY(.dtors.*)))
	  KEEP (*(.fini_array EXCLUDE_FILE (*crtbegin.o *crtbegin?.o *crtend.o *crtend?.o ) .dtors))
	  PROVIDE_HIDDEN (__fini_array_end = .);
	} >FLASH AT>FLASH 
	
	.ctors          :
	{
	  /* gcc uses crtbegin.o to find the start of
	     the constructors, so we make sure it is
	     first.  Because this is a wildcard, it
	     doesn't matter if the user does not
	     actually link against crtbegin.o; the
	     linker won't look for a file to match a
	     wildcard.  The wildcard also means that it
	     doesn't matter which directory crtbegin.o
	     is in.  */
	  KEEP (*crtbegin.o(.ctors))
	  KEEP (*crtbegin?.o(.ctors))
	  /* We don't want to include the .ctor section from
	     the crtend.o file until after the sorted ctors.
	     The .ctor section from the crtend file contains the
	     end of ctors marker and it must be last */
	  KEEP (*(EXCLUDE_FILE (*crtend.o *crtend?.o ) .ctors))
	  KEEP (*(SORT(.ctors.*)))
	  KEEP (*(.ctors))
	} >FLASH AT>FLASH 
	
	.dtors          :
	{
	  KEEP (*crtbegin.o(.dtors))
	  KEEP (*crtbegin?.o(.dtors))
	  KEEP (*(EXCLUDE_FILE (*crtend.o *crtend?.o ) .dtors))
	  KEEP (*(SORT(.dtors.*)))
	  KEEP (*(.dtors))
	} >FLASH AT>FLASH 

	.dalign :
	{
		. = ALIGN(4);
		PROVIDE(_data_vma = .);
	} >RAM AT>FLASH	

	.dlalign :
	{
		. = ALIGN(4); 
		PROVIDE(_data_lma = .);
	} >FLASH AT>FLASH

	.data :
	{
    	*(.gnu.linkonce.r.*)
    	*(.data .data.*)
    	*(.gnu.linkonce.d.*)
		. = ALIGN(8);
    	PROVIDE( __global_pointer$ = . + 0x800 );
    	*(.sdata .sdata.*)
		*(.sdata2.*)
    	*(.gnu.linkonce.s.*)
    	. = ALIGN(8);
    	*(.srodata.cst16)
    	*(.srodata.cst8)
    	*(.srodata.cst4)
    	*(.srodata.cst2)
    	*(.srodata .srodata.*)
    	. = ALIGN(4);
		PROVIDE( _edata = .);
	} >RAM AT>FLASH

	.bss :
	{
		. = ALIGN(4);
		PROVIDE( _sbss = .);
  	    *(.sbss*)
        *(.gnu.linkonce.sb.*)
		*(.bss*)
     	*(.gnu.linkonce.b.*)		
		*(COMMON*)
		. = ALIGN(4);
		PROVIDE( _ebss = .);
	} >RAM AT>FLASH

	PROVIDE( _end = _ebss);
	PROVIDE( end = . );

    .stack ORIGIN(RAM) + LENGTH(RAM) - __stack_size :
    {
        PROVIDE( _heap_end = . );   
        . = ALIGN(4);
        PROVIDE(_susrstack = . );
        . = . + __stack_size;
        PROVIDE( _eusrstack = .);
    } >RAM 

}

STM32、PY32、その他のマイクロコントローラーの GPIO の 8 つの入出力モードの詳細な説明

Tue, 18 Mar 2025 00:00:00 +0000

GPIOの8つの入出力モード

GPIO (汎用入力/出力) は、STM32 マイクロコントローラーで一般的に使用されるペリフェラルの 1 つで、外部回路の接続と制御に使用されます。 GPIO ピンは、入力 (センサーの信号入力) または出力 (外部デバイスを駆動するコントローラー) として使用できます。 STM32 マイクロコントローラーには、フローティング入力、プルアップ入力、プルダウン入力、アナログ入力、プッシュプル出力、オープンドレイン出力、多重化プッシュプル出力、多重化オープンドレイン出力という 8 つの一般的な入出力 (GPIO) モードがあります。

入力モード

入力フローティング (GPIO_Mode_IN_FLOATING)

入力フローティング: フローティングとは、ロジックデバイスとピンがハイレベルまたはローレベルに接続されていないことを意味します。ロジックデバイスの内部構造により、入力ピンがフローティングのままの場合、ピンがハイレベルに接続されているのと等価になります。一般的な実使用においては、ピンをフローティングにすることは干渉を受けやすいため推奨しません。フローティングとは平たく言えば空中に浮いているという意味で、デフォルトではこのポートはどこにも接続されておらず、ハイインピーダンス状態になっているということになります。この設定はデータ送信時によく使用されます。フローティングの最大の特徴は電圧の不確実性です。それは 0V、VCC、または (ほとんどの場合) 2 つの値の間の値である可能性があります。通常、ADC 入力にはフローティングが使用され、結果に対するプルアップ抵抗とプルダウン抵抗の影響を軽減できます。

特徴: ピンはハイインピーダンス状態で、外部回路に接続されていないため、外部信号レベルを測定します。
アプリケーションシナリオ: キー入力、センサー入力などの外部信号の受信状態。

// 初始化浮空输入模式的GPIO
GPIO_InitStruct.Pin = GPIO_PIN_0;
GPIO_InitStruct.Mode = GPIO_MODE_INPUT;          // 浮空输入模式
GPIO_InitStruct.Pull = GPIO_NOPULL;              // 不设置上拉或下拉
HAL_GPIO_Init(GPIOA, &GPIO_InitStruct);

入力プルアップ (GPIO_Mode_IPU)

プルアップモードに入る: プルアップとは、ポイントを Vcc などに高く引き上げることを意味します。プルアップとは、不確かな信号を抵抗を通してハイレベルにクランプすることです。抵抗は電流制限器としても機能します。弱と強の違いはプルアップ抵抗の抵抗値だけであり、厳密な区別はありません。
特長：プルアップ抵抗を内蔵しており、端子のデフォルトレベルはハイレベルです。
アプリケーションシナリオ: ボタンが押されたなど、外部信号が低レベルになったときを検出します。

// 初始化上拉输入模式的GPIO
GPIO_InitStruct.Pin = GPIO_PIN_0;
GPIO_InitStruct.Mode = GPIO_MODE_INPUT;          // 上拉输入模式
GPIO_InitStruct.Pull = GPIO_PULLUP;              // 上拉输入
HAL_GPIO_Init(GPIOA, &GPIO_InitStruct);

入力プルダウン (GPIO_Mode_IPD)

入力プルダウン: 電圧を GND に引き下げることを意味します。プルアップの原理と同じ
特長：プルダウン抵抗を内蔵しており、端子のデフォルトレベルはLowレベルです。
アプリケーションシナリオ: ボタンが離されたときなど、外部信号がハイレベルになったときを検出します。

// 初始化下拉输入模式的GPIO
GPIO_InitStruct.Pin = GPIO_PIN_0;
GPIO_InitStruct.Mode = GPIO_MODE_INPUT;          // 下拉输入模式
GPIO_InitStruct.Pull = GPIO_PULLDOWN;            // 下拉输入
HAL_GPIO_Init(GPIOA, &GPIO_InitStruct);

アナログ入力 (GPIO_Mode_AIN)

アナログ入力: アナログ入力とは、従来の入力を指します。デジタル入力は、PCM デジタル信号、つまり 0,1 のバイナリデジタル信号の入力です。デジタル/アナログ変換を通じてアナログ信号に変換され、プリアンプを通じてパワーアンプに入力されます。パワーアンプはアナログのままです。
特徴: 連続的に変化するアナログ信号を受信するために使用され、通常は ADC (アナログ - デジタルコンバーター) と組み合わせて使用されます。
アプリケーションシナリオ: センサー信号やオーディオ入力などのアナログ信号の変化を測定します。

// 初始化模拟输入模式的GPIO
GPIO_InitStruct.Pin = GPIO_PIN_0;
GPIO_InitStruct.Mode = GPIO_MODE_ANALOG;         // 模拟输入模式
GPIO_InitStruct.Pull = GPIO_NOPULL;              // 不设置上拉或下拉
HAL_GPIO_Init(GPIOA, &GPIO_InitStruct);

出力モード

オープンドレイン出力 (GPIO_Mode_Out_OD)

オープンドレイン出力：出力端子はトランジスタのコレクタに相当します。ハイレベル状態を得るにはプルアップ抵抗が必要です。電流駆動に適しています。電流を吸収する能力は比較的強いです(通常20mA以内)。

オープンドレイン回路には次の特徴があります。

外部回路の駆動能力を利用してIC内部の駆動を軽減します。 IC の内部 MOSFET がオンになると、駆動電流が外部 VCC から R プルアップ、MOSFET を通って GND に流れます。 IC 内部では非常に高いゲート駆動電流のみが必要です。
一般に、オープンドレインは、異なるレベルのデバイスを接続し、レベルを一致させるために使用されます。オープンドレインピンが外部プルアップ抵抗に接続されていない場合、ローレベルしか出力できないためです。同時にハイレベルを出力する機能が必要な場合はプルアップ抵抗を接続する必要があります。プルアップ電源の電圧を変えることで送信レベルを変更できるのが利点です。例えば、プルアップ抵抗を付加することで、TTL/CMOSレベルの出力などが可能になります（プルアップ抵抗の抵抗値により、論理レベルの変換エッジの速度が決まります。抵抗値が大きいほど速度が遅くなり、消費電力も小さくなります。そのため、負荷抵抗の選択は、消費電力と速度の両方を考慮する必要があります）。
オープンドレインは柔軟な出力方法を提供しますが、立ち上がりエッジの遅延という弱点もあります。立ち上がりエッジは外部プルアップ受動抵抗を介して負荷を充電するため、抵抗を小さく選択すると遅延は小さくなりますが、消費電力は大きくなります。逆に、遅延が大きい場合、消費電力は小さくなります。したがって、遅延が必要な場合は、立ち下がりエッジ出力を使用することをお勧めします。
複数のオープンドレイン出力ピンを 1 つのラインに接続できます。プルアップ抵抗を介して、デバイスを追加することなく「AND ロジック」関係が形成されます。これは、I2C や SMBus などのバスがバス占有ステータスを決定するための原則でもあります。補足：「行AND」とは何ですか？

ノード (ライン) 上で、プルアップ抵抗を電源 VCC または VDD と、n 個の NPN または NMOS トランジスタのコレクタ C またはドレイン D に接続します。これらのトランジスタのエミッタＥまたはソースＳは全て接地線に接続されている。 1 つのトランジスタが飽和している限り、このノード (ライン) はグランドレベルに引き下げられます。これらのトランジスタのベースが電流を注入する (NPN) か、ゲートがハイレベルを追加する (NMOS) ため、トランジスタは飽和します。したがって、これらのベースまたはゲートとこのノード (ライン) の関係は NOR 論理になります。このノードの後ろにインバータを追加すると、OR 論理になります。

実際、これは単純に次のように理解できます。すべてのピンが一緒に接続されると、外部プルアップ抵抗が接続されます。 1つのピンが論理0を出力している場合、それはグランドに接続されていることに相当し、それに並列に接続されている回路は「ワイヤでショートされているのと同じ」なので、外部回路の論理レベルは0になります。すべてがHighの場合にのみ、ANDの結果は論理1になります。

特徴: ローレベルのみを出力でき、ピンをハイにプルするには外部プルアップ抵抗が必要です。一定の運転能力を持っています。
アプリケーションシナリオ: I2C バスなどの外部デバイスに接続されている場合、他のデバイスと通信するために使用されます。

// 初始化开漏输出模式的GPIO
GPIO_InitStruct.Pin = GPIO_PIN_0;
GPIO_InitStruct.Mode = GPIO_MODE_OUTPUT_OD;     // 开漏输出模式
GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_HIGH;   // GPIO速度设置为高速
HAL_GPIO_Init(GPIOA, &GPIO_InitStruct);

オープンドレイン多重化機能(GPIO_Mode_AF_OD)

オープンドレイン多重化機能: GPIO ポートを 2 番目の機能として使用する (つまり、汎用 IO ポートとして使用しない) 場合の構成状況として理解できます。ポートは代替機能出力モード (プッシュプルまたはオープンドレイン) に設定する必要があります。

特徴: オープンドレイン出力特性を備えており、GPIO ピンを特定のペリフェラルの機能として使用するために使用できます。
アプリケーションシナリオ: I2C バス通信ピン、障害信号出力などの周辺機器に接続された特殊機能ピン。

// 初始化复用开漏输出模式的GPIO
GPIO_InitStruct.Pin = GPIO_PIN_0;
GPIO_InitStruct.Mode = GPIO_MODE_AF_OD;          // 复用开漏输出模式
GPIO_InitStruct.Pull = GPIO_NOPULL;              // 不设置上拉或下拉
GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_HIGH;    // GPIO速度设置为高速
HAL_GPIO_Init(GPIOA, &GPIO_InitStruct);

プッシュプル出力 (GPIO_Mode_Out_PP)

プッシュプル出力: ハイレベルとローレベルを出力し、デジタルデバイスに接続できます。プッシュプル構造とは、一般に 2 つのトランジスタが相補信号によって制御され、一方のトランジスタがオンになるともう一方のトランジスタが常にオフになることを意味します。ハイレベルとローレベルは、IC の電源によって決まります。

プッシュプル回路は、同じパラメータを持つ 2 つのトランジスタまたは MOSFET です。それらはプッシュプルモードで回路内に存在します。それぞれが正と負の半サイクルの波形タスクを担当します。回路が動作しているとき、2つの対称的なパワースイッチ管のうちの1つだけが一度にオンになるため、伝導損失が小さく、効率が高くなります。出力は電流を負荷にシンクすることができます。プッシュプル出力段は、回路の負荷容量を増加させるだけでなく、スイッチング速度も増加させます。

特長：高レベル、低レベルの出力が可能で、確実な駆動能力を持っています。
アプリケーションシナリオ: LED ライトの制御、他の論理回路の駆動など、外部回路の駆動に使用されます。

// 初始化推挽输出模式的GPIO
GPIO_InitTypeDef GPIO_InitStruct;
GPIO_InitStruct.Pin = GPIO_PIN_0;               // GPIO引脚号
GPIO_InitStruct.Mode = GPIO_MODE_OUTPUT_PP;     // 推挽输出模式
GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_HIGH;   // GPIO速度设置为高速
HAL_GPIO_Init(GPIOA, &GPIO_InitStruct);         // 初始化GPIOA

プッシュプル多重化機能(GPIO_Mode_AF_PP)

プッシュプル多重化機能：GPIOポートを第2機能として使用する場合（一般的なIOポートとして使用しない場合）の構成状況として把握できます。

特徴: プッシュプル出力特性を備えており、GPIO ピンを特定のペリフェラルの機能として使用するために使用できます。
アプリケーションシナリオ: UART シリアル通信ピン、PWM 出力などのペリフェラルの特殊機能ピンに接続します。

// 初始化复用推挽输出模式的GPIO
GPIO_InitStruct.Pin = GPIO_PIN_0;
GPIO_InitStruct.Mode = GPIO_MODE_AF_PP;          // 复用推挽输出模式
GPIO_InitStruct.Pull = GPIO_NOPULL;              // 不设置上拉或下拉
GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_HIGH;    // GPIO速度设置为高速
HAL_GPIO_Init(GPIOA, &GPIO_InitStruct);

Ubuntu 24.04 で pyocd Jlink をインストールして使用する

Mon, 17 Mar 2025 00:00:00 +0000

Jリンク使用

J-link OB ARM シミュレーションダウンロードデバッガー SWD プログラマーと互換性があり、淘宝網 7-9 元セット

インストール

Jlinkドライバーをインストールする

1
2

去这个地址下载deb程序
https://www.segger.com/downloads/jlink/

Pythonをインストールする

$ sudo apt install python-is-python3
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following NEW packages will be installed:
  python-is-python3
0 upgraded, 1 newly installed, 0 to remove and 35 not upgraded.
Need to get 2,684 B of archives.
After this operation, 15.4 kB of additional disk space will be used.
Get:1 http://archive.ubuntu.com/ubuntu noble/main amd64 python-is-python3 all 3.11.4-1 [2,684 B]
Fetched 2,684 B in 2s (1,672 B/s)             
Selecting previously unselected package python-is-python3.
(Reading database ... 158342 files and directories currently installed.)
Preparing to unpack .../python-is-python3_3.11.4-1_all.deb ...
Unpacking python-is-python3 (3.11.4-1) ...
Setting up python-is-python3 (3.11.4-1) ...
Processing triggers for man-db (2.12.0-4build2) ...

$ python
Python 3.12.3 (main, Feb  4 2025, 14:48:35) [GCC 13.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> exit()

pipxをインストールする

$ sudo apt install pipx
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
  python3-argcomplete python3-packaging python3-pip-whl python3-platformdirs python3-psutil python3-setuptools-whl python3-userpath python3-venv python3.12-venv
The following NEW packages will be installed:
  pipx python3-argcomplete python3-packaging python3-pip-whl python3-platformdirs python3-psutil python3-setuptools-whl python3-userpath python3-venv python3.12-venv
0 upgraded, 10 newly installed, 0 to remove and 35 not upgraded.
Need to get 3,508 kB of archives.
After this operation, 7,832 kB of additional disk space will be used.
Do you want to continue? [Y/n] y
Get:1 http://archive.ubuntu.com/ubuntu noble-updates/universe amd64 python3-pip-whl all 24.0+dfsg-1ubuntu1.1 [1,703 kB]
Get:2 http://archive.ubuntu.com/ubuntu noble-updates/universe amd64 python3-setuptools-whl all 68.1.2-2ubuntu1.1 [716 kB]
Get:3 http://archive.ubuntu.com/ubuntu noble-updates/universe amd64 python3.12-venv amd64 3.12.3-1ubuntu0.5 [5,678 B]
Get:4 http://archive.ubuntu.com/ubuntu noble-updates/universe amd64 python3-venv amd64 3.12.3-0ubuntu2 [1,034 B]
Get:5 http://archive.ubuntu.com/ubuntu noble-updates/universe amd64 python3-argcomplete all 3.1.4-1ubuntu0.1 [33.8 kB]
Get:6 http://archive.ubuntu.com/ubuntu noble/main amd64 python3-packaging all 24.0-1 [41.1 kB]
Get:7 http://archive.ubuntu.com/ubuntu noble/main amd64 python3-platformdirs all 4.2.0-1 [16.1 kB]
Get:8 http://archive.ubuntu.com/ubuntu noble/universe amd64 python3-userpath all 1.9.1-1 [9,416 B]
Get:9 http://archive.ubuntu.com/ubuntu noble/universe amd64 pipx all 1.4.3-1 [787 kB]
Get:10 http://archive.ubuntu.com/ubuntu noble/main amd64 python3-psutil amd64 5.9.8-2build2 [195 kB]
Fetched 3,508 kB in 3s (1,301 kB/s)       
Selecting previously unselected package python3-pip-whl.
(Reading database ... 161768 files and directories currently installed.)
Preparing to unpack .../0-python3-pip-whl_24.0+dfsg-1ubuntu1.1_all.deb ...
Unpacking python3-pip-whl (24.0+dfsg-1ubuntu1.1) ...
Selecting previously unselected package python3-setuptools-whl.
Preparing to unpack .../1-python3-setuptools-whl_68.1.2-2ubuntu1.1_all.deb ...
Unpacking python3-setuptools-whl (68.1.2-2ubuntu1.1) ...
Selecting previously unselected package python3.12-venv.
Preparing to unpack .../2-python3.12-venv_3.12.3-1ubuntu0.5_amd64.deb ...
Unpacking python3.12-venv (3.12.3-1ubuntu0.5) ...
Selecting previously unselected package python3-venv.
Preparing to unpack .../3-python3-venv_3.12.3-0ubuntu2_amd64.deb ...
Unpacking python3-venv (3.12.3-0ubuntu2) ...
Selecting previously unselected package python3-argcomplete.
Preparing to unpack .../4-python3-argcomplete_3.1.4-1ubuntu0.1_all.deb ...
Unpacking python3-argcomplete (3.1.4-1ubuntu0.1) ...
Selecting previously unselected package python3-packaging.
Preparing to unpack .../5-python3-packaging_24.0-1_all.deb ...
Unpacking python3-packaging (24.0-1) ...
Selecting previously unselected package python3-platformdirs.
Preparing to unpack .../6-python3-platformdirs_4.2.0-1_all.deb ...
Unpacking python3-platformdirs (4.2.0-1) ...
Selecting previously unselected package python3-userpath.
Preparing to unpack .../7-python3-userpath_1.9.1-1_all.deb ...
Unpacking python3-userpath (1.9.1-1) ...
Selecting previously unselected package pipx.
Preparing to unpack .../8-pipx_1.4.3-1_all.deb ...
Unpacking pipx (1.4.3-1) ...
Selecting previously unselected package python3-psutil.
Preparing to unpack .../9-python3-psutil_5.9.8-2build2_amd64.deb ...
Unpacking python3-psutil (5.9.8-2build2) ...
Setting up python3-setuptools-whl (68.1.2-2ubuntu1.1) ...
Setting up python3-pip-whl (24.0+dfsg-1ubuntu1.1) ...
Setting up python3-platformdirs (4.2.0-1) ...
Setting up python3-psutil (5.9.8-2build2) ...
Setting up python3-packaging (24.0-1) ...
Setting up python3-argcomplete (3.1.4-1ubuntu0.1) ...
Setting up python3-userpath (1.9.1-1) ...
Setting up python3.12-venv (3.12.3-1ubuntu0.5) ...
Setting up python3-venv (3.12.3-0ubuntu2) ...
Setting up pipx (1.4.3-1) ...
Processing triggers for man-db (2.12.0-4build2) ...

pyocd をインストールする

$ pipx install pyocd
  installed package pyocd 0.36.0, installed using Python 3.12.3
  These apps are now globally available
    - pyocd
    - pyocd-gdbserver
⚠️  Note: '/home/knightli/.local/bin' is not on your PATH environment variable. These apps will not be globally accessible until your PATH is updated. Run `pipx ensurepath` to automatically add it, or manually modify your PATH in
    your shell's config file (i.e. ~/.bashrc).
done! ✨ 🌟 ✨
$ pipx ensurepath
Success! Added /home/knightli/.local/bin to the PATH environment variable.

Consider adding shell completions for pipx. Run 'pipx completions' for instructions.

You will need to open a new terminal or re-login for the PATH changes to take effect.

Otherwise pipx is ready to go! ✨ 🌟 ✨

pyocdの使用

-V バージョン番号をリストする

1
2

knightli@knightli-py32:~$ pyocd -V
0.36.0

pyocd listコマンド

-p 命令使用来查看调试器的信息，
pyocd list / pyocd list -p
列出连接到电脑上的 dap link 或者 jlink的信息

knightli@knightli-py32:~$ pyocd list -p
  #   Probe/Board               Unique ID    Target  
-----------------------------------------------------
  0   Segger J-Link (unknown)   4294967295   n/a

knightli@knightli-py32:~$ pyocd list -t
列出所支持的IC，可以是内置的，也可以是通过安装pack获得支持的.
Source这一列  builtin 表示内置 pack表示通过安装pack获得支持的.


  Name                      Vendor                   Part Number                  Families   Source   
------------------------------------------------------------------------------------------------------
  air001                    AirM2M                   Air001                                  builtin  
  air32f103xb               AirM2M                   Air32F103xB                             builtin  
  air32f103xc               AirM2M                   Air32F103xC                             builtin  
  air32f103xe               AirM2M                   Air32F103xE                             builtin  
  air32f103xg               AirM2M                   Air32F103xG                             builtin  
  air32f103xp               AirM2M                   Air32F103xP                             builtin  
  cc3220sf                  Texas Instruments        CC3220SF                                builtin  
  cortex_m                  Generic                  CoreSightTarget                         builtin  
  cy8c64_sysap              Cypress                  cy8c64_sysap                            builtin  
  cy8c64x5_cm0              Cypress                  cy8c64x5_cm0                            builtin  
  cy8c64x5_cm0_full_flash   Cypress                  cy8c64x5_cm0_full_flash                 builtin  
  cy8c64x5_cm4              Cypress                  cy8c64x5_cm4                            builtin  
  cy8c64x5_cm4_full_flash   Cypress                  cy8c64x5_cm4_full_flash                 builtin  
  cy8c64xa_cm0              Cypress                  cy8c64xA_cm0                            builtin  
  cy8c64xa_cm0_full_flash   Cypress                  cy8c64xA_cm0_full_flash                 builtin  
  cy8c64xa_cm4              Cypress                  cy8c64xA_cm4                            builtin  
  cy8c64xa_cm4_full_flash   Cypress                  cy8c64xA_cm4_full_flash                 builtin  
  cy8c64xx_cm0              Cypress                  cy8c64xx_cm0                            builtin  
  cy8c64xx_cm0_full_flash   Cypress                  cy8c64xx_cm0_full_flash                 builtin  
  cy8c64xx_cm0_nosmif       Cypress                  cy8c64xx_cm0_nosmif                     builtin  
  cy8c64xx_cm0_s25hx512t    Cypress                  cy8c64xx_cm0_s25hx512t                  builtin  
  cy8c64xx_cm4              Cypress                  cy8c64xx_cm4                            builtin  
  cy8c64xx_cm4_full_flash   Cypress                  cy8c64xx_cm4_full_flash                 builtin  
  cy8c64xx_cm4_nosmif       Cypress                  cy8c64xx_cm4_nosmif                     builtin  
  cy8c64xx_cm4_s25hx512t    Cypress                  cy8c64xx_cm4_s25hx512t                  builtin  
  cy8c6xx5                  Cypress                  CY8C6xx5                                builtin  
  cy8c6xx7                  Cypress                  CY8C6xx7                                builtin  
  cy8c6xx7_nosmif           Cypress                  CY8C6xx7_nosmif                         builtin  
  cy8c6xx7_s25fs512s        Cypress                  CY8C6xx7_S25FS512S                      builtin  
  cy8c6xxa                  Cypress                  CY8C6xxA                                builtin  
  hc32a460xe                HDSC                     HC32F460xE                              builtin  
  hc32a4a0xi                HDSC                     HC32F4A0xI                              builtin  
  hc32f003                  HDSC                     HC32F003                                builtin  
  hc32f005                  HDSC                     HC32F005                                builtin  
  hc32f030                  HDSC                     HC32F030                                builtin  
  hc32f072                  HDSC                     HC32F072                                builtin  
  hc32f120x6                HDSC                     HC32F120x6TA                            builtin  
  hc32f120x8                HDSC                     HC32F120x8TA                            builtin  
  hc32f160xa                HDSC                     HC32F160xA                              builtin  
  hc32f160xc                HDSC                     HC32F160xC                              builtin  
  hc32f190                  HDSC                     HC32F190                                builtin  
  hc32f196                  HDSC                     HC32F196                                builtin  
  hc32f448xa                HDSC                     HC32F448xA                              builtin  
  hc32f448xc                HDSC                     HC32F448xC                              builtin  
  hc32f451xc                HDSC                     HC32F451xC                              builtin  
  hc32f451xe                HDSC                     HC32F451xE                              builtin  
  hc32f452xc                HDSC                     HC32F452xC                              builtin  
  hc32f452xe                HDSC                     HC32F452xE                              builtin  
  hc32f460xc                HDSC                     HC32F460xC                              builtin  
  hc32f460xe                HDSC                     HC32F460xE                              builtin  
  hc32f4a0xg                HDSC                     HC32F4A0xG                              builtin  
  hc32f4a0xi                HDSC                     HC32F4A0xI                              builtin  
  hc32l072                  HDSC                     HC32L072                                builtin  
  hc32l073                  HDSC                     HC32L073                                builtin  
  hc32l110                  HDSC                     HC32L110                                builtin  
  hc32l130                  HDSC                     HC32L130                                builtin  
  hc32l136                  HDSC                     HC32L136                                builtin  
  hc32l190                  HDSC                     HC32L190                                builtin  
  hc32l196                  HDSC                     HC32L196                                builtin  
  hc32m120                  HDSC                     HC32M120                                builtin  
  hc32m120x6                HDSC                     HC32M120                                builtin  
  hc32m423xa                HDSC                     HC32M423xA                              builtin  
  k20d50m                   NXP                      K20D50M                                 builtin  
  k22f                      NXP                      K22F                                    builtin  
  k22fa12                   NXP                      K22FA12                                 builtin  
  k28f15                    NXP                      K28F15                                  builtin  
  k32l2b3                   NXP                      K32L2B3                                 builtin  
  k32w042s                  NXP                      K32W042S                                builtin  
  k64f                      NXP                      K64F                                    builtin  
  k66f18                    NXP                      K66F18                                  builtin  
  k82f25615                 NXP                      K82F25615                               builtin  
  ke15z7                    NXP                      KE15Z7                                  builtin  
  ke17z7                    NXP                      KE17Z7                                  builtin  
  ke18f16                   NXP                      KE18F16                                 builtin  
  kinetis                   NXP                      Kinetis                                 builtin  
  kl02z                     NXP                      KL02Z                                   builtin  
  kl05z                     NXP                      KL05Z                                   builtin  
  kl25z                     NXP                      KL25Z                                   builtin  
  kl26z                     NXP                      KL26Z                                   builtin  
  kl27z4                    NXP                      KL27Z4                                  builtin  
  kl28z                     NXP                      KL28x                                   builtin  
  kl43z4                    NXP                      KL43Z4                                  builtin  
  kl46z                     NXP                      KL46Z                                   builtin  
  kl82z7                    NXP                      KL82Z7                                  builtin  
  kv10z7                    NXP                      KV10Z7                                  builtin  
  kv11z7                    NXP                      KV11Z7                                  builtin  
  kw01z4                    NXP                      KW01Z4                                  builtin  
  kw24d5                    NXP                      KW24D5                                  builtin  
  kw36z4                    NXP                      KW36Z4                                  builtin  
  kw40z4                    NXP                      KW40Z4                                  builtin  
  kw41z4                    NXP                      KW41Z4                                  builtin  
  lpc11u24                  NXP                      LPC11U24                                builtin  
  lpc11xx_32                NXP                      LPC11XX_32                              builtin  
  lpc1768                   NXP                      LPC1768                                 builtin  
  lpc4088                   NXP                      LPC4088                                 builtin  
  lpc4088dm                 NXP                      LPC4088dm                               builtin  
  lpc4088qsb                NXP                      LPC4088qsb                              builtin  
  lpc4330                   NXP                      LPC4330                                 builtin  
  lpc54114                  NXP                      LPC54114                                builtin  
  lpc54608                  NXP                      LPC54608                                builtin  
  lpc5526                   NXP                      LPC5526                                 builtin  
  lpc55s16                  NXP                      LPC55S16                                builtin  
  lpc55s28                  NXP                      LPC55S28                                builtin  
  lpc55s36                  NXP                      LPC55S36                                builtin  
  lpc55s69                  NXP                      LPC55S69                                builtin  
  lpc800                    NXP                      LPC800                                  builtin  
  lpc824                    NXP                      LPC824                                  builtin  
  lpc845                    NXP                      LPC845                                  builtin  
  m2354kjfae                Nuvoton                  M2354KJFAE                              builtin  
  m252kg6ae                 Nuvoton                  M252KG6AE                               builtin  
  m263kiaae                 Nuvoton                  M263KIAAE                               builtin  
  m467hjhae                 Nuvoton                  M467HJHAE                               builtin  
  m487jidae                 Nuvoton                  M487JIDAE                               builtin  
  max32600                  Maxim                    MAX32600                                builtin  
  max32620                  Maxim                    MAX32620                                builtin  
  max32625                  Maxim                    MAX32625                                builtin  
  max32630                  Maxim                    MAX32630                                builtin  
  max32660                  Maxim                    MAX32660                                builtin  
  max32666                  Maxim                    MAX32666                                builtin  
  max32670                  Maxim                    MAX32670                                builtin  
  mimxrt1010                NXP                      MIMXRT1011xxxxx                         builtin  
  mimxrt1015                NXP                      MIMXRT1015xxxxx                         builtin  
  mimxrt1020                NXP                      MIMXRT1021xxxxx                         builtin  
  mimxrt1024                NXP                      MIMXRT1024xxxxx                         builtin  
  mimxrt1050                NXP                      MIMXRT1052xxxxB_hyperflash              builtin  
  mimxrt1050_hyperflash     NXP                      MIMXRT1052xxxxB_hyperflash              builtin  
  mimxrt1050_quadspi        NXP                      MIMXRT1052xxxxB_quadspi                 builtin  
  mimxrt1060                NXP                      MIMXRT1062xxxxA                         builtin  
  mimxrt1064                NXP                      MIMXRT1064xxxxA                         builtin  
  mimxrt1170_cm4            NXP                      MIMXRT1176xxxxx_CM4                     builtin  
  mimxrt1170_cm7            NXP                      MIMXRT1176xxxxx_CM7                     builtin  
  mps3_an522                Arm                      AN522                                   builtin  
  mps3_an540                Arm                      AN540                                   builtin  
  musca_a1                  Arm                      MuscaA1                                 builtin  
  musca_b1                  Arm                      MuscaB1                                 builtin  
  musca_s1                  Arm                      MuscaS1                                 builtin  
  ncs36510                  ONSemiconductor          NCS36510                                builtin  
  nrf51                     Nordic Semiconductor     NRF51                                   builtin  
  nrf51822                  Nordic Semiconductor     NRF51                                   builtin  
  nrf52                     Nordic Semiconductor     NRF52832                                builtin  
  nrf52832                  Nordic Semiconductor     NRF52832                                builtin  
  nrf52833                  Nordic Semiconductor     NRF52833                                builtin  
  nrf52840                  Nordic Semiconductor     NRF52840                                builtin  
  nrf91                     Nordic Semiconductor     NRF91XX                                 builtin  
  rp2040                    Raspberry Pi             RP2040Core0                             builtin  
  rp2040_core0              Raspberry Pi             RP2040Core0                             builtin  
  rp2040_core1              Raspberry Pi             RP2040Core1                             builtin  
  rtl8195am                 Realtek Semiconductor    RTL8195AM                               builtin  
  rtl8762c                  Realtek Semiconductor    RTL8762C                                builtin  
  s32k344                   NXP                      S32K344                                 builtin  
  s5js100                   Samsung                  S5JS100                                 builtin  
  stm32f051                 STMicroelectronics       STM32F051                               builtin  
  stm32f103rc               STMicroelectronics       STM32F103RC                             builtin  
  stm32f412xe               STMicroelectronics       STM32F412xE                             builtin  
  stm32f412xg               STMicroelectronics       STM32F412xG                             builtin  
  stm32f429xg               STMicroelectronics       STM32F429xG                             builtin  
  stm32f429xi               STMicroelectronics       STM32F429xI                             builtin  
  stm32f439xg               STMicroelectronics       STM32F439xG                             builtin  
  stm32f439xi               STMicroelectronics       STM32F439xI                             builtin  
  stm32f767zi               STMicroelectronics       STM32F767xx                             builtin  
  stm32h723xx               STMicroelectronics       STM32H723xx                             builtin  
  stm32h743xx               STMicroelectronics       STM32H743xx                             builtin  
  stm32h7b0xx               STMicroelectronics       STM32H7B0xx                             builtin  
  stm32l031x6               STMicroelectronics       STM32L031x6                             builtin  
  stm32l432kc               STMicroelectronics       STM32L432xC                             builtin  
  stm32l475xc               STMicroelectronics       STM32L475xC                             builtin  
  stm32l475xe               STMicroelectronics       STM32L475xE                             builtin  
  stm32l475xg               STMicroelectronics       STM32L475xG                             builtin  
  w7500                     WIZnet                   W7500                                   builtin  
  ytm32b1ld0                Yuntu Microelectronics   YTM32B1LD0                              builtin  
  ytm32b1le0                Yuntu Microelectronics   YTM32B1LE0                              builtin  
  ytm32b1md1                Yuntu Microelectronics   YTM32B1MD1                              builtin  
  ytm32b1me0                YTMicro                  YTM32B1ME0                              builtin

pyocdパックコマンド

pyocd は 2 つの方法で MCU をサポートします。1 つはビルトイン (組み込み)、数が制限されている方法、もう 1 つはパックを介してサポートされる方法です。どの MCU を pyocd で動作させる必要があるか、keil5 と同様に対応するパックをインストールします。新しくインストールされた Keil5 はマイクロコントローラーをサポートしていません。新しくインストールした keil を使用して特定の種類のマイクロコントローラーをサポートする場合は、対応するソフトウェアパッケージをインストールする必要があります。 pyocd は、パックの管理、インストール、検索、削除などを行うための組み込みサブコマンドを提供します。

knightli@knightli-py32:~$ pyocd pack -h
usage: pyocd pack [-h] [-v] [-q] [-L LOGGERS=LEVEL] [--color [{always,auto,never}]] [-c] [-u] [-s] [-f GLOB] [-i GLOB] [-n] [-H]  ...

options:
  -h, --help            show this help message and exit

logging:
  -v, --verbose         Increase logging level. Can be specified multiple times.
  -q, --quiet           Decrease logging level. Can be specified multiple times.
  -L LOGGERS=LEVEL, --log-level LOGGERS=LEVEL
                        Set log level of loggers whose name matches any of the comma-separated list of glob-style patterns. Log level must be one of (critical, error, warning, info, debug). Can be
                        specified multiple times. Example: -L*.trace,pyocd.core.*=debug
  --color [{always,auto,never}]
                        Control color logging. Default is auto.

subcommands:
  
    clean               Delete the pack index and all installed packs.
    find                Report pack(s) in the index containing matching device part numbers.
    install             Download and install pack(s) containing matching device part numbers.
    show                Show the list of installed packs.
    update              Update the pack index.

pack operations:
  -c, --clean           (Deprecated; use clean subcommand.) Erase all stored pack information.
  -u, --update          (Deprecated; use update subcommand.) Update the pack index.
  -s, --show            (Deprecated; use show subcommand.) Show the list of installed packs.
  -f GLOB, --find GLOB  (Deprecated; use find subcommand.) Report pack(s) in the index containing matching device part numbers.
  -i GLOB, --install GLOB
                        (Deprecated; use install subcommand.) Download and install pack(s) containing matching device part numbers.

pack options:
  -n, --no-download     Just list the pack(s) that would be downloaded, don't actually download anything.
  -H, --no-header       Don't print a table header.

インデックスディレクトリを更新する

1
2
3

knightli@knightli-py32:~$ pyocd pack update
0000195 I Updating pack index... [pack_cmd]
Downloading descriptors (1603/1603)

サポートが必要な IC を見つける

knightli@knightli-py32:~$ pyocd pack find py32
  Part          Vendor   Pack                Version   Installed  
------------------------------------------------------------------
  PY32E407xC    Puya     Puya.PY32E4xx_DFP   1.0.0     False      
  PY32E407xD    Puya     Puya.PY32E4xx_DFP   1.0.0     False      
  PY32E407xE    Puya     Puya.PY32E4xx_DFP   1.0.0     False      
  PY32F002Ax5   Puya     Puya.PY32F0xx_DFP   1.2.2     False      
  PY32F002Bx5   Puya     Puya.PY32F0xx_DFP   1.2.2     False      
  PY32F002Xx2   Puya     Puya.PY32F0xx_DFP   1.2.2     False      
  PY32F002Xx4   Puya     Puya.PY32F0xx_DFP   1.2.2     False      
  PY32F002Xx5   Puya     Puya.PY32F0xx_DFP   1.2.2     False      
  PY32F003x4    Puya     Puya.PY32F0xx_DFP   1.2.2     False      
  PY32F003x6    Puya     Puya.PY32F0xx_DFP   1.2.2     False      
  PY32F003x7    Puya     Puya.PY32F0xx_DFP   1.2.2     False      
  PY32F003x8    Puya     Puya.PY32F0xx_DFP   1.2.2     False      
  PY32F030x4    Puya     Puya.PY32F0xx_DFP   1.2.2     False      
  PY32F030x6    Puya     Puya.PY32F0xx_DFP   1.2.2     False      
  PY32F030x7    Puya     Puya.PY32F0xx_DFP   1.2.2     False      
  PY32F030x8    Puya     Puya.PY32F0xx_DFP   1.2.2     False      
  PY32F031x4    Puya     Puya.PY32F0xx_DFP   1.2.2     False      
  PY32F031x6    Puya     Puya.PY32F0xx_DFP   1.2.2     False      
  PY32F031x7    Puya     Puya.PY32F0xx_DFP   1.2.2     False      
  PY32F031x8    Puya     Puya.PY32F0xx_DFP   1.2.2     False      
  PY32F040Cx6   Puya     Puya.PY32F0xx_DFP   1.2.2     False      
  PY32F040Cx8   Puya     Puya.PY32F0xx_DFP   1.2.2     False      
  PY32F040Cx9   Puya     Puya.PY32F0xx_DFP   1.2.2     False      
  PY32F040CxB   Puya     Puya.PY32F0xx_DFP   1.2.2     False      
  PY32F040Ex6   Puya     Puya.PY32F0xx_DFP   1.2.2     False      
  PY32F040Ex8   Puya     Puya.PY32F0xx_DFP   1.2.2     False      
  PY32F040Ex9   Puya     Puya.PY32F0xx_DFP   1.2.2     False      
  PY32F040ExB   Puya     Puya.PY32F0xx_DFP   1.2.2     False      
  PY32F040x6    Puya     Puya.PY32F0xx_DFP   1.2.2     False      
  PY32F040x8    Puya     Puya.PY32F0xx_DFP   1.2.2     False      
  PY32F040x9    Puya     Puya.PY32F0xx_DFP   1.2.2     False      
  PY32F040xB    Puya     Puya.PY32F0xx_DFP   1.2.2     False      
  PY32F071Cx6   Puya     Puya.PY32F0xx_DFP   1.2.2     False      
  PY32F071Cx8   Puya     Puya.PY32F0xx_DFP   1.2.2     False      
  PY32F071Cx9   Puya     Puya.PY32F0xx_DFP   1.2.2     False      
  PY32F071CxB   Puya     Puya.PY32F0xx_DFP   1.2.2     False      
  PY32F071Ex6   Puya     Puya.PY32F0xx_DFP   1.2.2     False      
  PY32F071Ex8   Puya     Puya.PY32F0xx_DFP   1.2.2     False      
  PY32F071Ex9   Puya     Puya.PY32F0xx_DFP   1.2.2     False      
  PY32F071ExB   Puya     Puya.PY32F0xx_DFP   1.2.2     False      
  PY32F071x6    Puya     Puya.PY32F0xx_DFP   1.2.2     False      
  PY32F071x8    Puya     Puya.PY32F0xx_DFP   1.2.2     False      
  PY32F071x9    Puya     Puya.PY32F0xx_DFP   1.2.2     False      
  PY32F071xB    Puya     Puya.PY32F0xx_DFP   1.2.2     False      
  PY32F072Cx6   Puya     Puya.PY32F0xx_DFP   1.2.2     False      
  PY32F072Cx8   Puya     Puya.PY32F0xx_DFP   1.2.2     False      
  PY32F072Cx9   Puya     Puya.PY32F0xx_DFP   1.2.2     False      
  PY32F072CxB   Puya     Puya.PY32F0xx_DFP   1.2.2     False      
  PY32F072Ex6   Puya     Puya.PY32F0xx_DFP   1.2.2     False      
  PY32F072Ex8   Puya     Puya.PY32F0xx_DFP   1.2.2     False      
  PY32F072Ex9   Puya     Puya.PY32F0xx_DFP   1.2.2     False      
  PY32F072ExB   Puya     Puya.PY32F0xx_DFP   1.2.2     False      
  PY32F072x6    Puya     Puya.PY32F0xx_DFP   1.2.2     False      
  PY32F072x8    Puya     Puya.PY32F0xx_DFP   1.2.2     False      
  PY32F072x9    Puya     Puya.PY32F0xx_DFP   1.2.2     False      
  PY32F072xB    Puya     Puya.PY32F0xx_DFP   1.2.2     False      
  PY32F303x8    Puya     Puya.PY32F3xx_DFP   1.0.0     False      
  PY32F303xB    Puya     Puya.PY32F3xx_DFP   1.0.0     False      
  PY32F303xC    Puya     Puya.PY32F3xx_DFP   1.0.0     False      
  PY32F403xB    Puya     Puya.PY32F4xx_DFP   1.0.1     False      
  PY32F403xC    Puya     Puya.PY32F4xx_DFP   1.0.1     False      
  PY32F403xD    Puya     Puya.PY32F4xx_DFP   1.0.1     False      
  PY32F410xB    Puya     Puya.PY32F4xx_DFP   1.0.1     False      
  PY32L020x5    Puya     Puya.PY32L0xx_DFP   1.0.0     False      
  PY32M010x5    Puya     Puya.PY32Mxxx_DFP   1.0.4     False      
  PY32M020x6    Puya     Puya.PY32Mxxx_DFP   1.0.4     False      
  PY32M030x8    Puya     Puya.PY32Mxxx_DFP   1.0.4     False      
  PY32M031x8    Puya     Puya.PY32Mxxx_DFP   1.0.4     False      
  PY32M070CxB   Puya     Puya.PY32Mxxx_DFP   1.0.4     False      
  PY32M070xB    Puya     Puya.PY32Mxxx_DFP   1.0.4     False      
  PY32MD310x8   Puya     Puya.PY32Mxxx_DFP   1.0.4     False      
  PY32MD320x8   Puya     Puya.PY32Mxxx_DFP   1.0.4     False      
  PY32MD410x8   Puya     Puya.PY32Mxxx_DFP   1.0.4     False      
  PY32MD420x8   Puya     Puya.PY32Mxxx_DFP   1.0.4     False      
  PY32T020Bx6   Puya     Puya.PY32T0xx_DFP   1.0.2     False      
  PY32T020x5    Puya     Puya.PY32T0xx_DFP   1.0.2     False      
  PY32T020x6    Puya     Puya.PY32T0xx_DFP   1.0.2     False      
  PY32T092xC    Puya     Puya.PY32T0xx_DFP   1.0.2     False

インストールパック -i の後に対応する Part 列が続きます

knightli@knightli-py32:~$ pyocd pack -i PY32F002Ax5
Downloading packs (press Control-C to cancel):
    Puya.PY32F0xx_DFP.1.2.2
Downloading descriptors (001/001)

インストールが完了したら、検索を続けます。 1つのパックが複数のパーツに対応していることがわかります。

knightli@knightli-py32:~$ pyocd pack find py32
  Part          Vendor   Pack                Version   Installed  
------------------------------------------------------------------
  PY32E407xC    Puya     Puya.PY32E4xx_DFP   1.0.0     False      
  PY32E407xD    Puya     Puya.PY32E4xx_DFP   1.0.0     False      
  PY32E407xE    Puya     Puya.PY32E4xx_DFP   1.0.0     False      
  PY32F002Ax5   Puya     Puya.PY32F0xx_DFP   1.2.2     True       
  PY32F002Bx5   Puya     Puya.PY32F0xx_DFP   1.2.2     True       
  PY32F002Xx2   Puya     Puya.PY32F0xx_DFP   1.2.2     True       
  PY32F002Xx4   Puya     Puya.PY32F0xx_DFP   1.2.2     True       
  PY32F002Xx5   Puya     Puya.PY32F0xx_DFP   1.2.2     True       
  PY32F003x4    Puya     Puya.PY32F0xx_DFP   1.2.2     True       
  PY32F003x6    Puya     Puya.PY32F0xx_DFP   1.2.2     True       
  PY32F003x7    Puya     Puya.PY32F0xx_DFP   1.2.2     True       
  PY32F003x8    Puya     Puya.PY32F0xx_DFP   1.2.2     True       
  PY32F030x4    Puya     Puya.PY32F0xx_DFP   1.2.2     True       
  PY32F030x6    Puya     Puya.PY32F0xx_DFP   1.2.2     True       
  PY32F030x7    Puya     Puya.PY32F0xx_DFP   1.2.2     True       
  PY32F030x8    Puya     Puya.PY32F0xx_DFP   1.2.2     True       
  PY32F031x4    Puya     Puya.PY32F0xx_DFP   1.2.2     True       
  PY32F031x6    Puya     Puya.PY32F0xx_DFP   1.2.2     True       
  PY32F031x7    Puya     Puya.PY32F0xx_DFP   1.2.2     True       
  PY32F031x8    Puya     Puya.PY32F0xx_DFP   1.2.2     True       
  PY32F040Cx6   Puya     Puya.PY32F0xx_DFP   1.2.2     True       
  PY32F040Cx8   Puya     Puya.PY32F0xx_DFP   1.2.2     True       
  PY32F040Cx9   Puya     Puya.PY32F0xx_DFP   1.2.2     True       
  PY32F040CxB   Puya     Puya.PY32F0xx_DFP   1.2.2     True       
  PY32F040Ex6   Puya     Puya.PY32F0xx_DFP   1.2.2     True       
  PY32F040Ex8   Puya     Puya.PY32F0xx_DFP   1.2.2     True       
  PY32F040Ex9   Puya     Puya.PY32F0xx_DFP   1.2.2     True       
  PY32F040ExB   Puya     Puya.PY32F0xx_DFP   1.2.2     True       
  PY32F040x6    Puya     Puya.PY32F0xx_DFP   1.2.2     True       
  PY32F040x8    Puya     Puya.PY32F0xx_DFP   1.2.2     True       
  PY32F040x9    Puya     Puya.PY32F0xx_DFP   1.2.2     True       
  PY32F040xB    Puya     Puya.PY32F0xx_DFP   1.2.2     True       
  PY32F071Cx6   Puya     Puya.PY32F0xx_DFP   1.2.2     True       
  PY32F071Cx8   Puya     Puya.PY32F0xx_DFP   1.2.2     True       
  PY32F071Cx9   Puya     Puya.PY32F0xx_DFP   1.2.2     True       
  PY32F071CxB   Puya     Puya.PY32F0xx_DFP   1.2.2     True       
  PY32F071Ex6   Puya     Puya.PY32F0xx_DFP   1.2.2     True       
  PY32F071Ex8   Puya     Puya.PY32F0xx_DFP   1.2.2     True       
  PY32F071Ex9   Puya     Puya.PY32F0xx_DFP   1.2.2     True       
  PY32F071ExB   Puya     Puya.PY32F0xx_DFP   1.2.2     True       
  PY32F071x6    Puya     Puya.PY32F0xx_DFP   1.2.2     True       
  PY32F071x8    Puya     Puya.PY32F0xx_DFP   1.2.2     True       
  PY32F071x9    Puya     Puya.PY32F0xx_DFP   1.2.2     True       
  PY32F071xB    Puya     Puya.PY32F0xx_DFP   1.2.2     True       
  PY32F072Cx6   Puya     Puya.PY32F0xx_DFP   1.2.2     True       
  PY32F072Cx8   Puya     Puya.PY32F0xx_DFP   1.2.2     True       
  PY32F072Cx9   Puya     Puya.PY32F0xx_DFP   1.2.2     True       
  PY32F072CxB   Puya     Puya.PY32F0xx_DFP   1.2.2     True       
  PY32F072Ex6   Puya     Puya.PY32F0xx_DFP   1.2.2     True       
  PY32F072Ex8   Puya     Puya.PY32F0xx_DFP   1.2.2     True       
  PY32F072Ex9   Puya     Puya.PY32F0xx_DFP   1.2.2     True       
  PY32F072ExB   Puya     Puya.PY32F0xx_DFP   1.2.2     True       
  PY32F072x6    Puya     Puya.PY32F0xx_DFP   1.2.2     True       
  PY32F072x8    Puya     Puya.PY32F0xx_DFP   1.2.2     True       
  PY32F072x9    Puya     Puya.PY32F0xx_DFP   1.2.2     True       
  PY32F072xB    Puya     Puya.PY32F0xx_DFP   1.2.2     True       
  PY32F303x8    Puya     Puya.PY32F3xx_DFP   1.0.0     False      
  PY32F303xB    Puya     Puya.PY32F3xx_DFP   1.0.0     False      
  PY32F303xC    Puya     Puya.PY32F3xx_DFP   1.0.0     False      
  PY32F403xB    Puya     Puya.PY32F4xx_DFP   1.0.1     False      
  PY32F403xC    Puya     Puya.PY32F4xx_DFP   1.0.1     False      
  PY32F403xD    Puya     Puya.PY32F4xx_DFP   1.0.1     False      
  PY32F410xB    Puya     Puya.PY32F4xx_DFP   1.0.1     False      
  PY32L020x5    Puya     Puya.PY32L0xx_DFP   1.0.0     False      
  PY32M010x5    Puya     Puya.PY32Mxxx_DFP   1.0.4     False      
  PY32M020x6    Puya     Puya.PY32Mxxx_DFP   1.0.4     False      
  PY32M030x8    Puya     Puya.PY32Mxxx_DFP   1.0.4     False      
  PY32M031x8    Puya     Puya.PY32Mxxx_DFP   1.0.4     False      
  PY32M070CxB   Puya     Puya.PY32Mxxx_DFP   1.0.4     False      
  PY32M070xB    Puya     Puya.PY32Mxxx_DFP   1.0.4     False      
  PY32MD310x8   Puya     Puya.PY32Mxxx_DFP   1.0.4     False      
  PY32MD320x8   Puya     Puya.PY32Mxxx_DFP   1.0.4     False      
  PY32MD410x8   Puya     Puya.PY32Mxxx_DFP   1.0.4     False      
  PY32MD420x8   Puya     Puya.PY32Mxxx_DFP   1.0.4     False      
  PY32T020Bx6   Puya     Puya.PY32T0xx_DFP   1.0.2     False      
  PY32T020x5    Puya     Puya.PY32T0xx_DFP   1.0.2     False      
  PY32T020x6    Puya     Puya.PY32T0xx_DFP   1.0.2     False      
  PY32T092xC    Puya     Puya.PY32T0xx_DFP   1.0.2     False

pack show

knightli@knightli-py32:~$ pyocd pack show
  Pack                Version  
-------------------------------
  Puya.PY32F0xx_DFP   1.2.2

チップの消去

knightli@knightli-py32:~/py32f0-template$ pyocd erase -t py32f003x4 -c
0003869 I Erasing chip... [eraser]
0007944 I Chip erase complete [eraser]
knightli@knightli-py32:~/py32f0-template$

フラッシュチップ

knightli@knightli-py32:~/py32f0-template$ pyocd flash -t py32f003x4 Build/app.hex 
0003310 I Loading /home/knightli/py32f0-template/Build/app.hex [load_cmd]
[==================================================] 100%
0047672 I Erased 12288 bytes (3 sectors), programmed 10112 bytes (79 pages), skipped 0 bytes (0 pages) at 0.22 kB/s [loader]

py32f0-template flash

knightli@knightli-py32:~/py32f0-template$ make flash
pyocd erase -t py32f003x4 --chip --config ./Misc/pyocd.yaml
0003761 I Erasing chip... [eraser]
0005480 I Chip erase complete [eraser]
pyocd load Build/app.elf -t py32f003x4 --config ./Misc/pyocd.yaml
0001227 I Loading /home/knightli/py32f0-template/Build/app.elf [load_cmd]
[==================================================] 100%
0043537 I Erased 12288 bytes (3 sectors), programmed 10112 bytes (79 pages), skipped 0 bytes (0 pages) at 0.23 kB/s [loader]
knightli@knightli-py32:~/py32f0-template$ more Misc/pyocd.yaml 
pack:
  - Misc/Puya.PY32F0xx_DFP.1.1.7.pack

Python はそれぞれ zip 形式と 7z 形式を使用して、パスワード付きでフォルダーを圧縮します

Sun, 09 Feb 2025 00:00:00 +0000

zip形式の圧縮

import pyzipper

    with pyzipper.AESZipFile(dest+'.zip', "w", encryption=pyzipper.WZ_AES) as zf:
        zf.setpassword(b"password")
        for file in os.listdir(dest):
            fullfile = os.path.join(dest,file)
            zf.write(fullfile, file)

import pyzipper vs import zipfile
pyzipper と zipfileapi は基本的に同じです
zipfile は解凍時のパスワードの使用のみをサポートしており、パスワード付きの圧縮パッケージの作成はサポートしていません。 pyzipper は、パスワード付きの圧縮パッケージの作成をサポートしています。
zf.write(path1, path2)
path1: 圧縮するファイルのパス
path2: 圧縮後のzipファイル内のパス
pyzipper.AESZipFile
パスワード設定暗号化=pyzipper.WZ_AES AES パスワード zf.setpassword(b"password") パスワードを設定します

7z形式の圧縮

import py7zr

    with py7zr.SevenZipFile(dest + '.7z', 'w', password='password') as archive:
        archive.writeall(dest, '')

archive.writeall(path1, path2)
path1 圧縮するファイルのパス。ディレクトリ全体を指定できます。
path2 は圧縮後の 7z ファイル内のパス、’’ はルートディレクトリを意味します
パスワードを設定する
password=‘password’

ffmpeg トランスコーディング h265、さまざまなエンコーダ、ソフトウェア/ハードウェアの速度比較、CPU/統合グラフィックス/専用グラフィックスのエンコード速度の比較

Fri, 07 Feb 2025 00:00:00 +0000

ビューエンコーダ

ffmpeg -encoders
ffmpeg version 7.0.1-full_build-www.gyan.dev Copyright (c) 2000-2024 the FFmpeg developers
  built with gcc 13.2.0 (Rev5, Built by MSYS2 project)
  configuration: --enable-gpl --enable-version3 --enable-static --disable-w32threads --disable-autodetect --enable-fontconfig --enable-iconv --enable-gnutls --enable-libxml2 --enable-gmp --enable-bzlib --enable-lzma --enable-libsnappy --enable-zlib --enable-librist --enable-libsrt --enable-libssh --enable-libzmq --enable-avisynth --enable-libbluray --enable-libcaca --enable-sdl2 --enable-libaribb24 --enable-libaribcaption --enable-libdav1d --enable-libdavs2 --enable-libuavs3d --enable-libxevd --enable-libzvbi --enable-librav1e --enable-libsvtav1 --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxavs2 --enable-libxeve --enable-libxvid --enable-libaom --enable-libjxl --enable-libopenjpeg --enable-libvpx --enable-mediafoundation --enable-libass --enable-frei0r --enable-libfreetype --enable-libfribidi --enable-libharfbuzz --enable-liblensfun --enable-libvidstab --enable-libvmaf --enable-libzimg --enable-amf --enable-cuda-llvm --enable-cuvid --enable-dxva2 --enable-d3d11va --enable-d3d12va --enable-ffnvcodec --enable-libvpl --enable-nvdec --enable-nvenc --enable-vaapi --enable-libshaderc --enable-vulkan --enable-libplacebo --enable-opencl --enable-libcdio --enable-libgme --enable-libmodplug --enable-libopenmpt --enable-libopencore-amrwb --enable-libmp3lame --enable-libshine --enable-libtheora --enable-libtwolame --enable-libvo-amrwbenc --enable-libcodec2 --enable-libilbc --enable-libgsm --enable-libopencore-amrnb --enable-libopus --enable-libspeex --enable-libvorbis --enable-ladspa --enable-libbs2b --enable-libflite --enable-libmysofa --enable-librubberband --enable-libsoxr --enable-chromaprint
  libavutil      59.  8.100 / 59.  8.100
  libavcodec     61.  3.100 / 61.  3.100
  libavformat    61.  1.100 / 61.  1.100
  libavdevice    61.  1.100 / 61.  1.100
  libavfilter    10.  1.100 / 10.  1.100
  libswscale      8.  1.100 /  8.  1.100
  libswresample   5.  1.100 /  5.  1.100
  libpostproc    58.  1.100 / 58.  1.100
Encoders:
 V..... = Video
 A..... = Audio
 S..... = Subtitle
 .F.... = Frame-level multithreading
 ..S... = Slice-level multithreading
 ...X.. = Codec is experimental
 ....B. = Supports draw_horiz_band
 .....D = Supports direct rendering method 1
 ------
 V....D a64multi             Multicolor charset for Commodore 64 (codec a64_multi)
 V....D a64multi5            Multicolor charset for Commodore 64, extended with 5th color (colram) (codec a64_multi5)
 V....D alias_pix            Alias/Wavefront PIX image
 V..... amv                  AMV Video
 V....D apng                 APNG (Animated Portable Network Graphics) image
 V....D asv1                 ASUS V1
 V....D asv2                 ASUS V2
 V....D libaom-av1           libaom AV1 (codec av1)
 V....D librav1e             librav1e AV1 (codec av1)
 V..... libsvtav1            SVT-AV1(Scalable Video Technology for AV1) encoder (codec av1)
 V....D av1_nvenc            NVIDIA NVENC av1 encoder (codec av1)
 V..... av1_qsv              AV1 (Intel Quick Sync Video acceleration) (codec av1)
 V....D av1_amf              AMD AMF AV1 encoder (codec av1)
 V....D av1_vaapi            AV1 (VAAPI) (codec av1)
 V....D avrp                 Avid 1:1 10-bit RGB Packer
 V....D libxavs2             libxavs2 AVS2-P2/IEEE1857.4 (codec avs2)
 V..X.D avui                 Avid Meridien Uncompressed
 VF...D bitpacked            Bitpacked
 V....D bmp                  BMP (Windows and OS/2 bitmap)
 VF...D cfhd                 GoPro CineForm HD
 V....D cinepak              Cinepak
 V....D cljr                 Cirrus Logic AccuPak
 V.S..D vc2                  SMPTE VC-2 (codec dirac)
 VFS..D dnxhd                VC3/DNxHD
 V....D dpx                  DPX (Digital Picture Exchange) image
 VFS..D dvvideo              DV (Digital Video)
 VFS..D dxv                  Resolume DXV
 V....D libxeve              libxeve MPEG-5 EVC (codec evc)
 VF...D exr                  OpenEXR image
 V.S..D ffv1                 FFmpeg video codec #1
 VF...D ffvhuff              Huffyuv FFmpeg variant
 V....D fits                 Flexible Image Transport System
 V....D flashsv              Flash Screen Video
 V....D flashsv2             Flash Screen Video Version 2
 V..... flv                  FLV / Sorenson Spark / Sorenson H.263 (Flash Video) (codec flv1)
 V....D gif                  GIF (Graphics Interchange Format)
 V..... h261                 H.261
 V..... h263                 H.263 / H.263-1996
 V.S... h263p                H.263+ / H.263-1998 / H.263 version 2
 V....D libx264              libx264 H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 (codec h264)
 V....D libx264rgb           libx264 H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 RGB (codec h264)
 V....D h264_amf             AMD AMF H.264 Encoder (codec h264)
 V....D h264_mf              H264 via MediaFoundation (codec h264)
 V....D h264_nvenc           NVIDIA NVENC H.264 encoder (codec h264)
 V..... h264_qsv             H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 (Intel Quick Sync Video acceleration) (codec h264)
 V....D h264_vaapi           H.264/AVC (VAAPI) (codec h264)
 V.S..D hap                  Vidvox Hap
 VF...D hdr                  HDR (Radiance RGBE format) image
 V....D libx265              libx265 H.265 / HEVC (codec hevc)
 V....D hevc_amf             AMD AMF HEVC encoder (codec hevc)
 V....D hevc_mf              HEVC via MediaFoundation (codec hevc)
 V....D hevc_nvenc           NVIDIA NVENC hevc encoder (codec hevc)
 V..... hevc_qsv             HEVC (Intel Quick Sync Video acceleration) (codec hevc)
 V....D hevc_vaapi           H.265/HEVC (VAAPI) (codec hevc)
 VF...D huffyuv              Huffyuv / HuffYUV
 VF...D jpeg2000             JPEG 2000
 VF.... libopenjpeg          OpenJPEG JPEG 2000 (codec jpeg2000)
 VF...D jpegls               JPEG-LS
 V....D libjxl               libjxl JPEG XL (codec jpegxl)
 VF...D ljpeg                Lossless JPEG
 VFS..D magicyuv             MagicYUV video
 VFS... mjpeg                MJPEG (Motion JPEG)
 V..... mjpeg_qsv            MJPEG (Intel Quick Sync Video acceleration) (codec mjpeg)
 V....D mjpeg_vaapi          MJPEG (VAAPI) (codec mjpeg)
 V.S... mpeg1video           MPEG-1 video
 V.S... mpeg2video           MPEG-2 video
 V..... mpeg2_qsv            MPEG-2 video (Intel Quick Sync Video acceleration) (codec mpeg2video)
 V....D mpeg2_vaapi          MPEG-2 (VAAPI) (codec mpeg2video)
 V.S... mpeg4                MPEG-4 part 2
 V....D libxvid              libxvidcore MPEG-4 part 2 (codec mpeg4)
 V..... msmpeg4v2            MPEG-4 part 2 Microsoft variant version 2
 V..... msmpeg4              MPEG-4 part 2 Microsoft variant version 3 (codec msmpeg4v3)
 V....D msrle                Microsoft RLE
 V..... msvideo1             Microsoft Video-1
 V....D pam                  PAM (Portable AnyMap) image
 V....D pbm                  PBM (Portable BitMap) image
 V....D pcx                  PC Paintbrush PCX image
 V....D pfm                  PFM (Portable FloatMap) image
 V....D pgm                  PGM (Portable GrayMap) image
 V....D pgmyuv               PGMYUV (Portable GrayMap YUV) image
 V....D phm                  PHM (Portable HalfFloatMap) image
 VF...D png                  PNG (Portable Network Graphics) image
 V....D ppm                  PPM (Portable PixelMap) image
 VF...D prores               Apple ProRes
 VF...D prores_aw            Apple ProRes (codec prores)
 VFS... prores_ks            Apple ProRes (iCodec Pro) (codec prores)
 VF...D qoi                  QOI (Quite OK Image format) image
 V....D qtrle                QuickTime Animation (RLE) video
 V....D r10k                 AJA Kona 10-bit RGB Codec
 V....D r210                 Uncompressed RGB 10-bit
 VF...D rawvideo             raw video
 V....D roqvideo             id RoQ video (codec roq)
 V....D rpza                 QuickTime video (RPZA)
 V..... rv10                 RealVideo 1.0
 V..... rv20                 RealVideo 2.0
 V....D sgi                  SGI image
 V....D smc                  QuickTime Graphics (SMC)
 V....D snow                 Snow
 V..... speedhq              NewTek SpeedHQ
 V....D sunrast              Sun Rasterfile image
 V....D svq1                 Sorenson Vector Quantizer 1 / Sorenson Video 1 / SVQ1
 V....D targa                Truevision Targa image
 V....D libtheora            libtheora Theora (codec theora)
 VF...D tiff                 TIFF image
 VF...D utvideo              Ut Video
 VF...D v210                 Uncompressed 4:2:2 10-bit
 V....D v308                 Uncompressed packed 4:4:4
 V....D v408                 Uncompressed packed QT 4:4:4:4
 V....D v410                 Uncompressed 4:4:4 10-bit
 V.S..D vbn                  Vizrt Binary Image
 V..... vnull                null video
 V....D libvpx               libvpx VP8 (codec vp8)
 V....D vp8_vaapi            VP8 (VAAPI) (codec vp8)
 V....D libvpx-vp9           libvpx VP9 (codec vp9)
 V....D vp9_vaapi            VP9 (VAAPI) (codec vp9)
 V..... vp9_qsv              VP9 video (Intel Quick Sync Video acceleration) (codec vp9)
 VF...D wbmp                 WBMP (Wireless Application Protocol Bitmap) image
 V....D libwebp_anim         libwebp WebP image (codec webp)
 V....D libwebp              libwebp WebP image (codec webp)
 V..... wmv1                 Windows Media Video 7
 V..... wmv2                 Windows Media Video 8
 V..... wrapped_avframe      AVFrame to AVPacket passthrough
 V....D xbm                  XBM (X BitMap) image
 V....D xface                X-face image
 V....D xwd                  XWD (X Window Dump) image
 V....D y41p                 Uncompressed YUV 4:1:1 12-bit
 V....D yuv4                 Uncompressed packed 4:2:0
 VF...D zlib                 LCL (LossLess Codec Library) ZLIB
 V....D zmbv                 Zip Motion Blocks Video
 A....D aac                  AAC (Advanced Audio Coding)
 A....D aac_mf               AAC via MediaFoundation (codec aac)
 A....D ac3                  ATSC A/52A (AC-3)
 A....D ac3_fixed            ATSC A/52A (AC-3) (codec ac3)
 A....D ac3_mf               AC3 via MediaFoundation (codec ac3)
 A....D adpcm_adx            SEGA CRI ADX ADPCM
 A....D adpcm_argo           ADPCM Argonaut Games
 A....D g722                 G.722 ADPCM (codec adpcm_g722)
 A....D g726                 G.726 ADPCM (codec adpcm_g726)
 A....D g726le               G.726 little endian ADPCM ("right-justified") (codec adpcm_g726le)
 A....D adpcm_ima_alp        ADPCM IMA High Voltage Software ALP
 A....D adpcm_ima_amv        ADPCM IMA AMV
 A....D adpcm_ima_apm        ADPCM IMA Ubisoft APM
 A....D adpcm_ima_qt         ADPCM IMA QuickTime
 A....D adpcm_ima_ssi        ADPCM IMA Simon & Schuster Interactive
 A....D adpcm_ima_wav        ADPCM IMA WAV
 A....D adpcm_ima_ws         ADPCM IMA Westwood
 A....D adpcm_ms             ADPCM Microsoft
 A....D adpcm_swf            ADPCM Shockwave Flash
 A....D adpcm_yamaha         ADPCM Yamaha
 A....D alac                 ALAC (Apple Lossless Audio Codec)
 A....D libopencore_amrnb    OpenCORE AMR-NB (Adaptive Multi-Rate Narrow-Band) (codec amr_nb)
 A....D libvo_amrwbenc       Android VisualOn AMR-WB (Adaptive Multi-Rate Wide-Band) (codec amr_wb)
 A..... anull                null audio
 A....D aptx                 aptX (Audio Processing Technology for Bluetooth)
 A....D aptx_hd              aptX HD (Audio Processing Technology for Bluetooth)
 A....D libcodec2            codec2 encoder using libcodec2 (codec codec2)
 A....D comfortnoise         RFC 3389 comfort noise generator
 A....D dfpwm                DFPWM1a audio
 A..X.D dca                  DCA (DTS Coherent Acoustics) (codec dts)
 A....D eac3                 ATSC A/52 E-AC-3
 A....D flac                 FLAC (Free Lossless Audio Codec)
 A....D g723_1               G.723.1
 A....D libgsm               libgsm GSM (codec gsm)
 A....D libgsm_ms            libgsm GSM Microsoft variant (codec gsm_ms)
 A....D libilbc              iLBC (Internet Low Bitrate Codec) (codec ilbc)
 A..X.D mlp                  MLP (Meridian Lossless Packing)
 A....D mp2                  MP2 (MPEG audio layer 2)
 A....D mp2fixed             MP2 fixed point (MPEG audio layer 2) (codec mp2)
 A....D libtwolame           libtwolame MP2 (MPEG audio layer 2) (codec mp2)
 A....D libmp3lame           libmp3lame MP3 (MPEG audio layer 3) (codec mp3)
 A....D libshine             libshine MP3 (MPEG audio layer 3) (codec mp3)
 A....D mp3_mf               MP3 via MediaFoundation (codec mp3)
 A....D nellymoser           Nellymoser Asao
 A..X.D opus                 Opus
 A....D libopus              libopus Opus (codec opus)
 A....D pcm_alaw             PCM A-law / G.711 A-law
 A....D pcm_bluray           PCM signed 16|20|24-bit big-endian for Blu-ray media
 A....D pcm_dvd              PCM signed 16|20|24-bit big-endian for DVD media
 A....D pcm_f32be            PCM 32-bit floating point big-endian
 A....D pcm_f32le            PCM 32-bit floating point little-endian
 A....D pcm_f64be            PCM 64-bit floating point big-endian
 A....D pcm_f64le            PCM 64-bit floating point little-endian
 A....D pcm_mulaw            PCM mu-law / G.711 mu-law
 A....D pcm_s16be            PCM signed 16-bit big-endian
 A....D pcm_s16be_planar     PCM signed 16-bit big-endian planar
 A....D pcm_s16le            PCM signed 16-bit little-endian
 A....D pcm_s16le_planar     PCM signed 16-bit little-endian planar
 A....D pcm_s24be            PCM signed 24-bit big-endian
 A....D pcm_s24daud          PCM D-Cinema audio signed 24-bit
 A....D pcm_s24le            PCM signed 24-bit little-endian
 A....D pcm_s24le_planar     PCM signed 24-bit little-endian planar
 A....D pcm_s32be            PCM signed 32-bit big-endian
 A....D pcm_s32le            PCM signed 32-bit little-endian
 A....D pcm_s32le_planar     PCM signed 32-bit little-endian planar
 A....D pcm_s64be            PCM signed 64-bit big-endian
 A....D pcm_s64le            PCM signed 64-bit little-endian
 A....D pcm_s8               PCM signed 8-bit
 A....D pcm_s8_planar        PCM signed 8-bit planar
 A....D pcm_u16be            PCM unsigned 16-bit big-endian
 A....D pcm_u16le            PCM unsigned 16-bit little-endian
 A....D pcm_u24be            PCM unsigned 24-bit big-endian
 A....D pcm_u24le            PCM unsigned 24-bit little-endian
 A....D pcm_u32be            PCM unsigned 32-bit big-endian
 A....D pcm_u32le            PCM unsigned 32-bit little-endian
 A....D pcm_u8               PCM unsigned 8-bit
 A....D pcm_vidc             PCM Archimedes VIDC
 A....D real_144             RealAudio 1.0 (14.4K) (codec ra_144)
 A....D roq_dpcm             id RoQ DPCM
 A..X.D s302m                SMPTE 302M
 A....D sbc                  SBC (low-complexity subband codec)
 A..X.D sonic                Sonic
 A..X.D sonicls              Sonic lossless
 A....D libspeex             libspeex Speex (codec speex)
 A..X.D truehd               TrueHD
 A....D tta                  TTA (True Audio)
 A..X.D vorbis               Vorbis
 A....D libvorbis            libvorbis (codec vorbis)
 A....D wavpack              WavPack
 A....D wmav1                Windows Media Audio 1
 A....D wmav2                Windows Media Audio 2
 S..... ssa                  ASS (Advanced SubStation Alpha) subtitle (codec ass)
 S..... ass                  ASS (Advanced SubStation Alpha) subtitle
 S..... dvbsub               DVB subtitles (codec dvb_subtitle)
 S..... dvdsub               DVD subtitles (codec dvd_subtitle)
 S..... mov_text             3GPP Timed Text subtitle
 S..... srt                  SubRip subtitle (codec subrip)
 S..... subrip               SubRip subtitle
 S..... text                 Raw text subtitle
 S..... ttml                 TTML subtitle
 S..... webvtt               WebVTT subtitle
 S..... xsub                 DivX subtitles (XSUB)

この段落に注意してください。hevc_ プレフィックスは、H.265 エンコーディングに適していることを意味します。

 V....D libx265              libx265 H.265 / HEVC (codec hevc)
 V....D hevc_amf             AMD AMF HEVC encoder (codec hevc)
 V....D hevc_mf              HEVC via MediaFoundation (codec hevc)
 V....D hevc_nvenc           NVIDIA NVENC hevc encoder (codec hevc)
 V..... hevc_qsv             HEVC (Intel Quick Sync Video acceleration) (codec hevc)
 V....D hevc_vaapi           H.265/HEVC (VAAPI) (codec hevc)

Windows システムで利用可能なハードウェアエンコーディング:

libx265 : 默认hevc编码器, 使用CPU编码
hevc_nvenc : Nvidia 硬件编码器
hevc_amf : AMD显卡硬件编码器
hevc_qsv : Intel 硬件编码器

Linux システムで使用できるハードウェアエンコーディング:

1
2
3

libx265 : 默认hevc编码器, 使用CPU编码
hevc_vaapi : Intel 硬件编码器
hevc_nvenc nvenc_hevc : Nvidia 硬件编码器

MacOS システムで利用可能なハードウェアエンコーディング:

1
2
3

libx265 : 默认hevc编码器, 使用CPU编码
hevc_videotoolbox : Intel 硬件编码器
hevc_videotoolbox : Apple Silicon硬件加速

別のビデオエンコーダを使用し、エンコードに別のハードウェアを使用する場合は、-c:v を指定します。たとえば、次のコマンドは Nvidia ハードウェアエンコーダを指定します。

`1`	`ffmpeg -i 1.mp4 -c:v hevc_nvenc out.mp4`

同じ動画の簡易比較テスト

AMD 7840H CPU エンコーディング

ffmpeg -i t.mp4 -c:v libx265 o1.mp4
ffmpeg version 7.0.1-full_build-www.gyan.dev Copyright (c) 2000-2024 the FFmpeg developers
  built with gcc 13.2.0 (Rev5, Built by MSYS2 project)
  configuration: --enable-gpl --enable-version3 --enable-static --disable-w32threads --disable-autodetect --enable-fontconfig --enable-iconv --enable-gnutls --enable-libxml2 --enable-gmp --enable-bzlib --enable-lzma --enable-libsnappy --enable-zlib --enable-librist --enable-libsrt --enable-libssh --enable-libzmq --enable-avisynth --enable-libbluray --enable-libcaca --enable-sdl2 --enable-libaribb24 --enable-libaribcaption --enable-libdav1d --enable-libdavs2 --enable-libuavs3d --enable-libxevd --enable-libzvbi --enable-librav1e --enable-libsvtav1 --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxavs2 --enable-libxeve --enable-libxvid --enable-libaom --enable-libjxl --enable-libopenjpeg --enable-libvpx --enable-mediafoundation --enable-libass --enable-frei0r --enable-libfreetype --enable-libfribidi --enable-libharfbuzz --enable-liblensfun --enable-libvidstab --enable-libvmaf --enable-libzimg --enable-amf --enable-cuda-llvm --enable-cuvid --enable-dxva2 --enable-d3d11va --enable-d3d12va --enable-ffnvcodec --enable-libvpl --enable-nvdec --enable-nvenc --enable-vaapi --enable-libshaderc --enable-vulkan --enable-libplacebo --enable-opencl --enable-libcdio --enable-libgme --enable-libmodplug --enable-libopenmpt --enable-libopencore-amrwb --enable-libmp3lame --enable-libshine --enable-libtheora --enable-libtwolame --enable-libvo-amrwbenc --enable-libcodec2 --enable-libilbc --enable-libgsm --enable-libopencore-amrnb --enable-libopus --enable-libspeex --enable-libvorbis --enable-ladspa --enable-libbs2b --enable-libflite --enable-libmysofa --enable-librubberband --enable-libsoxr --enable-chromaprint
  libavutil      59.  8.100 / 59.  8.100
  libavcodec     61.  3.100 / 61.  3.100
  libavformat    61.  1.100 / 61.  1.100
  libavdevice    61.  1.100 / 61.  1.100
  libavfilter    10.  1.100 / 10.  1.100
  libswscale      8.  1.100 /  8.  1.100
  libswresample   5.  1.100 /  5.  1.100
  libpostproc    58.  1.100 / 58.  1.100
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 't.mp4':
  Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2avc1mp41
    encoder         : Lavf58.33.100
  Duration: 00:38:56.60, start: 0.000000, bitrate: 284 kb/s
  Stream #0:0[0x1](und): Video: h264 (High) (avc1 / 0x31637661), yuv420p(progressive), 1280x720 [SAR 1:1 DAR 16:9], 148 kb/s, 25 fps, 25 tbr, 12800 tbn (default)
      Metadata:
        handler_name    : VideoHandler
        vendor_id       : [0][0][0][0]
  Stream #0:1[0x2](und): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 128 kb/s (default)
      Metadata:
        handler_name    : SoundHandler
        vendor_id       : [0][0][0][0]
Stream mapping:
  Stream #0:0 -> #0:0 (h264 (native) -> hevc (libx265))
  Stream #0:1 -> #0:1 (aac (native) -> aac (native))
Press [q] to stop, [?] for help
x265 [info]: HEVC encoder version 3.6+28-8f16d2257
x265 [info]: build info [Windows][GCC 14.1.0][64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
x265 [info]: Main profile, Level-3.1 (Main tier)
x265 [info]: Thread pool created using 16 threads
x265 [info]: Slices                              : 1
x265 [info]: frame threads / pool features       : 4 / wpp(12 rows)
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra
x265 [info]: ME / range / subpel / merge         : hex / 57 / 2 / 3
x265 [info]: Keyframe min / max / scenecut / bias  : 25 / 250 / 40 / 5.00
x265 [info]: Lookahead / bframes / badapt        : 20 / 4 / 2
x265 [info]: b-pyramid / weightp / weightb       : 1 / 1 / 0
x265 [info]: References / ref-limit  cu / depth  : 3 / off / on
x265 [info]: AQ: mode / str / qg-size / cu-tree  : 2 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress            : CRF-28.0 / 0.60
x265 [info]: tools: rd=3 psy-rd=2.00 early-skip rskip mode=1 signhide tmvp
x265 [info]: tools: b-intra strong-intra-smoothing lslices=4 deblock sao
Output #0, mp4, to 'o1.mp4':
  Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2avc1mp41
    encoder         : Lavf61.1.100
  Stream #0:0(und): Video: hevc (hev1 / 0x31766568), yuv420p(progressive), 1280x720 [SAR 1:1 DAR 16:9], q=2-31, 25 fps, 12800 tbn (default)
      Metadata:
        handler_name    : VideoHandler
        vendor_id       : [0][0][0][0]
        encoder         : Lavc61.3.100 libx265
      Side data:
        cpb: bitrate max/min/avg: 0/0/0 buffer size: 0 vbv_delay: N/A
  Stream #0:1(und): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 128 kb/s (default)
      Metadata:
        handler_name    : SoundHandler
        vendor_id       : [0][0][0][0]
        encoder         : Lavc61.3.100 aac
frame= 1259 fps= 66 q=35.8 size=    1280KiB time=00:00:50.28 bitrate= 208.6kbits/s speed=2.63x

速度は 2 ～ 4 の間で変動します。このデータには何か問題があるのではないでしょうか?私のシステムに問題があるのかもしれません。

AMD 7840H GPU 統合グラフィックスエンコーディング

ffmpeg -i t.mp4 -c:v hevc_amf o2.mp4
ffmpeg version 7.0.1-full_build-www.gyan.dev Copyright (c) 2000-2024 the FFmpeg developers
  built with gcc 13.2.0 (Rev5, Built by MSYS2 project)
  configuration: --enable-gpl --enable-version3 --enable-static --disable-w32threads --disable-autodetect --enable-fontconfig --enable-iconv --enable-gnutls --enable-libxml2 --enable-gmp --enable-bzlib --enable-lzma --enable-libsnappy --enable-zlib --enable-librist --enable-libsrt --enable-libssh --enable-libzmq --enable-avisynth --enable-libbluray --enable-libcaca --enable-sdl2 --enable-libaribb24 --enable-libaribcaption --enable-libdav1d --enable-libdavs2 --enable-libuavs3d --enable-libxevd --enable-libzvbi --enable-librav1e --enable-libsvtav1 --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxavs2 --enable-libxeve --enable-libxvid --enable-libaom --enable-libjxl --enable-libopenjpeg --enable-libvpx --enable-mediafoundation --enable-libass --enable-frei0r --enable-libfreetype --enable-libfribidi --enable-libharfbuzz --enable-liblensfun --enable-libvidstab --enable-libvmaf --enable-libzimg --enable-amf --enable-cuda-llvm --enable-cuvid --enable-dxva2 --enable-d3d11va --enable-d3d12va --enable-ffnvcodec --enable-libvpl --enable-nvdec --enable-nvenc --enable-vaapi --enable-libshaderc --enable-vulkan --enable-libplacebo --enable-opencl --enable-libcdio --enable-libgme --enable-libmodplug --enable-libopenmpt --enable-libopencore-amrwb --enable-libmp3lame --enable-libshine --enable-libtheora --enable-libtwolame --enable-libvo-amrwbenc --enable-libcodec2 --enable-libilbc --enable-libgsm --enable-libopencore-amrnb --enable-libopus --enable-libspeex --enable-libvorbis --enable-ladspa --enable-libbs2b --enable-libflite --enable-libmysofa --enable-librubberband --enable-libsoxr --enable-chromaprint
  libavutil      59.  8.100 / 59.  8.100
  libavcodec     61.  3.100 / 61.  3.100
  libavformat    61.  1.100 / 61.  1.100
  libavdevice    61.  1.100 / 61.  1.100
  libavfilter    10.  1.100 / 10.  1.100
  libswscale      8.  1.100 /  8.  1.100
  libswresample   5.  1.100 /  5.  1.100
  libpostproc    58.  1.100 / 58.  1.100
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 't.mp4':
  Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2avc1mp41
    encoder         : Lavf58.33.100
  Duration: 00:38:56.60, start: 0.000000, bitrate: 284 kb/s
  Stream #0:0[0x1](und): Video: h264 (High) (avc1 / 0x31637661), yuv420p(progressive), 1280x720 [SAR 1:1 DAR 16:9], 148 kb/s, 25 fps, 25 tbr, 12800 tbn (default)
      Metadata:
        handler_name    : VideoHandler
        vendor_id       : [0][0][0][0]
  Stream #0:1[0x2](und): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 128 kb/s (default)
      Metadata:
        handler_name    : SoundHandler
        vendor_id       : [0][0][0][0]
Stream mapping:
  Stream #0:0 -> #0:0 (h264 (native) -> hevc (hevc_amf))
  Stream #0:1 -> #0:1 (aac (native) -> aac (native))
Press [q] to stop, [?] for help
Output #0, mp4, to 'o2.mp4':
  Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2avc1mp41
    encoder         : Lavf61.1.100
  Stream #0:0(und): Video: hevc (hev1 / 0x31766568), yuv420p(progressive), 1280x720 [SAR 1:1 DAR 16:9], q=2-31, 2000 kb/s, 25 fps, 12800 tbn (default)
      Metadata:
        handler_name    : VideoHandler
        vendor_id       : [0][0][0][0]
        encoder         : Lavc61.3.100 hevc_amf
  Stream #0:1(und): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 128 kb/s (default)
      Metadata:
        handler_name    : SoundHandler
        vendor_id       : [0][0][0][0]
        encoder         : Lavc61.3.100 aac
[out#0/mp4 @ 000002924b008480] video:26548KiB audio:6235KiB subtitle:0KiB other streams:0KiB global headers:0KiB muxing overhead: 0.774909%
frame= 9834 fps=903 q=-0.0 Lsize=   33036KiB time=00:06:33.20 bitrate= 688.3kbits/s dup=2 drop=0 speed=36.1x

速度は30〜40の間で変動します

I7 13620H CPUエンコーディング

ffmpeg -i t.mp4 -c:v libx265 o1.mp4
ffmpeg version 7.1-full_build-www.gyan.dev Copyright (c) 2000-2024 the FFmpeg developers
  built with gcc 14.2.0 (Rev1, Built by MSYS2 project)
  configuration: --enable-gpl --enable-version3 --enable-static --disable-w32threads --disable-autodetect --enable-fontconfig --enable-iconv --enable-gnutls --enable-libxml2 --enable-gmp --enable-bzlib --enable-lzma --enable-libsnappy --enable-zlib --enable-librist --enable-libsrt --enable-libssh --enable-libzmq --enable-avisynth --enable-libbluray --enable-libcaca --enable-sdl2 --enable-libaribb24 --enable-libaribcaption --enable-libdav1d --enable-libdavs2 --enable-libopenjpeg --enable-libquirc --enable-libuavs3d --enable-libxevd --enable-libzvbi --enable-libqrencode --enable-librav1e --enable-libsvtav1 --enable-libvvenc --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxavs2 --enable-libxeve --enable-libxvid --enable-libaom --enable-libjxl --enable-libvpx --enable-mediafoundation --enable-libass --enable-frei0r --enable-libfreetype --enable-libfribidi --enable-libharfbuzz --enable-liblensfun --enable-libvidstab --enable-libvmaf --enable-libzimg --enable-amf --enable-cuda-llvm --enable-cuvid --enable-dxva2 --enable-d3d11va --enable-d3d12va --enable-ffnvcodec --enable-libvpl --enable-nvdec --enable-nvenc --enable-vaapi --enable-libshaderc --enable-vulkan --enable-libplacebo --enable-opencl --enable-libcdio --enable-libgme --enable-libmodplug --enable-libopenmpt --enable-libopencore-amrwb --enable-libmp3lame --enable-libshine --enable-libtheora --enable-libtwolame --enable-libvo-amrwbenc --enable-libcodec2 --enable-libilbc --enable-libgsm --enable-liblc3 --enable-libopencore-amrnb --enable-libopus --enable-libspeex --enable-libvorbis --enable-ladspa --enable-libbs2b --enable-libflite --enable-libmysofa --enable-librubberband --enable-libsoxr --enable-chromaprint
  libavutil      59. 39.100 / 59. 39.100
  libavcodec     61. 19.100 / 61. 19.100
  libavformat    61.  7.100 / 61.  7.100
  libavdevice    61.  3.100 / 61.  3.100
  libavfilter    10.  4.100 / 10.  4.100
  libswscale      8.  3.100 /  8.  3.100
  libswresample   5.  3.100 /  5.  3.100
  libpostproc    58.  3.100 / 58.  3.100
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 't.mp4':
  Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2avc1mp41
    encoder         : Lavf58.33.100
  Duration: 00:38:56.60, start: 0.000000, bitrate: 284 kb/s
  Stream #0:0[0x1](und): Video: h264 (High) (avc1 / 0x31637661), yuv420p(progressive), 1280x720 [SAR 1:1 DAR 16:9], 148 kb/s, 25 fps, 25 tbr, 12800 tbn (default)
      Metadata:
        handler_name    : VideoHandler
        vendor_id       : [0][0][0][0]
  Stream #0:1[0x2](und): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 128 kb/s (default)
      Metadata:
        handler_name    : SoundHandler
        vendor_id       : [0][0][0][0]
Stream mapping:
  Stream #0:0 -> #0:0 (h264 (native) -> hevc (libx265))
  Stream #0:1 -> #0:1 (aac (native) -> aac (native))
Press [q] to stop, [?] for help
x265 [info]: HEVC encoder version 4.0+6-a069836f3
x265 [info]: build info [Windows][GCC 14.2.0][64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
x265 [info]: Main profile, Level-3.1 (Main tier)
x265 [info]: Thread pool created using 16 threads
x265 [info]: Slices                              : 1
x265 [info]: frame threads / pool features       : 4 / wpp(12 rows)
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra
x265 [info]: ME / range / subpel / merge         : hex / 57 / 2 / 3
x265 [info]: Keyframe min / max / scenecut / bias  : 25 / 250 / 40 / 5.00
x265 [info]: Lookahead / bframes / badapt        : 20 / 4 / 2
x265 [info]: b-pyramid / weightp / weightb       : 1 / 1 / 0
x265 [info]: References / ref-limit  cu / depth  : 3 / off / on
x265 [info]: AQ: mode / str / qg-size / cu-tree  : 2 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress            : CRF-28.0 / 0.60
x265 [info]: tools: rd=3 psy-rd=2.00 early-skip rskip mode=1 signhide tmvp
x265 [info]: tools: b-intra strong-intra-smoothing lslices=4 deblock sao
Output #0, mp4, to 'o1.mp4':
  Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2avc1mp41
    encoder         : Lavf61.7.100
  Stream #0:0(und): Video: hevc (hev1 / 0x31766568), yuv420p(tv, progressive), 1280x720 [SAR 1:1 DAR 16:9], q=2-31, 25 fps, 12800 tbn (default)
      Metadata:
        handler_name    : VideoHandler
        vendor_id       : [0][0][0][0]
        encoder         : Lavc61.19.100 libx265
      Side data:
        cpb: bitrate max/min/avg: 0/0/0 buffer size: 0 vbv_delay: N/A
  Stream #0:1(und): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 128 kb/s (default)
      Metadata:
        handler_name    : SoundHandler
        vendor_id       : [0][0][0][0]
        encoder         : Lavc61.19.100 aac
[out#0/mp4 @ 00000121f66deb40] video:3922KiB audio:4961KiB subtitle:0KiB other streams:0KiB global headers:2KiB muxing overhead: 3.049582%
frame= 7823 fps=308 q=35.8 Lsize=    9154KiB time=00:05:12.84 bitrate= 239.7kbits/s speed=12.3x

スピードは12～13くらい

I7 13620H GPU エンコーディング

ffmpeg -i t.mp4 -c:v hevc_qsv o2.mp4
ffmpeg version 7.1-full_build-www.gyan.dev Copyright (c) 2000-2024 the FFmpeg developers
  built with gcc 14.2.0 (Rev1, Built by MSYS2 project)
  configuration: --enable-gpl --enable-version3 --enable-static --disable-w32threads --disable-autodetect --enable-fontconfig --enable-iconv --enable-gnutls --enable-libxml2 --enable-gmp --enable-bzlib --enable-lzma --enable-libsnappy --enable-zlib --enable-librist --enable-libsrt --enable-libssh --enable-libzmq --enable-avisynth --enable-libbluray --enable-libcaca --enable-sdl2 --enable-libaribb24 --enable-libaribcaption --enable-libdav1d --enable-libdavs2 --enable-libopenjpeg --enable-libquirc --enable-libuavs3d --enable-libxevd --enable-libzvbi --enable-libqrencode --enable-librav1e --enable-libsvtav1 --enable-libvvenc --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxavs2 --enable-libxeve --enable-libxvid --enable-libaom --enable-libjxl --enable-libvpx --enable-mediafoundation --enable-libass --enable-frei0r --enable-libfreetype --enable-libfribidi --enable-libharfbuzz --enable-liblensfun --enable-libvidstab --enable-libvmaf --enable-libzimg --enable-amf --enable-cuda-llvm --enable-cuvid --enable-dxva2 --enable-d3d11va --enable-d3d12va --enable-ffnvcodec --enable-libvpl --enable-nvdec --enable-nvenc --enable-vaapi --enable-libshaderc --enable-vulkan --enable-libplacebo --enable-opencl --enable-libcdio --enable-libgme --enable-libmodplug --enable-libopenmpt --enable-libopencore-amrwb --enable-libmp3lame --enable-libshine --enable-libtheora --enable-libtwolame --enable-libvo-amrwbenc --enable-libcodec2 --enable-libilbc --enable-libgsm --enable-liblc3 --enable-libopencore-amrnb --enable-libopus --enable-libspeex --enable-libvorbis --enable-ladspa --enable-libbs2b --enable-libflite --enable-libmysofa --enable-librubberband --enable-libsoxr --enable-chromaprint
  libavutil      59. 39.100 / 59. 39.100
  libavcodec     61. 19.100 / 61. 19.100
  libavformat    61.  7.100 / 61.  7.100
  libavdevice    61.  3.100 / 61.  3.100
  libavfilter    10.  4.100 / 10.  4.100
  libswscale      8.  3.100 /  8.  3.100
  libswresample   5.  3.100 /  5.  3.100
  libpostproc    58.  3.100 / 58.  3.100
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 't.mp4':
  Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2avc1mp41
    encoder         : Lavf58.33.100
  Duration: 00:38:56.60, start: 0.000000, bitrate: 284 kb/s
  Stream #0:0[0x1](und): Video: h264 (High) (avc1 / 0x31637661), yuv420p(progressive), 1280x720 [SAR 1:1 DAR 16:9], 148 kb/s, 25 fps, 25 tbr, 12800 tbn (default)
      Metadata:
        handler_name    : VideoHandler
        vendor_id       : [0][0][0][0]
  Stream #0:1[0x2](und): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 128 kb/s (default)
      Metadata:
        handler_name    : SoundHandler
        vendor_id       : [0][0][0][0]
Stream mapping:
  Stream #0:0 -> #0:0 (h264 (native) -> hevc (hevc_qsv))
  Stream #0:1 -> #0:1 (aac (native) -> aac (native))
Press [q] to stop, [?] for help
[hevc_qsv @ 000001d85b080680] Using the constant quantization parameter (CQP) by default. Please use the global_quality option and other options for a quality-based mode or the b option and other options for a bitrate-based mode if the default is not the desired choice.
Output #0, mp4, to 'o2.mp4':
  Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2avc1mp41
    encoder         : Lavf61.7.100
  Stream #0:0(und): Video: hevc (hev1 / 0x31766568), nv12(tv, progressive), 1280x720 [SAR 1:1 DAR 16:9], q=2-31, 25 fps, 12800 tbn (default)
      Metadata:
        handler_name    : VideoHandler
        vendor_id       : [0][0][0][0]
        encoder         : Lavc61.19.100 hevc_qsv
      Side data:
        cpb: bitrate max/min/avg: 0/0/0 buffer size: 0 vbv_delay: N/A
  Stream #0:1(und): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 128 kb/s (default)
      Metadata:
        handler_name    : SoundHandler
        vendor_id       : [0][0][0][0]
        encoder         : Lavc61.19.100 aac
frame= 5418 fps=404 q=-0.0 size=    5888KiB time=00:03:36.56 bitrate= 222.7kbits/s speed=16.2x

速度は16～17程度でCPUより少し速いです。

NV 4060 GPU エンコーディング

ffmpeg -i t.mp4 -c:v hevc_nvenc o.mp4
ffmpeg version 7.1-full_build-www.gyan.dev Copyright (c) 2000-2024 the FFmpeg developers
  built with gcc 14.2.0 (Rev1, Built by MSYS2 project)
  configuration: --enable-gpl --enable-version3 --enable-static --disable-w32threads --disable-autodetect --enable-fontconfig --enable-iconv --enable-gnutls --enable-libxml2 --enable-gmp --enable-bzlib --enable-lzma --enable-libsnappy --enable-zlib --enable-librist --enable-libsrt --enable-libssh --enable-libzmq --enable-avisynth --enable-libbluray --enable-libcaca --enable-sdl2 --enable-libaribb24 --enable-libaribcaption --enable-libdav1d --enable-libdavs2 --enable-libopenjpeg --enable-libquirc --enable-libuavs3d --enable-libxevd --enable-libzvbi --enable-libqrencode --enable-librav1e --enable-libsvtav1 --enable-libvvenc --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxavs2 --enable-libxeve --enable-libxvid --enable-libaom --enable-libjxl --enable-libvpx --enable-mediafoundation --enable-libass --enable-frei0r --enable-libfreetype --enable-libfribidi --enable-libharfbuzz --enable-liblensfun --enable-libvidstab --enable-libvmaf --enable-libzimg --enable-amf --enable-cuda-llvm --enable-cuvid --enable-dxva2 --enable-d3d11va --enable-d3d12va --enable-ffnvcodec --enable-libvpl --enable-nvdec --enable-nvenc --enable-vaapi --enable-libshaderc --enable-vulkan --enable-libplacebo --enable-opencl --enable-libcdio --enable-libgme --enable-libmodplug --enable-libopenmpt --enable-libopencore-amrwb --enable-libmp3lame --enable-libshine --enable-libtheora --enable-libtwolame --enable-libvo-amrwbenc --enable-libcodec2 --enable-libilbc --enable-libgsm --enable-liblc3 --enable-libopencore-amrnb --enable-libopus --enable-libspeex --enable-libvorbis --enable-ladspa --enable-libbs2b --enable-libflite --enable-libmysofa --enable-librubberband --enable-libsoxr --enable-chromaprint
  libavutil      59. 39.100 / 59. 39.100
  libavcodec     61. 19.100 / 61. 19.100
  libavformat    61.  7.100 / 61.  7.100
  libavdevice    61.  3.100 / 61.  3.100
  libavfilter    10.  4.100 / 10.  4.100
  libswscale      8.  3.100 /  8.  3.100
  libswresample   5.  3.100 /  5.  3.100
  libpostproc    58.  3.100 / 58.  3.100
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 't.mp4':
  Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2avc1mp41
    encoder         : Lavf58.33.100
  Duration: 00:38:56.60, start: 0.000000, bitrate: 284 kb/s
  Stream #0:0[0x1](und): Video: h264 (High) (avc1 / 0x31637661), yuv420p(progressive), 1280x720 [SAR 1:1 DAR 16:9], 148 kb/s, 25 fps, 25 tbr, 12800 tbn (default)
      Metadata:
        handler_name    : VideoHandler
        vendor_id       : [0][0][0][0]
  Stream #0:1[0x2](und): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 128 kb/s (default)
      Metadata:
        handler_name    : SoundHandler
        vendor_id       : [0][0][0][0]
Stream mapping:
  Stream #0:0 -> #0:0 (h264 (native) -> hevc (hevc_nvenc))
  Stream #0:1 -> #0:1 (aac (native) -> aac (native))
Press [q] to stop, [?] for help
Output #0, mp4, to 'o.mp4':
  Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2avc1mp41
    encoder         : Lavf61.7.100
  Stream #0:0(und): Video: hevc (Main) (hev1 / 0x31766568), yuv420p(tv, progressive), 1280x720 [SAR 1:1 DAR 16:9], q=2-31, 2000 kb/s, 25 fps, 12800 tbn (default)
      Metadata:
        handler_name    : VideoHandler
        vendor_id       : [0][0][0][0]
        encoder         : Lavc61.19.100 hevc_nvenc
      Side data:
        cpb: bitrate max/min/avg: 0/0/2000000 buffer size: 4000000 vbv_delay: N/A
  Stream #0:1(und): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 128 kb/s (default)
      Metadata:
        handler_name    : SoundHandler
        vendor_id       : [0][0][0][0]
        encoder         : Lavc61.19.100 aac
frame=24617 fps=1035 q=9.0 size=  102656KiB time=00:16:24.56 bitrate= 854.1kbits/s speed=41.4x

スピード40+

UbuntuでLSIカードのハードディスクステータスsmartctlを確認し、ハードディスクstorcli64を見つけてホットスワップ交換します。

Fri, 24 Jan 2025 00:00:00 +0000

Smartctl を使用してハードディスクのステータスを確認する

スマートCTLのインストール

1
2

$ sudo apt update
$ sudo apt install smartmontools

ディレクトリとディスク間の対応関係を表示する

$ df
Filesystem       1K-blocks        Used  Available Use% Mounted on
tmpfs              3282308       20776    3261532   1% /run
efivarfs               302         192        106  65% /sys/firmware/efi/efivars
/dev/sdi2        228554124    11376292  205495068   6% /
tmpfs             16411524           0   16411524   0% /dev/shm
tmpfs                 5120           0       5120   0% /run/lock
/dev/sdi1          1098628        6296    1092332   1% /boot/efi
/dev/sda2      15625861116  9835617292 5790243824  63% /mnt/A01
tmpfs              3282304          12    3282292   1% /run/user/1000

対応するディスクのスマート情報を確認する

$ sudo smartctl -a /dev/sda
[sudo] password for knightli: 
smartctl 7.4 2023-08-01 r5530 [x86_64-linux-6.8.0-51-generic] (local build)
Copyright (C) 2002-23, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family:     Western Digital Ultrastar DC HC550
Device Model:     WDC  WUH721816ALE6L4
Serial Number:    2BHUKDEN
LU WWN Device Id: 5 000cca 295d9b61a
Firmware Version: PCGNW232
User Capacity:    16,000,900,661,248 bytes [16.0 TB]
Sector Sizes:     512 bytes logical, 4096 bytes physical
Rotation Rate:    7200 rpm
Form Factor:      3.5 inches
Device is:        In smartctl database 7.3/5528
ATA Version is:   ACS-4 published, ANSI INCITS 529-2018
SATA Version is:  SATA 3.3, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is:    Fri Jan 24 15:14:57 2025 UTC
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status:  (0x80) Offline data collection activity
                                        was never started.
                                        Auto Offline Data Collection: Enabled.
Self-test execution status:      (   0) The previous self-test routine completed
                                        without error or no self-test has ever 
                                        been run.
Total time to complete Offline 
data collection:                (  101) seconds.
Offline data collection
capabilities:                    (0x5b) SMART execute Offline immediate.
                                        Auto Offline data collection on/off support.
                                        Suspend Offline collection upon new
                                        command.
                                        Offline surface scan supported.
                                        Self-test supported.
                                        No Conveyance Self-test supported.
                                        Selective Self-test supported.
SMART capabilities:            (0x0003) Saves SMART data before entering
                                        power-saving mode.
                                        Supports SMART auto save timer.
Error logging capability:        (0x01) Error logging supported.
                                        General Purpose Logging supported.
Short self-test routine 
recommended polling time:        (   2) minutes.
Extended self-test routine
recommended polling time:        (1758) minutes.
SCT capabilities:              (0x003d) SCT Status supported.
                                        SCT Error Recovery Control supported.
                                        SCT Feature Control supported.
                                        SCT Data Table supported.

SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000b   100   100   001    Pre-fail  Always       -       0
  2 Throughput_Performance  0x0005   135   135   054    Pre-fail  Offline      -       100
  3 Spin_Up_Time            0x0007   083   083   001    Pre-fail  Always       -       350 (Average 350)
  4 Start_Stop_Count        0x0012   097   097   000    Old_age   Always       -       1511
  5 Reallocated_Sector_Ct   0x0033   100   100   001    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x000b   100   100   001    Pre-fail  Always       -       0
  8 Seek_Time_Performance   0x0005   140   140   020    Pre-fail  Offline      -       15
  9 Power_On_Hours          0x0012   097   097   000    Old_age   Always       -       24995
 10 Spin_Retry_Count        0x0013   100   100   001    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   098   098   000    Old_age   Always       -       148
 22 Helium_Level            0x0023   100   100   025    Pre-fail  Always       -       100
192 Power-Off_Retract_Count 0x0032   100   100   000    Old_age   Always       -       4832
193 Load_Cycle_Count        0x0012   100   100   000    Old_age   Always       -       4832
194 Temperature_Celsius     0x0002   058   058   000    Old_age   Always       -       36 (Min/Max 16/54)
196 Reallocated_Event_Count 0x0032   100   100   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0022   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0008   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x000a   100   100   000    Old_age   Always       -       28

SMART Error Log Version: 1
ATA Error Count: 28 (device log contains only the most recent five errors)
        CR = Command Register [HEX]
        FR = Features Register [HEX]
        SC = Sector Count Register [HEX]
        SN = Sector Number Register [HEX]
        CL = Cylinder Low Register [HEX]
        CH = Cylinder High Register [HEX]
        DH = Device/Head Register [HEX]
        DC = Device Command Register [HEX]
        ER = Error register [HEX]
        ST = Status register [HEX]
Powered_Up_Time is measured from power on, and printed as
DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes,
SS=sec, and sss=millisec. It "wraps" after 49.710 days.

Error 28 occurred at disk power-on lifetime: 24824 hours (1034 days + 8 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  84 53 20 30 80 60 40  Error: ICRC, ABRT 32 sectors at LBA = 0x00608030 = 6324272

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  35 03 20 30 80 60 40 00      00:01:43.419  WRITE DMA EXT
  ef 03 46 00 00 00 00 00      00:01:43.416  SET FEATURES [Set transfer mode]
  ef 03 0c 00 00 00 00 00      00:01:43.414  SET FEATURES [Set transfer mode]
  ec 00 01 00 00 00 00 00      00:01:43.413  IDENTIFY DEVICE
  61 08 00 88 f2 4f 40 00      00:01:43.287  WRITE FPDMA QUEUED

Error 27 occurred at disk power-on lifetime: 24824 hours (1034 days + 8 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  84 43 00 00 00 00 00  Error: ICRC, ABRT at LBA = 0x00000000 = 0

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  61 08 00 88 f2 4f 40 00      00:01:43.287  WRITE FPDMA QUEUED
  ec 00 01 00 00 00 a0 00      00:01:42.858  IDENTIFY DEVICE
  ec 00 01 00 00 00 a0 00      00:01:42.858  IDENTIFY DEVICE
  25 03 10 00 00 00 40 00      00:01:42.526  READ DMA EXT
  ef 03 46 30 80 60 00 00      00:01:42.524  SET FEATURES [Set transfer mode]

Error 26 occurred at disk power-on lifetime: 24824 hours (1034 days + 8 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  84 53 20 30 80 60 40  Error: ICRC, ABRT 32 sectors at LBA = 0x00608030 = 6324272

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  35 03 20 30 80 60 40 00      00:01:42.402  WRITE DMA EXT
  ef 03 46 88 f2 4f 00 00      00:01:42.399  SET FEATURES [Set transfer mode]
  ef 03 0c 88 f2 4f 00 00      00:01:42.397  SET FEATURES [Set transfer mode]
  ec 08 00 88 f2 4f 00 00      00:01:42.396  IDENTIFY DEVICE
  61 08 00 88 f2 4f 40 00      00:01:42.272  WRITE FPDMA QUEUED

Error 25 occurred at disk power-on lifetime: 24824 hours (1034 days + 8 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  84 43 00 00 00 00 00  Error: ICRC, ABRT at LBA = 0x00000000 = 0

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  61 08 00 88 f2 4f 40 00      00:01:42.272  WRITE FPDMA QUEUED
  35 03 08 a0 f2 4f 40 00      00:01:42.271  WRITE DMA EXT
  ef 03 46 a0 f2 4f 00 00      00:01:42.269  SET FEATURES [Set transfer mode]
  ef 03 0c a0 f2 4f 00 00      00:01:42.267  SET FEATURES [Set transfer mode]
  ec 03 08 a0 f2 4f 00 00      00:01:42.267  IDENTIFY DEVICE

Error 24 occurred at disk power-on lifetime: 24824 hours (1034 days + 8 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  84 53 08 a0 f2 4f 40  Error: ICRC, ABRT 8 sectors at LBA = 0x004ff2a0 = 5239456

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  35 03 08 a0 f2 4f 40 00      00:01:42.272  WRITE DMA EXT
  ef 03 46 a0 f2 4f 00 00      00:01:42.269  SET FEATURES [Set transfer mode]
  ef 03 0c a0 f2 4f 00 00      00:01:42.267  SET FEATURES [Set transfer mode]
  ec 03 08 a0 f2 4f 00 00      00:01:42.267  IDENTIFY DEVICE
  35 03 08 a0 f2 4f 40 00      00:00:55.790  WRITE DMA EXT

SMART Self-test log structure revision number 1
No self-tests have been logged.  [To run self-tests, use: smartctl -t]

SMART Selective self-test log data structure revision number 1
 SPAN  MIN_LBA  MAX_LBA  CURRENT_TEST_STATUS
    1        0        0  Not_testing
    2        0        0  Not_testing
    3        0        0  Not_testing
    4        0        0  Not_testing
    5        0        0  Not_testing
Selective self-test flags (0x0):
  After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.

The above only provides legacy SMART information - try 'smartctl -x' for more

実行後は出力からハードディスクの状態を判断でき、出力されたSN番号から後続の工程でハードディスクを特定することができます。

storcli64 を使用してハードドライブの物理的な場所を特定します。

storcli64をインストールする

Broadcom 公式 Web サイトにアクセスして storcli をダウンロードします
https://www.broadcom.com/support/download-search?dk=storcli 対応するバージョンをダウンロードする

解凍後、ディレクトリ /STORCLI_SAS3.5_P33/univ_viva_cli_rel/Unified_storcli_all_os/Ubuntu に移動します。

1
2
3

unzip STORCLI_SAS3.5_P33.zip
cd STORCLI_SAS3.5_P33/univ_viva_cli_rel/Unified_storcli_all_os/Ubuntu
dpkg -i storcli_007.3205.0000.0000_all.deb

storcli64を実行する

rootとして実行する必要があります

コントローラーを探す

# storcli64 show
CLI Version = 007.3205.0000.0000 Oct 09, 2024
Operating system = Linux 6.8.0-51-generic
Status Code = 0
Status = Success
Description = None

Number of Controllers = 1
Host Name = knightli-m3
Operating System  = Linux 6.8.0-51-generic
StoreLib IT Version = 07.3205.0200.0000
StoreLib IR3 Version = 16.16-0

IT System Overview :
==================

------------------------------------------------------------------------------
Ctl Model           AdapterType   VendId DevId SubVendId SubDevId PCI Address 
------------------------------------------------------------------------------
  0 Dell HBA330 Adp   SAS3008(C0) 0x1000  0x97    0x1028   0x1F45 00:02:00:00 
------------------------------------------------------------------------------

実行後、ctl はコントローラー ID で、ここでは番号 0 になります。

ハードドライブを探す

`1`	`# storcli64 /c0 show all > hd.txt`

hd.txtでハードドライブを検索

Drive /c0/e0/s7 Device attributes :
=================================
Manufacturer Id = ATA     
Model Number = WDC  WUH721816ALE6L4
NAND Vendor = NA
SN = 2BHUKDEN            
WWN = 5000CCA295D9B61A
Firmware Revision = PCGNW232
Raw size = 14.552 TB [0x746bfffff Sectors]
Coerced size = 14.552 TB [0x746bfffff Sectors]
Non Coerced size = 14.552 TB [0x746bfffff Sectors]
Device Speed = Unknown
Link Speed = 6.0Gb/s
NCQ setting = N/A
Sector Size = 512B
Config ID = NA
Number of Blocks = 31251759103
Connector Name = N/A

上記のフラグメントで、まずシリアル番号 SN を検索し、それを探している SN と照合します。すると、上記のハードディスクの対応する場所が表示されます。上記は/c0/e0/s7です。これを使用して、後でハードディスクを見つけることができます。

ハードドライブを見つけてフラッシュします

`1`	`# storcli64 /c0/e0/s7 start locate`

ハードドライブのライトが点滅し始める

`1`	`# storcli64 /c0/e0/s7 stop locate`

ハードドライブのライトが点滅を停止する

openwrtでワイヤーガードが自動的に再接続しない問題を解決する方法

Sun, 19 Jan 2025 00:00:00 +0000

openwrtでワイヤーガードが自動的に再接続しない問題を解決する方法

ここ 2 日間、OpenWrt での Wireguard 相互接続に苦労していましたが、1 日使用した後に問題を発見しました。元々はダイナミック DNS を使用して接続されており、IP は 48 時間後に自動的に変更されます。現時点では、Wireguard は自動的に再接続されないため、正常化するには手動で接続する必要があります。

次のスクリプトを使用します

#!/bin/sh

if ! ping -c 3 对方wgIP 3 > /dev/null 2>&1 ;then

echo "The Wireguard is down! Now try restarting wg0!\n" >> ./ddns-wg0.log

ifdown wg0 #wg0是你的wg接口名称
sleep 3
ifup wg0
fi

openwrt に付属のスクリプトを使用する

スクリプトは /usr/bin/wireguard_watchdog にあります。

. /lib/functions.sh

check_peer_activity() {
  local cfg=$1
  local iface=$2
  local public_key
  local endpoint_host
  local endpoint_port
  local persistent_keepalive
  local last_handshake
  local idle_seconds

  config_get public_key "${cfg}" "public_key"
  config_get endpoint_host "${cfg}" "endpoint_host"
  config_get endpoint_port "${cfg}" "endpoint_port"
  persistent_keepalive=$(wg show ${iface} persistent-keepalive | grep ${public_key} | awk '{print $2}'):1/128 Scope:Host

  # only process peers with endpoints and keepalive set
  [ -z ${endpoint_host} ] && return 0;
  [ -z ${persistent_keepalive} -o ${persistent_keepalive} = "off" ] && return 0;

  # skip IP addresses
  # check taken from packages/net/ddns-scripts/files/dynamic_dns_functions.sh
  local IPV4_REGEX="[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}"
  local IPV6_REGEX="\(\([0-9A-Fa-f]\{1,4\}:\)\{1,\}\)\(\([0-9A-Fa-f]\{1,4\}\)\{0,1\}\)\(\(:[0-9A-Fa-f]\{1,4\}\)\{1,\}\)"80:b91d/128 Scope:Link
  local IPV4=$(echo ${endpoint_host} | grep -m 1 -o "$IPV4_REGEX$")    # do not detect ip in 0.0.0.0.example.comrors:0 dropped:3224 overruns:0 frame:0
  local IPV6=$(echo ${endpoint_host} | grep -m 1 -o "$IPV6_REGEX")
  [ -n "${IPV4}" -o -n "${IPV6}" ] && return 0;

  # re-resolve endpoint hostname if not responding for too long
  last_handshake=$(wg show ${iface} latest-handshakes | grep ${public_key} | awk '{print $2}')6 addr: fe80::ded8:7cff:fe40:7c82/64 Scope:Link
  [ -z ${last_handshake} ] && return 0;
  idle_seconds=$(($(date +%s)-${last_handshake}))
  [ ${idle_seconds} -lt 150 ] && return 0;
  logger -t "wireguard_monitor" "${iface} endpoint ${endpoint_host}:${endpoint_port} is not responding for ${idle_seconds} seconds, trying to re-resolve hostname"
  wg set ${iface} peer ${public_key} endpoint "${endpoint_host}:${endpoint_port}"00  
}

# query ubus for all active wireguard interfaces
wg_ifaces=$(ubus -S call network.interface dump | jsonfilter -e '@.interface[@.up=true]' | jsonfilter -a -e '@[@.proto="wireguard"].interface' | tr "\n" " ")

# check every peer in every active wireguard interface
config_load network
for iface in $wg_ifaces; do
  config_foreach check_peer_activity "wireguard_${iface}" "${iface}"
done

上記のスクリプトをcrontabに追加します

上記のスクリプトのいずれかを使用できます

インターフェース経由で追加

システムを開く –> スケジュールされたタスク
以下の内容を入力して保存します

`1`	`* * * * * /usr/bin/wireguard_watchdog`

コマンドライン経由で追加

SSHでopenwrtに接続
crontab -e
- - - - /usr/bin/wireguard_watchdog を追加します
保存

LVM を使用して Ubuntu でハードドライブを管理する

Fri, 17 Jan 2025 00:00:00 +0000

LVM の概要

LVM は Logical Volume Manager の略で、Linux 環境でディスクパーティションを管理するためのメカニズムです。 LVM は、ハードディスクとファイルシステムの間に論理層を追加して、ファイルシステムの基礎となるハードディスクパーティションレイアウトを保護し、ハードディスクパーティション管理の柔軟性を向上させます。

LVM を使用してハードディスクを管理する基本的なプロセスは次のとおりです。

ハードドライブを物理ボリュームとして作成する
複数の物理ボリュームをボリュームグループに結合する
ボリュームグループ内に論理ボリュームを作成する
論理ボリューム上にファイルシステムを作成する
LVM を通じてハードディスクを管理すると、ファイルシステムはハードディスクのサイズに制限されなくなり、複数のハードディスクに分散したり、動的に拡張したりすることができます。

LVMの基本概念

物理ストレージメディア (物理メディア): システムの /dev/hda、/dev/sda などのハードディスクなど、システムの物理ストレージデバイスを指します。これは、ストレージシステムの最下位レベルのストレージユニットです。
物理ボリューム (PV): ハードディスクパーティション、または論理的にディスクパーティションと同じ機能を持つデバイス (RAID など) を指します。 LVM の基本的なストレージ論理ブロックです。物理ボリュームには、デフォルトで 2 番目の 512 バイトセクタに配置される特別なラベルが含まれていますが、ラベルは最初の 4 つのセクタのいずれかに配置することもできます。タグには、物理ボリュームのランダムな一意の識別子 (UUID) が含まれており、ブロックデバイスのサイズと、デバイス内の LVM メタデータが保存される場所が記録されます。
ボリュームグループ (VG): 物理ボリュームで構成され、基礎となる物理ボリュームの詳細がマスクされます。特定の物理ボリューム情報に関係なく、ボリュームグループ上に 1 つ以上の論理ボリュームを作成できます。
論理ボリューム (LV): ボリュームグループは直接使用できないため、使用する前に論理ボリュームに分割する必要があります。論理ボリュームは、異なるファイルシステムにフォーマットして、マウント後に直接使用できます。
物理エクステント (PE): 物理ボリュームは同じサイズの「ブロック」に格納され、ブロックのサイズはボリュームグループ内の論理ボリュームブロックのサイズと同じです。
論理エクステント (LE): 論理ボリュームは「ブロック」という単位で格納され、ボリュームグループ内のすべての論理ボリュームのブロックサイズは同じになります。

インストール

1
2

sudo apt update
sudo apt install lvm2

物理ボリュームPVの管理

物理ボリュームの作成

pvcreate [option] devname ...

示例：将/dev/sdb、/dev/sdc创建为物理卷。
# pvcreate /dev/sdb /dev/sdc

物理ボリュームを表示する

pvdisplay [option] devname

示例：显示物理卷/dev/sdb的基本信息。
# pvdisplay /dev/sdb

物理ボリュームの削除

pvremove [option] pvname ...

示例：删除物理卷/dev/sdb。如果物理卷已经加入卷组，需要先删除卷组或者从卷组中移除，再删除物理卷。
# pvremove /dev/sdb

ボリュームグループVGの管理

ボリュームグループの作成

vgcreate [option] vgname pvname ...

示例：创建卷组 vg1，并且将物理卷/dev/sdb和/dev/sdc添加到卷组中。
# vgcreate vg1 /dev/sdb /dev/sdc

ボリュームグループの表示

vgdisplay [option] [vgname]

示例：显示卷组vg1的基本信息。
# vgdisplay vg1

ボリュームグループの拡張

vgextend [option] vgname pvname ...

示例：将卷组vg1中添加物理卷/dev/sdb。
# vgextend vg1 /dev/sdb

ボリュームグループの縮小

vgreduce [option] vgname pvname ...

示例：从卷组vg1中移除物理卷/dev/sdb2。
# vgreduce vg1 /dev/sdb2

ボリュームグループの削除

vgremove [option] vgname

示例：删除卷组vg1。
# vgremove vg1

論理ボリュームLVの管理

論理ボリュームの作成

lvcreate [option] vgname

示例1：在卷组vg1中创建10G大小的逻辑卷。
# lvcreate -L 10G vg1

示例2：在卷组vg1中创建200M的逻辑卷，并命名为lv1。
# lvcreate -L 200M -n lv1 vg1

論理ボリュームの表示

lvdisplay [option] [lvname]

示例：显示逻辑卷lv1的基本信息。
# lvdisplay /dev/vg1/lv1

論理ボリュームのサイズを変更する

lvresize [option] vgname

示例1：为逻辑卷/dev/vg1/lv1增加200M空间。
# lvresize -L +200 /dev/vg1/lv1

示例2：为逻辑卷/dev/vg1/lv1减少200M空间。
# lvresize -L -200 /dev/vg1/lv1

示例3：为逻辑卷/dev/vg1/lv1增加所有可用空间
# lvresize -l +100%FREE /dev/vg1/lv1

論理ボリュームを拡張する

lvextend [option] lvname

示例1：为逻辑卷/dev/vg1/lv1增加100M空间。
# lvextend -L +100M /dev/vg1/lv1

示例2：为逻辑卷/dev/vg1/lv1增加所有可用空间
# lvextend -l +100%FREE /dev/vg1/lv1

論理ボリュームを縮小する

lvreduce [option] lvname

示例：将逻辑卷/dev/vg1/lv1的空间减少100M。
# lvreduce -L -100M /dev/vg1/lv1

論理ボリュームの削除

lvremove [option] vgname

示例：删除逻辑卷/dev/vg1/lv1。
# lvremove /dev/vg1/lv1

ファイルシステムを作成してマウントする

ファイルシステムの作成

mkfs [option] lvname

示例：在逻辑卷/dev/vg1/lv1上创建ext4文件系统。
# mkfs -t ext4 /dev/vg1/lv1

ファイルシステムを手動でマウントする

mount lvname mntpath

示例：将逻辑卷/dev/vg1/lv1挂载到/mnt/data目录。
# mount /dev/vg1/lv1 /mnt/data

拡張ファイルシステム

論理ボリューム LV を拡張した後、パーティションのサイズは変更されません。パーティションを手動で拡張する必要があります。以下では、例として ext4 ファイルシステムを取り上げます。

先把分区umount
umount /dev/vg1/lv1
检查并修复文件系统的错误
e2fsck -f /dev/vg1/lv1
扩展文件系统到所有分区空间
resize2fs /dev/vg1/lv1

さらに、umount を使用せずにパーティションサイズをオンラインで直接調整することもできることがわかりました。

1
2

扩展文件系统到所有分区空间
resize2fs /dev/vg1/lv1

Vgextend の失敗を処理する際のエラー「デバイスの論理ブロックサイズが一貫していません」

Fri, 17 Jan 2025 00:00:00 +0000

デバイスの論理ブロックサイズが一致しない発生理由

問題は、Vgextend に新しく追加されたディスクの論理ブロックサイズが、VG 内の元のディスクの論理ブロックサイズと異なることです。たとえば、元の VG が論理ブロックサイズ 512 のディスクデバイス上に構築されているが、Vgextend 中に新しく追加されたデバイスの論理ブロックサイズが 4K である場合、この問題が発生します。

解決策 1: lvm.conf でallow_mixed_block_sizes=1 を有効にする

/etc/lvm/lvm.conf ファイルを開き、allow_mixed_block_sizes=1 を変更します。

しかし、このように、同じ LV 上でブロックサイズを混在させても安全でしょうか? https://serverfault.com/questions/1150643/is-it-safe-to-use-allow-mixed-block-sizes-1-in-lvm-when-using-ext4-with-4k-blo

解決策 2: 一部のハードドライブの論理ブロックサイズを変更して、すべてのハードドライブの一貫性を保つ

ハードディスクの論理ブロックサイズを確認する

lsblk

$ lsblk -td
NAME    ALIGNMENT MIN-IO OPT-IO PHY-SEC LOG-SEC ROTA SCHED       RQ-SIZE  RA WSAME
sda             0   8192   8192    4096     512    0 mq-deadline     256 128    0B
sdb             0   4096      0    4096     512    0 mq-deadline     256 128    0B
sdc             0   4096      0    4096     512    1 mq-deadline     256 128    0B
nvme1n1         0    512      0     512     512    0 none           1023 128    0B
nvme0n1         0    512      0     512     512    0 none           1023 128    0B

PHY-SEC は物理セクタサイズを示し、LOG-SEC は論理セクタサイズを示します。

sysfs

$ cat /sys/class/block/sda/queue/physical_block_size
4096
$ cat /sys/class/block/sda/queue/logical_block_size
512

sda はデバイス名です

fdisk

$ sudo fdisk -l /dev/sda
Disk /dev/sda: 745.22 GiB, 800176914432 bytes, 1562845536 sectors
Disk model: P1635N08CLAR800 
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 8192 bytes / 8192 bytes

セクタサイズ物理は物理セクタサイズを示し、セクタサイズ論理は論理セクタサイズを示します。

smartctl

$ sudo smartctl -a /dev/nvme0n1
...
Supported LBA Sizes (NSID 0x1)
Id Fmt  Data  Metadt  Rel_Perf
 0 +     512       0         2
 1 -    4096       0         1
...

サポートされている LBA サイズを表示、サポートされている LBA、+ セクションは現在選択されている LBA サイズです

変更セクター LBA サイズの変更

警告: ハードディスクのセクターサイズを変更すると、すべてのデータが消去され、回復不能になります。

一部の NVMe および「エンタープライズ」SATA ドライブは、それぞれ標準 NVMe (NVMe Command Set Standard 1.0 以降の場合は NVM のフォーマット) または ATA (ATA Command Set Standard 1.0 以降の場合は SET SECTOR CONFIGURATION EXT) を介して報告されたセクターサイズの変更をサポートします。機械式ハードディスクの場合、この操作は物理セクターサイズと一致するように論理セクターサイズを変更することにより、ハードディスクのパフォーマンスを最適化します。 NVMe SSD の場合、論理セクターサイズと物理セクターサイズの両方が変更されます。

SATA SSD は通常、セクターサイズの変更をサポートしていません。一部の Intel SATA SSD は、報告された物理セクターサイズのみを変更でき、論理セクターサイズは変更できません。セクターサイズの変更には、低レベルのフォーマットを含む一連の複雑な操作が必要です。別の方法として、ハードドライブ上にファイルシステムを作成するときにセクターサイズを手動で指定することで、パフォーマンスを最適化することもできます。

機械式ハードドライブを変更する

hdparm ツールを使用して、ハードドライブのセクターサイズを変更できるかどうかを判断します。

論理セクターサイズの変更をサポートしていないハードドライブは、現在のセクターサイズのみを報告します。

$ sudo hdparm -I /dev/sda | grep 'Sector size:'
        Logical/Physical Sector size:           512 bytes
$ sudo hdparm -I /dev/sdb | grep 'Sector size:'
        Logical/Physical Sector size:           512 bytes

ハードディスクの論理セクターサイズの変更をサポート

$ sudo hdparm -I /dev/sdc | grep 'Sector size:'
        Logical  Sector size:                   512 bytes [ Supported: 2048 256 ]
        Physical Sector size:                  4096 bytes
$ sudo hdparm -I /dev/sdk | grep 'Sector size:'
        Logical  Sector size:                   512 bytes [ Supported: 2048 256 ]
        Physical Sector size:                  4096 bytes

hdparm ツールを使用して、メカニカルハードディスクのセクターサイズを変更します。

SATA メカニカルハードドライブが複数の論理セクターサイズとオプションの SET SECTOR CONFIGURATION EXT ATA コマンドをサポートしている場合 (たとえば、Seagate は FastFormat 機能を備えたハードドライブを推進しています)、hdparm を使用して、サポートされているさまざまな論理セクターサイズを切り替えることができます。次のコマンドを使用して、これを 4096 バイト (つまり 4Kn) に設定できます。

`1`	`# hdparm --set-sector-size 4096 --please-destroy-my-drive /dev/sdX`

変更後、hdparm は 4096 バイトの論理セクターサイズを報告するはずです。

1
2
3

# hdparm -I /dev/sdX | grep 'Sector size:'
        Logical  Sector size:                  4096 bytes [ Supported: 512 4096 ]
        Physical Sector size:                  4096 bytes

NVMe SSDを変更する

ソリッドステートドライブ (SSD) は多くの場合、より大きな物理ブロック (通常は 4 KiB、8 KiB、場合によってはそれよりも大きい) を使用しますが、通常、論理ブロックサイズは 512 バイトとして報告されます。 nvme-cli パッケージで Identify Namespace コマンドを使用すると、NVMe ハードドライブのフォーマットされた論理ブロックアドレスサイズ (FLBAS) を表示できます。

1
2
3

$ sudo nvme id-ns -H /dev/nvme0n1 | grep "Relative Performance"
LBA Format  0 : Metadata Size: 0   bytes - Data Size: 512 bytes - Relative Performance: 0x2 Good (in use)
LBA Format  1 : Metadata Size: 0   bytes - Data Size: 4096 bytes - Relative Performance: 0x1 Better

メタデータサイズは、論理ブロックアドレス (論理ブロックアドレス、LBA) ごとの追加メタデータバイトのサイズです。この機能は Linux ではまだ完全にはサポートされていないため、値 0 の形式を使用することをお勧めします。相対パフォーマンスは、さまざまな形式で提供されるパフォーマンスレベル (劣化、良好、良好、最高など) を表します。

Smartctl は、デバイスがサポートする論理ブロックアドレスサイズも表示できます。

# smartctl -c /dev/nvme0n1
...
Supported LBA Sizes (NSID 0x1)
Id Fmt  Data  Metadt  Rel_Perf
 0 +     512       0         2
 1 -    4096       0         1

論理ブロックアドレスサイズは、–lbaf パラメーターを使用して nvme format コマンドにターゲット値を渡すことで変更できます。

# nvme format --lbaf=1 /dev/nvme0n1
You are about to format nvme0n1, namespace 0x1.
WARNING: Format may irrevocably delete this device's data.
You have 10 seconds to press Ctrl-C to cancel this operation.

Use the force [--force] option to suppress this warning.
Sending format operation ... 
Success formatting namespace:1

lbaf は ID 値に対応し、変更が完了するまでに数秒かかります。

ffmpegを使用してmp3ファイルを処理する

Tue, 07 Jan 2025 00:00:00 +0000

MP3 ビットレートエンコードモード

通常、mp3 には VBR、ABR、CBR という 3 つのビットレートがあります。

CBR固定ビットレート

CBRとはConstant Bitrateの略で、中国語で固定ビットレートを意味します。
ビットレート 128 kbps の CBR MP3 曲の場合、曲の最初の 128 KB は最初の 2 秒のサウンドを記述し、次の 128 KB は 2 秒目のサウンドを記述します。曲が歌うのに 640 秒かかる場合、曲のサイズは 128kb × 640 = 80Mb = 10MB となります。いわゆる 128kbps は 1 秒あたり 128kb を意味します。
注意してみると、このエンコード方式ではビットレートが固定されているため、圧縮された容量が非常に大きくなることがわかります。もちろん、音質には他の 2 つよりもいくつかの利点がありますが、この利点は最小限かもしれません。

VBR ダイナミックビットレート

VBR (可変ビットレート) 動的ビットレート。つまり、固定ビットレートはありません。圧縮ソフトウェアは、圧縮中に音声データに基づいて使用するビットレートを瞬時に決定します。簡単に理解すると、曲の詳細が豊富な場合、その時点でのビットレートは比較的高く、その他の状況では比較的低くなり、音質とサイズの両方が考慮されます。たとえば、曲の冒頭では人が一人で歌っていますが、サウンドは比較的シンプルなので、1 秒以内にサウンドを表現するには 64kb を使用します。曲のクライマックスでは全員で合唱するのですが、音が比較的複雑なので、1秒以内の音を表現するには256kbを使います。

ABR平均ビットレート

ABR（Average Bitrate）は、VBRの補間パラメータです。たとえば、wav ファイルのエンコードに 192kbps ABR を使用するように指定すると、Lame はファイルの 85% に 192kbps の固定エンコードを使用し、残りの 15% を動的に最適化します。つまり、複雑な部分は 192kbps より高い値でエンコードされ、単純な部分は 192 kbps より低い値でエンコードされます。 192kbps CBR と比較すると、192kbps ABR はファイルサイズは同等ですが、音質は大幅に向上しています。 ABR エンコードは VBR エンコードより 2 ～ 3 倍高速で、128 ～ 256kbps の範囲では品質は CBR よりも優れています。この方法は、容量要件が固定されている場合に適しています。たとえば、圧縮してディスクに書き込みたい場合、ディスクの容量が固定されている場合、平均値を計算し、その平均値に基づいて操作できます。

ffmpegを使用して圧縮する

可変ビットレートVBR

ffmpeg -i sample.wav -vn -c:a libmp3lame -aq 4 -ac 2 sample.mp3

参数说明:  
-i 输入音频文件
-vn 不处理视频 
-c:a 指定音频编码器 copy、mp3(libmp3lame)、aac、
-aq 质量  数字越小,编码音质约好,体积越大
-ac 声道数

固定コードレートCBR

ffmpeg -i sample.wav -vn -c:a libmp3lame -b:a 192k -ac 2 sample.mp3

-i 输入音频文件
-vn 不处理视频 
-c:a 指定音频编码器 copy、mp3(libmp3lame)、aac、
-b:a 固定编码率
-ac 声道数

metadata

1
2
3

ffmpeg -i sample.wav -map_metadata -1 -vn -c:a libmp3lame -aq 8 -ac 2 sample.mp3

-map_metadata -1  清除metadata

機械式ハードドライブを正しくホットスワップする方法、ハードドライブのホットスワップの正しい姿勢をマスターするための 1 つの記事: 抜きたくない場合は抜いても構いません。

Wed, 01 Jan 2025 00:00:00 +0000

物理レベル: ハードウェアはホットスワップをサポートする必要があります

まず、ハードウェアが物理レベルでホットスワップをサポートできることを確認してください。これがすべての前提条件です。

BIOS レベルで関連する設定を開きます

ASUS マザーボードを例に挙げると、手順は次のとおりです。

起動後、F2 キーまたは DEL キーを押して BIOS に入ります。
詳細モードに切り替えます。
パス「Advanced\PCH Storage Configuration」を順に入力し、SATA インターフェイスに対応するホットプラグオプションを「有効」に切り替えます。
F10 キーを押すと、現在の BIOS 設定が保存され、終了します。

以上の操作により、ホットスワップ機能をオンにすることができます。他のハードウェアでも同様の動作があります。

ソフトウェアオペレーティングシステムレベル

Windowsシステム

関連するハードドライブでの操作の使用を停止します
「デバイスマネージャー」で削除する必要があるハードドライブを選択し、「デバイスのアンインストール」をクリックします。
アンインストールが成功したら、ハードドライブを抜き差しできるようになります。

Linuxシステム

関連するハードドライブでの操作の使用を停止します
ファイルシステム内の関連ハードディスクをアンマウントします (umount /dev/sda)
LVM を使用している場合は、すべての LVM グループを非アクティブ化します。 (vgchange-an)
ハードディスクをスリープ状態にして、HDD の速度を下げます。 (sudo hdparm -Y /dev/sda)
オペレーティングシステムでデバイスを削除するには (echo 1 | sudo tee /sys/block/sda/device/delete)、コマンドの実行後、ドライブはヘッドをパークし、ディスクを完全に停止し、バスの電源を無効にします。パークされていないヘッドが回転するプラッターに接触すると、ドライブが永久に損傷する可能性があります。
上記の操作が成功すると、ハードディスクの挿入と取り外しが可能になります。

inpaint-web 画像修復、透かし除去、画像高解像度、完全無料、無制限、高速処理速度、オープンソースツール

Thu, 24 Oct 2024 00:00:00 +0000

inpaint-web

inpaint-web は、Webgpu テクノロジと wasm テクノロジに基づいた、純粋にブラウザ側で実装された、無料のオープンソースの修復および画像アップスケーリングツールです。 github アドレス https://github.com/lxfater/inpaint-web/

主な機能

画像の修復、ウォーターマークの除去

元の画像

修復後の写真、修復場所が異なり、別の場所が消去されています

元の画像

コンテンツの一部を消去します

ぼやけた画像の高解像度

元の画像

4 倍拡大後

元の画像

/ 4 倍拡大後

一般的に使用される WiFi チャネルと周波数帯域 2.4G 5G (5.2G 5.5G 5.8G)

Sun, 29 Sep 2024 00:00:00 +0000

一般的に使用される WiFi チャネルと周波数帯域 2.4G 5G (5.2G 5.5G 5.8G)

2.4G周波数帯

2.4 GHz 周波数帯域には 5 MHz 間隔で区切られた 14 チャネルがあります (12 MHz で区切られたチャネル 14 とチャネル 13 を除く)。 [2] 40 MHz 帯域は、2 つの隣接する 20 MHz 帯域で構成されます。どの帯域がプライマリ (制御) 帯域であり、どの帯域がセカンダリ (拡張) 帯域であるかに応じて、ルータは 1+5、5+1、9+13、13+9 として表示される場合があります。

5G周波数帯

5.2G周波数帯

5.2Gの利用可能なチャネル: 36、40、44、48、52、56、60、64; 全国のレーダー環境はチャネル 52、56、60、および 64 と競合するため、無線端末のアクセスの問題を回避するために、通常モードではこれらのレーダーチャネルを回避することをお勧めします。

5.5G周波数帯

5.5GHz は 5GHz 周波数帯域の一部であり、特定の周波数の割り当ては国や地域によって異なる場合があります。中国では、5GHz 周波数帯域の割り当てには、5.470GHz ～ 5.725GHz の周波数範囲が含まれます。

5.8G周波数帯

5.8GHz周波数帯では、中国は149、153、157、161、165の5つのチャネルのみを開設している。 1 セットの 80MHz チャネルバンドリング (149-161) または 2 セットの 40MHz チャネルバンドリング (149-153 および 157-161) をサポートできます。したがって、165 チャネルが 20MHz 帯域幅をサポートします。現在の帯域幅が 20MHz であるため、チャネル 165 は表示されませんが、帯域幅を変更すると表示されるようになります。

Xiaomi Ax3600ルーターのmibibパーティションはファームウェアと互換性があります

Tue, 09 Jul 2024 00:00:00 +0000

Xiaomi ルーター mibib

対応する 2 つのドキュメントがオンラインで見つかります。

Xiaomiオリジナルミビブ
オリジナル mibib ファイルのダウンロード
qsdk の大きなパーティションに対応する mibib は、多くのアンデッド uboot がフラッシュするときにこのファイルをフラッシュします。
qsdk バージョン mibib ファイルのダウンロード

ミビブ適応性

異なる mibib は異なるファームウェアに対応します。間違って点滅すると正常に起動しません。不滅の uboot がなければ、レンガになってしまうことさえあります。

オリジナルの mibib ファイルに対応するファームウェアオンラインの openwrt 公式ウェブサイト、openwrt.ai のファームウェアのほとんどが互換性があります
qsdkラージパーティションmibib対応ファームウェア qsdkファームウェア
ファームウェアは両方の mibib タイプと互換性があります。上記2種類に対応しているファームウェアは以下の通りです。
openwrt-ipq807x-generic-redmi_ax6-squashfs.ubi

ルーターがどの mibib であるかを確認する方法

mibib.xiaomi.bin ファイルと mibib.qsdk.bin ファイルをルーターの /tmp ディレクトリにアップロードします。

1
2

mtd verify /tmp/mibib.xiaomi.bin /dev/mtd1 
mtd verify /tmp/mibib.qsdk.bin /dev/mtd1

xiaomi AX3600のリソース

Xiaomi ax3600のバックアップ
ax3600bak.appsbl.bin
ax3600bak.mibib.bin

次のコマンドを入力してパーティションを表示し、mtd1 および mtd7 パーティションが存在するかどうかを確認します。

`1`	`cat /proc/mtd`

存在が正しいことを確認後、点滅を開始します。

mtd erase /dev/mtd1
mtd write /tmp/ax3600bak.mibib.bin /dev/mtd1
mtd erase /dev/mtd7
mtd write /tmp/ax3600bak.appsbl.bin /dev/mtd7

オリジナルファームウェア
miwifi_r3600_firmware_5da25_1.0.17.bin
miwifi_r3600_firmware_d1610_1.1.21.bin
不滅のユーブート Xiaomi オリジナルのファームウェアで uboot する ssh コマンドを作成します。

1
2
3

scp把固件ax6bushi-openwrt-ipq807x-u-boot.bin传到路由器tmp目录，ssh命令打以下命令:
. /lib/upgrade/platform.sh
switch_layout boot; do_flash_failsafe_partition ax6bushi-openwrt-ipq807x-u-boot "0:APPSBL"

ax6bushi-openwrt-ipq807x-u-boot.bin
ax6qsdknand-ipq807x_64-single.img
toxiaomiyuanbannand-ipq807x_64-single.img

ポータブル Wi-Fi スティック用の Debian システムの共通拡張機能の修正

Sat, 28 Oct 2023 00:00:00 +0000

USBモードを切り替える

ホストモードに切り替えると、他の USB デバイスを Wi-Fi スティックに接続できます。ガジェットモードに切り替えると、Wi-Fi スティックをコンピューターに接続できます。

USBホストモード(ホスト)に切り替える

echo host > /sys/kernel/debug/usb/ci_hdrc.0/role

デフォルトのスレーブモード (ガジェット) に切り替えます (コンピューターの USB ネットワーク共有と adb に接続します)。

echo gadget > /sys/kernel/debug/usb/ci_hdrc.0/role

起動時に自動的に切り替え、/etc/rc.local の exit 0 に次の内容を追加します (起動時に rc.local を確実に実行できるようにするには、systemd サービスを追加する必要があります)

# usb auto host
sleep 3
grep 0 /sys/kernel/debug/usb/ci_hdrc.0/device | grep speed
if [ $? -eq 0 ]
then
echo host > /sys/kernel/debug/usb/ci_hdrc.0/role
fi

コンピューターの電源を入れ、3 秒待ってコンピューターに接続されているかどうかを確認します。接続されていない場合は、ホストモードに切り替えて USB デバイスを接続します。

Wi-Fi スティックの内部スペースが不十分な状況に適したディスク圧縮を使用します (一部の Wi-Fi スティックには 4G スペースしかありません)。

より高い圧縮率を使用すると、スペースの使用量は減りますが、より多くの CPU を使用します。

btrfs ファイルシステムの使用

ルートパーティションをbtrfsに変換する

btrfs ファイルシステムのみがリアルタイム圧縮機能を備えているため、rootfs ルートパーティションを btrfs に変換する必要があります変換する前に、カーネルが btrfs をサポートしていることを確認する必要があります。カーネルが btrfs をサポートしていない場合は、カーネルのコンパイル時に btrfs をサポートするオプションを追加する必要があります (make menuconfig)。次のコマンドを使用してルートパーティションを変換します。

`1`	`btrfs-convert root.img`

fstabを変更する

emmc の遅い CPU は非常にリッチであるという事実に基づいて、より高い圧縮率の使用を検討できます。デフォルトは 3 です。1 ～ 15 の範囲で設定できます。8 を超えることはお勧めできません。 /etc/fstab を変更し、zstd を zstd:6 に変更して、圧縮レベルを 6 に変更します。コンピューターの起動失敗の原因となる変更エラーを回避するには、まず次のコマンドを変更してマウントテストを実行します (構成よりも 1 つ多い再マウントオプションがあります)。

`1`	`sudo mount -o remount,defaults,noatime,compress=zstd:6,commit=120 /dev/mmcblk0p14 /`

ルートパーティションを圧縮する

このコマンドを使用して、ルートパーティションを圧縮できます。システムは約 700 メートルを占めます。圧縮を 3 から 6 に調整すると、占有量を 2g から 1.4g に減らすことができます。

`1`	`sudo btrfs filesystem defragment -r -v -czstd /`

ポータブル Wi-Fi 用の Debian システムファームウェアのコンパイル

Wed, 09 Aug 2023 00:00:00 +0000

システムの準備

Ubuntu 22.04.2 LTSをインストールする
パッケージをインストールする

sudo apt install binfmt-support qemu-user-static gcc-10-aarch64-linux-gnu kernel-package fakeroot simg2img img2simg mkbootimg bison flex gcc-aarch64-linux-gnu pkg-config libncurses-dev libssl-dev unzip git

ダウンロードコード

リポジトリコードのクローンを作成する

`1`	`git clone https://github.com/OpenStick/linux.git --depth=1`

カーネルのコンパイル

コアのオーバークロック

ファイル linux/drivers/clk/qcom/a53-pll.c を変更します。

static const struct pll_freq_tbl a53pll_freq[] = {
	{  998400000, 52, 0x0, 0x1, 0 },
	{ 1094400000, 57, 0x0, 0x1, 0 },
	{ 1152000000, 62, 0x0, 0x1, 0 },
	{ 1209600000, 63, 0x0, 0x1, 0 },
	{ 1248000000, 65, 0x0, 0x1, 0 },
	{ 1363200000, 71, 0x0, 0x1, 0 },
	{ 1401600000, 73, 0x0, 0x1, 0 },
	{ 1621600000, 84, 0x0, 0x1, 0 },
	{ 1841600000, 96, 0x0, 0x1, 0 },
	{ 1951600000, 103, 0x0, 0x1, 0 },
	{ }
};

最初の列は動作周波数、2 番目の列は電源電圧です。

これまでのルールによれば、200Mhz増加ごとに電圧値が10ずつ増加すると大まかに判断できます。ただし、チップの設計周波数を超えているため、消費電力と発熱を同時に考慮する必要があるため、後から増やす場合は電圧値を若干上げる必要があります。 1401600000以降のデータは上記のルールに従って追加されます。

ファイル linux/arch/arm64/boot/dts/qcom/msm8916.dtsi を変更します。デフォルトの周波数は 220 行目あたりに表示されます。その後、周波数を上げます。増加した周波数を前のファイルに追加する必要があります。

        opp-1363200000 {
			opp-hz = /bits/ 64 <1363200000>;
		};
		opp-1401600000 {
			opp-hz = /bits/ 64 <1401600000>;
		};
		opp-1621600000 {
			opp-hz = /bits/ 64 <1621600000>;
		};
		opp-1841600000 {
			opp-hz = /bits/ 64 <1841600000>;
		};
		opp-1951600000 {
			opp-hz = /bits/ 64 <1951600000>;
		};

コンパイル設定

cd linux
export CROSS_COMPILE=aarch64-linux-gnu-
export ARCH=arm64
make msm8916_defconfig 
make menuconfig

make msm8916_defconfig はプリセットのコンパイルパラメータをインポートします make menuconfig 構成オプション

Klipper USBシリアルポートドライバーを追加

USB デバイスは見つかるが、/dev でシリアルディレクトリとデバイスが見つからない問題に適用されます。

lsubをインストールする sudo apt-get install usbutils
USB ポートをホストモードに切り替えます (root として実行) echo host > /sys/kernel/debug/usb/ci_hdrc.0/role
USB デバイスを表示する lsusb コマンドを実行すると、対応する USB デバイスが表示されるはずです。対応する USB デバイスがない場合は、通信の問題、ファームウェアの問題、またはボード自体の異常が考えられます。
上記の問題をすべて解決したら、シリアルポートドライバーを追加します。

Device Drivers  --->  [*] USB support  --->  <*>   USB Modem (CDC ACM) support 
Device Drivers  --->  [*] USB support  --->  <*>   USB Serial Converter support  --->   [*]   USB Serial Console device support  
Device Drivers  --->  [*] USB support  --->  <*>   USB Serial Converter support  --->   [*]   USB Generic Serial Driver
Device Drivers  --->  [*] USB support  --->  <*>   USB Serial Converter support  --->   <*>   USB Serial Simple Driver   
其他根据设备种类选择

コンパイルを開始する

`1`	make -j`nproc` bindeb-pkg

上記のコマンドは、1 ステップで deb ファイルパッケージを直接生成します。 ls ../ と入力して表示します。

Ubuntu 22.04では、make-kpkgに対応するソフトウェアパッケージをアップデートできません。公式声明では、あまりにも長い間維持されていなかったため、削除されたとのことです。したがって、次のコマンドは実行できません。一部の以前のバージョンでは可能な場合があります。

1
2

make -j-j`nproc`
fakeroot make-kpkg  --initrd --cross-compile aarch64-linux-gnu- --arch arm64  kernel_image kernel_headers

コンパイルが完了すると、ファイルの 3 つの部分が生成されます

ヘッダーとイメージを含むカーネル deb パッケージ linux-headers-5.15.0-handsomekernel+_5.15.0-handsomekernel+-7_arm64.deb および linux-image-5.15.0-handsomekernel+_5.15.0-handsomekernel+-7_arm64.deb は、コンパイルディレクトリ ../ の 1 レベル上にあります。
Image.gz linux/arch/arm64/boot/Image.gz
デバイスツリーdtb linux/arch/arm64/boot/dts/qcom/msm8916-handsome-openstick-xxxxxxxx、デバイスに応じて選択してください

-rw-rw-r-- 1 knightli knightli 49312  8月  5 18:32 linux/arch/arm64/boot/dts/qcom/msm8916-handsome-openstick-sp970.dtb
-rw-rw-r-- 1 knightli knightli 49480  8月  5 18:32 linux/arch/arm64/boot/dts/qcom/msm8916-handsome-openstick-ufi001b.dtb
-rw-rw-r-- 1 knightli knightli 49652  8月  5 18:32 linux/arch/arm64/boot/dts/qcom/msm8916-handsome-openstick-ufi001c.dtb
-rw-rw-r-- 1 knightli knightli 49312  8月  5 18:32 linux/arch/arm64/boot/dts/qcom/msm8916-handsome-openstick-uz801.dtb

rootfs、ルートパーティションの処理中

変更は、元の openstick プロジェクトによってリリースされたルートパーティションパッケージに基づいて完了します。

オリジナルの openstick debian 基本パッケージをダウンロードする

mkdir ~/rootfs
cd ~/rootfs
wget https://github.com/OpenStick/OpenStick/releases/download/v1/debian.zip && unzip debian.zip
mv ./debian/rootfs.img ~/rootfs

debian.zip パッケージでは、rootfs.img はルートパーティションの img ファイルです。

simg2imgを使用してマウント可能な形式に変換します

`1`	`simg2img rootfs.img root.img`

chroot は rootfs を処理します

mount root.img

sudo mount root.img /mnt
sudo mount --bind /proc /mnt/proc 
sudo mount --bind /dev /mnt/dev
sudo mount --bind /dev/pts /mnt/dev/pts
sudo mount --bind /sys /mnt/sys

rc.localブートスクリプトを作成する

cat>>/etc/systemd/system/rc-local.service<<EOF
[Unit]
Description=/etc/rc.local
ConditionPathExists=/etc/rc.local

[Service]
Type=forking
ExecStart=/etc/rc.local start
TimeoutSec=0
StandardOutput=tty
RemainAfterExit=yes
SysVStartPriority=99

[Install]
WantedBy=multi-user.target
EOF

cat <<EOF >/etc/rc.local
#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#

exit 0
EOF

systemctl daemon-reload && systemctl enable rc-local

ロケールを再構成する

OpenStickで使用されているdebianは効率化されているため、エラーメッセージが表示される場合があります。 warning: setlocale: LC_ALL: cannot change locale (en_US)

次の方法でこの問題を解決できます

1
2

$ sudo apt install locales
$ sudo dpkg-reconfigure locales

en_US.UTF-8 を選択できます

適切なソース修正

/etc/apt/sources.list.d/mobian.list は無効なので、直接削除できます

後続のブートパーティションに必要なファイルを抽出します

ファイル：/mnt/boot/initrd**.img 事前にコピーしておいてください

chroot の終了 umount の終了

出口から出口へ直接入力

sudo umount /mnt/proc 
sudo umount /mnt/dev/pts
sudo umount /mnt/dev
sudo umount /mnt/sys
sudo umount /mnt

simg2img を使用して逆変換します

フラッシュ用に boot.img を rootfs.img 形式に変換します

`1`	`img2simg root.img rootfs.img`

rootfs.img は、最終処理後のルートパーティションイメージファイルです。

ブートパーティションのハンドル

以下では ufi001c デバイスを例として取り上げますが、他のデバイスも類推できます。

必要書類一覧

コンパイル中に生成される Image.gz (linux/arch/arm64/boot/Image.gz)
コンパイルプロセス中に生成されるデバイスツリー dtb (linux/arch/arm64/boot/dts/qcom/msm8916-handsome-openstick-ufi001c.dtb) は、デバイスに応じて選択されます。
rootfs の変更後に生成される /boot/initrd**.img

ブートの生成

1
2
3

cat Image.gz msm8916-handsome-openstick-ufi001c.dtb > ufi001c-kernel-dtb
mv initrd.img-* initrd.img
mkbootimg --base 0x80000000 --kernel_offset 0x00080000 --ramdisk_offset 0x02000000 --tags_offset 0x01e00000 --pagesize 2048 --second_offset 0x00f00000 --ramdisk initrd.img --cmdline "earlycon root=PARTUUID=a7ab80e8-e9d1-e8cd-f157-93f69b1d141e console=ttyMSM0,115200 no_framebuffer=true rw" --kernel ufi001c-kernel-dtb -o ufi001c-boot.img

ufi001c-boot.img は、最終的に生成されたブートパーティションイメージファイルです。

この時点で、rootfs.img ufi001c-boot.img が生成されています。 debian.zip フラッシュパッケージ内の rootfs.img boot.img を置き換えてフラッシュするだけです。

Ubuntu 22.04 での mdadm RAID リセット

Fri, 17 Mar 2023 00:00:00 +0000

mdadm を使用して RAID ディスクを作成します。 RAID を使用しなくなったら、RAID を削除する前に通常のディスクにリセットすることをお勧めします。そうしないと、使用時にさまざまな問題が発生します。

リセットプロセス

ステータスを確認する

lsblk -o NAME,SIZE,FSTYPE,TYPE,MOUNTPOINT
NAME      SIZE FSTYPE            TYPE  MOUNTPOINT
loop0       4K squashfs          loop  /snap/bare/5
loop1      62M squashfs          loop  /snap/core20/1587
loop2    63.3M squashfs          loop  /snap/core20/1828
loop4   239.8M squashfs          loop  /snap/firefox/2391
loop5   400.8M squashfs          loop  /snap/gnome-3-38-2004/112
loop6   346.3M squashfs          loop  /snap/gnome-3-38-2004/119
loop7    91.7M squashfs          loop  /snap/gtk-common-themes/1535
loop8    45.9M squashfs          loop  /snap/snap-store/582
loop9    45.9M squashfs          loop  /snap/snap-store/638
loop10   49.8M squashfs          loop  /snap/snapd/18357
loop11    284K squashfs          loop  /snap/snapd-desktop-integration/14
loop12    304K squashfs          loop  /snap/snapd-desktop-integration/49
loop13  241.6M                   loop  /snap/firefox/2432
sda      59.6G                   disk  
├─sda1    512M vfat              part  /boot/efi
└─sda2   59.1G ext4              part  /
nvme0n1 476.9G linux_raid_member disk  
└─md0   953.6G ext4              raid0 /mnt/md0
nvme1n1 476.9G linux_raid_member disk  
└─md0   953.6G ext4              raid0 /mnt/md0

linux_raid_memberのディスクにマウントポイントがあるか確認するコマンドを使用する場合

`1`	`umount /mnt/md0`

アンインストールする

襲撃をやめる

`1`	`sudo mdadm --stop /dev/md0`

スーパーブロックをクリアします。RAID 内のすべてのディスクをクリアする必要があります

1
2

sudo mdadm --zero-superblock /dev/nvme0n1
sudo mdadm --zero-superblock /dev/nvme1n1

構成ファイルを確認して、保持する必要があるかどうかを確認してください。 /etc/mdadm/mdadm.conf /etc/fstab

Ubuntu 22.04 で NTFS パーティションをマウントする際の書き込み速度が遅い問題の解決策

Sat, 04 Mar 2023 00:00:00 +0000

Ubuntu 22.04 で NTFS パーティションをマウントする際の書き込み速度が遅い問題の解決策

WD HC550 のハードディスクは、Windows では 250M/s 以上で読み書きできますが、Ubuntu では非常に遅く感じます。速度を測定してみたところ、読み込み速度は200M/s+と普通ですが、書き込み速度は80M/s+しかなく低速でした。マウントパラメータを変更する

ファイル /etc/fstab を変更します

`1`	`/dev/disk/by-uuid/xxxxxxxxxx /mnt/WD_16T_01 ntfs-3g defaults,lazytime,uid=1000,dmask=007,fmask=117,big_writes,nofail,auto 0 0`

変更後の読み取りおよび書き込み速度: 250M/s+

HP Z440 ワークステーションマザーボードを使用した DIY 低コスト 256G メモリホスト

Sun, 26 Feb 2023 00:00:00 +0000

HP Z440 ワークステーションマザーボードを選ぶ理由

メモリー選択

DDR4 2133 32G ECC REG メモリ 4R4 が 190/個に値下げされました
256G は 8 個だけ必要なので、合計価格 1908=1520
DDR3 を選択したほうが安いかもしれませんが、それほど悪くはありません。 DDR4の方が良い気がします。したがって、8 つのメモリスロットを備えたマザーボードを選択する必要があります。できるだけ軽く、小さくするには、CPU を 1 つだけ搭載するのが最適です。

CPUの選択

私は一番早い段階で E5 2620 V3 を選択しましたが、タオバオで送料無料で 9.9 元でした。

安いのが主な理由ですが、マザーボードのBIOSが古すぎるとV4のCPUポイントが不良になるのではないかという不安もあります。
ただし、E5 2620 V3 はメモリ周波数 1866 のみをサポートします。正式に使用する場合は、淘宝網で約 30 元の E5 2620 V4 または E5 2630 V4 を検討できます。

Z440 でベアボーンを試してみませんか

シャーシ全体が重すぎるため、持ち運びが不便であり、部品の分解や組み立ても面倒です。さらに、HP がこのシステムに提供する最大電源はわずか 700 ワットであり、少し小さいです。 Xianyu で Z440 マザーボード + 電源アダプターケーブルを合計 400 で売っている人を見かけたので、マザーボードを購入して戻ってきました。

マザーボードをいじり始める

マザーボードインターフェース図

寸法とネジ穴の位置

サイズは標準の ATX で、ネジ穴は基本的に揃っており、ここでは正常です。
しかし、問題はCPUソケットのバックプレートにあります。バックプレートは少し高く、シャーシに押し付けられます。ネジポストが短くなりました。ネジを強く締めることもできますが、マザーボードがわずかに変形する可能性があります。
最初のアイデアは、銅柱をより高いものに交換することでした。交換後、マザーボードの取り付けはOKでしたが、PCIE拡張カードがネジ止めできないことが分かりました。
したがって、唯一の解決策はバックプレーンを交換することです。

シャーシインターフェースパネル

インターフェースNo.25

ブート警告を排除する

このマザーボードには多くのテストが行われています。何も気にしないと、大量の警告が表示されます。

フロントUSB

前面 USB が BIOS に接続されていない場合、エラーが報告されます。

必要ない場合は、ジャンパ接続だけを行ってください。

オーディオインターフェース

シャーシに直接接続できます。接続しないとエラーが報告されます。そうでない場合は、Presence と Ground を接続するだけです。

接続するジャンパーキャップを見つけるだけです

ファンの警告

このマザーボードには、CPU ファン、メモリファン (2 個)、フロントファン、およびケースファンがあります。接続されていない場合、エラーが発生する可能性があります。 CPUファンは6ピンあります。普通の4ピンファンの片側のスロットを切って差し込むだけです。他のファンも可能な限り接続する必要があります。最初はエラーが報告されない場合がありますが、構成が変更され、温度が変化すると、警告が表示される場合があります。たとえば、メモリ量が少ない場合はアラームは発生しませんが、メモリ量が多い場合はアラームが発生します。
温度が上がりすぎるとケースファンがアラームを鳴らすようです。あまり使用しない場合は、空ファンの回転数検出ピンを使用済みファンに接続することで警告を解除できます。

メモリファンを除いて、他のすべてのファンには右から 3 番目のピンがあり、これは速度検出です。 CPUファン6ピン、右から揃えて接続

電力警告

以前のものを変更した後、警告は 1 つを除いて基本的に解決されました。
539 - Power supply wattage insufficient for LR dimm memory configuration
これは電源に関係しているようです。改造した電源コードに何か問題があるのではないかと思います。

このマザーボードには、18P と 12P の 2 つの電源インターフェイスがあります。

18p 電源インターフェイスの定義

+12V_B は、マザーボードの +3.3V および 5V レギュレータ、一部の補助 CPU 電圧、および一部のファンに電力を供給します。
+12V_S は、一部のチップセットレギュレータ、その他の周辺回路、および PCI スロット 3、4、および 5 に電力を供給します。
+12V_D はスロット 1 と 2 に電力を供給します。

12P 電源インターフェイスの定義

この12PはCPU 8PとCPU 4Pの電源です。
マザーボードに近い 6 ピンはアース線で、その上の 6 ピンは 12V です。
CPU とメモリはこの 12 ピンコネクタから電力を供給されます。

ただし、すべての電圧ピンが検出され、必要な電圧が生成されましたが、警告が常に存在していました。

後で次の投稿を見つけました
HP Z440开机自检提示错误 539-LR内在 DIMM 配置的电源功率不足
 “Power supply insufficient” warning problem
この警告は電源とは関係ありません。 Z440 がオリジナルの 700 ワット電源を使用している場合でも、LR メモリが使用されている限りこの警告が表示され、オフにすることはできません。
非 LD メモリを使用する場合、そのような警告は表示されません。

Z640 の 925 ワット電源を使用すると、この問題を解決できるかもしれません。電源種類の検出は18pインターフェースの9番ピンです。これを変更すると問題が解決する可能性があります。
既存のアナログ回線の9番ピンは接地されています。テストしましたが、接続しないと動作しませんでした。

最終結果

結局、LR dimm 使用時に警告 539 - LR dimm メモリ構成に電源のワット数が不足していますがクリアできないため、他の警告をクリアする計画は断念しました。警告をスキップするには、起動時に Enter キーを押すことを選択します。 Intel AMT を使用すると、リモート起動してこれらの警告をスキップすることもできるため、問題ありません。ただし、2Rx4 REG ECC メモリ (REG メモリ、非 LREG メモリ) を使用すると、すべての警告を完全に排除できます。ただし、2Rx4 の REG ECC メモリは高価になります。

リモコン

このマザーボードには BMC がありません。ブート警告がある場合、WOL (wake on lan) ネットワークウェイクアップはシステムインターフェイスから直接ブートできません。キーボードの任意のキーを押すとスキップされます。このマザーボードは Intel AMT をサポートしていますが、サーバー E5 CPU を使用しており、コアディスプレイを備えていないため、完全な AMT 機能をサポートすることはできません。主にリモートデスクトップをサポートしていません。 AMTで利用できる機能は以下のとおりです。

リモート電源オン/オフ、再起動
システム情報と構成を表示する
Serial-over-Lan を使用すると、起動時にテキストインターフェイスでコンソールを表示し、キーを押して警告をスキップできます。
ほぼすべての基本的なリモコン機能が利用可能です。

サーバー(Z440)の構成

AMT の構成について話しましょう。

起動時に CTRL + P を押して、AMT 設定に入ります。何度か試す必要があります。検出に時間がかかり、見逃しやすいようです。
初めて入るときは、パスワードの設定を求められます。パスワードは次の条件を満たす必要があります。満たさない場合、設定は失敗し、明確なプロンプトは表示されません。

  至少8位字符；
  必须包括一位0，1，2 ··· 9数字；
  必须包括一位非文字、数字的ASCII字符，如!，@，$；
  必须包括大写、小写拉丁字符，如A，a，B，b；

AMT設定インターフェイスに入る
パスワードを設定した後、Intel(R) AMT Configurationを直接選択してAMT設定インターフェイスに入ります。
AMTパラメータを設定する
Network Setup は ATM で使用される IP アドレスを設定します
[ユーザーの同意] で、[ユーザーオプトイン] オプションを [なし] に変更して、リモートアクセスを無効にし、パスワードを要求します。
ネットワークアクセスをアクティブ化すると、ネットワーク経由で AMT にアクセスできるようになります
SOL/IDER 設定 Serial-over-LAN
必ずレガシーリダイレクトモードをオンにしてください。オンにしないと、画面が黒いままになり、Serial-over-LAN で画像が表示されなくなります。

クライアント制御設定

ウェブへの直接アクセスブラウザは http://amt-ip:16992 に直接アクセスしますシステムステータスの設定情報、電源のオンとオフのみが表示され、端末インターフェイスは表示されません。
MeshCommander の使用
下载地址 : https://www.meshcommander.com/meshcommander
アカウントのセットアップ:

ホストのAMTに接続した後

Serial-over-LAN の使用

まず「接続」をクリックし、次に「電源を入れて起動する」を選択します。
次に、起動ターミナルインターフェイスが表示されます
投稿エラーメッセージも表示されます。 Enter を押して起動をスキップして続行します。
こうすることで、起動警告をスキップして、インストールされているシステムに入ることができます。

グラフィックカードなしで開始

このマザーボードには HDMI DP ポートがなく、E5 V3 V4 シリーズ CPU を使用する場合は統合グラフィックスカードがないため、フラッシュグラフィックスカードを取り付ける必要があります。
このグラフィックスカードは PCIe スロットを占有します。すべての構成が完了したときに、このグラフィックスカードを取り外すと、システムはオペレーティングシステムを起動できず、途中で停止します。
BIOS にはヘッドレスブート機能を有効にするオプションはありませんが、これはいくつかの方法で実現できます。
その方法は次のとおりです。

ESC を押して起動し、BIOS に入ります
複製されたセットアップを選択します
FAT32 でフォーマットされた USB フラッシュドライブを Z440 の USB ポートに挿入します。
現在の設定を USB デバイスにバックアップするを選択します
次に、USB ディスクを開くと、ファイル HpSetup.txt がルートディレクトリに表示されます。
HpSetup.txt ファイルを開き、「ヘッドレスブート」を検索します。改造前

1
2
3

Headless Boot
	*Disable
	Enable

修正後

1
2
3

Headless Boot
	Disable
	*Enable

変更後、Z440 BIOS で [複製されたセットアップ] -> [USB デバイスから現在の設定を復元] を選択します。
セットアップが完了したら、グラフィックスカードを取り外して起動できます。

消費電力

E5 2630V4 CPUを使用してテスト済み

シングル 32g ECC REG 2133 4R*4 メモリ、ブート SSD のみ、グラフィックスカードなし、Ubuntu デスクトップに対応、消費電力 41 ワット
8 32g ECC REG 2133 4R4 メモリを挿入、SSD のみ起動、グラフィックスカードなし、Ubuntu デスクトップに入り、消費電力 60 ワット (60-41) / 7 = 3 ワット各 32g ECC REG 2133 4R4 メモリは約 3 ワットを消費します

Certbot による無料の Let's Encrypt 証明書の更新が成功したことを確認する方法

Thu, 08 Dec 2022 00:00:00 +0000

スケジュールされたタスクが存在するかどうかを確認する

root@localhost:~# sudo systemctl status certbot.timer
● certbot.timer - Run certbot twice daily
     Loaded: loaded (/lib/systemd/system/certbot.timer; enabled; vendor preset: enabled)
     Active: active (waiting) since Wed 2022-12-07 02:08:51 UTC; 22h ago
    Trigger: Thu 2022-12-08 04:56:59 UTC; 3h 49min left
   Triggers: ● certbot.service

Dec 07 02:08:51 localhost systemd[1]: Started Run certbot twice daily.

上記のスケジュールされたタスクが存在する場合、タイミングは成功です。
新しいバージョンでは、スケジュールされたタスクはインストール中に自動的に設定されるため、手動で設定する必要はありません。

更新操作が成功するかどうかを確認する

certbot renew コマンドを使用して確認します。実行後、certbot が管理するすべてのドメイン名が検証されます。

root@localhost:~# sudo certbot renew --dry-run
Saving debug log to /var/log/letsencrypt/letsencrypt.log

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/abc.com.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Simulating renewal of an existing certificate for ijoke.fun and abc.com and www.abc.com

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/knightli.com.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Simulating renewal of an existing certificate for knightli.com and www.knightli.com

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Congratulations, all simulated renewals succeeded: 
  /etc/letsencrypt/live/abc.com/fullchain.pem (success)
  /etc/letsencrypt/live/knightli.com/fullchain.pem (success)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

すべてのシミュレートされた更新が成功したことを確認し、すべてが成功したことを示します。

よくある失敗例

root@localhost:/# sudo certbot renew --dry-run
Saving debug log to /var/log/letsencrypt/letsencrypt.log
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/abc.com.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Simulating renewal of an existing certificate for abc.com and www.abc.com
Failed to renew certificate abc.com with error: Could not bind TCP port 80 becau
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/knightli.com.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Simulating renewal of an existing certificate for knightli.com and www.knightli.com
Failed to renew certificate knightli.com with error: Could not bind TCP port 80 because it is already in use by another process on this system (such as a web server). Please stop the program in question and then try again.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
All simulated renewals failed. The following certificates could not be renewed:
  /etc/letsencrypt/live/abc.com/fullchain.pem (failure)
  /etc/letsencrypt/live/knightli.com/fullchain.pem (failure)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
2 renew failure(s), 0 parse failure(s)
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.

上記は失敗例です。失敗の理由は、証明書の申請時にスタンドアロン方式が使用されたためです。 Certbotは申請時および更新時に自らhttpサービスを構築します。これが他の http サーバーを実行しているサーバーである場合、障害が発生します。

これを成功させるには、certbot の構成ファイルを変更する必要があります。

/etc/letsencrypt/renewal/ ディレクトリでドメイン名に対応する構成ファイルを見つけます。

root@localhost:~# ll /etc/letsencrypt/renewal
drwxr-xr-x 2 root root 4096 Dec  7 02:59 ./
drwxr-xr-x 9 root root 4096 Dec  8 01:09 ../
-rw-r--r-- 1 root root  530 Dec  7 02:59 abc.com.conf
-rw-r--r-- 1 root root  545 Dec  7 02:59 knightli.com.conf

対応する構成ファイルを変更します

原有
authenticator = standalone

修改成（适用于nginx服务器的情形）
authenticator = nginx
installer = nginx

Synology NAS 上に Git サーバーをセットアップし、定期的なバックアップに Hyper Backup を使用する

Wed, 07 Dec 2022 00:00:00 +0000

Gitサーバーを構築する

パッケージセンターに Git サーバーをインストールする

ユーザーを作成する

アカウント名が git であると仮定して、git リポジトリデータを保存するための新しいユーザーを作成します。
コントロールパネル -> ユーザーアカウント -> 新規

ユーザーホームサービスを有効にする

[コントロールパネル] -> [ユーザーアカウント] -> [詳細設定] に移動し、「ユーザーホームサービス」を有効にします。

SSH機能を有効にする

Git サーバーには SSH 経由でアクセスする必要があります。「コントロールパネル」→「ターミナルとSNMP」に進み、「SSH機能を有効にする」にチェックを入れます。

SSH 経由で Synology NAS に接続する

SSH ツール (Windows ターミナル、Putty、Xshell など) を使用して Synology NAS に接続します
アカウント番号とパスワードはユーザー作成時に入力した内容です。プロンプトに従ってユーザー名を入力します。パスワードが渡されると、接続は成功します。

証明書によるパスワード不要のログインを設定する

ユーザーのホームディレクトリは /var/services/homes/git/ です。ホームディレクトリに .ssh ディレクトリを作成し、.ssh ディレクトリにauthorized_keys ファイルを作成して、このファイルにキーを保存します。完了後のディレクトリ構造は次のようになります。

root@DiskStation:/var/services/homes/git# ll
total 0
drwxr-xr-x  1 git  users 726 Dec  7 21:21 .
drwx--x--x+ 1 root root   58 Dec  7 21:17 ..
drwx------  1 git  users  30 Dec  6 12:37 .ssh

root@DiskStation:/var/services/homes/git# cd .ssh/
root@DiskStation:/var/services/homes/git/.ssh# ll
total 4
drwx------ 1 git users   30 Dec  6 12:37 .
drwxr-xr-x 1 git users  726 Dec  7 21:21 ..
-rw-r--r-- 1 git users 2408 Dec  6 11:35 authorized_keys

root@DiskStation:/var/services/homes/git/.ssh# more authorized_keys 
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDLZE20i2x2ms4BzrLwOsusHa/Xe2x4bA4fhJvlcTF9yVGJZEaHKHOPOGbxAxGtP0igqjIp95yRPwBX+YYWL9oG26LSBVZ8fuDbcj/TVVIP5rsG+5W4UrZxZHrPd91LQRCfIWPr7XfjTCZr9amaan7GCw2Zf/1pSiYmhfI4yWwteB/29TOavWNf1+ArWm/dFtfA
Nea6/BTJFRjrJuhh91VR1exOxEFK7gVRmg6KsmKzGNhSPkzlhRXLyQz7ttyaCY6VIH6NyHWjMnd8Io/tfpv7mL89/XfdnKgmkhzeUWUoAgvDBGnZpaFRV9PnSZDvV5BPcBx7WG9+4yPrAqj8x knightli@ubuntu

ファイルやディレクトリの権限情報を変更する

1
2

chmod 700 .ssh
chmod 644 .ssh/authorized_keys

sshd 構成ファイル /etc/ssh/sshd_config を変更します。次の 3 行が必要であることに注意してください。 # でコメントされている場合は、コメントを開きます。対応する行がない場合は追加する必要があります。

1
2
3

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile  .ssh/authorized_keys

設定が成功すると、SSH パスワードを使用せずに SSH 経由で直接 Synology NAS にログインできるようになります。この手順は、今後 git コマンドを使用するたびにパスワードを入力する必要を避けるためです。

Git サーバーを使ってみる

サーバー側にプロジェクトリポジトリを作成する

git@DiskStation:~$ mkdir my_project
git@DiskStation:~$ cd my_project/
git@DiskStation:~/my_project$ git init --bare
hint: Using 'master' as the name for the initial branch. This default branch name
hint: is subject to change. To configure the initial branch name to use in all
hint: of your new repositories, which will suppress this warning, call:
hint: 
hint:   git config --global init.defaultBranch <name>
hint: 
hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
hint: 'development'. The just-created branch can be renamed via this command:
hint: 
hint:   git branch -m <name>
Initialized empty Git repository in /volume1/homes/git/my_project/

クライアント側の操作

1
2
3

C:\Users\knightli>git clone git@192.168.8.100:my_project
Cloning into 'my_project'...
warning: You appear to have cloned an empty repository.

コマンドラインの clone の後の git は、サーバーによって作成されたアカウント名です。
my_project はプロジェクトのウェアハウス名です。

クローンが完了すると、その後の操作は通常どおりになります。
プッシュが完了すると、データは Synology NAS の git ユーザーホームディレクトリに保存されます。

git@DiskStation:~/my_project$ ll
total 12
drwxr-xr-x 1 git users  98 Dec  7 22:23 .
drwxr-xr-x 1 git users 746 Dec  7 22:23 ..
drwxr-xr-x 1 git users   0 Dec  7 22:23 branches
-rw-r--r-- 1 git users  66 Dec  7 22:23 config
-rw-r--r-- 1 git users  73 Dec  7 22:23 description
-rw-r--r-- 1 git users  23 Dec  7 22:23 HEAD
drwxr-xr-x 1 git users 506 Dec  7 22:23 hooks
drwxr-xr-x 1 git users  14 Dec  7 22:23 info
drwxr-xr-x 1 git users  16 Dec  7 22:23 objects
drwxr-xr-x 1 git users  18 Dec  7 22:23 refs

Hyper Backup のスケジュールされたバックアップ

git リポジトリデータはすべて /var/services/homes/git/ にあります。このディレクトリをバックアップするだけで済みます。

ハイパーバックアップをインストールする

ハイパーバックアップの構成

openwrtカスタムコンパイルからフラッシュまでのRedmi AX6Sルーターの全プロセス

Sun, 04 Sep 2022 00:00:00 +0000

AX6Sのハードウェア構成

CPU MediaTek MT7622B 2 cores A53
Flash 128MB NAND
Ram 256MB
https://www.mi.com/global/product/xiaomi-router-ax3200/

AX6S 用の Openwrt カスタムコンパイル

まず Linux システムをインストールします。Ubuntu LTS を推奨します。

コンパイルの依存関係をインストールする

sudo apt update -y
sudo apt full-upgrade -y
sudo apt install -y ack antlr3 asciidoc autoconf automake autopoint binutils bison build-essential \
bzip2 ccache cmake cpio curl device-tree-compiler fastjar flex gawk gettext gcc-multilib g++-multilib \
git gperf haveged help2man intltool libc6-dev-i386 libelf-dev libglib2.0-dev libgmp3-dev libltdl-dev \
libmpc-dev libmpfr-dev libncurses5-dev libncursesw5-dev libreadline-dev libssl-dev libtool lrzsz \
mkisofs msmtp nano ninja-build p7zip p7zip-full patch pkgconf python2.7 python3 python3-pip libpython3-dev qemu-utils \
rsync scons squashfs-tools subversion swig texinfo uglifyjs upx-ucl unzip vim wget xmlto xxd zlib1g-dev

ソースコードをダウンロードし、フィードを更新し、構成を選択します

git clone https://github.com/coolsnowwolf/lede
cd lede
./scripts/feeds update -a
./scripts/feeds install -a
make menuconfig

ターゲットプロファイルの選択
LuCI -> アプリケーション -> を選択します。


[ * ]	表示选中
[ ]	不选
< M >	编译成模块

一般的なアプリケーション

名称	菜单位置	说明
luci-app-adbyby-plus	服务 -> 广告屏蔽大师 Plus +	可以让同一网络环境下的设备，都能享受到去广告的效果
luci-app-aliddns	服务 -> 阿里DDNS	阿里的ddns解析
luci-app-ddns	服务 -> 动态域名	动态域名 , 不支持阿里DDNS
luci-app-autoreboot	系统 -> 定时重启	可以设定定时重启
luci-app-arpbind	网络 -> IP/MAC 绑定	绑定IP/MAC
luci-app-filetransfer	系统 -> 文件传输	传输文件到openwrt的文件系统
luci-app-firewall	网络 -> 防火墙	防火墙
luci-app-frpc	服务 -> Frp 内网穿透	Frp内网穿透客户端
luci-app-frps	服务 -> Frps	Frp内网穿透服务端
luci-app-guest-wifi	网络 -> 访客网络	WiFi访客网络
luci-app-nlbwmon	带宽监控	包括带宽监控菜单下的所有内容
luci-app-qos	网络 -> QoS	服务质量, 可以分类设置各种流量的优先级
luci-app-ssr-plus	服务 -> ShadowSocksR Plus+	科学上网, 可以选择需要的plugin
luci-app-turboacc	网络 -> Turbo ACC 网络加速设置	网络加速
luci-app-unblockmusic	无菜单	解锁网易云音乐
luci-app-upnp	服务-> UPnP	通用即插即用（UPnP）
luci-app-vlmcsd	服务 -> KMS服务器	微软产品激活服务器
luci-app-wireguard	网络 -> 接口菜单设置	状态 -> WireGuard 状态可以查看链接状态
luci-app-wol	服务 -> 网络唤醒	网络唤醒

必要な機能を選択して保存します。すべて選択したら終了します。

DL ライブラリをダウンロードし、ファームウェアをコンパイルします (-j の後にスレッド数が続きます。最初のコンパイルでは単一スレッドを使用することをお勧めします)。

1
2

make download -j8
make V=s -j1

コンパイルが正常に完了すると、コンパイルされたファームウェアは ~/lede/bin/targets/mediatek/mt7622/ に配置されます。


首次刷机使用	openwrt-mediatek-mt7622-xiaomi_redmi-router-ax6s-squashfs-factory.bin
在openwrt系统中升级使用	openwrt-mediatek-mt7622-xiaomi_redmi-router-ax6s-squashfs-sysupgrade.bin

クラックアンドフラッシュ AX6S

Redmiテストファームウェアをフラッシュする

テストファームウェアをフラッシュした後でのみ、後続の操作のために Telnet 経由で AX6S に接続できます。テストファームウェア miwifi_rb03_firmware_stable_1.2.7.bin

Telnetパスワードを計算する

番号を計算するにはルーターの SN 番号が必要です。この番号はマシンの背面のラベルに記載されています。バックグラウンド管理インターフェイスも見つかります
数値を計算する多くの Web サイトは期限切れになりました。次の Python プログラムを実行して自分で計算できます。

#!/usr/bin/env python3
import sys
import hashlib

if sys.version_info < (3,7):
    print("python version is not supported", file=sys.stderr)
    sys.exit(1)

# credit goes to zhoujiazhao:
# https://blog.csdn.net/zhoujiazhao/article/details/102578244

salt = {'r1d': 'A2E371B0-B34B-48A5-8C40-A7133F3B5D88',
        'others': 'd44fb0960aa0-a5e6-4a30-250f-6d2df50a'}


def get_salt(sn):
    if "/" not in sn:
        return salt["r1d"]

    return "-".join(reversed(salt["others"].split("-")))


def calc_passwd(sn):
    passwd = sn + get_salt(sn)
    m = hashlib.md5(passwd.encode())
    return m.hexdigest()[:8]


if __name__ == "__main__":
    if len(sys.argv) != 2:
        print(f"Usage: {sys.argv[0]} <S/N>")
        sys.exit(1)

    serial = sys.argv[1]
    print(calc_passwd(serial))

1
2

abc@openwrt-build:~$ python calc_ax6s_pwd.py SN
00d135eb

出力は Telnet パスワードです

TelnetでAX6Sに接続

ルーターに接続する前に、まずルーターの IP アドレスを決定します。ルーターの LAN アドレスは、ルーターが接続されているネットワークの管理インターフェイスを介して表示できます。たとえば、私のルーターの IP アドレスは 192.168.0.121 です。ターミナルを開き、次のコマンドを入力します。
telnet 192.168.0.121
ユーザー名: ルートパスワード: 先ほど計算したパスワード

ログインに成功したら、次を実行します。

1
2
3

nvram set ssh_en=1 && nvram set uart_en=1 && nvram set boot_wait=on && nvram set bootdelay=3 && nvram set flag_try_sys1_failed=0 && nvram set flag_try_sys2_failed=1
nvram set flag_boot_rootfs=0 && nvram set "boot_fw1=run boot_rd_img;bootm" && nvram set flag_boot_success=1 && nvram commit 
/etc/init.d/dropbear enable && /etc/init.d/dropbear start

実行が成功すると、scp サービスが開き、scp サービスを使用してファームウェアをルーターにアップロードします。

ファームウェアをアップロードする

Windows は、winscp ソフトウェアを使用してルーターに接続し、上記の手順でコンパイルしたファイル openwrt-mediatek-mt7622-xiaomi_redmi-router-ax6s-squashfs-factory.bin を /tmp/ ディレクトリにアップロードし、その名前を Factory.bin ファイルに変更します。

フラッシュファームウェア

Telnet ウィンドウで次のコマンドを使用して、ファームウェアをフラッシュします。

`1`	`mtd -r write /tmp/factory.bin firmware`

点滅が完了すると、ルーターが再起動します。再起動が完了すると、デフォルトの情報は次のようになります。
IPアドレス：192.168.1.1
USER: root
Password: password

問題が点滅した後の回復

Xiaomiルーター修復ツールをダウンロード
https://bigota.miwifi.com/xiaoqiang/tools/MIWIFIRepairTool.x86.zip
使用方法
サポートされているモデルに ax6s はありませんが、個人的なテストには利用できます。 PC 側の修復ツールを使用するには、ネットワークカードの構成を変更するためのシステム権限が必要であり、使用する前にウイルス対策アプリケーションを終了する必要があります。
https://web.vip.miui.com/page/info/mio/mio/detail?postId=19134127&app_version=dev.20051

シビルアタック

Tue, 05 Jul 2022 00:00:00 +0000

名前の由来

フローラ・レア・シュライベリーの1973年の小説『シビル』を原作とした同名の映画は、シビル・ドーセットというペンネームで受けた女性の心理療法の物語である。彼女は解離性同一性障害と診断されており、16の人格を持っています。

魔女の攻撃

シビルアタック、中国語訳は「魔女の攻撃」。この形式の攻撃はブロックチェーンネットワークに特有のものではありません。これは、2002 年の「シビル攻撃」で John R. Douceur によって初めて提案されました。当時は、p2p ネットワークにおける攻撃の形式を指していました。攻撃者は単一ノードを使用して複数の ID を偽造し、分散ストレージシステムの冗長メカニズムを破壊しました。 Sybil 攻撃は、次のようなさまざまなネットワークサービスに存在します。

P2Pネットワーク
ピアツーピア (英語:peer-to-peer、P2P とも呼ばれる) は、ピアツーピア技術としても知られ、ユーザーグループ (ピア) に依存して情報を交換する分散型インターネットシステムです。その機能は、以前のネットワーク送信のノード数を減らして、データ損失のリスクを軽減することです。中央サーバーを備えた中央ネットワークシステムとは異なり、ピアツーピアネットワーク内の各クライアントはノードでもありサーバーでもあります。どのノードも他のノードを直接見つけることができないため、情報交換にはそのユーザーグループに依存する必要があります。 P2 で複数の ID を偽造すると、ネットワークのデータ冗長性機能が弱まります
ソーシャルネットワーク
攻撃者は複数のアイデンティティを作成し、社会活動を行っており、これは魔女攻撃とみなされます。
ブロックチェーンネットワーク
攻撃者がブロックチェーンネットワーク内に十分な偽の ID を作成した場合、多数決でネットワーク上の実際のノードを破り、ブロックの送受信を拒否することができます。大規模なウィッチ攻撃では、取引の順序が簡単に変更され、取引が確認できなくなったり、取引が取り消されたりして、二重支払いなどの問題が発生します。

ブロックチェーンネットワークは魔女の攻撃をどのように解決するのでしょうか?

ブロックチェーンネットワークは、暗号的に検証可能で希少な (無限ではない) リソースを使用して、この問題を解決します。つまり、ノードには、ある種の暗号的に検証可能な希少なリソースが必要となるため、ノードの要件が大幅に増加し、ウィッチ攻撃の難易度が高まります。

コンピューティング能力 (Proof of Work)
ビットコインは、プルーフ・オブ・ワークを使用してトランザクションを検証し、ネットワークのセキュリティを確保します。さらに、作業証明により二重支出の問題を防ぐことができます。ブロックチェーンのセキュリティは、新しいブロックを確認してブロックチェーンを更新する権利を得るためにコンピューティング能力を使用して互いに競争する「マイナー」と呼ばれる参加者によって守られています。成功したマイナーにはネットワークからビットコインが与えられます。 2021 年 12 月の時点で、マイナーはマイニングに成功したビットコインブロックごとに 6.25 ビットコインのブロック報酬と取引手数料を受け取ります。
ステークの証明
Proof of Stake は Proof of Work の最も一般的な代替手段であり、スケーラビリティやエネルギー消費の問題など、Proof of Work の制限を改善するために設計されたコンセンサスメカニズムです。「バリデーター」と呼ばれるプルーフ・オブ・ステークの参加者は、ブロックを検証する機会をめぐって競争するために強力なハードウェアデバイスを使用する必要はありません。ブロックチェーンのネイティブ暗号通貨をステーク (ロック) するだけで済みます。次にネットワークは、賭けられた暗号通貨の量に基づいて勝者を選択し、検証したブロックからの取引手数料の割合を勝者に報酬として与えます。ステーキングされるトークンが多ければ多いほど、バリデーターになる可能性が高くなります。

Hugo の Markdown で複雑なテーブルを使用する

Sun, 15 May 2022 00:00:00 +0000

Markdown 構文自体には複雑なテーブルの挿入が含まれていないため、HTML 構文を使用して実現できます。

Hugo で HTML サポートを有効にする

config.yaml
 
markup:
  goldmark:
    renderer:
      unsafe: true

unsafe:
デフォルトでは、Goldmark は生の HTML と潜在的に危険なリンクをレンダリングしません。インライン HTML や JavaScript が大量にある場合は、これをオンにする必要があります。

html構文

複雑なテーブルと単純なテーブルの間には、水平セルの結合と垂直セルの結合という 2 つの大きな違いがあります。 HTML 構文を通じてこれら 2 つの操作を実現する本質は、冗長な空白セルを削除し、特定のセルの Colspan 属性と rowspan 属性を使用して塗りつぶしを拡張することです。

水平方向のセルの結合: 1 つのセルが複数の列のスペースを占めている場合でも、colspan 属性に基づきます。垂直セルの結合: 1 つのセルが複数の行のスペースを占めている場合でも、rowspan 属性に基づきます。

行を結合する

<table>
    <tr>
        <td>列一</td>
        <td>列一</td>
   </tr>
    <tr>
        <td colspan="2">合并行</td>
    </tr>
    <tr>
        <td colspan="2">合并行</td>
    </tr>
</table>

表示効果:

列一	列一
合并行
合并行

列を結合する

<table>
    <tr>
        <td>列一</td>
        <td>列二</td>
   </tr>
    <tr>
        <td rowspan="2">合并列</td>
        <td >行二列二</td>
    </tr>
    <tr>
        <td >行三列二</td>
    </tr>
</table>

表示効果:

列一	列二
合并列	行二列二
行三列二

行と列を結合する

<table>
    <tr>
        <td>列一</td>
        <td>列二</td>
   </tr>
   <tr>
        <td colspan="2">合并行</td>
   </tr>
   <tr>
        <td>列一</td>
        <td>列二</td>
   </tr>
    <tr>
        <td rowspan="2">合并列</td>
        <td >行二列二</td>
    </tr>
    <tr>
        <td >行三列二</td>
    </tr>
</table>

表示効果:

列一	列二
合并行
列一	列二
合并列	行二列二
行三列二

Ubuntu 20.04 で Mellanox Infiniband ネットワークカードの IP アドレスを設定する方法

Fri, 29 Apr 2022 00:00:00 +0000

ネットワークカードの状態を確認する

knightli@epyc:~$ ibstat
CA 'mlx4_0'
        CA type: MT4103
        Number of ports: 2
        Firmware version: 2.42.5700
        Hardware version: 0
        Node GUID: 0x98f2b3ffffd5c3c0
        System image GUID: 0x98f2b3ffffd5c3c3
        Port 1:
                State: Down
                Physical state: Disabled
                Rate: 40
                Base lid: 0
                LMC: 0
                SM lid: 0
                Capability mask: 0x00010000
                Port GUID: 0x9af2b3fffed5c3c1
                Link layer: Ethernet
        Port 2:
                State: Down
                Physical state: Disabled
                Rate: 40
                Base lid: 0
                LMC: 0
                SM lid: 0
                Capability mask: 0x00010000
                Port GUID: 0x9af2b3fffed5c3c2
                Link layer: Ethernet

ネットワークポートのステータスを確認できる必要がある

ネットワークカードのデバイス名（論理名）を表示します。

knightli@epyc:~$ sudo lshw -c network
[sudo] password for knightli: 
  *-network DISABLED
       description: Ethernet interface
       product: MT27520 Family [ConnectX-3 Pro]
       vendor: Mellanox Technologies
       physical id: 0
       bus info: pci@0000:28:00.0
       logical name: enp40s0
       logical name: /dev/fb0
       version: 00
       serial: 98:f2:b3:d5:c3:c1
       capacity: 56Gbit/s
       width: 64 bits
       clock: 33MHz
       capabilities: pm vpd msix pciexpress bus_master cap_list rom ethernet physical fibre 1000bt-fd 10000bt-fd 40000bt-fd 56000bt-fd autonegotiation fb
       configuration: autonegotiation=on broadcast=yes depth=32 driver=mlx4_en driverversion=4.9-4.1.7 duplex=full firmware=2.42.5700 latency=0 link=no mode=1024x768 multicast=yes visual=truecolor xres=1024 yres=768
       resources: iomemory:1130-112f irq:133 memory:eb700000-eb7fffff memory:11390000000-11391ffffff memory:eb600000-eb6fffff memory:11392000000-113b1ffffff
  *-network DISABLED
       description: Ethernet interface
       physical id: 3
       bus info: pci@0000:28:00.0
       logical name: enp40s0d1
       serial: 98:f2:b3:d5:c3:c2
       capacity: 56Gbit/s
       capabilities: ethernet physical fibre 1000bt-fd 10000bt-fd 40000bt-fd 56000bt-fd autonegotiation
       configuration: autonegotiation=on broadcast=yes driver=mlx4_en driverversion=4.9-4.1.7 firmware=2.42.5700 link=no multicast=yes

複数のポートには複数のデバイス名が付けられます。たとえば、上記のポートが 2 つあり、それぞれに enp40s0 と enp40s0d1 という 2 つの論理名が付いています。

ネットプラン構成ファイルを変更する

各ポートに対応するIPを設定します

root@epyc:/home/knightli# vi /etc/netplan/00-installer-config.yaml 


# This is the network config written by 'subiquity'
network:
  ethernets:
    eno1:
      dhcp4: true
    enp40s0:
      addresses: [172.18.8.1/24]
    enp40s0d1:
      addresses: [172.18.9.1/24]
  version: 2

変更が完了したら、netplan apply を実行します。

`1`	`root@epyc:/home/knightli# netplan apply`

チェック結果

root@epyc:/home/knightli# ifconfig
enp40s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 172.18.8.1  netmask 255.255.255.0  broadcast 172.18.8.255
        inet6 fe80::9af2:b3ff:fed5:c3c1  prefixlen 64  scopeid 0x20<link>
        ether 98:f2:b3:d5:c3:c1  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 40  bytes 5671 (5.6 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

enp40s0d1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 172.18.9.1  netmask 255.255.255.0  broadcast 172.18.9.255
        inet6 fe80::9af2:b3ff:fed5:c3c2  prefixlen 64  scopeid 0x20<link>
        ether 98:f2:b3:d5:c3:c2  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 40  bytes 5671 (5.6 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 130  bytes 11184 (11.1 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 130  bytes 11184 (11.1 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

root@epyc:/home/knightli# ibstat
CA 'mlx4_0'
        CA type: MT4103
        Number of ports: 2
        Firmware version: 2.42.5700
        Hardware version: 0
        Node GUID: 0x98f2b3ffffd5c3c0
        System image GUID: 0x98f2b3ffffd5c3c3
        Port 1:
                State: Active
                Physical state: LinkUp
                Rate: 40
                Base lid: 0
                LMC: 0
                SM lid: 0
                Capability mask: 0x00010000
                Port GUID: 0x9af2b3fffed5c3c1
                Link layer: Ethernet
        Port 2:
                State: Active
                Physical state: LinkUp
                Rate: 40
                Base lid: 0
                LMC: 0
                SM lid: 0
                Capability mask: 0x00010000
                Port GUID: 0x9af2b3fffed5c3c2
                Link layer: Ethernet

Mellanox Infiniband カードスイッチ IB/イーサネット/VPI 動作モード

Thu, 28 Apr 2022 00:00:00 +0000

ネットワークカードの現在の動作ステータスを確認します

ibstat を実行すると、ネットワークカードの動作モードが返されるリンク層情報が返されます。

knightli@epyc:~$ sudo ibstat
CA 'mlx4_0'
        CA type: MT4103
        Number of ports: 2
        Firmware version: 2.42.5700
        Hardware version: 0
        Node GUID: 0x98f2b3ffffd5c3c0
        System image GUID: 0x98f2b3ffffd5c3c3
        Port 1:
                State: Down
                Physical state: Disabled
                Rate: 40
                Base lid: 0
                LMC: 0
                SM lid: 0
                Capability mask: 0x00010000
                Port GUID: 0x9af2b3fffed5c3c1
                Link layer: Ethernet
        Port 2:
                State: Down
                Physical state: Disabled
                Rate: 40
                Base lid: 0
                LMC: 0
                SM lid: 0
                Capability mask: 0x00010000
                Port GUID: 0x9af2b3fffed5c3c2
                Link layer: Ethernet

作業モードを切り替える

MST ソフトウェアをインストールする

`1`	`root@epyc:/home/knightli# systemctl start mst`

デバイス名を問い合わせる

MST デバイスの下には、返されたデバイス名が表示されます。 2 つのポートはデバイス名にも対応していることに注意してください。

root@epyc-7551p:/home/knightli# mst status
MST modules:
------------
    MST PCI module loaded
    MST PCI configuration module loaded

MST devices:
------------
/dev/mst/mt4103_pciconf0         - PCI configuration cycles access.
                                   domain:bus:dev.fn=0000:28:00.0 addr.reg=88 data.reg=92 cr_bar.gw_offset=-1
                                   Chip revision is: 00
/dev/mst/mt4103_pci_cr0          - PCI direct access.
                                   domain:bus:dev.fn=0000:28:00.0 bar=0xeb700000 size=0x100000
                                   Chip revision is: 00

作業モードを切り替える

mlxconfig -d /dev/mst/mt4103_pciconf0 set LINK_TYPE_P1=1

-d デバイス名
LINK_TYPE
LINK_TYPE_P1: ポート 1
LINK_TYPE_P2: ポート 2
1 : IB
2 : Ethernet
3 : VPI

root@epyc:/home/knightli# mlxconfig -d /dev/mst/mt4103_pciconf0 set LINK_TYPE_P1=1

Device #1:
----------

Device type:    ConnectX3Pro    
Device:         /dev/mst/mt4103_pciconf0

Configurations:                              Next Boot       New
         LINK_TYPE_P1                        IB(1)           IB(1)           

 Apply new Configuration? (y/n) [n] : y
Applying... Done!
-I- Please reboot machine to load new configurations.

root@epyc:/home/knightli# mlxconfig -d /dev/mst/mt4103_pciconf0 set LINK_TYPE_P2=1

Device #1:
----------

Device type:    ConnectX3Pro    
Device:         /dev/mst/mt4103_pciconf0

Configurations:                              Next Boot       New
         LINK_TYPE_P2                        IB(1)           IB(1)           

 Apply new Configuration? (y/n) [n] : y
Applying... Done!
-I- Please reboot machine to load new configurations.

ホストを再起動します

`1`	`root@epyc-7551p:/home/knightli# sudo reboot`

無料の Google 翻訳 Web サイト「translate.google.cn」を使用して Markdown ドキュメント全体を翻訳する方法 (V2 修正版)

Sun, 24 Apr 2022 00:00:00 +0000

最初のバージョンの問題

翻訳中に区切り文字が変更されました

一部の特定の言語では、翻訳中に区切り文字が変更されることが判明しました。
01231 など、さまざまな種類の区切り文字を試しました。翻訳すると、02231 になるなど、数字が変わります。規則性は見つかりませんでした。これは、翻訳可能な言語、さらには翻訳時間に関係します。絶対に変更されない区切り文字が見つかりません。
翻訳システムに何らかのバグがある可能性もあります。そこで区切り文字を取り除き、個別に翻訳する必要がある部分を複数行に分割して翻訳し、分割行数も同時に記録します。

新しいバージョンの翻訳プロセス

新訳は大きく次のような工程に分かれます。

翻訳する必要のない部分を事前に抽出する
個別に翻訳する項目を複数行に分割し、分割した行数を記録します。
マークされた文書を行ごとにセクションに分割し、最大長を超えないように一度にその一部のみを翻訳します。
翻訳中にネットワークエラーが発生した場合は、再試行してください
翻訳結果は行番号に基づいてコンテンツにマッピングされます。
翻訳プロセスにより、一部の書式が失われ、文書の書式が再設定されます。

コードの実装

import hashlib
import codecs
import datetime
import glob
import json
import os
import re
import ssl
import time
import traceback
import urllib.parse
import urllib.request
import execjs

from cgitb import text
from importlib.resources import contents
from sre_constants import RANGE
from typing import TYPE_CHECKING
from unittest.util import strclass
from xml.etree.ElementTree import C14NWriterTarget

ssl._create_default_https_context = ssl._create_unverified_context
class GoogleTrans(object):
    def __init__(self):
        self.url = 'https://translate.google.cn/translate_a/single'
        self.TKK = "434674.96463358"  # 随时都有可能需要更新的TKK值

        self.header = {
            "accept": "*/*",
            "accept-language": "zh-CN,zh;q=0.9",
            "cookie": "NID=188=M1p_rBfweeI_Z02d1MOSQ5abYsPfZogDrFjKwIUbmAr584bc9GBZkfDwKQ80cQCQC34zwD4ZYHFMUf4F59aDQLSc79_LcmsAihnW0Rsb1MjlzLNElWihv-8KByeDBblR2V1kjTSC8KnVMe32PNSJBQbvBKvgl4CTfzvaIEgkqss",
            "referer": "https://translate.google.cn/",
            "user-agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.142 Safari/537.36",
            "x-client-data": "CJK2yQEIpLbJAQjEtskBCKmdygEIqKPKAQi5pcoBCLGnygEI4qjKAQjxqcoBCJetygEIza3KAQ==",
        }

        self.data = {
            "client": "webapp",  # 基于网页访问服务器
            "sl": "zh-cn",  # 源语言,auto表示由谷歌自动识别
            "tl": "en",  # 翻译的目标语言
            "hl": "zh-cn",  # 界面语言选中文，毕竟URL都是cn后缀了，就不装美国人了
            # dt表示要求服务器返回的数据类型
            "dt": ["at", "bd", "ex", "ld", "md", "qca", "rw", "rm", "ss", "t"],
            "otf": "2",
            "ssel": "0",
            "tsel": "0",
            "kc": "1",
            "tk": "",  # 谷歌服务器会核对的token
            "q": ""  # 待翻译的字符串
        }

        with open('token.js', 'r', encoding='utf-8') as f:
            self.js_fun = execjs.compile(f.read())

        # 构建完对象以后要同步更新一下TKK值
        # self.update_TKK()

    def update_TKK(self):
        url = "https://translate.google.cn/"
        req = urllib.request.Request(url=url, headers=self.header)
        page_source = urllib.request.urlopen(req).read().decode("utf-8")
        self.TKK = re.findall(r"tkk:'([0-9]+\.[0-9]+)'", page_source)[0]

    def construct_url(self):
        base = self.url + '?'
        for key in self.data:
            if isinstance(self.data[key], list):
                base = base + "dt=" + "&dt=".join(self.data[key]) + "&"
            else:
                base = base + key + '=' + self.data[key] + '&'
        base = base[:-1]
        return base

    def query(self, q, lang_from='zh-cn', lang_to=''):
        self.data['q'] = urllib.parse.quote(q)
        self.data['tk'] = self.js_fun.call('wo', q, self.TKK)
        self.data['sl'] = lang_from
        self.data['tl'] = lang_to
        url = self.construct_url()
        req = urllib.request.Request(url=url, headers=self.header)
        res = urllib.request.urlopen(req).read().decode("utf-8")
        response = json.loads(res)
        originalLanguageCode = response[2]
        targetText = ""
        originalText = ""
        for ds in response[0]:
            if ds[0]:
                targetText = targetText + ds[0]
            if ds[1]:
                originalText = originalText + ds[1]

        # print("翻译前：{}，翻译前code：{}".format(originalText, originalLanguageCode))
        # print("翻译后：{}, 翻译后code：{}".format(targetText, lang_to))
        return originalText, originalLanguageCode, targetText, lang_to

    def translate(self, sourceTxt, srcLang, targetLang, retries=0):
        print('translate ... sourceTxt length=', len(sourceTxt))
        if retries > 1:
            return
        try:
            result = self.query(sourceTxt, srcLang, lang_to=targetLang)[2]
            if result is None:
                retries += 1
                print('retry ', retries)
                self.translate(sourceTxt, srcLang, targetLang, retries)
            else :
                return result
        except:
            retries += 1
            self.translate(sourceTxt, srcLang, targetLang, retries)

# 内容无需翻译
# 比如 #date: 2022-04-01
class MdTransItemReserve(object):
    def __init__(self, line):
        self.trans_buff = '  \n'
        self.value = line.strip()

    def get_trans_buff(self):
        return self.trans_buff
    
    def compose(self, translated_lines, start_pos):
        translated_lines[start_pos] = self.value + '\n'
        return translated_lines, 1

# 内容全部需翻译
# 比如MD中的正文文本块
class MdTransItemPlainText(object):
    def __init__(self, line):
        self.trans_buff = line.strip() + '\n'

    def get_trans_buff(self):
        return self.trans_buff

    def compose(self, translated_lines, start_pos):
        pass
    
# 内容为#key:value形式，value需要翻译
class MdTransItemKeyValue(object):
    def __init__(self, line):
        idx = line.index(':')
        lstr = line[0: idx + 1]
        rstr = line[idx + 1:].strip()
        self.trans_buff = rstr + '  \n'
        self.value = lstr.rstrip()

    def get_trans_buff(self):
        return self.trans_buff

    def compose(self, translated_lines, start_pos):
        translated_lines[start_pos] = self.value + ' ' + translated_lines[start_pos].rstrip().replace('"','').replace(':',' ') + '\n'

# 内容为### Title形式，Title需要翻译
class MdTransItemTitle(object):
    def __init__(self, line):
        idx = line.index(' ')
        lstr = line[0: idx + 1]
        rstr = line[idx + 1:]
        self.trans_buff = rstr.rstrip() + '  \n'
        self.value = lstr.rstrip() 

    def get_trans_buff(self):
        return self.trans_buff
    
    def compose(self, translated_lines, start_pos):
        translated_lines[start_pos] = self.value + ' ' + translated_lines[start_pos].rstrip() + '\n'

# 内容为![图片标题](01.jpg) 形式，图片标题需要翻译
class MdTransItemImg(object):
    def __init__(self, line):
        idx1 = line.index('[')
        idx2 = line.index(']')
        if idx1 == idx2 - 1:
            self.value = line[:-1]
            self.trans_buff = '  \n'
            self.type = 1
        else:
            lstr = line[0: idx1 + 1]
            mstr = line[idx1 + 1: idx2]
            rstr = line[idx2: -1]
            self.trans_buff = mstr + '  \n'
            self.value1 = lstr
            self.value2 = rstr
            self.type = 2

    def get_trans_buff(self):
        return self.trans_buff

    def compose(self, translated_lines, start_pos):
        if self.type == 1:
            translated_lines[start_pos] = self.value + '  \n'
        elif self.type == 2:
            translated_lines[start_pos] = self.value1 + translated_lines[start_pos].rstrip() + self.value2  + '  \n'
    
# 内容为#key:["values1","values2",..."valueN"]形式，value需要翻译
class MdTransItemKeyValueArray(object):
    def __init__(self, line):
        idx = line.index(':')
        lstr = line[0: idx + 1]
        self.value = lstr
        rstr = line[idx + 1:].strip()
        if rstr.startswith('['):
            self.trans_buff = ''
            items = rstr[2:-2].split('\",\"')
            for item in items:
                self.trans_buff = self.trans_buff + item + '  \n'
            self.item_cnt = len(items)
        else:
            print("Wrong format with MdTransItemKeyValueArray:", text)

    def get_trans_buff(self):
        return self.trans_buff

    def compose(self, translated_lines, start_pos):
        value_text = ''
        for idx in range(start_pos, start_pos + self.item_cnt) :
            value_text = value_text + '"' + translated_lines[idx].strip().replace('"','').rstrip('.').replace(':',' ') + '",'
        
        translated_lines[start_pos] = self.value + ' [' + value_text[:-1] + ']  \n'
        
        for idx in range(1, self.item_cnt) :
            del translated_lines[start_pos + 1]

class MdTranslater():
    langs = ['en', 'zh-tw', 'th', 'hi', 'ms', 'tl', 'id', 'vi']
        
    def check_missing(self, md_folder):
        for lang in self.langs:
            dest_filename = md_folder + '/index.' + lang + '.md'
            if not os.path.exists(dest_filename):
                print('lack ', dest_filename)

    def replace_useless_char(self, tstr):
        return tstr

    def translate_md(self, src_lines, src_lang, dest_lang):
        is_front_matter = False
        md_trans_items = []
        for i in range(len(src_lines)):
            line = src_lines[i]
            if line.strip() == '---':
                is_front_matter = not is_front_matter
                md_trans_items.append(MdTransItemReserve(line))
                continue

            if is_front_matter:
                if line.startswith(('title:', 'slug:', 'description:')):
                    md_trans_items.append(MdTransItemKeyValue(line))
                elif line.startswith('date:'):
                    md_trans_items.append(MdTransItemReserve(line))
                elif line.startswith(('tags:', 'categories:', 'keywords:')):
                    md_trans_items.append(MdTransItemKeyValueArray(line))
                else:
                    md_trans_items.append(MdTransItemPlainText(line))
            else:
                if len(line.strip()) == 0:  # 空行
                    md_trans_items.append(MdTransItemPlainText(line))
                elif re.match('\!\[.*\]\(.*\)', line) is not None:  # 图片
                    md_trans_items.append(MdTransItemImg(line))
                elif line.strip().startswith('#'):  # 标题
                    md_trans_items.append(MdTransItemTitle(line))
                else:  # 普通文字
                    md_trans_items.append(MdTransItemPlainText(line))

        #待翻译md文本
        src_md_text = 'BEGIN  \n' ##在首尾都要加入特定行，否则翻译后会首尾的空行去掉，造成翻译前后对应不上
        for mdTransItem in md_trans_items:
            src_md_text = src_md_text + mdTransItem.get_trans_buff()
        src_md_text = src_md_text + 'END  \n' ##在首尾都要加入特定行，否则翻译后会首尾的空行去掉，造成翻译前后对应不上
        
        #分割文本，每次翻译，发送大小不大于2000
        part_src_md_text = ""
        dest_md_text = ""
        src_lines = src_md_text.splitlines()
        # print('src_lines:', len(src_lines))
        # print('src_lines:', src_lines)
        for line in src_lines:
            part_src_md_text = part_src_md_text + line + "\n"
            if len(part_src_md_text) > 500:  #不同语言这个值不同
                dest_md_text = dest_md_text + GoogleTrans().translate(part_src_md_text, src_lang, dest_lang) + "\n"
                part_src_md_text = ""
        if len(part_src_md_text) > 0:
            dest_md_text = dest_md_text + GoogleTrans().translate(part_src_md_text, src_lang, dest_lang) + "\n"

        translated_lines = dest_md_text.splitlines()
        start_pos = 1  #从第一行开始对应，首行为添加的无意义
        for mdTransItem in md_trans_items:
            # print(mdTransItem)
            mdTransItem.compose(translated_lines, start_pos)
            start_pos = start_pos + 1
            
        final_md_text = ''
        for dline in translated_lines[1 : -1]:
            final_md_text = final_md_text + dline.rstrip() + '  \n' 

        return final_md_text
    
    def translate_md_folder(self, src_lang, dest_lang, md_folder):
        dest_filename = md_folder + '/index.' + dest_lang + '.md'
        if os.path.exists(dest_filename):
            print('already translated ', dest_filename, ' skip.')
            return

        src_filename = md_folder + '/index.' + src_lang + '.md'
        if not os.path.exists(src_filename):
            print('src file ', src_filename, ' not exist! skip.')
            return

        #black list
        if (md_folder.endswith('000019') and dest_lang == 'my') or \
            (md_folder.endswith('000019') and dest_lang == 'hmn') :
            print(dest_filename, 'in black list, skip!')
            return

        print('translate file ', src_filename, ' to ', dest_filename)
        src_lines = ''
        with open(src_filename, encoding='utf-8') as src_filename_data:
            src_lines = src_filename_data.readlines()
            
        final_md_text = self.translate_md(src_lines, src_lang, dest_lang)
        # print('final_md_text',final_md_text)
        with open(dest_filename, 'w', encoding='utf-8') as outfile:
            outfile.write(final_md_text)

    def translate_md_folder_with_retries(self, src_lang, dest_lang, md_folder, retries=0):
        # print('translate md with retries=',  retries)
        if retries > 20:
            return
        try:
            return self.translate_md_folder(src_lang, dest_lang, md_folder)
        except Exception as e: 
            print(e)
            time.sleep(3)
            retries += 1
            self.translate_md_folder_with_retries(src_lang, dest_lang, md_folder, retries)


    def translate_all_md_folder(self, md_folder):
        print('translate_all_md_folder:', md_folder)
        files = [f for f in glob.glob(md_folder + "/**/index.zh-cn.md", recursive=True)]
        for f in files:
            d = os.path.dirname(f)
            for lang in self.langs:
                self.translate_md_folder_with_retries('zh-cn', lang, d)

    def cleanup(self, md_folder):
        print('cleanup:', md_folder)
        files = [f for f in glob.glob(md_folder + "/**/index.zh-cn.md", recursive=True)]
        for f in files:
            d = os.path.dirname(f)
            for lang in self.langs:
                dest_filename = d + '/index.' + lang + '.md'
                if os.path.exists(dest_filename):
                    print('remove ', dest_filename)
                    # os.remove(dest_filename)

参考資料

Google 翻訳では部分的に https://github.com/VictorZhang2014/free-google-translate を参照しています

無料の Google 翻訳 Web サイト、translate.google.cn を使用して Markdown ドキュメント全体を翻訳する方法

Thu, 21 Apr 2022 00:00:00 +0000

本方法已更新, 最新版请点击这里

Google 翻訳を直接使用する際の問題

一度に翻訳できる Web サイトの長さには制限があります。長い MD 文書はセクションに分けて複数回翻訳する必要があります。
Webサイトを翻訳する際には、前付のキーワードも一緒に翻訳されるため、翻訳後に前付部分を再構成する必要があります。翻訳言語が認識されないと、再編成がさらに面倒になります。
MarkDown キーワードにも上記と同様の問題が発生します。さらに、一部の言語 (ベトナム語やその他のあまり使用されていない言語など) では、MarkDown キーワードが翻訳中に翻訳結果に影響を与えることが判明しています。これは不完全な翻訳プログラムが原因である可能性があります。

翻訳プロセス

翻訳は大きく次のような工程に分かれます。

翻訳の必要のない部分を事前に抽出し、原文にマークを付けておきます。
マークされた文書を行ごとにセクションに分割し、最大長を超えないように一度にその一部のみを翻訳します。
翻訳中にネットワークエラーが発生した場合は、再試行してください
翻訳結果の元の未翻訳部分を置き換えます。
翻訳プロセスにより、一部の書式が失われ、文書の書式が再設定されます。

コードの実装

import codecs
import datetime
import glob
import json
import os
import random
import re
import ssl
import time
import urllib.parse
import urllib.request
from cgitb import text
from datetime import datetime
from importlib.resources import contents
from sre_constants import RANGE
from typing import TYPE_CHECKING
from unittest.util import strclass
from xml.etree.ElementTree import C14NWriterTarget

import execjs

ssl._create_default_https_context = ssl._create_unverified_context

class GoogleTrans(object):
    def __init__(self):
        self.url = 'https://translate.google.cn/translate_a/single'
        self.TKK = "434674.96463358"  # 随时都有可能需要更新的TKK值

        self.header = {
            "accept": "*/*",
            "accept-language": "zh-CN,zh;q=0.9",
            "cookie": "NID=188=M1p_rBfweeI_Z02d1MOSQ5abYsPfZogDrFjKwIUbmAr584bc9GBZkfDwKQ80cQCQC34zwD4ZYHFMUf4F59aDQLSc79_LcmsAihnW0Rsb1MjlzLNElWihv-8KByeDBblR2V1kjTSC8KnVMe32PNSJBQbvBKvgl4CTfzvaIEgkqss",
            "referer": "https://translate.google.cn/",
            "user-agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.142 Safari/537.36",
            "x-client-data": "CJK2yQEIpLbJAQjEtskBCKmdygEIqKPKAQi5pcoBCLGnygEI4qjKAQjxqcoBCJetygEIza3KAQ==",
        }

        self.data = {
            "client": "webapp",  # 基于网页访问服务器
            "sl": "zh-cn",  # 源语言,auto表示由谷歌自动识别
            "tl": "en",  # 翻译的目标语言
            "hl": "zh-cn",  # 界面语言选中文，毕竟URL都是cn后缀了，就不装美国人了
            # dt表示要求服务器返回的数据类型
            "dt": ["at", "bd", "ex", "ld", "md", "qca", "rw", "rm", "ss", "t"],
            "otf": "2",
            "ssel": "0",
            "tsel": "0",
            "kc": "1",
            "tk": "",  # 谷歌服务器会核对的token
            "q": ""  # 待翻译的字符串
        }

        with open('token.js', 'r', encoding='utf-8') as f:
            self.js_fun = execjs.compile(f.read())

        # 构建完对象以后要同步更新一下TKK值
        # self.update_TKK()

    def update_TKK(self):
        url = "https://translate.google.cn/"
        req = urllib.request.Request(url=url, headers=self.header)
        page_source = urllib.request.urlopen(req).read().decode("utf-8")
        self.TKK = re.findall(r"tkk:'([0-9]+\.[0-9]+)'", page_source)[0]

    def construct_url(self):
        base = self.url + '?'
        for key in self.data:
            if isinstance(self.data[key], list):
                base = base + "dt=" + "&dt=".join(self.data[key]) + "&"
            else:
                base = base + key + '=' + self.data[key] + '&'
        base = base[:-1]
        return base

    def query(self, q, lang_from='zh-cn', lang_to=''):
        self.data['q'] = urllib.parse.quote(q)
        self.data['tk'] = self.js_fun.call('wo', q, self.TKK)
        self.data['sl'] = lang_from
        self.data['tl'] = lang_to
        url = self.construct_url()
        # print(url)
        req = urllib.request.Request(url=url, headers=self.header)
        res = urllib.request.urlopen(req).read().decode("utf-8")
        # print("res======", res)
        response = json.loads(res)

        # print(response)
        originalLanguageCode = response[2]

        targetText = ""
        originalText = ""
        for ds in response[0]:
            # print("-----------------")
            # print(ds[0])
            # print("-----------------")
            # print(ds[1])
            # print("-----------------")
            if ds[0]:
                targetText = targetText + ds[0]
            if ds[1]:
                originalText = originalText + ds[1]

        print("翻译前：{}，翻译前code：{}".format(originalText, originalLanguageCode))
        print("翻译后：{}, 翻译后code：{}".format(targetText, lang_to))

        return originalText, originalLanguageCode, targetText, lang_to

    def translate(self, sourceTxt, srcLang, targetLang, retries=0):
        print('translate retries=',  retries)
        if retries > 20:
            return
        try:
            result = self.query(sourceTxt, srcLang, lang_to=targetLang)[2]
            print(result)
            if result is None:
                retries += 1
                self.translate(sourceTxt, srcLang, targetLang, retries)
            else:
                return result
        except:
            retries += 1
            self.translate(sourceTxt, srcLang, targetLang, retries)


class MdTransItem(object):
    def __init__(self, i):
        self.delimiter = '_{:05d}_'.format(i)

# 内容无需翻译
# 比如 #date: 2022-04-01
class MdTransItemReserve(MdTransItem):
    def __init__(self, text, i):
        MdTransItem.__init__(self, i)
        self.trans_buff = self.delimiter + '\n'
        self.value = text

    def get_trans_buff(self):
        return self.trans_buff

    def compose(self, translated_md_text):
        return translated_md_text.replace(self.trans_buff, self.value)

# 内容全部需翻译
# 比如MD中的正文文本块
class MdTransItemPlainText(MdTransItem):
    def __init__(self, text, i):
        MdTransItem.__init__(self, i)
        self.trans_buff = text

    def get_trans_buff(self):
        return self.trans_buff

    def compose(self, translated_md_text):
        return translated_md_text

# 内容为#key:value形式，value需要翻译
# 比如 #title: 这是文章标题
class MdTransItemKeyValue(MdTransItem):
    def __init__(self, text, i):
        MdTransItem.__init__(self, i)
        # print(text)
        idx = text.index(':')
        # print(idx)
        lstr = text[0: idx + 1]
        rstr = text[idx + 1:].strip()
        # print(rstr)
        self.trans_buff = self.delimiter + ' \n' + \
            rstr + '  \n' + self.delimiter + ' \n'
        self.value = lstr.rstrip()

    def get_trans_buff(self):
        return self.trans_buff

    def compose(self, translated_md_text):
        # return translated_md_text.replace(self.delimiter, self.value)
        print('self.delimiter:', self.delimiter)
        print(translated_md_text)
        result_md_text = ''
        dlen = len(self.delimiter)
        idx1 = translated_md_text.index(self.delimiter)
        idx2 = translated_md_text.index(self.delimiter, idx1 + 1)

        lstr = translated_md_text[0: idx1]
        mstr = translated_md_text[idx1 + dlen + 1: idx2]
        rstr = translated_md_text[idx2 + dlen + 1:]
        rstr = rstr.lstrip()

        result_md_text = lstr + self.value + ' ' + mstr.strip() + '\n' + rstr
        return result_md_text

# 内容为### Title形式，Title需要翻译
# 比如 ### MD标题
class MdTransItemTitle(MdTransItem):
    def __init__(self, text, i):
        MdTransItem.__init__(self, i)
        idx = text.index(' ')
        lstr = text[0: idx + 1]
        rstr = text[idx + 1:]
        # print(rstr)
        self.trans_buff = self.delimiter + ' \n' + \
            rstr + '  \n' + self.delimiter + ' \n'
        self.value = lstr.rstrip()

    def get_trans_buff(self):
        return self.trans_buff

    def compose(self, translated_md_text):
        # return translated_md_text.replace(self.delimiter, self.value)
        print('self.delimiter:', self.delimiter)
        print(translated_md_text)
        result_md_text = ''
        dlen = len(self.delimiter)
        idx1 = translated_md_text.index(self.delimiter)
        idx2 = translated_md_text.index(self.delimiter, idx1 + 1)

        lstr = translated_md_text[0: idx1]
        mstr = translated_md_text[idx1 + dlen + 1: idx2]
        rstr = translated_md_text[idx2 + dlen + 1:]
        rstr = rstr.lstrip()

        result_md_text = lstr + self.value + ' ' + mstr.strip() + '\n' + rstr
        return result_md_text


# 内容为![图片标题](01.jpg) 形式，图片标题需要翻译
# 比如 ![图片名称](01.jpg)
class MdTransItemImg(MdTransItem):
    def __init__(self, text, i):
        MdTransItem.__init__(self, i)
        idx1 = text.index('[')
        idx2 = text.index(']')
        if idx1 == idx2 - 1:
            self.value = text[:-1]
            self.trans_buff = self.delimiter + '\n'
            self.type = 1
        else:
            lstr = text[0: idx1 + 1]
            mstr = text[idx1 + 1: idx2]
            rstr = text[idx2: -1]
            self.trans_buff = self.delimiter + '_B ' + mstr + ' ' + self.delimiter + '_E\n'
            self.value1 = lstr
            self.value2 = rstr
            self.type = 2

    def get_trans_buff(self):
        return self.trans_buff

    def compose(self, translated_md_text):
        if self.type == 1:
            translated_md_text = translated_md_text.replace(
                self.delimiter, self.value)
        elif self.type == 2:
            translated_md_text = translated_md_text.replace(
                self.delimiter + '_B', self.value1)
            translated_md_text = translated_md_text.replace(
                self.delimiter + '_E', self.value2)
        return translated_md_text

# 内容为#key:["values1","values2",..."valueN"]形式，value需要翻译
# 比如 keywords: ["关键词1","关键词2","关键词3"]
class MdTransItemKeyValueArray(MdTransItem):
    def __init__(self, text, i):
        MdTransItem.__init__(self, i)
        idx = text.index(':')
        # print(idx)
        lstr = text[0: idx + 1]
        self.value = lstr
        rstr = text[idx + 1:].strip()
        # print(rstr)
        # 列表内容
        if rstr.startswith('['):
            self.trans_buff = ''
            self.trans_buff = self.trans_buff + self.delimiter + '  \n'

            # print('strat with [')
            trans_str = ''
            items = rstr[2:-2].split('\",\"')
            for item in items:
                self.trans_buff = self.trans_buff + item + '\n'

            self.trans_buff = self.trans_buff + self.delimiter + '  \n'

        else:
            print("Wrong format with MdTransItemKeyValueArray:", text)

    def get_trans_buff(self):
        return self.trans_buff

    def compose(self, translated_md_text):
        print('self.delimiter:', self.delimiter)
        print(translated_md_text)
        result_md_text = ''
        dlen = len(self.delimiter)
        idx1 = translated_md_text.index(self.delimiter)
        idx2 = translated_md_text.index(self.delimiter, idx1 + 1)

        lstr = translated_md_text[0: idx1]
        mstr = translated_md_text[idx1 + dlen + 1: idx2]
        rstr = translated_md_text[idx2 + dlen + 1:]
        rstr = rstr.lstrip()

        result_md_text = lstr

        result_md_text = result_md_text + self.value + ' ['
        mstr_array = mstr.strip().split('\n')
        for m in mstr_array:
            if m.endswith('.'):
                m = m[0:-1]
            result_md_text = result_md_text + '"' + m + '",'

        if result_md_text.endswith(','):
            result_md_text = result_md_text[0: len(result_md_text) - 1]

        result_md_text = result_md_text + ']\n'
        result_md_text = result_md_text + rstr
        return result_md_text

class MdTranslater(object):
    langs = ['en', 'zh-tw', 'th', 'hi', 'ms', 'tl', 'id', 'vi']

    def cleanup(self, md_folder):
        for lang in self.langs:
            dest_filename = md_folder + '/index.' + lang + '.md'
            if os.path.exists(dest_filename):
                print('remove ', dest_filename)
                os.remove(dest_filename)

    def check_missing(self, md_folder):
        for lang in self.langs:
            dest_filename = md_folder + '/index.' + lang + '.md'
            if not os.path.exists(dest_filename):
                print('lack ', dest_filename)

    def replace_useless_char(self, tstr):
        return tstr

    def translate_md(self, src_lang, dest_lang, md_file):
        dest_filename = md_file.replace(src_lang, dest_lang)
        if os.path.exists(dest_filename):
            print('already translated ', dest_filename, ' skip.')
            return

        src_filename = md_file
        if not os.path.exists(src_filename):
            print('src file ', src_filename, ' not exist! skip.')
            return

        src_md_lines = ''
        with open(src_filename, encoding='utf-8') as src_filename_data:
            src_md_lines = src_filename_data.readlines()

        print('translate ', dest_filename, ' ...')
        is_front_matter = False
        md_trans_items = []
        for i in range(len(src_md_lines)):
            line = src_md_lines[i]
            line = self.replace_useless_char(line)
            if line.strip() == '---':
                is_front_matter = not is_front_matter
                md_trans_items.append(MdTransItemReserve(line, i))
                continue

            if is_front_matter:
                if line.startswith(('title:', 'slug:', 'description:')):
                    md_trans_items.append(MdTransItemKeyValue(line, i))
                elif line.startswith('date:'):
                    md_trans_items.append(MdTransItemReserve(line, i))
                elif line.startswith(('tags:', 'categories:', 'keywords:')):
                    md_trans_items.append(MdTransItemKeyValueArray(line, i))
                else:
                    md_trans_items.append(MdTransItemPlainText(line, i))
            else:
                if len(line.strip()) == 0:  # 空行
                    md_trans_items.append(MdTransItemPlainText(line, i))
                elif re.match('\!\[.*\]\(.*\)', line) is not None:  # 图片
                    md_trans_items.append(MdTransItemImg(line, i))
                elif line.strip().startswith('#'):  # 标题
                    md_trans_items.append(MdTransItemTitle(line, i))
                else:  # 普通文字
                    md_trans_items.append(MdTransItemPlainText(line, i))

        # 待翻译md文本
        src_md_text = ''
        for mdTransItem in md_trans_items:
            src_md_text = src_md_text + mdTransItem.get_trans_buff()

        # 分割文本，每次翻译，发送大小不大于1000
        part_src_md_text = ""
        dest_md_text = ""
        for line in src_md_text.splitlines():
            part_src_md_text = part_src_md_text + line + "\n"
            if len(part_src_md_text) > 1000:
                dest_md_text = dest_md_text + GoogleTrans().translate(part_src_md_text,
                                                                      src_lang, dest_lang) + "\n"
                part_src_md_text = ""
        if len(part_src_md_text) > 0:
            dest_md_text = dest_md_text + GoogleTrans().translate(part_src_md_text,
                                                                  src_lang, dest_lang) + "\n"

        for mdTransItem in md_trans_items:
            print(mdTransItem)
            dest_md_text = mdTransItem.compose(dest_md_text)

        final_md_text = ''
        for dline in dest_md_text.splitlines():
            final_md_text = final_md_text + dline + '  \n'

        with open(dest_filename, 'w', encoding='utf-8') as outfile:
            outfile.write(final_md_text)

    def translate_md_with_retries(self, src_lang, dest_lang, md_folder, retries=0):
        print('translate md with retries=',  retries)
        if retries > 20:
            return
        try:
            time.sleep(1)
            return self.translate_md(src_lang, dest_lang, md_folder)
        except:
            time.sleep(5)
            retries += 1
            self.translate_md_with_retries(
                src_lang, dest_lang, md_folder, retries)

    def translate_all_md(self, md_folder):
        print('translate_all_md:', md_folder)
        files = [f for f in glob.glob(
            md_folder + "/**/*.zh-cn.md", recursive=True)]
        for f in files:
            for lang in self.langs:
                self.translate_md_with_retries('zh-cn', lang, f)

参考資料

Google 翻訳では部分的に https://github.com/VictorZhang2014/free-google-translate を参照しています

openwrt と Wireguard を使用して、インターネット経由で 2 つのリモートネットワークセグメントを接続します

Thu, 14 Apr 2022 00:00:00 +0000

目的

異なる場所に 2 つの LAN があり、どちらもインターネットにアクセスできますが、相互には接続されていません。 2 つの LAN をインターネット経由で接続し、2 つの LAN 内のホストが 1 つの LAN と同じように相互にサービスにアクセスできるようにしたいと考えています。ただし、インターネットトラフィックは同じままで変化しません。

ネットワーク要件

少なくとも一方の端には外部 IP アドレスがあります (固定 IP である必要はありません)。
両方の LAN に openwrt システムがあり、Wireguard がインストールされています。 (Wireguard をインストールできる他のシステムも許容されますが、Openwrt は比較的安価です)

インストールと構成

秘密鍵と公開鍵を生成する

各インターフェースには秘密鍵と公開鍵が必要です。生成してペアリングする必要があるインターフェイスがいくつかあります。ここでは、2 つのインターフェイスで使用するために 2 つのペアを生成する必要があります。

1
2

wg genkey | tee privatekey1 | wg pubkey > publickey1
wg genkey | tee privatekey2 | wg pubkey > publickey2

openwrtインターフェース設定

ノード1の構成

ノード2の構成

動的IPのみの場合のスクリプト

動的 IP が 1 つしかない場合、番号をリダイヤルして IP が変わると、接続が切断されます。

パブリックネットワークの IP エンドは切断を検出する必要がありません。
次に、dnsmasq を再起動します (/etc/init.d/dnsmasq restart)。再起動後にのみ、新しい動的 IP を更新できます (動的ドメイン名をアクティブに更新するには、パブリック IP エンドが必要です)。
パブリック IP エンドがアクティブに接続を再確立することはありません

完全なスクリプトは次のとおりで、crontab に追加する必要があります。

#!/bin/sh
DATE=$(date +%Y-%m-%d" "%H:%M:%S)
CHECKHOSTNAME="192.168.8.1"
VPNINTERFACE="WG0"

ping -c3 $CHECKHOSTNAME

if [ $? -eq 0 ]; then
    echo "ok"
    logger $(echo "${DATE} - $0: OK - $VPNINTERFACE UP AND RUNNING")

else
    echo "RESTART $VPNINTERFACE Interface"
    logger $(echo "${DATE} - $0: NO VPN CONNECTION RESTART $VPNINTERFACE INTERFACE...")
    /etc/init.d/dnsmasq restart
    ifdown $VPNINTERFACE
    ifup $VPNINTERFACE
fi

CHECKHOSTNAME は、ノードを接続するルーターのアドレスです。

静的ルートを構成する

Ubuntu および Nginx に GoAccess をインストールして Web サイトのステータスをリアルタイムで監視する方法

Thu, 14 Apr 2022 00:00:00 +0000

インストール後の様子

インストールGoAccess

システムに付属のものを使用してください。バージョンが古い場合があります。

`1`	`apt-get install goaccess`

deb.goaccess.io 公式最新安定版を使用してください

$ wget -O - https://deb.goaccess.io/gnugpg.key | gpg --dearmor | sudo tee /usr/share/keyrings/goaccess.gpg >/dev/null
$ echo "deb [signed-by=/usr/share/keyrings/goaccess.gpg] https://deb.goaccess.io/ $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/goaccess.list
$ sudo apt-get update
$ sudo apt-get install goaccess

update.sh ファイルを作成する

`1`	`goaccess /var/log/nginx/www.knightli.com.access.log -o /www/www.knightli.com/r.html --log-format=COMBINED`

/var/log/nginx/www.knightli.com.access.log は、http サーバーのアクセスログファイルのディレクトリです。
/www/www.knightli.com/r.html は、http サーバーの静的 Web ページのルートディレクトリとファイル名です。

crontabに追加し、アクセスログに従って1分ごとに生成する

crontab -e

# m h  dom mon dow   command
* * * * * ~/update.sh

ファイルにアクセスする

ブラウザ経由でhttp://www.knightli.com/r.htmlにアクセス

Synology に screen をインストールする方法

Mon, 11 Apr 2022 00:00:00 +0000

ipkg経由でインストールする

必要書類

screen_4.0.3-2_i686.ipk
http://ipkg.nslu2-linux.org/feeds/optware/syno-i686/cross/unstable/screen_4.0.3-2_i686.ipk

termcap_1.3.1-2_i686.ipk
http://ipkg.nslu2-linux.org/feeds/optware/syno-i686/cross/unstable/termcap_1.3.1-2_i686.ipk

インストールコマンド

root@DiskStation:~# wget http://ipkg.nslu2-linux.org/feeds/optware/syno-i686/cross/unstable/screen_4.0.3-2_i686.ipk
root@DiskStation:~# wget http://ipkg.nslu2-linux.org/feeds/optware/syno-i686/cross/unstable/termcap_1.3.1-2_i686.ipk

root@DiskStation:~# ipkg install termcap_1.3.1-2_i686.ipk 
Installing termcap (1.3.1-2) to root...
Configuring termcap
Successfully terminated.
root@DiskStation:~# ipkg install screen_4.0.3-2_i686.ipk 
Installing screen (4.0.3-2) to root...
Configuring screen
Successfully terminated.

Google 翻訳パラメータの具体的な意味

Sun, 03 Apr 2022 00:00:00 +0000

住所： https://translate.google.cn/translate_a/single

パラメータの意味:

client - 客户端类型 webapp(基于网页访问服务器)
sl     - 翻译源语言代码 (auto 表示自动识别)
tl     - 翻译目标语言
hl     - 界面语言
q      - 要翻译的文本
otf    - "2" 未知
ssel   - "0" 未知
tsel   - "0" 未知
kc     - "1" 未知
tk     - 谷歌服务器会核对的token
ie     - input encoding (a guess)
oe     - output encoding (a guess)

dt - 翻译需要包含的属性，具体内容如下
    t - translation of source text
    at - alternate translations
    rm - transcription / transliteration of source and translated texts
    bd - dictionary, in case source text is one word (you get translations with articles, reverse translations, etc.)
    md - definitions of source text, if it's one word
    ss - synonyms of source text, if it's one word
    ex - examples
    rw - See also list.
    dj - Json response with names. (dj=1)

参照コード:
https://github.com/VictorZhang2014/free-google-translate
https://stackoverflow.com/questions/26714426/what-is-the-meaning-of-google-translate-query-params/29537590#29537590

Hugo パーマリンク設定と中国語 URL、スラッグ、SEO の最適化

Sun, 03 Apr 2022 00:00:00 +0000

中国語の URL が SEO に与える影響

現地言語を URL (Uniform Resource Locators) として使用することに関して、John Mueller (Google ウェブマスタートレンドアナリスト) はかつてこの問題に関するビデオを公開しました。

したがって、URL に中国語を使用できますが、中国語の URL は UTF-8 で翻訳されますが、翻訳後の URL 構造は非常に長くて見苦しくなります。例: 中国語の「これは例 1」は、トランスコード後は「%E8%BF%99%E6%98%AF%E4%B8%80%E4%B8%AA%E4%BE%8B%E5%AD%901」になります。

中国語のタイトルを URL として使用する

現在、この方法を使用する人が多くなっていますが、この方法には次のような欠点があります。

タイトルに特殊文字が含まれている場合、Hugo はエラーを報告します。特殊文字を含むファイルを作成できない (「.」文字を含むタイトルなど、Windows 環境でよくある)
タイトルが長すぎる場合、hugo はエラーを報告します。生成されたディレクトリが長さ制限を超えています
検索エンジンが長い中国語のタイトルを解析するとき、意味のない中国語の文字 (「和」、「的」などの漢字、および一部の句読点) が除外されます。したがって、タイトルを URL として使用するのは適切ではありません。

Hugoのパーマリンク設定

config.yamlで設定します

1
2

permalinks:
post: /:year/:month/:day/:slug/

パーマリンクで年、月、日を設定し、スラッグを使用して URL を指定できます。

フロントマターにスラッグを設定する

スラッグを設定すると、Hugo は通常、仕様への準拠をさらに高めるためにスラッグをさらに最適化します。

すべての文字を小文字に変換し、
すべてのスペースを置き換えるには - を使用します
すべての特殊文字を削除します

スラグ最適化の原則

Slug は URL の重要な部分を占めており、これを最適化する必要があります。最適化の原則は次のとおりです。

「和」、「的」などの意味のない漢字や句読点の使用は避けてください。
for、and、if、or などのストップワードの使用は避けてください (検索エンジンによってフィルタリングされます)。
最終 URL はできるだけ短く、スラッグの長さは 3 ～ 5 ワード以内に保つようにしてください。
スラッグにコンテンツのキーワードを含めて、適切なキーワードを選択します

スラグ最適化の利点

検索エンジン結果ページ (SERP) でのランキングを向上させる
ユーザーがページのコンテンツを簡単に予測できるようにします。
観客にとってはより魅力的に映るでしょう。
簡潔な URL によりコンテンツ情報が伝わりやすくなり、SEO にも役立ちます。

検索エンジンは、短くてキーワードが豊富なスラッグを好みます。

検索エンジンは、「for」、「and」、「if」、「or」などの特定の単語を検索結果から除外します。それらはストップワードと呼ばれます。検索エンジンは検索結果を探すときにそれらを重要とはみなさないため、貴重なリソースを消費する URL にそれらを含めても意味がありません。

この記事のスラッグ設定:

`1`	`slug: Hugo permalinks 中文URL slug SEO优化`

美しいスープとPythonを使用してキーワード、HTMLメタ属性の説明を取得します

Sun, 03 Apr 2022 00:00:00 +0000

間違ったアプローチ

私は最初に次の方法を使用しましたが、常に失敗しました。

1
2

title = soup.find("meta", name="description")
title = soup.find("meta", name="keywords")

正しい方法

美しいスープでは、メタタグを取得するために name=<…> の代わりに property=<…> を使用する必要があります。必要なものを取得するための最終コードは次のとおりです。

#获取description
md_desc = soup.find('head').find('meta', attrs={'name': 'description'})['content']

#获取keywords
md_keywords = soup.find('head').find('meta', attrs={'name': 'keywords'})['content']

別の方法

2 つの検索メソッドを通じて

1
2
3

meta = soup.findall("meta")
title = meta.find(name="description")
image = meta.find(name="keywords")

apt を使用して Erlang を Ubuntu 20.04 にインストールする

Tue, 29 Mar 2022 00:00:00 +0000

Erlang GPG キーをインポートする

1
2
3

sudo apt update
sudo apt install software-properties-common apt-transport-https
wget -O- https://packages.erlang-solutions.com/ubuntu/erlang_solutions.asc | sudo apt-key add -

Erlang リポジトリを Ubuntu 20.04 apt ソースリストに追加する

`1`	`echo "deb https://packages.erlang-solutions.com/ubuntu focal contrib" \| sudo tee /etc/apt/sources.list.d/erlang.list`

apt を使用して Erlang をインストールする

1
2

sudo apt update
sudo apt install erlang

診る

knightli@epyc:~$ erl
Erlang/OTP 24 [erts-12.2.1] [source] [64-bit] [smp:64:64] [ds:64:64:10] [async-threads:1] [jit]

Eshell V12.2.1  (abort with ^G)
1> 
User switch command
 --> q

hello.erl テストファイルを編集する

% This is a test Hello World Erlang Code
-module(hello).
-import(io,[fwrite/1]).
-export([helloworld/0]).

helloworld() ->
   fwrite("Hello, Erlang World!\n").

コンパイルして実行する

knightli@epyc:~$ erl
Erlang/OTP 24 [erts-12.2.1] [source] [64-bit] [smp:64:64] [ds:64:64:10] [async-threads:1] [jit]

Eshell V12.2.1  (abort with ^G)
1> c(hello).
{ok,hello}
2> hello:helloworld().
Hello, Erlang World!
ok
3>  
User switch command
 --> q

Ubuntu 20.04 での HP 544+FLR-QSFP ネットワークカード構成 (RDMA) NVMe over Fabric の使用

Tue, 29 Mar 2022 00:00:00 +0000

ハードウェア

HP 544+FLR-QSFP 40 Gb/s 2-Port(s) Ethernet Adapter Card 544+FLR-QSFP 764285-B21

番号対応表

编号	产品	OEM
879482-B21	HPE InfiniBand FDR/Ethernet 40Gb/50Gb 2-port 547FLR-QSFP adapter	Mellanox ConnectX-5 technology
764284-B21	HPE InfiniBand FDR/Ethernet 10Gb/40Gb 2-port 544+QSFP adapter	Mellanox ConnectX-3 Pro technology
764285-B21	HPE InfiniBand FDR/Ethernet 10Gb/40Gb 2-port 544+FLR-QSFP adapter	Mellanox ConnectX-3 Pro technology
764737-001	InfiniBand FDR/Ethernet 10Gb/40Gb 2-port 544+FLR-QSFP (FlexibleLOM) adapter - InfiniBand bandwidth up to 56 Gb/s Fourteen Data Rate (FDR), Ethernet bandwidth up to 40 Gb/s, PCIe 3.0	Mellanox ConnectX-3 Pro technology
764286-B21	HP InfiniBand QDR/Ethernet 10Gb 2-port 544+FLR-QSFP Adapter	Mellanox ConnectX-3 Pro technology

ソフトウェア

MLNX_OFED_LINUX-4.9-4.1.7.0-ubuntu20.04-x86_64.tgz
https://network.nvidia.com/products/infiniband-drivers/linux/mlnx_ofed/

インストール構成

ドライバーをコンパイルしてインストールする

ストレージ側と接続側の両方にインストールする必要があることに注意してください。

tar -zvxf MLNX_OFED_LINUX-4.9-4.1.7.0-ubuntu20.04-x86_64.tgz
cd MLNX_OFED_LINUX-4.9-4.1.7.0-ubuntu20.04-x86_64/
sudo ./mlnxofedinstall --with-nvmf 
sudo update-initramfs -u
sudo apt install nvme-cli
reboot

IPアドレスを設定する

ストレージ側と接続側の両方を構成する必要があることに注意してください。実際のデータは IP 経由ではなく、IB ネットワークと RDMA 経由で送信されます。

ネットワークポートを見つける

knightli@epyc:~$ sudo lshw -c network
  *-network:0               
       description: Ethernet interface
       product: I350 Gigabit Network Connection
       vendor: Intel Corporation
       physical id: 0
       bus info: pci@0000:01:00.0
       logical name: eno1
       version: 01
       serial: ac:1f:6b:e7:e7:b4
       capacity: 1Gbit/s
       width: 32 bits
       clock: 33MHz
       capabilities: pm msi msix pciexpress bus_master cap_list ethernet physical tp 10bt 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation
       configuration: autonegotiation=on broadcast=yes driver=igb driverversion=5.6.0-k firmware=1.69, 0x80000df4 latency=0 link=no multicast=yes port=twisted pair
       resources: irq:84 memory:eff20000-eff3ffff ioport:1020(size=32) memory:eff44000-eff47fff memory:1c904000000-1c90401ffff memory:1c904020000-1c90403ffff
  *-network:1
       description: Ethernet interface
       product: I350 Gigabit Network Connection
       vendor: Intel Corporation
       physical id: 0.1
       bus info: pci@0000:01:00.1
       logical name: eno2
       version: 01
       serial: ac:1f:6b:e7:e7:b5
       size: 1Gbit/s
       capacity: 1Gbit/s
       width: 32 bits
       clock: 33MHz
       capabilities: pm msi msix pciexpress bus_master cap_list ethernet physical tp 10bt 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation
       configuration: autonegotiation=on broadcast=yes driver=igb driverversion=5.6.0-k duplex=full firmware=1.69, 0x80000df4 ip=192.168.8.161 latency=0 link=yes multicast=yes port=twisted pair speed=1Gbit/s
       resources: irq:98 memory:eff00000-eff1ffff ioport:1000(size=32) memory:eff40000-eff43fff memory:1c904040000-1c90405ffff memory:1c904060000-1c90407ffff
  *-network
       description: interface
       product: MT27520 Family [ConnectX-3 Pro]
       vendor: Mellanox Technologies
       physical id: 0
       bus info: pci@0000:61:00.0
       logical name: ibp97s0
       logical name: /dev/fb0
       version: 00
       serial: a0:00:02:20:fe:80:00:00:00:00:00:00:9c:dc:00:00:00:00:00:00
       width: 64 bits
       clock: 33MHz
       capabilities: pm vpd msix pciexpress bus_master cap_list rom physical fb
       configuration: autonegotiation=on broadcast=yes depth=32 driver=ib_ipoib driverversion=4.9-4.1.7 duplex=full firmware=2.42.5700 ip=172.18.8.2 latency=0 link=yes mode=1024x768 multicast=yes visual=truecolor xres=1024 yres=768
       resources: iomemory:8f0-8ef irq:94 memory:ea500000-ea5fffff memory:8f06000000-8f07ffffff memory:ea400000-ea4fffff
  *-network DISABLED
       description: interface
       physical id: 4
       bus info: pci@0000:61:00.0
       logical name: ibp97s0d1
       serial: a0:00:03:00:fe:80:00:00:00:00:00:00:9c:dc:00:00:00:00:00:00
       size: 10Gbit/s
       capabilities: physical
       configuration: autonegotiation=on broadcast=yes driver=ib_ipoib driverversion=4.9-4.1.7 duplex=full firmware=2.42.5700 link=no multicast=yes speed=10Gbit/s

製品のネットワークポート: MT27520 ファミリ [ConnectX-3 Pro]、対応する論理名: ibp97s0 に注意してください。

ネットワークポートのIPを設定します

/etc/netplan/00-installer-config.yaml を変更し、IP アドレスを追加します

# This is the network config written by 'subiquity'
network:
  ethernets:
    eno1:
      optional: true
      dhcp4: true
    eno2:
      optional: true
      dhcp4: true
    ibp97s0:
      addresses: [172.18.8.2/24]
  version: 2

変更後、sudo netplan applyを実行

ストレージ構成 (物理 nvme ディスクはこのサーバー上にあります)

exp_nvme.sh

#!/bin/bash
expdev(){
    echo "exp nvme dev [subsystem] = $1 [nvme dev] = $2 [namespace number]=$3 [ip]=$4 [port]=$5"
    mkdir /sys/kernel/config/nvmet/subsystems/$1/namespaces/$3
    echo -n $2 > /sys/kernel/config/nvmet/subsystems/$1/namespaces/$3/device_path
    echo 1 > /sys/kernel/config/nvmet/subsystems/$1/namespaces/$3/enable
    mkdir /sys/kernel/config/nvmet/ports/$3
    echo $4 > /sys/kernel/config/nvmet/ports/$3/addr_traddr
    echo rdma > /sys/kernel/config/nvmet/ports/$3/addr_trtype
    echo $5 > /sys/kernel/config/nvmet/ports/$3/addr_trsvcid
    echo ipv4 > /sys/kernel/config/nvmet/ports/$3/addr_adrfam
    ln -s /sys/kernel/config/nvmet/subsystems/$1 /sys/kernel/config/nvmet/ports/$3/subsystems/$1
}

modprobe mlx5_core
modprobe nvmet
modprobe nvmet-rdma
modprobe nvme-rdma

mkdir /sys/kernel/config/nvmet/subsystems/data_8
echo 1 > /sys/kernel/config/nvmet/subsystems/data_8/attr_allow_any_host
expdev data_8 /dev/nvme0n1 800 172.18.8.1 6600
expdev data_8 /dev/nvme1n1 801 172.18.8.1 6601
expdev data_8 /dev/nvme2n1 802 172.18.8.1 6602
expdev data_8 /dev/nvme3n1 803 172.18.8.1 6603
expdev data_8 /dev/nvme4n1 804 172.18.8.1 6604

接続終了設定（このサーバーからリモートnvmeディスクに接続）

####nvme コマンドラインツールをインストールする

`1`	`sudo apt install nvme-cli`

nvmeスクリプトを実行する

1
2
3

modprobe mlx5_core
modprobe nvme-rdma
sudo nvme connect -t rdma -n data_8 -a 172.18.8.1 -s 6601

実行が成功したら、 sudo fdisk -l を使用して接続されている nvme デバイスを一覧表示し、ローカルブロックデバイスの方法に従ってそれらをマウントできます。

UPS は停電後に Linux サーバースクリプトを自動的にシャットダウンします

Mon, 28 Mar 2022 00:00:00 +0000

安価な UPS には検出ポートがないため、停電後にサーバーをシャットダウンするには手動介入が必要です。このスクリプトは、停電を自動的に検出し、サーバーをシャットダウンできます。
このスクリプトは Linux システムのみをサポートします。

動作原理

動作にはリファレンスデバイスが必要です。参照デバイスには IP アドレスがあり、UPS システムの外部に接続されている必要があります。停電後はIPアドレスが失われます。サーバーが ping に失敗した場合、指定された時間内にサーバーは自動的にシャットダウンします。

crontab のタイミング設定

crontab は root に設定する必要があります。他のユーザーにはコンピューターをシャットダウンする権限がありません。

1
2

# m h  dom mon dow   command
* * * * * /root/detect_ups.sh >> /var/log/detect_ups.log

* * * * * は 1 分ごとにテストすることを意味します
/root/detect_ups.sh はスクリプトの場所を示します

検出スクリプト

/root/detect_ups.sh

#!/bin/bash 

me="$(basename "$0")";
running=$(ps h -C "$me" | grep -wv $$ | wc -l);
[[ $running > 1 ]] && exit;

detect_ip=192.168.1.1
ping_count=1
detect_delay=300
echo " detect ip:=$detect_ip"
echo " detect delay:=$detect_delay sec"

ping -c ${ping_count} ${detect_ip} > /dev/NULL
if [ $? -eq 0 ]
then
    echo ' AC Power OK !'
else
    echo " AC Power maybe off, checking again after ${detect_delay} second !"
    sleep ${detect_delay}  #延时秒
    ping -c ${ping_count} ${detect_ip} > /dev/NULL
    if [ $? -eq 0 ]
    then
        echo ' AC Power recover, return !'
    else
        echo ' AC Power always off, poweroff !'
        /usr/sbin/poweroff
    fi
fi

Hugo 記事 (MD ファイル) のディレクトリ構成

Fri, 25 Mar 2022 00:00:00 +0000

Hugo の通常のディレクトリ構造

一般的な例は次のとおりです

content/
└── post
    ├── chinese-test
    │   ├── florian-klauer-nptLmg6jqDo-unsplash.jpg
    │   ├── helena-hertz-wWZzXlDpMog-unsplash.jpg
    │   ├── hudai-gayiran-3Od_VKcDEAA-unsplash.jpg
    │   ├── index.zh-cn.md
    │   └── luca-bravo-alS7ewQ41M8-unsplash.jpg
    ├── emoji-support
    │   ├── index.md
    │   └── the-creative-exchange-d2zvqp3fpro-unsplash.jpg
    ├── markdown-syntax
    │   ├── index.md
    │   └── pawel-czerwinski-8uZPynIu-rQ-unsplash.jpg
    ├── math-typesetting
    │   └── index.md
    ├── placeholder-text
    │   ├── index.ar.md
    │   ├── index.md
    │   └── matt-le-SJSpo9hQf7s-unsplash.jpg
    └── rich-content
        └── index.md

上に示すように、md ファイルは content/post ディレクトリに保存されます。各記事にはディレクトリがあります。記事内で使用されている画像とMDファイルは同じディレクトリに配置されています。記事数が少ない場合にはこの構造でも大きな問題はありませんが、ブログを書く時間が長くなり記事数が増えてくると、投稿ディレクトリ内のディレクトリが多くなり、探すのが面倒になってきます。次のディレクトリ構造が使用できます

時間ごとに分割されたディレクトリ構造

content/
└── post
    ├── 2020
    │   ├── 1.zh-cn.md
    │   ├── 1.zh-tw.md
    │   └── 2
    │       ├── 1.jpg
    │       ├── 2.jpg
    │       ├── 3.png
    │       ├── index.zh-cn.md
    │       ├── index.zh-tw.md
    │       └── 4.png
    ├── 2021
    │   ├── 1.zh-cn.md
    │   ├── 1.zh-tw.md
    │   ├── 2.zh-cn.md
    │   ├── 2.zh-tw.md
    │   ├── 3.zh-cn.md
    │   ├── 3.zh-tw.md
    │   ├── 4.zh-cn.md
    │   ├── 4.zh-tw.md
    │   ├── 5.zh-cn.md
    │   └── 5.zh-tw.md
    └── 2022
        ├── 1.zh-cn.md
        ├── 1.zh-tw.md
        └── 2
            ├── 1.png
            ├── 2.png
            ├── 3.png
            ├── 4.png
            ├── 5.png
            ├── 6.png
            ├── 7.png
            ├── 8.png
            ├── 9.png
            ├── index.zh-cn.md
            └── index.zh-tw.md

上に示すように

post ディレクトリの下に、まず年に基づいてサブディレクトリを作成します。もちろん、更新頻度が高い場合は、年/月または年/月/日に基づいて第 1 レベルのディレクトリを作成することもできます。
画像のない記事は年月日ディレクトリに直接保存されます。
画像がある場合は、追加の第 1 レベルのディレクトリを作成します。 md ファイルの名前は、index.lang.md です (他の名前のファイルを使用すると、画像は表示されません)。画像は同じディレクトリに配置されます。
さまざまな言語の MD ファイルがまとめられ、index.zh-cn.md、index.zh-tw.md などのさまざまなindex.lang.md によって区別されます。

Hugoブログが発言コメント機能を追加

Fri, 25 Mar 2022 00:00:00 +0000

発話と他の競合製品との比較

発言は GitHub の問題に基づいたコメントツールです同様のツールである gitment、gitalk、disqus コメントツールと比較すると、次のような利点があります。

非常に軽量で、読み込みが非常に速く、設定が比較的簡単です
現在disqusが充電中のようです
speech は github の問題に基づいており、さまざまなテーマを備えたオープンソースの無料ウィジェットがあります。

インストール手順

github アカウントを持ってリポジトリを作成する必要があります。コメントはこのリポジトリの課題に保存されます。
発話アプリをインストールする発言アプリのインストールは比較的簡単で、GitHub に直接インストールするだけです。 GitHub アプリのリンク: https://github.com/apps/utterances 発話アプリケーションにアクセスし、「インストール」ボタンをクリックしてインストールします。最初のステップで作成したリポジトリを選択します
Hugo の config.toml ファイルで設定するだけです

[params.utteranc]         # utteranc is a comment system based on GitHub issues. see https://utteranc.es
    enable = true
    repo = "github_user/repository"    # The repo to store comments
    issueTerm = "pathname"

WordPress から Hugo に移行する方法

Wed, 23 Mar 2022 00:00:00 +0000

移行する理由

wordpressのWeb MDエディターは機能が比較的弱く、使用中に問題が発生しやすく、編集内容が失われやすいです。 Hugo では、より効率的な独自のローカル MD エディターを選択できます。
WordPress イメージは、最初にアップロードしてから、md ファイル内で参照する必要があります。 Hugo はディレクトリに配置することで直接参照できます。
WordPress はデータベースと PHP をインストールする必要がありますが、サーバーに高い要件があり、メンテナンスが面倒です。

移行プロセス

Hugoをインストールする

https://gohugo.io/getting-started/quick-start/ インストールして初期設定を完了する

ワードプレスのMDファイルをエクスポートする

この https://github.com/SchumacherFM/wordpress-to-hugo-exporter エクスポートを使用します

WordPress プラグインディレクトリ wp-content/plugins/ に、「WordPress to Hugo Exporter」のソースコードを直接クローンします。

1
2
3

$ git clone https://github.com/SchumacherFM/wordpress-to-hugo-exporter.git
$ cd wordpress-to-hugo-exporter
$ php hugo-export-cli.php

このコマンドは、hugo-export.zip ファイルをローカルに生成します。

ファイルを解凍すると、主に次の部分が含まれます。

config.yaml: Hugo の設定ファイル、これを書き換えます
photos: このディレクトリにはすべてのブログ投稿があります。全てMDファイルです。ファイル名には日付が付いているので、日付順に並べ替えることができます。
wp-content: このディレクトリは主にアップロードディレクトリであり、以前にアップロードされたすべてのメディアファイルが含まれます。 WordPress は年と月ごとに分けて保存されます。他のページも作成している場合は、他のページ名のディレクトリがあり、そこには MD ファイルも含まれています。

MD ファイルを表示すると、記事のタイトル、作成者、作成時刻、URL アドレス、分類、タグ、その他の情報を含む YAML 部分が先頭に表示されます。概要情報もありますが、通常、Hugo テーマは「抜粋」概要を認識しません。これを「説明」に変更すると、この部分が Web サイトのページヘッダーの「メタ説明」のコンテンツになります。これでエクスポート作業は完了です

MDファイルをインポートする

通常、エクスポートされたファイルは /content ディレクトリに配置されます。詳細については、テーマのドキュメントを参照してください。テーマの選択は https://themes.gohugo.io/ です。

ウェブサイトを生成してアップロードする

1
2

hugo
rsync -azv public/ root@youre_server_ip:/your/folder/

Ubuntu 20.04でRAID下のディスクのスマート情報（SSDの読み書きボリュームや耐久性情報など）を確認する方法

Thu, 25 Nov 2021 00:00:00 +0000

スマートモンツールをインストールする

`1`	`sudo apt-get install smartmontools`

表示するには次のコマンドを使用します /dev/sda は、RAID 形成後のデバイス名です。 -d cciss,0 RAID のディスク番号 0、同様に -d cciss,1 は Raid のディスク番号 1 を意味します

`1`	`sudo smartctl -a -d cciss,0 /dev/sda`

実際のコマンド出力は次のとおりです。

smartctl 7.1 2019-12-30 r5022 [x86_64-linux-5.11.0-40-generic] (local build)
Copyright (C) 2002-19, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Vendor:               SEAGATE
Product:              XS800LE70004
Revision:             0003
Compliance:           SPC-5
LU is resource provisioned, LBPRZ=1
Rotation Rate:        Solid State Device
Form Factor:          2.5 inches
Logical Unit id:      0x5000c5003e83f24b
Serial number:        HLJ03MGG0000822150Z3
Device type:          disk
Transport protocol:   SAS (SPL-3)
Local Time is:        Thu Nov 25 17:47:46 2021 CST
SMART support is:     Available - device has SMART capability.
SMART support is:     Enabled
Temperature Warning:  Enabled

=== START OF READ SMART DATA SECTION ===
SMART Health Status: OK

Percentage used endurance indicator: 13%
Current Drive Temperature:     37 C
Drive Trip Temperature:        70 C

Manufactured in week 30 of year 2019
Specified cycle count over device lifetime:  10000
Accumulated start-stop cycles:  340
Elements in grown defect list: 0

Vendor (Seagate Cache) information
  Blocks sent to initiator = 4018240293
  Blocks received from initiator = 2045277761
  Blocks read from cache and sent to initiator = 0
  Number of read and write commands whose size <= segment size = 0
  Number of read and write commands whose size > segment size = 0

Vendor (Seagate/Hitachi) factory information
  number of hours powered up = 2459.70
  number of minutes until next internal SMART test = 59

Error counter log:
           Errors Corrected by           Total   Correction     Gigabytes    Total
               ECC          rereads/    errors   algorithm      processed    uncorrected
           fast | delayed   rewrites  corrected  invocations   [10^9 bytes]  errors
read:          0        0         0         0          0     881666.641           0
write:         0        0         0         0          0     915841.827           0

Non-medium error count:        0

No Self-tests have been logged

Percentage used endurance indicator: SSD ディスクの健全性情報。0 は新品を意味し、100 は健全性レベルが 0 であることを意味します。まだ正常に使用できる可能性がありますが、期待寿命が消耗していることを意味します。

Gigabytes processed （read，write）データの読み取りおよび書き込みの数、単位は GB

Ubuntu 20.04 での HP アレイカードツール ssacli の使用

Tue, 23 Nov 2021 00:00:00 +0000

ssacli (スマートストレージアドミニストレータコマンドラインインターフェイス) ツールを使用して、HP アレイカードを管理できます。

インストール

HP の MCP リポジトリを追加する To add HP’s MCP repository to apt sources list use this command:

`1`	`echo "deb http://downloads.linux.hpe.com/SDR/repo/mcp stretch/current non-free" > /etc/apt/sources.list.d/hp-mcp.list`

MCP リポジトリの公開キーをダウンロードします。

wget -q -O - http://downloads.linux.hpe.com/SDR/hpPublicKey1024.pub | apt-key add -
wget -q -O - http://downloads.linux.hpe.com/SDR/hpPublicKey2048.pub | apt-key add -
wget -q -O - http://downloads.linux.hpe.com/SDR/hpPublicKey2048_key1.pub | apt-key add -
wget -q -O - http://downloads.linux.hpe.com/SDR/hpePublicKey2048_key1.pub | apt-key add -

ssacliパッケージをインストールする

1
2

apt update
apt install ssacli

ssacli ツールの使用

略語

chassisname = ch
controller = ctrl
logicaldrive = ld
physicaldrive = pd
drivewritecache = dwc
licensekey = lk

共通コマンドアレイカードの詳細を表示

`1`	`ssacli ctrl all show detail`

アレイカード構成を表示する

`1`	`ssacli ctrl all show config`

すべての物理ディスク情報を表示する

`1`	`ssacli ctrl slot=0 pd all show detail`

RAID 0論理ドライブを作成する

`1`	`ssacli ctrl slot=0 create type=ld drives=1I:1:1,1I:1:2 raid=0`

論理ドライブの削除

`1`	`ssacli ctrl slot=0 ld 1 delete`

新しいディスクを論理ドライブに追加する

`1`	`ssacli ctrl slot=0 ld 2 add drives=1I:1:6,1I:1:7`

物理ドライブを取り外します

`1`	`ssacli ctrl slot=0 pd 1I:1:1 modify erase`

アレイカードの温度を表示する

`1`	`ssacli ctrl all show detail \| grep 'Controller Temperature'`

`1`	`Controller Temperature (C): 43`

ディスク温度の表示

`1`	`ssacli ctrl slot=5 pd all show detail \| grep 'Current Temperature'`

1
2
3

         Current Temperature (C): 37
         Current Temperature (C): 36
         Current Temperature (C): 43

パススルーを設定する For Smart-array controller starting with P, e.g. P420i:

`1`	`ssacli controller slot=0 modify hbamode=on`

For HBAs starting with H, e.g. H240:

`1`	`ssacli controller slot=0 modify raidmode=off`

Ubuntu 20.04 での zfs ファイルシステムの使用

Tue, 23 Nov 2021 00:00:00 +0000

zfs を使用する利点は、いつでもハードディスクを追加できることです。 zfs をインストールする

`1`	`sudo apt install zfsutils-linux`

zpoolの作成

`1`	`sudo zpool create data_ar /dev/sdb`

既存のプールにディスクを追加する

1
2
3

sudo zpool add data_ar /dev/sdd
sudo zpool add data_ar /dev/sdd -f
sudo zpool add data_ar /dev/sde -f

システムの再起動またはアップデート後、zfs が表示されなくなります

`1`	`zpool import data_ar`

スナップショットの作成

`1`	`sudo zfs snapshot data_ar@v01`

zpool スナップショットをバックアップする

`1`	`zfs send data_ar@v01 \| gzip > /mnt/d/backupfile.gz`

zfsの削除

`1`	`sudo zpool destroy data_ar`

マウントポイントを変更する

`1`	`sudo zfs set mountpoint=/myspecialfolder mypool`

Certbot を使用して、無料で自動的に更新される Nginx 用の HTTPS 証明書を Ubuntu20.04 にインストールする方法

Tue, 02 Nov 2021 00:00:00 +0000

最終効果

インストールが完了すると、次の結果が得られます。

Nginx Web サービスの無料証明書をインストールする
証明書の有効期限が切れると、証明書を自動的に更新してインストールできます。更新プロセス中に手動介入は必要ありません。

インストールプロセス

ファイアウォールの設定

ファイアウォールがインストールされていない場合は、次のコマンドを使用してファイアウォールをインストールします。

1
2

sudo apt update
sudo apt install ufw

ファイアウォールは、ssh (ポート 22)、http (ポート 80)、https (ポート 443) のポート通信を開きます。

1
2
3

sudo ufw allow ssh
sudo ufw allow http
sudo ufw allow https

ファイアウォールを有効にする

`1`	`sudo ufw enable`

ファイアウォールのステータスを表示するには、次のコマンドを使用します。

`1`	`sudo ufw status`

Certbot をインストールする

まず snapd をインストールし、次に snapd を使用して Certbot をインストールします

sudo apt update
sudo apt install snapd
sudo snap install core
sudo snap refresh core
sudo apt remove certbot
sudo snap install --classic certbot

リンクの作成

`1`	`sudo ln -s /snap/bin/certbot /usr/bin/certbot`

Certbot を使用して証明書を取得し、インストールします

Certbot を実行して証明書を取得します
- 証明書を取得し、Nginx に自動的にインストールします (推奨) これが推奨される方法です。証明書を取得すると、Nginx 構成ファイルが自動的に変更され、証明書がインストールされます。設定は 1 つの簡単なステップで完了
1

sudo certbot --nginx
- 証明書を取得しますが、Nginx にインストールされませんこの方法では証明書のみを取得します。その後、証明書のインストールプロセスを完了するには、Nginx 構成ファイルを手動で変更する必要があります。
1

sudo certbot certonly --nginx

2.メールアドレスを入力 3. 利用規約に同意する 4. メーリングリストに登録することを選択できます 5. ドメイン名を入力します 6. 次に、Certbot は Let’s Encrypt と通信して証明書を要求します。

操作が成功すると、Certbot は証明書が有効であることを確認します。また、証明書とキーチェーンが保存されているディレクトリと有効期限に関する情報も表示されます。証明書は通常、90 日後に期限切れになります。

Requesting a certificate for www.example.com
Performing the following challenges:
http-01 challenge for www.example.com
Waiting for verification...
Cleaning up challenges
Deploying Certificate to VirtualHost /etc/nginx/sites-enabled/default
Redirecting all traffic on port 80 to ssl in /etc/nginx/sites-enabled/default

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Congratulations! You have successfully enabled https://www.example.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
...
- Congratulations! Your certificate and chain have been saved at:
/etc/letsencrypt/live/www.example.com/fullchain.pem
Your key file has been saved at:
/etc/letsencrypt/live/www.example.com/privkey.pem
our certificate will expire on 2021-05-29.

Certbot を使用して TLS/SSL 証明書を更新する

インストール後、Certbot は証明書を自動的に更新するように構成されます。更新された証明書を手動で要求したり、Certbot を再度実行したりする必要はありません。 Certbot はすべての証明書を自動的に更新します。

iFlytek 音声合成 API を介して音声と字幕 (SRT) ファイルを同期的に生成

Fri, 29 Jan 2021 00:00:00 +0000

iFlytek 音声 API

iFlytek の音声合成 API は合成音声を出力することしかできず、対応する字幕 (srt) ファイルを直接生成することはできません。ただし、API は音声生成プロセス中に処理されたバイト数を同期的に返します。

1
2

data.ced	string	合成进度，指当前合成文本的字节数
注：请注意合成是以句为单位切割的，若文本只有一句话，则每次返回结果的ced是相同的。

このフィールドを通じて、必要な srt 字幕ファイルを生成できます。

踏まれた穴は

PCM ファイルは API を通じて返される必要があります。 MP3 ファイルを返すことを選択した場合、mp3 ファイルの長さを計算するときにエラーが発生します。つまり、各 mp3 セグメントの長さを合計し、生成されるファイルの合計の長さになる必要があります。ただし、実際にはまったく一致しないことが判明し、最終的に生成される srt ファイルのタイムラインが不正確になります。次の mp3 Python ライブラリは正しいとは見なされません。

    #使用mutagen.mp3
    from mutagen.mp3 import MP3
    audio = MP3(filename)
    duration = audio.info.length

    #使用ffmpeg
    duration = ffmpeg.probe(filename)['format']['duration']

    #使用eyed3
    duration = eyed3.load(filename).info.time_secs

返された mp3 の形式に何か問題があるはずです

###Pythonコード

# -*- coding:utf-8 -*-
import websocket
import datetime
import hashlib
import base64
import hmac
import json
from urllib.parse import urlencode
import time
import ssl
from wsgiref.handlers import format_date_time
from datetime import datetime
from time import mktime
import _thread as thread
import os
import shutil
import ffmpeg
import sys

wsParam = None

class Const() :
    PCM_FOLDER = './pcm'

class Ws_Param(object):
    # 初始化
    def __init__(self, APPID, APIKey, APISecret, Text):
        self.APPID = APPID
        self.APIKey = APIKey
        self.APISecret = APISecret
        self.Text = Text

        # 公共参数(common)
        self.CommonArgs = {"app_id": self.APPID}
        # 业务参数(business)，更多个性化参数可在官网查看
        self.BusinessArgs = {"aue": "raw", "auf": "audio/L16;rate=16000", "vcn": "aisjiuxu", "volume":80, "pitch":25, "tte":"utf8"}
        self.Data = {"status": 2, "text": str(base64.b64encode(self.Text.encode('utf-8')), "UTF8")}
        #使用小语种须使用以下方式，此处的unicode指的是 utf16小端的编码方式，即"UTF-16LE"”
        #self.Data = {"status": 2, "text": str(base64.b64encode(self.Text.encode('utf-16')), "UTF8")}

    # 生成url
    def create_url(self):
        url = 'wss://tts-api.xfyun.cn/v2/tts'
        # 生成RFC1123格式的时间戳
        now = datetime.now()
        date = format_date_time(mktime(now.timetuple()))

        # 拼接字符串
        signature_origin = "host: " + "ws-api.xfyun.cn" + "\n"
        signature_origin += "date: " + date + "\n"
        signature_origin += "GET " + "/v2/tts " + "HTTP/1.1"
        # 进行hmac-sha256进行加密
        signature_sha = hmac.new(self.APISecret.encode('utf-8'), signature_origin.encode('utf-8'),
                                 digestmod=hashlib.sha256).digest()
        signature_sha = base64.b64encode(signature_sha).decode(encoding='utf-8')

        authorization_origin = "api_key=\"%s\", algorithm=\"%s\", headers=\"%s\", signature=\"%s\"" % (
            self.APIKey, "hmac-sha256", "host date request-line", signature_sha)
        authorization = base64.b64encode(authorization_origin.encode('utf-8')).decode(encoding='utf-8')
        # 将请求的鉴权参数组合为字典
        v = {
            "authorization": authorization,
            "date": date,
            "host": "ws-api.xfyun.cn"
        }
        # 拼接鉴权参数，生成url
        url = url + '?' + urlencode(v)
        # print("date: ",date)
        # print("v: ",v)
        # 此处打印出建立连接时候的url,参考本demo的时候可取消上方打印的注释，比对相同参数时生成的url与自己代码生成的url是否一致
        # print('websocket url :', url)
        return url

def on_message(ws, message):
    try:
        message =json.loads(message)
        code = message["code"]
        sid = message["sid"]
        audio = message["data"]["audio"]
        audio = base64.b64decode(audio)
        status = message["data"]["status"]
        ced = message["data"]["ced"]
        print(message)
        if status == 2:
            print("ws is closed")
            ws.close()

        if code != 0:
            errMsg = message["message"]
            print("sid:%s call error:%s code is:%s" % (sid, errMsg, code))
        else:
            with open(Const.PCM_FOLDER + '/v_'+ ced.zfill(8) +'.pcm', 'ab') as f:
                f.write(audio)

            with open(Const.PCM_FOLDER + '/all.pcm', 'ab') as fa:
                fa.write(audio)

    except Exception as e:
        print("receive msg,but parse exception:", e)

def on_error(ws, error):
    print("### error:", error)

def on_close(ws):
    print("### closed ###")

def on_open(ws):
    def run(*args):
        d = {"common": wsParam.CommonArgs,
             "business": wsParam.BusinessArgs,
             "data": wsParam.Data,
             }
        d = json.dumps(d)
        print("------>开始发送文本数据")
        ws.send(d)
    thread.start_new_thread(run, ())

def read_text() :
    with open('content.txt','r',encoding='utf-8') as f:
        content = f.read()
    return content

def pcm_duration(filename):
    fsize = os.path.getsize(filename)
    duration = fsize / 16000 / 2
    print(duration)
    return float(duration)

def format_mtime(mtime) :
    hh = int(mtime / 3600000)
    mm = int((mtime % 3600000) / 60000)
    ss = int((mtime % 60000) / 1000)
    sss = int(mtime % 1000)
    text = ('%02d' % hh) + ':' + ('%02d' % mm) + ':' + ('%02d' % ss) + ',' + ('%03d' % sss)
    return(text)

def init():
    global wsParam
    if os.path.exists(Const.PCM_FOLDER):
        shutil.rmtree(Const.PCM_FOLDER)
    time.sleep(1)
    os.makedirs(Const.PCM_FOLDER)
    time.sleep(1)

    text = read_text()
    print(text)
    wsParam = Ws_Param(APPID='XXXXX', APISecret='XXXXXXXXXXXXXXXXXXXXXXXXXX',
                       APIKey='XXXXXXXXXXXXXXXXXXXXXXXXXXXX',
                       Text=text)

def create_pcm():
    global wsParam
    websocket.enableTrace(False)
    wsUrl = wsParam.create_url()
    ws = websocket.WebSocketApp(wsUrl, on_message=on_message, on_error=on_error, on_close=on_close)
    ws.on_open = on_open
    ws.run_forever(sslopt={"cert_reqs": ssl.CERT_NONE})

def create_srt() :
    global wsParam

    prevId = 1
    prevCed = '0'
    prevDuration = 0

    text = read_text()
    print(text)

    for file in os.listdir(Const.PCM_FOLDER):
        if (not os.path.isdir(file)) and (file.startswith('v_')) and (file.endswith('.pcm')):
            print('process file ' + file)
            duration = pcm_duration(Const.PCM_FOLDER + '/' + file)
            ced = file[2:-4]
            print('ced=' + ced)
            if duration > 0.5 :
                with open('content.srt', 'a') as fb:
                    line1 = str(prevId)
                    line2 = format_mtime(int(round(prevDuration * 1000))) + ' --> ' + format_mtime(int(round((prevDuration + duration) * 1000)))
                    line3 = text.encode('utf-8')[int(prevCed):int(ced)].decode('utf-8')
                    print(line1)
                    print(line2)
                    print(line3)
                    fb.write(line1 + '\n')
                    fb.write(line2 + '\n')
                    fb.write(line3 + '\n')
                    fb.write('\n')
                prevId += 1
            prevDuration += duration
            prevCed = ced
    print('prevDuration=' + str(prevDuration))

def convert_mp3():
    cmd='ffmpeg -y -f s16le -ac 1 -ar 16000 -acodec pcm_s16le -i ' + Const.PCM_FOLDER + '/all.pcm all.mp3'
    os.system(cmd)

if __name__ == "__main__":
    init()
    create_pcm()
    create_srt()
    convert_mp3()

技術文書 on KnightLiブログ

Windows Secure Boot証明書が2026年に期限切れ：一般ユーザーと管理者はどう更新すべきか

今回の更新は何を意味するのか

起動に影響するのか

一般ユーザーがすべきこと

企業管理者が注意すべきこと

デュアルブートとサードパーティ起動ツールは特に注意

やるべきでないこと

まとめ

Hugo aliases の使い方：古い URL の自動リダイレクトと 404 修正ガイド

aliases が役立つ場面

基本的な書き方

url フィールドとの関係

Hugo のデフォルト実装

サーバーサイドリダイレクトを検討する場面

aliases を使うときの注意点

実用的な確認手順

まとめ

参考資料

FreeRTOS、RT-Thread、Zephyr の選び方：3 大 RTOS のアーキテクチャ差と適用場面

まず結論

FreeRTOS：軽量で成熟したカーネル

RT-Thread：国内 MCU とコンポーネントに強い

Zephyr：RTOS というより組み込みシステム基盤

Devicetree が重要な理由

アプリケーションコードがきれいになる理由

資源コストは文脈で見る

どう選ぶか

Zephyr を選ばない方がよい場合

まとめ

2023-2026年の大規模モデルアーキテクチャ総復習：トークナイザ、位置エンコーディング、注意機構、MoE、正規化、活性化関数

まず全体像をつかむ

トークナイザ：「分けられる」から「token を節約する」へ

位置エンコーディング：RoPE が主流に

注意機構：MHA から GQA、スライディングウィンドウ、MLA へ

MoE：「パラメータは多いが、毎回使うのは一部」

正規化：RMSNorm が一般的に

活性化関数：ReLU/GELU から SwiGLU へ

2023-2026 年の全体傾向

初心者はどう学ぶべきか

まとめ

Ubuntu 26.04 LTSでAndroidアプリを動かす：Waydroidの導入と注意点

まず適性を確認する

Waydroidをインストールする

Android環境を初期化する

APKをインストールする

マルチウィンドウ

Google Playは必要か

よくある問題

エミュレーターやVMとの違い

おすすめの使い方

参考資料

GPT-5.5 Prompt 移行ガイド：古いプロンプトはまず削ってから直す

古い prompt をなぜ書き直す必要があるのか

outcome-first：まず完了条件を定義する

絶対ルールを減らし、判断ルールを書く

retrieval budget を設定する

reasoning effort を最初から上げない

text.verbosity は出力を制御するが、思考を制御するわけではない

preamble と phase：長いタスクを見えるようにする

モデルに自分の作業を検証させる

GPT-5.5 に向いた prompt 骨格

古い prompt を移行する実際の順序

古い prompt 移行チェックリスト

GPT-5.5 prompt 例：旧 vs 新

パラメータの組み合わせ

残すべきルール

誤って削ってはいけないもの

まとめ

参考資料

コンピューター用語を平易に言うと：TTS、STT、API、RAG、Agent は何を指すのか

TTS と STT：文字と音声の相互変換

OCR：画像から文字を写し取る

NLP と LLM：機械に人間の言葉を扱わせる

API と SDK：一方は窓口、一方は道具箱

CRUD：作成、読み取り、更新、削除

Cache：よく使うものを手元に置く

Queue：タスクを並べて順番に処理する

Index：データベースに目次を作る

RPC、REST、Webhook：システム同士の話し方