Debian testing что это

Обновлено: 05.07.2024

Debian — стабильный, надежный, популярный, полностью некоммерческий дистрибутив Linux. В основном используется на персональных компьютерах или на серверах.

Debian имеет крупнейший репозиторий пакетов, использует DEB пакеты и менеджер пакетов Advanced Packaging Tool (APT), поддерживающий отслеживание зависимостей и обновления пакетов. В Debian включены стабильные версии пакетов. Это накладывает некоторые ограничения, в частности, многие пакеты устаревшие, но проверенные временем.

Debian поддерживает множество аппаратных архитектур. Дистрибутив можно использовать для встраиваемых систем.

На основе дистрибутива Debian создаются такие дистрибутивы, как Ubuntu, MX Linux, Knoppix, MEPIS, Damn Small Linux, Dreamlinux и другие.

История

Основатель дистрибутива американский программист Ян Мердок (Ian Ashley Murdock). Он анонсировал Debian 16 августа 1993 г. и изначально назвал его "the Debian Linux Release".

Название

Название Debian образовано от соединения имени подруги Яна Мердока, Дебры Линн (Debra Lynn), и его собственного, Ian: Deb+Ian.

Установка

Установка Debian требует некоторых навыков и знаний, однако, по каждой версии Debian существует подробное руководство по установке Debian на русском языке.

Установка проходит в графическом режиме с пояснениями каждого шага (доступен русский язык).

Есть два распространенных способа установки Debian: обычная и Netinstall.

Netinstall — сетевая установка. В данном случае вы скачиваете небольшой образ диска (до 200 мб), который содержит базовые данные для установки, а все дополнительные пакеты скачиваются из интернета во время установки.

Обычную установку можно выполнить из Live-режима, используя графическую программу установки.

Стандартные имя пользователя и пароль Live-режима:

Дистрибутивы, основанные на Debian

Некоторые дистрибутивы, представленные в нашем каталоге, основанные на дистрибутиве Debian или тесно связанные с ним:

Простую, ориентированную на пользователей информацию о тестируемом выпуске вы можете посмотреть в ЧаВО Debian.

Обычным пользователям и разработчикам тестируемого выпуска важно знать, что обновления безопасности для тестируемого выпуска не поддерживаются командой безопасности. Дополнительную информацию смотрите в ЧаВО команды безопасности.

Эта страница в первую очередь содержит те аспекты тестируемого выпуска, которые важны для разработчиков Debian.

Как работает тестируемый выпуск

Тестируемый выпуск генерируется автоматически. Он создается из нестабильного выпуска при помощи набора сценариев, которые пытаются переместить пакеты, не имеющие, как кажется, серьезных ошибок, мешающих выпуску (release-critical bugs). Эти сценарии выполняют перемещение пакетов с учётом их зависимостей.

Пакет (конкретная версия пакета) будет перемещена в тестируемый выпуск, когда он удовлетворяет всем следующим критериям:

Пакет должен находиться в нестабильном выпуске 10, 5 или 2 дня, в зависимости от срочности загрузки;
Он должен быть скомпилирован и обновлён для всех архитектур, для которых он был ранее скомпилирован в нестабильном выпуске;
Он не должен содержать ошибок, мешающих выпуску и которые не содержатся в версии пакета, уже находящейся в тестируемом выпуске (дополнительную информацию см. ниже);
Все его зависимости либо должны быть удовлетворены пакетами, уже находящимися в тестируемом выпуске, либо должны удовлетворяться группой пакетов, которые устанавливаются одновременно с ним;
Операция установки пакета в тестируемый выпуск не должна ломать какие-либо пакеты, уже находящиеся в тестируемом выпуске. (дополнительную информацию см. ниже.)

Пакет, удовлетворяющий первым трём условиям из обозначенных выше, называется Годным кандидатом (Valid Candidate) .

Сценарий обновления показывает, когда каждый пакет может быть перемещен из нестабильного выпуска в тестируемый . Сценарий предоставляет два вывода:

вывод обновления [в формате gzip]: полный, необработанный вывод сценариев тестируемого вывода, содержащий информацию о рекурсивном прохождении по списку кандидатов

Часто задаваемые вопросы (с ответами)

Что такое ошибки, мешающие выпуску (release-critical bugs), и как они подсчитываются?

