패키지가 아닌 관리 소프트웨어를 스스로 업데이트하지 않는 이유는 무엇입니까?

Question 1

이러한 유형의 기능을 구현하는 것은 "홈 호출" 측면(업데이트가 있는지 확인하기 위해)과 "현재 위치에서 업데이트" 측면 모두 매우 어렵습니다.

사용자 시스템에서 실행되는 소프트웨어는 최신 버전이 사용 가능한지 확인하는 방법을 알아야 합니다(즉, 네트워크를 사용할 다른 이유가 없을 수도 있는 응용 프로그램에 네트워크 코드를 추가하는 것을 의미합니다).
소프트웨어는 네트워크 조건에 관계없이 작동해야 합니다(분명히 완전히 오프라인일 때; 그러나 부분적으로 연결되어 있을 때 이상한 오류로 인해 실패해서는 안 됩니다).
최신 버전이 사용 가능한지 여부를 결정할 수 있는 방법이 필요합니다(사용자가 소스 저장소에서 빌드할 때 버전을 어떻게 비교합니까?).
서버 측이 있는 어딘가에 서버가 있어야 하며, 이를 개발해야 할 수도 있습니다.
서버에서나 중간자 공격을 통해 업데이트가 손상되지 않도록 해야 합니다. 따라서 TLS 및/또는 일종의 강력한 서명을 사용해야 합니다.
사용자가 사용할 수 있는 형식으로 업데이트를 제공해야 합니다. 처음에는 소스에서 빌드했을 수도 있지만 소프트웨어를 실행 중인 시스템에 소스에서 새 버전을 다시 빌드하는 데 필요한 모든 것이 있다는 보장은 없습니다. 따라서 (가능한 모든 대상 플랫폼에 대해) 바이너리를 제공해야 합니다.

(이것은 완전한 목록이 아닙니다.)

이것들은 모두 배포판에 의해 처리된 문제이므로 배포판이 문제를 처리하도록 하는 것이 더 쉽습니다. 게다가 다음과 같이쿠살라난다최신 버전의 소프트웨어를 실행하는 데 관심이 있는 사용자는 최소한 공지 메일링 목록을 팔로우할 만큼 관심을 갖고 있으므로 그런 방식으로 알림을 받게 될 것입니다.

고려해야 할 또 다른 측면은 상당수의 사람들이 어떤 방식으로든 집에 전화하는 데 사용하는 소프트웨어를 원하지 않는다는 것입니다. 일부 배포판은 어느 정도 길이가 있습니다.제거하다배포하는 소프트웨어에서 이를 수행하는 코드 또는 사용을 추적하는 데 사용할 수 있는 소프트웨어의 다른 부분(예를 들어웹에서 이미지, 글꼴 또는 CSS를 로드하는 문서). 다음의 모든 "개인정보 침해" 태그를 확인하세요.데비안의 린티안예를 들어.

이 모든 것은 업데이트 정보를 자체적으로 제공하는 데 필요한 메커니즘을 포함하는 소프트웨어가 그토록 적고 스스로 업그레이드할 수 있는 소프트웨어의 수가 더 적은 이유를 설명합니다.

"문제"를 해결하는 다른 방법이 있습니다. CI 시스템을 사용하는 소프트웨어 개발자는 일반적으로 이를 확장하여 일종의 소비 가능한 형태(패키지)로 "야간" 빌드를 제공할 수 있습니다. 관심 있는 사용자는 관심 있는 소프트웨어에 대한 업데이트 소스를 정기적으로 가져오기 위해 자체 빌드 시스템을 설정할 수 있습니다(이는 기업 환경에서 매우 일반적입니다). 또는 최신 소스에서 자체적으로 빌드되는 AUR 스타일 패키지를 설정할 수 있습니다.

Answer

이러한 유형의 기능을 구현하는 것은 "홈 호출" 측면(업데이트가 있는지 확인하기 위해)과 "현재 위치에서 업데이트" 측면 모두 매우 어렵습니다.

