При проектуванні корпоративної IT-системи необхідно визначитися з колом завдань, що вирішуються, і з вимогами з безпеки, швидкодії та надійності. Ці характеристики безпосередньо залежить від вибору операційної системи (ОС), встановлюваної на сервері. UNIX-подібні системи BSD і GNU/Linux, що вільно розповсюджуються, поступово витісняють звичний Windows. Вони більш безпечні, оскільки доступ здійснюється за принципом «все заборонено, що не дозволено», тому вони практично не схильні до вірусних атак, мають високу продуктивність і надійність.
Операційні системи сімейства BSD
Система поширення програмного забезпечення Berkeley Software Distribution (BSD) була створена на початку 90-х випускниками Університету Берклі (Каліфорнія). Розробники UNIX-подібної операційної системи 386BSD виклали вихідні коди у відкритий доступ, на їх основі були написані базові ОС:
- BSD/OS, комерційна версія
- NetBSD, Open-source.
- FreeBSD, Open-source.
Комерційна версія більше не підтримується, а інші Open-проекти успішно розвиваються. В даний час існують 4 проекти BSD з відкритими кодами. Кожен проект ґрунтується на своєму власному ядрі; вони створені для різних цілей, але мало відрізняються один від одного.
Сімейство BSD:
- FreeBSD – проект спрямований на створення простої в управлінні системи з високою продуктивністю.
- DragonFlyBSD - високопродуктивна ОС, що масштабується, призначена для підтримки багатопроцесорної обробки даних (SMP), створена з проекту FreeBSD;
- NetBSD - підтримує максимальну переносимість коду для різних обчислювальних ресурсів; підтримує застаріле обладнання; цю ОС використовували у космічних проектах NASA.
- OpenBSD – надійна ОС із підвищеним рівнем безпеки створена на базі проекту NetBSD; її встановлюють у банках та державних установах США.
Окремо можна відзначити TrueOS (раніше PC-BSD) – операційна система, заснована на FreeBSD та орієнтована для використання на робочих станціях.
Найпоширеніша – FreeBSD, вона встановлена у 80% користувачів, які зупинили свій вибір на сімействі BSD.
У режимі online доступна докладна документація в різних форматах налаштування та керування системою.
На FreeBSD програми можна встановити двома способами:
- за допомогою диспетчера пакетів (починаючи з версії 9.1 за промовчанням пропонується нова, більш гнучка реалізація пакетів, що практично не відстає від версій у портах);
- з використанням колекції портів.
Колекція портів - автоматизована система збирання програм із вихідних кодів - значно полегшує процес установки. На даний момент налічується понад 33 000 додатків. Достатньо задати параметри збирання, вибравши потрібні пункти з меню, і запустити процес виконання.
Операційні системи Linux
Linux, на відміну BSD, є лише ядром ОС. Додаванням до ядра GNU-програм формуються ОС GNU/Linux зі своїм набором прикладних та системних компонентів. Дистрибутиви Linux поширюються як інсталяційних пакетів безкоштовно або за помірну ціну; можна скомпілювати систему з вихідних кодів.
Основні лінукс-дистрибутиви:
- Debian – один із перших дистрибутивів.
- Ubuntu – найпопулярніший лінукс, створений на базі Debian.
- Fedora – підтримується RedHat.
- RHEL – комерційна версія лінуксу Fedora.
- Gentoo – повністю збирається із вихідних кодів, можна гнучко налаштувати систему.
- Mint – сумісний з Ubuntu, містить Java та AdobeFlash.
- Slackware – найстаріший лінукс.
- Arch - дистрибутив, що постійно оновлюється, підтримує бінарний формат і установку з вихідних кодів.
- CentOS – заснована на комерційному дистрибутиві RedHat, стабільна серверна ОС.
- PCLinuxOS – портативний LiveCD-дистрибутив.
Кожен лінукс створювався під певні завдання. Для встановлення Gentoo та Arch необхідний багатий досвід у вирішенні проблем із залежностями та драйверами. Щодо просто встановлюються дистрибутиви Ubuntu та Debian.
Розібратися в тонкощах роботи із системою допомагають поради досвідчених фахівців із неформальної спільноти лінуксоїдів. Більшість програм, написаних під Linux, можна вільно завантажити з репозиторіїв в Інтернеті.
Порівнюємо FreeBSD та Linux
І сімейство BSD, і лінукси найчастіше розробляються на некомерційній основі та доступні для безкоштовного використання. Користувачі можуть брати вихідні коди та змінювати на свій розсуд.
І FreeBSD, і дистрибутиви сімейства Linux є UNIX-подібними операційними системами. Лінукс спочатку створювався Лінусом Торвальдсом як вільна альтернатива UNIX-подібній системі MINIX, тоді як FreeBSD ближче до початкової версії UNIX: перша ОС сімейства BSD навіть мала назву Berkeley Unix.
Загальна UNIX-спадщина обох сімейств проявляється у використанні подібних патернів. І там, і там взаємодія користувача з системою здійснюється переважно за допомогою командного інтерпретатора (shell), програмний інтерфейс програми (API) має схожий функціонал, є подібність і в ієрархії файлової системи. Завдяки цьому набагато простіше портувати програми з FreeBSD в Linux і навпаки, ніж з інших не-UNIX-подібних систем.
Одна з основних відмінностей між сімейством BSD та дистрибутивами, в основі яких лежить ядро Linux, полягає у типі ліцензування.
Більшість дистрибутивів Linux та додатків для них поширюються під ліцензією GNU GPL, також відомою як ліцензія copyleft (авторське ліво), що дозволяє використовувати оригінальний код для створення нових продуктів, не запитуючи дозволу власника вихідних текстів, але зберігаючи умови його поширення. Ця ліцензія просуває ідею вільного поширення та відкритості понад усе. Тому при розробці пропрієтарного програмного забезпечення варто з обережністю використовувати продукти, ліцензовані GPL.
Операційні системи сімейства BSD, у тому числі і FreeBSD, поширюються під ліцензією BSD, що містить більше свободи, ніж ліцензія GPL, не вимагаючи всіх похідних продуктів збереження всіх умов вихідної ліцензії. Програмне забезпечення під ліцензією BSD можна вільно використовувати для розробки пропрієтарних програм із закритим вихідним кодом.
Ще одне важливе відмінність у тому, що FreeBSD містить як ядро, а й базові компоненти операційної системи, розроблені командою FreeBSD. У той час як лінукс – це лише ядро. А ось вже конкретний дистрибутив включає крім ядра і певний набір програмного забезпечення, зібраний найчастіше з різних джерел.
Використання FreeBSD та Linux
Цікаво, що і FreeBSD, і Linux лежать в основі багатьох інших відкритих і пропрієтарних систем, а також використовуються на різних пристроях.
Наприклад, FreeBSD лягла в основу таких продуктів:
- FreeNAS – операційна система для мережевого сховища.
- pfSense – дистрибутив міжмережевого екрану.
- m0n0wal – дистрибутив вбудованого міжмережевого екрану.
- Darwin – ядро систем macOS, iOS.
- Junos – операційна система для мережевого обладнання від Juniper Networks.
- Isilon Systems' OneFS – операційна система для мережевого сховища від Dell EMC.
- Netflix Open Connect appliances – стрімінгові сервери.
- Ігрові консолі PlayStation 3, PlayStation 4, PlayStation Vita від Sony Computer Entertainment.
- та ін.
На основі ядра Linux створено:
- Android – операційна система для мобільних пристроїв (Google).
- Tizen – операційна система для мобільних пристроїв (Samsung).
- VMware ESXi – гіпервізор.
- ChromeOS – операційна система для ноутбука Chromebook.
- ОС для одноплатних комп'ютерів Cotton Candy та Raspberry Pi.
- ОС для мережного обладнання Linksys
- та ін.
Висновок
З часом системи з відкритим кодом розвиваються, і сучасному користувачеві набагато простіше їх встановити та використовувати, ніж раніше. Розглянуті системи дуже схожі, і вибір можна робити, ґрунтуючись на наявності конкретного завдання та відповідних фахівців, які знаються на конкретній системі.
В ATLEX дистрибутив CentOS використовується на серверах та серверах для надання послуги на базі Xen. Для хмарних сервісів OpenStack використовується дистрибутив Ubuntu. А на FreeBSD працюють деякі службові сервери.
Ви можете встановити та протестувати будь-яку ОС на віртуальних машинах у нашому , а фахівці компанії завжди нададуть вам кваліфіковану підтримку.
У сфері сучасного програмного забезпечення з відкритими вихідниками слово «Linux» практично перетворилося на синонім поняття «операційна система», хоча мало хто знає про те, що насправді це далеко не єдина на сьогоднішній день ОС типу Unix, вихідні коди якої є доступними для всіх.
Відповідно до даних, отриманих від IOSC, у 1999 році практично третина всіх машин, які були підключені до інтернету, працювали на основі Linux, тоді як практично 15% застосовували операційну систему FreeBSD. Що це за система, і по сьогоднішній день знають лише небагато сучасних користувачів ПК, незважаючи на всі її переваги і широке поширення свого часу. Варто відзначити той факт, що багато світових лідерів у сфері Web-послуг активно працюють на даній системі. Зокрема, слід зазначити, що на сьогоднішній день система Yahoo заснована на FreeBSD. Що це дає користувачам, вони навряд чи знають і навіть замислюються, але власники системи впевнені, що це правильне рішення.
Що таке BSD?
BSD розшифровується як Berkeley Software Distribution. Саме так свого часу називалося програмне забезпечення, яке у Берклі поширював у вихідних кодах. При цьому варто відзначити той факт, що спочатку доповнення до стандартної операційної системи UNIX - це єдине, що було FreeBSD. Що це було порівняно із нинішньою версією системи?
На основі версії 4.4 BSD-Lite створювалося кілька операційних систем, які мають відкриті вихідні коди. Зокрема, склад цих систем включав розробки інших проектів, серед яких на окрему увагу заслуговує проект GNU.
Структура
Переваги та особливості, які має ця система, відрізняються структурою FreeBSD. Що це за структура?
- Ядро, яке призначається для ретельного планування всіх процесів, управління пам'яті, роботи з різними пристроями, а також для підтримки багатопроцесорних систем. При цьому слід зазначити той факт, що, на відміну від ОС Linux, у цьому випадку є кілька типів ядер BSD, які відрізняються різними особливостями.
- Бібліотека С, яка використовується як основний системний інтерфейс програмування, причому ґрунтується на коді з Берклі, а не з проекту GNI.
- Всі файлові утиліти, компілятори, оболонки, редактори зв'язків, а також інші програми кінцевого користувача, при цьому деякі з них ґрунтуються на коді GNU.
- FreeBSD UNIX - операційна система, що включає X Window, яка відповідає безпосередньо за Дана система застосовується в переважній більшості версій BSD і офіційно підтримується проектом X.Org. Дана система дозволяє користувачеві робити вибір з кількох графічних оболонок, а також цілого ряду легких віконних менеджерів.
- Велика кількість інших системних та прикладних програм.
Що таке справжній UNIX?
Варто відзначити, що сама по собі FreeBSD UNIX – операційна система завжди різна. І типи таких систем є клонами одне одного. Вони є лише нащадків загального предка - традиційної операційної системи UNIX. Цей факт може трохи здивувати, тим більше якщо згадати, що розробник цієї операційної системи ніколи не розкривав широкому загалу коди своїх розробок.
BSD – це UNIX?
І дійсно, операційна система UNIX ніколи не була програмним забезпеченням, що має відкритий вихідний код, у зв'язку з чим BSD безумовно не можна буде назвати системою UNIX, хоча б тому, що графічний інтерфейс операційних систем є різним. Однак у той же час компанія, яка розробляла UNIX, активно користувалася чужими розробками, і, зокрема, це стосується програмного забезпечення, яке розроблялося організацією CSRG.
Спочатку дистрибутиви BSD, а також графічний інтерфейс операційних систем являв собою комплекси програм користувача, і така ситуація тривала рівно доти, поки компанія не уклала контракт з DARPA, підлеглим Мета даного контракту - це оновлення різних комунікаційних протоколів, на яких підтримувалася комп'ютерна мережа агентства .
Протягом 80-х років сформувалося кілька компаній, що займаються виробництвом робочих станцій, при цьому варто відзначити, що багато хто з них купував ліцензії на використання UNIX замість того, щоб намагатися розробляти з нуля власне програмне забезпечення. Зокрема, варто виділити компанію Sun, яка вчинила таким чином і вирішила на основі версії 4.2BSD зрештою випустити власну операційну систему, яка називалася SunOSTM. Коли ж компанія AT&T, що займається розробкою UNIX, зрештою вирішила зайнятися комерційним продажем своєї операційної системи, з'явилася досить аскетична реалізація - System III, за якою з часом був також вихід системи System V.
Чому ця операційна система залишається незатребуваною?
Є деяка низка причин, через які сьогодні FreeBSD 10 користується не таким широким попитом:
- Розробники найчастіше цікавляться якістю власного коду, причому більше його шліфуванням, а не рекламою.
- За великим рахунком, популярність Linux є наслідком цілої низки зовнішніх факторів щодо даного проекту, зокрема це стосується засобів масової інформації, а також компаній, які вирішили сформувати власний бізнес, надаючи послуги користувачам цієї операційної системи.
- Розробники BSD у переважній більшості є більш досвідченими в порівнянні з розробниками Linux, у зв'язку з чим вони набагато менше уваги приділяють тому, щоб полегшити життя простим користувачам. Іншими словами, налаштування FreeBSD для звичайного користувача є більш складним, ніж
- У 1992 році розробник UNIX вирішив подати до суду на компанію BSDI, яка займалася постачанням операційної системи BSD/386. Основний пункт звинувачення в даному випадку був тим, що в ОЗ містився закритий код, який належав позивачу, і начебто справа в кінцевому підсумку була залагоджена за межами суду 1994-го, але цілий комплекс вторинних позовів навіть у наші дні отруює життя багатьом людям.
- Є думка, що самі собою проекти BSD різняться і при цьому можуть навіть конфліктувати між собою. Ця думка ґрунтується на подіях, які відбувалися досить давно.
Що краще – Linux чи BSD?
На сьогоднішній день найчастіше вибирають, встановлюючи сервер Apache, FreeBSD замість традиційного більшості інших систем Linux. Для середнього користувача різниця між цими системами є на диво малою, оскільки обидва продукти ґрунтуються на UNIX. Обидві системи розробляються на некомерційній основі.
Кому належить BSD?
Немає якоїсь конкретної людини або компанії, яка б володіла розробкою BSD. Розробка, а також подальше розповсюдження цієї системи здійснюється цілою групою висококваліфікованих і при цьому відданих проекту спеціалістів, зібраних з усього світу. Певні компоненти BSD є окремими проектами, що мають відкритий код, який має свої закони та колективи розробників.
Що ж вибрати?
Вибір між цими операційними системами є досить складним, тому можна виділити кілька порад, які дозволяють вибрати, який варіант є оптимальним - Linux або FreeBSD. Команди в обох випадках досить схожі, тому вибір найчастіше може будуватися на основі наступного:
- Якщо вами вже використовується певна Open Source ОС, то вам не варто навіть щось змінювати.
- Системи FreeBSD можуть виявляти набагато більшу продуктивність, але це правило не є універсальним.
- Системи BSD відрізняються досить гарною репутацією, і особливо це стосується надійності.
- BSD-проекти відрізняються найкращою репутацією завдяки тому, що вони відрізняються високою якістю, а також повнотою доступної документації.
- У BSD можна використовувати переважну більшість здійснюваних файлів Linux, в той час як Linux не може використовувати багато файлів, що виконуються в BSD.
Забезпечує технічну підтримку, а також обслуговує FreeBSD – порти та системи – компанія FreeBSD Mall, Inc.
Події у світі вільно-розповсюджуваних операційних систем сімейства BSD: FreeBSD, OpenBSD і NetBSD вже давно привертають увагу розробників ОС. Інформація про можливості, переваги та недоліки подібних систем, а також відомості щодо їх комерційних реалізацій (BSD/OS) будуть корисні, коли в черговий раз перед користувачем постає питання: чи купувати комерційну Unix-систему або зробити крок у бік програмного забезпечення, що вільно розповсюджується. Крім того, стаття може зацікавити всіх, хто хоче дізнатися історію ОС Unix.
Історія BSD Unix почалася з того моменту, коли в 1974 році до Університету Берклі (Каліфорнія, США) потрапила операційна система Unix. На той час ця ОС вже кілька років за символічну плату поширювалася лабораторією Bell Technical Labs (BTL) серед університетів та інших навчальних закладів, встигнувши завоювати симпатії користувачів, яким припала до душі відкритість системи: Unix постачалася у вихідних текстах (без підтримки та гарантій BTL) , і користувачі мали можливість самостійно вивчати, виправляти та розширювати її. Все це породжувало бажання ділитися своїми доробками з іншими ентузіастами Unix і багато в чому сформувало специфічний спосіб мислення та Unix-культуру. Слід зазначити, що співробітники Bell Technical Labs вчинили дуже мудро (можливо, навіть не усвідомлюючи цього), відпустивши Unix у вільне плавання. Свобода надала послугу як самій системі, так і її користувачам - на Unix виросло чимало професіоналів, не кажучи вже про кількість дипломів, захищених за цією темою. Тож можна вважати, що ОС Unix вступила у комерційний світ із повною університетською освітою. До речі, нещодавно на подібний крок - передачу вихідного коду навчальним закладам - зважилася фірма BSDI. Цікаво, чи повториться історія?
Але повернемося до Берклі. Саме там народилися багато ідей, що стали тепер загальновизнаними - підтримка протоколу TCP/IP в ОС Unix, система віртуальної пам'яті, швидка файлова система (FFS), редактори ex і vi, BSD sockets (інтерфейс програмування мережевих додатків), sendmail, csh та багато іншого . Університет також дав світові чудових фахівців, які багато в чому визначили розвиток Unix – досить згадати Еріка Аллмана, Білла Джоя чи Чака Хейлі. Саме до них першим потрапили тексти Unix, що "оселилися" у Берклі. Розробкою Unix тут займалася група Computer System Research Group (CSRG), яка, на жаль, розпалася 1992 року. Однак найкращі її традиції були продовжені компанією BSDI (Berkeley Software Development, Inc.) та групами розробників FreeBSD та NetBSD. Нещодавно до них додалася команда проекту OpenBSD.
1. Все почалося з 386BSD
У той час по світу тинялося кілька версій BSD Unix, але всі вони мали щось спільне: для їх використання потрібно мати ліцензію на початковий вихідний код Unix. Більша частина коду BSD була написана в Берклі, і одного разу хтось помітив, що власне оригінального коду залишилося не так багато; так народилася ідея створити вільно-розповсюджуваний Unix і почати його поширення через мережу (Net distribution).
Вільям і Лінна Джолітц вирішили переписати частини системи, які бракують створення загальнодоступного варіанта BSD Unix. В результаті з'явилася 386BSD версія 0.0. Ще не готова до використання, 386BSD мала одну безперечну перевагу: для того щоб створити працездатний варіант системи, більше не вимагалося source license, що вселяє жах. Незабаром з'явилася 386BSD 0.1 (на той час Linux, інший член сімейства безкоштовних систем Unix, існував уже понад рік). Багато людей, бажаючи повозитися з вихідним кодом, з яким вони вже були знайомі раніше, вирішили почати використовувати та виправляти 386BSD 0.1. В результаті починаючи з червня 1992 року в систему було внесено велику кількість виправлень та покращень. На багатьох серверах FTP існував навіть неофіційний patchkit (набір виправлень), який дозволяв зробити 386BSD більш стабільною та зручною у застосуванні - багато труднощів у роботі системи вирішувалися саме за допомогою patchkit. Але сьогодні, після виникнення деяких юридичних проблем з частиною коду, що належить AT&T/Berkeley, оригінальну систему стало досить важко знайти - її було видалено з FTP-серверів по всьому світу.
Слід згадати, що коли некомерційне сімейство BSD тільки створювалося, Вільям і Лінна в якості основи використовували стрічку під назвою Berkeley Net Release/2. Збудувавши таким чином міцний фундамент, вони також заклали, самі не бажаючи того, бомбу сповільненої дії. У результаті юридичних битв частина файлів вихідної стрічки Net/2 була позначена як binary only. Отже, вони мали бути відтворені з нуля, щоб отримати істинно вільно-распространяемую систему. У цьому полягає основна причина того, що зараз знайти оригінальну версію 386BSD version 0.1 практично неможливо. Для того, щоб замінити 386BSD, народилося три нові системи під новими іменами. Першою була NetBSD, незабаром за нею пішла FreeBSD, а нещодавно до цієї групи додалася OpenBSD.
Якщо подивитися на файл README, що поставляється з кожною системою BSD, можна виявити, що ці системи базуються на BSD 4.4-Lite. Команда розробників FreeBSD використовувала BSD 4.4-Lite distribution і створила відсутні частини коду; все це після подальшого розвитку і перетворилося на FreeBSD. Розробники NetBSD почали розробку з 386BSD, додавши доступні частини з BSD 4.4. Система OpenBSD свого часу відокремилася від NetBSD - розробники вирішили поєднати кращі риси FreeBSD (зручність роботи та функціональність) і NetBSD (переносність на велику кількість платформ). Таким чином, команди розробників Open/Free/NetBSD знову створили ті файли, які були відсутні в оригінальному комплекті BSD 4.4-Lite або не могли поширюватися вільно. Всі системи максимально наближені до BSD 4.4, хоча кожна має свої переваги і недоліки.
Розглянемо ці системи докладніше, проте відразу варто зауважити, що дуже часто багато, сказане про одну систему, підходить і до іншої: всі ці ОС OpenBSD, FreeBSD і NetBSD розвиваються окремо, але не ізольовано.
2. NetBSD
NetBSD Project - це результат спроби великої групи ентузіастів створити вільно розповсюджуваний варіант Unix-сумісної операційної системи. NetBSD заснована на великій кількості програмного забезпечення, що вільно розповсюджується, в першу чергу BSD4.4-Lite Університету Берклі. Система працює на багатьох платформах - від DEC Alpha до Apple Macintosh і z80, поставляється з повним вихідним кодом і підтримується самими розробниками системи та користувачами. Основну ставку розробники зробили на надійність та підтримку великої кількості платформ. Мабуть, сьогодні навряд чи знайдеться апаратна конфігурація, де не можна було б встановити NetBSD.
Реалізація проекту розпочалася у січні 1993 року, і вже до квітня з'явився перший офіційний випуск – версія 0.8, яка працювала лише на платформі i386. За нею була версія 0.9 у серпні того ж року. Спочатку NetBSD була успадкована від 386BSD, яка використовувала Berkeley Net Release 2 (BNR/2) і, природно, як і інші операційні системи на базі BNR/2, у якийсь момент зіткнулася з труднощами. Лише через рік після випуску 0.9, у жовтні 1994-го, з'являється NetBSD 1.0 – перша версія NetBSD, яка базується на BSD4.4-Lite. Крім цього, система була портована HP300/9000, Macintosh, PC532, Sun SPARC і Amiga. У вересні 1995 року створюється NetBSD Foundation, некомерційна організація, покликана стати координуючим органом NetBSD Project. Незабаром (листопад, 1995) NetBSD портується на Atari, DECstation, VAX, Sun3; до неї додається двійкова сумісність (в межах однієї платформи) з FreeBSD, iBCS2, SunOS, Ultrix, HPUX, Linux, OSF/1, SVR4. Версія одержує номер 1.1. Найсвіжішою версією NetBSD стала реалізація 1.2 (жовтень, 1996), а поряд з багатьма вдосконаленнями та змінами з'явилася підтримка платформ DEC Alpha, Motorola MVME boards, SPARC/Sun4m.
Система NetBSD поширюється у двох варіантах: формальний випуск та NetBSD-current. FreeBSD та OpenBSD мають ту саму схему. Формальний випуск має номер версії і включає добре налагоджені утиліти, ядро, вихідних кодів і засоби установки. Випуск являє собою баланс між можливостями та стабільністю – його легше встановити, ніж current-версію. Такі версії добре налагоджені і з'являються відносно рідко, тому вони підходять тим, хто бажає мати систему, що стабільно працює. Ці версії зручніші у підтримці, оскільки завжди ясно, про що йдеться. Найбільша проблема з формальними версіями полягає в тому, що користувач не отримує доступу до бази вихідного коду з останніми покращеннями та виправленнями. Формальну версію нескладно встановити - для кожної платформи є детальні інструкції, образи завантажувальних дисків або файлів miniroot. Як правило, існує процедура, що дозволяє легко перейти з попередньої версії на нову.
З NetBSD-current ситуація зовсім інша. Чергова current-версія з'являється щоночі і є "зліпком" дерева вихідного коду NetBSD, який потрібно перекомпілювати на вашій платформі. Оскільки робота ведеться постійно, поточна версія часом не зовсім налагоджена, може містити помилки, може навіть не скомпілюватися. Current-версія корисна розробникам драйверів, системного програмного забезпечення та тим, хто бере участь у створенні NetBSD. Current-версія дозволяє розробникам "триматися разом", виловлює помилки та оперативно вносить зміни. У якийсь момент current-версія починає перетворюватися на formal release, відбувається бета-тестування, а від цієї гілки росте нова current-версія і т. д. Таким чином, розвиток не зупиняється ні на мить, і при цьому жодна фаза не прихована від спільноти - завжди можна запропонувати свої зміни та доповнення, які (якщо вони мають сенс) будуть включені до поточного.
NetBSD project прагне дотримуватися таких стандартів індустрії, як POSIX і Standard C. Нагадаємо, що POSIX (Portable Operation Systems Interface) - назва фінансованої IEEE групи, яка розробляє стандартний API для Unix-подібних операційних систем. Існує POSIX.1 (IEEE Std1003.1-1990), який стандартизує API для Сі POSIX.2 (IEEE Std1003.1-1992), що стандартизує роботу оболонки та утиліт. Інші POSIX-стандарти описують мови Ада та Фортран, розширення для роботи в реальному часі і т. д. Зараз NetBSD дуже близька до POSIX.1, тому перенесення програмного забезпечення в середу NetBSD – нескладне завдання. Але навряд чи колись NetBSD отримає статус системи, що відповідає POSIX, оскільки сертифікація коштує чималих грошей. Проте розробники вважають, що NetBSD ближче до POSIX і Standard C, ніж будь-яка інша операційна система, що вільно розповсюджується.
3. FreeBSD
Проект FreeBSD народився на початку 1992 року і частково виріс із проекту "Неофіційний набір виправлень для 386BSD" або, точніше, з patchkit, очолюваного Нейтом Вільямсом, Родом Граймсом та Джорданом Хаббардом. Крім того, у розробці брали участь Девід Грінмен та Джуліан Елішер, хоча офіційно вони приєдналися до проекту лише через місяць після початку його реалізації. Оскільки організація роботи через patchkit вже не могла врятувати становище, головною метою проекту було створення проміжного варіанту 386BSD, в якому було б виправлено більшість помилок. Можливо, хтось зараз може згадати робочі назви проекту типу 386BSD 0.5 або 386BSD Interim, які відображали поточний стан справ.
Приблизно в цей час Білл Джолітц відмовився від подальшої підтримки та розвитку системи, у результаті проект модернізації 386BSD перетворився на те, що ми знаємо тепер під назвою FreeBSD (ім'я було придумане Девідом Грінменом). Джордан Хаббард звернувся до Walnut Creek CDROM (США), сподіваючись відкрити додаткові канали розповсюдження для ще не створеної операційної системи. Компанія Walnut Creek CDROM не просто підтримала ідею поширення FreeBSD на CD – вона ще допомогла з комп'ютерною технікою та швидкісним підключенням до Internet. Перший CD-диск із FreeBSD з'явився в грудні 1993-го - це був FreeBSD 1.0, версія якого теж поширювалася по Мережі. Система була заснована на стрічці 4.3 BSD Lite (Net/2) з Берклі та доповнена компонентами з 386BSD та від Free Software Foundation. Для першої версії успіх був досить значним, і незабаром у травні 1994-го на світ з'явилася дуже вдала версія 1.1.
Однак потім на горизонті почали згущуватися хмари. Компанія Novell - спадкоємець AT&T - розпочала позов за заборону використання фрагментів коду в стрічці Berkeley Net/2, які вели своє походження з AT&T. Університет Берклі був змушений випустити "полегшений" варіант, названий BSD4.4-Lite, та порекомендувати всім користувачам Net/2 перейти на нього. Тому в кінці липня 1994 FreeBSD project припиняє постачання FreeBSD, але, відповідно до ліцензійної угоди, має право на випуск ще однієї версії до настання "години Х". У результаті з'являється FreeBSD 1.1.5.1 – результат року роботи на Net/2. Ця версія мала кращу продуктивність, ніж усі попередні, мала вищу надійність і сама по собі була чудовим продуктом.
Але тепер розробники мали фактично почати все заново, ґрунтуючись на новому і неповному наборі BSD 4.4-Lite. Через різні юридичні обмеження команда Berkeley CSRG видалила велику кількість коду, що використовується для створення працездатної системи, що завантажується, і фактично порт на Intel x86 виявився дуже неповним. FreeBSD Project знову почав роботу в грудні 1994-го, і вже в січні 1995 року FreeBSD версії 2.0 з'явилася в Мережі та на CD. Незважаючи на деякі шорсткості, система мала великий успіх, і незабаром за нею була швидша і зручніша в установці FreeBSD 2.0.5, випущена в червні 1995 року.
Наприкінці цього року на світ з'явилася версія 2.1 дуже стабільна, багато в чому вдосконалена, яка за всіма параметрами перевершувала версію FreeBSD 1.1.5.1. За два роки було виконано величезну роботу з перетворення неповного набору BSD 4.4-Lite у працюючу, надійну та зручну операційну систему. Не можна не захоплюватися командою розробників, до якої на той час приєдналися багато чудових програмістів-ентузіастів. Трохи пізніше 2.1 перетворилася на 2.1.5, потім на 2.1.6. В обох випадках підвищено стабільність, додано додаткові драйвери, виправлено знайдені помилки. У лютому 1997-го в системній бібліотеці було виявлено неточність у обробнику змінної оточення PATH_LOCALE, і тоді команда розробників FreeBSD видалила версію 2.1.5/2.1.6 з усіх FTP-серверів та випустила версію 2.1.7 (security-relea) Потім вийшла версія 2.2 і розпочалися роботи над FreeBSD 3.0, де намічається підвищення якості роботи віртуальної машини (VM), що дозволить покращити емуляцію DOS та Windows-додатків.
Крім того, зовсім нещодавно було розпочато грандіозний проект зі строкового перебору всього коду FreeBSD (близько 120 Мбайт). Мета проекту - позбутися проблем із security, виправити виявлені помилки та покращити загальний стиль. Дерево вихідного коду було розбито на окремі частини, що проглядаються різними командами програмістів; всі виправлення неодноразово перевіряються ще раз незалежними фахівцями. Все це дозволяє сподіватися, що FreeBSD стане більш захищеною системою. До речі, проаналізувавши список розсилки BUGTRAQ за останні півроку, можна помітити, що комерційні ОС типу Solaris, IRIX, не кажучи вже про NT, значно перевершують FreeBSD за кількістю помилок у програмах, критичних для безпеки. Додаткову інформацію про FreeBSD Audit Project можна знайти за адресою: http://www.freebsd.org/auditors.html.
Таким чином, розробка FreeBSD не є закритим процесом, а навпаки, підтримує багаторічні традиції співпраці фахівців з різних країн світу, які працюють над одним завданням. Найактивніші з розробників переходять у команду FreeBSD core team, яка займається загальним напрямом та цільовою координацією проекту.
4. OpenBSD
Проект OpenBSD відокремився від NetBSD зовсім недавно і є членом сімейства BSD4.4-Lite. Сьогодні OpenBSD розвивається самостійно; Крім власних розробок до нього включаються вдалі ідеї з інших груп (FreeBSD/NetBSD). Розробку OpenBSD розпочав Тео де Раадт, один із чотирьох творців NetBSD. І якщо раніше про OpenBSD ще можна було сказати: "OpenBSD - це NetBSD плюс додаткові можливості", то зараз, після довгої роботи, очевидно, що OpenBSD є самостійною системою із сімейства BSD - дуже багато, порівняно з оригінальною версією, було додано і виправлено.
У спадок OpenBSD дісталася хороша багатоплатформна підтримка, проте процес портування продовжується. Особливу увагу група OpenBSD приділяє захищеності системи: зокрема вже давно була спроба переробки вихідного коду для запобігання можливим атакам, пов'язаним з фіксованим розміром буфера, а також виконано виправлення безлічі програм. OpenBSD має чудову POSIX-сумісність, надійність і захищеність. Команда OpenBSD завжди оперативно реагує на повідомлення про неточності та можливі неполадки, вона відкрита для нових розробників, і кожен спеціаліст має можливість додати в систему те, чого їй не вистачає.
OpenBSD сумісна з багатьма розширеннями FreeBSD (зокрема, системою FreeBSD ports); нещодавно з'явилася підтримка ATM, ведеться робота над включенням IPX та інших мережевих протоколів. Одна з головних переваг OpenBSD - це розуміння необхідності захищеності системи. Система OpenBSD залишається практично найнадійнішою у цьому плані Unix-подібною системою для ПК. Остання версія OpenBSD – 2.0, а найближчим часом з'явиться версія 2.1 (на CD та серверах FTP).
5. Можливості Net/Free/OpenBSD
Отже, що ж сьогодні є сімейством вільно поширюваних BSD Unix-систем?
FreeBSD - Unix-подібна операційна система для ПК, заснованих на архітектурі Intel, що включає 386-е, 486-е і Pentium-процесори. Крім того, ОС NetBSD/OpenBSD підтримують багато інших платформ. Всі три системи надають багато можливостей, які раніше були доступні лише на потужніших і найдорожчих машинах.
6. Особливості реалізацій
На додаток до основної поставки FreeBSD пропонує велику колекцію портованих програмних продуктів із кількох сотень найменувань. Список включає мережне програмне забезпечення, системи програмування, ігри та багато іншого. Повна колекція займає лише 10 Мбайт на диску, оскільки зберігаються лише списки змін, які потрібно зробити у вихідних текстах перед компіляцією. Для встановлення достатньо набрати команду "make", після чого система автоматично забере базову версію програми з CD або з FTP сервера, зробить необхідні зміни і скомпілює. Для тих, хто не має наміру компілювати програми самостійно, підійде колекція вже готового програмного забезпечення (packages). Для встановлення програми необхідно набрати єдину команду pkg_add з ім'ям архіву, який можна знайти на CD або на FTP.
ОС FreeBSD функціонально повна, надійна та швидка в роботі. Мабуть, ця система з усього сімейства BSD-систем, що вільно розповсюджуються, розвивається зараз найбільш динамічно. Велика увага приділяється сумісності з іншими системами та зручністю роботи. Якщо користувач працює на x86, слід звернути увагу саме на FreeBSD - вона дозволить дуже плавно увійти в світ BSD-систем. NetBSD більше орієнтується на підтримку різних платформ, а OpenBSD намагається об'єднати найкращі сторони FreeBSD та NetBSD, приділяючи особливу увагу захищеності системи. На додаток до чудової роботи, виконаної в CSRG, команди розробників витратили багато тисяч годин, удосконалюючи системи, щоб ті забезпечували максимальну продуктивність і надійність. У той час як комерційні гіганти борються за подібні переваги на полі операційних систем для ПК, FreeBSD, NetBSD та OpenBSD пропонують їх уже зараз.
7. Приклади використання
Прикладні області, у яких можна використовувати BSD Unix, обмежені лише уявою користувача - від розробки програмного забезпечення автоматизації роботи підприємства до автоматичного управління супутникової антени. Якщо щось може бути зроблено за допомогою комерційної реалізації Unix, то, швидше за все, це може бути зроблено і із застосуванням BSD Unix, який абсолютно безкоштовно пропонує велику кількість програмного забезпечення високої якості з дослідницьких центрів та університетів усього світу. Число доступних комерційних програм зростає з кожним днем.
Оскільки вихідний код систем повністю доступний, система може бути налаштована та адаптована для вирішення конкретних проблем, що забезпечує гнучкість, відсутню у багатьох комерційних закритих систем. Ось лише деякі приклади використання FreeBSD, NetBSD або OpenBSD:
BSD Unix, як правило, не включає код підтримки DES, щоб не порушувати експортні обмеження США, де доступний додатковий компонент, що забезпечує DES; для жителів Європи та інших країн також існує реалізація DES, що розповсюджується через європейські FTP-сервери. Якщо захист паролів - єдине, що потрібно від функції crypt(), і не потрібно використовувати паролі в інших системах (Sun, DEC і т. д.), FreeBSD пропонує надійний криптографічний захист, заснований на MD5. Ця модель забезпечує захист лише на рівні DES, або навіть перевершує його, тому вона влаштовує більшість користувачів системи. OpenBSD підтримує MD5, ведуться роботи з додавання моделі шифрування blowfish. ОС FreeBSD також рухається до реалізації додаткових схем шифрування, між якими можна буде перемикатися.
8. BSD/OS – комерційна BSD-система
Досі основна увага приділялася BSD-системам, що вільно розповсюджуються, проте має сенс згадати також комерційну версію BSD/OS компанії Berkeley Software DesingBSD/OS. Декілька провідних фахівців CSRG організували в 1991 році BSD Inc., щоб розвивати технологію BSD і донести її до комерційних замовників.
BSD/OS – повнофункціональна, POSIX-сумісна Unix-система для процесорів архітектури 386, 486 та Pentium. Система заснована на програмному забезпеченні Університету Берклі, а також на інших джерелах і компонентах, розроблених у BSDI. Перша версія BSD/OS була поставлена замовнику у березні 1993 року. Сьогодні BSDI Internet Server, заснований на BSD/OS, широко відомий у своєму класі систем та має кілька нагород (наприклад, InfoWorld Top Score Award у 1995 р.). Як і інші BSD-системи, дана ОС може служити WWW-сервером, маршрутизатором і т. д. BSDI Internet server несе у світ ПК багато з того, що раніше було можливе лише на потужніших системах: багатозадачність, підтримка мережі. Так, тести швидкості BSDI показали, що BSD/OS на Intel 486/66 розвиває швидкість на рівні Sun SPARCStation II, а Pentium-процесор можна порівняти вже з SUN SS10.
BSD/OS включає всі компоненти повноцінної системи: X11R6, TCP/IP (+SLIP/PPP), NFS, кошти розробки на C/C++, набір додатків та інших. BSD/OS поставляється у двійковому вигляді, а й за окрему плату - із вихідними текстами. Мабуть, єдине, у чому BSD/OS безперечно обганяє своїх безкоштовних конкурентів – це підтримка. BSD/OS - комерційний продукт, і його користувачам доступні "гарячі" телефонні лінії, до їх послуг відділи підтримки тощо.
9. То що ж краще?
Однозначної відповіді це питання дати не можна. Будь-які аргументи в "священній війні" - це марнування часу. Але можна глянути і з іншого боку. Всі системи надають давно очікувані та унікальні можливості: повністю функціональна операційна система працює на популярному устаткуванні, при цьому її вихідні тексти повністю доступні. Ті, хто давно працює в комп'ютерній індустрії, згадають, що ОС практично завжди створювалися постачальниками конкретної апаратури і, як правило, альтернативи їхній системі не існувало. Вихідні тексти ніколи не публікувалися (багато компаній і зараз продовжують цю "добру" традицію). Стати справжнім професіоналом можна було лише самостійно розібравшись у структурі системи, у логіці її роботи.
Але сьогодні становище змінилося. Користувач має можливість придбати ПК, який буде в кілька разів потужніший за багатокористувацькі VAX, і при цьому вибрати з кількох вільно поширюваних операційних систем (BSD, Linux і т. д.) Класичне питання: якщо щось виглядає, як качка, ходить, як качка, і крякає, як качка, як це називається? Відповідь залежить від того, чи є слово "качка" торговою маркою! Якщо це так, то найкраще, на що ви можете розраховувати без згоди власника торгової марки, це "качкоподібна істота". Unix є торговою маркою X/Open Company, тому решта систем, які не мають права на її використання, називають свої продукти Unix-подібними або навіть "UN*X-like". Тому жодна з перерахованих ОС формально не може називатися Unix, але хіба вони стали від цього гіршими?
Сьогодні безкоштовні ОС динамічно розвиваються, ні в чому не поступаючись, а багато в чому навіть перевершуючи своїх комерційних конкурентів. Більше того, користувачам дається шанс особисто вплинути на розвиток системи – достатньо мати у штаті хороших програмістів, щоб стати незалежним від постачальника операційної системи. Не доведеться чекати кілька тижнів, якщо виявляється якась неточність чи виникає необхідність щось покращити чи додати. Замість закритого колективу розробників (чи багато хто знає імена творців Windows 95?) існує спільнота ентузіастів, відкрита для співпраці.
Ви можете вибрати ту операційну систему, яка найбільше підходить: FreeBSD, OpenBSD, Linux, NetBSD або щось інше. Але що б ви не обрали, це вдала угода. Багато невеликих фірм, Internet-провайдерів, інших організацій та користувачів відмовляються витрачати гроші на те, що можна отримати безкоштовно, і все частіше використовують системи сімейства Unix, що вільно розповсюджуються. Ви боїтеся, що не зможете знайти потрібне програмне забезпечення? По-перше, до ваших послуг Internet, по-друге, можна придбати програмне забезпечення під BSD/OS та/або Linux і використовувати його на своїй системі - двійкова сумісність добре налагоджена. Крім того, багато комерційних розробників повертаються зараз у бік BSD-систем, що вільно розповсюджуються.
Література
В. Колонцов. Знайти, перевірити та знешкодити. Відкриті системи. – 1996, # 6, сс. 58-63.
Додаткова інформація про операційні системи сімейства BSD
386BSD -старі версії BSD сьогодні орієнтуються виключно на академічну та дослідницьку спільноту, що поширюються через Dr. Dobb's Journal на CD-дисках.
FreeBSD -версія BSD для платформи Intel орієнтується широкого використання, поширюється на CD (Walnut Creek CD-ROM, http://www.cdrom.com) та через FTP ( http://www.freebsd.org).
BSD/OS (BSDI Internet Server) -комерційна система BSD від Berkeley Software Development, Inc. для Intel-платформ ( http://www.bsdi.com).
Usenet groups: comp.Unix.bsd.* Fidonet: ru.Unix uk.Unix.bsd IRC: #netbsd, #freebsd, #openbsd etc.
ОС BSD жила, живе та житиме
Ця нотатка народилася в ході численних переходів з однієї системи на іншу, в ході багаторічного (у тимчасових масштабах IT) їх спільного використання, а також у ході роздумів на тему: а яку систему мені поставити на нову машину? Безпосереднім же поштовхом для неї послужило листування з рядом авторів і мрії про ідеальний дистрибутив, обговорювані не так давно. Але для початку – Пара застережень
Повинен відразу попередити – відповіді на запитання, винесене як заголовок, тут не буде. Бо й сам його не знаю. Але за те, що я дотримуюсь заповіту великого римського історика – ручаюся. Тому що люблю обидві системи і, більше того, і ту, і іншу використовую в повсякденному житті - то разом, то порізно, залежно від завдань, причин і просто настрою.
І ще: далі ні слова не буде говорити про застосування Linux або FreeBSD як сервери, вузли локальної мережі тощо сисадмінських матеріях. А виключно - про користувальницькі, або десктопні, їх якості. Передбачаючи реакцію деякої категорії читачів, останню фразу готовий виділити тэгом і повторити двічі та тричі:–)Суб'єктивний вступ
Скоро чотири роки, як FreeBSD та Linux чергуються на моїх машинах (домашніх та службових) з деякою періодичністю. Або мирно вживаються в одному, окремо взятому системному блоці. І за цей час я помітив цікаву закономірність.
У періоди, коли на моїй машині одна FreeBSD, робочий час мій розподіляється приблизно так: 90% - практична робота (абсолютно не важливо, який характер вона носить в даний момент), і 10% - більш-менш нездорові експерименти над системою. Варто ж угнездитися в куточку вінчестера якомусь Linux-у - і тимчасова частка експериментів відразу підскакує до 50%. А в періоди, коли я займався збиранням Linux-а з нуля, експериментальний режим фактично ставав перманентним.
І я запитав себе – чому? І – собі ж – відповів: FreeBSD – цілісна і струнка система, у якій після комплексу початкових налаштувань немає бажання ні додати чогось, ні зменшити. Невипадково рух , іноді що охоплює широкі верстви Linux–пользователей, у світі FreeBSD мало розвитку: відомий твір Йенса Швайкхардта (існуюче й у ) – це скоріш опис автоматизованої альтернативи sysinstall, ніж ручного побудови своєї системи з нуля.
Linux таку внутрішню стрункість продемонструвати не може. І тому бажання щось змінити у вже встановленій системі, удосконалити, додати, почистити, а то й просто перезбирати все наново, виникає постійно, і долається лише дефіцитом часу.
Однак це не означає, що я однозначно вважаю FreeBSD найкращою системою для роботи. Тому що моя робота, в тому числі, складається і зі створення різних навколокомп'ютерних нотаток. Сюжети, яким постачають ті самі нездорові експерименти над системою, проведенню яких так сприяє Linux - і до яких так не має FreeBSD.
Однак повторюю, все це суто суб'єктивно, адже далеко не всі займаються твором навколокомп'ютерних нотаток. І тому спробую провести більш об'єктивне порівняння. Перша спроба об'єктивізму: «залізо»
Що потрібно більшості користувачів від операційної системи як такої? По-перше, звичайно підтримка «заліза», яке на настільних персоналках, як відомо, одноманітністю не страждає.
Існує думка, що Linux підтримує ширший спектр обладнання, ніж FreeBSD. Справді, для останньої ми не знайдемо, скажімо, драйверів принтерів від виробника. Повноцінна підтримка сучасних відеокарт реалізована тільки в тому випадку, якщо вони від NVIDIA (та й то, за відгуками, значно гірша, ніж для Linux-а). Ймовірно, виникне в цій ОС напруження і т.зв. win-модемами. Це з одного боку.
А з іншого: всім щасливим власникам контролерів ATA RAID і Serial ATA в Linux донедавна доводилося вдаватися до різноманітних хитрощів. До того ж не завжди вдалим, особливо якщо приєднані до таких контролерів диски передбачалося використовувати як завантажувальні пристрої. Власне, ситуацію можна вважати нормалізованою тільки в останніх ядрах гілки 2.6.X.
У FreeBSD ж 5-й гілки більш менш паралельно, на якому контролері IDE-родини сидить жорсткий диск: завдяки CAM (Common Access Method) якось працювати з ним можна буде в будь-якому випадку, а якщо він ще й коректно впізнаний, то не буде перешкод і завантаження з нього. Та й у 4-й гілці - я жодного разу не стикався з проблемами для «одновікових» контролерів ATA RAID.
Інший приклад – звукові карти. Усі ті, що засновані на більш-менш поширених чіпах, працювали у FreeBSD без найменшої напруги (рук або думки). Те саме можна сказати і про «чіпсетний» звук. У Linux-і аналогічні пристрої часто вимагали не цілком тривіальних маніпуляцій з ALSA-драйверами, благо нині вони вбудовані в ядро. Однак навіть і в останньому випадку без деяких настроювальних дій не обійтися. Але це вже є предметом другої спроби об'єктивізму.
А результат «залізного» об'єктивізму я сформулював би так: можливо, Linux підтримує ширше коло всілякого обладнання (у тому числі, і деякої екзотики), але все «залізо», що підтримується FreeBSD (а це практично все стандартне і поширене «залізо»), використовувати, як правило, простіше. І тут ми плавно переходимо до другого хвилюючого для користувача, особливо початківця (а не початківці давно зробили свій вибір) моменту, ім'я якому - Налаштування
Усталена (і ретельно культивована) думка, ніби FreeBSD складніше в установці та налаштуванні, ніж Linux, я не можу пояснити нічим іншим, як непорозумінням. Бо нічого спільного із дійсністю воно не має.
Почнемо з встановлення. Інсталяція FreeBSD штатними засобами (за допомогою утиліти sysinstall) виконується за півгодини, не вимагає неодмінного доступу до Мережі (хоча такої зайвим не буде) і дає в результаті повністю працездатну систему з кириличною консоллю, що функціонує dial-up (або, за ситуацією, включенням до локалку), що запускаються Іксами та необхідним для початку практичної діяльності мінімумом пакетів (з прекомпільованих бінарників). Всі налаштування, і загальносистемні, і для прикладних пакетів, розумні (нехай і не ідеальні з точки зору конкретного користувача).
Звичайно, встановлення FreeBSD потребує деяких попередньо отриманих знань. Які зводяться до уявлення про розмітку диска в BSD-стилі, прийнятої тут номенклатурі накопичувачів і стратегії створення файлових систем. Не тому, що ці моменти такі складні – просто вони дуже відрізняються від усього, що користувач міг знати раніше (з досвіду спілкування з DOS/Windows або Linux). До того ж розмітка диска і файлові системи на них – це єдине, що користувач не в змозі змінити після інсталяції (без тотальної переустановки, звичайно). Однак і це не настільки страшно: пропонована в sysinstall схема розмітки і файлових систем за умовчанням цілком схожа на настільну персоналку, хоча і не ідеальна в ряді спеціальних випадків.
Більшість відомих мені інсталяторів з різних дистрибутивів Linux відрізняються від Free "шного sysinstall в дві протилежні сторони:
- є установники простіші – хоча, на мій погляд, це та сама простота, яка гірша... самі знаєте чого;
- і є установники більш гнучкі – але вони вже вимагають від користувача досить глибоких знань і чіткого розуміння суті вчинених дій.
Нарівні з Free-шним sysinstall я поставив би (з усіх мені відомих) тільки інсталятор з Archlinux. Написаний, як свідчить його розробник, під впливом першого він забезпечує майже таке ж поєднання простоти і гнучкості.
Однак (і це вже специфіка Linux як системної цілісності), навіть у цьому випадку закінченої працездатної системи на виході не виходить. Без ручного доведення обійтися не вдасться.
Звичайно, постінсталяційне доведення можна забороняти і в FreeBSD. Однак тут вона спрямована на досягнення ідеалу, а не на забезпечення базової функціональності. Що б я проілюстрував серією прикладів.
Почнемо з тієї ж русифікації. Відразу після встановлення FreeBSD користувач, за бажанням, отримує повністю кирилізовану консоль. Правда, в одному-єдиному варіанті, з внутрішнім кодуванням kOI8-R, введенням в ньому ж і екранним висновком в кодуванні DOS, та ще й з не зовсім ідеальними шрифтами. Але ніяких подальших дій щодо базової русифікації від нього обов'язково не потрібно. А привести розкладки та шрифти у відповідність до свого ідеалу він може і пізніше. У дистрибутивах Linux, що не дуже напирають на дружність користувачеві ручної правки пари конфігів, мабуть, не уникнути. На причинах цього не зупинятимуся (для тих, хто представляє різницю між консоллю в Linux і FreeBSD, вони очевидні).
Звичайно, в user-орієнтованих дистрибутивах Linux вітчизняного походження користувач отримує стовідсотково русифіковану консоль "з коробки". Однак виконану відповідно до уявлень розробників. Які не повинні збігатися з уявленнями (і, головне, потребами) даного конкретного користувача. І в цьому випадку на корекцію йому доведеться витратити значно більше сил, ніж при русифікації з нуля якогось дистрибутива з числа Source Based. На підтвердження чого – згадаємо численні статті, присвячені відкату в Red Hat (і Fedore"ном Core) з «прогресивного» кодування UTF на KOI8, нехай «бомжівське», але цілком влаштовує багатьох і багатьох...
Русифікація консолі тісно пов'язана зі стилем ініціаційних файлів, прийнятих у цій системі. І тут лінійний BSD-стиль з позицій користувача виглядає більш простим, ніж прийнята в Linux ініціація в стилі System V, заснована на понятті runlevels, Переведення якого як «рівні виконання» здатний остаточно заплутати початківця.
Панове адміни промислових серверів заперечать мені, що стиль System V дозволяє гнучко підключати та відключати різні стартові сервіси. Не буду сперечатися. Однак, чи часто таке завдання постає перед настільним користувачем? Набагато частіше його метою є вбиття разів і назавжди численних служб, які майнтайнери дистрибутива вважали за життєво необхідне для його щастя.
Невипадкова тенденція багатьох сучасних дистрибутивів Linux до використання BSD-стилю завантаження, прикладами чого, крім класичної Slackware, і CRUX, і Gentoo. А в Archlinux поняття runlevels взагалі втрачає значення, хоча відповідні слова у файлі /etc/inittab можна знайти, на практиці рівні виконання при старті системи ніяк не грають. А ось спроб впровадити в BSD-системи «прогресивний» стиль System V щось не спостерігається. Не вважати ж таким угруповання скриптів різних робіт на єдиному підкаталозі на / etc у FreeBSD 5-й галузі.
Щодо русифікації Іксів – X, як відомо, він і в Африці X. І дії з вписування шляхів до файлів з кириличними шрифтами, корекція клавіатурної розкладки та встановлення перемикача з латиниці на кирилицю виявляться неминучими, поверх якої операційки Ікси.
Другий показовий приклад – налаштування звуку. У FreeBSD це вимагає (для переважної більшості поширених чіпів та чіпсетного аудіо) внесення одного (і однакового у всіх випадках) рядка в конфігурацію ядра та перекомпіляції останнього. Після чого про звук можна просто забути - він працюватиме завжди і скрізь.
До речі, можна обійтися і без перекомпіляції ядра, модуль підтримки звуку збирається (як і багато модулів) у FreeBSD в обов'язковому порядку, достатньо завантажити його вручну або забезпечити завантаження при старті системи.
У Linux: починаємо з того, що те саме чіпсетне аудіо (а з поступовим вимиранням карт типу SB AWE128 воно стає кращим для всіх користувачів без претензій на меломанію або композиторство) неодмінно вимагає драйверів ALSA. Добре, що нині вони вбудовані в ядро і в більшості дистрибутивів включені в ядра як модулі. Якщо ні, то перекомпіляція ядра великої праці не становитиме.
Однак перекомпіляція ядра справа не обмежується. Потрібно ще поставити відповідний ALSA-інструментарій (та ще, як правило, засоби сумісності її зі старою звуковою системою OSS), активізувати відповідного демона і за допомогою не цілком очевидних засобів забезпечити його самовідновлення. І після цього знову зіткнутися з несподіванками. Наприклад, з небажанням мирного співіснування ALSA та arts (звукової системи KDE). Звичайно, мені можуть заперечити, що це проблеми KDE, проте FreeBSD їх не виникає зовсім.
До речі, про доустановку інструментарію (і інших програм)... Адже для цього необхідна Система управління пакетами
Тут донедавна першість, безумовно, належала FreeBSD. Система портів її забезпечувала незрівнянне поєднання простоти та гнучкості, завжди залишаючи можливість вибору – чи збирати пакети з вихідних джерел, чи встановлювати їх із бінарників. Не забороняючи і комбінацію цих методів. З усього Linux-ового багатства по цій частині з портами міг зрівнятися тільки Debian-овський apt, асимільований в надрах багатьох rpm-based дистрибутивів. Однак, хоча apt і передбачає можливість складання власних пакетів, основним методом при ньому є використання прекомпільованих бінарників, зібраних у відповідність до уявлень майнтайнера про залежність оних.
Нині становище змінилося і в Source Based дистрибутивах Linux широко використовуються портоподібні системи, що розвинулися під сильним впливом свого FreeBSD-прототипу: портежі Gentoo, Sorcery з Sorcerer'а, порти CRUX, Archlinux Building System з однойменного дистрибутива. Вони часом перевершують свого прародина гнучкості, глобалізації налаштування або прозорості пристрою, використання і модернізації До того ж, за десятиліття свого розвитку порти FreeBSD стали дуже громіздкою і важкооглядною спорудою, підтримка якої в актуальному стані є окремим завданням. яка сама по собі вже є частиною не базової системи, але системи портів).
І тут доречно сказати пару слів про ще одну поширену легенду – ніби збірка з вихідних джерел за допомогою портоподібних управляючих комплексів завжди призводить до більш «чистої» (тобто вільної від зайвих компонентів) системі. Це далеко не завжди так.
Во–первых, у самій природі портів (та його клонів) часто закладена деяка надмірність встановлюваних компонентів. Хрестоматійний приклад – cvs-up, що вимагає для актуалізації, як базової системи, так і портів FreeBSD: у бінарному вигляді це легкий компактний пакет, який навіть не обтяжує користувача з модемним підключенням. При складанні через порти він тягне за собою дистрибутив modula (оскільки на ньому написаний), який надалі не стане в нагоді нікому, крім прихильників цієї мови програмування.
Що мене завжди дивувало в портах FreeBSD, так це ситуація зі збиранням мого улюбленого редактора joe. Який як залежність неодмінно вимагав GNU make версії 3.80, хоча власний make входить до складу FreeBSD Distributions і зібрати з його за допомогою joe руками не становить жодних проблем.
А взагалі «чистота» установки пакета залежить від конкретної реалізації порту. Нещодавно виявив я в новинах повідомлення про нового віконного менеджера під назвою edo - невеликого, як говорилося, компактного і швидкого. Виявився він і в портах FreeBSD, звідки вирішив його зібрати. У результаті цей маленький:–) WM потягнув за собою (як залежність залежності) не що інше, як MySQL...
Однак якщо ви думаєте, що така поведінка портів - особливість FreeBSD, і творці їх Linux-клонів врахували помилки минулого, то запевняю це не завжди так. Причому в Linux ситуація посилюється особливостями базової системи, точніше неузгодженістю розвитку окремих її компонентів.
Кожен, кому доводилося збирати Linux from Scratch, знає, що деякі версії пакетів Base Linux мають звичай збиратися тільки з певними (не обов'язково найсвіжішими) версіями таких утиліт, як autoconf і automake, категорично відмовляючись робити це з іншими їх версіями (нехай навіть більш свіжими та прогресивними).
Розробники Source Based дистрибутивів Linux часом обходять цю складність тим, що примусово вносять до списку залежностей таких «слизових» пакетів autoconf і automake «торішнього» розливу, при тому, що сам по собі базовий комплект включає вже поточні на даний момент їх версії. В результаті чого, наприклад, у Gentoo при виконанні бутстрапінгу або emerge system можна з подивом спостерігати, як система лізе в Інтернет за бородатим, як Карл Маркс, autoconf хоча свіжа його версія щойно була розгорнута з тарбала stage1. А якщо згадати, що багато хто вважає, ніби по-справжньому стабільне ядро Linux може бути зібране тільки з gcc версії 2.9.X, результатом чого виявляється присутність у системі двох компіляторів, то про яку «чистоту» збірки можна ще говорити?
Втім, досягнення розумного балансу між розгортанням прекомпільованих пакетів, встановленням їх із портоподібної системи та самостійним «штучним» складанням – тема зовсім окремої розмови. А поки що ризикну сформулювати ще пару «об'єктивок»:
- FreeBSD, попри усталену думку, значно простіше в налаштуванні та локальному адмініструванні. Навіть без урахування того факту, що вона одна, а Linux-ів - багато;
- навпаки, система портів FreeBSD в даний час (на відміну від недавнього минулого) не має значних переваг перед аналогічними інструментами з Source Based дистрибутивів Linux.
Якщо ретельно підрахувати наведені вище плюси та мінуси обох операційних операцій, можна дійти висновку, що рахунок між ними – рівний. Можливо, з незначною позиційною перевагою FreeBSD, але настільки незначною, що цілком слушно погодитися на нічию. Однак кожна ОС встановлюється, налаштовується та нарощується додатками не заради себе самої, а для практичного використання. І тому слід розглянути в порівнянні їх
Тут для початку ризикну висловити крамольну, з погляду фанатиків будь-якої з обговорюваних систем, думка (втім, фанатики будь-яку думку, яка не співпадає з їхньою власною, вважають крамольною). А саме:
Для користувача, що надає перевагу роботі в графічному режимі, різниці між FreeBSD та Linux практично немає.
Бо такий користувач більшу частину часу проводить в Іксах, і йому абсолютно все одно, поверх якої операційки ці самі Ікси крутяться. Йому тільки здається, що він працює в Linux або FreeBSD (NetBSD, OpenBSD – ризикну розширити цей список). Насправді працює він у KDE (Gnome, XFce, WindowMaker – потрібне дописати). І якби йому не довелося попередньо встановлювати і налаштовувати свою операційну систему, він мав би шанс ніколи не дізнатися, в якій саме з POSIX-сумісних систем він працює: перед ним будуть одні і ті ж інтерфейсні елементи, одні і ті ж засоби налаштування та додатки .
Так що в порівняльному аспекті мова може йти тільки про роботу в консольному режимі з використанням системних і утиліт користувача базового комплекту.
І тут я не можу не вимовити оду текстової консолі FreeBSD та засобів управління нею. Які включають лише дві команди: vidcontrol і kbdcontrol, призначення яких однозначно випливає з назв. І які дозволяють налаштувати в консолі абсолютно все – від густини символів на екрані (т.зв. дозволу) до кольору бордюрів, своїх для кожного віртуального терміналу.
Користувач Linux для початку змушений розбиратися з тим, який із двох пакетів керування консоллю – kbd або console-tools застосовується у його дистрибутиві. Звичайно, нині вони практично ідентичні за своїми можливостями, але кожен має свій набір команд з синтаксисом, що трохи відрізняється. А деякі налаштування (наприклад, кольори тексту і фону) вимагають від нього використання команд, які не входять до жодного з пакетів. А дещо (наприклад, самі кольори бордюрів) все одно залишаться для нього недоступними.
Сказане стосується і базових команд обох систем. FreeBSD Distributions – моноліт, тісно пов'язаний з ядром, що включає в себе все, що може знадобитися користувачеві для адміністрування та використання системи (а адміністрування локального десктопу така ж завдання користувача, як і обробка текстів або маніпулювання файлами).
Звичайно, і Linux має той же самий набір класичних Unix-утиліт (точніше, як і FreeBSD, їх аналогами). Однак це саме роз'єднані пакети, що розроблялися в рамках проекту GNU, незалежно від операційної системи. І вже через це не настільки тісно інтегровані з нею та між собою.
Так що ж, у консольному режимі першість залишається поза FreeBSD? На мою думку, безумовно. Але тільки якщо йдеться саме про суто текстову консоль. Якщо ж звернути свій погляд на т.зв. графічну консоль (реалізовану за допомогою Frame Buffer), все бачиться дещо інакше.
Почати з того, що графічна консоль FreeBSD (т.зв. Raster Mode) обмежена одним-єдиним роздільною здатністю 800x600 (тут мова йде саме про справжній піксельному дозволі, а не щільність символів). Та й то на деяких чіпах цей режим не працює взагалі, на інших має цілком поганий вигляд. Власне, нормального результату в Raster Mode мені не вдавалося досягти ні на одній з відеокарт, що були в моєму розпорядженні.
У Linux графічна консоль просто радує око. Навіть за підтримки Frame Buffer для абстрактних VESA-сумісних карт, можна варіювати дозволи від 640×480 до 1280×1024, зі зміною глибини кольору в стандартному діапазоні. Що забезпечує не тільки комфортний перегляд зображень, а й дуже пристойне (на мій погляд – більш ніж пристойне) відтворення відео. Для карт, що мають добре реалізовані власні драйвера в ядрі Linux (Matrox, ATI, чіпсетне відео від Intel), до цього додається можливість встановлення нестандартних дозволів екрану.
Звичайно, ніхто не використовує консоль для роботи із зображеннями, і дуже мало для перегляду відео. Чому ж я надаю такої значення графічній консолі? Та тому, що непомітно, але настає ера рідкокристалічних дисплеїв, що знаменує смерть чисто текстового режиму (але не консольного режиму як такого). Чому легко зрозуміють ті, хто бачив стандартний текстовий режим 80x25 символів на 18-дюймовому LCD-моніторі з фізичною роздільною здатністю матриці 1280x1024. А як це виглядало б на екрані зі співвідношенням сторін 16:9, я боюся собі навіть уявити...
Нарешті, залишається ще одне питання, важливе для користувача -Про продуктивність
Уявлення про більшу швидкодію FreeBSD у порівнянні з Linux-ом так само традиційно, як і думка про більшу складність її налаштування. Проте чи все однозначно?
Во–первых, як із основних критеріїв у своїй розглядається швидкість завантаження, кореляція якої зі швидкістю виконання додатків дещо сумнівна. Пам'ятається, з великої кількості операційок, які мені довелося бачити у своєму житті, найшвидше завантажувалася MS DOS:–)
По-друге, навіть якщо вважати швидкість завантаження одним із критеріїв швидкодії, то перевага перед Linux-ом виявляє тільки FreeBSD 4-ї гілки. П'ята гілка вантажиться рівно стільки ж, скільки і будь-який дистрибутив Linux, що задіює файлову систему пристроїв devfs. Звичайно, в благородній Linux-родині можна підібрати таких представників, які вантажаться ще довше, але це дуже дружні до користувача системи, обтяжені ... достатком стартових сервісів (зокрема, автовизначником обладнання kudzu).
За своїм суто користувальницьким досвідом я б сказав, що різниці в швидкодії на завдання користувача між Linux і FreeBSD органолептично зазвичай не проглядається. За двома винятками, перший з яких – файлові операції.
Очевидно, що на продуктивність файлових операцій кожної ОС впливають два фактори - реалізація взаємодії з дисковою підсистемою (для робочого столу - безпосередньо з інтерфейсом ATA) і організація файлової системи (систем), що підтримується. І ось тут FreeBSD виявляється в невигідному в порівнянні з Linux положенні.
Вище згадувалося, що за рахунок CAM у FreeBSD (мова йде про 5-й гілці) досягається універсалізм у роботі з дисковими контролерами - у мене склалося враження, що їй взагалі байдуже, на якому конкретно контролері сидить диск (аби він впізнавав BIOS" – але й це необхідно тільки для завантаження з нього ядра.) Проте за універсалізм доводиться платити І, схоже, що в даному випадку розплата настає у вигляді зниження швидкодії дискових операцій – хоча достовірної інформації з цього питання я не знайшов, виходячи із загальних міркувань це виглядає схожим на правду.
Така перша сторона питання. Друга – файлова система FreeBSD, якими є UFS та (за замовчуванням у 5-й гілці) її вдосконалена модернізація UFS2. Традиційно в цій ОС обидві використовуються в частково синхронному режимі (noasync mode), коли зміни метаданих файлів записуються на диск негайно, а зміни блоків даних кешуються в оперативній пам'яті.
У Linux прийнято іншу модель роботи з ATA-дисками: різні типи контролерів мають (або не мають) власну підтримку в ядрі. Що виключає використання пристроїв, що явно не підтримуються, зате для підтримуваних, судячи з усього, забезпечує більшу швидкодію. Файлові системи (а Linux підтримує як нативні кілька їх різновидів) за замовчуванням всі (крім, можливо, JFS) використовуються в повністю асинхронному режимі (async mode), коли і дані, і метадані кешуються в оперативній пам'яті.
В результаті поєднання зазначених факторів файлові операції здійснюються на Linux значно швидше, ніж у FreeBSD. Власне, я завжди це підозрював, але тільки показало, наскільки відставання FreeBSD 5-ї гілки в цьому плані суттєве – становище не рятує навіть механізм SoftUpdates, покликаний підвищити надійність і продуктивність маніпуляцій над файлами. До речі сказати - у FreeBSD 4-й гілки такого відставання раніше не спостерігалося, що побічно підтверджує негативний вплив роботи з дисковою підсистемою (що посилює деградацію саме синхронних операцій) - в ній модель CAM не використовується (принаймні, не використовувалася, коли я нею користувався). А ось у Linux з його виключно асинхронним використанням файлових систем, за моїми спостереженнями, залежність швидкості роботи з файлами від продуктивності дискового заліза майже немає.
Друге з обіцяних винятків відноситься до операцій свопінгу. Які в Linux та FreeBSD виконуються суттєво по-різному. Для встановлення чого достатньо подивитися на виведення команди top у тій та іншій ОС при середньому навантаженні. У Linux можна побачити, що з достатньої кількості оперативної пам'яті відсоток використання swap–пространства прагне нулю. Наприклад, на моєму ноутбуці з Linux (512 Мбайт пам'яті) в момент створення цих рядків, при завантаженому KDE, html-редакторі Quanta, konsole, двох екземплярах konqueror і працюючому mplayer (відтворення mpeg і RealAudio), swap не задіяний взагалі. На робочому столі з FreeBSD (1 Гбайт пам'яті) при тому ж навантаженні задіяна область підкачування менше 10% майже не опускається.
Це пов'язано з тим, що Linux вдається до свопінгу тільки при переповненні оперативної пам'яті, у FreeBSD ж на диск у будь-якому випадку (навіть при надлишку RAM) вивантажуються сторінки пам'яті, до яких не було звернень протягом якогось проміжку часу. По суті, оперативна пам'ять у цій ОС виступає як свого роду кеш для області підкачування (точніше, для віртуальної пам'яті взагалі). Що ефективно при обмеженому її обсязі і було виправдано в давні часи, коли процесори були повільними, а пам'яті – мало. Нині така модель використання свопінгу в деяких ситуаціях призводить до уповільнення роботи. Приклад – KDE з великою кількістю робочих столів та періодичним перемиканням між ними, де таке уповільнення видно неозброєним оком.
Все це обумовлює більшу об'єктивну (встановлювану тестами) і особливо суб'єктивну швидкодію Linux порівняно з FreeBSD. Хоча має знову підкреслити – йдеться саме про десктопну сферу: на сильно завантаженому сервері механізм кешування FreeBSD може проявити свої сильні сторони, і швидкісні співвідношення між цими системами, можливо, у ряді випадків виявляться прямо протилежними. Підіб'ємо підсумки
На початку цієї нотатки я не обіцяв дати однозначної відповіді на поставлене в її заголовку питання. Точніше обіцяв, що його не буде. І справді, для себе однозначної відповіді я не бачу. Але деякі намітки для нього зробити собі дозволю.
Чим підкуповує FreeBSD – так це а) простотою установки, б) логічністю налаштування та в) легкістю адміністрування в локальному масштабі. Однак ті ж особливості (принаймні більша їх частина) характерні нині і для кращих (на мою думку) сучасних представників Linux-родини (CRUX і Archlinux, певною мірою – Gentoo). Хоча очікувати від них внутрішньої стрункості та цілісності FreeBSD, зі зрозумілих причин, найближчим часом не доводиться.
У той же час я усвідомлюю архаїчність файлової системи FreeBSD, особливо чітко проступає в порівнянні з сучасними реалізаціями ReiserFS і XFS для Linux. І майже місячна експлуатація FreeBSD-десктопа і Linux-ноутбука - машин з практично рівною номінальною швидкодією, - що називається, віч-на-віч, переконує мене в більшій швидкодії останньої. А ось що має більшу вагу для користувача – це кожен має вирішувати для себе. Хоча, як це не прикро, Linux зараз здається найкращим вибором для настільного застосування.
Однак підкреслю – зараз, адже вихід версії FreeBSD 5.3 може суттєво змінити ситуацію. Однак, що б не трапилося, майбутнє хотілося б бачити як взаємовплив обох операційних систем, взаємну асиміляцію всіх плюсів та виживання мінусів. Чому я й закінчив би свою тривалу розповідь гаслом у дусі радянських часів:
Демон із пінгвіном – брати навіки!
Вступ
Старт системи розпадається на два етапи, лише опосередковано пов'язані між собою — власне завантаження її та ініціалізацію.
Під завантаженням операційної системи розуміється запуск виконання спеціальної програми, що називається образом ядра системи (чи навіть ядром). Образ ядра — майже звичайний бінарний файл. І специфіка його запуску — тільки в тому, що, якщо будь-які інші програми запускаються під управлінням будь-якої ОС, зчитуючись з файлової системи, яку ця ОС сприймає як рідна (native), то ядро має запуститися як би само собою, без будь-якої операційної системи (бо воно і є операційною системою), і з носія, про який система нічого не знає (оскільки сама вона ще не завантажена). Не випадково в англомовній літературі для процесу завантаження існує загальноприйнята метафора називається bootstrapping, що так само алегорично можна перекласти як «підняття себе за шнурки своїх черевиків». І хоча в реальному житті таке не кожному вдається, у світі POSIX-систем ця процедура здійснюється регулярно — і зазвичай успішно.
Образ ядра системи містить все необхідне для чистого bootstrapping'а. Проте виконати його можна лише з носія без файлової системи. Тому прямий запуск ядра, наскільки я знаю, використовується тільки при завантаженні з дискети. При звичайному старті ОС з вінчестера в цій справі бере участь і якась зовнішня сила — спеціальна програма, яка називається завантажувачем. Вона завантажує ядро системи, відповідає за визначення обладнання, підвантаження об'єктних модулів (модулів ядра, що завантажуються) і монтування кореневої файлової системи (в режимі «тільки для читання»). Ядро ж тим часом запускає системні (тобто не пов'язані з виконуваними файлами) процеси, що управляють віртуальною пам'яттю, буферами, сторінками пам'яті і т.д., аж до swapper'а, а по завершенні - свій і перший «звичайний» (тобто асоційований із виконуваним файлом на диску) процес init (/sbin/init).
Після цього в дію вступає система ініціалізації. Її роль — забезпечити за допомогою відповідних стартових скриптів (вони ж — сценарії ініціалізації), монтування файлових систем (і перемонтування кореня в режимі «читання/запису»), запуск основних системних сервісів або демонів, виклик команд для отримання терміналу (процеси getty) та авторизації користувачів (login). Закінчення старту системи знаменується запрошенням до авторизації.
Зорово етапи завантаження та ініціалізації відрізняються тим чи іншим візуальним поданням повідомлень, що виводяться. У DragonFlyBSD, наприклад, повідомлення про хід завантаження виводяться символами радикально білого кольору, що змінюються на етапі ініціалізації звичайним білим приглушено.
Завантаження та ініціалізація - це перше, що в будь-якій ОС бачить користувач. Щоправда, користувачеві POSIX-сумісної системи таке задоволення випадає набагато рідше, ніж підвіконню. Нормальний режим експлуатації домашньої Unix-машини - це її включення рано-вранці і вимкнення - пізно ввечері. (Щоправда, уявлення про «рано» та «пізно» у всіх свої). А службова Unix-машина по-доброму вимикатися взагалі не повинна — аж до повної фізичної амортизації. Ну а необхідність у рестарті системи в процесі роботи в Linux або BSD виникає надзвичайно рідко. Власне, тільки після перескладання та реінсталяції нового ядра (або перенесення кореневого розділу — але це вже взагалі винятковий випадок) — у всіх інших випадках реконфігурування системи можна обійтися без цього.
Так що, здавалося б, що за справу користувачеві до того, як протікає старт системи, і як довго він триває? Проте деякі дії з налаштування обох етапів цього процесу бувають необхідними. Бо при старті системи не тільки виводиться деяка заставка і, можливо, меню з варіантами завантаження, а й підвантажуються модулі ядра, що відповідають готівковому обладнанню, монтуються файлові системи, запускаються сценарії ініціалізації, відкриваються віртуальні термінали тощо, тощо. Звичайно, безумовно обов'язковим із усіх цих дій є лише власне завантаження ядра — інші можуть бути виконані згодом. Однак чи не краще налаштувати систему так, щоб відразу після закінчення процедури її старту отримати повністю готову до вживання систему, ніж потім доводити її вручну до цього стану?
Крім того, розуміння ходу завантаження та ініціалізації буде не зайвим при ручному втручанні в цей процес. А необхідність такого втручання — на жаль, іноді виникає в аварійних ситуаціях...
Так що давайте простежимо основні стадії завантаження та ініціалізації DragonFly і подивимося, що в них підлягає налаштуванню, а також де і як (а головне – навіщо) в них можна втрутитися.
Про завантаження та завантажувачів
Розпочати вивчення старту системи резонно з першого її етапу - а саме, власне завантаження. Як вже було сказано, управління цими етапами здійснює спеціальна програма, яка російською так і називається - завантажувач. Хоча в англійській для неї використовується два терміни - loader і boot manager (що, як ми побачимо з часом, трохи різні речі, але зараз це не важливо).
Насправді будь-який завантажувач включає дві або навіть три відносно незалежні частини — навіть якщо він поширюється у вигляді єдиного пакета, як Lilo або GRUB. Щоб переконатися в цьому, уявімо собі, як відбувається запуск машини на "залізному", так би мовити, рівні (мається на увазі - intel-сумісної персоналки, на інших архітектурах все трохи інакше).
Насамперед після включення живлення запускається програма, прошита в ПЗУ комп'ютера (BIOS). Вона виконує перевірку заліза, після чого шукає носій, встановлений в BIOS Setup як перший завантажувальний пристрій (для визначеності - вінчестер), на ньому - перший фізичний блок, що містить так званий головний завантажувальний запис (MBR - Master Boot Record).
Вміст MBR - це, по-перше, таблиця дискових розділів, тих чотирьох, в один з яких ми раніше встановили DragonFly. А по-друге - якийсь код, що приймає на себе керування від BIOS після закінчення його роботи. У стандартному MBR - тому, що записаний на "свіжовкрученому" вінчестері або відновлюється після DOS-команди FDISK /mbr - цей код тільки і може, що знайти перший фізичний розділ диска (primary partition) і передати управління на його завантажувальний сектор. Чого цілком достатньо для завантаження операційних систем на кшталт DOS або Windows 9X/ME з першого (або єдиного) розділу. Але явно мало в будь-якому іншому випадку, наприклад, якщо на диску встановлено кілька ОС, які, природно, не можуть уміститися в одному розділі.
Тому до складу будь-якого завантажувача має входити програма, що записується в MBR. Оскільки обсяг останнього - всього 512 Кбайт (розмір фізичного дискового блоку), з яких частина вже зайнята під таблицю розділів, особливо багатих функцій до цієї програми не вмістити. Зазвичай вона здатна на те, щоб упізнати всі задіяні (used) первинні розділи, вивести їх список і дозволити користувачеві вибрати розділ для завантаження, після чого передати управління на завантажувальний сектор обраного розділу.
Подібно MBR, завантажувальний сектор розділу (Boot Record - вже не Master!) містить інформацію про його розмітку (Disk Label), що залежать від схеми, що використовується в даній ОС, і керуючий код, що приймає естафету від програми, записаної в MBR. І цей код – друга складова частина завантажувача. Щоправда, її можливості також не можуть бути багатими — адже розмір завантажувального сектора розділу становить ті ж 512 Кбайт. І тому на неї покладається одна-єдина функція - передати управління програмі, що лежить за межами завантажувального сектора. Яка, власне, і повинна пізнати кореневий розділ ОС і несаму файлову систему, після чого, прямо або опосередковано, завантажити її ядро.
Легко здогадатися, що перші дві складові завантажувача, по суті, не мають відношення до жодної операційної системи, і не є частинами файлової системи взагалі. А от із третьою — можливі варіанти. Вона може входити у файлову ієрархію завантажуваної ОС, як Lilo, або являти собою щось на зразок самостійної міні-ОС, як GRUB (не випадково його настійно рекомендують встановлювати у власний дисковий розділ, що не монтується за замовчуванням до кореня будь-якої з операційних операцій). А як справи з пристроєм завантажувача нашої героїні — DragonFlyBSD?
Стадії завантаження
У цій ОС для завантаження системи використовується програма, загальна всім операционок BSD-родини. Вона має власне ім'я, і ім'я це, як не дивно, — BSD Loader (хоча, як з'ясується трохи пізніше, це дещо умовно).
Маю покаятися — за кілька років спілкування з FreeBSD та епізодичним знайомством із її сестрами (OpenBSD і навіть NetBSD) у мене якось не було приводу розбиратися з пристроєм їхнього завантажувача. Ну вантажить він чудово рідну систему - і чудово (наприклад, FreeBSD). Грузить також інші BSD-системи — ще краще. Що без напруження і Linux може завантажити — взагалі здорово. А те, що ще й на завантаження Windows здатний — це просто безкоштовний додаток…
Як і перебував би я в щасливому незнанні, якби якось у зв'язку з встановленням FreeBSD на ноутбук Toshiba не довелося покопатися трохи з опціями BSD Loader. І тут виявилося, що це — програма з потужними інтерактивними можливостями, та ще й з налаштуванням. Не порівняти з GRUB'ом, звичайно, але якщо не експериментувати з численними операційними системами на багатьох вінчестерах, — функцій loader'а виявляється більш ніж достатньо. Що я спробую продемонструвати нижче на прикладі ОС DragonFlyBSD. Однак майже все сказане має силу і для інших BSD-систем (а для FreeBSD - і без застереження «майже»).
Основна особливість завантажувача DragonFly (хоча майже все сказане має силу і для всіх інших BSD-систем — а для FreeBSD і без застереження «майже»), що відрізняє його від Lilo і меншою мірою GRUB — те, що він не маскує свою багатокомпонентну природу, включаючи чотири (майже) самостійні програми.
Перша частина завантажувача (т.зв. boot0) - це програма, що записується при інсталяції системи в завантажувальний сектор диска, з якого здійснюється завантаження машини згідно з установками BIOS. Зазвичай це Master на першому IDE-каналі (про SCSI-диски тут не буде), але можливі варіанти (наприклад, за наявності апаратного ATA RAID або додаткових ATA-контролерів). Ця програма відповідає за першу стадію етапу завантаження, а якою відбувається читання таблиці первинних дискових розділів, виведення їх списку (якщо розділів більше одного), деякого періоду очікування для вибору користувачем (за замовчуванням завантажувальним буде розділ, обраний у попередньому сеансі роботи) та після такого (або після закінчення фіксованого періоду очікування), передачі управління коду, записаному в завантажувальному секторі вибраного (або замовчального) розділу. Вибір розділу здійснюється натисканням клавіш F1—F4). Якщо два диски, натискання клавіші F5просто передасть керування на завантажувальний сектор другого з них - а там уже події потечуть залежно від того, що в ньому записано: читати розділи на другому фізичному диску boot0 сам не здатний.
Список розділів для вибору включає їх імена відповідно до ідентифікаторів типу файлової системи, наприклад:
F1 DOS F2 Linux F3 BSD F5 Drive 1
Донедавна BSD Loader не міг ні впізнати логічні розділи всередині Extended DOS, ні завантажити з них якусь операційну систему. Однак нині становище, мабуть, змінилося: це можна укласти з повідомлень про можливість встановлення DragonFlyBSD у розширений розділ (єдиною, наскільки мені відомо, із BSD-систем, на це здатною). А чи можна уявити установку системи без можливості її завантаження штатними засобами?
У принципі наявність першої частини BSD-завантажувача не є обов'язковим: його цілком може підміняти завантажувач Linux (той самий Lilo, що передає управління на завантажувальний сектор BSD-слайсу «по ланцюжку») або мультисистемний GRUB, який здатний працювати з файловими системами і завантажувати ядра різних операційок.
Друга частина (boot1) розміщується у завантажувальному секторі первинного розділу, що несе BSD-систему (BSD-слайсу). Тобто і boot0, і boot1 лежать не тільки за межами файлової системи, але і, фактично, поза власне слайсом BSD. Третя ж частина (boot2) лежить вже всередині слайсу, але не входить до якогось із його логічних розділів.
Друга та третя частини завантажувача — це, по суті, єдина програма, розділена лише через обмеження розміру завантажувального сектора розділу (512 байт). Так що в завдання boot1 входить лише впізнати слайс BSD, знайти на ньому boot2 і передати йому керування. А вже той повинен, почекавши деякий час, впізнати кореневу файлову систему, знайти на ній і запустити двійковий виконуваний файл - /boot/loader , що утворює четверту частину завантажувача; строго кажучи, термін BSD loaderтільки до цієї програми і належить.
Таким чином, можна бачити, що перші три частини BSD-завантажувача (boot0, boot1 і boot2) лежать поза файловими системами встановленої ОС BSD. В яку ми потрапляємо тільки починаючи з запуску loader , звичайного файлу, що виконується, що міститься в спеціальному каталозі /boot кореневої файлової системи.
Щоправда, у каталозі /boot (це — «умолчальное» місце розташування loader) поруч із його виконуваним файлом можна побачити також файли з іменами boot0 , boot1 і boot2 . Але вони є лише копії відповідного коду, розташованого (і запускається) поза файловою системою BSD. Призначення їх – відновлення можливості завантаження після аварійних ситуацій.
Завдання loader 'а - швиденько завантажити ядро і набір замовчальних модулів, після чого він виводить своє меню з логотипом проекту, на якому можна дізнатися бабку (що підміняє чортика з вилами з FreeBSD). Меню містить такі пункти:
- Boot DragonFly— нормальне завантаження ядра з усіма модулями, монтуванням файлових систем і відпрацюванням запропонованих стартових скриптів;
- Boot DragonFly with ACPI disabled— те саме, тільки з вимкненням модулів acpi, що іноді може знадобитися на деяких ноутбуках;
- Boot DragonFly in Safe Mode- Завантаження в безпечному режимі, тобто без підключення модулів;
- Boot DragonFly in single user mode— завантаження в режимі одного користувача, при якому монтується (та й тільки для читання) лише коренева файлова система, а етап ініціалізації ігнорується;
- Boot DragonFly with verbose logging- Звичайне завантаження, але з виведенням докладних повідомлень;
- Escape to loader prompt- Вихід у командний рядок завантажувача;
- Reboot— ну, це ми знаємо, як три пальці, тільки краще.
Якщо не зробити жодного вибору — через десять секунд почне завантажуватися замовчальний варіант. Для запобігання чого (і отримання додаткового часу на роздуми) достатньо натиснути Spacebar— відлік часу зупиниться, і завантаження не буде до явного вибору.
Після вибору або закінчення терміну давності починається досить тривалий процес визначення обладнання, в ході якого на екран виводяться численні повідомлення ядра — їхня відмінність від звичайних повідомлень — у яскраво-білому «забарвленні» символів. Ці повідомлення дуже цікаві, але розглянути їх нелегко. Що, втім, не страшно – надалі їх можна буде переглянути командою dmesg. Після цього монтується коренева файлова система і з неї (звичайним виконуваним файлом /sbin/init) запускається процес init, відпрацьовуються стартові скрипти. На ознаменування цього яскраво-білий колір повідомлень ядра змінюється на звичайний сірий - етап завантаження, який нас цікавить зараз, закінчено.
Інтерактивне керування процесом завантаження
Виникає питання – чи може користувач вплинути на процес завантаження? Відповідь на нього буде позитивною. У ході роботи завантажувальної системи користувачеві тричі надається свобода вибору: вибору розділу завантаження на початковій стадії boot0 , вибору інтерактивного управління на стадії boot2 і вибору режиму завантаження відразу після запуску loader 'а. І у всіх цих випадках користувач може втрутитися у процес руками. Навіщо? Це вже інше питання, і відповідь на нього, сподіваюся, стане зрозумілою з наступного викладу.
З вибором розділу завантаження все ясно: він дозволяє завантажити одну з ОС, якщо на цій машині встановлено кілька. А ось на стадії роботи boot2 можна перервати його виконання, точніше уникнути запуску loader 'а. Для цього в паузі між вибором завантаження з BSD-розділу та появою повідомлень про завантаження ядра та модулів (пауза ця знаменується появою на екрані миготливого символу _) потрібно натиснути будь-яку клавішу. У відповідь буде запрошення виду:
>> BSD/i386 BOOT Default: 0:ad(0,a)/boot/loader boot:
І в рядку запрошення можна вказати варіант завантаження, відмінний від замовчування. Наприклад, можна безпосередньо завантажити файл образу ядра системи. Це може мати деякий сенс після перескладання ядра - якщо нове виявилося конфігурованим недостатньо коректно для завантаження (але - на жаль - достатньо, щоб скомпілюватися).
Для цього потрібно сконструювати шлях до старого ядра за образом і подібністю до умовчального варіанту. Тобто вказати:
- номер диска в машині у відповідність до BIOS (0 — перший з готівки, 1 — другий, і так далі, незалежно від порядку підключення);
- його інтерфейс - у прикладі ad символізує ATA диск (для SCSI диска було б da, для дискети - fd);
- номер на IDE-каналі (0 - майстер, 1 - слейв);
- розділ у сенсі, використовуваному BSD Label, тобто частина слайсу, що резервується під кореневу файлову систему BSD (a;
- Ім'я файлу старого ядра - /kernel.old .
Якщо на диску є кілька первинних розділів різних типів, то розділи не-BSD типу будуть пропущені, і літера a (очевидно, що образ ядра може лежати тільки на кореневій файловій системі) буде ставитись до першого підрозділу слайсу з ідентифікатором 165 (навіть якщо на диску він буде четвертим за ліком).
При сумніві в точному імені файлу (а їх може бути кілька перед інсталяцією кожного нового неопробованого ядра рекомендується зробити копію попереднього, свідомо працездатного), у рядку запрошення можна ввести знак питання, відповіддю на що буде список кореневого каталогу (але не глибше - переглянути вміст підкаталогів, навіть у тій самій файловій системі, на стадії boot2 не вдасться).
Втім, ту ж процедуру - завантаження старого ядра, - можна (і потрібно, оскільки це набагато простіше) виконувати через loader, до розгляду інтерактивних можливостей якого ми переходимо.
Меню loader 'а пропонує достатній вибір режимів для штатних ситуацій, але всі позаштатні (на те вони такі й є) явно не охоплює. Зокрема, варіант завантаження старого ядра в меню не передбачено. На щастя, передостанній пункт меню вирішує цю проблему (і заразом багато інших).
Отже, вибравши пункт шостий меню Escape to loader prompt, - ми опиняємось у середовищі командного інтерпретатора loader 'а. Вона має шелл-подібний інтерфейс - команди з їх опціями та аргументами вводяться після запрошення, що має вигляд
З погляду зручності інтерактивної роботи — не GRUB, звісно: ні тобі автодоповнення, ні історії команд, можливості редагування обмежені клавішею Backspace. Але з головною своєю роллю - введенням та виконанням вбудованих команд, - loader цілком справляється.
Тим більше, що цих команд досить багато: повний їх список можна отримати, ввівши знак питання в командному рядку. Доступна і допомога - команда help видасть коротку підказку, help имя_команди - докладніші відомості про використання команди-аргументу. Втім, синтаксис команд — також шелоподібний, тож труднощів із цим бути не повинно.
Вбудовані команди loader можна розділити на три частини за їх призначенням:
- для отримання інформації;
- для конфігурування завантажувача;
- власне керувати процесом завантаження.
З першої групи команд відзначимо наступні: ls, lsdev, lsmod, show, more. Перша призначена для перегляду кореневої файлової системи та її підкаталогів — правда, тільки тих, що не лежать на окремих підрозділах. Але оскільки всі необхідні для завантаження файли лежать у підкаталогах безпосередньо кореня (у /boot, /dev, /modules), це обмеження не суттєво. Варіант команди ls -l виводить список файлів (і каталогів) із зазначенням їх розміру – без цієї опції лише літерою d позначаються каталоги.
Команда lsdev виводить список дискових пристроїв, що є в машині, їх первинних розділів та підрозділів (останні тільки для розділів, розмічених за правилами BSD Label). Опція -v забезпечує деталізацію виведення.
Команда lsmod забезпечує перегляд модулів, завантажених loader до появи меню (або запрошення командного рядка). Як і в попередньому випадку, є опція деталізації -v.
Команда show виконує аналогічну функцію, але щодо змінних завантажувача. Дана без аргументу, вона виводить значення всім певних змінних. Якщо ж як аргумент вказати ім'я змінної, то буде показано лише її значення. Допустимо кілька аргументів, що розділяються крапкою з комою.
Ну а more виконує ті ж функції, що і її тезка з Unix-утиліт. Вона дозволяє переглянути вміст текстового файлу - тобто, перебуваючи в командному інтерпретаторі loader 'а, ми можемо ознайомитися з конфігами, важливими для завантаження (і з будь-якими іншими).
Команди конфігурування дозволяють визначити чи зняти змінні завантажувача, завантажити чи видалити модулі ядра. Як мовилося раніше, саме ядро з певним зумовленим набором модулів і змінних завантажується до меню loader 'а його командного інтерпретатора. Так ось, за допомогою відповідних команд ці наперед визначені набори можна дещо скоригувати (або змінити повністю). Це може бути необхідно, якщо умовна конфігурація ядра з яких-небудь причин не вантажиться (частий випадок - конфлікт ноутбучних систем енергозбереження з системними модулями ACPI), з метою налагодження, або просто задоволення цікавості для.
Спочатку розглянемо команди керування модулями. Це пара команд load і unload для завантаження і видалення модулів, відповідно. Перша використовується з аргументом ім'я_модуля, яке за потреби можна підглянути (за допомогою ls) у каталозі /modules - ім'я в аргументі дається без суфікса *.ko. Команда unload з аналогічним аргументом видалить зазначений модуль, без аргументів - видалити всі модулі взагалі, дозволяючи почати конфігурацію з аркуша.
Дія команд load і unload поширюється на ядро загалом. Так, за допомогою команди
OK unload kernel
можна вивантажити з пам'яті ядро (наприклад, якщо воно виявилося непрацездатним), а за допомогою команди
OK load kernel.old
завантажити ядро старе, працездатне.
Пара аналогічного призначення - set і unset, - існує і для змінних оточення завантажувача. Ці змінні служать для зміни поточного дискового пристрою, вказівки розташування кореневої файлової системи, визначення шляхів до модулів ядра, відмінних від умовчального /modules , і тому подібних речей. Робиться це командою set у відповідність до синтаксису C-shell, наприклад:
OK set currdev="disk1s1a"
Визначає поточний пристрій у термінах «диск#_слайс#_раздел».
Допустимо кілька значень для однієї змінної - вони поділяються крапкою з комою. Наприклад,
OK set module_path="/;/modules;mymodule_path"
визначає розташування модулів ядра - кореневий, замовчальний каталог modules і каталог /mymodule_path: очевидно, що якщо просто визначити в цій змінній шлях до власних модулів, інформація про розташування модулів замовчальних була б втрачена. Звертаю увагу на присутність у визначенні змінної значення / - цей шлях необхідний для завантаження ядра за допомогою команди load (DragonFlyBSD ядро за замовчуванням встановлюється в кореневий каталог).
Деякі змінні просто дозволяють або забороняють якісь дії, і, відповідно, їх значення булеви — YES або NO . Звичайно, вони потребують деталізуючих змінних, що визначають те, що ними було дозволено. Наприклад, змінна
OK set userconfig_script_load="YES"
тільки дозволяє виконання користувацьких сценаріїв конфігурування, а змінна
OK set userconfig_script_name="/boot/my.conf"
визначає, який саме сценарій має бути застосований у цьому випадку.
За допомогою змінних можна визначати режими завантаження. Наприклад, після встановлення змінної
OK set boot_single
Визначення змінної може скасовуватися командою
Unset ім'я_змінної
У деяких випадках її еквівалентом буде визначення змінної з булевим значенням NO або словом disable в імені.
Повний список вбудованих змінних оточення завантажувача можна переглянути на відповідній man-сторінці:
$ man 8 loader
І, нарешті, команди керування завантаженням. Найважливіша з них — boot , без опцій та аргументів, що викликає негайне завантаження ядра в його замовчальній або поточній (тобто з перевизначеними змінними та модулями) конфігурації. /p>
Опції команди boot конкретизують режим завантаження. Наприклад, команда
OK boot-s
Викликає завантаження в режимі одного користувача. Це еквівалентно тому, якби виконати ту ж команду без опцій, попередньо встановивши змінну boot_single .
Аргументи команди boot можуть визначити ім'я образу ядра, виконуваного сценарію завантаження, і так далі. Той самий сакраментальний приклад: команда
OK boot kernel.old
призведе до завантаження старого ядра, аналогічно команді boot без опцій після виконання пари
OK unload kernel OK load kernel.old
Втім, перша команда цієї пари все одно не завадить — щоб уникнути… Особливо якщо нове ядро зібралося зовсім криво.
Тут було розказано не про всі можливості інтерактивного режиму BSD-завантажувача — лише про ті, які мені довелося використовувати. Більш детальні відомості можна отримати не тільки в man (8) loader, але і безпосередньо читанням файлу допомоги:
$less /boot/loader.help
І зовсім не обов'язково в процесі керування завантаженням – краще зробити це завчасно.
Конфігурування завантажувача
Користувач, який встиг перейнятися духом Unix Way (або хоча б відчув його), має право запитати: якщо в процес завантаження можна втрутитися інтерактивно, чи не можна певні при цьому параметрами параметри раз і назавжди зафіксувати? І відповіддю йому буде: звичайно ж, можна.
Інтуїтивно ясно, що оскільки втручання користувача можливе на першому (boot0) і останньому (loader) етапах завантаження, саме вони і піддаються налаштуванню. Так воно і виявляється.
Правда, на першому етапі завантаження можна налаштувати не так вже й багато, а саме:
- змінити час очікування вибору розділу (за замовчуванням воно дорівнює дивній цифрі 18,2 секунд — так у документації сказано);
- зафіксувати один із розділів як завантажувальний за замовчуванням - без цього, як уже говорилося, умовним виступає розділ, вибраний при попередньому старті машини;
- ще деякі дрібниці, практичного значення не мають.
Наведеним цілям служить команда boot0cfg. Варто пам'ятати тільки, що її використання пов'язане зі зміною Головного Завантажувального Запису (MBR), руйнування якого призводить до неможливості старту машини з диска. Імовірність запсувати цією командою MBR надзвичайно мала, та й страшних наслідків не має. Однак (береженого бог береже) – краще тримати під рукою інсталяційний диск DFBSD. Не для переустановки системи, звичайно, але для відновлення завантажувального запису — адже це велика рятувальна дискета. А як буде предметом наступної статті циклу.
Отже, можна змінити час очікування за допомогою опції -t # , де # — значення в секундах (нульове значення не допускається). За допомогою опції -s # один певний розділ диска робиться завантажуваним за замовчуванням на віки вічні (а не той, з якого був виконаний старт при останньому включенні машини). Очевидно, що тут допустимі значення 1-4 (за кількістю можливих первинних розділів) плюс 5 – передача управління на MBR другого диска. А опція -v дасть нам докладнішу інформацію про результати виконаної операції. Ну і, звичайно, потрібно аргумент - ім'я дискового пристрою, MBR якого ми змінюємо. Тобто команда
$ boot0cfg -t 30 -s 2 -v -f /boot/boot0.old ad0
модифікує MBR першого IDE-диска (аргумент ad0) так, що 2-й його слайс стане замовчально-завантажувальним, час на вибір розділу зросте до 30 секунд, і видасть звіт про результати своєї роботи у вигляді приблизно наступного:
# flag start chs type end chs offset size 1 0x00 0: 1: 1 0x83 850:254:63 63 13671252 2 0x80 851: 0: 1 0xa5 261:254:53 = 50 30 options=packet,noupdate,nosetdrv default_selection=F2 (Slice 2)
Так, опція -f створить копію поточного завантажувального запису в каталозі /boot ; правда, файл /boot/boot0 і є копією MBR свіжоінстальованої системи, але для страховки ще один дубль не зашкодить.
Звернемо увагу на опцію noupdate у підсумковому висновку команди: саме вона фіксує один із слайсів як завантажуваний за замовчуванням. Якщо таке становище з якихось причин не сподобається, це легко змінити, повторивши команду в такій формі:
$ $ boot0cfg -o update ad0
Ну а сенс інших опцій (та інші способи застосування команди) можна уточнити у тітки Мані: man(8) boot0cfg.
Ось ми й дісталися налаштування власне loader 'а. Я якось раніше обмовився, що до появи меню і можливості переходу в інтерактивний режим вже встигає завантажитися ядро з певним набором параметрів, і обіцяв розповісти, де і ким ці параметри покладені. Настав час виконати свою обіцянку.
Так ось, параметри завантаження ядра покладені сценарієм ініціалізації завантажувача - /boot/loader.rc. Насправді це своєрідний пакетний файл, з якого викликається кілька окремих сценаріїв, але для нас зараз це не суттєво. А важливо те, що покладено умовні змінні оточення завантажувача та їх значення у парному сценарії конфізі - файлі /boot/defaults/loader.conf. У ньому описуються і шляхи для пошуку модулів, і ім'я стандартного ядра, і поточний дисковий пристрій і коренева файлова система, і час затримки перед завантаженням - все те, що можна визначити як змінні оточення інтерактивно. А ще в ньому є список різноманітних модулів ядра (загалом кажучи, всіх можливих) і вказується, чи слід їх завантажувати автоматично під час старту, чи ні.
Сам по собі /boot/defaults/loader.conf для редагування не призначений, лише показує всі можливі параметри завантаження і фіксує їх значення за замовчуванням. І тому власне цілей налаштування loader 'а служить не він, а файл /boot/loader.conf.
Щоправда, одразу після встановлення системи ми такого файлу в системі не побачимо. Його потрібно створити самому, перенести в нього потрібні опції файлу /boot/defaults/loader.conf і належним чином змінити їх значення.
У налаштуванні будь-якої системи зазвичай простіше показати, як вона робиться, ніж розповісти про це. І тому наведу як приклад свій /boot/loader.conf з деякими коментарями. Я людина проста, до надмірностей не схильна, і тому файл цей у мене дуже маленький.
Autoboot_delay="5" # Час очікування перед автозавантаженням beastie_disable="YES" # Скасування виведення меню завантажувача usb_load="YES" # Завантаження модуля підтримки шини USB ugen_load="YES" # Завантаження підтримки USB-пристроїв взагалі ums_load="YES" # Завантаження підтримки USB-миші # Ці рядки потрібні, якщо відповідні функції # не вбудовані в ядро жорстко snd_pcm_load="YES" # Завантаження модуля підтримки звуку snd_ich_load="YES" # Завантаження модуля звукового пристрою # У прикладі - чіпсетне аудіо від Intel ICH#
Додатково тут можна включити завантаження модуля зберігачів екрану взагалі і, за тим, конкретного модуля (відповідні файли розташовані в каталозі /modules і мають вигляд *_saver.ko):
Vesa_load="YES" screensave_load="YES" screensave_name="fire_saver"
А можна також завантажити і власну splash-картинку (створенням якої, у форматі *.bmp або *.pcx, і її розміщенням у каталозі /boot слід подбати завчасно):
Splash_bmp_load="YES" bitmap_load="YES" bitmap_name="filename.bmp"
Звернімо увагу на рядок vesa_load , що підвантажує модуль підтримки однойменного режиму в консолі: він необхідний для деяких, графічних, скрінсейверів (наприклад, наведеного в прикладі «полум'я») і, звичайно, splash-картинок. Втім, підтримка VESA може бути вбудована у ядро (див. циклу).
Наведений приклад не вичерпує можливості реконфігурації завантажувача — інші можливості можна отримати з перегляду файлу /boot/defaults/loader.conf . Потрібно тільки мати на увазі, що якісь функції, що забезпечуються модулями, що підвантажуються, можуть бути вже вкомпільованими в ядро — замовчальне або власноруч зібране, — і дублювати їх не потрібно. Тобто перед редагуванням /boot/loader.rc непогано звіритися з поточною конфігурацією ядра. Для свіжовстановленої системи вона описана у файлі /usr/src/sys/i386/conf/GENERIC, а для власноруч зібраного… втім, якщо ви вже збирали ядро, то краще за мене знаєте, як називається файл його конфігурації, і що в ньому вписано.
Скажу лише кілька слів про модулі підтримки файлових систем. Очевидно, що вбудовувати в ядро підтримку тих, що використовуються лише епізодично (типу msdos), немає ніякого сенсу: у цьому випадку для всіх з них (включаючи і ext2fs) при компіляції ядра будуть за замовчуванням зібрані і модулі, що завантажуються. Однак і в завантаженні цих модулів при старті необхідності немає (хоча відповідні рядки у файлі /boot/defaults є). При зверненні до пристрою з чужою файловою системою необхідний модуль автоматично підвантажиться. Це ж стосується і модулів підтримки таких пристроїв, як диски в оперативній пам'яті (md - Memory Disk), якщо, звичайно, не передбачається старт системи саме з них.
А ось зі звуковими пристроями не відбувається. І тому, якщо ліниво щоразу перед прослуховуванням музики завантажувати відповідні модулі (забігаючи вперед, зауважу, що це робиться командою kldload имя_модуля), то краще запропонувати їхнє автоматичне завантаження при старті системи, як це зроблено в прикладі.
Знайти потрібні модулі легко - вони містять у своєму імені компонент snd. Тобто можна вдатися до команди типу
$ls /modules | grep snd
та зі списку виводу вибрати відповідний реаліями. При цьому для багатьох поширених звукових карт на шині PCI достатньо модуля snd_pcm .
У наведеному прикладі скасовано виведення меню loader 'а. Меню це описується у файлі /boot/beastie.4th, використання якого наказано у файлі /boot/loader.rc рядком
Include /boot/beastie.4th
Зрозуміло, це обов'язково. Можна, навпаки, переробити /boot/beastie.4th так, щоб окремі пункти меню відповідали власним варіантам завантаження — наприклад, з різними наборами модулів, що підргужуються, для чого доведеться створити кілька альтернативних конфігураційних файлів для loader 'а. Або образів ядра, зібраного з різними опціями. А якщо ви ще й вишивати вмієте (пардон, малювати ASCII-символами), то можна замінити прикрасу меню бабку на щось своє.
Завдання ініціалізації
Припустимо, однак, що тим чи іншим способом завантаження ядра та всього супутнього господарства успішно завершена. І тут у справу вступає головний калібр будь-якої POSIX-системи – процес init. Це перший (у прямому і переносному сенсі - в BSD-системах його ідентифікатор дорівнює одиниці) користувальницький (тобто працює в просторі користувача ядра, юзерланді), процес, і запускається він виконанням однойменного файлу /sbin/init .
Насправді це можуть бути (і в різних системах справді бувають) різні програми. Більше того, його можна підмінити при інтерактивному керуванні процесом завантаження іншою програмою, наприклад командною оболонкою. Однак це зараз не дуже важливо – розглянемо лише штатні завдання програми /sbin/init.
Першою з завдань, як у часі виконання, і за значенням, є перевірка цілісності готівкових файлових систем. Для чого кожна з них перевіряється на наявність біта чистого розмонтування (clean byte), який автоматично встановлюється в ході правильного завершення попереднього сеансу роботи. Якщо такий біт виявляється на кожній файловій системі — все гаразд, справа рухається далі. Якщо ні — можливі варіанти, про які йтиметься у наступній статті.
Слід зазначити, що сам по собі «біт чистого розмонтування» аж ніяк не гарантує збереження файлової системи та, особливо, її даних. Він лише показує, що файлову систему було коректно розмонтовано у попередньому сеансі. У цьому випадку процес init робить не позбавлене резону припущення, що з метаданими та даними її все гаразд, і переходить до виконання наступного завдання.
А наступне завдання процесу init – це виклик та відпрацювання сценаріїв ініціалізації, або стартових скриптів, зібраних у каталозі /etc та (або) його підкаталогах. Це звичайні сценарії оболонки, розраховані на виконання стандартним POSIX-шеллом і включають послідовності команд, покликані монтувати файлові системи, активізувати область свопінгу, встановлювати системний годинник, запускати ті чи інші служби і демони.
Команди, що утворюють стартові сценарії, отримують свої опції, їх значення та аргументи зі спеціальних файлів конфігурації, які також мають своїм місцезнаходженням /etc та його підкаталоги. Конфігураційні файли (чи простому конфіги) є або прості бази даних опцій і аргументів команд, або списки імен змінних, (відповідних опціям команд, які у скриптах) з присвоєними їм значеннями. Конфіги від скриптів легко відрізняються під час перегляду каталогу /etc відсутністю перших біта виконання.
Нарешті, третя неодмінна задача процесу init – так зване отримання терміналу (запуск процесу getty), встановлення його властивостей та підготовку до авторизації – витіснення його процесом login. Виконання цієї процедури також визначається параметрами відповідного конфігураційного файлу.
Послідовний поділ стартових сценаріїв та їх конфігураційних файлів – один із наріжних принципів загальносистемного конфігурування. По суті, користувачеві при нормальному ході налаштування практично немає необхідності ні знайомитися зі вмістом скриптів (хоча це і не шкідливо), ні, тим паче, міняти в них щось (останнє допустимо тільки в тому випадку, якщо цей користувач точно знає, що робить, інакше систему легко довести до непрацездатного стану). А ось вносити зміни до значення параметрів конфігураційних файлів - не тільки можна, але і потрібно - зрозуміло, така роздільна здатність не позбавляє користувача розуміння сенсу своїх дій.
Розуміння це, однак, утруднюється тим, що і сценарії ініціалізації, та їх конфігураційні файли реалізовані в різних ОС та їх дистрибутивах по-різному. Втім, це різноманіття можна звести до двох стилів - BSD, всі варіації на тему якого дуже схожі один на одного, і System V, кожен представник якого є оригінальним за своїм. Перший стиль ініціації використовується в операційних системах однойменного сімейства. Стиль System V переважає в більшості поширених дистрибутивів Linux. Хоча останнім часом і в багатьох із них (CRUX, Archlinux, Gentoo) все ширше застосовуються BSD-подібні схеми ініціації.
Ініціалізація DragonFly
У DragonFly, як і належить представнику BSD-родини, прийнято завантаження в BSD-стилі. Основна відмінність його від стилю System V - відсутність поняття runlevels (що часто неточно перекладається як рівні завантаженняабо навіть рівні запуску). Натомість існує поняття режимів завантаження, яких всього два — однокористувацький і розрахований на багато користувачів.
В режимі одного користувача завантаження відбувається а) при виборі відповідного пункту ( Boot in single user mode) у меню початкового завантажувача; б) при заданні команди boot -s у командному рядку завантажувача (після вибору пункту його меню Escape to loader prompt), та в) при виявленні серйозних (непереборних автоматично) порушень цілісності файлової системи в ході її перевірки на першій стадії ініціалізації).
При завантаженні в режимі одного користувача фактично консервується стан після відпрацювання loader 'а. Тобто не відбувається ні монтування файлових систем (за винятком кореневої, з якою раніше було завантажено ядро — та й змонтовано в режимі лише для читання), ні запуску сценаріїв ініціалізації, ні активізації віртуальних терміналів, ні запрошення до авторизації користувачів. Активізується лише перша, системна, консоль з автоматичною, за замовчуванням безпарольною, реєстрацією на ній суперкористувача.
Очевидно, що нормальна робота в режимі одного користувача неможлива — він призначений для аварійно-відновлювальних робіт після збоїв і деяких системних маніпуляцій. Для звичайних же процесів призначений нормальний розрахований на багато користувачів режим.
При завантаженні в розрахованому на багато користувачів режимі (а вона здійснюється за умовчанням при включенні машини або її перезавантаженні) всі стадії ініціації проходяться по повній програмі: після перевірки монтуються призначені до того файлові системи (а корінь файлової системи ремонтується в режимі читання/запису), відпрацьовуються певні стартові скрипти (де і ким певні — незабаром побачимо), і активізуються всі зумовлені віртуальні термінали (які — також попереду) із запрошеннями до авторизації. Авторизація можлива як для адміністратора, так і для будь-якого користувача, але про безпарольний вхід доведеться забути. Коротше кажучи, йде нормальна цивілізована робота.
Між однокористувацьким і розрахованим на багато користувачів режимами не лежить непереборної прірви: перехід з одного режиму в інший можливий не тільки при рестарті машини, але і в ході одного сеансу. Для негайного переходу до однокористувацького режиму служить команда
$ shutdown now
Повернення назад у розрахований на багато користувачів режим відбувається за командою
Такий спосіб широко застосовується для реініціалізації системи без повного її перезавантаження після зміни будь-яких конфігураційних параметрів - він протікає набагато швидше за повний рестарт. Потрібно тільки пам'ятати, що при цьому не всі послуги та демони повинні працювати правильно. Наприклад, відмовляється служити демон консольної миші.
Завантаження в розрахованому на багато користувачів режимі - і це відмінна особливість BSD-стилю, - потенційно тягне за собою доступність для запуску абсолютно всіх системних служб і демонів: сценарії, що ініціалізують (розташовуються в каталозі /etc/rc.d) теоретично можуть бути запущені з головного стартового сценарію - файлу / etc / rc. А ось які з них будуть запущені реально визначається опціями його конфігураційного файлу - /etc/rc.conf . Наявність пари головного стартового сценарію та його конфігураційного файлу – друга відмінна риса DragonFly (і взагалі BSD-стилю ініціації).
При встановленні DragonFly в каталог /etc на диску записується якийсь замовчальний /etc/rc.conf , рядки якого мають вигляд
Servicename_enable="значення"
Змінна = "значення"
Значення рядків першого виду = YES або NO. Легко здогадатися, що вони дозволяють (або забороняють) запуск іменованого сервісу за допомогою відповідного (і, як правило, однойменного) сценарію з каталогу /etc/rc.d . Значення рядків другого виду - це параметри, що передаються командам, що входять до скриптів ініціалізації.
За замовчуванням у DragonFly — і це також традиція BSD-систем, — у файлі /etc/rc.conf дозволено запуск лише мінімально необхідної для початку роботи кількості системних служб. Більша їх частина зазвичай заборонена — або явним чином, вказівкою значення «NO», або за умовчанням (а звідки ці замовчання беруться — ми зараз побачимо). Так що включення необхідних користувачеві демонів (наприклад, тієї ж консольної миші) справа рук самого користувача.
Стартові замовчування беруться з файлу /etc/defaults/rc.conf , в якому описані всілякі (і всі можливі) стартові сервіси та їх параметри (пам'ятаєте - подібну пару «замовчального» і робочого конфігів ми бачили для програми loader). Цей файл не призначений для прямого редагування (хоча воно і не заборонено атрибутами його доступу). Натомість слід знайти у ньому рядки, які стосуються необхідних сервісів, перенести в /etc/rc.conf і дозволити їх запуск (або, навпаки, заборонити, якщо він дозволено за умовчанням, але у разі не потрібен). Уточнюючі настройки сервісів також беруться з /etc/defaults/rc.conf , переносяться в /etc/rc.conf і їм приписуються необхідні значення.
У загальному вигляді це робиться, наприклад, так: в одній віртуальній консолі (на якій потрібно зареєструватися як root або отримати його права командою su) у текстовому редакторі відкривається файл /etc/rc.conf, в іншій (на ній можна авторизуватись і звичайним користувачем ) дається команда типу
$less /etc/defaults/rc.conf
І потрібні рядки з останнього просто переносяться до першого, де й модифікуються належним чином. Не шкідливо при цьому задіяти і третю консоль користувача - для читання man (5) rc.conf .
Як усе це відбувається практично, простіше розглянути на кількох прикладах. У статті про встановлення DragonFly було показано, що для налаштування консольної миші з USB-інтерфейсом достатньо активізувати демона відповідних пристроїв, вписавши у файл /etc/rc.conf рядок
Usbd_enable="YES"
Однак для інших типів мишей потрібне визначення деякої кількості інших змінних. Яких визначити не складно. Вирушаємо в раніше відкритий файл /etc/defaults/rc.conf і відшукуємо в ньому рядки, що стосуються миші - в даному випадку зручно скористатися командою типу
$grep mouse defaults/rc.conf
- І дивимося на висновок результату пошуку:
Moused_enable="NO" # Run the mouse daemon. moused_type="auto" # Натисніть page для rc.conf(5) для наявних # settings. moused_port="/dev/psm0" # Натиснути на свій порт. moused_flags="" # Any additional flags to moused. mousechar_start="NO" # if 0xd0-0xd3 default range is occupied in your # start like mousechar_start=3, see vidcontrol(1)
З якого, власне, стають очевидними подальші дії. Спочатку слід дозволити запуск мишачого демона — навіщо в /etc/rc.conf вноситься рядок
Moused_enable="YES"
Команда /usr/sbin/moused (а включити підтримку миші можна і з командного рядка, але тільки в даному сеансі роботи - про це буде сказано трохи пізніше) у загальному випадку вимагає двох опцій - вказівки протоколу (це те, що описується рядком moused_type) і порту підключення (серіального, PS/2, USB - шинні миші, швидше за все, з вживання вже вийшли). При описі протоколу рядок
Moused_type="auto"
підійде для всіх, наскільки мені відомо, сучасних гризунів із роз'ємами PS/2, хоча його можна вказати точно – ps/2. А ось для серіальних (і тим більше шинних) мишей протокол слід обов'язково поставити у явному вигляді. Яким - дивимося в man(5) rc.conf або man(8) moused (я, грішною справою, про ці істоти вже забув).
Явна вказівка порту також потрібна тільки для серіальних і шинних мишей («Ви знаєте тітку Маню? — Я знаю тітку Маню. — Ви вірите тітці Мані? — Я вірю тітці Мані. — Так от, у неї й питайте за таких звірів…») . Хоча якщо вказати
Moused_port="/dev/psm0"
для PS-поломної тварини, шкоди не буде ні найменшого.
Moused_flags=""
можна задати різноманітні опції, передбачені для команди /usr/sbin/moused, як то: емуляцію середньої кнопки для двоклавішних моделях (на скролюючих мишах коліщатко працює аналогічно середній кнопці), швидкість реакції, акселерацію при переміщенні курсору і так далі. За подробицями — знову ж таки до Мани, до Мани, до Мани…
Ну а про рядок
Mousechar_start="NO"
розмова вже була: якщо як кодування виводу використовується KOI8-R, а ядро не перезбиралося, або перезбиралося без опції
Options SC_MOUSE_CHAR=0x3
умовчувальне NO слід замінити на 3 . У будь-якому іншому випадку вона просто не потрібна.
Як буде показано в наступній статті, однією з цілей перескладання ядра було забезпечення підтримки графічної консолі. Однак включення відповідної опції до конфіг ядра мало - відповідний відеорежим потрібно ще активізувати. Це забезпечується сценарієм /etc/rc.d/syscons , що виконує, зокрема, команду vidcontrol, що відповідає за все, що має відношення до налаштувань екрану. А свої параметри ця команда отримує з файлу /etc/rc.conf . Зокрема, відеорежим визначається змінною
Allscreens_flags=""
для якої потрібно визначити відповідне значення як MODE_#режима. Наприклад, при бажанні мати роздільну здатність 800×600 і 32-бітну глибину кольору цей рядок набуде вигляду
Allscreens_flags="MODE_277"
Тепер про заключну стадію ініціації — процес отримання терміналу. Вона контролюється записами у файлі /etc/ttys, про який мимохіть згадувалося в статті про встановлення системи. Наявність спеціального файлу для конфігурування віртуальних терміналів - третя з важливих відмінностей BSD-систем: у Linux, незалежно від стилю сценаріїв ініціалізації, прийнятих у конкретному дистрибутиві, налаштування віртуальних терміналів описується у загальному конфізі процесу init.
Вміст файлу /etc/ttys виглядає таким чином (рядки, що описують термінали, що отримуються при модемному доступі на машину, я опускаю як неактуальні):
Console none unknown off secure # ttyv0 "/usr/libexec/getty Pc" cons25 on secure # Virtual terminals ttyv1 "/usr/libexec/getty Pc" cons25 on secure ttyv2 "/usr/libexec/getty Pc" cons2 /usr/libexec/getty Pc" cons25 on secure ttyv4 "/usr/libexec/getty Pc" cons25 on secure ttyv5 "/usr/libexec/getty Pc" cons25 on secure ttyv6 "/usr/libexec/getty Pc" cons2 ttyv7 "/usr/libexec/getty Pc" cons25 on secure ttyv8 "/usr/X11R6/bin/xdm -nodaemon" xterm off secure
Як можна бачити, це проста база даних, поля якої мають наступний зміст:
- ім'я термінального пристрою, що має значення console для так званої системної консолі, та ім'я віртуального терміналу (ttyv# , де # — порядковий номер) для всіх інших;
- процес, що запускається на даному терміналі для його активізації; на системній консолі жодного процесу не запускається, її роль (у першу чергу місце розташування системних повідомлень) виконує перший віртуальний термінал; на інших, крім останнього (про який буде окрема розмова) таким процесом є стандартний getty;
- тип терміналу – за умовчанням для стандартного відеорежиму 80×25;
- статус терміналу, що визначає, активізований (on) чи ні (off); «негативне» значення за умовчанням можна побачити у двох записах — першої та останньої;
- ступінь захищеності терміналу; умовчувальне значення secure передбачає, що цей термінал фізично, так би мовити, недоступний для зловмисника, і тому на ньому безбоязно можна зареєструватися суперкористувачу; якщо змінити його на unsecure , то авторизація root'а з даного терміналу виявиться неможливою; вказівка значення unsecure для системної консолі спричинить необхідність завдання пароля суперкористувача при завантаженні в однокористувальному режимі.
Що тут підлягає зміні? По-перше, тип терміналу: у разі русифікації консольного режиму умовне значення cons25 слід замінити на cons25r; втім, адже ми це зробили відразу після установки, чи не так? При використанні відмінної від стандартної щільності символів тип терміналу також змінюється. Наприклад, якщо використовується режим 80×30, слід підставити cons30r . Повний список допустимих значень типів терміналу можна переглянути у файлі /etc/termcap .
Далі, з погляду безпеки не позбавлено сенсу дозволити авторизацію суперкористувача тільки на будь-якій одній віртуальній консолі, наприклад, першій: все одно для практичної роботи вона мало придатна, тому що на неї валом валяться системні повідомлення. Більшість їх, звичайно, можна позбутися редагуванням файлу /etc/syslog.conf , перенаправивши висновок їх, що описується рядком
*.err;kern.debug;auth.notice;mail.crit /dev/console
з системної консолі в будь-який файл (або навіть пристрій /dev/null). Однак дещо на консолі з'являтиметься все одно — наприклад, повідомлення про приєднання та від'єднання пристроїв гарячого підключення (типу USB-накопичувачів або PC-карток).
У принципі реєстрацію адміністратора можна взагалі заборонити: отриманню тимчасових прав root-оператора командою
це аж ніяк не перешкоджає. Зрозуміло, кількість віртуальних терміналів, що активізуються при старті системи, можна змінити в той чи інший бік. Зрозуміло, що для зменшення їхньої кількості досить просто видалити або закоментувати «зайві» рядки, а для збільшення — вписати існуючі (не забувши перейменувати файли відповідних пристроїв). Тільки потрібно мати на увазі, що ядро GENERIC підтримує 16 віртуальних терміналів, мінімум один з яких повинен бути зарезервований для запуску віконної системи X — вручну або автоматично. І ще — при збільшенні числа віртуальних терміналів потрібно потурбуватися про наявність файлів відповідних пристроїв (виду ttyv#) — за умовчанням у каталозі /dev їх «лише» 12.
До речі, про Іксів. Користувачі Linux мають можливість забезпечити авторизацію у графічному режимі (і автоматичне завантаження Іксів) простим методом – зміною runlevel за умовчанням. А як бути користувачам BSD-систем, які поняття runlevel не мають, - тим, хто працює переважно в Іксах і кому набридло набирати команду startx? Та все так само просто: достатньо активізувати «іксовий» віртуальний термінал, замінивши в останньому рядку off на on . Це спричинить автоматичне завантаження менеджера графічного входу в систему — xdm . Який, природно, можна замінити його більш просунутим аналогом. Наприклад, рядок
Ttyv8 "/usr/local/bin/kdm -nodaemon" xterm off secure
Зворотний бік ініціалізації системи — це її зупинка або рестарт, відмінностей між цими процесами практично немає. І відповідає за нього команда shutdown, яка може бути дана від імені суперкористувача або члена групи operator. З опцією -h вона викликає зупинку машини, з опцією -r - її перезавантаження. І ще цій команді потрібен аргумент — час, коли зупинка чи рестарт мають статися. Втім, є спосіб і миттєвого зупинки або рестарту:
$shutdown -h now
$ shutdown -r now
відповідно.
Крім того, існують команди halt і reboot того ж призначення. Однак самостійної ролі вони не грають, просто викликаючи команду shutdown з опцією зупинки та перезавантаження відповідно.
Зупинка системи відбувається у порядку, зворотному її ініціалізації. Спочатку робиться спроба коректного завершення всіх процесів користувача відправкою їм сигналу TERM . Через деякий проміжок часу всім ще «живим» процесам відправляється сигнал KILL — для гарантованого їх вбивства. Потім стопоряться всі стартові сервіси та демони. Нарешті, вміст кешів записується на диск (за допомогою команди sync), і розмонтуються файлові системи. Після цього зазвичай з'являється повідомлення про можливість безпечного відключення живлення машини або воно автоматично вимикається. При рестарті все відбувається так само, але після зупинки системи автоматично починається перезавантаження машини.
Як мовилося раніше, сценарії, відповідальні за запуск стартових сервісів, перебувають у каталозі /etc/rc.d . Більшість програм, що запускаються ними, - це так звані демони (daemon - Disk And Execution MONitor), щось на зразок резидентних програм, що працюють у фоновому режимі в очікуванні запиту на виконання їх функції (друку, відправки пошти, звернення до ftp- або http-серверу, і так далі). У відповідності з цим сценарії, що їх запускають, влаштовані за принципом start - stop. І якщо під час ініціації системи виконується перша функція, то за її зупинки, як легко здогадатися, друга.
Хід процесу зупинки системи визначається сценарієм /etc/rc.shutdown. Призначення його — виконати функцію stop у сценаріях всіх сервісів, запущених зі скрипту /etc/rc у відповідність до описом, даним у /etc/rc.conf і /etc/defaults/rc.conf .
