Command

この記事を作った動機 Intel Arc で音声からの文字起こしができる Whisper を動かせることが分かったので記録したい。Whisper は PyTorch を使っているが、それを XPU に対応したものに差し替えることで動作が確認できたことに関して、具体的に作業内容を記録したい。 Whisper を使った文字起こしでは、Vibe を使うことでもできるが、Nvidia の CUDA 環境で無い限り、Intel Arc 環境においては、Vulkan を使ってしまう。PyTorch 環境においては XPU を使わなければ、Intel Arc の GPU 性能をフルに使い切れていない様相が見受けられたことも背景にある。 環境の前提 Intel Arc を使っている Conda 環境を導入済み Linux 環境 記事の作業内容のまとめ conda create -n whisper conda activate whisper conda install pip pip install -U openai-whisper pip uninstall torch pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/xpu Whisper のインストール conda 環境を専用に作る conda create -n whisper conda activate whisper conda install pip whisper を pip でインストール 一旦 Nvidia 環境用の pytorch などがインストールされてしまうが、一旦はインストールを終わらせる。 ...

この記事を作った動機 Android 端末において SoftEther VPN で稼働しているサーバに接続しようとすると、L2TP/IPsec を使った方法と、OpenVPN を使った方法の2つの接続方法がある。しかし、新しいバージョンの Android (12以降) において標準的に利用できる VPN には既に L2TP/IPsec は含まれておらず接続できない。また、OpenVPN を使った方法では、接続には成功するものの、そこに至るまでの設定が分かりづらかったり、技術的に一筋縄では行かないところが多々あった。これら経緯から、やったことについて記録を残したい。 ネットワーク構成 全体像 今回は、192.168.x.0/24 として描かれているネットワークに属するクライアントを Android スマホに見立てる。 今回問題になった特徴について 私の環境では通常のVPNネットワークと異なり、VPNに接続した先にあるネットワークを介して、更に別のネットワークにパケットを転送するPCがあって、そこを介してやり取りするという特徴があり、今回問題になった。 記録 VPN 接続したときのスマホのルーティングテーブルの様子 基本的に OpenVPN 関連で特別なルーティング設定をしても Android OS 側は直接制御を持っていないように見受けられる。以下のように192.168.1.0/24へのルーティングは、OpenVPN 側で正しく動作していても以下のように直接は確認できない。 adb shell cofud:/ $ ip route 10.0.0.0/8 dev ccmni1 proto kernel scope link src 10.150.92.221 192.168.30.12/30 dev tun0 proto kernel scope link src 192.168.30.13 cofud:/ $ exit 使うべきアプリ OpenVPN Connect ではなく、OpenVPN for Android を使うべき。 Android ではアプリを介してしか詳細な制御ができず、OpenVPN Connect は限られた設定項目しか利用できない問題があった。ルーティングや MTU、MSS、DNSなどについて細かく設定したい場合は、OpenVPN for Android などの別のアプリが必要であった。OpenVPN Connect などのアプリは、基本的に詳細な設定ができず、かつどのように読み込ませた".ovpn"などの設定が実際反映されているか確認が難しかったり色々困難があった。 ...

