投稿

善趣と悪趣

イメージ
自分の仮説 梵天 慧(出家修行、リトリート) キッダーパドーシカ(他化自在天+楽変化天) 定(精進・念) マノーパドーシカ(兜率天+夜摩天) 戒(他者に迷惑をかけないこと) 地居天(三十三天+四大王天) 施(分かち合い)・頭陀支(小欲知足) 地獄 痴・見執(頑固な思い込み・決め付け) 畜生 瞋・慢執(利己的な遺伝子・弱肉強食) 餓鬼 貪・欲執(独り占め・環境破壊) 梵天 梵天は出家修行者だけが死後に行ける天界なので(かといってもちろん、出家修行者であればそれだけで行ける、というわけではない)、俗世間人である我々とは無縁であるから、ここでは深掘りしない。 キッダーパドーシカ(他化自在天+楽変化天) 日本国憲法で言う「内心の自由」が極度に実現された天界。つまり、文学・芸術・思想・宗教の源となる神々の居所。仏敵である悪魔は第六天魔(他化自在天)の一種であるとされるが、各宗教の至高の絶対神というのは、他化自在天である。織田信長も自称したという第六天魔王(仏敵たる悪魔)は大自在天(ヒンドゥのシヴァ神)とされるが、固有名称はともかくとして、この悪魔である他化自在天は、造化力を自在に操るゆえに「自在」などと名付けられている。つまり、「化ける・化かす」のが特徴である(そう考えると、シヴァよりもヴィシュヌの方が他化自在天らしく思える)。 悪魔は、釈尊が仏教を布教することを嫌がり、「不死に到る安穏なる道を覚ったのであれば、その道をお前一人で行け。どうして他人に教えようとするのか」などと釈尊を攻撃したりした(布教を勧請した梵天サナンクマーラとは対照的である)。後に、悪魔は、偽仏教を広めることによって、仏教の真の姿を希釈化して世間から隠す方策に転じる。史実の生身の人間の存在であった釈尊を表わしていた仏陀=如来という称号は、一般名称化され、史実の釈尊から乖離して一人歩きして、神秘的な神霊存在として換骨奪胎され、別物となり、ただの迷信の対象として作り変えられた。 真言密教では、大日如来という、もはや史実の存在としては何の根拠もない仏陀を捏造し、彼が(ヒンドゥのヴィシュヌのように)様々な化身に「化けて」人々を救うのだという設定を作り上げた。「化ける」という設定から、これは実は如来などではなく、初期仏教では他化自在天の性質として考えら

金儲け主義の陰陽師

イメージ
先日、山口敏太郎の YouTube ラジオ(2021−03−08 【ガチ鑑定】驚愕!!あーりんによる真実の心霊写真鑑定【前編】 の 23:21~29:45)を聴いていると、「〇〇については良い評判は聞かない」「金儲け主義の陰陽師だということしか聞かない」「金が大好きな陰陽師だと聞く」と形容されているものに行き当たった。 真実を語る黒子「陰陽師などという肩書自体が、偽物特有の名乗り」 僕は、「陰陽師」という肩書を心霊商売のセールス文句にしているのは、橋〇京〇しか、寡聞にして知らない。そもそも、「陰陽師などという肩書自体が、偽物特有の名乗りだ」ということを、民俗学 YouTuber の真実を語る黒子が言っていた(2023-10-03 【質問】陰陽師に本物はいますか?【答】 の 4:59~8:50)。 「敢えて YouTube で言う」という強調の仕方から、彼は、YouTube で有名な陰陽師を自称する特定の人間を念頭に置いているのだということがわかる。そこうなるとやはり、〇本〇明しか、僕は寡聞にして知らない 真実を語る黒子は、トクモリザウルスのヤースー(吉本興業の心霊芸人)とも WinWin チャンネルという形でコラボしていたりする(ex. 【素の2人】Win Winチャンネル【なかよし】 )ので、特に怪しい人物ではないことがわかる。 ヤースーの方は、真実を語る黒子の他にも、同じ吉本興業の後輩であるシークエンスはやともや先輩の好井まさお、太田プロ出身のナナフシギ(大赤見ノヴ&吉田猛々)といった芸人仲間、そして都市ボーイズ(岸本誠&早瀬康広)といった心霊芸能界隈のそうそうたる面々と仲良くコラボしている。 こういった、心霊 YouTuber 界隈から、橋〇京〇が爪弾きにされている(有名な割にコラボの相手にされていない)ような雰囲気を感じるのは、僕だけだろうか? それには、山口敏太郎の言うような、表には出てこない(そのため、メディアの裏読みができない情弱な一般人、例えば、長年ジャニーズの黒いビジネスを支えたジャニオタのような人々には、裏の事情を察することができない)が、業界人には(裏では)実は結構知られている「悪い評判」というものが、関係している可能性は低くはないだろう。 シークエンスパパとも「霊がいない空間に向かって、話しかけていた」

