기술 세계에는 누군가가 분산을 피하기 위해 다른 모든 것의 최고를 모으는 형식을 만들려고 할 때마다 목록에 새 형식 만 추가한다는 오래된 농담이 있습니다. 그 중 일부는 수정없이 모든 Linux 배포판에서 실행할 수있는 패키지 형식을 만들려는 노력과 함께 있습니다. 금세기까지 우리는 이미 세 살이었습니다.
Snap, Flatpak 및 Appimage. 기존 형식과의 차이점
기본 패키지 형식과 독립 실행 형 패키지 형식의 주요 차이점은 이전 버전이 운영 체제에 설치된 다른 프로그램과 종속성을 공유한다는 것입니다. 즉, 프로그램 Y에 종속성 1이 필요하고 해당 종속성이 필요한 프로그램 X에 의해 설치된 경우 해당 종속성은 다시 설치되지 않습니다.
별도의 형식으로 패키지 된 프로그램에는 작동하는 데 필요한 모든 종속성이 포함되어 있습니다. 즉, 의존성 1은 필요한 프로그램이 설치 될 때마다 설치됩니다.
두 번째 차이점은 기존 패키지 형식은 각 배포의 사양으로 빌드되어야한다는 것입니다.. 그렇기 때문에 Ubuntu는 Debian에서 파생 된 배포판이지만 첫 번째 저장소를 두 번째 저장소에서 사용할 수 없을만큼 차이가 중요합니다.
세 번째 차이점은 기존 패키지에 대한 종속성을 수정하면이를 필요로하는 다른 모든 패키지의 작동에 영향을 미칠 수 있습니다. 반면에 프로그램을 독립적 인 형식으로 수정해도 나머지 시스템에는 영향을 미치지 않습니다.
각 배포의 특성에 따라 패키지 관리자에서 독립적 인 형식으로 응용 프로그램을 설치하고이를 담당하는 관리자와 함께 업데이트를 자동화 할 수 있습니다.
Ubuntu에서 소프트웨어 센터를 사용하면 Snap과 같은 기존 형식으로 두 프로그램을 모두 설치할 수 있으며 후자를 선호합니다. GNOME Software Center (Ubuntu가 파생 된)를 허용하는 플러그인이 있지만이 배포판에서는 작동하지 않습니다.
Ubuntu Studio의 경우 KDE Neon 및 Manjaro가 두 형식 모두에서 작동하는 동안 Snap 패키지를 사용하는 옵션을 활성화 할 수 있습니다.
스냅
2014 년에 개발이 시작된 이래 최신 독립 형식입니다. 데스크톱 Linux 배포판뿐만 아니라 사물 인터넷, 모바일 장치 및 서버에도 사용할 수 있습니다. 에별도의 앱 스토어 생성이 가능하지만 현재는 Canonical에서 운영하는 앱 스토어가 하나뿐입니다. 스냅크래프트.
Snapcraft에는 가장 인기있는 오픈 소스 앱 모음이 있지만 그 강점은 사설 소프트웨어 개발자와 클라우드 서비스 제공 업체가 개발 한 프로그램입니다.
플랫 팩
Flatpak은 2015 년에 공식적으로 출시되었지만 xdg-app으로 알려진 또 다른 범용 형식 프로젝트의 연속입니다. 이 프로젝트는 루트 권한이 필요하지 않거나 시스템에 보안 위협이되지 않는 안전한 가상 샌드 박스에서 애플리케이션을 실행할 수 있어야합니다.
Flatpak은 데스크톱 배포에 중점을두고 있으며 응용 프로그램 저장소의 개념을 사용합니다. Flathub 가장 잘 알려진 것.
Flathub의 강점은 일반적으로 주요 오픈 소스 애플리케이션의 최신 버전이 있습니다.
Appimage
AppImage는 2004 년에 처음 출시 된 가장 오래된 독립형 패키지 형식입니다.
"One application-one file"의 패러다임을 따르는 최초의 형식. 즉, Appimage 파일을 다운로드 할 때마다 응용 프로그램과 기능에 필요한 모든 것을 다운로드합니다. 응용 프로그램을 사용하려면 실행 권한을 부여하고이를 식별하는 아이콘을 두 번 클릭하기 만하면됩니다.
Appimage는 앱 스토어 시스템을 사용하지 않지만 건초 웹 페이지 여기에서 사용 가능한 모든 타이틀 목록을 찾을 수 있습니다.
Appimage를 업데이트하려면 다음을 사용할 수 있습니다. 이 도구.
각각의 가상 유닛이 필요하기 때문에 앱을 설치할 때 스냅의 속도가 급격히 증가한다는 언급이 없었던 것이 그립습니다.
각각의 가상 유닛이 필요하기 때문에 앱을 설치할 때 스냅의 속도가 급격히 증가한다는 언급이 없었던 것이 그립습니다.
귀하의 의견에 감사드립니다. 명심 할게요.
개인적으로 저는 독립적 인 소프트웨어 패키징의 문제는 훨씬 더 깊은 갈등을 반영한 것이라고 생각합니다. 이는 다른 배포판에 의한 LSB 및 FSH 표준 준수 정도와 관련이 있습니다.
패키징의 기본 요소 중 하나는 소프트웨어의 위치와 위치와 구성 파일을 모두 유지하는 표준 라이브러리의 구현입니다. 따라서 라이브러리 충돌을 방지합니다. 다른 운영 체제에서 일반적이고 안타깝게도 표준을 준수하지 않아 소프트웨어를 유지 관리하고 업데이트하기가 어려워지는 것은 물론 한 배포판에서 다른 배포판으로 소프트웨어를 마이그레이션하는 것입니다. 구현의 표준 준수를 분석하지 않고 하우투에서 여러 번 수행 된 수동 컴파일의 나쁜 관행은 결국 시스템 관리자에게 큰 골칫거리가됩니다. 특히 누군가가 다른 이전 관리자가 설치 한 프로덕션 서버를 인수해야하는 경우.
어떤 식 으로든 독립적 인 패키징은 결국 그 철학에 기여하여 독립성 이상, 특정 형식 또는 회사에 대한 의존성을 촉진합니다. 플랫폼 마이그레이션을 거의 불가능한 작업으로 여러 번 만듭니다. 장기보다는 단기에 더 많이 생각합니다. 15 년 이상의 경력을 가진 진지한 관리자가 목격 할 수있는 상황입니다. 그리고 나는 의도적으로 그 수치를 말하는데, 그 기간에 충분한 배포가 통과되는 것을 보았을 것이기 때문에 조만간 프로젝트 나 서비스가 어떤 이유로 든 플랫폼에서 마이그레이션하도록 강요 될 것임을 깨닫게 될 것입니다. 프로젝트를 수행하는 동안 평가 프로세스에 거의 들어 가지 않는 상황. 마이그레이션하기 가장 쉬운 곳은 앞서 언급 한 표준을 가장 잘 준수하는 플랫폼입니다. 이러한 독립 패키지이기 때문에 이러한 표준에서 가장 먼 패키지입니다.
흥미로운 공헌에 대해 생각해 본 적이 없습니다.
AppImage 파일 업데이트 도구는 거의 쓸모가 없습니다. 내가 시도한 7 개의 AppImage 파일 (Inkscape, Olive, KSnip, MuseScore, OpenShot) 중 하나만 작업하려고 시도했으며 "확인 서명이 없습니다"로 끝나므로 업데이트하지 않았습니다. 즉, 어떤 용도로도 사용되지 않으며 참조를 제거 할 수 있습니다. 또한 몇 달 동안 업데이트되지 않았습니다.
댓글 주셔서 감사합니다