iMac 注文完了!

クレジットカードの承認が下りれば OK ですね。カード決済完了しました。問題ないと思います。注文した iMac のスペックを列挙してみます。

  • シルバーの 8 コア CPU/8 コア GPU モデル 
  • 512 GB ストレージ 
  • 16GB のユニファイドメモリ
  • テンキー付きの Magic Keyboard
  • Magic Mouse

現在使っている iMac(mid 2017) は下取りに出します。 Apple の下取りは、新しい iMac が届いてから環境移行の時間 ( 確か 15 日 ) を見てくれますので、安心です。私の場合外付けの HDD にタイムマシンでバックアップをとっていますので、それを使って環境移行を行うつもりです。なので、環境移行が上手くいったことを確認してから今使っている Intel iMac を下取りに出そうと思っています。

下取り価格は除いて、 224,800 円です。安くなりましたね。 M2( 仮称 ) だともう少し高くなるのかもしれません。 M2( 仮称 ) にはまだ少し未練があります。

納期は 3 週間〜 4 週間ですね。最大 5/31 となってます。伸びる可能性もあると思ってます。早くなったら儲けものです。さて、あと 1 ヶ月、今使っているアプリの M1 対応具合を調べて過ごすことにします。楽しみでございます。

iMac のオプション

GPU8 コアの 512 GB モデルを購入するつもりです。つもりなのですが、 512 GB というのは今使っている Intel iMac と同じです。なんとなく同じじゃ面白くないなぁと思ったりしているんですね。いや、同じでもいいんですよ。でも、なんかねぇw

そして、ユニファイド・メモリも 16GB にするつもりなので、価格がどのぐらいになるのか気になります。 SSD を 1TB ぐらいにすると、ユニファイド・メモリと合わせてどのぐらいになるのだろうと ( 価格ですね ) 。 30 日にはっきりするので、また記事を上げます。

かなりの確率で、プロ向けの MacBook Pro/iMac は M2( 仮称 ) になるものと思います。そちらも気になりますねぇ。どのぐらい早くなるのでしょうね。 M2( 仮称 ) はコア数はおそらく倍近く。ユニファイド・メモリも増強されるんじゃないかなぁ。

この時期で購入するのはどうなんだろうという思いはあります。 M2( 仮称 ) 搭載 iMac を待った方がいいんじゃないか。ただ、待っているうちに環境が大きく M1 環境に移行していると思います。そんな中、 Intel Mac を使い続けるのは得策ではないと思っています。やっぱり M1 iMac 購入だよなぁ。なんせ M1 は過渡期にあるわけですからね。 2 年の過渡期の真ん中ぐらいですな。 M1 Mac の完成がどんな感じになるのか楽しみですねぇ。

さて、 30 日にはオプションも決定します。 5 月末とされている発売がいつぐらいになるのか、待ち遠しいです ( 昨日も書いたな ) w

iMac 2021 購入します ( 予告 )

本当は M2( 仮 ) 搭載を狙っていたんですが、待っていられませんw 購入します。あと数日で予約受付開始ですね。まだ、オプションについて公表されていませんので、わかりませんがさてどうなるでしょうね。

個人的には、 CPU/GPU それぞれ 8 コアの 512 GB モデルを購入するつもりです。メモリは 16GB のユニファイド・メモリにします。さて、それでいくらになるんでしょう。 8GB のユニファイド・メモリだと、 199,800 円ですね。 220,000 万ぐらいになるのかな?

今使っている 21inch の iMac と実寸ではほとんど変わりません。問題になりそうなのは、 USB-A ポートがないことかな。ハブを購入することを考えています。 A ポートはやはりまだ必要です。

\ (^O^) / 楽しみだよ〜  5 月末まで待てないw

Nexus5 を中古で購入

Nexus5 なんてもう過去の機種なんですが、 Android11 を動くように改造したヤツを中古で購入しました。単純に好奇心からです。

なにゆえ

ず〜っと、以前に別のアンドロイド端末をもっていたことがあったんですが、使い道がなく売却してしまいました。今回は、最新の OS に載せ替えていますのでそこそこ使えるのかなと思っています。実際使った感じは、まずまずかなと思います。ただし …

Wi-Fi が安定しない

