История изменений

Ты просто неграмотен в Linux и не знаешь, о чем говоришь, вот тебе примеры технических отличий:

Я как-раз достаточно грамотен, чтобы говорить, где отличия «критические», которые требуют серьезного докостыливания, а где отличия бюрократические и придирические.

В отличии от Ubuntu, в Debian по умолчанию не поставляются заголовки ядра. Поэтому перед установкой VirtualBox или VMware нужно к метапакету ядра linux-image-amd64 нужно доустановить метапакет linux-headers-amd64.

Что решается командой по установке заголовков ядра или использованием центра приложений, а также включением со стороны Oracle в зависимости по умолчанию последнего заголовка ядра. Не крит.

Команды сразу по памяти:

sudo apt-add-repository contrib non-free sudo apt update sudo apt install linux-headers-amd64

PopOS основан на Ubuntu, но вместо загрузчика GRUB2 использует systemd-boot, при обычном использовании разницы нет, а вот при восстановлении после сбоя заметно.

Поскольку дистрибутив является ремиксом Ubuntu, а не самостоятельной единицей, как Suse или базальт, мануал по восстановлению аналогичен мануалу по восстановлению Ubuntu, с той лишь разницей, что будет установлен Grub. Да, есть мануалы, где предлагается полностью с ноля установить Grub или воспользоваться костылем Boot repair, который по сути с нуля переустанавливает Grub. И снова не крит.

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

Но я нигде не утверждал, что рецепты от родителя на 100% подлинно подходят к дочернему дистрибутиву. Дословно:

как правило мало чем отличается.

По мне так разницы между Debian, Ubuntu и Mint на сегодняшний день как таковой, нет.

Последнее - ИХМО.

А есть куда более критические отличия, которые как-раз и наблюдаются в RPM - семействе. Например, использование пакета RPM Google Chrome от Fedora в базальте приводит к тому, что пакет замораживается и не обновляется, поскольку в пакете Chrome нет автоматического заполнения поля /etc/apt/sources.list. А это уже требует серьезного ручного вмешательства в sources.list с поверкой на работоспособность такого вмешательства, что чревато появлением в браузере уязвимостей различного толка, поскольку не факт, что DNF/Zypper-репозиторий корректно будет считан менеджером пакетов APT. Крит.

Еще один крит RPM-семейства - это даже при наличии src.rpm разночтений в зависимостях, которые наблюдаются даже между Fedora 32-34 и RHEL 9. Например, таким образом мне не удалось собрать пакет от F32 в окружении RHEL 9, поскольку там его зависимость была заменена другим аналогом. Тоже крит.

И таких критов, включая различное поведение при сборке драйверов Nvidia - даже в разных репозиториях RHEL по-разному собирается проприетарный драйвер - где-то через dkms, где-то через akmod, где-то уже запакованный kmod, существенное количество. В тех же производных Debian, Ubuntu и Mint я еще ни разу не встречал отличное от dkms поведение при сборке. В этом полное единогласие. Это например, чревато тем, что система не сможет загрузиться при установке обновлений ядра, поскольку изготовитель пакета не заложил тот же DKMS.

А вышеописанное Вами решается во всех случаях с помощью ТГ-каналов и чатов дистрибутива копипастом команд. Да здесь как вариант в соответствующих темах. Копипастят и не думают. А то, что описал я, не решается в пятиминутных чатах. И это - основной критерий, которым я руководствуюсь, когда говорю о критических или некритических отличиях.

Ты просто неграмотен в Linux и не знаешь, о чем говоришь, вот тебе примеры технических отличий:

Я как-раз достаточно грамотен, чтобы говорить, где отличия «критические», которые требуют серьезного докостыливания, а где отличия бюрократические и придирические.

В отличии от Ubuntu, в Debian по умолчанию не поставляются заголовки ядра. Поэтому перед установкой VirtualBox или VMware нужно к метапакету ядра linux-image-amd64 нужно доустановить метапакет linux-headers-amd64.

Что решается командой по установке заголовков ядра или использованием центра приложений, а также включением со стороны Oracle в зависимости по умолчанию последнего заголовка ядра. Не крит.

PopOS основан на Ubuntu, но вместо загрузчика GRUB2 использует systemd-boot, при обычном использовании разницы нет, а вот при восстановлении после сбоя заметно.

