배포판 GNU를 만드는 것은 무엇이며 GNU가 아닌 Linux 배포판이 있습니까?

Question 1

그만큼자유 소프트웨어 재단은 주장한다대부분의 Linux 배포판은 실제로 Linux 커널을 사용하는 GNU 시스템입니다. 그들은 GNU가 Linux가 등장하기 전에 무료 운영 체제를 개발하기 위한 오랜 프로젝트였다는 사실에 근거하여 이러한 주장을 하고 있습니다.커널은 마지막 누락된 조각일 뿐이었습니다.. 실제로 모든 Linux 기반 데스크톱 및 서버 배포판은 적어도 일부 GNU 구성 요소를 사용한다는 점에서 옳습니다. 아마도 가장 중요한 것은GNU C 라이브러리(글리BC),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 라이브러리(글리BC),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 커널은 인터넷의 발전에 힘입어 상당한 관심을 끌기 시작했습니다.

Richard Stallman의 GNU 프로젝트는 당시 계획된 GNU 운영 체제의 커널로 HURD 마이크로커널을 사용할 계획이었습니다. 그러나 새로운 Linux 커널 프로젝트를 중심으로 Linux 배포판(Linux 커널을 기반으로 한 무료 Unix 계열 운영 체제)이 형성되기 시작하면서 Stallman은 관심을 갖게 되었습니다. 1993년 데비안 프로젝트가 시작되었을 때 Ian Murdock의 지도 하에 FSF는 이 젊은 프로젝트에 재정적 지원을 제공했습니다. 그러나 데비안 개발자들은 부분적으로 기술적인 문제로 인해 Stallman 및 FSF와 빠르게 헤어졌습니다. 예를 들어 한 가지 문제는 Stallman이 프로그램에서 디버깅 기호를 유지하기를 원하는 반면 Debian은 디버깅 기호를 제거하기를 원했다는 것입니다.

데비안과 FSF가 헤어지자 Stallman은 데비안을 GNU/Linux라고 부르도록 요청했습니다. Murdock이 리더십을 그에게 넘겼기 때문에 Bruce Perens에게 요청이 이루어졌습니다. 이들 조직은 좋은 조건으로 헤어지고 공통의 목표를 공유했기 때문에 데비안 개발자들은 그가 요청한 대로 했습니다. 물론 Stallman이 이러한 이름을 독립적으로 장려한 것은 사실이지만, 실제 Linux 기반 운영 체제가 자신을 그렇게 지칭하는 데 협력한 것은 이러한 이름의 사용을 촉진하는 데 중요한 역할을 했습니다.

Stallman이 제시한 이론적 근거에는 (a) Linux 커널을 제외한 시스템의 핵심은 대부분 GNU 도구였으며, (b) Linux 커널은 어떤 의미에서 GNU 프로젝트의 정점/완성이었습니다. 한동안 작동하는 커널을 얻으려면 이 이름을 사람들에게 GNU 프로젝트의 이상을 인정하고 상기시키는 방법으로 사용해야 합니다. 이유 (a)는 더 자주 언급되는 경향이 있지만 그 당시에는 사실이 아니었고 지금은 훨씬 덜 사실입니다. Linux 기반 운영 체제의 분명히 중요한 부분은 bash, gcc, binutils, gdb와 같은 GNU 도구에 의존하지만 libc 등은 경우에 따라 다른 도구로 대체될 수 있습니다. 따라서 그러한 주장은 적어도 논쟁의 여지가 있으며 실제로 많은 논쟁을 불러일으켰습니다.

내가 아는 한 데비안과 (일부) 그 파생물(부모의 지시에 따라)만이 스스로를 GNU/Linux라고 부릅니다. 그러나 Fedora, Gentoo 등과 같은 소위 Linux 배포판은 본질적으로 Debian과 다르지 않습니다. 대부분 동일한 소프트웨어입니다. 따라서 이들을 GNU/Linux라고 부르는 데에는 똑같이 좋은 이유가 있습니다.

GNU 사용자 영역 없이 Linux 커널을 사용하는 시스템은 많지 않습니다. 왜냐하면 둘이 대체로 함께 개발되고 다양한 방식으로 얽혀 있기 때문입니다. (예를 들어 Linux 커널은 gcc의 확장(GNU) C로 작성되었으며 표준 C 컴파일러로 빌드되지 않습니다.) Thomas가 말했듯이 명백한 예는 Android이지만 Google에서 너무 많이 포크했기 때문에 앞으로 병합/조정에 대한 이야기가 있지만, 더 이상 안드로이드 커널을 리눅스라고 부르는 것이 맞는지는 의문입니다.

여담으로, Stallman과 FSF가 분명히 GNU/Linux 용어를 다소 강하게 밀어붙인다는 점은 불행한 일입니다. 예를 들어 조나단 코베트(Jonathan Corbet)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 커널은 인터넷의 발전에 힘입어 상당한 관심을 끌기 시작했습니다.