Wi-Fi がイマイチ安定しません。電波状況は問題ないのですが、プツプツ切れる。リスタートさせたり、電源を入れ直したりしてみましたが、イマイチです。ふと、設定をのぞいてみると「自動的に接続する」のチェックが外れていました。これが原因かなぁ。

今様子を見ているところです。もし、まだ安定しないなら microUSB 接続の有線 LAN アダプタをかませてやろうかなとも考えています。

SMS 対応 SIM カードを発注

私は、 BIGLOBE ユーザーなのですが、追加で SIM をゲットすることが出来ます。メインの回線 (iPhone 回線 ) の子回線を格安で獲得できるのですね。 350 円ぐらいだったと思います。

早速子回線を発注して到着待ちです。

さて何に使おうか

購入してから考えるのは私の悪い癖です。更に、中古端末のため、バッテリーが弱い。バッテリー交換しようかとか、ケースに入れようかとか考えています。

自宅内で使うサブ機ですので、アプリもガシガシ入れて楽しもうと思います。さて、何に使おうか?

clubhouse 初体験

招待制の音声による SNS clubhouse をはじめて使ってみました。 iPhone に USB 接続のマイクをつなげ、 Bluetooth でヘッドフォン (AirPods Max) で音声を聞きながら、 iMac で作業をしながら。なるほど面白いメディアですね。明日は昔メーリングリストでつながっていた仲間ともルームを共有する予定です。ハハッ、色々ありますね。

導入のハードル

日本語化されていません。これ、結構大きなハードルになっていそうですね。手探りでやらなけばいけない。今日のルームでも話題になっていました。 Facebook やってる人だったら、抵抗ないかもしれない実名主義ってのも抵抗に感じる人もいるかもですね。そして何より招待制であると言うことでしょうか。

招待を受けた側がバンされると、招待した人もバンされてしまうという連座制も知っている人からすればオイオイって感じに思うところかもしれませんね。

ながらメディア

そして、今日のルームでも話題なっていた「ながらメディア」であるというのも流行っている理由の 1 つかもです。私の場合は、何かするときにまず間違いなく音楽がかかっています。その音楽の替わりにトークが割り込んでくるという感覚ですね。

今日の私も、 iMac での作業しながらのトークでした。仕事場で雑談しながらも、手は作業している。そんな感覚で別に違和感は感じませんでした。ラジオとか、ポッドキャストの双方向版。そんな感じに思いました。

発言出来るようになるまで

誰でもしゃべってるところに入っていくことは出来ます。しゃべっているところが、ルームと呼ばれます。ただ、ルームに入っていっただけでは発言の機会はありません。手を上げて、モデレーターに承認してもらうことで発言も出来るようになります。

聞くだけなら、ナンボでも聞くことが出来ます。ただそれだと、一発取りのポットキャストと何ら変わらないので、自分でも発言を求めて手を上げるべきだなぁと思いました。私、あんまりしゃべるのは得意ではないので、手を上げてもしゃべることは少なかったですが、手を上げなければ話題の中にも入っていけませんからね。

ルームの選択

さて、難しいのはルームの選択ですね。モデレーターが発言を認めないルームもありました。 clubhouse では録音が禁止されていますので、一過性のものになります。あとで聞き直そうと思ってもそれは出来ないってことになります。なので、なおのこと聞きたいルームを選択するのが重要になります。

しかし、ルームを選ぶには数行のインフォメーションを頼りにするか、モデレーターを選択するしかありません。今日のルームは、モデレーターを選択したものでした。楽しく会話できたのは、モデレーターの個性によるものが大きいと思います。もちろんそこに参加している人の個性がうまくマッチしてコソですけどね。

そして、感想

面白いメディアですね。ただ、これ単独で完結させるのはもったいないなぁと思ったりしました。話をしたいネタがあらかじめ決まっている場合、レジュメのようなものが必要だったりしますね。他のメディアとのミックスでより楽しさが増すんじゃないかな。

録音できないってことが雑談中心の話題になりそうですね。あとは特定の趣味を持ったサークルのようなものに合うのかな。個人的には入り浸りになるメディアではないと感じましたが、面白そうなルームを見つけたら入っていきたいなぁと思います。

ルームの選択、難しいなぁ。

rc.local の書式

