У будь-яких взаємозалежних системах є в основному два варіанти. Абстракція та інтеграція. (Я навмисно не використовую технічні умови). За допомогою абстракції ви говорите, що, коли ви здійснюєте виклик в API, який, хоча код за API може змінюватися, результат завжди буде однаковим. Наприклад, коли нам зателефонують, fs.open()нам не важливо, чи це мережевий диск, SSD або жорсткий диск, ми завжди отримаємо відкритий дескриптор файлів, з яким ми можемо працювати. Завдяки "інтеграції" мета - забезпечити "найкращий" спосіб зробити щось, навіть якщо спосіб зміниться. Наприклад, відкриття файлу може відрізнятися для спільної мережі, ніж для файлу на диску. Обидва способи досить широко використовуються на сучасному робочому столі Linux.
З точки зору розробників, це питання "працює з будь-якою версією" або "працює з певною версією". Чудовим прикладом цього є OpenGL. Більшість ігор налаштовані на роботу з певною версією OpenGL. Не має значення, чи збираєте ви з джерела. Якщо гра була написана для використання OpenGL 1.1, а ви намагаєтеся змусити її працювати на 3.x, ви не будете добре провести час. На іншому кінці спектру, деякі дзвінки, очікується, незважаючи ні на що. Наприклад, я хочу зателефонувати, fs.open()я не хочу байдуже, на якій версії ядра я перебуваю. Я просто хочу дескриптор файлу.
Кожен спосіб має переваги. Інтеграція надає "новіші" функції за рахунок зворотної сумісності. У той час як абстракція забезпечує стабільність щодо "новіших" дзвінків. Хоча важливо зазначити, що це питання є пріоритетним, а не можливим.
З точки зору комунальних питань, без по-справжньому вагомих причин абстракція завжди краще в складній системі. Наприклад, уявіть, чи fs.open()працювали б інакше залежно від версії ядра. Тоді для простої бібліотеки взаємодії з файловою системою потрібно було б підтримувати кілька сотень різних «відкритих файлів» методів (або, ймовірно, блоків). Коли вийшла нова версія ядра, ви не зможете "оновити", вам доведеться протестувати кожен використаний програмний продукт. Ядро 6.2.2 (підроблене) може просто зламати ваш текстовий редактор.
Для деяких прикладів реального світу OSX, як правило, не піклується про порушення простору користувача. Вони спрямовані на частіше "інтеграцію" над "абстракцією". І при кожному великому оновленні ОС все ламається. Це не означає, що один спосіб краще, ніж інший. Це вибір та дизайнерське рішення.
Найголовніше, що екосистема Linux наповнена дивовижними проектами з відкритими джерелами, де люди або групи працюють над проектом у вільний час або тому, що інструмент корисний. Зважаючи на це, друге, коли воно перестане бути веселим і починає бути PIA, ці розробники підуть кудись ще.
Наприклад, я подав патч BuildNotify.py. Не тому, що я альтруїст, а тому, що я використовую інструмент, і мені хотілося функції. Це було легко, так що тут, мати патч. Якби це було складно або громіздко, я б не користувався BuildNotify.pyі знайшов би щось інше. Якби кожен раз, коли з'являлось оновлення ядра, мій текстовий редактор зламався, я просто використовував би іншу ОС. Мої внески до громади (хоч і невеликі) не продовжувались б і не існували тощо.
Отже, проектне рішення було прийнято до абстрактних системних викликів, так що коли я fs.open()це роблю, це просто працює. Це означає збереження fs.openдовго після fs.open2()здобуття популярності.
Історично це мета POSIX систем загалом. "Ось набір викликів і очікувані значення повернення. Ви з'ясуєте середину." Знову з міркувань портативності. Чому Лінус вирішив використовувати цю методологію, є внутрішньою для його мозку, і вам доведеться попросити його точно знати, чому. Якби я, проте, я вибрав би абстракцію над інтеграцією на складній системі.