UNIX와 유사한 운영 체제에서는 얼마나 극단적인 수준의 결합이 허용됩니까? [폐쇄]

전반적으로 대안은 더 많은 노력을 기울이고 더 적은 것을 얻는 것이기 때문에 이는 의미가 있습니다.

거의 모든 컴퓨팅 시스템(아마도 모든 시스템, 기간)은 레이어로 구축됩니다. 모든 플랫폼은 그 아래에 있는 콘텐츠에 대해 가정을 합니다. lsC 표준 라이브러리가 있다고 가정합니다. 코어가 있을 것으로 추정됩니다. 컴퓨팅 하드웨어가 있을 것으로 가정됩니다. 안정적인 전압 등이 있다고 가정합니다.

다음과 같은 가정을 함으로써 코드를 더 빠르게 작성할 수 있습니다. 나는 더 많은 것을 할 수 있다. 나는 C 라이브러리, zip 라이브러리 또는 암호화 라이브러리를 번들링하는 데 관심이 없습니다. 다른 사람이 그럴 것입니다. 다른 사람들이 이러한 구성 요소를 개선하거나 업그레이드하기로 결정하면 나에게 확실히 이익이 됩니다. 이 코드를 공유하는 다른 모든 프로그램에서도 마찬가지입니다. 일관된 시스템에서는 더 빠르고, 더 깨끗하고, 더 작고, 더 좋습니다.

그러나 알다시피, 더 의존적입니다. 암호화가 호환되지 않는 방식으로 업그레이드되면 충돌이 발생하고 패키지 관리가 어려워집니다. 패키지 관리를 어렵게 만드는 종속성 유형을 실제로 분리하려면 구성 요소가 종속성을 인라인해야 합니다. 아래에 더 많은 스택을 포함해야 합니다. 그리고 이것이 바로 문제의 핵심입니다.종속성이 적은 프로그램을 만들려면 더 많은 것을 이해하는 빌드 시스템이 필요합니다.. 이곳은 개발자가 시간을 보내고 싶어하거나 보내야 하는 곳이 아닙니다.

당신은 현재의 곤경을 "극단적인 결합"이라고 표현합니다. 사람들은 모든 것을 독립형으로 만들려고 노력했습니다.스탈리, 모든 바이너리를 정적으로 링크된 상태로 유지하도록 설계된 Linux 배포판입니다. 그러나 극단적인 분리는 동일한 효과를 가질 수 있습니다. 즉, 각 프로그램에 대해 가상 머신이 있다고 상상해 보십시오.

우리 업계의 놀라운 성장은 주로 과거를 빠르게 기반으로 구축하는 능력에 기인합니다. 우리 모두는 문자 그대로나 비유적으로나 거인의 어깨 위에 서 있습니다. 어쩌면 미래에 우리는 거인의 키를 키우기 위한 첫 번째 단계로 거인을 먹을 수도 있습니다. 하지만 현재로서는 대략적으로 타협이 옳은 것 같습니다. 계속해서 등반하여 우리 아래의 거인들이 잘 지내도록 합시다.

커플링이 강한가요? 사실, "한 가지 일을 잘하라"는 원칙과 파이프라인 등을 사용하여 작동하는 애플리케이션을 구축하는 것은 느슨한 결합을 보여준다고 생각합니다. 예를 들어 ps axf | grep vim을 실행하면 ps와 grep이 매우 느슨하게 결합됩니다.

Unix 및 Unix 계열 운영 체제에는 "극단적인 결합"이 없습니다.

극단적인 디커플링(즉, 독립 소프트웨어)은 모든 것이 CLI에 있던 Unix 초기에는 표준이었습니다.

주목할 가치가 있는 유일한 결합 코드는 쉘 스크립트 자체입니다. 왜냐하면 쉘 스크립트가 사용 가능하려면 호출하는 명령이 필요하기 때문입니다. 이러한 명령의 대부분은 기본 설치의 일부이므로 문제가 되지 않습니다.

대규모 라이브러리(예: 그래픽 환경, X11, 위젯 툴킷 등)를 도입하면 단일 실행 파일에 필요한 모든 라이브러리를 포함하는 것이 저장 공간(디스크 공간이 희박할 때 실행 파일이 커짐)과 메모리 사용량( 동일한 코드가 많이 반복되고 RAM이 부족한 경우). 그런 다음 이러한 제한을 극복하기 위해 공유 개체가 도입되었습니다.

이제 우리는 일반적으로 필수 라이브러리 및 유사한 파일로 인해 애플리케이션의 종속성 트리가 상당히 복잡해질 수 있는 상황에 직면해 있습니다. 개발자가 핵심 애플리케이션에 집중하고 기존 애플리케이션에 나머지 애플리케이션을 사용할 수 있도록 하는 것입니다. 즉, 바퀴를 재발명하지 마십시오.

새 버전이 이전 버전과의 호환성을 깨뜨리고 이름 충돌(동일한 컴퓨터에 함께 설치된 소프트웨어는 제외)으로 인해 발생하는 문제를 제외하고는 이로 인해 큰 문제가 발생하지 않습니다. 좋은 설계와 표준을 사용하면 두 가지 문제를 모두 피할 수 있습니다.