メインコンテンツへスキップ

Appleの心臓部「Darwin OSとXNUカーネル」を徹底解剖!他OSへの影響や開発秘話も暴露

·4 分
2025/04 Darwin OS XNUカーネル MacOS カーネル オペレーティングシステム

Appleの心臓部「Darwin OSとXNUカーネル」を徹底解剖!他OSへの影響や開発秘話も暴露

引用元:https://news.ycombinator.com/item?id=43597778

llincerd 2025-04-06T17:21:10

Darwinってマジでおもろいよね。コアコンポーネントの変更ペースがヤバい。syscallの後方互換性を捨てたり、強制コード署名とか、dyld_shared_cacheでシステムライブラリのファイル読み込みを高速化したり。完全に結果重視のデザインで、昔ながらのやり方に固執しない感じ。Appleみたいな大手がやるからこそできるんやろな。

conradev 2025-04-06T22:37:05

マジそれな。userspace driversとかexclaves[1]とか、進化が止まらんね。セキュリティがkernelを進化させる大きな要因ってのは間違いないっしょ。

bch 2025-04-06T01:27:15

>Machの仮想メモリ(VM)システムはプロジェクト以外にも影響を与え、4.4BSDや後のFreeBSDでメモリ管理サブシステムとして採用された”
…とNetBSD[0]、OpenBSD[1]もね。DragonFly BSD[2]は違うみたいやけど。

inkyoto 2025-04-06T01:53:47

残念ながら、それは完全には正しくないんだよね。
386BSD、FreeBSD、NetBSDの3つ(最初はOpenBSDはなかった)は、Mach 2.5スタイルの設計を受け継いだんだけど、FreeBSDはすぐにMach VMの残骸を全部捨てて、完全に新しくて高性能なVMに書き換えたんだ[0]。FreeBSD 4にはMachのコードは残ってなくて、それは90年代後半のこと。だからFreeBSDはMachとの関係で語れないんだよね。最初の頃はそうだったってだけで。
NetBSDとOpenBSDもしばらくはMachを使ってたんだけど、すぐに限界が来て(パフォーマンスとかSMPとかネットワークとか)、UVM(unified virtual memory)で書き換えることにしたんだ。UVMはChuck Cranorが設計して、彼の論文のテーマにもなったんだよ。OpenBSDは後でUVMを借りて採用して、今でも使ってる。
だから、今のBSDでMachを使ってるのはXNU/Darwinだけなんだよね。しかもMach 2.5じゃなくてMach 3。Machには2.5、3、4があって(GNU/HurdはMach 4を使ってる)、互換性は低いから、別々の設計として扱うのが良いと思うよ。

bch 2025-04-06T02:30:26

>I am not sure whether DragonBSD is dead or alive today at all.”
マジか[0][1]。元気にしてるといいな。技術的に面白いし、独自の道を歩んでるのが魅力的[2][3][4][5]。

inkyoto 2025-04-06T03:24:41

最後のリリースが「Version 6.4.0 released 2022 12 30」で、2007年と2012年のリンクは、2025年の今、プロジェクトがまだ生きていることを保証するには弱い気がするな。他の似たようなプロジェクトと比べるとね。
HAMMER(前の設計)とHAMMER2(2018年からの現在の設計)は、全く違うファイルシステムのデザインだってことも注意。前の設計をここで言及する意味があるのか疑問。

bch 2025-04-06T05:23:14

>The last release being «Version 6.4.0 released 2022 12 30», links from 2007 and 2012 do not lend much assurance that the project is still alive in 2025 – compared to other similar projects.”
だよねー。git repoには昨日のコミットもあるけど、NetBSDほどじゃないし。
>Also note that HAMMER (the previous design) and HAMMER2 (the current design, since 2018) are two distinct, incompatible file system designs. I am not sure what is the value of mentioning the previous and abandoned design in the this context.”
確かに。HAMMER2について触れてるイントロとしてリンクしたけど、ミスったわ。

o11c 2025-04-06T02:14:59

>I am not sure whether DragonBSD is dead or alive today at all.”
NetBSDと同じくらいの活動レベルっぽいね。それをどう捉えるかは人それぞれ。

tansanrao 2025-04-06T01:31:38

へー、おもしろい!記事に追記するね、ありがとう!

agentkilo 2025-04-06T03:06:00

記事には、swapファイルを管理するpager daemonsはユーザ空間で実行され、カーネルメモリもswapアウトされることがあるって書いてあるけど、ユーザ空間のdaemonがどうやってカーネルメモリをswapアウトするのか説明がないんだよね。特別なdaemonのための例外があるのか、特別なシステムコールがあるのか?ユーザ空間のメモリ管理についてもっと詳しく知りたいんだけど。

