yooseeによる
2005年09月26日 12時49分の掲載
選択肢が増えてきた部門より。
選択肢が増えてきた部門より。
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
こんなのも入ってるみたいなんですけど、どーすればいーんでしょーねぇ……。
親コメント
それぞれも用途に分けて (スコア: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（月友）
X 稼働マシンに VNC 接続 (スコア:2, 興味深い)
GUI 不要なら SSH ログインでも十分でしょう。
# わたしはむしろ、Mac から Windows マシンに VNC/RDC 接続することが多いですが。
NHK 受信料はテレビの台数分契約にしてほしい
Re:X 稼働マシンに VNC 接続 (スコア:2, すばらしい洞察)
VNCとちがって、Xのプロトコルをやり取りするので、VNCより快適に動くと思います。
フリーもあるようですが、商用ソフトならExceedとか、国産ならASTEC-Xとかですかね。
Windowsアプリケーション間とコピーペーストもできるので、便利です。
うちの会社は、開発にはRedHat Enterprise or Solarisを使っていて
マシン自体は共有化されているので、
大半は端末PCにExceedを入れてX端末として使ってます。
(私はわがまま言ってUltra60を端末として使わせてもらってますが)
親コメント
Re:X 稼働マシンに VNC 接続 (スコア:3, 参考になる)
つ[日本語106キーボードの設定 [atmarkit.co.jp]]
つ[jp106keymapのパッチ [iokibe.net]]
# 試したばっかなんだけど軽くてイイ感じっス。
GNU is a religion. [flcl.org]
親コメント
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 にインストールして色々頑張るより、遥かに楽ですから。
GNU is a religion. [flcl.org]
親コメント
Re:じゃまにならない場所 (スコア:2, おもしろおかしい)
玄箱？
始祖あんりあ（Ichigo Mayo)
親コメント
目的で大別すると２つあるよね (スコア: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 は後がないよ (スコア:2, 参考になる)
だから結局「grep hoge `find .`」は「カレントディレクトリ以下のファイルをfindでリストアップし、全てgrepにかけてhogeという文字列が含まれる行を表示する」という動作になります。つまり一部のgrepが備えている「再帰grep」(GNUのだと-rオプションが相当する)機能と同じことをしているわけです。「find . -name *hoge*」とは全然違いますね。
親コメント
私はVMWare派 (スコア:1, 興味深い)
Re:私はVMWare派 (スコア:2, 参考になる)
私もFreeBSD on VMWareで使ってます。
もともとFreeBSDをネイティブで使っていたのですが、Windowsを使わざるをえない状況に追い込まれたため、FreeBSDをVMWare上で動かすという方法をとってます。
VMWare上でXを起動して全画面表示にするとWindowsを意識しないで使えるのでいい感じです(これはWin用Xサーバでもできますが、表示の速さという点でVMWareに匹敵するものを私は知らないです)。
Cygwinは日本語処理周りの挙動がおかしかったので、今では「使いやすいDOSプロンプト」程度の扱いです(苦笑)。
他は…使ったことがないのでなんとも。
親コメント
Re:え？ (スコア:3, 参考になる)
GUI無しで使えるLinuxやBSDをゲストにしておいたほうが総合的なパフォーマンスがいいんですよ。
重たいOSはホストで。軽いOSはゲストで。
ゲストにもTerminalでアクセスすれば、VMwareのネックの描画の遅さも気にならないって物です。
親コメント
Re:え？ (スコア:2, 興味深い)
それもありますが、DirectXを使わなければならなくなったというのが実態です(苦笑)。
親コメント
使いやすいshell-Likeなインターフェースが (スコア:1, 参考になる)
だったりします。
いろいろ (スコア:1, 興味深い)
ひっくりかえせば「Linuxってメッセンジャーもないの？」と
言ってた奴と同じ心根になりかねない。
Linux上でのゴテゴテGUIアプリがなんか興ざめなように
Windows上でならWindowsらしい使い方を工夫したい。
findやgrep、tar、wget gzip, bzip2、Perlなんかはどうしても欲しいんだけど
シェルっぽいことをバッチファイル書いてやるとどうなるか、とか
あるアプリケーションでどうこなすか考えてたほうがおもしろい。
ApacheやMySQL、NamazuにEstraier。ソフトウェア単位だと
あっちで慣れたものがWindows上でも動くから、
Win環境に不足に感じることはもうほとんどなくなった。
といいつつMeadow + eshellは手放せないんだけどｗ
逆もアリですよねぇ？ (スコア:1)
Linux上で、Windowsを利用する。。。のも選択枝に入ると思います。
で、ちょいとUbuntuお気に入り。
+QEMUあたりで、Windows動くといいなぁと思いつつ、
リモートデスクトップで現状満足してたりします。(汗；)
理想的には、Xen上でWindowsも動いてくれることですかね。
どちらにしても、Windowsさわる時間が短くなってくれますが、
なくなってくれそうにはありませんねぇ。
UNIX-like tools (スコア:1)
あとは、tcshとPerl(どちらもcygwinじゃなくてWin32版)ぐらいかな。
cygwinはWindowsネイティブとのファイルシステムのすりあわせ方が気に入らないのでできるだけ使わない方向で。
まあ、FreeBSD機が別にあるので、ここぞという時はそっちを使ってるだけなんですけど…
pkgsrc (スコア:1)
/procにあるプロセス情報（W32なプロセスも全部見れるんで）WindowsなサーバのUN*X的な自動管理とかできたらなぁって 思って今は試験的に使ってますけどね。
(今のところpkgsrcでコンパイルしたもの)
使用目的はスラド(わら (スコア:1)
以前はcygwinでしたが、コンパイルを通すのが(^^;面倒なのと、遅いのとで、
最近はめっきりcoLinuxです。
coLinuxは一応OSなのに、ライブラリなcygのほうが
w3mのスクロールが遅いってのは、一体どういうことなんだか。
そこへ来るとcoLinuxだと、キャッシュ(？)に入ってる二度目のBootとかだと、
まぢ３秒でBootしたりする(OSASKもびっくりってか？)んで、ストレスなんて全然ないです。
もちろん上げっぱなしにしてても(メモリとか足りなくならん限り)ストレスは無いですし。
コンパイルが面倒ってのは、依存ライブラリを「揃える」のが面倒っていう意味です。
これはcoLinux云々というよりdebianでapt-getのお蔭ですね。
楽してます。依存ライブラリがどれなのかは勝手に解決してくれるんで。
バイナリがいきなりインストールされるかどうかは、俺としては二の次だなあ。依存関係のほうがよほど重大。
知らねえライブラリの名前を求めてGoogleをさまよったり(わら)、
ソース追っかけてコンパイル条件を考えたりするのは、
ちと疲れました。
cygwinにapt環境を入れるっていうdistro(?)に目鼻がついたら、また使う気になるかも知れませんが、
少なくともあの「テキストとGUIの悪い所どり」みたいな感じのcygのインストーラーは
もう触りたくない感じ。
＃おかげで、初めて(わら)UTF8対応なw3mを手にすることが出来たのでG7
ディスクの食いかたも、cygで下手に色々入れると(しかもインストーラがアレだから
入れるものの選別作業が面倒すぎて、うんざりして全部入れちゃいがち) あっさり数GBに達します。
それに比べりゃcoLinuxでささやかに1GB(GUIものを一切入れなきゃ楽勝でしょう)のほうがよほどマシですし、
cygのファイル数は凄いのに対して、coなら仮想ディスクファイル１つで済むから、繁雑さも少ない。
あとはcoLinuxなw3mから、WinのFireFoxへ、URL飛ばしですね。
どっかで教わったので俺もやってみました。
% cat ~/local/bin/openurl
#!/bin/sh
(
echo 'require "Win32API"'
echo 'url="'"$*"'"'
echo 'shellexecute = Win32API.new("shell32.dll","ShellExecuteA",%w(p p p p p i),"i")'
echo 'shellexecute.call(0, "open", "#{url}", 0, 0, 1)'
) > ${HOME}/sambaのどこか/url.rb
こんなScript(ruby Scriptを作るshell Scriptっす)をw3mの外部ブラウザに割り当てて、
win側ではurl.rbが生成されるのをフォルダ監視ソフトの類で待ち受けて”実行”すれば、
FireFox(などのブラウザ)がWin側であがります。
これ系の仕込みをやっておくと、WinとcoLinuxが別OSであるがゆえの不便は、だいぶ緩和される感じ。
余談。
cygwinを「c:\」にインストールして、それをアンインストールすると
やっぱりcドライブ全部持って行かれるんですかね？(わら
UNIX風PATHを理解する非cygwinソフトとの相性を考えると、
/usrに対応する実フォルダは、やっぱりc:\usrに存在してて欲しいんですよね。うーむ。
クロスコンパイラだけなら (スコア:1)
環境作るのにコツが要るけどね。
from もなか
親コメント
Re:飛び道具 (スコア:1)
私もそれです。
たまにVirtualPCを全画面表示にして、知人を驚かせます。
でも…設問と逆なんですよね…
----------------------------------------
You can't always get what you want...
親コメント
Re:cmd.exe(WindowsXP) (スコア:1, 参考になる)
親コメント
Re:Cygwinかな？ (スコア:1)
ちょっと前はVNCの存在を知りながらcygwinのXでリモートの接続を試みたりしました。
接続には成功したものの、それに満足してしまい(使い勝手が悪いのもあったけど)あっさりVNCに流れてしまいました。
でもそれからあまり時間の経たないうちに、遠隔でGUI使うのってどうなんだろうか？
と思ってしまいCygwin+XもVNCも放置状態。
gccなんかも入れてはいますが結局はLinuxマシンにアクセスしてやってしまったり。
最近はsshクライアントとエディタ(vim)としてしか使っていない現実。
結局はwindowsの範疇にあるものはwindowsでオペレーションした方が面倒もありませんし。
親コメント
Cygwinの問題点 (スコア:1, 興味深い)
アップデートに失敗すると、それ以降再インストールで引っかかるとか
基本的な問題点ってどうなったんでしょう？
親コメント
Re:飛び道具 (スコア:2, 興味深い)
違反と言うより、来年以降、intel MacOSXが台頭すると
それが動作速度、ホストの安定性と利便性の点から
本命になるんじゃないかと思うんですが・・・
親コメント
Re:CAL (スコア:1)
http://www.microsoft.com/japan/windowsserversystem/virtualserver/evaluation/virtualizationfaq.mspx＃一次情報を見つけたのはいいけど、この文章が何を言っているのかわからない orz
名物に旨いものなし！
親コメント
Re:最強の疑似UNIX環境はDOSKEY？ (スコア:1)
# ローカル環境で激しくunix系コマンド使うことってあんまりないんですよねぇ・・・
親コメント