Все ошибки с высокой важностью по умолчанию считаются ошибками, мешающими выпуску; в настоящее время это ошибки с важностью critical, grave и serious.

Предполагается, что эти ошибки оказывают влияние на шансы пакета войти в стабильный выпуск Debian: вообще, если пакет содержит открытые ошибки, мешающие выпуску, он не попадет в тестируемый выпуск и, следовательно, не будет выпущен в составе стабильного выпуска.

Количество ошибок в тестируемом выпуске представляет собой все ошибки, мешающие выпуску, которые отмечены как применимые к комбинациям пакет/версия, доступным в тестируемом выпуске для выпускаемой архитектуры.

Как установка пакета в тестируемый выпуск может сломать другие пакеты?

Структура архивов выпуска такова, что они могут содержать только одну версию пакета; пакет, определяется его именем. Поэтому когда пакет с исходным кодом acmefoo устанавливается в тестируемый выпуск вместе со своими двоичными пакетами acme-foo-bin, acme-bar-bin, libacme-foo1 и libacme-foo-dev, то старая версия удаляется.

Тем не менее, старые версии могут предоставлять двоичный пакет со старой библиотекой с тем же именем, как например libacme-foo0. Удаление старого acmefoo удалит libacme-foo0, что сломает все пакеты, зависящие от этого пакета.

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

Когда набор двоичных пакетов, предоставляемый пакетом с исходным кодом, изменяется указанным образом, все пакеты, зависящие от старых двоичных файлов, должны быть обновлены так, чтобы они зависели от новых двоичных файлов. Так как установка такого пакета с исходным кодом в тестируемый выпуск ломает все пакеты, зависящие от него в тестируемом выпуске, следует быть осторожным: все зависящие пакеты должны быть обновлены и готовы для установки, чтобы они не были сломаны, и, когда всё готово, обычно требуется вмешательство менеджера выпуска или его ассистента.

Если вы испытываете проблемы со сложными группами пакетов, для помощи свяжитесь с debian-devel или debian-release.

Я всё ещё не понимаю! Сценарии тестируемого выпуска говорят, что этот пакет является годным кандидатом, но он всё ещё не попал в тестируемый выпуск.

Скорее всего это происходит потому, что когда пакет устанавливается, напрямую или не напрямую, он сломает некоторые другие пакеты.

Проверьте зависимости вашего пакета. Допустим ваш пакет зависит от libtool или от libltdl X . Ваш пакет не может войти в тестируемый выпуск, пока нужная версия libtool не будет готова войти в него.

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

Вот когда текстовый вывод [в формате gzip] оказывается полезен: он даёт подсказки (хотя и очень краткие) о том, какие пакеты ломаются, когда годный кандидат добавляется в тестируемый выпуск (подробная информация в справочнике разработчика).

Почему иногда трудно добавить пакеты с Архитектура: all в тестируемый выпуск?

Если должен быть установлен пакет с Архитектура: all , его зависимости должны удовлетворяться на всех архитектурах. Если он зависит от определённых пакетов, которые компилируются только на ограниченном наборе архитектур Debian, то его зависимости не могут быть удовлетворены.

Тем не менее, в данное время тестируемый выпуск игнорирует возможность установки пакетов с Архитектура:all на не-i386 архитектуры. ( Это серьезный хак и я не то, чтобы рад, сделать это, но вот пожалуйста. —aj)

Мой пакет застрял, так как он устарел на некоторых архитектурах. Что мне делать?

Проверьте статус вашего пакета в базе данных журналов сборки. Если пакет не собран, он будет отмечен как провалившийся (failed); исследуйте журналы сборки и исправьте проблемы, вызванные исходным кодом вашего пакета.

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

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

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

Есть ли исключения? Я уверен, что `acmefoo` попал в тестируемый выпуск, хотя он не удовлетворяет всем требованиям.

Менеджеры выпуска могут отменять эти правила двумя способами:

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

Покажите реальный, нетривиальный пример

Вот он: когда пакет с исходным кодом apache устанавливается в тестируемый выпуск вместе со своими двоичными пакетами apache, apache-common, apache-dev и apache-doc, старая версия удаляется.

Тем не менее, все пакеты с модулями Apache зависят от apache-common (>= что-то ), apache-common (<< что-то ) , поэтому это изменение сломает все эти зависимости. Следовательно, все модули Apache должны быть перекомпилированы с новой версией Apache для того, чтобы тестируемый выпуск был обновлён.

Давайте рассмотрим это более тщательно: после того как все модули будут обновлены в нестабильном выпуске так, чтобы они работали с новой версией Apache, сценарии тестируемого проверят пакет apache-common и обнаружат, что он ломает все модули Apache, поскольку они имеют параметр Зависит: apache-common (<< текущая версия ) , и затем проверят libapache- foo и обнаружат, что он не устанавливается, поскольку имеет параметр Зависит: apache-common (>= новая версия ) .

Тем не менее, позже они применят другую логику (иногда она вызывается вручную): они будут игнорировать тот факт, что apache-common ломает пакеты, и продолжат; если пакет всё ещё не работает после того, как мы сделаем всё, что можно, очень жаль, но может быть он будет работать. Позже сценарии проверят все случайные пакеты libapache- foo и увидят, что они работают.

После того, как всё было попробовано, они попытаются проверить то, сколько пакетов будет сломано, выяснят, лучше это или хуже, чем то, что было изначально, и если да, примут всё и забудут об этом пакете. Вы увидите это в update_output.txt на строках recur: .

по сути, говорит, что уже обнаружено, что foo и bar лучше, я не пытаюсь baz , чтобы посмотреть, что происходит, даже несмотря на то, что это ломает пакеты . Строки update_output.txt, начинающиеся с accepted (принято) , обозначают, что то, что появится лучше, а строки, начинающиеся с skipped (пропущено) обозначают, что то, что может появится, хуже.

Файл `update_output.txt` совершенно нечитаем!

Давайте рассмотрим пример:

Это означает, что если cln войдёт в тестируемый выпуск, то ginac-cint и libginac-dev станут неустанавливаемыми в тестируемом выпуске на i386. Заметьте, что архитектуры проверяются в алфавитном порядке и показываются только проблемы первой архитектуры — вот почему чаще всего показывается архитектура alpha.

Строки с got содержат количество проблем в тестируемом выпуске на разных архитектурах (до первой архитектуры, где найдена проблема — см. выше). i-45 означает, что если бы cln вошёл в тестируемый выпуск, в выпуске было бы 45 неустанавливаемых пакетов на i386. Некоторые из пунктов, приведённых над и под cln, показывают, что 43 пакета были неустанавливаемыми в тестируемом выпуске на i386 в это время.

Строка skipped: cln (0) (150+4) означает, что остаётся 150 пакетов, которые следует проверить, чтобы проверка всех пакетов была завершена, и что 4 пакета уже не планируются для обновления, так как они будут ломать зависимости. Число (0) не важно, вы можете его игнорировать.

Заметьте, что проводится несколько проверок всех пакетов в одном запуске сценария тестируемого выпуска.

Изначально часто задаваемые вопросы и ответы на них собрал Жиль Бьян (Jules Bean).

Дополнительная информация

Следующие страницы содержат дополнительную информацию о текущем состоянии тестируемого выпуска и миграции пакетов из нестабильного выпуска в тестируемый:

Статистика по устаревшим двоичным пакетам в testing, stable
Проблемы с зависимостями в testing, stable

Также вам может быть интересно прочитать старое письмо с объяснением. Его единственный главный недостаток в том, что в нём не учитывается пул пакетов, так как он был реализован Джеймсом Троупом (James Troup) после того, как было написано письмо.

Тестирующий код доступен с ftp-master.

За реализацию тестирования благодарим Энтони Тоунса (Anthony Towns).

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

Как использовать Debian Testing (next-stable)

Надежный способ установить testing с нуля - это произвести минимальную установку Debian Stable, а потом обновиться со stable до testing.

Кроме того, вы можете использовать testing image of the debian-installer, но обратите внимание, что установщик testing дистрибутива больше подходит для тестирования самого установщика, чем для установки testing дистрибутива. Bugs in the testing installer should be filed against the debian-installer pseudopackage.

Чтобы обновиться до testing, если вы уже установили стабильный выпуск, отредактируйте файл /etc/apt/sources.list, заменяя 'stable' (или текущее кодовое имя стабильного выпуска) в строках apt на 'testing' (или кодовое имя следующего стабильного выпуска). Могут потребоваться дополнительные изменения в этом файле. Вы также можете сделать это с помощью synaptic.