Поскольку дистрибутив является ремиксом Ubuntu, а не самостоятельной единицей, как Suse или базальт, мануал по восстановлению аналогичен мануалу по восстановлению Ubuntu, с той лишь разницей, что будет установлен Grub. Да, есть мануалы, где предлагается полностью с ноля установить Grub или воспользоваться костылем Grub Restore, который по сути с нуля переустанавливает Grub. И снова не крит.

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

Но я нигде не утверждал, что рецепты от родителя на 100% подлинно подходят к дочернему дистрибутиву. Дословно:

как правило мало чем отличается.

По мне так разницы между Debian, Ubuntu и Mint на сегодняшний день как таковой, нет.

Последнее - ИХМО.

А есть куда более критические отличия, которые как-раз и наблюдаются в RPM - семействе. Например, использование пакета RPM Google Chrome от Fedora в базальте приводит к тому, что пакет замораживается и не обновляется, поскольку в пакете Chrome нет автоматического заполнения поля /etc/apt/sources.list. А это уже требует серьезного ручного вмешательства в sources.list с поверкой на работоспособность такого вмешательства, что чревато появлением в браузере уязвимостей различного толка, поскольку не факт, что DNF/Zypper-репозиторий корректно будет считан менеджером пакетов APT. Крит.

Еще один крит RPM-семейства - это даже при наличии src.rpm разночтений в зависимостях, которые наблюдаются даже между Fedora 32-34 и RHEL 9. Например, таким образом мне не удалось собрать пакет от F32 в окружении RHEL 9, поскольку там его зависимость была заменена другим аналогом. Тоже крит.

И таких критов, включая различное поведение при сборке драйверов Nvidia - даже в разных репозиториях RHEL по-разному собирается проприетарный драйвер - где-то через dkms, где-то через akmod, где-то уже запакованный kmod, существенное количество. В тех же производных Debian, Ubuntu и Mint я еще ни разу не встречал отличное от dkms поведение при сборке. В этом полное единогласие. Это например, чревато тем, что система не сможет загрузиться при установке обновлений ядра, поскольку изготовитель пакета не заложил тот же DKMS.

А вышеописанное Вами решается во всех случаях с помощью ТГ-каналов и чатов дистрибутива копипастом команд. Да здесь как вариант в соответствующих темах. Копипастят и не думают. А то, что описал я, не решается в пятиминутных чатах. И это - основной критерий, которым я руководствуюсь, когда говорю о критических или некритических отличиях.

Ты просто неграмотен в Linux и не знаешь, о чем говоришь, вот тебе примеры технических отличий:

Я как-раз достаточно грамотен, чтобы говорить, где отличия «критические», которые требуют серьезного докостыливания, а где отличия бюрократические и придирические.

В отличии от Ubuntu, в Debian по умолчанию не поставляются заголовки ядра. Поэтому перед установкой VirtualBox или VMware нужно к метапакету ядра linux-image-amd64 нужно доустановить метапакет linux-headers-amd64.

Что решается командой по установке заголовков ядра или использованием центра приложений, а также включением со стороны Oracle в зависимости по умолчанию последнего заголовка ядра. Не крит.

PopOS основан на Ubuntu, но вместо загрузчика GRUB2 использует systemd-boot, при обычном использовании разницы нет, а вот при восстановлении после сбоя заметно.

Поскольку дистрибутив является ремиксом Ubuntu, а не самостоятельной единицей, как Suse или базальт, мануал по восстановлению аналогичен мануалу по восстановлению Ubuntu, с той лишь разницей, что будет установлен Grub. Да, есть мануалы, где предлагается полностью с ноля установить Grub или воспользоваться костылем Grub Restore, который по сути с нуля переустанавливает Grub. И снова не крит.

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

Но я нигде не утверждал, что рецепты от родителя на 100% подлинно подходят к дочернему дистрибутиву. Дословно:

как правило мало чем отличается.

По мне так разницы между Debian, Ubuntu и Mint на сегодняшний день как таковой, нет.

Последнее - ИХМО.

А есть куда более критические отличия, которые как-раз и наблюдаются в RPM - семействе. Например, использование пакета RPM Google Chrome от Fedora в базальте приводит к тому, что пакет замораживается и не обновляется, поскольку в пакете Chrome нет автоматического заполнения поля /etc/apt/sources.list. А это уже требует серьезного ручного вмешательства в sources.list с поверкой на работоспособность такого вмешательства, что чревато появлением в браузере уязвимостей различного толка, поскольку не факт, что DNF/Zypper-репозиторий корректно будет считан менеджером пакетов APT. Крит.