ニンゲンTV 沖縄編

イメージ
ノロ末吉が登場するニンゲンTVの沖縄編、いよいよ今晩 19:00 か。 沖縄というので、澄田綾乃(彼女側のグラビアの撮影の仕事のスケジュールに合わせたとかで)の登場回かと思ったりもしたが、予告編に影も形も見られないことからすると、今回は、女性サブメンバーは無しなのだろうか? 待望の本編は、下から:

e-Tax: このアプリは作成コーナーの画面内でご利用いただくものです。直接クリックして起動することはできません

イメージ
e-Tax(with マイナンバーカード + IC カードリーダー)を macOS Big Sur で使おうとして、最後の最後の段階の、データを国税庁に送信する段階になって「このアプリは作成コーナーの画面内でご利用いただくものです。直接クリックして起動することはできません」というエラーに陥った。 macOS で、それも Big Sur に早々と更新するような勢で、さらにマイナンバーカードを IC カードリーダーを使って確定申告しようというような酔狂者は少ないのか、検索してもあまり事例を見付けることができない。辛うじて Twitter には このような国税庁の Mac 対応不足を指摘するものを発見したのみ。 上記ツイートにより、このエラーが自分だけではないことがわかったのはいいのだが、実は、この「Mac 対応不足 → Windows なら ok」という認識は誤っていて、むしろ余計に皆が Windows に逃げようとする流れを是認・助長してしまっている。実際のところ、全然、Mac でも ok(後述)。決して e-Tax ヘルプデスクに「ゴルァ電」して、混雑に拍車をかけないように。 旧バージョンの e-Tax をアンインストールしろ! この重要なポイントが、なぜか、e-Tax のホームページで見つけられず(つまりググっても辿り着けない)、インストール時の jizenMac.dmg(仮想ディスクイメージ)の中の「インストールマニュアル.pdf」の説明の一部として「旧バージョンの e-Tax をアンインストールしろ」と書かれている。 これをやらないと、e-Tax の開始時では「正常にセットアップされています」と認識されているのに、最後の最後の国税庁にデータを送信する段階で「直接クリックして起動することはできません」エラーに陥いる。 ほとんど罠のような話。これでは「Mac 対応不足 → Windows なら ok」という認識を皆が抱いても仕方がないのかもしれない……。 ともかく、macOS Ventura とマイナンバーカードと IC カードリーダー( ACR1251DI-NTTCom )で今年(2024)も e-Tax はできている。Mac ユーザーの皆様には、めげずに貫き通して欲しい。

ACR1251DI-NTTCom と macOS

イメージ
そろそろ確定申告の時期を迎えて、e-Tax に関して、 M1 Mac の IC カードリーダーの対応が鬼門だ と国税庁が注意を喚起した件について、あちこちで記事になっている(2021 年当時の話)。 自分は M1 Mac ではないのだが、そもそも Big Sur にアップデートしてしまったので、その影響もあるのかどうか、既にアップデートしてしまってから気になってきた。 Mac で e-Tax を安心してできるようにと、わざわざ NTT コミュニケーションズのフラッグシップモデルである ACR1251DI-NTTCom を入手したくらいなので、それが迂闊な OS アップデートで差し障りが生じてしまうというのはちょっと残念過ぎる。JPKI(公的個人認証サービス)によると Big Sur はサポート対象外 である。不安が煽られる。 早速、ACR1251DI-NTTCom を MacBook に接続し、JPKI の利用者クライアントソフトを立ち上げてみた。 問題なく立ち上がる。動作チェックをしてみる。 動作チェックも無事終了する。念のため、マイナンバーカードの電子証明書を読み取らせてみたが、正常に機能した。 M1 Mac はともかく、どうやら Big Sur については(ACR1251DI-NTTCom に関する限り)問題ないようだ。 更新:macOS Ventura 2024 年 3 月の時点で、2023 年度分確定申告を e-Tax(マイナポータル経由)によって行ったが、ACR1251DI-NTTCom は少なくとも、自分の Intel-Mac(Macbook Pro 2017)では無事使えている。

