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

https://opennet.ru/59003/
По этому поводу можно уйти в адский запой под наркозом пытки садизм

Осваиваю Matrix, нашёл сие творение — iamb.

Клиент, написанный на языке Rust. Установка элементарная, управление в стиле Vim, консольный интерфейс и прочие прибамбасы.

#Soft

https://opennet.ru/59026/
Вот наша страна хотя бы в чём-то впереди всех. Что одназначно радует

Поздравляю всех вас с великим Днём Победы! Для каждого из нас это, безусловно, священная дата. Тех, кто воевал тогда, мы искренне благодарим и гордимся ими. Если бы не они, нас бы здесь могло и не быть. Светлая память всем тем, кто воевал за свободу и независимость, за мирное небо, за право жить.

"Праздник со слезами на глазах" — эта дата священна для каждого из нас, но я не вижу поводов для веселья, особенно сегодня в свете текущих событий. Возможно, я неправ, но я считаю, что те, кто веселится в этот день, бухает и начинает устраивать адский угар — просто пляшет на костях своих предков. Это не есть хорошо. Да, то, что мы тогда победили — это вселяет гордость. Может быть, даже радость за то, что сейчас этой гадости, с которой мы тогда боролись, уже нет. Но тем не менее — это была страшная и кровопролитная война, которая унесла около 27 млн жизней ни в чём неповинных людей. Помните о том, за что и против чего боролись ваши деды и прадеды, и не допустите повторения этих событий в будущем.

Можно много говорить о том, что история должна нас чему-то научить. Нет — она не должна ничему учить. Человек сам должен учиться и выносить из истории правильные уроки. Но, как мы можем наблюдать, человек не учится. Поэтому очень важно, всё-таки, не превращать такие даты в весёлые праздники, а думать о том, как и почему началась ВОВ, как она завершилась и к чему всё это привело мир в будущем. Только тогда мы сможем если не предотвратить кровопролитие на земле, то хотя бы научиться хоть какие-то вопросы решать дипломатическим путём.

Немного про AppImage. Часть 1. Краткое введение.

AppImage долгое время является моим любимым форматом распространения ПО. У него достаточно интересная философия: во-первых, ПО в этом формате самодостаточное, т.е. все его зависимости расположены вместе с основной программой в пакете (подробнее об этом поговорим в одной из следующих частей), во-вторых, философия "одна программа = один файл" мне очень близка и чем-то напоминает формат распространения ПО из macOS (об этом писал один хороший человек здесь).

Если сравнивать AppImage и обычные "нативные" пакеты для GNU/Linux, то можно выявить свои достоинства и недостатки. Самым главным достоинством я считаю возможность присутствия в системе нескольких версий одной и той же программы. Бывает, когда в новой версии софтины что-то сломали, удалили или переделали, и приходится сидеть на более старой версии. Не всегда можно откатиться до более старой версии используя обычные пакеты для GNU/Linux. Кроме того это вопрос зависимостей. Мы можем положить какие-то специфичные зависимости в AppImage пакет вместе с искомой программой, а какие-то оставшиеся зависимости, которые 100% существуют в системе, мы можем туда не класть - они могут подтянуться из основной системы самостоятельно. Я заметил такое поведение когда собирал нужные мне AppImage пакеты. Прикольная вещь, ибо мы можем даже уменьшить размер AppImage пакета, положив туда только то, чего точно нет в системе. А то, что точно в системе есть, будет только там и не будет продублировано в пакете. Крррасота!

Ну и, что самое главное, это унификация. У нас есть *.deb, *.rpm, пакеты для ArchLinux, пакеты для ещё какого-то дистрибутива... Мне нужно писать программу, а не пакетировать её для зоопарка дистрибутивов GNU/Linux, даже несмотря на наличие у этих дистрибутивов мейнтейнеров, которые могут сами всё собрать. Мейнтейнеры - это люди непредсказуемые. Могут так собрать программу, что в ней половина функций вообще отвалится. Периодически сталкивался с этим. Вот когда у нас есть, скажем, Flatpak для какого-то крупного и, как правило, коммерческого софта, и есть AppImage для всего остального - вот это круто. Не придётся думать, а для какого же дистрибутива мне делать пакет.

