서버 환경에서 deb에 비해 rpm의 장점은 무엇입니까? [폐쇄]

동일한 기본 문제를 해결하기 위해 deb 및 rpm 패키지 형식이 동시에 독립적으로 개발되었습니다. 대부분의 서버는 RHEL을 실행합니다. RHEL은 역사적으로 가장 인기 있는 배포판이었고 새로운 기술이 등장할 때 이를 수용하여 인내심을 가진 사람들이 자신이 이해하는 배포판에 전념할 수 있게 해주기 때문입니다. 엔터프라이즈 배포를 계획하고 있다면 RHEL/CentOS를 사용하는 것이 좋습니다. 해당 특정 배포에 대한 경험이 있는 사람을 찾고 직원을 배치하는 것이 더 쉬울 것이기 때문입니다(패키지 관리자 때문이 아닙니다). Canonical은 Ubuntu Enterprise를 제공하지만 기업으로서의 지원 인프라는 SuSE 또는 Red Hat만큼 개발되지 않았으며 여전히 엔터프라이즈 Linux에서는 틈새 기술입니다.

형식 자체는 서로 상의하지 않고 문제를 해결하려고 시도하며 한 형식에 존재하는 것이 다른 형식에도 존재한다는 점만 다릅니다. 왼쪽 핸들 국가와 오른쪽 핸들 국가와 약간 비슷합니다. 규칙을 일관되게 적용하는 한 둘 다 문제가 없습니다. 같은 이유로 두 솔루션을 통합할 인센티브가 거의 없습니다. 실제로는 문제가 되지 않습니다. 두 솔루션은 기능적으로 경쟁적이며 RPM 기반 배포판과 dpkg 기반 배포판 간의 광범위한 ABI 호환성을 보장하지 않습니다(즉, 패키지 관리자 소프트웨어를 공유해도 큰 이점이 없음을 의미).

apt-get관리자는 "and"와 같은 기호를 얼마나 선호하는지와 같은 개인적인 선호도를 가질 수 있지만 yum그게 전부입니다.

그러나 선택한 패키지에 관한 한 "엔터프라이즈"와 "커뮤니티" 스타일의 패키지 개발에 집중하고 싶지만 여전히 파일 형식은 아닙니다.

커뮤니티 포장에는 일반적으로 매우 느슨한 품질 보증 요구 사항이 있으며 커뮤니티 배포판은 모든 사람이 필요한 패키지를 찾을 수 있도록 모든 것을 제공하려는 강력한 인센티브를 가지고 있습니다. 엔터프라이즈 패키지는 안정성을 위해 주요 릴리스 내 ABI 호환성, 패키지 선택, 새로운 기능 도입 등을 보장합니다.

• 이것ABI 보증 - 애플리케이션 바이너리 인터페이스를 사용하면 시스템 업데이트를 수행하고 대체된 항목(라이브러리, 실행 파일 등)에 연결된 개별 프로그램을 간단히 다시 시작할 수 있습니다. 업스트림 수정 사항이 귀하에게 배송되는 버전과 관련된 경우 EL 배포 제공업체는 다른 어떤 것도 손상시키지 않는 방식으로 수정 사항을 배송 중인 버전으로 백포트하는 방법을 찾아야 합니다. 이는 또한 플랫폼 자체가 실행해야 할 ISV 제품에 대한 제품 인증을 얻는 데도 도움이 됩니다.

• 제한된 패키지 선택을 통해 패키지를 제공하는 회사는 문제에 대한 해결책을 찾을 때 볼 수 있는 소프트웨어에 대해 더 광범위한 품질 검사를 수행할 수 있습니다. 이는 패키지가 절망적으로 깨지지 않고 포함되기 전에 누군가에게 유용한 것처럼 보이면 되는 Fedora와는 대조적입니다.

• 새로운 기능에는 분명히 버그가 발생하며 지속적인 변경과 지원 중단이 발생할 수 있습니다. 지연된 채택 기능은 기업 사용자를 혼란으로부터 보호하는 EL 배포 방식이지만 ABI 호환성 요구 사항을 보장하는 데도 도움이 됩니다.

아마도 당신이 원하는 것보다 더 많은 정보가 있을 것입니다. 그러나 그게 전부입니다.

내 서버에 대한 Linux 배포판을 선택할 때 다음 두 가지 주요 요소를 고려합니다.

1. 서버가 특정 배포를 요구/권장하는 응용 프로그램 소프트웨어를 실행합니까? 일부 제품에는 지원되지 않는 배포판에서 실행 중인 경우 해당 공급업체의 지원이 필요한 경우 문제가 될 수 있는 지원 매트릭스가 있습니다.
2. 심각한 하드웨어 또는 운영 체제 오류가 발생한 경우 연중무휴 지원이 필요합니까? 그렇다면 저는 Red Hat에 대해 좋은 경험을 갖고 있으므로 Red Hat에 의지하고 있습니다. 그렇지 않다면 더 공격적인 업데이트 일정을 갖춘 다른 배포판(예: Debian 기반 배포판)을 선택합니다. 예를 들어,RHEL보통 뒤처져우분투PHP 버전에서.