- (IPAEng|ˈpɒzɪks) or Portable Operating System Interface cite web | title = POSIX | url = http://standards.ieee.org/regauth/posix/ | work = Standards | publisher = IEEE] is the collective name of family of related standards specified by the IEEE ... Wikipedia
POSIX- est le nom d une famille de standards définie depuis 1988 par l Institute of Electrical and Electronics Engineers et formellement désignée IEEE 1003.
Posix- est le nom d une famille de standards définie depuis 1988 par l IEEE et formellement désignée IEEE 1003.
POSIX- es el acrónimo de Portable Operating System Interface; la X viene de UNIX como seña de identitat de la API. El terme fue sugerido por Richard Stallman en resposta a la demanda de la IEEE, que buscaba un numero fácil de recordar. Una traducción … Wikipedia Español
POSIX- , 1986 im Standard 1003.1 der IEEE niedergelegte Spezifikation für Zugriffe auf Systemfunktionen unter Unix. Sowohl Unix Sy … Universal-Lexikon
POSIX- standartai statusas t sritis informatika apibrėžtis standartų grupė, apibrėžianti operacinės sistemos sąsajas tarp joje veikiančių programų bei tarnybų. Pirmuosius standartus sukūrė Elektros ir elektronikos inžinierių institutas (IEEE) Linukso… Enciklopedinis kompiuterijos žodynas
POSIX- es el acrónimo de Portable Operating System Interface, viniendo la X de UNIX con el significado de la herencia de la API (Se traduciría com Sistema Operativo Portable basado en UNIX). Estos son una familia de estándares de llamadas al sistema… … Enciclopedia Universal
POSIX- (Portable Operating System Interface базується на unix) n. колекція стандартів для операційних систем, які базуються на Unix (Computers) … English contemporary dictionary
POSIX
Posix- Das Portable Operating System Interface (POSIX [ˈpɒsɪks]) ist ein gemeinsam von der IEEE und der Open Group für Unix entwickeltes standardisiertes Application Programming Interface, das die Schnittstelle zwischen Applikation und dem…
Книги
- , Стівен А. Раго, У. Річард Стівенс. "UNIX. Професійне програмування" - це докладний довідковий посібник, який протягом 20 років допомагає професійним програмістам мовою С писати виключно…
- UNIX. Професійне програмування, Стівенс У. Річард, Раго Стівен А.. Ця книга заслужено користується популярністю у серйозних програмістів у всьому світі, оскільки містить найважливішу і практичну інформаціюпро керування ядрами UNIX та Linux. Без цих…
назва запропонована відомим спеціалістом, засновником Фонду вільного програмного забезпечення Річардом Столменом. Ми будемо розглядати найсучаснішу з доступних версійстандарту POSIX
, у редакції 2003 р., яку можна назвати "стандартом втричі", а саме: стандартом IEEE Std 1003.1, Технічним стандартом Open Group та (див. [ 6 ]), що для нас найважливіше, міжнародним стандартом ISO / IEC 9945 (див. . [[1], [2], [3], [4]). Історія створення цієї версії така. На початку 1998 р. представники трьох організацій – Комітету зі стандартівмобільних додатків
Інституту інженерів з електротехніки та електроніки, Open Group і робочої групи 15 підкомітету 22 спільного технічного комітету 1 (JTC1/SC22/WG15) Міжнародної організації зі стандартизації - розпочали консультації з питання злиття та розвитку курованих ними стандартів інтерфейсів до системних сервісів: IEEE St1. IEEE Std 1003.2, Базових специфікацій від Open Group, ISO/IEC 9945-1, ISO/IEC 9945-2. У вересні того ж року у місті Остін, штат Техас, в офісі корпорації IBM відбулося організаційне засідання групи, сформованої для досягнення поставленої мети (див. http://www.opengroup.org/austin).
- основні визначення (терміни, концепції та інтерфейси, загальні всім частин);
- опис прикладного програмного C-інтерфейсудо системних сервісів;
- опис інтерфейсу до системних сервісів на рівні командної мовиі службових програм ;
- детальне роз'яснення положень стандарту, обґрунтування ухвалених рішень.
Далі в ISO, IEEE та Open Group з більшою чи меншою швидкістю (у 2001-2002 рр.) пройшло формальне затвердження нового стандарту POSIX. Тим часом накопичувалися щодо дрібні виправлення, враховані у редакції 2003 року.
З розвитком стандарту розширювалося і трактування терміна "POSIX". Спочатку він ставився до документа IEEE Std 1003.1-1988, який описував прикладний програмний інтерфейсОС класу Unix Після стандартизації інтерфейсу на рівні командної мови та службових програм більш правильно розуміти під словом "POSIX" стандарт в цілому, позначаючи перераховані вище частини 2 і 3 через POSIX.1 та POSIX.2 відповідно до нумерації документів IEEE та ISO/IEC.
Основні ідеї стандарту POSIX
Стандарт POSIX визначає безліч базових, системних сервісів, необхідні функціонування прикладних програм. Доступ до них надається за допомогою інтерфейсу, специфікованого для мови C, командної мови та загальновживаних службових програм.
У кожного інтерфейсу є дві сторони: викликає і викликається. Стандарт POSIX орієнтований насамперед на зухвалу. Його мета - зробити додатки мобільними на рівні вихідної мови. Це означає, що при перенесенні C-програм на іншу операційну платформу буде потрібно перекомпіляція. Про мобільність здійснюваних програм та/або об'єктних файлів не йдеться.
Стандарт POSIX аж ніяк не обмежений рамками Unix-середовища. Існують операційні системи (ОС) "незалежного походження" (наприклад, системи реального часу), що надають необхідні сервіси і тим самим підтримують виконання POSIX-сумісних програм. Можна стверджувати, що дотримання стандарту POSIX полегшує перенесення додатків практично на будь-яку поширену операційну платформу. Додаткові зусилля щодо підвищення мобільності, що додаються на етапі розробки, безумовно, окупляться.
Визначаючи інтерфейс до системних сервісів, POSIX залишає поза розгляду їх реалізацію. Зокрема, не різняться системні викликиі бібліотечні функції. Не є об'єктом стандартизації засобу, апаратні обмеження та функції, необхідні тільки суперкористувачеві, що ще раз наголошує на спрямованості стандарту
Олексій Федорчук
2005 р
Однією з відмінних рис логічного пристрою файлової системи операційних систем POSIX-родини є їх ієрархічна, або деревоподібна, організації (правда, як я вже казав дерево виглядає це трохи дивно). Тобто тут немає, як у DOS чи Windows будь-якого роду, позначень (наприклад, літерних, чи будь-яких інших) окремих носіїв та його розділів: всі вони входять у єдину структуру як підкаталогів головного каталогу. званого кореневим. Процес підключення файлових системна самостійних фізичних носіях (та його розділах) до кореня файлового дерева називається монтуванням, а підкаталоги, вміст яких вони становлять, називаються точками монтування.
Історично в Unix склалася певна структура каталогів, дуже подібна в різних представниках цього сімейства в загальних рисах, але дещо різниться в деталях. Зокрема, файлова ієрархія в BSD-системах майже ідентична, відрізняючись від такої в Linux. А в останній суттєві відмінності виявляються між різними дистрибутивами. Аж до того, що структура файлової ієрархіїє одним з дистрибутивно-специфічних ознак.
Такий стан справ ускладнює твір крос-платформних додатків. І тому існує та активно розвивається проект стандартизації файлової ієрархії – FHS (Filesystem Hierarchy Standard).
Проект FHS був спрямований спочатку на упорядкування структури каталогів у численних дистрибутивах Linux. Пізніше він був пристосований до інших Unix-подібних систем (зокрема і BSD-клана). І нині робляться активні (але не дуже успішні) зусилля до того, щоб зробити його стандартом для POSIX-систем не лише на ім'я, але й фактично.
Стандарт FHS спочиває на двох основоположних принципах - чіткому відділенні у файловій ієрархії каталогів, що розділяються і нерозділяються, з одного боку, і незмінних і змінюваних - з іншого.
Протиставлення каталогів, що розділяються і неподіляються, обумовлено спочатку мережевою природою Unix. Тобто дані, що відносяться до локальної машини (наприклад, файли конфігурування її пристроїв) повинні лежати в каталогах, окремих від тих, вміст яких доступні з інших машин в мережі, локальної або глобальної (прикладом чого є не тільки дані користувача, а й програми) .
Суть протиставлення незмінних та змінних каталогів легко пояснити на прикладі. Так, ті ж загальні користувальницькі програми за своєю природою повинні бути незмінними (вірніше, доступними для модифікації тільки адміністратору системи, але не самому користувачу, що застосовує їх у своїй роботі). У той же час ці програми при своїй роботі генерують не тільки файли даних, скажімо, тексти або зображення (змінна їх природа ясна без коментарів), але всякого роду службову інформацію, типу log-файлів, тимчасових файлів тощо). Яка і повинна групуватися в каталогах, відокремлених від файлів програм, необхідних для їх запуску бібліотек, конфігураційних файліві т.д.
Тим не менш, незважаючи на активне просування в багатьох дистрибутивах Linux з числа найбільш поширених, статусу справжнього стандарту FHS не набув. Існує чимало дистрибутивів Linux, які не використовують деякі його положення. А з традиційною файловою ієрархією BSD-систем він співвідноситься лише частково.
І причина — в тому, що FHS ігнорує ще одне протиставлення, дуже важливе для користувача: протиставлення частин файлової системи, що легко відновлюються, і тих її компонентів, які відновлені важко або невідновні взагалі.
До перших, як не дивно, можна віднести саму базову систему: адже перевстановлення її з дистрибутивного носія, у разі фатального краху, справа не така вже й складна. До важковідновних частин файлової системи, очевидно, відносяться дані користувача: навіть у разі регулярного їх резервування (а чи багато користувачів настільки акуратні?) розгортання їх з архівів вимагатиме чималого часу (і майже неминуче спричинить деякі втрати).
Крім того, у BSD-системах і Source Based дистрибутивах Linux до важковідновних каталогів я відніс би все, пов'язане з пакетним менеджментом - дерево портів FreeBSD або pkgsrc в NetBSD (і системах, що його запозичили), їх аналоги в дистрибутивах Linux, власне вихідники портованих програм , Та й вихідні тексти системи теж. Бо навіть якщо все це є на дистрибутиві, ці компоненти файлової системи, як правило, підтримуються користувачем в актуальному стані шляхом синхронізації по Мережі з серверами проекту (інакше їх використання не має сенсу). І їхня втрата спричинить як тимчасові (особливо при модемному підключенні), так і фінансові (мало хто є щасливим володарем безкоштовного доступув Інтернеті) втрати.
Чітке дотримання концепції відокремлення поділяються і нерозділяються, незмінюваних і незмінюваних, відновних і невосстановимых каталогів один від одного дозволяє, в рамках єдиної деревоподібної файлової ієрархії, відокремити окремі її гілки фізично - тобто у вигляді самостійних файлових систем, розміщених на ізольованих пристроїв розділах, слайсах, партіях, etc.). Резонів до того багато - і підвищення швидкодії, і збільшення надійності, і просто міркування зручності, - але й про них зараз не йтиметься. Тому що в НаразіДля нас важливим є лише те, що ці гілки файлового древа повинні бути інкорпоровані в загальну файлову систему.
Типовий набір каталогів POSIX-системи
Власне кажучи, для функціонування абсолютно необхідна наявність лише однієї файлової системи - тієї, що монтується в кореневий каталог файлового дерева (свого роду аналог світового дерева Іггдрассиль). Кореневий каталог та його неодмінні гілки обов'язково повинні становити єдину файлову систему, розташовану на одному носії - диску, дисковому розділі, програмному або апаратному RAID-масиві, або логічному томі в розумінні LVM. І в ньому повинні розташовуватися всі компоненти, необхідні для старту системи і, в ідеалі, нічого більше.
Переглянути склад кореневого каталогу можна командою
$ ls -1 /
яка в будь-якій POSIX-системі покаже якийсь мінімальний джентльменський набір каталогів:
Bin/boot/etc/root/sbin/
Саме в них зібрано всі файли, без яких система не може існувати. Інші каталоги – приблизно такі:
Home/mnt/opt/tmp/usr/var/
Вони а) не обов'язкові (принаймні теоретично - практично обійтися без них важкувато), б) не кожен з них присутній у всіх системах і дистрибутивах, і в) кожен з них може бути (і часто є - якщо все робити з розуму ) точкою монтування власної гілки файлового дерева.
Крім цього, в більшості випадків у корені файлової системи POSIX-сумісних ОС присутні ще два підкаталоги:
Dev/proc/
Це зазвичай - точки монтування віртуальних файлових систем - пристроїв і процесів, відповідно (хоча, якщо файлова система пристроїв не використовується, каталог /dev обов'язково повинен бути компонентом кореневої файлової системи. Нарешті, в Linux-системах, як правило, в корені файлового дерева лежить ще й каталог /lib, призначений для головних системних бібліотек.
Коренева файлова система
Коренева файлова система є нерозділюваною (тобто не призначеною для спільного використання різними машинами мережі) і незмінною (тобто зміни до неї може вносити тільки адміністратор системи, але не програми користувача і, тим більше, не користувачі). Причому вкрай не рекомендується створювати в ній підкаталоги понад передбачені стандартом (і перераховані вище).
Наповнення кореневої файлової системи підбирається з таким розрахунком, щоб машина могла стартувати і зберігала б мінімальну функціональність навіть при аварійному завантаженні (або в режимі одного користувача), коли всі інші файлові системи не монтуються (і, відповідно, такі її гілки, як /usr або / var можуть виявитися недоступними.
Відповідно до цього старт машини забезпечується файлами каталогів /boot і /etc. У першому розміщуються ядро системи - здійсненний файл "особливого призначення", - і все, що потрібно для його завантаження: в Linux, наприклад, це системна карта (файл /etc/System.map), а в FreeBSD - модулі ядра, що завантажуються. Втім, часом ядро розміщується у корені файлової системи, і тоді каталог /boot може бути зовсім, а під модулі ядра може відводитися каталог /modules .
Каталог / etc призначений для загальносистемних конфігураційних файлів, що визначають умови її завантаження. Вміст його дуже залежить від системи (а в Linux — ще й від дистрибутива), і тому розглядати його тут я не буду — до цієї теми доведеться ще не раз повертатися.
Мінімально необхідна функціональність забезпечується вмістом каталогів /bin і /sbin - в них зібрані здійсненні файли найважливіших і системних програм, відповідно, тих самих, які дозволять виконати комплекс ремонтно-рятувальних заходів та привести машину у людський вигляд після збою.
Рознесення системних і користувацьких програм з підкаталогів кореня досить умовне. Жодна з цих команд для вирішення завдань користувача по-справжньому не призначена. Просто в каталозі /bin зібрані команди адміністрування, до яких час від часу звертається (або може звернутися) і звичайний користувач, а каталог sbin призначений для команд, про які користувач і знати не належить. І якими він, у більшості випадків, все одно не зможе скористатися через відсутність відповідних повноважень (наприклад, необхідних прав доступу до файлів пристроїв).
Для запуску POSIX-програм (у тому числі й тих, що зібрані в каталогах /bin та sbin), як правило, потрібен доступ до функцій загальносистемних бібліотек (насамперед головної бібліотеки glibc). І тому (майже) неодмінний компонент кореневого каталогу - підкаталог /lib, в якому вони зібрані.
У Linux каталог/lib служить ще однієї важливої мети - в його підкаталозі (/lib/modules) зібрані модулі ядра, що завантажуються (у FreeBSD їх місце - каталог /boot/kernel).
У FreeBSD каталогу /lib в кореневій файловій системі не виявляється - відповідні компоненти тут розміщуються на /usr/lib (див. далі). Це пов'язано з тим, що історично у FreeBSD найважливіші загальносистемні програми збиралися так, що необхідні їм бібліотечні функції вбудовувалися в їх здійсненні файли (так звана статична лінківка, про яку йтиметься в розділі 14). У FreeBSD 5-ї гілки програми з каталогів /bin і /sbin лінкуються динамічно, тобто за відсутності каталогу /usr (а Free це майже завжди окрема галузь файлової системи) вони не функціонують. У компенсацію чого передбачений каталог /restore, що виходить за рамки стандартів, що містить ті ж програми, але зілинковані статично (як випливає з імені каталогу, єдиним призначенням його вмісту є аварійно-рятувальні роботи).
І, нарешті, /root. Це - звичайний домашній каталог однойменного користувача, або адміністратора системи. Оскільки ніякої практичної роботи він не робить (або, принаймні, робити не повинен), вміст його - лише власні конфігураційні файли суперкористувача (командної оболонки користувача, улюбленого редактора і так далі).
Гілка /usr
Історично каталог /usr призначався для програм користувача і даних. Нині ці функції розподілені між каталогами /usr/local і /home (хоча і зараз у FreeBSD за умовчанням останній є символічним посиланням на /usr/home). Каталог же /usr — не змінюється, але поділяється, — служить вмістилищем основної частини прикладних програм і всього, що до них відноситься — вихідних текстів, конфігураційних файлів, бібліотек, що розділяються, документації тощо господарства.
Склад каталогу /usr істотно відрізняється у BSD-системах та Linux. У перших у нього містяться лише невід'ємні частини операційної системи (те, що у FreeBSD об'єднується поняттям Distributions). Програми, що встановлюються з портів або пакетів, мають місце своєї прописки підкаталог /usr/local , який може представляти окрему галузь файлового дерева.
У Linux каталог /usr служить вмістилищем всіх програм (та їх компонентів), штатно включених до складу дистрибутива. А підкаталог /usr/local призначається зазвичай для програм, що самостійно збираються з вихідників.
У будь-якому випадку, звичайний склад каталогу /usr наступний (за виведенням команди ls -1):
X11R6/ bin/ etc/ include/ lib/ libexec/ local/ sbin/ share/ src/
Як мовилося раніше, підкаталог /usr/local — окрема гілка файлового дерева, і тому буде розглянуто окремо. Призначення інших каталогів таке:
- /usr/bin і /usr/sbin призначені для здійснюваних файлів користувацьких і системних програм (тут межа між ними ще умовніша, ніж у разі кореневого каталогу), призначення яких виходить за рамки забезпечення базового функціонування системи;
- /usr/etc призначається для конфігураційних файлів окремих програм;
- /usr/include містить так звані заголовні файли, необхідні для лінкування виконуваних файлів з бібліотечними компонентами;
- /usr/lib і /usr/libexec — каталоги для бібліотек, що розділяються, від яких залежать користувацькі програми;
- /usr/share — вмістище найрізноманітніших, т.зв. архітектурно незалежних компонентів: тут можна бачити і документацію в різних форматах, і приклади конфігураційних файлів, і дані, що використовуються програмами управління консоллю (шрифти, розкладки клавіатури), та опис часових поясів;
- /usr/src - каталог для вихідних текстів; в Linux тут штатно поміщаються лише вихідники ядра (ядер) системи, в BSD ж клонах - повний набірвихідників того комплексу, що у FreeBSD називається Distributions; вихідники програм, які самостійно збираються, поміщати сюди, як правило, небажано;
- /usr/X11R6 — каталог для компонентів віконної системи Ікс — файлів (/usr/X11R6/bin), бібліотек (/usr/X11R6/lib), заголовків (/usr/X11R6/include), документації (/usr/X11R6/ man); файли Іксових додатків сюди поміщатися не повинні (за винятком, хіба що, віконних менеджерів) - їх місце в /usr, /usr/local або /opt, залежно від системи.
Крім цього, у каталозі /usr можуть виявитися підкаталоги /usr/var та /usr/tmp — зазвичай символічні посилання на відповідні гілки кореневого каталогу. А в деяких дистрибутивах Linux безпосередньо в / usr міститься і основна загальносистемна документація - man-сторінки (підкаталог / usr / man).
Нарешті, в BSD-системах і деяких Source Based дистрибутивах Linux (наприклад, Gentoo) у каталозі /usr розміщується підкаталог для системи управління пакетами - портів FreeBSD та OpenBSD (/usr/ports), їх аналогів в інших системах (/usr/portage в Gentoo). Хоча з точки зору дотримання букви та духу стандарту FHS (сам він про порти та подібних системахне згадує ні словом), більш логічним місцем їх розміщення був би каталог /var (див. нижче) - і саме так робиться в таких дистрибутивах, як CRUX та Archlinux.
Гілка /usr/local
Як уже було сказано, гілка /usr/local в Linux призначена для програм, що самостійно збираються з вихідних (не входять в даний дистрибутив). А у FreeBSD вона служить вмістилищем більшої частини додатків користувача - майже всього того, що виходить за рамки Distributions і встановлюється з пакетів або портів. Відповідно до цього, структура каталогу загалом повторює таку гілки /usr (зі зрозумілими винятками):
Bin/etc/include/lib/man/sbin/share/
Вміст підкаталогів також аналогічний: файли програм (/usr/local/bin та /usr/local/sbin), їх конфіги (/usr/local/etc), бібліотеки, з яким вони пов'язані, та їх заголовні файли (/usr/ local/lib і /usr/local/include , відповідно), man-сторінки (/usr/local/man) та будь-яка архітектурно незалежна всячина (/usr/local/share), у тому числі й документація в інших форматах.
Гілка /opt
Каталог /opt передбачений стандартом FHS, але реально використовується не у всіх дистрибутивах Linux, а в BSD-системах зовсім відсутній. Тим не менш, все більше програмпишеться у розрахунку на умовчувальну інсталяцію саме в нього.
Історично каталог /opt призначався в Linux для комерційних додатків і різноманітних програм недостатньо вільного характеру. Нині його призначення — розміщення великих самодостатніх програмних комплексів, як-от бібліотека Qt, KDE з його компонентами і додатками, OpenOffice.org тощо. Структура каталогу має бути такою: /opt/pkg_name . Ось як виглядає вона в моїй системі (Archlinux):
$ ls -1 /opt gnome/ kde/ OpenOffice.org1.1.2/qt/
Кожен із підкаталогів має власну внутрішню структуру:
$ ls -1 /opt/* /opt/gnome: bin/lib/man/share/ /opt/kde: bin/etc/include/lib/share/ /opt/OpenOffice.org1.1.2: help/ LICENSE LICENSE. html program/ README README.html setup@ share/ spadmin@ THIRDPARTYLICENSEREADME.html user/ /opt/qt: bin/ doc/ include/ lib/ mkspecs/ phrasebooks/ plugins/ templates/ translations/
Призначення підкаталогів всередині /opt/pkg_name легко вгадується за аналогією з /usr та /usr/local. Наприклад, /opt/kde/bin призначений для файлів системи KDE та її додатків, /opt/kde/etc — для конфігураційних її файлів, /opt/kde/include — для файлів заголовків, /opt/kde/lib — для бібліотек і /opt/kde/share — для файлів, що розділяються, у тому числі й документації. У KDE немає документації в man-форматі, якщо вона є, то (як у випадку Gnome - я його не ставив, це те, що потягли Gimp і тому подібні Gtk-додатки) можна бачити підкаталог /opt/pkg_name/man .
Можна бачити, що структура каталогу /opt відступає від історично сформованої (і внутрішньо обґрунтованої POSIX-традиції об'єднання в каталоги однотипних компонентів - виконуваних файлів, бібліотек і т. д. І при великій кількості інстальованих в нього програм створює певні труднощі: доводиться або перевантажувати змінними значеннями $PATH , що забезпечує швидкий доступдо команд (про що буде говорити в розділі 12), або створювати спеціальний каталог /opt/bin і поміщати в нього символічні посилання на бінарники програм, що виконуються. Тому в ряді дистрибутивів Linux (наприклад, CRUX) каталог /opt не використовується принципово. Як, зрештою, і в усіх BSD-системах. Цілком можливо, що так воно і краще.
Гілка /var
Як випливає з назви, каталог /var призначений для зберігання файлів, що змінюються, що генеруються в ході нормальної життєдіяльності різних програм - програмних (наприклад, браузерних) кешів, log-файлів, спулінгу друку та поштових систем, поштових скриньок, описи запущених процесів і так далі. Зокрема, саме в каталог /var розміщуються так звані дампи - зліпки стану оперативної пам'яті, що генеруються при аварійному завершенні роботи для виявлення причин цього. Відмінна особливістьвсіх цих компонентів — їх мінливий у процесі сеансу роботи і те, що вони, тим щонайменше, мають зберігатися під час перезавантаження системи.
Внутрішня структура /var дуже сильно змінюється від системи до системи, тому на деталях її пристрою я затримуватися не буду. Зауважу лише, що цей каталог є логічним місцем для приміщення компонентів різноманітних портоподібних систем управління пакетами, як це зроблено, наприклад, у дистрибутиві Archlinux, де під неї відведено підкаталог /var/abs (abs — Archlinux Building System).
Каталог /mnt
Каталог /mnt призначений для монтування файлових систем, що тимчасово використовуються, що розташовуються, як правило, на змінних носіях. У всеж встановленій системі він зазвичай порожній, і структура його ніяк не регламентована. Користувачеві вільно створити у ньому підкаталоги окремих видів носіїв. Наприклад, у моїй системі це /mnt/cd , /mnt/dvd , /mnt/usb та /mnt/hd — для дисків CD, DVD, флешки та знімного вінчестера.
У FreeBSD штатними каталогами для монтування CD та дискет є /cdrom та /floppy безпосередньо в кореневому каталозі. Що не цілком узгоджується зі стандартом, але за своїм логічним — у корінь винесені точки монтування пристроїв, що існують (як CD ROM) або донедавна існували (флоппі-дисковод) у будь-якій машині.
Гілка /home
Каталог /home призначений для розміщення домашніх каталогів користувачів. Вміст його не регламентовано, але зазвичай він має вигляд на кшталт /home/(username1,...,username#) . Хоча у великих системах із великою кількістю користувачів їхні домашні каталоги можуть бути об'єднані у групи.
У каталозі /home можуть розташовуватися домашні каталоги як реальних, а й деяких віртуальних користувачів. Так, якщо машина використовується як web- або ftp-сервер, можна бачити такі підкаталоги, як /home/www або /home/ftp відповідно.
Гілка /tmp
Залишилося поговорити лише про каталог для зберігання тимчасових файлів - /tmp. Як і компоненти /var, вони генеруються різними програмамиу ході нормальної їхньої життєдіяльності. Але, на відміну /var , для компонентів /tmp передбачається їх збереження поза поточного сеансу роботи. Більше того, всі посібники з системного адміністрування рекомендують регулярно (наприклад при рестарті машини) або періодично очищати цей каталог. І тому як /tmp доцільно монтувати файлові системи в оперативній пам'яті - tmpfs (в Linux) або mfs (в FreeBSD). Крім того, що це гарантує очищення його вмісту при перезавантаженні, так ще й сприяє швидкодії, наприклад компіляції програм, тимчасові продукти якої не записуються на диск, а поміщаються у віртуальний каталог типу /tmp/obj .
Багато системах можна побачити каталоги на кшталт /usr/tmp і /var/tmp . Це зазвичай символічні посилання на /tmp .
Стратегія поділу файлових систем
На завершення розмови про файлову ієрархію слід підкреслити, що гарантовано на одній файловій системі (фігурально кажучи, на одному дисковому розділі, хоча це й не зовсім точно) повинні бути лише каталоги, перелічені в параграфі Коренева файлова система. Все ж таки інші каталоги - /usr, /opt, /var, /tmp і, звичайно ж, /home можуть представляти точки монтування самостійних файлових систем на окремих фізичних носіях або їх розділах.
Більше того, в локальної мережіЦі каталоги цілком можуть розташовуватися навіть на різних машинах. Так, один комп'ютер, що виконує роль сервера додатків, може містити каталоги /usr і /opt, що розділяються в мережі, інший - файл-сервер, - вміщувати всі домашні каталоги користувачів, і так далі.
Залишилося тільки вирішити - які файлові системи доцільно вичленувати із загального файлового дерева, і навіщо це робити. Відповідь на ці питання дуже залежить від використовуваної ОС, а у випадку з Linux ще й від його дистрибутива. Проте, загальні принципивідділення файлових систем намітити можна. Для чого слід згадати про протиставлення, з одного боку, незмінних і змінних каталогів, з іншого — легко відновлюваних, важко відновлюваних та практично невідновних даних. Зробимо таку спробу стосовно користувальницького десктопу — у разі сервера розрахунки будуть істотно іншими.
Очевидно, що коренева файлова система у складі каталогів /bin , /boot , /etc , /root , /sbin , що містять легко відновлювані з дистрибутивного носія і дані, що практично не змінюються, повинні лежати на ізольованому дисковому розділі. У Linux до них має додатися ще й каталог /lib. З іншого боку, при використанні як завантажувача GRUB(незалежно від операційної системи) рекомендується винести окремий розділ каталог /boot .
У старих джерелах про Linux можна прочитати про інший сенс до виділення розділу для каталогу /boot , причому на самому початку диска: через неможливість завантаження ядра програмою Lilo з циліндра номером вище, ніж 1023. сучасних версіяхзавантажувачів таких обмежень немає. Тим не менш, якщо розділ під /boot створюється, резонно зробити його першим на диску, а безпосередньо за ним розмістити розділ підкачки: це додасть п'ять копійок швидкодії при здійсненні свопінгу.
І ще з галузі історії: вимога, щоб кореневий та завантажувальний розділи були неодмінно первинними, також давно знято. І ці файлові системи можуть поміщатися на логічних розділах всередині Extended Partition.
Так само ясно, що гілки файлової системи, що змінюються - каталоги /var і /tmp , - повинні бути винесені за межі кореневого розділу. Причому останній, як неодноразово говорилося раніше, взагалі доцільно розмістити на файловій системі оперативної пам'яті (tmpfs чи mfs). У випадку, якщо каталог /var містить підкаталоги для портоподібних систем пакетного менеджменту, подібно /var/abs , /var/cache/pacman/src та /var/cache/pacman/pkg в Archlinux, вони також повинні утворювати самостійні файлові системи
Тепер - каталог /usr, що містить або компоненти базової системи(як у BSD), або — основну масу додатків користувача (як у більшості дистрибутивів Linux). Він містить легковідновлювані дані і, по хорошому, повинен би бути практично незмінним, і тому, безумовно, заслуговує на виділення на самостійному розділі. Причому з його складу доцільно вичленувати, з одного боку, підкаталоги /usr/X11R6 та /usr/local , з іншого — підкаталоги для портоподібних систем пакетного менеджменту: /usr/ports , /usr/pkgsrc та /usr/pkg у BSD-системах , /usr/portages в Gentoo Linux, і так далі. Причому від останніх слід відокремити підкаталоги для розміщення вихідних джерел, що завантажуються з мережі при складанні портів - /usr/ports/distfiles, /usr/pkgsrc/disfiles, /usr/portages/distfiles та подібні їм.
У BSD-системах, крім цього, з каталогу /usr має сенс виділити підкаталоги /usr/src і /usr/obj, що містять вихідні тексти базових компонентів(включаючи ядро) та проміжні продукти їх компіляції, які утворюються в результаті процедур make buildworld і make buildkernel .
І, нарешті, каталог /home , що містить змінні і часто невідновні дані, підлягає винесенню з кореня файлової ієрархії обов'язково. Причому я завжди намагаюся розмістити його або на окремому слайсі (BSD), або на первинному розділі (Linux).
Запропонована схема поділу файлових систем може здатися надмірно ускладненою. Однак вона дає гарантію відокремлення легко відновлюваних, важко відновлюваних і невідновних даних, що полегшить перевстановлення системи у разі нагальної потреби, і навіть міграцію з системи на систему.
Додатковий її плюс - у тому, що для окремих гілок файлового дерева, залежно від характеру розміщених на ній даних, у Linux можна підібрати фізично оптимальну файлову систему. Наприклад, для розділу під /boot немає сенсу використовувати щось крім Ext2fs. Кореневий розділ зазвичай рекомендується форматувати у надійній і при цьому найбільш сумісній Ext3fs. Під каталоги з величезною кількістю дрібних файлів, такі як /var/abs в Archlinux, /usr/portages в Gentoo, доцільно задіяти ReiserFS: адже вміле поводження з дрібними файлами - це її профіль. А в каталозі /home, де можлива поява величезних мультимедійних файлів (і який сам по собі зазвичай дуже великий), до двору може припасти XFS (хоча, як показують виміри, і ReiserFS виглядає тут цілком гідно). Такі заходи можуть сприяти підвищенню і надійності зберігання даних та швидкодії файлових операцій.
Користувачі BSD-операцій безальтернативно прив'язані до файлових систем типу FFS. Однак і вони мають простір для маневру. По-перше - за рахунок варіювання розмірів блоку та фрагмента окремих файлових систем, що сприяє або продуктивності дискових операцій, або економії дискового простору. А по-друге, деякі гілки файлового древа (такі, як /tmp або /usr/obj , всупереч рекомендаціям, можна безбоязно монтувати в суто асинхронному режимі, вигравши на цьому відсоток-другий продуктивності.
Сьогодні спробуємо з'ясувати, що описує стандарт POSIX. Стандарти призначені для того, щоб мій комп'ютер міг взаємодіяти з вашим комп'ютером. Завдяки їм, на двох схожих комп'ютерах веб-сторінки або трансляція відео в реальному часі виглядатимуть однаково.
Однак стандартні призначені для масштабніших завдань, ніж простий обмін будь-якими даними між користувачами. Деякі стандарти визначають особливу модель, завдяки якій відкриваються можливості, які значно перевершують за своїм значенням сумісність файлів або мереж. Стандарт POSIX належить до їх числа.
Що таке POSIX?
POSIX (вимовляється як «позикс») - це портативний інтерфейс операційних систем. Але що це означає? По-перше, потрібно позначити область дії поняття «портативність», у даному випадку, і визначитися з поняттям «інтерфейс». Щоб з'ясувати це, необхідно відштовхуватися від того, що обидва поняття нерозривно пов'язані.
"Портативність", у контексті стандарту POSIX, відноситься до вихідного коду(Не до бінарників, які з цих вихідників збираються). Тепер з'ясуємо, що таке "інтерфейс". У програмуванні «інтерфейс» - це взаємодія вашого коду з рештою коду. Інтерфейс чекає від вашого коду надання певної інформації. Ваш код, своєю чергою, передбачає отримання певної інформації від інтерфейсу. Гарний приклад- функція fopen() у мові Сі. Вона чекає на інформацію з двох частин: шлях до файлу і режим, в якому він буде відкритий. За допомогою цих даних операційна система повертає інший вид інформації, який називається «дескриптор файлу». Дескриптор файлу може бути використаний для читання або запису файлу. Це і є інтерфейс. З усього цього випливає, що POSIX-сумісний код може бути скомпільований під будь-яку POSIX-сумісну операційну систему без серйозних змін, отже, він буде портативним.
Список інтерфейсів, що відносяться до стандарту POSIX, знаходиться, проте, навіть незважаючи на його величезну довжину, цілком можливо, що він неповний. POSIX не обмежується системними викликами, він також визначає стандарти для оболонок операційних систем (шеллів, інакше – інтерфейсів) командного рядка), системних утиліт, на кшталт «awk» або «echo», системних бібліотек та багато іншого.
Стандарт POSIX з'явився у вигляді проекту Річарда Столлмана у 1985 році та надалі був оформлений як IEEE Std 1003.-1998. Як видно з назви, 1998 був роком офіційної публікації. З того часу було випущено велику кількість доповнень і розширень до POSIX, який поступово перетворюється на ціле сімейство стандартів, формально відоме як IEEE 1003, визнане як міжнародне, з позначенням SO/IEC 9945, яке просто називається стандарт сімейства POSIX.
Операційній системі зовсім необов'язково бути POSIX-сумісною або тим більше мати сертифікат POSIX, проте це дозволяє розробникам створювати додатки, інструменти та платформи, не переписуючи код раз-по-раз, а лише доповнювати і підключатися до вже готового. Також зовсім не обов'язково писати POSIX-сумісний код, проте це значно покращує переносимість проектів між операційними системами. Це означає, що вміння писати код, який сумісний зі стандартом POSIX, є цінним саме собою, і, безумовно, дуже корисно для кар'єри. Великі проекти, такі як Gnome або KDE, дотримуються стандарту POSIX, що гарантує їхню роботу на різних операційних системах. Підсистема POSIX реалізована навіть у останніх випусках Windows. Linux, як відомо, підтримує більшість системних викликів, що належать до стандарту POSIX, так само як і велике розширення до нього, що називається «Стандартна база Linux», яка призначена для об'єднання дистрибутивів Linux у плані підтримки вихідних кодів та бінарних даних.
Сподіваюся, ми пролили світло на запитання, що таке POSIX. Маєте цікаву інформацію на тему? Будь ласка, поділіться їй у коментарях.