ネットワーク経由ではなく、ローカルのハードディスクドライブ間で多数・大容量のファイルをバックアップしたい場合にも、私はrsyncを使っている。
途中経過を表示してくれるし、途中で止まってしまった場合にもリカバリーが簡単だろうという意図である。
幸運にも途中で止まったことはないのだが、2回目以降は-u
オプションを付ければ良いはずと考えている。
$ rsync -av /share/a/data/ /share/c/data/
ネットワーク経由ではなく、ローカルのハードディスクドライブ間で多数・大容量のファイルをバックアップしたい場合にも、私はrsyncを使っている。
途中経過を表示してくれるし、途中で止まってしまった場合にもリカバリーが簡単だろうという意図である。
幸運にも途中で止まったことはないのだが、2回目以降は-u
オプションを付ければ良いはずと考えている。
$ rsync -av /share/a/data/ /share/c/data/
しばらく電源を入れていなかったAmazon Fire TV Stick (第1世代)があるのだが、後々面倒になるといけないのでOSのバージョンアップを しておくことにした。気付いたことを書いておきたい。
Fire TVのソフトウェアをアップデートするに あるように、設定→My Fire TV→バージョン情報→アップデートを確認の順で選択すれば、OSアップデートすることができる。
しかし、複数バージョンのアップデートがある場合、一気に最新のバージョンにアップデートすることはできず、1世代ずつ順々に適用していくこととなる。
Fire TV端末およびアクセサリのソフトウェアアップデートlに 記載のあるようなバージョンが各Fire TVデバイスの最新のOSのバージョンである。 しかし、2021-01-02現在、私の持っているAmazon Fire TV STick第1世代と第2世代は、いずれもFire OS 5.2.7.7ではなく5.2.7.6までしかアップデートできなかった。 新しいバージョンを見つけられないようだった。
これは、NetBSD Advent Calendar 2020の20日目の記事です。
標準のpkgsrc/www/firefoxをNetBSDで使うときは、標準ではSun audio backendを使うことになります。 ですが、私はpkgsrc/audio/pulseaudioを使っています。 その場合には、複数のオーディオデバイスを簡単に選べるようにしました。 pulseaudio-13.0nb9以降を使ってください。 ちなみに、WebRTCのオーディオ入力デバイスの切り替えにも便利です。 ただし、Bluetooth A2DP再生の場合には対応できていません(pad(4)は認識させていないため)。
複数のオーディオデバイスがある場合とはどのような場合かと言うと、例えばUSBオーディオデバイスが存在する場合です。 私の場合には、USB接続のヘッドセットを接続すると2つ目のオーディオデバイスが発生します。
PulseAudioを使うには、以下のようにpkgsrc/www/firefoxをビルドすると良いでしょう。
# cd /usr/pkgsrc/www/firefox-l10n # make PKG_OPTIONS.firefox=pulseaudio install
ちなみに、少なくとも最近のpkgsrc/www/firefoxでは、英語(en_US)ロケールであってもpkgsrc/www/firefox-l10nをインストールしておくことをお勧めします。
これは、Firefoxではなく、PulseAudioの方で設定します。
pkgsrc/audio/pulseaudioに含まれているpactl
コマンドを使い、以下のようにすると良いでしょう。
私のローカルpkgsrcツリーでは、pkgsrc/audio/pulseaudioは14.0になっているので、module.versionは14.0になっています。
ここでは、/dev/audio0とそれへのシンボリックリンクである/dev/audio、/dev/audio1の2系統が存在していることが分かります。
$ pactl list (snip) Module #6 Name: module-oss Argument: mmap=0 device=/dev/audio Usage counter: n/a Properties: module.author = "Lennart Poettering" module.description = "OSS Sink/Source" module.version = "14.0" Module #7 Name: module-oss Argument: mmap=0 device=/dev/audio0 Usage counter: n/a Properties: module.author = "Lennart Poettering" module.description = "OSS Sink/Source" module.version = "14.0" Module #8 Name: module-oss Argument: mmap=0 device=/dev/audio1 Usage counter: n/a Properties: module.author = "Lennart Poettering" module.description = "OSS Sink/Source" module.version = "14.0" (snip)
それでは、/dev/audio1で再生するように切り替えてみましょう。以下のように実行します。
$ pactl set-default-sink oss_output.audio1
これで、USB接続ヘッドセットの方から音が出るようになりました。
FirefoxのWebRTCのオーディオ入力デバイスは、WebRTCがオーディオ入力を要求する場合の選択肢が複数になるので、そこで選択できるようになります。 /dev/audio1を選択する場合のポップアップの例を下図に示します。
これで、Firefox関連で自由にオーディオ入出力を設定できると思います。
これは、NetBSD Advent Calendar 2020の22日目の記事です。
いつもOpenStreetMapにはお世話にあっていますが、最近はなかなか貢献できていません。 ですが、自宅の近所の道が間違っているのは気になっていました。 今回は、NetBSD環境からOpenStreetMapの地図を修正してみました。 もちろん、ウェブブラウザー上でiDで修正できるのは把握していますが、今回はpkgsrc/geography/merkaartorを使ってみました。
pkgsrc/geography/merkaartorは、pkgsrc/x11/qt5-qtwebkitなど大きめのパッケージに依存しており、 一からビルドするには重量級のパッケージです。 ふじわらさんの14日目の記事を参考に、 バイナリーパッケージを使った方が良いかもしれません。
以下では、私の好みで全てソースコードからビルドする方法を示しておきます。
# cd /usr/pkgsrc/geography/merkaartor # make install
目的の場所をMerkaartorで開くには、www.openstreetmap.orgで目的の場所を開いて、そのURLをDownload時に指定すると簡単なようです。 下図では、東京の秋葉原駅付近の部分 https://www.openstreetmap.org/#map=18/35.69935/139.77226 を指定する画面です。
不足している歩行者専用の通路を追加してみました。 しばらく修正していないので、思い出すのには時間がかかりましたが、問題なく追加し、www.openstreetmap.orgにアップロードできました。
これは、NetBSD Advent Calendar 2020の16日目の記事です。
IoT関係でのローコードプラットフォームとしてNode-REDというのがあります。 我が家にはIoTデバイスはないのですが、ウェブブラウザーでプログラミングできるというのは、いつでも面白いコンセプトです。 うまく行った例を私は知りませんが…。 今回はNetBSDでNode-REDを使ってみました。
Node-REDは、Node.jsで書かれたプラットフォームです。 pkgsrcはNode.jsのパッケージを扱う定番のやり方を確立できていないので、pkgsrcのパッケージにはなっていません。 Node.jsとnpmはpkgsrcパッケージになっています。 以下のようにインストールして行きましょう。
# cd /usr/pkgsrc/lang/nodejs # make install # cd /usr/pkgsrc/lang/npm # make install
ここまでで、Node.jsとnpmはインストールできました。 次にNode-REDをインストールします。
$ mkdir ~/nodered $ cd ~/nodered $ npm install --unsafe-perm node-red
これで、Node-REDをインストールできました。 次に起動させてみましょう。
$ cd ~/nodered $ ./node_modules/.bin/node-red
ローカルホストのFirefoxで、http://localhost:1880/ を開くと、Node-REDの画面を開くことができます。 これは、http://localhost:1880/testにGETを発行すると、ステータスコード201を返すプログラムになっています。 Deployボタンを押して、実行してみましょう 。
$ telnet localhost 1880 Trying ::1... telnet: Connect to address ::1: : Connection refused Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. GET /test HTTP/1.1 201 Created X-Powered-By: Express Access-Control-Allow-Origin: * X-Content-Type-Options: nosniff Content-Type: application/json; charset=utf-8 Content-Length: 2 ETag: W/"2-vyGp6PvFo4RvsFtPoIWeCReyIC8" Date: Wed, 23 Dec 2020 10:48:59 GMT Connection: close {}Connection closed by foreign host.
Node-REDの一部の機能しか試していませんが、NetBSDでもNode-REDを実行し開発することは可能なようです。
これは、NetBSD Advent Calendar 2020の21日目の記事です。
Androidスマートフォンで、USB接続するとumidi(4)として認識される機能のあるものがあります。 これはどういう動作をするのか気になっていました。 今回は、この機能がMIDI入力とMIDI出力の両方として利用できるものだと分かったので、NetBSDから使ってみたいと思います。
今回使ったAndroidスマートフォンは、Sony Xperia XZというAndroid 8の搭載された端末です。 普段は、自宅内のAsteriskの内線子機として使っている端末です。 これをUSBケーブルで、NetBSD端末につなげると、MIDIデバイスになるための接続を選択する画面が表示されます。 MIDIデバイスになる項目を選択しましょう。
どうやら、Androidスマートフォン単体ではMIDIデバイスにはなれないようです。 今回は、MIDIインプット機器とMIDIアウトプット機器のいずれにもなれる Dreamhound Studios製のMIDI Keyboardというアプリを 利用することにします。
このMIDI Keyboardアプリを起動させると、画面左上にMIDIメニューが表示されています。そこではInpiutとOutputについて、それぞれ指定できます。 標準ではいずれも(none)になっています。つまり、NetBSDとMIDI通信をすることができません。 これをいずれも「Android USB周辺機器ポート」に切り替えておきます。
NetBSDには、midiplay(1)とmidirecord(1)というコマンドが標準で用意されており、それぞれMIDIファイルの再生、MIDIファイルへの録音ができます。 まずは、当該部分のdmesgを確認してみましょう。umidi1として認識されていることが分かりました。
umidi0 at uhub5 port 1 configuration 1 interface 1 umidi0: Sony (0x0fce) F8332 (0xc1e7), rev 2.00/3.18, addr 10 umidi0: (genuine USB-MIDI) umidi0: out=1, in=1 midi1 at umidi0: <0 >0 on umidi0
以下のように実行した上で、MIDI Keyboardアプリの表示するキーボードで演奏してみます。
-d 1
で、midi1を使うことを指定しています。
$ midirecord -d 1 test.mid
こうやって録音した演奏を以下のように再生してみます。
-d 1
はmidirecordの場合と同様な意味です。
$ midiplay -d 1 test.mid
今回は、ピアノ音のみを扱うアプリでしたが、他の音源を扱えるアプリがあるかもしれませんので、探して試してみたいと思います。
これは、NetBSD Advent Calendar 2020の19日目の記事です。
2018年にBitVisorをNetBSD上でビルドし、その上でNetBSD/amd64-currentを動かす話を 書いていました。 最新版のBitVisorがNetBSDでビルドできるか、NetBSDが動くか確認してみました。
最新のBitVisorのソースコードは、sourceforge.netにあります。 hgを使っていて、BitBucketがhgサポートを終了してしまったので、sourceforge.netに移行されたようです。 以下のようにソースコードを入手します。
$ hg clone http://hg.code.sf.net/p/bitvisor/code bitvisor-code
ビルドには、mingw-w64のツールチェインが必要です。pkgsrc/cross/mingw-w64-x86_64-gccを利用すれば良いでしょう。 以下のようにインストールしておきます。 GNU make (gmake)も必要ですので、インストールしておきます。
$ cd /usr/pkgsrc/cross/mingw-w64-x86_64-gcc $ make install $ cd /usr/pkgsrc/devel/gmake $ make install
/usr/pkg/cross/x86_64-w64-mingw32以下にx86_64のmingw-w64ツールチェインがインストールされます。
以下のように実行すれば、UEFIブートできるBitVisorがビルドできます。
$ cd bitvisor-code $ PATH=/usr/pkg/cross/x86_64-w64-mingw32/bin:$PATH gmake -C boot/uefi-loader
インストールはUSBスティックに行なうことにします。 以下のように実行すれば良いでしょう。
# gpt destroy sd0 # gpt create sd0 # gpt add -t efi -s 200m sd0 # newfs_msdos /dev/rdk5 # mount_msdos /dev/dk5 /mnt # mkdir -p /mnt/EFI/boot # cp bitvisor-code/boot/uefi-loader/bsdriver.efi /mnt/EFI/boot # cp bitvisor-code/boot/uefi-loader/loadvmm.efi /mnt/EFI/boot/bootx64.efi # umount /mnt
作成したUSBスティックをNetBSD/amd64をUEFIインストールしてあるPCに挿してUSBスティックから起動すれば、 無事にBitVisor上でNetBSD/amd64 9.99.77を起動させることができました。
ネットワーク経由ではなく、ローカルのハードディスクドライブ間で多数・大容量のファイルをバックアップしたい場合にも、私は rsync を使っている。 途中経過を表示してくれるし、途中で止まってしまった場合にもリカバリーが簡単だろうという意図である。 幸運にも途中で止ま...