При цьому кожен з них може виконувати безліч різних обчислювальних процесів, які використовуватимуть ресурси саме цього комп'ютера.

Друга колосальна заслуга Unix – у її мультиплатформенності. Ядро системи розроблено таким чином, що його можна легко пристосувати практично під будь-який мікропроцесор.

Unix має інші характерні особливості:

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

Застосування

В даний час Unix-системи поширені в основному серед серверів, а також як вбудовані системи для різного обладнання, включаючи смартфони. Також Unix-системи домінують на суперкомп'ютерах, зокрема на 100% суперкомп'ютерів із рейтингу TOP500 встановлена ​​ОС Linux.

Перші версії Unix були написані на асемблері і не мали вбудованого компілятора з високою мовою . Приблизно в 1969 році Кен Томпсон за сприяння Денніса Рітчі розробив і реалізував мову Бі (B), що був спрощений (для реалізації на міні-комп'ютерах) варіант розробленого мови BCPL. Бі, як і BCPL, був інтерпретованою мовою. У 1972 році була випущена друга редакція Unix, переписана мовою Бі. У 1969-1973 pp. на основі Бі була розроблена компілювана мова, що отримала назву Сі (C).

Розкол

Важливою причиною розколу Unix стала реалізація 1980 року стеку протоколів TCP/IP. До цього міжмашинна взаємодія в Unix перебувала в зародковому стані - найбільш істотним способом зв'язку був UUCP (засіб копіювання файлів з однієї Unix-системи в іншу, що спочатку працював телефонними мережами за допомогою модемів).

Було запропоновано два інтерфейси програмування мережевих додатків: сокет Берклі (Berkley sockets) та інтерфейс транспортного рівня TLI (англ. Transport Layer Interface).

Інтерфейс Berkley sockets був розроблений в університеті Берклі і використовував стек протоколів TCP/IP, розроблений там же. TLI був створений AT&T відповідно до визначення транспортного рівня моделі OSI і вперше з'явився в системі System V версії 3. Хоча ця версія містила TLI і потоки, спочатку в ній не було реалізації TCP/IP або інших мережевих протоколів, але подібні реалізації надавалися сторонніми фірмами .

Реалізація TCP/IP офіційно і остаточно була включена в базове постачання System V версії 4. Це, як і інші міркування (переважно ринкові), викликало остаточне розмежування між двома гілками Unix - BSD (університету Берклі) та System V (комерційна версія) від AT&T). Згодом, багато компаній, ліцензувавши System V у AT&T, розробили власні комерційні різновиди Unix, такі як AIX, CLIX, HP-UX, IRIX, Solaris.

Сучасні реалізації Unix, зазвичай, є системами V чи BSD у чистому вигляді. Вони реалізують можливості як System V, і BSD.

Вільні Unix-подібні операційні системи

Зараз GNU/Linux та представники сімейства BSD швидко відвойовують ринок у комерційних Unix-систем і одночасно проникають як на настільні комп'ютери кінцевих користувачів, так і на мобільні та вбудовані системи.

Пропрієтарні системи

Після поділу компанії AT&T товарний знак Unix та права на оригінальний вихідний код неодноразово змінювали власників, зокрема, вони тривалий час належали компанії Novell.

Вплив Unix на еволюцію операційних систем

Unix-системи мають велику історичну важливість, оскільки завдяки їм поширилися деякі популярні сьогодні концепції та підходи в галузі ОС та програмного забезпечення. Також, у ході розробки Unix-систем було створено мову Сі.

Широко використовувана в системному програмуванні мова Сі, створена спочатку для розробки Unix, перевершила Unix за популярністю. Мова Сі була першою «віротерпимою» мовою, яка не намагалася нав'язати програмісту той чи інший стиль програмування. Сі був першою високорівневою мовою, що надає доступ до всіх можливостей процесора, таким як посилання , таблиці , бітові зрушення , інкременти і т. п. З іншого боку, свобода мови Сі призводила до помилок переповнення буфера в таких функціях стандартної бібліотеки Сі, як gets scanf. Результатом стали багато сумно відомих уразливостей, наприклад, та, що експлуатувалася у знаменитому черв'ю Морріса.

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

Unix надавав можливість використання протоколів TCP/IP на порівняно недорогих комп'ютерах, що призвело до швидкого зростання Інтернету. Це, у свою чергу, сприяло швидкому виявленню кількох великих уразливостей у системі безпеки, архітектурі та системних утилітах Unix.

Згодом провідні розробники Unix розробили культурні норми розробки програмного забезпечення, які стали настільки важливими, як і сам Unix. ( )

Одними з найвідоміших прикладів Unix-подібних ОС є macOS, Solaris, BSD і NeXTSTEP.

Соціальна роль у спільноті ІТ-професіоналів та історична роль

Початкові Unix працювали на великих розрахованих на багато користувачів комп'ютерах, до яких також пропонувалися і пропрієтарні ОС від виробника обладнання, такі як RSX-11 і її нащадок VMS. Незважаючи на те, що з низки думок [ чиїх?] тодішній Unix мав недоліки в порівнянні з даними ОС (наприклад, відсутність серйозних движків баз даних), він був: а) дешевшим, а іноді й безкоштовним для академічних установ; б) був портований з устаткування обладнання і розроблений портованою мовою Сі, що «відв'язувало» розробку програм від конкретної апаратури. Крім того, «відв'язаним» від апаратури та виробника виявився і досвід користувача – людина, яка працювала з Unix на VAX, легко працювала з нею ж і на 68xxx, і так далі.

Виробники апаратури на той час часто прохолодно ставилися до Unix, вважаючи її іграшковою, і пропонуючи свою пропрієтарну ОС для серйозної роботи - насамперед СУБД та заснованих на них бізнес-додатків у комерційних структурах. Відомі коментарі з цього приводу від DEC щодо її VMS. До цього прислухалися корпорації, але не академічне середовище, яке мало все для себе необхідне в Unix, часто не вимагало офіційної підтримки від виробника, справляючись самотужки, і цінувало дешевизну та переносимість Unix. Таким чином, Unix була чи не першою ОС, що переноситься на різну апаратуру.

Другим різким зльотом Unix була поява RISC-процесорів близько 1989 року. Ще до того існували т. зв. workstations - персональні однокористувацькі комп'ютери великої потужності, що мають достатній об'єм пам'яті, жорсткого диска та досить розвинену ОС (багатозадачність, захист пам'яті) для роботи з серйозними програмами, такими як CADи. Серед виробників таких машин виділялася компанія Sun Microsystems, яка зробила собі на них ім'я.

До появи RISC-процесорів у цих станціях зазвичай використовувався процесор Motorola 680x0, той самий, що й у комп'ютерах фірми Apple (хоча і під більш розвиненою операційною системою, ніж Apple). Близько 1989 року над ринком з'явилися комерційні реалізації процесорів RISC-архитектуры. Логічним рішенням ряду компаній (Sun та інших) було перенесення Unix на ці архітектури, що негайно спричинило і перенесення всієї екосистеми ПЗ для Unix.

Пропрієтарні серйозні ОС, такі як VMS, почали свій захід сонця саме з цього моменту (навіть якщо і вдалося перенести на RISC саму ОС, все було набагато складніше з додатками під неї, які в цих екосистемах найчастіше розроблялися на асемблері або на пропрієтарних мовах типу BLISS ), і Unix став ОС для найпотужніших комп'ютерів у світі.

Однак у цей час екосистема почала переходити на GUI в особі Windows 3.0. Величезні переваги GUI, а також, наприклад, уніфікована підтримка всіх типів принтерів були оцінені і розробниками, і користувачами. Це сильно підірвало позиції Unix на ринку PC – такі реалізації, як SCO та Interactive UNIX, не справлялися із підтримкою Windows-додатків. Що ж стосується GUI для Unix, званого X11 (були й інші реалізації, багато менш популярні), то він не міг повноцінно працювати на звичайній користувальницькій PC з огляду на вимоги до пам'яті - для нормальної роботи X11 потрібно 16 МБ, в той час як Windows 3.1 з достатньою продуктивністю виконувала і Word, і Excel одночасно 8 МБ (це було стандартним розміром пам'яті PC тоді). За високих цін на пам'ять це було лімітуючим фактором.

Успіх Windows дав імпульс внутрішньому проекту Microsoft під назвою Windows NT, яка була сумісна з Windows по API, але при цьому мала ті ж архітектурні особливості серйозної ОС, що і Unix - багатозадачність, повноцінний захист пам'яті, підтримку багатопроцесорних машин, права доступу до файлів та каталогів, системний журнал. Також Windows NT представила журнальну файлову систему NTFS, яка за можливостями на той момент перевищувала всі файлові системи, що поставляються з Unix - аналоги під Unix були тільки окремими комерційними продуктами від Veritas та інших.

Хоча Windows NT і не була популярна спочатку, через високі вимоги до пам'яті (ті ж 16 МБ), вона дозволила Microsoft вийти на ринок рішень для серверів, наприклад, СУБД. Багато хто тоді не вірив у можливість Microsoft, що традиційно спеціалізується на настільному ПЗ, бути гравцем на ринку ПЗ масштабу підприємства, де вже були свої гучні імена, такі як Oracle і Sun. До цього сумнівався той факт, що СУБД Microsoft - SQL Server - починався як спрощена версія Sybase SQL Server, ліцензована у Sybase і на 99% сумісна з усіх аспектів роботи з ним.

У другій половині 1990-х років Microsoft почав тіснити Unix і на ринку корпоративних серверів.

Сукупність перерахованих вище факторів, а також обвал цін на 3D-відеоконтролери, що стали з професійного обладнання домашнім, по суті вбила саме поняття workstation до початку 2000-х років.

Крім того, Microsoft простіше в управлінні, особливо в типових сценаріях використання.

Але зараз почався третій різкий зліт Unix.

Крім того, Столлман та його товариші чудово розуміли, що для успіху не зав'язаного на корпорації програмного забезпечення пропрієтарні засоби розробки не підходять. Тому вони розробили набір компіляторів для різних мов програмування (gcc), що разом із розробленими раніше утилітами GNU (заміна стандартних утиліт Unix) склало необхідний і досить потужний пакет програм для розробника.

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

Надалі Linux досягав нових і нових висот:

• перенесення серйозних пропрієтарних продуктів, таких як Oracle;
• серйозний інтерес IBM до цієї екосистеми як основи для своїх вертикальних рішень;
• поява аналогів багатьох звичних програм зі світу Windows;
• відмова деяких виробників обладнання від обов'язкового попереднього встановлення Windows;
• випуск нетбуків з лише Linux;
• використання як ядро ​​в Android.

На даний момент Linux є заслужено популярною ОС для серверів, хоча й менш популярною на робочих столах.

Деякі архітектурні особливості ОС Unix

Особливості Unix, що відрізняють цю родину від інших ОС, наведені нижче.