Для меня основным минусом является то, что в пакете может быть несколько программ, а файл AppImage с этим пакетом только один. К примеру, возьмём пакет LibreOffice. Он состоит из нескольких программ: Writer, Calc и Impress. Есть ещё Startcenter, это программа со списком последних документов, с которыми мы работали, ну и она содержит кнопки для создания новых документов. Я не могу просто так взять и запустить Writer, мне нужно запустить startcenter, и уже оттуда запустить Writer. Тоже самое и с другими программами. А если в пакете нет ничего вроде того самого startcenter, то хрен ты что-то запустишь. В общем, такой вот минус.

Во второй части хочу написать про создание своих пакетов AppImage. В официальной документации написано не очень понятно, да ещё и на англицком. Но мы же не знаем англицкий 🤡. На самом деле, там ничего сложного нет.

LinuxSovet

#AppImage

Скриншот для предыдущего поста. Чтобы было понятие, о чём я писал, что такое LibreOffice Startcenter

В свете бурных изменений в некоторых сообществах хочу отметить следующее. Статьи нашего сообщества могут появляться только на следующих сайтах/репозиториях/etc.:

1. Мой GitHub (репозиторий со статьями, сайт сообщества)
2. Руководство "Linux для себя"
3. Какие-то отдельные части могут быть в документации Calmira GNU/Linux-libre.
4. Сообщество группы в ВК.

Размещение статей оттуда (в первую очередь с сайта сообщества) на других сайтах или появление статей оттуда в иной литературе на других сайтах и/или в иных сообществах и/или в иных источниках до 15.05.2023 считаю недопустимым. Даже в том случае, если когда-либо я сам размещал их в соответствующих источниках. Не допускается публикация любых статей и иной информации сообщества в источниках, расположенных за пределами РФ, либо если владелец источника не является гражданином РФ, за исключением источников, указанных в начале поста. (пример недопустимого использования материалов нашего сообщества).

В том случае, если материалы из указанных выше допустимых источников размещены в сторонних источниках с моего согласия, то никаких проблем нет.

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

https://www.interfax.ru/russia/901159

На hh.ru на каждую вакансию по хрензнаетскольколион просмотров, отзывов и прочей фигни. Плюс всякие отсрочки, хуёчки и прочее. Не работа, а сказка, особенно когда учитель или врач получает условные 10 тыс рублей, а какой-то программист джун - 40. Понятное дело, что работать в IT - вещь всё-таки трудная, но и указанные выше профессии не менее сложны, а из важность быть может даже выше.

Немного про AppImage. Часть 2. Сборка AppImage.

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

1. Скачивание и распаковка архивов с исходным кодом ПО.
2. Конфигурирование пакета.
3. Сборка пакета (компиляция из исходного кода двоичных файлов в формате ELF, генерация иных необходимых файлов).
4. Установка пакета.

Устанавливать пакет можно либо в саму систему (либо в /, либо в /usr, либо в /opt), а можно и в другую директорию, если это поддерживается как используемой системой сборки, так и сборочными инструкциями пакета непосредственно. И вот собранный из исходного кода пакет нам нужно установить не в систему, а в отдельную директорию, к которой мы в будущем будем иметь доступ.

Для сборки пакета в формате AppImage нам нужно соблюсти следующую структуру каталогов:

APP.AppDir/
APP.AppDir/AppRun
APP.AppDir/app.desktop
APP.AppDir/app.png
APP.AppDir/APPDIR/файлы_программы

