Unix на работе. Часть вторая, программная

В этой части раскрываю тему программного обеспечения «которого нет» под ОС, которые «не нужны». Что есть, чего нет, где брать и что со всем этим делать.

Первая часть тут.

Минутка истории

История пользовательского программного обеспечения сложна и противоречива, на всем ее протяжении происходили стычки абсолютно разных идеологий, потребностей самих пользователей и технических возможностей индустрии.

Несмотря на то, что сами персональные компьютеры появились и продавались как коммерческий продукт, отношение к ценности программного обеспечения было и остается.. разным.

Одни считали, что программное обеспечение это отдельный коммерческий продукт, который должен продаваться в магазинах на соседней полке с компьютерами.

Другие — что каждый приличный джентельмен должен уметь собрать себе дробовик систему своими силами из исходников, включая компилятор и прикладное ПО. А исходники должны распространяться свободно и бесплатно:

«компилятор узнает своих» — не смог собрать, значит работа с компьютерами не твое.

Третьи — что исходный код хоть и должен оставаться открытым, но со сборкой и установкой пользователям все же стоит помочь, беря за услуги плату звонкой монетой.

Из идей первой группы со временем вырастут Microsoft и Apple, вторые до сих пор хиппуют в солнечной Калифорнии, ну а третьи превратились в современные RedHat и Suse.

Но все это — «дела давно минувших дней», ныне же все направления мысли о судьбах программного обеспечения сильно перемешались:

крупные корпорации научились извлекать выгоду из открытого ПО, поэтому свои странички на Github ныне есть не только у «монстров» вроде Microsoft или Apple, но даже у корпораций сильно поменьше, которые еще 10–15 лет назад запросто подавали в суд по поводу и без нарушения лицензионных прав.

Культура Unix

В отличие от Mac и Windows, где каждая более‑менее сложная программа является автономным продуктом, со своей ценой, рекламой и раскруткой — в мире юниксов программы являются в первую очередь утилитами.

Второй по важности ценностью у которых (сразу после функционала) является возможность комбинировать их между собой и собирать в цепочки обработки:

find . -type f  -exec grep -i "test" {} + | wc -l

На примере выше на самом деле используются три разные программы: find, grep и wc, соединенные в такую цепочку обработки.

Данная комбинация сначала ищет слово «test» без учета регистра во всех файлах в текущем каталоге, затем считает общее количество этого слова вхождений и отображает его.

Это и есть тот самый «Unix way»:

множество мелких утилит, каждая из которых делает что-то одно но хорошо, которые комбинируются в цепочку для достижения конечного результата.

Помимо очевидных достоинств, подобный подход порождает еще и неочевидные недостатки, главный из которых — неопределенность:

ничего готового нет, но с помощью bash, grep и awk можно организовать хоть полет на Луну.

Примерно в таком стиле любят отвечать опытные юниксоиды неопытным менеджерам, чем конечно вводят последних в определенный диссонанс.

Опытных юниксоидов можно понять и простить, наблюдая по сотому разу выполнение типовых задач автоматизации (обработка текста/архивация/перемещение файлов) путем создания полноценного приложения на Java/.NET/C++ — со сборкой и балеринами компиляцией.

Но и взгляд со стороны менеджера тоже имеет определенную осмысленность:

есть готовый продукт с четко определенным функционалом и ценой — покупаешь, устанавливаешь и используешь, все просто.

А тут р-раз — и оказывается что жизненно важный процесс в компании реализован на каких‑то непонятных «скриптах на баше».

Не буду в сотый раз приводить известную фразу Бисмарка про «колбасу и политику», но есть причины по которой менеджерам стоит держаться подальше от разработки. Одна из таких причин — невозможность передать инженерную культуру необразованному в техническом плане человеку.

Проще говоря объяснения из серии:

«у программ бывает всего два состояния — работает/не работает» или «grep в виде подключенной библиотеки ничем (кроме затраченного времени) не отличается от grep в виде отдельного запускаемого приложения»

на практике не особо работают, к сожалению.

Тот самый "софт которого нет"

Ввиду упомянутой выше философии Unix, доступности исходного кода и (чего греха таить) отсутствия серьезного коммерческого интереса — весь базовый юниксоидный софт давно перемешался между собой зависимостями и слился в практически единую платформу, которая теперь однотипна и более‑менее одинаково работает во всех современных *BSD и линуксах.

Потому что так проще:

проще работать, проще поддерживать, проще собирать.

