GNU/HURD

1 ：名無しさん＠お腹いっぱい。 ：2000/10/24(火) 00:14

・・・・。で、
GNU/HURD って、どんな状況なのさ？？

2 ：U-名無しさん ：2000/10/24(火) 00:16

ノートとかに乗っける人とかいませんか？
近頃刺激が欲しくて。

3 ：名無しさん＠お腹いっぱい。 ：2000/10/24(火) 00:20

ttp://www.jp.debian.org/ports/hurd
ttp://www.ne.jp/asahi/home/ki/HurdWorld/debian_gnu_hurd_faq/debian-gnu-hurd-faq.html

よって
┏┳┓┳　 ┳┏━┓　┏━┓┳┓┳ ┳┓
　 ┃　 ┃　 ┃┃ 　　　 ┃ 　 　┃┃┃ ┃┗┓
　 ┃　 ┣━┫┣┫　　 ┣┫　 ┃┃┃ ┃ 　┃
　 ┃　 ┃　 ┃┃ 　　　 ┃ 　 　┃┗┫ ┃┏┛
　 ┻　 ┻　 ┻┗━┛　┗━┛┻　 ┻ ┻┛

4 ：名無しさん＠お腹いっぱい。 ：2000/10/24(火) 00:29

そういえば、手持ちの UNIX_USER誌の 1998年9月号 に、
GnuHurd0.2(i386)の CD-ROM と、巻頭でインストール/環境設定記事、Ｘの設定記事
まで載ってるわ。忘れてた。

今度の連休にでも入れてみるか。。。

5 ：名無しさん＠お腹いっぱい。 ：2000/10/24(火) 01:10

　　 ∧＿∧　　／￣￣￣￣￣
　　（　´∀｀）＜　ttp://www.jp.debian.org/distrib/ftplistモナー
　　（　　　　） 　＼＿＿＿＿＿
　　｜ ｜　|
　　（_＿）＿）


　　∧ ∧　　　／￣￣￣￣￣￣￣￣￣￣￣￣￣
　　(,,ﾟДﾟ)　＜　ttp://www.jp.debian.org/docも読んどくとイイらしいよ
　 ./　　|　　　 ＼＿＿＿＿＿＿＿＿＿＿＿＿＿
　（＿__ﾉ
／

6 ：名無しさん＠お腹いっぱい。 ：2000/10/24(火) 01:11

>>3
なんでこれで「終了」な？ ドキュメントが更新されてないからってことか？
Hurd については www.gnu.org から辿れる Hurd のオフィシャルページに、

「もしも Linux が(普及)存在していのたら、Hurd を作りはじめましたか？」

というかなりイタイ質問に RMS が答えているよ…。

7 ：名無しさん ：2000/10/24(火) 01:35

はーい　質問。
Machマイクロカーネルってのは linuxのカーネルとは別物？
んでもって、GNUはカーネル依存じゃないよってことなんでしょーか？

8 ：名無しさん＠お腹いっぱい。 ：2000/10/24(火) 02:53

>>8 PC8001時代のゲームを思い出すな

9 ：名無しさん＠お腹いっぱい。 ：2000/10/24(火) 03:13

7>
Linuxはマイクロじゃないっす。

10 ：名無しさん＠お腹いっぱい。 ：2000/10/24(火) 04:57

Debian GNU/Hurd の CD image ができたらしい。
はじめに Linux ブートしてからインストールするようだ。
Debian Weekly News 参照。

11 ：名無しさん＠お腹いっぱい。 ：2000/10/24(火) 11:07

>>10
ttp://www.debian.org/News/weekly/2000/34/index.html
↑のことね。翻訳ソフトで一部ほにゃくしてみました
＃「地獄からのインストール」ってのが、コワイなぁ・・・

Debian GNU/Hurd CDイメージはDebianブーツフロッピーディスクに作成されたTheyが基づくことだった;
linuxがHurdをインストールするのに使用されて; そして; “; 理論上, Hurdをじゃがいもインストール
を受け入れるどんなシステム上にもインストールすることができる; Hurdがこれらのすべてのシステムを
走るかどうかが, 別の問題である; " これは前方でHurdのためのユーザビリティで大きいステップに似ている;
libcの問題は最近に引き続いて再浮上された.アップグレード不安定なのは, libcである.
libcが高度化した後に, 多くのデーモンが「不-互換性」のためにNSSモジュールで再開されなければならない.
そのようなデーモンのリストはlibc6のpostinstにハード・ワイヤードであるが, ベン・コリンズは, その
ようなリストがいつも不完全で, 時代遅れになると指摘した. いくつかの解決策が提案された.
何かが, マーカーを再開される(それらのイニットスクリプト, またはある他のファイルの中で)必要が
あるパッケージに追加することを伴う. 他のものは, 静的にそれらをリンクするか, またはプレロード
するのにNSSモジュールを使用するプログラムを変更することを伴う. この最終は最も上品な解決策のように
見えるが, 我々はそれが本当に働くかどうかを確信していない.

