ディストリビューションを GNU にするものは何か、また GNU ではない Linux ディストリビューションはあるか?

Question 1

のフリーソフトウェア財団は主張するLinuxディストリビューションの大半は、実はLinuxカーネルを使用しているGNUシステムである。この主張の根拠は、GNUはLinuxが登場する前からフリーなオペレーティングシステムを開発する長年のプロジェクトであり、カーネルは最後の欠けているピースに過ぎなかった事実上すべてのLinuxベースのデスクトップおよびサーバーディストリビューションは少なくともいくつかのGNUコンポーネントを使用しているという点で彼らの言う通りであり、おそらく最も重要なのはGNU C ライブラリ(glibc)、GNU コアユーティリティ(coreutils) とバッシュシェル。さらに、Linuxカーネルの開発は本質的にGCCに結びついています。GCC拡張機能の利用。

一部の組み込みシステム、おそらく最も有名なのはGoogleのAndroidですが、GNUコンポーネントやライブラリを一切使用していません。たとえばAndroidでは、GNU CライブラリはGoogle独自のBSDベースのBionic Cライブラリに置き換えられています。FSFは、このようなシステムを「GNU システム」または「GNU/Linux」しかし、一方で、彼らはこれらが単に「Linux」システムと呼ばれることも望んでいない。少なくとも、カーネルの構築にGNUツールを使用することは、ないシステムを「GNU システム」にする。

Answer

のフリーソフトウェア財団は主張するLinuxディストリビューションの大半は、実はLinuxカーネルを使用しているGNUシステムである。この主張の根拠は、GNUはLinuxが登場する前からフリーなオペレーティングシステムを開発する長年のプロジェクトであり、カーネルは最後の欠けているピースに過ぎなかった事実上すべてのLinuxベースのデスクトップおよびサーバーディストリビューションは少なくともいくつかのGNUコンポーネントを使用しているという点で彼らの言う通りであり、おそらく最も重要なのはGNU C ライブラリ(glibc)、GNU コアユーティリティ(coreutils) とバッシュシェル。さらに、Linuxカーネルの開発は本質的にGCCに結びついています。GCC拡張機能の利用。

一部の組み込みシステム、おそらく最も有名なのはGoogleのAndroidですが、GNUコンポーネントやライブラリを一切使用していません。たとえばAndroidでは、GNU CライブラリはGoogle独自のBSDベースのBionic Cライブラリに置き換えられています。FSFは、このようなシステムを「GNU システム」または「GNU/Linux」しかし、一方で、彼らはこれらが単に「Linux」システムと呼ばれることも望んでいない。少なくとも、カーネルの構築にGNUツールを使用することは、ないシステムを「GNU システム」にする。

Question 2

GNU/Linux 用語の歴史は 1990 年代初頭に遡ります。

1991 年、Linus Torvalds 氏はヘルシンキの自宅の寝室で Linux カーネルプロジェクトを開始しました。その後間もなく、インターネットの普及も手伝って Linux カーネルは大きな注目を集め始めました。

リチャード・ストールマンの GNU プロジェクトは、当時、計画中の GNU オペレーティングシステムのカーネルとして HURD マイクロカーネルを使用する計画でした。しかし、Linux ディストリビューション (Linux カーネルに基づく無料の Unix ライクなオペレーティングシステム) が新しい Linux カーネルプロジェクトを中心に形成され始めると、ストールマンは興味を持ちました。1993 年にイアン・マードックのリーダーシップの下で Debian プロジェクトが開始されると、FSF はこの若いプロジェクトにいくらかの資金援助を行いました。しかし、Debian 開発者は、技術的な問題もあって、ストールマンと FSF とすぐに袂を分かったのです。たとえば、ストールマンはプログラム内のデバッグシンボルを保持したいと考えていましたが、Debian はそれを削除したいと考えていました。

