Slackwareの魅力の秘密 30
ストーリー by Oliver
configure;make;make-install 部門より
configure;make;make-install 部門より
nekoie 曰く,"linuxにディストリビューションは色々有るものの、SlackwareやPlamoに根強い人気が有るのは何故か。その事に対する優れた考察がここにあります。思いっきし要約すると、『(コンピュータに任せずに)自分で管理するのが良い』というコトですね。(自分の経験的には、インストール日誌をつけるコトを強く推奨。)コレは、slackwareで無くても、パッケージ管理に頼らず、野良バイナリを繁殖させるタイプの人にも当てはまるかも。"
DebianのaptやFreeBSDのportsで完全極楽パッケージ任せな生活を送るか、RPM系でディストリビューション間のRPMの互換性の無さ相手にがんばるか、それとも全部自分で支配するか。さあ、どうする?
Linux from Scratch (スコア:4, 興味深い)
なかなか面白かったです。
Slackwareが好まれる理由って (スコア:2, すばらしい洞察)
#パッケージつかってるdistでmakeしたら却って手間だしね。
Re:客先にLinuxのシステムを納品する時は (スコア:2)
商用ソフトとなると、VMWareのLinux版もそうだけど、RPMとかtar.gz(で圧縮されたバイナリ)が入ってるのが普通ですね。
Shade for LinuxはRPMだけだったっけな
DebianでもRPMはalienで一応インストールはできるが。動作の保証はちょっと...みたい。
Re:Slackwareが好まれる理由って (スコア:2)
potato だと2年くらいこなさそうダシ。
パッケージは楽と言えば楽だが… (スコア:2, 参考になる)
linuxが世に注目されたときのうたい文句として「少ないリソースで動作するので古いPCの再生に最適」と言われていたのに、古いPCでは積みきれないほどの容量を要求されることがしばしばで、なんだかなぁという感じ。
これは一つのパッケージをインストールすると過剰なまでに依存関係を解決しようとするのが原因かも。
ソースからコンパイルするメリットは、コンパイルオプションが指定できることと、不要な機能をdisable,withoutしてスリムにできることだと思う。そうすれば不要なライブラリをインストールする手間も省けるし。
それに、一度パッケージを使い始めたら最後までパッケージを使わなくちゃいけないのも面倒。せっかく新しいバージョンが出てもパッケージが出るまで待たなきゃいけないのは新しいもの好きにはつらい。
最初はvineを使っていました。良いディストリビューションだとは思いますが、上記の理由で現在はplamoです。
…glibcも入れ替えてしまい原型を留めてはいないけど。(笑)
Slack使おうかなとも思っていたり。 (スコア:1)
今はDebianを主に使っています。で、まあ普通に使えて、普通に便利なんですが、パッケージが多いのは、逆に言えばいらないものも多いってことにもなります。仕事場はRedHatなんですけど、バイナリが汚い(というか設定がヘンなとき)、ソースをmakeしてます。だったらSlackのほうが自分に向いてる可能性があるかもとちょっと考えたりするんですけどね。
Debianはサーバ用途だとけっこう楽ですけど、なんか閉じこめられている感じは否定できないです。でも、使い勝手は悪くないし、めんどくさがりやな自分には割とあってる気もします。Slackは忠実な人向きかな?
パッケージシステムの動作をきちんと把握したうえで (スコア:1)
Slackware -> RedHat -> Debian と流れ着いてもう何年も他の distribution は使ってない。
一台しかマシンが無ければね (スコア:1)
俺が RPM 使ってるのはパッケージ作るのが楽だから。 Slack の .tgz 作るより楽だよ。ホント。
そもそも Slack を自力で管理出来る力があるなら、 どのディストリビューションを使っても困らないよ。
パッケージングシステムが嫌いだなんて言う奴は configure;make;make install しか憶えられなかったのさ。
中途半端はイヤかも (スコア:1)
そんなわけでFreeBSD or Plamoを選ぶことが多い。
# SlackじゃないのはRING鯖に置いてないから。
Re:パッケージシステムの動作をきちんと把握したうえ (スコア:1)
これを励行していれば、自宅の10台のマシンも
わりとへっちゃらさ。
仕事もいっしょさ。面倒だと思っても、手順を
踏んでいれば、ずっと楽になる。
Re:Linux from Scratch (スコア:1)
英語読めないけど。(^^;;
# 近いところで serioware ってディストリビューション使ったけど玉砕。
# rpm > dpkg と渡ってきたけど、やっぱり source から構築というのは
# 魅力的。私にとっては slack は最終的にたどり着くべき場所だね。
---------- yuzo ----------
RPMの互換性 (スコア:1)
rpm --rebuild
で自前で再構築すればたいがいうまく動きますね。 この時に、同じ世代のディストリビューションを使うのが成功率を上げるポイントかも。
Re:パッケージシステムの動作をきちんと把握したうえ (スコア:1)
パッケージ管理システムに頼る限りは全部自分で支配してるとは言えないというのなら configure も make も使わずにやれってんだ。
configure も make も定型処理を簡単に間違いなく行うためのツールだろう。似たようなもんだ。
ところで、元ネタの要約は「自分で管理したい人もいる」で「自分で管理するのが良い」なんて言ってねーと思うが。
要約失敗。 (スコア:1)
確かに、要約失敗してるです(主語が抜けてた‥‥)。正確に要約すると、
「slackwareを使う魅力は、『自分で管理する』という感覚が好きだから」
になるのかな(まだ何か違う気もするけど)。
makeの場合はMakefileをいじれば、かなり自分の好きに出来るし、最後の手段としてソース自体をいじる事も出来るけど、バイナリパッケージとして固められちゃってると、その辺が出来ないのがイヤンなので。
まぁ、自分でバイナリパッケージを作っちゃうのは、明らかに、「自分で管理してる」部類に入ってるしね(実際問題、沢山のマシンにインストールする時は、コレやらない訳には行かないし(とか、この時点で「自分でパッケージを作る」という選択をしてる時点でアレなのか?))。
客先にLinuxのシステムを納品する時は (スコア:1)
Cube
Re:一台しかマシンが無ければね (スコア:1)
RPMって作るのは楽かもしれませんけど, 管理するのがしんどくありませんか? あれってパッケージ間の依存関係の管理はやりませんよね. ですから他の人の作成したパッケージを利用するのが難しくなると思うのですが.
その点では*BSDのports/pkgやDebianのapt-getは更新が前提での管理は楽だと思います.
ちなみにportsでの基本はmake installだけです.
FreeBSD ユーザなのですが... (スコア:1)
(*) 私の思うWindows的問題 ... 細かい設定をなるべく自動化or簡単に設定できるようなソフトを入れてあるため、一見便利に見える。しかし、そのツールのためにいろんなものが隠蔽されていたり、そのソフトへのOS(userland) の依存度があまりに大きすぎるため、そのソフトに想定外のことが起きた途端に、通常よりも余計な手間がかかるor物事が完全に破綻してしまうこと。
Vine-2.1.5が必要になって入れてみたら、Xなんて入れるつもりもないのにxf86config.pyだかがエラー吐いてインストーラが落ちまくって、非常に悲しかったです。
どっちが楽なんだろ? (スコア:1)
Debianでapt-get sourceしたのを、Plamoに持って行ってmake。
細い回線で、OSやディストリビューションやらアーキテクチャの違うもののために、いくつもパッケージを落とすのはつらいし。
でもMakefileいじる方がしんどかったりもする…。
Re:客先にLinuxのシステムを納品する時は (スコア:1)
間を取ってSPM (スコア:1)
Re:RPMの互換性 (スコア:1)
なければSRPMをとってきてrebuild or 調整てなことをしてますが、
最近は各ディストリビューションで独自にマクロを定義してる事も多くて、
単純にrebuildできない事も少なくないですね。
元々のマクロの内容が分からないと
結局は一からSPEC書くほうが楽だったりします。
調べればいい事なんだけど、気持ち悪いから
%configureとか%makeinstallとか嫌い。
-- Che Che - Bye Bye
Re:Slackware使っててよかったことは (スコア:1)
同じようなことはFreeBSDにも当てはまりますね。
/etc/rc.d/というディレクトリもrc.sysinitもないので直されようがない。
Re:Slackware使っててよかったことは (スコア:1)
同じようなことはFreeBSDにも当てはまりますね。
/etc/rc.d/というディレクトリもrc.sysinitもないので直されようがない。
FreeBSDにも/etc/rc.dあるんですが...
Re:一台しかマシンが無ければね (スコア:1)
パッケージングシステムが嫌いだなんて言う奴は configure;make;make install しか憶えられなかったのさ。
刺のある発言ですねえ。そんなことは、ないと思いますが。
でも、同じ理由で私もSlackwareはもう、ほとんど使ってないです。台数増えると、やってらんないですね、確かに。
4台管理してるんですけど。 (スコア:1)
バージョン 4.0 から 7.1 までバラバラでして、ちょっと前までは 3.4 も現役でした。(さすがに今ではマシン性能が低くて、パッチ当ててコンパイルに時間がかかるので引退させましたが)
管理ですけど、一度自分なりの環境作っちゃうと、あとは継続的なセキュリティパッチだけなんで、4台くらいならそんなに大変じゃなかったりします。
もっとも、3.4 の頃には入って無かった apache, xntp, samba なんかのソフトは、今でも 3.4 当時独自に入れたのと同じディレクトリに自分でソースからコンパイルして(-fstack-protectorできるし)入れていたりするので、もはや Slackware ではなくなっているのかもしれません。
ところで、元ネタですけれど、私が Slackware を使い続ける理由、ってのをまさに説明してくれています。
私的には、
「ソースはフリーでも心がクローズド」
なのは嫌なのです。
パッケージ管理ツールにすら管理されない自由さが、Slackware の魅力ですね。
kaokun
FreeBSD の /etc/rc.d (スコア:1)
tag を見る限り、これって current だけみたいですよ。
Re:Slackwareが好まれる理由って (スコア:1)
> パッケージなんぞ待っていられない、というのもある。
最新版とか開発版使いたい時こそパッケージ使う気が。
もし最新版がダメダメでも後戻りするのが簡単ですから。
何でもかんでもパッケージ化してインストールするように
なってしまった今日このごろ。
最初は野良ビルドするより手間かかりますが、
後々楽ですからねぇ。
Slackware使っててよかったことは (スコア:0)
/etc/rc.d/の下のrc.sysinitとか直されてもなんともなぁーい。
ついでだが、いくつかの系統の違うDistributionを同一サイトで混ぜて使うと、もっと効果的です。管理するほうは、全部知ってなきゃいけないが。
packageも (スコア:0)
Re:客先にLinuxのシステムを納品する時は (スコア:0)