この記事を作った動機 Linux 環境において、VPN 環境についてトラブルシュートしていたところ、設定ミスが発生した。その原因として、viaという単語を正しく解釈できておらず、VPN クライアントの設定ミスでパケットをクライアント内のネットワークでループさせていたということがあった。今回の記事では、そのことについて軽くまとめたい。 説明 簡易的な解釈 iproute2 における via というキーワードは、ゲートウェイ設定(静的ルーティング、Next Hop)を表す。ルーティングされる対象のネットワーク via ゲートウェイ のような書き方になる。ゲートウェイとして、クライアント自身を設定してしまうとローカルでループしてパケットが期待どうりにネットワークに排出されない通信障害になる。 例えば、クライアントが VPN 接続先以外のネットワークから VPN 接続をすることを想定する。VPN クライアントは仮想インターフェース(vpn_vps)に、192.168.30.100/24 を持っていると仮定し、VPN サーバの仮想ハブが 192.168.30.2 をL3仮想スイッチルーティング用に持っている場合を想定する。この場合、192.168.30.0/24 のネットワークを経由して、192.168.0.0/24 にパケットを送りたい場合は、192.168.30.2 をゲートウェイを設定する。192.168.30.100/24 などクライアント自身を指定すると、通信がローカルでループし、VPN クライアントはそもそもパケットを外部のネットワークに排出せず、通信障害になる。 一見すると 192.168.0.0/24 via [VPNクライアント自身のIP] とかくと、VPNクライアント自身のIPを経由して外部に 192.168.0.0/24 宛てのパケットをルーティングするという解釈もできそうだが、少なくとも Linux 環境の iproute2 の設定においては、その解釈は間違っていそうである。あくまで via というキーワードが示しているのは、次にパケットをどのコンピュータに送るべきか、外部のルーティングが可能なコンピュータの IP を指定するという意味合いなようである。クライアント自身を設定してしまうと、クライアント自身にルーティングしてしまうようである。 また、Linux 環境の iproute2 における設定では、明確に外部のゲートウェイとなる PC の IP を指定しなくても、パケットを送り出したいインターフェースだけ指定するという、曖昧な設定もできるようである。192.168.0.0/24 dev vpn_vps のようにして、192.168.0.0/24 宛てのパケットを、vpn_vps という NIC からとにかく送り出すという設定はできるようである。 # いろんな書き方の例 # VPNクライアントとして接続されているルータPCにルーティングする仮想L3スイッチのIPを 192.168.30.2/24 として仮定している ip route add 192.168.0.0/24 via 192.168.30.2 dev vpn_vps ip route add 192.168.0.0/24 dev vpn_vps ip route add defalt via 192.168.30.2 dev vpn_vps 前提とするネットワーク構成図に関する説明 単語の説明 Home Network 自宅のネットワークなど私的に運用される LAN Foreign Network 大学や仕事場所、コンビニやファミレスなどにある公共の場所にある LAN 各ネットワークに関する説明 192.168.0.0/24 家庭用ルータではなく、主に nftables によって転送が管理されていて、カーネルで転送許可をしてある Linux ルータPCで管理されている自宅のネットワーク 192.168.30.0/24 固定 IP を持った VPS 上で動いている SoftEther VPN Server (DHCP サーバが有効) における仮想ハブのネットワーク 192.168.x.0/24 大学や仕事場所、コンビニやファミレスなどにある公共の場所のネットワーク 192.168.0.1/24 192.168.30.2/24 192.168.x.1/24 各ネットワークにおけるデフォルトゲートウェイ や DHCP、場合によっては DNS サーバーなど一通りのルーティングなどのネットワークに必要な機能を備えた装置の IP やルーティングを行う仮想L3スイッチの IP 192.168.30.13/24 SoftEther VPN Server を動かしている VPS がクライアントとして仮想ハブのネットワークに参加しているときの IP 192.168.30.100/24 Foreign Network から VPN 接続して仮想ハブに参加している VPN クライアントの仮想 NIC における IP NIC 名の説明 vpn_vps Foreign Network から VPS 上にある VPN の仮想ハブにアクセスする際に、VPN クライアントが使う仮想インターフェース名 その他説明 ルータPC Home Network で使われている、家庭用ルータの代わりに、スイッチとセットで nftables で転送や NAT を構成し、ip-hole や kea で DNS や DHCP サーバとしても機能するようにした Linux PC のこと。VPS 上で動いている VPN サーバのネットワークにもクライアントとして参加し、192.168.30.0/24 と 192.168.0.0/24 の間を転送する。異なるネットワーク間を転送する際、ARPプロキシ(L2ルーティング)は有効にしていない。 VPN サーバー 今回登場する VPN サーバーは直接 Home Network からは動作せず、VPS 上に専用に用意したものである。192.168.30.0/24 のネットワークを接続した VPN クライアントに提供する。仮想 L3 スイッチの設定により、192.168.0.0/24 宛てへのパケットを、192.168.30.0/24 に接続していてネットワークの越境が可能な転送設定をしてある VPN クライアントであるルータPCに仕向けるように設定してある。 説明の図 各ルーティング状況に関する説明 パケットがクライアント内部でループするイメージ 上記の図のような状況において、トラブルシュートでは以下のような厄介な挙動が見受けられた。 ...