Debian と FSF が袂を分かった後、ストールマンは Debian が自らを GNU/Linux と呼ぶように要求しました。この要求は、マードックがリーダーシップを彼に引き渡したため、ブルース・ペレンズに行われました。これらの組織は良好な関係で袂を分かち合い、共通の目標を共有していたため (そして共有していたため)、Debian 開発者は彼の要求に従いました。もちろん、ストールマンが独自にそのような名前を推進してきたのは事実ですが、実際の Linux ベースのオペレーティングシステムが自らをそのように呼ぶことに協力したことは、そのような名前の使用を促進する上で大きな意味がありました。

ストールマンが示した理論的根拠には、(a) Linux カーネル以外のシステムの中核は主に GNU ツールである、(b) Linux カーネルは、しばらくの間機能するカーネルの実現に取り組んできた GNU プロジェクトの集大成/完成形であるという意味において、GNU プロジェクトの理想を認め、人々に思い出させるためにこの名前を使用するべきである、などがありました。理由 (a) は、当時も今もまったく当てはまりませんが、かなり頻繁に言及される傾向があります。Linux ベースのオペレーティングシステムの重要な部分は明らかに bash、gcc、binutils、gdb、libc などの GNU ツールに依存していますが、場合によってはこれらを他のツールで置き換えることができます。したがって、このような議論は少なくとも議論の余地があり、実際に多くの議論が行われてきました。

私の知る限り、Debian とその派生版 (その親に倣ったもの) だけが GNU/Linux を自称しています。しかし、Fedora、Gentoo などの他のいわゆる Linux ディストリビューションは、実質的に Debian と何ら変わりなく、ほとんど同じソフトウェアです。したがって、これらを GNU/Linux と呼ぶのには、同様に十分な理由があります。

GNU ユーザーランドなしで Linux カーネルを使用しているシステムは多くありません。なぜなら、この 2 つは大部分が一緒に開発され、さまざまな方法で絡み合っているからです。(たとえば、Linux カーネルは gcc の拡張 (GNU) C で書かれており、標準の C コンパイラではビルドできません。) Thomas が言ったように、明らかな例は Android ですが、Google によって非常に頻繁にフォークされているため、Android カーネルを Linux と呼ぶのが正しいかどうかは疑問です。ただし、将来的には統合/調整の話があります。

余談だが、残念ながらストールマンとFSFは明らかにGNU/Linuxの用語をかなり強く押し付けているようだ。例えば、ジョナサン・コーベットLWNのコメントに書いたFSF は、GNU/Linux という用語を使用しない限り、彼と話をすることを拒否している。Jon は、LWN の創設者であるだけでなく、尊敬される上級カーネル開発者でもある。コメント全体は次のように述べている。

この点について明確にしておきます。FSF は、私たちが何を言うか、どのような用語を使うかについて事前に約束しない限り、私たちと話をすることを拒否したため、私たちは何年も前に FSF にコメントを求めるのをやめました。私たちはそのような約束をする気はありません。そのようなことに関する FSF の方針が変更されたのであれば、喜んでお知らせします。

これは明らかに、とりわけ GNU/Linux 用語のこだわりを指しています。

上記の歴史については、Glyn Moody 著の「Rebel Code」の第 6 章 (「Boot Then Root」) で詳しく説明されています。

Answer

GNU/Linux 用語の歴史は 1990 年代初頭に遡ります。

1991 年、Linus Torvalds 氏はヘルシンキの自宅の寝室で Linux カーネルプロジェクトを開始しました。その後間もなく、インターネットの普及も手伝って Linux カーネルは大きな注目を集め始めました。

