Unix на работе. Часть 3: Разработка
Как вести разработку без Windows и Mac. Большой жирный, необрезанный спич.
Первая часть тут, вторая тут. Как я начинал работать с юниксом тут.
Вводная
Вам надо вести разработку под юниксом в замечательном 2023м году.
Так получилось вас заставили или так надо.
Исхожу из того что у вас уже есть хоть какой-то опыт ставили убунту дома, то есть история не про «совсем с нуля» и «/» вместо «c:\» вас уже не вводит в ступор.
Но при этом что такое «make world» вы еще не знаете, поэтому все что ниже практически полностью про линукс, с небольшими выносками про FreeBSD.
Краткая история
Не хочу даже 10-метровой палкой трогать говно под названием «какой дистрибьютив лучше», опишу лишь базовые принципы.
С древних времен было было две больших группы дистрибьютивов:
Debian (deb)-based и RPM-based, где deb и rpm — это формат бинарных пакетов, в которых поставляется софт.
RPM-based это Red Hat и RHEL, плюс Suse и Mandriva (которая теперь Mageia). А Debian он и в Африке — Debian.
Из RHEL в какой-то момент появился CentOS, затем сильно позже — Oracle Linux. Из Debian вырос целый зоопарк, в котором главным слоном был и есть Ubuntu. Породивший в свою очередь еще целый выводок различных дистрибьютивов и форков.
А потом появился Arch Linux, немного порвавший всем жопы шаблон на тему обновлений своим «rolling release» циклом выпуска.
Он сразу стал очень популярным как раз у разработчиков, поскольку был «золотой серединой» между совсем уж маргинальной Gentoo (и тем более LFS) и «изделием из кирпича и металла» в виде CentOS или Debian.
Из Arch Linux выросла куча популярных дистрибьютивов, например Manjaro. Он как раз на скриншоте в начале статьи.
Зачем я это читаю?
Чтобы правильно выбрать, разумеется.
Например бинарные сборки коммерческого и открытого софта разработчики выкладывают обычно только в самых популярных форматах: deb и rpm.
С указанием еще платформы и версии:
сборки под RHEL и CentOS идут отдельно, а у Ubuntu есть LTS и текущая версии, тоже временами с разными сборками.
Так что если будет нужно иметь дело с бинарными сборками какого-то софта вне репозиториев — придется выбирать одну из поддерживаемых ОС.
Первая свежесть
Вторым важным моментом является свежесть поставляемых с ОС библиотек и частота их обновлений.
В стабильных Debian и CentOS например это происходит настолько нечасто, что софт успевает устареть на момент включения в обновление:
Даже если вы собираетесь тихо и мирно заниматься веб-разработкой, не влезая в дебри системных библиотек — у вас обязательно вылезут проблемы с каким-нибудь несвежим nodejs, петоном или Ruby. А установка более свежего станет приключением из-за системных зависимостей.
Изолировать разработку от системых библиотек не получится при всем желании — это не венды, с обратной совместимостью в линуксе всегда было плохо.
Это когда версия едва успела появиться в репозитории разработчиков а ее уже запихивают в portage Gentoo.
Если вам и правда интересно заниматься вопросами совместимости между набором из 20 000+ библиотек в альфа и бета версиях — вперед.
Но думаю большинство все-таки работают за деньги, а за такую #блю их почему-то не платят.
Вообщем вам нужно что-то более менее популярное и достаточно часто обновляемое:
Ubuntu, Manjaro — самое оно.
У каждого популярного дистрибьютива есть нестабильные версии, находящиеся в разработке: Fedora у RHEL, Debian Unstable у обычного Debian и так далее.
Вам это не надо, если вы собираетесь заниматься работой а не онанизмом. Либо если очень хорошо знаете что делаете.
С ОС думаю закончили, теперь про редакторы.
Visual Studio Code
Чемпион и лицо современной разработки на юниксах. Везде где сейчас есть разработка под линуксом — везде будет это лицо эта среда разработки. Поддерживает в том или ином виде все популярные языки:
C/C++, С#, JavaScript, Typescript, Python, Ruby, Java, Haskell,
Делает его при этом Microsoft, что само по себе еще лет 10 назад тянуло на анекдот.
Вообщем, я уже забыл когда последний раз использовал какой-нибудь KDevelop, MonoDevelop, Geany, Komodo или другие специфичные среды, кроме имеющих отношение к Java — настолько VSCode закрывает все потребности.
Есть и стабильно работает только под FreeBSD, под OpenBSD и NetBSD его нет.
Вот так выглядела попытка портировать под OpenBSD.
Справедливости ради надо упомянуть и про юниксовую классику:
Но даже «диды» вроде меня ими особо не пользовались, хотя юниксами я занимаюсь 20+ лет.
Насколько это актуально — изучать и использовать редактор, построенный вокруг технических ограничений консольного терминала из 70х? Решайте сами.
emacs и vim есть на всех юниксах, во всех дистрибьютивах. Вообще везде.
Так что если нужно работать на какой-то совсем дикой экзотике — вперед.
Дальше я опишу особенности разработки на основных языках под юниксом.
Node.js
Что LTS что Сurrent версии достаточно стабильны, шанс попасть на конфликт с зависимостями минимален, но есть. Особенно на всяких «суперстабильных» Debian и CentOS.
Надо понимать, что собирать ноду из исходников самостоятельно достаточно тяжело из-за большого числа зависимостей, в том числе внезапной зависимости от Python в виде нативной библиотеки, а не интерпретатора скриптов (!), который используется при сборке.
Скорее всего вам также придется отключить OOM Killer — он любит убивать процессы nodejs при сборке на больших проектах.
BSD:
Все плохо и тяжко. Официально Node.js ни на одной из BSD не поддерживается. Доступные бинарные сборки — всегда сильно устаревшие. В том числе в портах. Так что собирать придется ручками из исходников.
В работе очевидно тоже есть проблемы, поэтому делать продакшн на ноде под фрибзд точно не надо.
Python
Петон родился и вырос в юниксах, это его дом и основная среда обитания. Поэтому он есть везде официально и везде поддерживается.
У вас будет больше проблем при разработке на петоне под Windows чем под любым линуксом.
Под маком кстати все очень и очень хорошо, любители еб#ть цифры Data Science подтвердят.
Но без лопаты говна ложки дегтя конечно никак:
Основная проблема петона — биндинги к нативным библиотекам. Они везде и всюду. Они причина всех падений и всей нестабильности.
Нужно вам поработать с Postgres — библиотека работы с ней нативная, на Си. А биндинги петона с ней просто линкуются.
Один неправильный чих и все упало.
.NET
Самый херовый вариант из возможных — пытаться вести разработку под дотнет на юниксах.
Технически .NET Core доступен и официально поддерживается аж Микрософтом, но это такой п#здец в работе что словами не описать:
Это абсолютно чужая, противоестественная среда для него, а значит вы будете собирать все детские проблемы из 90х: кодировки, прямой-обратный слеш в пути к файлам и так далее.
Дотнет создан для венды, точка. Ни малейшего практического смысла использовать его в юниксах для новых проектов — нет.
Единственное разумное применение — портирование какого-то проекта из вендов и нормального дотнета.
Кстати можем с этим помочь если надо, пишите.
BSD:
Вы серьезно? Ну ок, да это тоже можно сделать. На уровне шутки.
Java
С джавой все всегда было хорошо, поскольку она изначально создавалась на юниксах и всегда на них же эксплуатировалась.
Скорее Windows и особенно Mac для джавы являются «вражеской средой». Вообщем работающую JRE/JDK вы получите везде, на любых дистрибьютивах линукса и коммерческих юниксах и без особых проблем.
Могут быть определенные проблемы с Eclipse и софте, который на нем построен (например замечательный DBeaver) — из-за нативной библиотеки SWT.
Но это надо попасть. Последний раз я падение эклипса из-за нативных ошибок видел на Slackware, так что сами понимаете — шанс не большой.
Во всех BSD джава конечно же есть, но во-первых официально не поддерживается, во-вторых обновления версий сильно запаздывают. Где-то на полгода. На момент написания статьи например доступна только 19я версия а не 20 и дальше.
Поэтому существуют определенные проблемы с эксплуатацией. Из года в год их все меньше и меньше, но они есть.
Мобильная разработка
Очевидно что речь только про Андроид, поскольку J2ME кануло в лету а нормальная iOS разработка возможна только на маках.
Android Studio содержит нативные зависимости, сам Android SDK имеет бинарники, эмулятор Android и его правильная работа зависит от настроек окружения.
Вообщем я бы не советовал при мобильной разработке сильно уходить от самых популярных дистрибьютивов, хоть в требованиях и написано:
- Any 64-bit Linux distribution that supports Gnome, KDE, or Unity DE; GNU C Library (glibc) 2.31 or later.
На заборе тоже написано, а за ним — дрова.
BSD:
Только для совсем#бнутыхопытных, это очень сложно.
Как нибудь опишу процесс в отдельной статье.
Итого
Самое лучшее — петон и джава, самый адский гемморой — дотнет. Гемморой чуть попроще — nodejs.
Хотя сама современная разработка — один сплошной гемморой, лучше бы я чем-то другим в жизни столько лет занимался, ей богу.
To be continued..
В следующей части расскажу про нативную разработку: Си, C++, Rust и Golang — про цирк и клоунов, которые больше не смеются.