OpenWrt で Let's Encrypt (with acme.sh)

イメージ
このブログ記事を最初にまとめた当時(2020-11-11)には気付かなかったが、現在(2023-12-06)ではいつの間にか、OpenWrt のパッケージモジュールとして acme が用意されており、さらには LuCI から使うための luci-app-acme までも存在している。以前の僕はこれらの OpenWrt パッケージについて知らなかったので、acme.sh の 公式サイト の説明に従って一般的な Linux マシンとしてインストールし、コマンドを実行して使用してと、愚直に自力の作業をしていたものである。今では OpenWrt の acme.sh についての 公式の説明 も存在するので、それに従って作業すれば、ほとんど苦もなく完了できる。 だが、acme.sh の実行による Let's Encrypt からの証明書の発行が半自動化されたとはいえ、DNS や NGINX などと連携させる必要があり、総合的な話としては一定の知識を要するので、ここにまとめておきたいと思う。 Web ルートの準備 acme.sh では証明書の発行時の身元確認の方式として、Web ルートに .well-known/acme-challenge という一時的な隠しフォルダを作成し、そこにユニークな文字列からなるファイル名を持ったファイルを設置して、インターネット側から http://(ドメイン名)/.well-known/acme-challenge/(ファイル名)にアクセスできるかどうかで、確認するという形になっている。 このため、いきなり、acme を使うのではなくて、先に DNS 側でドメインが OpenWrt ルーターの IP を指し示すように設定しておき、さらに OpenWrt ルーター側では、NGINX の設定で、そのドメイン名での http アクセスが /www 以下に対応付けられるようにしておかなければならない。 DNS の設定 A レコードでデフォルトドメインがルーターの IP アドレスを指し示すように設定している他、CNAME で www がデフォルトドメインの別名であるようにしている。CAA レコードは今回の趣旨とは全く関係がないオマケで、無関係の他者が勝手にこのドメイン名を使った証明書を作成することを防ぐためのものである( 参考 )

クレジットカードの海外事務手数料

最近(2024-01-19 時点)、あちこちで Mastercard / VISA 系の海外事務手数料の値上げが発生しているようなので、まとめてみた。(税込) Mastercard / VISA エポス 1.63 参照 ポケット(Mastercard) 1.90 参照 エムアイ 2.00 参照 VIEW 2.20 参照 楽天 2.20 参照 セゾン 2.20 参照 PayPay 2.20 参照 JACCS 2.20 参照 Orico 2.20 参照 三井住友 2.20 参照 MUFG 2.20 参照 d 2.20 参照 ポケット(VISA) 2.20 参照 Gold Point + 2.20 参照 セディナ 2.20 参照 JCB VIEW 1.60 参照 PayPay 1.60 参照 JACCS 1.60 参照 Orico 1.60 参照 ポケット 1.60 参照 MUFG 1.60+0.44 参照 セゾン 1.60+0.55 参照 楽天 2.20 参照 セディナ 2.20 参照 AmEx セゾン 1.75+0.25 参照 楽天 2.20 参照 エムアイ 2.00+0.25 参照

tkinter on macOS (via MacPorts)

各種 UNIX 系ツールのインストール・管理は MacPorts を使っているが、MacPorts でインストールした Python の tkinter を使おうとしたところ、XQuarz 経由で Tk が動く形となり、日本語入力が使えずに、コピー&ペーストしながら入力して、かなり不便なのを我慢していた。 どうにかならないものかと改めて情報を探ってみたが、X11 を使わずに Quarz を使うなどという 10 年前の情報が出るだけで、既に XQuarz が使われている自分の場合にはこれ以上手の施しようがないと思い込んでいた。 ──が、これが単なる、しかし致命的な勘違いで、Quartz と XQuartz では別物というか、XQuartz は、Quartz をワザワザ X11 互換モードで動かしているものらしく、要するに X11 のことである。だから Quartz をちゃんと Quartz として動かす必要があった。たったそれだけ、それだけだが致命的な勘違いだったというわだ。 「 macOS の matplotlib (MacPorts) で X11 を要求される問題を回避する 」というブログ記事の通りにして、無事に Quartz で tkinter を動かすことができた。記事自体は matplotlib に関するものだが、tkinter の場合も MacPorts 経由でインストールされた Tk を使うので、tk +x11 → tk +quartz に切り替えればよいというのは同じである。 MacPorts の tk は デフォルトで X11 を使用する ことになっていたので、 -x11 +quartz を付けてインストールし直せばよい(+x11 と +quartz は conflict するので同時に設定できない)。 sudo port install tk -x11 +quartz お蔭様で、無事、日本語入力もできるようになった。

