mieki256's diary

そもそも、FFFTP等から正常にFTPSで接続できた際、どういうログが表示されるのだろう。そこからして分からなかったので、LAN内でFTPS (Explicit) 接続できるFTPサーバを立てて動作確認してみようと思い立った。

とりあえず、足元に置いてあるサブPC、Ubuntu Linux 22.04 LTS (Core i3-6100T機)に、FTPサーバ、vsftpd 3.0.5-0ubuntu1 がインストール済みだったので、設定(/etc/vsftpd.conf)を変更して、FTPS(Explicit)接続ができるようにしてみる。

• 接続先はLAN内の Ubuntu Linux 22.04 LTS + vsftpd 3.0.5。ぷららのFTPサーバじゃなくて、LAN内の実験用サーバ。
• FTPクライアントを動かしたOSは、Windows10 x64 22H2。

動作確認に使ったFTPクライアントは以下。 LAN内 の Ubuntu Linux + vsftpd にFTPS接続できたかどうかの結果も書いておく。勘違いされるとマズいので再度書く。ぷららのFTPサーバじゃないよ。LAN内の、だよ。

FTPクライアント	接続成功/失敗
FileZilla 3.65.0	Success
WinSCP 6.1.1	Success
Cyberduck 8.6.2	Success
FFFTP 1.98g	Success
FFFTP 2.00 x86	Success
FFFTP 4.5 x86	Failure
FFFTP 5.8 x86	Failure
FFFTP 5.8 x64	Failure

自分の手元の環境では、FFFTP 3.x以降のバージョンは、ことごとくFTPS接続に失敗している。

FFFTP は、2.00までと、3.x以降で、SSL/TLS関係の処理がごっそり変わっているそうで。2.00までは自前でSSL/TLS関連ファイルを持って処理をしていたけれど、3.x以降はWindowsが持ってる機能を使って処理するようになって、そのせいか環境によってFTPS接続ができたりできなかったりするらしい。

ネット上では「FTPS接続したいならFFFTPで」的に紹介されていることが多いけれど、今現在、一般的に入手しやすい FFFTP は 3.x以降なので、この状況はマズい気がする…。FTPサーバの種類、サーバ側設定との相性がかなりあるのではないか…。安易にFFFTPを推奨するのは危ない…。そのあたり、ぷららは分かっているのだろうか？ もちろん、フツーのFTP接続なら悪い選択肢では無いだろうけど。自分も普段使っているし。

ちなみに、「FFFTP の 32bit(x86) と 64bit(x64) で動作が変わるのではないか？」「OSが64bit版なら FFFTP も64bit版を選ばないとダメなのではないか？」と思ったけれど。試したところ、そのあたりは関係なさそう。動作に違いは無かった。

念のため、FFFTP 5.8 x64 から、 Ubuntu Linux 22.04 LTS + vsftpd にアクセスしてみた際のログ(?)も書いておく。ぷららのFTPサーバじゃないよ。

 ## DEBUG MESSAGE ON ! ##
 FFFTP Ver.5.8 64bit Copyright(C) 1997-2010 Sota & cooperators.
 ...
 ----------------------------
 FTP over Explicit SSL/TLS (FTPES)を使用します.
 ホスト i36100t (192.168.1.11:21) に接続しています.
 接続しました.
 220 Welcome to blah FTP service.
 >AUTH TLS
 234 Proceed with negotiation.
 ## InitializeSecurityContextW() failed(0x80090326): 予期されない、または形式が間違ったメッセージを受信しました。
 ログインできません.
 ## Skt=2208 : Socket closed.

FTPクライアント側(FFFTP)が、AUTH TLS を送信した直後にエラーが出て失敗している。

逆に考えると、FTPサーバ側がそこそこ真っ当に設定できていれば、FTPクライアントから AUTH TLS を送信するところまでは少なくとも進むはず、と言えそう。

しかし、ぷららのサーバはそこまで進まず、上記で言えば 220 すら返ってこない状態なので、やはりぷらら側で何かを間違えてしまっているとしか思えないわけで…。

各FTPクライアントは以下から入手できる。

_FFFTPの詳細情報 : Vector ソフトを探す！ (FFFTP 2.00が入手可能)
_Releases - ffftp/ffftp - GitHub (FFFTP 3.x以降が入手可能)
_FileZilla - The free FTP solution
_Cyberduck
_「WinSCP」SCP/SFTP/FTPS対応のFTPクライアント - 窓の杜

本来、FFFTP 2.00以前は OSDN から入手できるはずなのだけど、OSDNがずっと 504。つい最近、OSDNが中国企業に売られてしまったことが関係しているのだろうか…？

_接続不調が続く「OSDN」、米「SourceForge」がプロジェクトの勧誘に乗り出す - やじうまの杜 - 窓の杜

ググっていたら、Vector から FFFTP 2.00 を入手できることが分かった。下のほうにスクロールしていくと 2.00 (ffftp-2.00.zip) がある。助かった。

_FFFTPの詳細情報 : Vector ソフトを探す！

以下を参考にしながら vsftpd の設定をしていった。

_Ubuntu 22.04 LTS : Vsftpd Over SSL/TLS 設定 : Server World
_Ubuntu 20.04 で SSL/TLS を使用して FTP サーバー (vsftpd) をインストールおよび構成する方法
_vsftpd over TLS/SSL@cbreeze
_CentOS vsftpdでSSL/TLS暗号化接続が出来ないまたは途中で止まる - POCH-7003 BEATout!
_vsftpd - Over SSL/TLS 設定すると FileZilla でエラー！ - mk-mode BLOG

vsftpd に、FTPS接続の設定をしていく。

FTPS接続を可能にするためには、証明書なるものが必要らしい。外部に公開するサーバならちゃんとした証明書が必要らしいけど、今回はあくまでLAN内で実験するだけなので、自己署名の証明書なるものを作成して作業を進める。

以下を実行して、/etc/ssl/private/vsftpd.pem として証明書を作成。途中で国コードやら何やらを尋ねてくるので入力する。

sudo openssl req -x509 -nodes -newkey rsa:2048 -keyout /etc/ssl/private/vsftpd.pem -out /etc/ssl/private/vsftpd.pem -days 3650

$ sudo openssl req -x509 -nodes -newkey rsa:2048 -keyout /etc/ssl/private/vsftpd.pem -out /etc/ssl/private/vsftpd.pem -days 3650