Еще один крит RPM-семейства - это даже при наличии src.rpm разночтений в зависимостях, которые наблюдаются даже между Fedora 32-34 и RHEL 9. Например, таким образом мне не удалось собрать пакет от F32 в окружении RHEL 9, поскольку там его зависимость была заменена другим аналогом. Тоже крит.

И таких критов, включая различное поведение при сборке драйверов Nvidia - даже в разных репозиториях RHEL по-разному собирается проприетарный драйвер - где-то через dkms, где-то через akmod, где-то уже запакованный kmod, существенное количество. В тех же производных Debian, Ubuntu и Mint я еще ни разу не встречал отличное от dkms поведение при сборке. В этом полное единогласие. Это например, чревато тем, что система не сможет загрузиться при установке обновлений ядра, поскольку изготовитель пакета не заложил тот же DKMS.

А вышеописанное Вами решается во всех случаях с помощью ТГ-каналов и чатов дистрибутива копипастом команд. Да здесь как вариант в соответствующих темах. Копипастят и не думают. А то, что описал я, не решается в пятиминутных чатах.

Ты просто неграмотен в Linux и не знаешь, о чем говоришь, вот тебе примеры технических отличий:

Я как-раз достаточно грамотен, чтобы говорить, где отличия «критические», которые требуют серьезного докостыливания, а где отличия бюрократические и придирические.

В отличии от Ubuntu, в Debian по умолчанию не поставляются заголовки ядра. Поэтому перед установкой VirtualBox или VMware нужно к метапакету ядра linux-image-amd64 нужно доустановить метапакет linux-headers-amd64.

Что решается командой по установке заголовков ядра или использованием центра приложений, а также включением со стороны Oracle в зависимости по умолчанию последнего заголовка ядра. Не крит.

PopOS основан на Ubuntu, но вместо загрузчика GRUB2 использует systemd-boot, при обычном использовании разницы нет, а вот при восстановлении после сбоя заметно.

Поскольку дистрибутив является ремиксом Ubuntu, а не самостоятельной единицей, как Suse или базальт, мануал по восстановлению аналогичен мануалу по восстановлению Ubuntu, с той лишь разницей, что будет установлен Grub. И снова не крит.

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

Но я нигде не утверждал, что рецепты от родителя на 100% подлинно подходят к дочернему дистрибутиву. Дословно:

как правило мало чем отличается.

По мне так разницы между Debian, Ubuntu и Mint на сегодняшний день как таковой, нет.

Последнее - ИХМО.

А есть куда более критические отличия, которые как-раз и наблюдаются в RPM - семействе. Например, использование пакета RPM Google Chrome от Fedora в базальте приводит к тому, что пакет замораживается и не обновляется, поскольку в пакете Chrome нет автоматического заполнения поля /etc/apt/sources.list. А это уже требует серьезного ручного вмешательства в sources.list с поверкой на работоспособность такого вмешательства, что чревато появлением в браузере уязвимостей различного толка, поскольку не факт, что DNF/Zypper-репозиторий корректно будет считан менеджером пакетов APT. Крит.

Еще один крит RPM-семейства - это даже при наличии src.rpm разночтений в зависимостях, которые наблюдаются даже между Fedora 32-34 и RHEL 9. Например, таким образом мне не удалось собрать пакет от F32 в окружении RHEL 9, поскольку там его зависимость была заменена другим аналогом. Тоже крит.

И таких критов, включая различное поведение при сборке драйверов Nvidia - даже в разных репозиториях RHEL по-разному собирается проприетарный драйвер - где-то через dkms, где-то через akmod, где-то уже запакованный kmod, существенное количество. В тех же производных Debian, Ubuntu и Mint я еще ни разу не встречал отличное от dkms поведение при сборке. В этом полное единогласие.

А вышеописанное Вами решается во всех случаях с помощью ТГ-каналов и чатов дистрибутива копипастом команд. Да здесь как вариант в соответствующих темах. Копипастят и не думают.

Ты просто неграмотен в Linux и не знаешь, о чем говоришь, вот тебе примеры технических отличий:

Я как-раз достаточно грамотен, чтобы говорить, где отличия «критические», которые требуют серьезного докостыливания, а где отличия бюрократические и придирические.

В отличии от Ubuntu, в Debian по умолчанию не поставляются заголовки ядра. Поэтому перед установкой VirtualBox или VMware нужно к метапакету ядра linux-image-amd64 нужно доустановить метапакет linux-headers-amd64.