リチャード・ストールマンの GNU プロジェクトは、当時、計画中の GNU オペレーティングシステムのカーネルとして HURD マイクロカーネルを使用する計画でした。しかし、Linux ディストリビューション (Linux カーネルに基づく無料の Unix ライクなオペレーティングシステム) が新しい Linux カーネルプロジェクトを中心に形成され始めると、ストールマンは興味を持ちました。1993 年にイアン・マードックのリーダーシップの下で Debian プロジェクトが開始されると、FSF はこの若いプロジェクトにいくらかの資金援助を行いました。しかし、Debian 開発者は、技術的な問題もあって、ストールマンと FSF とすぐに袂を分かったのです。たとえば、ストールマンはプログラム内のデバッグシンボルを保持したいと考えていましたが、Debian はそれを削除したいと考えていました。

Debian と FSF が袂を分かった後、ストールマンは Debian が自らを GNU/Linux と呼ぶように要求しました。この要求は、マードックがリーダーシップを彼に引き渡したため、ブルース・ペレンズに行われました。これらの組織は良好な関係で袂を分かち合い、共通の目標を共有していたため (そして共有していたため)、Debian 開発者は彼の要求に従いました。もちろん、ストールマンが独自にそのような名前を推進してきたのは事実ですが、実際の Linux ベースのオペレーティングシステムが自らをそのように呼ぶことに協力したことは、そのような名前の使用を促進する上で大きな意味がありました。

ストールマンが示した理論的根拠には、(a) Linux カーネル以外のシステムの中核は主に GNU ツールである、(b) Linux カーネルは、しばらくの間機能するカーネルの実現に取り組んできた GNU プロジェクトの集大成/完成形であるという意味において、GNU プロジェクトの理想を認め、人々に思い出させるためにこの名前を使用するべきである、などがありました。理由 (a) は、当時も今もまったく当てはまりませんが、かなり頻繁に言及される傾向があります。Linux ベースのオペレーティングシステムの重要な部分は明らかに bash、gcc、binutils、gdb、libc などの GNU ツールに依存していますが、場合によってはこれらを他のツールで置き換えることができます。したがって、このような議論は少なくとも議論の余地があり、実際に多くの議論が行われてきました。

私の知る限り、Debian とその派生版 (その親に倣ったもの) だけが GNU/Linux を自称しています。しかし、Fedora、Gentoo などの他のいわゆる Linux ディストリビューションは、実質的に Debian と何ら変わりなく、ほとんど同じソフトウェアです。したがって、これらを GNU/Linux と呼ぶのには、同様に十分な理由があります。

GNU ユーザーランドなしで Linux カーネルを使用しているシステムは多くありません。なぜなら、この 2 つは大部分が一緒に開発され、さまざまな方法で絡み合っているからです。(たとえば、Linux カーネルは gcc の拡張 (GNU) C で書かれており、標準の C コンパイラではビルドできません。) Thomas が言ったように、明らかな例は Android ですが、Google によって非常に頻繁にフォークされているため、Android カーネルを Linux と呼ぶのが正しいかどうかは疑問です。ただし、将来的には統合/調整の話があります。

余談だが、残念ながらストールマンとFSFは明らかにGNU/Linuxの用語をかなり強く押し付けているようだ。例えば、ジョナサン・コーベットLWNのコメントに書いたFSF は、GNU/Linux という用語を使用しない限り、彼と話をすることを拒否している。Jon は、LWN の創設者であるだけでなく、尊敬される上級カーネル開発者でもある。コメント全体は次のように述べている。

この点について明確にしておきます。FSF は、私たちが何を言うか、どのような用語を使うかについて事前に約束しない限り、私たちと話をすることを拒否したため、私たちは何年も前に FSF にコメントを求めるのをやめました。私たちはそのような約束をする気はありません。そのようなことに関する FSF の方針が変更されたのであれば、喜んでお知らせします。

これは明らかに、とりわけ GNU/Linux 用語のこだわりを指しています。

上記の歴史については、Glyn Moody 著の「Rebel Code」の第 6 章 (「Boot Then Root」) で詳しく説明されています。

Question 3