...+.......+..+...
...
-----
You are about to be asked to enter information that will be incorporated into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:JP                                # 国コード
State or Province Name (full name) [Some-State]:Fukushima           # 地域(都道府県名)
Locality Name (eg, city) []:Sukagawa                                # 都市
Organization Name (eg, company) [Internet Widgits Pty Ltd]:RAD11    # 組織名
Organizational Unit Name (eg, section) []:                          # 組織の部門名 
Common Name (e.g. server FQDN or YOUR name) []:i36100t              # サーバのFQDN
Email Address []:yourname@example.com                               # 管理者のメールアドレス

サーバのFQDNとやらは、そのPCの hostname をそのまま入力したほうが良さそう。

念のためにアクセス権を変更。Ubuntu Linux 22.04 LTSの場合、最初から600になってた。

sudo chmod 600 /etc/ssl/private/vsftpd.pem

sudo vi /etc/vsftpd.conf

# 149行以降

rsa_cert_file=/etc/ssl/private/vsftpd.pem
rsa_private_key_file=/etc/ssl/private/vsftpd.pem
ssl_enable=YES
allow_anon_ssl=NO

ssl_ciphers=HIGH

# ssl_ciphers=ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA

# ssl_ciphers=kEECDH+AESGCM+AES128:kEECDH+AESGCM:kEECDH+AES128:kEECDH+AES:!aNULL:!eNULL:!LOW:!EXP

force_local_data_ssl=YES
force_local_logins_ssl=YES

ssl_tlsv1=YES
# ssl_tlsv1_1=YES
# ssl_tlsv1_2=YES
ssl_sslv2=NO
ssl_sslv3=NO

require_ssl_reuse=NO

strict_ssl_read_eof=NO

# Passive mode
pasv_enable=YES
# pasv_min_port=40000
# pasv_max_port=40030
pasv_min_port=60000
pasv_max_port=60010

vsftpdを再起動。

sudo systemctl restart vsftpd.service

これでFTPS接続ができるようになった。

FFFTP 1.98g でFTPSサーバ(vsftpd)にアクセス後、ファイルを転送してみたら以下のエラーが出た。

426 Failure reading network stream.

以下で解説されていた。

_vsftpdにアップロードしたら"426 Failure reading network stream."エラーが出るときの解決法 - Qiita

マニュアルのstrict_ssl_read_eofの項目にはDefault: NOと書いてあるがマニュアルの誤記で実際にはデフォルトYESである。

設定ファイルを変更して、strict_ssl_read_eof=NO を追記したところ、エラーは出なくなった。

sudo vi /etc/vsftpd.conf

strict_ssl_read_eof=NO

/etc/vsftpd.conf 内に記述する内容について、以下のような記述も見かけたが、実際に /etc/vsftpd.conf に記述してしまうと、Windows10 x64 22H2 + FFFTP 1.98g、FFFTP 2.00 x86、FileZilla 3.65.0 でFTPS接続できなくなってしまった。

ssl_sslv2=NO
ssl_sslv3=NO
ssl_tlsv1=YES
ssl_tlsv1_1=YES
ssl_tlsv1_2=YES

 ## DEBUG MESSAGE ON ! ##
 FFFTP Ver.2.00 Copyright(C) 1997-2010 Sota & cooperators.
 ...
 OpenSSLが読み込まれました.
 ----------------------------
 FTP over Explicit SSL/TLS (FTPES)を使用します.
 ホスト i36100t を探しています. (TCP/IPv4)
 ホスト i36100t (192.168.1.11 (21)) に接続しています. (TCP/IPv4)
 ## #### Connect: Error=10061
 接続できません. (TCP/IPv4)
 ## Skt=2236 : Socket closed.

以下の記述なら、FTPS接続ができた。何故。

ssl_tlsv1=YES
ssl_sslv2=NO
ssl_sslv3=NO

巷の解説記事では、以下のように、TLS 1.2 のみを有効にしている指定が多いのだけど…。

ssl_sslv2=NO
ssl_sslv3=NO
ssl_tlsv1=NO
ssl_tlsv1_1=NO
ssl_tlsv1_2=YES

皆、一体どのOS/FTPクライアントを使って動作確認してるのだろう…？

また、以下のような記述も見かけた。

ssl_ciphers=ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA

これを設定しても、FFFTP 1.98g、FileZilla 3.65.0 から接続できた。でもまあ、今回は以下の指定にしておく。

ssl_ciphers=HIGH

FFFTP 1.98g で、vsftpd にFTPS接続できた時の結果は以下。

FFFTP Ver.1.98g Copyright(C) 1997-2010 Sota & cooperators.
...
OpenSSLが読み込まれました.
----------------------------
FTP over Explicit SSL/TLS (FTPES)を使用します.
ホスト i36100t を探しています. (TCP/IPv4)
ホスト i36100t (192.168.1.11 (21)) に接続しています. (TCP/IPv4)
接続しました. (TCP/IPv4)
220 Welcome to blah FTP service.
>AUTH TLS
234 Proceed with negotiation.
>PBSZ 0
200 PBSZ set to 0.
>PROT P
200 PROT now Private.
>USER hogeuser
331 Please specify the password.
>PASS [xxxxxx]
230 Login successful.
>FEAT
211-Features:
 EPRT
 EPSV
 MDTM
 PASV
 PBSZ
 PROT
 REST STREAM
 SIZE
 TVFS
211 End
>TYPE A
200 Switching to ASCII mode.
>PASV
227 Entering Passive Mode (192,168,1,11,225,252).
ダウンロードのためにホスト 192.168.1.11 (57852) に接続しています. (TCP/IPv4)
接続しました. (TCP/IPv4)
>LIST
150 Here comes the directory listing.
226 Directory send OK.
...

この結果から、いくつかのことが分かる。

1. まず、FFFTP が「接続しました. (TCP/IPv4)」と言ってきた直後、FTPサーバから送られてきたウェルカムメッセージ、「220 Welcome to blah FTP service.」が表示される。
2. その直後、FTPクライアントは、「AUTH TLS」を送信する。暗号化通信関係のコマンドだろうか。サーバ側は「234 Proceed with negotiation.」を返してきて…。
3. その後、何度かやり取りして、暗号化通信が有効になるのだろう。そこでようやくFTPクライアントは、ユーザ名を「USER hogeuser」で送信する。
4. サーバから「331 Please specify the password.」が返ってきたら、FTPクライアントはパスワードを「PASS [xxxxxx]」で送信してやる。
5. パスワードが間違ってなければ、サーバは「230 Login successful.」を返してくる。
6. そこから、PASVモードを有効にしたり、ファイルの一覧を取得したり、といったやり取りになっていく。

