アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ナニゲにアレゲなのは、ナニゲなアレゲ -- アレゲ研究家
そもそも (スコア:5, すばらしい洞察)
OSによってはもう15年も前に可能になっていたことなのにどうして未だに日常的にそういう使い方ができる環境になってないんだ?
Re:そもそも (スコア:1, すばらしい洞察)
最近は「同じ名前のアカウントで違うホストに直接ログイン」でしょう?
Windowsのドメインログオンだって「同じアカウントで違うホストに直接ログイン」なんだし。
(Activeなんたらだとどうだか知らないが)
Re:そもそも (スコア:1)
ここで言うのは同じアカウントで違うホストに直接ログオンです。
もちろんNetInfoとファイルのサーバは共通ですが、いずれのホストにログオンしても(その画面解像度やCPUアーキテクチャにかかわりなく)同じように利用できる環境が存在していたのです。
Re:そもそも (スコア:0)
Re:そもそも (スコア:0)
Re:そもそも (スコア:0)
Windows なら移動プロファイルにしてドメイン管理すれば、ユーザーが行なえる範囲の操作は全てサーバーにコピーされ、ログオン時に端末にコピーされるでしょ?
ユーザーの権利を阿呆みたいに拡大して使ってるなら、それはその管理者の責任でデータを移すような処理をすれば良いだけですし。
Re:そもそも (スコア:2, すばらしい洞察)
共有ホームを使えば即時反映されるから解決する…なんてことはない。共有ホームに置けるのは極一部のデータのみ。
一応、オフラインフォルダを使うことでコピー量は低減できるらしい。でもそもそも移動プロファイルに未対応のソフトウェアもあるし。
NFSホーム(+automount)を知らない人にとっては移動プロファイルは画期的な機構かもしれないが、知ってる人にとってはややこしい割に使えない機構…だと思う。
Re:そもそも (スコア:1, 参考になる)
たとえば、毎回サーバからクライアント、クライアントからサーバへのコピーが発生する点。あるユーザアカウントに対して同時に位置クライアントからのみのログオンしか許さないのであれば問題は少ないのですが、同時に複数のクライアントからログオンした際に作業の不整合が発生する可能性があります。
また、デフォルトではMy Documentsとデスクトップがユーザプロファイルにあるため、ユーザが通常の作業でファイルを頻繁、かつ大量に置く可能性があり、これもまたプロファイルコピーのオーバヘッドを増大させます。
このあたり、Windows 2000/XPはまだまだマルチユーザ・分散クライアント対応という点で過渡期のOSであるといわざるをえないでしょう。
Re:そもそも (スコア:0)
Re:そもそも (スコア:2, 興味深い)
ただ指摘されているようにデスクトップに大量にファイルを置いているとログオンごとにNWをいじめる事になっていました。
当時の環境ではファイルサーバの容量がきつかったです(導入初期が30MBで最後の頃は一人100MBまでだったかな)。
Re:そもそも (スコア:1)
フォルダリダイレクトが最適解かどうかは,その場所次第ではありますが,ログイン時のネットワークオーバヘッドはほぼ無力化出来ます.
------------------------
いつかきちんと仕上げよう
Re:そもそも (スコア:0)
でも、ネットワークでフォルダを共有(SMB)するくらいならば、フォルダリダイレクトを活用して、デスクトップ等を共有するというのはいい選択だと思うけど。プロファイルのコピーはファイルサーバーでの一元管理って意味で(特にデスクトップを含めて)もなんか、個人的には好きじゃない。
フォルダリダイレクトとは直接関係ないが、各マシンでの統一環境って意味では、デスクトップの利用程度ならいいけど、問題はクライアント毎にOSのバージョンが違うとかそういうのが混ざると、アプリケーション環境、プロファイルも含めて土の端末からも完璧に同じってはのは無理があるよね。win2k と winXP の混在環境って、予算のないところだと結構あると思う。そこまで、ぴっちし、同じにしろ!ってのはまぁ、勘弁してくれって事で。
まぁ、あまり大規模の環境で構築・運用・使ったことないので、どこで何がベストなのかは知らないけど。windows でも、unix 風味にどこにログオンしてもホームは一緒ってのが簡単にできるってのは、最初感動したのを良く覚えている。無論アカウント情報も。
Re:そもそも (スコア:0)
少なくともWindowsは同じアカウントで違うホストにログインできますよねえ。
Windows以外の同じアカウントで違うホストにログインするような環境っていうと、単にアカウント情報だけNISやLDAPとかで共有しているだけで、ホームディレクトリもNFSとかで同じものを使っていたり…。
Re:そもそも (スコア:0)
下手に同期処理などの小細工するよりも、単純に同じものを使ってたほうが便利なんじゃないかと思います。
Re:そもそも (スコア:0)
へ?
#957881 のACは15年前に既に存在していた共通アカウント別マシンログインはそんな単純なものではないって言ってるんじゃないの?
それがどういうものなのか名称すら教えてもらえないですけど。
同じホームディレクトリを使っていて「別のマシン」と思ってたりしたんなら、よく分かってなくてX端末使ってる初心者と変わりないと思う。
Re:そもそも (スコア:0)
Re:そもそも (スコア:1, 興味深い)
CPUサーバとファイルサーバとディスプレイサーバを分ければ今でも十分可能なんじゃないかと思うけど、そういう使い方してるところはあまり見かけないのは何故なんだろう。
Re:そもそも (スコア:0)
さぁ?
「端末」というのが何をさしているか正確にわかりませんが
13年前に大学の情報処理教育センターで
私が始めて触れたウィンドウシステムも持ったNeXTでは
同じアカウントでログインしていましたが
単なるダム端末、X端末ではなく、単体でそれなりの
処理能力を持った端末であったと思います。
# どこの大学かはばれそうなのでAC
Re:そもそも (スコア:1, 参考になる)
大阪大学の情教に92年に導入された黒NeXTの場合、
・アカウントだけは集中管理(認証のみ)
・全ての端末は全く同じ環境になっている
・ユーザーは端末上にファイルを保存できない
(一時的なファイルは作れるが、ログアウトしたら消える)
・環境設定やファイル保持に、フロッピーを使う
という、今の Portable Firefox に近い形だったかと。
おかげで、できるだけ大容量のFDが使いたいってことで、
2ED フロッピーがよく使われてました。
私は使ったことは無いのですが、
その後、白NeXTが導入された時には、ホームも共有されて、
手ぶらでどこでも同じ環境が使えるようになったと
聞き及んでいます。
Re:そもそも (スコア:0)
>手ぶらでどこでも同じ環境が使えるようになったと
>聞き及んでいます。
えーっと、大学は正解なんですが
白になる前に、確かホームはネットワーク共有に
なった記憶があるんだけどなぁ?
環境保持用の2EDは・・・生協で買いました・・・
# NeXTユーザ以外、2EDなんてみんな使ってないよなぁ
Re:そもそも (スコア:0)
> なった記憶があるんだけどなぁ?
おっと、そうでしたか
じゃあ、豊中-吹田に高速専用線(ATM)を引いた時に変えたのかな?
黒NeXT導入当時は、キャンパス間の線は「ホームの共有なんて論外」なぐらい細かったです。たしか64kだかそれくらい。
認証の本サーバは豊中ですが、吹田にもミラーサーバを置いてたはず。そうじゃないと認証すらおぼつかないと…
#そのあたりは UNIX マガジンをひっくり返せば分かるんでしょうけど、手元にないや…
Re:そもそも (スコア:0)
Re:そもそも (スコア:0)
それじゃあ15年どころじゃないはるか昔からあるTSSになっちまうような…
TSS対話環境っていつからあるんだろ。DECのVT05端末が作られたのが1970年 [vt100.net]だそうなので、
少なくともそれ以上には遡るのだろうが…
Re:そもそも (スコア:1)
パスワード他を共有したマシン群のことだと思う。20年前までは行かな
いけれど、80年代後半に使ってましたよ。VAXからSunに変わって便利
なんで結構嬉しかった記憶があるな。
#Sun3が4台くらいのクラスタだったような。
Re:そもそも (スコア:0)
> 同じアカウントでログインしているのに端末ごとに環境が違うのがおかしい。
> OSによってはもう15年も前に可能になっていたことなのに
と書いてある方はそうかもしれんけど、
それに対して同じホストと書いてしまったのだから外れちゃったんじゃないのというお話。