Posts

なんとLameの新バージョン、4.0が出ています。この夏に出たみたい。バイナリをWindowsに入れようと思ったら、x86/x64の2つがありました。どちらが早いのでしょうか。 ダウンロード元には以下のように説明がありました。 x64 bundle compiled with LLVM/Clang 22.1.8 Compiler. win32 bundle compiled with Intel 19.0 and should work on XP, or later. Both bundles include the libmpg123_0.dll. でも良く分かりません。なので実際に試してみました。試す条件は以下の通り。 CPU: Intel Core Ultra 5 245 入力ファイル: 32bit float WAV 1.17GB オプション: -V0 のみ 試した結果は以下の通りでした。 版 速度(倍) x64 163.6 x86 113.3 x64の方がだいぶん早いという結果でした。新しめのCPUを使っていたらx64版を使わない理由はない、という感じなんでしょう。 ついでにノートPCでも試してみました。スペックの違いだけ書くと、 CPU: Intel Core i7-1355U 速度は以下の通りでした。 版 速度(倍) x64 145.8 x86 106.6 傾向は似たような感じですね。

まえがき WordPressで運用していたこのページですが、夏休みの自由研究ということで、この度Hugoを利用して再構築することにしました。 理由としては、 WordPressは重いから WordPressの更新が面倒だから あたりでしょうか。 Hugoで生成すると、全部のページが単なるHTMLになるので、重いという問題はなくなります。 また、WordPressの更新に悩まされることもなくなります。 一方で、 ページをビルドしないといけない ビルド結果をサイトにアップしないといけない といったあたりは手間が増えることになります。 移行概要 自分で管理しているVPSにWordPressを入れていたので、WordPressのプラグインではなく、データベース(MySQL)から直接データを取得して、全部の投稿を1つずつのファイルにすることにします。 また、URLについては、WordPressの設定により、 /archives/%post_id% となっており、これはそのまま活かすよう、記事IDをファイル名にすることにします。 記事数もそこそこあるので、記事は年ごとのディレクトリを作って、その中に入れるようにします。 今後作成する記事については記事ID=YYYYMMDDとすればいいのかな、例えば 2026/20260722.md みたいな感じに。 Copilotが書いてくれた移行ツールの仕様は以下のような感じ。 データ移行ツール仕様 方針 URLは維持する HTML本文は維持する 画像URLは維持する WordPressの記事IDをファイル名に利用する コメントは無視する 入力・出力 WordPress の MySQL データベースを直接参照する。 利用するテーブルは以下の通り。 wp_posts wp_terms wp_term_taxonomy wp_term_relationships 各記事は以下のファイルに出力する。 content/posts/YYYY/ID.md 例: content/posts/2025/799.md 投稿日の年ごとにディレクトリを分ける。 content/posts/ ├── 2004/ ├── 2005/ ├── ... ├── 2024/ ├── 2025/ └── 2026/ ファイル名には、WordPressの記事IDをそのまま利用する。 799.md 800.md 801.md 対象記事 以下の条件を満たす記事のみ変換対象とする。 post_type = 'post' post_status = 'publish' Front Matter 出力例: --- title: "Ubuntu24.04でSkinny.phpが警告を出すことへの対処" date: 2025-02-26 00:00:00 categories: - "コンピュータ" --- 対応表: ...

自宅で使っているSynologyのDS223jに、PlanexのUSB LANアダプタ(USB-LAN2500R2)を刺して、2.5GbEに対応させた。以下は必要情報へのリンク。 https://www.planex.co.jp/articles/lan/25gbe_no6/ https://github.com/bb-qq/r8152/releases Planexのサイトに書いてある通りにやればたぶんできると思うが、自分のためにメモしておくと、追加で入れたドライバは r8152-rtd1619b-2.20.1-1_7.2.spk である。これのインストールができれば、あとはUSBにアダプタを刺すだけだ。

