프로그램이 컴파일 된 형식으로 배포되지 않는 이유는 무엇입니까?

그러나 그들은 같은 지침을 제공합니다

cd downloaded_program
./configure
make install

필요한 ELF 및 일부 .so 파일이 생성됩니다.

Windows 앱과 같이 다운로드를 위해 zip 파일 안에 넣지 않겠습니까? 사용자가 컴파일해야하는 이유가 있습니까?

요인을 분석해 봅시다 ...

분석 :

플랫폼에 따른 종속성 : 개발자가 여러 아키텍처 별 응용 프로그램 변형을 작성하고 유지 관리하는 환경에서 발생하는 몇 가지 문제가 있습니다.

• 변형에 따라 다른 소스 코드가 필요함 — UNIX 기반 운영 체제마다 다른 기능을 사용하여 동일한 작업을 구현할 수 있습니다 (예 : strchr (3) vs. index (3)). 마찬가지로, 변형에 따라 다른 헤더 파일을 포함해야 할 수도 있습니다 (예 : string.h vs. strings.h).

• 변형에 따라 다른 빌드 절차가 필요합니다 — 플랫폼에 따라 빌드 절차가 다릅니다. 차이점은 컴파일러 위치, 컴파일러 옵션 및 라이브러리와 같은 특정 사항을 포함 할 수 있습니다.

• 다른 변형에 대한 빌드는 별도로 유지해야합니다. 단일 소스 트리가 있으므로 한 아키텍처의 객체 모듈 및 실행 파일이 다른 아키텍처의 객체 모듈 및 실행 파일과 혼동되지 않도록주의해야합니다. 예를 들어, 링크 편집기는 SunOS–4 용으로 작성된 객체 모듈을 사용하여 IRIX–5 실행 파일을 만들려고 시도해서는 안됩니다.

• 모든 운영 체제에는 고유 한 연결 관리 체계가 있으며 필요에 따라 ELF (Executable and Linking Format) 파일을 준비해야합니다.

• 컴파일러는 일련의 명령어 인 빌드를 생성 하며 별개의 아키텍처는 서로 다른 명령어 세트를 의미합니다 ( 명령어 세트 아키텍처 비교 ). 따라서 컴파일러의 출력은 각 아키텍처마다 다릅니다 (예 : x86, x86-64, ARM, ARM64, IBM Power ISA, PowerPC, Motorola 6800, MOS T 6502 등 )

보안 :

• 바이너리를 다운로드하면 그것이하는 일을 확실하게 할 수는 없지만 소스 코드를 감사하고 자체 컴파일 된 바이너리를 시스템에서 사용할 수 있습니다. 그럼에도 불구하고 사용자 Techmag 는 자신의 의견에서 좋은 지적을했으며 코드를 감사하려면 코드를 평가하기 위해 지식이 풍부하고 유능한 코더가 필요하지만 안전 보장은 아닙니다.

시장 :이 섹션에는 많은 요소가 있지만 다시 시작하려고합니다.

• 모든 회사가 모든 플랫폼에 도달하는 것을 목표로하는 것은 아니며 시장과 플랫폼 인기도 및 판매 대상에 따라 다릅니다.

• 자유 소프트웨어는 소프트웨어를 가능한 한 광범위하게 사용할 수 있도록하는 정신을 가지고 있지만 소프트웨어가 모든 플랫폼에 맞게 설계된 것은 아니며 소프트웨어를 지원하는 커뮤니티에 따라 다릅니다.

결론 :

모든 소프트웨어가 모든 플랫폼에 맞게 설계된 것은 아닙니다. 모든 아키텍처 및 플랫폼에 바이너리를 제공한다는 것은 컴파일, 테스트 및 모든 플랫폼에 대한 유지 관리를 의미합니다. 때로는 너무 비싸서 사용자가 자체 플랫폼에서 컴파일하면 피할 수 있습니다. 또한 사용자는 자신이 무엇을 실행하고 있는지 알고 있습니다.

