刈払機

自宅の庭の雑草をとるのに「草刈鎌」を使ってきました。手間がかかりますが、なんとかなりました。大変なのはもちろんですが、刈り終わったところが綺麗になっているのを見るのは、爽快です。

 

何年か前から、近所には町内会がボランティアで掃除している公園があり、そこの草刈りを将来的には手伝って貰えるとありがたいと言われるようになりました。そうなると手作業では大変ですから、刈払機が必要です。刈払機があれば、自宅の庭でも使えるので、検討に検討を重ねて、先月HiKOKIのCG18DAを購入しました。本体にはチップカッターが付属していましたが、自宅の庭で使うにはナイロンカッターの方が良さそうです。HiKOKIの別売り製品は高額なので、ホームセンターで安価なものを購入しました。また、充電器などの付属品を収納するため、これもホームセンターで手ごろな工具箱を購入しました。

 

準備万端整えて、自宅の庭で初めて刈払機を使ってみました。ナイロンカッターなので、土埃が飛びますが、あっという間に雑草が無くなっていくのは驚きです。また塀際などの雑草も刈れるので、とても助かります。バッテリは30分くらいしか持ちませんでした。

 

刈払機の威力に驚きましたが、地面の上にある雑草を刈り取っているだけです。これまで手作業でやっていたときは、地中の根も取り除いていたので、同じことが刈払機で出来るわけではありません。今後は、刈払機と手作業を併用していくことになると思います。

Let's note CF-SV8RCCVSにNetBSD/amd64 11.0をインストールしたが、無線LANが使えない

Let's note CF-SV8RDCVSにFreeBSD/amd64 15.1-RELEASEをインストールし、アプリケーションを入れたり、デバイスを使えるようにしたり、いろいろと調査してきました。なかなか悪くないと思いますが、他のBSDも試してみて、最終的に何を使うか決めようと思います。そういうことで、今度はNetBSD/amd64 11.0をインストールしました。

 

インストールそのものは、普通です。NetBSDのインストーラは、地味で、Ubuntuなどに比べると不親切と評されることもあります。そういう印象はありますが、インストール自体は、問題なく終わりました。

 

無線LANを設定しようと思い、「ifconfig -a」 してみると、デバイスが出てきません。Geminiに救いを求め、「pcictl pci0 list」したところ、「000:20:3: Intel Dual Band Wireless AC 9560 (miscellaneous network, revision 0x11)」と認識されています。ところがマニュアル「IWM(4)」では「The iwm driver provides support for Intel Wireless 3160, 3165, 3168, 4165, 7260, 7265, 8260, and 8265 PCIe Mini Card Ual Band newtork adapters.」と書かれており、未対応のようです。

 

Let's note CF-SV8は、2019年頃に登場したマシンですから、それほど最新機種ということもありません。FreeBSD/amd64では無線LANが使えていましたから、故障しているわけではありません。NetBSDのポリシーとして、綺麗に設計しようとしていて、対応が遅れているのでしょう。いつかは対応されると思いますが、今は使えないのは確かです。

 

NetBSDは諦めることにします。次はOpenBSDを試そうと思います。 

Let's note CF-SV8RDCVSのFreeBSD/amd64 15.1-RELEASEの内蔵カメラ

Let's note CF-SV8RDCVSにFreeBSD/amd64 15.1-RELEASEをインストールしました。このマシンには内蔵カメラがついています。これまで所有してきたデスクトップPCやノートPCで内蔵カメラがあるのは初めてです。当面使う予定はありませんが、ちょっと試してみました。

 

設定手順は難しくありません。

1. 「pkg install webcamd」でwebcamdをインストールします。
2. 本来なら「sysrc webcamd_enable="YES"」しておいて、「service webcamd start」すべきなのですが、一時的なテスト目的ですので、以下の手順で直接起動しました。
3. 「kldload cuse」しておいて、「webcamd -d ugen0.2 -B」として起動します。ここで「ugen0.2」は内蔵カメラのデバイス番号です。ここで「/dev/video0」などのデバイスが出来ていることを確認します。
4. 内蔵カメラを使うユーザは「pw groupmod webcamd -m ユーザ名」としてグループ「webcamd」を加えておく必要があります。

これで設定できたので、内蔵カメラを使ってみます。

1. 「v4l2-ctl -d /dev/video0 --list-ctrls」や「v4l2-ctl -d /dev/video0 --list-formats-ext」で内蔵カメラの情報を取得してみます。
2. 実際のアプリケーションで内蔵カメラを使ってみます。今回は「ffmpeg -f v4l2 -input_format mjpeg -video_size 1280x720 -ss 2 -i /dev/video0 -vframes 1 test.jpg」として、静止画をファイルに落としてみました。

 

以上で、動作は確認できました。当面利用することはないのですが、何かの折に役立つのではないかと思います。

Let's note CF-SV8RDCVSのFreeBSD/amd64 15.1-RELEASEでBluetooth