Apache2+PHP(CGI)の話。 バーチャルホストで相乗りしてるWebサーバなので、PHPはCGIでsuexecして動かしているのだけど、WordPressベースのページは応答に500msかかったりして、あまり良くない感じ。そこでPHP-FPMの導入を検討することになった。 インストールは簡単でphp-fpmを入れたらよい。あとは要りそうなモジュールを有効にしておく。 sudo a2enmod actions fcgid alias proxy_fcgi 次に、プールの設定をする。ここではexample.comの設定をユーザexampleで実行しているものとする。 /etc/php/8.3/fpm/pool.dに、www.confというのがあるので、それをコピーしてexample.confというのを作り、以下のように修正する。 ; pool name ('www' here) [wwwexample] (snip) user=www-dataexample group=www-dataexample (snip) listen = /run/php/php8.3-fpm.sockphp8.3-fpm-example.sock これで修正終わり。php8.3-fpmを再起動する。 次に、Apache2のバーチャルホストの設定に以下を追加する。 <FilesMatch \.php$> SetHandler "proxy:unix:/run/php/php8.3-fpm-example.sock|fcgi://localhost" </FilesMatch> これで修正終わり。apache2を再起動する。 うまくいけばこれだけでPHPはPHP-FPMを使うようになる。冒頭に500msかかっていたと書いたが、同じページがPHP-FPM有効だと60msとかで表示できるようになり、文字通り桁が違う。

Ubuntu20.04(PHP 7.4.3)で動作してたSkinny.phpが、Ubuntu24.04(PHP 8.3.6)でワーニングを出すようになった。 Deprecated: strlen(): Passing null to parameter #1 ($string) of type string is deprecated in /../Skinny.php(1251) : eval()'d code on line 28 困りましたね。本来は非推奨なのを取り除くように修正するべきなんでしょうが、時間もないのでとりあえずこのメッセージを抑制してしまいます。1251行目をこんな感じにしちゃいます。 error_reporting(E_ALL & ~E_DEPRECATED); eval( "?>" . $code ); ひどいなと思うけど仕方ない。今後は別のテンプレートエンジン使うしかないだろうな。

さくらのVPSでUbuntu24.04のサーバを借りて標準の状態でたてたら、IPv6経由でログインできなかった。 色々調べては試して時間を無駄にした。 結論を書くと、「/etc/netplan/01-netcfg.yaml」の中のIPv6の設定がコメントアウトされている。このコメントを外して再起動をすれば、IPv6での通信ができるようになった。 なんで標準でIPv6通信をしないようになってるんだろう。ポリシーがあるのかな。まあいいや、動けば。

光回線が引き込んである1階と、PCがある2階の書斎の間は有線が引けないので、これまでWiFi6の無線LANルータでつないでました。最高で100Mbpsくらいしか速度が出ず、10Gbpsの回線を引いてるだけに、もったいないなと思ってました。 先日ついにTP-LinkのDeco BE65 Pro(リンク先はBE75)を2台購入して導入しました。1階と2階間のネックがずいぶん解消して、書斎のPCでもコンスタントに1Gbps-2Gbpsに迫る速度がでるようになりました。WiFi7すごい。 見た目はこんな感じでスッキリしています。 スピードを計測すると、こんな感じ。 Deco BE75なら10GbE対応で、アンテナも多いので速度がもう少し出そうですが、ペアで7万円オーバーはちょっと高い…のであきらめてBE65にしたという経緯があります。 ノートPCはWiFi6E対応なので、WiFi7のフルスピードではないですが、それでも1Gbpsくらい出るようになりました。これはずいぶん捗りそうな感じです。 いまのところ対外回線は10Gあっても使い切れてません。この感じだと2Gあれば十分なのではないかな。NUROでいいやという伏線かもしれません。 Deco BE65は専用アプリで悩むところもなく導入できて楽ちん、かと思いきや、いじってると設定を戻せなくなったり、色々バグっぽい感じがします。仕方なくハードウェアリセットボタンを押し、アプリは消して最初からやり直しました。2回目のセットアップでは標準状態からあまり変えないようにする感じに。そうすると快適に動いてます。 今のところ完成した製品という状態ではなく、ベータテスト中なのでは、という印象を持ちました。FWやアプリのアップには期待しましょう。 そういうわけで、あまり設定を変えていないのですが、「IoTネットワーク」という機能を有効にしてみました。2.4GHz帯に追加のSSIDを設定できるというやつです。これを今までのルーターと同じSSIDにしておけば、エアコンや冷蔵庫等の設定変更が面倒なものについて、一斉に移行できると考えたからです。もくろみ通り、これはうまくいき、それら機械の設定しなおしは発生せずに移行できました。

