This system provides many niceties: it makes it easy for different versions of libraries to coexist, it's easy to uninstall software compiled from source, and it does not require a database-oriented package management system.
どっちがいい悪い、という問題じゃなくて、CUI と GUI で設計が違ってくるってこと。だから、GUI を念頭に作られた MacOS や Windows を「キーボードでも使えるよ」というのは、CUI を使い込んでいない人の言うことだ。
Windows なんかは、それをもっとつきつめているんで、人々に「CUIは面倒だ」という考えを植えつけるのに役立ってると思う。
"C:\Documents and Settings\hogehoge\My Documents\foobar" なんて、面倒で入力してられん。「Administrator」にしてもそう。というか、なぜテキストファイルが「.doc」じゃなくて「.txt」なんだ。「.txt」のほうが入力しにくいじゃないか。
階層型ファイルシステムを根本から考え直す (スコア:3, 参考になる)
この問題に対しては、Linux 界は FHS のような取り決めをして分類法を強化するつもりのようです。この方法だと、ファイル数が増大しつつある現状を考慮すると、素人考えとしてはいつか破綻を来しそうに思えます。
また、Microsoft 社は Windows 新版では SQL DB と結合したファイルシステム WinFS を採用することでこの問題を解決するつもりのようです。ただこの方法だとファイルシステムがかなり重くなりそうで実用的なのかどうかは疑問です。
これ以外に解決方法はないのでしょうか?
参考:
http://japan.cnet.com/news/ent/story/0,2000047623,20054024,00.htm
>WinFSはファイル記録/アクセス/索引の新たな方法で、Windows XP以前のWindowsで利用し
>ていたNTFSやFAT32に置き換わるものだ。MicrosoftはWinFSを準備するため、主要フォルダーを
>ライブラリに整理した。たとえば、スタートメニューからPicture & Video Library、Game Library、
>Music Libraryにアクセスするという具合だ。新OSの全フォルダは、種類や題名、カテゴリ、コメント
>などさまざまな基準で分類することが可能。
以下オフトピック:
個人的には、WinFS はハロウィーン文書に記載のある「プロトコルの脱共有化」を果たすために採用されたのだ、と思ってます。
Re:階層型ファイルシステムを根本から考え直す (スコア:1)
そのために、UI 表示の仕事を GPU においだしてあいた CPU を使います、って?
# というかむしろ WinFS を理解するHDD(またはDiskArray)とか言い出すんだろうか…
djb (スコア:2, すばらしい洞察)
daemontools-0.76では /program /service /package が使われています。
まあ当方はこんなもの [linuxfromscratch.org]を改造して、 /var/supervise にインストールしましたが…。
#正直いって押しつけはイクナイ!!
Re:djb (スコア:1)
/program, /package は使われてないですね。代わりに /command が使われてます。
/service もデフォルトなだけで、簡単に変更できますよ?
main(){printf("Hello World\n");}
Re:djb (スコア:2, 参考になる)
/commandにはバイナリへのシンボリックリンクが入ります。
(/programは使われてなかったのね…)
djbの目指すシステムはファイルシステムのレイアウト [unixuser.org]などで説明されています。
FHS の失敗: いくつかの事例 [unixuser.org]という主張もあります。
>/service もデフォルトなだけで、簡単に変更できますよ?
svscanbootを書き換えるだけだったっけ。。。
Re:djb (スコア:1)
ドキュメントもそうなってますね。記憶から完全消去されてました(汗
main(){printf("Hello World\n");}
Re:djb (スコア:1)
FreeBSDのPortsではデフォルトで /var/service になりますね。
設計とか (スコア:2, 参考になる)
他の OS、例えば Plan 9 の場合:
/bin//386/bin/ls
/rc/bin/man
/usr/yourname/
/sys/src/cmd/ls.c
/sys/log/dns
/lib/fonts/
一見似ているようで、Unix のそれより合理的になっているわけです。
こういった試みは重要ですが、今回の場合、とりあえず、見た目が違いすぎて、とっても変に見えます…。
意義 (スコア:2, 参考になる)
GoboLinuxのページ [gobolinux.org]より...
べつに、こんな複雑なことをしなくたって、バージョンの違う複数のライブラリのインストールはできてしまうと思うんだけど。次に、ソースから自分でコンパイルする場合、そんな変なディレクトリ構造をとると Makefile や configure をいじるのが面倒だし、 各ファイルに対して /System/Links/Libraries/libpng.so.3 などのリンクを張ってる時点で、このリンクの管理もやらなくちゃならないから、その利点とやらもなくなってしまう。最後に、パッケージ管理システムはパッケージごとのファイルの所在を管理しているだけじゃなくて、パッケージごとの依存関係なども管理してくれるので、rpm なり deb なりの管理システムはあったほうがいい。ユーザーとしてどういう人をターゲットとしてるのか、いまいち分からないんだよなあ。自分でソースを取ってきてコンパイルするような、初心者でないユーザーを対象としているみたいだけど、そういう人々は、伝統的な Unix 流のやりかたに慣れていると思うんだけど。
Linuxの意味 (スコア:2)
どんどん薄れていきそうですね。
カーネルにLinuxを使っていればLinuxOS(?)という捉え方が一般
的になっていくのか、はてさて。
Re:Linuxの意味 (スコア:2)
root (スコア:2, 興味深い)
ディレクトリ構造の変更をするだけなら (スコア:1, おもしろおかしい)
# タレコみをみて即反応しただけのAC
Re:ディレクトリ構造の変更をするだけなら (スコア:1, すばらしい洞察)
大文字 (スコア:1)
/System/Settings/BootScripts/Reboot
だとコマンドラインからのアクセスが面倒臭いのでディレクトリ名は小文字で統一してほしい。
他力本願。
tcsh なら... (スコア:3, 参考になる)
% cd /d[Tab] → % cd /Documents\ and\ Settings/
となります.
zshでも (スコア:2, 参考になる)
でできるようになります。
一応bash (スコア:1, 参考になる)
Re:一応cmd.exe (スコア:1)
日本人にとっては (スコア:1, おもしろおかしい)
/プログラム/ジャバ開発環境 とか、/設定/してみる? とか
になったら、インパクトありそう。
使いやすいかどうかは…?
Re:では悪のり (スコア:4, おもしろおかしい)
/etc/shadow -> /その他/陰
/proc/interrupts -> /動作状態/邪魔者
でつか?
# 意訳万歳なのでID
Re:パーテョション (スコア:1, すばらしい洞察)
Re:そうでなくとも (スコア:2, すばらしい洞察)
# あ、できたらできたでどう見るのがいいか、って論争になるだけか。
Re:伝統の無視なんだが (スコア:2, おもしろおかしい)
「sl」と打ち間違える人がいなくなって悲しいです。
SL(1): 究極の冗談コマンド
Re:伝統の無視なんだが (スコア:2, すばらしい洞察)
Re:伝統の無視なんだが (スコア:1, おもしろおかしい)
Re:伝統の無視なんだが (スコア:1)
「ウルトラ スーパー リラティビティ」の方がちょっと知的だけど、やっぱり「ルンルン」でしょ。
#ボケ大会と勘違いしてるけどID
Re:FHS (スコア:1)
Re:FHS (スコア:1, 興味深い)
/sbin
/usr/bin
/usr/sbin
/usr/local/bin
というようにunixの実行ファイルは点在しています。
/におくファイルを厳選して最小の構成をつくり別のパーティションとしておけば、
最悪の事態でもアンマウントしてfsck可能ということが最大の利点だと思います。
でも、KNOPPIXのようなCD bootするディストリビューションがある現在、
上のようなことはメリットなんでしょうか。
むしろ各々のプログラムがどのディレクトリに入ることが出来るかということは、
/binには最年長の歴史を持つ直系御三家や貴族プログラム、
/usr/binには多くの人に広く認められた譜代プログラム
/usr/local/binには人気はあっても名門出身ではない外様プログラム
/usr/local/プロジェクト名/bin/ デビュー直後のプログラム
というような階級づけで分けているのではないかと考えたりします。
例えばperlとかrubyは外様と譜代にディストリビューションによって評価が分かれるところです。
apacheは最初、/usr/local/binにも入れてもらえず最近になって
/usr/local/apache/binから/usr/sbinへの進入を許されました。
sbin関係ではumountが必要なディスクの修復プログラム、特にundeleteなんかは
/sbinに入るべきだと思いますが。
というわけで、思い切った見直しをするのは悪くないと思います。各スクリプトの先頭の #!
を書き直すのが面倒でなければということですが。
Re:FHS (スコア:1)
Re:FHS (スコア:1)
基本的にはルート直下の/bin, /sbinについては両方ともルートパーティションのみのmountで使用できるよう, スタティックリンクにしておく物がほとんどです. (FreeBSD4.8では/bin下ではrmailのみがダイナミックリンクでした)
現在ではbinは一般ユーザでも使用する物, sbinは原則的には管理者のみが使用する物という感じみたいです. これにより, PATHを切った際に一般ユーザが不要な管理コマンドを見に行かなくする, といった管理上の利便性があると思います.
Re:FHS (スコア:3, おもしろおかしい)
/Linux2.24/system32/vmlinuz
/Program files/Emacs21.3/bin/
/Documents and Settings/Default User/My Documents/
/LNTemp
(以下略)
# 適当にID
Re:FHS (スコア:1)
# /usr/local/bin/w3m.exe /usr/home/g7/bookmarks/slash\ dot\ japan.url なのでG7
実際にそれをやって (スコア:2, 参考になる)
やれやれな話ですねぇ
Re:いっそのこと (スコア:1)
grepかけてディレクトリ名を特定しようにも、 Winだと長すぎて読めなかったことがあります。
ふつうにMy Documentsにたとりつくまで、
C:\Documents and Settings\Administrator\My documents\
と、ここまでで53文字。
更にこのしたで細かくディレクトリ分けしようなら、もっと長くなります。
対処が「ユーザ名を短くすること」なんてのはいやです。
Re:いっそのこと (スコア:1, 参考になる)
Word2000でも「グループ文書」(子文書をインクルードして親文書に取り込める機能)は、 途中のディレクトリ名に空白はおろか 日本語文字が入っただけで相対パス指定が無効になり、 他のディレクトリに移動させただけでとたんに文書が読めなくなります。
そもそもWordで20ページ以上の文章を作ろうと 思うのがいけないのだとは思いますが。
およよ? (スコア:1)
およ? 結構書いていると思いますが。。。
20ページでへこたれてしまってはまずいですよ。
200ページでは、ダウンかなぁ???
高いスペックのPCならいいんだよ。さぁみんな買い替えよう!!!(ってことだろ?)
Re:同一バージョンをいくつも入れられる (スコア:2, 興味深い)
/usr/java/j2sdk1.4.1_02
/usr/java/IBMJava2-13 -> /opt/IBMJava2-13
/usr/java/jdk1.3.1
で使っているんですが(Redhat7.3にRPMでインストール)、これで
問題ありません。それとも別の問題のことを言っています?
「1アプリケーション1ディレクトリ」という考え方は昔からあっ
たし、ディレクトリ名が違うというのが新しいだけじゃないのか
な。/.ed されていて gobolinux のサイトに接続できないのだけれ
ども、もし gobolinux が
# mv /bin /dokka/bin
とかしても普通にシステムを起動できるようなファイルシステム
を導入した、というのならばそれはそれで画期的なんだけれども。
長いファイル・ディレクトリ名 (スコア:2, すばらしい洞察)
一方、CUI システムは、読みやすさを多少犠牲にしても、入力しやすい命名をする。大文字の使用だって、大文字を1回使うと小指を1回使わないといけないので、CUI ユーザーは特に理由もなくなんとなく大文字と小文字を混ぜるなんてことは、やらない。(全部大文字だったら、CAPS を入れっぱなしにしておけばいいので、それはそれで問題はないと思うけど。)
どっちがいい悪い、という問題じゃなくて、CUI と GUI で設計が違ってくるってこと。だから、GUI を念頭に作られた MacOS や Windows を「キーボードでも使えるよ」というのは、CUI を使い込んでいない人の言うことだ。
Windows なんかは、それをもっとつきつめているんで、人々に「CUIは面倒だ」という考えを植えつけるのに役立ってると思う。
"C:\Documents and Settings\hogehoge\My Documents\foobar" なんて、面倒で入力してられん。「Administrator」にしてもそう。というか、なぜテキストファイルが「.doc」じゃなくて「.txt」なんだ。「.txt」のほうが入力しにくいじゃないか。
DVORAKなら楽です (スコア:2, おもしろおかしい)
>「.txt」のほうが入力しにくいじゃないか。
DVORAKにすると、どちらも楽ですよ。
DOC→左中指、右人差し指、左薬指、右中指
TXT→左中指、右中指、左人差し指、右中指
DVORAKに慣れるのが大変ですが。
Re:長いファイル・ディレクトリ名 (スコア:1, 参考になる)
Re:長いファイル・ディレクトリ名 (スコア:1, おもしろおかしい)
#あれ?
Re:長いファイル・ディレクトリ名 (スコア:1, おもしろおかしい)
Re:長いファイル・ディレクトリ名 (スコア:1)
特に日本語を使っていたりすると, 面倒さ倍増.
ということで, ファイルマネージャと連携を取って, クリック一発でファイル名とかパスを入力できるGUI指向のシェルってのが欲しいんですが...
Re:長いファイル・ディレクトリ名 (スコア:1)
なら、cmd.exe とエクスプローラを使用して、かなり楽に入力することができますよ。
エクスプローラのファイルをドラッグして、コマンドプロンプトの画面にドロップすると、カーソル位置にファイル名が展開されます。これ、結構便利で、マイクロソフト教に転びそうになります(笑)
Re:MacOS Xのことを (スコア:1)
大文字で始まっていると、GUI で表示される。
Re:MacOS Xのことを (スコア:1)
Re:MacOS Xのことを (スコア:1)
しました。慣れればいいんでしょうけどね。。。
(I can't get no) satisfaction
Re:MAOIX(トピ違い) (スコア:1, 参考になる)
MAOIXって今で言うWindows Installerや.infファイルの仕掛けを目指してたものだったかと思います。
簡単に言えばインストール時に登録するファイルや書き換えるconfig.sysやautoexec.batをきちんと手順立てて設定ファイルに書き込ませ、規格化させるというものでした。この規格に従っていればアプリケーションがアンインストーラを用意することなくMAOIXが自動的に処理を代行できる、という理想が掲げられていたものです。
そこでexeファイルをはじめとする様々なファイルの置き場所が*nixっぽかった(正しくはBSDをお手本にしたみたいです)ので、レス元のように「Unix風のディレクトリ」に見えたのでしょう。
当時はアンインストーラ自体がほとんど必要とされておらず、ユーザは自主的にディレクトリを削除するとかconfig.sysを直すとかで事実上のアンインストール作業を実行する前提が成り立っていたばかりか、MAOIXの設定ファイルを書く作業があまりにも面倒でなかなか従ってもらえなかったため、ほとんど広がらなかったような覚えがあります。
Re:MAOIX(トピ違い) (スコア:2, 興味深い)
そうですね、もっと簡単なものですが。autoexec.batやconfig.sysの各行を
読み取ったり、編集したり、同様に簡単なテキストファイルの読み書き、
あとは、ディスクの残り容量や接続されているドライヴ数を得る関数や
画面にメッセージ出すための関数類(Basicのprintやlocateやclsみたいな)、
あとはif-else、while、for、do-whileのような制御構造、数値でも文字列
でもある変数...etc.などをもった簡単なインタープリター言語でした。
> 当時はアンインストーラ自体がほとんど必要とされておらず、
> ユーザは自主的にディレクトリを削除するとかconfig.sysを直すとかで
> 事実上のアンインストール作業を実行する前提が成り立っていたばかりか、
それはその通りですが、
> MAOIXの設定ファイルを書く作業があまりにも面倒でなかなか
> 従ってもらえなかったため、ほとんど広がらなかったような覚えがあります。
そんなに面倒な作業じゃなかったですよ。(そのアプリケイション自体の
インストーラーをCなどで書くことを考えれば)
(maoix.exeを作った本人が言ってるのですから本当です!^^)
統一仕様のディレクトリー構成がBSDっぽかったのは、当時のASCIIの
担当者のせいでしょうね ;)
もう時効でしょうからバラしてしまうと、
M = Microsoft
A = ASCII
O = 大塚商会
I = I・Oデータ
X = その他
の略だったはず。