au ひかり用の HGW を HGW-BL1500HM に更新

イメージ
実家の au ひかり用の HGW を Aterm BL902HW から HGW-BL1500HM に更新した。条件(メッシュ Wi-Fi の有料オプション(おうちどこでも WiFi)への申し込みとの抱き合わせ)付きだが、キャンペーンで今なら手数料無料で更新できたからだ(有料オプションは、料金が発生する前に速攻で解約する予定)。 両者の違い: Wi-Fi が ax/ac 対応になった(BL902HW では an まで) NEC(日本)製から Askey(台湾)製になった VDSL モデム一体型から分離型になった 両者の共通点: 有線の WAN/LAN は 1Gbps でギガビットイーサなのは同じ 有料オプションの Wi-Fi は使っていなかったし、今後も使う予定はないので、かなりどうでもいい話(だが、au 側としてはそこが理由で今回のキャンペーンを行ったのだろうけど)。 NEC(日本)製から Askey(台湾)製になったことについては、ファイヤーウォールの初期設定(👉 au ひかり用の HGW のファイアーウォールの初期設定 )など、特に変った点は見られず、この辺りの一貫性はメーカー側よりは au 側にイニシアティブがあるのだろう。ただ、設定項目としては同じでも、かなり画面の外観が変っていて、レイアウトが無駄に大きく(NEC の時は 1 次元的に縦に長いレイアウトだったが、Askey では 2 次元的で横に段組されていて今さら古い時代のホームページみたいなセンス)、行きたい画面に辿り着くまでステップ数が無駄に多い印象。 Wi-Fi は使わないし、かといって使う方の有線の WAN/LAN は前の BL902HW と同じなのに、なぜ、わざわざ更新しようと思ったのか? それはまあ、Wi-Fi が高速化された分、スループット(CPU の処理速度も含めた総合的な性能)がより高速になっているであろうことが期待できるからである。 実は段違い? マンションタイプの VDSL なので、そこがボトルネックにはなってしまうのだが、実は、BL902HW の場合と BL1500HM で大きく違っている部分があり、それは、VDSL モデムと HGW 間の接続が、100Base-TX から 1000Base-T に上がった点である。

au ひかり用の HGW のファイアーウォールの初期設定

au ひかり用の HGW である HGW-BL1500HM について、初期状態でのファイアーウォールの設定について調べてみた(ちなみに、前世代の Aterm BL902HW についても設定内容は同じである)。 WAN 側インターフェース 種別 方向 プロトコル 送信元 送信元ポート 宛先 宛先ポート 優先度 廃棄 out UDP any any any 137-139 1 廃棄 out TCP any any any 137-139 2 廃棄 out UDP any any any 445 3 廃棄 out TCP any any any 445 4 廃棄 out TCP any any any 2049 5 廃棄 out UDP any any any 2049 6 廃棄 out TCP any any any 1243 7 廃棄 out TCP any any any 12345 8 廃棄 out TCP any any any 27374 9 廃棄 out TCP any any any 31785 10 廃棄 out UDP any any any 31789 11 廃棄 out UDP any any any 31791 12 廃棄 in TCP any any any 1243 13 廃棄 in TCP any any any 12345 14 廃棄 in TCP any any any 27374 15 廃棄 in TCP any any any 31785 16 廃棄 in UDP any any any 31789 17 廃棄 in UDP any any any 31791 18 一見複雑なようだが、全て廃棄するルールで、送信元ポートは全て any であり、重複してエントリーされているものがあるので、宛先ポート毎にまとめて考えれば、かなり単純だと思う。独自に宛先ポート毎の表にしてみた: WAN 側インターフェース 宛先ポート 方向 プロトコル 備考 137-139 out TCP/UDP NetBIOS over TCP/IP (Windows) 445 out TCP/UDP Direct Hosting of SMB (Windows) 2049 out T