Посмотрите на два скриншота ниже:

Каталог /usr/bin по традиции из времен еще старого Unix 5 содержит набор пользовательского ПО — тех самых утилит, которые пользователь комбинирует в цепочки обработки ради выполения своих рутинных задач.

Как видите этот набор не сильно отличается даже между столь технически разными FreeBSD и Ubuntu, что думаю отлично иллюстрирует мысль:

средства разработки, ключевые библиотеки и базовые консольные утилиты — последние 20 лет однотипны и однообразны во всем Unix-мире.

Такое единение когда‑то стало поводом называть Linux как GNU/Linux, поскольку утилиты GNU стали обеспечивать базовое пользовательское окружение. На сегодняшний день официально себя называет «GNU/Linux» например проект Debian.

Что же касается BSD, стоит процитировать английскую википедию, которая (местами) cильно адекватней переводов:

The Berkeley Software Distribution or Berkeley Standard Distribution^[1] (BSD) is a discontinued operating system based on Research Unix, developed and distributed by the Computer Systems Research Group (CSRG) at the University of California, Berkeley

Так что BSD с самого начала представляла собой больше набор готового прикладного ПО (тот самый «software distrubution») для конечных пользователей, нежели ядро ОС. Собственно так дела у BSD-шников обстоят и поныне:

несмотря на то, что у каждой из «святой троицы» BSD (FreeBSD/NetBSD/OpenBSD) cвое отдельное уникальное ядро, такой серьезной фиксации на его ручной пересборке как в линуксе нет.

Разумеется сборка из исходников как ядра так и всей системы целиком вполне возможна силами пользователей, но сие не является ни каким-то особым достижением ни необходимостью для BSD-системы.

А в случае OpenBSD — самостоятельная сборка вообще официально не является рекомендованной.

Каждая из BSD систем до сих пор воспринимается своими пользователями как нечто готовое и ценится за «соответствие заявленного действительному» — описанному в официальном руководстве можно верить.

Минутка жести

Поскольку в прошлый раз выяснилось, что на Хабре достаточно много интересующихся классическими старыми Unix вроде Solaris — немного расскажу как обстоят дела с софтом там.

Несмотря на то, что в базовом Solaris было достаточно прикладного ПО (на 2005й год), для более-менее удобного существования его все равно было мало.

Усугубляло проблему и то, что в Solaris множество системных утилит вроде grep, awk, make и так далее имели свои особые версии, несовместимые с набором GNU по логике работы или ключам.

Поэтому с времен появления x86-версии (2003й год) Solaris появился проект, предоставляющий внешние подключаемые репозитории с открытым ПО:

OpenCSW (pronounced open-cashew /ˈkæʃuː/) is an easy to use open source software distribution installable on top of Solaris and Solaris-based systems. 

Первым что ставилось из этого репозитория был набор утилит от GNU включая компилятор gcc, поскольку собрать что‑либо сложнее «Hello world» штатным было проблематично.

Как видите проект действует до сих пор и позволяет использовать большое количество открытого ПО уже в современных версиях Solaris, вроде Oracle Solaris или OpenIndiana.

Хотя разумеется это не так актуально — в базовой поставке ныне включено куда больше открытого ПО чем 20 лет назад.

Подводя итог:

что в «сложной» FreeBSD, что в «пользовательской» Ubuntu на сегодняшний день вас будут ждать практически одинаковые базовые утилиты и приложения: grep, awk, mc, bash, perl, python и так далее.

Разумеется отличия есть (временами существенные), но с годами их все меньше и меньше и тенденция — к все большей унификации и единообразию.

Кстати Python везде актуальной версии, насильно работать на 2.х ветке из-за редкости ОС вам точно не придется.

Вообщем‑то всем этим базовым софтом закрываются любые задачи автоматизации и большая часть рутинных задач, возникающих во время повседневной работы.

Так что проблемы отсутствия необходимых инструментов для работы едва ли посетят вас в любой современной Unix-системе.

А теперь поговорим о печальном.

Профессиональный софт

Существует большое количество профессионального ПО с длинной историей, для которого операционная система является не более чем кнопкой запуска. С некоторыми примерами такого ПО вы наверняка сталкивались в торрентах за время обучения в ВУЗе:

продукция Adobe, в первую очередь — Photoshop, ПО для 3D‑моделирования (Maya, 3DMax), ПО для инженеров и архитекторов (Autocad) и так далее.