comex 2025-04-06T05:48:23

この記事の内容、ちょっと違うみたいだよ。ごっちゃになってる部分があるね。

- Machのマイクロカーネルは、昔はユーザーランドのページングをサポートしてたんだ。mmapみたいに、ファイルシステムの代わりにデーモンを使ってたんだって。
https://web.mit.edu/darwin/src/modules/xnu/osfmk/man/memory-…
でもDarwinで使われてたかは不明。少なくともここ20年はないんじゃないかな。
- dynamic_pagerはこれを使ってなくて、もっと限定的なMachのインターフェースを使ってた。xnuがswap不足をdynamic_pagerに知らせて、dynamic_pagerがswapファイルを作って、macx_swaponとかでカーネルに渡してたんだって。でも実際のswapはカーネルがやってた。
https://github.com/apple-oss-distributions/system_cmds/blob/…
今はカーネルに移動して、dynamic_pagerはほぼ何もしてない。
https://github.com/apple-oss-distributions/system_cmds/blob/…
- カーネルメモリのほとんどはwiredでページアウトできないけど、カーネルはページング可能なメモリを要求できる(IOMallocPageableとか)。それはswapできるけど、あんまり使われてないみたい。
ユーザーランドが直接pagingに関わらなくても、ファイルシステムとかで間接的に関わることがあるから注意が必要だね。FUSEとかNFSとかSMBとか。
EDIT:最後に書いたことは間違ってるかも。ユーザー空間でブロックするファイルシステムは作れるけど、swapを置けるかはわかんない。

krackers 2025-04-06T06:41:25

>xnu could alert it when it was low on swap; dynamic_pager would create swap files, and pass them back into the kernel”
swapファイルの作成をユーザー空間経由にするメリットって何?カーネルが自分で作れば良くない?

comex 2025-04-06T07:03:28

今はカーネルが自分でswapファイル作ってるよ。昔と違った理由は分からないな。dynamic_pagerのコードも355行しかないし、ユーザー空間に処理を移すほど複雑じゃないし。でも1999年に書かれたものだし、マイクロカーネルへの熱意があったのかもね(フルMach pagingからは撤退してたけど)。

delusional 2025-04-06T09:25:15

当時のドキュメントを見ると、歴史的な経緯っぽいね。マイクロカーネルとして作られたインターフェースが、実際のシステムに適用されるときに、マイクロカーネルの概念が役に立たなくなって、負担にならない部分だけ残ったって感じかな(pagerインターフェースみたいに)。

95014_refugee 2025-04-07T09:01:52

長い間、カーネル内でファイル操作が発生しないように頑張ってたんだよ(レイヤー構造のため)。でも、最終的にもっとヤバい考えが広まっちゃったんだよね。

rollcat 2025-04-06T17:23:25

カーネルがファイル(どんなファイルでも)を単独で管理するのは、ハードウェアやユーザー空間について勝手な前提を置きすぎだと思うんだ。レスキューシステムでfsckしようとしたり、外部ROメディアから起動したり、ディスクレスで起動したり、NFSから起動したりすると、予期せぬ問題が起こる可能性がある。

一方、Linuxでは、swapon(2)であらゆるものを指定できる。ファイル、パーティション、ディスク全体、/dev/zram、zvolなど(最後のzvolは危険なデッドロックにつながる可能性があるからやめないで)。

XNU/NeXT/Darwin/OSXの開発者も同じくらいの柔軟性を求めていたのかな?何かのために、適切なものを、たとえスタブとしてでも、用意しておきたかったのかな?

swatson741 2025-04-06T01:34:36

Darwinカーネルが話題になると、AppleがLinuxをフォークして、その上にOSサービスを構築してたらどうなってたんだろうって考えちゃうんだよね。

特にDarwinにこだわり続けるのを見ると、残念な気持ちになる。オープンソースにとって損失だし、Appleも時間と金をつぎ込んでるのに、見返りが少ない気がする。

wtallis 2025-04-06T01:58:51

Appleがそういうスイッチをするタイミングはなかったと思うよ。NeXTSTEPはLinuxより前だし、Mac OS Xに採用されたときには、カーネルを丸ごと置き換えるプロジェクトなんてできなかっただろうし、1990年代後半のLinuxは、明らかに優れた選択肢とは言えなかった。OS Xが数バージョン進んで、消費者向けPCで最も成功したUNIX系OSとして確立された後では、Linuxベースに切り替えるのは、コストがかかるだけで、短期的なメリットはほとんどないリスクだっただろうね。