kubuntu に起動時にメールを出すスクリプトをセットしたつもりだったけど、動作しない。無知をさらけ出すことになりますが、書式がしっかりしてなかったんですわ。

経緯

Kubuntu はモニターにつなげてはあるのですが、通常モニターはアクティブになっていません。入力を切り替えてやればモニターに映るんですが、ここ数ヶ月事実上のヘッドレスマシンになっています。

簡単なスクリプトなどの実験台になってくれているのですが、時々リスタートさせる必要があります。そこで、ちゃんと起動してくれたのか確かめるために、極簡単なスクリプトを書いてそれを /etc/rc.local に書き込んだつもりでした。

動かないスクリプト

ところがですね。動かないんですよ。何度リスタートしても動かない。スクリプトをコマンドプロンプトに打ち込んでやれば動く。何度テストしてもコマンドプロンプトに打ち込んでやれば動くんですね。メールがちゃんと届く。でも、 rc.local に書き込んだのは動かない。

ググってみると、 systemctl でステータスを確認できるらしい。それすら知らなかった。早速やってみました。エラーでてましたよ。 Failed to execute command: Exec format error これもググってみました。そのものズバリの答えはなかなか見つかりませんでしたが、しかしよくよく考えてみると、エラーを翻訳してみると「コマンドの実行に失敗しました。実行形式エラー」実行形式?

とってもシンプルな答え (無知だった )

「コマンドの実行に失敗しました。実行形式エラー」何度も読んでいたら、答えにたどり着きました。シバン (shebang) ですね。スクリプトを書くときに、1行目に必ず書く、アレです。スクリプトの本文をいきなり書いていたんです。無知ですね。恥ずかしいです。コマンドプロンプトに書き込んだときには、コマンドプロンプトが Mac の場合 zsh だったりしますが、いちいち明示しなくても zsh が解釈してくれます。しかし、 rc.local の場合、一体どのインタプリタを指定しているのかわかりませんよね。私シパンを書いていませんでした。恥ずかしい。

Kubuntu の場合、 bash を指定してやれば間違いないだろうと思ったら、ビンゴでした。ステータスを確認したらちゃんと動いてくれてるのを確認できましたし、メールも届きました。

まとめ

まとめもへったくれもありませんが、同じように設定した Raspberry Pi などでは問題なかったのに、なぜ Kubuntu でシパンを抜かしていたのか? 実は、 Raspberry Pi などでは rc.local ファイルはもともと存在していて、スクリプトが書き込まれていました。 Kubuntu は rc.local ファイルが存在しなかったんですね。そのため、シパンを抜かして書き込んで「これで OK 」と思っていたんです。

無知の言い訳にしかなりませんが、そういうことです。恥ずかしいけど、自分への戒めもこめてエントリーにしました。

WAF を OFF にしないとエラーが出ます

WordPress の追加 CSS を変更しようとしたら、エラーになります。何がおかしいのか調べたら、サーバーサイドの WAF (ウエブアプリケーションファイアーウォール)がいたずらしていました。

WAF って何?

私の使っているのは、 Lollipop さんです。 Lollipop さんでは、 WAF (ウエブアプリケーションファイアーウォール)を提供しており、これを ON にしておくことを推奨しています。

WAF (ワフ)は” Web Application Firewall ”の略で、「 Web アプリケーションの脆弱性を悪用した攻撃」から Web サイトを保護するセキュリティ対策です。 Web サーバーの前段に設置して通信を解析・検査し、攻撃と判断した通信を遮断することで、 Web サイトを保護します。
インターネットバンキングや EC サイトのように、ユーザーからの入力を受け付けたり、リクエストに応じて動的にページを作成する Web サイトの保護に適しています。 

WAF とは?| SiteGuard |キヤノン

動的なページを作成するってところは、 WordPress にも合致してますね。私もこの機能を ON にして使っていました。

トラブル発生

さて、安定して使っていたんですが、どうもうまく動かないのが1つ出てきました。 WordPress には CSS を追加して指定する機能が備わっているんですが、これがうまくいかない。めったにいじるところではないので、気がつかなかったのですけど何度やってもエラーが出る。

このエラーですね。時間をおいて確認しろというので、時間をおいてやってみてもダメです。その他の機能はうまく動いてくれていますが、これだけうまく動きません。

