Существуют ли опасности при использовании нескольких менеджеров пакетов
Ядро Linux, особенно в дни 0.11, загружалось напрямую аппаратным BIOS.
Обычно BIOS просматривает загрузочный сектор (дискеты )или главную загрузочную запись жесткого диска и загружает этот сектор. На жестком диске MBR затем загружает загрузочный сектор «основного раздела».
В этом загруженном загрузочном секторе достаточно информации, чтобы знать, как загрузить ядро в память, а затем запустить его.
Со старыми старыми дисками версии 0.11 это было эффективное решение для загрузки с дискеты, с ядром на одном диске и корнем на другом диске, так что система загрузки была очень простой.
Когда Linux работал с жесткими дисками, процесс загрузки был очень простым. Это было настолько просто, что стало возможным создавать такие инструменты, как «loadlin», которая была простой программой для DOS, которая загружала ядро Linux и загружалась в него, эмулируя загрузчик BIOS. Таким образом можно создать меню config.sys DOS для загрузки DOS или Linux; ранняя форма двойной загрузки.
Но в основе своей ядро Linux загружается с «голого железа» и берет на себя управление машиной.
Один из лучших способов сломать дистрибутив — попытаться беспрепятственно использовать пакеты другого дистрибутива. Тот факт, что у Parrot aptи у Debian apt, не означает, что они будут хорошо работать вместе. Различные дистрибутивы версии -могут нумеровать пакеты по-разному, и вы можете обнаружить, что установка пакета Debian требует любого количества -нумерованных зависимостей от Parrot. Или вы можете обнаружить, что Debian нужен пакет, которого у Parrot даже нет, и наоборот.
Боюсь, это плохая идея.
Менеджер пакетов Snap не должен быть проблемой, используются отдельные файлы и виртуальные файловые системы. То же самое относится к Flatpak или Appimages, если вам нужно приложение, доступное только там.
Но вы также упомянули RPM. Это может вызвать проблемы. Их не следует использовать в Debian и его производных, таких как ParrotOS.
Как правило, это почти всегда приводит к поломке вашей системы, если только вы не предпримете специальных шагов, чтобы избежать такой ситуации. Все менеджеры пакетов дистрибутива (, в отличие от языковых PM, таких как NPM или PIP ), предназначены для работы в предположении, что они имеют 100% контроль над подавляющим большинством файловой системы за пределами /usr/localи /home, и они довольно надежно ломают вещи, когда это предположение не выполняется. На самом деле, даже просто ручная сборка и установка программного обеспечения независимо от менеджера пакетов может быть рискованной (, поэтому здравомыслящие администраторы используют /usr/localдля таких вещей ).
Однако,это не означает, что вы не можете использовать программное обеспечение, которое не упаковано для вашего дистрибутива:
- Если у него есть пакет Flatpak, AppImage или Snap, вы почти всегда можете безопасно использовать его при условии, что ваш дистрибутив может поддерживать требования для этих форматов (почти все основные из них поддерживают AppImage из коробки, а Flatpak и/ или Snap с минимальными усилиями ).
- Программное обеспечение может быть доступно в виде образа Docker, который можно использовать не только в любом дистрибутиве Linux, поддерживающем Docker, но и в Windows или macOS.
- Вы также можете создать свой собственный образ Docker для программного обеспечения, просто используя обычный контейнер ОС в качестве основы.
- Большинство нормальных менеджеров пакетов позволяют выполнять установку в настраиваемый пользователем префикс вместо корневой файловой системы (, хотя это не всегда доступно для пользователя -, работающего с такими инструментами, как APT или DNF ). Это можно использовать для создания среды chroot, из которой вы сможете запускать нужное программное обеспечение.
- При условии, что это FOSS, вы обычно можете собрать исходный код для своего дистрибутива. Просто не забудьте настроить его так, чтобы помещать вещи в
/usr/local, чтобы вы не мешали диспетчеру пакетов (и, возможно, заглянуть в GNU Stow , это значительно упрощает управление такими вещами ). ].