* nix 및 기타 와 같은 다양한 플랫폼 및 소프트웨어 환경 이 있으므로 소프트웨어를 실행할 수 있으며 응용 프로그램 (또는 응용 프로그램과 함께 사용할 라이브러리)을 빌드하는 것이 유일한 현실적인 방법입니다. "양호한"소프트웨어 항목으로서 이러한 구성 요소의 많은 조합. 물론, GPL과 같은 라이센스는 소스 코드를 사용할 수 있어야합니다 . 따라서 소프트웨어가 제대로 작동하지 않더라도 일반적으로 사용자에게는 문제가 있습니다. 또는 제작자가 더 이상 존재하지 않거나 더 이상 존재하지 않는 경우에도 다이빙하고 수정하기 위해 일부 타사 .

소스 코드로 소프트웨어를 배포 하면 소프트웨어가 주장하는 것을 수행하고 대신 또는 불쾌한 작업을 수행하지 않는다는 독립적 인 검증 도 가능 합니다. 제작자에 대한 신뢰 수준을 낮추더라도 실제로는 소프트웨어를 향상시킵니다!

먼저, 귀하의 질문은 결함이있는 전제에 기초합니다. 프로그램 은 컴파일 된 형식으로 배포됩니다!

대부분의 다른 Linux 배포판과 마찬가지로 Ubuntu에 소프트웨어를 설치하는 일반적인 방법은 대부분의 Unix 변형과 마찬가지로 패키지를 설치하는 것입니다. Ubuntu에서 소프트웨어 센터 또는 다른 패키지 관리자를 열고 사용 가능한 소프트웨어를 찾아보십시오. 설치할 패키지를 선택하면 바이너리 (패키지에 프로그램이 포함 된 경우)가 컴퓨터에 다운로드되어 설치됩니다.

기본적으로 패키지 관리자는 배포 관리자가 만든 패키지를 제공합니다. 타사 패키지 소스를 찾을 수도 있습니다. Ubuntu는 타사에서 패키지를 제공 할 수있는 표준화 된 방법으로 PPA 를 제공합니다.

작성자로부터 소프트웨어를 컴파일 된 형태로 다운로드하는 것이 최후의 수단입니다. 소프트웨어가 패키지화 될 정도로 인기가 없거나 패키지화되지 않은 최신 버전이 절대적으로 필요한 경우에만 수행하면됩니다. 대부분의 사람들은 이것을 할 필요가 없습니다.

소프트웨어가 배포 용으로 패키지되지 않은 경우 종종 이진 형식이 아닌 소스 형식으로 배포됩니다. 이것이 Linux 세계에서는 종종 발생하지만 Windows 세계에서는 거의 발생하지 않는 두 가지 주요 이유가 있습니다. 한 가지 이유는 Linux에서 오픈 소스 프로그램의 비율이 훨씬 높기 때문입니다. 프로그램의 소스 코드를 사용할 수없는 경우 유일한 배포 형식은 이진입니다. 다른 이유는 리눅스 세계가 훨씬 더 다양하기 때문입니다. 호환되지 않는 라이브러리 버전의 각 세트마다 다른 바이너리가 필요합니다. 이는 종종 각 배포판의 각 버전마다 다른 바이너리를 의미합니다. Windows는 각 패키지 작성자가 사용하는 라이브러리를 프로그램과 함께 배포하여이를“해결”합니다 (결과 : 컴퓨터는 각 라이브러리의 사본을 사용하는 프로그램 당 하나씩, 라이브러리에서 버그가 수정 된 경우, 이 프로그램을 사용하는 각 프로그램은 업데이트를 제공해야 함) 3 년 정도마다 새 버전의 운영 체제를 출시합니다. 유닉스는 훨씬 더 다양한 다양성과 훨씬 더시기 적절한 버그 수정 습관을 가지고 있으며, 배포판마다 다른 바이너리를 만들어 라이브러리 배포 문제를 해결합니다.

