SavePearlHarbor

Альтернативные способы поиска и установки программ в Linux

—

от автора

admin

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

Уклон в альтернативные варианты, поэтому в этой статье будет мало рассказано про [⟹]классические пакетные менеджеры (apt/apt-get, dnf/yum, …) и про [⟹]компиляцию из исходников.

Статья написана так как, на проводимых мною, курсах про Linux (в Сетевой Академии ЛАНИТ) постоянно встречаю людей, которые (переходя с Windows на Linux) имеют одни и те же сложившиеся стереотипные привычки и ожидания касательно установки и поиска прикладного ПО, которые, скорее, уведут их на сложный путь «установки несовместимого» и/или путь «установки ПО через компиляцию из исходников». И хоть информацию про поиск и установку ПО для Linux, не входящего в официальный репозиторий, в интернете можно найти, но информация эта достаточно разрозненная и не всегда понятны плюсы-минусы различных подходов.

Алгоритм поиска и установки ПО

У меня сложился такой алгоритм.

У меня сложился такой алгоритм.

  • 1. [➜] Популярное свободное ПО:

    • [⟹] классический пакетный менеджер

  • 2. [➜] Менее популярное свободное ПО
    …и     [➜] проприетарное ПО, имеющее пакет для Linux:
    (Объединил эти два пункта, так как варианты решений во многом похожи)

    • a. [➜] Пакет под ваш или под совместимый дистрибутив:

      • [⟹] Использовать готовые рецепты по установке: eepm play, …

      • [⟹] Подключить сторонний репозиторий

        • [⟹] Скачать пакет

    • b. [➜] Пакет под НЕ совместимый дистрибутив:

      • [⟹] Использовать другой пакетный менеджер и формат пакета

        • [⟹] кроссдистрибутивные форматы пакетов: AppImage, Flatpak, Snap, …

        • [⟹] альтернативные пакетные менеджеры: pip, gem, npm, cargo, …

        • [⟹] контейнеры: docker, podman, …

      • [⟹] Конвертировать пакет в формат своего дистрибутива

      • [⟹] Написать запрос в техподдержку

      • [⟹] Компиляция из исходников и сборка пакета

  • 3. [➜] Проприетарное ПО, НЕ имеющие пакет для Linux:

    • [⟹] Поищите аналог

    • [⟹] Использовать эмулятор API нужной системы

    • [⟹] Использовать виртуализацию

Если вдруг кажется, что «тут сложно, а вот в другой ОС всё было просто» — учтите, что там («в другой ОС») вы, скорее всего, рассматривали только самый узкий и ограниченный вариант установки проприетарного ПО, специально созданного под используемую вами систему. Однако захотели бы вы, к примеру, поставить в Windows приложение, написанное только для Mac, то, думаю, в полной мере оценили бы, что там весь процесс гораздо сложнее (если вообще возможно решение).

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

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

? ЛикБез: Чем различаются проприетарное ПО и свободное ПО

Вкратце:

  • Термины «Свободное ПО/Free Software» и «Открытое ПО/OpenSource» практически означают одно и то же — наличие права и возможности изучать, модифицировать и распространять исходный код ПО. Просто в первом термине уклон сделан на наличие прав (изучать, модифицировать и распространять), а во втором — на доступность исходного кода.
    Кому интересны подробности — рекомендую почитать про:

    • ? Открытое программное обеспечение

    • ? Определение свободного программного обеспечения

    • ? Определение_Open_Source

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

    • ? Проприетарное программное обеспечение

    • Часто проприетарное ПО имеет различные ? vendor-lock‘и — закрытые форматы файлов или недокументированные протоколы взаимодействия.

? Пример-цитата из лицензии проприетарного продукта:

Фрагмент из лицензии одного отечественного проприетарного продукта, к тому же созданного на основе свободного программного обеспечения:

Пользователь обязуется не осуществлять самостоятельно и не создавать условия третьим лицам для осуществления следующих действий: Изучать, исследовать или испытывать функционирование ПО в целях определения алгоритма работы ПО и его компонентов, декомпиляцию и дизассемблирование любых составных частей ПО или иным способом осуществлять попытку получить исходный текст ПО или любой его части за исключением случаев, разрешенных применимым правом, несмотря на данное ограничение, и только в объеме, разрешенным применимым правом. Если применимое право запрещает ограничение указанных действий, любая информация, полученная таким способом, не должна использоваться для создания программного обеспечения, по своему виду существенно схожего с ПО.

[Название продукта не указываю, но аналогичные фрагменты можно найти в лицензии многих проприетарных продуктов]

Да, и в этой же лицензии есть такой интересный фрагмент:

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

  • Про платность/бесплатность. Стоит отметить, что «проприетарное ПО» НЕ синоним «платного ПО». Часто платное ПО использует некую проприетарную лицензию, но бывает:

    • бесплатное проприетарное ПО:
      — ?Freeware
      — ?Shareware
      — ?Freemium
      — ?Adware
      — ?Nagware

    • платное свободное ПО:
      — ?Open_core
      — ?Двойное_лицензирование
      — ?Donationware

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

? Пример-цитата из лицензии одного отечественного проприетарного продукта:

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

Минусы проприетарного ПО:

Имейте понимание, что приобретая или скачивая закрытое ПО вы устанавливаете себе в систему «может и золотые, но наручники» (то есть программа делает не то, что нужно вам, а то, что хочет разработчик этой программы — как молоток, который будет забивать только одобренные производителем молотка гвозди). При этом, ПО может содержать «жучок», который собирает и докладывает своему автору различную информацию о вас («той ли системы у вас гвозди», «как часто вы используете молоток», «GPS-координаты места, где забит гвоздь» и т.п.), не оповещая и не спрашивая разрешения у вас (пользователя ПО). И только порядочность разработчика ПО, а иногда и боязнь публичной огласки и репутационные риски в случае обнаружении подобного функционала, дает слабую надежду на отсутствие не заявленного в ПО функционала.

Подробнее про минусы проприетарного ПО:

Тут не ставлю цель попугать или сказать, что производители проприетарного ПО поголовно включают в него всякого рода «закладки» (например, телеметрию), но такое встречается в мире ПО (любого — как закрытого, так и открытого). Просто в открытом ПО гораздо сложнее незаметно скрыть подобный функционал от общественности (то есть лично вы можете не просмотреть этот код, однако есть же и те, кто будут внедрять это ПО в проектах, требующих повышенных мер безопасности. А значит, они выполнят сами или закажут у специалистов подробный аудит кода — про это же есть и так называемый «?закон Линуса»). Бывает, подобное стараются скрыть, используя умышленно запутанные фрагменты кода [это называется ?ОбфускацияПО], но наличие таких фрагментов только привлечет большее внимание специалистов, занимающихся безопасностью и оттолкнет всех сомневающихся от использования такого продукта на своих проектах. К тому же, в открытом ПО пользователь (или ?мейнтейнер дистрибутива, собирающий пакет) может переписать спорные фрагменты кода, пересобрать пакет и использовать программу без них.

  • [минус] Наличие технических или правовых ограничений

    • ограничения на использование ПО: например, создание в альтернативных открытых форматах,

    • ограничение на копирование ПО. То есть вы «купили ПО», но на самом деле оно не ваше — вы приобрели лишь право им пользоваться, да и это право вы не можете, к примеру, передать своим родственникам.

    • и уж точно есть ограничение на модификацию ПО под свои нужды. Даже если вы испытываете неудобства в какой-то части интерфейса (а удобство — это субъективное понятие, так как люди разные, и одни и те же элементы интерфейса одни считают удобными, а другие — неудобными) — смиритесь и пользуйтесь, ну и надейтесь, что разработчики когда-нибудь переделают.

    • отказ от обслуживания, если вы вдруг …: из «не той страны», не продлили подписку, не той профессии (например, продукт, доступный по академической лицензии, перестанет быть доступным, когда завершится статус студента или сотрудника обучающей организации), …

    • наличие подписки о неразглашении или отказ от разработки альтернативных решений

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

  • [минус] ПО закрытое = «кот в мешке», в нем могут быть встроены как заявленные, так и недокументированные возможности, которые вы не планировали приобретать:

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

    • встроенная реклама,

    • использование ресурсов вашей системы для сторонних целей (например, майнинг электронных денег, распределенные сетевые атаки на другие системы, …)

    • … (пишите еще варианты в комментариях — не сильно готовился перечислять минусы закрытого ПО, гораздо больше хотел бы проговорить про плюсы открытого ПО — так как эти плюсы обычно менее видны для людей, ранее использовавших только закрытое ПО).

  • [минус] Довольно часто закрытое ПО пытаются продвинуть и сделать более популярным свой закрытый формат файлов, в которых можно сохранять результат своей работы, вместо существующих открытых форматов. Такой вариант ? vendor-lock, чтобы помешать в дальнейшем переход на использование другого ПО. Суть такого подхода можно понять на примере стратегии борьбы с конкурентными разработками «? Embrace, Extend, and Extinguish», используемой одной корпорацией в недавнем прошлом.

  • [плюсы] Наверное, есть какие-то плюсы. Хотя, скорее всего, эти плюсы не для потребителя.

    • [плюсы] Для потребителя: у платного закрытого ПО может быть официальная техподдержка от производителя (в открытых разработках может быть, а может и не быть такой опции от автора ПО, но при этом данную услугу обычно предлагают дистрибьютеры), дополнительные услуги (например, облачный хостинг, скидки, пробный период, …), мерч и т.п.