Для такого типа ПО операционная система является своего рода кнопкой «Пуск», а все законченное решение для работы представляет собой специально подобранное и настроенное оборудование, поддерживаемую и настроенную ОС и установленный поверх профессиональный софт.

Временами с сертификацией всего программно‑аппаратного комплекса. И самих специалистов.

Поставляется такой софт естественно закрытым и оптимизируется только под поддерживаемые платформы.

Думаю вполне очевидно что в философию «Unix Way» такое ПО не вписывается никак, поэтому ждать официального релиза какого‑нибудь «фотошопа под FreeBSD» точно не стоит.

На уровне шутки это конечно можно сделать (сам делал, каюсь), но ожидать от подобной связки рабочего функционала и тем более пытаться использовать для реальной работы будет уже перебором.

Тем не менее ситуация постепенно исправляется, развиваются открытые аналоги таких систем: Blender, Gimp, FreeCAD, LibreOffice — все эти проекты за последние 10 лет шагнули очень далеко вперед.

Мне лично сложно судить о возможности полной замены продукции Adobe или Autodesk — поскольку никогда профессионально не занимался графикой, но все чаще замечаю, что как минимум студенты и начинающие авторы используют открытое графическое ПО в полный рост с достаточно вдохновляющим результатом.

Добавлю также, что сами производители профессионального ПО постепенно начинают активную поддержку Linux и все больше такого софта начинает хоть как‑то в нем работать, что не может не радовать.

Эмуляция

Одним из решений проблемы нехватки программного обеспечения в той или иной редкой ОС является эмуляция.

Надо отметить, что в Unix-мире с эмуляцией полный порядок:

всевозможных эмуляторов как аппаратной части так и специфического окружения — очень много.

Про самые важные из них я сейчас расскажу.

Dosbox

Начать стоит со знаменитого Dosbox, который позволяет закрыть наверное все возможные вопросы с софтом для любых вариаций и версий DOS и его окружения.

Помимо DOS, этот эмулятор позволяет запускать старые версии Windows (3.1, 95, 98, NT):

Добавлю, что у проекта Dosbox существуют более продвинутые форки с еще большим функционалом и даже порты на другие языки.

Кстати порт Dosbox на Java был использован автором для одного эксперимента, за который SkyNet его точно грохнет когда роботы придут к власти.

Wine

Следующим важным инструментом современного юниксоида является Wine, который при наличии времени и прямых рук позволяет запустить даже ААА-игры последнего поколения там где им не место:

Поскольку я далек от компьютерных игр — ценю Wine за возможность запуска более приземленного и обывательского ПО:

Qemu

Ооочень интересная штука, позволяющая запускать «то что нельзя но очень хочется» на обычном компьютере.

С помощью этого эмулятора возможно запустить ОС из мира больших корпоративных серверов на вашей домашней Ubuntu:

Понимаю, что врядли слова HP-UX или PA-RISC что-то скажут большинству читателей, поэтому просто показываю красивое что даже такая эмуляция ныне возможна:

Еще этот эмулятор крайне портабельный, поэтому присутствует в самых неожиданных местах.

Mame

Для самых необычных архитектур на свете существует эмулятор Mame, который позволяет запускать совсем уж редкий софт:

Разумеется в случае программной эмуляциии не‑x86 архитектур скорость оставляет желать лучшего, но поверьте — это куда проще чем восстановление и запуск реального устаревшего железа из 90х.

Виртуализация

Следующей темой, достойной раскрытия является виртуализация, прежде всего — аппаратная, с использованием возможностей современных процессоров.

В Linux за это отвечает подсистема KVM, но с недавних пор подобные решения были портированы и для всех BSD: OpenBSD, NetBSD и FreeBSD.

В случае FreeBSD, такая виртуализация породила интересное решение проблемы драйверов к современным WiFi-картам.

Самое главное что стоит знать:

аппаратная виртуализация сильно ускоряет работу гостевых ОС по сравнению с классическими решениями вроде VirtualBox или VMWare.

Поэтому с ее помощью возможно сделать например такое.

Но и сам классический эмулятор VirtualBox — не приговор, поскольку он портабелен и неплохо работает даже под FreeBSD.

В качестве примера запущенная в этом эмуляторе MacOS:

BSD и десктоп

Стоит также рассказать про опыт использования BSD-систем на рабочих станциях, поскольку такая практика является достаточно редкой.

FreeBSD

Cамая «user friendly» из всех BSD, с самым широким набором прикладного ПО. Фактически все что доступно в Linux — будет доступно и в FreeBSD (за редкими исключениями).

