Хотя многие считают Linux современной операционной системой, она воплощает в себе идеи, которым уже более 50 лет. Рассмотрим некоторые из этих давних концепций и причины, по которым они сохраняются в современных дистрибутивах Linux.
Структура каталогов
Древовидная структура файлов
Возможно, вы не задумываетесь о структуре каталогов, но именно она поразила специалистов в области информатики, когда в 1974 году в журнале Communications of the ACM была опубликована статья «Система разделения времени Unix» (The Unix Time-Sharing System). Файловая система имела иерархическую структуру — воплощая новаторскую для того времени концепцию, которая сегодня воспринимается как нечто само собой разумеющееся.
Структура каталогов и по сей день является характерной чертой Unix-подобных систем, включая Linux. Каталоги расходятся от центрального корневого (обозначаемого как /) подобно тому, как ветви дерева отходят от ствола. В отличие от DOS или Windows, здесь нет буквенных обозначений дисков. Это означает, что дерево каталогов может охватывать несколько устройств: например, физический жёсткий диск и SSD, стационарный накопитель и USB-флешку или SSD и оптический диск. Такая организация обеспечивает файловой системе высокую гибкость.
Процессы
Одновременный запуск различных процессов из командной строки
Одной из отличительных черт Unix всегда была многозадачность, в то время как другие системы, например MS-DOS, были однозадачными. Именно она позволила реализовать такие функции, как управление задачами (job control).
Задачу можно перевести в фоновый режим, что удобно для процессов, которые, как известно, требуют длительного времени выполнения:
some_long_process &
Эта команда позволяет сохранить контроль над командной оболочкой (shell), переводя процесс some_long_process в фоновый режим. В противном случае вы не смогли бы выполнять другие действия, пока этот процесс работал.
Если вы запустили процесс в оболочке и он выполняется слишком долго, можно нажать Ctrl+z, чтобы приостановить его и вернуть управление оболочкой.
Приостановленный процесс можно перевести в фоновый режим командой bg:
bg
Механизм управления задачами был разработан в эпоху, когда преобладали текстовые терминалы. С повсеместным распространением оконных систем, таких как X11, он стал использоваться реже, однако по-прежнему остается полезным инструментом при работе в окне терминала.
Конвейеры
Перенаправление ввода и вывода способами, о которых вы даже не подозревали
Концепция «конвейера» (pipeline), пожалуй, является самым значимым наследием Unix в системе Linux. Программы Unix позволяют перенаправлять свои потоки ввода и вывода непосредственно в командной оболочке (shell).
Программа может направлять свой вывод в файл — например, утилита ps, перечисляющая все процессы в системе:
ps aux > allprocs
Также можно перенаправить ввод из файла — например, при запуске скрипта оболочки:
sh < command_list.sh
Но именно конвейер, вероятно, играет самую важную роль. Он передаёт вывод одной команды на вход другой. Один из моих любимых примеров — забавный трюк, превращающий вывод команды fortune в радужный текст:
fortune | lolcat
В рекламном фильме Bell Labs 1982 года можно увидеть, как Брайан Керниган, один из создателей языка C, буквально на лету создаёт программу проверки орфографии, используя уже существующие утилиты командной строки.
Открытый исходный код на языке C
C — ключ к запуску программ на разных типах компьютеров
Хотя сама система Unix не была проектом с открытым исходным кодом, университеты, получавшие её от Bell Labs, зачастую имели доступ к исходному коду. Одной из особенностей, отличавших Unix от других операционных систем, было то, что её основные компоненты были написаны на языке высокого уровня — языке C, созданном Деннисом Ритчи и ставшем популярным благодаря первому изданию книги «Язык программирования C» (авторы — Брайан Керниган и Деннис Ритчи; книга известна под аббревиатурой K&R).
Ранее операционные системы писались на языке ассемблера. Программы на ассемблере работают быстро, но писать их утомительно, к тому же они жёстко привязаны к конкретному компьютеру или архитектуре. Поскольку C — это компилируемый язык, для запуска программы, написанной на C, на другом компьютере достаточно было лишь создать компилятор для этой машины.
На практике же переносимость часто оставалась лишь теоретической. Хотя скомпилировать программу на C для запуска на другом компьютере было относительно несложно, на ранних этапах большинство разработчиков писали программы в среде Unix и зачастую воспринимали особенности этой системы как должное. В результате такие программы не работали в других операционных системах. Одним из способов решения этой проблемы был перенос всей среды на новый компьютер — иными словами, портирование Unix на эту машину. Поскольку C был языком высокого уровня, это можно было сделать, изменив лишь машинно-зависимые части кода.
Поддержка пользователей
В мире Linux можно обойтись помощью друзей
Во времена разработки Unix компания AT&T — материнская компания Bell Labs — действовала в рамках мирового соглашения, ограничивающего её деятельность в обмен на фактическую монополию на телефонную связь в США. На практике это означало, что AT&T не могла выводить на рынок никакие продукты, кроме услуг телефонной связи. Следовательно, компания не имела права продавать Unix как коммерческий продукт. Через свою дочернюю структуру Western Electric компания AT&T предоставляла Unix университетам и исследовательским лабораториям практически по себестоимости — за плату, едва покрывавшую расходы на пересылку магнитных лент.
Это также означало, что AT&T не обеспечивала техническую поддержку. Пользователям Unix приходилось самостоятельно заниматься исправлением ошибок и обновлением системы. Они объединялись в группы — например, в знаменитую Usenix, которая со временем сама по себе превратилась в крупную конференцию по компьютерным наукам. Студенты и аспиранты, изучающие информатику, успешно справлялись с возникавшими задачами. Одним из ответвлений этого движения стала система BSD (Berkeley Software Distribution), созданная в Калифорнийском университете в Беркли в конце 1970-х годов.
И сегодня можно получить помощь и поддержку в сообществах пользователей, на форумах и в тематических разделах Reddit.
Использование маломощного оборудования
Найдите старый компьютер (хотя, возможно, и не PDP-7)
Пользователи Linux гордятся тем, что могут запускать дистрибутивы этой системы на устаревшем оборудовании — например, на старом ноутбуке; однако эта традиция восходит ещё к самой Unix. Когда Кен Томпсон и Деннис Ритчи начали работу над Unix, это происходило после того, как компания Bell Labs вышла из проекта MULTICS — системы, которую можно назвать «Windows Vista своего времени». Это был амбициозный проект, призванный создать то, что мы сегодня назвали бы «облачными вычислениями»: своего рода вычислительную инфраструктуру, доступную и надёжную, подобно электросети или водопроводу (по крайней мере, в США).
Проект MULTICS вышел за рамки бюджета и затянулся, хотя в 1970-х годах система всё же появилась на мейнфреймах. В распоряжении Томпсона и Ритчи было менее мощное оборудование. Они взяли в работу компьютер PDP-7 производства Digital Equipment Corporation. Это было сродни тому, как сегодня находят новое применение старому ПК.
Продолжая традиции Unix
От иерархической структуры каталогов до переносимого кода на языке C — Linux сохраняет множество традиций, заложенных в Unix. Эта система опирается на лучшие достижения прошлого, устремляясь при этом в будущее.
Комментарии (15)
alan008
19.07.2026 10:05Возможно это уже более поздний момент (1988), но важно и появление стандартов POSIX и ANSI C (стандартизация системного API)
SIISII
19.07.2026 10:05Насколько помню, MULTICS, "пародией" на который был ранний не UNIX ещё, а UNICS, был написан на PL/I.
Древовидная структура каталогов -- вроде, тоже MULTICS. Ну а отсутствие "букв", а точнее, явного указания на устройство является, как по мне, громаднейшим недостатком. Вот надо мне заменить жёсткий диск в ПК -- как мне сходу понять, какие каталоги на нём лежат?
Многозадачность -- это вообще норма любых ОС середины 1960-х годов.
А вот многопоточности не было (а в OS/360 была!), да и новые задачи (процессы) порождались уродливым и исключительно неэффективным fork. Асинхронного ввода-вывода тоже не было, хотя ввод-вывод по самой своей природе асинхронен...
В общем, в реальности уних -- весьма и весьма посредственная, если не сказать убогая система. Посему потом и стали придумывать всякие расширения, стандарт POSIX родили (но линух его не придерживается)...
vadimr
19.07.2026 10:05Вот надо мне заменить жёсткий диск в ПК -- как мне сходу понять, какие каталоги на нём лежат?
mount | grep /dev/мойраздел
Зато не надо перенастраивать программы, установив дополнительный диск.
В остальном с Вами согласен, но указанная проблема надумана.
SIISII
19.07.2026 10:05А в любой "нормальной" системе никаких команд вводить не надо вообще, и так понятно, что и где лежит. Плюс, надуманной проблему я не считаю; лично мне в работе крайне неудобен униховый подход. Лучше уж буквально физические адреса, хотя я предпочёл бы буквенно-цифровые обозначения примерно как в RSX-11 (DM3: и т.п.), только без жёстких ограничений на длину (ну, там-то понятно -- память экономили).
Зато не надо перенастраивать программы, установив дополнительный диск
А вот это не понял, честно говоря. Скажем, установил я новый диск на Винде -- с какой стати мне что-то перенастраивать? Максимум -- удобную мне буковку ему назначить.
vadimr
19.07.2026 10:05и так понятно, что и где лежит
Да ни фига не понятно на самом деле. Если мы возьмём Windows, то соответствие между буквами разделов и физическими дисками тоже неочевидно (при том, что на одном диске может быть несколько разделов).
Дальше ещё возникает вопрос со всякими аппаратными и программными RAID и прочими виртуальными разделами.
В Unix логические адреса вводятся поверх физических, и это правильно. Хотя виртуальные машины в значительной степени тоже решают эту проблему. Но современные PC далеки от систематического использования виртуальных машин на фронтэнде.
А вот это не понял, честно говоря. Скажем, установил я новый диск на Винде -- с какой стати мне что-то перенастраивать?
Ну вот например был у меня домашний раздел пользователя /home/user на некотором физическом диске, и перестал влезать. Тогда я подключаю ещё один HDD, копирую туда данные юзера и этот же каталог /home/user монтирую на него. Всё продолжает работать. А так бы пришлось все пользовательские ссылки менять на новое устройство.
SIISII
19.07.2026 10:05Если мы возьмём Windows, то соответствие между буквами разделов и физическими дисками тоже неочевидно (при том, что на одном диске может быть несколько разделов)
Что в Винде можно всё запутать -- это да; иногда это даже неизбежно. Но Винда позволяет и не запутывать, если у тебя нет веских причин для всяких там "виртуальных разделов". Я вот давно диски на разделы не разбиваю (не считая системного, но это уже сама Винда делает), поэтому у меня строгое соответствие "буква -- физический диск" (технически у меня сейчас на рабочем компе пять физических дисков).
В Unix логические адреса вводятся поверх физических, и это правильно
С этим я согласен, но я не согласен с "единой файловой системой", которую я просто обязан использовать, и не согласен с сокрытием физических устройств, которые где-то там надо искать. Я убеждён, что основной должна быть индивидуальная система на каждом диске/разделе -- и она должна быть "на виду", а не где-то там спрятана, ну а всякие там порты и т.п. устройства вообще не должны входить в какую-то такую единую иерархию, а лежать сами по себе. Вот если хошь, то поверх этих никак не связанных между собой и прямо доступных файловых систем и устройств строй виртуальное дерево а-ля Уних -- но не прячь нижний уровень.
Ну вот например был у меня домашний раздел пользователя /home/user на некотором физическом диске, и перестал влезать. Тогда я подключаю ещё один HDD, копирую туда данные юзера и этот же каталог /home/user монтирую на него. Всё продолжает работать. А так бы пришлось все пользовательские ссылки менять на новое устройство.
Про такой вариант не подумал, но лично мне это абсолютно и категорически не нравится. Я в такой ситуации либо поставил бы более ёмкий диск, либо просто часть каталогов держал бы на другом диске -- собственно, у меня так дело и обстоит, никакого "каталога пользователя" у меня нет, а то, что создаёт сама Винда, мною никак не используется (ну, кроме сэйвов игрушек, которые туда пишутся автоматом; все документы, проекты и т.д. я держу в отдельных каталогах на основном рабочем диске, не совпадающим с системным).
Но замечу, что Ваш стиль работы, как и униховое "дерево", можно поддерживать и на "нормальной" системе с помощью, скажем, драйвера виртуальной файловой системы -- и я не против такого варианта, я против, повторюсь, жёсткого навязывания уних-стиля, который лично мне жутко неудобен.
misha_erementchouk
19.07.2026 10:05И под Виндой можно куда угодно монтировать уже сколько лет, и под Линуксом ничто не запрещает монтировать диски куда-нибудь в /c, /d
Оно, в общем, удобно, что вместо чего-то вроде \\?\Volume{f6e5d4c3-b2a1-0f9e-8d7c-6b5a4f3e2d1c}\ можно просто c:\ писать, но больших выводов отсюда не сделать.
RedEyedAnonymous
19.07.2026 10:05А в любой “нормальной” системе никаких команд вводить не надо вообще, и так понятно, что и где лежит.
В винде вашей “буквы дисков” давно уже точки монтирования, а системные каталоги полны линков… ой, простите, reparse points. Порядок присвоения букв по умолчанию, ЕМНИМС, менялся несколько раз. Плюс ещё элементы shell’s namespace, которые видны в проводнике, но отсутствуют в физической ФС.
RulenBagdasis
19.07.2026 10:05Хорошо, что вы поместили “нормальный” в кавычки, помянув винду и её упоротые “диски”. На одном устройстве может быть несколько дисков, которые указывают в разные места, а также разные диски могут указывать в одно место. Вводить может ничего и не надо, но без бутылки бывает тяжело разобраться что же именно находится на каком-то физическом устройстве. А за обратные слэши в путях черти давно отдельный котёл приготовили.
Набрать
findmnt --realгораздо удобнее, как по мне. Сразу видно, кто на ком стоял.
snarkrans
19.07.2026 10:05Главная фишка Linux это лизензия GPL. Благодаря лицензии Linux смог вытеснить Bsd и Unix системы.
SIISII
19.07.2026 10:05Скорей, религиозный, а не технический подход. Псевдосвобода GNU -- это ж религия в практически чистом виде, только официального культа святого Столлмана не хватает.
vadimr
19.07.2026 10:05Довольно смелое заявление насчёт "вытеснить BSD системы". Маководы недоумевают.
Elbrus128
19.07.2026 10:05Я понимаю, когда для перевода выбирают ценную статью, несущую свет знаний. Но зачем этот мусор переводить?
Всегда любил Юникс. Но, нахрена сравнивать ОС для персоналок (DOS) с ОС для мини-ЭВМ (Unix)? Это разные классы аппаратного обеспечения, в принципе.
Или вот:
В отличие от DOS или Windows, здесь нет буквенных обозначений дисков. Это означает, что дерево каталогов может охватывать несколько устройств: например, физический жёсткий диск и SSD....
Монтировать логический том на папку др. логического тома Уиндоуз уже лет 30 умеет. Не сильно меньше самой Юникс.
Перенаправлением потоков ввода-вывода мы и на DOS активно пользовались в 80-е. Хотя на Юниксе это все гораздо мощнее реализовано. Но, там и аппаратное обеспечение не такое, как под ДОС было.
Короче, весьма странный текст.
А, с электросетями надо было бы сравнивать не со Штатовскими, а с советскими. Первая глобальная единая управляемая электросеть с перетоком энергии.
vadimr
Это всё очень хорошо, но, кроме языка Си для написания ядра, остальные перечисленные вещи были придуманы не в Unix.
Главным достоинством Unix было то, что её спроектировали с возможностью переносимости, в то время как остальные ОС того времени (да и большинство до сих пор) были заточены под конкретную линейку оборудования.
SIISII
Я б сказал -- единственным достоинством.