アカウント名:
パスワード:
ＩＴ系の人間だが、私は会社でも家でもほぼLinuxしか使ってない。WindowsはLibreでOffice文書読めない時に仮想マシンで立ち上げるくらい。
これと言って困る事も無いし、早いし、洗練されてもいるし、実際とても快適。
一旦そっちに行ってしまえば、何が問題なのかさっぱり判らない。
ディストリビューション選びだって、決めてしまえばそのうち手に馴染んでくるので、スマホ選ぶのと同じ感覚。これって論点を誤っているんじゃないかなぁ？
Ubuntuを家でも職場でも使ってる。問題がないかというと、ある・Visioがない・デュアルモニタの時に1枚しかスクリーンロックがかからない・日本語入力が・・・阿保・RICHOの複合機だけ認識しない他はあまり困らないかなー
メリットは・AnsibleがNativeに使える・DockerもNativeで使える・sshが快適・aptでほとんど済ませているのでアップデート漏れがない
日本語入力（変換）そのものよりGUIツールキットのデグレがひどい。特にGTK+。リグレッションテストしてないのかよ！と叫びたくなるくらい同じようなバグが数バージョンおきに再発する。しかも複数のバグが非同期でもぐらたたき状態となるので、古い版が安定しているかというとそうではない。
結局のところ依存ライブラリ問題の根が深い。その点、Windowsは克服とまで言えなくとも、DLL地獄からちゃんと学んでいる。
Macのアプリケーションパッケージみたいに、特定のライブラリなんかに依存するなら、アプリケーションフォルダ以下で完結する構造にしてしまえばいいのに。
なんであちこち散らかして共有にこだわるのか理解できない。
Windowsも、未だにシステムフォルダに何でもかんでもブチ込む気持ち悪さは変わってないと思う。最初から入ってるフォントと後から入れたフォントの区別がつかないとかあるし。Macみたいにフォルダ分けりゃいいのに、なんで一箇所に入れさせようとするんだろ。
今後はユーザフォントはAppData以下に入れるようになるとかどっかで見かけたりはしたけど。
HDD占有容量と実行時のメモリー消費量を節約するためにDLLやsoが発展したのはいいけどそれが原因でDLL HELLみたいな事が起きたんですよね実行ファイル内に必要なコードが全部リンクされてれば問題は起きないんですが…
せめてシステム専用と各実行ファイルローカルをきれいに分別できればいいのですがUnix系はこれが難しかったような（うろおぼえ）Windowsも一時期は(セキュリティ上の問題で)デフォルトオプションで出来ないようにしてましたが戻しましたよね
> せめてシステム専用と各実行ファイルローカルをきれいに分別できればいいのですが> Unix系はこれが難しかったような（うろおぼえ）絶対パスを使う、runpath(RPATH)を使う、$ORIGIN を使う、LD_LIBRARY_PATH を使う、LD_PRELOAD を使うなど。問題ないですよ。
Windowsは実行ファイルと同じディレクトリに.libでリンクした(自分で明示的にロードしなくても済むDLLのリンク方法)DLLを置いておくと最初にそれがヒットするんですがUNIX系はシステムで設定したディレクトリのものがヒットしますよね？
これはシステムDLLを別なものに置き換える悪さができるから一時期無効化（システムディレクトリのものを優先するように）されたのですがまた解禁されたと記憶しています※最近それ系に触れてないのでまた変わったかもしれませんが
たとえばシステムにインストールしてあるjpegライブラリーとソフトで使っているjpegライブラリーのバージョンが違い互換性問題が生じる場合Windowsなら実行ファイルと同じディレクトリにソフトが使っているバージョンのDLLをコピーすれば動くのですがUNIXはそこまで簡単ではないですよね？
$ORIGIN というのは、実行可能ファイル/共用ライブラリからの相対パスを指定するためのものです。例えば実行可能ファイル/共用ライブラリの runpath に $ORIGIN とだけ設定すると、その実行可能ファイル/共用ライブラリの置かれたディレクトリに存在するライブラリが優先して読み込まれます。存在しない場合は、システム標準の場所が検索されます。これは実行可能ファイル/共用ライブラリの構築時に設定するものですが、elfedit というユーザコマンドを使用して後付けで変更する事も可能です。
バージョン間で非互換性がある場合は、そもそもライブラ
ファイル名で解決するのは新しいlibjpeg.so新しいlibjpeg(2).so新しいlibjpeg(2)修正版.so最新のlibjpeg.so :と本質的には変わらんよね。アプリケーション開発者とユーザがそれぞれバージョンを管理しなければならない。
違いますよ。正しく作られたライブラリと正しく作られたアプリケーションであれば、ユーザは何もする必要はありません。ライブラリに互換性のない変更を加える場合には、番号を上げます。番号を振るのはライブラリ開発者の役目。繰り返します。番号を振るのはライブラリ開発者の役目。アプリケーション開発者やユーザは関与しません。libjpeg.so.1libjpeg.so.2...libjpeg.so.62libjpeg.so.63ブランチする場合には、ライブラリ自体の名称を変更します。libjpeg2.so.62 みたいに似た名前を付ける事もありますし、全く異なる名前を付ける事もあります。アプリケーションの開発者は、
うまく廻らない場合の話をしているのに何を言っているんでしょうか？
番号、番号言ってますけど、結局のところファイル名ですよね？そしてそれはいわゆるパッケージマネージャが扱うライブラリのバージョン番号ではないですよね？
あと、番号なし等の抽象的なsoは、具体的なsoのシンボリックリンクになっていることが少なくありませんが、それの管理はユーザになるのではないでしょうか。
ライブラリファイルの最後に付いている番号と、ライブラリのバージョン番号は、同一である必要はありません。というか、多くの場合は異なりますね。
libjpeg.so.62.0.0 実ファイルlibjpeg.so.62 -> libjpeg.so.62.0.0 シンボリックリンクlibjpeg.so -> libjpeg.so.62 シンボリックリンク
実際には、このように三階層にする事が多いです。(62 という数字には意味はありません。単なる例としてご理解を)互換性のある変更を加えた場合は、0.0 の部分を更新し、libjpeg.so.62 のリンク先を更新されたライブラリに向けます。このとき、更新前の実ファイルを残しても
だから例外的にうまく廻らない場合の話をしているの。原理原則を語るトピックじゃないの。
では、原理原則にそぐわない例外的な事例を、具体的にあげていただければ、その場合はどうなるか議論できるのではないでしょうか？
「例外がーーー」と言うばかりで状況が分からなければ、一般論や原理原則論で語るしかないのは当然のことで。
というわけで、例外にこだわるACさん、事例を教えてください。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
皆さんもソースを読むときに、行と行の間を読むような気持ちで見てほしい -- あるハッカー
利用者としては・・・ (スコア:0)
ＩＴ系の人間だが、私は会社でも家でもほぼLinuxしか使ってない。
WindowsはLibreでOffice文書読めない時に仮想マシンで立ち上げるくらい。
これと言って困る事も無いし、早いし、洗練されてもいるし、実際とても快適。
一旦そっちに行ってしまえば、何が問題なのかさっぱり判らない。
ディストリビューション選びだって、決めてしまえばそのうち手に馴染んでくるので、スマホ選ぶのと同じ感覚。
これって論点を誤っているんじゃないかなぁ？
Re: (スコア:0)
Ubuntuを家でも職場でも使ってる。
問題がないかというと、ある
・Visioがない
・デュアルモニタの時に1枚しかスクリーンロックがかからない
・日本語入力が・・・阿保
・RICHOの複合機だけ認識しない
他はあまり困らないかなー
メリットは
・AnsibleがNativeに使える
・DockerもNativeで使える
・sshが快適
・aptでほとんど済ませているのでアップデート漏れがない
Re: (スコア:0)
日本語入力（変換）そのものよりGUIツールキットのデグレがひどい。
特にGTK+。
リグレッションテストしてないのかよ！と叫びたくなるくらい
同じようなバグが数バージョンおきに再発する。
しかも複数のバグが非同期でもぐらたたき状態となるので、
古い版が安定しているかというとそうではない。
結局のところ依存ライブラリ問題の根が深い。
その点、Windowsは克服とまで言えなくとも、
DLL地獄からちゃんと学んでいる。
Re: (スコア:0)
Macのアプリケーションパッケージみたいに、特定のライブラリなんかに依存するなら、
アプリケーションフォルダ以下で完結する構造にしてしまえばいいのに。
なんであちこち散らかして共有にこだわるのか理解できない。
Windowsも、未だにシステムフォルダに何でもかんでもブチ込む気持ち悪さは変わってないと思う。
最初から入ってるフォントと後から入れたフォントの区別がつかないとかあるし。
Macみたいにフォルダ分けりゃいいのに、なんで一箇所に入れさせようとするんだろ。
今後はユーザフォントはAppData以下に入れるようになるとかどっかで見かけたりはしたけど。
Re: (スコア:0)
HDD占有容量と実行時のメモリー消費量を節約するためにDLLやsoが発展したのはいいけど
それが原因でDLL HELLみたいな事が起きたんですよね
実行ファイル内に必要なコードが全部リンクされてれば問題は起きないんですが…
せめてシステム専用と各実行ファイルローカルをきれいに分別できればいいのですが
Unix系はこれが難しかったような（うろおぼえ）
Windowsも一時期は(セキュリティ上の問題で)デフォルトオプションで出来ないようにしてましたが戻しましたよね
Re: (スコア:0)
> せめてシステム専用と各実行ファイルローカルをきれいに分別できればいいのですが
> Unix系はこれが難しかったような（うろおぼえ）
絶対パスを使う、runpath(RPATH)を使う、$ORIGIN を使う、
LD_LIBRARY_PATH を使う、LD_PRELOAD を使うなど。
問題ないですよ。
Re: (スコア:0)
Windowsは実行ファイルと同じディレクトリに.libでリンクした(自分で明示的にロードしなくても済むDLLのリンク方法)DLLを置いておくと最初にそれがヒットするんですが
UNIX系はシステムで設定したディレクトリのものがヒットしますよね？
これはシステムDLLを別なものに置き換える悪さができるから一時期無効化（システムディレクトリのものを優先するように）されたのですが
また解禁されたと記憶しています
※最近それ系に触れてないのでまた変わったかもしれませんが
たとえばシステムにインストールしてあるjpegライブラリーとソフトで使っているjpegライブラリーのバージョンが違い互換性問題が生じる場合
Windowsなら実行ファイルと同じディレクトリにソフトが使っているバージョンのDLLをコピーすれば動くのですが
UNIXはそこまで簡単ではないですよね？
Re: (スコア:0)
$ORIGIN というのは、実行可能ファイル/共用ライブラリからの相対パスを指定するためのものです。
例えば実行可能ファイル/共用ライブラリの runpath に $ORIGIN とだけ設定すると、
その実行可能ファイル/共用ライブラリの置かれたディレクトリに存在するライブラリが優先して読み込まれます。
存在しない場合は、システム標準の場所が検索されます。
これは実行可能ファイル/共用ライブラリの構築時に設定するものですが、
elfedit というユーザコマンドを使用して後付けで変更する事も可能です。
バージョン間で非互換性がある場合は、そもそもライブラ
Re: (スコア:0)
ファイル名で解決するのは
新しいlibjpeg.so
新しいlibjpeg(2).so
新しいlibjpeg(2)修正版.so
最新のlibjpeg.so
:
と本質的には変わらんよね。
アプリケーション開発者とユーザが
それぞれバージョンを管理しなければならない。
Re: (スコア:0)
違いますよ。
正しく作られたライブラリと正しく作られたアプリケーションであれば、ユーザは何もする必要はありません。
ライブラリに互換性のない変更を加える場合には、番号を上げます。番号を振るのはライブラリ開発者の役目。
繰り返します。番号を振るのはライブラリ開発者の役目。アプリケーション開発者やユーザは関与しません。
libjpeg.so.1
libjpeg.so.2
...
libjpeg.so.62
libjpeg.so.63
ブランチする場合には、ライブラリ自体の名称を変更します。
libjpeg2.so.62 みたいに似た名前を付ける事もありますし、全く異なる名前を付ける事もあります。
アプリケーションの開発者は、
Re: (スコア:0)
うまく廻らない場合の話をしているのに
何を言っているんでしょうか？
番号、番号言ってますけど、結局のところファイル名ですよね？
そしてそれはいわゆるパッケージマネージャが扱うライブラリのバージョン番号ではないですよね？
あと、番号なし等の抽象的なsoは、具体的なsoのシンボリックリンクになっていることが少なくありませんが、
それの管理はユーザになるのではないでしょうか。
Re: (スコア:0)
ライブラリファイルの最後に付いている番号と、ライブラリのバージョン番号は、同一である必要はありません。
というか、多くの場合は異なりますね。
libjpeg.so.62.0.0 実ファイル
libjpeg.so.62 -> libjpeg.so.62.0.0 シンボリックリンク
libjpeg.so -> libjpeg.so.62 シンボリックリンク
実際には、このように三階層にする事が多いです。(62 という数字には意味はありません。単なる例としてご理解を)
互換性のある変更を加えた場合は、0.0 の部分を更新し、libjpeg.so.62 のリンク先を更新されたライブラリに向けます。
このとき、更新前の実ファイルを残しても
Re: (スコア:0)
だから例外的にうまく廻らない場合の話をしているの。
原理原則を語るトピックじゃないの。
Re:利用者としては・・・ (スコア:2)
だから例外的にうまく廻らない場合の話をしているの。
原理原則を語るトピックじゃないの。
では、原理原則にそぐわない例外的な事例を、具体的にあげていただければ、その場合はどうなるか議論できるのではないでしょうか？
「例外がーーー」と言うばかりで状況が分からなければ、一般論や原理原則論で語るしかないのは当然のことで。
というわけで、例外にこだわるACさん、事例を教えてください。