ジョーであるときに, Debianレビューが難問だったが数週間前に発行されて, バールはLinuxWorldで
Debian 2.1を見直した. そうだ, 1年以上前によくリリースされたDebian 2.1. それは楽しいレビュー
でなかった; 忘れ難い引用文は「地獄からのインストール」を含む,そして,「この分配は無料のソフトウェア
のためのポスター子供であるべきである」; 「FBI最重要手配人ポスターの上にそれはあるべきである」.
Thereは大きく, Debianメーリングリストにおける全体のかなり当惑している反応に関するそうである.
だれかがなぜ厳しくDebianの古いバージョンを見直していたか?

12 ：名無しさん＠お腹いっぱい。 ：2000/10/24(火) 18:35

>>11
熱にうかされた子供のうわ言みたいだ（笑

13 ：名無しさん＠お腹いっぱい。 ：2000/10/24(火) 21:54

じゃがいもインストール...

14 ：名無しさん＠お腹いっぱい。 ：2000/10/24(火) 22:14

じゃがいもの前は、ハム。

15 ：名無しさん＠お腹いっぱい。 ：2000/10/24(火) 23:16

>>6

「もし、Linux がプロジェクト開始当時にあったならば、そして、別の
　カーネルを開発するかどうか検討していた時期ならば、我々はフリー・
　ソフトウェアが無い、ほかのプロジェクトを開始していただろう。
　しかし、昔に戻ってＨｕｒｄをスタートさせていた。そして、今日動くよ
　うに作り上げた。我々は、これが優れたアーキテクチャとして、
　よりパワフルなフリーＯＳとして作られていく事を希望している。」

ってやつ？

16 ：名無しさん＠お腹いっぱい。 ：2000/10/25(水) 01:11

>>15
そーです。

その後だか途中にに

「我々は作りかけたものを途中で投げ出すような真似はしない」

という意地といおうか悲愴なメッセージがあったと思うけれど、
こいつを抜かしちゃいけませんぜ、ダンナ。

17 ：名無しさん＠お腹いっぱい。 ：2000/10/25(水) 03:08

>14
potato(2.2)の前はslink(2.1)
hammは2.0

18 ：名無しさん＠お腹いっぱい。 ：2000/10/25(水) 06:17

>>7
マイクロカーネルって言うのは、カーネルがカーネルとして
必要としている必要最小限の機能を提供するカーネルだね。
んでもって、その他の部分は、カーネルの外に追い出してしまう。
Hurd は、マイクロカーネルが持っていなくて、UNIX のカーネルが
持っている機能をカーネルの外（非特権空間）で動くデーモン群
として実装してる。そんなふうに中身はぜんぜん違うんだけど、
ユーザーからは UNIX と同じように見えるんだね。
まさに Unix Replacing Daemons って感じだね。

そういえば、mount コマンドの中身はシェルスクリプト
だったような・・・。

19 ：名無しさん＠お腹いっぱい。 ：2000/10/25(水) 08:26

18に補足
デーモンよりサーバというな。で、Machはそうしたマイクロカーネルの
仕組みを提供するもの。Machの上にBSDサーバを走らせれば、UNIX BSD
になるし（Mac OS Xとか）、Linuxサーバ走らせればMkLinuxになるわけだな。

各サーバ間はメッセージをやりとりするのだが、その昔はこれが結構な
オーバーヘッドになったため、マイクロカーネルは実用的でないという
説が強かった。Linuxがモノリシックな理由の一つはこれだな。
今は、そんなことはないそうなのだが、俺はその辺の論文を追っかけて
いるわけでもないので、本当のところは知らない。

20 ：18 ：2000/10/25(水) 09:08

>>19
>デーモンよりサーバというな。
そうね。HURD の D にちなんでデーモンと呼んでみました。

>結構なオーバーヘッドになったため
>...
>今は、そんなことはないそうなのだが

L4 っていう MK はめちゃめちゃ速いという話があった。
これに Hurd を移植できれば・・・という話も。

>俺はその辺の論文を追っかけているわけでもないので、
>本当のところは知らない。

おなじく。

21 ：名無しさん＠お腹いっぱい。 ：2000/10/25(水) 23:44

