Trong bất kỳ hệ thống phụ thuộc lẫn nhau, về cơ bản có hai sự lựa chọn. Trừu tượng và hội nhập. (Tôi cố tình không sử dụng thuật ngữ kỹ thuật). Với Trừu tượng hóa, bạn đang nói rằng khi bạn thực hiện cuộc gọi tới API, trong khi mã đằng sau API có thể thay đổi, kết quả sẽ luôn giống nhau. Ví dụ: khi chúng tôi gọi, fs.open()chúng tôi không quan tâm đó là ổ đĩa mạng, ổ SSD hay ổ cứng, chúng tôi sẽ luôn nhận được một bộ mô tả tệp mở mà chúng tôi có thể làm được. Với "tích hợp", mục tiêu là cung cấp cách "tốt nhất" để thực hiện một việc, ngay cả khi cách thay đổi. Ví dụ: mở tệp có thể khác đối với chia sẻ mạng so với tệp trên đĩa. Cả hai cách đều được sử dụng khá nhiều trong máy tính để bàn Linux hiện đại.
Từ quan điểm của các nhà phát triển, đó là một câu hỏi "hoạt động với bất kỳ phiên bản nào" hoặc "hoạt động với một phiên bản cụ thể". Một ví dụ tuyệt vời về điều này là OpenGL. Hầu hết các trò chơi được thiết lập để hoạt động với một phiên bản cụ thể của OpenGL. Không thành vấn đề nếu bạn biên dịch từ nguồn. Nếu trò chơi được viết để sử dụng OpenGL 1.1 và bạn đang cố gắng để nó chạy trên 3.x, bạn sẽ không có thời gian tốt. Ở phía bên kia của quang phổ, một số cuộc gọi, dự kiến sẽ hoạt động bất kể điều gì. Ví dụ, tôi muốn gọi fs.open()tôi không muốn quan tâm tôi đang dùng phiên bản kernel nào. Tôi chỉ muốn một mô tả tập tin.
Có những lợi ích cho mỗi cách. Tích hợp cung cấp các tính năng "mới hơn" với chi phí tương thích ngược. Trong khi trừu tượng hóa cung cấp sự ổn định đối với các cuộc gọi "mới hơn". Mặc dù điều quan trọng cần lưu ý đó là vấn đề ưu tiên, không phải là khả năng.
Từ quan điểm chung, không có lý do thực sự tốt, sự trừu tượng luôn tốt hơn trong một hệ thống phức tạp. Ví dụ, hãy tưởng tượng nếu fs.open()làm việc khác nhau tùy thuộc vào phiên bản kernel. Sau đó, một thư viện tương tác hệ thống tệp đơn giản sẽ cần duy trì hàng trăm phương thức "mở tệp" khác nhau (hoặc có thể là các khối). Khi một phiên bản kernel mới xuất hiện, bạn sẽ không thể "nâng cấp", bạn sẽ phải kiểm tra từng phần mềm bạn đã sử dụng. Kernel 6.2.2 (giả) có thể phá vỡ trình soạn thảo văn bản của bạn.
Đối với một số ví dụ trong thế giới thực, OSX có xu hướng không quan tâm đến việc phá vỡ Không gian người dùng. Họ nhắm đến "tích hợp" hơn "trừu tượng" thường xuyên hơn. Và tại mỗi bản cập nhật hệ điều hành lớn, mọi thứ đều bị phá vỡ. Điều đó không có nghĩa là cách này tốt hơn cách khác. Đó là một sự lựa chọn và quyết định thiết kế.
Quan trọng nhất, hệ sinh thái Linux chứa đầy các dự án mã nguồn mở tuyệt vời, nơi mọi người hoặc các nhóm làm việc với dự án trong thời gian rảnh hoặc vì công cụ này hữu ích. Với ý nghĩ đó, thứ hai nó ngừng vui vẻ và bắt đầu là một PIA, những nhà phát triển đó sẽ đi đến một nơi khác.
Ví dụ, tôi đã gửi một bản vá cho BuildNotify.py. Không phải vì tôi vị tha, mà vì tôi sử dụng công cụ này và tôi muốn có một tính năng. Thật dễ dàng, vì vậy ở đây, có một bản vá. Nếu nó phức tạp hoặc cồng kềnh, tôi sẽ không sử dụng BuildNotify.pyvà tôi sẽ tìm thứ khác. Nếu mỗi lần cập nhật kernel xuất hiện trình soạn thảo văn bản của tôi bị hỏng, tôi sẽ chỉ sử dụng một hệ điều hành khác. Những đóng góp của tôi cho cộng đồng (dù nhỏ) sẽ không tiếp tục hoặc tồn tại, v.v.
Vì vậy, quyết định thiết kế được đưa ra cho các cuộc gọi hệ thống trừu tượng, để khi tôi thực hiện fs.open()nó chỉ hoạt động. Điều đó có nghĩa là duy trì fs.openlâu sau khi fs.open2()nổi tiếng.
Trong lịch sử, đây là mục tiêu của các hệ thống POSIX nói chung. "Đây là một tập hợp các cuộc gọi và giá trị trả về dự kiến, bạn tìm ra giữa." Một lần nữa vì lý do tính di động. Tại sao Linus chọn sử dụng phương pháp đó là nội bộ trong não của anh ta, và bạn sẽ phải hỏi anh ta để biết chính xác tại sao. Tuy nhiên, nếu là tôi, tôi sẽ chọn sự trừu tượng hóa tích hợp trên một hệ thống phức tạp.