Помимо репозиториев с готовыми пакетами (как в Linux), существует еще и система портов, представляющая собой набор скриптов для скачивания исходников и сборки приложений локально.

К сожалению практика распространения ПО в виде готовых сборок отсутствует для BSD систем, поэтому если какого‑то приложения нет ни в официальном репозитории ни в портах — придется собирать самостоятельно из исходников.

Что хоть и звучит страшно, но на практике не представляет (в большинстве случаев) какой-то серьезной проблемы.

Также стоит добавить, что существует специальный скрипт, сильно упрощающий настройку FreeBSD на десктопе. Запуск этого скрипта буквально за пару шагов даст вам полноценную пользовательскую систему с графическим окружением.

OpenBSD

OpenBSD куда более сложная в использовании система, к тому же для десктопа придется серьезно ослаблять систему безопасности, поэтому их знаменитая фраза:

Only two remote holes in the default install, in a heck of a long time!

уже не будет иметь отношения к вашей инсталляции.

Также как и во FreeBSD, у OpenBSD есть и официальные репозитории с готовыми пакетами и свой аналог портов.

К сожалению набор прикладного софта все равно очень скуден, а процесс его одобрения и попадания в официальный репозиторий затруднен из‑за повышенных требований к безопасности в этой ОС.

Поэтому стоит обращать внимание на WIP (Work in progress) репозитории, в которых разработчики ведут работу над портом того или иного приложения.

Часто это единственный способ получить нативную сборку без виртуализации под эту редкую ОС.

Стоит еще отметить, что ввиду определенных особенностей этой системы, под OpenBSD не работает Wine.

NetBSD

Известный девиз этой ОС «Of course it runs NetBSD» не распространяется на прикладное ПО. Поэтому например факт запуска NetBSD на Amiga не означает, что там же будет работать Libreoffice, Chromium и весь остальной привычный пользовательский софт.

Что касается использования NetBSD на обычной x86-архитектуре, тут тоже есть неприятные сюрпризы.

Самое главное (с точки зрения использования на десктопе) — отсутствие Chrome/Chromium.

Ребята просто не успевают за космическими темпами разработки, которые последние годы удерживает проект Chromium.

Для сравнения в FreeBSD обновления пакета стабильной версии chromium приходят пару раз в неделю, а набор патчей для OpenBSD выглядит вот так и по объему исходного кода приближается к размерам ядра этой ОС.

Работы по портированию Chromium под NetBSD тем не менее идут, все действие происходит в WIP репозитории, но у автора ни разу не получалось собрать Chromium из этих исходников до конца — обязательно что‑то отваливалось.

Так что на текущий момент единственным поддерживаемым нативным браузером для NetBSD является Firefox Nightly.

Что касается готовых пакетов, тут как и во всех остальных BSD есть официальный репозиторий, пакетный менеджер и свой аналог системы портов.

Последний что характерно также кроссплатформенный и позволяет использование далеко не только под NetBSD:

Но разумеется набор ПО сильно зависит от архитектуры, также далеко не каждый пакет собирается на редких архитектурах, даже если присутствует в портах.

Подводя итог

С доступностью ПО в современном Unix‑мире все очень даже хорошо, за счет постоянного процесса унификации — различий (с точки зрения пользователя) между конкретными ОС становится с каждым годом все меньше.

Вы уже врядли столкнетесь с полной дезориентацией при переходе из Linux в какую‑либо из BSD‑систем — как это было в недавнем прошлом с большими коммерческими Unix вроде AIX или Solaris.

Врядли понадобится и изучение каких-то специальных команд для каждой конкретной ОС, поскольку все специфика осталась на уровне настройки и управления доступом, но не ежедневного использования.

Единственная область, где дела по‑прежнему не очень — современный профессиональный узкоспециализированный коммерческий софт, вроде Adobe Photoshop.

Его в Linux и *BSD не было (за редкими исключениями), нет и скорее всего не будет:

Как только ОС превращается в кнопку «пуск» для коммерческого продукта — вся магия «Unix Way» теряется, как и смысл использования открытой ОС для таких задач.

Но даже такое ПО вполне возможно заставить работать в Unix-окружении с помощью технологий эмуляции и виртуализации, пусть и с существенной потерей скорости работы.

To be continued..

В следующей части расскажу об особенностях разработки под Unix, как это делать правильно и наслаждаться процессом а не страдать от результатов.