«Алгоритм поиска» в обратном порядке

В жизни я бы начал поиск ПО с официального репозитория своего дистрибутива и вам бы посоветовал искать нужные программы там. Это наиболее правильный способ установки ПО в Linux-системах: пакеты в репозитории протестированы и специально собраны под вашу систему, а, следовательно, с их установкой и запуском будет меньше всего проблем. Но …
… человек, начинающий своё знакомство с миром Linux (и еще не осознающий сильные стороны OpenSource), часто интересуется «как установить программу (название той программы, что он пользовался ранее в другой ОС)» и, скорее всего, это что-то из последних пунктов (про проприетарное ПО), указанного выше алгоритма. Поэтому буду рассказывать в обратном порядке (в основном сделав уклон на альтернативные способы установки пакетов) — с мыслью, что «да, сейчас помогу вам узнать, как найти и установить проприетарное ПО, но начните использовать открытое ПО и точно найдёте много интересного и полезного для себя функционала».

3. [➜] Проприетарное ПО, НЕ имеющее пакет для Linux

  • [⇫ Алгоритм] Варианты решения:

    • [⟹] Поищите аналог

    • [⟹] Использовать эмулятор API нужной системы

    • [⟹] Использовать виртуализацию

Образно говоря это, к примеру, про программы типа «Adobe Photoshop».

  • [⟹] Поищите аналог:
    Настоятельно рекомендую проработать этот вариант, если вы до этого использовали только проприетарное — вполне возможно найдется аналог, а иногда и более функциональный. Хотя поначалу будет менее привычный интерфейс (зависит от сложившихся привычек при использовании прошлого ПО — часто бывает, что ищут «шашечки, а не ехать» — не функционал, а чтобы кнопки были расположены также). Существует огромное количество хорошего и качественного прикладного ПО для Linux — начните видеть шире и пользоваться не только тем, что рекламируется за деньги:

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

  • [⟹] Использовать эмулятор API нужной системы
    Эмулятор позволяет запускать приложения, написанные для других систем.
    (Некоторые здесь упомянутые приложения не являются эмуляторами систем, а скорее открытые реализации API этих систем, но простым пользователям в такие тонкости можно сильно не вдаваться. Так wine — Win32 API, а Darling — Cocoa API)

    • Для приложений, написанных под Windows: ?Wine, ?Valve_Proton, ?CrossOver, …

      • к wine стоит еще упомянуть утилиты:

        • winetricks — скрипт для установки стандартных компонент Windows (DLL-библиотеки, шрифты, Direct3D, …)

        • winecfg позволяет выбрать какую версию Windows эмулировать и различные её настройки

        • есть различные обертки, позволяющие упростить установку Windows игр/программ в Linux: ?PortProton, ?Lutris, ?Bottles, …

    • Для DOS-приложений: ?DOSBox, dosemu, …

    • Для NES/Dendy/Wii-игр: ?Nestopia, ?zsnes, ?snes9x, ?DeSmuME, ?yuzu(suyu), ?FCEUX, ?Mednafen, ?dolphin-emu, …

    • Для игровой приставки PSP: ?PPSSPP, …

    • Для MacOS: ?Darling, …

    • Для Android: ?Anbox, Waydroid, …

    ☑️ Особенности эмулятора: ???(⚠️)

    ?: Исходный код ЗАКРЫТ

    ✦ Подготовленная бинарная сборка на основе закрытых исходников — сложно проверить наличие ?НДВ.
    ✦ Минусы проприетарного ПО >>>

    ПРЕДУПРЕЖДЕНИЕ

    ✦ Не запускайте root’ом.
    ✦ Не запускайте пользователем, от которого вы используете мессенджеры и посещаете сайты с личной информацией (например, социальные сети, онлайн-банк, …). Приложение, запущенное от того же пользователя, может получить доступ к этой информации.
    ✦ Использовать либо из проверенных источников, либо в изолированных системах, в которых не хранится секретная информация.
    ✦ Рассмотреть какой-нибудь вариант запуска этого приложения в изолированной среде: виртуализация, контейнеры, песочницы (chroot, firejail, namespaces-изоляция, …) или используя мандатные ограничения (SELINUX-политики, AppArmor-политики, …).
    — В winecfg можно ограничить, какие директории хостовой системы будут доступны из эмулятора WINE.

    ?: Размер и скорость менее оптимальны, чем у аналога в виде классического пакета, собираемого из исходников под вашу ОС

    ✦ Размер пакета БОЛЬШЕ, чем у открытых аналогов.
    ✦ Работает МЕДЛЕННЕЕ открытых аналогов.
    (здесь имеется в виду, что дистрибьюторы или пользователи не имеют ни правовой ни технической возможности пересобрать пакет, поэтому оптимальность реализована только на том уровне, которую предусмотрел разработчик, не знающий особенности вашей системы)

    ?: НЕ требуются права администратора

    ✦ Для запуска и «установки» подобных приложений через эмулятор НЕ требуются права администратора (права администратора понадобятся для установки только самого эмулятора).
    ✦ Допустима установка в «своей песочнице» разных версий пакета и под разные системы.

    ?Замечание: Не встроено в систему

    ✦ Так как ПО закрытое и не собиралось непосредственно по ваш дистрибутив, то оно, скорее всего, не будет использовать встроенные в систему библиотеки и темы оформления (то есть будет внешне отличаться от оформления других приложений).
    ✦ Может (зависит от возможностей эмулятора), при установке программы, не появиться ярлык приложения в стартовом меню (?меню «Пуск») среды рабочего стола. Можно вручную создать подобный ярлык в /usr/share/applications/ или в ~/.local/share/applications/ — но при удалении программы ярлык также понадобится удалить вручную.
    ✦ Не будет обновляться при обновлении системы, понадобится вручную искать и устанавливать новые версии программы.

    ? Документация по эмуляторам: ⊚​Alt, ⊚AstraLinux, ⊚RedOS
    winetricks - для установки стандартных компонент Windows, которые могут понадобиться для запуска ПО в эмуляторе

    winetricks — для установки стандартных компонент Windows, которые могут понадобиться для запуска ПО в эмуляторе
    ? PortProton — простая установка Windows-игр и популярных лаунчеров игр

    Хотел бы отдельно рекомендовать инструмент отечественной разработки, сильно упрощающий установку Windows-игр, а также установку таких популярных лаунчеров, как WGC, Epic Games, BattleNET, Origin, EVE Online, RockStar, Ubisoft connect, League of Legends и многих других.

    PortProton для установки игр

    PortProton для установки игр

    Легко устанавливается:

    • Есть пакет в репозиториях ⊚Альт и ⊚ROSA

    • Доступен в виде flatpak-пакета в репозитории flathub, то есть в остальных дистрибутивах (а также в игровой консоли Steam Deck) можно установить простой командой:
      flatpak install ru.linux_gaming.PortProton

    • Также есть инструкция на официальном сайте (https://linux-gaming.ru)

    Подробнее:

    Бывает, что создают классический пакет для Linux-дистрибутивы, в котором на самом деле используется обертка для запуска Windows-приложения через wine.

    [Замечание] Не все приложения могут работать через эмулятор, особенно если они

    • используют недокументированные API системы,

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

  • [⟹] Использовать виртуализацию
    (внутри Linux запустить виртуальную машину с другой ОС или другим дистрибутивом, для которого есть пакет) — на родном ?KVM/?qemu или на других решениях — можно с использованием как CLI-управлением, так и с GUI- или Web-управлением: ?Virt-Manager(libvirt:CLI/GUI), ?Proxmox_VE(CLI/WUI), ?VirtualBox(CLI/GUI), ?GNOME_Boxes(GUI), ?OVirt(WUI), ?OpenNebula(CLI/WUI), …

    • минус такого решения: некоторая часть ресурсов системы (зависит от используемого решения и поддержки ? аппаратной виртуализации) будет использоваться гипервизором — будет чуть или сильно медленнее работать, чем если бы гостевая ОС устанавливалась напрямую на данное оборудование.

    • плюс такого решения: нет необходимости искать нужный формат пакета

2. [➜] Менее популярное свободное ПО

… и [➜] проприетарное ПО, имеющее пакет для Linux

  • [⇫ Алгоритм]:

    • a. [➜] Пакет под ваш или под совместимый дистрибутив

    • b. [➜] Пакет под НЕ совместимый дистрибутив

Немного прокомментирую, что подразумеваю под «менее популярным свободным ПО» — это программы, которые существуют для Linux, но почему-то не оказались в репозиториях используемого вами дистрибутива. Причины три:

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

  • Сложный пакет с большим количеством зависимостей. Чтобы добавить этот пакет в дистрибутив, ?мейнтейнерам дистрибутива нужно еще и добавить большое количество библиотек, необходимых для данного пакета, и еще поддерживать их — обновлять и отслеживать совместимость с другими пакетам, которые могут использовать те же библиотеки, но других версий.

  • Один из многочисленных проектов на github/gitlab/… и мейнтейнеры вашего дистрибутива еще про него не узнали (и не осознали, насколько это нужная их клиентам утилита), чтобы добавить его в репозиторий дистрибутива. А также,
    реально очень редкий пакет, который кроме вас и разработчика этой программы используют всего несколько пользователей со всего мира — что-то очень сильно узкоспециализированное
    или своё ПО (написанное разработчиками из вашей конторы под нужды вашей конторы).

Поэтому у такого менее популярного свободного ПО ситуация немного схожа с ситуацией «поиска пакета для закрытого ПО, у которого есть установочный пакет под Linux». Также в официальных репозиториях пакета нет: значит, нужно знать про подключение сторонних репозиториев или про использование альтернативных форматов пакетов. Но для свободного ПО (в отличии от проприетарного), есть вариант [⟹ Компиляция из исходников и сборка пакета], ну и гораздо больше шансов найти пакет, под используемый вами, или совместимый дистрибутив (так как есть не малое количество людей в мире, способных собрать пакет из исходников под определенный дистрибутив — этому может и школьник научиться).

☑️ Особенности проприетарного ПО в виде пакета под Linux: ?(⚠️)??

?: Исходный код ЗАКРЫТ

✦ Подготовленная бинарная сборка на основе закрытых исходников — сложно проверить наличие ?НДВ .
✦ Минусы проприетарного ПО >>>

ПРЕДУПРЕЖДЕНИЕ:

✦ Очень сильно рискуете, используя не проверенный (хотя бы сообществом) код, да еще и root’ом (при установке пакета), а также пакет может содержать SUID-утилиты и include-настройки к системным службам, уменьшающие (или даже ломающие) безопасность вашей системы.
✦ Использовать либо из проверенных источников, либо в изолированных системах, в которых не хранится секретная информация.
✦ Рассмотреть какой-нибудь вариант запуска этого приложения в изолированной среде: виртуализация, контейнеры, песочницы (firejail, namespaces-изоляция, chroot, …) или используя мандатные ограничения (SELINUX-политики, AppArmor-политики, …)

?: Размер и скорость работы зависит от реализации

✦ Размер пакетов зависит от того, вшиты ли в него зависимости или нет — другие люди (не разработчики данного ПО) не имеют права собирать более оптимизированный пакет.
✦ Скорость работы зависит от того, насколько оптимально собран пакет разработчиками ПО — другие люди не имеют права собирать более оптимизированный пакет.

?: требуются права администратора

✦ Для установки пакета и подключению стороннего репозитория требуются права администратора.
✦ Права администратора НЕ понадобятся для конвертации пакета, но понадобятся для установки утилит конвертирования и потом для установки сконвертированного пакета.
✦ Права администратора НЕ понадобятся затем (после установки) при использовании программы (если это прикладное пользовательское ПО)

2a. [➜] Пакет под ваш или под совместимый дистрибутив

  • [⇫ Алгоритм]:

    • Варианты решения:

      • [⟹] Использовать готовые рецепты по установке: eepm play, …

      • [⟹] Подключить сторонний репозиторий

        • [⟹] Скачать пакет

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

Определить, с каким дистрибутивом совместим, используемый вами дистрибутив, можно командой: grep ID_LIKE /etc/os-release — отсутствие вывода означает самобытность (самостоятельность, не совместимость с другими) дистрибутива.

? Примеры совместимых дистрибутивов: ⊚AstraLinux, ⊚RedOS, ⊚Alt

  • ⊚AstraLinux является деривативом ⊚Debian — собирается на его основе. Значит, большинство пакетов от соответствующей версии Debian установятся с минимум проблем в AstraLinux:

    • AstraLinux_1.8 на основе Debian_12(Bookworm),

    • AstraLinux_1.7 на основе Debian_10(Buster),

    • AstraLinux_1.6 на основе Debian_9(Stretch),

    • Примечание про отсутствие необходимости сертификации прикладного ПО, которые НЕ влияют на сертифицированные характеристики ОС: https://wiki.astralinux.ru/pages/viewpage.action?pageId=63802854

    • ID_LIKE=debian

  • ⊚Ubuntu — достаточно известный дистрибутив, который также создается на основе Debian:

    • ID_LIKE=debian

  • ⊚RedOS является RedHat-совместимым дистрибутивом, поэтому в RedOS с большой вероятностью можно установить пакеты, сделанные для ?RHEL(RedHat), ⊚CentOS или ⊚Fedora — например, из репозитория ? EPEL (Extra Packages for Enterprise Linux)

    • ID_LIKE="rhel centos fedora"

  • ⊚Alt(Альт) не назвал бы RedHat-совместимым: хотя в Альт используются пакеты в формате rpm, но кроме формата пакетов их с RedHat ничего не связывает. Одинаковый формат пакетов НЕ означает, что в Альт подойдут пакеты от RedHat/Fedora/CentOS (хотя тут, наверное, ближе всех Fedora) — там разное написание зависимостей и разные пост-установочные скрипты. Alt правильнее называть rpm-based, но не RedHat-based (кстати, похожая история и у дистрибутивов SUSE). Вероятность успешной установки и работы пакетов от другого RedHat-совместимого дистрибутива невелика, хотя и не нулевая, поэтому в Альт предустановлена замечательная утилита перепаковки пакетов [eepm repack ⟹] и утилита установки стороннего ПО [eepm play ⟹]

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

[Замечание] Не рекомендуется обновлять целиком систему или основные системные библиотеки, если подключены репозитории от совместимых дистрибутивов, так как это может поломать систему. То есть, если вы подключили сторонний репозиторий, установили нужные с него пакеты (желательно только прикладное ПО, без обновления системных компонент) и затем отключили репозиторий.

  • [⟹] Использовать готовые рецепты по установке
    Рецепты-утилиты, автоматизирующие установку стороннего ПО

    • у универсального пакетного менеджер eepm (от ?Etersoft) есть подкоманда play, упрощающая установку различных популярных прикладных программ (очень интересное и лучшее решение для простого пользователя). Доступны рецепты для установки более 190 известных программ, постоянно добавляются поддержка новых программ и корректируются уже существующие рецепты при выпуске новых версий ПО.

      ? Использование: eepm play и appinstall

      eepm предустановлен в дистрибутивах ⊚Alt (и есть в репозиториях ⊚RedOS и в ⊚ROSA), а также ?легко устанавливается во многие другие дистрибутивы (?список дистрибутивов).

      • Чтобы посмотреть ?список доступного для установки ПО:
        eepm play

      • Чтобы установить нужное приложение:
        eepm play ИМЯ
        Данная команда скачает приложение (для многих с официального сайта) пересоберет (если требуется) пакет под ваш дистрибутив и установит его. То есть если потом понадобится удалить приложение, то можно будет просто деинсталировать установленный пакет через штатный пакетный менеджер.

      • Также рекомендуется периодически обновлять сам eepm, так как рецепты достаточно часто меняются — например, если вышла новая версия какой-нибудь программы или добавили новый рецепт или исправили ошибку в старом рецепте. Обновлять можно либо штатным пакетным менеджером (если его репозитории пополняются новыми версиями eepm), либо:
        eepm selfinstall

      • Также в ⊚Альт (предустановлен в «Альт Рабочая станция» и доступен в репозитории для «Альт Сервер») есть графическое приложение appinstall, которое позволяет простому пользователю (не знающему про командную строку) выполнять из графики установку в несколько кликов мышкой проприетарных программ, доступных через eepm:

      Или командой appinstall из командной строки пользователем(понадобится ввести пароль root'а)

      Или командой appinstall из командной строки пользователем
      (понадобится ввести пароль root’а)
      appinstall (GUI для "eepm play") в ⊚Альт

      appinstall (GUI для «eepm play») в ⊚Альт

      eepm активно развивается:

      • в «Альт Рабочая станция» (10.1) была eepm версии 3.28.1 и из него можно было установить 57 программ,

      • а в доступной для Альт 10.2, версии eepm 3.62.2 уже поддерживается установка 190 программ.

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

      Подробнее:
      — ? https://wiki.etersoft.ru/Epm
      — ? https://www.altlinux.org/Epm

    Рецепты-инструкции, автоматизирующие установку стороннего ПО

    • Также в разных дистрибутивах есть свои официальные руководства по установке популярного проприетарного ПО:

      ? Руководства по установке стороннего софта: ⊚Alt, ⊚Astra, ⊚RedOS

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

      redoswelcome в ⊚RedOS

      redoswelcome в ⊚RedOS

  • [⟹] Подключить сторонний репозиторий
    для вашего дистрибутива или для совместимого дистрибутива.

    ☑️ Особенности пакетов из сторонних репозиториев: ?(?)✈️?

    ?: Исходный код ЗАКРЫТ

    ✦ Пакет содержит уже скомпилированные бинарные файлы

    Замечание:

    ✦ Так как это не из официального репозитория вашего дистрибутива, то НЕ ПРОВЕРЕНО на наличие вредоносного кода сторонними специалистами — устанавливайте и используйте на свой страх и риск.

    ?: Исходный код ОТКРЫТ, если в репозитории есть пакеты с исходниками

    ✦ В репозитории могут (должны, в случае СПО) также присутствовать пакеты с исходниками (файлы с суффикс-расширением «.src.rpm») — тогда можно проверить исходники и также пересобрать бинарный пакет на его основе.

    ✈️: Небольшой размер пакета и оптимальная скорость выполнения

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

    ?: требуются права администратора

    ✦ Для установки пакета и для подключения репозитория требуются права администратора.

    ⚠️Замечания по использованию сторонних репозиториев:

    «Сторонний» имеется ввиду по отношению к дистрибутиву. То есть создатели дистрибутива не учитывали, что вы будете использовать этот репозиторий и НЕ могут гарантировать, что он не поломает вам систему. (Использовать только на свой страх и риск — может содержать вредоносный или не протестированный код).

    • Не забывайте отключать сторонние репозитории (если репозиторий содержит не только дополнительное прикладное ПО, но и системные утилиты/библиотеку — как, например, официальный репозиторий другого, но совместимого дистрибутива) после установки из них дополнительного прикладного ПО. И не стоит обновлять целиком систему с подключенным сторонними репозиториями.

    • Не стоит устанавливать из стороннего репозитория системное ПО (например, ядро или библиотеку glibc) и ПО, влияющие на безопасность системы (например, криптографическую библиотеку openssl или pam-модули, отвечающие за аутентификацию пользователей).

    • При установке нового пакета из стороннего репозитория обращайте внимание, будут ли удаляться как конфликтующие какие-нибудь пакеты, которые вы используете.

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

    Можно разделить на несколько видов:

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

      ? Примеры сторонних репозиториев от разработчиков программы:

    • сторонний пользовательский репозиторий-коллекция — это как коллекция пакетов, которые пользователи собирают (компилируя из исходников) для себя (соответственно, под используемую ими версию дистрибутива) и выкладывают эти репозитории в общий доступ. Многие производители дистрибутивов поддерживают и предоставляют инструментарий для сборки и свои серверы для размещения подобных пользовательских репозиториев, чтобы была простая возможность найти и установить дополнительное ПО, не вошедшее в официальный репозиторий.

      ? Примеры пользовательских репозиторий-коллекций:

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

      ? Примеры сторонних репозиториев-коллекция организаций/сообществ:

      • Репозиторий Sisyphus для ⊚Alt — нестабильный репозиторий с самым свежим программным обеспечением. Не рекомендуется для использования простыми пользователями, так как это тестовая ветка репозитория (предназначена для разработчиков) и работа пакетов тщательной проверки еще не подвергалась, но если вдруг руки чешутся поломать нужна самая последняя версия пакета, то можно подключить этот репозиторий и установить пакеты из него (но НЕ рекомендуется обновлять систему с этого репозитория).

      • Репозиторий Debian можно подключить в ⊚AstraLinux в качестве стороннего репозитория дополнительного ПО. Только НЕ стоит обновлять систему с этого репозитория, так как это не репозиторий с дополнительными пакетами, а на нем есть также и системные пакеты и после такого обновления система, скорее, превратится в ⊚Debian. Также стоит учитывать список ПО, которые не рекомендуется устанавливать и обновлять из сторонних репозиториев в ⊚AstraLinux, так как это нарушит требования безопасности информации, указанной в сертификатах.

      • Репозиторий EPEL для ⊚RedHat-совместимых дистрибутивов (например, ⊚RedOS) содержит десятки тысяч пакетов дополнительного прикладного (не системного) ПО.

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

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

      ? Структура репозиториев ⊚Debian: Stable/Unstable/Testing и подразделы: main, contrib, non-free

      Для примера приведу разновидности репозиториев дистрибутива ⊚Debian (похожее деление можно заметить и у других дистрибутивов, хотя названия могут отличаться):

      • Stable — основной репозиторий. С проверенными и оттестированными пакетами. Рекомендуется использовать пользователям.

      • Testing — репозиторий только для разработчиков и тестеров дистрибутива. В него попадают новые пакеты с НЕ оттестированным функционалом.

      • Unstable/sid — репозиторий только для разработчиков дистрибутива. В него попадают новые совершенно НЕ проверенные (даже на то, что они собираются) пакеты.

      • Unofficial — различные неофициальные репозитории

      • Updates — обновления пакетов. Можно разделить на:

        • Обновления безопасности, которые исправляют только уязвимости и не добавляют новый функционал.

        • Новые версии пакетов, добавляющие новые функции обновляемому ПО.

        • Backports. Обычно в стабильной версии дистрибутива (особенно это касается коммерческих дистрибутивов, и очень сильно касается сертифицированных дистрибутивов, так как требуется время на тестирование и сертификацию любых изменений) используются не самые последние версии программ. И когда в мире выходит обновление безопасности для новой версии программы, это обновление может не подойти для той старой версии программы, которая используется в дистрибутиве. В этом случае обновление исправляют, чтобы оно применялось для старой версии ПО. Подобные модифицированные под старые версии ПО обновления и называют backports, и часто их выносят в отдельный репозиторий.

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

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

      • non-free — проприетарное ПО (различные не открытые прошивки, кодеки и т.п.). Не рекомендуется использовать, так как нет возможности проверить исходный код, но есть пользователи, которым может понадобиться подобное ПО.

      • contrib — стороннее ПО, которое использует non-free компоненты или собиралось при их помощи. Не рекомендуется использовать, но есть пользователи, которым может понадобится подобное ПО.

      ? Структура репозиториев ⊚Ubuntu: Main, Universe, Restricted, Multiverse

      Репозитории Ubuntu делятся по принципу свободное/несвободное и поддерживаемое/неподдерживаемое (то есть фирма ?Canonical (разработчик Ubuntu) предоставляет официальную коммерческую техподдержку по этим программам и обязуется выпускать обновления для пакетов в этом репозитории в рамках периода поддержки (сейчас для LTS версии — это пять лет).

      Свободное ПО

      Несвободное ПО

      Поддерживаемое

      Main

      Restricted

      Неподдерживаемое

      Universe

      Multiverse

      • Main — бесплатное программное обеспечение с открытым исходным кодом, поддерживаемое Canonical.

      • Universe — бесплатное программное обеспечение с открытым исходным кодом, поддерживаемое сообществом. Коллекция доступного свободного ПО без каких-либо гарантий на техподдержку и появление обновлений в дальнейшем.

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

      • Multiverse — программное обеспечение, использование которого ограничено авторскими правами или юридическими вопросами — использование на свой страх и риск.

      ? Структура репозиториев ⊚SUSE: модули и расширения

      У достаточно известного коммерческого дистрибутива ⊚SUSE (а точнее SLES — SUSE Linux Enterprise Server) репозиторий разбит на множество репозиториев (их называют модули и расширения) по назначению, каждый из которых имеет свой уровень и период поддержки, а также стоимость лицензии (модули входят в стоимость SLES, а расширения приобретаются отдельно):

      • Модули:

        • Basesystem — базовая система, что-то вроде, того что обычно входит в минимальную установку

        • Containers — инструментарий для контейнеров

        • Desktop Applications — среда рабочего стола и приложения для нее

        • Development Tools — инструменты для разработчиков ПО и компиляции приложений

        • Legacy — пакеты, используемые в предыдущих версиях дистрибутива и помеченные как устаревшие в текущей версии

        • NVIDIA Compute — драйверы NVIDIA

        • Public Cloud — инструменты для создания и развертывания образов системы в облачных средах

        • Python 3 — соответственно поддержка последней версии Python

        • Server Applications — различные сетевые службы, такие как DNS, DHCP, FTP и т.д.

        • Transactional Server — поддержка транзакционных обновлений (позволяет откатывать неудачные обновления)

        • Web and Scripting — пакеты для веб-сервера

        • …

      • Расширения:

        • SUSE Package Hub — огромное количество дополнительного прикладного ПО, поддерживаемого сообществом

        • Live Patching — инструментарий для обновления системы и ядра без перезагрузки

        • High Availability — различные решения для построения кластеров

        • High Performance Computing — для организации суперкомпьютера

        • Real Time — пакеты для организации системы реального времени

        • Workstation Extension — дополнительные графические приложения для организации рабочей станции: офисные пакеты, графические редакторы, почтовый клиент, …

        • …

      ? Примеры репозиториев: ⊚Alt, ⊚RHEL (Fedora, CentOS) ⊚SUSE, ⊚RedOS

      • Для сравнения в отечественном ⊚Alt:

        • репозитории p9, p10, … аналогичны по назначению stable-репозиторию у ⊚Debian.

        • репозиторий Sisyphus как testing-репозиторий у ⊚Debian.

        • Также предлагается продукт Альт Платформа для создания на его основе своих дистрибутивов другими организациями.

      • Коммерческие дистрибутивы часто не открывают свои репозитории для разработки и часто поддерживают разработку совместимого дистрибутива сообществом, и данный дистрибутив выступает в качестве тестовой площадки для проверки новых технологий:

        • ⊚Fedora — дистрибутив, разрабатываемый сообществом при поддержке RedHat. Являлась тестовой площадкой для ⊚RHEL (хотя ⊚RHEL серверный дистрибутив, а ⊚Fedora — для рабочих станций) до появления ⊚CentOS_Stream.

        • ⊚CentOS_Stream — официально бета-версия ⊚RHEL (RedHat Enterprise Linux).

        • Наработки из ⊚OpenSUSE затем используются в коммерческом ⊚SLES (SUSE Linux Enterprise Server).

        • На основе ⊚Debian создаются многие коммерческие дистрибутивы: ⊚Ubuntu, ⊚AstraLinux, … То есть официальный репозиторий Debian’а, можно сказать, используется ими в качестве тестового репозитория.

      • В ⊚RedOS используется следующая структура репозиториев:

        • os/ – базовый репозиторий

        • kernels/ – репозиторий ядер

        • updates/ – репозиторий обновлений

    • ? https://repology.org — различная статистика (количество пакетов, версии программ, …) по репозиториям разных дистрибутивов.

  • [⟹] Скачать пакет

    • Скачиваете пакет с сайта ПО (или прописывайте репозиторий с пакетами) и устанавливаете [⟹ через классический продвинутый пакетный менеджер] (который используется в вашем дистрибутиве apt/apt-get/yum/dnf/zypper/pacman/…) — многие из них умеют устанавливать пакеты не только из репозитория по имени пакета, но и по имени файла из локального каталога (только нужно указать путь к файлу, а не только имя пакета). К тому же, если для скачанного пакета понадобятся зависимости, пакетный менеджер подтянет их из репозитория (если необходимых зависимостей нет в вашем репозитории, то, вероятно, пакет не под ваш дистрибутив и рассмотрите вариант [➜ Пакет под НЕ совместимый дистрибутив]).
      Например:
      dnf install ~/Загрузки/PACKAGE_NAME-1.2.3.x86_64.rpm
      или
      apt install ~/Загрузки/PACKAGE_NAME-1.2.3.x86_64.deb

      ? Примеры: Microsoft, Zoom, TrueConf, Яндекс-Браузер, МойОфис

      • Microsoft:

        • Думаю, для многих может оказаться открытием, что даже (неожиданно!!!) Microsoft свое различное ПО выкладывает в формате rpm/deb-пакетов для Linux: https://packages.microsoft.com/

      • Zoom:

        • Обычно различный коммерческий софт предоставляют на своем сайте возможность скачать пакет под некоторые популярные дистрибутивы Linux. Там же выложен архив с portable-версией их программы для остальных менее популярных дистрибутивов.

          • Не сочтите за рекламу. Данная программа приведена как пример того, что недавние Windows-пользователи ищут на Linux. Сам же не пользуюсь подобным закрытым ПО, которое открывает удаленный доступ к вашему компьютеру (даже, если вы не организатор встречи, а подключаетесь только кого-нибудь послушать). В крайнем случае такие программы следует использовать только на компьютерах без персональных и/или коммерческих данных.

      • TrueConf:

        • Отечественный аналог Zoom (также проприетарный и зачем-то при установке серверной версии пакета добавляющий своему пользователю право на чтение вашего файла /etc/shadow), предоставляет возможность скачать пакеты под отечественные и некоторые другие дистрибутивы Linux.

      • Яндекс-Браузер:

        • Предлагает скачать либо deb-, либо rpm-пакет (если открыть эту страницу на Linuх) для соответственно Debian-совместимых и RedHat-совместимых дистрибутивов.

      • МойОфис:

        • Предлагает скачать либо deb-, либо rpm-пакет (если открыть эту страницу на Linuх) для соответственно Debian-совместимых и RedHat-совместимых дистрибутивов.

2b. [➜] Пакет под НЕ совместимый дистрибутив

  • [⇫ Алгоритм]:

    • Варианты решения:

      • [⟹] Использовать другой пакетный менеджер или формат пакета

        • [⟹] кроссдистрибутивные форматы пакетов:

          • [⟹] AppImage

          • [⟹] Flatpak

          • [⟹] Snap

          • [⟹] архив с исполняемыми файлами или самораспаковывающийся архив-установщик

          • Установить другой классический пакетный менеджер: rpm/dpkg, yum/dnf/apt

        • [⟹] альтернативные пакетные менеджеры (pip, gem, npm, cargo, …)

          • [⟹] pip (Python)

          • [⟹] gem (Ruby)

          • [⟹] npm (nodejs/JavaScript)

          • [⟹] cargo (Rust)

          • composer (PHP)

        • [⟹] использовать контейнеры: docker, podman, …

      • [⟹] Конвертировать пакет в формат своего дистрибутива

      • [⟹] Написать в техподдержку

      • [⟹] Компиляция из исходников и сборка пакета

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

  • Использовать другой пакетный менеджер или формат пакета

    • Кроссдистрибутивные форматы пакетов — обычно это решение используется для больших программ с большим количеством зависимостей, и поэтому их удобнее (для разработчиков дистрибутивов и пользователей) устанавливать в виде ?portable-ПО с встроенными всеми необходимыми библиотеками:

      • ?AppImage — это тип исполняемого файла, содержащий в себе portable-приложение в виде само-распаковывающегося архива.

        ☑️ Особенности Appimage: ???(⚠️)

        ?: Пакет не содержит исходники

        ✦ Подготовленная бинарная сборка, многие на основе открытых исходников, но сложно проверить наличие ?НДВ.
        ✦ Дистрибутиво-независимый формат — один и тот же пакет можно использовать в совершенно разных дистрибутивах.
        ✦ Есть несколько сторонних сайтов-коллекций ссылок на AppImage-пакеты (AppImageHub, AppImage.github.io, …), в которых удобно организоаван поиск пакетов (разбиты по категориям, есть описания, скриншоты, комментарии пользователей и очки рейтинга).

        ?: Размер и скорость менее оптимальны, чем у аналога в виде классического пакета, собираемого из исходников под вашу ОС

        ✦ Размер пакетов БОЛЬШОЙ, так как включает в себя все необходимые зависимости.
        ✦ МЕДЛЕННЕЕ запускается, так как при запуске распаковывается.

        ?: НЕ требуются права администратора

        ✦ Можно одновременно использовать разные версии программы.
        ✦ Не устанавливается в систему — запускается без установки

        ?Замечание: Не встроено в систему

        ✦ Не будет использовать встроенные в систему библиотеки и темы оформления, то есть может внешне отличаться от оформления других приложений.
        ✦ Не появится ярлык приложения в стартовом меню (?меню «Пуск») среды рабочего стола. (Можно добавить ярлык вручную)
        ✦ Не будет обновляться при обновлении системы, понадобится вручную искать и устанавливать новые версии программы.

        ? Использование AppImage

        • Предварительные действия:

          • Не требуется установка специального пакетного менеджера.

          • В некоторых серверных дистрибутивах может понадобиться разрешить пользователю использовать утилиту fuse.

        • Поиск программ:

        • Установка:

          • Установка не производится — для запуска требуется:
            — скачать файл с расширением AppImage
            — выставить на него право «исполняемый» (в свойствах файла в файловом менеджере или командой: chmod +x FILE.AppImage)

          • [Дополнительно] При желании можно вручную добавить ярлык на исполняемый файл в стартовое меню (?меню «Пуск») среды рабочего стола)

          • [Дополнительно] [eepm repack ⟹] умеет конвертировать AppImage-пакет в формат классического пакета для системы — дополнительно добавляет иконку в меню запуска приложений

        • Запуск:

          • Запустить его (кликнув по файлу в файловом менеджере или из командной строки: ./FILE.AppImage )

        ? Документация по Appimage: ⊚Alt, ⊚AstraLinux, ⊚RedOS

      • ?Flatpak — формат пакетов со специальным пакетным менеджером для установки переносимых приложений: доступны flatpak-пакеты Zoom, Telegram, VSCode, Discord и многие другие.

        ☑️ Особенности Flatpak: ???

        ?: Пакет не содержит исходники

        ✦ Подготовленная бинарная сборка, многие на основе открытых исходников, но сложно проверить наличие ?НДВ.
        ✦ Дистрибутиво-независимый формат — один и тот же пакет можно использовать в совершенно разных дистрибутивах.
        ✦ Помимо FlatHub (репозитория разработчика данного формата) можно использовать свои или сторонние репозитории flatpak-пакетов.

        ?: Размер и скорость менее оптимальны, чем у аналога в виде классического пакета, собираемого из исходников под вашу ОС

        ✦ Размер пакета БОЛЬШОЙ, так как включает в себя все необходимые зависимости.
        ✦ МЕДЛЕННЕЕ запускается, так как при запуске распаковывается.

        ?: НЕ требуются права администратора

        ✦ Можно одновременно использовать разные версии программы.
        ✦ Выполняются почти из песочницы (без влияния на основную систему и другие приложения).
        ✦ Поддержка установки flatpak-пакетов есть в некоторых предустановленных графических менеджерах пакетов («Центр приложений»: GNOME Software, KDE Discover, …) в основном в дистрибутивах, предназначенных для простых пользователей.

        ? Использование Flatpak

        • Предварительные действия:

          • Установить пакет flatpak (присутствует по умолчанию в большинстве дистрибутивов, за исключением ⊚Ubuntu, так как разработчики ⊚Ubuntu стараются таким образом сделать более популярным свой аналогичный формат Snap).

          • Необходимо подключить репозиторий Flathub (более 4500 пакетов) — в некоторых дистрибутивах, например в ⊚Alt, установив пакет flatpak-remote-flathub, или командой в одну строку:
            flatpak remote-add --if-not-exists flathub https://dl.flathub.org/repo/flathub.flatpakrepo

          • Посмотреть список подключенных репозиториев:
            flatpak remote-list
            или (тоже самое)
            flatpak remotes

        • Информация и поиск программ:

          • Полный список доступных программ:
            flatpak remote-ls

          • Поиск программ (и узнать ID приложения):
            flatpak search NAME

          • Список установленных программ:
            flatpak list

          • Информация по установленной программе:
            flatpak info ID-приложения

        • Установка:

          • flatpak install ID-приложения

            • например:
              Установка приложения Bottles (упрощает установку игр и приложений, написанных под Windows, с использованием разновидностей эмулятора wine и автоматизированной доустановки необходимых dll-библиотек):
              flatpak install com.usebottles.bottles
              Установка мессенджера Телеграм:
              flatpak install org.telegram.desktop

        • Запуск:

          • flatpak run ID-приложения

        ? Документация по Flatpak: ⊚Alt, ⊚RedOS

      • ?Snap — формат пакетов со специальным пакетным менеджером для установки переносимых приложений.

        ☑️ Особенности Snap: ???

        ?: Пакет не содержит исходники

        ✦ Подготовленная бинарная сборка, многие на основе открытых исходников, но сложно проверить наличие ?НДВ.
        ✦ Дистрибутиво-независимый формат — один и тот же пакет можно использовать в совершенно разных дистрибутивах.
        ✦ Есть только один репозиторий пакетов (SnapStore), который управляется коммерческой компанией ?Canonical. На нём также есть описания, рейтинги, обзоры и скриншоты поставляемых программ.

        ?: Размер и скорость менее оптимальны, чем у аналога в виде классического пакета, собираемого из исходников под вашу ОС

        ✦ Размер пакета БОЛЬШОЙ, так как включает в себя все необходимые зависимости.
        ✦ МЕДЛЕННЕЕ запускается, так как при запуске распаковывается.

        ?: требуются права администратора

        ✦ Но можно делегировать возможность установки snap-пакетов определенным пользователям или группам через polkit (предоставив доступ к действию io.snapcraft.snapd.manage) или через правила sudo.
        ✦ Выполняются в изолированной среде (с минимальным влиянием на основную систему и другие приложения).
        ✦ Поддержка установки snap-пакетов есть в некоторых предустановленных графических менеджерах пакетов («Центр приложений»: KDE Discover, …) в основном в дистрибутивах, предназначенных для простых пользователей (при этом, в ?GNOME Software с 2019 убрали поддержку snap-пакетов).

        ? Использование Snap

        • Предварительные действия:

          • В основном развивается и используется по умолчанию в ⊚​Ubuntu и основанных на Ubuntu дистрибутивах, но доступен и в других дистрибутивах.

          • Требуется установить пакет snapd

          • Запустить службу:
            systemctl enable --now snapd.socket

        • Информация и поиск программ:

          • Поиск пакетов:
            snap find NAME

          • Список установленных программ:
            snap list

          • Информация по установленной программе:
            snap info NAME

        • Установка:

          • snap install NAME

            • Пример: snap install snap-store — установка «Центра приложений» (GUI для поиска и установки snap-пакетов)

        • Запуск:

          • snap run NAME

        ? Документация по Snap: ⊚RedOS, ⊚AstraLinux

      • Архив с исполняемыми файлами (ПО.tar.gz)
        и самораспаковывающийся архив-установщик (INSTALL.run или INSTALL.sh) раньше (до появления AppImage), да и сейчас еще можно встретить, что некоторые программы (особенно проприетарные) распространяются в виде бинарного файла (с названием типа «INSTALL.run») или скрипта(с названием типа «INSTALL.sh»), которые являются либо само-распаковывающимся архивом с программой, либо скриптом, анализирующим к какому семейству относится используемый вами дистрибутив, часто спрашивающий дополнительную информацию, а также устанавливающий или просящий установить определенные необходимые пакеты-зависимости, после чего устанавливает свою программу. В отличии от AppImage для его запуска требуются права root’а.

        ☑️ Особенности архивов-установщиков: ?(⚠️)??

        ?: Исходный код ЗАКРЫТ

        ✦ Подготовленная бинарная сборка на основе закрытых исходников — сложно проверить наличие ?НДВ.
        ✦ Минусы проприетарного ПО >>>

        ПРЕДУПРЕЖДЕНИЕ:

        ✦ Очень сильно рискуете, используя приложение в таком формате, так как запускается не проверенный сообществом код, да еще и root‘ом.
        ✦ Использовать либо из проверенных источников, либо в изолированных системах, в которых не хранится секретная информация.
        ✦ Если в формате скрипта (INSTALL.sh) рекомендуется тщательно прочитать этот скрипт перед запуском его root’ом на предмет поиска сомнительных действий и если такие найдутся, то лучше не запускать его.
        ✦ Рассмотреть какой-нибудь вариант запуска этого приложения в изолированной среде: виртуализация, контейнеры, песочницы (chroot, firejail, namespaces-изоляция, …) или используя мандатные ограничения (SELINUX-политики, AppArmor-политики, …)

        ?: Размер и скорость менее оптимальны, чем у аналога в виде классического пакета, собираемого из исходников под вашу ОС

        ✦ Размер пакета БОЛЬШОЙ, так как включает в себя все необходимые зависимости.
        ✦ МЕДЛЕННЕЕ запускается, так как при запуске распаковывается.

        ? Использование архив с исполняемыми файлами

        Не путать с архивом с исходниками — компилировать не понадобится.

        Это, скорее, что-то типа portable-приложения в виде архива. Данный формат предполагает, что пользователь распакует архив и найдет в нём инструкцию (текстовый README-файл) или просто бинарную утилиту, которую можно запустить.

        ? Использование INSTALL.run / INSTALL.sh

        (Допустим, вы скачали файл INSTALL.run в свою директорию «Загрузки»)

        • Перейти в директорию со скаченным файлом:
          cd ~/Загрузки

        • Сделать его исполняемым:
          chmod +x INSTALL.run

        • Запустить либо от пользователя (если этот бинарник/скрипт запускает, а не устанавливает программу):
          ./INSTALL.run

        • Либо от root’а (если этот бинарник/скрипт добавляет репозитории и устанавливает программу):
          sudo ./INSTALL.run(или, переключившись утилитой «su -«, и из под root’а запустить «./INSTALL.run»)

        • eget (?) — утилита для скачивания ПО в виде небольших предварительно скомпилированных утилит из GitHub. Оно ищет в, указанном в виде аргумента команды, github-репозиторие исполняемый файл (в том числе и внутри архивов, а также переименует appimage-файл) и копирует его в /usr/local/bin

      • Установить другой классический пакетный менеджер. Не стал бы такое рекомендовать, и это пример, скорее, из раздела «и так можно», хотя обычно так не делают. Главное в таком подходе не сильно увлекаться потом установкой пакетов в другом формате и, следовательно, от совсем другого дистрибутива, чтобы не поломать систему. Но небольшое прикладное ПО, не меняющие системные библиотеки, таким образом можно доустановить.

        ? Пример: yum в ⊚AstraLinux, dpkg в ⊚Alt

        • ⊚AstraLinux:

          • как например, описано в статье «Использование yum в ⊚АстраЛинукс». То есть в дистрибутиве с deb-пакетами и пакетным менеджером apt устанавливают пакетный менеджер yum для того, чтобы ставить пакеты в формате rpm.

        • ⊚Alt:

          • можно установить dpkg и dnf вдобавок к используемым по умолчанию rpm/apt.

    • Использовать альтернативные пакетные менеджеры (pip, gem, npm, cargo, composer, …) для поиска в огромном количестве небольших утилит в соответствующих индексах зарегистрированных проектов. Только нужно понимать, что это скорее поисковики по централизованным базам/каталогам программ (в которую их добавляют сами разработчики программ) и иногда эти утилиты никем сторонним (кроме таких же пользователей, как и вы) не проверялись на наличие вредоносного кода (хотя при наличии жалоб от пользователей программу могут убрать из базы/каталога).

      • ?pip (Python) — более 500 тысяч проектов, написанных на Python.

        ? Использование pip

        • Предварительные действия:

          • Необходимо установить утилиту pip(в разных дистрибутивах пакет может называться по-разному: pip, python3-pip или python-pip, python3-module-pip, …)

            • Утилита может называться: pip, pip3 (чтобы отобразить используемую версию Python)

            • также в некоторых дистрибутивах в репозитории есть утилита pipx, которая устанавливает каждый python-пакет в отдельном виртуальном окружении (в чем-то похоже на использование pip с venv)

          • Чтобы не поломать зависимости с установленными Python-пакетами/модулями из классического репозитория системы, рекомендуется для установки Python-пакетов через pip предварительно включить использование виртуального окружения (например, через модуль venv или conda):

            • python3 -m venv DIR

            • source DIR/bin/activate

            • и дальше все остальные команды выполнять в этом терминале с правильно настроенным виртуальным окружением

        • Информация и поиск программ:

          • Название пакетов и описания ищут на https://pypi.org/

          • Также можно установить утилиту pip_search и затем использовать её для поиска пакетов:

            • pip install pip_search; pip_search PKG

        • Установка:

          • pip install PKG

            При этом эти пакеты выкачиваются из каталога PyPI (Python-PackageIndex), в котором свои пакеты регистрируют сами разработчики программ.

          • Также часто различные приложения с git-ресурсов, требующие доустановку необходимых Python-модулей, содержат их список в файле с названием requirements_versions.txt, так что обычно установка таких приложений выполняется примерно так:

            • git clone https://github.com/USER/APP

            • cd APP

            • pip3 install -r requirements_versions.txt

        • Запуск:

          • так как pip устанавливает утилиты в домашней директории пользователя в поддиректорию .local/bin/, то может понадобится прописать настройку для командного интерпретатора (например, для bash — в ~/.bashrc):
            export PATH="$PATH:~/.local/bin/"

          • Запуск из командной строки просто по имени утилиты:
            NAME
            или
            ~/.local/bin/NAME

      • ?gem (Ruby) — более 180 тысяч проектов, написанных на Ruby.

        ? Использование gem

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

        • Предварительные действия:

          • Необходимо установить утилиту gem (обычно пакет gem или rubygems)

        • Поиск и информация о пакете:

          • gem search PKG
            или поиск [Search Gems] на сайте rubygems.org
            или, например, в каталоге ruby-toolbox.com

          • gem search PKG -d # с описаниями

        • Установка:

          • gem install PKG

          • gem install PKG --install-dir DIR
            # установка в определенную директорию (там также создаются поддиректория bin/ с скриптом для запуска)

        • Информация:

          • gem list # список установленных

          • gem info PKG # информация об установленном

          • gem contents PKG # содержимое и расположение

      • ?npm (nodejs/JavaScript) — более 1,3 миллиона пакетов, написанных на JavaScript и исполняемых через Node.js.

        ? Использование npm

        ? Использование npm(Мои знания по npm достаточно поверхностны. Могу ошибаться, если заметили ошибку поправьте в комментариях)

        • Предварительные действия:

          • Необходимо установить утилиту npm (обычно пакет npm)

        • Поиск и информация о пакете:

          • npm search PKG
            или поиск [Search packages] на сайте npmjs.com

          • npm view PKG

        • Установка:

          • nmp install PKG

          • Также часто различные приложения с git-ресурсов, требующие доустановку необходимых NodeJS-модулей, содержат их список в файле package.json, так что обычно установка таких приложений выполняется примерно так:

            • git clone https://github.com/USER/APP

            • cd APP

            • npm install

        • Запуск:

          • npm run NAME

      • ?Cargo (Rust) — более 151 тысяч проектов, написанных на Rust.

        ? Использование cargo

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

        • Предварительные действия:

          • Необходимо установить утилиту cargo (обычно пакет cargo)

        • Поиск пакетов:

          • cargo search PKG
            или поиск [Search packages] на сайте crates.io (или в другом репозиториях указанных в ~/.cargo/registry/index/*/config.json)

        • Установка:

          • cargo install PKG

          • Установка Rust-приложения с git-ресурса:

            • git clone https://github.com/USER/APP

            • cd APP

            • cargo build

          • Список установленных пакетов:

            • cargo install --list

        • Запуск:

          • так как cargo устанавливает утилиты в домашней директории пользователя в поддиректорию ~/.cargo/bin/, то может понадобиться прописать настройку для командного интерпретатора (например, для bash — в ~/.bashrc):
            export PATH="$PATH:~/.cargo/bin/"
            И запуск из командной строки просто по имени утилиты:
            NAME или ~/.cargo/bin/NAME

      • ?Composer (PHP) — более 395 тыс пакетов, написанных на PHP.

      • … (вероятно, аналогичные решения есть или появятся и для других языков программирования)

    • Использовать контейнеры: docker, podman, …

      • Также некоторые приложения/службы распространяются для Docker/Podman/Lilipod/.. в виде контейнеров (например, с DockerHub).

        • К тому же можно использовать distrobox для интеграции запущенного окружения из контейнера с хостовой системой.

  • Конвертировать пакет в формат своего дистрибутива:

    • (тернистый путь) утилиты rpm2cpio позволят распаковать как архив rpm-пакеты и, аналогично, dkpg-deb распаковывает deb-пакеты. Затем их можно собрать в deb-пакет (утилитой debuild или dpkg-deb) или в rpm-пакет (утилитой rpmbuild), или просто раскопировать файлы из архива в систему (проблема только в том, что понадобится вручную убедиться, что установлены все необходимые зависимости и нужных версий, а также сохранить где-то список файлов, чтобы потом, например, знать, что именно удалить, если пакет не понадобится или если понадобится обновить эту программу).

    • утилита ?alien конвертирует из формата в формат deb/rpm/tgz

    • (вариант попроще) у утилиты eepm (доступной для многих отечественных дистрибутивов) есть подкоманда «repack«, которая позволяет автоматизировать процесс перепаковки из формата пакета для другого дистрибутива в формат пакета вашего дистрибутива (в том числе из deb в rpm и наоборот):
      eepm repack /PATH/PKG.deb
      То есть, если есть пакет под другой дистрибутив, можно его скачать и переконвертировать под свой дистрибутив и затем установить сконвертированный пакет.

  • Написать в техподдержку вашего дистрибутива с просьбой добавить в репозиторий соответствующий пакет (всё таки данная возможность стала гораздо доступнее при использовании отчественных дистрибутивов — стоит воспользоваться этой появившейся возможностью). Всё зависит от сложности и востребованности запрашиваемого ПО и свободного времени у создателей дистрибутива, а также условий договора на техподдержку (у клиентов коммерческих дистрибутивов). Зато пакет будет собран и протестирован специалистом дистрибутива (знающим особенности дистрибутива и не раз собиравшим пакеты). В сертифицированных дистрибутивах пакет также пройдет внешнюю проверку на наличие недокументированных возможностей.

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

    • Предпологаю, это сработает быстрее для крупного клиента коммерческого дистрибутива.

  • Компиляция из исходников и сборка пакета под свой дистрибутив

    • когда-то давно (лет 25 назад) это был основной способ установки пакетов, и тогда пользователь/админ Linux-системы должен был быть немного программистом (уметь читать и править чужой код), чтобы собрать и установить пакет из исходников. Сейчас не стал бы рекомендовать этот способ большинству — лучше поищите готовый пакет. Но у сборки из исходников есть плюсы (можно проверить код, можно написать или найти патчи, улучшающие ПО, …).

    • Для желающих в это погрузиться рекомендую попробовать установить дистрибутивы ⊚Linux_From_Scratch (дистрибутив, распространяемый в виде pdf-книги) и его русскоязычный аналог ⊚Lx4U (“Linux для себя”) , ⊚Arch, ⊚Gentoo, …

    • Обычно в архиве с исходниками есть файлы README и INSTALL и в них расписан порядок сборки (компиляции) бинарных файлов из исходников.

      • Потребуется изучить, что значит классическое заклинание:
        ./configure && make && sudo make install

      • ?CheckInstall (?): вместо «sudo make install» правильнее (в дистрибутивах на базе rpm/deb-пакетов) использовать «sudo checkinstall«

    • Также можно собрать на основе исходников (или уже скомпилированных бинарников) свой установочный пакет, например, rpm-пакет (утилитой rpmbuild, понадобится написать spec-файл) или deb-пакет.

    • Также можно создать свой репозиторий (собрав в него множество пакетов своих или сторонних разработчиков, если лицензия не запрещает): reprepro (для apt), createrepo (для dnf/yum), …

    ? Документация про сборку пакетов: ⊚​Alt, ⊚RedOS
    ☑️ Особенности ПО в исходниках: ?✈️??

    ?: Исходный код ОТКРЫТ

    ✦ Можно проверить на наличие недокументированных возможностей.
    ✦ Можно применить свои патчи (исправления) — модифицировать ПО под свои нужды.
    ✦ Можно собрать пакет «любой» дистрибутив.

    ✈️: Небольшой размер и оптимальная скорость выполнения

    ✦ Пакет нужно сначала собрать, но при сборке можно оптимизировать пакет под свою систему.

    ?: требуются права администратора

    ✦ Для сборки пакета потребуются права администратора для установки инструментов разработчика: компилятора, различных дополнительных библиотек и утилит для сборки.

    ?: требуются навыки программиста

    ✦ Понадобятся (хотя бы минимальные) навыки программиста.

1a. Популярное свободное ПО

Если же нужная вам программа есть в репозитории, то просто ставьте пакетным менеджером (apt/apt-get, dnf/yum, …), используемым в вашем дистрибутиве, и не надо ничего придумывать — это будет наиболее правильное решение. Пакетный менеджер сам найдет и скачает нужный пакет и зависимости из официальных репозиториев дистрибутива. Это основной и наиболее рекомендуемый способ установки приложений в большинстве дистрибутивов и про него вы уже сами знаете или можете точно прочитать в официальных руководствах своего дистрибутива, в отличии от описанных здесь альтернативных вариантах. Или может позже напишу отдельную статью…, или приходите к нам на курсы в Сетевую Академию ЛАНИТ — соответствующий модуль есть и в авторских курсах и в программе курсов любого вендора.

☑️ Особенности пакетов из официального репозитория: ?✈️?

?: Исходный код ОТКРЫТ

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

✈️: Небольшой размер пакета и оптимальная скорость выполнения

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

?: требуются права администратора

✦ Для установки пакета требуются права администратора (понадобится либо знать пароль пользователя root, либо настроенное делегирование обычному пользователю устанавливать пакеты через sudo или polkit-правила).
✦ Допустима установка только одной версии пакета. Бывают исключения из этого правила (к примеру, ядро, python, openssl, …).

? Документация про классический пакетный менеджер: ⊚Alt, ⊚RedOS

Добавлю только, что еще во многих дистрибутивах помимо классического пакетного менеджера бывают дополнительные GUI-утилиты для поиска и установки прикладного ПО:

  • «Центр приложений» среды рабочего стола — в некоторых графических средах рабочего стола используется своё приложение, предоставляющее пользователям графический инструмент для поиска и установки прикладного ПО: программы (отображаются только прикладные программы, без отображения отдельных пакетов и библиотек, которые будут устанавливаться) сгруппированы по категориям, есть описания, скриншоты, пользовательские оценки и т.д. Часто при помощи ?polkit-правила делегируется устанавливать программы пользователям из определенной группы без наличия у них root-доступа.

    В основном пакеты устанавливаются из официального репозитория дистрибутива, но также могут быть дополнительно подключены различные другие провайдеры альтернативных пакетов (например, FlatHub (репозиторий flatpak-пакетов или SnapStore (репозиторий snap-пакетов).

    • GNOME Software (gnome-software) используется в среде рабочего стола GNOME.
      Есть возможность использовать flatpak-пакеты, НЕ поддерживаются snap-пакеты.

      • Ubuntu Software (тот же gnome-software, но с добавлением использования snap-пакетов) используется в ⊚Ubuntu.

    • KDE Discover (plasma-discover) используется в среде рабочего стола KDE
      Есть возможность использовать flatpak- и snap-пакеты

    ? Примеры: GNOME(gnome-software) и KDE(plasma-discover)

    • gnome-software (GNOME)

      «Центр приложений» (gnome-software) в GNOME

      «Центр приложений» (gnome-software) в GNOME
      Пример приложения в «Центре приложений» (gnome-software)

      Пример приложения в «Центре приложений» (gnome-software)

    • plasma-discover (KDE)

      «Центр программ» (plasma-discover) в KDE

      «Центр программ» (plasma-discover) в KDE

  • Также к классическому пакетному менежеру в дистрибутивах с графикой прилагается GUI-утилита поиска и установки пакетов:

    • С пакетным менеджером apt, обычно (например, в ⊚Alt и ⊚AstraLinux) используют ?synaptic.

    • C пакетным менеджером dnf в ⊚RedOS используется dnfdragora.

На этом всё!
Спасибо за внимание — надеюсь кто-то смог прочитать эту статью целиком.
Ну и надеюсь узнали для себя полезное.

Мои статьи на Хабре:


ссылка на оригинал статьи https://habr.com/ru/articles/804053/

Комментарии

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *