Сегодня мы поговорим о том, зачем учить операционную систему GNU/Linux, о преимуществах работы в командной строке и о том, как это все связано с философией Unix.
Это не перевод, а мой авторский текст, появившийся в результате долгих чтений комментариев на хабре и других всевозможных интернет ресурсов. Я не ставил целью задеть чьи-то чувства или оскорбить, а любые совпадения случайны. Прошу отнестись с пониманием.
В мире десктопных операционных систем, вроде той же Windows, понятие программы сильно специализировано. Если вам нужна программа для просмотра видео, вы идете и скачиваете конкретную программу, которая была специально написана для этой цели. Если хотите слушать музыку, для вас также существует целый спектр программ, которые решают эту задачу. В общем, для любой типовой задачи уже написаны и распространяются под разного рода условиями огромное количество программ под разные цели.
Как правило, эти программы весят довольно много, предоставляют дополнительные интеграции и функции, которые вам могут быть вообще не нужны. Порой доходит до абсурда и приходится скачивать и устанавливать гигабайтные пакеты только лишь для того, чтобы иметь возможность редактировать текст. К примеру, для того, чтобы время от времени показывать вам рекламу, разработчики интегрируют в программы код полноценных браузеров, вроде Chromе. Или, если необходимо проигрывать видеоролики внутри приложения, вместо того, чтобы интегрировать свой код со стандартными программами, уже установленными в системе, встраивают внутрь своего продукта полноценные видео-проигрыватели с кучей лишнего кода, которые будут без причины тормозить вашу систему и сжирать драгоценную память.
Проблема с таким подходом начинает вырисовываться тогда, когда вам необходимо решить довольно специфичную задачу, и вы не можете найти уже готовую программу, которая реализует нужную логику.
“Как я запущу Фотошоп на этом вашем Линуксе? Мне же нужно работать, а не заниматься ерундой.”
Поймите меня правильно, такой подход весьма удачно работает, когда речь заходит о профессиональных пакетах: инженерных, творческих, например, AutoCAD, MATLAB, Adobe Photoshop, Blender и многих других. Эти большие и довольно раздутые программные решения позволяют миллионам людей по всему миру осваивать полезные профессии и создавать потрясающие продукты, перенимая лучшие практики и стандартизируя рабочий процесс.
В другой крайности нам пришлось бы осваивать программирование только лишь для того, чтобы каждый раз реализовывать необходимый функционал. А это превратилось бы в безумную трату времени для огромного количества людей, заставляя их погружаться в не профильные для них направления.
Между этими двумя крайностями существует некий промежуточный уровень, который позволяет решать нестандартные задачи, программ для решения которых явным образом не предусматривается. Но тем не менее использовать для этого некие относительно крупные готовые строительные блоки. Мы уже избавлены от необходимости писать программный код, но все еще имеем достаточно гибкую систему удобных утилит, при объединении которых в цепочки можем создавать необходимую нам логику.
Эти строительные блоки являются простыми программами, утилитами, которые сами по себе могут быть довольно бесполезными, но изначально спроектированными для использования в связке с другими. В операционной системе GNU/Linux около сотни таких базовых утилит, доступных из коробки в любом типовом дистрибутиве. Еще тысячи, как правило, находятся в стандартных репозиториях и могут быть установлены при желании одной командой. Многие из этих утилит можно запускать в разных режимах, используя стандартизированную систему флагов. Благодаря этой гибкости мы имеем по-настоящему безграничное поле для экспериментов, где ваши возможности может ограничить только ваша фантазия.
А склейкой для этих утилит является простой текст, который они принимают на стандартный ввод, модифицируют в рамках своей работы и передают дальше следующим утилитам. Получается своего рода конвеер данных. Простой, без проблем читаемый людьми текст и является тем универсальным интерфейсом передачи информации.
Если бы систему Unix создавали сегодня, я полагаю, такой подход просто не одобрили бы. К примеру, ввели бы систему объектов, как это сделано Майкрософтом в PowerShell, либо навязали бы использовать для обмена данными некий сериализованный формат данных, вроде JSON или YAML. Несомненно, использовали бы шифрование, сертификаты для подписывания пакетов данных, протокол был бы бинарным и не читаемым без использования специальных утилит. А работа с файловой системой и с ядром из пространства пользователя напоминала бы работу с базой данных.
Однако, на наше счастье, все эти традиции к переусложнению появились гораздо позже, и отцы-основатели системы Unix этим не слишком грешили. И, конечно, поступили мудро.
“Я вообще Python учу, за ним будущее, а этот ваш баш - это какая-то устаревшая жесть”
Может такие создаваемые на коленке конвеерные цепочки и не будут претендовать на полноценное и долговременное решение, которое будет красиво оформленным и оптимально реализованым, но это все компенсируется простотой использования, возможностью быстро набросать черновой вариант и поиграться с данными одними только стандартными средствами операционной системы. А уже найдя правильный подход, можно и скрипт на Питоне написать, коль будет у вас такое желание.
Особенно бесценным этот опыт будет для инженеров, которые часто вынуждены работать в очень стеснённых условиях, и поэтому им просто необходимо использовать любые возможности для автоматизации и упрощения своей работы.
“Линукс нужно допиливать напильником, чтобы выглядел достойно. Вот мои конфиги.”
Если вы программист, то, как правило, ваш мир ограничен только одним вашим персональным компьютером, куда вы можете устанавливать любые программы для повышения эффективности своей работы. Поэтому на вашей машине наверняка будут установлены десятки дополнительных утилит, а стандартный Bash будет заменен на продвинутый Zsh. Конфигурационные файлы многих программ будут подстроены под себя, и множество “алиасов” под часто запускаемые сценарии создадут тот комфортный язык общения с компьютером, который будете понимать только вы. Вы даже можете использовать какой-либо экзотический графический интерфейс, вроде тайлового менеджера i3, со своими настройками и горячими клавишами.
Доведя этот процесс до предела, ваше виртуальное рабочее место по навороченности и технологичности может напоминать кабину космического аппарата из научно-фантастического фильма.
“И это правильно, я меньше чем с тремя экранами не работаю. И только с механической клавиатурой.”
Однако, что же делать тем специалистам, которые строят и администрируют комплексные системы, состоящие из тысяч серверов? У них просто нет возможности установить на все машины удобные утилиты и подстроить все под себя. Зачастую нет даже возможности физически установить что-либо, так как выход в интернет на продакшен-сервере может быть и вовсе заблокирован. А часть виртуальных машин будут настолько древними или настолько важными, что вы и дышать на них будете бояться, чтобы случайно что-то не сломать.
Приходится довольствоваться тем, что есть под рукой. И тут умение работать в стандартных окружениях, в командной строке, умноженное на огромный потенциал, который заложен в саму операционную систему, будет являтся моментом истины, отличающим хорошего специалиста от посредственного. Вам ничем не помогут знания о новомодных хайповых тенденциях, современных поделках, расширяющих функционал стандартных утилит, и якобы делающие их более удобными. Все эти знания будут полностью бесполезны в реальной работе и будут только отвлекать. Также будут полностью бесполезны знания о графических столах и чем они отличаются друг от друга.
Я еще раз повторяю, интерфейс графического стола или мобильного телефона не хуже и не лучше интерфейса командной строки. Нужно просто понимать сильные и слабые стороны обоих подходов и использовать каждый из них там, где он более уместен.
“А я работаю с Remote Desktop к моей рабочей машине и пишу код. Все шустро работает.”
Представте, что вы работаете из дома, подключаясь к своему офисному компьютеру через зашифрованный VPN-шлюз. Компания решила, что напрямую подключаться к продакшен-системе вы не можете, а можете только из подсети вашего офисного компьютера. Поэтому мы подключаемся к этому компьютеру, чтобы затем уже с него переподключиться к удаленному серверу в интернете. Однако этот сервер - это всего лишь контролирующий сервер, который еще иногда называется Bastion Host, у которого один сетевой интерфейс подключен к всемирной сети, а второй к внутренней защищенной сети, где расположены все самые важные сервера. Поэтому уже через него мы должны переподключиться непосредственно к тому серверу, с которым изначально хотели работать.
Согласитесь, что графический интерфейс просто не сможет адекватно работать в таких условиях. Передавать изображение на такие растояния, через такое количество промежуточных узлов можно, но это будет крайне не удобно. Получаемая картинка не будет обновляться в реальном времени, создавая в лучшем случае постоянные задержки, в худшем - постоянные разрывы соединения. Да и задержка порой такая, что работать просто не возможно.
Однако, даже если между вашим компьютером и конечным сервером пропускная способность сети всего несколько килобайт в секунду, а такое бывает довольно часто, подключаться к виртуальному терминалу по SSH все еще может быть достаточно комфортно. Используя интерфейс командной строки, вы сможете сделать любое изменение, проверить и устранить любую неисправность, протестировать приложение, проверить систему на безопасность, проверить логи системы и многое другое. Все, что от вас требуется, это знать, какие команды запускать и в каком порядке. А система отзывчиво сделает все, о чем вы ее просите, без лишних вопросов. Так, словно вы работаете не на удаленном сервере, расположенном на другой стороне Земли, а на своей домашней станции. Это происходит потому, что передать короткую текстовую команду во много раз проще, чем непрерывный видео поток.
"Все же как-то странно в 21-м веке пялиться в черный экран, графический интерфейс лучше”
К тому же, в отличии от графических интерфейсов, при работе с интерфейсом командной строки информация, с которой вы работаете, всегда однозначна и сконцентрированна. Вы всегда видите текст ровно там, где ожидаете его увидеть, а не размазанную палитру цветов, между которыми где-то должны скрываться разбросанные по всему экрану буквы. Понятно, что, приложив некоторые усилия, можно создавать хорошо продуманные и качественные графические интерфейсы, но до стандартизации там очень далеко. Каждая программа часто стремится предоставлять свой неповторимый пользовательский опыт, который и выделяет ее среди конкурентов. Но согласовываться эти визуальные компоненты в общей гамме приложений, запущенных у вас на компьютере, совсем не обязаны.
Можно сколько угодно кричать о старомодности, об устаревании и о том, что работа в консоли не удобна, но факт остается в том, что в мире IT работа в терминале является главным и часто единственным возможным способом работы со сложными информационными системами.
И, конечно, никто не запрещает вам работать с интерфейсом командной строки и при этом использовать тот же самый графический интерфейс, открывая в множестве вкладок виртуального терминала необходимые сессии, и в то же время держать отрытыми в браузере десятки страниц с нужной документацией.
“Мне достаточно Windows. Много лет с ним работаю и меня все устраивает. А для игр у меня PlayStation”
Понятно, что если вы используете компьютер для развлечений, то, скорее всего, вы используете операционную систему, вроде Microsoft Windows или MacOS, и вполне довольны этим. Если ваша профессия просто не оставляет иного выбора, вы будете использовать то программное обеспечение, что используют ваши коллеги и никаких проблем при этом не испытывать.
Однако, давайте посмотрим на это шире. Что, если вы используете свой компьютер для задач, для которых не существует единого и общепринятого инструментария? Представьте себе сотни серверов, разбросанных по разным точкам земного шара, десятки сложных систем, вроде Kubernetes, реляционных и документо-ориентированных баз данных, брокеров сообщений, различной вспомогательной инфраструктуры. В сложных микросервисных архитектурах, состоящих из сотен взаимодействующих друг с другом сервисов, ежедневно приходится иметь дело с множеством абстракций и условностей, которые и запомнить-то не просто, не то, что с ними работать. Программисты, системные администраторы, DevOps инженеры, специалисты по сетевой безопасности, аналитики данных - все эти профессии требуют разных инструментов, разных навыков и подходов. Да и среди одних и тех же программистов есть те, кто разрабатывают прикладное программное обеспечение, другие разрабатывают сайты или мобильные приложения. Есть те, кто больше специализируется на фронтенде или на бекенде. Но не нужно забывать и о тех, кто работает близко к железу и пишет драйвера устройств или разрабатывает встроенные системы. И это только некоторые из возможных направлений.
Вы просто не напишете графических приложений для всего многообразия задач, которые возникают ежедневно перед людьми, создающими и эксплуатирующими такие системы. Напротив, эти потребности часто естественным образом покрываются взаимодействием простых утилит, которые входят в базовую сборку любого дистрибутива GNU/Linux.
Да, возможно, не так красиво, не так презентативно, но, с точки зрения инженера, командная строка полностью покрывает потребности и позволяет не отвлекаться и сосредоточиться непосредственно на самой задаче.
Поэтому сама постановка вопроса “что лучше” лишена смысла. Для решения тех задач, которые ставит перед нами профессия в ранее перечисленных специальностях, командная строка - это лучший возможный интерфейс, который за счет своей простоты может использоваться в любых приложениях даже для решения тех задач, для которых не создавался.
“Да кто вообще использует эту операционную систему. Мак лучше”
Обыватели склонны преувеличивать значение операционных систем от Майкрософт и Apple, считая их за некий общемировой стандарт, поскольку в ежедневной деятельности у них нет возможности убедиться в том, что может быть как-то иначе. Да, сегодня операционные системы на базе ядра Linux не могут занять достойное место в ряду десктопных систем, хотя фактически ничем им не уступают. Однако, давайте будем честны и не забудем упомянуть, что по какой-то причине те же корпорации полностью проиграли на рынке серверных решений. И сегодня операционная система GNU/Linux и отчасти системы семейства BSD полностью доминируют в этом сегменте.
Они используются сегодня не только в классических серверах, расположенных в датацентрах по всему миру, но и в мобильных телефонах, маршрутизатах, суперкомпьютерах, всевозможной бытовой технике, автомобилях, видеокамерах и многих других приложениях. И я не удивлюсь, если даже в космических аппаратах и лунных модулях, там, где нет особых требований к железу, все работает примерно так же, как у вас на домашнем компьютере.
Все те социальные сети и мессенджеры, а также многочисленные интернет-ресурсы, без которых мы не мыслим нашу жизнь сегодня, с подавляющей долей вероятности используют Unix-подобные операционные системы для своего функционирования. И во всех этих и многих других приложениях ваши знания будут актуальны и не устареют ещё очень долгое время.
“Стойте, а как же .Net? Это же очень популярная технология”
И да, я знаю, что .Net и некоторые другие решения активно используются на бекенде многих уважаемых компаний. Однако, это скорее отклонение от нормы, и мировые тенденции скорее говорят об обратном. Доминирование таких платформ, как Java, они пошатнуть не в состоянии, а та же Java прекрасно себя чувствует на серверах с GNU/Linux и OpenJDK на борту. Даже если сами разработчики используют в своей работе систему от Майкрософт и Linux в глаза не видели.
Не имеет значения, какой фреймворк и какой язык программирования современнее, быстрее или удачнее с точки зрения архитектурных решений, если большие корпорации все равно отдают предочтение Java по бизнес причинам.
Сам факт существования таких систем, как Mono, делающей разработку на .Net кросплатформенной и WSL, позволяющей использовать Linux внутри Windows, говорят о том, как шатко сегодня положение Windows в этом сегменте рынка.
“Я вообще писатель и зачем мне может потребоваться погружаться во все это?”
Даже если вы не инженер и непосредственно с вашей деятельностью это перекликается слабо, у операционной системы GNU/Linux в запасе много интересных и полезных инструментов, которые имеют не только специфичное “айтишное” применение, но и являются частью всемирного наследия. К таковым, например, можно отнести систему контроля версий Git и систему компьютерной верстки текста TeX.
Я еще раз хочу подчеркнуть, что нет необходимости воспринимать так называемую философию Unix как истину в последней инстанции. Это всего лишь абстракция, идея, которая в некоторых случаях может быть удобна, в других не достаточна. Однако тот факт, что она вот уже столько лет активно используется и за это время никаких реальных альтернатив придумано не было, заставляет признать, что испытание временем она выдержала и никуда уходить не собирается.
“Линукс полностью устарел, и все нужно переписывать. Там вообще весь код из семидесятых, максимум девяностых.”
Однако, среди всего многообразия мнений переодически встречается и такое, что весь этот подход устарел и его необходимо полностью пересмотреть. Все эти утилиты операционной системы, вроде текстового редактора vim, командной оболочки bash, системы инициализации systemd и многих других (нужное подчеркнуть) используются только потому, что все еще по старинке предустановлены в большинстве дистрибутивов и только поэтому все еще популярны. Если бы не этот сдерживающий прогресс фактор, не оставляющий шансов молодому поколению в их стремлении “сделать мир лучше”, мы бы уже давно пользовались удобными инструментами, а не были бы заложниками этого исторического хлама.
К сожалению, такой подход часто можно встретить в различных обсуждениях, а значит подобное убеждение плотно засело в головах у множества людей. Нет ничего проще, чем выдрать из исторического контекста некоторое утверждение и возвести его в абсолют. Что же, позвольте продолжить такую линию рассуждений и поговорить о том, что и само ядро Linux полностью устарело хотя бы потому, что является монолитным. Давайте перепишем и его и перейдем на более “прогрессивную” микроядерную архитектуру, как это сделано, например, в операционной системе Minix.
Не забудем также, что и архитектура процессоров, которые мы сегодня используем, полностью устарела, так как тянет за собой десятилетия обратной совместимости с уже не существующими технологиями. Давайте срочно создавать новую архитектуру, которая будет лишена всего этого наследия, и использовать исключительно ее. Затем подготовим под эту технологическую базу миллионы специалистов, чтобы быть способными внедрить ее на всех производствах и серверных мощностях по всему миру. Да и заводы не забудем полностью перестроить под новый технологический процесс, так как нам понадобится в кратчайший срок заменить весь мировой серверный парк.
На все это потребуется в лучшем случае сотни миллиардов долларов и годы усилий на международном уровне. Но что это по сравнению с мнением некоторых экспертов, правда?
Конечно, необходимо разрабатывать новые операционные системы, языки программирования, инструменты и библиотеки. Прогресс ни в коем случае не стоит останавливать. Новые и прогрессивные тенденции, сколь слабыми они ни были бы в момент своего появления, имеют все шансы окрепнуть и заменить собой устаревшие подходы и практики. Однако, было бы очень странным ожидать, что то, что используется сейчас, полностью исчезнет из истории без всякого следа. Скорее всего, элементы идей и программного кода, который мы используем сегодня, останутся для будущих поколений множественными рудиментами и анахронизмами, с которыми они будут вынуждены сосуществовать. В том числе с теми технологиями, которые мы на данном этапе считаем передовыми и наиболее удачными, но которые, несомненно, станут устаревшими в новых исторических реалиях.
Поэтому, пока кто-то ждёт и страдает, мы будем изучать и использовать то, что есть и понимать, что за всеми этими технологиями стоят десятилетия тяжелого эволюционного процесса, состоящего из труда и усилий миллионов людей. Среди них есть как хорошие, так и плохие специалисты, принимающие хорошие и плохие решения. Эти люди могут работать в стеснённых условиях согласно общему корпоративному плану, над которым не властны, или вольных художников, работающих в свое свободное время над тем, что им действительно интересно.
Поэтому давайте не забывать о принципе историзма и строить наши карьеры и жизни, исходя из этого понимания. А также не забывать о том, что мы, если и можем чего-то добиться, то это только потому, что, вне всякого сомнения, стоим на плечах гигантов.
А на сегодня это все.