Richard Stallman의 GNU 프로젝트는 당시 계획된 GNU 운영 체제의 커널로 HURD 마이크로커널을 사용할 계획이었습니다. 그러나 새로운 Linux 커널 프로젝트를 중심으로 Linux 배포판(Linux 커널을 기반으로 한 무료 Unix 계열 운영 체제)이 형성되기 시작하면서 Stallman은 관심을 갖게 되었습니다. 1993년 데비안 프로젝트가 시작되었을 때 Ian Murdock의 지도 하에 FSF는 이 젊은 프로젝트에 재정적 지원을 제공했습니다. 그러나 데비안 개발자들은 부분적으로 기술적인 문제로 인해 Stallman 및 FSF와 빠르게 헤어졌습니다. 예를 들어 한 가지 문제는 Stallman이 프로그램에서 디버깅 기호를 유지하기를 원하는 반면 Debian은 디버깅 기호를 제거하기를 원했다는 것입니다.

데비안과 FSF가 헤어지자 Stallman은 데비안을 GNU/Linux라고 부르도록 요청했습니다. Murdock이 리더십을 그에게 넘겼기 때문에 Bruce Perens에게 요청이 이루어졌습니다. 이들 조직은 좋은 조건으로 헤어지고 공통의 목표를 공유했기 때문에 데비안 개발자들은 그가 요청한 대로 했습니다. 물론 Stallman이 이러한 이름을 독립적으로 장려한 것은 사실이지만, 실제 Linux 기반 운영 체제가 자신을 그렇게 지칭하는 데 협력한 것은 이러한 이름의 사용을 촉진하는 데 중요한 역할을 했습니다.

Stallman이 제시한 이론적 근거에는 (a) Linux 커널을 제외한 시스템의 핵심은 대부분 GNU 도구였으며, (b) Linux 커널은 어떤 의미에서 GNU 프로젝트의 정점/완성이었습니다. 한동안 작동하는 커널을 얻으려면 이 이름을 사람들에게 GNU 프로젝트의 이상을 인정하고 상기시키는 방법으로 사용해야 합니다. 이유 (a)는 더 자주 언급되는 경향이 있지만 그 당시에는 사실이 아니었고 지금은 훨씬 덜 사실입니다. Linux 기반 운영 체제의 분명히 중요한 부분은 bash, gcc, binutils, gdb와 같은 GNU 도구에 의존하지만 libc 등은 경우에 따라 다른 도구로 대체될 수 있습니다. 따라서 그러한 주장은 적어도 논쟁의 여지가 있으며 실제로 많은 논쟁을 불러일으켰습니다.

내가 아는 한 데비안과 (일부) 그 파생물(부모의 지시에 따라)만이 스스로를 GNU/Linux라고 부릅니다. 그러나 Fedora, Gentoo 등과 같은 소위 Linux 배포판은 본질적으로 Debian과 다르지 않습니다. 대부분 동일한 소프트웨어입니다. 따라서 이들을 GNU/Linux라고 부르는 데에는 똑같이 좋은 이유가 있습니다.

GNU 사용자 영역 없이 Linux 커널을 사용하는 시스템은 많지 않습니다. 왜냐하면 둘이 대체로 함께 개발되고 다양한 방식으로 얽혀 있기 때문입니다. (예를 들어 Linux 커널은 gcc의 확장(GNU) C로 작성되었으며 표준 C 컴파일러로 빌드되지 않습니다.) Thomas가 말했듯이 명백한 예는 Android이지만 Google에서 너무 많이 포크했기 때문에 앞으로 병합/조정에 대한 이야기가 있지만, 더 이상 안드로이드 커널을 리눅스라고 부르는 것이 맞는지는 의문입니다.

여담으로, Stallman과 FSF가 분명히 GNU/Linux 용어를 다소 강하게 밀어붙인다는 점은 불행한 일입니다. 예를 들어 조나단 코베트(Jonathan Corbet)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 이전에 시작되었으며 전체 운영 체제를 구축하기 위한 많은 양의 유틸리티를 제공합니다.

그러나 커널이 누락되었습니다. 그들은 비록허드커널, 준비하는 데 너무 오랜 시간이 걸렸습니다. 그런 다음리눅스가 왔다주변의 큰 열정의 도움으로 허드보다 더 빠르게 진화했습니다.

이제 서로 다른 두 프로젝트의 사용자 영역과 커널이 생겼습니다. 그리고 각각은 운영 체제를 갖추는 데 필수적이므로 협회 이름을 지정하는 것은 어떻습니까?GNU/리눅스그러면 각 프로젝트에 크레딧이 할당되나요?

