GentooのPortageをOpenBSDとFreeBSD に 68
ストーリー by Oliver
好きなものでミックスジュース 部門より
好きなものでミックスジュース 部門より
ababincho曰く、"OpenBSD Journal の記事により。Gentoo Linux の Portageを、OpenBSD と FreeBSD に移植する試みがはじまっています。/ で tarball を展開してインストールするようです。/etc/make.conf が競合するのではないかと思うのですが、どうなんでしょう?"
ちょうど本家では (スコア:1, 参考になる)
合わせて読みませう。
Re:ちょうど本家では (スコア:2, 参考になる)
>Portupgradeの話題が
今さら、何でPortupgradeが話題になるのかと思ったら、
Portupgradeの使い方に関するコラム [onlamp.com]が2003/08/28に発表された、ということだったのか。
portupgradeのインストールの仕方(CVSupの使い方を含む)から始まって、定番のアップデート方法、便利な周辺コマンドの紹介、と盛りだくさん。
Re:ちょうど本家では (スコア:0)
だいぶ欲しい。
まあ、妄想なんだが (スコア:1, 参考になる)
いつのまにか portage と Makefileの比較になってる人を
たまに見かけるんだな。
Makefileと比較すんなら.ebuildファイル。
このことは、逆に言えば、
「ディストリビューションのパッケージ管理」とは別に
「パッケージの記述法(automake/autoconfな世界のお約束)」
にも、そろそろ大幅な改良が起こりうるかもな、
てな妄想に繋がって、興味深いというか怖いというか。
そういう大変化には、若輩ゆえ出会ってないんですが、
どんなもんなんでしょ。
#意味なくAC
Re: まあ、妄想なんだが (スコア:2, 参考になる)
Re:まあ、妄想なんだが (スコア:0)
限界があるんですよね。
各ソフトがモジュラリティについて考慮してくれないと、
依存関係が大きくなりすぎることがある。
こういうのは、ビルドシステムも含めた全体のコンポーネント化の
仕組みがないと解決が困難なのは事実でしょうね。
Re:まあ、妄想なんだが (スコア:3, 参考になる)
いや, それ以前に「パッケージ」と言う呼び方で一くくりにするには, カーネルモジュールやライブラリみたいなプリミティブな物からinstant-workstationみたいな環境セットと言ったほうがよさそうな物まで, あまりにも階層が違う物が有るわけで. 他にもパッケージ間の衝突なんて問題もあるので, 一筋縄ではいかないと思います.
思うに, パッケージ管理についてもOS的な階層化と各階層毎のインターフェイスの定型化, それにVM的な環境の分離といったことが必要になるのではないでしょうか? FreeBSDなら標準でjailが使えるので, こういったパッケージ管理の構造化を試してみるのも面白いかもしれませんね.
Re:まあ、妄想なんだが (スコア:0)
結局のところ、それが「コンポーネント化」(の一部分)なんですね。
> それにVM的な環境の分離といったことが必要になるのではないでしょうか?
> FreeBSDなら標準でjailが使えるので, こういったパッケージ管理の
> 構造化を試してみるのも面白いかもしれませんね.
VM というか、インターフェースの世代の問題で、一つのコンポーネントの
世代の異なる複数の版を同一システム内
Re:まあ、妄想なんだが (スコア:1)
>結局のところ、それが「コンポーネント化」(の一部分)なんですね。
ここらへんは、インターフェース「される(?)」対象物を
はっきり一種類(ただし抽象的だが)の「オブジェクト」なるものに
絞ってしまったオブジェクト指向に、一日の長が有るように思います。
卑近なところでいえばJavaかな。Javaの*.class(とそれの集まりである*.jar)ファイルとか。
C言語(アセンブラ?)ベースのリンクシステムより格段に扱いが楽になってる。
あれが扱い易いのは、まず最初に扱「われる」ものの性質をきっちり(使いやすい形に)決めてしまったから、だよね。
#Javaの「1クラス=1ファイル」という思い切りは、なかなか慧眼だと思う。
#1クラス=1ファイルということは、複数のファイルを実行時より前に結合することを敢えて諦めるという意味でもある。
#クラスファイルどうしが「くっつく」ことが無いから、常に単体の単位で扱えるので、問題が複雑化しにくい。
#また、クラスという論理単位とファイルという物理単位を常に一致させると、管理がし易い。
で、オブジェクト指向のオブジェクトやクラスと比べると、
Unix(やその他のありがちなOS)でいうところのプログラムやライブラリの切り分け単位は、
ちとばっかり曖昧模糊としていて、扱いにくいです。
だから、それの束ね方の問題であるところのパッケージも、なかなかすっきりしない…
#MakeよりAntのほうが良いと言われても、XMLだとどうもピンと来なくて困ってるG7
#たしかにMakeそのものはかなりヤラシイが。
>> それにVM的な環境の分離といったことが必要になるのではないでしょうか?
>VM というか、インターフェースの世代の問題で、一つのコンポーネントの
>世代の異なる複数の版を同一システム内に同居させなければならない、
コンポーネントって、
実行時の仮想マシン(プロセス含む)同士の関連のさせかたの問題として捉える文脈も見かけるし、
一方でコンパイル&結合時のライブラリ同士の関連のさせかたの問題として捉える文脈も見かけます。
どっちが正統&正当なのかは俺はよく判りません。どっちもありなのかな…
># それをやろうとしたのが ActiveX ではある。
Unixより後の世代のOSは、きっとどれも(期待と誇張を含むが)、
そういう方向性を打ち出してるような気がする。
ただし、失敗することも有るけどね。
例えば、なまじ綺麗に部品化できるもんだから、悪辣なプログラムを綺麗に部品化して配布してしまってたり、
悪辣な部品を配布されてしまったり(=ウイルス?ワーム?)ということも出来るようになってしまう。
こういう仕組みをOS(特にNetworkつき)に導入する場合は、以前以上にセキュリティとかには気をつけた基本設計が要求されるようです。
#自作のScript言語の中ならばアクセス制御が欲しいとは思わないが、この仕組みがそのままOSになっても良いとは、ちょっと思えない…
おいらは (スコア:0)
Re:BSD・・・ (スコア:1, すばらしい洞察)
http://www.jp.netbsd.org/ja/Documentation/software/packages.html#bootstrap
OpenPackagesは?
さて、パッケージ管理システムを記述する言語に
makeを選んだ事自体がミスだったような記事を読んだ
ことがあります。
makeを捨てちゃうなら改良どころか最初からの作り直しに
なるわけで、それだったら既に枠組みが出来ている所と
相乗りするのは決して悪くない選択肢だと思いますがね。
Re:BSD・・・ (スコア:2, 参考になる)
Re:BSD・・・ (スコア:0)
pkgsrcはFreeBSDのportsをNetBSDに持ってきたものですが。
他OSに対応ったって、基本的な枠組みは同じですよ。
Re:BSD・・・ (スコア:0)
>makeを選んだ事自体がミスだったような記事を読んだ
>ことがあります。
それを言い出すとですね、そもそも Makefile というものが
根本的にわかり難いという話に帰着してしまう気はします。
pkg に関しては、どうも中途半端に make を使ってる気
Re:BSD・・・ (スコア:1, 参考になる)
Re:BSD・・・ (スコア:1)
Re:BSD・・・ (スコア:1, おもしろおかしい)
もちろん、ports/sysutils/portage を作ってから、各portsのMakefileにUSE_PORTAGE= YESを...(ぉぃ)
Re:BSD・・・ (スコア:0)
妙なプライドや意地で判断を誤るよりは
よっぽどマシだよねー
Re:BSD・・・ (スコア:0)
モデレーションの合計: 過小評価 = 1, 合計 = 1.
過小評価って + モデレートなのか?
Re:BSD・・・ (スコア:0)
Re:BSD・・・ (スコア:0)
「他人のモデレーションは『過小評価』だよ」という意味じゃなかったっけ?
Re:BSD・・・ (スコア:0)
Re:BSD・・・ (スコア:1)
「評価を上げる」「評価を下げる」
ってなかんじにわかりやすくすればいいのに。
It's not who is right, it's who is left.
Re:BSD・・・ (スコア:0)
その理屈だと過大評価はマイナスになるだろう?
それにモデレーションに対してはメタモデレーションがあるわけだから、それはやっぱり違うと思うぞ。
Re:BSD・・・ (スコア:0)
#389295 さんのでいいんじゃない。
Re:BSD・・・ (スコア:0)
いまちょうどモデレーション権限をもってますが、
「過大評価」という項目はないみたいですよ。
> それにモデレーションに対してはメタモデレーションがあるわけだから、
Re:BSD・・・ (スコア:0)
メタモデで“公平でない”が集まればプラスもマイナスもキャンセルされるやん。
Re:BSD・・・ (スコア:0)
Re:BSD・・・ (スコア:0)
したがってバザールから輸入すると。
Re:BSD・・・ (スコア:2, 興味深い)
例によってFreeBSDのコアチームなどの役割を誤解してるか、
ESRのあたりの言うことを鵜呑みにしてるんだろうなあ。
FreeBSDは数人のコアチームが何でも決めていると思ってる
人が多いけど、間違いです。
技術的判断は下さないしリリースエンジニアリングもしないし
寄付の受付や資金運営もしません。フレームの仲裁や各チームの
調整を助けたりというのがメイン。
ごく初期はコアチームがいろんな力を持っていたけど、それは
まだ人数が少なくてコアチームにいる人たちが実際に開発や運営の
中心にいたから。創始者とか、メインアーキテクトとかね。
OpenBSDの事情は誰かフォローして。
Re:BSD・・・ (スコア:2, 興味深い)
Re:BSD・・・ (スコア:1)
興味のないものに対する世間の認識なんてその程度ってことです。
それを変えるには辻説法でもするしかありませんが、
そういうのは自分の仕事じゃないというのがこっちの
世界の雰囲気なので、世間はやっぱりそのままなのです。
いいじゃん、困らないし。
なんとかするのはしたい人の仕事。
Re:BSD・・・ (スコア:1)
Re:BSD・・・ (スコア:2, 興味深い)
たしかに往年のSteve Priceとは違った意味でロボっぽいです。
mahoさんは十分よくやっていると思いますよ。
少なくともPORTREVISIONの意味がわからなかったりとか
「お前は俺より新米なんだから口を出すな」とか言ってきたりは
しませんし。(一部笑うところ)
Re:BSD・・・ (スコア:1, 参考になる)
二元論的なモデルだというのを忘れてはいけません。
完全な伽藍モデルで動いているプロジェクトも、
完全なバザールモデルで動いているプロジェクトも
存在しないと思います。
「『完全な伽藍』でないもの全て = バザール」という捕らえ方は
精密ではないでしょう。もっとも、最初からこのアナロジーでは
精密な議論ができない、というのが正しいとは思いますけど。
ESR がバザールの典型として挙げている Linux にしたって、
伽藍的要素はあると思います。
結局はそのあたりの折衷具合をどう捉えるかの違いじゃないですかね。
FreeBSD の場合で言えば、誰でも開発に参加できるとはいえ、
きわめて基本的な部分に関しては、数名のハッカー(not core)が自らの
判断と権限と責任だけで実装してるところがいくつかあります。
そういう部分は、伽藍的といえますね。
逆に言えば、伽藍的要素があったからこそ、newconfig vs (略
一方で、ports はきわめてバザール的要素が強いでしょう。
一口に FreeBSD と言っても、そういう意味で均質じゃないんですね。
> OpenBSDの事情は誰かフォローして。
Theo というアクの強いアーキテクトが大きな発言権を
持ってるということを除けば、ほかの BSD とも大差ないでしょう。
# NetBSD は要らない?じゃあフォローしません(ぉ
Re:BSD・・・ (スコア:0)
企業ベースだと、このレベルの大幅な変更って、どこまで可能なのでしょう。僕は良い例を知りません。
Re:BSD・・・ (スコア:1)
# Multiplan を捨てて Excel を採用したとか……
-- 哀れな日本人専用(sorry Japanese only) --
Re:BSD・・・ (スコア:1)
Windows9x→WindowsNT
Adobe Premiere (スコア:0)
まあ、今までのPremiereを作ってた開発陣は Apple に移籍しちゃってますから、しかたなく作り直したという噂も…
Re:BSD・・・きわめつけMacOS X (スコア:0)
しかもすべて成功させています。
1.Motolora68XXX->PowerPC
2.MacOS->MacOS X
3.ADB->USB&IEEE1394
4.CEO交代!
5.etc
#そのおかげでBSD使いに成れたのでAC
Re:BSD・・・きわめつけMacOS X (スコア:1)
失敗してる歴史もありますけど :)
Re:BSD・・・きわめつけMacOS X (スコア:1)
OpenDoc
Copland
Knowledge NavigatorのAgent(これはMicrosoftにWizardとして取り入れられている気がする)
他にも沢山の屍技術があるから「すべて」というのはちょっと褒めすぎ。
Masafumi Otsune [otsune.com]
Re:BSD・・・ (スコア:0)
> したがってバザールから輸入すると。
そんな大それた話かなぁ。話を表面的に捉えすぎなんじゃないかな。
ビルドシステム/配布システムと開発パラダイムは無関係だと思うよ。
ports/pkgsrc に限って言えば、その運用という点ではバザールに近いし。
OS のコア部分に関しては、ビルドシステムはともかく、
いまの tgz ベースの配布システムに問題があるという認識が
一部にはあるのも事実で、これから脱却しようという試みには
NetBSD の sysp
Re:BSD・・・ (スコア:0)
Re:BSD・・・ (スコア:0)
技術的にはframeworkの移植ができるのはわかりきってるけど、今の9000を越えたports treeをどうやってそこへ持っていくかが問題なんじゃないのかなぁ。
Re:BSD・・・ (スコア:0)
BSDに入れるとか・・・・
# もうすぐ rsync対象もそろそろ60000かぁ・・・
Re:Windows・・・ (スコア:0)
>恵んでもらうって・・・
>情けない・・・
ってマイクロソフトのこと?
#煽ってないって!提灯も持ってないって!
#怒らないで!ぶたないで!
Re:Windows・・・ (スコア:0)
Re:ネタですが、 (スコア:1)
debianは386用のバイナリを用意していますが、PentiumなりのCPU向きの最適化はあまりされていないのでは。ここらへんはGentooはやりたい放題です
自分がemergeでインストールしたパッケージの一覧。個人的にうれしいのはシステムにインストールされたパッケージの一覧(手持ちのsidで837個入っている)ではないということ。覚えておけるからね。
それは大事ではないかもしれませんが、視認性は高いです。
Re:ネタですが、 (スコア:1)
まーおいらは当分はaptでいいかな。
---------------------------------
KQ