web ページで「二重の取り消し線」を書きたい！

今回はちょっと趣きが違う投稿をしよう。

　今回のお題はタイトルにあるように，web ページ上の文章の一部に「二重取り消し線」をつけるやり方，である。

　二重ではない取り消し線は，以前なら

<s>...</s>

のように書いていた。 でも，最近は css を使うので，web ページのヘッダー部にスタイルを記載するか，

<span style="XXXX">....</span>

のように「span」として記載するか，になる（と思っている）。 ちなみに

<div style="XXXX">....</div>

だと前後に改行が入るので，文章の途中なら「span」の方がいいと思う。

　さて，本題の「二重取消線」だが，まず，取り消し線はスタイルとして，

<span style="text-decoration:line-through;">XXXX</span>

としてすると「取り消し線」が引かれる。
　◯ 取り消し線の例です

しかし，これはまだ二重になっていない。二重にするには，

<span style="text-decoration:line-through double;">XXXX</span>

とする。他のパターンも含めて例を示そう。
　◯ 二重取り消し線の例です：double
　◯ ダッシュ取り消し線の例です：dashed
　◯ 点線の取り消し線の例です：dotted
　◯ 波線の取り消し線の例です：wavy
　◯ 普通の取り消し線の例です：solid

さらに以下のようにすると色もつけられる。

<span style="text-decoration:line-through double red;">XXXX</span>

とする。「#XXXXXX」形式の色の指定もできるみたい。
　◯ 赤色の二重取り消し線の例です：double red
　◯ 青色の二重取り消し線の例です：double blue
　◯ 緑色の二重取り消し線の例です：double green
　◯ ピンク？の二重取り消し線の例です：double #FF2288
　◯ ピンク？の波線の取り消し線の例です：wavy #FF2288

お試しあれ

FreeBSD で「libssl.so.11」がないからアプリが実行できない，と言われた

　2023年10月15日に FreeBSD 上のアプリケーションのアップデートをしていたら，急に多くのアプリケーションが動かなくなった。 その顛末を書こう。

　きっかけは FreeBSD 上で portupgrade をしたことに始まる。このパターンは結構多い。 今回は，実はアップデート自体には全く問題はなかった。 しかし，その後，急に多くのアプリが動かなくなった。 吐き出すエラーは

ld-elf.so.1: /usr/local/lib/libssl.so.11: version XXXXXX required by YYYYYY not found

という感じのもの（ここで XXXXXX や YYYYYY はバージョンやこのライブラリを使ってるアプリやら別のライブラリやら）

これが1個や2個ならいいが，サーバーによってはルート権限で実行もできなくてほとほと困ってしまった。

ちょっと調べると，この「libssl.so.11」は「openssl-1.1.1w」でインストールされるものだった。 これは，FreeBSD では「/usr/ports/security/openssl111/」でインストールできる。 実は少し前までは「openssl」といえばこのバージョンだったが，ちょっと前にデフォルトバージョンが「3.0.x」に変わっていた。 そのため，openssl をアップデートした際に，v.1.1.1w から v.3.0.x に上がってしまい，ライブラリが libssl.so.12 になっていた。 結果として openssl-1.1.1w でインストールされた libssl.so.11 を使ってるアプリケーションソフトでエラーが起こったみたい。

そこで，どのアプリが libssl.so.11 を使っているかをチェックしてみた。 それには以下のようにする。

# pkg shlib -qR libssl.so.11
libevent-2.1.12
librtmp-2.4.20190330
rtmpdump-2.4.20190330
python27-2.7.18_2
p5-Net-SSLeay-1.92
w3m-0.5.3.20230129
..........

FreeBSD で zfs ファイルシステムに M.2 NVMe SSD を追加した

　2023年9月に FreeBSD で使用している「zfs」に M.2 NVMe 接続の SSD を追加した。 その件についてメモを兼ねて書いておこう。

　1個前の投稿で，zfs ファイルシステムのアップグレードの話を書いた。 zfs ファイルシステムのアップグレードは，実は今回の M.2 NVMe 接続の SSD を追加の際に必要になったので行ったのだった。 一部重複する内容もあるが，あまり気にしないでおこう。

