Windows の場合、ソフトウェアカタログを作るとしたら日本だけでも数十万のアプリの名前が並んで、カテゴリー単位で分けても数千とかが並ぶ事になるのですね。
当然ながらメンテナンスコストなどもかかりますし、Windows にはアプリケーションが多すぎて非現実的なのですよ。Vector 辺りは頑張って収集していましたけど。
Perl でも Ruby でも Python でもなんでもいいですが、使いたいモジュールが OS 標準のパッケージシステムに含まれていないことは非常に運用上の手間が増えるため、避けたいわけです。
その基準はクライアントマシンとしての Ubuntu ならいいかもしれませんが、Ubuntu Server を Web サーバーとして利用したいなどの場合には「必要なモジュールがまとめて管理できない」ディストリビューションは大きなマイナスにしかなりませんし、個別に入れるなら Windows でも Linux でも大差がない、という事になってしまいますよ。
うーん。 (スコア:0)
Re: (スコア:0)
デスクトップ用途には失格。
Re: (スコア:0)
Re: (スコア:1)
ブラウザ上でリンクをクリックして出てくるダイアログで「実行」を選べばOKです。
まあブラウザキャッシュやTEMPディレクトリにダウンロードされてるといえばダウンロードされてますが。
Re: (スコア:3, 興味深い)
そうじゃなくて、ブラウザ上でテンポラリディレクトリにダウンロードして
実行するとしても、配布元をいちいち巡らなくちゃいけないわけでしょう?
それぞれインストールしたいものがどこで配布されてるのかを把握してなくちゃ
いけないWindowsデスクトップの文化がLinuxデスクトップ的には失格なわけです。
# aptitude install firefox
これだけで済む。GUIのラッパーを被せても同じです。
リストからインストールしたいソフトウェアを選択して、「インストール」ボタンを押すだけ。
どちらが優れているとはいいませんが、
というのはそういう意味ではないです。
Re: (スコア:0)
IE起動して検索窓にfirefoxといれて出てきたリンクからダウンロードボタンを押すのと
対して違いなくないですか?
Re:うーん。 (スコア:0)
ソフトウェアを入れるまでに使わないといけない頭の量が違います。
例えば2chなどで「windowsのお勧めフリーソフトを挙げるスレ」にあるものを試してみたいとき。
一々サイト覗いてダウンロードのリンク探して、sourceforgeだったらミラーサイト選ぶのに更に1アクション増やして、
という作業を延々と繰り返すのは面倒です。
落としたら落としたでsetup.exeを起動させて「次へ」ボタンの連打。
気に入らなかったらひとつずつアンインストールを繰り返し。これもまた無駄にインタラクティブ。
pacman -S firefox chromium konquerorで3つのブラウザをインストール、気に入らなければpacman -Rでアンインストール。
debian系でもredhat系でも殆ど同じです。
Re:うーん。 (スコア:1)
Windows の場合、ソフトウェアカタログを作るとしたら日本だけでも数十万のアプリの名前が並んで、カテゴリー単位で分けても数千とかが並ぶ事になるのですね。
当然ながらメンテナンスコストなどもかかりますし、Windows にはアプリケーションが多すぎて非現実的なのですよ。Vector 辺りは頑張って収集していましたけど。
また、Linux などのソフトウェアカタログも万能ではありません。たとえば Perl を使いたい場合でも、CPAN にあるモジュール群すらメンテナンスされていなくて Ubuntu などでは数百、RedHat 系では数十程度しかない訳ですが、本当にそれで足りていると思ってますか?
メンテナンスを考えたらできるだけ入れたくないものの、必要であれば結局 CPAN モジュールを利用してインストール。ディストリビューション標準の管理から外れるため、更新管理も結局自分で行う必要が出てきます。
# FreeBSD だと数千入ってますが、それでも入っていないものは入っていません。
例えば○○などで「Linux のおすすめフリーソフトを挙げるスレ」にあるものを試してみたいとき。
リポジトリーに含まれているかを確認し、存在しない場合は諦めるか自分で build。もしかしたら誰かがパッケージを作ってくれているかもしれないけれど。
たまにパッケージ名にバージョン番号などが付いている場合があるため、この点を意識して入れる必要がある場合もある。
……とかいう場合はどうしましょうね。メジャーなものは大体入ってますが、そうではない場合は結構漏れが多いですよ。
Re:うーん。 (スコア:1)
最初に管理方法が無く各ベンダにまかせてたから、統一など不可能だけど、あれば便利だったでしょう。
少なくとも今みたいに各ベンダー(Google, Apple, Adobe, Java, DivX, etcetc)が独自にアップデータを提供する、みたいな事態は避けられたかと。
> リポジトリーに含まれているかを確認し、存在しない場合は諦めるか自分で build。
もはやUbuntuのリポジトリに含まれていないようなアプリは、パッケージが存在しない/メンテされないくらい、それを必要としているユーザーが少ない訳だから、どっちにしろ初心者が安心して使えるものではないでしょ。
iTunesに無いアプリをiPhoneにインストールするようなもんだ。
Re: (スコア:0)
2万です。数千とは桁が違う。Debianもね。
Re:うーん。 (スコア:1)
ゴミの様なプログラムでも好き勝手に作って公開出来てたから、今のWindowsユーザ数を支えるだけのエンジニアを確保できたんだろうけどね。
今でこそプログラムはインターネットで落としてきてインストールするのが当たり前になってるけど、昔は雑誌のCDからとかが多かったから(回線が細すぎるから)一括管理なんて出来ないだろうし。
#ちょうど/.に広告でてるけど、今はWeb系に限ってWindowsもネットワークインストールの管理プログラムだしてるね。
#まったくもってぱっとしないけど。
##ゴミを作って公開していた時期があるけどID
Re:うーん。 (スコア:1)
Perl でも Ruby でも Python でもなんでもいいですが、使いたいモジュールが OS 標準のパッケージシステムに含まれていないことは非常に運用上の手間が増えるため、避けたいわけです。
その基準はクライアントマシンとしての Ubuntu ならいいかもしれませんが、Ubuntu Server を Web サーバーとして利用したいなどの場合には「必要なモジュールがまとめて管理できない」ディストリビューションは大きなマイナスにしかなりませんし、個別に入れるなら Windows でも Linux でも大差がない、という事になってしまいますよ。
Re:うーん。 (スコア:1)
CPAN モジュール限定の話ですよ。
そうでないと、それこそ RedHat 系で数十なんてのもさすがにおかしいでしょう。
Re:うーん。 (スコア:1)
具体的にはglc [nullkey.ath.cx]とか、FlightGear(不安定版) [flightgear.org]とか。
実際、「ディストロのリポジトリに無いけど管理したいソフト(どれも不安定版)」は、自前のシェルスクリプトでgitとかcvsとかsvnからソース取ってきてインストールまで半自動化(スクリプトを端末から実行するだけ)してる。毎日PCに触る使う時間帯が決まってるならcron使って全自動化するけどw
#新しいtar玉orパッチを自動で取ってきて、自動でダウンロードしてパッケージ化して自前の野良リポジトリに置くなり自動でインストールしてしまうスクリプトを組んでしまえば管理しやすくなりそうだけど、それはやってない。
#自動でインストールされるのがマズいならメール通知に留めるべきかも。
Re:うーん。 (スコア:1)
標準パッケージシステムに含まれていないと管理が面倒というのは、対象が 10 台 100 台と増えても容易に管理できるかという世界の話になりますので、そういう「組み込み」はできるだけ避けたい訳です。
ただでさえ、個別マシンにわざわざログインして導入しないといけない、なんていう管理コストが上がるようなことはできるだけしたくない訳ですから。
それでいつつ「これは展開していい」「これは展開したくない」という辺りを集中的に管理できるかどうかというのは、サーバーの運用管理上非常に重要な点ではないでしょうか。
# もちろん、それなりのコストをかけてそこまで組み込んで完全管理する、というのもコストが許すならアリなんですけどね。
Re:うーん。 (スコア:1)
#もっとも、下記の方法は、ある程度機材構成とディストロが統一されてるのが前提です。アーキテクチャもディストロもバラバラだったら意味ありませんw
1:1台をパッケージ自動作成&パッケージテスト用鯖にして、パッケージ作成スクリプトを組み込んで、そのサーバに社内向けリポジトリを作成する。
2:自動作成されたパッケージを1:のサーバにだけインストールしてテストして、合格なら社内リポジトリに置く。不合格なら捨てるか手直しして再テスト。
#社内で作ったパッケージの信頼性を云々…と言い出したら、ディストロ公式パッケージも「配布者がやってるテストは信用できるのか?」って事になってキリがなくなるので、お偉いさんに言われない限りは厳密にやる必要は無い気がします。
3:他の100台は社内向けリポジトリ「も」参照するように/etc/yum.confか/etc/apt/sources.listを修正する
4:後は放置しておけば各鯖がyum-cronとかcron-aptで勝手にアップデートしてくれる
この方法だと、手間=金が掛かるのは2と3の行程で済みますよ。と言っても、テストの内容次第ではもの凄く金が掛かりますがw
#サーバでもデスクトップでも台数が多ければ似たような問題があるので「いつの間にサーバの話にしたんだ」とかツマラナイ事を言うつもりはありません。