Здесь APP - это имя программы, которую мы собираем. Поэтому, если вы собираете программу из исходного кода, установите её в APP.AppDir/!
Если мы собираем Firefox, то вместо APP подставьте Firefox. Файлы app.desktop и app.png содержат файлы для интеграции пакета в систему. Также файл app.png может быть использован для генерации превью файлов с этими пакетами (см. предыдущий пост), точнее не сам этот файл, а ссылка на него, которая автоматически создаётся при создании AppImage.
Замените в именах этих файлов app на имя пакета. Для Firefox пусть будет firefox.desktop и firefox.png.

app.png - это иконка приложения. Обычно она содержится в директории APPDIR/share/icons или иной. Поищите её, она должна быть.

Простейший *.desktop файл выглядит так:

[Desktop Entry]
Name=MyApp
Exec=myapp
Icon=myapp
Type=Application
Categories=Utility;

Параметр Name должен совпадать с APP - именем программы (например, Firefox). Параметр Exec нам здесь не особо важен, ибо вместо него для запуска программы будет использован скрипт AppRun. Icon носит имя иконки программы, которую мы поместили в APP.AppDir/ до создания этого *.desktop. Параметр Categories описывает категории, к которым относится наша программа. В меню окружений KDE, MATE, Xfce и других оно попадёт в указанные категории. Зайдите сюда, чтобы посмотреть список допустимых категорий.

Проверьте *.desktop файл на правильность:

`desktop-file-validate app.desktop`

Если вы собираете программу без графического интерфейса (консольную программу), то обязательно добавьте параметр Terminal=true, чтобы после её возможной интеграции в меню системы мы могли запускать программу в терминале.

APPDIR - это каталог, в который установлена программа. Это может быть opt, может быть usr, тут уже без разницы. Например, у меня для программы Firefox этот каталог называется firefox. Название здесь не критично, но его нужно будет учитывать в будущем, когда мы будем создавать скрипт AppRun для запуска нашего приложения. Самое главное, чтобы из этой директории смогла работать программа и, не менее важное, чтобы из этого каталога мы смогли бы запустить эту программу.

AppRun, как вы поняли, это исполняемый BASH скрипт, запускающий программу из AppImage пакета. Тут возникает вопрос - а как нам запустить программу из пакета? Мы можем указать что-то вроде этого:

#!/bin/bash
./APP/app_name

(где APP - директория с установленной программой, а app_name - название двоичного файла или скрипта - собственно, нужной нам программы).

—== ПРОДОЛЖЕНИЕ В ПОСТЕ НИЖЕ ==—

А ты оформил под-письку на LinuxSovet???

#AppImage

—== ПРОДОЛЖЕНИЕ ПОСТА ВЫШЕ ==—

Но так у нас не сработает. Мы можем просто указать app_name, но и так тоже не сработает. Дело в том, что скрипту AppDir передаются некоторые переменные окружения, которые мы можем использовать для запуска нужных программ из пакета. Одной из них является переменная $APPDIR, которую мы и будем использовать для формирования пути до исполняемого файла программы:

#!/bin/bash
$APPDIR/APP/app_name

(где APP - директория с установленной программой, а app_name - название двоичного файла или скрипта - собственно, нужной нам программы).

Не забудьте сделать AppRun исполняемым:

chmod +x AppRun

Создание пакета

Скачайте отсюда пакет appimagetool. У меня скачан пакет с именем appimagetool-x86_64.AppImage, поэтому показываю на нём. Дайте этому пакету право исполнения: chmod +x appimagetool-x86_64.AppImage и запустите его следующим образом:

./appimagetool-x86_64.AppImage APP.AppDir APP-VERSION-ARCH.AppImage

Замените APP на имя программы, VERSION - на её версию, ARCH - на архитектуру, для которой программа собиралась (например, x86_64). Если всё прошло успешно, то у нас будет собран новый AppImage пакет.

А ты оформил под-письку на LinuxSovet???

#AppImage