　SSD の追加が必要になった理由は，使用している 2.5 inch の SSD の容量が心もとなくなってきたから，である。 Note PC をサーバーとして使い，そのストレージに 1TB の 2.5 inch SSD を使っているが，写真やらを大量に置いていると徐々に SSD の容量を圧迫してきた。 実質 920GB ほどの領域で，空きが 180GB 程度になっていた。これはちょっと心もとない。ということで，ストレージを増やすことにした。

　今使ってる Note PC には空いている NVMe のスロットがあるので，新たに NVMe の SSD を追加することにした。 そうすると 2.5 inch SSD は特に何もしなくていい。特に「zfs」を使ってるので拡張も簡単やし…。 そこで 1TB の M.2 NVMe SSD を買って追加することにしたのだった。

M.2 NVMe 接続の SSD の追加

　具体的な（物理的な）M.2 NVMe 接続の SSD の追加についてはここでは書かないでおこう。 写真とか撮ってないし…。 NVMe SSD は思ったよりも小さい印象がある。2.5 inch SSD よりも小さい（細長く薄っぺらい）印象がある。

zfs について

　zfs に関しては前回の投稿を見てほしいが， 複数のデバイス（複数の HDD や複数の SSD など）をストレージに使う際に，見た目は全体として1個のファイルシステムとして（全体を1個のプール (pool)として）扱えるところが便利である。 言い換えると「プール」という大きな HDD が1個あるような感じであり，その中に物理的なデバイスを追加して，複数の（1個でもいいが）HDD や SSD で1個のプールを構成している。 今回も M.2 NVMe SSD を追加して，それを既存のプールに追加するだけだった。

FreeBSD で zfs をアップグレードした際に efi boot 領域を作り直した

　2023年9月に FreeBSD で使用している「zfs」に M.2 NVMe 接続の SSD を追加した。 その際，「zfs」ファイルシステムのアップグレードが必要であり，かつ元からあった 2.5 inch SSD の efi boot 領域を作り直さないといけなかった。 その件についてメモを兼ねて書いておこう。

　そもそも，なぜ zfs のアップグレードが必要になったというと，使用している 2.5 inch の SSD の容量が心もとなくなってきたから，だった。 現在，当該の FreeBSD は L社の Note PC に入っているが，HDD は遅いので SSD に置き換えている。 その際，1TB の 2.5 inch SSD を入れたのだが，web サーバーに写真やらを大量に置いていると徐々に SSD の容量を圧迫してきた。 実質 920GB ほどの領域で，空きが 180GB 程度になっていた。 さすがにこれはちょっと心もとない。ということで，ストレージを増やすことにした。

　ストレージを増やすには，一つの手段として 2.5 inch SSD をより大きな容量のものに変更する，という手が考えられる。 しかし，それだと新しい SSD にシステムを入れ直して，データも移動させないといけない。それは手間がかかる。 一方，現在使っている Note PC には空いている NVMe のスロットがある。それなら新たに NVMe の SSD を追加することもできる。 M.2 NVMe を追加するなら 2.5 inch SSD は特に何もしなくていいことになる。データの移動もさせなくてもいい。 そこで 1TB の M.2 NVMe SSD を買って追加することにした。 （M.2 NVMe SSD の追加の話は次の投稿で書くことにする）

　ところで，現在 FreeBSD を入れているサーバーは，ファイルシステムとして「zfs」を使っている。 これはもともと Oracle 社の Solaris 用に開発されたものみたい。 zfs の便利な点は，複数のデバイス（複数の HDD や複数の SSD など）をストレージに使う際に，見た目は全体として1個のファイルシステムとして扱える点が挙げられる。 そのため，どんな物理デバイスがどのように使われているか，をあまり意識しなくていい。 デバイスを追加する際にも，いちいちスライスを切り直したりしなくてもいい。 また，既存のシステムのデバイスを交換する際にも，物理的にデバイスを接続した後の処理がシステムを止めずにできる。 デメリットとしては，ファイルシステムの管理用にある程度 CPU の能力を使う点が挙げられるが…。

