Un*xにもレジストリー導入

Unixのコンフィグもいいかげん乱雑な/etc/*の手編集を
止めたほうがいい。key&valueをDBに突っ込んで、レジストリー
を構成するのはどう?実際Cobaltはに多様なことをやっていて
DBから/etcへコンフィグファイルを生成している。

まぁたしかに、linux なんかはそうしたほうがいいんじゃないかな。笑

>>1
おぅ、いいじゃん。
やってくれ。

>>1
勝手にやってくれ。お前しか使わんだろうが。

君だけやれば良い。　>>1
（手作業が一番楽だったりするんだよナ）

カーネルモードにツリー形式も扱えるまともな、トランザクション
データベースがあればいいんだよな。
ファイルシステムはそのデータベースをディスクドライブにじかに
マッピングする形にすると。で、ファイルinファイルを出来るように
すればファイルシステムの中に更にレジストリみたいなものを簡単に構築
出来るようになる。通常のファイルアクセスはディレクトリなどの
ファイルシステム部分へのアクセスはトランザクションにして、データへの
アクセスはダンプするタイプとトランザクションでのアクセスの二つを用意する。
レジストリみたいなファイルの場合は全部トランザクションでいつでも
ロールバックできるようにすれば設定も元に戻すことができる。
ちょい昔だとこんなの馬鹿な話だったけど今なら十分可能だと思うんだけどね。

>>6
レジストリとファイルシステムの本質的な違いって何？
レジストリにこだわらなくて別にファイルシステムでいいんじゃない？
トランザクションってジャーナルじゃだめ？
レジストリの必要性がわからない。コンフィグファイルの統一化というのなら意味がわかるが･･･。

registry=thin file system

>>7
databaseとfilesystemとの違いを求めてどうする？

本質は同じで、>>6は特性の違いを述べているのではないか？

javaにもregisterとregistryがあるけど、駄目環境認定？

レジストリは退化だと思う。
いざというときに設定ファイルをcatで読んだり、書いたりしたことある?
レジストリを入れるくらいならlibcレベルでがっちりした、穴のない
設定ファイルparser を導入して、書式を統一させたほうがよい。

>>9

あほ？ジャーナルファイルシステムって知ってる？

Darwinはレジストリっぽい物使ってなかったっけ?
# いや、BSD magazineのhack記事にそんな話が載っていたような

rm -f /etc/registry
でシステム破壊か。

現状が最高だと思っている人たちばかりなの？

>>15
現状から変わればなんでもいいと思ってるの?

ごたくはいいから、まずはモノを作って見せてくれ。

LISP 式はどう？

>>13
アプリケーションの設定ファイルが XML で書式統一されてるので、同じ
コマンドで一応一通り処理できる。Xt のリソースと概念的にはにたよーなもん
Darwin の部分の大半は従来の UNIX と同じ個別の設定ファイル。
あ、名前情報は NetInfo に入ってる。

ファイルinファイルじゃなくてファイルシステムinファイルね。

WinのCOMみたいなコンポーネントオブジェクトを実現しようと思ったらどうする？
テキストファイルで設定ファイル作ってコンポーネントオブジェクトの参照
する度に設定ファイル上からスキャンするの？なんかの設定情報を探すのにetcの下grepするの？
そんなの非効率的でしょ。設定情報は一箇所にまとまっててかつ検索が早いほうがいい。
トランザクションで変更が管理できるならなお良い。
いまのWinのレジストリでも検索は弱い。だから山本風水式でレジストリデータを
まとめると速くなったりする。
トランザクションで変更が管理できて、ツリーになってる物ってファイルシステムも同じ
ものを必要としてるんだよ。だったら双方をサポートできるような構造にして同じコードを
使ったほうがメモリは食わないし、信頼性もあげやすい。そういう意味でのファイルシステムinファイル。
レジストリみたいな設定情報、ファイルシステム、通常のDB、3つの要求が1つのコードで
満たせるんだからいいと思うんだけどねえ。
Oracleが作ったwebサーバーなんかいいとこ行ってるよな。Oracleがカーネルモードで動いてて
ファイルシステムは無くて、webサーバーが直接OracleのDBからデータを読み込むように
なってる。惜しむらくはOracleがOSメーカーじゃなかったからOSとして作ることが出来なかった
とこだな。

要はトラぶった際に人力で解析したり書き換えたりできればいいだけなんじゃないの？
confファイルの中があまりにも汚ければだめだし、Winみたいに一括管理でも人間が見て
わかりやすい作りになっていれば問題ないと思う。

>>21
レジストリはリビジョン管理したくてもできないのがネックだと思う。
いや、ちゃんと更新履歴取ったり昔のバージョンとdiff取ったりする
仕組みがあるならレジストリでもいいんだろうけどさ。

Windowsのregistryの、HKEY_CURRENT_USER, HKEY_LOCAL_MACHINEって仕組み、
/etc/mailcap, ~/.mailcapみたいなユーザによる上書き、
って仕様になってないことが多いのは痛いな。NTとか複数人で使うとね。

それから、GUIでやりたくてLinux使っている人は、linuxconf使いなよ。

あとあれだ。
Windowsの場合アプリとOSの垣根がほとんどなくて、OSの設定なんだけど
Software\Microsoftに入ってたり、その逆とかかなりぐちゃぐちゃで
バックアップ取りづらくてたまらんので、symlinkみたいな仕組みもないと
駄目かも。

とか考えると、やっぱりこれってfilesystemそのものよね。

・テキストなのであらゆる方法で書き換えが可能。印刷保存も簡単
・ファイル単位でバックアップできる。サイズが小さいからFDでも可
・その場にバックアップファイルを置いておける（探す手間が省ける）
・コメントを書き込める。コメントアウトですぐに復帰できる

これらの利点を覆すようなモノができるのならば、
専用ツールで一元管理するレジストリのようなものに
移行してもよいが。

* 速度面と一元管理の面からDB(レジストリ)化する
* テキストも残し、テキストが変更されたらDBに反映、DBが変更されたら
　テキストに反映

うーん、負荷かかりそうだし不整合出そうでやだな。

「富豪的」に考えれば、parsingのコストなんか無視したほうが
よくない? DB化というのは貧乏くさい考えかただ。
ファイルシステムとparsingのための資源ががっぽり使えると
仮定すれば DB にする必要はないと思う。

>>26
/procみたいな仮想的なファイルシステムにするのが良いと思う。
ただ、何よりも先に設定ファイルの記述方法と、設定ファイルの構文解析処理の
両方の統一化が図られないといけないが。

>>27
レジストリ化したときのメリットが少なければテキスト化した方がよいと思うが、
* 統一的な履歴管理
* バックアップ／リストア処理の単純化
* 書式統一（および付随事項として構文解釈処理の統一化）。
がもしも達成できるとしたらレジストリ化するのも悪い選択肢ではないと思うのだが。

# どーでもいいことなのだが、名称が「レジストリ」だとイメージ的に
# 「（悪い意味で）混沌とした設定保存空間」みたいな感触を受けるの
# で、別の名称のほうがいいかも(藁

レジストリを作っても世界中のソフトウェアの方がついてこないな

レジストリっていうと確かにイメージ悪いな…

>>30,>>32
それは単にWinのアレと同じ名前だからでしょ。
専用DBで一元管理つーのが本質なわけで

AS/400......

UNIXにレジストリだなんて、やめてくれよ
レジストリ使ってて、これは便利と考えたこと無いよ
第一、重要な情報を、レジストリで一元管理していたら
ハッカーの餌食だよ。

>>35
ハッカーさんの食指が動いたとして、何か問題が起きるのかね?

>>３５
今は/etcの下に（ほぼ）全部集められているわけで。
ﾊｶｰの仕事のやりやすさなら、レジストリと大差ないと思われ

いくつものドメインを抱えるレンタルサーバ業者なら、たいてい
ある設定ファイルからコマンド一発で Web や DNS や MTA の
設定ファイルを作るようなツール（といっても Makefile が
ほとんどだろうな）を独自に持ってるよ。新規にドメインが
契約されたり解約されたりするたびに設定をひとつづつ手で
書き換えるのは効率が悪すぎるもん。

レジストリではないけど、異なるサービスの設定を一元管理するのも
頭の使い方しだいでどうにでもなるってこと。

>>35
いやな理屈だなぁ。
攻め込まれるのがいやだから城内を迷路にしてたみたいじゃん。
そうじゃなくて、単純に増改築を繰り返してきたから
使いづらくなったんだろ？

セキュリティ強化の目的で、各confファイルを暗号化して、レジストリにするって言うのは？

>>40
暗号化すると各デーモンを立ち上げる度にパスワードを入れる必要があるんでしょ？やだ、そんなの。パーミッションじゃだめ？

素人の浅知恵でなんですけど、アプリやサーバの定義ファイルなんかは各自バラバラな
書き方をしてるから、いっそのこと、xmlにしてくれればいいなと思うのですが。
だめっすか？慣れないvi（失礼）でタイプミス起こして延々悩むよりは。。。

うん、そう思う。設定ファイルの書式統一せよ!
でもフリーのUNIXの世界ではM$のような独裁者がいないから
開発者に言うこときかせるのはむずかしいと思うよ。
技術的な問題よりはむしろそっちのほうが問題。
なにかの形式がものすごく広まって de facto スタンダードに
なればよいけど、今のところそういうアプリケーションてあるかな。

レジストリねえ…
このスレッドで賛成意見書いている人って、設定ファイルのバージョン管理
とかしたことないんだろうなあ。

vi を使うのに困難を覚えるような人は、Windows 2000 使ってた方が幸せな
気もする。

>>44
そうか？
RCS なり CVS なりとはぜんぜん関係なくて、設定ファイルの書式が
バラバラであるということに異を唱えてるのだが。
つーか、ほんとにレジストリ方式で一元管理するならば、
関係ないものにまでミスが波及しないよう、今よりもさらに
バージョン管理の重要性が増すと思う。

＞ RCS なり CVS なりとはぜんぜん関係なくて、設定ファイルの書式が
＞ バラバラであるということに異を唱えてるのだが。

設定ファイルの書式を統一すると、inetd.conf とか passwd ファイルの
ような設定は、当然現在よりも複雑な書式にならざるを得ない (その結果、
エディタによる編集は面倒になり間違いも増える) けど、それでいいの？

設定ファイルの書式を統一するメリットというのは、常に統合化された
管理ツールを介して編集する場合だろうけど、個人的に、そういうのは
全くいらないなあ。エディタで十分。

管理作業で難しいのは、設定ファイルの意味を理解することであって、
設定ファイルの文法に関しては困難を覚えたことはないから。
typo の類はエラーメッセージ見れば一瞬で直せるし。

＞ つーか、ほんとにレジストリ方式で一元管理するならば、
＞ 関係ないものにまでミスが波及しないよう、今よりもさらに
＞ バージョン管理の重要性が増すと思う。

Windows のレジストリのバージョン管理って、全然駄目なんですけどー。
というわけで、反証が一例あるよ。

>>46
>Windows のレジストリのバージョン管理って、全然駄目なんですけどー。
>というわけで、反証が一例あるよ。

それはレジストリの考え方がいけないのではなくて
ユーザーレベルの概念の無いWin95から上がってきたから。
Win2000では多少改善されている、Win9xカーネルが絶滅し、
ソフトの対応も増えれば解決する。

いずれにせよ、レジストリシステムが使えないと云う証明にはならない。

> それはレジストリの考え方がいけないのではなくて
> ユーザーレベルの概念の無いWin95から上がってきたから。
> Win2000では多少改善されている、

Windows 2000 のレジストリ・サービスには cvs log や cvs diff や branch
の機能もあるのかな？ あと、各エントリーにコメントをつける機能も欲しいな。

> Win9xカーネルが絶滅し、ソフトの対応も増えれば解決する。

やっぱりレジストリが欲しいような人は Windows 2000 を使うべきだよねえ。

僕は現状の UNIX の設定ファイルで満足してるので必要ないっす。
というか、inetd.conf や passwd の形式が無用に複雑になるなんて嫌。

> 僕は現状の UNIX の設定ファイルで満足してるので必要ないっす

んー、だけど各 OS 間で設定ファイルのパスが
ばらばらなものがあって、それくらいは統一してもらえると
ありがたいよ。レジストリとは関係なく。

>>48
設定のデータ構造によって適切な書式というのは異なるのだから、
エディタでも書き換えやすい書式を作って統一しようというのは
難しいだろな。

>>49
同意。書式はバラバラでもいいが (サンプル見りゃわかるしな)、
せめて場所くらいはどうにかしてほしい。

>>48
> Windows 2000 のレジストリ・サービスには cvs log や cvs diff や branch
> の機能もあるのかな？ あと、各エントリーにコメントをつける機能も欲しいな。

前半はレジストリ（設定ファイルのデータベース化）の本論とは別の話だろう。

Windows 2000のレジストリだってcvsと同じ入出力をするようなアプリケーションを
作れば良いだけだし、コメントだったら "#Comment" みたいにダミーの名前を付けて
あげれば良いだろう。レジストリの本筋は「情報を如何に保存するか」であって、
コメントを付けられるかどうかはユーザの利用次第でなんとでもなるだろうに。

ちょっと前にLinux系のメーリングリストで議論してたファイルシステム内の
ファイルの配置の統一化と似たような議論だな。あっちは "Unix互換システム
上でプログラム本体の置き場がバラバラなのをなんとかしよーぜ" だったのが、
こちらは "設定ファイルの書き方がバラバラなのをなんとかしよーぜ" なのだ
と思う。

> 僕は現状の UNIX の設定ファイルで満足してるので必要ないっす。
> というか、inetd.conf や passwd の形式が無用に複雑になるなんて嫌

別に複雑化しろなんて言ってないぞ。ただ、従来の物との互換性を保つための
仕掛け（XMLで書いても仮想的に /etc/ 以下においてあるように見えるとか）
は必要だろうな、移行措置として。

書式統一はともかく、XMLにする利点を教えてくれ

> 書式統一はともかく、XMLにする利点を教えてくれ

1. はやってる
2. カッコよさげ

XML使う理由なんてみんなこんなもんだろ。

げいつに洗脳されたノカ

レジストリーはカスタマイズデータの塊。不変のものと、
常に変化するものとは個別に管理したい、当然のなりゆき
だと思う。レジストリー導入に関して反対はしない。現に
AIXはODMというレジストリーと同じ概念のものを提供して
いる。WindowsにしてもAIXにしてもその実装と利用方法が
中途半端に感じる。それは、ユーザーに対して簡単にアクセス
を許さない流儀とコメントのなさ、にあるとおもう！
Windowsはregedit®edt32をAIXはかつてodmeditを提供し
いた。両方とも結果的にはシステムクラッシュへの扉をユーザー
に開放しただけ。システムの完成には何時会えるの？会えないの？
有り得ないの？

レジストリファイルが壊れたらみんなパァてのがやだ。
バイナリなのがやだ。
レジストリ設定するソフト必須なのがやだ。

とあるレジストリツリーの下がぐちゃぐちゃになるのと/etc以下が
ぐちゃぐちゃになるのに大差はないと思う。

メジャーなソフトの設定ファイルなら、インストール直後、
ファイルの先頭や要所要所にコメントアウトの形で
サンプル行が乗っているよね。細かい解説つきで。

それを開いて、コピペして、説明にしたがって書き換えれば
大抵のソフトは動き出すんだよね。

バイナリファイルは死んだデータである。

>>58
同意。
一箇所に設定を集めるのは便利かもしれないが
バイナリにしてしまってはデメリットが大きすぎる

AIXのODMはレジストリといって差し支えないと思うが。
それだけでシステムすべてを設定しているわけではないけど。

>>53
皆が自分と同じだと思わないほうが良いぞ.
あえて問うが、何故行思考でなければならないのだ?

>>12
著しくヴァカなので腹たった。

transacted file system, commit and rollback control, 他にもいろいろいおうか？

とりあえずヴァカ殲滅しないと話が元に戻らないとオモワレ

とりあえず、このスレからヴァカ認定発言をイタイ発言スレに持っていこう

認定馬鹿の晒し首陳列完了

まずは>>63だね。

linuxconf を発展させてはどうだろう。
テキストとツリーと両刀使いで。

で、そのシステムは GUI から設定も
コマンドライン起動で問い合わせ＆変更もできるようにすると良い。

というかコマンドラインで設定ファイルの問い合わせ＆変更が
できるシステムを GUI 側から呼んでツリー表示すればいい。

/procって揮発性のあるファイルシステムだから、レジストリ用途には向いていないと思われ。

XML 形式に一票.
ただ、形式など別にどうでもよくて、
それをパースして必要なデータを簡単に取り込めるライブラリを開発者に提供して、
簡単に設定できるようなツールを利用者に提供すれば、結構広まるのでは?

これで、書式の統一は図れるし、クラッシュしてもテキストだから問題ない。
広まってくれれば、さらに優れた設定ツールが出てくるだろうし。
どんな設定ファイルでも一つの設定ソフトで管理できるようになるよね。

ただ、この手のツールは、
最終的にSWATみたいに、ブラウザで制御するような形になりそう。

>>68
> ただ、形式など別にどうでもよくて、
> それをパースして必要なデータを簡単に取り込めるライブラリを開発者に提供して、
> 簡単に設定できるようなツールを利用者に提供すれば、結構広まるのでは?

じゃ Tcl 使え。(藁

>>62
なんか君の気持ちよくわかるよ。>>12は馬鹿だね。
file systemもぶっちゃけた話ただのDatabaseってことわかってないよな。
馬鹿に馬鹿って言われてむかつくのは厨房だってわかっててもむかつく時は
むかつくもんだ。

>>70
>file systemもぶちゃけた話ただのDatabaseってこと
ちょっとぶっちゃけ過ぎじゃないですか？
Databaseはデータの内容まで保証するけど、file system
の方は、ジャーナルファイルシステムだとしてもデータの
内容までは保証しない。

ここまで書いておきながら申し訳なりませんが、データを
保証するファイルシステムがあるのかな？レスくださいね。

>>68
gconf がそれじゃないの?

>>67
別に/procと同じファイルシステムにしろとはどこにも書いてないだろ。

/procを例に出したのは、仮想的なファイルシステム（＝実際にファイルが
存在するわけではないが、特定の記憶域内の情報の形態を変えてマッピング
するもの）の一例としてだ。

>>71
いつ「データベース」がデータの内容を保証するシステムになったのだ？

トランザクションベースのデータベースシステムは内容を保証しようとする
機構は存在するが、トランザクションという考え方すら存在しないデータベ
ースシステムだっていくらでもあるだろうに。

>>73
そうだね。正確にはトランザクションデータベースですな。
70の人ですか。私からの質問への返事もお願いします。

俺は実物はみたこと無いけど、そういうファイルシステムはあるらしい。
だが、トランザクションがあろうがなかろうがそんなものはdatebaseの
本質的な問題じゃあないだろ。ある一定のキー(file systemの場合はパス名と、
ファイルオフセットだ)からデータを参照・変更する構造は紛れもなくdetabaseだ。
file systemはネームスペースがツリー型、データベースはカラム・ロウ型に
通常なっているだけであって、ツリー型のデータベースはレジストリをはじめ
いろいろ存在するし、カラム・ロウ型のfile systemだって実現できる。
実際、前レスでも書いたがOracleのWebサーバーはOracleをfile system代わりに
使ってるだろ。
ジャーナリングファイルシステムのようにメタデータの一貫性を保つような
ファイルシステムは更にトランザクションデータベースと似てくる。
メタデータの変更をトランザクションの必要なデータの変更とみなし、
通常のファイルデータの変更はダンプとみなす。もしアプリがファイルデータの
変更もトランザクションとしたいならそれもサポートする。こんなファイル
システムがあればまんまトランザクションデータベースとしても使えるだろ。
NFSだってリモートデータベースとみなすことも出来るし、NFSの要求を受け取って
SQLへ変換してSQLデータベースをNFSサーバーとして使うようなプロキシサーバー
すら不可能な話ではない。

そんなとっちらかった話をしてて何がおもろいんだろ。
>>70の「俺定義」を聞いていても仕方ないよ…

つか、設定ファイルをレジストリにしてなんかメリットあるの??

>>76
情報の一元管理

ファイルがひとつなら一元管理したことになるのか。バカだな。

>>78
激しく同意

なんか無駄な議論だなぁ。終わってるって感じ。
ファイルのフォーマット統一っていうのはなんとなく意味わかるけど。
そもそもジャーナルファイルシステムがあれば、十分じゃん。いまではエディタも高機能になっていて、もし、マシンが落ちてもきちんとバックアップファイルを残してくれるし。(emacsだと#...#ってやつね）

一連の流れの裏に
「GUIでconf設定したい」
という妄想が潜んでいるのではないかと邪推してみる.

>>81
そうかも。

>>81
そう言われてみれば納得の行く発言もあるな。

ならWebmin(藁

APIが用意されてそれをみんなが使うようにすれば
その先の保存方法はなんでもいいや。
複数のプログラムが使う共通な設定とかに使うのが便利かな？

resolve.conf なんかは、たしかにもっとスマートになってもいいと思わない?
PPPなんか使ってると、いつも壊れやしないかとヒヤヒヤする。
それから NIS の話を誰も言わないけど、あれは一種の
レジストリみたいなもんじゃないだろうか?

設定の内容を不特定多数に流通させるわけでもないのになんで XML が出てき
てんだよ。データの書式って言うと何でもかんでも XML ってのはどうかして
んじゃないのか？　たいして読みやすいわけでもなし。
それこそ programmable な設定ファイルとして lisp の S 式をそのまま
dump する方がマシだ。

そんな気はするよね。
XMLがこれだけ広まっちゃった以上仕方ないけど。

あ、でもこの手の用途では定着しているわけじゃないからいいのか。

XMLではないが、httpd.confを見るとそんなに悪いもんでもないかと思う.

なんつうかさぁ...

Windowsで標準dbの一つとしてregistryがあって、それは古典的なBTree+に
過ぎなくてGUIなデータベースブラウザが標準装備になっているだけの事だろ？

そんなことはUNIXでも実現できていて、離合集散を繰り返した結果標準化に
必ず失敗するUNIXと、離合集散しないのでリファレンス実装しか存在しない
Windowsであるだけに過ぎない話だろ....

ヴァカ過ぎる。Windowsを神格化してねぇか、あんたら？

大体テキストファイルで設定管理したけりゃ、registryでiniファイルに
シンボリックリンク張ってみな。SDKを読めばコマンド一発で出来るぜ。
そうしたらレジストリのキーはiniファイルとしてファイルシステムから
レジストリ上にマッピングされる。cvsで好きなだけ管理するがよい。

ちゃんと使った事もない癖に想像だけで偉そうな事を言うなヴァカども。

もっといいたくなってきたな。/etcの下をレジストリのように管理したけりゃ
kernelをちょっといじってinitを起こす前にmfsなりramdiskなりを
etcにマウントして、shutdownしてinitが死んだときにmemory内容を
適当なパーティションにダンプしちまえばいいだろう。ファイルシステムは
データベースだと考えれば全く問題ないだろうし、設定かえたきゃ
mountしていじくってしまえば一発だ。linuxだったらliloでちょっと
がんばってinittabをいじれば楽勝だろ？kernelいじるまでもない。

やっぱさぁ....想像だけでものを言うヴァカを駆逐しませんかい？

>>93
補足だ。registry like operationという手法で、/bootにramdisk
イメージを追加でおいておき、/etcにオートマウント・アンマウントを
init〜shutdownに連動する機能は2.2時代からとっくにあったようだ。
使った事はないが、考える奴はちゃんと考えて、実際にやってるのだな。

やっぱ想像だけでものを言うヴァカは皆殺しにしようぜ。

> 大体テキストファイルで設定管理したけりゃ、

いや、そんなことしたら Windows でレジストリ使っているメリットが
かなりスポイルされちゃうでしょ。

レジストリにももちろんそれなりのメリットはあるのは認めてるんだけどな。

でも、レジストリみたいに統合化されたアプローチをとらない、ふつうの UNIX の
ような OS にもメリットはあって、個人的にそっちの方が好きなだけよ。
つまり、レジストリによるメリットは、自分の使い方では不要な物なの。

「レジストリが使いたい人は Windows を使えば？」っていうのは
そういう意味だし、別に Windows をおとしめているつもりはないっす。

Windows のようにエンドユーザー向けに統合化された環境を提供するなら、
GUI による編集や、OS やアプリケーション更新時の自動処理を優先した
レジストリのようなアプローチが有効だろうけど、プロフェッショナル
向けの、オープンな (各ツール間の結合度が弱い) 環境を提供するなら、
形式バラバラのテキストファイルにも、それなりのメリットはあるのよ。
それは別にバージョン管理だけじゃなくて、既存の環境との互換性も
そうだし、地球の裏側のマシンに対してシリアルコンソールとテキスト
エディタを使って OS の更新作業をしたりする際の利便性とかもあるわけ。

共通した書式を持たないということは、裏返せば、各ツールに最も適した
little language による記述をしているってことになるわけで、設定内容全て
を把握して手動で管理する場合には、最も効率の高い記述形式なのよ。
それが、「書式を統一化すると、現在よりも複雑な書式になる」という
文章の意図していたところ。

Linux のようにエンドユーザー向けの環境を重視している OS だと、
レジストリみたいな方向性に行く可能性もあるけど、別に書式を共通化
したり、レジストリみたいに集中管理しなくても同じ機能は実現できる
わけで、本当にそういう方向に行くのかは怪しいところ。

>>91-94
なにひとりで興奮してんの？
しかもAPI統一の話と情報一元管理の話を取り違えてるし。
ramdisk化したって何も変わんねえ。

> やっぱ想像だけでものを言うヴァカは皆殺しにしようぜ。
じゃあまずおまえが死ね。

テキストファイルとバイナリの両立てはどう？
アプリ側は個別の.confファイルを吐き出し、それをmakeして一つのバイナリファイルを作成するの。
その場合でもセキュリティー的にはOSのレジストリとユーザーごとのレジストリは分けた方がいいかも
しれないけど。

>>91-94
誰に対して言ってるんだ。勝手に自分で問題を設定して
勝手に突っ走ってるように見える。おちつけよ。
このスレで出ている問題は沢山あるぞ。

議論が分散してきたからここらでまとめが必要かな。
現在の UNIX 設定ファイルについての問題は:
　1. 一箇所にまとまってない
　2. 書式が統一されてない
　3. 設定をいじるルーチンも統一されてない

ということがあげられる (不十分だったら補完して)。
そして、これらの問題を解決しつつ

　a. リビジョン管理できるように
　b. 簡単にはクラッシュしないような構造に
　c. なるべく単純な構造に (いざというとき人手でいじれる)

しなきゃいけないのだ。Windows 方式のレジストリは
この要求を満たすか? 満たさないとしたら、どういう手法が
望ましいのか? というところでどうだろう。

>>99
現在の UNIX 設定ファイルは乱雑であり、アプリケーションのインストール時や各種設定変更の際にあま
りにも面倒である。各種インストーラーやコンフィグレーションツールの不備の原因として>>99の1.2.3.の点
が上げられる。
と言う感じですな。

b.の問題は最終的には運用でカバーする以外ないと思う。 /etc/hoge.conf だってバックアップを取ってお
かないと復旧できないわけだし。
c.の問題は、テキストかバイナリかという問題ですか？Winのようなバイナリ方式だと処理は速いが透過性
に欠ける。両方を採用すると不整合の問題などに悩むと。
a.の問題はc.でテキスト形式を採用すれば解決は簡単な気がする。

あと補足。
　4. ユーザごと、環境ごとに設定が分けられない。

たとえばモバイル環境ではデフォルトの resolve.conf を
オーバーライドしたり、といったようなこと。
ユーザの設定も home に置くのか、一括して扱うのかが
現在のところ混在している (たとえば使用するシェルは
/etc/passwd で一括管理されているし)。

>大体テキストファイルで設定管理したけりゃ、registryでiniファイルに
>シンボリックリンク張ってみな。SDKを読めばコマンド一発で出来るぜ。

できません。できるというなら具体的なコマンド名を挙げてみろ。

>やっぱ想像だけでものを言うヴァカは皆殺しにしようぜ。

というわけでまずお前が氏ね

>>101
うーん、この文脈で resolv.conf を出してくるのは適当でないと思うが。
それは DHCP とかで設定をもらったのを反映させるときに
適切に resolv.conf を編集できない dhcp client の問題だろ。

エディットだけ。
emacsLispプログラマの大先生にお願いして、（メジャーな設定ファイルだけでも）固有の書式とパラメータをサクサク入力編集できるモードをつくってもらをー。
設定ファイル群の仮想ディリクトリバッファ（正式名忘れた）を用意してもらオー。

だれかetcfsつくればいいじゃん

>>103
いやそうじゃなくて。
resolve.conf というひとつのファイルをみんなでいじるのが
問題だと。環境ごとに複数の hosts, resolve.conf, nsswitch.conf 等を
用意しておいて、参照を切りかえる方式のほうがスマートでしょ。

あのさ。設定ファイルいじる事がそんなにメンドイ？
アプリ導入してから安定するまでじゃん。
頻繁に変更が入るものはちゃんと設定用コマンドが用意されてるし。

普段は設定ファイルの存在すら忘れてるでしょ。

#インストールマニアならいざ知らず...

思い通りに行かなくて始めて弄る設定ファイルだからこそ
書式の統一、または環境直行性を欲するのです。

>>106
うーん、あらかじめ用意しておいた複数の設定(ファイルとは限らない)
に対する参照を切り替えるだけで解決できるならそれでもいいかも
知れないけれど、DHCP で割り当てらた情報を元に　resolv.conf を
書き換える、みたいなケースだと、参照の変更だけではすまないでしょ。

それとも、実体を変更するのとそれに対する参照を変更するのとの
2段構えにする? それだとレジストリの当初の目的の一元管理に
反しちゃうよね?

>書式の統一、または環境直行性を欲するのです。

え〜、マジで。
統一って言ったってXMLあたり採用されたら、悲しくなっちゃうけど。

> 思い通りに行かなくて始めて弄る設定ファイルだからこそ
> 書式の統一、または環境直行性を欲するのです

思い通りに行くので、それを欲しないっス。

つーか、時間を要するのは設定の意味を理解することであって、設定の書式が
原因で困ったことなんてないっス。

>>102
rundll.exe

まったくヴァカは死ねば？

>>112 & その関連の人たち
すれ違いの煽り合いが面白いよ、君たち

>>112
>rundll.exe
本当に想像だけで物を言ってるな。実はWindowsなんて一度も使ったこと
ないだろ。

>まったくヴァカは死ねば？

お前がな

110>え〜、マジで。
110>統一って言ったってXMLあたり採用されたら、悲しくなっちゃうけど。
私もXMLで統一されたら猿怒かもしれません。
111>つーか、時間を要するのは設定の意味を理解することであって、設定の書式が
原因で困ったことなんてないっス。
書式じゃなくて、意味と考え方サンセー。
各々作者殿の考え方をラッピングしてくれる環境ほしいね。
WINのレジストリはそういう意味で失敗ぽいです。

まあ、UNIXにレジストリを入れるなんて、統一企画でも
作らない限り無理かも…

更にレジストリ入れて何か良くなる…さあ考え付かないねえ
逆にレジストリ入れることによって起きる弊害のほうが多い。
�@全てのUNIXにレジストリを入れられるかー＞無理だ。
�AレジストリをUNIX使ってる連中が、今更使うとはおもえない。
�Bプログラム毎に今まである程度まとまっていた設定が
ばらばらになり、管理が難しくなるのではないか。

>>116
無理は承知の上で妄想してみたり。

X Window System の resource はどうなんだろう?
X のクライアントに限定されてはいるが、>>99 のあげた条件は
そこそこクリアしてそうに見える。

> 1. 一箇所にまとまっていない
一箇所というわけではないが置き場所は体系づけられ整理されている。
> 2. 書式が統一されていない
少なくとも文法は統一されている。
> 3. 設定をいじるルーチンも統一されてない
読む方は整備されている。書く方はないけど、単に必要なかったからで
書式が統一されてるから作るのは簡単そうだ。

更に a-c の条件も合格だ。じゃあ、X の resource をレジストリとして
採用したらうまくいくかというと俺はダメだと思う。
それは Windows のレジストリがダメなのと同じことだ。
臭いところに蓋をしても本当に楽にはならないよね。

でも無意味にバリエーションあり過ぎ。fetchmail なんとかしてくれ。(藁

djbの教え: parsingはバグの原因となるのでやるべからず。

プログラミングはバグの原因となるのでやるべからず。

>>119 やんなくていいよ。

まったくヴァカは死ねば？

>>121
コピペウザイ

わあい、ヴァカが一杯いる！

　　 　 　 　 　 　 　 　 ／￣￣￣￣￣
　　 　 　 　 　 　 　 　 |　ヲタクがはやく
　　 　　,＿＿　　　　　| 　　　逝ってくれますように
　 　 ／　　.／＼ 　　　＼＿＿＿＿＿
　 ／　　.／( ・ ).＼ 　　　　　　o〇　 　 　　 ヾ!;;;::iii|//"
／_____／ .（´ｰ｀）　,＼　　 ∧∧　　　　　　 　 |;;;;::iii|/ﾞ
￣|| || || ||. |っ¢..||￣　　 （,,　　）　ﾅﾑﾅﾑ　　 |;;;;::iii|
　 || || || ||./,,,　|ゝ iii~ 　　⊂　　ヾｗｗｗｊｊｒｊｗw!;;;;::iii|ｊｗｊｊｒｊｗw〃
　 |￣￣￣|~~凸（￣）凸　.（　　,,）〜　ｗｊｗｊｊｒｊ从ｊｗｗｊｗｊｊｒｊ从ｊｒ