]
トップ «前の日記(2010-04-08) 最新 次の日記(2010-04-12)» 編集

Yukiharu YABUKI の tDiary



このtDiaryを検索します。

2010-04-09 [長年日記]

_ 「コミュニティ団体運営の手引き」〜自治会、町内会、その他地域活動を行うグループの皆さまに〜

総務省トップ > 組織案内 > 研究会等 > コミュニティ組織のガバナンスのあり方に関する研究会 > 「コミュニティ団体運営の手引き」〜自治会、町内会、その他地域活動を行うグループの皆さまに〜ってことで、総務省の研究会から、「コミュニティ団体運営の手引き」が出た。(http://www.soumu.go.jp/main_sosiki/kenkyu/community_governance/27329_3.html)どのぐらいの影響力と他方面との調整が終わっているかわからないが、なーんも無いよりはマシ。お金について揉めないようにと色々かいてはります。

_ 文体診断ロゴーン

(http://logoon.org/about.html)いきなり、文体診断をしてもいいが、中身が気になるならaboutを読んでからやってみると良い。

_ deb.li - the Debian ShortURL service

Debian が ShortURL service を持つ意味はなんだろう。...(http://wiki.debian.org/deb.li)

_ aegis

現在主流の、分散管理リポジトリをつかったワークフローと Aegis が提供するワークフローにどれだけの差があるのだろうか。

  • トランザクションベースのソフトウェアの構成管理
    Aegis は、開発者のチームがプログラムに対して別々に多くの変更を加えるような作業が行えるフレームワークを提供します。そのような作業時に、Aegis は各変更をできるだけ壊さずにまとめ、プログラムのマスタソースコードへの統合を行います。
    Aegis は、トランザクションベースの手法をバージョン管理に適用することにより、複数の開発者および開発コードツリーが連携する際の問題を単純化します。また、Web ブラウザで閲覧可能なレポジトリや統合されたテスト機構が提供されています。
    Aegis のドキュメントについては aegis-doc パッケージを、Tk ベースのユーザインターフェイスについては aegis-tk パッケージ、Web ベースのユーザインターフェイスについては aegis-web パッケージをご覧ください。

    [Debian sidのaegisパッケージ解説より引用]

  • Aegis
    Aegis is a project change supervisor, and performs some of the Software Configuration Management needed in a CASE environment. Aegis provides a framework within which a team of developers may work on many changes to a program independently, and Aegis coordinates integrating these changes back into the master source of the program, with as little disruption as possible. Resolution of contention for source files, a major headache for any project with more than one developer, is one of Aegis's major functions.

    [Software by Peter Millerより引用]

_ libbfd.aの具体例

libbfd.aの続き。

上のコードでは nm の出力を使ってシンボルの情報を取得しています。外部コマンドを呼び出さないでシンボルの情報を取得するには libbfd というライブラリを使うと便利です。libbfd を使ったコードの例としては、鵜飼さんの livepatch が参考になります。また、livepatch では /proc/PID/maps を見て共有ライブラリ内のシンボル情報の取得およびアドレスの再配置の計算を行っていますが、ここでは実行形式ファイルに含まれるシンボルだけを対象としました。

[普通のやつらの下を行け: assert_caller()より引用]

ってことができると。

_ 静的リンクと動的リンクの混合(その2)

なぜstatic linkか
 Linuxそのものは単一のOSでありながら、ディストリビューションによって入ってるライブラリやバージョンに違いがあって、あるLinuxのバイナリをそのまま他のLinuxへ持っていって動くということはめったにない。では足りないライブラリを新しく入れればいいのではないかとも思うが、ライブラリの依存が依存を呼び、ひとつのライブラリをインストールするために山ほど依存するライブラリを入れねばならないということもある。これを Dependency Hellとも言う。aptのように依存チェックを行って自動で入れてくれるものもあるが、採用しているのは一部のディストリビューションのみである。
 そこで静的リンクの登場となる。静的リンクとは、つまり依存するライブラリを実行ファイルの中にあらかじめ含めてしまうことで、こうすれば依存するのは Linuxカーネルのみとなる。つまりディストリビューションに関わらず使えるようになる。ただしライブラリを実行ファイルに含めるのでファイルサイズは大きくなるし、他のアプリケーションと共通のライブラリを使っていたとしても、新たにメモリを確保される。それでもほとんどのライブラリは数KBから大きくても100MBを超えるようなものはまずないと思うので、相当古いマシンを使うのでなければ余裕で動作させられるだろう。

[Linux静的リンクのすすめより引用]

上記のことはわかっててやっているのなら良いが、preloadの仕組みなどで動的なリンクを仮定している場合もあるので、勉強のためにはやってみるのが良いと思う。静的リンクと動的リンクの混合で触れたような考察や、既存で動的リンクと静的リンクを併用している oprofile の事例を研究してみるのも良い。