사용자 시스템에서 실행되는 소프트웨어는 최신 버전이 사용 가능한지 확인하는 방법을 알아야 합니다(즉, 네트워크를 사용할 다른 이유가 없을 수도 있는 응용 프로그램에 네트워크 코드를 추가하는 것을 의미합니다).
소프트웨어는 네트워크 조건에 관계없이 작동해야 합니다(분명히 완전히 오프라인일 때; 그러나 부분적으로 연결되어 있을 때 이상한 오류로 인해 실패해서는 안 됩니다).
최신 버전이 사용 가능한지 여부를 결정할 수 있는 방법이 필요합니다(사용자가 소스 저장소에서 빌드할 때 버전을 어떻게 비교합니까?).
서버 측이 있는 어딘가에 서버가 있어야 하며, 이를 개발해야 할 수도 있습니다.
서버에서나 중간자 공격을 통해 업데이트가 손상되지 않도록 해야 합니다. 따라서 TLS 및/또는 일종의 강력한 서명을 사용해야 합니다.
사용자가 사용할 수 있는 형식으로 업데이트를 제공해야 합니다. 처음에는 소스에서 빌드했을 수도 있지만 소프트웨어를 실행 중인 시스템에 소스에서 새 버전을 다시 빌드하는 데 필요한 모든 것이 있다는 보장은 없습니다. 따라서 (가능한 모든 대상 플랫폼에 대해) 바이너리를 제공해야 합니다.

(이것은 완전한 목록이 아닙니다.)

이것들은 모두 배포판에 의해 처리된 문제이므로 배포판이 문제를 처리하도록 하는 것이 더 쉽습니다. 게다가 다음과 같이쿠살라난다최신 버전의 소프트웨어를 실행하는 데 관심이 있는 사용자는 최소한 공지 메일링 목록을 팔로우할 만큼 관심을 갖고 있으므로 그런 방식으로 알림을 받게 될 것입니다.

고려해야 할 또 다른 측면은 상당수의 사람들이 어떤 방식으로든 집에 전화하는 데 사용하는 소프트웨어를 원하지 않는다는 것입니다. 일부 배포판은 어느 정도 길이가 있습니다.제거하다배포하는 소프트웨어에서 이를 수행하는 코드 또는 사용을 추적하는 데 사용할 수 있는 소프트웨어의 다른 부분(예를 들어웹에서 이미지, 글꼴 또는 CSS를 로드하는 문서). 다음의 모든 "개인정보 침해" 태그를 확인하세요.데비안의 린티안예를 들어.

이 모든 것은 업데이트 정보를 자체적으로 제공하는 데 필요한 메커니즘을 포함하는 소프트웨어가 그토록 적고 스스로 업그레이드할 수 있는 소프트웨어의 수가 더 적은 이유를 설명합니다.

"문제"를 해결하는 다른 방법이 있습니다. CI 시스템을 사용하는 소프트웨어 개발자는 일반적으로 이를 확장하여 일종의 소비 가능한 형태(패키지)로 "야간" 빌드를 제공할 수 있습니다. 관심 있는 사용자는 관심 있는 소프트웨어에 대한 업데이트 소스를 정기적으로 가져오기 위해 자체 빌드 시스템을 설정할 수 있습니다(이는 기업 환경에서 매우 일반적입니다). 또는 최신 소스에서 자체적으로 빌드되는 AUR 스타일 패키지를 설정할 수 있습니다.

Question 2

소프트웨어 자체에 일부 브라우저와 같은 업데이트를 확인하기 위해 "집에 전화"하는 기능이 없는 한동기화 중할 수 있을 것 같지만, 일반적으로 사용 가능한 최신 버전의 소프트웨어가 있다는 것을 사용자/관리자에게 자동으로 경고할 수 있는 메커니즘이 없습니다.

패키지 관리자를 사용하여 설치하는 패키지는 관심 있는 운영 체제에서 패키지를 최신 상태로 유지하고 기능을 유지하는 데 관심이 있는 사용자가 만듭니다.

예를 들어 포장하는 사람앤서블, 또는GNU 코어 유틸리티, 또는야쉬 쉘, 또는CMake또는 특정 Unix 시스템을 위한 수천 개의 소프트웨어 프로젝트 중 다른 프로젝트는 해당 프로젝트에 대한 관련 메일링 리스트에 가입되거나 소스 코드 저장소 또는 소스 배포 파일을 정기적으로 볼 수 있는 특수 도구를 가지고 있을 가능성이 높습니다(반드시 그런 것은 아님). . 새로운 릴리스에 대해 알게 되면 Unix의 패키징 절차에 따라 소프트웨어를 적절한 방식으로 다운로드, 컴파일, 테스트, 패치(등) 및 패키징합니다. 여기에는 빌드/패키징 프로세스에서 나타나는 비호환성 또는 기타 문제에 대해 업스트림(소프트웨어 개발자에게)과 다운스트림(소프트웨어 사용자에게) 모두에 대한 의사소통이 포함될 수 있습니다.

그런 다음 작업하는 Unix와 타사 패키지 배포 방식에 따라 저와 여러분 같은 사용자가 패키지 관리자를 사용하여 시스템을 업데이트할 수 있도록 패키지를 등록, 업로드 또는 커밋합니다.

