パスワードを忘れた? アカウント作成
5300 story

Slackware 9.0 リリース 28

ストーリー by Oliver
slack-forever 部門より

alp曰く、"Slackware 9.0 が 3/19 にリリースされています。XFree 4.3.0, gcc-3.2.2 KDE 3.1/Gnome 2.2 等。公式アナウンスはこちら。玄人向けのディストリビューションっぽくなってしまってかなりになりますけど、昔は単純さに惹かれて使っていました。"

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • unofficial の ISO image もあるようです。
    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.
  • by Anonymous Coward on 2003年03月20日 19時37分 (#283208)
    まだミラーサイトには行き渡ってないみたいですね。
    本家のftpは万年渋滞状態なので少し待った方が良いですね。
  • by Anonymous Coward on 2003年03月20日 19時46分 (#283211)
    あるライブラリがあって、それに脆弱性が発見されたとします。
    バージョン1.0 は脆弱だったので、バージョン1.1 にアップデート
    したとします。このときに libhoge.so.1 から libhoge.so.2 に変
    わって、同時にバイナリ互換でなくなったとします。

    libhoge.so.1 にリンクしているバイナリを見つけるのは手動で
    全部のバイナリを ldd で調べるのでしょうか?

    いまみたいにライブラリがたくさんない時代では、人間の手で
    全部のライブラリを把握していることも可能でしたが、昨今の
    ライブラリだらけのご時世には Slackware の管理方法はちょっと
    、、、ね。
    • by Anonymous Coward on 2003年03月20日 20時19分 (#283226)
      pkgtool(slackwareの簡易パッケージツール)を使うなら、依存したライブラリも
      同時に upgrade すればイイし(他のパッケージツールと同じですね)、ソースから make したのなら
      当然把握してますよね。
      親コメント
    • 取りあえずlibhoge.so.1の実体を消してしまえば問題ないのでは?
      バイナリ互換でなくなった時点でそのライブラリを使っているパッケージは再コンパイルしないと使えないわけですから同義でしょう。
      • > 取りあえずlibhoge.so.1の実体を消してしまえば問題ないのでは?

        認証まわりの ライブラリを消してしまうと
        ログインできなくなる可能性がありますよ。

        たとえば、openssl が提供するような
        /usr/lib/libcrypto.so
        を消すと、 /bin/login などは 新規に起動できなくなります。

        認証まわりのソフトウェアの更新を行う場合は
        動作確認が取れるまで、決してログアウトせずに作業するとか
        ある程度のノウハウを蓄積してからでないと面倒です。
        親コメント
      • 消すっていうのは簡単でいいですよね。

        また、脆弱性がっていう部分で、外向けのサーバ用途だと推測します。
        サーバ用途であれば、使っているバイナリは把握可能ではないですか?

        SunOS4の時代から自分でmakeして入れて対応してきているので、それほど
        不可能な管理だと思っていないのですが、どうでしょうか。
      • 「脆弱性を突かれる心配がなくなる」という意味では同義ですが、「動かしてみないと動くかどうかわからん」というのはちょっと問題あるかも。
        デーモンだったらpsしてみてちゃんと動いてるかどうかがわかり
        • それは slackware に限った話ではないと思うんですが。
          元コメントで「slackware の管理方法は....」とおっしゃっているのは、
          乱暴な言い方をするとソースからコンパイルなんて今時....って事なんでしょうが、
          パッケージマネージャを使っていても、動かしてみるまでは分からないのは同じでしょう?
          • パッケージ管理してあると、完全かはともかく
            依存ライブラリのチェックはしますよね。

            ソースからビルドしていると、
            どのソフトがどのライブラリに依存してるか分からんっちゅうことですな。
            • > どのソフトがどのライブラリに依存してるか分からんっちゅうことですな。
              どのライブラリに依存してるかも調べないでシステムに入れるの?
              その感覚が信じられん…。
    • その程度ならスクリプトをちょいちょいと書けば済むのでは?
      っていうか、その程度のスクリプトぐらいなら書ける人をユーザ層として想定してるのではないかと...>Slackware
      • スクリプトまで書かなくても

        # find /bin/ /sbin/ /lib/ /usr/bin/ /usr/sbin/ /usr/lib/ -print -exec ldd {} \; >hoge.out

        で、hoge.outをlessで開いてサーチで済みますね。

        # お好みに合わせて/usr/localも足すと...

    • …そんな頭の悪いバージョンアップするようなライブラリあるの?
      参考のために具体例あったらおしえてください。使うの避けるようにするんで。
      • by shunak (3585) on 2003年03月20日 20時05分 (#283221)
        libpng や openssl かな?

        libpng-1.0 から libpng-1.2 にアップデートしたときに遭遇したことがあります。Mozilla や gtk+ が libpng-1.0 にリンクしていて、Galeon や gnome-control-center などのアプリケーションが libpng-1.2 にリンクしてビルドしていたせいで 、あちこち png 画像が表示できない、という馬鹿なことをやったことがあります。

        結構前に、openssl もセキュリティホールが発見されたので交換しようとしたら、後方互換性がなくてむちゃくちゃ大変だった記憶が。

        使うのを避けられればもちろんそれがベター。でもできないですよねぇ。
        親コメント
typodupeerror

あつくて寝られない時はhackしろ! 386BSD(98)はそうやってつくられましたよ? -- あるハッカー

読み込み中...