Linux는 하나 이상의 특정 CPU 플랫폼에서 실행됩니다. ELF 파일 (또는 다른 종류의 원시 실행 파일)을 배포 한 경우 일부 Linux 버전에서 소프트웨어를 실행하지 못할 수 있습니다. 소프트웨어를 최대한 폭넓게 사용할 수 있도록하려면 소스 코드를 사용하는 것이 좋습니다. 예를 들어 Linux는 Sparc, Intel, AMD, ARM 및 기타 유형의 프로세서에서 실행됩니다.

예를 들어 ELF 파일이 특히 인텔 프로세서를 대상으로하는 경우 다른 유형의 하드웨어는 소프트웨어를 실행할 수 없습니다. ELF는 플랫폼에 독립적이지만 호스트 코드는 플랫폼의 기계 코드를 준수해야합니다. 유사한 패키지를 가진 배포판이 몇 개 있는지 (예 : 다른 프로세서를 지원하는 경우 _386 및 _586 패키지) 알 수 있습니다. 올바른 작업을 수행하려면 올바른 ELF 파일을 설치해야합니다.

마찬가지로 다른 인터럽트, 링커 등을 사용하는 사용자 정의 Linux 버전을 빌드하기로 결정한 경우에도 코드를 컴파일하려면 소스 코드가 필요합니다. 소스 코드에 플랫폼 별 빌드 지침이 없더라도 각 플랫폼 은 다르며 다른 시스템에서 ELF를 실행하지 못할 수 있습니다.

소스로 배포 한 최초의 이유는 플랫폼의 다양성이었습니다. 리눅스 커뮤니티는 그 방법론과 새로운 정치적 부분적 이유를 위해 그 방법론을 계속 해왔다.

예를 들어, Windows와 달리 Linux는 역사적으로 ABI (Application Binary Interface)를 오랫동안 안정적으로 유지하기 위해 귀찮게하지 않았습니다. 중대한.

상업용 운영 체제는 혁신에 대해 매우 훈련을 받아 장기적인 응용 프로그램 호환성을 달성합니다. 새로운 기능 / 소프트웨어 인터페이스는 항상 기존 기능에 추가해야합니다. 두 가지 사항을 유지해야하며 릴리스 후 변경 사항은 매우 높은 것으로 간주해야합니다. 또는 계획된 응용 프로그램 노후화 사실을 OS 용 소프트웨어를 작성하는 사람과 함께 포용 할 수 있습니다 (MS에서는 힌트가 아니라 다른 OS 공급 업체에서 힌트를 얻음).

Linux 커뮤니티의 일부 요소에서는 바이너리 전용 형식으로 배포 된 소프트웨어 (주어진 Linux 배포 이외의)에 대해 장기적으로 안정적인 플랫폼을 달성하는 것도 바람직하지 않은 것으로 간주됩니다. 두 플랫폼을 모두 비논리적 인 사용자로서, 그것이 좋은지 나쁜지 말하지 않습니다. 그것은 마치 같다.

많은 경우 (적어도 * nix 세계에서) 소스 코드는 가장 이식성이 뛰어난 소프트웨어 버전입니다. 소스가 있으면 공유 소프트웨어가 지원할 수있는 모든 플랫폼에서 작동 할 수 있습니다 (많은 경우 POSIX 호환을 의미 함). 바이너리를 해제하면 해당 바이너리가 릴리스 된 플랫폼 (소프트웨어 및 하드웨어 모두)과의 호환성 만 보장됩니다.

윈도우에서 바이너리는 소프트웨어를 공유하기에 가장 편리하고 이식 가능한 형태입니다. 소스 컴파일은 일반적인 Windows 소프트웨어 배포 모델의 일부가 아니기 때문에 Microsoft는 바이너리가 여러 버전의 OS에서 작동 할 수 있도록 오랫동안 노력해 왔습니다. http://www.joelonsoftware.com/articles/APIWar.html

대부분의 Linux 소프트웨어는 무료 소프트웨어입니다. 바이너리가 아닌 일부 컴파일 명령어와 함께 소스 코드를 배포하면 소스 코드를 컴파일하기 전에 검토하거나 편집 할 수 있습니다. 이런 식으로 프로그램이 실제로 무엇을하고 있으며 유해하지 않다는 것을 확신 할 수 있습니다.