예를 들어 나는GNU 스토우OpenBSD에서 사용할 수 있습니다(저는 이 소프트웨어의 "포트 관리자"입니다). 나는 때때로 GNU 웹 사이트에서 Stow의 현재 상태를 확인하고(자주 업데이트되지 않음) 새 버전을 발견하면 이를 설치하고 작동하는지 확인하고 OpenBSD 포트를 업데이트합니다. 내 개인 컴퓨터에서. 그런 다음 포트에 대한 패치가 포함된 OpenBSD 포트 목록을 이메일로 보냅니다(포트는 OpenBSD에서 Makefile 세트로 배포됩니다). 커밋 권한이 있는 사람은 OpenBSD 포트 CVS 트리에 커밋하기 전에 내 패치가 깔끔하게 적용되고 포트가 올바른지 확인합니다.

다음에 사용자가 CVS 트리를 업데이트하고 포트를 다시 빌드하거나 최종적으로 나타날 바이너리 포트를 다운로드할 때 GNU Stow 설치가 업데이트됩니다.그러나 GNU Stow는 자체적으로 새 버전이 사용 가능한지 여부를 인식하지 못합니다.이는 단순히 GNU Stow가 수행해야 하는 작업이 아닙니다. 자체 포함된 디렉터리 계층 구조에 타사 소프트웨어를 설치하는 데 사용하는 도구이며 다음과 같습니다.정말 이상해사용될 때마다 "콜 홈"을 시도한 경우( ls갑자기 실행하려면 네트워크 액세스가 필요한 것처럼 이상한 경우)

소프트웨어 업데이트를 자체적으로 수행하는 것은 시스템의 많은 구성 요소를 함께 테스트해야 하기 때문에 많은 경우 바람직하지 않을 수 있습니다. 필요한 인프라는 더 작은 패키지를 심각하게 부풀리게 하며, 노하우나 리소스가 부족한 개인이 일종의 고가용성 업데이트 서버를 실행하여 자동으로 최신 상태를 유지하는 소프트웨어를 개발하는 것은 불가능합니다.

Answer

소프트웨어 자체에 일부 브라우저와 같은 업데이트를 확인하기 위해 "집에 전화"하는 기능이 없는 한동기화 중할 수 있을 것 같지만, 일반적으로 사용 가능한 최신 버전의 소프트웨어가 있다는 것을 사용자/관리자에게 자동으로 경고할 수 있는 메커니즘이 없습니다.

패키지 관리자를 사용하여 설치하는 패키지는 관심 있는 운영 체제에서 패키지를 최신 상태로 유지하고 기능을 유지하는 데 관심이 있는 사용자가 만듭니다.

예를 들어 포장하는 사람앤서블, 또는GNU 코어 유틸리티, 또는야쉬 쉘, 또는CMake또는 특정 Unix 시스템을 위한 수천 개의 소프트웨어 프로젝트 중 다른 프로젝트는 해당 프로젝트에 대한 관련 메일링 리스트에 가입되거나 소스 코드 저장소 또는 소스 배포 파일을 정기적으로 볼 수 있는 특수 도구를 가지고 있을 가능성이 높습니다(반드시 그런 것은 아님). . 새로운 릴리스에 대해 알게 되면 Unix의 패키징 절차에 따라 소프트웨어를 적절한 방식으로 다운로드, 컴파일, 테스트, 패치(등) 및 패키징합니다. 여기에는 빌드/패키징 프로세스에서 나타나는 비호환성 또는 기타 문제에 대해 업스트림(소프트웨어 개발자에게)과 다운스트림(소프트웨어 사용자에게) 모두에 대한 의사소통이 포함될 수 있습니다.

그런 다음 작업하는 Unix와 타사 패키지 배포 방식에 따라 저와 여러분 같은 사용자가 패키지 관리자를 사용하여 시스템을 업데이트할 수 있도록 패키지를 등록, 업로드 또는 커밋합니다.

예를 들어 나는GNU 스토우OpenBSD에서 사용할 수 있습니다(저는 이 소프트웨어의 "포트 관리자"입니다). 나는 때때로 GNU 웹 사이트에서 Stow의 현재 상태를 확인하고(자주 업데이트되지 않음) 새 버전을 발견하면 이를 설치하고 작동하는지 확인하고 OpenBSD 포트를 업데이트합니다. 내 개인 컴퓨터에서. 그런 다음 포트에 대한 패치가 포함된 OpenBSD 포트 목록을 이메일로 보냅니다(포트는 OpenBSD에서 Makefile 세트로 배포됩니다). 커밋 권한이 있는 사람은 OpenBSD 포트 CVS 트리에 커밋하기 전에 내 패치가 깔끔하게 적용되고 포트가 올바른지 확인합니다.