Кодовое имя следующего стабильного выпуска, например "bookworm", будет отслеживать "bookworm", даже когда "bookworm" перейдет в статус стабильного или старого стабильного выпусков, в том время как "testing" будет отслеживать только тестируемые выпуски. Если вы предпочитаете отслеживать jessie, когда он станет стабильным, обновите файл /etc/apt/sources.list заменив "stable" или "testing" на кодовое имя следующего тестируемого выпуска.

После установки или корректировки источников программного обеспечения, регулярно запускайте apt-get update && apt-get upgrade, чтобы получить новые версии и обновления безопасности. Если вы заметили, что некоторые пакеты не обновлены, вы должны попробовать запустить apt-get dist-upgrade, но будьте осторожны, эта команда попытается установить или удалить пакеты, поэтому тщательно проверяйте все предлагаемые действия до процесса выполнения.

Примечание

2016-07-14, обновляя Stretch из Jessie могли удалиться некоторые пакеты, которые нужны для запуска Gnome, и конечном итоге, вы могли оказаться в командной строке. Для восстановления Gnome, зайдите под пользователем root и выполните следующие команды:

Другие пакеты, возможно, также нужно будет переустановить, используйте опцию reinstall, как показано выше, если будут ошибки.

Соображения

Пример из видов временной поломки которые могут произойти в next-stable (testing) дистрибутиве: было обновление perl-5.6.0 до perl-5.6.1 из-за которого perl не мог найти свои модули, если они были из пакета собранного с помощью perl-5.6.0. Однако, вручную установив переменную PERL5LIB на /usr/lib/perl/5.6.0, можно было решить проблему даже до того, как в testing поступит исправленная версия пакета.

Testing меняется чаще чем stable, но не так часто как unstable, поэтому ожидается, что новые стабильные версии программ будут установлены так скоро, как они будут готовы для next-stable (testing). Рано или поздно testing "замораживается' для неминуемой подготовки к становлению стабильным выпуском. Смотрите также DebianStability.

По сравнению со stable и unstable, testing имеет худщую скорость получения обновлений безопасности. Если речь идет о безопасности, не выбирайте testing.

Поговорим о Debian и Ubuntu. И там, и там можно использовать команды apt-get для управления приложениями. Оба дистрибутива поддерживают установку DEB-пакетов. Часто, читая статьи про Linux, можно видеть, что для Debian и Ubuntu подходят одни и те же инструкции по установке каких-то программ.

Чем же, при такой близости друг к другу, различаются эти дистрибутивы?

Для начала надо сказать, что Debian и Ubuntu принадлежат одном и тому же семейству Linux-дистрибутивов. А именно — Debian — это исходный дистрибутив, созданный в 1993 году Иэном Мёрдоком. А дистрибутив Ubuntu, основанный на Debian, создал в 2004 году Марк Шаттлворт.

«Дистрибутив Ubuntu основан на Debian», — что это значит?

Хотя и существуют сотни дистрибутивов Linux, лишь немногие из них являются независимыми, то есть, созданными с чистого листа. Среди крупнейших независимых дистрибутивов можно отметить Debian, Arch Linux, Red Hat.

Дистрибутив Ubuntu основан на Debian. Это значит, что Ubuntu использует тот же механизм работы с пакетами (APT), что и Debian, и то, что в Ubuntu применяется очень много пакетов и библиотек из репозиториев Debian. В качестве базы для Ubuntu используется инфраструктура Debian.

Базой для Ubuntu является Debian

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

Различия между Ubuntu и Debian

Итак, ОС Ubuntu построена на базе архитектуры и инфраструктуры Debian, она использует те же DEB-пакеты, что и Debian.

Значит ли это, что пользоваться Ubuntu — это то же самое, что и пользоваться Debian? Не совсем. Существует множество дополнительных факторов, которые отличают один дистрибутив от другого.

Обсудим эти факторы и, таким образом, сравним Ubuntu и Debian. Прежде чем мы начнём — прошу помнить о том, что некоторые сравнения применимы к настольному варианту ОС, а некоторые — к серверному.

▍1. Цикл выпуска

Существует два вида выпусков Ubuntu — LTS ( Long Term Support, «поддержка в течение длительного периода») и обычные. LTS-выпуски выходят каждые два года, они поддерживаются в течение 5 лет. При обновлении системы у пользователя есть возможность обновиться до следующего доступного LTS-выпуска. Такие выпуски считаются более стабильными, чем обычные.