何が悪いんだろうと考えてみるに、私の操作が悪いのか、サーバーサイドの問題なのか。どうもサーバーくさいんですよね。

単純に CSS に改行を1つ入れただけでもエラーになります。私の iMac から WordPress が動いているサーバーのどこかに何か障害になっているものがあるんじゃないか。そう考えたんですね。

WAF が原因でした

原因と書きましたが、 WAF そのものは悪くなかったんだと思うのですね。ファイアーウォールですから、何か普段と異なるアクセスが生じた場合それを停止するのが、ファイアーウォールの役目です。そういう意味では、 CSS を書き込むという行為は、通常記事を作っている時のアクセスとは少し異なるので、異常と関知してしまったのかもしれません。

しかし、そうは言っても不便ですな。 Lollipop さんの WAF は、 ON → OFF に変えても5分ぐらいタイムラグが生じます。 Lollipop さんのログインページの WAF 設定を OFF にして、しばらく待ってから問題の CSS の書き換えを行ってみると、ビンゴでした。

まとめ

WordPress の CSS 変更は、 WAF を OFF にしないと動かない場合があります。必ずしもこれだけが原因というわけではないと思いますが、同じようにエラーが出ている人は、 WAF を疑ってみてはいかがでしょうか。

最後に、 CSS の更新が終わったら、 WAF を元通りに ON にしておきましょうね。

Raspberry Pi の ntp 設定を変更する

小ネタです。調べ物をしてたら、 Raspberry Pi OS には標準で NTP サーバーの機能が埋め込まれており、 Debian の NTP サーバーにアクセスしているということでした。必ずしも変更する必要もないかもしれませんが、気になったので日本のサーバーに変更しました。

状態確認

