アカウント名:
パスワード:
少し補足すると、最近私用で可動部分を一切用いない、1UのハイトでハーフサイズのPC/AT機を見せてもらいました。Linuxが載っていてflash ATAでbootするのですが、どう頑張っても256MBの壁があるためやはり/binや/sbinは厳しいそうです(機能拡張のためにHDDを載せるオプションもあるそうで)。
容量がきびしい環境では crunched binary にすれば? という気がするんだが…
それはさておき、/ と /usr を別パーティションにする習慣が一部にあるためにライブラリの置き場が /usr/lib と /lib の2箇所になってしまうのがなんかいやん。
crunchで残る問題として、crunched binary全体をaddress spaceにmapしなければならないことがあります。crunchが大きくなれば必要なpage数も増えます。中には実際には実行されないにもかかわらずmapされてしまうpageもあるでしょう。
こんな時にshared objectが使えれば、実行しないtext、読まないdataには一切pageを使う必要がありません。pmapを初めとするvm metadataを切り詰めた状態でも動くものができる可能性があります。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはシンプルである。必要なのはそのシンプルさを理解する素質だけである -- Dennis Ritchie
i386でも恩恵あり (スコア:2, 参考になる)
少し補足すると、最近私用で可動部分を一切用いない、1UのハイトでハーフサイズのPC/AT機を見せてもらいました。Linuxが載っていてflash ATAでbootするのですが、どう頑張っても256MBの壁があるためやはり/binや/sbinは厳しいそうです(機能拡張のためにHDDを載せるオプションもあるそうで)。
Re:i386でも恩恵あり (スコア:0)
容量がきびしい環境では crunched binary にすれば? という気がするんだが…
それはさておき、/ と /usr を別パーティションにする習慣が一部にあるためにライブラリの置き場が /usr/lib と /lib の2箇所になってしまうのがなんかいやん。
省メモリも可能か? (スコア:1)
crunchで残る問題として、crunched binary全体をaddress spaceにmapしなければならないことがあります。crunchが大きくなれば必要なpage数も増えます。中には実際には実行されないにもかかわらずmapされてしまうpageもあるでしょう。
こんな時にshared objectが使えれば、実行しないtext、読まないdataには一切pageを使う必要がありません。pmapを初めとするvm metadataを切り詰めた状態でも動くものができる可能性があります。