Каждые шесть месяцев выходят обычные выпуски Ubuntu, не относящиеся к категории LTS. Их поддержка осуществляется лишь в течение девяти месяцев, но в них имеются более новые, в сравнении с последним LTS-выпуском, версии ПО и возможности. Когда заканчивается жизненный цикл используемого обычного выпуска — нужно обновиться до следующей версии Ubuntu.

В результате у того, кто пользуется Ubuntu, учитывая особенности выхода её выпусков, есть возможность выбирать между стабильностью и новыми возможностями.

А вот у Debian имеется три вида выпусков: стабильные (Stable), тестируемые (Testing) и нестабильные (Unstable). Нестабильные выпуски предназначены для «полевых» испытаний, для реальной работы ими лучше не пользоваться.

А тестируемые выпуски не так уж и нестабильны. Соответствующая ветка используется для подготовки следующего стабильного выпуска. Некоторые пользователи Debian выбирают именно Testing-выпуски для того чтобы быстрее других получить доступ к новым возможностям.

И наконец — скажем пару слов о стабильных выпусках Debian. Это — основные выпуски Debian. Они могут не отличаться наличием в них самого нового ПО или самых новых возможностей, но, если говорить о стабильности, то можно сказать, что они исключительно стабильны.

Новый стабильный выпуск выходит раз в два года. Такие выпуски поддерживаются в течение трёх лет. После этого нужно обновляться до нового стабильного выпуска.

▍2. Свежесть программного обеспечения

Команда apt-cache policy

Ориентированность ОС Debian на стабильность означает то, что разработчики системы не всегда стремятся к тому, чтобы включать в неё самые свежие версии программного обеспечения. Например, в самой свежей Debian 11 используется GNOME 3.38, а не последняя GNOME 3.40.

То же самое касается и другого ПО — вроде GIMP, LibreOffice и так далее. Это — тот компромисс, на который вынужден идти тот, кто выбирает Debian. Именно поэтому в сообществе Linux популярна шутка «Debian stable = Debian stale», намекающая на то, что стабильная Debian — это Debian не первой свежести.

Выпуски Ubuntu LTS тоже нацелены на стабильность. Но в них обычно используются более актуальные, чем в Debian, версии популярного ПО.

Стоит обратить внимание на то, что то же самое справедливо и для некоторых программ, устанавливаемых из репозиториев, поддерживаемых разработчиками ОС. В результате, например, если вам нужна самая последняя версия Docker — можно добавить репозиторий Docker и в Debian, и в Ubuntu.

В целом же можно отметить, что в стабильных выпусках Debian обычно используются более старые версии ПО, чем в сравнимых выпусках Ubuntu.

▍3. Доступность программного обеспечения

И Debian, и Ubuntu имеют огромные репозитории программного обеспечения. Но у Ubuntu есть ещё и PPA (Personal Package Archive). Благодаря PPA процедура установки более новых программ или свежих версий уже имеющихся программ немного облегчается.

Использование команды add-apt-repository

Использовать PPA можно и в Debian, но это не так удобно, как в Ubuntu. В Debian это обычно сопряжено с некоторыми проблемами.

▍4. Поддерживаемые платформы

Доступны варианты дистрибутива Ubuntu для 64-битных платформ x86 и ARM. В рамках проекта больше не выпускаются 32-битные образы ОС.

А Debian, с другой стороны, поддерживает и 32-битные и 64-битные архитектуры. Кроме того, Debian поддерживает ещё и 64-битную архитектуру ARM (arm64), и ARM EABI (armel), и ARMv7 (EABI hard-float ABI, armhf), и 32-битную архитектуру MIPS с обратным порядком байтов (mipsel), и 64-битную архитектуру MIPS с обратным порядком байтов (mips64el), и 64-битную архитектуру PowerPC с обратным порядком байтов (ppc64el), и IBM System z (s390x).

В результате — неудивительно то, что Debian называют «универсальной операционной системой».

▍5. Установка

Установка Ubuntu гораздо проще, чем установка Debian. И я, говоря это, не шучу. Установка Debian может вызвать сложности даже у пользователей Linux среднего уровня подготовки.

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

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

Не самая дружелюбная процедура самостоятельной загрузки прошивки в Debian

Команда разработчиков Ubuntu гораздо снисходительнее относится к включению в состав стандартного дистрибутива драйверов и прошивок с закрытым исходным кодом.