この記事を作った動機 単に地味にしんどかった設定についてその手順をブログに記録したいだけ。今回は CapsLock キーを ESC キーに割り当てることについて、記事を記録する。環境については、以下の項目を前提としている。 Linux GNOME Wayland やり方 パッケージのインストール yay -S keyd # sudo pacman -S keyd 設定を書く (/etc/keyd/default.conf) [ids]の項目がないと一切設定が効かない。以下では*を指定することですべての入力デバイスを Keyd の対象として扱っている。再割当てには、[main]セクションを作り、そこに再割当て対象のキー名 = 割り当てたい役割のキー名という形で記述しただけである。 [ids] * [main] capslock = escape 明示的に Keyd 管理対象の入力デバイスを指定する 明示的に、Keyd の影響が及ぶキーボードなどのデバイスを指定するには、lsplug コマンドなど、何かしら接続された USB 機器の ID をリスト表示できるプログラムを使い、ID をたしかめ、そのうえで Keyd の設定項目の [ids] に対象のデバイスを指定する。 yay -S lsplug lsplug # ... # USB 4-11.4.2 [046d:c52b] Logitech, Inc. Unifying Receiver # USB 4-11.4.3 [046d:c52b] Logitech, Inc. Unifying Receiver # USB 4-11.4.4 [046d:c548] Logitech, Inc. Logi Bolt Receiver # ... [ids] 046d:c548 ; 除外する場合は "-"を先頭につける -046d:c52b [main] capslock = escape ...

この記事を作った動機 単に Git で間違ったリモートを設定してしまったときの修正方法の記録をする。 やり方 # 必要に応じて変更したリモートリポジトリにあるブランチ名を確認すること # リモート先に origin と指定した場合自動選択される。 git branch -a # * main # remotes/origin/main # Remote URL を間違える例 git remote add origin https://url.to.repo/userName/Receipt-OCR-to-CSV-with-PDF.git git remote -v # origin https://url.to.repo/userName/Receipt-OCR-to-CSV-with-PDF.git (fetch) # origin https://url.to.repo/userName/Receipt-OCR-to-CSV-with-PDF.git (push) # 正しい Remote URL に設定する例 git remote set-url origin gitea@192.168.1.9:userName/Receipt-OCR-to-CSV-with-PDF.git git remote -v # origin gitea@192.168.x.x:userName/Receipt-OCR-to-CSV-with-PDF.git (fetch) # rigin gitea@192.168.x.x:userName/Receipt-OCR-to-CSV-with-PDF.git (push) 参考にしたサイトとか Google Gemini https://gemini.google.com/app (2026年4月19日) Git - git-remote Documentation https://git-scm.com/docs/git-remote#Documentation/git-remote.txt-add (2026年4月19日) Git - git-remote Documentation https://git-scm.com/docs/git-remote#Documentation/git-remote.txt-set-url (2026年4月19日) Git - user-manual Documentation https://git-scm.com/docs/user-manual#managing-branches (2026年4月19日) Git - git-remote Documentation https://git-scm.com/docs/git-remote#Documentation/git-remote.txt-set-head (2026年4月19日) Git - git-branch Documentation https://git-scm.com/docs/git-branch#Documentation/git-branch.txt--a (2026年4月19日)

