Linux 실행 파일 형식과 소프트웨어 배포 패키지를 이해할 수 없습니다. Linux 자체는 다양한 배포판으로 제공되며 각 패키지는 각 배포판에 대해 개별적으로 컴파일되는 것처럼 보입니다. 왜 이런거야? 특정 "패키지"는 서로 다른 배포판에 설치되도록 설계되었지만 소프트웨어의 실행 파일 형식이 다르다는 것을 알고 있습니다.
또한 많은 Linux 사용자가 GUI 버전보다 명령 프롬프트 버전의 애플리케이션을 선호하는 이유는 무엇입니까? 작은 설치 공간이 필요하다는 점은 이해하지만 GUI 애플리케이션이라도 올바르게 코딩하면 작은 설치 공간을 가질 수 있습니다.
답변1
패키지 관리자 및 종속성
대부분의 Linux 배포판은 소프트웨어 설치 및 제거를 위해 패키지 관리자를 사용합니다. 패키지 관리자는 (거의) 모든 소프트웨어를 다운로드할 수 있는 중앙 저장소를 사용하는 기능, 소프트웨어를 응집력 있는 그룹으로 설치할 수 있는 번들로 구성, 주요 이점: 패키지 종속성 처리 및 추적과 같은 이점을 제공합니다. 제거할 수 있도록 변경됩니다.
일부 소프트웨어에는 소프트웨어에서 다시 구현될 경우 중복되는 작업을 수행하기 위해 특정 라이브러리나 기타 프로그램이 필요할 수 있습니다. 패키지를 사용하면 이러한 종속성을 표현할 수 있습니다.
차이점: 패키지 형식 및 전략
다양한 패키지 관리자가 있습니다. 각각은 기존 것이 누군가의 요구를 충족시키지 못했기 때문에 만들어졌습니다. 각 패키지 관리자에는 고유한 패키지 형식이 필요합니다.
또한 배포판마다 포함된 소프트웨어에 대한 요구 사항이 다릅니다. 소스 코드에서 기계 실행 파일로 컴파일할 때 제공되는 옵션에 따라 다양한 기능을 가질 수 있는 소프트웨어가 많이 있습니다. 일부 배포판은 완전한 기능 세트와 풍부한 경험을 제공하기를 원하는 반면, 다른 배포판에서는 가능한 가장 간소하고 단순한 경험을 제공하기를 원하며 그 사이에는 모든 것이 있습니다. 또한 배포판에서는 디렉터리 구조의 형식을 다르게 지정하거나 다른 초기화 시스템을 사용하기로 결정할 수도 있습니다. 그들은 소프트웨어를 다르게 번들링하기로 결정할 수도 있습니다. 두 가지 다른 배포판에 "dev-utils"라는 패키지가 있을 수 있지만 한 버전에는 이를 포함 yacc
하고 다른 버전에는 포함하지 않습니다. 이러한 다양한 요구 사항으로 인해 배포판은 소프트웨어를 다양한 방식으로 컴파일하도록 선택합니다.
이것이 바로 패키지 관리자가 올바른 형식의 패키지를 가지고 있더라도 해당 패키지가 다른 배포용이라면 작동하지 않을 수 있는 이유입니다. 예를 들어 패키지는 yacc
설치에 따라 달라질 수 있으며 "dev-utils" 패키지를 요구하여 이러한 종속성을 표현하지만 "dev-utils"에는 해당 패키지가 포함되어 있지 않습니다 yacc
. 이제 종속성을 충족하지 않는 패키지가 설치됩니다.
이것은 문제가 되지 않습니다.
Linux 배포판의 중요한 부분은 중앙 소프트웨어 저장소를 유지 관리하는 것입니다. 배포판은 이 모든 것을 유지 관리합니다. 이는 실제로 소프트웨어 설치를 매우 쉽게 만듭니다. 일반적으로 패키지 관리자를 사용하여 일부 패키지를 검색하고 선택한 다음 패키지를 설치하도록 지시하면 나머지는 자동으로 처리됩니다. Windows 소프트웨어 설치 프로세스에는 타사 웹 사이트에서 소프트웨어를 찾고, 적절한 다운로드 링크를 찾고, 다운로드하고, 바이러스를 확인하고, 설치 프로그램을 실행하는 과정이 포함되며, 그런 다음 관련 없는 질문을 많이 합니다. 이 중 어느 것도 Linux에서는 표준이 아닙니다.
저장소에는 다음을 포함할 수 없습니다.모든 것
이제 어떤 경우에는 필요한 소프트웨어가 배포 저장소에 없을 수도 있습니다. 소프트웨어 저장소에서 제공하는 패키지는 배포판의 특징 중 하나입니다. 배포 저장소에서 필요한 소프트웨어를 찾을 수 없는 경우 세 가지 가능한 경로가 있습니다(실제로는 두 가지 경로와 실제로 문제를 일으키는 한 가지 방법).
커뮤니티 저장소
많은 배포판에는 배포판과 관련이 없는 사람들이 관리하는 비공식 저장소가 있습니다. Ubuntu는 이를 PPA라고 부르고 Fedora는 Fedora People Repositories라고 부릅니다. Arch Linux에는 타사에 대한 특정 이름이 없습니다.저장소이지만 패키지 "레시피" 모음인 AUR이 있습니다(참고: AUR은 하나만 있음). 패키지가 작동하지 않으면 제거하기 쉽기 때문에 먼저 이러한 소스 중 하나에서 패키지를 설치해 볼 수 있습니다.
소스 코드에서 컴파일
필요한 내용이 포함된 비공식 저장소를 찾을 수 없다면 소스에서 컴파일하는 것이 어렵지 않습니다. 배포용 개발 패키지를 설치해야 합니다. 여기에는 일반적으로 소프트웨어 구축에 필요한 컴파일러, 링커, 파서 및 기타 도구와 같은 기본 사항이 포함됩니다. 그런 다음 프로젝트의 소스 코드를 찾습니다(거의 항상 .tgz
또는 .tbz
("tarball"이라고 함) 에 tar -xf filename.tgz
패키지되어 있음). 어딘가에 자체 디렉터리에 다운로드하고 압축을 푼다(일반적으로 해당 디렉터리에 생성됨). 이름이 있는 파일 README
이거나 INSTALL
존재하는 경우 계속해서 읽고 다음 몇 단계는 명령줄에서 수행되며 존재하는 경우 를 통해 실행합니다 ls
. 이는 일반적으로 몇 가지 테스트를 실행합니다. 배포판이 어떻게 설정되어 있는지 확인하고 소프트웨어를 컴파일하는 데 필요한 도구가 있는지 확인하십시오. 다음 단계는 실제로 소프트웨어를 컴파일하는 것입니다. 이는 소프트웨어의 크기에 따라 다릅니다. 컴파일이 완료되면 소프트웨어를 실행할 수 있습니다. 여기에는 컴파일된 제품을 파일 시스템의 적절한 위치에 복사하는 작업이 포함되며, 그 후에 소프트웨어를 사용할 수 있습니다.configure
./configure
make
make install
긴 섹션이지만 아래에 요약되어 있습니다."readme, ./configure, make, make install". 이것이 기억해야 할 관례입니다.
다른 배포판의 패키지 설치(이렇게 하지 마세요)
나는 이것을 나열한다.예그리고 대안이 있지만 거의 확실하게 잘 끝나지 않을 것입니다. 다른 배포판의 패키지를 설치하는 것이 가능하며 그렇게 하고 싶을 수도 있습니다. 글쎄요. 시스템을 잘 알기 전까지는 이 작업을 수행하지 마십시오. 사실, 가능하더라도 이 작업을 수행하는 방법을 보여주기 위해 여기에는 어떤 명령도 넣지 않겠습니다. 이것이 유일한 옵션인 것처럼 보이는 지점에 도달하면 패키지 관리자를 사용하여 패키지를 설치하지 말고 패키지에서 내용을 꺼내서 무엇에 대한 메모와 함께 수동으로 시스템에 넣으십시오. 필요하면 취소할 수 있도록 했습니다.
명령줄 비트
어떤 사람들은 이점 때문에 명령줄을 선호합니다. 이는 다음 세 가지로 요약될 수 있습니다.
- 자동화가 용이함
- 속도(GUI의 모든 곳을 클릭하는 것과 비교)
- 표현력
그 중 가장 중요한 것은 표현력입니다. 그래픽 인터페이스에서는 할 수 없지만 명령줄에서는 할 수 있는 일이 있습니다.
마지막으로 명령줄 지침은 "여기를 클릭하고 저기를 클릭하세요." 유형의 지침을 제공하는 것보다 올바른 정보를 전달하는 것이 더 쉽기 때문에 유용한 포럼(예: 이 포럼)에서 종종 제공됩니다.
답변2
답변이 길어서 죄송합니다. 빠르고 더러운 것을 원한다면 요약을 읽으십시오.
일반화하다
- 실행파일 형식은 동일합니다.
- 패키지 프로그램이 호환되더라도 호환되지 않는 다양한 패키지 관리자가 있습니다. (패키지는 파일과 같은 설치 프로그램 파일로 생각할 수 있습니다
.msi
). - 기본적으로 배포판/버전마다 핵심 라이브러리 버전이 다르며 일관성과 안정성을 위해 이러한 버전에 대해 애플리케이션을 구축해야 합니다. (Dll 지옥의 Linux 버전).
- 배포판마다 이를 약간 다르게 처리하므로 경우에 따라 호환성 문제가 발생할 수 있습니다.
- 명령줄은 더 빠를 수 있으며 Unix 명령줄은 Windows 명령줄보다 훨씬 좋습니다.
패키지 관리자
먼저 패키지 관리자입니다. 패키지 관리자의 주요 목적은 설치된 패키지와 해당 패키지를 구성하는 파일의 데이터베이스를 유지 관리하는 것입니다.
패키지 관리자를 사용하면 패키지를 쉽게 설치할 수 있고, 패키지를 쉽게 제거할 수도 있습니다. 또한 패키지는 시스템 일관성을 유지하기 위해 설치/제거 시 실행해야 할 다양한 스크립트를 지정할 수 있습니다(예: 특정 하위 시스템 관련 데이터베이스에 패키지 등록).
다양한 패키지 관리자
다양한 장점과 단점을 지닌 다양한 패키지 관리자가 있습니다. 예에는 rpm 및 debian 패키지 관리자(.deb 파일)가 포함되지만 다른 것들도 있습니다. 이러한 패키지 관리자는 분명히 다른 형식을 요구하므로 호환되지 않습니다.
다양한 배포판 또는 버전
대부분의 Linux 배포판은 오픈 소스이므로 Windows 시스템보다 코드 재사용이 더 많습니다. 애플리케이션은 기능의 다양한 부분을 구현하기 위해 많은 라이브러리를 사용할 수 있습니다. 라이브러리 자체에서도 이 작업을 수행하는 경우가 많으며 때로는 동일한 라이브러리에서도 수행됩니다.
안타깝게도 라이브러리는 다양한 버전으로 존재하며 그 중 일부는 호환되지 않습니다(특히 미리 컴파일된 실행 파일의 바이너리 호환성). Unix 시스템에서는 여러 버전이 잘 공존할 수 있지만(이 관점에서 볼 때 dll 지옥을 줄임) 대부분의 경우 하나의 실행 프로그램에서 두 가지 다른 버전의 라이브러리를 사용하면 충돌이 발생합니다.
결과적으로 바이너리 배포판은 다양한 핵심 패키지의 새 버전을 계속 사용하기 위해 자체적으로 업그레이드되는 경우가 많습니다(다른 경우에는 대규모 업데이트를 수행해야 함).
다른 다른 파일
또한 Distro는 특정 파일의 위치와 구성 관리 방법이 다릅니다. 패키지에 영향을 미칠 수 있는 패키지에 따라 다릅니다.
명령줄
Unix는 주로 워크스테이션이자 서버 운영 체제입니다. 이는 전문 시스템 관리자를 염두에 두고 설계되었음을 의미합니다. 자동화는 시스템 관리 도구 상자의 중요한 부분이며 쉘 스크립팅이 이를 수행하는 방법입니다. 그래픽 파일 관리자에서 파일 이름 앞에 0부터 1000까지 추가해 보십시오.
관리자는 여러 컴퓨터를 관리하는 경우가 많기 때문에 여러 시스템에서 동일한 작업을 수행해야 합니다. SSH와 같은 도구를 사용하면 여러 시스템에서 동시에 작업을 수행한 다음 컴퓨터가 작업을 마칠 때까지 기다리는 것이 매우 쉽습니다.
정확한 사양, 자동화 및 반복성은 작업 관리를 위한 그래픽 도구보다 명령줄을 더 유망하게 만듭니다. 또한 Unix에 사용할 수 있는 다양한 셸이 있으며, 이번 경쟁을 통해 Windows 명령 프롬프트와 거의 비교할 수 없는 매우 강력한 셸이 탄생했습니다.
실제로 Microsoft는 이를 잘 이해하고 최신 버전의 Windows Server를 주로 관리하는 명령줄의 대안으로 PowerShell을 제공했습니다.
답변3
실행 파일 형식은 배포판 전체에서 동일하지만 실행 파일이 제대로 작동하려면 추가 기본 소프트웨어가 필요할 수 있습니다. Redhat 기반 배포판을 살펴보면 설치 제품이 특정 소프트웨어에 대한 모든 요구 사항을 포함하는 rpm이며 요구 사항이 충족되지 않으면 소프트웨어가 기본적으로 설치되지 않는다는 것을 알 수 있습니다. ( yum
일부 Redhat 기반 버전의 대안 rpm
으로 사용하세요.) 정의에 따르면 GUI는 명령 프롬프트 인터페이스보다 훨씬 더 큰 공간을 차지해야 합니다. UNIX의 기본 아이디어는 주어진 작업이 최대한 효율적으로 작동하도록 모든 것을 단순화하는 것입니다. 이것이 단일 작업을 수행하는 유틸리티가 너무 많고, 해당 작업의 출력을 다른 작업의 입력에 연결하여 다른 작업을 수행할 수 있는 이유입니다.
답변4
아치. 또는 전체적으로 개발된 FreeBSD입니다. (RHEL, SLES 및 유사한 시스템이 전체적으로 지원됩니다.)
노트북용 : 민트색상
사용 가능한 해킹 가능성: Arch.
가학적인 해커: 제누.
흥미로운 해킹 가능성: LFS.
지원 가능성(서버): RHEL, Ubuntu LTS, FreeBSD(Linux와 다름).