Unix like что это
Unix-подобная операционная система
Unix-подобная операционная система
UNIX-подобная операционная система (иногда сокр. *nix) — система, которая образовалась под влиянием UNIX. Термин включает свободные/открытые операционные системы, образованные от UNIX компании Bell Labs или эмулирующие его возможности, коммерческие и запатентованные разработки, а также версии, основанные на исходном коде UNIX. Нет стандарта, определяющего термин, и допустимы различные точки зрения о том, считать ли определённый продукт UNIX-подобным или нет.
Содержание
Термин «UNIX-подобный» и торговая марка UNIX
The Open Group обладает торговой маркой UNIX и ведёт дела Single UNIX Specification, где слово UNIX используется как знак соответствия. Они не приветствуют употребление термина «UNIX-подобный» и считают, что это злоупотребление их товарным знаком. Руководство группы требует использования заглавных букв в названии UNIX или в другом случае отдельно от остального текста, одобряют использование слова UNIX как прилагательного в сочетании с такими словами, как «система», и не одобряют написание через дефис (относится к английскому тексту). Наиболее близкий термин, который они сочли бы корректным, был бы UNIX system-like. [1]
С 2007 года ведётся спор между Wayne R. Gray и The Open Group, в котором обсуждается использование слова UNIX как торгового знака. [2] По словам Trademark Trial and Appeal, Board Grау со своей компанией требует от The Open Group предоставить ему документацию для их требований к торговой марке.
Также, в 2007 году The Open Group настояла на том, чтобы немецкий Университет Касселя не использовал «UNIK» в качестве сокращения. [3]
Категории
Деннис Ритчи, один из создателей UNIX, выразил своё мнение, что UNIX-подобные системы, такие как Linux, являются де-факто UNIX-системами. Эрик Рэймонд предложил разделить UNIX-подобные системы на 3 типа:
Генетический UNIX Системы, исторически связанные с кодовой базой AT&T. Большинство, но не все коммерческие дистрибутивы UNIX-систем подпадают под эту категорию. Так же, как и BSD-системы, которые являются результатами работы университета Беркли в поздних 1970-х и ранних 1980-х. В некоторых из этих систем отсутствует код AT&T, но до сих пор прослеживается происхождение от разработки AT&T. UNIX по товарному знаку или бренду Эти системы, в основном коммерческого характера, были определены The Open Group как соответствующие Единой спецификации UNIX, и им разрешено носить имя UNIX. Большинство этих систем — коммерческие производные кодовой базы System V в той или иной форме (например, Amiga UNIX), хотя некоторые (например, z/OS компании IBM) заслужили торговую марку через слой совместимости с POSIX, не являясь по сути UNIX. Многие старые UNIX-системы не подходят под это определение. UNIX по функциональности В целом, любая система, поведение которой примерно соответствует спецификации UNIX. К таким системам можно отнести Linux и Minix, которые ведут подобно UNIX-системе, но не имеют генетических связей с кодовой базой AT&T. Большинство свободных/открытых реализаций UNIX, являясь генетическим UNIX или нет, подпадают под ограниченное определение этой категории в связи с дороговизной сертификации The Open Group, которая стоит несколько тысяч долларов.
Cygwin, не являясь операционнной системой, предоставляет UNIX-подобную среду в Microsoft Windows; также существуют сервисы Microsoft Windows для UNIX.
Развитие UNIX-подобных систем
UNIX-системы начали появляться с поздних 1970-х и ранних 1980-х. Много проприетарных версий, таких как Idris (1978), Coherent (1983), и UniFlex (1985), ставили целью обеспечить нужды бизнеса функциональностью, доступной обученным пользователям UNIX.
Когда AT&T разрешила коммерческое лицензирование UNIX в 1980-х, множество разработаных проприетарных систем основывались на этом, включая AIX, HP-UX, IRIX, Solaris, Tru64, Ultrix и Xenix. Это во многом вытесняло проприетарных клонов. Растущая несовместимость между системами привела к созданию стандартов взаимодействия, в том числе POSIX и Единой спецификации UNIX.
Между тем, в 1983 году был запущен проект GNU, благодаря которому удалось сделать операционную систему, которую все пользователи компьютера могли свободно использовать, изучать, исправлять, пересобирать. Различные UNIX-подобия разрабатывались аналогично GNU, часто с теми же основными компонентами. Они прежде всего служили дешёвым замещением UNIX и включали 4.4BSD, Linux и Minix. Некоторые из них послужили основой для коммерческих UNIX-систем, таких как BSD/OS и Mac OS X. Примечательно, что Mac OS X 10.5 (Leopard) сертифицирован Единой спецификацией UNIX. [4]
Что такое UNIX и зачем он нужен
Операционная система, которая изменила мир, хотя в ней почти никто не работал
В 1970-х годах в мире появился UNIX — операционная система, из которой растут ноги у большинства современных операционок. Для своего времени это был технологический прорыв, а заложенные там принципы мы используем до сих пор. В этой статье — что же там было такого революционного.
👍 Статья расширяет кругозор и помогает лучше понять информатику, но не имеет прикладной ценности. Если вам нужно что-то прикладное — прочитайте про размеры элементов в CSS.
Однозадачные компьютеры
Когда компьютеры только начали появляться, то работали они примерно так:
Получается, что они работали в однозадачном режиме: работает только одна программа, а для запуска второй нужно остановить первую. По этому принципу до сих пор работают контроллеры в ваших микроволновках и холодильниках, а также контроллеры типа Arduino.
Сначала такой подход всех устраивал, потом стало неудобно.
Многозадачные компьютеры
Чтобы компьютер работал более эффективно, программисты написали код, который управляет работой всего компьютера — операционную систему.
Первые операционные системы были псевдомногозадачными. Это значит, что они не запускали одновременно несколько программ, а в цикле по очереди брали по одной команде из каждой программы и выполняли их. Так как переключение между командами из разных программ происходит быстро, то создаётся впечатление, что они работают одновременно.
Потом эту проблему тоже решили, и компьютер мог выполнять несколько программ действительно одновременно, чтобы они не мешали друг другу. Так появились многозадачные операционные системы.
Но в то время домашних компьютеров не было, а желающих поработать за университетским компьютером было много, поэтому все работали по очереди. Например, один лаборант работал на нём с часу до двух, второй — с двух до трёх, а научный руководитель работал за компьютером с трёх до шести.
При этом мощности компьютеров уже хватало на то, чтобы с ним мог работать второй пользователь, не замедляя работу первого. А вот операционных систем, которые бы так умели, — не было. И здесь появляется UNIX.
UNIX — многопользовательская операционная система
Создатели UNIX Кен Томпсон и Деннис Ритчи (который потом напишет язык C) решили проблему так:
Со стороны пользователя кажется, что весь сервер в его распоряжении, но на самом деле сервером могут пользоваться одновременно десятки человек и не знать о том, что сервер выполняет что-то ещё. Сейчас это звучит обычно и примитивно, но для того времени это был прорыв.
Операционную систему, которая умеет всё это делать, назвали UNIX — сокращение от Uniplexed Information and Computing Service (единый информационно-вычислительный сервис). Изначально это называлось UNICS, но потом последние две буквы превратились в одну.
Что нового появилось в UNIX, чего до неё не было
Вот что впервые появилось именно в UNIX — и в виде идей, и в виде готового кода:
Файловая система с любой глубиной вложенности. Мы сейчас привыкли к папкам, в которых можно создавать другие папки, а в них третьи и так почти до бесконечности. Но до UNIX глубина вложенности была ограничена — нельзя было создать, например, папку внутри другой папки.
Модель работы с файлами. Пользователю раньше нужно было самому предусмотреть формат, размер и физическое размещение файлов на диске. В UNIX это всё взяла на себя операционная система.
Работа с программами напрямую. До UNIX настройку работы всех программ можно было сделать только в командной строке: запустил → компьютер что-то посчитал → показал результат. Если нужно изменить параметры, то это надо было делать через командную строку. В новой системе можно было менять настройки программ прямо внутри них — именно так и устроены сейчас все программы.
Вывод всего как текста. Раньше компьютеры работали с битами и выводили битовые последовательности. Их нужно было отдельно разбивать на нужные фрагменты или использовать встроенные программы для перевода битов в байты, а из них — в текст.
В UNIX единица вывода — это не бит, а байт. А в байт как раз умещается символ текста, а значит, с ним можно работать как с текстом: искать, склеивать с другими, отправлять в файл и так далее.
Регулярные выражения стали использоваться не только в профессиональных задачах, но и как основа для обработки вывода программ.
Язык C. Этот язык появился в UNIX как замена языка B. Но B был интерпретируемым языком (как Python), и для запуска программ нужен был его интерпретатор. Язык C — компилируемый, а значит, готовые программы можно запускать на любом совместимом компьютере, даже если на нём нет компилятора C.
Протокол TCP/IP. До UNIX этот протокол не был популярен, и компьютеры связывались друг с другом по более старому протоколу, который не имел столько возможностей. Теперь благодаря этой операционной системе весь мир пользуется интернетом, построенным на протоколе TCP/IP. Справедливости ради, этот протокол появился не в первой поставке UNIX.
Как работают в UNIX
Для управления этой системой почти всегда используется командная строка. Есть, конечно, и графический интерфейс для некоторых систем и задач, но штука в том, что UNIX заточен на работу в серверах. А у серверов чаще всего нет ни клавиатуры, ни монитора — только сетевые соединения, через которые пользователи и соединяются с сервером, чтобы им управлять.
Как UNIX стал стандартом
С середины 1970-х годов идёт довольно мутная история, в которой компания
AT&T долго и небезуспешно пытается заработать на UNIX, а американские университеты и инженеры-любители делают свою открытую версию. Идёт конкуренция между стандартами, инструментами, поставками и протоколами.
Конкуренция выливается в то, что у UNIX появляется множество более совершенных потомков. Их мы называем Unix-подобными системами.
Можно сказать, что Unix-подобность — это такой набор правил, условностей и стандартов, которых должны придерживаться новые операционки, чтобы сохранять преемственность и некоторую совместимость. То есть такой ГОСТ для операционных систем. Операционка может быть и без ГОСТа, но с ним лучше.
Где сегодня используется UNIX
В чистом виде UNIX сейчас используется только на серверах и оборудовании связи. Всё дело в том, что для домашнего использования эта система подходит слабо: у неё нет встроенного графического интерфейса и все операции и программы нужно настраивать вручную.
Зато если нужна гарантированная надёжность, производительность и масштабируемость, особенно при сетевых нагрузках, — используют UNIX или производные от неё. Про них сейчас тоже расскажем.
UNIX-подобные системы
На основе оригинальных версий Юникса появилось много разных операционных систем: BSD, Solaris, HP-UX и даже MacOS, который сделан на основе BSD версии 4.4. Идеи, которые были заложены 50 лет назад, оказались настолько рабочими, что применяются до сих пор.
А ещё есть Linux и его производные — RedHat, Calculate, Ubuntu и ещё сотня дистрибутивов. Многие думают, что Линукс — это развитие Юникса, но на самом деле это полностью самостоятельное и независимое от него семейство операционных систем, хотя и слова похожие. Про Линукс обязательно расскажем в следующей статье.
UNIX-like
Unix-подобная (иногда сокр. *nix) операционная система — это система, которая образовалась под влиянием Unix. Термин включает свободные / открытые операционные системы, образованные от Unix компании Bell Labs или эмулирующие его возможности, коммерческие и запатентованные разработки, а также версии, основанные на исходном коде Unix. Нет стандарта, определяющего термин, и допустимы различные точки зрения о том, считать ли определённый продукт «Unix-подобным» или нет.
Содержание
Термин «Unix-подобный» и торговая марка UNIX
The Open Group обладает торговой маркой UNIX и ведёт дела Единой Спецификации UNIX, где слово «UNIX» используется как знак соответствия. Они не приветствуют употребление термина «Unix-подобный» и считают, что это злоупотребление их товарным знаком. Руководство группы требует использования больших букв в названии «UNIX» или в другом случае отдельно от остального текста, одобряют использование имени как прилагательного в сочетании с такими словами как «система», и не одобряют использование дефиса. Наиболее близкий термин, который они сочли бы корректным, был бы «UNIX system-like». [1]
С 2007 существует спор между Wayne R. Gray и Open Group, который обращает внимание на использование слова UNIX как торгового знака. [2] По словам Trademark Trial and Appeal, Board Grаусо своей компанией требует от Open Group предоставить ему документацию для их требований к торговой марке.
Также, в 2007 г. Open Group настояла на том, чтобы Немецкий Университет Касселя не использовал «UNIK» в качестве сокращения.
Категории
Денис Ритчи, один из создателей UNIX, выразил своё мнение, что Unix-подобные системы, такие как de facto UNIX-системами. Эрик Рэймонд предложил разделить Unix-подобные системы на 3 типа:
Развитие Unix-подобных систем
Unix системы начали появляться с поздних ’70х и ранних ’80х. Много проприетарных версий, таких как Idris (1978), Coherent (1983), и UniFlex (1985), ставили целью обеспечить нужды бизнеса функциональностью, доступной обученным пользователям UNIX.
Когда AT&T разрешила коммерческое лицензирование UNIX в 1980х, множество разработаных проприетарных систем основывались на этом, включая AIX, IRIX, Solaris, Tru64, Xenix. Это во многом вытесняло проприетарных клонов. Растущая несовместимость между системами привела к созданию стандартов взаимодействия, в том числе
Между тем, в 1983 году был запущен GNU Project, благодаря которому удалось сделать 4.4BSD, Linux, и Minix. Некоторые из них послужили основой для комерческих Unix систем, таких как BSD/OS и Mac OS X. Примечательно, Mac OS X 10.5, Leopard, сертифицирован Единой Спецификацией UNIX. [3]
Примеры
Большинство производителей открытых Unix систем и не добиваются сертификации UNIX для своего продукта даже в качестве компромата: стоимость сертификации считается недопустимой. Для таких систем обычно используют термин Freenix. Примером являются Linux, OpenSolaris, Plan 9, и FreeBSD, OpenBSD.
Есть множество запатентованных Unix-подобий, таких как AIX; IRIX; Mac OS X; QNX; SCO OpenServer; Solaris; Tru64 UNIX (based on OSF/1); Xenix; и
См. также
Примечания
Ссылки
Полезное
Смотреть что такое «UNIX-like» в других словарях:
Unix-like — Diagram of the relationships between the major Unix like systems A Unix like (sometimes referred to as UN*X or *nix) operating system is one that behaves in a manner similar to a Unix system, while not necessarily conforming to or being certified … Wikipedia
Unix-like — Para el sistema operativo desarrollado en los laboratorios Bell, véase Unix. Diagrama de las relaciones entre los mayores sistema operativo Unix like Un sistema operativo Unix like (a veces abreviado como UN*X o *nix para no tener problemas con l … Wikipedia Español
Unix-like — Генеалогическое дерево Unix подобных ОС Unix подобная (иногда сокр. *nix) операционная система это система, которая образовалась под влиянием Unix. Термин включает свободные / открытые операционные системы, образованные от Unix компании Bell… … Википедия
Unix-like — adjective a) Said of a computer operating system that behaves closely to Unix. Often used to describe systems which do not qualify for use of the Unix trademark. NetBSD provides its users with a free Unix like system. b) Said of a computer… … Wiktionary
Unix-like — ● ►en adj. ►UNIX Qui ressemble à Unix, qui en est un petit cousin. Linux et FreeBSD sont des exemples de tels système d exploitation … Dictionnaire d’informatique francophone
Unix — (officially trademarked as UNIX, sometimes also written as Unix with small caps) is a computer operating system originally developed in 1969 by a group of AT T employees at Bell Labs, including Ken Thompson, Dennis Ritchie, Douglas McIlroy, and… … Wikipedia
Unix security — Unix security: maintaining a secure environment on Unix and Unix like operating systems is dependent on design concepts of these operating systems, but vigilance through user and administrative techniques is important to maintain security… … Wikipedia
Unix — (registrado oficialmente como UNIX®) es un sistema operativo portable, multitarea y multiusuario; desarrollado, en principio, en 1969 por un grupo de empleados de los laboratorios Bell de AT T, entre los que figuran Ken Thompson, Dennis Ritchie y … Wikipedia Español
Unix time — Unix time, or POSIX time, is a system for describing points in time, defined as the number of seconds elapsed since midnight Coordinated Universal Time (UTC) of January 1 1970, not counting leap seconds. It is widely used not only on Unix like… … Wikipedia
Unix-подобная операционная система — Генеалогическое дерево UNIX подобных ОС UNIX подобная операционная система (иногда сокр. *nix) система, которая образовалась под влиянием UNIX. Термин включает свободные/открытые операционные системы, образованные от UNIX компании … Википедия
Чем Linux отличается от UNIX, и что такое UNIX-подобная ОС?
UNIX (не стоит путать с определением «UNIX-подобная операционная система») — семейство операционных систем (Mac OS X, GNU/Linux).
Первая система была разработана в 1969 в Bell Laboratories, бывшей американской корпорации.
UNIX-подобная ОС
UNIX-подобная ОС (иногда используют сокращение *nix) — система, образованная под влиянием UNIX.
Слово UNIX используется как знак соответствия и как торговая марка.
Консорциум The Open Group обладает торговой маркой «UNIX», но наиболее известен как сертифицирующий орган для торговой марки UNIX. Недавно на The Open Group был пролит свет в связи с публикацией спецификации «Single UNIX Specification», стандартов которым должна удовлетворять ОС чтобы гордо называться Unix.
Вот здесь вы можете взглянуть на генеалогическое древо UNIX-подобных операционных систем.
Linux
Linux — общее название UNIX-пободных операционных систем, которые разработаны в рамках проекта GNU (проект по разработке СПО). Linux работает на огромном множестве архитектур процессора, начиная от ARM заканчивая Intel x86.
Наиболее известными и распространенными дистрибутивами являются Arch Linux, CentOS, Debian. Также существует много «отечественных», российских дистрибутивов — ALT Linux, ASPLinux и другие.
Возникает довольно много споров об именовании GNU/Linux.
Сторонники «open source» используют термин «Linux», а сторонники «free software» — «GNU/Linux». Я предпочитаю первый вариант. Иногда для удобства представления термина GNU/Linux используют написания «GNU+Linux», «GNU-Linux», «GNU Linux».
В отличие от коммерческих систем (MS Windows, Mac OS X) Linux не имеет географического центра разработки и определенной организации, которая владела бы системой. Сама система и программы для нее — результат работы огромных сообществ, тысяч проектов. Присоединиться к проекту или создать свой может каждый!
Вывод
Подводя итог, я могу сказать, что отличия между Linux и UNIX очевидны. UNIX — намного более широкое понятие, фундамент для построения и сертификации всех UNIX-подобных систем, а Linux — частный случай UNIX.
UNIX-подобные системы содержат кучу костылей. Крах «философии UNIX»
В первой части статьи перечислю кучу костылей UNIX, и вообще разных недостатков. Во второй — про «философию UNIX». Статья написана наскоро, «полировать» дальше не хочу, скажите спасибо, что написал. Поэтому многие факты привожу без ссылок.
UPD от 2017-02-12: источники: раз и два. Имя отписавшегося maintainer’а ext4: Theodore Ts’o. Вот его слова:
If you really care about making sure something is on disk, you have to use fsync or fdatasync. If you are about the performance overhead of fsync(), fdatasync() is much less heavyweight, if you can arrange to make sure that the size of the file doesn’t change often. You can do that via a binary database, that is grown in chunks, and rarely truncated.
Two famous people, one from MIT and another from Berkeley (but working on Unix) once met to discuss operating system issues. The person from MIT was knowledgeable about ITS (the MIT AI Lab operating system) and had been reading the Unix sources. He was interested in how Unix solved the PC loser-ing problem. The PC loser-ing problem occurs when a user program invokes a system routine to perform a lengthy operation that might have significant state, such as IO buffers. If an interrupt occurs during the operation, the state of the user program must be saved. Because the invocation of the system routine is usually a single instruction, the PC of the user program does not adequately capture the state of the process. The system routine must either back out or press forward. The right thing is to back out and restore the user program PC to the instruction that invoked the system routine so that resumption of the user program after the interrupt, for example, re-enters the system routine. It is called «PC loser-ing» because the PC is being coerced into «loser mode,» where «loser» is the affectionate name for «user» at MIT.
The MIT guy did not see any code that handled this case and asked the New Jersey guy how the problem was handled. The New Jersey guy said that the Unix folks were aware of the problem, but the solution was for the system routine to always finish, but sometimes an error code would be returned that signaled that the system routine had failed to complete its action. A correct user program, then, had to check the error code to determine whether to simply try the system routine again. The MIT guy did not like this solution because it was not the right thing.
Если кратко и своими словами, то в начале разработки UNIX авторы UNIX решили попросту выдавать ошибку из ядра пользовательской программе, если пользовательская программа прервана по сигналу, и на этот сигнал повешен обработчик. Иными словами, если вы перехватили Ctrl-C (т. е. поставили на него обработчик) в своей программе, а юзер за терминалом нажал этот самый Ctrl-C, то ОС выполнит обработчик, а потом вместо простого продолжения того сисвызова, который выполнялся в момент Ctrl-C, просто прервёт его, вернув из ядра в пользовательскую программу EINTR. В результате программисту, пишущему эту программу придётся эту EINTR предусмотреть. А это усложняет этот userspace код. Ценой упрощения кода ядра. Да, нужно было сделать по-другому. Усложнить код ядра и упростить userspace код, который придётся писать всем программистам. Но тому человеку из Беркли из цитаты выше было пофигу. Он фактически сказал: «Да мне пофиг, что все будут страдать, главное, чтоб код ядра попроще был».
Дальше — больше. Позже в UNIX-системах всё же пофиксили упомянутую особенность, добавив так называемый SA_RESTART. То есть вместо того, чтобы просто всё пофиксить, они добавили специальный флаг. Так мало того, что они это сделали, этот SA_RESTART ещё и не всегда работает! В частности, в GNU/Linux select, poll, nanosleep и др. не продолжают свою работу после перехваченного прерывания даже в случае SA_RESTART!
Commands — Are These Real Words?
The basic AIX commands (and all UNIX system commands) are, for the most
part, very short, cryptic, two-letter command names. Imagine back years ago,
when computers had only very slow teletype keyboards and paper “displays.”
(Some of us aren’t imagining, we’re remembering!) Imagine also, people who
didn’t like typing long commands because there was such a long delay between
commands and the computer response. If there were any mistakes, the user had
to retype the whole thing (especially aggravating for folks that type with only
two fingers!).
Also, some UNIX commands came from university students and researchers who
weren’t bound by usability standards (no rules, merely peer pressure). They
could write a very useful, clever command and name it anything—their own initials,
for example (awk by Aho, Weinberger, and Kernighan), or an acronym
(yacc, Yet Another Compiler-Compiler).
A child which dies but is never waited for is not really gone in that it still consumes disk swap and system table space. This can make it impossible to create new processes. The bug can be noticed whenseveral & separators are given to the shell not followed by ancommand without an ampersand. Ordinarily things clean themselves upwhen an ordinary command is typed, but it is possible to get into asituation in which no commands are accepted, so no waits are done;the system is then hung.The fix, probably, is to have a new kind of fork which creates aprocess for which no wait is necessary (or possible); also to limit the number of active or inactive descendants allowed to a process.
Это цитата из очень раннего мануала UNIX. Уже тогда существование зомби-процессов признавалось багом. Но потом на этот баг попросту забили. Понятное дело, что гораздо позже эта проблема всё же была решена. Т. е. в современном GNU/Linux инструменты для убивания зомби-процессов всё же существуют. Но о них мало кто знает. Обычным kill’ом зомби не убиваются. Про существование зомби-процессов все говорят: «It’s for design».
Скажу лишь вот что. В C до сих пор не научились удобно работать со строками. Неудобство работы со строками постоянно приводит к разнообразным проблемам безопасности. И эту проблему до сих пор не решили! Вот относительно свежий документ от комитета C. В нём обсуждается весьма сомнительный способ решения проблемы со строками. И делается вывод, что этот способ плох. Год публикации: 2015. То есть даже к 2015-му году окончательного решения ещё нет!
И это не говоря об отсутствии простой, удобной и мультиплатформенной системы сборки (а не этого монстра autotools, который ещё и не поддерживает винду, и другого монстра cmake, который поддерживает винду, но всё равно монстр), стандартного менеджера пакетов, удобного как npm (js) или cargo (rust), нормальной portability library, с помощью которой можно было кроссплатформенно хотя бы прочитать содержимое папки и хотя бы даже главного сайта C, который был бы главной точкой входа для всех новичков и содержал бы в себе не только документацию, но и краткую инструкцию по установке инструментов C на любую платформу, по созданию простого проекта на C, а также содержал бы удобный поиск по пакетам C (которые должны быть размещены в стандартном репозитории) и, главное, был бы точкой сбора user community. Я даже зарегал домен c-language.org в надежде, что когда-нибудь я создам там такой сайт. Эх, мечты, мечты. (У меня ещё cpp-language.org заныкан, бугога :)) Но всего этого нет. Хоть это и есть у всех популярных языков, кроме C и C++. И даже у Haskell всё это есть. И у Rust.
У Rust, у этого выскочки, который, кстати говоря, метит в ту же нишу, что и C. Есть единый конфиг, который одновременно является конфигом проекта, конфигом сборки и конфигом для менеджера пакетов (собственно, cargo — это менеджер проектов и система сборки одновременно). Есть возможность указания в качестве зависимости для данного пакета другого пакета, размещённого где-то в *GIT*, в том числе указание в качестве зависимости напрямую программы на *GITHUB*. Генерация из коробки документации из сорцов, записанной в комментах на *MARKDOWN*. И пакетный менеджер, использующий для версий *SEMVER*. Итак, *GIT*, *GITHUB*, *MARKDOWN*, *SEMVER*, короче говоря *BUZZWORDS*, *BUZZWORDS* и ещё раз *HIPSTERS’ BUZZWORDS*. И всё сразу из коробки. Прямо вот заходишь на их главный сайт, и вот на тебе на блюдечке с голубой каёмочкой. И работает всё одинаково на всех платформах. Несмотря на то, что Rust — это вроде как язык системного программирования, а не какой-нибудь там javascript. Несмотря на то, что в Rust можно байты гонять. И арифметика указателей там есть. Так почему же у них, у этих выскочек-растовцев, эти хипстерские баззворды есть, а у нас, сишников, их нет? Обыдно.
Я помню, один знакомый спрашивает у меня, где посмотреть список пакетов для C/C++. Пришлось сказать ему, что такого единого места нет. Он: «Программисты на C/C++ должны страдать?» Мне нечего было ему ответить.
Ах да, забыл ещё одну вещь. Посмотрите, пожалуйста, на прототип функции signal в том виде, в котором он дан в стандарте C: ⟦ void (*signal(int sig, void (*func)(int)))(int); ⟧ и попытайтесь его понять.
Слишком много бекслешей, да? Ну, не нравится так, давайте чередовать одинарные и двойные кавычки, будет не так скучно:
А между прочим, если бы вместо shell’а был Lisp, и там функция ssh передавала бы на удалённую сторону не строку (вот она, повёрнутость UNIX на тексте!), а уже распарсенный AST (abstract syntax tree), то такого ада бекслешей не было бы:
«А? Что? Lisp? Что за Lisp?» Интересно, да? На, читайте. И другие статьи Грэма. На русском тоже можно найти.
UPD от 2017-02-12: источник.
«Философия UNIX». Есть мнение, что якобы UNIX прекрасна и идеальна. Что все её основные идеи («всё есть файл», «всё есть текст» и т. д.) прекрасны и составляют так называемую прекрасную «философию UNIX». Так вот, как вы уже начали догадываться, это не совсем так. Давайте разберём эту «философию UNIX» по пунктам. Сразу скажу: я не хочу сказать, что все пункты нужно отменить, просто я указываю на их неуниверсальность.
Я не закончил по поводу «всё есть текст». Стандартные утилиты выдают вывод в виде простого текста. Для каждой утилиты фактически нужен свой парсер. Часто приходится парсить вывод той или иной утилиты при помощи sed, grep, awk и т. д. У каждой утилиты свои опции для того, чтобы установить, какие именно столбцы нужно выдавать, по каким столбцам нужно сортировать вывод и т. д. Было бы лучше, если бы утилиты выдавали вывод в виде XML, JSON, некоего бинарного формата или ещё чего-нибудь. А для удобного вывода этой информации на экран и для дальнейшей работы с ней можно было бы пайпить результат в дополнительные утилиты, которые убирают те или иные столбцы, сортируют по тому или иному столбцу, выбирают нужные строки и т. д. И либо выводят результат в виде красивой таблички на экран, либо передают его куда-то дальше. И всё это универсальным способом, не зависящим от исходной утилиты, которая сгенерировала вывод. И без необходимости парсить что-либо регексами. Да, UNIX shell плохо работает с JSON и XML. Но ведь у UNIX shell полно других недостатков. Нужно выкинуть его вовсе и заменить на некий другой язык, который помимо всего прочего может удобно работать со всякими JSON.
Короче говоря, вместо UNIX shell нужно использовать любой другой скриптовый язык программирования. Который подходит не только для скриптинга, но и для реального программирования. Который не запускает новый процесс каждый раз, когда нужно «touch’нуть» файл. Возможно, понадобится «доложить» в этот скриптовый язык средства для простого выполнения вещей, которые есть в shell, скажем, для создания пайпов.
Но потом, через много лет, этот же Пайк сделал ещё две презентации, в которых, как я считаю, отменил свою философию обратно. Поняли, фанатики, да? Ваш кумир отказался от своей же философии. Можете расходиться по домам. В первой презентации «Systems Software Research is Irrelevant» Пайк сетует на то, что никто больше не пишет новых ОС. А даже если и пишут, то просто ещё один UNIX (который подразумевается в этой презентации уже чем-то неинтересным): «New operating systems today tend to be just ways of reimplementing Unix. If they have a novel architecture — and some do — the first thing to build is the Unix emulation layer. How can operating systems research be relevant when the resulting operating systems are all indistinguishable?»
Вторую презентацию Пайк прямо называет: «The Good, the Bad, and the Ugly: The Unix Legacy». Пайк говорит, что простой текст не универсален, он хорош, но работает не всегда: «What makes the system good at what it’s good at is also what makes it bad at what it’s bad at. Its strengths are also its weaknesses. A simple example: flat text files. Amazing expressive power, huge convenience, but serious problems in pushing past a prototype level of performance or packaging. Compare the famous spell pipeline with an interactive spell-checker». Далее: «C hasn’t changed much since the 1970s… And — let’s face it — it’s ugly». Дальше Пайк признаёт ограниченность пайпов, соединяющих простые утилиты, ограниченность регексов.
UNIX был гениальным на момент своего появления. Особенно, если учесть, какие инструменты были в распоряжении у авторов UNIX. У них не было уже готового UNIX, чтобы на нём можно было разрабатывать UNIX. У них не было IDE. И программировали они вообще на ассемблере изначально. У них, видимо, был только ассемблер и текстовый редактор.
Люди, стоящие у истоков UNIX, в определённый момент начали писать новую ОС: Plan 9. В том числе упомянутые Томпсон, Ритчи и Пайк. Учитывая многие ошибки UNIX. Но и Plan 9 никто не возводит в абсолют. В «Systems Software Research is Irrelevant» Пайк упоминает Plan 9, но несмотря на это всё равно призывает писать новые ОС.
James Hague, ветеран программирования (занимается программированием с восьмидесятых) пишет: «What I was trying to get across is that if you romanticize Unix, if you view it as a thing of perfection, then you lose your ability to imagine better alternatives and become blind to potentially dramatic shifts in thinking» (ссылка). Прочитайте эту статью и его же статью «Free Your Technical Aesthetic from the 1970s», на которую он ссылается. (Вообще, если вам понравилась моя статья, то и его блог тоже, наверное, понравится, погуляйте там по ссылкам).
Итак, я не хочу сказать, что UNIX — плохая система. Просто обращаю ваше внимание на то, что у неё есть полно недостатков, как и у других систем. И «философию UNIX» я не отменяю, просто обращаю внимание, что она не абсолют. Мой текст обращён скорее к фанатикам UNIX и GNU/Linux. Провокационный тон просто чтобы привлечь ваше внимание.
UPD от 2017-02-14: комментаторы указывают, что сравнивать UNIX shell с PHP некорректно. Конечно, некорректно! Потому что UNIX shell не претендует на то, чтобы быть полноценным языком программирования, он предназначен для скриптинга системы. Вот только я в одно время этого не знал. И вдобавок считал UNIX shell прекрасным. Вот для людей в таком же положении я всё это и говорю. Ещё как минимум один комментатор говорит, что сравнивать UNIX shell нужно с cmd. Я бы сказал, что сравнивать надо с Windows Powershell. Последний, как я уже говорил, в чём-то превосходит UNIX shell.
UPD от 2017-02-14: мне понравился вот этот коммент от sshikov:
Но я скажу за автора — к сожалению, прямо сегодня можно найти сколько угодно восторженных статей типа «А вот есть такая замечательная фигня, как bash, щас я вам про нее расскажу. » — где unix way откровенно перехваливается неофитами. Это не помешает иногда компенсировать долей скепсиса.
Да, в этом-то и всё дело! Достало, что хвалят UNIX way. Что считают UNIX красивым и ещё и других учат. А использовать-то UNIX можно.
UPD от 2017-02-14: как минимум один комментатор сказал, что пересел с Windows на UNIX-подобные ОС и счастилив. Что поначалу он плевался от UNIX, но потом решил, что программировать под UNIX гораздо проще, чем под Windows. Так вот, я тоже сперва использовал и программировал на Windows. Потом пересел на UNIX. И сперва, конечно, было очень непривычно. Потом прочувствовал «философию UNIX», ощутил всю её мощь. Программировать под UNIX стало легко. Но позже пришло ещё одно озарение. Что UNIX неидеальна, а «философия UNIX» неабсолютна. Что программирование на «голом UNIX», с использованием C и Shell сильно уступает, скажем, Web-программированию. И далеко не только потому, что в Web-программировании используются языки, в которых трудно выстрелить себе в ногу, в отличие от C (тут языку C предъявить нечего, он намеренно является низкоуровневым). Но ещё и из-за всех этих quirks мейкфайлов, шела, языка C. Отсутствия удобных инструментов, систем сборки, менеджеров пакетов. Всё это, в принципе, можно было бы исправить. Вот я написал эту статью, чтобы открыть на это глаза тем, кто об этом не знает. У Windows тоже полно недостатков (я разве где-то говорил, что Windows лучше UNIX?). Но в чём-то Windows лучше UNIX (как минимум в некоторых особенностях Powershell). Сейчас я продолжаю использовать и программировать под UNIX. UNIX меня устраивает, мне достаточно удобно, хотя теперь уже я вижу многие его недостатки. Я не призываю бросать UNIX. Используйте UNIX дальше, просто не считайте его идеалом.
UPD от 2017-02-16: многие комментаторы рассказывают, как же полезны и удобны UNIX системы. Что они есть уже десятки лет, на них работает весь интернет. Что они стабильны и прекрасно справляются с возложенными на них задачами. И даже удалённо переустановить GNU/Linux можно 🙂 А я и не спорю. Я не призываю отказываться от UNIX. Я просто хочу, чтобы вы видели недостатки UNIX. UNIX работает, используйте его. Процитирую James Hague, на которого я уже ссылался:
Enough time has passed since the silly days of crazed Linux advocacy that I’m comfortable pointing out the three reasons Unix makes sense:
1. It works.
2. It’s reliable.
3. It stays constant.
But don’t—do not—ever, make the mistake of those benefits being a reason to use Unix as a basis for your technical or design aesthetic. Yes, there are some textbook cases where pipelining commands together is impressive, but that’s a minor point. Yes, having a small tool for a specific job sometimes works, but it just as often doesn’t.
Одно время я тоже, как и многие из вас, повёлся на эту «философию UNIX». Думал, что она прекрасна. А потом понял, что это не так. И вот этим своим открытием я хочу с вами поделиться. Мои мысли не новы. Они уже есть в приведённых мною ссылках. Я просто хочу сообщить эти мысли аудитории Хабра. Мой пост написан наскоро, ночью. Читайте скорее не его, а ссылки, которые я привожу. В первую очередь две презентации Пайка, в которых он «отменяет философию UNIX» и два поста от James Hague. Мой пост фактически написан, чтобы привлечь внимание к этим ссылкам.
Как минимум один из комментаторов сказал, что многие из названных мной «недостатков» UNIX недостатками не являются. Например, слишком короткие имена команд. Ну да. Это не недостаток. Но это пример необдуманного решения. Сиюминутного решения, принятого под влиянием обстоятельств, имевших важность тогда. Как и с тем примером с /usr или make. Я показываю, что UNIX была непродумана. Да и вообще, вглядитесь в историю UNIX! Сотрудникам Bell Labs не понравилась сложность проекта Multics. Они сказали: «Да ну этот Multics, давайте по-быстрому напишем свою ОС, запростецкую». И написали. Понимаете? ОС получилась довольно хорошей. Но не идеальной. UNIX — это хак. Успешный хак, который выполнил свою миссию и продолжает её выполнять.
И я не говорю, что философия UNIX (даже в тех местах, которые мне не нравятся) всегда не верна. Часто конвееры и shell-скрипты — это именно то, что нужно. Но не всегда.
Один комментатор приводит следующие принципы UNIX:
Write programs that do one thing and do it well.
Write programs to work together.
Write programs to handle text streams, because that is a universal interface.
С первыми двумя я согласен при условии, что они понимаются в отрыве от UNIX shell и конвееров. Их можно перенести даже на новомодные микросервисы, общающиеся с помощью REST. С третьим я не согласен (как я понимаю, подразумевается именно придумывание простого кастомного текстового формата для каждого случая вместо единого формата наподобие JSON). Часто текст — это именно то, что нужно. Но пихать его везде как universal interface глупо. На эту роль скорее претендует JSON или XML. Или, может, какой-нибудь формат для структурированных данных, который ещё не изобрели.
iTWire: Systemd seems to depart to a large extent from the original idea of simplicity that was a hallmark of UNIX systems. Would you agree? And is this a good or a bad thing?
Linus Torvalds: So I think many of the «original ideals» of UNIX are these days more of a mindset issue than necessarily reflecting reality of the situation.
There’s still value in understanding the traditional UNIX «do one thing and do it well» model where many workflows can be done as a pipeline of simple tools each adding their own value, but let’s face it, it’s not how complex systems really work, and it’s not how major applications have been working or been designed for a long time. It’s a useful simplification, and it’s still true at *some* level, but I think it’s also clear that it doesn’t really describe most of reality.
It might describe some particular case, though, and I do think it’s a useful teaching tool. People obviously still do those traditional pipelines of processes and file descriptors that UNIX is perhaps associated with, but there’s a *lot* of cases where you have big complex unified systems.
And systemd is in no way the piece that breaks with old UNIX legacy. Graphical applications seldom worked that way (there are certainly _echoes_ of it in things like «LyX», but I think it’s the exception rather than the rule), and then there’s obviously the traditional counter-example of GNU emacs, where it really was not about the «simple UNIX model», but a whole new big infrastructure thing. Like systemd.
Now, I’m still old-fashioned enough that I like my log-files in text, not binary, so I think sometimes systemd hasn’t necessarily had the best of taste, but hey, details…
Вернёмся к моему примеру с touch’ем. «Как touch’нуть все файлы в папке foo (и во вложенных)?» Допустим, что нужно не touch’нуть их, а grep’нуть из них все строки со словом bar и положить результат туда же. Т. е. для каждого файла file сделать ⟦ grep bar file > tmp; mv tmp file ⟧. Как быть? Если делать решение с циклом, то мы упираемся в те пять хаков, которые нужно сделать, чтобы не выстрелить себе в ногу. Результат будет таким, со всеми пятью хаками:
Нет, неправильно! Это не будет работать, если имя содержит одинарную кавычку. Правильный вариант таков:
Всё это сделать можно, если надо, но сам факт того, что нужно постоянно держать это в голове и обходить грабли, говорит о том, что здесь что-то не то.
Теперь по поводу другого примера. Где нужно удалить все файлы определённого размера. Да, всё это можно сделать одним вызовом find. Там есть опции и для проверки размера, и для удаления. Да. Вот только я вижу здесь хак. Хак в том, что find имеет фактически в себе целый sublanguage, подъязык. Язык вот этих вот опций. Почитайте хорошенько ман find’а. Вы узнаете, что, оказывается, порядок опций find’а имеет значение. Что каждая опция имеет truth value, т. е. булевское значение. Что можно по-хитрому комбинировать эти опции. Что в зависимости от порядка опции, от их truth value find принимает решение, в какой момент нужно остановить обработку опций для данного файла и нужно ли descend в данный каталог (т. е. нужно ли искать внутри этого каталога).
Что тут плохого? Плохо то, что find имеет свой sublanguage. Что это ещё один язык в дополнение к shell. (А sed, кстати говоря — это ещё один язык, а awk — это ещё один язык и так далее, авторы UNIX’а любили создавать по языку на каждый чих.) Нужно было вместо этого сделать так, чтобы find только умел искать файлы. А всю остальную функциональность нужно вынести из него. Проверки на размер файла должны быть снаружи. А если find’у нужно принять решение, нужно ли descend в данный каталог, то он должен вызывать внешний callback. Да, в UNIX shell так вряд ли получится. На то он и UNIX shell.
echo вроде как предназначен, чтобы печатать на экран строки. Вот только использовать его для этой цели, если строчка чуть сложнее, чем «Hello, world!», нельзя.
И даже для этой цели echo использовать можно не всегда. Недавно прочитал, что в интерактивном старом bash нельзя писать ⟦ echo «Hello, world!» ⟧. Вот несколько абзацев текста, объясняющих суть проблемы и пути обхода. В новых bash такого нет, на моей системе не воспроизводится.