BSD 유틸리티와 같은 다른 사용자 영역이 있거나BusyBox. 그러나 GNU 유틸리티에 비해 다소 완벽하며 일부 소프트웨어는 GNU 사용자 영역에서만 작동합니다. 예를 들어, 대부분의 BSD 운영 체제는 GCC를 컴파일러로 사용하고 있지만LLVM곧 이 상황이 바뀔 것이다.

그리고 범용 운영 체제로서 다음을 실행할 수 있습니다.FreeBSD 커널과 GNU 사용자 영역을 갖춘 데비안.

Answer

운영 체제는 커널과 사용자 영역의 조합입니다. 기본적으로 커널은 하드웨어를 관리하고 사용자 영역은 사용자에게 포괄적인 인터페이스를 제공합니다.

일반적인 GNU/Linux 배포판에서는리눅스커널을 제공하는 동안GNU 프로젝트사용자 영역 도구를 가져옵니다. GNU는 Linux 이전에 시작되었으며 전체 운영 체제를 구축하기 위한 많은 양의 유틸리티를 제공합니다.

그러나 커널이 누락되었습니다. 그들은 비록허드커널, 준비하는 데 너무 오랜 시간이 걸렸습니다. 그런 다음리눅스가 왔다주변의 큰 열정의 도움으로 허드보다 더 빠르게 진화했습니다.

이제 서로 다른 두 프로젝트의 사용자 영역과 커널이 생겼습니다. 그리고 각각은 운영 체제를 갖추는 데 필수적이므로 협회 이름을 지정하는 것은 어떻습니까?GNU/리눅스그러면 각 프로젝트에 크레딧이 할당되나요?

BSD 유틸리티와 같은 다른 사용자 영역이 있거나BusyBox. 그러나 GNU 유틸리티에 비해 다소 완벽하며 일부 소프트웨어는 GNU 사용자 영역에서만 작동합니다. 예를 들어, 대부분의 BSD 운영 체제는 GCC를 컴파일러로 사용하고 있지만LLVM곧 이 상황이 바뀔 것이다.

그리고 범용 운영 체제로서 다음을 실행할 수 있습니다.FreeBSD 커널과 GNU 사용자 영역을 갖춘 데비안.

Question 4

Linux 배포판 GNU를 만드는 것은 무엇입니까? 커널을 컴파일하는 데 사용된 도구입니까? 배포판과 함께 배송되는 도구입니까?

그렇습니다. 그렇습니다. 커널은 하나의 모놀리식 독립 실행형 실행 파일입니다.모든 것그 외에는 "에 거주합니다.사용자 영역". 일반적으로 사용자 영역 응용 프로그램은 표준 C 라이브러리인 하나 이상의 시스템 라이브러리를 사용합니다. ¹ 다양한 유틸리티 기능 외에도 이는 시스템 호출, 즉 시스템(즉, 커널에 수행할 작업 요청)에 대한 액세스를 제공합니다. 파일 작업과 같은 매우 기본적인 작업에도 필요한 것입니다. Linux에서 사용되는 C 라이브러리 구현은 GNU C 라이브러리인 glibc입니다.

리눅스 커널 자체는 C로 작성되었으며 작동하려면 C 라이브러리가 필요합니다. 단, 이 경우 필요한 부분은 외부가 아닌 내부에서 컴파일됩니다. 이를 위해 일반적으로 사용되는 컴파일러는 GCC("GNU 컴파일러 컬렉션")이고 C 라이브러리는 glibc입니다.

사실상 모든 사용자 영역은 glibc에 대해 컴파일되므로 커널 다음으로 시스템에서 가장 중요한 것 중 하나입니다. 또 다른 필수 구성 요소는 실행 파일을 외부 라이브러리에 연결하는 링커입니다. 그것도 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 제품이지만 glibc만큼 기본은 아닌 glib와 혼동하지 마십시오). 언급된 다른 모든 항목(아래 설명된 첫 번째 항목 제외)을 살펴보면 모두 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 라이브러리 AFAIK는오직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가 제공하는 것은 이것이 전부가 아닙니다. 그들은 또한 bash시스템 *nix를 (대부분) POSIX와 호환되게 만드는 쉘과 기타 핵심 도구 및 유틸리티를 담당합니다 . 그리고 최초의 Linux DE 중 하나이자 가장 널리 사용되는 GNOME입니다. 그리고 앞서 언급한 glib는 GNOME 및 기타 DE와 같은 기능을 지원하는 많은 고급 기능을 제공합니다. GNOME은 원래 GIMP용으로 개발된 GTK를 기반으로 구축되었습니다. GTK는 또한 다양한 다른 DE의 기본이기도 합니다. GTK와 GIMP도 GNU 제품입니다. 그들은 많은 일을 해왔습니다.

¹ 어떤 라이브러리에도 연결되지 않는 사용자 영역 애플리케이션과 같은 것이 있습니다. 이것들은 불린다공전이는 본질적으로 해당 라이브러리의 일부가 (커널과 마찬가지로) 컴파일되어 있음을 의미합니다.

Answer