つまり、正常にFTPS接続できているなら…。

• まずサーバは、ウェルカムメッセージを 220 で返してくる。
• そこでようやくFTPクライアントは「おい磯野、暗号化通信しようぜ！」的に「AUTH TLS」を送信する。
• ユーザ名やパスワードのやり取りをするのは、「AUTH TLS」が通った後の話。

まずはFFFTPのログに「AUTH TLS」が出てこないと話にならない。

「AUTH TLS」が出てきていないのに「ユーザ名やパスワードが間違ってませんか？」「パスワードが短すぎるのでは？」などと言い出すのは頓珍漢な話、ということになるのだろう。たぶん。

FileZilla 3.65.0 でアクセスした時の結果は以下。

状態:           i36100t のアドレスを解決中
状態:           [2405:6583:3200:b100:cdd6:8f8c:4b36:a61f]:21 に接続中...
状態:           接続を確立しました。ウェルカム メッセージを待っています...
レスポンス:     220 Welcome to blah FTP service.
コマンド:       AUTH TLS
レスポンス:     234 Proceed with negotiation.
状態:           TLS を初期化しています...
トレース:       TLS Handshake successful
トレース:       Protocol: TLS1.3, Key exchange: ECDHE-SECP256R1-RSA-PSS-RSAE-SHA384, Cipher: AES-256-GCM, MAC: AEAD, ALPN: ftp
状態:           TLS 接続が確立されました。
コマンド:       USER hogeuser
レスポンス:     331 Please specify the password.
コマンド:       PASS ********
レスポンス:     230 Login successful.
状態:           サーバーは non-ASCII の文字をサポートしていません。
コマンド:       PBSZ 0
レスポンス:     200 PBSZ set to 0.
コマンド:       PROT P
レスポンス:     200 PROT now Private.
状態:           ログインしました
トレース:       Measured latency of 4 ms
状態:           "/public_html/plala" のディレクトリ リストを取得中...
コマンド:       CWD /public_html/plala
レスポンス:     250 Directory successfully changed.
コマンド:       TYPE I
レスポンス:     200 Switching to Binary mode.
コマンド:       EPSV
レスポンス:     229 Entering Extended Passive Mode (|||60004|)
トレース:       Binding data connection source IP to control connection source IP 2405:6583:3200:b100:bc64:5065:7fdf:7cb5
トレース:       Trying to resume existing TLS session.
コマンド:       LIST
レスポンス:     150 Here comes the directory listing.
トレース:       TLS Handshake successful
トレース:       TLS Session resumed
トレース:       Protocol: TLS1.3, Key exchange: , Cipher: AES-256-GCM, MAC: AEAD, ALPN: 
レスポンス:     226 Directory send OK.
状態:           "/public_html/plala" のディレクトリ リストの表示成功

やはり、サーバから220が返ってきてから AUTH TLS を送ってる。FFFTPと違って、AUTH TLS を送って 234 が返ってきたら、すぐにユーザ名やパスワードを送って、その後、PBSZ 等を送ってるようだなと…。

ところで、今朝、再度ぷららのサイトのフォームから問い合わせをしてみたわけで…。以下のFFFTPのログも一緒につけて、「FTPS接続できません。何かこちらで試せることはありますか？」と尋ねてみたわけで…。

 FFFTP Ver.1.98g Copyright(C) 1997-2010 Sota & cooperators.
 ...
 OpenSSLが読み込まれました.
 ----------------------------
 FTP over Explicit SSL/TLS (FTPES)を使用します.
 ホスト 60.43.63.107 (21) に接続しています. (TCP/IPv4)
 接続しました. (TCP/IPv4)

 接続できません.

夕方頃、ぷららサポートセンターからメールで返事が来たわけで…。「パスワードが短すぎるのかもしれない。7文字以上にしてみてくれ」とのこと。

あのさあ。こちらから送ったFFFTPのログを眺めれば、そこじゃないと分かるだろうよ…。

もちろん、サポートさんの仰る通り、一応、念のため、パスワード変更も試してみたけれど、やはり状況は変わらず。当たり前だけど。

だって、パスワードを送るどころか、ユーザ名すらFTPクライアントから送ることができてないし、そもそも「おい磯野、暗号化通信しようぜ！ (AUTH TLS)」すらあちらに送れてないわけで…。「おい、いそ」と言い出す前にカツオ(www7.plala.or.jp)が電話ガチャン、みたいな。カツオのスマホの電話番号(IPアドレス)に電話してるから、おそらくカツオが電話を取ったんじゃねえかな、ぐらいは想像できるけど、取り付く島もないというか。

ログを見ればそういうことが分かるはずなんだけど、最初から見る気ゼロで答えてるんだろうな…。 *1

これはもう只の邪推と愚痴だけど。ぷららでは、サポート担当の人と、サーバの設定をしてる人の間で、連絡を取り合う手段が一切何もなくて、もう返事のしようもないのかもしれない。だから「パスワードを」とか言ってお茶を濁そう(?)としてるのかも。

あるいは、メールを返してきているのは、AIなのかもしれない…。どうも話が通じていない感があるし…。AIが相手では、そりゃFFFTPのログを見せても理解できるわけがないよな…。

しかし、だとしたら、よくないなあ。せっかくユーザがサービスの障害報告をしてくれても、対応をAIに任せてたら、しかるべき部署に連絡が一切行かなくなる。サービスが正常動作してないのに、そのことすら把握できなくなる。どう考えてもマズい。もっとも、AIに置き換えてしまえば人件費が、なんて上の人が安易に考える時点で、当の昔にサポート担当は他部署から完全に分離・断絶されているのだろうから、人間がやってもAIがやっても結局状況は変わらないのかもしれないけど…。

どうすりゃいいんだ、コレ。サポートに連絡してもこんな状態ではなあ…。このサービス、詰んでないか。

そもそも本来、「FTPS接続しか受け付けません」ではなくて…。

• Webブラウザ経由で更新できる仕組みも用意しておくとか (昔、Yahoo! GeoCities がそういう仕組みも提供してた)、
• 申請があったユーザだけはFTP接続を許可するとか、