オペレーティングシステムは、カーネルとユーザーランドの組み合わせです。基本的に、カーネルはハードウェアを管理し、ユーザーランドはユーザーに包括的なインターフェイスを提供します。

一般的なGNU/Linuxディストリビューションでは、リナックスカーネルを提供し、GNUプロジェクトユーザーランドツールを提供します。GNU は Linux よりずっと前に開始され、完全なオペレーティングシステムを構築するための大量のユーティリティを提供します。

しかし、核が欠けていた。ハードカーネルの準備に時間がかかりすぎた。そしてLinuxが登場周囲の大きな熱意のおかげで、ハードよりも速く進化しました。

これで、2つの異なるプロジェクトからユーザーランドとカーネルができました。それぞれがオペレーティングシステムに不可欠なので、関連付けに名前を付けるのはいかがでしょうか。GNU/Linuxつまり、各プロジェクトに功績が与えられるということですか?

BSDユーティリティのような他のユーザーランドもあります。ビジーボックスしかし、GNUユーティリティと比較すると、それらは多かれ少なかれ完成されており、一部のソフトウェアはGNUユーザーランドでのみ動作します。たとえば、BSDオペレーティングシステムのほとんどはコンパイラとしてGCCを使用していますが、LLVMすぐにこの状況は変わるでしょう。

そしてユニバーサルオペレーティングシステムとして、FreeBSDカーネルとGNUユーザーランドを搭載したDebian。

Answer

オペレーティングシステムは、カーネルとユーザーランドの組み合わせです。基本的に、カーネルはハードウェアを管理し、ユーザーランドはユーザーに包括的なインターフェイスを提供します。

一般的なGNU/Linuxディストリビューションでは、リナックスカーネルを提供し、GNUプロジェクトユーザーランドツールを提供します。GNU は Linux よりずっと前に開始され、完全なオペレーティングシステムを構築するための大量のユーティリティを提供します。

しかし、核が欠けていた。ハードカーネルの準備に時間がかかりすぎた。そしてLinuxが登場周囲の大きな熱意のおかげで、ハードよりも速く進化しました。

これで、2つの異なるプロジェクトからユーザーランドとカーネルができました。それぞれがオペレーティングシステムに不可欠なので、関連付けに名前を付けるのはいかがでしょうか。GNU/Linuxつまり、各プロジェクトに功績が与えられるということですか?

BSDユーティリティのような他のユーザーランドもあります。ビジーボックスしかし、GNUユーティリティと比較すると、それらは多かれ少なかれ完成されており、一部のソフトウェアはGNUユーザーランドでのみ動作します。たとえば、BSDオペレーティングシステムのほとんどはコンパイラとしてGCCを使用していますが、LLVMすぐにこの状況は変わるでしょう。

そしてユニバーサルオペレーティングシステムとして、FreeBSDカーネルとGNUユーザーランドを搭載したDebian。

Question 4

Linux ディストリビューションを GNU たらしめるものは何でしょうか? カーネルをコンパイルしたツールでしょうか? ディストリビューションが同梱されているツールでしょうか?

はい、そうです。カーネルは 1 つのモノリシックなスタンドアロン実行可能ファイルです。すべてそれ以外の場合は「ユーザーランド一般に、ユーザーランドアプリケーションは、少なくとも 1 つのシステムライブラリ、つまり標準 C ライブラリを使用します。1^さまざまなユーティリティ関数に加えて、これは、ファイル操作などの非常に基本的なタスクにも必要なシステムコール (システム、つまりカーネルに何かを実行するよう要求する) へのアクセスを提供します。Linux で使用される C ライブラリ実装は、GNU C ライブラリである glibc です。

Linux カーネル自体は C で書かれており、動作するために C ライブラリも必要です。ただし、この場合は必要な部分が外部ではなくコンパイルされています。通常、これに使用されるコンパイラは GCC (「GNU コンパイラコレクション」) であり、C ライブラリは glibc です。