Let's note CF-SV8RDCVSにFreeBSD/amd64 15.1-RELEASEをインストールしました。このマシンにはBluetoothがあります。Bluetoothを積極的に使ってみたいという訳ではないのですが、どんな風に使うのか気になったので、設定してみました。

 

設定手順は難しくありません。

1. 「pkg install iwmbt-firmware」でファームウェアパッケージをインストールします。
2. 「usbconfig | grep -i bluetooth」でデバイスの番号を確認しておきます。
3. 「iwmbtfw -d ugen0.3 -f /usr/local/share/iwmbt-firmware」でファームウェアを転送します。ここでは「ugen0.3」が前項で確認したデバイス番号です。

 

これで設定できたので、Bluetoothを使ってみます。

1. 「hccontrol -n ubt0hci Read_BD_ADDR」でBluetooth MACアドレスを読み取ってみます。
2. 「hccontrol -n ubt0hci Inquiry」で周辺にある機器が反応するか確認してみます。

 

Bluetoothに対応した機器はスマホくらいしか所有していません。「Inquiry」で検出できたのは確認しました。しかしBluetoothを使って、何かをしようという気にはならなかったので、確認はここまでとしました。 

KB5124008の影響で「ファイル履歴が外付けドライブを認識しない」という問題が発生しているらしい

記事「Windows 11の大型アップデートKB5124008で深刻な不具合続出…「更新を遅らせるな」の直後に混乱発生」によると、「ファイル履歴(File History)がバックアップ用ドライブを認識しないという報告が多数上がって」いるそうです。私が「ファイル履歴」が動かなくなったのも、これが原因なのかもしれません。

 

マイクロソフトは「ファイル履歴」を重視していないように見受けられます。推測となりますが「OneDrive」を推しているのでしょう。

 

もしかすると、この問題が解決するパッチが出るかもしれません。しかし私自身は、「ファイル履歴」からFreeFileSyncに移行するつもりです。 

FreeFileSyncにおける「比較」の挙動

Windows11では「ファイル履歴」の動作が怪しいので、FreeFileSyncを使用して同等機能を実現しようと思います。ちょっと試したら、ほぼ期待したようになったのですが、こちらはこちらで動作が怪しいです。

 

同期元はWindows11で、同期先はFreeBSD上のSambaです。初回は同期対象ファイルを全てコピーします。これは想定しているとおりです。問題は、2回目以降の同期対象ファイルが多すぎることです。ログを残す設定にしているので、どのファイルがコピーされたのかは把握できます。しかし、全く変更していないファイルが同期対象ファイルとして選ばれています。これは、FreeFileSyncにおける「比較」処理の問題です。

 

FreeFileSyncでは、同期元と同期先のファイルを「比較」し、同期対象ファイルを選択します。この「比較」では、「変更日時とファイルサイズ」、「ファイル内容」、「ファイルサイズのみ」という手段が提供されています。よく利用されるのは「変更日時とファイルサイズ」のようです。

 

FreeFileSyncには、デバッグ用ログというものが存在しないので、挙動を観察して状況を推測するしかありません。同期対象として選択されるファイルについて、Windows11側とSamba側のタイムスタンプの精度が関係している気がします。Windows11側では秒以下の時間も記録しているようですが、Samba側では記録していないようなので、「比較」すると「差異がある」という判断になってしまうようなのです。

 

それでは「比較」を「ファイルサイズのみ」でおこなうことにしたら、うまくいくのではないかと思い、試してみました。ところが相変わらず、全く変更していないファイルが同期対象ファイルとして選択されてしまいます。「比較」には「ファイル内容」という手法もありますが、ファイルの内容を読むのは処理時間が相当長くなる恐れがあるので、試してみるのは避けようと思います。 

 

2回目以降の同期で誤って同期対象ファイルを選択していると思われるのは、全ファイルの1%弱なので、スッキリと納得はできませんが、このまま利用を続けてみようと思います。 

Windows11の「ファイル履歴」は非推奨なのか

自宅で使用しているデスクトップPCは、Windows8からWindows10に移行し、昨年にはWindows11を使っています。Windows10の頃から「ファイル履歴」を使用してきました。普段のオペレーションで、うっかりファイルを削除してしまったり、上書きしてしまったことがあり、その場合に救出するのに役立ちました。

Windows11になってから、「ファイル履歴」の動作がWindos10の頃とは違う気がしていましたが、動作はしていました。しかし数日前に動作が止まり、再実行させようとしても、「ファイル履歴のドライブに再接続してバックアップを実行するまでの間、ファイルは一時的にハードドライブにコピーされます。」というエラーがでてしまいます。解決を試みましたが、動作するようになりません。

 

Geminiに相談すると、Windows11では「ファイル履歴」を非推奨にしようとしている傾向がみられるとのことでした。そうであれば、もう「ファイル履歴」を使い続けるのは諦め、何か別の手段に移行しようと思います。FreeFileSyncというものがあるそうなので、使ってみようと思います。