0.3.1 リリース候補、テストしてください

37 件のメッセージ BitcoinTalk サトシ・ナカモト, andy_3_913, Insti, jimbobway, ラズロ・ハニエツ, 0x0, knightmb, db, RHorning, adavid, lachesis, BioMike 2010年7月15日 — 2010年7月17日

これはバグ修正のメンテナンスリリースだ。SourceForge にアップロード済みだ。Mac OS X には修正の必要がなかったため、更新は不要だ。0.3.0 のままで問題ない。

ダウンロードリンクは bitcoin.org にある。

変更点:

  • Tiago Faria によるポルトガル語翻訳を追加 Windows
  • ユーザー名に非 ASCII 文字が含まれている場合の 22DbRunRecoveryException の修正 Linux
  • ラズロによる生成スレッドを最低優先度に下げる修正
  • libcrypto のリンク問題が発生している場合の修正
  • ギャビン・アンドレセンによる「ウィンドウシステム起動時に開始」オプションの実装

これはバグ修正のメンテナンスリリースだ。SourceForge にアップロード済みだ。Mac OS X には修正が不要だったため、更新する必要はない。0.3.0 のままで問題ない。

ダウンロードリンクは bitcoin.org にある。

変更点:

  • Tiago Faria によるポルトガル語翻訳を追加 Windows
  • ユーザー名に ASCII 以外の文字が含まれている場合の 22DbRunRecoveryException の修正 Linux
  • ラズロによる生成スレッドを最低優先度に下げる修正
  • libcrypto のリンクに問題がある場合の修正
  • ギャビン・アンドレセンによる「ウィンドウシステム起動時に開始」オプションの実装
andy_3_913 2010年7月15日 17:11 UTC 原文 ·

サトシ、 インストール前にバックアップが必要だろうか?

まあ、バックアップして損はないし、定期的にバックアップするのは良い習慣だが、いいえ、このインストール前にバックアップは必須ではない。

andy_3_913 2010年7月15日 17:25 UTC 原文 ·
サトシ・ナカモトの投稿(2010年7月15日 08:23 UTC)

まあ、バックアップして損はないし、定期的にバックアップするのは良い習慣だが、いいえ、このインストール前にバックアップは必須ではない。

了解 😊

もう数日間計算し続けているから、最初からやり直したくないんだ!!!!

Insti 2010年7月15日 17:30 UTC 原文 ·

コイン生成する前にコンピューターに完全なブロックチェーンが必要だ。まだブロックチェーンの途中なら、まだコインを生成できない。

何ブロックまで来ているか確認するには、ステータスバーの下部にある吹き出しにマウスを合わせればいい。 または https://www.bitcoin.org/en/network でネットワーク全体のブロック数を確認できる。

andy_3_913 2010年7月15日 17:32 UTC 原文 ·

こちらでは、 改善されなかった。 同じ症状のまま。ただし belownormal に設定できない。アクセスが拒否される!!

編集: おかしなことに、 Firefox や Windows エクスプローラーはすぐに開く。少しもたつくが。しかし gomez のようなものは開かない!

特定の問題があるとは思わない。多くのものを同時に実行していて、メモリーが一杯になりページファイルを使用しているためにシステムが遅くなっているのだと思う。生成を停止すると CPU が 0%に下がることを確認されたので、CPU 使用率は確実にすべてアイドル優先度だ。0.3.1 にはこれらの問題に影響する変更は含まれていない。

jimbobway 2010年7月15日 18:04 UTC 原文 ·

インストール、再インストール、あるいはバックアップのせいでウォレットを失うことが本当に怖い。別のスレッドでは、あるユーザーがウォレットをバックアップした結果、自分の bitcoin をすべて、永遠に失ってしまった。

このスレッドを見てくれ:http://bitcointalk.org/index.php?topic=359.0

バックアップとリストアを正しく行うための手順を一歩ずつまとめてもらえないだろうか。

あいつは自分のコインを二重支払いしようとして、システムがそれを防いだんだ。その過程で、ウォレットファイルを入れ替えてるうちに片方を失くして、使っていなかったコインも失くしちゃったんだよ。

wallet.dat をバックアップするだけで十分だ。bitcoin faucet でもらえる無料コインで試してみればいい。

0x0 2010年7月15日 18:16 UTC 原文 ·