다음에 사용자가 CVS 트리를 업데이트하고 포트를 다시 빌드하거나 최종적으로 나타날 바이너리 포트를 다운로드할 때 GNU Stow 설치가 업데이트됩니다.그러나 GNU Stow는 자체적으로 새 버전이 사용 가능한지 여부를 인식하지 못합니다.이는 단순히 GNU Stow가 수행해야 하는 작업이 아닙니다. 자체 포함된 디렉터리 계층 구조에 타사 소프트웨어를 설치하는 데 사용하는 도구이며 다음과 같습니다.정말 이상해사용될 때마다 "콜 홈"을 시도한 경우( ls갑자기 실행하려면 네트워크 액세스가 필요한 것처럼 이상한 경우)

소프트웨어 업데이트를 자체적으로 수행하는 것은 시스템의 많은 구성 요소를 함께 테스트해야 하기 때문에 많은 경우 바람직하지 않을 수 있습니다. 필요한 인프라는 더 작은 패키지를 심각하게 부풀리게 하며, 노하우나 리소스가 부족한 개인이 일종의 고가용성 업데이트 서버를 실행하여 자동으로 최신 상태를 유지하는 소프트웨어를 개발하는 것은 불가능합니다.

Question 3

예전에는 필요에 따라 새로운 소프트웨어를 설치하는 전문가가 컴퓨터를 관리했습니다.

시간이 지남에 따라 다양한 운영 체제는 소프트웨어를 수동으로 최신 상태로 유지해야 하는 부담을 덜기 위해 두 가지 전통을 발전시켰습니다.

Linux 및 대부분의 기타 최신 Unix 변형에서 운영 체제는 다음과 함께 제공됩니다.패키지 관리자. 대부분의 소프트웨어는 이 패키지 관리자를 통해 설치되며, 새 버전이 출시되면 패키지 관리자가 소프트웨어를 업데이트합니다.
Windows에는 최근까지 패키지 관리자가 제공되지 않았기 때문에 Windows 소프트웨어 공급자는 업데이트를 설치하기 위해 자체 코드를 갖는 습관을 갖게 되었습니다.

패키지 관리자 접근 방식은 특히 오픈 소스 세계에 매우 적합합니다. 오픈 소스 소프트웨어는 독립적으로 개발되고 함께 조립되는 수천 개의 패키지로 구성되기 때문입니다. 패키지를 조립할 때 많은 일이 잘못될 수 있으므로 대부분의 Linux 배포판은풀어 주다. 일부 배포판에는 유일한 일관성 확인이 소프트웨어 컴파일뿐인 "롤링 릴리스"가 있습니다. 다른 곳에서는 더 많은 테스트를 거쳐 1년에 한두 번, 심지어는 2년에 한 번만 새 릴리스를 제공합니다.

Windows 접근 방식에 비해 Linux 접근 방식의 장점은 소프트웨어 패키지가 서로 협력할 수 있다는 것입니다. 소프트웨어 A와 소프트웨어 B가 함께 무언가를 하려는 경우 파트너가 설치되었는지 여부를 모니터링하고, 업그레이드에 대처하고, 제거 시 부스러기를 남기지 않도록 주의해야 하기 때문에 Windows 접근 방식에서는 이것이 어렵습니다. 이는 특히 그렇습니다. Windows 소프트웨어가 사용하는 모든 라이브러리를 번들로 묶어야 하는 이유는 라이브러리에서 버그가 발견되면 해당 라이브러리를 사용하는 모든 소프트웨어를 업데이트해야 함을 의미합니다. 반면 Linux에서는 라이브러리를 사용하는 프로그램 수에 관계없이 라이브러리가 포함된 패키지만 업데이트하면 됩니다.

운영 체제는 소프트웨어 업데이트를 위한 메커니즘을 제공하므로 Linux 소프트웨어 작성자는 바퀴를 다시 만들 필요가 없습니다.

배포판에서 제공하는 것보다 최신 버전의 소프트웨어를 설치할 필요가 거의 없습니다. 최신 소프트웨어는 일반적으로 버그가 적지 않습니다. 심각한 버그(특히 보안 버그)가 발견되면 배포판에서 업데이트를 제공합니다. 일부 소프트웨어의 최신 버전은 사용자가 사용할 수 있는 새로운 기능이 있는 버전에만 유용합니다.

필요하지 않더라도 최신 버전의 소프트웨어를 갖고 싶다면 Debian Unstable 또는 Arch Linux와 같은 롤링 릴리스 배포판을 설치해야 합니다. Ubuntu, Mint 또는 Debian stable과 같은 일관된 릴리스가 포함된 배포판은 매주 시스템을 중단시키고 싶지 않은 사람들을 위한 것입니다.

Answer