GNSS (GPS) データから距離を求める

　ここ数回続けて GNSS (GPS) 関連の投稿をしている。 今回は GNSS (GPS) のデータから距離を求める話を書こう。

　距離については，以前 GPS 経路データから求めた距離の誤差について というのを書いた。 その時は六甲全山縦走路の距離に関して，GNSS (GPS) で得られた経路の距離の誤差について考えたものだった。 今回は，距離の求め方について書こうと思う。ま，ほとんどどっかのサイトの受け売りやけどね。

　地図上の距離を求めるには定規で測って縮尺を考えて距離を出す，というのも考えられるが，GNSS (GPS) で経路を記録していると，緯度＋経度，という情報が得られる。 そこで，2点間の緯度と経度の情報を使って距離を求める，というのが今回のお話し。

緯度の経度について

　まず，距離を求める前に緯度と経度の話を書こう。
緯度は英語で「Latitude」，経度は「Longitude」と言う。 なので，計算スクリプトで lat やら Lat やらとあれば「緯度」を示し，lng や Lng, 場合によっては lon や Lon とあれば「経度」を表していると考えて欲しい。 ちなみに「高度」は「Altitude」が使われることが多い（と思う）。

SparkFun GNSS NEO-M9N + OpenLog Artemis で構成した GNSS ロガーのログ

　前回の投稿で，SparkFun 製の GNSS NEO-M9N ユニットと SparkFun 製の OpenLog Artemis で作った GNSS ロガーのことを書いた。今回のその GNSS ログについて書こうと思う。

　SparkFun 製 OpenLog Artemis は，Microcontroller の Apollo 3 Blue MCU を持つ Artemis Module で構成されたログ記録用のユニットである。それに SparkFun 製の GPS Breakout - NEO-M9N, U.FL (Qwiic) という GNSS ユニット，LiPo バッテリーを組み合わせると簡単に GNSS ロガーができる。SW をつなげる以外はほぼコネクタをつなげるだけ，でできる。

　その場合の GNSS のログは，OpenLog Artemis にプログラムされている形式で記録される。 以下にその例を示そう。

