Fedora 開発者、/bin や /lib、/sbin の廃止を提案 78
ストーリー by reo
何の略語かは諸説紛々 部門より
何の略語かは諸説紛々 部門より
hylom 曰く、
Fedora Project において、/bin や /lib、/sbin といったディレクトリを廃止し、すべてのバイナリを /usr/bin や /usr/lib、/usr/sbin といった /usr 以下に配置することが提案されているそうだ (The H の記事より) 。
2012 年 5 月にリリースが予定されている Fedora 17 での変更を検討しているらしい。これにより、すべてのバイナリを 1 つのファイルシステム上に配置できるようになるというメリットがあるそうだ。たとえばルートファイルシステムとは別のファイルシステムを /usr 以下にマウントしている場合などに、ストレージを管理しやすくなる、といったメリットが挙げられている。/bin や /lib などは /usr/bin や /usr/lib のシンボリックリンクとして用意することで後方互換性を確保するとのこと。
大丈夫なの? (スコア:3)
Re:大丈夫なの? (スコア:2)
困りますねー。 /usr/sbin にバイナリが有る訳だから、少なくとも/usrにマウントは出来ないでしょう。
hoihoi-p 得意淡然、失意泰然。
Re:大丈夫なの? (スコア:2)
「/bin や /lib、/sbin」に統一じゃなく、「/usr/bin や /usr/lib、/usr/sbin」に統一なんだろう。
hoihoi-p 得意淡然、失意泰然。
Re: (スコア:0)
> すべてのバイナリを 1 つのファイルシステム上に配置できるようになるというメリットがある
だから / と /usr は同じファイルシステムになるという前提なんでしょ。
今時は initramfs が /sbin を持っているから大丈夫。 (スコア:3)
> すべてのバイナリを 1 つのファイルシステム上に配置できるようになるというメリットがある だから / と /usr は同じファイルシステムになるという前提なんでしょ。
それは間違い。やっぱり / と /usr は分ける方向。 http://thread.gmane.org/gmane.linux.redhat.fedora.devel/155511/focus%3... [gmane.org] の理由 i を見ましょう。
/sbin やら何やらは、initramfs(initrd) の中に丸抱えされているから、それに 引きずられる必要は無いじゃん、と。
確認方法:
zcat /boot/initramfs-$(uname -r).img|cpio -ivt|grep bin
Re:今時は initramfs が /sbin を持っているから大丈夫。 (スコア:2)
モデ権が行使できれば、迷わず差し上げたいナイスフォローでした。
考えてみれば、 PXE的な diskless でやってることですね。
ありがとうございますー (スコア:2)
丁度調べた所だったので、折角なので皆さんと情報共有、と。
Re:大丈夫なの? (スコア:2)
/usrを複数のfsに分割する理由がないと言うではなく
/usrを/(root)から分割する理由がないという意味ですよね。
私の感覚とは隔たりが大きいのですが、お使いのプラットホームを教えて頂けないでしょうか?
それでいいの? (スコア:2)
Cygwin (スコア:1)
そういえば、事情は違うでしょうがCygwinも似たようなことやっていますね。こっちは逆ですが。
Re: (スコア:0)
GNU/Hurd も同じですね
5年前の記憶では
# まだやってるのかな?
Re: (スコア:0)
GNU/Hurdってなに?OSなの?
#って人もそろそろいるんじゃないかなぁ
WindowsからLinuxに移って (スコア:1)
とても不思議だったことが2つ
その1つが、なんでプログラムごとに別フォルダ(Linuxだとディレクトリ)に入れないの?ってこと。
だって、プログラムってどこかで1つの団体が管理しているわけじゃないのに、
どうやって同じファイル名のプログラムが2つ以上ないってことを保障してるのさ?
ディストリビューターによってはパッケージ管理システムでそういう不具合が起こらないようにしているのもあるだろうけど、
野良ビルドして入れた場合、最悪別のプログラムに上書きされてしまう危険もあるだろうに。
ちなみに、もう1つの疑問は、
実行中のプログラムであっても終了させずに上書き更新できるってこと。
Re:WindowsからLinuxに移って (スコア:2)
> 実行中のプログラムであっても終了させずに上書き更新できるってこと。
ファイルをopenしたまま、そのファイルをrmして、そのファイルシステムのdfをとってみましょう。
Re:WindowsからLinuxに移って (スコア:1)
昔話ですが、SunOS4では、
ローカルファイルシステムは実行中のファイルを上書きしても大丈夫だけど、
NFS経由なリモートのファイルシステム上から実行中のファイルを上書きすると落ちてました。
#/usr/local/bin をNFSで共有していて、Emacsを更新したらあちこちから悲鳴が聞こえてきたことがあります…
Re:WindowsからLinuxに移って (スコア:2)
プログラムごとに別のディレクトリにしても、結局ディレクトリ名の衝突という問題が避けられないのでは?(衝突頻度が減るとは思いますが)
実行中のプログラムを更新できるのは、unlink(あるいはrename)したあとコピーすれば i-node は別になるからで、実行中のプログラムが終了すればリファレンスカウントが1つ減り、リファレンスカウントが0になればブロックは解放されます。
Re:WindowsからLinuxに移って (スコア:1)
そのために/optってのがあったけど、あんまり使われてないですね。
それぞれのディレクトリにパスを通すのが面倒だからでしょうけど。
あと野良ビルドは、パッケージシステムとは別のところに入れるんじゃない?
自分はそうしてました。
私は逆にWindowsの仕様がとても不満でした。
アプリ終了したはずなのにファイル・フォルダが消せないことがたまにあったり…
Re: (スコア:0)
今度はディレクトリ名が被るでしょ。
Windows の Program Files みたいに団体ごとにディレクトリ分けろって?それらにいちいち PATH 通すの?
> 実行中のプログラムであっても終了させずに上書き更新できるってこと。
inode というやつがあってだな・・・
Re:WindowsからLinuxに移って (スコア:1)
>その1つが、なんでプログラムごとに別フォルダ(Linuxだとディレクトリ)に入れないの?ってこと。
今度はディレクトリ名が被るでしょ。
Windows の Program Files みたいに団体ごとにディレクトリ分けろって?それらにいちいち PATH 通すの?
ディレクトリ名にはバージョン番号まで含めることで重複を回避し、
PATH のために /bin 等にリンクも置くタイプのディストロはあるみたいです。
http://www.gobolinux.org/ [gobolinux.org]
http://www.gobolinux.org/index.php?page=at_a_glance [gobolinux.org]
Re:WindowsからLinuxに移って (スコア:1)
全部がそうなってるのは珍しそうですが、Firefoxは多くのディストロでそんな感じになってる気がします。
$ file `which firefox`
/usr/bin/firefox: symbolic link to `../lib/firefox-7.0.1/firefox.sh'
1を聞いて0を知れ!
Re:WindowsからLinuxに移って (スコア:1)
Windows の Program Files みたいに団体ごとにディレクトリ分けろって?それらにいちいち PATH 通すの?
PATH通してもコマンド名が被ってたら意味ないし。
「ファイル名を大域のコマンド名に扱う」PATHっつう概念が、40年経ってとっくに破綻しているんだろうがな。
Re: (スコア:0)
逆に、Openしてると消せないとか Windows 手抜きすぎだろ って思った。
Re:WindowsからLinuxに移って (スコア:1)
脆弱性があるプロセスを上げっぱなしのまま更新した気になるよりマシだと思いますけど。
ファイルを書き換えた気になっていたが、別プロセスにより mv されて別のファイルを置かれていた、なんてのも微妙ですね。
Re:WindowsからLinuxに移って (スコア:3)
GRACEFULな更新を志向してるなら当然なのでは?
むしろリブートを強要するWindwosの文化に違和感を覚えます。
#そもそもGRACEFULなんて概念はM$(と金魚の糞)にはなかったっり
Re:WindowsからLinuxに移って (スコア:1)
gracefulなのは一部アプリだけじゃね。
Linuxでも入力待ちのシェルが勝手に落ちて再起動したりはせんよ。
どのプロセスがパッチ済みか管理できないのは、どちらのOSも変わらんのだよなあ。
#てか誤字多いぞ。落ち着け。
Re: (スコア:0)
手抜きかどうかは分からないけど、
Windowsってアプリが終了してもロックがかかったままになって
消せないファイルがときどきできて困るんですよね。
Re: (スコア:0)
非標準の物は /opt を使うべきかと。といっても、従ってないところが多いかもね。
自分でコンパイルした場合は、/usr/local とかを使うんじゃないかな。
実行中のプログラムでも終了させずに上書き更新ができるのは、ファイルシステムがそれを可能にしているから。System V 時代のファイルシステムだと、上書き更新して実行中のプログラムが落ちるとか言ったことがあったけどね。
Re:WindowsからLinuxに移って (スコア:2)
実際、多くのソフトでコンパイルする場合、 ./configure で、
デフォルトの prefix が /usr/local になってると思います。
# 特に指定しないなら、make install で /usr/local 以下にコピーされる。
パッケージシステムは /usr/local をいじらない (と思ってる) ので、
安心して使えますし。
Re:WindowsからLinuxに移って (スコア:2)
ports って、/usr/local 以下に置くんですね。
BSD 系だと、自分でコンパイルしたらどこに置くのが普通なのか
までは分からなかったけど。。
ってか、local の意味って何?
# そのハードウェアもしくは使用者グループ独自 (local) のとかかな
# と思ってました。
Re:WindowsからLinuxに移って (スコア:1)
私は、自分でビルドしたものはホームディレクトリ以下に置くことにしました。どうせ利用者は私自身だけなのですから。
#Mac OS Xでも、Homebrewが(デフォルトでは)/usr/localを使ってくれやがる。この点だけは/optのMacPortsのほうが好み。
Plan9みたいに (スコア:1)
同様に/sbin,/usr/sbin,/usr/local/sbinも/sbinに重ねてしまう。
そのユーザの権限で使えないコマンドは見えないようにしてしまえば、PATH変数はほとんど不要になるのかも。
-- やさいはけんこうにいちば〜ん!
いまさら (スコア:0)
Solaris はとうの昔にそうなってましたけど、
なんで LFS では /bin と /usr/bin とを分けようなんて酔狂なことを考えたんでしょうね。
Re:いまさら (スコア:2)
SingleUnixSpecificationでは /binと/usr/binって分ける規格になってたっけ??
Re:いまさら (スコア:1)
君は、minirootがフロッピーディスクのサイズに制限されていた時代のことを知らないんだね。
Re: (スコア:0)
Solaris でも、/sbin と /usr/sbin は別でしょ。
シングルユーザモードで必要なものはルート・パーティションに存在し、
ルート・パーティションの容量は最小限でも済むようになってる。
もちろんルート・パーティションと /usr パーティションを同一にすることもできる。
Fedora のやり方だと、ルート・パーティションと /usr パーティションの分離ができなく
なり、大容量のルート・パーティションが必要になるので、Solaris とはむしろ逆ですね。
Linuxの場合、シングル・ユーザモード用バイナリにあたるのは initrd にあり、/boot パーティション
にあるから…ってのが理由な
Re:いまさら (スコア:2)
なので*BSDではlibが壊れた時のために, static linkされた緊急メンテナンス用コマンド群が/rescue [freebsd.org]ディレクトリの下に用意されています.
NFSで共有 (スコア:0)
最近は、/usrをNFSで共有するなんて、もうやらないのかもしれないですね。
そんなことすると、パッケージのアップデートとかで不整合が起きそうですし。
Re:NFSで共有 (スコア:1)
以前 /usr/local を nfs で共有していたことはありましたが、「localじゃないじゃん」と思って居ました。
名前の由来 (スコア:0)
ところで、/binや/libは名前の由来は想像できるけど、
/usrって何?
変更するなら、この謎の名前もどうにかした方がいいような。
Re:名前の由来 (スコア:4, 興味深い)
以前、"USeR" の略じゃなくて、User Service Routine だとか User System Roesource の略だという話題も出たのですが (NEST :: laboratory の記事 [hatena.ne.jp])、その後どうもその話は信憑性が疑わしいというお話となり、やっぱり user が usr になったんだよという説が有力っぽいです (odz buffer の記事 [hatena.ne.jp]) 。
# 以前後輩にドヤ顔で「User System Resource の略なんだぜー」と吹聴して回った過去を恥じつつ。
Hiroki (REO) Kashiwazaki
Re:名前の由来 (スコア:2)
Re:名前の由来 (スコア:2)
Re:名前の由来 (スコア:2)
/usr/ucbはSunOS4にもありましたね。/5binとか/usr/5binとか今考えるとSolarisへの助走だったんですね。
disklessをプッシュし始めたあたりで、共有するか?書込するか?等でファイルシステムレイアウトを見直したようですね。
Re:名前の由来 (スコア:2)
Re:名前の由来 (スコア:1)
実際のところ/homeというディレクトリが普通になったのは, 4BSDあたりからだったように記憶しています. SystemIIIごろの解説書では/usr直下に各ユーザのホームディレクトリを掘っていましたし.
おそらくNFSでホームディレクトリを共有するという運用が広がるようになって, /homeを別ファイルシステムにする必要が出てきたのだと思います.
Re:名前の由来 (スコア:2)
Re:名前の由来 (スコア:3, おもしろおかしい)
握手券ビジネスの略でしたっけ?
1を聞いて0を知れ!
Re:にわかなほうですけど (スコア:2)
>ところがそれぞれが歴史的経緯かいろんなフォルダに振られてて困るという。
Windowsだってc:の下にはいろいろ細かいフォルダやサブフォルダがいろいろあって探すのに苦労しますが・・・・。
UNIXは これでも、歴史的経緯をぶっちして大整理した結果こうなってるんですけどね。 昔の/etcや/usrはほんとに何でもかんでもごちゃ混ぜに入っている世界だった。
Re:にわかなほうですけど (スコア:1)
現在の様にディスクがインテリジェント化されて, 論理的なアクセスと物理的なアクセスの区別が無くなっている状況では, このような考え方で分割して問題ないと思います. 後は
といったところを考慮して論理的な分割をしておけばOKだと思います. これがエンタープライズレベルのデータベースなんかだと, 物理的なIO速度とか障害時の波及・復旧範囲なんかを考慮しないといけないですけどね.
Re:/usr/X11R[67] (スコア:1)
FreeBSDも他のportsと同様に/usr/local送りになりました.