記録 簡潔さのために、最初に結論を持ってくることにする。 効果があったこと 効果があったことは、gnome-remote-desktop を 50.0-1 から 49.0-1 にダウングレードすることである。安全のために自動でアップグレードされないよう/etc/pacman.confにおいて、ignorePkg の項目にgnome-remote-desktopやGDMを設定しておくことが推奨される。 試して失敗したこと、微妙だったこと Nvidia のドライバの以下のバージョンを試す 580 580 のちょっと古いバージョン 575 (カーネルバージョンを下げる必要がある。) 550 異なるデスクトップ環境(KDE)を使う Google Gemini Fast 3 に症状を具体的に投げて、提案される環境変数を試す。 Google 検索で gnome-remote-desktop や PipeWire などが吐き出すエラーについて、コピペして調べてフォームラムなどにあたってみる。 egl-gbm、egl-wayland、egl-wayland2 の 3 つのうち、egl-gbmとegl-wayland を /usr/share/egl/egl_external_platform.d/ gnome-remote-desktop 別の手段として VNC サーバである wayvnc を試してみたが、GNOME ではそもそも動作不能であった。 CUDA のバージョンを Arch Linux - cuda 13.2.1-1 (x86_64) から AUR (en) - cuda12.0 に下げた。 この記事を作った動機や経緯 最近 GNOME を動かしている GTX1080Ti を搭載するサーバ環境において、 Virt-Manager 経由で仮想マシンを立ち上げようとしたところ、部分的に更新をした影響でシステムが中途半端な状態になり、起動できないことがあった。そこでいつもどうり、すべてのパッケージを yay コマンドより更新して再起動をかけたところ異変が起こった。 具体的には、GNOME デスクトップ環境で RDP 接続時において画面が真っ白になる症状が起こった。GPU が接続されている物理ディスプレイには正しく画面が表示されているが、RDPからは内容が全く見えず、Remmina においては真っ白でマウスやキーボード入力は動作する状態で、Windows 11 25H2 の Win32 の方の伝統的な RDP クライアントでは真っ黒になってしばらくして切断されてしまうという挙動になった。結論としては、gnome-remote-desktopパッケージが新しすぎる場合、PipeWire を正しく初期化できず、pw-topなどで確認すると、音声だけ転送され画面は一切転送されていないことが分かった。 ...

この記事を作った動機 GNOME デスクトップ環境などにおいて特定のスクリプトを実行するなど、定型処理を気軽に行うために、ショートカット(デスクトップエントリ)を作成したいということがあった。しかし、.desktopという拡張子を持つファイルを所定の場所に作れば、ショートカットができることがわかっていたものの、その内容がめんどくさくて、放置していたことがあった。 そこで今回はExample Desktop Entry File | Desktop Entry Specificationの.desktopエントリの例を参考に、最低限私が使いたいように加工した物をテンプレートとして記録しておくことにした。 事前情報 [userName]と書かれている部分は、適宜存在するユーザのホームディレクトリ名などに書き換える。 設定内容 .desktopの内容 スクリプトを実行する場合には、Terminal=trueを指定すること、実行権限を付与すること(“chmod +x [対象のスクリプトやバイナリ]")やインタプリンタなどを指定するシバンが先頭に必要である。(例:”#!/bin/bash","#!/bin/python") [Desktop Entry] Version=1.0 Type=Application Name=A sample sortcut Comment=This is a sample desktop entry text. Terminal=true Exec=/path/to/script.sh Icon=[icons フォルダ直下に配置した画像名か、画像までのファイル名を含めた絶対パス 拡張子も書く] .desktopのファイルの配置場所 特定のユーザだけ /home/[userName]/.local/share/applications 全体に反映 /usr/share/applications アイコン画像の配置場所と利用方法 icons フォルダに直接画像を配置する場合は、デスクトップエントリの記述においてIcon=[拡張子を含めたファイル名]で通り、すべてのパスを書く必要はない。階層構造を作るには、Icon Theme Specification に従って厳密にインデックスなどをテキストで指定する必要があり手間がかかるので今回は省略する。それ以外の場所に配置する場合は、デスクトップエントリの記述においてIcon=[画像のファイル名を含めた絶対パス]とする必要がある。 特定のユーザだけ /home/[userName]/.local/share/icons 全体に反映 /usr/share/icons 例 例として、ゆっくり霊夢をアイコンとしたecho "ゆっくりしていってね!"を実行するスクリプトへのショートカットの作成について、以下に示す。 .desktopファイル 配置場所 /home/[userName]/.local/share/applications/yukkuri.desktop 内容 [Desktop Entry] Version=1.0 Type=Application Name=Yukkuri say something meaningless Comment=Yukkuri will say something meaningless. Terminal=true Exec=/home/[userName]/script/yukkuri/say.sh Icon=/home/[userName]/.local/share/icons/yukkuri/reimu/normal.png スクリプト 配置場所 /home/[userName]/script/yukkuri/say.sh 内容 #!/bin/bash echo "ゆっくりしていってね!" 画像 配置場所 /home/[userName]/.local/share/icons/yukkuri/reimu/normal.png ゆっくり霊夢の画像 (normal.png) 動作例 期待したとおりに動作している例 ...

