dragonfly bsd どうよ

1 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/06/29 22:31] dragonfly bsd どうよ なんか面白そうだが。 113 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/08/11 21:10] 推測できると思いますが、目標ポートのmp_SendMsg()関数はメッセージを どう扱うかを完全に制御します。メッセージフラグによって渡されたヒントが どのようなものであっても、目標ポートはメッセージに対して(呼び元から 見て)同期的にふるまって応答することも、メッセージをキューに入れてEASYNCを 返すこともできます。一般的にメッセージ処理は発信者から見て「ブロック」 すべきではありません。つまり、メッセージを同期的に処理することがブロック につながるのであれば目標ポートは同期的に処理してはいけないということです。 そのかわりに、自身のスレッドのキュー(目標ポートの構造体に、便利なように 埋め込んであるメッセージキュー)に入れて、EASYNCを返すようにします。 114 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/08/11 21:48] : (このパラグラフは特に変更しなくていいよね) ここで覚えておくべき重要なことは、もっともよい最適化とはmp_SendMsg()に よる直接の実行で、単純なサブルーチン呼出しの他には実質的にオーバヘッドを 伴わないことです(訳注: no more〜thenはDillonのいつもの釣りね)。 キュー処理もせず、応答ポートをいじることもなく、ということです。もし メッセージを同期的に扱ってよいのであれば、これは非常にコストの低い 処理ということになります。この特徴があるからこそ、性能の問題を気にせずに メッセージングインタフェースを意図して使うことができるのです。私達は たとえばMachで用いているような種類の洗練手法を使うことはあえてしません。 少なくとも低レベルなメッセージインタフェイスでは、メモリマップやポインタの 追跡といったことをしません。ユーザ⇔カーネル間のメッセージインタフェイスは 単純にmp_SendMsg()の関数ベクタを用い、それによって適切な変換をします。 そうすることで、送信側と受信側に関しては、メッセージがそれらの VMコンテキストに対しローカルになります(局所性を持つということ)。 115 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/08/11 22:28] 軽量カーネルスレッドモデル DragonFlyはその中核部分に軽量カーネルスレッド(LWKT)を用います。 システムのプロセスは全てスレッドと結びついていて、カーネルのみの プロセスのほとんどは事実上純粋なスレッドです。たとえば、pageout デーモンは純粋なスレッドでプロセスコンテクストを持ちません。 LWKTモデルはアーキテクチャによらないいくつかの鍵となる特徴があります。 これらの特徴はCPU間の競合を除く、あるいは減らすために設計されています。 1.システムの各CPUは自己完結のLWKTスケジューラを持ちます。スレッドは意図的に CPUに結びついていて、いくつかの特殊な状況下でのみ他のCPUへ移動することが できます。特定のCPU上のLWKTスケジューリング処理はそのCPU上でのみ直接 実行されます。これは、LWKTスケジューラ本体がスケジュール追加、除去、 CPU内でのスレッド間スイッチを、ロックを一切せずに処理できるということです。 単純なクリティカルセクションの除いてはMPロックもなにもなしにです。 2. スレッドはカーネルで動作中は他のCPUにプリエンプティブに移動されることは ありません。スレッドはブロックされている間はCPU間を移動しません。 ユーザランドスケジューラはユーザモードで実行しているスレッドを移動できます。 スレッドは非割り込みスレッドへプリエンプティブにスイッチすることは ありません(この間FreeBSD初心者スレで出た話題のやつね)。割り込みスレッドが カレントスレッドをプリエンプトする場合、割り込みスレッドが終了または ブロックした時点でプリエンプトされた方のスレッドはスケジュール状態によらず 復元されます。たとえば、あるスレッドはlwkt_deschedule_self()を呼んだあと、 実際に(別のスレッドへ)スイッチする前にプリエンプトされる可能性があります。 これは問題ありません。なぜなら割り込みスレッドが完了またはブロックしたあと そのスレッドに直接制御が戻るからです。 116 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/08/11 22:51] 3. 上の(2)により、スレッドはCPUごとのglobaldata構造体を通じて得た 情報をロックなしにキャッシュすることができます。また、その情報が 割り込みスレッドによって変更されないと分かっている場合は、 クリティカルセクションに入る必要がありません。これによって、 いろいろな種類のデータのCPUごとのキャッシュ(訳注: 「の」の連続だ) を、事実上オーバヘッドなしに持つことができます。 4. あるCPUが他のCPUに属するスレッドをスケジュールしようとする場合は、 ターゲットCPUにIPIベースのメッセージを発行して、処理を実行します。 このメッセージはデフォルトで非同期で、このためIPIはレイテンシを 伴うことがありますが必ずしもCPUサイクルを浪費するとは限りません。 このIPIの処理はクリティカルセクションに入ったスレッドによってブロック されます。実際、LWKTスケジューラはそうします。クリティカルセクションの 出入りは安価な処理と考えられるので、ロックやバスロック命令を必要と しません。 5. IPIメッセージサブシステムはFIFOあふれによるデッドロックに対し、 送信キューの停滞が解消するのを待つ間、受信キューをスピンして処理する ことで対処します。IPIメッセージサブシステムはこのような状況下で 特にスレッドのスイッチを行いません。これによって、まれにスピンが 発生する場合があってもソフトウェアはこれをノンブロッキングAPIのように 扱うことができます。 117 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/08/11 22:59] これらの鍵となる特徴に加え、LWKTモデルでは高速割込みプリエンプション とスレッド割込みプリエンプションを両立します。高速割り込みはカレント スレッドがクリティカルセクションに入っていない場合はプリエンプトできます。 スレッド割込みもカレントスレッドをプリエンプトできます。LWKTシステムは、 スレッド割込みにスイッチしたあとそれがブロックまたは完了した場合に もとのスレッドに戻ります。IPI関数は高速割り込みと非常に似たやり方で 動作し、同じくtrapframe機能を持ちます。これはDragonFlyのSYSTIMERS APIで hardclock()やstatclock()の割込みを全てのCPUに分配するために多く用いられて います。 118 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/08/11 23:15] IPIメッセージサブシステム LWKTモデルはCPU間通信のための非同期メッセージシステムを実装します。 基本的には、関数ポインタとデータ引数を引数として関数を呼び出すと ターゲットCPUにそれを渡り、ターゲットCPUはそれを非同期に実行します。 これは非同期モデルなので呼び側は同期完了を待ちません。このため性能が 非常に向上し、ターゲットCPUへのオーバヘッドもおおまかには割り込み と同等程度です。 IPIメッセージは高速割り込みのように動作します...つまり(クリティカル セクションに左右されますが)ターゲットCPUで動いているものは何でも プリエンプトし、実行し、そのあともともと動いていたものに復帰します。 このためIPI関数はいかなる理由であってもブロックすることは許されません。 IPIメッセージはスレッドをスケジュールしたり他のCPUに属しているメモリを 解放するといった処理をするのに用いられます。 IPIメッセージ処理は少なくとも6個の主なLWKTサブシステムで多用されています。 それらには、CPUごとのスレッドスケジューラ、slab allocator、メッセージ サブシステムが含まれています。IPIメッセージ処理はDragonFlyに本来的に 適応したサブシステムなので、Big Giant Lockを必要とせず、使用してもいません。 全てのIPIベースの関数は従ってMPセーフである必要があります(そうなっています)。 119 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/08/12 09:25] これって、ひとつの資源に対して単一のCPU&スレッドを張り付けることで、排他制御をシンプルにする というおおざっぱな理解であってる? スレッド切替が頻繁に発生してパフォーマンスで劣るんじゃないかとか、 スレッドの優先度制御をどうするかとか、いろいろ問題もありそうだけど、 おらワクワクしてきたぞ。 120 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/08/12 12:25] IPIベースのCPU同期サブシステム LWKTモデルは、汎用でマシンに依存しないCPU同期APIが備わっています。 このAPIによって、デリケートなデータ構造にアクセスしている状態の ターゲットCPUを既知の状態に移行させることができます。このインタフェイスは 主にMMUのページテーブルを更新するのに使用されています。たとえば、 もし適切なロックを確保していたとしても、ページテーブルエントリの モディファイビットをテスト、クリアしたあとにページテーブルエントリを 削除するのは安全ではありません。これは、他のCPUで動作しているユーザランド プロセスがそのページを読み書きする可能性があるからで、その場合向こう側のCPUが TLBを書き戻すのとページテーブルエントリをクリアしようとする処理の間に レース状態が生じます。適切な解決は、ページテーブルエントリへ書き戻す 可能性のあるCPU(つまりpmapのpm_activeマスクでセットされている全CPU)を まず既知の状態に移行し、変更処理をしてから、各CPUのTLBを無効化するリクエストに よってCPUを解放するという方法です。 DragonFlyに備わっているAPIにはデッドロックがありません。複数のCPU同期処理が 並行に動作することが可能で、これはCPU同期イベントの主導権を握っているスレッド にもあてはまります。これは柔軟なしくみですが、CPU同期インタフェイスは制御 された環境で動作するため、コールバック関数はIPIメッセージサブシステムで 用いられるものとちょうど同じように動作する傾向にあります。 121 名前：名無しさん＠お腹いっぱい。 mailto:sage えっちねた板の連貼りみたいだ [04/08/12 14:21] 同期トークン 同期トークンはいくつものスレッドが同時につかめます。トークンをつかんでいる スレッドは、同一のトークンをつかんでいる他のスレッドが同時には実行しない ことが保証されます。 一つのスレッドは同期トークンをいくつでもつかむことができます。 あるスレッドは、イールドまたはブロック条件を通じて同期トークンを つかむことがありますが、そのスレッドが(ブロックあるいはイールドされて) 実行中でない間、それらのトークンをつかんでいる他のスレッドが実行する 可能性があることを考慮に入れる必要があります。 理論上、同期トークンの機構から起きるデッドロック状態で解決できないものは ありません。しかし、初期の実装ではトークンを同時につかんだ場合にライブロック の問題が起きる可能性があります。 同期トークンは、同一のトークンをつかもうとする割り込みが他のスレッドを プリエンプトしてしまうことから保護するのにも使われます。これはBig Giant Lock (BGL; MPロックともいう)とは若干違った作用があります。BGLは同一CPUの割り込みを インターロックすることはありません。重要なことは、プリエンプションによって 一時的に他のスレッドへのスイッチが起きることがあるとしても、トークンの原子性 (?atomicity)プリエンプティブ条件によって維持されるということです。トークンの 原子性(?atomicity)を維持するためにspl()レベルやクリティカルセクションに入る 必要はありません。 同期トークンはプリエンプティブは割り込みが起きるのをさまたげることはありません が、割込みをブロックして再スケジュールさせることがあります。スレッド化されて いない高速割り込みやIPIメッセージング割り込みはトークンをつかうことが できません。それは処理に必要なスレッドコンテキストを持っていないからです。 そのかわり、これらのサブシステムはクリティカルセクションを使うことで 排他制御をします。 122 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/08/12 19:40] DragonFly - ユーザAPI 移植性のあるユーザAPIを作る 多くの標準的なUNIXシステムでは、生の構造体データを含む多種のデータを、 システムコールテーブルを通じてやりとりします。ユーザプログラムがそれ 自身より古いあるいは新しいカーネルとやりとりする上で最大の障害は、 これらの生の構造体データはよく構造が変わるということです。最も厄介なのは ネットワークインタフェイス、ルーティングテーブルのioctl、ipfw、 ps,vmstatが直接アクセスするプロセス構造体などです。しかし、stat()や readdir()のようなどうということのないシステムコールでさえ問題があります。 もっと一般的な言い方をすれば、システムコールはそれ自体が移植性の問題を 生むことがあるということです。 このプロジェクトの目標として以下のものがあります。 (1) 実質全てのシステムコールをメッセージベースにする、 (2) 構造体の情報を、直接ではなく機能や要素のリストを通じて渡すようにする、 (3) 汎用の「中間層」を実装する。 (3)はある種のエミュレーション層のように見えるもので、管理はカーネルが行うが ユーザ空間にロードされます。この層は全ての標準的なシステムコールAPIを実装し、 それらを適切なメッセージに変換します。 例えば、Linuxエミュレーションはカーネルランドでなく(カーネルに保護された) ユーザランドで動作します。FreeBSDのエミュレーションも同じように動作します。 実際「ネイティブ」なプログラムもシステムコールという私達がよくなじんだものを 見るためにエミュレーション層を通ります。ただ違うのは、ネイティブな プログラムはエミュレーション層が存在し、ユーザランドから直接アクセスできる のを知っているので、ただカーネルに入ってすぐにエミュレーション層に戻る ためだけに余分なINT0x80(でも何でも)を無駄にしない、ということです。 123 名前：名無しさん＠お腹いっぱい。 mailto:sage 誰かチェックしてね [04/08/12 19:42] [User API続き] システムコールをメッセージベースの構成要素に変更することによるもう一つの 大きな利点は、ユーザランドスレッドの問題を完全に解決できるということです。 もう複数のユーザランドスレッドを処理するのに複数のカーネルコンテクストや スタックは必要なくなり、プロセスあたり一つのカーネルコンテキストとスタック があればよいのです。ユーザランドスレッドはシステムの各CPUごとに実プロセスを 生成するのにrfork()を使い続けますが、他全ての処理はスレッドに対応した エミュレーション層を使えます。実際、ほとんど全てのユーザランドのupcall (コールバック)はカーネルから直接発行されるのではなくユーザランドの エミュレーション層から発行します。以下はスレッド対応エミュレーション層 が動作する例です: [コード] たったこれだけです。DragonFlyが実装する「本当の」システムコールは 送信、受信、待機に必要な原始的なメッセージ通信機能のみです。 他はエミュレーション層を通過します。もちろん、カーネルの側では メッセージコマンドはFreeBSD 4.xにあるのと同じ規模のディスパッチ テーブルにたどりつきます。でもサブシステムがメッセージベースになっていく につれて、syscallメッセージはよりいっそうこれらのサブシステムに 統合されてゆくので、「メッセージ」を処理するためのオーバヘッドは 最終的には独立したシステムコールを処理するオーバヘッドよりも小さくなる でしょう。「エミュレーション層」はユーザランドプログラムが期待するものと カーネルが期待するものを分離するブラックボックスの役割をするので、 移植性を確保することははるかに簡単になります。エミュレーション層は カーネルといっしょに更新する(または後方互換性のあるバージョンを作る) ことができるため、ユーザランドのバイナリからは移植性の問題は見えなく なります。 加えて、メッセージパシングモデルが提供する利点を全て受けられます。 それはデバッグや他の目的のためにシステムコールに割込んだり、 たとえばセキュリティ環境のもとづいて特定クラスのシステムコールを 無効にしたり変更したりするといったセキュリティ層をカーネル内に 構築するというものです。 124 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/08/12 23:15] wids.net/balk/dragonfly-jt-status.html 125 名前：名無しさん＠お腹いっぱい。 mailto:sage あんまり自信はないけど [04/08/16 01:00] 新しいVFSモデル (3rd par.) i.e. → すなわち、つまり (4th par.) A messaging interface is preferable for many reasons, not the least of which being that it makes stacking actually work the way it should work, as independant and opaque elements which stack together to form a whole. For example, with the new API a capability layer could be slapped onto a filesystem that otherwise doesn't implement one of its own, and the enduser would not know the difference. Filesytems are almost universally self-contained entities. A message-based API would allow these entities to run in userspace for debugging or even in a deployment when one absolutely cannot afford a crash. Why run msdosfs or cd9660 in the kernel and risk a crash when it would operate just as well in userland? メッセージングインタフェイスは多くの理由から好ましいものです。特に 独立的で不透明な要素が積み重なって全体を形成するという、スタッキングが 本来すべき動作を実現するという点によるところが少なくありません。たとえば 新しいAPIでは、ファイルシステムが実装していない機能に対して機能層をあてがう ことができ、エンドユーザにはその違いが分かりません。ファイルシステムは 大部分が自己完結型(注: 相互依存する別の要素を持たないという意味ね)の要素です。 メッセージベースのAPIではこれらの要素をデバッグのためにユーザランドで動作 させることを可能にしますし、また絶対にクラッシュしてはいけないような場合 にも威力を発揮します。msdosfsやcd9660がユーザランドでも同じように動作する ならわざわざカーネルの中で動かしてクラッシュする危険にさらす必要はない でしょう? ... 126 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/08/16 01:38] その割にはMachって流行んないよな(ぼそっ 127 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/08/16 02:22] >>125 翻訳乙！ opaque って定訳あるのかな。「（実装が）隠蔽された」とか？ 128 名前：125 mailto:sage [04/08/16 07:21] >>127 うん。 GPLのライセンス表記の中には「A copy that is not "Transparent" is called "Opaque".」という説明があるので透明でないということで 「不透明」と訳したけど。実際「opaque object」を不透明オブジェクトと 訳す例もあるみたいだけど、一語でいおうとするとしっくりこないよね。 129 名前：名無しさん＠中学生英語 mailto:sage [04/08/16 20:18] >>125 > (3rd par.) > i.e. → すなわち、つまり うげ。 wids.net/balk/dragonflybsd.vfsmodel.j2.txt 130 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/08/17 04:53] >>125 > (4th par.) 文のつながりが一部いまひとつのように思うので、改善案。 あとユーザランドはユーザ空間の間違いだと思う。 メッセージングインタフェースは多くの点で優れています。 それは、スタッキングのあるべき姿である、独立なカプセル化された要素が積み 重なって全体を形成するということを実現したことによるところが少なくありません。 例えば、新しいAPIではファイルシステムに実装されていなかった機能の機能層をかぶ せることができ、しかもエンドユーザには元から実装されていたときとの違いが わかりません。 また、ファイルシステムはどれもほとんど例外なく自己完結したひとまとまりの オブジェクトになっています。メッセージベースのAPIではこれらのオブジェ クトをユーザ空間で動かすことができ、デバッグにも使えれば、クラッシュが 絶対許されない条件下の運用にも威力を発揮します。 msdosfsやcd9660がユーザ空間でも同じように動作するならわざわざカーネルの 中で動かしてクラッシュする危険にさらす必要はないでしょう? 131 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/08/17 14:03] >>126 Mach以外のMK系OSもkernelの外に出したはずのものをどんどんkernelに取りこんで 行ってるしね。NTが代表例だけど、MachベースなはずのOS Xもそう。 132 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/08/20 11:05] Minix を思い出したのは気のせい？ 133 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/08/21 01:42] じゃあまたforkするのかしら。 134 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/08/22 11:04] 長期運用中の方、FreeBSD5.2.1より安定してますか？ 135 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/08/22 12:34] 使ってる人いないの？ 136 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/08/22 12:41] 使い続けてる人は少ないと思われ 試しに入れてみる人は多いだろうが 137 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/08/22 18:14] 俺は手頃なマシンがなかったから、 VMwareにいれてmake worldをずっとしてるだけ。 138 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/08/22 23:58] >>134 「安定」の定義にもよるが、たぶん安定はしていない。panicやフリーズなし に動くかどうかはハードウェアによる。たとえばDragonFlyの日本語訳を まとめようとしている はるかタン(たぶん男だよね)のマシンは時計が2倍速らしいし。 現状DragonFly-CURRENTは1-RELEASEよりはマシな状態だけど、いくらfork元が FreeBSD 4.8-RELEASEでも結局 -CURRENTなのであっちが直ればこっちが壊れる というようなことは覚悟の上でないと使えない。(でも-CURRENT trackerはそれが 楽しみで使ってるんだよね?) 俺のまわりで一番長く稼働しているのはDellのpen4デスクトップマシンで、 そいつはCVS repoの取得とXサーバを動かしているぐらい。ここ半年ぐらいは panicやフリーズはなく、カーネル入れ替え時以外は無停止で運用中。いまの uptimeはほぼ一ヶ月。マシン自体は2年前にFreeBSD 5-CURRENTで運用開始して 以来ほとんど電源つけっぱなしで動かしているんで、けっこう丈夫みたい。 139 名前：名無しさん＠1.1-CURRENT mailto:sage [04/08/23 05:59] >>134 FreeBSD-CURRENT よりは安定してます。 :) クライアントで使ってると X 上げたらフリーズとか、Gtk ものをあげたらフリーズ とか、しょっちゅうそんな感じです。サーバとしては使ったことないから、サーバ としてどうかはわからんです。 # crater.dragonflybsd.org はちょっと前から DragonFly になってるらしい。 ま、 CURRENT ですから、安定を求めるのもどうかと。 140 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/08/23 19:43] >>139 ビデオカードと使っているドライバは? 141 名前：名無しさん＠1.1-CURRENT mailto:sage [04/08/23 20:30] >>140 MGA G400 で、 XFree86 4.3 ですが。 142 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/08/25 22:50] >>115-121 wids.net/www.dragonflybsd.org/ja/goals/threads.cgi 143 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/08/25 22:59] >>142 神！ 144 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/08/27 15:23] >>138 はるかタン オサーンだったのか orz 145 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/09/08 14:57] >>121 atomicity であってたみたいです。"原子性"のままでいいでしょうか ? www.dragonflybsd.org/cvsweb/site/data/goals/threads.cgi.diff?r1=1.10&r2=1.11&f=u >>144 ｵｻｰﾝじゃないわいっ 146 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/09/08 16:01] >>145 「不可分性」ぐらいかな？ 要するに「ある動作が一つの要素として完結し、その動作の間に関係する 状態が変わることが無い事」ぐらいの意味だから。 例えば、rename(2)の動作は一見「目的のファイルをopenし、 元のファイルもopenし、元のファイルからreadし、目的のファイルにwriteし、 目的のファイルをcloseし、元のファイルをunlinkする」ことによって 達成できるけど、これはatomicな動作ではないため競合状態が起きたり するということね。 147 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/09/08 21:07] atomic は atomic でいいよ。 ヘタに訳すとわけわからん。 148 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/09/08 22:52] >>147 そう、いろいろ考えたけどしっくりくる訳語がない。でもアルファベット が散りばめられた翻訳もそれはそれで読みづらい(人によるかな)し、かと いって「アトミシティ」と書くのもどうかなと思う。 「…性」という造語で訳すなら>>146がいっているように「不可分性」かな。 元の文章をきれいさっぱり忘れるとして、日本語でできるだけ簡単な言葉を 使ってどう説明できるか、なんだよね。 149 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/09/08 23:31] googleしたら、原子性という言葉を結構使ってるね。 でもこれだったらatomicってしてくれたほうがなんぼかまし。 150 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/09/09 12:54] アトミック性とかはどうよ。 151 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/09/09 13:25] 英字で atomicity のままが一番わかりやすいよ。 atomicity と書いてわからない人には どう書いてもわからないと思う。 せいぜい訳注をつけるくらいか。 152 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/09/14 01:05:23] とりあえず5-CURRENTだったメル鯖を置き換えてから10日が過ぎました。 153 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/09/14 06:38:42] >>152 うを、漢だ… 154 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/09/14 16:29:37] 1.0 リリースということなんで興味はあるものの、 OSのコードが読めないどころか、atomic の意味も知らないようなへたれは まだ来ない方が良い雰囲気ですのう。 155 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/09/15 19:29:29] >>154 Document まとめてる某氏も C が読めないと言ってたような気が 156 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/09/16 22:39:38] >>154 "DragonFly_Stable" tag が打たれてからなら、ちょっと安心かも。 いつ打たれるのかはわからんけど。 157 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/09/17 00:49:18] >>154-156 いまは本当に-CURRENTなので、最低でもFreeBSD-CURRENTを自分の メインマシンに入れて、うまいことババ引かずに運用する技術 and/or 運を持っていることが必要。アプリケーションまわりだと ports/dfportsの代替ができないと一般ユーザにはつらいかな。 ところでnullfsは不安定だという声をたまに聞くけど、それって 4.x系でもそうなんだっけ。5-CURRENTの時にひどいめにあったけど 4.xではどんなにハードに使っても刺さったことなかったけど。 このあいだのVFS 04/99が入って以降、nullfsは刺さるようになったよ。 158 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/09/17 01:18:43] 以前の4-stableでは使い方によってはおかしくなったりしたけど、 最近は問題ないよ。 159 名前：名無しさん＠お腹いっぱい。 [04/09/23 02:06:35] とりあえずクロック爆走問題は「options TIMER_USE_1」で直ったよ、 とbugs@で みやもっさんが感動のご様子。 160 名前：159 mailto:sage [04/09/23 02:07:32] bugs@じゃなくてkernel@だった 161 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/09/23 03:14:44] >>152 激藁 162 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/09/23 11:24:44] >>152のメル鯖は今どうなってるんだろう? 163 名前：152 mailto:sage [04/09/23 13:44:56] >>162 IPFW2をコンパイルしていなかったのでコンパイルしなおしてから こんなもんです(15 usersはメーラを上げっぱなしにしているから)。 $ uptime 1:42PM up 8 days, 11:05, 15 users, load averages: 0.02, 0.03, 0.00 まあsubversionやqmailのMLを抜けてからは流量が減ったので 非常に蝦そうですね。 164 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/09/23 17:42:36] 蝦そうって何だw 165 名前：名無しさん＠お腹いっぱい。 mailto:sage 海老 [04/09/23 23:43:42] それはttyドライバの(ry 166 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/09/24 00:29:52] >>152には申し訳ないがもっと負荷をかけていじめてもらい Dragonflyがどれほどのものか見てみたい。 167 名前：163 mailto:sage [04/09/24 08:34:40] >>166 DragonFlyの限界より先に冷却の限界が来てしまうのだけど。 168 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/09/24 22:32:40] 負荷かけっぱなしだとで冷却しきれないマシンって不良品じゃないのか？ 169 名前：167 mailto:sage [04/09/25 00:49:30] >>168 ヒートシンク頼みなんで夏場はcx_stateとcpu_throttle_stateを 最低に絞ってるんです。だからいじめないでね。 170 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/09/26 00:59:01] >>167 結局鯖をDragonFlyに変えてなんか違いを感じるの? 171 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/09/26 13:35:07] とんぼのめがねはみずいろめがね あおいおそらをとんだから とんだから 172 名前：169 mailto:sage [04/09/26 13:49:05] >>170 使用感は5.xの時とそんなに違わない。 173 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/09/26 22:15:52] もしDragonFlyにGUIインストーラがついてきたらBSDユーザーの割合に 変化は生じるだろうか? 174 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/09/26 23:14:07] 誤差 175 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/09/26 23:18:08] YesかNoかでいったらYesだろう 176 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/09/27 01:41:12] anaconflyｷﾎﾞﾝﾇ 177 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/09/27 14:22:23] >>173 その場合の「インストーラ」というのは、実はインストール時だけじゃなく 設定ツールとしても動作しなくてはいけないんだよね。 インストール時だけでいいならinstaller teamが作っているCGI installer にちょっと化粧をすれば見栄えはよくなるんじゃないかなと思う。 178 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/09/27 15:36:46] >>176 シャレで作ってみた。 wids.net/balk/20040927-dragonfly-anaconda.png 179 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/09/27 19:59:16] >>177 anacondaって設定ツールとしても使えるの? 設定ツールはインストーラーと別でもまとまり取れてれば なんとかなる気がするよ。 180 名前：176 mailto:sage [04/09/27 21:43:13] >177 まさか出てくるとは..全角でＧＪ！ 181 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/09/30 20:51:07] !>>178 シャレとわかっていながらちょっと期待しちゃったよ 182 名前：名無しさん＠お腹いっぱい。 [04/09/30 20:58:27] Onipotefly BSD 183 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/10/02 12:05:01] ApjBSD 184 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/10/02 16:17:08] EbiFlyBSD for nagoya 185 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/10/14 00:54:18] 本家のdiaryだがもうちょっと頻繁に更新されないものだろうか? 186 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/10/14 01:27:23] dillon が書いている限り、無理だろうね 187 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/10/14 19:56:36] そこで はるかタン登場ですよ。 188 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/10/14 22:34:03] >>187 あの質を維持するには hrs さんくらいの人じゃないと無理 189 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/10/15 19:06:13] 忙しさでDillonぶっ倒れそーな気がするよ 190 名前：名無しさん＠お腹いっぱい。 mailto:sage>はるかタソ [04/10/21 00:05:48] stripped /kernel ってのは --strip-debugのほうの話で、--strip-all しなければfileコマンドの結果は'not stripped'になるんだよもん。 191 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/10/21 00:21:36] >>190 おぉ、さんきゅーです。 192 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/10/21 20:57:41] 空いてたPCにDragonFlyBSDを入れてみたがさしあたっての 目的がないことに気付いたよ orz 193 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/10/21 21:31:21] >>192 じゃとりあえず # echo 'CCVER?=gcc34' >> /etc/make.conf してから、普段自分が使っている環境を整えてみてください。 portsのコンパイルが失敗したらMLなり(英語がだめならニポーン人 ぽい関係者にメール出すなり)粘着されるのがいやならこのスレでもいいので 報告くらはい。 194 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/10/24 04:25:25] ttp://wids.net/haruka/ で日記のRSSとか配信してない？ bloglinesで更新チェックできると皆幸せになりそげ。 195 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/10/25 07:29:02] >>193 ニポーン人ぽい関係者てほとんどこのスレも見ているような(w 196 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/10/25 19:42:47] >>194 でもそのページはblogではないんでは 197 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/10/25 20:06:57] こういうことなら得意みたいだから、頼み込めばｶﾞﾝｶﾞってくれるのがﾊﾙｶたん。 198 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/10/25 20:07:16] >>194 してないんですが、DragonFly の情報に関しては分離というか何と言うか、 そんな予定があるんで少し待って下さい。 199 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/10/26 02:58:47] Cannaをコンパイルしたところwchar_tの定義でエラーがでますた。 Canna/include/widedef.hの65から70行目までをコメントアウトしたら とりあえずコンパイルはできました 200 名前：200 mailto:sage [04/10/26 12:31:09] >>199 それはCCVER=gcc2でもCCVER=gcc34でも同じですか? 201 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/10/26 12:57:53] /etc/make.confにCCVER?=gcc34いれたときです。 CCVER=gcc2だと　include/machine/ansi.hが見つからないて感じのエラーがでました 202 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/10/26 20:24:48] Cannaの報告した199です。コンパイルは問題なかったけどkterm上でshift+spaceで変換する時 四角の中の"あ"の文字が記号になって日本語の入力ができませんでした。 gcc34でコンパイルしたFreeWnnだと問題なく日本語の表示、入力ができました。 203 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/11/01 23:03:15] よねたにさんが修正入れたみたい。 > canna 204 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/11/02 23:46:19] DragonFlyBSDってSMPはどうなるの? FreeBSDは5系列から色々手入れてるみたいだけど? 205 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/11/03 00:38:05] まさにSMPというかNUMAアーキテクチャーで効率的になるためにforkしたようなもんだが。 206 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/11/03 03:48:17] >>204 >>110-125 207 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/11/03 21:13:56] >205 じゃあDragonFlyBSDの真髄はSMPなマシンじゃないと味わえないのね orz 208 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/11/04 00:47:47] なんでまだ200程度までしかないスレだというのに、ログすら読まないバカが 湧いて出ているんだろう? 209 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/11/04 01:09:11] >>194 wids.net/dbsdlog.jp/ wids.net/dbsdlog.jp/index.rdf >>197 私にできるのはこれくらいですからねぇ。 210 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/11/04 03:20:33] >>209 うぇーん、サイドバーが本文にかぶって読めないよー 211 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/11/04 19:45:40] >>210 微修正しました。これでどうでしょう。 212 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/11/06 00:22:21] >>208 2chはPC以外からも利用できます。 213 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/11/06 08:45:10] >>212 それがどうしたの?

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef