Філософія Unix

Філософія Unix, заснована Кеном Томпсоном, є набором культурних норм і філософських підходів до мінімалістичної, модульної розробки програмного забезпечення. Вона ґрунтується на досвіді провідних розробників операційної системи Unix. Перші розробники Unix відіграли важливу роль у внесенні концепцій модульності та багаторазового використання у практику розробки програмного забезпечення, породивши рух «програмних інструментів». Згодом провідні розробники Unix (і програм, що працювали на ній) встановили набір норм для розробки програмного забезпечення. Ці норми стали настільки ж важливими та впливовими, як і сама технологія Unix та отримали назву «філософія Unix».

Філософія Unix наголошує на створенні простого, короткого, ясного, модульного та розширюваного коду, який може легко підтримуватися та перепрофілюватися іншими розробниками, а не тільки його творцями. Філософія Unix віддає перевагу композиційності на противагу монолітному дизайну.

Філософію Unix задокументував Дуглас Макілрой^[1] у журналі Bell System Technical 1978 року, яка складалась з 4 пунктів:^[2]

1. Зробіть так, щоб кожна програма добре виконувала одну справу. Щоб виконати нову роботу, створюйте нові програми, а не ускладнюйте старі, додаючи новий функціонал.
2. Очікуйте, що вихід кожної програми стане вхідним сигналом для іншої, поки невідомої, програми. Не захаращуйте вихідні дані сторонньою інформацією. Уникайте суворо стовпчастих або двійкових форматів введення. Не наполягайте на інтерактивному введенні.
3. Проектуйте та створюйте програмне забезпечення, навіть операційні системи, які потрібно випробувати завчасно, в ідеалі протягом кількох тижнів. Не соромтеся видаляти незграбні частини та відновлювати їх.
4. Не використовуйте некваліфіковану допомогу, щоб полегшити виконання завдання, краще скористайтесь інструментами, навіть якщо ви видалите деякі з них після того, як закінчите їх використання.

Пізніше Пітер Х. Салус узагальнив ці пункти у своїй книзі «A Quarter-Century of Unix» (1994):^[1]

1. Пишіть програми, які роблять одну справу і роблять її добре.
2. Пишіть програми з можливістю спільної роботи над ними.
3. Пишіть програми для обробки текстових потоків, тому що це універсальний інтерфейс.

У своїй статті 1974 року, яка була відзначена численними нагородами^[3], Річі та Томпсон цитують такі міркування щодо дизайну:^[4]

1. Спростіть написання, тестування та запуск програм.
2. Замініть пакетну обробку на інтерактивне використання.
3. Економність та елегантність дизайну через обмеження розмірів («порятунок через страждання»).
4. Самодостатня система: все програмне забезпечення Unix підтримується під Unix.

У своїй передмові до книги 1984 року «Середовище програмування UNIX» Брайан Керніган і Роб Пайк (обидва з Bell Labs) дають короткий опис дизайну Unix і філософії Unix:^[5]

Автори пишуть, що мета цієї книги — «повідомити про філософію програмування UNIX». ^[5]

У жовтні 1984 року Браян Керніган і Роб Пайк опублікували статтю під назвою « Проектування програм у середовищі UNIX» . У цій статті вони критикують збільшення програмних опцій і функцій, які є в деяких нових системах Unix, таких як 4.2BSD і System V, і пояснюють філософію програмних засобів Unix, кожен з яких виконує одну загальну функцію:^[6]

Автори порівнюють такі інструменти Unix, як cat, з більшими пакетами програм, які використовуються іншими системами.^[6]

Макілрой, тодішній керівник дослідницького центру Bell Labs Computing Sciences і винахідник конвеєра,^[7] узагальнив філософію Unix таким чином:^[1]

Крім цих тверджень, він також наголосив на простоті та мінімалізмі в програмуванні Unix:^[1]

Макілрой також критикував сучасний Linux за наявність програмного роздування, зауважуючи, що «закохані шанувальники нагодували Linux смаколиками до невтішного стану ожиріння».^[8] Він порівнює це з попереднім підходом, використаним у Bell Labs при розробці та перегляді Research Unix :^[9]

Як стверджує Макілрой, і, як правило, прийнято в Unix-спільноті, від програм Unix завжди очікується дотримання концепції DOTADIW («Do One Thing And Do It Well»). В Інтернеті мало інформації про абревіатуру DOTADIW, але вона докладно обговорювалась під час розробки нових операційних систем, особливо у спільноті Linux.

Патрік Фолькердінг, керівник проекту Slackware Linux, використав цей принцип проектування в критиці архітектури systemd, заявивши, що "спроба контролювати служби, розетки, пристрої, монтування тощо, все в межах одного демона стикається з концепцією Unix: «Робіть одну річ і робіть її добре».^[10]

У своїй книзі «Мистецтво програмування Unix», яка була вперше опублікована в 2003 році^[11] Ерік С. Реймонд, американський програміст і прихильник відкритих кодів, підсумовує філософію Unix як принцип KISS «keep it simple, stupid».^[12] Він наводить ряд правил проектування:^[1]

• Створюйте модульні програми
• Пишіть читабельні програми
• Використовуйте композицію
• Пишіть прості програми
• Пишіть невеликі програми
• Пишіть прозорі програми
• Пишіть надійні програми
• За потреби ускладнюйте дані, а не програму
• Зважайте на очікувані знання потенційних користувачів
• Уникайте непотрібного виведення
• Пишіть програми, які дають збій, так, щоб їх було легко діагностувати
• Цінуйте час розробника, а не час комп'ютера
• Пишіть абстрактні програми, які генерують код, замість написання коду вручну
• Пишіть гнучкі та відкриті програми
• Зробіть розширюваними програму та її протоколи.

У 1994 році Майк Ганкарц (член команди, яка розробила систему X Window), спирався на свій власний досвід роботи з Unix, а також на дискусії з колегами-програмістами та людьми в інших сферах, які залежали від Unix, щоб створити філософію UNIX, яка підсумовує це в дев'яти найважливіших принципах:

1. Чим менше — тим краще.
2. Кожна програма має добре виконувати лише одну роботу.
3. Створіть прототип якомога швидше.
4. Виберіть портативність, а не ефективність.
5. Зберігайте дані в плоских текстових файлах .
6. Використовуйте переваги програмного забезпечення на свою користь.
7. Використовуйте скрипти середовища, щоб збільшити портативність.
8. Уникайте неконтрольованих інтерфейсів користувача.
9. Зробіть кожну програму фільтром .

Річард П. Габріель припускає, що ключовою перевагою Unix було те, що він втілив філософію проектування, яку він назвав «чим гірше, тим краще», в якій простота інтерфейсу та реалізації важливіші за будь-які інші атрибути системи, включаючи коректність, послідовність і повноту. Габріель стверджує, що цей стиль дизайну має ключові еволюційні переваги, хоча він ставить під сумнів якість деяких результатів.

Наприклад, на початку Unix використовував монолітне ядро (це означає, що процеси користувача здійснювали системні виклики у стеку користувача). Якщо сигнал був доставлений процесу, коли він був заблокований під час тривалого введення-виведення в ядрі, що робити? Чи слід відкласти сигнал, можливо, на тривалий час (можливо, на невизначений термін), поки введення/виведення не буде завершено? Обробник сигналів не може бути виконаний, коли процес перебував у режимі ядра з конфіденційними даними ядра в стеку. Чи повинне ядро скасувати системний виклик і зберегти його для повторного відтворення та перезапуску пізніше, припускаючи, що обробник сигналу завершиться успішно?

У цих випадках Кен Томпсон і Денніс Річі віддавали перевагу простоті, а не досконалості. Система Unix іноді поверталася раніше після системного виклику з повідомленням про те, що вона нічого не зробила — «Перерваний системний виклик» або помилка номер 4 (EINTR) у сучасних системах. Звичайно, виклик був перерваний, щоб викликати обробника сигналів. Це могло статися лише для кількох тривалих системних викликів, таких як read(), write(), open() і select() . Позитивним є те, що це зробило систему введення-виводу в рази простішою для розробки та розуміння. Більшість користувацьких програм жодним чином від цього не постраждали б, оскільки вони не обробляли інших сигналів окрім SIGINT і відразу б зупинили виконання, якщо б хоч один був піднятий^[куди?]. Для кількох інших програм, таких як програмні середовища або текстові редактори, які реагують на натискання клавіш керування завданням, можна було б додати невеликі обгортки до системних викликів, щоб негайно повторити виклик, якщо виникла помилка EINTR.Таким чином, проблему було вирішено простим способом.

У статті 1981 року під назвою "Правда про Unix: інтерфейс користувача жахливий "^[13] опублікованій в Datamation, Дон Норман критикував філософію дизайну Unix за відсутність інтерфейсу користувача. Пишучи зі свого досвіду в когнітивній науці та з точки зору тодішньої філософії когнітивної інженерії, він зосередився на тому, як кінцеві користувачі розуміють і формують особисту когнітивну модель систем, або, у випадку з Unix, не можуть її зрозуміти, і як результат, стають причиною катастрофічних помилок (наприклад, втрата годинної роботи).

• Когнітивна інженерія
• Архітектура Unix
• Мінімалізм (обчислення)
• Розробка програмного забезпечення
• Принцип KISS
• Хакерська етика
• Список філософій розробки програмного забезпечення
• Все є файлом
• Гірше, тим краще

• Середовище програмування Unix, Брайан Керніган і Роб Пайк, 1984
• Розробка програми в середовищі UNIX — стаття Пайка і Кернігана, яка передувала книзі.
• Нотатки щодо програмування на C, Роб Пайк, 21 вересня 1989 року
• Чверть століття Unix, Пітер Х. Салус, Аддісон-Веслі, 31 травня 1994 р. (ISBN 0-201-54777-5)
• Філософія — з «Мистецтво програмування Unix», Ерік С. Реймонд, Аддісон-Веслі, 17 вересня 2003 р. (ISBN 0-13-142901-9)
• Остаточний звіт проекту Multics Kernel Design від М. Д. Шредера, Д. Д. Кларка, Дж. Х. Зальцера та Д. Х. Уеллса, 1977 р.
• Філософія UNIX, Майк Ганкарц,ISBN 1-55558-123-4

• Основи філософії Unix — Catb.org
• Філософія Unix: Короткий вступ — The Linux Information Project (LINFO)
• Чому філософія Unix все ще має значення