개인적으로 프로그램의 실행 파일을 얻는 것을 좋아하지 않는 주된 이유는 먼저 소스 코드가 실제로 수행하는 작업을 확인하고 싶기 때문입니다 (주로 다른 사람들의 코드를 보는 것을 즐기기 때문에) 또한 악성 코드에 대한 소스 코드를 확인합니다.

많은 답변에 따르면 대부분의 경우 소프트웨어 가 컴파일 된 형식으로 배포됩니다. 이 가정에 동의합니다. 그럼에도 불구하고 소프트웨어를 소스로 배포하는 것이 컴파일 된 형식으로 배포하는 것보다 낫습니다.

나는 그것이 사실인지 확실하지 않지만, 인터넷의 시작 부분에서 네트워크 대역폭이 나쁘기 때문에 때로는 컴파일 된 형식보다 소스별로 소프트웨어를 배포하는 것이 더 빠를 수 있다고 상상합니다. 코드 소스는 일반 텍스트 일 ​​뿐이므로 컴파일 된 형식의 소프트웨어보다 작은 경우가 많습니다. 따라서 코드 소스가있는 소프트웨어를 배포하는 것이 사용자가 컴파일 할 수있는 경우이를 공유하는 더 좋은 방법 인 것 같습니다.

많은 다른 플랫폼에서 실행되는 많은 유닉스 시스템이 있다는 사실 외에도 Windows 소프트웨어는 하나의 Windows 버전과 하나의 플랫폼 (PC)에 대해서만 걱정해야하지만이 배포판에서 직면하는 문제를 고려하십시오. ).

PC 만 걱정하더라도 32 비트와 64 비트의 두 가지 아키텍처가 있습니다. 알다시피, 대다수의 Windows 소프트웨어는 단순히 64 비트를 무시하고 32 비트 소프트웨어 만 제공하므로 64 비트 시스템을 사용하는 경우 차선책의 소프트웨어가 남습니다. 그런 다음 라이브러리가 있습니다. 한 소프트웨어 공급 업체는 적절한 라이브러리가 설치되어 있지 않은 경우 프로그램을 실행하려고 할 때 이상한 오류가 발생하는 것을 원하지 않으므로 프로그램과 함께 라이브러리를 포함하기 만하면됩니다 (이 라이브러리가 이미있는 경우에도 다운로드가 더 커짐) ). 두 번째 프로그램은 동일한 작업을 수행하지만 다른 버전의 라이브러리를 사용합니다. 가장 좋은 경우, 프로그램 B에는 이전 버전과 호환되는 최신 버전의 라이브러리가 포함되어 있으므로 프로그램 B를 설치 한 경우프로그램 A는 작동하지만 역순으로 설치하면 이전 버전의 라이브러리가 남으므로 프로그램 B가 중단됩니다. 종종 있지만, 라이브러리 공급 업체는 변경 수 없습니다 당신이 처음이 중단됩니다에있는 두 개의 프로그램을 설치 주문 그래서 상관없이 호환 라이브러리의 이름을 변경 귀찮게하지 않습니다. 이것을 "dll hell"이라고합니다.

슬프게도, 이것을 피하기 위해, 대부분의 Windows 소프트웨어는 공유 디렉토리 대신 자신의 프로그램 디렉토리에 모든 라이브러리를 제공하는 데 의존했습니다. 첫 번째 장소에서 dll의 포인트와 더 많은 램과 디스크 공간을 사용하고 모든 중복 라이브러리를 다운로드하는 시간이 끝납니다.

그렇기 때문에 오픈 소스 소프트웨어가 소스 형식으로 게시되고 OS 공급 업체가 종속성 문제를 해결하고 라이브러리를 복제하지 않고도 실제로 필요한 사전 컴파일 된 바이너리 만 다운로드하는 패키지 관리자를 만들었습니다. 이것은 또한 많은 다른 플랫폼에서 실행되는 많은 다른 유닉스 시스템이 있다는 사실을 다룹니다.