rPman

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

GHex is a hex editor for the GNOME desktop.

можно забить в поиск synaptic или консольной apt свое название gnome hex editor и в полученном списке ищем что то похожее
p.s.

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

# whereis ghex
ghex: /usr/bin/ghex /usr/share/man/man1/ghex.1.gz

затем определяем имя пакета по имени файла (не обязательно запускаемого)

# dpkg -S /usr/bin/ghex
ghex: /usr/bin/ghex

тут слева имя пакета, справа имя файла (может быть что один и тот же файл есть в разных пакетах
p.s. если поиск пакета по файлу не сработал, значит данный пакет не установлен, если не говорить в разрезе задачи удаления а просто определить в каком пакете нужный файл, нужно установить утилиту apt-file, она загрузит базу всех пакетов и позволит искать по ним (так же на сколько я знаю при установке bashcompletion при запуске неизвестного приложения будет выдаваться список пакетов где есть похожие по имени)

2. узнав имя пакета его можно удалить либо synaptic либо в консоли

apt remove ghex
или
apt purge ghex

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

если что то идет не так, то нужно смотреть сообщения об ошибках
p.p.s. есть мощный консольный GUI для пакетного менеджера - aptitude, умеет много проблем разруливать

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

Конкретно для виртуальной машины нужно установить драйвера гостевой ос (смотреть ту виртуальную машину которую используешь), например VirtualBox таскает с собой VirtualBoxAdditionals.iso

универсально (т.е. и на реальном железе):
с помощью cvt генерируешь дефолтные параметры для своего режима и затем добавляешь этот режим с помощью xrandr
https://wiki.archlinux.org/title/xrandr
https://linuxnow.ru/view.php?id=103

Зачем выбирать специализированную версию linux - RedOS а затем уходить от ее протестированных компонент на самые новые, в 99% случаев вне зависимости от ос это непередаваемые приключения и страдания. Чем тебя qt5 версии не устраивают, которые есть в репах этой ос?

Так как готовых backports разработчики или сообщество не предоставило (наличие их отсутствия показывает размер и качество этого сообщества и разработчиков данной ОС), то собирать вам весь комплекс пакетов самостоятельно

Без знания linux боюсь будет очень сложно, ведь на таком квесте спотыкаются и опытные пользователи

RedOS Система основана на rpm пакетах, пакетный менеджер утилита dnf (ранее yum) так как скорее всего основано на centos. С некоторой вероятностью у операционной системы может быть бинарная совместимость с centos (одинаковые версии системных библиотек) а значит можно попытаться поискать готвые решения от туда.

p.s. но главное, куда поедет сертификация, после того как вы на эту ос начнете водружать системные пакеты собственной/чужой сборки?

Например
1. отключаешь display manager - lightdm (или что у тебя там для меню авторизации и выбора DE)
2. минимум что необходимо для работы графического режима - это xserver, для его запуска достаточно запустить утилиту X (кстати кажется до сих пор требует root), будет запущен графический сервер без Desktop Environment, но нужно понимать что DE отвечает за управление окнами, а точнее управление их размерами, положением на экране и вообще сокрытие/минимизация. Т.е. без этого, если твое приложение ожидает что пользователь будет перемещать его окна (а это к примеру диалоговое окно открытия/сохранения файлов) то он уже это сделать не сможет, все окна будут без заголовков и бордюра для изменения их размеров.
И кстати, чтобы графическое приложение запустилось и отображалось на X нужно устанавливать переменную окружения DISPLAY, значение смотреть либо в конфиге X либо в логах (скорее всего будет что то типа :0, это имя сервера и номер xserver, запущенного на нем, напоминаю, что linux из коробки умеет multiseat)
3. чтобы появился хоть какой то интерфейс взаимодействия, нужно установить DE, из минималистичных, идеальных для kiosk mode - я бы рекомендовал awesome, в нем к примеру можно настроить чтобы все открываемые окна сразу разворачивались на весь экран.

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

Из минималистичных и вполне функциональных DE можно предложить еще какой-нибудь openbox, его можно настроить так чтобы вообще никаких 'пуск' и списка задач не было, а только иконки и приложение на весь экран. Но пользователь сможет добраться до редактирования меню и запустить любое приложение, т.е. это не для kiosk mode

Чтобы запустить xserver с DE автоматически можно либо настроить автозагрузку в lightdm (это правильно) либо просто запускать утилиту startx, которая смотрит в пользовательском каталоге .xinitrc и запускает DE от туда.

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

Собственно как запускать приложения автоматически при включении компьютера тоже вопрос очень интересный, способов много, минимум три могу предложить
* правильный - настроить службу и прописать ей зависимости и автозапуск,
* так же до сих пор есть устаревший способ настройки службы без зависимостей sysvinit - /etc/init.d
* ну еще есть /etc/rc.local

lvm? lvextend

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

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

Еще момент, некоторые файловые системы, например btrfs/zfs, умеют на лету! добавлять (и удалять) диски к пулу, и не обязательно это должен быть raid, возможно простое объединение пространств дисков, даже без чередования. Собственно btrfs я бы и рекомендовал использовать, даже не смотря на его нестабильный статус (так как все его проблемы касаются вещей, которые можно не использовать, например raid56)

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

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

Запрети всем доступ к usb и запили скриптик, который к примеру по крону будет проверять список устройств, например с помощью lsblk (там можно настроить подробный вывод) и смотри там uuid или метку или идентификатор устройства и монтируй

а для размонтирования разрешай запуск своего sudo unmount, пусть ярлыком запускают пользователи

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

на нужную тебе комбинацию клавиш (в штатных настройках DE) настраиваешь на запуск своей команды bash -e touch /tmp/имя_файла, эта команда создаст пустой указанный файл