びぁ
09/10/18 19:12:30
びぁ
09/10/03 08:35:44
ＳＨＩＮＴＡ
09/10/02 23:30:54
びぁ
09/10/02 20:53:50
テスト
09/10/02 10:24:12
ひろん
07/11/15 13:37:37
せな
07/11/14 21:38:03
Koki
07/11/14 18:04:13
びぁ
07/11/14 15:15:12
test
07/10/21 21:01:58
|
ホスト - ゲスト間のネットワーク(ブリッジの場合)がうまくいかない事があります。
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 (くれぐれも自己責任でお願いします)
最初の Basho Live CD でやった ramdisk のカラクリ。
bfs_ramdisk_patch.zip
私が実験的にやったものです。今や無用の長物ですが、興味ある方は自己責任でどうぞ。Haiku 本家に問い合わせたりしないように願います。私自身も忘却の彼方でロストテクノロジーと化していますので、お答えできないかも知れません。
SHINTAさんのブート時の無駄なデバイスロードで知ったのですが、デバイスドライバをブート時に全てロードするのが問題になっているそうな。
私は、全ロードは確かに無駄だが、必要な無駄である、という立場。
デバイスドライバをロードするかどうかを別途管理するということは、それだけ複雑なロジックを組み込むという事で、複雑なロジックは不安定要素を含める事につながり、メリットに対してデメリットが大きいのではないか、と思います。
たしか、Haiku はシンプルさを追求するのも一つの目標だったように思うのですが、これでは矛盾するのではないでしょうか？
OS の安定度を直接左右するカーネル・デバイスドライバであれば、よほどメリットが上回っていないと。なかなか賛成しづらいものがあります。
そもそも Haiku はそんな小手先のテクニックに拘る事自体がナンセンスなほど速いし、リスクを承知でデバイスマネージャのようなものを実装して、どれだけのメリットにつながるのか甚だ疑問に思います。また、そのデバイスマネージャ自身が起動速度低下を招く可能性もあります。
ただ、具体的にどのデバイスドライバが、どのデバイスに対応している、という情報にすばやくアクセスできる仕組みはあったほうが良いとは思います。無駄と判断できるデバイスドライバは、そのシンボリックリンクを削除するだけで DISABLE できるので。
(これが axeld 氏が言っている「新しいドライバアーキテクチャ」に含まれるのかも)
コメントの件では大変失礼しました。
サーバさんへ POST する文字コード設定が知らぬ間に変えられてるようでした。今はたぶん OK。
自作 php なんで保守がめいどさんになってきました。どっかのブログにでも引っ越そうかな。
|
|
