Windows上のUNIX環境はどれが使いやすい? 111
ストーリー by yoosee
選択肢が増えてきた 部門より
選択肢が増えてきた 部門より
Anonymous Coward 曰く "OS毎に得意・不得意があり、それぞれのOSに適したことを作業させるのが最良であるかもしれないが、Windows上でUNIX環境があると便利なことも多い。2台準備するかデュアルブートさせれば済むことであるが、スペースや効率の面で問題がある。そのような需要に応えてきたのが1995年にプロジェクトが始まったCygwinであるが、最近では他の選択肢も増えてきた。
主だったものでは、MSがリリースしており昨年無償化された
MS SFU(Windows Services for UNIX)、
Cygwinにインストーラ・RPMパッケージ管理・日本語環境等を追加したX on Windows3 、PC/AT互換機そのものをエミュレートするVMwareやVirtual PCの上でFreeBSDやLinuxを動かす、あるいはCooperative Linux(coLinux)でLinuxをWindowsアプリとして動かすなど多様な選択肢があり、初・中級者レベルではどれにしようか戸惑ってしまう。
そこで、ここに挙げた例に関わらず Windows におけるUNIX環境を実際に使用している/.Jの方々に、動作の軽さ・重さなどの使用感や、機能・管理のしやすさ等の面で、皆さんが使いやすいと思っているのはどんな方法か、お聞きしたい。"
使ってみたもの比較 (スコア:5, 参考になる)
・VMware Workstation - 汎用のバーチャルマシン。x86系OSならたいてい動かせる。商用ソフト。
○⇒汎用性は最も高く、安定している。スナップショット機能など、使い勝手もよい。
×⇒ちょっと重い。ちょっと高い。
・coLinux - Linux専用バーチャルマシン。Linuxカーネルにパッチを当て、Windowsの専用ドライバ上で動かす。使い勝手はまんまリモートにあるLinuxマシン。
○⇒Linux専用なためか、比較的軽い。experimentalな機能(cofsとか)を使わなければ安定している。サービス化できるのがうれしい。
×⇒画面回りは弱い。現状では別途Xサーバの調達が必要。ファイアウォールが有効だと、ネットワーク設定に悩む場合がある。
・cygwin - UNIXシステムコールやデバイスアクセス等をcygwin1.dllでエミュレートすることによって構築された疑似UNIX環境。
○⇒メジャーなツールはたいてい移植されているので、UNIXユーザがWindows上でオペレーションするのに便利。Win32サブシステム上に構築されているので、Win32APIも使える。
×⇒UNIX的コンテクストとWindows的コンテクストにギャップがあるため(例:ファイルシステムの見え方)、思わぬトラブルの原因となる。マルチバイト関係はだめだめ。特にファイルシステム。
・SFU - Microsoftが提供する(例によって買収して手に入れたものだが)、Windowsカーネル上で動くUNIXサブシステム。
○⇒WindowsとSFUでファイルシステムがシームレスに扱える。NFSでマウントやエクスポートができる。(日本語については「?」だけど)
×⇒一般的なUNIXと似て非なる部分で多大な障害がある(例:ツールをビルドするのにいっぱい手を加えないと通らない、パーミッションやオーナー、/etc/以下などがUNIX的でない)。Win32サブシステムとの会話が標準入出力とネットワークしかない。Win32APIが叩けない(=GUIが一切扱えない)のが何げに致命的。
個人的結論は、
いろんなOSが使いたい⇒VMware
「本物」のLinux環境が欲しいが、それさえあれば十分⇒coLinux
Window上でもつい「ls」とタイプしてしまう⇒cygwin
問題が多過ぎて使いもんにならねー⇒SFU
というところかなぁ。今使ってるマシンには、coLinuxとcygwinが入ってます。
Re:使ってみたもの比較 (スコア:2, 参考になる)
まぁ、それに、
> limits.h:#define MB_LEN_MAX 1
未だにこーゆー定義のままだったりしますから。
> newlib.h:#define _MB_LEN_MAX 8
こんなのも入ってるみたいなんですけど、どーすればいーんでしょーねぇ……。
Re:使ってみたもの比較 (スコア:1)
# ターミナルで UTF-8 がまあ使えるようになったあたりからかなぁ
ちなみに Windows には Cygwin を入れていますが常用しているのは Windows 機ではなくて Mac...
--
ただ、UTF-8 を通す Windows/Mac 用FTPクライアントがあまり多くは見つからないのが難
それぞれも用途に分けて (スコア:3, 興味深い)
VMwareとcoLinuxは、Windowsの世界とか隔離された完全なLinux環境といった感じで、CygwinはWindows側の世界をシェルでいじりたい時用の環境と使い分けています。
VMwareとcoLinuxの方は、VMwareをVer1から使ってきましたが、最近coLinuxも安定してきたので、サービスとして常駐できるのが便利でcoLinuxが中心となってきています。起動とシャットダウンを意識しないで使えるのはすばらしいですね。
coLinuxでホストのFileSystemを直にマウントできるcofsがもっと安定すれば、Cygwin+Perlワンライナーで処理していた作業の多くも、coLinuxで代替できる気がして期待しています。
DesktopはWindowsで、その上で仮想Linuxで便利なサービスが使えるので、coLinux+LAMP環境はとても快適です。
環境でなく組み合わせで (スコア:2, 参考になる)
あとはMeadow [meadowy.org]とかcronNT [vector.co.jp]なんかでUNIXっぽい環境を整えています。
Your 金銭的 potential. Our passion - Micro$oft
Tsukitomo（月友）
Re:環境でなく組み合わせで (スコア:1)
Win32 ではとりあえず ruby が動けば用が足りるので。Meadow では skk、mew、yatex、emacs-wiki を動かしてます。でも cat がなかっりするので結構不便。コンパイル環境がないのは諦め。
Re:環境でなく組み合わせで (スコア:1)
開発環境まではいらなくて、ちょこっとメモ帳でrubyを書いたりする程度。
Excelの使い方が分からないのと生来の不精のせいで、なぜかsort、uniq、comm、tee、wcなどが必要になってくる。
X 稼働マシンに VNC 接続 (スコア:2, 興味深い)
GUI 不要なら SSH ログインでも十分でしょう。
# わたしはむしろ、Mac から Windows マシンに VNC/RDC 接続することが多いですが。
Re:X 稼働マシンに VNC 接続 (スコア:2, すばらしい洞察)
VNCとちがって、Xのプロトコルをやり取りするので、VNCより快適に動くと思います。
フリーもあるようですが、商用ソフトならExceedとか、国産ならASTEC-Xとかですかね。
Windowsアプリケーション間とコピーペーストもできるので、便利です。
うちの会社は、開発にはRedHat Enterprise or Solarisを使っていて
マシン自体は共有化されているので、
大半は端末PCにExceedを入れてX端末として使ってます。
(私はわがまま言ってUltra60を端末として使わせてもらってますが)
Re:X 稼働マシンに VNC 接続 (スコア:1)
一応入れてはあるものの、あんまり使用していません。
#職員室のWin機をXwinXで動かしたら
#気味悪がられた(笑
---------+---------+----------+
年をとるのは素敵なことです。
Re:X 稼働マシンに VNC 接続 (スコア:3, 参考になる)
つ[日本語106キーボードの設定 [atmarkit.co.jp]]
つ[jp106keymapのパッチ [iokibe.net]]
# 試したばっかなんだけど軽くてイイ感じっス。
Re:X 稼働マシンに VNC 接続 (スコア:3, すばらしい洞察)
でも vnc4 の場合、英文だけですよね。
日本語 patch は未だ見掛けてません。
先に私が投稿にて紹介した X-Deep/32 も日本語は通りませんが。
vnc も Windows 用 X サーバも、何が良いかって、 XFree86 等の設定に手間取る必要がないのが良いんです。
XF86Setup とかでいちいちチップセットを確認したり、ディスプレイの表示能力を調べたり、チップセット固有のオプションとかを調べたり、というような煩わしさが一切ない。
確かにネイティヴの X サーバを立ち上げるよりは速度面のパフォーマンスでは劣るだろうけど、最近のマシンは十分に早いんで、 vnc でも特に問題は感じません。
だって、何も考えなくとも、コマンドラインで指定した解像度で X が起動しちゃうんですから。
DVD 等の動画や MIDI の再生等は Win に任せた方が手っ取り早いですし、 MSIE でないとどうしても閲覧できない web サイトなんてゴロゴロありますし、印刷は Win でやる方が遥かに簡単で柔軟で綺麗ですし。
Windows を完全に捨てることなんてできっこないんです。
vnc に出会ってから、 PC-UNIX の環境設定でハードウェア固有の設定等に時間を費すのがなんだか馬鹿馬鹿しくなってきました。
ついでに言っちゃえば、 coLinux こそ、 Win の不足面を補うツールであり、デスクトップ或はモバイル環境における Linux の正しい使い方じゃないか、とまで思うようになりました。
Linux をノート PC にインストールして色々頑張るより、遥かに楽ですから。
じゃまにならない場所 (スコア:1)
# サーバマシンに雑用させるのはよくないと思いつつも、
# ついついSSHを立ち上げてしまう自分。手軽なんだよなぁ。
yp
Re:じゃまにならない場所 (スコア:2, おもしろおかしい)
玄箱？
Re:じゃまにならない場所 (スコア:1)
Re:じゃまにならない場所 (スコア:1, おもしろおかしい)
＞「下駄箱」
玄箱のCPUにゲタを噛ませて高速化を…（略）
目的で大別すると２つあるよね (スコア:2, すばらしい洞察)
後者はホストの Windows 環境のファイルを弄ったり、プロセスを操作したりといったことが出来るのがメリットで、それが出来なければこんな中途半端な UNIX 環境は出来れば使いたくない派。
てかその目的でもっとより良い環境ってまだ無いんですかね？
Re:目的で大別すると２つあるよね (スコア:2, 参考になる)
SFUはどうなんだろうと気になりつつも、Cygwinでずるずるときてます。
coLinuxは今まであんまり考慮したことなかったですが、
ここでの話を見てるとかなり魅力的な環境みたいですね。
VMwareから離れられるかも。
なんにしろCygwinを本気では使ってないです。
開発だなんだなど本格的にUnixライク環境が必要になったらCygwinでは無理が多すぎます。
考慮しなければならないレイヤが一枚増えちゃいます。
なんでとっととPuTTYを開いてFreeBSDで作業します。楽でいいです :)
>てかその目的でもっとより良い環境ってまだ無いんですかね？
私の今の環境でやるとすると…
・Windowsの方でファイル共有
・VMware(の上のFreeBSD)からsmbでマウント
・FreeBSDのコマンドを使って操作
てことになるでしょうか。プロセス操作は無理ですけど。
Windows側にsshd立ててCygwinのコマンド群を叩いて、それでプロセス取得、操作もやりましょうか。
って私の頭だと混乱するだろうなあ…。
SFU は後がないよ (スコア:1, 興味深い)
Re:SFU は後がないよ (スコア:2, 参考になる)
プリインストールでないエディションだと、どうなるんでしょう。
Interix は標準環境だと gnuツールに慣れた体には違和感があるのですが、cygwin は遅すぎなのとバグ多すぎで、イライラするので、少しずつgnuツールをコンパイルして SFU に環境を移しました。
SFUと cygwinのように ネイティブにWindows のファイルシステムを触れること、Windowsのアプリとの相互に連携動作を行なうための環境と、純粋に Linux/Unix環境を作るための coLinuxや VMWareなどのエミュレータとはカバー範囲がまるっきり違うと思うんですが。
Re:SFU は後がないよ (スコア:2, 興味深い)
> Interix は標準環境だと gnuツールに慣れた体には違和感があるのですが、(中略)少しずつgnuツールをコンパイルして SFU に環境を移しました。
自分で環境をコンパイルしなければならないのは、ほげり倒して遊ぶにはいいですが、今片付けなくてはならない仕事がある時にgrep -rが拒否されたりするのは実に微妙ですね。
私も暇なときに、とりあえずzshなどコンパイルしてはみたものの、そもそもzsh自体がマルチバイトに対応していないので、実用にはなりませんでした。
＃「とりあえずzsh」という所が、何か間違っているような気もする orz
名物に旨いものなし！
Re:SFU は後がないよ (スコア:1)
単純に質問なのですが, なぜfind . -name '*hoge*'としないのは何故でしょうか?
Re:SFU は後がないよ (スコア:2, 参考になる)
だから結局「grep hoge `find .`」は「カレントディレクトリ以下のファイルをfindでリストアップし、全てgrepにかけてhogeという文字列が含まれる行を表示する」という動作になります。つまり一部のgrepが備えている「再帰grep」(GNUのだと-rオプションが相当する)機能と同じことをしているわけです。「find . -name *hoge*」とは全然違いますね。
Re:SFU は後がないよ (スコア:1)
なるほど要はディレクトリも含めてのgrepということですか. ただ, それならパイプを使った方がコマンドライン長の制限がかからないので汎用性は高いでしょう. ちなみにFreeBSDの/usr/srcディレクトリ下で実行すると, みごとに"Argument list too long."でこけました. それともzshだとxargsと同じようにパラメータ分割処理を行っているのかな?
昔のDOS系のOSじゃあパイプは使い物にならなかったけど, WinNT系のOSなら使えるようになったと思っていたんだけど, やっぱり性能的に問題があるのかな?
Re:SFU は後がないよ (スコア:1)
いえ、エラーが出たら諦めて、 find の -exec オプションに切り替えてました。 xargs は知らなかったのですが、こちらのほうが簡潔でよさげですね。
ちなみにzshであれば grep hoge **/* というのもありますが、コマンドライン長の制限に引っかかるのは grep hoge `find .` と同様です。
名物に旨いものなし！
Re:SFU は後がないよ (スコア:1)
あとシェルは指示されたプロセス以外起動しません。引数が勝手に間引かれたり、複数プロセス起動していたら困ります。
xargsは仕様としてコマンドライン引数に入りきらなかった場合、複数回、起動することになっています。
そのためxargsのコンパイル時にはコマンドライン引数の最大長をチェックしてます。＜GNU findの場合
Re:SFU は後がないよ (スコア:1)
それで困ってからでなければ、より打鍵数の多いコマンドは叩きませんねえ。
＃ってか負け惜しみだけど
名物に旨いものなし！
Re:SFU は後がないよ (スコア:1, 興味深い)
Re:SFU は後がないよ (スコア:1)
＃コンパイルの時のメモが手元にないっ
名物に旨いものなし！
私はVMWare派 (スコア:1, 興味深い)
Re:私はVMWare派 (スコア:2, 参考になる)
私もFreeBSD on VMWareで使ってます。
もともとFreeBSDをネイティブで使っていたのですが、Windowsを使わざるをえない状況に追い込まれたため、FreeBSDをVMWare上で動かすという方法をとってます。
VMWare上でXを起動して全画面表示にするとWindowsを意識しないで使えるのでいい感じです(これはWin用Xサーバでもできますが、表示の速さという点でVMWareに匹敵するものを私は知らないです)。
Cygwinは日本語処理周りの挙動がおかしかったので、今では「使いやすいDOSプロンプト」程度の扱いです(苦笑)。
他は…使ったことがないのでなんとも。
Re:私はVMWare派 (スコア:1, 参考になる)
VMwareの仮想ディスクを差分取るモードで動かしていたので、
WindowsXPをいじり倒して壊しても
差分破棄で簡単に復帰できたので重宝してました。
Re:私はVMWare派 (スコア:1, 参考になる)
X11が動くかどうかとか、インストールするハードウェアを
選ばず Linuxを同じ環境にセットアップできるので 便利です
対応しているハードウェアの多さだけならWindowsには 敵いませんから、
Windows+VMware で Linux のための統一ハードウェアを 提供している感じで使っています
Re:私はVMWare派 (スコア:1)
Linux限定なこととXを別に用意することを除けばかなりいい選択肢だと思います。
各種サービスはcoLinuxで動かして、Windowsのファイルをいじる必要が
あるときだけCygwin使ってます。
＃結局zsh、grep、sed、sort、cygstart、wgetぐらいでことたりますが。
Re:え？ (スコア:3, 参考になる)
GUI無しで使えるLinuxやBSDをゲストにしておいたほうが総合的なパフォーマンスがいいんですよ。
重たいOSはホストで。軽いOSはゲストで。
ゲストにもTerminalでアクセスすれば、VMwareのネックの描画の遅さも気にならないって物です。
Re:え？ (スコア:2, 興味深い)
それもありますが、DirectXを使わなければならなくなったというのが実態です(苦笑)。
Re:私はVMWare派 (スコア:1)
VPCでも良いと思ったけど、VMWAREよりもたつくことが多いので、余り実用に向かないと判断。
ただ、使い勝手はVPCの方が良いかと思ったりする。
Re:私はVMWare派 (スコア:1)
VPC確かに操作や設定は、Windowsライクで入り易い気がするけど、仮想ディスクのアクセスが遅すぎるね。
微妙な差だけど、重要な部分なんで、VMWareの勝利ってとこかな、俺の中では。
cat_kei@
使いやすいshell-Likeなインターフェースが (スコア:1, 参考になる)
だったりします。
いろいろ (スコア:1, 興味深い)
ひっくりかえせば「Linuxってメッセンジャーもないの？」と
言ってた奴と同じ心根になりかねない。
Linux上でのゴテゴテGUIアプリがなんか興ざめなように
Windows上でならWindowsらしい使い方を工夫したい。
findやgrep、tar、wget gzip, bzip2、Perlなんかはどうしても欲しいんだけど
シェルっぽいことをバッチファイル書いてやるとどうなるか、とか
あるアプリケーションでどうこなすか考えてたほうがおもしろい。
ApacheやMySQL、NamazuにEstraier。ソフトウェア単位だと
あっちで慣れたものがWindows上でも動くから、
Win環境に不足に感じることはもうほとんどなくなった。
といいつつMeadow + eshellは手放せないんだけどｗ
Re:いろいろ (スコア:1)
wgetは是非とも欲しいし、Python使いなのでPythonも必須ですが、tar, gzip, bzip2の代わりは7-zipなどを使うことでおおむねカバーできるし、find, grepの代わりはエクスプローラで間に合わせてます。
エクスプローラじゃ力不足な時は(めったに無いですが)Pythonでスクリプト書いてしまいますね。最近os.walk()の使い方に凝ってまして。
しかしそのスクリプトはLinuxマシンにsshで入ってEmacsで書いてます。ダメじゃん。
Re:いろいろ (スコア:1)
Scripting.FileSystemObject でもある程度の処理は可能ですね。
バイナリが扱えないのが痛いですけど。
使うたびにノートン先生が怒るのはセキュリティ的に甘すぎるのか、
ノートン先生が短気なのか…
逆もアリですよねぇ？ (スコア:1)
Linux上で、Windowsを利用する。。。のも選択枝に入ると思います。
で、ちょいとUbuntuお気に入り。
+QEMUあたりで、Windows動くといいなぁと思いつつ、
リモートデスクトップで現状満足してたりします。(汗；)
理想的には、Xen上でWindowsも動いてくれることですかね。
どちらにしても、Windowsさわる時間が短くなってくれますが、
なくなってくれそうにはありませんねぇ。
クロスコンパイラだけなら (スコア:1)
環境作るのにコツが要るけどね。
from もなか
Re:Cygwinかな？ (スコア:1)
ちょっと前はVNCの存在を知りながらcygwinのXでリモートの接続を試みたりしました。
接続には成功したものの、それに満足してしまい(使い勝手が悪いのもあったけど)あっさりVNCに流れてしまいました。
でもそれからあまり時間の経たないうちに、遠隔でGUI使うのってどうなんだろうか？
と思ってしまいCygwin+XもVNCも放置状態。
gccなんかも入れてはいますが結局はLinuxマシンにアクセスしてやってしまったり。
最近はsshクライアントとエディタ(vim)としてしか使っていない現実。
結局はwindowsの範疇にあるものはwindowsでオペレーションした方が面倒もありませんし。
Cygwinの問題点 (スコア:1, 興味深い)
アップデートに失敗すると、それ以降再インストールで引っかかるとか
基本的な問題点ってどうなったんでしょう？
Re:飛び道具 (スコア:2, 興味深い)
違反と言うより、来年以降、intel MacOSXが台頭すると
それが動作速度、ホストの安定性と利便性の点から
本命になるんじゃないかと思うんですが・・・
Re:飛び道具 (スコア:1)
私もそれです。
たまにVirtualPCを全画面表示にして、知人を驚かせます。
でも…設問と逆なんですよね…
----------------------------------------
You can't always get what you want...
Re:飛び道具 (スコア:1, おもしろおかしい)
VPCの2kで，Basilisk II [nifty.com]を走らせるっちゅう，おバカな事やってます....
え，68kMac買ったらいい，Classic使えばいいじゃんって？
Re:cmd.exe(WindowsXP) (スコア:1, 参考になる)