• Файлова система деревоподібна, чутлива до регістру символів у іменах, дуже слабкі обмеження довжину імен і шляхи.
• Немає підтримки структурованих файлів ядром ОС, лише на рівні системних викликів файл є потік байтів.
• Командний рядок знаходиться в адресному просторі процесу, що запускається, а не витягується системним викликом з процесу інтерпретатора команд (як це відбувається, наприклад, в RSX-11).
• Поняття «змінних оточення».
• Запуск процесів виклик fork(), тобто можливість клонування поточного процесу з усім станом.
• Концепція stdin/stdout/stderr.
• Введення-виведення лише через дескриптори файлів .
• Традиційно вкрай слабка підтримка асинхронного введення-виведення, порівняно з VMS та Windows NT.
• Інтерпретатор команд є звичайний додаток, що спілкується з ядром звичайними системними викликами (в RSX-11 і VMS інтерпретатор команд виконувався як спеціальний додаток, спеціальним чином розміщений в пам'яті, що користується спеціальними системними викликами, підтримувалися також системні виклики, що дають можливість. команд).
• Команда командного рядка є не більше ніж ім'я файлу програми, не потрібна спеціальна реєстрація та спеціальна розробка програм як команд (що було звичайною практикою в RSX-11, RT-11).
• Не прийнятий підхід з програмою, що задає користувачеві питання режимах своєї роботи, замість цього використовуються параметри командного рядка (у VMS , RSX-11 , RT-11 програми працювали також з командним рядком, але за її відсутності видавали запит на введення параметрів).
• Простір імен пристроїв на диску в каталозі /dev, що піддається управлінню адміністратором, на відміну від підходу Windows, де цей простір імен розміщується в пам'яті ядра, і адміністрування цього простору (наприклад, завдання прав доступу) вкрай утруднене через відсутність його постійного зберігання дисках (будується щоразу під час завантаження).
• Широке використання текстових файлів для зберігання налаштувань, на відміну від двійкової бази даних налаштувань, як, наприклад, Windows.
• Широке використання утиліт обробки тексту до виконання повсякденних завдань під управлінням скриптів.
• "Розкрутка" ОС після завантаження ядра шляхом виконання скриптів стандартним інтерпретатором команд.
• Широке використання

Історія UNIX® починається 1969 р. Більшість сучасних UNIX-систем є комерційними версіями вихідних дистрибутивів UNIX. Solaris від Sun, HP-UX Hewlett-Packard, AIX® від IBM є найкращими представниками UNIX, які, крім того, мають свої власні унікальні елементи та власні фундаментальні рішення. Наприклад, Sun Solaris - це UNIX, але, крім того, вона містить багато інструментів та розширень, розроблених спеціально для робочих станцій і серверів виробництва Sun.

Linux® був розроблений у спробі створити безкоштовну альтернативу комерційним UNIX-середовищам. Його історія починається в 1991 або навіть в 1983 р., коли був створений проект GNU, чиєю вихідною метою було надати безкоштовну альтернативу UNIX. Linux працює на набагато більшій кількості платформ, наприклад, на Intel®/AMD x86. Більшість ОС UNIX здатні працювати лише на одній платформі.

У Linux і UNIX загальне історичне коріння, але є й серйозні відмінності. Багато інструментів, утиліт і безкоштовних програм, що є стандартними для Linux, спочатку замислювалися як безкоштовна альтернатива програмам для UNIX. Linux часто надає підтримку безлічі опцій та програм, запозичуючи кращу або найбільш популярну функціональність з UNIX.

Адміністратор або розробник, який звик працювати з Linux, UNIX може здатися не дуже зручною для використання. З іншого боку фундамент UNIX-подібної операційної системи (інструменти, файлова система, інтерфейси API) досить стандартизований. Однак деякі деталі систем можуть мати суттєві відмінності. Далі у статті будуть розглянуті ці відмінності.

Технічні відмінності

Розробники комерційних дистрибутивів UNIX розраховують на певне коло клієнтів та серверну платформу для своєї операційної системи. Вони добре уявляють, яку підтримку та оптимізацію яких додатків потрібно реалізувати. Виробники UNIX роблять все можливе для сумісності між різними версіями. З іншого боку, вони опублікували стандарти своїх ОС.

Розробка GNU/Linux, з іншого боку, не орієнтована на конкретні платформи та коло клієнтів, і розробники GNU/Linux мають різні досвід та погляди. У Linux-спільноті немає суворого стандартного набору інструментів чи середовищ. Для вирішення цієї проблеми було запущено проект Linux Standards Base (LSB), але він виявився не таким результативним, як хотілося б.

Ця недостатня стандартизованість призводить до значних неузгодженостей усередині Linux. Для деяких розробників можливість використовувати кращі досягнення інших операційних систем є плюсом, проте не завжди зручне копіювання в Linux елементів UNIX, наприклад, коли імена пристроїв усередині Linux можуть бути взяті з AIX, тоді як інструменти для роботи з файловою системою орієнтовані HP-UX. Несумісності такого роду зустрічаються між різними дистрибутивами Linux. Наприклад, Gentoo та RedHat реалізують різні методи оновлень.

Для порівняння - кожен новий реліз UNIX-системи виходить із добре документованим описом нових особливостей та змін UNIX. Команди, інструменти та інші елементи рідко змінюються, і часто ті ж аргументи командного рядка для програм залишаються незмінними протягом багатьох версій цього програмного забезпечення. Коли ж відбуваються значні зміни в цих елементах, постачальники комерційних UNIX систем часто надають оболонку, необхідну для забезпечення сумісності з ранніми версіями цього інструменту.

Подібна сумісність означає, що утиліти та програми можуть використовуватися на нових версіях операційних систем без перевірки та зміни їх вихідного коду. Тому перехід на нову версію UNIX, в якій зазвичай немає принципових відмінностей від старої версії, для користувачів або адміністраторів пов'язаний із набагато меншими зусиллями, ніж перехід із одного дистрибутива Linux на інший.

Архітектура апаратного забезпечення

Більшість комерційних версій UNIX створено для однієї чи невеликої кількості архітектур апаратного забезпечення. HP-UX працює тільки на платформах PA-RISC та Itanium, Solaris – на SPARC та x86, а AIX призначений лише для процесорів POWER.

Завдяки цим обмеженням UNIX-виробники можуть відносно вільно модифікувати свій код для цих архітектур і використовувати будь-яку перевагу своєї архітектури. Оскільки вони чудово знають підтримувані ними пристрої, їхні драйвери працюють краще, і їм не потрібно враховувати обмеження BIOS, характерні для ПК.

Linux, з іншого боку, історично розроблявся задля забезпечення максимальної сумісності. Linux доступний на різних архітектурах, а кількість пристроїв введення/виводу та іншої периферії, яка може використовуватися з цією ОС, майже безмежна. Розробники не можуть заздалегідь знати, яке конкретне обладнання буде встановлено на комп'ютері, і часто не можуть забезпечити його ефективне використання. Одним із прикладів є керування пам'яттю на Linux. Раніше Linux використовував сегментну модель пам'яті, спочатку розроблену для x86. Зараз він адаптований для використання сторінки пам'яті, але все ще зберігає деякі вимоги до сегментної пам'яті, що викликає проблеми, якщо архітектура не підтримує сегментовану пам'ять. Це не є проблемою для виробників UNIX. Вони точно знають, на якому обладнанні працюватиме UNIX.

Ядро

Ядро є серцем операційної системи. Вихідний код ядра комерційних дистрибутивів UNIX є власністю їх розробників і поширюється межі компанії. Цілком протилежна ситуація з Linux. Процедури для компіляції та виправлення ядер та драйверів дуже різні. Для Linux та інших операційних систем з відкритим кодом патч може бути випущений у вигляді вихідного коду, і кінцевий користувач може встановити, перевірити і навіть модифікувати його. Ці патчі зазвичай перевірені не так ретельно, як патчі від постачальників комерційних ОС UNIX. Оскільки немає повного списку додатків та середовищ, які мають бути тестовані для коректної роботи на Linux, Linux-розробники залежать від кінцевих користувачів та інших розробників, які відловлюватимуть помилки.

Постачальники комерційних UNIX-дистрибутивів випускають ядра лише як виконуваного коду. Деякі релізи є монолітними, тоді як інші дозволяють оновити лише якийсь конкретний модуль ядра. Але в будь-якому випадку цей реліз надається лише у формі коду, що виконується. Якщо необхідно оновлення, адміністратор повинен чекати, поки виробник випустить патч у бінарному коді, однак його може втішити те, що виробник виконає ретельну перевірку свого патча на зворотну сумісність.

Усі комерційні версії UNIX певною мірою еволюціонували до модульного ядра. Драйвери та окремі особливості ОС доступні як окремі компоненти і можуть бути за потребою завантажені або вивантажені з ядра. Але відкрита модульна архітектура Linux набагато гнучкіша. Однак гнучкість та адаптованість Linux означають і постійну зміну. Вихідний код Linux постійно змінюється, і, за забаганням розробника, може змінитися API. Коли модуль або драйвер написано для комерційної версії UNIX, він пропрацює набагато довше, ніж той самий драйвер для Linux.

Підтримка файлової системи

Однією з причин, завдяки якій Linux став досить потужною ОС, є його сумісність з іншими операційними системами. Одна з найбільш очевидних особливостей – це достаток файлових систем, які є доступними. Більшість комерційних версій UNIX підтримують два або три типи файлової системи. Linux, однак, підтримує більшість із сучасних файлових систем. показує, які файлові системи підтримуються ОС UNIX. Будь-яку з цих файлових систем можна змонтувати на Linux, хоча не всі з цих систем підтримують у повному обсязі читання та запис даних.

Таблиця 1. Файлові системи, стандартні для UNIX

Більшість комерційних версій UNIX підтримують журнальні файлові системи. Наприклад, HP-UX як стандартна файлова система використовує hfs, але він також підтримує файлову систему vxfs, що журналується. Solaris підтримує ufs та zfs. Журнальована файлова система є важливим компонентом будь-якого серверного середовища для підприємства. У Linux підтримка файлових систем, що журналуються, була реалізована пізно, але тепер є кілька варіантів – від клонів комерційних файлових систем (xfs, jfs) до специфічних для Linux файлових систем (ext3, reiserfs).

Інші особливості файлових систем включають підтримку квот, список контролю доступу до файлів, дзеркальне копіювання, знімки системи та зміна розмірів. У тій чи іншій формі вони підтримуються файловими системами Linux. Більшість із цих особливостей не є стандартними для Linux. Одні особливості можуть працювати на одній файловій системі, тоді як інші вимагають іншої файлової системи. Деякі з цих особливостей просто недоступні на певних файлових системах Linux, інші потребують додаткової установки інструментів, наприклад, певної версії LVM чи підтримку дискових масивів (software raid package). Історично так склалося, що в Linux сумісність програмних інтерфейсів і стандартних інструментів досягається важко, тому безліч файлових систем реалізують ці особливості по-різному.

Оскільки комерційні UNIX-системи підтримують обмежену кількість файлових систем, їх інструменти та методики роботи з ними більш стандартизовані. Наприклад, оскільки Irix підтримувалася лише одна головна файлова система, то був лише один спосіб завдання списків контролю доступу. Це набагато зручніше для кінцевого користувача та для подальшої підтримки цієї ОС.

Доступність додатків

Більшість базових програм однакові як на UNIX, так і на Linux. Наприклад, команди cp, ls, vi та cc доступні на UNIX і Linux, і дуже схожі, якщо не повністю ідентичні. Linux-версії цих інструментів базуються на GNU-версіях цих інструментів, тоді як версії цих інструментів для UNIX базуються на традиційних UNIX-інструментах. Ці інструменти для UNIX мають тривалу історію та рідко змінювалися.

Але це зовсім не означає, що комерційні версії UNIX не можуть використовуватися з інструментами GNU. Фактично багато виробників комерційних UNIX ОС включають до своїх дистрибутивів багато GNU-інструментів або пропонують їх як безкоштовне доповнення. GNU-інструменти не просто стандартні інструментальні засоби. Деякі з таких безкоштовних утиліт немає комерційних аналогів (emacs чи Perl). Більшість виробників встановлюють ці програми, і вони або автоматично встановлюються разом із системою, або доступні як додатковий компонент.

Безкоштовні програми з відкритим вихідним кодом майже завжди вбудовуються у всі Linux-дистрибутиви. Існує велика кількість безкоштовного програмного забезпечення, доступного для Linux, і багато цих програм були портовані на комерційні версії ОС UNIX.

Комерційні та/або із закритим вихідним кодом програми (CAD, фінансові програми, графічні редактори) можуть не мати аналогів для Linux. Хоча деякі виробники випускають версії своїх додатків для Linux, більшість виробників не поспішає робити це, поки популярність Linux у користувачів не зросте.

З іншого боку, комерційні версії UNIX історично мають підтримку великої кількості програм рівня підприємства, наприклад, Oracle або SAP. Linux сильно програє через труднощі сертифікації великих додатків, тоді як комерційні версії UNIX сильно не змінюються від релізу до релізу. Linux може сильно змінитися не тільки з кожним новим дистрибутивом, але іноді і в проміжку між релізами одного дистрибутива. Тому виробнику програмного забезпечення дуже важко зрозуміти, в якому саме середовищі використовуватиметься їхня програма.

Системне адміністрування

Хоча деякі дистрибутиви Linux поставляються зі стандартним набором інструментів для керування системою, наприклад, SUSE"s YaST, не існує спільного для Linux стандарту інструментальних засобів системного адміністрування. Доступні текстові файли та інструменти командного рядка, але іноді їх застосування може бути незручним. Кожна комерційна версія UNIX має свій власний інтерфейс керування системою, який дозволяє керувати елементами системи та змінювати їх за допомогою цього інтерфейсу Нижче наведено приклад Менеджера системного адміністрування для HP-UX.

Цей SAM містить такі модулі:

• Користувачі чи групи, якими треба керувати.
• Параметри ядра можна змінити.
• Налаштування мережі.
• Налаштування та ініціалізація дисків.
• Налаштування X Server.

Якість цього пакета чудово утиліт, причому цей пакет утиліт добре взаємодіє з текстовими файлами. Аналогу цього інструменту для Linux немає. Навіть YaST в SUSE не має такої ж функціональності.

Ще один аспект у UNIX та Linux, який, здається, змінюється майже з кожною версією ОС – розташування сценаріїв ініціалізації системи. На щастя, /sbin/init та /etc/inittab є стандартними каталогами. Але сценарії запуску системи знаходяться у різних каталогах. показує місця, де зберігаються сценарії ініціалізації системи різних дистрибутивів UNIX і Linux.

Таблиця 2. Розташування сценаріїв ініціалізації системи для різних версій UNIX

HP-UX	/sbin/init.d
AIX	/etc/rc.d/init.d
Irix	/etc/init.d
Solaris	/etc/init.d
Redhat	/etc/rc.d/init.d
SUSE	/etc/rc.d/init.d
Debian	/etc/init.d
Slackware	/etc/rc.d

Через велику кількість дистрибутивів Linux і майже нескінченного числа доступних програм (з урахуванням того, що версій цієї програми теж багато) для цієї ОС, управління програмами на Linux стає складним завданням. Вибір правильного інструменту залежить від того, з яким дистрибутивом ви працюєте. Далі незручності виникають через те, що деякі дистрибутиви використовують формат файлів Redhat Package Manager (RPM), у той час як їх програми несумісні. Такий поділ призводить до появи величезної кількості опцій роботи з пакетами, і не зрозуміло, яка система використовується в конкретному середовищі.

З іншого боку, комерційні дистрибутиви UNIX містять стандартні менеджери пакетів. Навіть при тому, що існують різні версії додатків та специфічні формати для різних версій UNIX, середовище управління додатками незмінне. Наприклад, Solaris використовує ті самі інструменти керування пакетами програм з моменту свого створення. І швидше за все засоби ідентифікації, додавання або видалення пакетів програм у Solaris будуть також незмінними.

Виробники комерційних дистрибутивів UNIX поставляють також і апаратне забезпечення, для роботи на якому призначена їхня ОС, тому у своїх ОС вони можуть впроваджувати якісь нові пристрої, що набагато важче зробити для Linux. Наприклад, в останніх версіях Linux були спроби реалізувати підтримку компонентів з можливістю їхньої "гарячої заміни" (зі змінним успіхом). Комерційні версії UNIX мають таку можливість вже багато років. Також у комерційних версіях UNIX краще, ніж у Linux, реалізовано моніторинг за апаратним забезпеченням. Виробники можуть написати драйвери та впровадити їх у свою операційну систему, яка вестиме моніторинг стану системи, наприклад, кількість помилок пам'яті ECC, параметри енергоспоживання або будь-якого іншого компонента апаратного забезпечення. Підтримка такого роду для Linux очікується лише у віддаленому майбутньому.

Апаратне забезпечення для комерційних UNIX-систем також має просунуті опції завантаження. Перед тим, як операційна система завантажиться, існує багато можливостей налаштувати її завантаження, перевірити "здоров'я" системи або налаштувати параметри апаратного забезпечення. BIOS стандартного персонального комп'ютера PC має меншу частину, якщо взагалі має цих опцій.

Підтримка

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

При покупці комерційної версії UNIX виробники зазвичай надають технічну підтримку. Більшість користувачів Linux не мають підтримки компанії-виробника ОС. Вони можуть отримати підтримку лише за допомогою електронної пошти, форумів та різних спільнот користувачів Linux. Однак, ці групи призначені не тільки для користувачів Linux. Багато адміністраторів комерційних операційних систем сімейства UNIX беруть участь у цих відкритих групах підтримки для того, щоб мати можливість як надавати допомогу, так і, за необхідності, користуватися нею. Багато людей знаходять такі групи взаємодопомоги навіть кориснішими, ніж система підтримки, запропонована виробником ОС.

Висновок

Фундаментальні основи UNIX та Linux дуже схожі. Користувачеві чи системному адміністратору перехід з Linux на UNIX додасть у роботу деякі незручності, але загалом перехід виявиться безболісним. Навіть якщо файлові системи та ядра у них будуть відрізнятися і для їх освоєння знадобиться деякий час, інструменти та API залишаються незмінними. В основному ці відмінності істотні не більше ніж різницю між основними версіями UNIX. Всі гілки UNIX і Linux поступово розвиваються і будуть трохи відрізнятися один від одного, але через зрілість концепцій UNIX основи ОС не зміняться дуже сильно.

Вступ

Що таке Unix?

Де взяти безкоштовний Unix?

Які основні відмінності Unix від інших ОС?

Чому Unix?

Основні поняття Unix

Файлова система

Комадний інтерпретатор

Посібники - man

Вступ

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

Народження ОС Unix відноситься до кінця 60-х років, і ця історія вже обросла "легендами", які часом по-різному розповідають про деталі цієї події. ОС Unix народилася в дослідному центрі Bell Telephone Laboratories (Bell Labs), що входить до складу корпорації AT&T. Спочатку цей ініціативний проект для ЕОМ PDP-7 (згодом - для PDP-11) являв собою чи то файлову систему, чи комп'ютерну гру, чи систему підготовки текстів, чи те, й інше, і третє. Важливо, однак, те, що з самого початку проект, що перетворився в результаті на ОС, замислювався як програмне середовище колективного користування. Автором першої версії Unix є Кен Томпсон, проте в обговоренні проекту, а згодом – і в його реалізації брав участь великий колектив співробітників (Д. Рітчі, Б. Керніган, Р. Пайк та інші). На наш погляд, кілька щасливих обставин народження Unix визначили успіх цієї системи на багато років уперед.

Для більшості співробітників колективу, в якому народилася ОС Unix, ця ОС була "третьою системою". Існує думка (див., наприклад), що системний програміст досягає високої кваліфікації тільки при виконанні третього свого проекту: перший проект виходить ще "учнівським", у другий розробник намагається включити все, що не вийшло в першому, і в результаті він виходить занадто громіздким , і лише у третьому досягається необхідний баланс бажань та можливостей. Відомо, що до народження Unix колектив Bell Labs брав участь (разом з іншими фірмами) у розробці ОС MULTICS. Кінцевий продукт MULTICS (Bell Labs не брала участі в останніх стадіях розробки) має всі ознаки "другої системи" і не набув широкого поширення. Слід, однак, зауважити, що в цьому проекті було народжено багато принципово важливих ідей та рішень, і деякі концепції, які багато хто вважає народженими в Unix, насправді має своїм джерелом проект MULTICS.

ОС Unix була системою, яка робилася "для себе та для своїх друзів". Перед Unix не ставилося завдання захоплення ринку та конкуренції з будь-якими продуктами. Самі розробники ОС Unix були її користувачами, і самі оцінювали відповідність системи своїм потребам. Без тиску ринкової кон'юнктури така оцінка могла бути гранично об'єктивною.

ОС Unix стала системою, яка зроблена програмістами і програмістів. Це визначило витонченість та концептуальну стрункість системи - з одного боку, а з іншого - необхідність розуміння системи для користувача Unix та почуття професійної відповідальності для програміста, який розробляє програмне забезпечення для Unix. І жодні подальші спроби зробити "Unix для чайників" не змогли позбавити ОС Unix цієї гідності.

У 1972-73 р.р. Кен Томпсон та Денніс Рітчі написали нову версію Unix. Спеціально для цієї мети Д. Рітчі створив мову програмування C, представляти яку тепер уже немає необхідності. Більше 90% програмного коду Unix написано цією мовою, і мова стала невід'ємною частиною ОС. Те, що основна частина ОС написана мовою високого рівня, забезпечує можливість її перекомпіляції в коди будь-якої апаратної платформи і є обставиною, що визначила широке поширення Unix.

У період створення Unix антимонопольне законодавство США не давало корпорації AT&T можливості виходити ринку програмних продуктів. Тому ОС Unix була некомерційною та вільно поширювалася, насамперед – в університетах. Там її розвиток продовжувався, і найактивніше воно велося в Каліфорнійському університеті в Берклі. У цьому університеті було створено групу Berkeley Software Distribution, яка займалася розвитком окремої гілки ОС - BSD Unix. Протягом усієї наступної історії основна гілка Unix та BSD Unix розвивалися паралельно, неодноразово взаємно збагачуючи одна одну.

У міру поширення ОС Unix став дедалі зростати інтерес до неї комерційних фірм, які почали випускати власні комерційні версії цієї ОС. Згодом стала комерційною та "основна" гілка Unix від AT&T, для її просування була створена дочірня фірма Unix System Laboratory. Гілка BSD Unix у свою чергу розгалужилася на комерційну BSD і Free BSD. Різні комерційні та вільно розповсюджувані Unix-подібні системи будувалися на базі ядра AT&T Unix, проте в них включалися і властивості, що запозичуються з BSD Unix, а також оригінальні властивості. Незважаючи на загальне джерело, відмінності між членами сімейства Unix накопичувалися і в результаті призвели до того, що перенесення додатків з однієї Unix-подібної ОС до іншої стало надзвичайно утрудненим. З ініціативи користувачів Unix виник рух стандартизації API Unix. Цей рух був підтриманий Міжнародною організацією стандартів ISO та призвів до виникнення стандарту POSIX (Portable Operation System Interface eXecution), який розвивається і в даний час і є найавторитетнішим стандартом для ОС. Однак, оформлення специфікацій POSIX як офіційного стандарту – процес досить повільний, і він не може задовольняти потреби виробників програмного забезпечення, що призвело до виникнення альтернативних промислових стандартів.

З переходом AT&T Unix до компанії Nowell назва цієї ОС змінилася на Unixware, а права на торгову марку Unix перейшли до консорціуму X/Open. Цей консорціум (нині - Open Group) розробив свої (ширші, ніж POSIX) специфікації системи, відомі як Single Unix Specification. Нещодавно вийшла друга редакція цього стандарту, значно краще узгоджена з POSIX.

Нарешті, ряд фірм - виробників своїх версій Unix утворив консорціуму Open Software Foundation (OSF), який випустив свою версію Unix - OSF/1, створену з урахуванням мікроядра Mach. OSF також випустив специфікацію системи OSF/1, на основі якої фірми-члени OSF стали випускати власні Unix-системи. Серед таких систем: SunOS фірми Sun Microsystems, AIX фірми IBM, HP/UX фірми Hewlett-Packard, DIGITAL UNIX фірми Compaq та інші.

Спочатку Unix-системи цих фірм переважно базувалися на BSD Unix, але сьогодні більшість сучасних промислових Unix-систем будуються з урахуванням використанні (за ліцензією) ядра AT&T Unix System V Release 4 (S5R4), хоча успадковують деякі властивості BSD Unix. Ми не беремо на себе відповідальність порівнювати комерційні Unix-системи, тому що періодично з'являються у пресі порівняння такого роду найчастіше представляють протилежні результати.

Компанія Nowell продала Unix компанії Santa Crouse Operations, яка випускала власний Unix-продукт – SCO Open Server. SCO Open Server базувався на раніше версії ядра (System V Release 3), але був чудово налагоджений і відрізнявся високою стабільністю. Фірма Santa Crouse Operations інтегрувала свій продукт з AT&T Unix і випустила Open Unix 8 , проте потім продала Unix фірмі Caldera, яка є власником "класичної" ОС Unix сьогодні (наприкінці 2001 р).

Фірма Sun Microsystems розпочала своє представництво у світі Unix системою SunOS, створеної на основі ядра BSD. Однак згодом замінила її системою Solaris на основі S5R4. В даний час поширюється версія 8 цієї ОС (є також v.9-бета). Solaris працює на платформі SPARC (RISC-процесори, що виготовляються за специфікаціями Sun) та Intel-Pentium.

Компанія Hewlett-Packard пропонує ОС HP-UX. v.11 на платформі PA-RISC. HP-UX базується на S5R4, але містить багато властивостей, що "видають" її походження від BSD Unix. Звичайно ж HP-UX буде доступна і на платформі Intel-Itanium.

Фірма IBM виступає з ОС AIX, остання на сьогоднішній день версія - 5L (про неї ще йтиметься попереду). IBM не оголошувала "родовід" AIX, це в основному оригінальна розробка, але перші версії носили ознаки походження від FreeBSD Unix. Наразі AIX більше схожа на S5R4. Спочатку ОС AIX була доступна і на платформі Intel-Pentium, але згодом (відповідно до загальної політики IBM) перестала підтримуватися на цій платформі. В даний час AIX працює на серверах IBM RS/6000 та інших обчислювальних платформах на базі процесорів PowerPC (у тому числі і на суперкомп'ютерах IBM).

ОС DIGITAL UNIX фірми DEC була єдиною промисловою реалізацією системи OSF/1. ОС DIGITAL UNIX працювала на RISC-серверах Alpha фірми DEC. Коли 1998 р. фірма DEC була поглинена фірмою Compaq, у фірму Compaq перейшли і сервери Alpha, і DIGITAL UNIX. Фірма Compaq має намір відновити присутність на ринку серверів Alpha і тому інтенсивно розвиває і ОС для них. Нинішня назва цієї ОС – Tru64 Unix (поточна версія – 5.1A), вона продовжує базуватися на ядрі OSF/1 і несе в собі багато ознак BSD Unix.

Незважаючи на те, що більшість комерційних Unix-систем базуються на одному ядрі та задовольняють вимоги POSIX, кожна з них має власний діалект API, і відмінності між діалектами накопичуються. Це призводить до того, що перенесення промислових додатків з однієї Unix-системи на іншу важко і вимагає, як мінімум, перекомпіляції, а часто - і коригування вихідного коду. Спробу подолати "розбрід" і створити єдину для всіх ОС Unix було вжито в 1998 р. альянсом фірм SCO, IBM і Sequent. Ці фірми об'єдналися у проекті Monterey з метою створення єдиної ОС на базі Unixware, власником якої на той час була SCO, IBM AIX та ОС DYNIX фірми Sequent. (Фірма Sequent займає лідируючі позиції у виробництві ЕОМ архітектури NUMA – несиметричної багатопроцесорної – і DYNIX – це Unix для таких ЕОМ). ОС Monterey мала працювати на 32-розрядній платформі Intel-Pentium, 64-розрядній платформі PowerPC і на новій 64-розрядній платформі Intel-Itanium. Про підтримку проекту заявили майже всі лідери виробництва апаратних засобів та проміжного програмного забезпечення. Навіть фірми, що мають власні клони Unix (крім Sun Microsystems), оголосили, що на платформах Intel вони підтримуватимуть лише Monterey. Робота над проектом просувалася, мабуть, успішно. ОС Monterey була серед перших, які довели свою працездатність на Intel-Itanium (поряд з Windows NT і Linux) і єдиною, яка при цьому не вдавалася до емуляції 32-розрядної архітектури Intel-Pentium. Однак у фінальній стадії проекту відбулася фатальна подія: SCO продала своє Unix-відділення. Ще раніше фірма Sequent увійшла до складу IBM. "Спадкоємцем" всіх властивостей ОС Monterey стала ОС IBM AIX v.5L. Проте не зовсім усіх. Платформа Intel-Pentium не є для IBM стратегічним напрямком і на цій платформі ОС AIX недоступна. А оскільки інші лідери комп'ютерної індустрії не поділяють (чи не повністю поділяють) таку позицію IBM, ідея спільної ОС Unix так і не реалізувалася.

Якщо ви недавно почали вивчати Linux і освоюватися в цьому величезному всесвіті, то напевно, часто зустрічали термін Unix. Звучить дуже схоже на Linux, але що воно означає? Напевно, вам цікаво, чим відрізняється unix від linux. Відповідь це питання залежить від цього що ви розумієте під цими словами. Адже кожен із них може інтерпретуватися по-різному. У цій статті ми розглянемо спрощену історію Linux і Unix, щоб допомогти вам зрозуміти, що це і як вони між собою пов'язані. Як завжди, ви можете ставити запитання або додати додаткову інформацію в коментарях.

Свою історію Unix розпочав наприкінці 1960-х та на початку 1970-х у науково-дослідних обчислювальних лабораторіях AT&T Bell Labs у Сполучених штатах. Разом з MIT та General Electric дослідницька лабораторія Bell Labs розпочала розробку нової операційної системи. Деякі дослідники були незадоволені ходом розробки цієї операційної системи. Вони відійшли від роботи над основним проектом та почали розробляти власну ОС. У 1970 році ця система отримала назву Unix, а через два роки вона була повністю переписана мовою програмування Сі.

Це дозволило поширювати та портувати Unix на різні пристроїта обчислювальні платформи.

Оскільки Unix продовжував розвиватись, AT&T почав продавати ліцензії на використання її в університетах, а також у комерційних цілях. Це означало, що не всі могли, як зараз, вільно змінювати та поширювати код операційної системи Unix. Незабаром почало з'являтися багато редакцій та варіантів операційної системи Unix, призначеної на вирішення різних завдань. Найвідомішою з них була BSD.

Linux схожий на Unix за функціональністю та можливостями, але не кодовою базою. Ця операційна система була зібрана із двох проектів. Перший – проект GNU, розроблений Річардом Столлманом у 1983, другий – ядро ​​Linux, написане Лінусом Торвальдсом у 1991.

Метою проекту GNU було створити систему схожу на Unix, але не залежну від нього. Іншими словами, операційну систему, яка не містить код Unix, яка могла б вільно розповсюджуватися та модифікуватися без обмежень, як вільне програмне забезпечення. Оскільки вільне ядро ​​Linux не могло працювати само по собі, проект GNU об'єднався з ядром Linux, і так народилася операційна система Linux.

Конструювався Linux під впливом системи Minix, нащадка Unix, але весь код написано з нуля. На відміну від Unix, який використовувався на серверах та великих мейнфреймах різних підприємств, Linux був розрахований для використання на домашньому комп'ютеріз найпростішим апаратним забезпеченням.

На сьогоднішній день Linux працює на величезній кількості платформ, більшому ніж будь-яка інша ОС, це сервери, системи, що вбудовуються, мікрокомп'ютери, модеми і навіть мобільні телефони. Тепер буде детальніше розглянута різниця linux і unix.

Що таке Unix

Термін Unix може стосуватися таких понять:

• Оригінальна операційна система розроблена в AT&T Bell Labs, на основі якої розвиваються інші ОС.
• Товарний знак написано великими літерами. UNIX належить The Open Group, яка розробила набір стандартів для операційних систем – Single UNIX Specification. Тільки ті системи, які відповідають стандартам, можуть законно називатися UNIX. Сертифікація не є безкоштовною і вимагає від розробників платити за використання цього товарного знака.
• Усі операційні системи зареєстровані під назвою Unix. Тому що вони відповідають вищезазначеним стандартам. Це AIX, A/UX, HP-UX, Inspur K-UX, Reliant UNIX, Solaris, IRIX, Tru64, UnixWare, z/OS та OS X - так, навіть ті, що працюють на комп'ютерах Apple.

Що таке Linux

Термін Linux стосується лише ядра. Операційна система не буде повною без настільного середовища та додатків. Оскільки більшість програм були розроблені і зараз розробляються в рамках проекту GNU, повна назва операційної системи – GNU/Linux.

Зараз багато людей використовують термін Linux для позначення всіх дистрибутивів, заснованих на ядрі Linux. На даний момент найновіша версія ядра Linux - 4.4, версія 4.5 знаходиться на стадії розробки. Зміна нумерації релізів ядра з 3.х на 4.х відбулася не так давно.

Linux - це Unix, подібна операційна система, яка веде себе як Unix, але не містить його код. Unix подібні ОС часто називають Un * x, * NIX і * N? X, або навіть Юніксоїдами. Linux не має сертифікації Unix, а GNU розшифровується як GNU not Unix, так що в цьому відношенні Mac OS X більше Unix ніж Linux. Але ядро ​​Linux і ОС GNU Linux дуже схожі на Unix за функціональністю, реалізують більшість принципів філософії Unix. Це легкочитаний код, зберігання конфігурації системи в окремих текстових файлах, а також використання невеликих інструментів командного рядка, графічна оболонка та менеджер сеансів.

Важливо зазначити, що далеко не всі Unix подібні системи отримали сертифікацію UNIX. У певному контексті всі операційні системи, засновані на UNIX чи його ідеях, називаються UNIX подібними, незалежно від цього чи є в них сертифікат UNIX чи ні. Крім того, вони можуть бути комерційними та безкоштовними.

Сподіваюся, тепер стало зрозуміліше, ніж відрізняється unix від linux. Але підемо ще далі і підіб'ємо підсумки.

Основні відмінності

• Linux – вільна операційна система з відкритим вихідним кодом, а оригінальна Unix – ні, крім деяких її похідних.
• Linux - це клон оригінального Unix, але він містить його код.
• Головна відмінність unix від linux, у тому, що Linux - це тільки ядро, в той час як Unix була і є повноцінною операційною системою.
• Linux було розроблено для персональних комп'ютерів. А Unix орієнтований насамперед на великі робочі станції та сервери.
• Сьогодні Linux підтримує більше платформ, ніж Unix.
• Linux підтримує більше типів файлових систем, ніж Unix.

Як бачите, плутанина зазвичай виникає через те, що linux vs unix можуть означати різні речі. Яке значення не мало на увазі, факт залишається фактом - Unix був першим, а Linux з'явився пізніше. Linux народився із прагнення свободи програмного забезпечення та мобільності, натхненний підходом Unix. Можна сміливо сказати, що ми всі в боргу перед рухом вільного програмного забезпечення, тому що світ був би набагато гіршим без нього.

МІНІСТЕРСТВО ОСВІТИ І НАУКИ РОСІЙСЬКОЇ

ФЕДЕРАЦІЇ

ФЕДЕРАЛЬНА АГЕНЦІЯ З ОСВІТИ

ДЕРЖАВНИЙ ОСВІТНИЙ УСТАНОВА

ВИЩОЇ ПРОФЕСІЙНОЇ ОСВІТИ

ТАГАНРОГСЬКИЙ ДЕРЖАВНИЙ РАДІОТЕХНІЧНИЙ УНІВЕРСИТЕТ

Дисципліна «Інформатика»

"Операційна система UNIX"

Виконала: Орда-Жигуліна Д.В., гр. Е-25

Перевірив: Вишневецький В.Ю.

Таганрог 2006

Вступ

Що таке Unix 3

Де взяти безкоштовний Unix 7

Основна частина. (Опис Unix)

1. Основні поняття Unix 8

2. Файлова система 9

2.1 Типи файлів 9

3. Командний інтерпретатор 11

4. Ядро ОС UNIX 12

4.1 Загальна організація традиційного ядра ОС UNIX 13

4.2 Основні функції ядра 14

4.3 Принципи взаємодії з ядром 15

4.4 Принципи обробки переривань 17

5. Керування введенням/виводом 18

5. 1 Принципи системної буферизації введення/виведення 19

5. 2 Системні виклики для керування введенням/виводом 21

6. Інтерфейси та вхідні точки драйверів 23

6. 1 Блокові драйвери 23

6. 2 Символьні драйвери 24

6. 3 Поточні драйвери 25

7. Команди та утиліти 25

7. 1 Організація команди в ОС UNIX 26

7. 2 Перенаправлення введення/виведення та організація конвеєра 26

7. 3 Вбудовані, бібліотечні та користувацькі команди 26

7. 4 Програмування командною мовою 27

8. Засоби графічного інтерфейсу користувачів 27

8.1 Ідентифікатори користувача та групи користувачів 30

8.2 Захист файлів 32

8.3 Перспективні ОС, що підтримують ОС UNIX 33

Висновок

Основні відмінності Unix від інших OS 36

Області застосування Unix 37

Вступ

Що таке Unix

Термін Unix і недостатньо еквівалентний йому UNIX використовують у різних значеннях. Почнемо з другого термінів, як простішого. У двох словах, UNIX (саме у такій формі) - зареєстрована торгова марка, що спочатку належала корпорації AT&T, яка змінила за своє довге життя багато господарів і нині є власністю організації під назвою Open Group. Право використання імені UNIX досягається шляхом свого роду " перевірки на вошивість " - проходження тестів відповідності специфікаціям якоїсь еталонної ОС (Single Unix Standard - що у разі можна перекласти як Єдиний Стандарт на Unix). Процедура ця не тільки складна, а й дуже недешева, і тому їй зазнали лише кілька оперціонок із нині здорових, і всі вони є пропрієтарними, тобто є власність деяких корпорацій.

Серед корпорацій, які заслужили право на ім'я UNIX потім розробників/тестувальників та кров'ю (точніше, доларом) власників, можна назвати наступні:

Sun з її SunOS (більш відомою у світі під ім'ям Solaris);

IBM, що розробила систему AIX;

Hewlett-Packard – власник системи HP-UX;

IRIX – операційна компанія компанії SGI.

Крім цього, власне ім'я UNIX застосовується до систем:

True64 Unix, розроблена фірмою DEC, з ліквідацією якої перейшла до Compaq, а нині, разом з останньою, стала власністю тієї ж Hewlett-Packard;

UnixWare – власність компанії SCO (продукту злиття фірм Caldera та Santa Cruz Operation).

Будучи пропрієтарними, всі ці системи продаються за чималі (навіть за американськими масштабами) гроші. Однак це - не головна перешкода до поширення власне UNIX"ів. Бо загальною їх особливістю є прив'язка до певних апаратних платформ: AIX працює на серверах та робочих станціях IBM з процесорами Power, HP-UX - на власних машинах HP-PA (Precission Architecture) , IRIX - на графічних станціях від SGI, що несуть процесори MIPS, True64 Unix - призначена для процесорів Alpha (на жаль, в базі спочилих). Sparc, і той самий PC, що, проте, не сильно посприяло їх поширеності - внаслідок відносно слабкої підтримки нової PC-периферії.

Таким чином, UNIX – це поняття насамперед юридичне. А ось за терміном Unix закріпилося технологічне трактування. Так в побуті IT-індустрії називають все сімейство операційних систем, що походять від "первозданной" UNIX компанії AT&T, або відтворюють її функції "з чистого листа", у тому числі вільні ОС, такі як Linux, FreeBSD та інші BSD, ніякій перевірці на відповідність Single Unix Standard ніколи не піддавалися. І тому їх часто називають Unix-подібними.

Широко поширений також близький за змістом термін POSIX-сумісні системи, яким об'єднується сімейство ОС, що відповідають однойменному набору стандартів. Самі собою стандарти POSIX (Portable Operation System Interface based on uniX) розроблялися з урахуванням практики, прийнятої у Unix-системах, і тому останні є за визначенням POSIX-совместимыми. Однак це не зовсім синоніми: на сумісність зі стандартами POSIX, претендують операційні системи, пов'язані з Unix лише побічно (QNX, Syllable), або не пов'язані взагалі (аж до Windows NT/2000/XP).

Щоб прояснити питання взаємин UNIX, Unix і POSIX, доведеться трохи заглибитися в історію. Власне історія цього питання докладно розглянута у відповідному розділі книги "Вільний Unix: Linux, FreeBSD та інші" (найближчим часом виходить у видавництві БХВ-Петербург) і в статтях з історії Linux і BSD-систем.

Операційна система Unix (точніше її перший варіант) була розроблена співробітниками Bell Labs (підрозділи компанії AT&T) в 1969-1971 роках. Перші її автори - Кен Томпсон і Денніс Річі - робили це виключно для власних цілей, зокрема, для того, щоб можна було розважатися улюбленою грою StarTravel. І з низки юридичних причин сама компанія не могла використовувати її як комерційний продукт. Однак практичне застосування Unix знайшлося досить швидко. По-перше, вона використовувалася в Bell Labs для підготовки різноманітних технічної (у тому числі патентної) документації. А по-друге, на Unix базувалася комунікаційна система UUCP (Unix to Unix Copy Programm – програма копіювання з Unix до Unix).

Інша сфера застосування Unix у 70-х – початку 80-х років минулого століття виявилася зовсім незвичайною. А саме, у вихідних текстах вона поширювалася серед наукових установ, які ведуть роботи в галузі Computer Science. Метою такого поширення (воно не було цілком вільним у нинішньому розумінні, але фактично виявлялося вельми ліберальним) були: освіта та дослідження у вищевказаній галузі знань.

Найбільшу популярність здобула система BSD Unix, створена в Університеті Берклі, Каліфорнія. Яка, поступово звільняючись від пропрієтарного коду первозданної Unix, зрештою, після драматичних перипетій (докладно описаних тут), дала початок сучасним вільним BSD-системам – FreeBSD, NetBSD та іншим.

Одним із найбільш важливих результатів роботи університетських хакерів виявилося (1983 рік) впровадження в Unix підтримки протоколу TCP/IP, на якому ґрунтувалася тодішня мережа ARPANET (і яка стала основою основ сучасного Інтернету). Це стало передумовою домінування Unix у всіх сферах, пов'язаних із Всесвітньою мережею. І це виявилося наступним практичним застосуванням цього сімейства операційок - на той час про єдину Unix говорити вже не доводилося. Тому що вона, як було сказано раніше, відокремилися дві її гілки - те, що походить від первозданної UNIX (згодом вона отримала ім'я System V) та система беркліанського походження. З іншого боку, System V лягла в основу тих різноманітних пропрієтарних UNIX"ів, які, власне, і мали юридичне право претендувати на це ім'я.

Остання обставина - розгалуження колись єдиної ОС на кілька ліній, що поступово втрачають сумісність, - усупереч суперечності з одним з наріжних каменів Unix-ідеології: переносимості системи між різними платформами, та її додатків - з однієї Unix-системи в іншу. Що викликало до життя діяльність різного роду організацій, що стандартизують, що завершилася врешті-решт створенням набору стандартів POSIX, про який говорилося раніше.

Саме на стандарти POSIX спирався Лінус Торвальдс, створюючи "з нуля" (тобто не використовуючи код, що існував раніше) свою операційну систему - Linux. А та, швидко і успішно освоївши традиційні сфери застосування Unix-систем (розробка софту, комунікації, Інтернет), згодом відкрила для них і нову - настільні платформи користувача загального призначення. Що й забезпечило її популярність у народі - популярність, що перевершує таку всіх інших Unix-систем, разом узятих, як пропрієтарних, і вільних.

Далі мова піде про роботу в Unix-системах у найширшому значенні цього слова, без урахування різного роду торгових марок та інших юридичних проблем. Хоча основні приклади, що стосуються прийомів роботи, будуть взяті в галузі вільних їх реалізацій - Linux, меншою мірою FreeBSD, і ще меншою - з інших BSD-систем.

Де взяти безкоштовний Unix?

FreeBSD База – www.freebsd.org;

Звернутись можна на www.sco.com

Основна частина. (Опис Unix)

1. Основні поняття Unix

Unix базується на двох основних поняттях: "процес" та "файл". Процеси являють собою динамічний бік системи, це суб'єкти; а файли – статичну, це об'єкти дії процесів. Майже весь інтерфейс взаємодії процесів з ядром та один з одним виглядає як запис/читання файлів. Хоча треба додати такі речі, як сигнали, пам'ять, що розділяється, і семафори.

Процеси можна дуже умовно розділити на два типи - завдання та демони. Завдання - це процес, який виконує свою роботу, прагнучи якнайшвидше закінчити її і завершитися. Демон чекає на події, які він повинен обробити, обробляє події, що відбулися, і знову чекає; завершується він зазвичай за наказом іншого процесу, найчастіше його вбиває користувач, давши команду "kill номер_процесса". У цьому сенсі виходить, що інтерактивне завдання, яке обробляє введення користувача, швидше схоже на демона, ніж на завдання.

2. Файлова система

У старих Unix"ах відводилося 14 букв на ім'я, у нових це обмеження знято. У директорії крім імені файлу знаходиться його ідентефікатор inode - ціле число, що визначає номер блоку, в якому записані атрибути файлу. Серед них: номер користувача - власника файлу; номер групи, кількість посилань на файл (див. далі) дати і час створення, останньої модифікації та останнього звернення до файлу, атрибути доступу Атрибути доступу містять тип файлу (див. далі), атрибути зміни прав при запуску (див. далі) доступу до нього для господаря, одногрупника та інших читання, запис і виконання.

Кожен файл (але не директорія) може бути відомий під кількома іменами, але обов'язково лежать одному розділі. Усі посилання файл рівноправні; файл стирається, коли видаляється останнє посилання на файл. Якщо файл відкритий (для читання та/або запису), кількість посилань на нього збільшується ще на одиницю; так багато програм, що відкривають тимчасовий файл, відразу видаляють його, щоб при аварійному завершенні, коли операційна система закриває відкриті процесом файли, цей тимчасовий файл був видалений операційною системою.

Є ще одна цікава особливість файлової системи: якщо після створення файлу запис у нього йшов не поспіль, а з великими інтервалами, то для цих інтервалів місце на диску не виділяється. Таким чином сумарний об'єм файлів у розділі може бути більшим за об'єм розділу, а при видаленні такого файлу звільняється менше місця, ніж його розмір.

2.1 Типи файлів

Файли бувають таких типів:

простий файл прямого доступу;

директорія (файл, що містить імена та ідентефікатори інших файлів);

символьний лінк (рядок з ім'ям іншого файлу);

блоковий пристрій (диск або магнітна стрічка);

послідовний пристрій (термінали, послідовні та паралельні порти; диски та магнітні стрічки теж мають інтерфейс послідовного пристрою)

названий канал.

Спеціальні файли, призначені для роботи з пристроями, зазвичай зосереджені в директорії "/dev". Ось деякі з них (у номінації FreeBSD):

tty* - термінали, у т.ч.: ttyv - віртуальна консоль;

ttyd - DialIn термінал (зазвичай послідовний порт);

cuaa - DialOut лінія

ttyp – мережевий псевдо-термінал;

tty - термінал, з яким асоційовано завдання;

wd* - жорсткі диски та їх підрозділи, у т.ч.: wd - жорсткий диск;

wds - партія цього диска (названа тут "slice");

wds – розділ партиції;

fd – floppy-диск;

rwd*, rfd* - те саме, що wd* і fd*, але з послідовним доступом;

Іноді потрібно, щоб програма, запущена користувачем, мала не права користувача, що запустив її, а якісь інші. І тут встановлюється атрибут зміни прав права користувача - господаря програми. (Як приклад наведу програму, яка читає файл з питаннями та відповідями і на підставі прочитаного тестує студента, що запустив цю програму. Програма повинна мати право читати файл з відповідями, а студент, що запустив її, - ні.) Так, наприклад, працює програма passwd, з допомогою якої користувач може змінити свій пароль. Користувач може запустити програму passwd, вона може зробити зміни в системній базі даних - а користувач не може.

На відміну від DOS, в якому повне ім'я файлу виглядає як "диск:шляхом", і RISC-OS, в якій воно виглядає "-файлова_система-диск:$.шлях.ім'я" (що взагалі кажучи має свої переваги), Unix використовує прозору нотацію у вигляді "/шлях/ім'я". Корінь відраховується від розділу, з якого було завантажено ядро ​​Unix. Якщо потрібно використовувати інший розділ (а на завантажувальному розділі зазвичай знаходиться тільки найнеобхідніше для завантаження), використовується команда `mount /dev/файл_розділу директорія`. При цьому файли та піддиректорії, які раніше знаходилися в цій директорії, стають недоступними, поки розділ не буде розмонтований (природно, всі нормальні люди використовують для монтування розділів порожні директорії). Виробляти монтування та розмонтування має право тільки супервізор.

При запуску кожен процес може розраховувати, що для нього вже відкрито три файли, які йому відомі як стандартне введення stdin за дескриптором 0; стандартний висновок stdout по дескриптору 1; і стандартний висновок stderr по дескриптору 2. При реєстрації в системі, коли користувач вводить ім'я та пароль, а йому запускається shell, усі троє направлені на /dev/tty; пізніше будь-який з них може бути перенаправлений у будь-який файл.

3. Командний інтерпретатор

У Unix практично завжди входять два командні інтерпретатори - sh (shell) і csh (C-подібний shell). Крім них ще бувають bash (Bourne), ksh (Korn) та інші. Не вдаючись до подробиць, наведу загальні принципи:

Усі команди, крім зміни поточної директорії, встановлення змінних оточення (environment) та операторів структурного програмування – зовнішні програми. Ці програми зазвичай розміщуються в каталогах /bin і /usr/bin. Програми системного адміністрування - у каталогах /sbin та /usr/sbin.

Команда складається з імені програми і аргументів, що запускається. Аргументи відокремлюються від імені команди та один від одного пробілами та табуляціями. Деякі спецсимволи інтерпретуються самим shell"ом. Спецсимволами є " " ` ! $ ^ * ? | & ; (ще які?).

В одному командному рядку можна дати кілька команд. Команди можуть бути поділені; (Послідовне виконання команд), & (асинхронне одночасне виконання команд), | (Синхронне виконання, стандартний висновок stdout першої команди буде подано на стандартне введення stdin другий).

Крім того, можна брати стандартне введення з файлу, включивши як один з аргументів "файл" (файл буде обнулений) або ">>файл" (запис буде зроблено в кінець файлу).

Якщо потрібно отримати інформацію з будь-якої команди, дайте команду "man ім'я_команди". На екран це буде видаватися через програму "more" - подивіться, як з нею керуватися на вашому Unix'е командою `man more`.

4. Ядро ОС UNIX

Як і в будь-якій іншій багатокористувацькій операційній системі, що забезпечує захист користувачів один від одного та захист системних даних від будь-якого непривілейованого користувача, в ОС UNIX є захищене ядро, яке управляє ресурсами комп'ютера та надає користувачам базовий набір послуг.

Зручність та ефективність сучасних варіантів ОС UNIX не означає, що вся система, включаючи ядро, спроектована та структурована якнайкраще. ОС UNIX розвивалася протягом багатьох років (це перша в історії операційна система, яка продовжує завойовувати популярність у такому зрілому віці – вже понад 25 років). Звичайно, нарощувалися можливості системи, і, як це часто буває у великих системах, якісні покращення структури ОС UNIX не встигали за зростанням її можливостей.

В результаті, ядро ​​більшості сучасних комерційних варіантів ОС UNIX є не дуже чітко структурованим монолітом великого розміру. З цієї причини програмування на рівні ядра ОС UNIX продовжує залишатися мистецтвом (якщо не вважати відпрацьованою та зрозумілою технологією розробки драйверів зовнішніх пристроїв). Ця недостатня технологічність організації ядра ОС UNIX багатьох не задовольняє. Звідси прагнення повного відтворення середовища ОС UNIX за зовсім іншого організації системи.

Через найбільшу поширеність часто обговорюється ядро ​​UNIX System V (можна вважати його традиційним).

4.1 Загальна організація традиційного ядра ОС UNIX

Одне з основних досягнень ОС UNIX полягає в тому, що система має властивість високої мобільності. Сенс цієї якості у тому, що вся операційна система, включаючи її ядро, порівняно просто переноситься різні апаратні платформи. Усі частини системи, крім ядра, є повністю машинно-незалежними. Ці компоненти акуратно написані мовою Сі, і для їх перенесення на нову платформу (принаймні в класі 32-розрядних комп'ютерів) потрібна лише перекомпіляція вихідних текстівкоди цільового комп'ютера.

Звичайно, найбільші проблеми пов'язані з ядром системи, яке повністю приховує специфіку комп'ютера, що використовується, але саме залежить від цієї специфіки. В результаті продуманого поділу машинно-залежних і машинно-незалежних компонентів ядра (мабуть, з точки зору розробників операційних систем, у цьому полягає найвище досягнення розробників традиційного ядра ОС UNIX) вдалося досягти того, що основна частина ядра не залежить від архітектурних особливостей цільової платформи. написана повністю мовою Сі і для перенесення на нову платформу потребує лише перекомпіляції.

Однак порівняно невелика частина ядра є машинно-залежною і написана на суміші мови Сі та мови асемблера цільового процесора. При перенесенні системи на нову платформу потрібно переписування цієї частини ядра з використанням мови асемблера та врахуванням специфічних характеристик цільової апаратури. Машинно-залежні частини ядра добре ізольовані від основної машинно-незалежної частини, і за хорошому розумінні призначення кожного машинно-залежного компонента переписування машинно-залежної частини є переважно технічним завданням (хоч і вимагає високої програмістської кваліфікації).

Машинно-залежна частина традиційного ядра ОС UNIX включає такі компоненти:

розкрутка та ініціалізація системи на низькому рівні (поки що це залежить від особливостей апаратури);

первинна обробка внутрішніх та зовнішніх переривань;

керування пам'яттю (у тій частині, що відноситься до особливостей апаратної підтримки віртуальної пам'яті);

перемикання контексту процесів між режимами користувача та ядра;

пов'язані з особливостями цільової платформи частини драйверів пристроїв.

4.2 Основні функції ядра

До основних функцій ядра ОС UNIX прийнято відносити такі:

(a) Ініціалізація системи – функція запуску та розкручування. Ядро системи забезпечує засіб розкручування (bootstrap), який забезпечує завантаження повного ядра на згадку про комп'ютера і запускає ядро.

(b) Керування процесами та нитками - функція створення, завершення та відстеження існуючих процесів та ниток ("процесів", що виконуються на спільній віртуальній пам'яті). Оскільки ОС UNIX є мультипроцесною операційною системою, ядро ​​забезпечує поділ між запущеними процесами часу процесора (чи процесорів у мультипроцесорних системах) та інших ресурсів комп'ютера створення зовнішнього відчуття те, що процеси реально виконуються в паралель.

(c) Управління пам'яттю – функція відображення практично необмеженої віртуальної пам'яті процесів у фізичну оперативну пам'ять комп'ютера, яка має обмежені розміри. Відповідний компонент ядра забезпечує використання одних і тих же областей оперативної пам'яті декількома процесами з використанням зовнішньої пам'яті.

(d) Управління файлами – функція, що реалізує абстракцію файлової системи, – ієрархії каталогів та файлів. Файлові системи UNIX підтримують кілька типів файлів. Деякі файли можуть містити дані у форматі ASCII, інші відповідатимуть зовнішнім пристроям. У файловій системі зберігаються об'єктні файли, файли і т.д. Файли зазвичай зберігаються на пристроях зовнішньої пам'яті; доступ до них забезпечується засобами ядра. У світі UNIX існує кілька типів організації файлових систем. Сучасні варіанти ОС UNIX одночасно підтримують більшість типів файлових систем.

(e) Комунікаційні засоби - це функція, що забезпечує можливості обміну даними між процесами, що виконуються всередині одного комп'ютера (IPC - Inter-Process Communications), між процесами, що виконуються в різних вузлах локальної або глобальної мережі передачі даних, а також між процесами та драйверами зовнішніх пристроїв. .

(f) Програмний інтерфейс - функція, що забезпечує доступ до можливостей ядра з боку процесів користувача на основі механізму системних викликів, оформлених у вигляді бібліотеки функцій.

4.3 Принципи взаємодії з ядром

У будь-якій операційній системі підтримується деякий механізм, який дозволяє програмам користувача звертатися за послугами ядра ОС. В операційних системах найвідомішої радянської обчислювальної машини БЭСМ-6 відповідні засоби спілкування з ядром називалися екстракодами, в операційних системах IBM вони називалися системними макрокомандами тощо. У ОС UNIX такі кошти називаються системними викликами.

Назва не змінює сенс, який полягає в тому, що для звернення до функцій ядра ОС використовуються "спеціальні команди" процесора, при виконанні яких виникає особливе внутрішнє переривання процесора, що переводить його в режим ядра (у більшості сучасних ОС цей вид переривань називається trap - пастка). При обробці таких переривань (дешифрації) ядро ​​ОС розпізнає, що насправді переривання є запитом до ядра з боку програми користувача на виконання певних дій, вибирає параметри звернення і обробляє його, після чого виконує "повернення з переривання", відновлюючи нормальне виконання користувальницької програми .

Зрозуміло, що конкретні механізми порушення внутрішніх переривань з ініціативи програми користувача різняться в різних апаратних архітектурах. Оскільки ОС UNIX прагне забезпечити середовище, в якому користувацькі програми могли б бути повністю мобільні, був потрібний додатковий рівень, що приховує особливості конкретного механізму порушення внутрішніх переривань. Цей механізм забезпечується так званою бібліотекою системних дзвінків.

Для користувача бібліотека системних викликів є звичайною бібліотекою заздалегідь реалізованих функцій системи програмування мови Сі. При програмуванні мовою Сі використання будь-якої функції з бібліотеки системних викликів нічим не відрізняється від використання будь-якої власної або бібліотечної Си-функції. Однак усередині будь-якої функції конкретної бібліотеки системних викликів міститься код, що є, взагалі кажучи, специфічним для апаратної платформи.

4.4 Принципи обробки переривань

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

Якщо говорити не дуже точно і конкретно, суть прийнятого на сьогодні механізму полягає в тому, що кожному можливому перериванню процесора (чи то внутрішнє чи зовнішнє переривання) відповідає деяка фіксована адреса фізичної оперативної пам'яті. У той момент, коли процесору дозволяється перерватися через наявність внутрішньої або зовнішньої заявки на переривання, відбувається апаратна передача управління на комірку фізичної оперативної пам'яті з відповідною адресою - зазвичай адреса цієї комірки називається "вектором переривання" (як правило, заявки на внутрішнє переривання, т е. заявки, що надходять безпосередньо від процесора, задовольняються негайно).

Справа операційної системи - розмістити у відповідних осередках оперативної пам'яті програмний код, що забезпечує початкову обробку переривання та ініціює повну обробку.

В основному ОС UNIX дотримується загального підходу. У векторі переривання, що відповідає зовнішньому перериванню, тобто. переривання від деякого зовнішнього пристрою, містяться команди, що встановлюють рівень виконання процесора (рівень виконання визначає, які зовнішні переривання процесор повинен реагувати негайно) і здійснюють перехід на програму повної обробки переривання у відповідному драйвері пристрою. Для внутрішнього переривання (наприклад, переривання з ініціативи програми користувача за відсутності в основній пам'яті потрібної сторінки віртуальної пам'яті, у разі виняткової ситуації у програмі користувача тощо) чи переривання від таймера у векторі переривання міститься перехід відповідну програму ядра ОС UNIX.

5. Керування введенням/виводом

Традиційно в ОС UNIX виділяються три типи організації вводу/виводу та, відповідно, три типи драйверів. Блокове введення/виведення головним чином призначене для роботи з каталогами та звичайними файлами файлової системи, які на базовому рівні мають блокову структуру. На рівні користувача можна працювати з файлами, прямо відображаючи їх в сегменти віртуальної пам'яті. Ця можливість розглядається як верхній рівень блокового введення/виводу. На нижньому рівні блокове введення/виведення підтримується блочними драйверами. Блокове введення/виведення, крім того, підтримується системною буферизацією.

Символьне введення/виведення служить для прямого (без буферизації) виконання обмінів між адресним простором користувача та відповідним пристроєм. Спільною для всіх символьних драйверів підтримкою ядра є забезпечення функцій пересилання даних між користувацькими та ядерними адресними просторами.

Нарешті, потокове введення/виведення схоже на символьне введення/виведення, але через наявність можливості включення в потік проміжних обробних модулів має істотно більшу гнучкість.

5. 1 Принципи системної буферизації вводу/виводу

Традиційним способом зниження накладних витрат при виконанні обмінів із пристроями зовнішньої пам'яті, що мають блокову структуру, є буферизація блокового вводу/виводу. Це означає, що будь-який блок пристрою зовнішньої пам'яті зчитується насамперед деякий буфер області основної пам'яті, званої в ОС UNIX системним кешем, і вже звідти повністю або частково (залежно від виду обміну) копіюється у відповідний простір користувача.

Принципами організації традиційного механізму буферизації є, по-перше, те, що копія вмісту блоку утримується в системному буфері до тих пір, поки не виникне необхідність її заміщення через брак буферів (для організації політики заміщення використовується різновид алгоритму LRU). По-друге, під час запису будь-якого блоку пристрою зовнішньої пам'яті реально виконується лише оновлення (чи освіту і заповнення) буфера кеша. Дійсний обмін з пристроєм виконується або при виштовхуванні буфера внаслідок заміщення його вмісту, або при виконанні спеціального системного виклику sync (або fsync), який підтримується спеціально для насильницького виштовхування у зовнішню пам'ять оновлених буферів кешу.

Ця традиційна схема буферизації увійшла у суперечність із розвиненими в сучасних варіантах ОС UNIX засобами управління віртуальною пам'яттю і особливо з механізмом відображення файлів у сегменти віртуальної пам'яті. Тому в System V Release 4 з'явилася нова схема буферизації, що поки використовується паралельно зі старою схемою.

Суть нової схеми у тому, що лише на рівні ядра фактично відтворюється механізм відображення файлів у сегменти віртуальної пам'яті. По-перше, нагадаємо про те, що ядро ​​ОС UNIX дійсно працює у своїй віртуальній пам'яті. Ця пам'ять має складнішу, але принципово таку ж структуру, що і користувальницька віртуальна пам'ять. Іншими словами, віртуальна пам'ять ядра є сегментно-сторінковою, і нарівні з віртуальною пам'яттю для користувача процесів підтримується загальною підсистемою управління віртуальною пам'яттю. З цього випливає, по-друге, що будь-яка функція, що забезпечується ядром для користувачів, може бути забезпечена одними компонентами ядра для інших його компонентів. Зокрема, це стосується і можливостей відображення файлів у сегменти віртуальної пам'яті.

Нова схема буферизації в ядрі ОС UNIX головним чином ґрунтується на тому, що для організації буферизації можна не робити майже нічого спеціального. Коли один з процесів користувача відкриває не відкритий до цього часу файл, ядро ​​утворює новий сегмент і підключає до цього сегменту відкривається файл. Після цього (незалежно від того, чи користувальницький процес працюватиме з файлом у традиційному режимі з використанням системних викликів read і write або підключить файл до сегменту своєї віртуальної пам'яті) на рівні ядра робота буде здійснюватися з тим ядерним сегментом, до якого підключений файл на рівні ядра. Основна ідея нового підходу полягає в тому, що усувається розрив між управлінням віртуальною пам'яттю та загальносистемною буферизацією (це потрібно було б зробити давно, оскільки очевидно, що основну буферизацію в операційній системі має робити компонент управління віртуальною пам'яттю).

Чому ж не можна відмовитись від старого механізму буферизації? Вся справа в тому, що нова схема передбачає наявність деякої безперервної адресації всередині об'єкта зовнішньої пам'яті (має існувати ізоморфізм між відображеним і відображеним об'єктами). Однак, при організації файлових систем ОС UNIX досить складно розподіляє зовнішню пам'ять, що особливо стосується i-вузлів. Тому деякі блоки зовнішньої пам'яті доводиться вважати ізольованими, і для них вигідніше використовувати стару схему буферизації (хоча, можливо, у завтрашніх варіантах UNIX і вдасться повністю перейти до уніфікованої нової схеми).

5. 2 Системні виклики для керування введенням/виводом

Для доступу (тобто для отримання можливості подальшого виконання операцій введення/виводу) до файлу будь-якого виду (включаючи спеціальні файли) користувальницький процес повинен здійснити попереднє підключення до файлу за допомогою одного із системних викликів open, creat, dup або pipe.

Послідовність дій системного виклику open (pathname, mode):

аналізується несуперечність вхідних параметрів (головним чином, які стосуються прапорів режиму доступу до файлу);

виділяється або знаходиться простір для описувача файлу у системній області даних процесу (u-області);

у загальносистемній області виділяється чи знаходиться існуючий простір для розміщення системного описника файлу (структури file);

провадиться пошук в архіві файлової системи об'єкта з ім'ям "pathname" і утворюється або виявляється описувач файлу рівня файлової системи (vnode у термінах UNIX V System 4);

Виконується зв'язування vnode з раніше утвореною структурою файлу.

Системні виклики open та creat (майже) функціонально еквівалентні. Будь-який існуючий файл можна відкрити за допомогою системного виклику creat, і будь-який новий файл можна створити за допомогою системного виклику Open. Однак стосовно системного виклику creat важливо підкреслити, що у разі свого природного застосування (для створення файлу) цей системний виклик створює новий елемент відповідного каталогу (відповідно до заданого значення pathname), а також створює і відповідним чином ініціалізує новий i-вузол.

Нарешті, системний виклик dup (duplicate – скопіювати) призводить до утворення нового дескриптора вже відкритого файлу. Цей специфічний для ОС UNIX системний виклик служить виключно з метою перенаправлення введення/виведення). Його виконання полягає в тому, що в u-області системного простору користувача процесу утворюється новий описувач відкритого файлу, що містить новостворений дескриптор файлу (ціле число), але посилається на вже існуючу загальносистемну структуру file і містить ті самі ознаки і прапори, які відповідають відкритого файлу-зразка.

Іншими важливими системними викликами є системні виклики read та write. Системний виклик read виконується так:

у загальносистемній таблиці файлів знаходиться дескриптор зазначеного файлу, і визначається, чи законне звернення від цього процесу до цього файлу у вказаному режимі;

на деякий (короткий) час встановлюється синхронізаційне блокування на vnode даного файлу (вміст описувача не повинен змінюватися в критичні моменти операції читання);

виконується власне читання з використанням старого або нового механізму буферизації, після чого дані копіюються, щоб стати доступними в адресному просторі користувача.

Операція запису виконується аналогічно, але змінює вміст буфера буферного пула.

Системний виклик close призводить до того, що драйвер обриває зв'язок з відповідним процесом користувача і (у разі останнього за часом закриття пристрою) встановлює загальносистемний прапор "драйвер вільний".

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

Природно, оскільки драйвери головним чином призначені для управління зовнішніми пристроями, програмний код драйвера повинен містити відповідні засоби для обробки переривань від пристрою. Виклик індивідуальної програми обробки переривань драйвері відбувається з ядра операційної системи. Подібним чином драйвері може бути оголошений вхід "timeout", до якого звертається ядро ​​при закінченні раніше замовленого драйвером часу (такий тимчасовий контроль є необхідним при керуванні не надто інтелектуальними пристроями).

Загальна схема інтерфейсної організації драйверів показано малюнку 3.5. Як свідчить цей малюнок, з погляду інтерфейсів і загальносистемного управління розрізняються два види драйверів - символьні та блокові. З погляду внутрішньої організації виділяється ще один вид драйверів – потокові (stream) драйвери. Проте за зовнішнім інтерфейсом потокові драйвери не відрізняються від символьних.

6. Інтерфейси та вхідні точки драйверів

6. 1 Блокові драйвери

Блокові драйвери призначаються обслуговування зовнішніх пристроїв з блокової структурою (магнітних дисків, стрічок тощо.) і від інших тим, що вони розробляються і виконуються з допомогою системної буферизації. Іншими словами, такі драйвери завжди працюють через системний буферний пул. Як видно на малюнку 3.5, будь-яке звернення до блочного драйвера для читання або запису завжди проходить через попередню обробку, яка полягає в спробі знайти копію потрібного блоку буферному пулі.

Якщо копія необхідного блоку не знаходиться в буферному пулі або якщо з якоїсь причини потрібно замінити вміст деякого оновленого буфера, ядро ​​ОС UNIX звертається до процедури strategy відповідного блокового драйвера. Strategy забезпечує стандартний інтерфейс між ядром та драйвером. З використанням бібліотечних підпрограм, призначених для написання драйверів, процедура strategy може організовувати черги обмінів з пристроєм, наприклад з метою оптимізації руху магнітних головок на диску. Усі обміни, які виконуються блочним драйвером, виконуються з буферною пам'яттю. Перепис потрібної інформації в пам'ять відповідного процесу користувача проводиться програмами ядра, завідувачами управління буферами

6. 2 Символьні драйвери

Символьні драйвери призначені для обслуговування пристроїв, обміни з якими виконуються посимвольно, або рядками символів змінного розміру. Типовим прикладом символьного пристрою є принтер, який приймає один символ за один обмін.

Символьні драйвери не використовують системну буферизацію. Вони безпосередньо копіюють дані з пам'яті процесу користувача при виконанні операцій запису або в пам'ять користувача процесу при виконанні операцій читання, використовуючи власні буфера.

Слід зазначити, що можна забезпечити символьний інтерфейс для блокового пристрою. У цьому випадку блочний драйвер використовує додаткові можливості процедури strategy, що дозволяють обмінюватись без застосування системної буферизації. Для драйвера, що має одночасно блоковий і символьний інтерфейс, у файловій системі заводиться два спеціальні файли, блоковий і символьний. При кожному зверненні драйвер отримує інформацію про те, як він використовується.

6. 3 Поточні драйвери

Основним призначенням механізму потоків (streams) є підвищення рівня модульності та гнучкості драйверів зі складною внутрішньою логікою (найбільше це стосується драйверів, що реалізують розвинені мережеві протоколи). Специфікою таких драйверів є те, що більшість програмного коду не залежить від особливостей апаратного пристрою. Понад те, часто виявляється вигідно по-різному комбінувати частини програмного коду.

Все це призвело до появи потокової архітектури драйверів, які є двонаправленим конвеєром обробних модулів. На початку конвеєра (найближче до процесу користувача) знаходиться заголовок потоку, до якого перш за все надходять звернення з ініціативи користувача. Наприкінці конвеєра (ближче до пристрою) знаходиться звичайний драйвер пристрою. У проміжку може розташовуватися довільне число модулів, кожен з яких оформляється відповідно до обов'язкового потокового інтерфейсу.

7. Команди та утиліти

Під час інтерактивної роботи у середовищі ОС UNIX користуються різноманітними утилітами чи зовнішніми командами мови shell. Багато цих утиліт є не менш складними програмами, ніж сам командний інтерпретатор (і між іншим, командний інтерпретатор мови shell сам є однією з утиліт, яку можна викликати з командного рядка).

7. 1 Організація команди в ОС UNIX

Для створення нової команди потрібно просто дотримуватися правил програмування мовою Сі. Кожна правильно оформлена Сі-програма починає виконання з функції main. Ця "напівсистемна" функція має стандартний інтерфейс, що є основою організації команд, які можна викликати в середовищі shell. Зовнішні команди виконуються інтерпретатором shell за допомогою зв'язування системних викликів fork та одного з варіантів exec. До параметрів системного виклику exec входить набір текстових рядків. Цей набір текстових рядків передається на вхід функції main програми, що запускається.

Більш точно, функція main отримує два параметри - argc (число текстових рядків, що передаються) і argv (покажчик на масив покажчиків на текстові рядки). Програма, що претендує на її використання в якості команди shell, повинна мати точно визначену зовнішнім інтерфейсом(параметри зазвичай вводяться з терміналу) і має контролювати та правильно розбирати вхідні параметри.

Крім того, щоб відповідати стилю shell, така програма не повинна сама перевизначати файли, що відповідають стандартному вводу, стандартному виводу та стандартному виводу помилок. Тоді команді може звичайним чином перенаправлятися введення/виведення, і вона може включатися в конвеєри.

7. 2 Перенаправлення введення/виводу та організація конвеєра

Як видно з останньої пропозиції попереднього пункту, для забезпечення можливостей перенаправлення вводу/виводу та організації конвеєра під час програмування команд не потрібно робити нічого спеціального. Достатньо просто не чіпати три початкові дескриптори файлів і правильно працювати з цими файлами, а саме, робити висновок у файл з дескриптором stdout, вводити дані з файлу stdin і виводити повідомлення про помилки у файл stderror.

7. 3 Вбудовані, бібліотечні та користувацькі команди

Вбудовані команди є частиною програмного коду командного інтерпретатора. Вони виконуються як підпрограми інтерпретатора, їх неможливо замінити чи перевизначити. Синтаксис та семантика вбудованих команд визначено у відповідній командній мові.

Бібліотечні команди є частиною системного програмного забезпечення. Це набір програм, що виконуються (утиліт), що поставляються разом з операційною системою. Більшість цих програм (таких як vi, emacs, grep, find, make і т.д.) виключно корисно на практиці, але їх розгляд знаходиться за межами цього курсу (щодо редакторів vi та emacs та утиліти підтримки цілісності програмних файлів make існують окремі товсті книги).

Користувальницькою командою є будь-яка програма, організована відповідно до вимог, викладених у Таким чином, будь-який користувач ОС UNIX може необмежено розширювати репертуар зовнішніх команд своєї командної мови (наприклад, можна написати власний командний інтерпретатор).

7. 4 Програмування командною мовою

Будь-який із згадуваних варіантів мови shell у принципі можна використовувати як мову програмування. Серед користувачів ОС UNIX є багато людей, які пишуть на shell цілком серйозні програми. Для програмування краще використовувати мови програмування (Сі, Сі++, Паскаль тощо), а чи не командні мови.

8. Засоби графічного інтерфейсу користувачів

Хоча багато професійних програмістів, що працюють у середовищі ОС UNIX, і сьогодні вважають за краще користуватися традиційними малими засобами взаємодії з системою, широке поширення щодо недорогих кольорових графічних терміналів з високою якістю дозволу призвело до того, що у всіх сучасних варіантах ОС UNIX підтримуються графічні інтерфейси користувача з системою , а користувачам надаються інструментальні засоби для розробки графічних інтерфейсів з програмами, що розробляються ними. З точки зору кінцевого користувача засоби графічного інтерфейсу, що підтримується в різних варіантах ОС UNIX, та й інших системах (наприклад, MS Windows або Windows NT), приблизно однакові за своїм стилем.

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

По-друге, у всіх сучасних різновидах графічного інтерфейсу підтримується керування мишею. У випадку ОС UNIX часто виявляється, що звичайною клавіатурою терміналу користуються лише при переході до традиційного рядкового інтерфейсу (хоча в більшості випадків принаймні в одному вікні терміналу працює один із командних інтерпретаторів сімейства shell).

По-третє, таке поширення "мишачого" стилю роботи виявляється можливим за рахунок використання інтерфейсних засобів, заснованих на піктограмах (icons) та меню. У більшості випадків, програма, що працює в деякому вікні, пропонує користувачеві вибрати будь-яку функцію, що виконується, або шляхом відображення у вікні набору символічних образів можливих функцій (піктограм), або за допомогою пропозиції багаторівневого меню. У будь-якому випадку для подальшого вибору виявляється достатнім керування курсором відповідного вікна за допомогою миші.

Нарешті, сучасні графічні інтерфейси мають "дружність по відношенню до користувача", забезпечуючи можливість негайного отримання інтерактивної підказки з будь-якого приводу. (Напевно, правильніше було б сказати, що добрим стилем програмування з використанням графічних інтерфейсів є стиль, у якому такі підказки реально забезпечуються.)

Після перерахування всіх цих загальних властивостей сучасних засобів графічного інтерфейсу може виникнути природне питання: Якщо області графічних інтерфейсів існує така однаковість, що особливе може бути сказано з приводу графічних інтерфейсів серед ОС UNIX? Відповідь досить проста. Так, кінцевий користувач дійсно в будь-якій сьогоднішній системі має справу приблизно з тим самим набором інтерфейсних можливостей, але в різних системах ці можливості досягаються по-різному. Як завжди, перевагою ОС UNIX є наявність стандартизованих технологій, що дозволяють створювати мобільні програми з графічними інтерфейсами.

8. Принципи захисту

Оскільки ОС UNIX із самого свого зародження замислювалася як розрахована на багато користувачів операційна система, в ній завжди була актуальна проблема авторизації доступу різних користувачів до файлів файлової системи. Під авторизацією доступу розуміються дії системи, які допускають або не допускають доступ даного користувача до файлу в залежності від прав доступу користувача та обмежень доступу, встановлених для файлу. Схема авторизації доступу, застосована в ОС UNIX, настільки проста і зручна і водночас настільки потужна, що стала фактичним стандартом сучасних операційних систем (які не претендують на якості систем із багаторівневим захистом).

8.1 Ідентифікатори користувача та групи користувачів

З кожним виконуваним процесом в ОС UNIX пов'язуються реальний ідентифікатор користувача (real user ID), ідентифікатор користувача (effective user ID) і збережений ідентифікатор користувача (saved user ID). Всі ці ідентифікатори встановлюються за допомогою системного виклику setuid, який можна виконувати лише у режимі суперкористувача. Аналогічно, з кожним процесом зв'язуються три ідентифікатори групи користувачів - real group ID, effective group ID та saved group ID. Ці ідентифікатори встановлюються привілейованим системним викликом setgid.

При вході користувача в систему програма login перевіряє, що користувач зареєстрований у системі і знає правильний пароль (якщо він встановлений), утворює новий процес і запускає в ньому потрібний для цього користувача shell. Але перед цим login встановлює для новоствореного процесу ідентифікатори користувача та групи, використовуючи для цього інформацію, що зберігається у файлах /etc/passwd та /etc/group. Після того, як з процесом пов'язані ідентифікатори користувача та групи, для цього починають діяти обмеження для доступу до файлів. Процес може отримати доступ до файлу або виконати його (якщо файл містить програму) тільки в тому випадку, якщо обмеження доступу, що зберігаються при файлі, дозволяють це зробити. Пов'язані з процесом ідентифікатори передаються створюваним ним процесам, поширюючи ними самі обмеження. Однак у деяких випадках процес може змінити свої права за допомогою системних викликів setuid та setgid, а іноді система може змінити права доступу процесу автоматично.

Розглянемо, наприклад, таку ситуацію. У файл /etc/passwd заборонено запис усім, крім суперкористувача (суперкористувач може писати в будь-який файл). Цей файл також містить паролі користувачів і кожному користувачеві дозволяється змінювати свій пароль. Є спеціальна програма/bin/passwd, що змінює паролі. Однак користувач не може це зробити навіть за допомогою цієї програми, оскільки запис у файл /etc/passwd заборонено. У системі UNIX ця проблема вирішується в такий спосіб. При файлі може бути вказано, що при його запуску повинні встановлюватися ідентифікатори користувача та/або групи. Якщо користувач запитує виконання такої програми (за допомогою системного виклику exec), для відповідного процесу встановлюються ідентифікатор користувача, відповідний ідентифікатору власника виконуваного файлу та/або ідентифікатор групи цього власника. Зокрема, при запуску програми /bin/passwd процес отримає ідентифікатор суперкористувача, і програма зможе зробити запис файлу /etc/passwd.

І для ідентифікатора користувача, і для ідентифікатора групи реальний ID є істинним ідентифікатором, а ID, що діє - ідентифікатором поточного виконання. Якщо поточний ідентифікатор користувача відповідає суперкористувачу, цей ідентифікатор і ідентифікатор групи можуть бути перевстановлені в будь-яке значення системними викликами setuid і setgid. Якщо поточний ідентифікатор користувача відрізняється від ідентифікатора суперкористувача, то виконання системних викликів setuid і setgid призводить до заміни поточного ідентифікатора істинним ідентифікатором (користувача або групи відповідно).

8.2 Захист файлів

Як і прийнято в розрахованій на багато користувачів операційній системі, в UNIX підтримується одноманітний механізм контролю доступу до файлів і довідникам файлової системи. Будь-який процес може отримати доступ до деякого файлу в тому і тільки в тому випадку, якщо права доступу, описані під час файлу, відповідають можливостям цього процесу.

Захист файлів від несанкціонованого доступу в ОС UNIX ґрунтується на трьох фактах. По-перше, з будь-яким процесом, що створює файл (або довідник), асоційований деякий унікальний у системі ідентифікатор користувача (UID – User Identifier), який надалі можна трактувати як ідентифікатор власника новоствореного файлу. По-друге, з кожним процесом, який намагається отримати деякий доступ до файлу, пов'язана пара ідентифікаторів - поточні ідентифікатори користувача та його групи. По-третє, кожному файлу однозначно відповідає його описник – i-вузол.

Будь-якому використаному у файловій системі i-вузлу завжди однозначно відповідає один і лише один файл. I-вузол містить досить багато різноманітної інформації (більша її частина доступна користувачам через системні виклики stat і fstat), і серед цієї інформації знаходиться частина, що дозволяє файловій системі оцінити правомочність доступу даного процесу до цього файлу в потрібному режимі.

Загальні принципи захисту однакові для всіх існуючих варіантів системи: Інформація i-вузла включає UID та GID поточного власника файлу (негайно після створення файлу ідентифікатори його поточного власника встановлюються відповідними діючим ідентифікатором процесу-творця, але надалі можуть бути змінені системними викликами) . Крім того, в i-вузлі файлу зберігається шкала, в якій зазначено, що може робити з файлом користувач - його власник, що можуть робити з файлом користувачі, що входять до тієї ж групи користувачів, що і власник, і що можуть робити з файлом інші користувачі. Дрібні деталі реалізації різних випадках системи різняться.

8.3 Перспективні ОС, що підтримують ОС UNIX

Мікроядро - це мінімальна стрижнева частина операційної системи, що служить основою модульних і переносимих розширень. Очевидно, більшість операційних систем наступного покоління володітимуть мікроядрами. Однак є безліч різних думок щодо того, як слід організовувати служби операційної системи по відношенню до мікроядра: як проектувати драйвери пристроїв, щоб досягти найбільшої ефективності, але зберегти функції драйверів максимально незалежними від апаратури; чи слід виконувати операції, що не стосуються ядра, у просторі ядра або у просторі користувача; варто зберігати програми наявних підсистем (наприклад, UNIX) або краще відкинути все і почати з нуля.

У широке вжиток поняття мікроядра ввела компанія Next, в операційній системі якої використовувалося мікроядро Mach. Невелике привілейоване ядро ​​цієї ОС, навколо якого розташовувалися підсистеми, що виконуються в режимі користувача, теоретично мало забезпечити небувалу гнучкість і модульність системи. Але на практиці ця перевага була дещо знецінена наявністю монолітного сервера, що реалізує операційну систему UNIX BSD 4.3, яку компанія Next вибрала як оболонку мікроядра Mach. Однак опора на Mach дала можливість включити в систему засоби передачі повідомлень та ряд об'єктно-орієнтованих сервісних функцій, на основі яких вдалося створити елегантний інтерфейс кінцевого користувача з графічними засобами конфігурування мережі, системного адміністрування та розробки програмного забезпечення.

Наступною мікроядерною операційною системою була Windows NT компанії Microsoft, в якій ключовою перевагою використання мікроядра мала стати не тільки модульність, а й переносимість. (Зауважимо, що немає одностайної думки з приводу того, чи слід насправді відносити NT до мікроядерних ОС.) ОС NT була побудована таким чином, щоб її можна було застосовувати в одно- і мультипроцесорних системах, заснованих на процесорах Intel, Mips та Alpha (і тих, які прийдуть слідом за ними). Оскільки в середовищі NT повинні були виконуватися програми, написані для DOS, Windows, OS/2 та систем, сумісних зі стандартами Posix, компанія Microsoft використовувала властиву мікроядерному підходу модульність для створення загальної структури NT, що не повторює жодну з операційних систем. Кожна операційна система емулюється у вигляді окремого модуля або підсистеми.

Пізніше мікроядерні архітектури операційних систем були оголошені компаніями Novell/USL, Open Software Foundation (OSF), IBM, Apple та іншими. Одним із основних конкурентів NT в області мікроядерних ОС є Mach 3.0, система, створена в університеті Карнегі-Меллон, яку як IBM, так і OSF взялися довести до комерційного вигляду. (Компанія Next як основа для NextStep поки використовує Mach 2.5, але також уважно придивляється до Mach 3.0.) Іншим конкурентом є мікроядро Chorus 3.0 компанії Chorus Systems, обране USL як основа нових реалізацій ОС UNIX. Деяке мікроядро використовуватиметься в SpringOS фірми Sun, об'єктно-орієнтованому наступнику ОС Solaris (якщо, звичайно, Sun доведе роботу над SpringOS до кінця). Очевидною є тенденція до переходу від монолітних до мікроядерних систем (цей процес не є прямолінійним: компанія IBM зробила крок назад і відмовилася від переходу до мікроядерної технології). До речі, це зовсім не новина для компаній QNX Software Systems і Unisys, які вже протягом декількох років випускають мікроядерні операційні системи, що користуються успіхом. ОС QNX має попит на ринку систем реального часу, а CTOS фірми Unisys популярна в галузі банківської справи. В обох системах успішно використана модульність, властива мікроядерним ОС.

Висновок

Основні відмінності Unix від інших OS

Unix складається з ядра з включеними до нього драйверами та з утиліт (зовнішніх по відношенню до ядра програм). Якщо треба змінити конфігурацію (додати пристрій, змінити порт або переривання), то ядро ​​перезбирають (перелінковують) з об'єктних модулів або (напр., FreeBSD) з вихідних. Це не зовсім правильно. Деякі параметри можна поправити без перескладання. Існують також loadable kernel modules.

У протилежність Unix" у Windows (якщо не уточнюється, яка, то маються на увазі 3.11, 95 і NT) і OS/2 при завантаженні фактично на ходу прилінковують драйвери. При цьому компактність зібраного ядра і повторне використання загального коду на порядок нижче, ніж у Unix Крім того, при незмінній конфігурації системи ядро ​​Unix без переробки (потрібно змінити тільки стартову частину BIOS) може бути записаний в ПЗУ і виконуватися _не_завантажуючись_ в ОЗУ. пам'ять, не звільняються на диск.

Unix - найбільш багатоплатформна OS. WindowsNT намагається наслідувати його, але поки це погано вдається - після відмови від MIPS і POWER-PC, W"NT залишилися всього на двох платформах - традиційна i*86 і DEC Alpha. Переносність програм з однієї версії Unix на іншу обмежена. Неакуратно написана програма , що не враховує відмінностей у реалізаціях Unix, що робить необґрунтовані припущення типу "змінна integer повинна займати чотири байти" може зажадати серйозної переробки, але все одно це набагато легше, ніж наприклад перенести з OS/2 на NT.

Області застосування Unix

Unix використовується як як сервер, так і робочої станції. У номінації серверів із ним конкурують MS WindowsNT, Novell Netware, IBM OS/2 Warp Connect, DEC VMS та операційні системи мейнфреймів. Кожна система має свою область застосування, в якій вона краща за інших.

WindowsNT - для адміністраторів, які віддають перевагу зручному інтерфейсу над економним витрачанням ресурсів і високій продуктивності.

Netware - для мереж, де необхідна висока продуктивність файлового і принтерного сервісу і менш важливі інші услуги. Головний недолік - на сервері Netware важко запускати програми.

OS/2 хороша там, де потрібний "легкий" сервер додатків. Ресурсів вимагає менше ніж NT, в управлінні гнучкіше (хоча в налаштуванні може і складніше), а багатозадачність дуже хороша. Авторизація та розмежування прав доступу не реалізовані на рівні ОС, що з лишком окупається реалізацією на рівні додатків-серверів. (Втім, часто інші OS роблять те саме). Багато станцій FIDOnet і BBS створено з урахуванням OS/2.

VMS - потужний, нічим не поступається Unix"ам (а багато в чому і перевершує його) сервер додатків, але тільки для платформ VAX і Alpha фірми DEC.

Мейнфрейми - для обслуговування дуже великої кількості користувачів (близько кількох тисяч). Але робота цих користувачів зазвичай організована як не клиент-серверного взаємодії, а вигляді хост-терминального. Термінал у цій парі скоріш не клієнт, а сервер (Світ Internet, N3 за 1996-й рік). До переваг мейнфреймів треба віднести більш високу захищеність і стійкість до збоїв, а до недоліків - ціну, що відповідає цим якостям.

Unix вдалий для кваліфікованого (або бажаючого стати таким) адміністратора, т.к. вимагає знання принципів функціонування процесів, що відбуваються в ньому. Реальна багатозадачність і жорсткий поділ пам'яті забезпечують високу надійність функціонування системи, хоча у продуктивності файл-і принт-сервісів Unix поступаються Netware.

Недостатня гнучкість надання прав доступу користувачів до файлів у порівнянні з WindowsNT ускладнює організацію _на_рівні_файлової_системи_ групового доступу до даних (точніше, до файлів), що на мій погляд компенсується простотою реалізації, а отже, меншими вимогами до апаратури. Втім, такі додатки, як SQL-сервер вирішують проблему групового доступу до даних самотужки, так що відсутня в Unix можливість заборонити доступ до _файлу_ конкретному користувачеві на мій погляд є надмірною.

Практично всі протоколи, на яких базується Internet, були розроблені під Unix, зокрема стек протоколів TCP/IP вигаданий в університеті Berkeley.

Захищеність Unix при правильному адмініструванні (а коли це не так?) ні в чому не поступається ні Novell, ні Windows NT.

Важливою властивістю Unix, що наближає його до мейнфреймів, є багатотермінальність, багато користувачів можуть одночасно запускати програми на одній Unix-машині. Якщо не потрібно використовувати графіку, можна обійтися дешевими текстовими терміналами (спеціалізованими або на базі дешевих PC), підключеними повільними лініями. У цьому з ним конкурує лише VMS. Можна використовувати і графічні X-термінали, коли на одному екрані є вікна процесів, що виконуються на різних машинах.

У номінації робочих станцій з Unix конкурують MS Windows*, IBM OS/2, Macintosh та Acorn RISC-OS.

Windows - тим, хто цінує сумісність більше ефективності; для тих, хто готовий купити велику кількість пам'яті, дискового простору та мегагерц; для тих, хто любить не вникаючи в суть, клацати мишкою по кнопках у вікні. Щоправда, рано чи пізно все одно доведеться вивчити принципи роботи системи та протоколів, але тоді вже буде пізно – вибір зроблено. Важливою перевагою Windows слід визнати також можливість вкрасти купу програмного забезпечення.

OS/2 – для любителів OS/2. :-) Хоча за деякими відомостями OS/2 краще за інших взаємодіє з мейнфреймами та мережами IBM.

Macintosh - для графічних, видавничих та музичних робіт, а також для тих, хто любить зрозумілий, гарний інтерфейс і не хоче (не може) розумітися на подробицях функціонування системи.

RISC-OS, прошита в ПЗУ, дозволяє не витрачати час на інсталяцію операційної системи та відновлення її після збоїв. Крім того, практично всі програми під нею дуже економно витрачають ресурси, завдяки чому не потребують свопінгу та працюють дуже швидко.

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

Список літератури

1. Навчальний посібник Кузнєцова С.Д. ”Операційна система UNIX ”2003р.;

2. Поляков А.Д. "UNIX 5-th Edition на x86, або не забувайте історію";

3. Карпов Д.Ю. "UNIX" 2005 р.;

4. Федорчук О.В. "Майстерність роботи в Unix", 2006 р.

5. Матеріали сайту http://www.citforum.ru/operating_systems/1-16;

МІНІСТЕРСТВО ОСВІТИ ТА НАУКИ РОСІЙСЬКОЇ ФЕДЕРАЦІЇ ФЕДЕРАЛЬНА АГЕНЦІЯ З ОСВІТИ ДЕРЖАВНА ОСВІТА ВИЩОЇ ПРОФЕСІОНАЛЬНИЙ ПРОФЕСІЙНОСТІ