Googleがイメージ生成のAIを公開して、それがBard経由で利用できるようになった。日本語での生成はできないけれど、英語で指定すると、Bardから画像を生成することができた。

画像のダウンロードもできて、ダウンロードではフルサイズでみることができる。

久しぶりにWindows10で、WSLを起動したところ、”wsl.exe –update” を実行するようにというメッセージが表示された。
これは、従来のWSLから、Microsoft Store版(ストア版)のWSLにアップデートするコマンドだった。実行しないという選択もないので、実行した。
wsl.exe --update
実際に実行してみると、下記のようになる。「Linux 用 Windows サブシステム はインストールされました。」を表示されれば成功。念のため、”wsl.exe –version” を実行し、結果が取得できれば、ストア版への更新ができている。
PS C:\Users\zen> wsl.exe --update
インストール中: Linux 用 Windows サブシステム
Linux 用 Windows サブシステム はインストールされました。
PS C:\Users\zen>
PS C:\Users\zen> wsl --version
WSL バージョン: 2.0.9.0
カーネル バージョン: 5.15.133.1-1
WSLg バージョン: 1.0.59
MSRDC バージョン: 1.2.4677
Direct3D バージョン: 1.611.1-81528511
DXCore バージョン: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows バージョン: 10.0.19045.3930
PS C:\Users\zen>
GitLab CE 16.7.0からGitLab CE 16.7.3へアップデートした。
apt update, apt upgrade で問題なくアップデートできた。
利用中のWindows PCの挙動が怪しいときは、システムファイルチェッカーを使ってみる。ファイルの破損等が問題の場合は、システムファイルチェッカーを使うことで修復が行われ、システムが安定する可能性がある。
1. Windows Updateを行って最新の状態にする。
2. コマンドプロンプトを管理者モードで起動する(右クリックして「管理者として起動する」を選択する)。
3. `DISM.exe /Online /Cleanup-image /Restorehealth` を実行する。
4. 3の部分が正常実行されたら、次に `sfc /scannow` を実行する。
5. なにか問題があれば自動修復された旨が表示される。
実行例は下図。

スマートフォンの回線をソフトバンクからamahoに切り替えたので、インターネット回線もソフトバンク光からahamo光に切り替えた。これで少しは月額コストを抑えられるはず。
ahamo光に切り替えたときのメモを残す。
ahamo光の申込みはキャンペーン(10,000ポイントバック)を使ったので、ahamoからキャンペーン用のサイトで申し込みをした。たぶん、これが間違いだったのかもしれない。キャンペーン用のところでなければ、もっとスマートに申し込みなどができていたかもしれない。
キャンペーンでは、docomoコンサルティングからの電話での申込み確認が必須。この電話がとてもダラダラと長い。重要事項の確認が微妙で事前に書類を読めば終わるようなことを電話で1時間くらいかかった。20分とか言っていたのだが。不明なところの確認もあったのだが、不明なところを質問すると、まるで答えられない。切り替え元のソフトバンク光から切り替えるときの注意点で、もとがPPPoE方式でないと、切り替えに時間がかかると言われた。なぜそれが必要なのかを聞いても、答えられなかった。それから、切り替え日で、新しい回線に切り替わってから、実際に通信できるまでに数日かかるという説明もあった。でも、なぜ数日もかかるのかについては教えてもらえず。というか、数日かかるとしか言われない。実際に、謎に2日もかかったわけなんだが。
ルータについては、レンタルではなくて、バッファローのルータ(WSR-1800AX4P-WH)を購入した。OCNバーチャルコネクト対応のルータを用意する必要があったので、バーチャルコネクト対応かつ、とりあえず安いバッファローのWiFi6対応のものを買った。
切替日の朝には、自動的にソフトバンク光側は通信できなくなっている、という説明だったので、そのままにしていた。が、切替日の朝でもソフトバンク光は使えていた。ソフトバンク光のルータの電源を落とし、フレッツ光の終端装置も電源を落とし、20分くらい放置してから、新しいルータ(WSR-1800AX4P)で自動接続を試したが、切り替わらない。というかIPv6のアドレスも取得しない。数時間放置して、ルータを再起動したが接続できない。時間をおいて、何度か試したが接続できず。切替日の翌朝も同じことを試したが、接続できなかった。
切替日の翌日の夜に、確認したところ、IPv6のアドレスは取得できるようになっていた。だが、接続がOCNバーチャルコネクトではなくて、別のものが表示された後に、接続がきれていた。そのため、バッファローのルータを本体側のスイッチでAutoからマニュアルに切り替えて、ブラウザでルータの設定画面を開き、インターネットの設定で、OCNバーチャルコネクトを選択した。(このマニュアルでの設定は、ルータの物理スイッチがAutoに設定されていると表示されないので注意。物理スイッチのAuto設定と、ソフトウェアとしてのAuto設定の2つがあり、これが両方ともマニュアルになっていないと設定できない。)ルータの設定で、OCNバーチャルコネクトを選択して、何回かルータを再起動したら、IPv4のアドレスを取得した表示がルータのステータス画面で表示されて、ahamo光でインターネットの通信ができるようになった。
ネットで見かけていたAmazon Primeビデオが見れないという書き込みもあったが見れた。PCからも、PS4からも、タブレットからも、Amazon Prime Videoは見れた。スプラトゥーン3の通信も問題なし。ルータの性能もあるかもしれないが、ソフトバンク光よりも通信速度は出ている。下りで300Mbpsくらい。
教訓をまとめると・・・
JP1 Network Node Manager(JP1 NNM)に送信されてきたトラップ(SNMP Trap)を表示するのは、nnmtrapdump.ovplコマンドをCLIで実行する。実行すると、結果がコンソールに表示される。件数が多いことが想定されるので、標準出力をつかって、ファイルに書き出す方がよい。
オプションのパラメータを指定することで、期間や送信元のIPアドレスで絞り込むことができる。
例)
C:\Program Files (x86)\Hitachi\Cm2NNMi\bin>nnmtrapdump.ovpl -from 2023-08-30T00:00:00 -to 2023-08-30T23:59:59 -source xxx.xxx.xxx.xxx
参考: https://itpfdoc.hitachi.co.jp/manuals/3021/30213E0230/NNMS0621.HTM
Google Cloud SQLでMySQLのインスタンスを追加すると、タイムゾーンがUTCになる。これを、日本に変える方法のメモ。
タイムゾーンの確認のSQLと実行例。
MySQL [(none)]> SHOW VARIABLES LIKE '%time_zone%'
-> ;
+------------------+--------+
| Variable_name | Value |
+------------------+--------+
| system_time_zone | UTC |
| time_zone | SYSTEM |
+------------------+--------+
2 rows in set (0.157 sec)
MySQL [(none)]>
変更方法
1. Google Cloudの管理画面にアクセスして、SQLの管理画面を開く。
2. 設定変更するインスタンスを開く。
3. 上部メニューの「開く」をクリックする。
4. 「フラグ」のところを広げる
5. 「データベースフラグを追加」をクリックする。
6. フラグ選択で、「default_time_zone」を選択する。
7. 値に、「Asia/Tokyo」を入力する(選択ではなくて、入力する)。
8. 保存する。
9. 保存後に、インスタンスの再起動が必要になるので、再起動する。

