Портативные программы для linux
Не так давно участники проекта Elementary Project представили на суд общественности новую технологию упаковки Linux-приложений под названием AppImage, которая позволяет запускать программы из одного файла на любом современном дистрибутиве без необходимости в их установке. Так ли хороша эта технология, как говорят о ней создатели, и нужна ли она Linux, мы постараемся выяснить на следующих страницах.
Введение
Преимущества таких программ виндузятники (а макосовцы — так и подавно) уже успели оценить. Их можно таскать с собой на флешке, выкладывать в Dropbox, хранить на рабочем столе вместо ярлыков, удалять одним нажатием клавиши. Они не требуют установки и не засоряют систему. Хороши со всех сторон, как ни посмотри. Но могут ли линуксоиды получить все это? Проведем эксперимент.
Попробуем скачать одно из них и запустить в первом попавшемся дистрибутиве (Kubuntu 10.04 x64). Кликаем по ссылке Opera 10.70 и через минуту получаем на жесткий диск одноименный файл весом 15 Мб, причем без расширения (позже выяснилось, что AppImage-приложения должны носить вполне осмысленное имя с расширением .appimage, но баг на их сайте все испортил).
Натравливаем на него команду file и видим «ELF 32-bit LSB executable, Intel 80386 …» — обычный исполняемый файл. Ставим бит исполнения (chmod +x Opera 10.70), запускаем… упс, библиотека libfuse.so.2 не найдена. Приложение не запускается на одном из самых популярных дистрибутивов со всеми стандартными пакетами.
ОК, делаем вид, что ничего не произошло. Для верности запускаем ldd, видим небольшое количество библиотек-зависимостей, среди которых стандартные библиотеки пакета libc — та самая libfuse и libglib-2.0.
С первой все ясно — это часть пакета fuse, используемого для создания файловых систем в пространстве пользователя (позже мы узнаем, зачем она нужна), но что же такое вторая? Это библиотека для работы с данными и их хранения, часть графического тулкита GTK (на котором основан Gnome), но может использоваться и консольным софтом, таким как mc. Она действительно есть по умолчанию в большинстве дистрибутивов, но вполне может и отсутствовать.
В Kubuntu libglib-2.0 имеется, поэтому остается только доустановить libfuse. Набираем «sudo apt-get install libfuse2» и… «Уже установлена самая новая версия libfuse2». Оказывается, либа уже в системе (действительно, она используется в драйвере NTFS-3g, который есть в любом Ubuntu), но почему ее не может найти наша программа?
Ответ на этот вопрос прост: на 64-битном ядре libfuse невозможно собрать в режиме совместимости с 32-битным софтом, коим является наша портабельная Opera 10.70. Вывод: пользуйтесь 32-битным линуксом.
Отлично, берем 32-битный Ubuntu 10.04 и ставим его в виртуалку. Скачиваем все тот же файл «Opera 10.70», делаем исполняемым, запускаем. На этот раз все прошло отлично, программа запустилась почти без задержек и продолжала нормально функционировать на протяжении двух часов. Однако после закрытия приложения на диске был найден каталог «.opera», содержащий конфигурацию браузера, что свидетельствует о достаточно серьезной недоработке технологии (какой прок от такого браузера, если я не могу утащить его вместе со своими настройками и паролями на флешке или через Dropbox).
Короче, первый раунд AppImage с треском проигрывает, так как и работает далеко не везде (64-битные машины сейчас повсеместны), и всем требованиям портабельности не соответствует. На очереди вскрытие.
Что внутри?
Попробовав портативные приложения в деле, постараемся разобраться, как они работают и чем отличаются от обычных дистрибутивных пакетов вроде Deb и RPM. Сами создатели AppImage не особо заботятся о документировании своей технологии, говоря только о том, что приложения упакованы в обычный ISO-образ, который включает в себя программу и все ее зависимости, поэтому дальнейшие изыскания придется проводить самостоятельно.
Во всем остальном это самый обычный ISO-образ, который можно смонтировать, чтобы изучить содержимое:
$ mkdir /tmp/appimage
$ sudo mount -o loop Opera 10.70 /tmp/appimage
$ cd /tmp/appimage && ls
Что мы видим внутри? Во-первых, корневой скрипт AppRun, который запускается загрузчиком сразу после монтирования ISO-образа. Его задача — подготовить приложение к работе и передать ему управление.
HERE=$(dirname $(readlink -f "$"))
export OPERA_DIR="$"/share/opera
exec "$"/lib/opera/opera "$@"
Эти три строки присваивают переменной окружения OPERA_DIR значение «/текущийкаталог/share/opera» и запускают программу из каталога «/текущийкаталог/lib/opera». Очевидно, OPERA_DIR указывает на каталог с ресурсами приложения, поэтому браузер использует его вместо стандартного «/usr/share/opera». Скорее всего, в случае многих других приложений скрипту AppRun пришлось бы использовать более хитрые приемы, чтобы переопределить дефолтовый каталог и обмануть приложение (например, символические ссылки), но здесь все просто. Следующий стандартный компонент AppImage — это файл opera-browser.desktop, содержащий метаданные приложения, такие как имя, путь к иконке (в данном случае — opera-browser.jpg), категории, к которым относится приложение, комментарии, типы ассоциированных с приложением файлов и т.д. (все в соответствии со стандартами freedesktop). Сама иконка программы дополнительно продублирована в скрытом файле .DirIcon. Остальное содержимое образа — компоненты самого приложения.
В данном случае это файлы LICENSE, install, opera-widget-manager и каталоги share и lib, представляющие собой локальную версию каталогов /usr/share и /usr/lib. Первый содержит все необходимые приложению ресурсы, документацию, man-страницы, второй — библиотеки зависимостей и сам исполняемый файл. У Opera зависимостей мало (разработчики компилируют ее статически, включая в бинарник даже библиотеку Xlib для работы с X Window), поэтому каталог lib почти пуст, только парочка библиотек самой программы и два плагина для Gstreamer. В целом, изнутри все выглядит довольно логично и просто, поэтому можно предположить, что и создавать такие образы будет легко.
AppImage своими руками
Путем вскрытия существующего AppImage-приложения мы узнали, какие компоненты оно может содержать. Обязательными из них являются всего три:
- Каталоговая структура самого приложения (бинарник, ресурсы, библиотеки-зависимости)
- Скрипт запуска приложения AppRun
- Файл .desktop, содержащий метаданные
Подыскиваем подходящий пакет и распаковываем его с помощью следующей команды:
Видим три файла: control.tar.gz, data.tar.gz и debian-binary. Первый и последний нам неинтересны, поэтому их можно смело удалять.
Второй файл содержит всю необходимую каталоговую структуру приложения как раз в нужном нам виде. Распаковываем его:
$ tar xzf data.tar.gz
И переименовываем получившийся каталог так, чтобы его новое имя заканчивалось на .appdir:
$ mv data пакет.appdir
Копируем файл имя_приложения.desktop из каталога пакет.appdir/usr/share/applications в корень каталога пакет.appdir. Помещаем туда же скрипт AppRun, загруженный с сайта Elementary Project:
Однако так просто все выглядит только на бумаге (точнее, на сайте Elementary Project). На самом деле процесс несколько сложнее. Дело в том, что .desktop-файл, представляющий собой обязательный компонент AppDir, можно найти далеко не в каждом пакете.
Изначально он был придуман для того, чтобы облегчить поиск и классификацию приложений в средах рабочего стола, поэтому в консольных приложениях его обычно нет, как нет и в старых, но хороших графических программах. Стандартный скрипт AppRun, доступный на сайте Elementary Project, также далек от идеала и не может обеспечить корректный запуск любого приложения. Все, что он делает — это выискивает в .desktop-файле путь к исполняемому файлу приложения, добавляет к путям поиска библиотек и команд локальные каталоги AppDir (например, пакет .appdir/usr/lib и пакет. appdir/usr/bin) и запускает исполняемый файл. Естественно, если обычное приложение хранит свои ресурсы где-нибудь в /usr/share, то при упаковке в AppImage они окажутся вне образа, и оно не сможет получить к ним доступ. Мы уже говорили о том, что в случае с браузером Opera эта проблема решается просто через присваивание имени нужного каталога переменной OPERA_DIR, в других случаях придется прибегать к более изощренным приемам.
История вопроса
Портабельные приложения были придуманы давно, но из-за простоты и очевидности идеи очень трудно понять, кто это сделал впервые.
Ведь даже в DOS, где о каких-то идеях и концепциях дизайна ОС говорить просто смешно, каждая вторая программа вполне могла носить статус Portable. Если же говорить о более экзотических ОС, то тут сразу вспоминается операционка компьютеров NEXTSTEP и ее более современный и разрекламированный потомок под названием Mac OS X. В этих ОС любое приложение представляет собой файл с расширением .app (на самом деле это каталог, который обрабатывается как отдельный файл), содержащий все компоненты приложения.
Еще раньше похожий подход применялся в операционной системе RISC OS, многие идеи которой позднее перекочевали в файловый менеджер ROX (об этом читай во врезке «AppImage и RISC OS»).
В UNIX-системах же подобные идеи обособления приложений в отдельные файлы и каталоги всегда считались ересью и проваливались в самом начале своего пути. Испокон веков UNIX исповедует собственную философию размещения файлов внутри файловой системы. Бинарные файлы — в одном каталоге, документы — в другом, библиотеки — в третьем. На момент появления UNIX эта идея была замечательной и делала разработчиков и пользователей счастливыми. Для просмотра доступных команд можно было вывести листинг каталога /bin, а для указания местоположения всех библиотек при сборке софта указать каталог /lib. Проблема этой идеи лишь в том, что она не рассчитана на установку дополнительного софта. Когда UNIX и философия открытых исходников стали популярны, количество стороннего ПО возросло в сотни раз, и с ним необходимо было что-то делать (не использовать же метод «make install» всю оставшуюся жизнь). И вот, чтящие традиции юниксоиды вместо того, чтобы действительно решать проблему, пошли по проторенной дорожке и создали пакетные менеджеры, которые встраивают новый софт в уже известную каталоговую структуру, предложенную еще 40 лет назад, а все те, кто двинулся иными путями, были объявлены иноверцами.
Выводы
AppImage-приложения не такие уж и портабельные, как заявляют их создатели, к тому же их просто делать только на бумаге. Скорее всего, они не займут достойное место в истории Linux, зато в очередной раз доказывают правильность утверждения о том, что домашний Linux должен отличаться от Linux'а серверного.
AppImage и RISC OS
В 1988 году компания Acorn Computers выпустила операционную систему RISC OS 2.00, предназначенную для компьютеров собственного производства. Кроме идеи файлов как логического центра графического интерфейса, операционка предлагала еще одну интересную концепцию под названием AppDir: любое приложение представляло собой специальный каталог, имя которого начиналось с восклицательного знака. При виде такого каталога файловый менеджер автоматически принимал его за исполняемый файл, а при клике — запускал файл !Run, расположенный внутри. Позже эту идею сперли создатели NEXTSTEP, но гораздо более интересным для нас является тот факт, что она же была реализована в файловом менеджере ROX-Filer (имя которого так и расшифровывается — RISC OS on X).
Создатели ROX лишь немного изменили первоначальную идею, заменив имя файла !Run на AppRun, файла !Sprites — на .DirIcon, выкинули из названия восклицательный знак и добавили вместо него расширение .appdir. Все это без изменений перекочевало в AppImage и обзавелось обязательным .desktop-файлом.
Толстый эльф
Год назад Ryan C. Gordon объявил о создании нового формата исполняемых файлов FatELF, который позволяет выполнять один и тот же бинарный файл на разных архитектурах. Например, без изменений запускать программу на процессорах архитектуры ARM и x86. В совокупности с идеей портабельных приложений FatELF позволил бы создать по-настоящему универсальные программы, которые работают везде и всегда.
То что для Windows делают portable-версии программ — я знал. Но что такое существует для Linux — для меня было открытие.
Portable-версии программ для Linux (в том числе и Ubuntu), можно скачать с сайта PortableLINUXapp.
Для того чтобы их запустить нужно сделать файл выполняемым. Для этого нужно щёлкнуть по нему правой кнопкой мышки, в контекстном меню выбрать пункт «Свойства». В открывшемся окне перейти на вкладку «Права» и установить флаг в поле «Позволять выполнение файла как программы».
Или из терминала:
где
MyDownloadedApp — путь к файлу, который был скачан.
Может пригодиться тем, у кого в офисах установлен Linux и админ мало того, что выдал права пользователя, так ещё и некоторые «нужные» программы удалил 🙂
P.S.
Узнал об этом из Juick.
Портативные (portable) версии программ для Linux: 18 комментариев
Глупость сморозили, уважаемый, я рад, что папка home используется по полной, иначе бы не имела большого смысла на отдельном разделе. Хотя соглашусь, что данные в папке сомой софтины были бы не лишними.
vanoc,
chmod +x file
равнозначно
chmod a+x file
То есть даёт разрешение выполнять этот файл все. Другими словами у файла становятся права 755. А если сделать как написал я
chmod u+x file
то право исполнения файла появиться только у его владельца, то есть права у файла будут 744.
На мой взгляд это как-то более правильно.
Э-эээ какбе умный админ отбирает права у тупых юзвергов. Статья ни о чем, т.к. при грамотно настроенных политиках простому пользователю сделать файл исполняемым НЕРЕАЛЬНО!
Я сам админю (около 150 машин). У меня мурашки поползли от заголовка! Не надо так пугать админов.
кир, я очень рад что вы настоящий профессионал в своём деле, но не забывайте и о том, что есть «системные администраторы», которые считают что самые лучшие настройки — это настройки по умолчанию. И таких, как показывает мой опыт, большинство 🙂
Прошу прощения! Файлы есть! Это я их не видел. Я только начинаю разбираться в Ubuntu. Увидел файлы при запуске Wine File. Можно ли сделать так, чтобы они отображались в Gnome Commander?
В комментариях говорилось о том, чтобы написать скрипт, который будет перемещать рабочие файлы приложений в home перед его запуском и на сменный носитель после завершения работы. Может быть кто-нибудь приведет пример такого скрипта? 😉
Anton, я решил, что ответ лучше разместить на форуме: Что за х*йня этот Linux!.
В операционной системе Windows мы довольно часто используем портативные программы. Это программы которые не требуют установки, сохраняют конфигурационные файлы при себе и запускаются независимо от установленных в системе компонентов. Их возможности могут быть очень полезны при создании флешек восстановления, тестирования нового программного обеспечения или просто установки новых программ, которых пока еще нет в репозиториях.
В Linux тоже есть-что то подобное. Вообще говоря, как портативную можно использовать любую программу, просто соберите программу из исходников, скачайте исполняемый файл в интернете или скиньте у знакомого и можете запускать из любой папки.
Но в таком случае остается одна проблема - это переносимость. Программа зависит от большого количества библиотек определенных версий и чтобы она заработала необходимо, чтобы все эти библиотеки были доступны в системе. Но в разных дистрибутивах, даже одни и те же библиотеки могут называться по разному. Поэтому для того чтобы реализовать портативные программы в Linux были придуманы специальные решения.
Одно из таких решений мы и рассмотрим сегодня. Это AppImage, проект основанный Elemantary и Portable Linux Apps. Одна программа состоит из одного файла образа, в котором находятся все необходимые для ее работы библиотеки, конфиги и сама программа. Правда остался один минус - конфигурация сохраняется по прежнему в домашней папке пользователя.
Фактически программа представляет собой ISO образ упакованный специальным способом и содержащий бит исполняемости. Для запуска программ не нужно ничего устанавливать достаточно скачать программу, сделать ее исполняемой и запускать. А благодаря тому, что все библиотеки находятся внутри образа, ее можно использовать в большинстве дистрибутивов Linux. Также такой способ подходит для запуска тестовых программ, которые требуют особые зависимости, но вы можете не засорять систему и просто скачать программу одним файлом.
Портативные программы в Linux
На сайте есть поиск, поэтому вы можете попытаться найти нужную программу:
Чтобы скачать программу, вам нужно перейти на вкладку Files, затем выбрать подходящую версию и просто кликнуть по ней.
После окончания загрузки осталось сделать файл исполняемым с помощью следующей команды:
И можно запускать выполнение:
Как видите программа полностью работает, и теперь ее можно записать на флешку и пробовать в другом дистрибутиве.
Но не только здесь можно найти программы в формате AppImage, некоторые разработчики сами распространяют свои продукты в этом формате, например известный видеоредактор OpenShot. Если вы хотите установить эту программу в своей системе и это не Ubuntu, вам придется очень сильно постараться. Поскольку пакеты готовы только для Ubuntu, а программа требует различные зависимости от разных пакетов Python до нужной версии Qt. Но с помощью AppImage вы можете установить программу в пару кликов.
Создание портативных программ в Linux
На самом деле в репозитории этих портативных программ не так уж много, и есть там только самые популярные, но что делать, если нужной вам программы там нет? Все просто, можно создать портативную программу Linux с помощью appimage самому, это очень легко. Для этого даже существуют инструменты с графическим интерфейсом.
В этой статье мы создадим AppImage образ для нового и очень перспективного браузера Vivaldi. Нам понадобятся два инструмента из AppImageKit - AppImageAssistant и AppDirAssisant. Первый предназначен для упаковки образа, а второй для сбора информации и файлов которые будут упакованы. Если кратко, то программа просканирует систему перед установкой программы, потом вы можете устанавливать нужную программу и ее зависимости любым способом, неважно будет то менеджер пакетов, ручная установка или сборка из исходников. Далее программа находит все измененные файлы, помещает их в специальную директорию и уже на основе той директории будет создан образ AppImage. Ну а теперь все по порядку.
Сначала скачаем нужное программное обеспечение:
Но тут есть один нюанс. Программы собраны для 32 битной архитектуры, поэтому в 64 битной системе для нормальной работы может не хватать библиотек libfuse.so-2 и libglade-2.0.so.0 в Ubuntu они очень просто устанавливаются с помощью пакетного менеджера, а для других дистрибутивов вы можете найти их в интернете и просто положить в папку /usr/lib. Во всем же остальном это такие же портативные программы, поэтому вы сможете работать с ними в любом Linux дистрибутиве.
Перейдем непосредственно к созданию портативной программы Linux, откройте AppDirAssistant, для этого в терминале перейдите в папку с программой и выполните:
Сейчас программа выполняет сканирование системы, чтобы заметить все изменения во время установки программы:
Как только сканирование будет завершено, можете переходить к установке программы любым удобным способом. Мы установим Vivaldi из скачанного с официального сайта RPM пакета, командой:
Но не забывайте, что неважно как вы устанавливаете программу.
Система будет еще раз просканирована, чтобы выявить все изменения:
Затем возможно появится вот такое окно с выбором точки просмотра:
Папки приложений по умолчанию сохраняются в папку Desktop, на данном этапе, вы можете добавить к программе дополнительные библиотеки, просто скопировав их в под-паку папка_приложения.AppDir/usr/lib/
Узнать какие библиотеки использует программа можно командой ldd, например для нашего Vivaldi:
Конечно команда не применима к скриптам, нужно найти именно исполняемый файл.
Теперь, когда все готово, можно переходить к сборке образа портативной программы AppImage. Для этого запустите утилиту AppImageAssistant:
Дальше выберите папку с только что созданной AppDir приложения:
После этого, сразу же начнется упаковка образа:
Затем, вы можете взять готовую программу в папке
/Desctop, скопировать ее куда-нибудь и можно запустить:
Как видите все работает. Можно скидывать программу на флешку и пользоваться в любой системе.
Выводы
Портативные программы Linux - это очень спорная технология. С одной стороны это очень удобно, потому что можно распространять софт поддерживаемый любым дистрибутивом, решается проблема с зависимостями, но с другой, такой способ распространения программ может повлечь за собой увеличение количества вирусов для Linux, ведь минимальное распространение вирусов обусловлено тем, что все программы устанавливаются из небольшого количества надежных и хорошо проверенных источников. А как вы считаете? Нужны ли Portable программы в Linux? Будете ими пользоваться? Нужно ли Losst создать свою библиотеку портативных программ для Linux? Напишите в комментариях!
Окружение Xfce
Любую систему можно разогнать, есть стандартные способы оптимизации десктопа: минимум софта в автозагрузке, preload, оптимальное зеркало для пакетов, apt-fast вместо apt-get, настройки для оптимизации отдельных приложений и так далее.
Но всё это мелкие оптимизации по сравнению с фундаментальными столпами:
- Лёгкий дистрибутив
- Легковесное окружение рабочего стола
- Быстрый софт
Поэтому — легковесное окружение и быстрый софт.
Легковесные окружения традиционно поставляются в комплекте с легковесными дистрибутивами, которые оптимизированы для работы на старом железе. Это Lubuntu, Linux Lite, Puppy Linux, TinyCore и др. Хотя самые аскетичные идут вообще без GUI. Например, TinyCore в варианте без GUI занимает всего 11 МБ. Базовая система размером 16 МБ предлагает десктопные окружения FLTK или FLWM, а версия CorePlus весом 106 МБ идёт с более продвинутыми менеджерами, такими как IceWM и FluxBox.
Но необязательно менять дистрибутив, чтобы повысить производительность системы. Для самого популярного Linux-дистрибутива — Ubuntu — тоже можно выбрать более легковесный рабочий стол, например, Xfce или LXDE.
Эти окружения требуют меньше оперативной памяти и вычислительных ресурсов процессора, а также поставляются со своим набором легковесных приложений, которые помогают ускорить систему.
Конечно, они выглядят не так современно, как Unity или GNOME, но приходится идти на какие-то компромиссы.
Кроме десктопного окружения, можно выбрать более производительные альтернативы для различных приложений Linux. Все перечисленные здесь программы доступны практически для любого дистрибутива, но в качестве примера указана Ubuntu.
Идея в том, чтобы на старом железе летала именно Ubuntu, то есть без смены дистрибутива.
Следующие приложения — не самые популярные, но достаточно надёжные, и при этом одни из самых производительных в своём классе.
Браузер: Midori
Midori — один из самых быстрых браузеров на движке WebKit и GTK3, который идёт в комплекте с некоторыми лёгкими дистрибутивами Linux, такими как Bodhi Linux, SilTaz и Raspbian. Раньше он был браузером по умолчанию в elementary OS, но в 2016 году разработка Midori приостановилась, так что его исключили из установок по умолчанию. Однако в конце 2018 года проект возобновился, и сейчас этот браузер входит в комплект приложений для десктопного окружения Xfce.
Поддерживаются вкладки, анонимные сессии, управление закладками, настраиваемый интерфейс, синхронизация через облако Astian Cloud. Поисковик по умолчанию DuckDuckGo.
У Midori множество опций, с которыми будет интересно повозиться опытному пользователю. Но нужно понимать, что он поддерживает не все современные технологии, поэтому в HTML5TEST даже не приблизится к максимальному результату. Да и список доступных расширений для него небогатый, но блокировщик рекламы есть.
Из других легковесных веб-браузеров под Linux можно назвать K-Meleon, Links, NetSurf и qutebrowser, все они в активной разработке.
Почтовые клиенты IMAP
Trojitá (Троица) на Qt — быстрый и эффективный почтовый клиент IMAP с открытым исходным кодом, один из лучших почтовых клиентов для Linux. Если вам достаточно поддержки только IMAP, то дальше можно и не искать.
Для достижения максимальной производительности Trojitá использует различные методы, в том числе автономное кэширование, режим экономии трафика, здесь минимальная нагрузка на память и CPU. Поддерживается IMAP по SSH, надёжная работа с HTML.
Эта программа является темой магистерской диссертации Яна Кундрата (Jan Kundrát), чешского разработчика. Собственно, подробнее всего о своём проекте он и рассказывает в этой диссертации, а также в блоге. Он вспоминает, что идея написать собственный клиент пришла к нему в районе 2005 года, потому что он не мог найти ничего подходящего его требованиям. KMail с многочисленными багами IMAP не впечатлял, Thunderbird падал минимум каждую неделю, а Evolution ему не нравился из-за Gnome. Многие программы выглядели как классические клиенты POP3, куда IMAP был добавлен в процессе разработки, а другие поддерживали весь набор функций IMAP, но страдали из-за непродуманного GUI.
Ян решил сначала закончить школу, а уже в университете плотно занялся разработкой нормального почтового клиента. Из языков программирования ему был известен только Python, поэтому он начал писать на нём, но вскоре открыл для себя Qt и C++ — и влюбился в них, как он сам рассказывает. К концу обучения клиент был готов.
Автор поддерживает проект до сих пор: последний коммит в основную ветку состоялся буквально пару дней назад. Но он уже не уделяет проекту слишком много внимания, например, больше не выкладывает на странице загрузки новые скомпилированные бинарники для Windows и разных дистрибутивов Linux.
Это необычная и легковесная альтернатива для известных, но более тяжеловесных почтовых клиентов, таких как вышеупомянутый Thunderbird, а также Evolution, Kmail, Geary, Mailspring (бывший Nylas Mail) и др. Хотя сторонникам полного аскетизма можно попробовать консольный клиент Mutt.
Mutt
Кстати, как раз в ноябре 2020 года состоялся выпуск версии Mutt 2.0, которой присвоен мажорный номер не из-за каких-то очень важных функций, а потому что некоторые из нововведений обратно несовместимы. Например, установлена настройка $ssl_force_tls по умолчанию, которую автор пробовал поставить в версии 1.3.0, но дал обратный ход из-за глюков. Кроме того, клиент научился автоматически инициировать заново соединение IMAP после обрыва.
У консольных почтовых клиентов по-прежнему большая аудитория, часть пользователей Mutt перешла на NeoMutt, OfflineIMAP и isync.
Установщик пакетов: Gdebi
Иногда на Ubuntu нужно быстренько установить пакет .deb. Конечно, можно использовать Ubuntu Software Center, но это ресурсоёмкое приложение, так что не слишком разумно использовать его для простой установки файлов .deb со всеми зависимостями. На этот случай есть утилита Gdebi, отличный инструмент для той же цели, только с минимальным графическим интерфейсом (или запускается из консоли).
Gdebi отлично справляется со своей работой, и его можно сделать установщиком по умолчанию для файлов .deb.
Установка Gdebi на Ubuntu:
Центр программного обеспечения: App Grid
Вообще, если говорить об альтернативе Ubuntu Software Center, то более легковесным вариантом представляется App Grid. Это практически обязательный инструмент, если вы часто используете центр ПО для поиска, установки и управления приложениями в Ubuntu. Наиболее визуально привлекательная и в то же время быстрая альтернатива стандартному софтверному центру.
App Grid поддерживает рейтинги, обзоры и скриншоты.
Установка в дистрибутивах на базе Ubuntu:
Музыка и радио
Yarock — элегантный музыкальный плеер с современным минималистичным интерфейсом. Плеер легковесный по дизайну, но в то же время обладает богатым набором продвинутых настроек.
Поддержка разных музыкальных коллекций, рейтинги, генератор умных плейлистов, простой поиск и фильтрация, дектопные уведомления, статистика по количеству воспроизведений песен, эквалайзер, управление из консоли и т. д. В качестве бэкенда могут работать Phonon, vlc и mpv. Список поддерживаемых аудиоформатов зависит от бэкенда: MP3, Ogg Vorbis, FLAC, WMA, MPEG-4 AAC.
Установка Yarock в дистрибутивах на базе Ubuntu:
Yarock умеет забирать поток с лучших сервисов интернет-радио: TuneIn, SHoutCast, Dirble. Кстати, разработчик Dirble устал от своего проекта и продал его в прошлом году, за что потом сильно извинялся.
С другой стороны, TuneIn до сих пор работает отлично, хотя у него нет нативного десктопного приложения. Однако TuneIn можно прослушивать через Yarock или через оболочку типа Nuvola Apps. Данный движок поддерживает множество стриминговых сервисов, включая Spotify, YouTube, Pandora и SoundCloud. Впрочем, Nuvola Apps нельзя назвать легковесным с зависимостями на 350 МБ.
Видеоплеер: VLC
Пожалуй, VLC — самое дефолтное приложение в этом списке. VLC действительно не нуждается в представлении, это стандарт де-факто на многих платформах, в том числе и под Linux. Плеер очень легковесный, это и одна из причин его популярности.
VLC — всё, что нужно для воспроизведения различных медиафайлов под Linux. В принципе, даже без отдельного музыкального плеера можно обойтись, потому что VLC понимает все аудиоформаты. Он безупречно работает даже на очень старых компьютерах и задействует аппаратное декодирование на всех платформах.
Файловый менеджер: PCManFM
PCManFM — стандартный файловый менеджер из среды LXDE. Как и другие приложения LXDE, он тоже лёгкий и быстрый. Создан как замена Nautilus, Konqueror и Thunar, а с 2010 полностью переписан заново с нуля, так что текущие версии сильно отличаются от семейства 0.5.х.
Несмотря PCManFM входит в комплект LXDE, но работает и с другими средами рабочего стола.
Установка PCManFM в дистрибутивах на базе Ubuntu:
Текстовый редактор и офисный пакет
По скорости работы ничто не сравнится с консольными редакторами, такими как nano, vim и emacs. Но некоторым людям в силу определённых причин больше нравится графический интерфейс. В этом случае можно посмотреть на Mousepad: чрезвычайно лёгкий и очень быстрый редактор. Поставляется с простым настраиваемым UI с несколькими темами.
Поддерживает подсветку синтаксиса. Таким образом, его можно использовать в качестве минимального редактора кода. Поставляется вместе со средой рабочего стола Xfce.
Кроме текстового редактора, бывают необходимы другие офисные приложения, в том числе электронные таблицы. Один самых легковесный вариантов — пакет Gnome Office с электронными таблицами Gnumeric и текстовым редактором AbiWord, который намного быстрее, чем другие текстовые процессоры, хотя здесь нет макросов, проверки грамматики и некоторых других функций.
Практически во всех категориях под Linux гораздо больше выбор различных программ, чем под Windows или macOS. Если поставить маленький дистрибутив и быстрый софт, то все нативные приложения будут летать даже на Raspberry Pi.
На правах рекламы
VDSina предлагает серверы в аренду под любые задачи, огромный выбор операционных систем для автоматической установки, есть возможность установить любую ОС с собственного ISO, удобная панель управления собственной разработки и посуточная оплата.
Читайте также: