大国同士が総力を挙げて殴り合う時代は1945年で終わりました。いまや先進国同士で全面武力衝突に陥る可能性は、ほとんどありません。しかし、今まさに世界大戦が行われています。武力ではなく経済で。
気づきにくいですが、日本もその惨禍に巻き込まれています。
今も日本はあまりにも不利な戦いを強いられようとしています。その主敵は、皮肉にも同盟国アメリカ合衆国。
経済や政治に明るい方なら私が何を言わんとしているか、おわかりかと思います。
そうです。その戦場は、TPP(環太平洋戦略的経済連携協定)です。
私は他人様に詳しく解説できるほど明るくはありませんので、解説サイトやリンク先の動画を見ていただくとして……
中野剛志氏 「ルール策定は政治力で決まる 米韓FTAよりひどいTPP交渉となるだろう」
米国丸儲けの米韓ＦＴＡから なぜ日本は学ばないのか 「ＴＰＰ亡国論」著者が最後の警告！
私の感想：
なんですか、この植民地政策は！？
アメリカは正義の国どころか諸悪の根源だな。(私は親米派です)
この戦、やばすぎます。しかも彼我の力量差は明らかで(民主党政権)、戦う前から、すでに負けフラグが立っています。
「勝てない戦はするな」これは、戦いの基本です。
誰ですか？惨禍、いや参加しないと世界の孤児になるとかいった人は。もう日本は鎖国でいーです。孤児でいーですから、こっち見ないでください。だいたい日本は江戸時代、二世紀以上も平和に暮らしてたのをムリヤリ開国させられて……おっと、関係無いな。
というわけで Haiku とか全然関係無い話で、しかも煽りまくってる内容で申し訳ないですが、重大な主権侵害を受けようとしてるわけですので、少しでも多くの人に知ってもらおうと思い書きました。
オンライン署名活動されておられる方もいらっしゃいます。どうか、みなさんも署名してください。お願いします。
それ以前に、こんな大事なことを決めるなら解散総選挙だろ！
追記:
アメさん自身は日本の参加を無理強いしているわけではないという説もあります。有形・無形の圧力を受けているのかもしれませんが。
ほっとけばいいものを推進派ときたら……
WindowsVista/7 になってからというもの、スリープやスクリーンセーバーの動作に不具合が出る……。
このような経験をお持ちの方は非常に多いようです。
私も例外ではありませんでした。
WindowsXP では問題なかったことが、Windows7 ではボロボロです。
というわけで調査してみました。
症例1: スリープから復帰できない
スリープ後、復帰させようと電源ボタンを押したところ、電源ランプは点灯し HDD もファンも回転する。だが画面はブラックアウトしたままというもの。
ごく短時間なら復帰できるが、数分スリープ状態が続くと復帰できない場合もあります。
システムイベントに Kernel-Power イベントID 41 (41病と呼ばれる)が記録されます。
対処法1
BIOS に Repost Video on S3 Resume という項目があれば、有効にしてみる。
対処法2
BIOS を更新してみる。
対処法3
上記1、2がダメだった場合、電源ユニットを交換してみる。
ちなみに私は最近 SABERTOOTH P67 Rev3.0 でこの問題に遭遇しました。
このマザーの BIOS (1502) には Repost Video on S3 Resume という項目が無かったので、電源ユニットを交換することで対処できました。
・ダメな電源: CORSAIR TX650 (CMPSU-650TXV2JP)
・うまくいった電源: ENERMAX LIBERTY ELT500AWT
ちなみに、ELT500AWT のが古くて容量も少ないです。納得いかねぇ。
症例2: スリープしてもすぐに復帰してしまう
対処法1
とりあえず、ここが詳しいです。
Windows Vistaマシンがスリープ状態から勝手に復帰するのを防止する- @IT
他にもぐぐれば結構出てくるので、ほとんどの人がトライしていると思います。
が、こういうのもあります。
対処法2
電源連動タップなどで、スリープに連動して電源遮断をしている機器(特に USB)を疑ってみる。
私は、次のデバイスで不具合が発生しました。
・Wacom Cintiq 21UX (DTZ-2100D/G)
・IODATA DMR-DM16CV
これらの機器にだけスリープ中に電源断または電源投入を行うと、本体(SABERTOOTH P67 Rev3.0)も釣られて起きます。神経質すぎるぞ。
仕方ないので、常時通電させておくことにしました。待機電流？誤差範囲。気にしない。
症例3: スクリーンセーバーやモニタ省電力モードに移行しない
対処法1
メディアプレイヤーや、ブラウザ内の YouTube やニコ動が開いたままだと、それらが邪魔をしている場合があります。
対処法2
レッツ! Windows 7 - 電源管理編(4)の「スリープの実行を邪魔している原因を探す」
が参考になります。
ここまではほとんどの人がトライしていると思います。
が、やっぱりこういうのもあります。
対処法3
お行儀の悪いデバイス(特に USB)を疑ってみる。
私の環境では、コレがお行儀が悪いです。→ X-Keys Desktop (USB)
どう設定を変えてみても、コイツが刺さってるだけでダメ。Windows7 に嫌われているようです。
ちなみにスリープには入れます。が、復帰後認識しない。やっぱり嫌われている。
1945年から1998年までの間に人類が行った核攻撃および核実験の歴史(動画)。
"1945-1998" by Isao Hashimoto: CTBTO Preparatory Commission
と、過去の測定データ。
測定データで見る「過去の出来事」
他にも「日本の環境放射能と放射線」では、なにかと話題のセシウム137降下物による放射能濃度などがデータベースとして公開されており、CSV ファイルに保存することができたりします。
核攻撃・核実験の歴史とあわせて見ると、なかなか興味深いものがあります。
冷戦下、状況が違えど私たちの先輩方は、その時代なりに原子力と向き合い知恵を絞ってきたのです。
無論、現役である私たちも立ち向かわなければなりません。感情やイデオロギーによるのではなく、次の世代のために、冷静に、科学的に、よりよい道を模索していかなければなりません。
原子力を放棄するも、推進するも、その決断をするためには何が必要か、何を人類にもたらすのか。よく考えて行動していきたいですね。
ちなみに私は、
「核分裂(いわゆる軽水炉)」→ まだやむなし
「核融合」→ 推進
という立場で、メタンハイドレートや海底ガス田をさっさと開発して、せめて原発10%くらいまで落とせよ派です。
ただ、原発を完全に 0% にするのは反対。
こういう高度な技術は、一旦ロストテクノロジーになってしまうと、いざ必要になったときに復旧に大変な困難を伴うものですし、「敵」を知る上でも技術と知識は継承しておきたいところです。
それに、ウランやプルトニウムが持つ巨大なエネルギーは、やっぱり惜しいとか思ってしまうし……。
救われない人間なのかもしれません。
ところで、サマータイムは私も大反対であります。
また、休日をずらすのも、あまりにも馬鹿げていると思います。
会社休日 → でも得意先は営業中 → 仕事しろ。
得意先は休日 → でも会社は営業中 → もちろん休めない。
わ☆は☆は。
ホスト - ゲスト間のネットワーク(ブリッジの場合)がうまくいかない事があります。
ping は通るし、ゲスト(Haiku)からインターネットにもつながるのに、ゲスト内の ftp サーバなどへホストから接続できない(逆はできたりする)という現象。もちろんファイアウォール等は切ってある。
このような不思議な現象でお困りの方、ホスト OS の LAN カードのデバイスドライバの設定を変更するとうまくいくことがあります。
Windows の場合はコレ。
ここの「チェックサムオフロード」を OFF にしてみてください。
画像は Marvel Yukon で、こいつは問題なかったのですが、Realtek 系では不具合が発生することが多いようです。Wireshark などのパケットモニタで、チェックサムの異常を観測できれば間違い無いと思う。つい先日まで使っていた VMware 5 系では問題なかったのに・・・。
ちなみに、ゲスト OS は Haiku に限らず、Windows でも起こりえます。
拙作の vmw_tools のマウスもダメダメでした。クリップボードの共有は OK。でも、もう直すの、めいどさんです・・・。
Haiku の文字コード変換ライブラリである libtextencoding.so は Shift_JIS の Microsoft コードページ 932 (CP932)には対応していません。よって、Windows 上で作った、丸数字やローマ数字が含まれるテキストファイルを何も考えず Haiku に持って来て開くと、文字化けしてしまいます。拙作の FtpPositive で Windows FTP サーバにアクセスした場合も例外ではありません。
ちなみに BeOS R5 以前は CP932 に対応していたようです。
↑本当のファイル名は、丸数字の123.txt
これを解消するためには、libtextencoding.so に CP932 対応させるパッチをあてなければなりません。
そもそも Haiku の libtextencoding.so は、GNU による文字コード変換ライブラリである libiconv に頼っており、当然変換結果も libiconv に依るものとなります。libiconv 自体は不完全ながら CP932 にも対応しています。しかし libtextencoding.so の実装は CP932 ではなく、標準の Shift_JIS 変換に限定しています。(CP932 はマイクロソフト実装の亜種で、微妙に違う)
Haiku ソース中の character_sets.cpp を CP932 対応に書き換えるだけでも改善されますが完全ではなく、さらにlibiconv パッチ適用済みの libiconv をリンクさせることで(たぶん)完全となります。
しかし、libiconv へのパッチ当て作業は容易ではありません。Haiku ソース構造は元々の libiconv を分解して取り込んでいるため、上記のパッチをそのまま当てることが出来ないからです。保守性が悪くなっているだけにしか思えませんが、何か理由があるのでしょう。
一応、パッチを当てた libtextencoding.so での実行結果も例示しておきます。
（全てチェックしたわけではないのですが、多分うまくいってるはず）
さて、無理矢理パッチを当てたモノで入れ替えても実用上問題ありませんが、長い目で見ると良い方法とは思えません。CP932 に限定するということは、逆に言えば CP932 ではない標準の Shift_JIS 変換が正しく行われないことを意味するからです。
では、将来どうするか。
Haiku の文字コード変換 API に、コードページを指定できるオプションを拡張する必要がありそうです。さらに、対応している文字コードおよびコードページを列挙する関数も必要となるでしょう。
ただ、短期的には Haiku 自体、このような実装がなされることはありえないと思いますので、個人単位、自己責任で対応するしかありません。
GCC4版 CP932 パッチ済み libtextencoding.so (くれぐれも自己責任でお願いします)
| 
