Комментарии 16
Это всё очень хорошо, но, кроме языка Си для написания ядра, остальные перечисленные вещи были придуманы не в Unix.
Главным достоинством Unix было то, что её спроектировали с возможностью переносимости, в то время как остальные ОС того времени (да и большинство до сих пор) были заточены под конкретную линейку оборудования.
Возможно это уже более поздний момент (1988), но важно и появление стандартов POSIX и ANSI C (стандартизация системного API)
Насколько помню, MULTICS, "пародией" на который был ранний не UNIX ещё, а UNICS, был написан на PL/I.
Древовидная структура каталогов -- вроде, тоже MULTICS. Ну а отсутствие "букв", а точнее, явного указания на устройство является, как по мне, громаднейшим недостатком. Вот надо мне заменить жёсткий диск в ПК -- как мне сходу понять, какие каталоги на нём лежат?
Многозадачность -- это вообще норма любых ОС середины 1960-х годов.
А вот многопоточности не было (а в OS/360 была!), да и новые задачи (процессы) порождались уродливым и исключительно неэффективным fork. Асинхронного ввода-вывода тоже не было, хотя ввод-вывод по самой своей природе асинхронен...
В общем, в реальности уних -- весьма и весьма посредственная, если не сказать убогая система. Посему потом и стали придумывать всякие расширения, стандарт POSIX родили (но линух его не придерживается)...
Вот надо мне заменить жёсткий диск в ПК -- как мне сходу понять, какие каталоги на нём лежат?
mount | grep /dev/мойраздел
Зато не надо перенастраивать программы, установив дополнительный диск.
В остальном с Вами согласен, но указанная проблема надумана.
А в любой "нормальной" системе никаких команд вводить не надо вообще, и так понятно, что и где лежит. Плюс, надуманной проблему я не считаю; лично мне в работе крайне неудобен униховый подход. Лучше уж буквально физические адреса, хотя я предпочёл бы буквенно-цифровые обозначения примерно как в RSX-11 (DM3: и т.п.), только без жёстких ограничений на длину (ну, там-то понятно -- память экономили).
Зато не надо перенастраивать программы, установив дополнительный диск
А вот это не понял, честно говоря. Скажем, установил я новый диск на Винде -- с какой стати мне что-то перенастраивать? Максимум -- удобную мне буковку ему назначить.
и так понятно, что и где лежит
Да ни фига не понятно на самом деле. Если мы возьмём Windows, то соответствие между буквами разделов и физическими дисками тоже неочевидно (при том, что на одном диске может быть несколько разделов).
Дальше ещё возникает вопрос со всякими аппаратными и программными RAID и прочими виртуальными разделами.
В Unix логические адреса вводятся поверх физических, и это правильно. Хотя виртуальные машины в значительной степени тоже решают эту проблему. Но современные PC далеки от систематического использования виртуальных машин на фронтэнде.
А вот это не понял, честно говоря. Скажем, установил я новый диск на Винде -- с какой стати мне что-то перенастраивать?
Ну вот например был у меня домашний раздел пользователя /home/user на некотором физическом диске, и перестал влезать. Тогда я подключаю ещё один HDD, копирую туда данные юзера и этот же каталог /home/user монтирую на него. Всё продолжает работать. А так бы пришлось все пользовательские ссылки менять на новое устройство.
Если мы возьмём Windows, то соответствие между буквами разделов и физическими дисками тоже неочевидно (при том, что на одном диске может быть несколько разделов)
Что в Винде можно всё запутать -- это да; иногда это даже неизбежно. Но Винда позволяет и не запутывать, если у тебя нет веских причин для всяких там "виртуальных разделов". Я вот давно диски на разделы не разбиваю (не считая системного, но это уже сама Винда делает), поэтому у меня строгое соответствие "буква -- физический диск" (технически у меня сейчас на рабочем компе пять физических дисков).
В Unix логические адреса вводятся поверх физических, и это правильно
С этим я согласен, но я не согласен с "единой файловой системой", которую я просто обязан использовать, и не согласен с сокрытием физических устройств, которые где-то там надо искать. Я убеждён, что основной должна быть индивидуальная система на каждом диске/разделе -- и она должна быть "на виду", а не где-то там спрятана, ну а всякие там порты и т.п. устройства вообще не должны входить в какую-то такую единую иерархию, а лежать сами по себе. Вот если хошь, то поверх этих никак не связанных между собой и прямо доступных файловых систем и устройств строй виртуальное дерево а-ля Уних -- но не прячь нижний уровень.
Ну вот например был у меня домашний раздел пользователя /home/user на некотором физическом диске, и перестал влезать. Тогда я подключаю ещё один HDD, копирую туда данные юзера и этот же каталог /home/user монтирую на него. Всё продолжает работать. А так бы пришлось все пользовательские ссылки менять на новое устройство.
Про такой вариант не подумал, но лично мне это абсолютно и категорически не нравится. Я в такой ситуации либо поставил бы более ёмкий диск, либо просто часть каталогов держал бы на другом диске -- собственно, у меня так дело и обстоит, никакого "каталога пользователя" у меня нет, а то, что создаёт сама Винда, мною никак не используется (ну, кроме сэйвов игрушек, которые туда пишутся автоматом; все документы, проекты и т.д. я держу в отдельных каталогах на основном рабочем диске, не совпадающим с системным).
Но замечу, что Ваш стиль работы, как и униховое "дерево", можно поддерживать и на "нормальной" системе с помощью, скажем, драйвера виртуальной файловой системы -- и я не против такого варианта, я против, повторюсь, жёсткого навязывания уних-стиля, который лично мне жутко неудобен.
И под Виндой можно куда угодно монтировать уже сколько лет, и под Линуксом ничто не запрещает монтировать диски куда-нибудь в /c, /d
Оно, в общем, удобно, что вместо чего-то вроде \\?\Volume{f6e5d4c3-b2a1-0f9e-8d7c-6b5a4f3e2d1c}\ можно просто c:\ писать, но больших выводов отсюда не сделать.
А в любой “нормальной” системе никаких команд вводить не надо вообще, и так понятно, что и где лежит.
В винде вашей “буквы дисков” давно уже точки монтирования, а системные каталоги полны линков… ой, простите, reparse points. Порядок присвоения букв по умолчанию, ЕМНИМС, менялся несколько раз. Плюс ещё элементы shell’s namespace, которые видны в проводнике, но отсутствуют в физической ФС.
Хорошо, что вы поместили “нормальный” в кавычки, помянув винду и её упоротые “диски”. На одном устройстве может быть несколько дисков, которые указывают в разные места, а также разные диски могут указывать в одно место. Вводить может ничего и не надо, но без бутылки бывает тяжело разобраться что же именно находится на каком-то физическом устройстве. А за обратные слэши в путях черти давно отдельный котёл приготовили.
Набрать findmnt --real гораздо удобнее, как по мне. Сразу видно, кто на ком стоял.
Назначение буквы диску ... Ну кто как привык... Но буква диска в пути это лишняя сущность, которая не нужна для чтения записи каталогов и файлов. Вместо выбора отдельной сущности (буква диска) программам достаточно выбрать каталог.
Можно для приложения выделить отдельный диск, подключив его к определённому каталогу и приложение не будет "знать" что оно работает с отдельным диском.
Главная фишка Linux это лизензия GPL. Благодаря лицензии Linux смог вытеснить Bsd и Unix системы.
Я понимаю, когда для перевода выбирают ценную статью, несущую свет знаний. Но зачем этот мусор переводить?
Всегда любил Юникс. Но, нахрена сравнивать ОС для персоналок (DOS) с ОС для мини-ЭВМ (Unix)? Это разные классы аппаратного обеспечения, в принципе.
Или вот:
В отличие от DOS или Windows, здесь нет буквенных обозначений дисков. Это означает, что дерево каталогов может охватывать несколько устройств: например, физический жёсткий диск и SSD....
Монтировать логический том на папку др. логического тома Уиндоуз уже лет 30 умеет. Не сильно меньше самой Юникс.
Перенаправлением потоков ввода-вывода мы и на DOS активно пользовались в 80-е. Хотя на Юниксе это все гораздо мощнее реализовано. Но, там и аппаратное обеспечение не такое, как под ДОС было.
Короче, весьма странный текст.
А, с электросетями надо было бы сравнивать не со Штатовскими, а с советскими. Первая глобальная единая управляемая электросеть с перетоком энергии.

Благодаря этим пяти идеям из Unix 1970-х годов Linux до сих пор отлично работает