상호 의존적 시스템에는 기본적으로 두 가지 선택이 있습니다. 추상화 및 통합. (의도적으로 기술 용어를 사용하지 않습니다). Abstraction을 사용하면 API에 대한 코드가 변경 될 수 있지만 결과는 항상 동일하다는 API를 호출 할 수 있습니다. 예를 들어 전화를 걸 때 fs.open()네트워크 드라이브, SSD 또는 하드 드라이브인지는 신경 쓰지 않고 항상 열려있는 파일 설명자를 얻을 수 있습니다. “통합”의 목표는 방법이 바뀌더라도 일을하는 “최상의”방법을 제공하는 것입니다. 예를 들어, 파일을 여는 것은 디스크의 파일과 네트워크 공유의 경우 다를 수 있습니다. 두 가지 방법 모두 최신 Linux 데스크탑에서 광범위하게 사용됩니다.

개발자 관점에서는 “모든 버전에서 작동”또는 “특정 버전에서 작동”이라는 문제입니다. 이에 대한 좋은 예는 OpenGL입니다. 대부분의 게임은 특정 버전의 OpenGL에서 작동하도록 설정되어 있습니다. 소스에서 컴파일하는 것은 중요하지 않습니다. 게임이 OpenGL 1.1을 사용하도록 작성되었고 3.x에서 실행하려고한다면 좋은 시간이 없을 것입니다. 스펙트럼의 다른 쪽 끝에서 일부 호출은 무엇이든 작동 할 것으로 예상됩니다. 예를 들어, 나는 fs.open()어떤 커널 버전을 사용하고 싶지는 않지만 전화 하고 싶습니다. 파일 설명자가 필요합니다.

각 방법에는 이점이 있습니다. 통합은 이전 버전과의 호환성을 유지하면서 “최신”기능을 제공합니다. 추상화는 “최신”호출보다 안정성을 제공합니다. 중요하지는 않지만 중요하지는 않습니다.

공동의 관점에서 볼 때, 정말 좋은 이유가 없다면 복잡한 시스템에서는 추상화가 항상 더 좋습니다. 예를 들어 fs.open()커널 버전에 따라 다르게 작동 하는지 상상해보십시오 . 그런 다음 간단한 파일 시스템 상호 작용 라이브러리는 수백 가지의 “열린 파일”방법 (또는 아마도 블록)을 유지해야합니다. 새로운 커널 버전이 나오면 “업그레이드”할 수 없으며 사용한 모든 소프트웨어를 테스트해야합니다. 커널 6.2.2 (가짜)는 텍스트 편집기를 손상시킬 수 있습니다.

일부 실제 사례에서 OSX는 사용자 공간을 깨뜨리는 것에 신경 쓰지 않는 경향이 있습니다. 그들은 더 자주 “추상”보다 “통합”을 목표로합니다. 그리고 모든 주요 OS 업데이트에서 문제가 발생합니다. 한 가지 방법이 다른 방법보다 낫다는 것은 아닙니다. 선택과 디자인 결정입니다.

가장 중요한 것은 Linux 에코 시스템은 사람들이나 그룹이 자유 시간에 프로젝트를 수행하거나 도구가 유용하기 때문에 멋진 오픈 소스 프로젝트로 채워져 있다는 것입니다. 이를 염두에두고 재미를 멈추고 PIA가되기 시작하면 개발자들은 다른 곳으로 갈 것입니다.

예를 들어,에 패치를 제출했습니다 BuildNotify.py. 이타 적이기 때문이 아니라 도구를 사용하기 때문에 기능을 원했습니다. 쉬웠으므로 여기 패치가 있습니다. 복잡하거나 성 BuildNotify.py가시면 사용하지 않고 다른 것을 찾을 것입니다. 커널 업데이트가 텍스트 편집기에서 나올 때마다 다른 OS를 사용합니다. 커뮤니티에 대한 나의 기여는 (작지만 작음) 계속되거나 존재하지 않을 것입니다.

따라서 디자인 결정은 시스템 호출을 추상화하여 결정했을 때 fs.open()작동합니다. 그것은 인기 fs.open를 fs.open2()얻은 후에 오래 유지하는 것을 의미합니다 .

역사적으로 이것은 POSIX 시스템의 목표입니다. “여기에는 일련의 호출과 예상 반환 값이 있습니다. 중간을 찾으십시오.” 이식성의 이유로 다시 한 번. Linus가이 방법론을 사용하기로 선택한 이유는 그의 뇌 내부에 있으며, 그 이유를 정확히 알아야합니다. 그러나 그것이 저라면 복잡한 시스템의 통합보다 추상화를 선택합니다.

답변