安いSDカードリーダーが3つあったので、それぞれベンチマークをとってみることにしました。ベンチマークは僕のデスクトップPCで、すべて同じSDカードを刺して実施しました。 1. バッファロー BSCR27U3BK バッファロー BSCR27U3BK 数年前に購入後、今もよく使っているリーダー。デスクトップPCだとType-Aなのが使いやすい。 2. バッファロー BSCR125U3CBK バッファロー BSCR125U3CBK 最近買ったバッファローのType-C用リーダー。Type-C専用だけど、サイズは小さくなる。今買うならこれでいいかも。 3. Anker USB-C 2-in-1 カードリーダー Anker USB-C 2-in-1 カードリーダー ともかく小さいリーダー。フィールドレコーダーのケースに入れる用に購入。レコーダーとPCを持っていきつつ、リーダーがなくて困ったことがあったので、それの予防用。 サイズの比較 3つのリーダーを並べると、Type-Aのリーダーの大きさや、ANKERの小さいリーダーの小ささが引き立ちます。 まとめ SDカードリーダーを使ってやることと言えば、動画、録音や写真の取り込みなので、やはりシーケンシャルリードが速い方が快適なはず。そういう目で見ると、バッファローの2つのリーダーがAnkerよりもちょっと速そうです。 バッファローのType-Cのリーダーは、ランダムリードとライトが少し遅いかもしれません。USBメモリ的に使うのでなければ、あまり気にする必要もないと思います。

一年ほど前に買って愛用しているトランセンドのSSDスティックESD310(Transcend TS1TESD310C)なのですが、大量のファイルを書き込むと、途中までは爆速なのに急に遅くなる、という現象が起こっておりました。 これは熱対策とかでわざとやってるのだろうと思っていましたが、やはり遅いとイライラするのでファームウェアの更新ができないかどうか探ってみました。 まず、公式に「SSD Scope」というツールがあり、SSDの各種情報を見ることができます。画面はこんな感じです。 ここにファームウェアのバージョンが表示されています。「W0807BMO」というバージョンになっていますが、これが遅いファームウェアでした。このバージョンの人は、ぜひファームウェアを更新したらよいです。超快適になりますよ。 更新するのは簡単で、「ESD Firmware Update Tool」というのをインストールして実行するだけ。画面からファームウェアの更新ができます。さくっとできたので画面イメージを取り損ねました。たぶん英語で警告が出たと思いますが、ファイルが全部消えることにご注意してください。更新後、前述のSSD Scopeでファームウェアのバージョンを確認すると「X0402BM0」となっています。 このバージョンに変えてから、最初に書いたようなスピードの低下は全然起こらなくなりました。とても快適になるので、この現象が起こっている方はぜひお試しください。

NASのディスク(8TB)があと1割ほどしか空いてないので、いろいろ整理してたりしてたけど、だるいので16TBへの換装をすることに決めた。選んだディスクは東芝のMN08ACA16Tというやつ。いま16TBのHDDは2本で9万円しないくらい。TBあたりの単価だと、そう割高ではない気もする。 SynologyのNAS箱(DS223j)で標準の冗長化をしてる(RAID1相当)ので、ディスクを1本新しいのにしてリビルドを走らせる。リビルドの所要時間は12時間ほど。2本とも新しいディスクをのせた2回目のリビルド時に、領域を拡張するか聞いてきた。気が利いてるねえ、ぜひ頼むわ。 みたいな感じで、NASを長期に止めることもなく、データをいったん外に移したりする必要もなく、きれいに移行できました。これで容量の問題で悩むことは当面なくなりそう。