この記事を作った動機 最近 Blender に Flamenco を導入して分散コンピューティング？を試す において、SMB ではなく SSHFSを使う必要があることがわかったので、SSHFS を試そうとしたところ、躓いたため記録を取る。 私の環境では、元々 SMB を使ってファイル共有を導入し、それを VPN 経由で利用していたが、それは普段の利用であってもファイルが大量にあるディレクトリを高遅延なネットワーク環境で開いたりすると1分ほど待たされたりするなど、明確に動作が遅いところがあった。そしてその挙動が、Blender の Flamenco の利用において顕著になり、限界が見受けられたため、SFTPを使った方法に移行するということがあった。 Blender の Flamenco において問題が起きる前までは、SMB 以外にすでに SFTP を使っていたが、それは Gnome Shell 内臓のファイラーで使っていたが、そちらでは、sftp://の URL から始まるパスで Gnome が勝手に独自でマウントしたフォルダーにアクセスするようになっている。SMB のときのように、マウントポイント用のフォルダを作成して、そこにネットワークドライブをマウントするという形態は取っていなかったため、問題になった。 そこで、SMB のように SFTP をマウントできる方法について、Google Gemini Fast 3に投げてみたところ、一つの提案として SSHFS を使う案が出てきたため試した。試したところ、コマンドラインにおいて、sshfsコマンドを使って、特定のフォルダに特定の SSH 接続先のフォルダをマウントするというような動作はできた。しかし、それを Systemd において自動化する際において、問題が起きた。 問題としては、私が Systemd に専用に備わっている方法や、/etc/fstab に明記する方法ではなく、起動後に自分で書いた専用の管理 Python スクリプトを Systemd で動かし、VPN と ネットワークドライブの管理を自分で自動的に行う方法を取っていたことによってその処理内容がsshfsコマンドの特性上適切でないことで起こった。SMB の時点では、/etc/fstab に書くことでネットワークドライブをマウントする方法もやっていたことがあった。しかし、それだと起動時やシャットダウン時において、ネットワークドライブにアクセスできなかった場合に、OS ごと巻き込んで、起動が途中で止まったりシャットダウンが途中で止まったりするなど、課題になったため、自分で手動で Systemd サービスやスクリプトを書いて起動して Gnome Shell にログインしてから具体的な処理が自動で走るように書いていた。その仕様が今回 SSHFS を導入するにあたって問題となった。 SSHFS - ArchWiki などに書いてあるように、専用の Systemd の automount を使ったりする方法もあるようであるが、私としては、ネットワークドライブは VPN の接続状況に応じて一緒に管理したいということがあった。SMB を使っていたときと同じように、SSHFS も自分でマウントするスクリプトを書いて、それを Systemd 経由でスクリプトとして実行し、専用の Python 管理スクリプトからは、systemd の自分で用意したネットワークドライブに関するサービスを叩くだけにしたいということがあった。 ...

この記事を作った動機 以下の Blender と Nvidia ドライバや CUDA の構成だと、CUDA のコンパイルに失敗して Cycles レンダリングにおける GPU 演算が正しく行われない結果になることがわかった。 yay -Qs nvidia # local/cuda 13.1.1-1 (2.2 GiB 4.7 GiB) # NVIDIA's GPU programming toolkit # local/egl-gbm 1.1.3-1 # The GBM EGL external platform library # local/egl-wayland 4:1.1.21-1 # EGLStream-based Wayland external platform # local/egl-wayland2 1.0.1-1 # EGLStream-based Wayland external platform (2) # local/egl-x11 1.0.5-1 # NVIDIA XLib and XCB EGL Platform Library # local/ffnvcodec-headers 13.0.19.0-1 # FFmpeg version of headers required to interface with Nvidias codec APIs # local/lib32-opencl-nvidia 590.48.01-1 # OpenCL implemention for NVIDIA (32-bit) # local/libnvidia-container 1.19.0-1 # NVIDIA container runtime library # local/libva-nvidia-driver 0.0.16-1 # VA-API implementation that uses NVDEC as a backend # local/libvdpau 1.5-4 # Nvidia VDPAU library # local/libxnvctrl 590.48.01-1 # NVIDIA NV-CONTROL X extension # local/linux-firmware-nvidia 20260309-1 # Firmware files for Linux - Firmware for NVIDIA GPUs and SoCs # local/nvidia-580xx-dkms 580.142-1 # NVIDIA kernel modules - module sources (580xx) # local/nvidia-580xx-utils 580.142-1 # NVIDIA drivers utilities (580xx) # local/nvidia-container-toolkit 1.19.0-1 # NVIDIA container toolkit # local/nvidia-prime 1.0-5 # NVIDIA Prime Render Offload configuration and utilities # local/nvidia-settings 590.48.01-1 # Tool for configuring the NVIDIA graphics driver # local/opencl-nvidia 590.48.01-4 # OpenCL implemention for NVIDIA yay -Qs blender # local/blender 17:5.0.1-9 # A fully integrated 3D graphics creation suite # local/blender-4.2-bin 4.2.260319.12a2dfa84963-1 # A fully integrated 3D graphics creation suite # local/blender-4.2-bin-debug 4.2.260319.12a2dfa84963-1 # Detached debugging symbols for blender-4.2-bin また、AUR にある CUDAの以下のバージョンを試したが、どれも正しく動かなかったし、現時点(2026/3/22)ではまだ動かす方法は見つかっていない。 ...