このビルドで俺の問題は解決した(追加情報はこのトピックを参照 http://bitcointalk.org/index.php?topic=373.0 )。

andy_3_913 2010年7月15日 18:23 UTC 原文 ·
サトシ・ナカモトの投稿(2010年7月15日 17:56 UTC)

特定の問題があるとは思わない。多くのものを同時に実行していて、メモリーが一杯になりページファイルを使用しているためにシステムが遅くなっているのだと思う。生成を停止すると CPU が 0%に下がることを確認されたので、CPU 使用率は確実にすべてアイドル優先度だ。0.3.1 にはこれらの問題に影響する変更は含まれていない。

ありえる。 だが、攻撃的に言っているわけではないが、こういう類のパフォーマンス低下は bitcoin を動かしているときにしか出ていない。 BOINC はアクティブだが、現在はプロジェクトは何も動かしていない。

メモリー 3GB、 キャッシュ 1524、 利用可能 1573、 空き 108。 bitcoin を止めるつもりはないが、少し奇妙に思える 😊

何か送ってほしいものはあるか?

追伸…… bitcoin 実行中に余分なディスクのスラッシングは気づかなかった 😊

knightmb 2010年7月15日 19:37 UTC 原文 ·

Windows 上では、コイン生成の優先度は依然として通常のままだ。BitCoin をコイン生成モードで実行し、CPU を全部食い尽くすもの(例えば CPU Hog: http://www.microtask.ca/cpuhog.html)を起動すると、BitCoin (http://www.microtask.ca/cpuhog.html%EF%BC%89%E3%82%92%E8%B5%B7%E5%8B%95%E3%81%99%E3%82%8B%E3%81%A8%E3%80%81BitCoin) と CPU Hog が 50/50 で CPU を分け合い、CPU Hog が全 CPU を取って BitCoin がアイドル/低プロセスでのみ動くという状態にはならないことが分かる。khash/s も半分に減っているので、スレッドが通常より低い優先度で動いていないさらなる証拠だ。

事前にコア数を数えておくべきだった 🤐。Windows 2000、XP、Vista 32/64、Windows 7 32/64 でテストした結果、バグではないことを確認した。

knightmb 2010年7月15日 20:15 UTC 原文 ·

Linux クライアント(64 ビット)では、「閉じる時に最小化」がまだトレイに最小化する(しばらくすると複数のトレイアイコンを生成して X サーバーがハングする)。

しかし、スレッドの優先度は全て適切に nice されているようだ。CPU を全て使っているスレッドは nice 19 で、0 や 2 の他のスレッドは CPU を使っていないので、システムはレスポンシブに感じる。

[knightmb@KnightMB ~]$ ps -eflL | grep bitcoin
0 S knightmb 13676 13591 13676  0    9  80   0 - 113704 poll_s 14:52 pts/1   00:00:02 ./bitcoin
1 S knightmb 13676 13591 13681  0    9  80   0 - 113704 hrtime 14:52 pts/1   00:00:00 ./bitcoin
1 S knightmb 13676 13591 13682  0    9  80   0 - 113704 hrtime 14:52 pts/1   00:00:00 ./bitcoin
1 S knightmb 13676 13591 13683  0    9  80   0 - 113704 hrtime 14:52 pts/1   00:00:00 ./bitcoin
1 S knightmb 13676 13591 13685  0    9  80   0 - 113704 hrtime 14:52 pts/1   00:00:00 ./bitcoin
1 S knightmb 13676 13591 13686  0    9  80   0 - 113704 hrtime 14:52 pts/1   00:00:00 ./bitcoin
1 S knightmb 13676 13591 13687  0    9  82   2 - 113704 hrtime 14:52 pts/1   00:00:00 ./bitcoin
1 R knightmb 13676 13591 13689 70    9  99  19 - 113704 -     14:52 pts/1    00:09:34 ./bitcoin
1 R knightmb 13676 13591 13714 71    9  99  19 - 113704 -     14:53 pts/1    00:09:39 ./bitcoin
1 R knightmb 13676 13591 13924 72    9  99  19 - 113704 -     14:53 pts/1    00:08:19 ./bitcoin
1 R knightmb 13676 13591 13314 73    9  99  19 - 113704 -     14:53 pts/1    00:08:19 ./bitcoin
1 R knightmb 13676 13591 13114 74    9  99  19 - 113704 -     14:53 pts/1    00:08:19 ./bitcoin
1 R knightmb 13676 13591 13984 75    9  99  19 - 113704 -     14:53 pts/1    00:09:19 ./bitcoin
1 R knightmb 13676 13591 13214 76    9  99  19 - 113704 -     14:53 pts/1    00:09:09 ./bitcoin
1 R knightmb 13676 13591 13917 77    9  99  19 - 113704 -     14:53 pts/1    00:08:12 ./bitcoin
1 R knightmb 13676 13591 13919 78    9  99  19 - 113704 -     14:53 pts/1    00:08:39 ./bitcoin
1 R knightmb 13676 13591 13934 79    9  99  19 - 113704 -     14:53 pts/1    00:08:51 ./bitcoin
1 R knightmb 13676 13591 13114 80    9  99  19 - 113704 -     14:53 pts/1    00:08:39 ./bitcoin
1 R knightmb 13676 13591 13624 81    9  99  19 - 113704 -     14:53 pts/1    00:09:11 ./bitcoin
1 R knightmb 13676 13591 13224 82    9  99  19 - 113704 -     14:53 pts/1    00:08:39 ./bitcoin
1 R knightmb 13676 13591 13374 83    9  99  19 - 113704 -     14:53 pts/1    00:08:55 ./bitcoin
1 R knightmb 13676 13591 13261 84    9  99  19 - 113704 -     14:53 pts/1    00:09:43 ./bitcoin
1 R knightmb 13676 13591 13171 85    9  99  19 - 113704 -     14:53 pts/1    00:08:55 ./bitcoin
1 R knightmb 13676 13591 13741 86    9  99  19 - 113704 -     14:53 pts/1    00:08:23 ./bitcoin
1 R knightmb 13676 13591 13371 87    9  99  19 - 113704 -     14:53 pts/1    00:09:42 ./bitcoin
1 R knightmb 13676 13591 13690 88    9  99  19 - 113704 -     14:53 pts/1    00:08:39 ./bitcoin
1 R knightmb 13676 13591 13234 89    9  99  19 - 113704 -     14:53 pts/1    00:08:33 ./bitcoin
1 R knightmb 13676 13591 13703 90    9  99  19 - 113704 -     14:53 pts/1    00:08:38 ./bitcoin
1 R knightmb 13676 13591 13991 91    9  99  19 - 113704 -     14:53 pts/1    00:08:39 ./bitcoin

「Start BitCoin on window system startup」が何をするのか正確にはわからないが?

ライブラリエラーについて、古めの Linux クライアント(1 つはたった 1年前のもの)で**/usr/lib/libstdc++.so.6 ‘GLIBCXX_3.4.11’ not found**が出る。ファイルを確認したところ、libstdc++.so.10 にリンクされているが、十分なバージョンかどうかわからない。

andy_3_913 2010年7月15日 20:26 UTC 原文 ·

申し訳ないが、これはほとんどちんぷんかんぷんだ!! 完全なバカじゃないが、大部分は理解の範疇を超えている!! 😊

db 2010年7月15日 20:39 UTC 原文 ·

listreceivedbyaddress と getreceivedbyaddress コマンドが bitcoind のヘルプで重複している。(0.3.0 でも同様。)

andy_3_913 2010年7月15日 21:05 UTC 原文 ·
dbの投稿(2010年7月15日 11:39 UTC)

listreceivedbyaddress と getreceivedbyaddress コマンドが bitcoind のヘルプで重複している。(0.3.0 でも同様。)

そうだ! きっとそうだ!! もう言ったが、まったくわからない! 一体何の話をしているんだ???

knightmbの投稿(2010年7月15日 10:37 UTC)

Windows上では、コイン生成の優先度は依然として通常のままだ。BitCoinをコイン生成モードで実行し、CPUを全部食い尽くすもの(例えばCPU Hog: http://www.microtask.ca/cpuhog.html)を起動すると、BitCoinとCPU (http://www.microtask.ca/cpuhog.html%EF%BC%89%E3%82%92%E8%B5%B7%E5%8B%95%E3%81%99%E3%82%8B%E3%81%A8%E3%80%81BitCoin%E3%81%A8CPU) Hogが50/50でCPUを分け合い、CPU Hogが全CPUを取ってBitCoinがアイドル/低プロセスでのみ動くという状態にはならないことが分かる。khash/sも半分に減っているので、スレッドが通常より低い優先度で動いていないさらなる証拠だ。

これを再現できなかった。デュアルプロセッサーなので、2 つのメモリーホグを実行した。タスクマネージャーによると、Bitcoin の CPU 使用率は 0%だった。khash/sec メーターは CPU を取得できなかったため更新されず、止まったままだった。

デュアルプロセッサーか?シングルプロセッサーのホグを実行していたのではないか?

knightmb 2010年7月15日 21:48 UTC 原文 ·
サトシ・ナカモトの投稿(2010年7月15日 12:40 UTC)
knightmbの投稿(2010年7月15日 10:37 UTC)

Windows上では、コイン生成の優先度は依然として通常のままだ。BitCoinをコイン生成モードで実行し、CPUを全部食い尽くすもの(例えばCPU Hog: http://www.microtask.ca/cpuhog.html)を起動すると、BitCoinとCPU (http://www.microtask.ca/cpuhog.html%EF%BC%89%E3%82%92%E8%B5%B7%E5%8B%95%E3%81%99%E3%82%8B%E3%81%A8%E3%80%81BitCoin%E3%81%A8CPU) Hogが50/50でCPUを分け合い、CPU Hogが全CPUを取ってBitCoinがアイドル/低プロセスでのみ動くという状態にはならないことが分かる。khash/sも半分に減っているので、スレッドが通常より低い優先度で動いていないさらなる証拠だ。

これを再現できなかった。デュアルプロセッサーなので、2つのメモリーホグを実行した。タスクマネージャーによると、BitcoinのCPU使用率は0%だった。khash/secメーターはCPUを取得できなかったため更新されず、止まったままだった。

デュアルプロセッサーか?シングルプロセッサーのホグを実行していたのではないか?

LOL、おそらくその通りだ。周りに PC がありすぎて、どれがシングルコア、デュアルコア、クアッド、8 コアかを把握するのが難しい。シングルプロセッサー PC で再テストする。

knightmb 2010年7月15日 21:56 UTC 原文 ·

ああ、その通り、問題なく動く。コア数を先に数えなかった自分を叩く。というわけで優先度のバグは取り下げる。投稿を編集しておく。Windows 2000、XP、Vista、7 で問題なく動作する。

knightmbの投稿(2010年7月15日 11:15 UTC)

Linux クライアント(64 ビット)では、「閉じる時に最小化」がまだトレイに最小化する(しばらくすると複数のトレイアイコンを生成して X サーバーがハングする)。

最初の投稿をこの修正を含む Linux 用 rc2 へのリンクで更新した。修正されているか確認してほしい。ありがとう!

http://www.bitcoin.org/download/bitcoin-0.3.1.rc2-linux.tar.gz

dbの投稿(2010年7月15日 11:39 UTC)

listreceivedbyaddress と getreceivedbyaddress コマンドが bitcoind のヘルプで重複している。(0.3.0 でも同様。)

はい、バグだ。次のバージョンで修正する必要がある。

db 2010年7月15日 22:23 UTC 原文 ·

Linux では、0.3.0 は生成時に nice 値が 0 になるが、0.3.1 では生成スレッドが nice 値 19 になり、他のスレッドは 0 のままだ。良さそうだ。

RHorning 2010年7月15日 22:29 UTC 原文 ·
knightmbの投稿(2010年7月15日 20:15 UTC)

「Start BitCoin on window system startup」が何をするのか正確にはわからないが?

Windows では、Bitcoin.exe をシステムレジストリの HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run、または代替として HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run に登録するべきだ。

どちらも起きていないようだ。だが「Startup」フォルダーには入った。それはいかにも Windows 95 っぽい(冗談だ……Microsoft はこれをめちゃくちゃにしてしまっていて、笑えるどころではない)。レジストリ設定を勧める理由はいくつかあり、ほとんどのソフトウェアがその場所に登録するという事実もそのひとつだ。個人的には Startup フォルダーの方が見栄えが良く、Windows のほとんどのソフトウェアが「そう振る舞うべき」だと思っているとしても、だ。

Windows でこの新バージョンの完全なフォレンジックは行っていないが、Windows インストーラを使った俺のインストールは問題なく進んだようだ。

adavid 2010年7月15日 22:39 UTC 原文 ·
knightmbの投稿(2010年7月15日 11:15 UTC)

Linuxクライアント(64ビット)では、「閉じる時に最小化」がまだトレイに最小化する(しばらくすると複数のトレイアイコンを生成してXサーバーがハングする)。

確認した。bitcoind は確かに nice になった。

RHorningの投稿(2010年7月15日 22:29 UTC)

どちらも起きていないようだ。だが「Startup」フォルダーには入った。それはいかにも Windows 95 っぽい(冗談だ……Microsoft はこれをめちゃくちゃにしてしまっていて、笑えるどころではない)。レジストリ設定を勧める理由はいくつかあり、ほとんどのソフトウェアがその場所に登録するという事実もそのひとつだ。個人的には Startup フォルダーの方が見栄えが良く、Windows のほとんどのソフトウェアが「そう振る舞うべき」だと思っているとしても、だ。

どちらでもいける。スタートアップフォルダーの利点は、すでに Bitcoin のディレクトリとアンインストーラーを消してしまっている場合でも、エンドユーザーが通常の UI(regedit ではなく)で目で見て手動で削除できることだ。手動で削除しても、Bitcoin が執拗に再追加し続けることはない。

OpenOffice も、リンクをスタートアップフォルダーに入れる例の一つだ。

lachesis 2010年7月16日 00:03 UTC 原文 ·
サトシ・ナカモトの投稿(2010年7月15日 13:07 UTC)
knightmbの投稿(2010年7月15日 11:15 UTC)

Linuxクライアント(64ビット)では、「閉じる時に最小化」がまだトレイに最小化する(しばらくすると複数のトレイアイコンを生成してXサーバーがハングする)。

最初の投稿にこの修正を含むLinux用rc2へのリンクを更新した。修正されているか確認してほしい。ありがとう!

http://www.bitcoin.org/download/bitcoin-0.3.1.rc2-linux.tar.gz

サトシ、バグを修正したんじゃなくて、トレイ最小化コードを丸ごと削除しただけだ。オプションにしてもらえないか? 元のバグは発生していないし、トレイ最小化機能をとても気に入っている。

非公開スイッチ -minimizetotray を付けて実行すると、オプションメニューからそのオプションが利用可能になる。

修正方法がわからない。wxWidgets、GTK、または Gnome の内部深くにある何かの問題だ。

lachesis 2010年7月16日 01:12 UTC 原文 ·

了解、それだけで十分だ。

BioMike 2010年7月16日 05:24 UTC 原文 ·

x86 Gentoo の Linux システムで 0.3.1 を独自の makefile でビルドした(静的クライアントではなくダイナミッククライアントをビルドする)。0.3.0 よりスムーズに動作するようだ。

ちなみに、標準の makefile が静的バージョンをビルドするのはなぜだろう?

異なるシステムに存在しない多くの依存関係のためだ。可能な限り静的リンクする方が簡単だ。サイズもそれほど増えない。

knightmb 2010年7月16日 15:27 UTC 原文 ·

Windows クライアントで、他のクライアントを手動で(-connect オプションで)たくさん接続すると、8 を超えると Windows クライアントが「外部」接続を切って、最初の 8 つ以上の内部マシンだけをネットワーク全体と思い込むことに気づいた人はいるだろうか?

Linux クライアントをゲートウェイとして使っていたので気づかなかったが、Windows クライアントで試したところ、最初は約 10 接続あったが、直接接続する 50 クライアントを追加した後、数は最終的に「内部クライアント」だけに落ちていった。

こうなると、ブロック数が増えなくなる。基本的に Windows クライアントは「ネットワーク」から自分を切り離し、他のすべてのクライアントが自分たちだけでネットワーク全体だと思い込んでいる。

自己崩壊ループのようなものだろうか? Linux クライアントではこの問題は起きない。50人が接続していても、外向きの接続を求め続け、受信ピアも入ってくる。悪意のある人がいれば、Windows クライアントに対する一種の DoS と言えるかもしれない。

良い指摘だ。8 台以上の LAN ノードを 1 つのゲートウェイノードに接続する場合は、ゲートウェイノードが着信接続を受信できるように設定した方が良い。そうしないと、ゲートウェイノードが 8 つ以上の接続を持っている間は、新しい外向き接続を追加しようとしない。接続している外部ノードが出入りしても、それらを置き換える新しい外向き接続を作成しない。着信接続を受け入れられるようにすれば、他の多くのノードがあなたに接続してくるので問題ない。

knightmb 2010年7月16日 17:58 UTC 原文 ·
サトシ・ナカモトの投稿(2010年7月16日 08:26 UTC)

良い指摘だ。8 台以上の LAN ノードを 1 つのゲートウェイノードに接続する場合は、ゲートウェイノードが着信接続を受信できるように設定した方が良い。そうしないと、ゲートウェイノードが 8 つ以上の接続を持っている間は、新しい外向き接続を追加しようとしない。接続している外部ノードが出入りしても、それらを置き換える新しい外向き接続を作成しない。着信接続を受け入れられるようにすれば、他の多くのノードがあなたに接続してくるので問題ない。

Windows クライアントにはポート 8333 を開いた静的 IP があり、ゲートウェイデバイスから他のピアに接続し、他のピアも接続してくるのが見えた。しかし 8 を超えると、外向きのピア接続を止め、しばらくすると受信ピアも止まった。WAN 上の外部よりも LAN 上のピアだけを気にしているようだ。Linux クライアントの動作は異なる。50人が接続していても、外向きの接続を求め続け、受信ピアも入ってくる。

これは自分のように何百台もの PC を使える人だけの問題だが、逆に言えば、1 台のクライアントに 8回以上接続する PC をセットアップすれば、しばらくするとかわいそうな Windows クライアントは、ネットワーク上でブロックを解いているつもりが、実は過去に閉じ込められた独自のマトリックス世界に吸い込まれることになる。

もちろんこれは理論上の攻撃で、心配して眠れなくなるようなものではないが、将来のために提起しておく。これを無効化する最も簡単な方法は、IP の自己チェックコードを入れることだ。基本的に、デュアルノード/クライアントモードで実行している時に、LAN/同一 IP アドレスなどからではない 8 つ以上の接続があることを確認する必要がある。

BioMike 2010年7月16日 19:46 UTC 原文 ·
サトシ・ナカモトの投稿(2010年7月16日 06:09 UTC)

異なるシステムに存在しない多くの依存関係のためだ。可能な限り静的リンクする方が簡単だ。サイズもそれほど増えない。

サイズ(静的バイナリは自分の場合 8倍大きい)が問題ではなく、セキュリティだと思う。

Boost、OpenSSL、Berkeley DB は UNIX システムではかなり一般的で(多くのものが依存している)、wxWidgets(唯一の主張は、Bitcoin が安定版ではなく現在の開発ブランチを使っていること)もそうだ。第二に、静的リンクは常に実行できるとは限らない(自分の場合、libpng-1.2 を読み込もうとするが、システムには libpng-1.4 があり、静的版は読み込みに失敗する)。第三に、OpenSSL にはセキュリティの問題がなかったわけではないので、静的コンパイルにより、システムが更新された安全なバージョンを提供していても、人々はセキュリティに問題のあるバージョンを使い続けることになる。

Windows 0.3.1 rc1 と Linux 0.3.1 rc2 を SourceForge にアップロードし、ホームページのリンクを更新した。

最初の投稿に記載されている問題に該当しない限り、0.3.1 に更新する必要はない。既に動作している場合は、0.3.0 のままで構わない。

knightmb 2010年7月17日 00:11 UTC 原文 ·
サトシ・ナカモトの投稿(2010年7月15日 22:07 UTC)
knightmbの投稿(2010年7月15日 20:15 UTC)

Linuxクライアント(64ビット)では、「閉じる時に最小化」がまだトレイに最小化する(しばらくすると複数のトレイアイコンを生成してXサーバーがハングする)。

最初の投稿にこの修正を含むLinux用rc2へのリンクを更新した。修正されているか確認してほしい。ありがとう!

http://www.bitcoin.org/download/bitcoin-0.3.1.rc2-linux.tar.gz

新しいリリース候補をテストしている。「閉じるときに最小化」が誤ってトレイに最小化される問題は解決された。X サーバーのクラッシュも起きていない、いいね! あとはあのトレイ機能をまた動作させられればいいんだが 😉