rtcDate,rtcTime,aX,aY,aZ,gX,gY,gZ,mX,mY,mZ,imu_degC,gps_Date,gps_Time,gps_Lat,gps_Long,gps_Alt,gps_SIV,gps_FixType,gps_GroundSpeed,gps_Heading,gps_pDOP,output_Hz,
01/01/2000,00:10:25.74,326.66,-913.57,-221.19,0.18,0.60,-0.25,-3.60,-5.10,-16.95,35.70,05/16/2023,05:58:15.000,350301689,1357728753,153510,0,0,0,23701918,9999,0.984,
01/01/2000,00:10:26.74,330.08,-923.34,-224.61,0.47,0.60,3.05,-3.30,-3.75,-18.90,35.46,05/16/2023,05:58:16.000,350301689,1357728753,153510,0,0,0,23701918,9999,0.984,
01/01/2000,00:10:27.75,326.66,-936.04,-217.29,-1.44,1.17,0.04,-4.20,-5.85,-13.05,35.46,05/16/2023,05:58:17.000,350301689,1357728753,153510,0,0,0,23701918,9999,0.984,
01/01/2000,00:10:28.75,330.57,-926.27,-238.77,-0.29,-1.0,-0.70,-2.85,-4.05,-15.15,35.46,05/16/2023,05:58:18.000,350301689,1357728753,153510,0,0,0,23701918,9999,0.984,
01/01/2000,00:10:29.76,330.08,-916.50,-208.50,0.27,-1.14,-0.30,-5.40,-4.35,-16.50,35.41,05/16/2023,05:58:19.000,350301689,1357728753,153510,0,0,0,23701918,9999,0.984,
01/01/2000,00:10:30.76,330.57,-923.34,-209.96,-1.18,1.53,-0.24,-4.20,-4.80,-15.90,35.70,05/16/2023,05:58:20.000,350301689,1357728753,153510,0,0,0,23701918,9999,0.984,
....
01/01/2000,00:37:46.67,320.80,-581.05,-425.29,-12.73,-6.39,-8.52,-23.55,6.45,-9.60,39.63,05/16/2023,06:25:37.000,348934290,1355106946,144510,0,0,0,25642680,9999,0.984,
01/01/2000,00:37:47.68,96.19,-470.70,-528.81,7.64,-4.62,-11.46,-20.70,9.0,-7.50,39.15,05/16/2023,06:25:38.000,348934290,1355106946,144510,0,0,0,25642680,9999,0.985,
01/01/2000,00:37:48.69,259.28,-1590.33,-871.58,-7.19,-3.47,-32.61,-24.0,14.25,-12.45,39.39,05/16/2023,06:25:39.000,348934290,1355106946,144510,0,0,0,25642680,9999,0.985,
01/01/2000,00:37:49.69,217.29,-411.13,-810.06,-6.67,21.91,39.07,-32.55,23.40,-10.35,39.24,05/16/2023,06:25:40.000,348934290,1355106946,144510,0,0,0,25642680,9999,0.985,
01/01/2000,00:37:50.70,490.72,-383.30,-527.83,10.15,1.86,14.40,-36.45,22.95,-18.30,39.48,05/16/2023,06:25:41.000,349718091,1358144528,145559,4,2,2749,25642680,258,0.985,
01/01/2000,00:37:51.71,259.77,-958.01,-951.66,-42.80,8.94,6.55,-43.95,24.0,-18.30,39.29,05/16/2023,06:25:42.000,349718458,1358144645,140839,7,3,1830,14312410,261,0.985,
01/01/2000,00:37:52.71,272.46,-431.15,-659.18,30.15,-22.78,-44.46,-37.65,23.85,-22.05,39.48,05/16/2023,06:25:43.000,349718704,1358143742,135256,7,3,1194,14318840,261,0.985,
01/01/2000,00:37:53.72,159.67,-394.53,-519.04,4.99,20.63,9.93,-33.45,21.75,-25.80,39.39,05/16/2023,06:25:44.000,349719339,1358143424,121481,9,3,890,13825742,240,0.985,
01/01/2000,00:37:54.73,-4.39,-623.05,-746.09,-17.57,28.05,82.57,-47.70,23.10,-20.70,39.39,05/16/2023,06:25:45.000,349719530,1358143564,118751,12,3,484,13825742,176,0.985,
01/01/2000,00:37:55.73,195.31,-1654.79,-700.20,5.57,-47.44,-106.35,-36.0,26.55,-22.20,39.48,05/16/2023,06:25:46.000,349719732,1358143546,113840,13,3,879,16785064,167,0.985,
01/01/2000,00:37:56.74,434.57,-520.02,-1026.86,-32.24,-12.02,4.37,-43.35,22.65,-19.50,39.29,05/16/2023,06:25:47.000,349719762,1358143542,110599,13,3,1022,17545512,167,0.985,

SparkFun GNSS NEO-M9N と SparkFun OpenLog Artemis で GNSS ロガーを作った（ほぼ線をつないだだけやけど…）

　久々の投稿の気がするが，まぁ，気にしないでおこう。

　今回は GNSS ロガーを組み上げた，というお話し。 組み上げたと言っても，Qwiic というシステムのケーブルでつないだだけ，という工作ともなんとも言えない話になっている。 ま，一応，いろいろとあるので備忘録を兼ねて書いておこうと思ったのが今回の投稿。

　まず，GNSS ロガーについてだが，これは GPS ロガーとほぼ同義語として使ってる。 GPS というのはアメリカが開発した衛星測位システムであり，同様の衛星測位システムとして，ヨーロッパの Galileo，ロシアの GLONASS，中国の北斗 (BeiDou) や，日本のみちびき (QZSS) などがあり，その総称として GNSS (Global Navigation Satellite System) が使われているので，ここでは GNSS ロガーと記載している。

　これまでも登山の行動経路の記録のために GPS ユニットや GNSS ユニットと SparkFun 製 OpenLog（シリアル通信上に流れてきたデータを単純に記録し続けるユニット）を組み合わせたお手製の GNSS ロガーを作ってきた。
・Gms-g9 を使った GNSS ロガーに挑戦してみた
・GNSS ロガー (Gms-g9 使用) の2号機を作る
・ランニングエレクトロニクス社製 Gms-g9 基板使用 GNSS ロガー 3号機の製作
など…。