Кроме того, установщик Debian выглядит устаревшим, чего не скажешь об установщике Ubuntu. Установщик Ubuntu, кроме того, распознаёт другие ОС, установленные на диске, и предлагает пользователю возможность установки Ubuntu совместно с уже установленными системами (с возможностью сформировать конфигурацию двойной загрузки). А вот исследуя установку Debian я ничего такого не заметил.

Установка Ubuntu проходит гораздо приятнее, чем установка Debian

▍6. Встроенная поддержка различного аппаратного обеспечения

ОС Debian, как уже было сказано, ориентирована, преимущественно на FOSS (Free and Open Source Software, свободное и открытое программное обеспечение). Это означает, что ядро, предоставляемое Debian, не содержит драйверов и прошивок с закрытым кодом.

Это не значит, что такие драйверы и прошивки нельзя заставить работать в Debian. Всё дело в том, что пользователю придётся самостоятельно добавлять или включать соответствующие репозитории и вручную устанавливать то, что ему нужно. Это может, особенно у новичков, отбить желание пользоваться Debian.

Нельзя сказать, что Ubuntu — это совершенная ОС, но, в деле встроенной поддержки различных аппаратных устройств, она гораздо лучше Debian. Это означает, что Ubuntu легче привести в рабочее состояние, и то, что пользователю будет, с самого начала, удобнее работать с этой ОС, чем с Debian.

▍7. Выбор окружения рабочего стола

В Ubuntu, по умолчанию, используется специально настроенное окружение рабочего стола GNOME. Поверх него можно установить другое окружение, или выбрать какой-то вариант Ubuntu с другим окружением рабочего стола — вроде Kubuntu (там используется KDE) или Xubuntu (Xfce).

В Debian тоже, по умолчанию, устанавливается GNOME. Но установщик даёт пользователю возможность самому выбрать окружение рабочего стола.

Выбор окружения рабочего стола при установке Debian

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

▍8. Игры

В последнее время ситуация с играми в Linux, в целом, улучшилась, что произошло благодаря Steam и Proton. Но возможность запуска игр, конечно, сильно зависит и от аппаратного обеспечения.

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

Нельзя сказать, что того же, что способна дать Ubuntu, нельзя достичь в Debian, но на это потребуется потратить некоторое время и некоторые силы.

▍9. Производительность

Если говорить о производительности, то чёткого ответа на вопрос о том, что быстрее — Ubuntu или Debian — нет. Причём, это справедливо и для настольных систем, и для серверов. И та и другая операционные системы популярны как на настольном, так и на серверном фронтах.

Производительность компьютера зависит от его аппаратных возможностей и от набора установленного на нём программного обеспечения. Настраивать параметры системы, оптимизируя её производительность, можно и в Ubuntu, и в Debian.

▍10. Сообщество и поддержка

Debian — это истинный продукт трудов сообщества разработчиков. Всё, что касается управления этим проектом, находится в ведении членов сообщества.

За Ubuntu стоит компания Canonical. Но это — не тот проект, который поддерживает исключительно некая корпорация. Вокруг Ubuntu тоже сформировалось сообщество разработчиков. Но окончательные решения по любым вопросам, касающимся Ubuntu, принимает именно Canonical.

Если же говорить о поддержке, то существуют специализированные форумы, на которых можно получить помощь и по Ubuntu, и по Debian.

Canonical, кроме того, предлагает профессиональную поддержку своим корпоративным клиентам. Разработчики Debian такой поддержки не предлагают.

Итоги

И Debian, и Ubuntu — это отличный выбор как для настольного компьютера, так и для сервера. Эти ОС используют менеджер пакетов apt и DEB-пакеты, и, в результате, дают своим пользователям очень похожие возможности.

Но для эффективного использования Debian нужен некоторый опыт. Особенно — если речь идёт о настольном варианте ОС. Если вы только начинаете осваивать мир Linux — то вам лучше будет остановить свой выбор на Ubuntu. Я полагаю, что новичкам, прежде чем перейти к Debian, нужно наработать некоторый опыт и познакомиться с Linux в целом.

Нельзя сказать, что знакомство с Linux нельзя начать с Debian, но такое начало, вероятнее всего, станет для новичка серьёзным испытанием.

Как вы выбираете дистрибутивы Linux для настольных компьютеров и для серверов?

Читайте также: