奈良の久保です。

 先にお断りしておきます。引用にて改行位置を変えさせていただきました。

On Thu, 27 Jan 2005 06:52:32 +0000 (UTC)
kono@ie.u-ryukyu.ac.jp (Shinji KONO) wrote:

> 僕は自分の責任で動かそうとしているので、あって、そこに関して
> 「Ret Hat を使え」ってのは、ちょっと余計なお世話だと思う。

 では、そこは余計なお世話ということで取り下げます。
重きを置きたいのは「自己責任で行ったにしては、自己責任でやったと
いうことを書かずに、結果の責任が他者にあるように書いている」と
いう点です。そちらに関しては記述がないようですので改めて伺いますが、
どう思われますか。
その原因に関する話をするのならば、まずどうして起こったかの方を
書いておくべきではないのですか。


> ただ、あなたが考えている Linux 開発者の態度とか、期待されるLinux
> ユーザが何かは、良くわかりました。それは覚えておきます。

 別に Linux に限りません。説明書でもオンラインドキュメントでも、
使い方が指定してあるもの一般で同じだと思います。家電製品でも
車でもソフトウェアでも、「なんとかなるだろう」で自己責任で指定外の
使い方をして問題が起こっている。それを、指定外の使い方をしている、という
ことを書かずに、ものの方が悪いように fj に書いて流している。
そういう行為はおかしいと思っている、ということです。
Linuxベースの OS や Linux上で動くソフトウェアだけ特別扱いする
理由はないはずです。

 ものを使えば、使い勝手や結果についていろいろ言いたくなるのは
わかりますし、情報交換や技術的な話も有用だと思います。
ですが、その時に「指定された使い方通りに使っていない」という
事実を書くのと書かないのとでは受け手の感じ方が大きく違うと思います。
河野さんは最初に書いているつもりかも知れませんが、
「もちろん、なんで出るかも知ってます。ソースがある場合の修正
の仕方もわかってます。」という記述だけでは、具体的なことが一切書かれて
いないので、読み取れない人も居ると思います。
この記述でも他の箇所でも結構です。「誰が読んでも自己責任の結果だと
読み取れる」と主張されるのでしたら、どこから読み取れるのか
示してください。

 河野さんが配布されている(あるいは配布されていた)ソフトウェアは、
ドキュメントが付けられていたり--helpオプションを付ければヘルプが
見られるようになっていると思いますが、それに従わずに使わって
おきながら、不具合が起きたといって、どう使ったかを書かずに
「ソフトウェアが悪い」というようなことを、 fj,あるいは他の媒体で
発言されていたらどう思いますか。
「別にどうってことない」ということでしたら、それは感覚、見解の違いと
いうことで結構です。
 私は、それは間違っていると思いますし、製作や配布に携わった方々に
対して失礼であると思います。

 
> バイナリ互換を落せば誰かが文句を言うのは当然だと思います。それは
> わかってやっているわけですよね。

 私は Synopsys の一ユーザで、ソフトウェアに関しては素人ですので
意図しているのかどうかまでは判りません。ですが、当然だとは思いません。
繰り返しますが、Project Vine は Vine Linux 3.0/3.1 が Red Hat と
バイナリ互換だとは謳っていませんし、Synopsys も Linux であれば
すべてのディストリビューションで動くとは言っていません。
このディストリビューションが一番の推奨、次点はこれ、三番目はこれ、と
書いてあるわけです。
私の確認できる範囲では、Project Vine も Synopsys も何ら責められるような
ことはしていません。河野さんが Linux に対して、何らかの思想というか
期待を持たれているのは少しわかりましたし、その通りに動いていないので
河野さんが文句を言っているということは理解できました。しかし、
そこから「誰かが文句を言うのは当然」と帰結させるのは無理でしょう。
Linux の上で動くアプリケーションは CPU が同じアーキテクチャであれば、
バイナリは互換でなければならない、といったようなことが私の知らない
どこかで定められているのですか。
それともご自分の責任でマニュアルに反した使い方をしながら、結果が
自分の意図通りにならなかったと逆切れする行為の方が当然なのですか。


 Linux に関係ない話ばかりでは次は Follow-upto:fj.news.usage にしましょう、
となってしまいそうなので、(それはそれでも構いませんが)
折角なので、 これまでの私の経験から言えることを書きます。

 まず、以前は Sun などでしか使えなかったツールが、コストパフォーマンスに
優れた PCで使えるようになったのことは非常にありがたいです。
6〜7年ほど前だと思いますが、当初MS-Windows(NT4.0だっと思います) を
サポートし始めたころは、ツール単体はまずまず動くけれども、Sun や
HP とスクリプトやデータを同じように扱えるようにするのは大変でした。
また、PentiumII 450MHz のマシンが、UltraSPARC-II 300MHz より若干速い、
というスピードだったと思います。
comp.lang.vhdlにも、他のベンダのツールだったかもしれませんが、
EDAツールの実行速度の比較結果がいくつか流れていました。
結局、苦労をしてまで移行するメリットはない、となり、私の周辺では
実際の設計には使われませんでした。
その後、PC でのサポートOSが Red Hat Linux になったことによって、
その苦労が大幅に減り、Sun との環境やデータの共通化、あるいは移行が
できるようになりました。
PC用のプロセッサの高性能化が進み、コストパフォーマンスだけでなく
パフォーマンス自体も Sun や HP を上回り、今はツールの安定度や品質と
いった面でも特に問題なく、実際に Linux 上で Synopsys のツールを使って
論理合成したり静的タイミング解析などをしたチップも市場で無事に
動作しています。Synopsys 以外のツールベンダも、Linux対応が進み、
私が関わる仕事で、Sun でなければならない、ということはほとんど
なくなりました。

 ディストリビューション、ライブラリのバージョン等を問わずに
バイナリが共通で使えるに越したことはないと思います。
しかし、現状はそのために、より知識が必要であったり工夫が要ったり、
検証工程が増えたり、何らかのコストが必要なわけです。
そういったものがツールの価格に跳ね返る、あるいは開発リソースの
分散によりツールの品質が落ち、設計したチップが市場で不良を起こす。
そういった事態になるよりは、今のプラットフォーム限定も止むなし、と
思います。あらかじめツールベンダがサポートしているディストリ
ビューションを用意しておくだけで双方メリットがあります。
サインオフに使っているツールの不具合で LSI が市場不良を起こせば、
Synopsys、チップメーカー、セットメーカーのすべてが、金額の面でも
信用の面でもかなりのダメージを受け、下手をすれば会社の存亡に
関わります。VDEC で起こしたテストチップならば、動かない
チップ作ってしまった、くらいで済むかもしれませんが、これに
したって笑えない金額が無駄になるでしょう。
様々なディストリビューションで動くという互換性と、ソフトウェアの
品質のどちらが重要だと思いますか。

 互換性に関して、私が経験したこと、知っていることを書きます。
しばらく前のバージョンはサポートされるプラットフォームは
 Red Hat Linux 7.2 だけでしたが、ここ最近のものは、Red Hat Enterprise
Linux 3.0 が Baseline Operating System と定められており、Red Hat
Enterprise Linux 2.1 が Binary Compatible Operating System と
して定められています。また、Red Hat 7.2 はサポートする、とも
書かれています。
私の部門では、Red Hat Enterprise Linux 3.0を導入しています。
過去のバージョンを使わなければならないこともあるので、
「Red Hat Linux7.3と Red Hat Enterprise Linux 3.0の両方を入れて、
当面は Red Hat 7.3で動かすのがよい」との意見もありましたが、私の
判断で Red Hat Enterprise Linux 3.0だけしか入れていません。
実際、ツールやシミュレーションモデルといったものが動かなかったことが
ありました。ですが、Red Hat Enterprise Linux には 7.3互換ライブラリの
パッケージがあらかじめ用意されており、その使い方は SolvNet から簡単に
参照でき、動作させることができました。その他は問題は起こっていません。

  https://solvnet.synopsys.com/retrieve/012548.html

 河野さんが書かれていた glibc をそのバイナリだけ古いのを使う、と
いうことの実現方法の一つだと思います。
すべてのディストリビューションとは行きませんが、Synopsys がサポート
プラットフォームにしている、していたものであれば互換性の問題は
ほとんど発生せず、Red Hat Linux 7.3で v2004.12までのツールは
問題なく動きますし、逆に Red Hat Enterprise Linux 3.0で
古いバージョンも動きます。正しく使ってきた普通のユーザなら
問題ないわけです。


> しかも、
>
>     system error message を stdout に出すような真似しておいて開きなおられる
> 
> のは、ちょっとなぁ。stderr だったら、まだ、許せるんだけど...

 開きなおられる、というのは Synopsys に対してですか。
サポート外のプラットフォームでしか発生しないエラーについてまで、
SolvNet ですぐ原因がわかるというのにまだご不満ですか。
河野さんが書かれている通り、結果はすべて河野さんの責任のはずですが、
やはり、他人に責任を転嫁しているようにしか読めません。


> detect できているんだから、そのようなバイナリに関しては古い errno
> の実装を使うっていう風にするべきだと思う。あるいは、errno をマクロ
> にしておいて、バイナリ互換のために int errno;もサポートするって、
> 
>    そんなに不可能な程、非常識な実装
> 
> なんですか?

 上にも書きましたが、私はソフトウェアに関しては素人なので、河野さんの
主張自体が理解できていません。ですので、妥当性もわからないので
コメントできません。


> > 誰の目にも入るように「Vine Linux 3.0 をお使いの方には特別な事情が
> > ない限り、Vine Linux 3.1 へのアップグレードを推奨いたします。」と
> > 書いてあります。3.0 をお使いになっている理由はどうしてですか。
> 
> 実は3.1です。手が滑べっただけ〜 そもそも、2.6->3.1 のupgrade
> で、このあたりの問題が出ているので。

 それくらいは、情報収集を怠らなければ、事前に予想できると思います。
私が河野さんの立場なら、まず 3.0へのアップグレードを言い出した人と
それを承認した人を怒りますね。情報工学科の研究室に配属されるほどの
学年の学生、あるいは教員であれば、Vine Linux 3.0のリリースを読めば、
その最初にメジャーコンポーネントのバージョンアップと書いてあって、
カーネルの次に glibc が挙げてあるのですから、こういった事態は
予測できるでしょう。glibc とは何かわからない人でも、Vine-users
メーリングリストを読んでいれば、βの動作報告などから問題があることは
わかります。
そして、それを危惧する人のために、Project Vineは3.0/3.1と並行して
2.6r4 のサポートも継続する、と言っており、パッケージのアップデートも
しています。実際、私が仕事で部門サーバ兼デスクトップとして
使っているマシンも家で趣味で使っているマシンも共に 2.6r4 のままです。

 
> もちろん、Vine Linuxを入れるのには、一応、反対しましたよ。
> でも、なんとか出来るつもりだったので、Vine Linuxで頑張っている
> んです。もちろん、これを理由に Red Hat に移行するていう手も
> あるけど、それは嫌だからいろいろやっているってところですね。

 事情は少しわかりましたが、河野さんの行動は正当化できないと
思います。

-- 
久保 善道
selvid@sannet.ne.jp