　しかし，それらも徐々にヘタってきた。GNSS ユニットがヘタったというよりは，基板のはんだ付けやら，基板用のミニスイッチなどがヘタってきた感じで，うまくログを記録できないケースも出てきた。そこで新しくなにかできないか？と思っていた時に見つけたのが SparkFun 製 OpenLog Artemis と SparkFun 製の GPS Breakout - NEO-M9N, U.FL (Qwiic) だった（NEO-M9N Breakout board は，Chip Antenna がついたものや，SMA コネクターのものもある）。

　この OpenLog Artemis と NEO-M9N board は Qwiic という接続システムを搭載しており，Qwiic 専用のケーブル（50mm，100mm，など）を使えば，はんだ付けなしでコントローラーとセンサー類を接続できる。 そこで，今回はこれを使って GNSS ロガーを作ってみた。

FreeBSD で Python のデフォルトバージョンを変えたら py-gobject3 がうまくアップデートできなかった話

　久々に書き込んでいる気がする…。
　今回は FreeBSD で Python のデフォルトバージョンを変えた時のトラブルの話を書こう。

　何をしたかと言うと，FreeBSD 上のアプリケーションとしていろいろあるのだが，Python もインストールされている。 Python は Python 自体を使いたいというよりは，他のアプリケーションとの依存関係で勝手にインストールされる。 ついこの間まで，なぜかうちの FreeBSD の python の default version は 3.8 に指定してあった。 もう 3.11 が出てるのにね。でも，まぁ，現時点では 3.9 がまだ FreeBSD 上でのデフォルトとなってるから，そこまでひどくはないと思うけど…。 ちなみに default version が 3.8 から 3.9 になったのは 2022/6/26 なんだけどね (現在は 2023/3 末)。

　なぜ急に default version をあげようと思ったかというと，ふと /usr/ports/UPDATING で python で検索したら，2022/6/26 に python の default version を 3.8 から 3.9 にした，と書いてあったから。 そこで，その 2022/6/26 の記載に従って処理をしてみた。
概略は，

(1) /etc/make.conf で python のデフォルトを指定してあったのをコメントアウトした。
(2) root 権限で以下を実行した。

  # portmaster -o lang/python39 python38
  # REINSTALL="$(pkg info -o "*py38*" | awk '{printf "%s ", $2}')"
  # pkg delete -f "*py38*"
  # portmaster $REINSTALL
  # REBUILD=$(pkg query -g "%n:%dn" '*' | grep py3 | grep -v py39 | cut -d : -f 1 | sort -u)
  # portmaster $REBUILD
  # REBUILD2=$(pkg list | grep python-38 | xargs pkg which | awk '{print $6}' | sort -u)
  # portmaster $REBUILD2

(3) 最後に "pkg remove python38" を実行して，/usr/local/lib/python3.8/ ディレクトリになにか残ってたら手動で消す。
というもの。

　で，エラーが起こったのは（まぁ，当然といえば当然だが）(2) の実行時。その中でも「portmaster $REINSTALL」ってのを実行中にエラーがでた。 これは，直前で python 3.8 で作られたアプリケーションを消し，それらを python 3.9 で（デフォルトで）作り直す，というコマンド。 それが最後まで実行されなかった。見ると途中に「ERROR」という文字が見える。 portmaster というコマンドは，複数のアプリケーションのアップデートを順にやってくれるが，どれかのアップデートでエラーが起こると，その先は実行してくれない。 今回見ていると，どうも「/usr/ports/devel/py-gobject3/」というアプリケーションのアップデート時にエラーを吐いていた。 エラーメッセージ（一部）はこんなんやった。