もしAppleが昔のMacOSを5年長く続けられたか、Linuxの成熟が5年早ければ、OS Xへの移行は全く違ったものになっていたかもしれないけど。でも、XNUを捨てて2.6以前のLinuxカーネルを採用するのは意味がなかったと思う。

swatson741 2025-04-06T02:09:12

全部同意だね。それに、Torvaldsが何をするかによっては、AppleはもっとコストのかかるXNUを手に入れることになって、大惨事になっていたかもしれない。AppleはTorvaldsとうまくやれると思うけど、どうなってたかは誰にも分からない。

inopinatus 2025-04-06T04:41:18

それはないって。絶対うまくいかないって。エゴと文化の衝突で、言い争いと責任のなすりつけ合いになるのが目に見えてる。Appleはメインフレーム以外で最も垂直統合されたシステムモデルを運用してるけど、Linuxとそのエコシステムは真逆だからね。あと、他の人も言ってるけど、NEXTSTEPのタイムラインが逆だよ。

もっとコメントを表示(1)
lunarlull 2025-04-06T04:03:59

乗り換えはまだしも、最初からOS XにLinuxを使う方が理にかなってたと思うな。そうならなかったのはJobsが自分のもう一つの子供に執着してたからでしょ。悪い選択じゃなかったけど、技術的なメリットよりも虚栄心とエゴから生まれた選択だったんじゃないかな。

dagmx 2025-04-06T05:46:14

なんでLinuxカーネルをベースにするのが理にかなってたのか、具体的に説明してないじゃん。当時の状況を説明して、なんでそう言えるのかをもっと詳しく教えてよ。Macはユーザーランド以外はBSDベースじゃないし。カーネルはかなり違ってたし、当時Linuxを使ってたらハードフォークしてたと思うよ。LinuxっていうとGNU/Linuxのこと言ってる人が多いけど、GNUはPOSIXのコマンドラインツールから大きくかけ離れてるし(そういう意味ではmacOSの方が忠実)、GPL3ライセンスはAppleにとって嫌悪すべきものだし。Linuxをベースにしたからって、今より良い結果になったとは到底思えないな。

jart 2025-04-06T11:36:22

まず、メモリ管理が良くなるはず。XNUカーネルのメモリマネージャーは時間計算量が低いから。mmap()を使ってスパースメモリマップをたくさん作ると、10,000個を超えたあたりからXNUが悲鳴を上げ始めるんだよね。

dagmx 2025-04-06T14:43:17

Linuxカーネルを使ったとしても、カーネルは大きく分岐してたはずだってコメントをもう一度読んでみて。30年前のカーネルが今と同じ特徴を持つと思ってるわけ?当時はどんなメリットがあったの?30年後も保証されるようなものはあった?

andrewf 2025-04-06T04:12:08

これって、AppleがJobsを意思決定者として迎え入れたって前提で、NEXTSTEPがおまけだったってことになってるよね。当時は逆で、Appleは将来のOSとしてNEXTSTEPを買収して、Jobsがおまけでついてきたんだよ。90年代のAppleのOS計画が大失敗だったことを考えると、Appleの役員会がLinuxに飛びつくとは思えないな。

lunarlull 2025-04-06T04:52:01

なんでAppleがLinuxに興味を持たなかったんだろ? JobsのおかげでNeXTSTEPを買ったのはわかるけど。Linuxは2000年にはデスクトップOSとして十分に使えるようになってたし、UXとかmac固有のドライバーを上に追加できたはず。デメリットはなかったはずだし、最大のライバルを弱体化させることにもなったのに。

musicale 2025-04-06T05:06:21

>Linuxは2000年にはデスクトップOSとして十分に使えるようになってた
Appleが決定したのは1996年だよ。

icedchai 2025-04-06T23:55:15

2000年代初頭、LinuxはデスクトップOSとしては実質的に使えなかった。唯一”完全に機能する”ウェブブラウザがInternet Explorerだったから。Netscape 4.xは”動作した”けど、めちゃくちゃ不安定で30分おきにクラッシュしてたし。Mozilla / Phoenix / Firefoxはまだ完成してなかったし。Chromeは存在しなかった。全然違う世界だったんだよ。オーディオとビデオの再生については言うまでもないよね。僕は1993年に初めてインストールした初期のLinuxユーザーだったけど、Linuxのデスクトップ体験はひどかったから、デスクトップでは悲しいことにWindowsを使ってたよ。

