2010-07-07 :-)
_ 朝ッ
0520 起床
_ 七夕らしいので願いごとを考えてみた
家内安全 交通安全
_ 願い
願いごとを神などにお願いする場合はせっかくだから人間の努力ではどうにもならないような運頼みの事象をお願いするようにしている。たとえばこう:
- 空から女の子が降ってきますように
- 出会い頭に食パンを咥えた女の子と衝突しますように
これらは自分自身の努力でどうにかなるものではない。いやもちろん空から降ってきた女の子を受け止めるだけの体力と根性を事前に備えておくことは自分の努力でどうにかしなければならないし、社会で生活して曲がり角があるような路上へ移動するための交通手段を確保するのも自分の努力しだいなのだが、じゃあそれらを備えたからといってちゃんと空から女の子が降ってくるか、出会い頭に食パンを咥えた女の子が出現するかどうかは自分の努力ではどうにもならない。ひょっとしたら空からムスカが降ってくるかもしれないからだ。女の子が降ってくるか、それともサングラスをかけた中年男性が降ってくるかは神のみぞ知るセカイである。
しかし実際に上記のようなことを本気( マジ )で考えている奴は頭がどうかしてるのでこんなことを願っている奴は居ないだろうけど、では現実的な願いとして何があるかといえば
- 家内安全
- 交通安全
などがそうなのである。まとめて「厄除け」でもいいんだろう。交通安全は安全運転を心がけるなど自分の努力でどうにかなる部分はたくさんあるが、しかし酔払い運転をしたキチガイが突っ込んでくるなどという事象は自分の努力では避けられることではない。つまり神頼みすることは「不運に見舞われませんように」だ。もちろん空から女の子が降ってくることも願ってなくはない。
_ tech-userlevel: Re: static vs. dynamic runtime linking, again (was: PAM and su -K)
スタティックリンク vs. 実行時ダイナミックリンク 再戦
( via めもがき:2010年6月6日分 )
だいぶ前ですが
先日リンク貼った
我が天敵Ulrich Drepper氏の Static Linking Considered Harmfulを
www.NetBSD.ORG 翻訳 Projectの miwarinさんが 日本語訳していいただいたようで、すばらしー。
full dynamic rootへ舵を切ったNetBSDでも未だstatic linkに固執する人もいるけどね。
過去にさんざtech-userlevelでフレームになりましたな、 このへんのスレッド参照。
まぁstatic linked root に *BSDらしさを求める人は一部 OpenBSD に流れたりもしましたが
捨ててみるとなんだこんなもんかってーのがstatic linked rootとどどどど童(ry
ということでネタを投下されたので読んでみる。あいかわらず ???? なところが多い (´Д｀；)
Subject: Re: static vs. dynamic runtime linking, again (was: PAM and su -K) To: Jason Thorpe <thorpej@shagadelic.org> From: Greg A. Woods <woods@weird.com> List: tech-userlevel Date: 01/24/2005 16:53:13 [ On Sunday, January 23, 2005 at 10:11:11 (-0800), Jason Thorpe wrote: ] > Subject: Re: PAM and su -K > > As soon as you step up and offer (and follow through) to maintain all > aspects of statically linking the NetBSD universe, then maybe I could > take this argument seriously. But until then, all I'm hearing from you > (and all the other people who irrationally fear an all-dynamic > universe) is an unreasonable demand to increase software maintenance > and development costs in a way that impedes the progress that the > NetBSD Project needs to make in order to stay relevant in the OS world.
> 次の段階になればすぐにあんたは NetBSD すべてをスタティックリンクできるようにメンテナンスしてくれ、と言うだろう。そして私はそれは本気なんだと捉える。だけどこれまでに私があんたから聞いたことは( そして他のひとたちも NetBSD すべてをダイナミックリンクにすることにたいして「ばかげた恐怖」を持っている ) ソフトウェアのメンテナンスや開発コストが理不尽に増大し、NetBSD プロジェクトが OS 界にとどまるためには邪魔だ、ということだ。
There's no "irrational fear" of static linking from me.
スタティックリンクに「ばかげた恐怖」なんて無い。
It's outright dislike and disgust of the clear and dramatic technical consequences and measurable costs and overhead of dynamic linking.
ダイナミックリンクのオーバーヘッドと計測可能なコストと、技術的に劇的な影響を及ぼすことが明確なので、それに対する嫌悪と嫌悪感だ。( 訳: and が続いてどれがどれやら分からない )
Dynamic linking really has no gain whatsoever for a vast and varied class of true real-world production systems, and I'm not just talking about embedded systems but also most day-to-day application servers, internet servers, file servers, etc., etc., etc. In fact it is a very serious pain in the butt more often than not; not to mention being a _constant_ and unnecessary drain on everyone's resources, no matter how plentiful they might seem to be.
ダイナミックリンクは、ものすごくたくさんある実在の製品にたいしてほんとにまったく有益じゃない。私は組み込みシステムのことだけについて話してるのではなく、日常使っているアプリケーションサーバー、インターネットサーバー、ファイルサーバーとかいろいろについても話しているんだ。実際、 _constant_ について触れていないし、たとえたくさリソースがあったとしても全員のリソースを食い潰さないわけではないので、たいていの butt ( 訳: ???? )について深刻だ。
Of course just as loadable kernel modules have their place in making kernel code easier to test and debug, dynamic linking has its place in similar situations as well as in certain specific environments where some resource constraints outweigh others. However it is clearly not the panacea you seem to suggest it to be, nor is it a key feature for "relevance in the OS world". I've never heard anything on this topic so completely ridiculous in my life!
もちろん、ローダブルカーネルモジュールはより簡単にカーネルコードを書いたりデバッグできるようになるし、ダイナミックリンクは、計算機資源が豊富な特定の環境下ならば活躍する( 訳: ???? )。でも、それは銀の弾丸であることを意味しないことは明らかだし、それってほんとに OS ( 訳: "relevance in the OS world" ???? )に関連する重要な機能なの? 私の人生の中でいま話題にしていることほどバカげたことは聞いたことが無い!
Meanwhile contrary to your suggestion the so-called costs and "unreasonable demands" on maintaining an all-static build option are really rather tiny to the point of being non-existent. The only real maintenance cost I've _EVER_ encountered with building static-linked systems (on _any_ platform, including NetBSD) has been the need to bash a few odd (mostly non-*BSD) developers about the ears and get them to learn/remember how to do proper dependency checking and parameter ordering for all their libraries. I welcome you to try to point out any that you think I may have missed, but keep in mind that I'm speaking from a position of considerable experience on this matter, and I don't just mean my recent year or so of experience with building and using static-only NetBSD systems in production environments.
その一方、so を呼び出すときのコストについてのあなたの意見への反論と、すべてをスタティックビルドするオプションをメンテナンスするという ***無茶な要求*** は存否の点に関してはごく些細なことだ( 訳: ???? )。ほんとにメンテナンスコストがかかる部分は、スタティックリンクされたシステムをビルドすることだけど、それはどれくらいのコストが発生するのか把握できるし( NetBSD のあらゆるプラットフォームで )、この件について知っているごくわずかの bash 開発者( ほとんどが BSD じゃない )が必要としているだけだし、どうやってまともな独立性をチェックするのか教えるか思い出させるだけでいいし、スタティックリンクされたライブラリのパラメーターを並べ替えるだけでいい。私が間違ってると思われる部分についてあなたが指摘してくれることについては歓迎する。ただ、私がこの件についてあまり詳しくないことは覚えておいてほしいし、ここ数年のスタティックビルドのみの NetBSD の動向についてはあまり経験もないんだ。
On the other hand almost everything about dynamic linking has measurable and demonstrable costs in many ways, from runtime costs with every program startup to the costs of complexity that impact both developers and system managers (though in different ways for each). This remains true on all kinds of systems, not just *BSDs of course (with the current ld.so mechanism and even with the support of helper tools such as libtool, we're only a very tiny step away from the DLL hell of other systems). In fact for anyone who takes the time to look with an open mind there's a vast mountain of published evidence attesting to the problems and costs of dynamic linking and all the additional tools and complexity it requires.
その一方、ほとんどの手法のダイナミックリンクはコストを計測可能で、そしてコストがかなりかかるということが実証済みだ。すべてのプログラムのスタートアップに費やす実行時のコストは、開発者やシステム管理者( それ以外のひとも )への衝撃は計り知れない。このことはもちろん BSD 以外のすべてのシステムに当てはまる( current の ld.so の仕組みがそうだし、libtool のような補助用のヘルパーツールもそうだ。我々は他のシステムでいう DLL 地獄と隣り合わせなのだ )。実際ダイナミックリンクのコストと、そのほか諸々のツールと、あとそれらを利用する何かについてこの問題を証明するという途方も無い作業があるんだけど、それをおこなうひとたちは随分 心が広いものだ( 訳: ???? )。
Furthermore all the claims that have been made over the years, and which are still being bandied about, for the benefits of dynamic linking are few, of lesser value, with all modern open-source systems.
さらに、これらの要求は何年も前からあるし、いまだに軽く扱われてるし、ダイナミックリンクから得られるものはほとんど無いし、すべてのモダンなオープンソースシステムにとって価値が無い。
Support for static linked executables (and their creation) is a basic, fundamental, requirement for the underlying OS, one that can never really go away -- at least not without completely changing the underlying paradigm of how executable code is loaded by the kernel.
スタティックリンクを実行( とそれらを作る )をサポートすることは OS の基本だし、基礎だし、それが無くなることはホントーーーーーに絶対にありえない。すくなくとも、実行コードがカーネルからロードされるこれまでの方法をすっかり置き換えるということは無い。
Indeed a great number of subtle bugs in many applications can be quickly and easily discovered and often eliminated just by testing that static linking works properly. This is because, unfortunately, the current linker we use does not even warn about missing symbols or duplicate symbols -- it just leaves all those problems, and their consequences, up to the runtime linker, which on the other hand simply assumes naively that _someone_ must have know what they were doing and it blindly makes choices that can, often as not, result in runtime errors, data corruption, etc.
それどころか、たくさんのアプリケーションが持つ大量の奇怪なバグはを早く簡単に発見できるし、たまにテストによって除去できるから、スタティックリンクはうまく機能する。残念ながら、current のリンカは不明なシンボルや重複するシンボルへ警告を出すことはできない。でもこれらはすべて問題じゃなくて、これらがなぜ起きるかというと、それはたんに誰かが何かやったに違いないし、実行時エラーとか不正なデータとか、それ以外の何かのいずれかでしかなく、つまり実行時リンカが悪い。
So, as Greywolf so aptly put it, don't you be cutting my rope for me!
だから、灰色狼も言ったけど「ロープ切らないで！」( 訳: おとぎ話か何かのセリフ? )
Since I do already maintain my own custom static-linked system using the NetBSD source tree as a base (and provided that the underlying technology in NetBSD still to makes this possible, as I have no doubt it will continue to do so), I can make available the fruits of my efforts to the NetBSD project as a whole. I'm not sure how this might be made to work in practice of course, but suffice it to say that there won't be any question that the little bit of maintenance you so fear will in fact be being done by someone anyway. :-)
だから、私はすでに自分用に NetBSD ソースツリーをベースにしたスタティックリンクシステムをメンテナンスしてる( そして、*既存の NetBSD* でこれが出来たので、私は間違ったことをしていないわけだし、このまま作業を続ける )、この作業は NetBSD 全体へ貢献しているのである。この作業をやるべきではないのかもしれないけど( 訳: ???? )、いまはいかなる問いも些細なことだし、メンテナンスはたいした手間じゃないし、それどころか誰がどうやってもこの作業をできるだろう、とだけ言っておく :-)
BTW, if NetBSD (and the rest of the GCC-using free OS projects) really do hope to remain relevant in the OS world while at the same time continuing to try to tout dynamic runtime linkers as a benefit, then they absolutely must work much faster and much harder towards providing proper pre-binding support (ala Darwin et al) along with much better facilities to help increase the locality of reference in massive dynamic-linked address spaces. Without such enhancements none of the very real and ever-present and ever-recurring costs of dynamic linking can ever be mitigated.
ところで、もし NetBSD ( とそのほか GCC を使っているフリーの OS プロジェクト )が実行時ダイナミックリンカが有益であると判断し、それを売り込みつつ、依然の状態を維持し続けることを望むのならば、適切な事前バインディング( いまどきの Darwin みたいな )をサポートするためにもっと早く、もっとハードに作業しなければならない。ダイナミックリンクされたアドレス空間への局所参照の増加を助けるためのにもっと良い機構が必要になる( 訳: ???? )
As for PAM, well it's still a poor solution looking for a problem, and one derived from old requirements that no longer exist in any modern open source systems.
PAM なんぞはこの問題に対してはじつに貧弱な解決策しかないし、これはもはや現存しない古いシステムのために作られたものだ。
If NetBSD had really wanted to follow the published goals for building a better system that had decent "dynamic" (i.e. runtime) controls for selecting different kinds of authentication mechanisms then the better answer would clearly have been the BSD Auth stuff, not this OpenPAM junk.
NetBSD が謳っているようなシステムを構築することをほんとに望むならば、異なる認証機構を選択するために適切な「動的」( 例: 実行時 )を実装することだ。そしてもっと良い答えは BSD 認証機構よりをもっと分かりやすくすることだ。OpenPAM のようなクズじゃなくて。
Maybe there really is enough benefit to some tiny few number of NetBSD users who think they need PAM to have OpenPAM integrated into the official NetBSD source tree, but if doing so forces it down the throats of all NetBSD users then something just isn't right. Such a unilateral move would clearly fly directly in the face of the stated, and widely accepted, goals of NetBSD.
たぶん PAM や OpenPAM が必要なごくわずかの NetBSD ユーザーのために努力するようなことは NetBSD ソースツリーに組み込んでしまうことだ。でももしそれをおこなうとすると、全 NetBSD ユーザーに強制することになるので、それは正しい解法ではない。NetBSD のゴールを受け入れるためにはどちらか一方が clearly fly directly in the face of the stated することになるだろう。( 訳: ????? )
『画面からヨメが出てきますように』が抜けてると思います...
逆に考えるんだ。おれたちが画面に入ればいいんだよ