alp曰く、"Slackware 9.0 が 3/19 にリリースされています。XFree 4.3.0, gcc-3.2.2 KDE 3.1/Gnome 2.2 等。公式アナウンスはこちら。玄人向けのディストリビューションっぽくなってしまってかなりになりますけど、昔は単純さに惹かれて使っていました。"
ヽ(´ー`)ノわーい (スコア:2, 参考になる)
http://pc.2ch.net/test/read.cgi/linux/980585420/492
// 「昔は単純さに惹かれて使っていました」なんて言わずに、今も使っておくれよん。
This cookie has a scrap of paper inside. It reads:
If you can't learn to do it well, learn to enjoy.
Re:ヽ(´ー`)ノわーい (スコア:1)
やっとversion を上げられます。# 現在slackware 7.0
実は8.0 はiso image が見付けられなかったので、
ダウンロードしていなかったのでした。
Re:ヽ(´ー`)ノわーい (スコア:1)
Re:ヽ(´ー`)ノわーい (スコア:1)
今から落としまーすヽ(´ー`)ノぃぇぃ
// もうトップから消えたのでAA解禁(笑)
This cookie has a scrap of paper inside. It reads:
If you can't learn to do it well, learn to enjoy.
ごめんなさい~ (スコア:0)
Re:ごめんなさい~ (スコア:0)
DL出来ない (スコア:0)
本家のftpは万年渋滞状態なので少し待った方が良いですね。
単純、、、だけど面倒くさい。 (スコア:0)
バージョン1.0 は脆弱だったので、バージョン1.1 にアップデート
したとします。このときに libhoge.so.1 から libhoge.so.2 に変
わって、同時にバイナリ互換でなくなったとします。
libhoge.so.1 にリンクしているバイナリを見つけるのは手動で
全部のバイナリを ldd で調べるのでしょうか?
いまみたいにライブラリがたくさんない時代では、人間の手で
全部のライブラリを把握していることも可能でしたが、昨今の
ライブラリだらけのご時世には Slackware の管理方法はちょっと
、、、ね。
Re:単純、、、だけど面倒くさい。 (スコア:1, 参考になる)
同時に upgrade すればイイし(他のパッケージツールと同じですね)、ソースから make したのなら
当然把握してますよね。
Re:単純、、、だけど面倒くさい。 (スコア:0)
バイナリ互換でなくなった時点でそのライブラリを使っているパッケージは再コンパイルしないと使えないわけですから同義でしょう。
Re:単純、、、だけど面倒くさい。 (スコア:1)
認証まわりの ライブラリを消してしまうと
ログインできなくなる可能性がありますよ。
たとえば、openssl が提供するような
/usr/lib/libcrypto.so
を消すと、 /bin/login などは 新規に起動できなくなります。
認証まわりのソフトウェアの更新を行う場合は
動作確認が取れるまで、決してログアウトせずに作業するとか
ある程度のノウハウを蓄積してからでないと面倒です。
Re:単純、、、だけど面倒くさい。 (スコア:1)
/bin/login がリンクしているのは glibc が提供する
/lib/libcrypt.so です。
Re:単純、、、だけど面倒くさい。 (スコア:1)
認証にかぎらず、dl_open(3)でしか使われてない shared object は ldd では検出できないですよね。注意が必要です。/lib/libnss_* とか。
Re:単純、、、だけど面倒くさい。 (スコア:0)
また、脆弱性がっていう部分で、外向けのサーバ用途だと推測します。
サーバ用途であれば、使っているバイナリは把握可能ではないですか?
SunOS4の時代から自分でmakeして入れて対応してきているので、それほど
不可能な管理だと思っていないのですが、どうでしょうか。
Re:単純、、、だけど面倒くさい。 (スコア:0)
デーモンだったらpsしてみてちゃんと動いてるかどうかがわかり
Re:単純、、、だけど面倒くさい。 (スコア:0)
元コメントで「slackware の管理方法は....」とおっしゃっているのは、
乱暴な言い方をするとソースからコンパイルなんて今時....って事なんでしょうが、
パッケージマネージャを使っていても、動かしてみるまでは分からないのは同じでしょう?
Re:単純、、、だけど面倒くさい。 (スコア:0)
依存ライブラリのチェックはしますよね。
ソースからビルドしていると、
どのソフトがどのライブラリに依存してるか分からんっちゅうことですな。
Re:単純、、、だけど面倒くさい。 (スコア:0)
どのライブラリに依存してるかも調べないでシステムに入れるの?
その感覚が信じられん…。
Re:単純、、、だけど面倒くさい。 (スコア:0)
っていうか、その程度のスクリプトぐらいなら書ける人をユーザ層として想定してるのではないかと...>Slackware
Re:単純、、、だけど面倒くさい。 (スコア:0)
# find /bin/ /sbin/ /lib/ /usr/bin/ /usr/sbin/ /usr/lib/ -print -exec ldd {} \; >hoge.out
で、hoge.outをlessで開いてサーチで済みますね。
# お好みに合わせて/usr/localも足すと...
Re:単純、、、だけど面倒くさい。 (スコア:0)
参考のために具体例あったらおしえてください。使うの避けるようにするんで。
Re:単純、、、だけど面倒くさい。 (スコア:2, 参考になる)
libpng-1.0 から libpng-1.2 にアップデートしたときに遭遇したことがあります。Mozilla や gtk+ が libpng-1.0 にリンクしていて、Galeon や gnome-control-center などのアプリケーションが libpng-1.2 にリンクしてビルドしていたせいで 、あちこち png 画像が表示できない、という馬鹿なことをやったことがあります。
結構前に、openssl もセキュリティホールが発見されたので交換しようとしたら、後方互換性がなくてむちゃくちゃ大変だった記憶が。
使うのを避けられればもちろんそれがベター。でもできないですよねぇ。
Re:単純、、、だけど面倒くさい。 (スコア:0)
セキュリティアップデートだったのですか?
機能アップデートだったらともかく、
脆弱性に関する対応のみで、互換性をとらなくなるような
ライブラリに出会った経験はありません、、SSLもですが。
Re:単純、、、だけど面倒くさい。 (スコア:1)
openssl の方は相当前だったので、よく覚えていませんが。openssh からなにから全部再コンパイルコースで酷く大変だった気が。
Re:単純、、、だけど面倒くさい。 (スコア:1)
それに、openssl とかだとパッケージも出ていたはずですよ。
This cookie has a scrap of paper inside. It reads:
If you can't learn to do it well, learn to enjoy.
Re:単純、、、だけど面倒くさい。 (スコア:1)
> それに、openssl とかだとパッケージも出ていたはずですよ。
うーん。Slackware を標準で使っていらっしゃる方っていらっしゃるのでしょうかー。
ssl の話題と外れますが、私は少なくともコンパイラを 2.95 のまま変えていないでちまちまと使い続けていますので、殆んどパッケージをつくり直しています。
Re:単純、、、だけど面倒くさい。 (スコア:1)
Re:単純、、、だけど面倒くさい。 (スコア:0)
対応忘れそうで怖いですねぇ。