f33d5173 2025-04-07T00:24:26

Safariが出たのは2003年だよ。

wpm 2025-04-06T16:26:02

Jobsは最初Appleに戻りたくなかったんだよね。AppleがNeXTSTEPを買収したのは、BeOSとの間でJean-Louis Gasseeが欲張りすぎて法外な値段を要求したから。それでAppleはNeXTを選んだってわけ。Jobsは当時、みんなと同じようにAppleに見切りをつけてて、潰れる会社を立て直すなんてまっぴらごめんだったんだ。それに、当時のNeXTだって絶好調ってわけじゃなかったし。
>There wouldn’t have been any downsides for them
>本当に?デメリットなんてないって言うの???
・15年分の開発とエンジニアの経験を捨てることになる(Avie TevanianがMachの開発を手伝ったんだから、これはLinusがソフトウェア開発のトップにいるのに、Hurdに乗り換えろって言うようなもんだよ!)
・ライセンスの問題(AppleはGPLのせいで未だに古いbash 3.2を使ってる)
・OSをリリースするまでの開発期間が長くなる(10.0のリリースに5年もかかったし、出来もイマイチだった)
ちょっと考えただけでもこれだけある。Linux kernelが1996年当時、XNUより優れてる、安全だって思い込んでるんじゃないの?

DeathArrow 2025-04-06T15:57:11

>it would have strengthened something that was hurting their biggest rival.
最大のライバルってMicrosoftのこと?Appleを1997年に倒産から救ったのはMicrosoftだよ。

monocasa 2025-04-06T06:55:24

AFAICT、AppleがNextSTEPを買収した時、LinuxはPowerPCに移植されてすらいなかったんじゃないかな。

GianFabien 2025-04-06T02:30:00

AppleがNeXTを買収した頃、Linuxは開発途上でまだ確立されてなかった。Linuxはモノリシックカーネルだから、Machのようなコンパートメント化はできなかったんだ。
今のFreeBSDは、DarwinとLinuxのオープンソースの利点を兼ね備えてるって感じかな。Appleのロックインが進むのが嫌なら、FreeBSD(や他のBSD)を検討する価値はあるかも。

laurencerowe 2025-04-06T07:14:22

FreeBSDってモノリシックカーネルじゃなかったっけ?コンパートメント化されてるって話は初耳。
俺の理解だと、MachはBSDがベースで、既存のBSDカーネルの大部分がマイクロカーネルの下で単一のタスクとして動作するハイブリッド型だったはず。Darwinはその後、FreeBSDの最新の開発を取り入れ、マイクロカーネル下のBSDカーネルをアップデートしたんだよね。

TickleSteve 2025-04-06T07:44:11