ERROR: Unhandled python OSError. This is probably not a Meson bug, but an issue with your build environment.
WARNING: Running the setup command as `meson [options]` instead of `meson setup [options]` is ambiguous and deprecated.
===>  Script "configure" failed unexpectedly.
Please report the problem to desktop@FreeBSD.org [maintainer] and attach the
"/var/ports/usr/ports/devel/py-gobject3/work-py39/pygobject-3.42.2/_build/meson-logs/meson-log.txt"
including the output of the failure of your make command. Also, it might be
a good idea to provide an overview of all packages installed on your system
(e.g. a /usr/local/sbin/pkg-static info -g -Ea).
*** Error code 1

　見ると，「/usr/ports/devel/py-gobject3/」という文字列が目に入った。つまり「py-gobject3」のアップデートに失敗している。 そこで，とりあえず環境変数「$REINSTALL」の中身を「echo $REINSTALL」として表示させ，py-gobject3 以外を portmaster でアップデートするとうまくいった。 しかし，その後のプロセスで py-gobject3 を使うみたいで再びエラーがでた。

　仕方ないのでネットワークのお世話になり，検索をかけると，https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238254 というページにたどり着いた。読んでみると，どうも「/usr/ports/devel/gobject-introspection/」をインストールしなおせ，と書いてある。 「pkg info -aI」として調べると，確かに「gobject-introspection-1.76.1,1」がインストールされていた。

　そこで「/usr/ports/devel/gobject-introspection/」（gobject-introspection-1.76.1,1）をインストールし直してから (make install として，重複してるとエラーがでたら make deinstall install clean とした)，「py-gobject3」を portmaster でアップデートしたらうまくいった。 何がおかしいのかよくわからないが，時々起こる似たような現象がおこる。何かのサブルーチンが最新になってなかった，ということみたいやけど，それ以上はいいことにしてしまった…。

FreeBSD で libxml2 のアップデートしたら，多くのアプリケーションが動かなくなった

　2022年3月26日に FreeBSD 上のアプリケーションのアップデートをしていたら，急に多くのアプリケーションが動かなくなった。 その顛末を書こう（まだ終わってないけど…）

　ことの起こりは FreeBSD 上で portupgrade をしたことに始まる。 まぁ，ホントは他のアプリケーションのアップデートができない，といわれてごそごそやっていたのだが…。 そのごそごそやっている時にメモを残しているのだが，そこで新しく emcas でファイルを作ろうと思った。 そしたらいきなり

ld-elf.so.1: /usr/local/lib/libxml2.so.2: version LIBXML2_2.4.30 required by /usr/local/bin/emacs not defined

と言われてしまった。

その時点での libxml2 のバージョンは

% pkg info -aI | grep libxml2
libxml2-2.9.13                 XML parser library for GNOME
py38-libxml2-2.9.13            Python interface for XML parser library for GNOME
py38-lxml-4.8.0                Pythonic binding for the libxml2 and libxslt libraries

だった。「libxml2」自体のバージョンは「2.9.13」だった。 説明を見る限りでは，この libxml2 は GNOME 上で XML のテキストファイルの解析（解釈？）をするものみたい。 なので，GNOME 上で動きそうなアプリケーションではかなり影響を受けそうな感じだった。 私の場合はそれが emacs だった。

Android スマホを，Mac アドレスフィルタリングしている Wi-Fi につないだ話

とある場所での Wi-Fi の接続で Mac アドレスフィルタリングがかかっている。 そこに新しく買った Android スマホをつなごうと思ってもうまくいかなかった。 なんどやっても，Mac アドレスを調べ直しても同じだった。

と，ふとスマホの今つないでいる Wi-Fi の設定の「詳細設定」を見ると「ランダム MAC を使用（デフォルト）」という項目が目に入った。 そこをタップすると「ランダム MAC を使用（デフォルト）」と「デバイスの MAC を使用」というのが選べるようになっていた。 そこで「デバイスの MAC を使用」を選ぶと Wi-Fi につながった…。

最近は Mac アドレスは簡単に変更できるので，Mac アドレスフィルタリングは意味がないという話になっている。 しかし，ちょっと前に設定されている Wi-Fi だとそれが残っていたりする。 今回はそこでひっかかった。Mac アドレスを登録してもらう時に Mac アドレスフィルタリングはもういらないからやめてほしい，といえばよかったか…