結局、頓挫してるのかなぁ？？

22 ：名無しさん ：2000/10/26(木) 01:11

今のLINUXは、マイクロカーネルじゃないわけね、、？
んでもって、
最低限に、コアの機能をしぼったものをマイクロカーネルっていうわけ？

この、マイクロカーネル思想の発端は、移植性の向上ですか？？

疑問符ばっか、、

23 ：名無しさん＠お腹いっぱい。 ：2000/10/26(木) 02:06

>>22

>今のLINUXは、マイクロカーネルじゃないわけね、、？

そうです。ただし、マイクロカーネルの上に乗る Linux サーバー
というものも存在します。

>最低限に、コアの機能をしぼったものをマイクロカーネルっていうわけ？

そうです。

>この、マイクロカーネル思想の発端は、移植性の向上ですか？？

たぶんそうだと思います。でも、ほかにも、特権モードで動く部分
が小さいので安定性が増すということもあると思います。
メモリ保護が働くからです。

24 ：名無しさん＠お腹いっぱい。 ：2000/10/26(木) 22:27

>22
まずはですねえ、従来のカーネル（モノリシックカーネル）は
デバイスドライバとかメモリ管理とかファイル管理とかプロセ
ス管理とかのシステムコールでぐちゃぐちゃじゃんという批判が
でたわけ。
でもって解決策として提示されたのがマイクロカーネル。これは、
必要最低限の機能を持つカーネルをおいて、その他の機能は全部
ユーザプロセスとしてしまえ。でもって、各サービス間の連携は
マイクロカーネルを媒介にメッセージをやりとりして解決しよう
というもの。しかし、こいつは（少なくとも当時は）遅かった。
メッセージのやりとり（IPC:プロセス間通信）がオーバーヘッド
になってしまったから。

デバイスドライバとかもユーザプロセスとして動作するから、
それが転けてもカーネルに問題はないわけ（少なくとも理屈
の上では）。現在の Linuxとか*BSDはデバイス周りが原因で
すぐにフリーズするけど、マイクロカーネルならそれはない
（少なくとも理屈の上では）。
たとえば、俺のLinux箱はUSBいじるとすぐに固まるのだけど、
これがマイクロカーネル化されていて、USBのデバイスドライバが
USBサーバとして動作していればそんなことはないわけ（少なくと
も理屈の上では）。

さっきから理屈理屈としつこいのは、マイクロカーネルの
（はずの）Windows NT はデバイス周りですぐ転けるから。
いわゆる Blue Screen of Death（青画面）だね。

25 ：名無しさん＠お腹いっぱい。 ：2000/10/26(木) 22:46

さらに、マイクロカーネルの最大の利点は、提唱当時は
誰も気づいていなかっただろうけど、マルチプロセッサに
強いこと。
このマルチプロセッサってのは SMP（対称型マルチプロセッ
サ） じゃなくて、非対称のやつね。いわゆるASMPか。
確かに、今のLinuxだってSMPでマルチプロセッサには対応
してるんだけど、これはそれほど多くのプロセッサには
使えない。
専用のアーキテクチャで動くASMPとSMPの違いは、SMPが
各プロセッサが同等のものなのに対し、ASMPはプロセッサ
毎に役目があること。カーネル実行するプロセッサ、
ユーザプロセス実行するプロセッサみたいにね。これに
よってプロセッサを効率よく使うことができる。特に、
512プロセッサとかの大規模な並列システムではね。

今後のPCは周波数の限界を迎えて、マルチプロセッサ
になっていくだろうから、このことは大きな意味を持つはず。

26 ：名無しさん＠お腹いっぱい。 ：2000/10/26(木) 22:49

たぶんX年後には、Linuxはマルチプロセッサに弱くて
ダサイ。僕の（マイクロカーネルの）OSなら上手に使え
るよ。
といって、新しいOSが華々しくデビューするのでしょうね。
ちょうどLinuxがデビューしたときのように。

27 ：名無しさん＠お腹いっぱい。 ：2000/10/26(木) 23:18

NTは(主にパフォーマンス上の理由で)kernel modeにいろんな物詰め込んで
るから、本来のマイクロカーネルとは別物だね。
# それはMS自身NT4リソースキットの中で認めてる

ただ、各モジュール間の結合が(モノリシックよりは)密ではないので、NT4
でGDIをkernel modeに大移動〜なんてやってもそこらじゅう修正して回る
必要はなかった、と(リソースキットで)自慢しとったね。
本当かどうかは知らんけど。

read.cgi ver5.26+ (01/10/21-)