設定変更後に確認した例。
システム側はUTCのままだが、アクセスしたとき(セッション)のタイムゾーンは、Asia/Tokyoに変わっており、現在時刻を取得した際の時間も日本時間になっていた。
MySQL [(none)]> SHOW VARIABLES LIKE '%time_zone%';
+------------------+------------+
| Variable_name | Value |
+------------------+------------+
| system_time_zone | UTC |
| time_zone | Asia/Tokyo |
+------------------+------------+
2 rows in set (0.159 sec)
MySQL [(none)]> select now();
+---------------------+
| now() |
+---------------------+
| 2023-12-11 13:50:43 |
+---------------------+
1 row in set (0.154 sec)
MySQL [(none)]>
とある機器の見積をとると、数年前の型落ち機種の見積ばかりが出てくる。型落ちを指定しているわけでも、コスト制約をしているわけでもない。なぜなんだろうか。
ぼちぼち販売終息になってもおかしくないくらいのロングセラーの機種で、CPUは4年落ちのXeonばかり。これから数年以上も使うという機器なのに、そんなに古いCPUを勧められる。後継機種が出ていないわけではない。後継機種で、2種も出ているのに、古い機種ばかりだ。これが、1社だけならばよいのだが、複数社(依頼したところ全部)から出てくるのだから、なかなか異常とも言える。在庫がダブついているのだろうか。COVID-19のときに半導体不足になったときに、ちょっと前の型を大量にストックしたりしたのだろうか。とはいえ、納期は即納というわけではなく1〜2ヶ月だから、どこからかは輸送されてくるはず。困るのは、安いと思っても、CPUの型番から、何年にリリースされたものなのかをしっかりとチェックしないと4年前のCPUだったりするということ。1、2年程度の型落ちならばよいが、4年となると・・・PCならば、買い替え時期にあたるくらいの期間だけに安物買の銭失いになりかねないということ。
いったい、どうしたのだろうか。不思議だ。
apt updateで、GitLabo 16.4.0から16.6へは自動アップデートできた。
また、小まめにGitLab CEのアップデートをやり忘れて、apt updateでのアップデートでエラーになった。今回は、GitLab CE 16.2から、GitLab CE 16.4.1へのアップデートだ。
apt upgradeで発生したエラー(一部抜粋)は下記。
gitlab preinstall: It seems you are upgrading from 16.2 to 16.4.
gitlab preinstall: It is required to upgrade to the latest 16.3.x version first before proceeding.
gitlab preinstall: Please follow the upgrade documentation at https://docs.gitlab.com/ee/update/index.html#upgrade-paths
dpkg: アーカイブ /tmp/apt-dpkg-install-33WUrh/15-gitlab-ce_16.4.1-ce.0_amd64.deb の処理中にエラーが発生しました (--unpack):
new gitlab-ce package pre-installation script subprocess returned error exit status 1
処理中にエラーが発生しました:
/tmp/apt-dpkg-install-33WUrh/15-gitlab-ce_16.4.1-ce.0_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)
まずは、GitLabのサイトで、アップグレードできるパスを調べる。
これによると、一度、16.3.5にアップグレードしてから、この時点の最新にアップグレードする必要があるとのこと。
アップグレードパス : 16.2 → 16.3.5 → 16.4.1
これを実行したコマンドは下記。段階的にアップデートして、最後に、GitLabを再起動する。
sudo apt update
sudo apt upgrade gitlab-ce=16.3.5-ce.0
sudo apt upgrade gitlab-ce=16.4.1-ce.0
sudo gitlab-ctl restart
何度もやっているので、作業自体はこなれた感じだ。