● systemd-timesyncd.service - Network Time Synchronization
   Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: enabled)
  Drop-In: /usr/lib/systemd/system/systemd-timesyncd.service.d
           └─disable-with-time-daemon.conf
   Active: active (running) since Sun 2021-01-10 15:17:18 JST; 1 weeks 2 days ago
     Docs: man:systemd-timesyncd.service(8)
 Main PID: 309 (systemd-timesyn)
   Status: "Synchronized to time server for the first time [2001:19f0:200:144b::2000]:123 (2.debian.pool.ntp.org)."
    Tasks: 2 (limit: 4915)
   CGroup: /system.slice/systemd-timesyncd.service
           └─309 /lib/systemd/systemd-timesyncd

 1月 10 15:17:17 raspberrypi systemd[1]: Starting Network Time Synchronization...
 1月 10 15:17:18 raspberrypi systemd[1]: Started Network Time Synchronization.
 1月 10 15:18:07 raspberrypi systemd-timesyncd[309]: Synchronized to time server for the first time [2600:3c04::f03c:92ff:fe41:5a9c]:123 (2.deb
 1月 16 11:18:17 raspberrypi systemd-timesyncd[309]: Timed out waiting for reply from [2001:1620:2777:b::128]:123 (2.debian.pool.ntp.org).
 1月 16 11:18:18 raspberrypi systemd-timesyncd[309]: Synchronized to time server for the first time [2001:19f0:200:144b::2000]:123 (2.debian.po

これが、設定前の Network Time Synchronization System の設定です。 debian.pool.ntp.org に読みに行ってます。これを ntp.nict.jp に変えます。

設定変更

設定ファイルは /etc/systemd/timesyncd.conf です。任意のエディタで編集します。

#NTP=
 ↓
NTP=ntp.nict.jp

これで OK なんですが、これまで標準だった debian サーバーの設定が残ったままで、 nict.jp にアクセスするか不明なので、 Debian サーバーにアクセスしないようにします。といっても、コメントアウトされた 1 文から#を取り去るだけです。

#FallbackNTP=0.debian.pool.ntp.org 1.debian.pool.ntp.org 2.debian.pool.ntp.org 3.debian.pool.ntp.org
 ↓
FallbackNTP=0.debian.pool.ntp.org 1.debian.pool.ntp.org 2.debian.pool.ntp.org 3.debian.pool.ntp.org

これで設定はおしまいです。簡単ですなぁ。

再起動と確認

では、設定ファイルをセーブして、 Network Time Synchronization System を再起動します。そして、設定を確認します。

$ sudo systemctl restart systemd-timesyncd.service
$ sudo systemctl status systemd-timesyncd.service

2行目の status コマンドで、設定が上手くいっているか確認します。エラーが出ていなければ次のようなステータスが表示されると思います。

● systemd-timesyncd.service - Network Time Synchronization
   Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: enabled)
  Drop-In: /usr/lib/systemd/system/systemd-timesyncd.service.d
           └─disable-with-time-daemon.conf
   Active: active (running) since Tue 2021-01-19 20:42:16 JST; 18s ago
     Docs: man:systemd-timesyncd.service(8)
 Main PID: 30168 (systemd-timesyn)
   Status: "Synchronized to time server for the first time [2001:ce8:78::2]:123 (ntp.nict.jp)."
    Tasks: 2 (limit: 4915)
   CGroup: /system.slice/systemd-timesyncd.service
           └─30168 /lib/systemd/systemd-timesyncd

 1月 19 20:42:16 raspberrypi systemd[1]: Starting Network Time Synchronization...
 1月 19 20:42:16 raspberrypi systemd[1]: Started Network Time Synchronization.
 1月 19 20:42:16 raspberrypi systemd-timesyncd[30168]: Synchronized to time server for the first time [2001:ce8:78::2]:123 (ntp.nict.jp).

ちゃんと ntp.nict.jp から時間を読んでます。完成ですね。

まとめ

簡単な変更ですし、順番にやれば問題なるところはないはずです。 ntp サーバーの詳しいシステムに関してはよく分かってないのですが、遅延がなければより正しい時間を表示されるはずですよね。 Debian のサーバーがどこにあるのかわかりませんが、日本国内ではないと思います。多少の遅延が生じているのかもしれませんね。

絶対に直さなければならないと言うわけではありませんが、気になったので直してみました。

Wacthdog の設定

Raspberry Pi zero がハングアップしていました。何が原因かはっきりしませんが、ハングアップは困るので、対策をとってみます。

Raspberry Pi OS には、 Wacthdog Timer というのがあらかじめ仕込んであるそうです。ただ、通常はこの機能が OFF になっています。 Wacthdog というのは、システムが一定間隔で生存確認を行い、生存確認が取れなかった場合にリスタートしてくれるというものです。 Wacthdog のシステム自体がダウンしてしまったら、当然リスタートもされないと思うのですが、システムのコア部分に組み込まれているので、よほどのことがない限り大丈夫でしょう。では設定していきます。

ブート・コンフィグに追記

$ sudo nano /boot/config.txt

ブート・パーティションにあるということからもわかる通り、システムのコア部分で起動するものですね。慎重に作業しましょう。次の1文を追記します

dtparam=watchdog=on

蛇足ながら、 ON を OFF にすることで Wacthdog 機能が OFF になります。もちろん、最初にこの1文は入っていませんでしたから、 Wacthdog は OFF ですね。

初期設定する

カーネルモジュールの初期設定を行います。これもテキストの修正だけです。作業そのものは簡単ですが、スペルミスは Wacthdog の動作に影響しますので、慎重に行いましょう。

$ sudo nano /etc/modprobe.d/bcm2835-wdt.conf

このファイルは最初、存在していませんでした。新規作成ですね。もしあったら以前に Wacthdog を設定しているかもしれませんね。

options bcm2835_wdt heartbeat=14 nowayout=0

heartbeat=14 が設定時間になります。14秒ですね。ここは自分の設定時間でいいと思います。次の nowatout=0 は、 heartbeat (心拍)が止まったのを感知してからリスタートするまでの時間ですが、特別な理由がない限り0で良いですね。

Systemd の設定

次に、 systemd の設定です。これで最後になります。

$ sudo nano /etc/systemd/system.conf

この中にはすでに設定部分がコメントアウトされた形で書き込まれていますので、検索して見つけましょう。おそらく先頭に # が入った形でコメントアウトされていると思うので、 # を削除した上で上で設定した heartbeat (心拍)時間と一致させます。

#RuntimeWatchdogSec=0
            ↓
RuntimeWatchdogSec=14

動作確認

以上の設定が終わったら、 Raspberry Pi をリスタートさせます。再起動したら、次の1文を打ち込みます。

$ dmesg | grep bcm2835-wdt

私のシステムでは、

[    2.816764] bcm2835-wdt bcm2835-wdt: Broadcom BCM2835 watchdog timer

という応答が帰ってきました。先頭部分の数字は変わります。何も応答が帰ってこない場合は、 Wacthdog が起動していないことが考えられます。スペルミスなどがないか、チェックしてください。実際にシステムをハングさせて見れば確実ですが、私怖くて出来ませんでした。 Wacthdog を信じることにします。

まとめ

私は、再起動が完了したらメールを飛ばすように設定しました。常にメールをチェックできるわけではないのですが、メールが来た時間から逆算してシステムがどうしてハングアップしてしまったのか推測できますね。

あえてここには書きませんが、システムをハングさせる方法はいくつかありますので、検索してください。 Raspberry Pi は現在、5台稼働していますので、それぞれに同様の設定をします。想定外のシステムストップがなくなると良いなぁ。

AirPods Max 1週間使ってみて

絶賛した前回と打って変わって、ちょっとここはなぁという部分を書いてみますね。

有線での接続について

専用のコード「 Lightning – 3.5mm オーディオケーブル( 1.2m ) - ブラック - Apple (日本)」これ使わないと有線での接続が出来ないそうです。私、通常の lightning- オーディオケーブルが使えるんだと思って、注文してしまいました。 178 円でした。中国のバッタモンですけどね。

このコード、アップルストア直販価格で、 3,800 円ぐらいします。ちょっと高いですね。かすかな期待として、購入した(今輸送中)中国のバッタモンが使えたりしないかと思ってます。ダメでしょうね。 Apple の方針でしょうから致し方ないですけど、使えないのは不便ですね。

バッテリーについて

1 回の充電で使える時間は長いので困りません。むしろ、使わないときのことが問題です。今回の記事を書くきっかけはこのバッテリーの問題です。

電源スイッチを持たない AirPods Max は常に電源が ON になっています。そうすることで、 iMac や iPhone トのシームレスな接続が担保されるわけですね。これは相当便利です。ところが、いわゆる待機電力というか、使っていないときのバッテリー消費が想像以上に大きいです。使わないまま2日放置すると、満充電から30%以下まで落ち込みます。

それを防止するためには、いわゆるブラジャーケースに入れてやることが必要になります。これ、意外に面倒です。ケースそのものにも入れ方がありまして、右側に充電用の lightning ポートがあり、それ用に切れ込みが入っています。

ケースに入れてやると、ケースについている磁石に反応して、 AirPods Max がディープスリープに入ります。この状態だとバッテリーほとんど減りません。ケースへの入れ方を間違えても問題ないみたいですが、入れないとバッテリーが減ってしまうのは変わりません。

シームレスな接続をとるか、バッテリーの持続時間をとるか。難しい問題だったと思いますが、ちょっと減り方が早いですね。

持ち運びは不便

ケースに入れたまま持ち運ぶとなると、ハードケースが欲しいところ。すでに Amazon ではいくつかハードケースを紹介してくれますね。ただ、フィット感がどうなのか実際に使ってみないとなんとも言えません。

頭につけるものを首になんぞするなと言われそうですが、

無精ひげがみっともないですねぇ

この向きに曲げられないのも個人的には「えっ〜」ってところでした、逆向きには回るんですが、この向きには曲げることが出来ません。首にセットすることは出来ないと思った方がいいですね。

…とは言え

分解能は全くもって素晴らしいですし、これまで音源として mp3(320kbps) で十分だと思っていたにもかかわらず、 AirPods Max で FLAC 音源との聞き比べをして以来、 FLAC 音源を鳴らせるプレーヤーを探していたりします。正直、 mp3 と flac で音質がこんなに変わるなんて思っていませんでしたし、それを聞き分けることが出来るガジェットが手に入るとも思ってもみませんでした。

今まで、あまり分解能が高くない廉価版のヘッドフォンを使っていたのが、もったいなかったなぁなどと思っています。音質面では全くもって文句のつけようがありません。

長時間の視聴でも疲れることがなく、耳が痛くなることもありません。素晴らしいヘッドフォンです。6万なにがしの価値はあったと確信しています。