Что решается командой по установке заголовков ядра или использованием центра приложений, а также включением со стороны Oracle в зависимости по умолчанию последнего заголовка ядра. Не крит.

PopOS основан на Ubuntu, но вместо загрузчика GRUB2 использует systemd-boot, при обычном использовании разницы нет, а вот при восстановлении после сбоя заметно.

Поскольку дистрибутив является ремиксом Ubuntu, а не самостоятельной единицей, как Suse или базальт, мануал по восстановлению аналогичен мануалу по восстановлению Ubuntu, с той лишь разницей, что будет установлен Grub. И снова не крит.

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

Но я нигде не утверждал, что рецепты от родителя на 100% подлинно подходят к дочернему дистрибутиву. Дословно:

как правило мало чем отличается.

По мне так разницы между Debian, Ubuntu и Mint на сегодняшний день как таковой, нет.

Последнее - ИХМО.

А есть куда более критические отличия, которые как-раз и наблюдаются в RPM - семействе. Например, использование пакета RPM Google Chrome от Fedora в базальте приводит к тому, что пакет замораживается и не обновляется, поскольку в пакете Chrome нет автоматического заполнения поля /etc/apt/sources.list. А это уже требует серьезного ручного вмешательства в sources.list с поверкой на работоспособность такого вмешательства, что чревато появлением в браузере уязвимостей различного толка, поскольку не факт, что DNF/Zypper-репозиторий корректно будет считан менеджером пакетов APT. Крит.

Еще один крит RPM-семейства - это даже при наличии src.rpm разночтений в зависимостях, которые наблюдаются даже между Fedora 32-34 и RHEL 9. Например, таким образом мне не удалось собрать пакет от F32 в окружении RHEL 9, поскольку там его зависимость была заменена другим аналогом. Тоже крит.

И таких критов, включая различное поведение при сборке драйверов Nvidia - даже в разных репозиториях RHEL по-разному собирается проприетарный драйвер - где-то через dkms, где-то через akmod, где-то уже запакованный kmod, существенное количество. В тех же производных Debian, Ubuntu и Mint я еще ни разу не встречал отличное от dkms поведение при сборке. В этом полное единогласие.

Ты просто неграмотен в Linux и не знаешь, о чем говоришь, вот тебе примеры технических отличий:

Я как-раз достаточно грамотен, чтобы говорить, где отличия «критические», которые требуют серьезного докостыливания, а где отличия бюрократические и придирические.

В отличии от Ubuntu, в Debian по умолчанию не поставляются заголовки ядра. Поэтому перед установкой VirtualBox или VMware нужно к метапакету ядра linux-image-amd64 нужно доустановить метапакет linux-headers-amd64.

Что решается командой по установке заголовков ядра или использованием центра приложений, а также включением со стороны Oracle в зависимости по умолчанию последнего заголовка ядра. Не крит.

PopOS основан на Ubuntu, но вместо загрузчика GRUB2 использует systemd-boot, при обычном использовании разницы нет, а вот при восстановлении после сбоя заметно.

Поскольку дистрибутив является ремиксом Ubuntu, а не самостоятельной единицей, как Suse или базальт, мануал по восстановлению аналогичен мануалу по восстановлению Ubuntu, с той лишь разницей, что будет установлен Grub. И снова не крит.

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

Но я нигде не утверждал, что рецепты от родителя на 100% подлинно подходят к дочернему дистрибутиву. Дословно:

как правило мало чем отличается.

По мне так разницы между Debian, Ubuntu и Mint на сегодняшний день как таковой, нет.

Последнее - ИХМО.

А есть куда более критические отличия, которые как-раз и наблюдаются в RPM - семействе. Например, использование пакета RPM Google Chrome от Fedora в базальте приводит к тому, что пакет замораживается и не обновляется, поскольку в пакете Chrome нет автоматического заполнения поля /etc/apt/sources.list. А это уже требует серьезного ручного вмешательства в sources.list с поверкой на работоспособность такого вмешательства, что чревато появлением в браузере уязвимостей различного толка, поскольку не факт, что DNF/Zypper-репозиторий корректно будет считан менеджером пакетов APT. Крит.

Еще один крит RPM-семейства - это даже при наличии src.rpm разночтений в зависимостях, которые наблюдаются даже между Fedora 32-34 и RHEL 9. Например, таким образом мне не удалось собрать пакет от F32 в окружении RHEL 9, поскольку там его зависимость была заменена другим аналогом.