他のアクセス方法も何かしら用意しておかないといかんだろう…。だって、ユーザがファイルを一切更新できない状況に追い込まれかねないわけで。何かしらの救済手段を用意してから切り替えないと。

動作確認が取れているFTPクライアントの種類とバージョンをサポートページに列挙してないのもなんだかなあ。いやまあ、どうせほとんど動作確認してないから書きようもないんだろうけど。今では入手できない上に暗号化通信機能を持ってないFFFTPのバージョンを平気でサイトに書いちゃってるぐらいだし。

それにしても、どうして急にこんな余計なことを…。セキュリティ強化以前に、ユーザがサーバにアクセスできなくなったら、それはもうサービスとして成立しないだろう…。 *2

pygame を使って xscreensaver用スクリーンセーバを作成する場合、現時点では制約があるっぽい。pygame は 1.x.x を使わないといけない。pygame 2.x.x では動作しない可能性が高い。

何故かと言うと…。

• pygame 1.x.x は SDL 1.x を利用して描画その他を行う。
• pygame 2.x.x は SDL 2.x を利用して描画その他を行う。
• SDL 1.x なら、環境変数 SDL_VIDEO_DRIVER と SDL_WINDOWID を設定することで、SDL の動作を制御することができる。
• SDL 2.x は、環境変数 SDL_VIDEO_DRIVER と SDL_WINDOWID を設定しても反映されない。らしい。確認してないけどそういう話を見かけた。

_pygameでxscreensaver用スクリーンセーバを作れないものか - mieki256's diary
_pygameでスクリーンセーバを作りたいのだけど - mieki256's diary

• Ubuntu Linux 20.04 LTS は、python*-pygame で pygame 1.9.6 がインストールされるので大丈夫。
• Ubuntu Linux 22.04 LTS は、python3-pygame で pygame 2.1.2 がインストールされるので、今回のスクリプトはおそらく動かない。

もう一つ。今回のスクリプトを動かすには xwininfo というツールが必要になる。Ubuntu Linux の場合、x11-utils というパッケージに入ってる。

※ 2022/08/06追記。Ubuntu Linux 22.04 LTS を VMware Player上でインストールして動作確認してみたところ、やはり Ubuntu 22.04 + pygame 2.1.2 では正常動作しなかった。

Ubuntu Linux 20.04 LTS の場合、以下で pygame 1.9.6 をインストールできる。

sudo apt install python-pygame
sudo apt install python3-pygame

• python-pygame は、Python 2.7 用のパッケージ。
• python3-pygame は、Python 3.x 用のパッケージ。

xwininfo は、以下でインストールできる。

sudo apt install x11-utils

ソースは以下。処理内容は、ウインドウ内でいくつかのボールが跳ね回るだけのもの。

_xscrsavpygame.py

import os
import sys
import math
import platform
import random
import subprocess
import re

IMG_FILE = "ball_64x64.png"
FPS = 60


class Ball:

    def __init__(self, img, scrw, scrh, t):
        self.img = img
        self.img_w = img.get_width()
        self.img_h = img.get_height()
        self.scrw = scrw
        self.scrh = scrh

        self.x = random.randint(16, scrw - self.img_w - 16)
        self.y = random.randint(16, scrh - self.img_h - 16)

        ang = random.randint(0, 360)
        spd = float(scrw) / t
        self.dx = spd * math.cos(math.radians(ang))
        self.dy = spd * math.sin(math.radians(ang))

    def update(self):
        self.x += self.dx
        self.y += self.dy
        if self.x <= 0 or self.x >= self.scrw - self.img_w:
            self.dx *= -1
        if self.y <= 0 or self.y >= self.scrh - self.img_h:
            self.dy *= -1

    def draw(self, screen):
        screen.blit(self.img, (self.x, self.y))