MachはBSDをベースにしてないよ。BSDを置き換えたんだ。
MachはAccentとAlephカーネルの後継。
BSDはユーザランドツールとして採用された。
"Machは、BSD版Unixのカーネルを置き換えるものとして開発された"(https://en.wikipedia.org/wiki/Mach_(kernel))
面白いことに、MkLinuxはLinuxのユーザランドでMachカーネルを使うプロジェクトだった(BSDじゃなくて)。

finnjohnsen2 2025-04-06T05:52:21

FreeBSDをデスクトップOSとして使うには、ドライバのサポートってどうなの?
10年くらい前に試した時は、Nvidiaのドライバがネイティブ解像度で動かなくて諦めたんだよね。Bluetoothも問題があった気がする。FreeBSDはサーバーOSだと思った。

inkyoto 2025-04-06T08:46:16

>As things now stand, FreeBSD represents many of the benefits of Darwin and the open source nature of Linux.
ありえない。FreeBSDは、Intelアーキテクチャ以外のサポートを全て打ち切るという、UNIXの原罪を犯した。UNIXのDNAには、多様なCPUとハードウェアプラットフォームのサポートが刻まれてるのに。
FreeBSDが衰退したのは、Intelだけが生き残ると信じてARMやRISC-Vを見誤ったからだと思う。Linuxがその隙間を埋めて、今やどこでも動いてる。FreeBSDは速いけど、Linuxの方が優れてる。

adrian_b 2025-04-06T11:15:07

1995年頃からFreeBSDとLinuxを使い続けてるけど、それは違うと思うな。
LinuxがFreeBSDより成功したのは、マルチスレッド、マルチコアCPUへの移行が大きかった。2003年のSMT Intel Pentium 4から始まったんだ。
2003年頃、FreeBSD 4.xはシングルコアCPUで最速で安定したOSだった。LinuxやWindowsよりずっと上。でもマルチコアCPUに対応できなくて、Linuxに負けた。FreeBSD 5.xで対応したけど、競争力のある性能を取り戻すまで時間がかかった。

inkyoto 2025-04-06T11:39:10

歴史的な出来事の解釈には概ね同意するけど、BSDコアチームのせいもあると思う(不人気な意見だけど)。
最初の間違いは、JVMのネイティブサポートを拒否したこと。Linuxエミュレーションで動かしたけど、バグだらけだった。でもユーザーはJavaアプリを求めてたんだよ。
2つ目の間違いは、コンテナ(Docker)を拒否したこと。Linuxベースのコンテナがクラウドコンピューティングを支えてるのに。FreeBSDは手遅れだった。

usrnm 2025-04-06T13:35:00

Dockerって2013年にできたんだよね。BSDが人気なくなった後じゃん。それに、FreeBSDの方がLinuxよりずっと前にコンテナの先駆けだったんだよ。https://en.m.wikipedia.org/wiki/FreeBSD_jail

もっとコメントを表示(2)
inkyoto 2025-04-06T14:04:33

FreeBSDのjailsは、ちょっと進んだchroot++みたいなもんかな。コンテナの前身って言えるかもしれないけど、kernelの分離が弱かったり、network stackの分離がオプションだったり、resource controlも弱かったりするんだよね。Solaris 10のzonesの方がコンテナとしては先だったんじゃないかな。

tzs 2025-04-06T15:41:12

FreeBSDが普及しなかった理由の一つに、デュアルブートの問題もあったと思うんだよね。FreeBSDはディスク全体を管理したがるから、Windowsとかと一緒のディスクに入れるのが難しかった。Linuxはパーティションを切ればよかったから、手軽だったんだよね。あとはCD-ROMの対応が遅かったのも痛かった。

danieldk 2025-04-06T10:03:50

FreeBSDがIntel CPUに特化してたから衰退したってのは違うと思うな。もっと前からLinuxに負けてたし。原因は色々あると思うよ。ATTの訴訟とか、FreeBSDがexpert向けだったとか、forkが多かったとか、資金力とか、色々。

inkyoto 2025-04-06T11:20:55

ATTの訴訟はもう解決済みの話だよ。むしろ、それがFreeBSDとかNetBSDができたきっかけなんだから。ライセンスの問題も関係ないと思うな。BSDライセンスの方が商用には向いてるんだし。問題は、FreeBSDの開発がclosed-sourceな人たちを受け入れなかったことじゃないかな。

_paulc 2025-04-06T10:17:11

>FreeBSDは、Intelアーキテクチャ以外をサポートしないっていう、UNIXの罪を犯したんだよ。
FreeBSDはamd64とかaarch64とか、色んなプラットフォームをサポートしてるよ。https://www.freebsd.org/platforms/

linguae 2025-04-06T02:31:17

AppleがLinuxをPowerPC Macに移植するプロジェクトに協力してたのは面白いよね。でも、Macintosh GUIをLinuxに移植する動きはなかったと思う。昔はA/UXとかMacintosh Application Environmentとかもあったけど、ワークステーションレベルのリソースが必要だったから、現実的じゃなかったんだよね。

threeseed 2025-04-06T06:10:09

MkLinuxのタイミングがすごいよね。Coplandがキャンセルされた頃にリリースされてるんだから、AppleはLinuxを使うことも考えてたのかもしれないね。

kalleboo 2025-04-06T08:04:11

MkLinuxがLinux-on-Machだったってのがすごいよね。MachをPowerPCに移植したのが、NeXTSTEP Machの移植にも使われたんだから、全部繋がってるんだね。

skissane 2025-04-06T01:41:13

>Darwin kernelの話になるといつも思うんだけど、AppleがLinuxをforkしてたらどうなってたんだろうね。
XNUは一部しかopen sourceじゃないんだよね。APFS filesystemとかはmissingしてるし。Linuxをforkしてたら、全部open sourceにする必要があったかもしれないけど、Appleはそれを嫌ったんじゃないかな。

mattl 2025-04-06T01:55:59

昔、NeXTがGCCをGPLで配布しようとしたけど、起動時にプロプライエタリな部分をリンクさせるってことを考えてたんだって。Stallmanが弁護士と話して拒否したらしいよ。sourceforge.net/p/clisp/clisp/ci/default/tree/doc/Wh…で”NeXT”を探してみて。

leoh 2025-04-06T04:46:46

Stallmanが裁判官は自分に味方するって言い張ったのは、ちょっぴり傲慢じゃないかな。Oracle v. Googleの裁判とか見ると、裁判官が技術的なことを全然理解してないみたいだったし。

threeseed 2025-04-06T01:56:58

90年代後半の話だよ。Ubuntuなんて影も形もなかったし、デスクトップLinuxは機能も使いやすさもイマイチだった。
Appleには、NeXTStepを新しいカーネルに書き換えるお金も時間もなかったんだよ。開発チームの多くが、Appleのエンジニアリングや技術戦略の整理、Macみたいな機能の開発に忙殺されてたし。
当時AppleはPowerPCを使ってて、NeXTStepは対応してたけどLinuxは対応してなかった。IBMがLinuxを動かすまでに数年かかったしね。

bigger_cheese 2025-04-07T01:30:25

>90年代後半、Ubuntu以前は、デスクトップLinuxは機能も洗練度もイマイチだった。
当時のLinuxの勢いは凄かったんだよ。常に画期的なことが起きてる感じで、メジャーアップデートの度に変化があってワクワクしたんだ。アップデートをダウンロードして試すのが本当にエキサイティングで、最先端にいる気分だった。システムはしょっちゅう壊れたけど、それもまた楽しかった。
Slashdotを毎日読んで、distrowatchで新しいディストリビューションが出るたびに試してたな。カーネルのビルドもよくやってたし。
LILOからGRUBへの変更、EXT2からEXT3への変更、OSSからASLAへのサウンドシステム変更、/sysの導入、Gentooのミーム、udev、Signalfd、Splice/VMsplice、初期のワイヤレスサポート、ndiswrapperとか色々あったなあ。
今のLinuxは安定してて、良い意味で”退屈”。歳をとって時間がなくなったのもあるけどね。昔はLinuxを常にいじってないと動かなかったけど、今は大体”動く”。Ctrl + Alt + Backspaceなんて、最後にやったのがいつだったか思い出せないよ。最後にワクワクしたのはio_uringかな。

toast0 2025-04-06T03:52:11

FreeBSDからのアップデート頻度から考えると、AppleがLinuxをフォークしたらLinux 2.4みたいになるんじゃないかな?
オープンソースにとって何の損失があるんだろう?AppleがLinux 2.4にカーネルを移植するのと、FreeBSD 4.4に移植するのと、時間やお金は変わらないと思うけど。

WD-42 2025-04-06T06:18:23

GPLなら、改造した部分を公開する必要があるからじゃない?AppleはBSDの緩いライセンスを利用してるから、ただ乗りできてるんだよ。

palata 2025-04-06T11:13:19

別の見方をすれば、また別のカーネルがメンテナンスされてるのは素晴らしいことだと思うよ。
もしAppleがDarwinをオープンソースにしたら、オープンソースにとって大きな勝利になるんじゃない?

pjmlp 2025-04-06T09:26:32

この記事にはたくさんの愛と努力が注ぎ込まれてるね。昔からこの業界にいて、NeXTSTEPのコードをWindowsに移植したり、GNUStepを試したり、YellowBoxやOpenStepを覚えたり、内部構造の本を読んだり、WWDCのコンテンツをよく見てるけど、この記事はほとんどのシステムの進化について、僕の記憶と一致してるよ。

naves 2025-04-06T11:01:45

JobsがTorvaldsをMac OS Xの開発に誘ったけど、Linusは断ったんだって。macrumors.com/2012/03/22/steve-jobs-tried-to-hir…

astrange 2025-04-11T09:07:23

たぶんこれって、iOSがフォアグラウンドのアプリにバックグラウンドのアプリより多くのCPUパワーを割り当てるために使ってるブーストとかスロットルの元ネタだよね。目的としては、デーモンがクライアントアプリのために作業するときに、そのアプリの優先度を引き継ぐためなんだって。thread groupsとかworkloadsが何のためにあるのかは忘れちゃった。

larusso 2025-04-06T06:22:05

I/O kitが速度のためにこのC++サブセットで書かれたのかどうかはわかんないな。当時、物議をかもしたことがあってさ。AppleがMacOS Xを発表して、今のソフトウェアと互換性がないって言ったんだよね。パートナーはみんなObjective-Cで書き直す必要があったんだ。これはうまくいかなかったんだよね。Appleは方針転換して、cppアプリケーションのためのAPIレイヤーの“carbon”と、objective-cベースのFramework“Foundation”の基盤となる“Core Foundation”を導入したんだ。Obj-c++がある理由もそれ。面白いのは、メモリ管理を無料にできたこと。C/cppの世界で割り当てられたオブジェクトを、余分なオーバーヘッドなしにobj-cに渡せるってこと。

もっとコメントを表示(3)
dcrazy 2025-04-06T17:25:24

既存のC++ドライバをObjective-Cで書き直す代わりにIOKitに移植できるのは売りになるよね。なぜかObjective-CのシェルをC++で書くのが嫌いな人が多いみたいだけど。

larusso 2025-04-07T04:01:40

今の時代と比べて、外部の会社がどれだけ多くのドライバを出荷・開発する必要があったか、過小評価してるんじゃない?ソフトウェア/ハードウェア会社にとっては大問題だったんだよ。

fithisux 2025-04-06T05:44:38

XNUの周りにもっと良いFOSSコミュニティを育てるべきだったよね。ARMに移行した今、x64用の実行可能なディストリビューションがあるべきだった。

whalesalad 2025-04-06T01:11:29

ダーウィンをこの深さで理解したいとずっと思ってたんだ。素晴らしい記事だね!

jshier 2025-04-06T01:15:00

Singhの『Mac OS X Internals』は俺のお気に入りの本の一つ。10.4の頃のMac OS Xの詳細な調査が素晴らしい。アップデート版があれば本当に嬉しいな。
Edit:この記事の最後に引用されてるのを見つけた。まさに(macOS)時代の源だね。

wpm 2025-04-06T02:41:02

Jonathan Levinの3部作“*OS Internals”がそのアップデートだけど、Catalinaの頃にDarwinに関する作業と執筆をやめちゃったんだよね。

kccqzy 2025-04-06T01:37:24

俺もWindows NTをこの深さで理解したいと思ってたんだ。Win32のことは飛ばして、その下にあるものを議論してくれ。俺の理解だと、Win32は単なる人格の一つに過ぎない。Windows XP時代にはWindows Services for UNIXがあって、Windows VistaにはSubsystem for UNIX-based Applicationsもあった。根底にあるNTカーネルは、POSIX準拠を可能にするほど柔軟なんだ。それは面白い読み物になるだろうね。

p_ing 2025-04-06T01:50:44

Windows Internalsって本がおすすめだよ。もっと古いのがいいならInside Windows NTがいいかも。もしくはWindows NT OS/2 Design Workbookもいいんじゃない?
Win32はただの機能の一つだけど必須なんだよね。OpenNTとかInterixとかSFUとかSUAもWin32と一緒に使えるし。もちろんOS/2もあったよね。

nunez 2025-04-06T16:23:00

100%同意。今はAzureのトップのRussinovichが、このシリーズの多くの本を書いてて、NTカーネルを書いたDavid Solomonも最初の頃のを一緒に書いてるんだ。最新版はWindows 10/Server 2016をカバーしてるから、めっちゃおすすめ。

skissane 2025-04-06T01:51:02

>Win32はただの機能の一つって理解してたけど…
いや、NTは複数の”機能”を動かすように設計されたんだけど、開発の初期にWin32を”メイン”にすることにしたんだよね。だからOS/2とかPOSIXはWin32に頼る形になっちゃった。複数の機能っていうのは最初の理想だったけど、うまくいかなかったんだよね。WSL1は昔のOS/2とかPOSIXとは全然違うし、WSL2はただのLinuxのVMだし。

ForOldHack 2025-04-06T06:19:25

「NT(Windows 2000まで)には、キャラクタモードの16bit OS/2アプリを動かすOS/2サブシステムが搭載されてた」ってOS/2 museumに書いてあるよ。

skissane 2025-04-06T16:38:10

>それって違うみたい。
いや、あんたが引用したコメントは正しいよ。あんたが言ってることの方が違う。
>OS/2 2.0はNTのスキンと互換レイヤーで、OS/2向けに出た
それ勘違いしてるよ。OS/2はNTのスキンとかじゃなくて、完全に別のOSだよ。
NTがOS/2 2.0になるとか、OS/2 3.0になるとか言われてた時期もあったけど、最終的にリリースされたOS/2 2.0はNTとは全然関係ないんだ。IBMが独自に開発したもので、Microsoftは関わってない(初期段階は別として)。

ForOldHack 2025-04-06T06:14:51

WSL2はただのLinux VMで、POSIXサブシステムはただの間に合わせだって。NTにOS/2サブシステムがあったなんて聞いたことないな。Cutlerは激怒するだろうね。俺の壁にはUnix、Windows、Linuxの年表があるんだ。今はMacOS Xのもあるよ。機能はコンテナになったけど、これはWindows版の仮想化だね。コンテナはVirtualPCがベースだけど、Mark Russinivichの才能があったからこそ。

skissane 2025-04-06T06:32:24

>NTにOS/2サブシステムがあったなんて聞いたことないな
NT 3.1からWindows 2000まであったんだよ。Windows XPからは削除されたけどね。サポートされてたのはキャラクタモードの16bit OS/2 1.xアプリだけ。32bitアプリはサポートされなかった。Microsoftは「Microsoft OS/2 Presentation Manager For Windows NT」っていう追加料金のアドオンを提供して、GUIアプリもサポートしてたけど(それでも16bit OS/2 1.xアプリだけ)。NTがOS/2になるはずだったから、互換性のために入れたんだよね。でもMicrosoftは32bit OS/2はサポートしなかった。コンテナとか仮想化は機能の後継だけど、アーキテクチャは全然違うよ。

skissane 2025-04-08T01:36:39

>Microsoft Jazz workstations (in-house Microsoft workstation design using Intel i860 RISC CPUs)で動いてた
訂正:Microsoft Jazz machineはMIPSを使ってた。i860 machineはMicrosoft Dazzleだった。NT for MIPSは実際に出荷されたけど、NT for i860はMIPS portが使えるようになった時点で中止された。

p_ing 2025-04-06T12:03:18

32-bit appsは、IBMがOS/2 2.0で導入したけど、サポートされなかったんだよね。
これは離婚が原因なのは明らかだけど、Cruiser APIが完成してなかったからでもあるんだ。
>最初のOS/2 APIセットは、進化中の32-bit Cruiser、つまりOS/2 2.0 APIセットを中心にしてるんだ。(Cruiser APIsの設計はNT OS/2の設計と並行して行われてる。)“

>OS/2の設計(共同開発契約)の性質上、2.0 APIsの設計に影響を与えて、移植可能でx86以外のシステムにも実装できるようにするのはほとんど無理だったんだ。“

p_ing 2025-04-07T11:42:56

うん、これだよ。https://computernewb.com/~lily/files/Documents/NTDesignWorkb…

skissane 2025-04-08T02:44:56

サンキュー!NT Design Workbookだね。WRKの一部として配布されたやつだ。
興味深いことに32-bit OS/2 APIのサポート(Dos32* APIs)について言及してる。これって単なる計画倒れだったのか、それとも実装したけどNT 3.1のリリース前に削除したのかはわからないな。
MicrosoftがOS/2 2.0のベータSDKを配布してたことを今知ったけど、MicrosoftのOS/2 2.0のプレリリース版は、最終的なIBM OS/2リリースに比べて色々欠けてるね。特にWorkplace Shell (WPS)。IBMは当初、WPSをOfficeVision for OS/2の一部としてリリースする予定だったけど、2.0の開発サイクルのかなり後半でコアOS/2製品に移行させたんだ。

ForOldHack 2025-04-06T06:06:15

すごく詳しくて読みやすかったから、印刷して今日みんなに最後のOSリリースの違いを見せて、Snow Leopardについて語り合ったんだ。Blue BoxがRosettaになって、Rosetta IIがIntelからARMへの移行で同じことをしたって誰も言わないよね。
細かい点はいくつかあるけど、今までで一番だね。(Rhapsodyとスウェーデン語のLinuxとNT 3.1から始めたんだ。)(7100でMKLinuxを動かしてたけど、ビデオアクセラレーションはできなかった。)

mike_hearn 2025-04-06T11:14:21

良い歴史だね。でも、AppleのOSをLinuxやWindowsと区別する優れたセキュリティの取り組みをたくさん飛ばしてる。Appleがセキュリティでどれだけ進んでるかっていう評価が足りないんだよな。いつかこのことが認識されて、機密性の高い仕事をしてる人はCISOからMacを使うように言われるようになるんじゃないかな。
重要なのはコード署名システム。これのおかげでアプリに権限を与えたり、サンドボックス化したり、それを実際に維持できる。AppleはほとんどのUNIXみたいにELFを使わず、Mach-Oっていう形式を使ってる。ELFとMach-Oの違いは、Mach-Oが署名済みコードディレクトリを含む追加のセクションをサポートしてること以外は重要じゃない。

記事一覧へ

海外テックの反応まとめ
著者
海外テックの反応まとめ
暇つぶしがてらに読むだけで海外のテックニュースに詳しくなれるまとめサイトです。