このページは、まだ未完成です。。。 nicotalk＆キャラ素材配布所 http://www.nicotalk.com/charasozai_kt.html （2024年5月16日） この記事を作った動機 最近 Gemini Fast 3 を使っていると、Blender において分散コンピューティングみたいなレンダリングの仕方ができることが分かり、気になった。それで、最初は Gemini Fast 3 が提案してきて、Blender - ArchWiki にも掲載されている、BlendNetを試そうと思った。 しかし、BlendNet のリポジトリを見てみると、実際のところは Blender 2.x.x の古い Blender にしか対応してなさそうな感じであった。私が使っている Blender のバージョンは 5.x.x 以降であったことから、別の物がないか Gemini Fast 3 に提案させてみると、Blender 公式の Flamenco が出てきたため試した。 そして、とりあえず動くようになるところまで、設定して確かめることができたため、そのことについて記録したい。まだ完全ではなく、途中でレンダリングに失敗したりと、成果物を得られている状態ではない。現状では Flamenco Manager と Flamenco Worker が実際に疎通を取り、Manager 側のクライアントの Blender からジョブを投げると、Worker 側がレンダリングを開始し負荷がかかるところまで確認した。 細かい説明(序章) 全体的な Flamenco 運用イメージ 以下に構築する環境のイメージを示す。今回はファイル共有サーバと Worker となる PC は物理的に1つに全部がまとまっている事を想定しているが、以下の画像ではわかりやすさのために、ファイル共有サーバやレンダリングを行う Worker farm の PC は物理的に分けている前提で表現している。 前提について 以下の点については、すでに設定されているものまたは前提として取り扱う。 Manager 側と Worker 側の間の設定 LAN で物理的に同じネットワークに繋がっているか、VPNによって実質的に同じネットワークに繋がっている。 SSH の設定が済ませてあり、LAN で物理的に同じネットワークに繋がっているときに疎通が取れる。 ping によって物理的に同じネットワークに繋がっているときに疎通が取れる。 Worker 側は GNOME RDP の設定が済ませてあり、Remmina クライアントにより LAN で物理的に同じネットワークに繋がっているときに疎通が取れる。 SFTP によるファイル共有が可能な状態になっている。 どちらも Linux 環境がセットアップされてあり、インターネットへの接続が確認できている。 firewalld をファイアウォールとして使っている。 VPN での接続がある場合について SMB ではなく SFTP によってファイルのやり取りを行う。 MTU サイズが十分小さく設定されており、ネットワーク障害が発生しないように設定されている。(MTUサイズ1000にするなど) 高遅延を前提とする。 Manager 側の視点から設定作業などを行い、Flamenco Manager と Blender を立ち上げた状態で作業する。 Manager 側と Worker 側は VPN によって遠隔地で通信を行う。 単語の解釈 Worker Flamenco において実際にレンダリング処理をする端末を、Flamenco公式ドキュメントなどを見た結果、Workerと呼ぶと私は現時点(2026/3/22)では解釈している。 ...