def main():
    if platform.system() == "Windows":
        os.environ["SDL_VIDEODRIVER"] = "windib"
        print("$SDL_VIDEODRIVER = %s" % os.environ["SDL_VIDEODRIVER"])
    else:
        # Linux or Darwin
        # os.environ["SDL_VIDEODRIVER"] = "x11"
        pass

    if "XSCREENSAVER_WINDOW" in os.environ:
        # xscreensaver
        hwnd = os.environ["XSCREENSAVER_WINDOW"]
        os.environ["SDL_WINDOWID"] = str(int(hwnd, 16))
        # print("$XSCREENSAVER_WINDOW = %s" % os.environ["XSCREENSAVER_WINDOW"])
        # print("$SDL_WINDOWID = %s" % os.environ["SDL_WINDOWID"])

        # get window size using xwininfo
        cmd = ["xwininfo", "-id", os.environ["XSCREENSAVER_WINDOW"]]
        p = subprocess.Popen(
            cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
        ret = str(p.communicate())
        size_info = re.search('Width:\s+(\d+)[^H]+Height:\s+(\d+)', ret)
        w, h = size_info.groups()
        scrw = int(w)
        scrh = int(h)
    else:
        # not xscreensaver
        hwnd = None
        scrw, scrh = 512, 256

    import pygame

    # pygame.init()
    pygame.display.init()

    # print("driver = %s" % pygame.display.get_driver())
    # print("pygame.display.get_wm_info()")
    # print(pygame.display.get_wm_info())
    # print("pygame.display.Info()")
    # print(pygame.display.Info())

    screen = pygame.display.set_mode((scrw, scrh))

    # pygame.display.set_caption('xscreensaver by pygame')

    # load image
    base_dir = os.path.realpath(os.path.dirname(__file__))
    file_path = os.path.join(base_dir, IMG_FILE)

    img = pygame.image.load(file_path).convert()
    img.set_colorkey(img.get_at((0, 0)), pygame.RLEACCEL)

    # create balls
    balls = []
    for i in range(16):
        balls.append(Ball(img, scrw, scrh, 60.0 * 3.0))

    clock = pygame.time.Clock()
    looping = True

    while looping:
        # main loop

        # event check
        for event in pygame.event.get():
            if event.type == pygame.QUIT:
                looping = False
            if event.type == pygame.KEYDOWN:
                if event.key == pygame.K_ESCAPE or event.key == pygame.K_q:
                    looping = False

        if not looping:
            break

        # move balls
        for obj in balls:
            obj.update()

        # fill bg
        screen.fill((0, 0, 0))

        # draw balls
        for obj in balls:
            obj.draw(screen)

        pygame.display.flip()
        clock.tick(FPS)

    pygame.quit()
    sys.exit()


if __name__ == '__main__':
    main()

使用画像は以下。

_ball_64x64.png

まずは xscreensaver を経由させずに動作確認してみる。

• xscrsavpygame.py と ball_64x64.png を任意の場所に置く。
• chmod +x xscrsavpygame.py で実行権限をつける。
• ./xscrsavpygame.py と打てば、pygameのウインドウが開いてボールが跳ね回るはず。

xscreensaver を経由させて実行してみる。xscreensaver の設定ファイル、~/.xscreensaver を編集。

programs:                                                                     \
                 "PYGAMESAVER"                                                \
                                  /home/USERNAME/hoge/fuga/xscrsavpygame.py \n\
                                maze -root                                  \n\

• TAB幅は8文字、TAB文字有効で編集を行う。
• 「programs:」以下に、追加するスクリーンセーバの名前と、Pythonスクリプトのパスを記述。
• 行の最後が「\」なら継続行、「\n\」ならスクリーンセーバ1つ分の記述が終わったことを示す、のだと思う。

xscreensaverの設定画面を表示して、上記で追加した「PYGAMESAVER」を選ぶと、プレビュー画面の中でもボールが跳ね回ってくれた。「プレビュー」ボタンをクリックしたら、フルスクリーンでテスト表示された。

これで、C/C++ を使わずに Python + pygame 1.x.x を使っても、xscreensaver用のスクリーンセーバを書けそうだと分かった。

以下、スクリプトソースについて少々解説。

環境変数 XSCREENSAVER_WINDOW 関係は、ruby-gtk2 で作ったスクリーンセーバの解説が参考になるかと。

_ruby-gtk2を使ってxscreensaver用スクリーンセーバを作る

環境変数 XSCREENSAVER_WINDOW が存在するかどうかは、以下の記述で調べられる。

if "XSCREENSAVER_WINDOW" in os.environ:
    # xscreensaver
    hwnd = os.environ["XSCREENSAVER_WINDOW"]
else:
    # not xscreensaver
    pass

pygame 1.x.x は、環境変数 SDL_WINDOWID にウインドウハンドルを設定してある状態で pygame.display.init() もしくは pygame.init() を呼ぶと、SDL_WINDOWID で指定されたウインドウで pygame のウインドウ(SDL 1.x のウインドウ)を作成してくれる。

また、環境変数 SDL_VIDEODRIVER に x11 や windib 等を設定すれば、どのビデオドライバーを使って描画するかを変更できる。まあ、pygame 1.x.x の場合、Linux は x11、Windows は windib がデフォルトで利用されるようではあるけれど…。

ただし、注意点がある。環境変数 SDL_WINDOWID や SDL_VIDEODRIVER の設定は、import pygame を呼ぶ前にしておかないといけない。import pygame を呼んでから、それらの環境変数を変更しても反映されない、らしい。試してないけど。

指定されたウインドウハンドル(ウインドウID)のウインドウから、サイズ(横幅と縦幅)を取得したかったのだけど、Python で取得する方法が分からなくて、かなりハマった…。先日書いた条件に、もう一つ条件を追加しないといかんなと…。

• 「環境変数 XSCREENSAVER_WINDOW があるかどうかを調べることができて」
• 「XSCREENSAVER_WINDOW で指定されたウインドウハンドルを使って描画ができて」
• 「XSCREENSAVER_WINDOW で指定されたウインドウのサイズを取得できる」 ← New!

そんな言語/フレームワーク/プログラムなら、xscreensaver用スクリーンセーバが作れますよ、みたいな。

ググってみた感じでは、pygame で環境変数 SDL_WINDOWID を使う事例として、「tkinter の Frame の中に pygame のウインドウを埋め込むサンプル」がほとんどだったのだけど。どのサンプルもウインドウサイズを事前に固定してるものばかり。どうやら Python のみを使ってウインドウサイズを取得するのは難しい模様。

Python でダメなら、他のツールではどうだろう。X11関連ツールの中にウインドウ情報を取得するツールがあったりしないか ―― と探してみたら、xwininfo というツールがあると知った。

_Ubuntu xwininfoコマンド その1 - ウィンドウの情報を調べる - kledgeb

このツールを Python から呼び出せば目的を果たせるのではないか。ググってみたら、そのものズバリ、Python から xwininfo を利用する事例が以下で紹介されていた。ありがたや。

_pythonで端末画面を保存する。 - Kinaconの技術ブログ
_pythonでウィンドウ座標を取得する - キラキラするのが筋トレです

そんなわけで、環境変数 XSCREENSAVER_WINDOW で指定されたウインドウのサイズを取得する記述は以下になる。

import subprocess
import re

# get window size using xwininfo
cmd = ["xwininfo", "-id", os.environ["XSCREENSAVER_WINDOW"]]
p = subprocess.Popen(
    cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
ret = str(p.communicate())
size_info = re.search('Width:\s+(\d+)[^H]+Height:\s+(\d+)', ret)
w, h = size_info.groups()
scrw = int(w)
scrh = int(h)

pygameスクリプトから画像を読み込むあたりでもハマった。スクリプトが置いてある場所をカレントディレクトリにした状態で動作確認している分には動くのだけど、別のカレントディレクトリから実行した際に「画像ファイルが読み込めない」と言われてしまった。

どうやら、スクリプトの置いてあるディレクトリを取得して、それを利用して画像のファイルパスを求めないといかんようだなと…。記述は以下。

import os
import pygame

# load image
base_dir = os.path.realpath(os.path.dirname(__file__))
file_path = os.path.join(base_dir, "hoge.png")

img = pygame.image.load(file_path).convert()
img.set_colorkey(img.get_at((0, 0)), pygame.RLEACCEL)

• __file__ にスクリプトのファイルパスが入っているから、それを利用してディレクトリを求める。
• os.path.join() で、ディレクトリと画像ファイル名を結合する。

_Pythonで実行中のファイルの場所（パス）を取得する__file__ | note.nkmk.me
_Python スクリプトが格納されているディレクトリのパスを取得する - まくまくPythonノート

pygame 2.x.x (Ubuntu Linux 22.04 LTS) では本当に動かないのかどうかがちょっと気になる。Ubuntu 22.04 LTS をどこかにインストールして実験してみないとダメかな…。

ケーズデンキに寄って、audio-technica ATH-P100M と、maxel製CR2032 x 1個を購入。

今までもTV視聴用に ATH-P100M を使ってたけどスポンジ部分がボロボロになったので買い替え。

_Windows10 V2004のシステムイメージの作成が0x80780119で失敗する【Ver2004】 - マイクロソフト コミュニティ

50MBというのは明らかに少ない。Windows10 1909までは500MB以上取られていたのに、2004では50MBになって、しかもシステムイメージの作成でエラーが出るらしい。

一応、某ツールを利用して、最初のパーティションを1GB近く確保した状態にしておいた。果たしてこの処置が、後で効いてくるのかどうか…。どうなんだろうなあ…。

この手のソレは、横からの構図をメインで見せるのが一般的、のような気がする。Moho Pro 12 を使って試してみたり。



昔の2DのTVゲームの世界で「多重スクロール」と呼ばれてた、こういった背景の見せ方をすれば、右か左に進んでると伝わるよなと。

ちなみに、「千銃士」の該当回が放送された数日後に、「天狼 Sirius the Jaeger」というアニメを見ていたら、そちらでも列車のシーンがあって。「天狼」は、真面目な映像制作に定評のあるP.A. Works作品なだけあって、不自然さを感じるカットが一切無くて唸ったのだけど。どうやら車内をかすかにローリングさせることで、動いてる感が増すようだなと気付かされたり。



ただ、ローリングのさせ方が分からない…。自分がやってみたコレは、どうも不自然というか…。どうやら「ガタン、ガタン」という規則的な揺れ方だけでは何かが足りなくて。ランダムにノイズが入る動きと言うか…。録画データを消しちゃったから確認もできない…。

一点透視っぽい構図なら、やはり背景も奥行きを伴う動きになってないといかんのではないか。ていうか、「天狼」がそういう処理をしていたわけで。たぶん、こうかな…。



要は、以下のように、 _ビルボード を動かしてやればいいのだろう…。



ソースネクストが時々2,980円で売ってたりする Moho 12 pro ですらこういうことができるのだから、プロが使ってるAEなら、もっとソレらしい見せ方ができるんだろうなと…。AE触ったことないから分からんけど。

作業をしているうちに思い出したけど。「魔女の宅急便」では ―― 「魔女宅」は車窓の風景ではなく列車の屋根の上からの風景だったけど ―― 背景動画で処理していたなと…。あの頃はセルとフィルムしか使えなかったから、背景を奥行きを伴う見た目で動かしたい＝背景動画しかないでしょ、だったのだろうなと。

デジタル制作が当たり前になったことで、セルや _BOOK を、Z値に基づいて何枚でも動かせるようになったわけで…。 _マルチプレーン・カメラ では重ねる枚数にもカメラを動かせる距離にも制限があっただろうけど、当時と比べたら随分とやれることが増えたはずだよなと…。

なのに、「千銃士」のアレは無いよなあ…。まあ、時間が無かったんだろうけど…。

「天狼」を見ていて気付いたけれど、構図を工夫していた気がするなと。

例えば、カメラ位置を低くして、椅子に座ってるキャラを下から捉えていたりして。たしかこんな感じ。



この構図だと、車窓には空しか入らない。なんだかコストパフォーマンス(?)が良さそうだなと…。

更に、時々鉄塔が窓の外を流れていくようにしていたあたりも上手いなと。「天狼」で走ってた列車はSLだからアレだけど、今時の列車ならまず電車だろうから、電気を送るための電線、を設置するための鉄塔、っぽいものが必ず一定間隔で視界に入るはずで。時々鉄塔が流れていくだけでも、進行方向が分かるし、結構な速度で列車が走ってることも伝わるよなと。しかも、常時画面に出しておかなければいけないわけでもないから、なんとなく精神的に楽なところもありそうな。

上記の構図はカメラが低い位置にあったけど、逆に、カメラ位置を高くして、キャラを上から捉えているカットもあった。まあ、以下のソレは、真横から見た構図に近いのだけど…。



この構図なら、車窓には地面しか入らない。地面だけなら、砂利が描かれたテクスチャでも置いて動かしとけば…。 *1

また、これは「天狼」じゃなくて、「プリンセス・プリンシパル」の列車回のキャプ画像を眺めていて気付いたことだけど。車内の窓が、斜めになって見えている構図のカットは、窓を白く光らせてそこだけ白飛びさせちゃう手もあるなと。それなら、背景の動かし方なんて考えなくて済む…。

考えてみたら、実写ドラマで、列車の客室シーンをスタジオ内のセットで撮影する時は、えてしてこの手を使うよなと…。車窓から見える風景を、一々再現してられないし。まずは電車が走ってるカットを映して状況説明してから、その後はずっと、車内から見える車外の風景は白飛び状態で通す。とか。

きっと他にも色々な小技があるのだろう…。

• 新海作品は高い確率で電車が出てくる印象があるけど、どんな処理をしていただろう？
• 「鋼鉄城のカバネリ」は列車が出ないと話にならないけど、どんな見せ方をしていたか？
• 「千と千尋の神隠し」「風立ちぬ」の列車シーンは、どういう処理をしていたか？

これからは、そういうシーンが出てきたら、ちょっと意識して見てみようかな…と。

一応置いておきます。CC0 / Public Domain ってことで。使い道なさそうだけど。

_train_room03_render03_edit4.png
_train_room04_render01_edit2.png
_train_room05_render01_edit3.png
_train_room05b_render01_edit2.png
_01sky.png
_02mountain.png
_03forest.png
_bg_moutain_h720.jpg
_grass1.png
_grass2.png
_grass3.png
_grass4.png
_grass5.png
_grass6.png
_grass7.png
_rocks_tex_c02.jpg

室内っぽい画像は Sweet Home 3D で作成。草っぽい画像は Krita で作成。どっちも無料で利用できるソフトです。

_Sweet Home 3D
_Krita | デジタルでのお絵描きと創造の自由を

只の思考メモです。

「塗りの手間を増やすことで絵の情報量を増やして、他のエンターテイメント作品の映像レベルに近づける試み」という話が出ていて、そのあたり興味深かったり。たしかにそういう方向で売りを作っていくのもアリだよな、と思うのだけど。その方向って「アニメ」にとっては正しいのだろうかと、個人的には疑問を持ってる状態で。

アニメ映像は、元々は作業量の都合で、線とベタ塗りという情報量の少ない画作りをしてたわけだけど。ある意味、怪我の功名で、実写映像に比べると視聴者が1コマ1コマを認識しやすくなってた気がするわけで。それにより、動きについての情報量の補完を、視聴者の脳内でしやすかったあたりがアニメ映像の魅力だったのではなかっただろうか、などと自分は邪推(?)していたりするわけで。例えば、金田パースとか板野サーカスとか、そんなところがあったのではないかと。

昨今、3DCGでロボット等が描かれて、つまりは手描きで実現しづらいほどの情報量が各コマに込められていて、しかもそれらが今までのアニメ映像の文脈に沿った、誇張された動きをしていたりするのだけど。ぶっちゃけ、各カットでどんな動きをしているのか分からないというか ―― 下手すると、ストーリー上伝達しておかなければいけないアクションすら、見ていて理解できない・認識できない時があって。1コマ1コマの視覚情報が多過ぎて、各コマの間にどんなコマが存在しているのか、脳の補完処理能力を超えてしまってるというか。 *1

要は、動いた時に魅力を感じる絵と、静止画で魅力を感じる絵は違う、という話なのでしょうけど。

とは言え、昔のアニメのような絵の情報量にしてしまうと、映像中から1コマ抜き出して静止画を提示した時、他作品よりみすぼらしく見えてしまって商売上はよろしくないだろうな、とも。Webにしろ、印刷媒体にしろ、静止画を見せて宣伝する場面が大半だから…。そんな状況を踏まえると、各コマの情報量を増やす方向性は商品訴求力が高い、という話になるのかな、てなところも。

それとはまた別に。絵の情報量を増やすという点では、最終的には3DCGに敵わないだろうという問題もあるよなと。例えば各ポリゴンに、手塗り感があるテクスチャを割り当てて動かせば、それだけでもパッと見は(あくまでパッと見は、ですけど)手塗りっぽい見た目になっちゃうし。それを各コマ、手描き・手作業で作ってみても、果たして勝負になるのかな、てな不安も。人件費が安い国ならそういう作りもアリだろうけど、日本はそうではないわけで。 *2 いやまあ、現時点では、他作品でそういうことをしてないから、今なら商品のアピールポイントになるんだけど。将来的には、さてどうかな、みたいな話で。

でも、他スタジオ・他作品がやってないことにチャレンジしてみる姿勢は称賛されてしかるべき、だよなと。

おそらく、作り終った時に、「やってはみたけど、これは現実的じゃなかった…無理があった…」と悟ることもできそうだし。動画や仕上げの人に意見を聞けば、作業する上で改善すべきポイントが見出せそうだし。「ここをコンピュータで自動化できれば現実的な作業になる」てなところも見えてくるんじゃないのか、そしてそれは、実際にやってみたからこそ見えてきた、てな展開もあるんだろう、などと素人考えで妄想(?)を。

まあ、見ていてそんなことをアレコレ考えてしまったので、面白いというか、興味深い特番でした。

評論家さんに、作品の特徴について語ってもらうのって、大変グーですな…。声優さん達のたわいもないお喋りを流すよりは、個人的にグーです。ただ、できれば、絶賛だけではなく、問題点も語ってほしかった気もしたり。いや、番宣相当の特番でソレやってどうするって言われそうだけど、長所と短所を両方語ると、見てる人の思考を刺激できるわけで、それはそれで作品について考える面白さを提供することに繋がるかも、てな気もするのだけど甘いかな。

_emacsの矩形選択モード紹介 | tech.kayac.com - KAYAC engineers' blog
_GNU Emacsマニュアル: Transient Mark
_コピーアンドペーストを使いこなす(松山智大) - ありえるえりあ

距離的に大丈夫かと思ったけど全然甘かった。腕が真っ赤な状態に。夜になって痛みまで出てきた。ピンチ。

優先度の高いパッチだけでも40個ある…。IE8やWMP11等を入れていったら更にパッチがガンガン増えていく…。

いや、数の多さはともかく、Windows Updateサイトへアクセスしたときの速度が異様に遅いのがとにかく問題で。どうしてこんなにページが出てくるのが遅いのだろう。どうなってるの？＞MS。

CDイメージ・DVDイメージ等で入手できないものかなあ。例えばウチの場合、親父さんや妹のPCも合わせると、XP機が4台、Vista機が1台あるわけだけど。DVDイメージ等を1回DLすれば1〜2回の転送量で済むはずのところが、5回分アクセスしてるわけで。コレ、無駄じゃないか？

MSは、Windows Update のあり方を少し見直したほうがいいのではないか。と思ったりもしたのだけど実際どうなんだろう。つーか Windows Updateの作業だけで、もう6時間ぐらいかかってるんだけど、まだ終わる気配が見えない。どうなってるの？＞MS。

WIndows Update中に、「再起動してくれや」メッセージが出たのでうっかり「再起動する」のボタンを押したら、正常終了する前に無理矢理終了・再起動をしたようで、チェックディスクが始まってしまった。なんてこった。セットアップ時は迂闊に再起動してはいけなかった、ということか。それともまさか初期不良か。

Memtest86+ 2.11 をUSBメモリから起動できるようにして、メモリチェック。

DOSは FreeDos を使った。起動できるUSBメモリの作成には HP USB Disk Storage Format Tool を使用。Memtest86+ は mt211.exe を選択。

3回ほどpassしたから、メモリは正常なのだろう。たぶん。おそらく。

写真で作れるという案に感心。誰かが描いた画ではなく、自分で撮った写真を使えることで、独自性を出しやすい予感。ただ、作例を眺めた限りでは、枠の有無、吹き出しの位置、台詞の横書き・縦書き等がしっくりこなくてなんだかちょっと。もう一点気になるのは、人物写真は何かにつけて使いづらいこと。4コマ漫画＝人物が会話してる、という状況が多いわけだけど、登場人物の写真を用意するあたり、結構障害になるかもしれない。…いや、フリー写真素材を活用すれば、そのあたりクリアできるか。

試用してみたり。脈絡のない写真を4枚並べるという作業に面白さを感じた。というか、 _外人4コマ の感覚に近いのか。台詞の入れ方・配置の仕方が今一つわからなかったけど、かえって写真のみで構成したほうが面白いかもしれん。ただ、結果画像をjpegでしか保存できないとか、左右に余白ができてしまうのは、なんだかちょっと。何か割り切った作りになってる感も。操作の容易さと機能の豊富さは、トレードオフなんだろうか。

Windows機なら、ペイントは標準で入ってるし。導入コストはかからない。てっとり早く試せるよな、となんとなく思ったのでクリップ。

PowerPoint等のプレゼンソフト操作習得の学習テーマとして、4コマ漫画を作成してみせる事例、かしら。

4コマに特化してるわけではなさそうだけど、メールで送るあたり、なるほどと。

_コミックツール というソフトもあるらしいのだが、 _Win95/98系でしか動かない ということになってるらしい。

「4コマ漫画BBS」なるcgiスクリプトも存在するらしい。しかし、配布元ページには辿りつけなかった。

なんだか気になる。

様々なレイアウトが選べるらしきあたり、興味が湧いた。

「4コマフォトメール」は、セリフやスタンプ・フレームなどを使って最大4コマで構成される物語が作成できるというもの。映画監督気分でオリジナルストーリーを作成できるという。作成した物語は、iモード・J-スカイ・EZweb、パソコンにメール送信できる。

デジテム、顔のパーツを選んで似顔絵が作成できるJ-スカイサイト より

_コミック＠メール公式ホームページ

携帯で作成もできるのか。

_最近のセリフ - はてなセリフ
_ヘルプ - はてなセリフ

任意の1コマに台詞だけ打ち込めるサービス、なのかしら？ 自分、よくわかってないんですが。

考えてみれば、4コマ漫画を作成したら誰かに見せたくなるのが当たり前であろうし。どうせ最後はネットにアップするのだから、最初からネット上で作ってしまおう・ネットサービスとして提供しよう、というのも至極当然の流れか。

同様のことは、お絵描きBBSなどでも言えるのかも。ローカルで描いて、画像変換して、掲示板にアップするより、最初から掲示板で描いてしまったほうが面倒臭くない。

そのあたりを考えていくと、他にも、ネットに移行・サービス提供できるものがあるのかもしれず。

• 最終的にはネットにアップすることが前提のもの。
• 尚且つ、現在はローカルで作業することが主となっているもの。

…具体例は即座に思いつかないけど。

注意点は、「ネットにアップすることが前提のもの」あたりかも。ローカルに残しておくことが前提のものを、ネット上でどうこうするのは、たぶん受けが悪い。例えば、社内の重要文書をネットサービスで作成する等は、流出の危険性もあるし、あまり受けないであろう予感。

いや、無理矢理ネットにアップすることで、予想外の効果が得られる可能性もあるか。例えば、日記系のコンテンツなどもソレだろうし。昔の感覚なら、「自分の日記を人様に見せて何が面白いんだ？」ということになるはずだが、実際やってみると、ネット全体で色々な効果が得られたわけで。「こんなものをアップしてどうするの？」といった印象のものが、意外と面白かったりする、てなこともあったりするのかも。

なんだか面白そう…。

24bit画像のまま、アニメgif作成ツール giam に渡すと、出力したアニメgifのあちこちに黒い点が入ってしまう。OPTPiXで、250色ぐらいで減色して、 *1 giam に渡してコマサイズ最適化等をしたら上手くいった、ように見える。

沖縄の写真をフリー素材として販売してるサイト。なるほど、配布もしつつ、同時に商売にもしてしまうと。これは賢いやり方かも。感心。

「南京大虐殺はなかった」とか、「アポロは月に行ってない」とか、そういうことを口にする人が居る世の中だもの。「広島・長崎に原爆は落ちてない」とか「落ちたけどあそこまで悲惨な状況じゃない。あれは捏造だ」とか言い始める人が居てもおかしくないかもなと、そんなことをぼんやりと。特に、中国人、韓国人、あるいはアメリカ人あたりがそんなことを言い始めたりして。…などとバカ妄想。

被爆者が「謝ってほしい」と主張し、アメリカ人科学者は「謝らない」と返すの図。

アメリカ人科学者は、原爆の被害も、戦時における他の殺戮行為と大小の差はあれ本質的には同じ「ヒドイこと」という認識をしてるように見えた。また、原爆の存在・行使が戦争終結を早めたというロジックを信じているようでもあったし。「リメンバー・パールハーバー」という言葉があることを被爆者二人に伝えていたし、戦時中は非戦闘員など居ないという認識も述べていたし、「謝るなら貴方達が謝るべきではないか」とも言っていた。

個人的には、謝罪を求める被爆者二人のほうがおかしい気がした。科学者の言い分のほうが、たぶん正しい。日本人は自分たちが加害者であったことを忘れてる。というか、内実はどうであれ、加害者として認識されてしかるべき国策を、自分たちが選択していった事実を、あまりに軽く考えすぎてるような気がする。 *1

「真珠湾攻撃を受けたときのアメリカ人の気持ちを理解しろ」とアメリカ人科学者から要求されたとして。被爆者がそういった気持ちを理解できるなら、アメリカ人科学者も、被爆者が原爆によって受けた悲しみを理解することができる可能性はあったのかもしれない。しかし、「リメンバー・パールハーバー」を口にする者の心情が理解できるなら、原爆を作った人間に対して謝罪を求めるような愚行もしないだろう。…謝罪を求めてる時点で、その被爆者も、相手の気持ちを理解できてないし、理解しようともしていない。であれば、アメリカ人科学者も同じだ。被爆者の気持ちを理解できる可能性など期待できない。…何十年も経過したのに、また同じことを繰り返してるような気がする。まあ、面と向かって話ができるようになっただけ、状況は改善してるのかもしれんけど。

何故、日本は、原爆の恐ろしさを理解してもらいたいと要求するのか。関係者に謝罪してもらうためではないだろう。「二度と同じことを繰り返さないために」、理解してもらうのではないのか。原爆の恐ろしさを理解してもらうのは手段であって。その手段によって達成したい目的・目標は、「二度と同じことを繰り返さない」こと。それを考えたとき、謝罪を求める被爆者の姿が、おかしく見えてしまったのでした。それは不毛な要求というか、目的を見失ってる ―― あるいは未だに目的が判ってないが故の、変な要求だよなぁ。 *2

_先生と呼ばれるほどの……（前編）
_先生と呼ばれるほどの……（後編）
すがやみつる先生のトラウマが元で、アシスタントさんが新たなトラウマを作ってしまったという話。それを解決するために、すがや先生は自分のトラウマを飲み込んだ。…ええお人やわぁ。(つД｀) こういう方こそ、周囲から尊敬の念をこめて、先生と呼ばれるに値する御仁ではないかと思ったりもして。