実質的にすべてのユーザーランドは glibc に対してコンパイルされているため、これはカーネルに次いでシステム上で最も重要なものの 1 つです。もう 1 つの重要なコンポーネントは、実行可能ファイルを外部ライブラリに接続するリンカーです。これも GNU 製品です。

これを説明するには、ライブラリ (実行可能だが、それ自体では実行できない) を含むさまざまな実行可能ファイルでを使用できますldd。マニュアルページに記載されているように、「ldd は、コマンドラインで指定された各プログラムまたは共有ライブラリに必要な共有ライブラリを出力します。」例:

> ldd /bin/bash
    linux-vdso.so.1 =>  (0x00007fff7348e000)
    libtinfo.so.5 => /lib64/libtinfo.so.5 (0x00007fdbdae7f000)
    libdl.so.2 => /lib64/libdl.so.2 (0x00007fdbdac7b000)
    libc.so.6 => /lib64/libc.so.6 (0x00007fdbda8c3000)
    /lib64/ld-linux-x86-64.so.2 (0x00007fdbdb0c8000)

「libc.so.6」に注目してください。これは glibc です (Linux の基礎となる別の GNU 製品である glib と混同しないでください。ただし、glibc ほど基礎的ではありません)。言及されている他のすべてのもの (以下で説明する最初のものを除く) を見ると、それらはすべて libc 自体にリンクしていることに気付くでしょう。libc.so.6 自体を見てみましょう。

> ldd /lib64/libc.so.6
    /lib64/ld-linux-x86-64.so.2 (0x00007f9cefa04000)
    linux-vdso.so.1 =>  (0x00007fffb21ff000)

「ld-linux-x86-64.so.2」は、上で言及したリンカーです (一般的にはldで、マニュアルページがあります)。ldd を実行することはできませんが、file動的にリンクされていると表示されています。おそらく libc (これは循環論法のように聞こえるかもしれませんが、そうではありません) と linux-vdso にリンクされていると思われます。この最後のリンカーは、の後にアドレスだけがあることに気付くので、興味深いものです=>。これは、実際にはカーネルの一部であるためです。

私の知る限り、CライブラリはのみCライブラリにリンクされていないシステム上の共有オブジェクトです。中心全体の混乱です。他のコンパイル言語の基本ライブラリでも libc が使用されています。例:

> ldd libstdc++.so.6.0.17 
    linux-gate.so.1 =>  (0xf77b8000)
    libm.so.6 => /lib/libm.so.6 (0xf7684000)
    libc.so.6 => /lib/libc.so.6 (0xf74d2000)
    /lib/ld-linux.so.2 (0xf77b9000)
    libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xf74b5000)

ライブラリとリンカーには、シンボリックリンクを使用して実装されたさまざまな仮名があることに注意してください (例: /lib64/ld-linux-x86-64.so.2 は実際には /lib64/ld-2.15.so です)。

またgcc、「ネイティブ」コンパイラ (カーネルと C ライブラリをコンパイルするため) はシステム上に存在する必要はありませんが、libc と ld は存在する必要があります。そうしないと何も動作しません。

GNU が提供するものはこれだけではありません。GNU は、bashシステムを *nix 風にし、(主に) POSIX 互換にするシェルやその他のコアツールやユーティリティも担当しています。また、最初の Linux DE の 1 つであり、最も広く使用されている GNOME もあります。そして、前述の glib は、GNOME やその他の DE などをサポートする高レベル関数を多数提供しています。GNOME は、もともと GIMP 用に開発された GTK 上に構築されています。GTK は、他のさまざまな DE の基礎にもなっています。GTK と GIMP も GNU 製品です。GNU は、多くのことを行ってきました。

¹ライブラリにリンクしないユーザーランドアプリケーションというものがあり、これらは静的実行可能ファイルであり、本質的には、そのライブラリの一部がコンパイルされていることを意味します (カーネルの場合と同様)。

Answer