Debian 32 или 64 какую выбрать

Обновлено: 03.07.2024

У меня есть рабочая станция Linux, которая в настоящее время имеет 4 ГБ оперативной памяти и планирует в ближайшее время перейти на 8 ГБ. ЦП является Core2Quad Q9550 .

Должен ли я установить 32- или 64-битный вариант Linux?

Вы должны установить 64-разрядную версию Linux. Несмотря на то, что для 32-разрядного ядра существуют способы адресации более 4 ГБ, приложения будут по-прежнему иметь ограничение в 3 ГБ.

Спасибо за ответ. Вы говорите о PAE? Это работает правильно на практике? В настоящее время я использую PAE для доступа к 4 ГБ без проблем. @ jia3ep: какие-либо конкретные причины, чтобы избежать PAE? Действительно, единственная причина не использовать PAE - снижение производительности на

0,1%, которое настолько незначительно, что вы даже не заметите этого.

Вы можете запустить 64-битное ядро ​​и 32-битный дистрибутив, который предоставит вам полный доступ к 4 ГБ или более оперативной памяти без потери производительности PAE. Это то, что я делаю на своей машине. Debian имеет linux-image-amd64, доступный для i386. К сожалению, Ubuntu этого не делает, вам придется скомпилировать собственное ядро, и я не знаю, есть ли в других дистрибутивах пакеты.

Тем не менее, для новых установок я бы рекомендовал 64-битную, так как производительность выше, если вы можете жить с хаки для 32-битных бинарных файлов, таких как Skype и некоторые плагины для браузера. В настоящее время дистрибутивы RPM поддерживают это нормально, в то время как Debian и Ubuntu этого не делают, но сейчас работают над поддержкой нескольких архитектур , причем первый релиз ожидается для Ubuntu 9.10 в этом году.

Снижение производительности PAE происходит из-за дополнительного уровня в поиске таблицы страниц. Однако, хотя системы PAE используют трехуровневую систему таблиц страниц, системы x86-64, работающие в длинном режиме, используют четыре уровня. Если это единственное наказание за использование PAE, разве 64-разрядная версия не всегда будет иметь худшую производительность в этом отношении? Конечно, 64 бит предлагает некоторые другие функции, которые могут восполнить компромисс, но вы, кажется, рекомендуете против PAE из-за дополнительного поиска таблицы страниц.

Вот один обзор от LinuxForums.

Я бы колебался, если вы много работали с нишей или разрабатывали инструменты, написанные на полностью скомпилированных языках. Многие из проектов, которые меня интересуют, например, LDC , только начинают поддерживать 64-битные. Лично я сдерживаюсь, но я также держу больше оперативной памяти, так что это не проблема для меня.

+1 для проверки того, что все необходимое программное обеспечение поддерживается на 64-битной.

32-разрядный может использовать только менее 4 ГБ для одного процесса , но он может использовать больше для всей системы. В Linux не так много несерверных приложений, которым понадобится столько оперативной памяти, сколько я могу себе представить.

Вам просто нужно установить ядро ​​PAE (расширение физического адреса):

и затем перезагрузите компьютер. Беги сверху или свободнее и тебе надо больше барана. Я рекомендую 32-разрядную версию для настольных компьютеров.

> Я рекомендую 32-битную версию для настольных компьютеров. Почему? Раньше не было ни 64-битного (Sun) Java-плагина, ни 64-битного (Adobe) флеш-плагина, но не решены ли сейчас эти два случая?

Я бы установил 64-битную версию и, возможно, что-то вроде VirtualBox, чтобы я мог параллельно запускать 32-битную версию на тот случай, если мне понадобится какое-то программное обеспечение, доступное только в 32-битной версии.

Вы не сможете использовать более 4 ГБ памяти, используя 32-разрядное ядро, не перепрыгивая через некоторые циклы, такие как PAE, которых, по-моему, лучше избегать.

Я запускаю 64bit 9.04 для домашнего компьютера. Я довольно много работаю с этой машиной, и единственная проблема, связанная с 64-битной архитектурой, с которой я сталкиваюсь, - это проблемы со стабильностью в 64-битной версии Adobe Flash.

Перейти на 64-разрядный. 32-разрядный может получить доступ только к 3,5 ГБ ОЗУ, и большинство проблем совместимости были устранены. Чтобы сделать это еще проще, используйте популярный дистрибутив, такой как Ubuntu .

Странно, 32 видит на 100 мегабайт больше.
Ну дак вот, есть ли весомые + для перехода на 64?
Из сторонних программ:
Инет - гуглохром
Скайп, Кутим, Деадбиф, Нерка, Дропбокс, Виртуалбокс
они тоже на 64 есть? Или надо пилить?

Из сторонних программ:
Инет - гуглохром
Скайп, Кутим, Деадбиф, Нерка, Дропбокс, Виртуалбокс
они тоже на 64 есть? Или надо пилить?

Skype для 64 бит нет и не будет - нужно ставить 32 бит + кучу ужных ему 32 бит библиотек.

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


Перед этим читал про винду. И прямо пишут, что аж +10% к скорости системы.
есть где нибудь сравнение/тест? Или все примерно одинаковое? - Не читайте большевистские газеты перед едой.
- Так других же нет?
- Так никаких не читайте.

И вы пишите .
(им то новые железки продавать надо? им тоже кушать надо?)


10% - это не аж , это всего лишь .
Вы их сможете каким-то образом ощутить . 10%?
Или чем-то имерить? Все наоборот: нет никаких причин на 64-битном железе оставаться на 32 бит. Это разные архитектуры, хотя и похожие. Одна из них эмулируется. Впрочем, на самом деле они обе эмулируются, так что разница несущественная. Все наоборот: нет никаких причин на 64-битном железе оставаться на 32 бит. Это разные архитектуры, хотя и похожие. Одна из них эмулируется. Впрочем, на самом деле они обе эмулируются, так что разница несущественная.
Почему? Существенные плюсы 64? Именно на моих 5 гигах.
Скорость? Мощность? Динамика? Распредение нагрузки? rain_99
Вам уже дважды сказали: существенной разницы Вы не заметите, по крайней мере при повседневной работе.
в консоли
вку́пе (с чем-либо)
в общем
вообще
в течение (часа)
новичок
нюанс
по умолчанию
приемлемо
проблема
пробовать
трафик
Все наоборот: нет никаких причин на 64-битном железе оставаться на 32 бит. Это разные архитектуры, хотя и похожие. Одна из них эмулируется. Впрочем, на самом деле они обе эмулируются, так что разница несущественная.
Почему? Существенные плюсы 64? Именно на моих 5 гигах.
Скорость? Мощность? Динамика? Распредение нагрузки?

Именно на ваших 5Gb, если вы используете 32 бит, вам нужно только проследить, чтобы устанавливаемая сборка ISO была с поддержкой технологии PAE.
P.S. Но, судя по вашей команде free, у вас с этим всё в порядке.

Ну вот тоже, опросил знакомых. Большинство "за прогресс".
Прямо такая формулировка.

Все говорят, что мы вместе.
Все говорят, но не знают в каком (с).

Как же мне надоели эти холивары 32vs64.
Для себя десять лет назад решил что если в процессоре есть какие-то дополнительные фичи, то уж надо их использовать. Потерять от этого точно ничего не потеряешь, а где-то немножко да выиграешь. С тех пор никогда не ставил i386-системы на amd64-машины.
в консоли
вку́пе (с чем-либо)
в общем
вообще
в течение (часа)
новичок
нюанс
по умолчанию
приемлемо
проблема
пробовать
трафик
Ну вот тоже, опросил знакомых. Большинство "за прогресс".

Ну так и флаг в руки!
Чего холиварим?

P.S. Можно ещё социологические опросы по всей форме проводить по решению технических проблем . среди широких слоёв населения.

Почему? Существенные плюсы 64? Именно на моих 5 гигах.
Скорость? Мощность? Динамика? Распредение нагрузки? реальная разница только в том, что для процесса сегмент данных может быть больше 3 гиг.
реальная разница только в том, что для процесса сегмент данных может быть больше 3 гиг.
в консоли
вку́пе (с чем-либо)
в общем
вообще
в течение (часа)
новичок
нюанс
по умолчанию
приемлемо
проблема
пробовать
трафик
здесь надо еще заметить, что 5 гигабайт памяти крайне мало, там отличий от 32 битного пае заметно не будет. От 8 гигабайт и выше - вот здесь оно того может и стоит.
Хотя я знаю, что 64 битный режим дарит некоторые дополнительные фишки от процессора, однако, не уверен в их особых плюсах. Тем более учитывая старый процессор ТС.

x86_64 в целом должно работать чуть быстрее, как уже сказали на 0-10%. При этом вырастет потребление ОЗУ приложениями, не в два раза, но на 10-20% легко.
Так же, несмотря на то, что технология PAE позволяет использовать более 4ГБ ОЗУ на 32-битных системах, она не позволяет выделить более 4ГБ одному приложению.

Лучше всего (хотя и не обязательно) добить ОЗУ до максимума (вероятно 8ГБ на этом железе) и перейти уже на x86_64.
В качестве примера: у меня x86_64 система отлично работает на древнем одноядерном P4 с 7ГБ ОЗУ.

вырастет потребление ОЗУ приложениями, не в два раза, но на 10-20% легко.
Пруф есть? Или логическое объяснение? Типов данных, которые занимают больше памяти на x86_64, очень немного, программ, которые используют разные типы данных в зависимости от архитектуры, тоже. Я и в единицы процентов не поверю, максимум — десятые доли.
в консоли
вку́пе (с чем-либо)
в общем
вообще
в течение (часа)
новичок
нюанс
по умолчанию
приемлемо
проблема
пробовать
трафик
Пруфа вот так под рукой нет, но что-то точно было. Можно на двух лив-сд разных архитектур проверить, запустив в них одно и то же приложение. вырастет потребление ОЗУ приложениями, не в два раза, но на 10-20% легко.
Пруф есть? Или логическое объяснение? Типов данных, которые занимают больше памяти на x86_64, очень немного, программ, которые используют разные типы данных в зависимости от архитектуры, тоже. Я и в единицы процентов не поверю, максимум — десятые доли.

Тип в основном один - указатель. Только в порядочных программах их немало
Ещё выравнивание в структурах не по 2 байта, а по 4. Но это как раз мелочи. вырастет потребление ОЗУ приложениями, не в два раза, но на 10-20% легко.
Пруф есть? Или логическое объяснение? Типов данных, которые занимают больше памяти на x86_64, очень немного, программ, которые используют разные типы данных в зависимости от архитектуры, тоже. Я и в единицы процентов не поверю, максимум — десятые доли.

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

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

Да, пожалуй я погорячился. Верю в единицы процентов для сферической программы в вакууме. ☺
в консоли
вку́пе (с чем-либо)
в общем
вообще
в течение (часа)
новичок
нюанс
по умолчанию
приемлемо
проблема
пробовать
трафик
Да, пожалуй я погорячился. Верю в единицы процентов для сферической программы в вакууме. ☺
А вообще, все такие сравнения, которые в качестве холивара не утихают лет 4-5, пустая трата времени . всё примерно одинаково: плюсы покрывают минусы и наоборот.

На 4 Гб памяти х64 система не есть гуд. Нужно 6 Гб минимум. Но всё зависит от используемых приложений, у меня и при 8Гб иногда система что-то сбрасывает в своп.

"На глаз" прирост скорости не определить: пользователь всё равно самый тормозной элемент системы.

По факту ориентироваться стоит на используемый софт. Если нужный софт перестает поддерживаться для определённой архитектуры - это повод задуматься, да. Если лет 10 тому чего-то не было для х64, то теперь вот ситуация медленно, но верно меняется, х32 сиротеет постепенно.

Q6600, 5гиг оперативки, GeForce GTS 250, хард 500 гиг.
То есть эмпирически 64 умеем.

Вполне. Я бы задумался о добавлении памяти и мигрировал. В Германию или Австрию.


Архитектура компьютера (англ. Computer architecture) — структура вычислительной машины, определяющая проведение обработки информации и принципы взаимодействия технических средств и программного обеспечения.
Оперативная память компьютера (ОЗУ, RAM). Сокращенно оперативную память компьютера называют ОЗУ (оперативное запоминающее устройство) или RAM (random access memory — память с произвольным доступом).

Что такое разрядность? Разрядность – способность одновременно обрабатывать какое-то количество битов.
Все системы Linux существуют в двух вариантах – 32-битные и 64-битные.
Архитектурные различия между 32 и 64-битными версиями Linux, разумеется, есть.
Самые главные особенности и отличия, которые непосредственно касаются пользователя и с которыми приходится сталкиваться:

1. Максимальный объем оперативной памяти (ОЗУ).
2. Разрядность операционной системы (32 или 64-bit).
3. Разрядность процессора.

Максимальный объем оперативной памяти.

32-битная операционная система может использовать, "видеть" не более 4 ГБ оперативной памяти. Это самое главное отличие, и самое существенное. Если в вашем компьютере оперативная память (ОЗУ) - 2 ГБ, то 32-битная операционная система работает с таким объемом нормально.

64-битная операционная система может работать с гораздо бОльшими объемами памяти – до 192 ГБ.

Если вы на компьютере с 4 ГБ ОЗУ будете работать под управлением 32-битной ОС, то она просто не увидит такой объем. Все, что она сможет использовать – это примерно 3.5 ГБ из 4 ГБ. Остальной объем она не может предоставить для работающих программ. Разумеется, если вы установите в компьютер с 8 ГБ ОЗУ, скажем, и при этом будете оставаться на 32-битной системе, то она так же не увидит более 3.5 ГБ из всего установленного объема и оставшиеся 4.5 ГБ останутся просто неиспользованными.

Какими особенностями обладает 64-битная система?

Визуально – никакими. Т.е. внешне – это обычная ОС, ничем не выделяющаяся от 32-битного варианта.
Технически – небольшие различия есть. Первое, собственно, что 64-битная ОС "видит" большие объемы памяти и умеет с ними работать. Второе – она позволяет запускать 64-битные приложения (32-битная - нет).

Разрядность процессора.

Соответственно, чтобы иметь возможность установить 64-битную Linux, ваш процессор должен поддерживать 64-битные инструкции (иначе вы даже не сможете начать установку 64-битной Linux). Называться эти инструкции могут по-разному: у Intel – IA64, у AMD – AMD64. Убедиться, что ваш процессор поддерживает нужные инструкции можно с помощью специальной терминальной команды - free -m, которая определяет объём оперативной памяти (ОЗУ) вашего компьютера.

Если вы новичок в Linux и не знаете архитектуру вашего компьютера, установите на диск CD/DVD или флешку желаемый дистрибутив Linux 32-bit (потому что система 32-bit загрузится в любом случае), загрузите его в live-режиме, откройте из системного меню программу терминал скопируйте и выполните команду (нажмите Enter):


Как видно на снимке, после выполнения команды в терминале на моём компьютере, в разделе Mem (Memory - Память) отобразилось total (общее, всего) - 4038 МБ ОЗУ или если перевести в гигабайты (1 ГБ=1024МБ), это около 4ГБ оперативной памяти, которой обладает мой компьютер. А это значит, что я могу устанавливать на свой компьютер, как 32-битные, так и 64-битные системы Linux.
Если у вас после выполнения команды определилось 2ГБ и менее, то установить на свой компьютер вы можете только 32-битные системы.

Надеюсь теперь вы сможете правильно выбрать архитектуру ОС Linux для установки на вашем компьютере.

Существует несколько различных дистрибутивов Debian. И очень важно сделать правильный выбор. В этой главе приводится информация, полезная для тех пользователей, которые хотят выбрать дистрибутив, наиболее подходящий для своей системы, а также рассматриваются ответы на вопросы, которые могут возникнуть в этом случае. Здесь речь идёт не о том, «почему лучше выбрать Debian», а о том, «какой из дистрибутивов Debian больше вам подходит».

3.1. Какой дистрибутив Debian (стабильный/тестируемый/нестабильный) лучше всего мне подойдёт?

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

Если для вас очень важна безопасность или стабильность — устанавливайте стабильный. Точка. Это самый лучший вариант достичь желаемого.

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

If you are a desktop user with a lot of experience in the operating system and do not mind facing the odd bug now and then, or even full system breakage, use unstable. It has all the latest and greatest software, and bugs are usually fixed swiftly.

Если вы настраиваете сервер, особенно такой, требования к стабильности которого довольно серьёзны, или если он доступен из сети Интернет, то устанавливайте стабильный. Это, безусловно, самый правильный и безопасный выбор.

Надеемся, что ответы на дальнейшие вопросы больше прояснят ситуацию. Если после прочтения всех ЧаВо вам всё ещё трудно принять решение, остановитесь на стабильном дистрибутиве.

3.1.1. Вы предлагаете установить стабильный дистрибутив, но при его использовании не обнаруживается или не работает такое-то аппаратное обеспечение. Что делать?

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

Список работающих в Linux ноутбуков можно найти на этом замечательном сайте. Там не описывается работоспособность именно в Debian, но это потрясающий ресурс. Для настольных компьютеров такого сайта не найти.

3.1.2. Есть ли разница между версиями пакетов в различных дистрибутивах?

Да. В нестабильном дистрибутиве находятся самые новые (последние) версии. Но пакеты в нём недостаточно хорошо протестированы и могут содержать ошибки.

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

Пакеты в тестируемом дистрибутиве — что-то среднее между двумя этими крайностями.

3.1.3. В стабильных дистрибутивах содержатся устаревшие версии программ. Только взгляните на Kde, Gnome, Xorg или даже ядро. Они очень старые. Почему?

Да, в общем вы правы. Возраст пакетов в стабильном дистрибутиве зависит от времени выпуска. Так как обычно между выпусками проходит больше года, отсюда и получаются старые версии пакетов. Однако, они были хорошо протестированы на момент выпуска и работают даже сейчас. Можно уверенно сказать, что в пакетах нет неизвестных серьёзных ошибок, проблем с безопасностью и т. д. Пакеты в стабильном дистрибутиве очень тесно подогнаны друг к другу. Все перечисленные плюсы очень важны для рабочих серверов, которые функционируют 24 часа в день, 7 дней в неделю.

On the other hand, packages in testing or unstable can have hidden bugs, security holes etc. Moreover, some packages in testing and unstable might not be working as intended. Usually people working on a single desktop prefer having the latest and most modern set of packages. Unstable is the solution for this group of people.

Как видите, стабильность и новизна находятся на разных концах спектра. Если нужна стабильность, устанавливайте стабильный дистрибутив. Если хотите работать с самыми новыми версиями пакетов, ставьте нестабильный.

3.1.4. Возможно ли позже перейти на другой дистрибутив и как это сделать?

Да, но это односторонний процесс. Вы можете перейти со стабильного на тестируемый, а затем на нестабильный. Но обратно вернуться невозможно. Лучше дважды подумать, прежде чем устанавливать/переходить на нестабильный дистрибутив.

Actually, if you are an expert and if you are willing to spend some time and if you are real careful and if you know what you are doing, then it might be possible to go from unstable to testing and then to stable. The installer scripts are not designed to do that. So in the process, your configuration files might be lost and.

3.1.5. Не могли бы вы подсказать мне какой выпуск следует устанавливать, стабильный, тестируемый или нестабильный?

No. This is a rather subjective issue. There is no perfect answer as it depends on your software needs, your willingness to deal with possible breakage, and your experience in system administration. Here are some tips:

Стабильный выпуск стабилен как скала. Он не ломается и имеет полную поддержку безопасности. Но он может не работать на очень новом оборудовании.

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

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

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

3.1.6. Вы упомянули, что тестируемый дистрибутив иногда ломается. Что имеется в виду?

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

Когда такое случается, говорят, что дистрибутив сломан (по крайней мере, применительно к этому пакету).

3.1.7. Почему тестируемый выпуск может быть сломан в течение нескольких месяцев? Разве исправления, добавляемые в нестабильный выпуск, не переходят в тестируемый?

The bug fixes and improvements introduced in the unstable distribution trickle down to testing after a certain number of days. Let's say this threshold is 5 days. The packages in unstable go into testing only when there are no RC-bugs reported against them. If there is a RC-bug filed against a package in unstable, it will not go into testing after the 5 days.

The idea is that, if the package has any problems, it would be discovered by people using unstable and will be fixed before it enters testing. This keeps testing in a usable state for most of the time. Overall a brilliant concept, if you ask me. But things aren't always that simple. Consider the following situation:

Предположим, что вам нужен пакет XYZ.

Также представим, что на 10 июня его версия в тестируемом дистрибутиве XYZ-3.6, а в нестабильном XYZ-3.7.

After 5 days, XYZ-3.7 from unstable migrates into testing.

So on June 15, both testing and unstable have XYZ-3.7 in their repositories.

Пользователь тестируемого дистрибутива видит, что для пакета XYZ есть обновление, и он устанавливает его, переходя с XYZ-3.6 на XYZ-3.7.

Теперь, 25 июня кто-то использующий тестируемый или нестабильный дистрибутив обнаруживает RC-ошибку в XYZ-3.7 и пишет письмо об этом в BTS.

Сопровождающий XYZ исправляет эту ошибку и загружает исправленную версию в нестабильный дистрибутив, скажем, 30 июня. Здесь предполагается, что потребовалось 5 дней, чтобы сопровождающий исправил ошибку и закачал новую версию. Число 5 не следует воспринимать как постоянную величину. Оно может быть меньше или больше, в зависимости от сложности имеющейся RC-ошибки.

This new version in unstable, XYZ-3.8 is scheduled to enter testing on July 5th.

But on July 3rd some other person discovers another RC-bug in XYZ-3.8.

Предположим, что сопровождающий XYZ исправил эту новую RC-ошибку и закачал новую версию XYZ через 5 дней.

So on July 8th, testing has XYZ-3.7 while unstable has XYZ-3.9.

This new version XYZ-3.9 is now rescheduled to enter testing on July 13th.

Now since you are running testing, and since XYZ-3.7 is buggy, you could probably use XYZ only after July 13th. That is you essentially ended up with a broken XYZ for about one month.

The situation can get much more complicated, if say, XYZ depends on 4 other packages. This could in turn lead to an unusable testing distribution for months. While the scenario above is immaginary, similar things can occur in real life, though they are rare.

3.1.8. С точки зрения администратора, какой дистрибутив требует большего внимания?

One of the main reasons why many people choose Debian over other Linux distributions is that it requires very little administration. People want a system that just works. In general one can say that stable requires very little maintenance, while testing and unstable require constant maintenance from the administrator. If you are running stable, all you need to worry about is keeping track of security updates. If you are running either testing or unstable it is a good idea to be aware of the new bugs discovered in the installed packages, new bugfixes/features introduced etc.

3.1.9. Что происходит при выходе новой версии дистрибутива?

Этот вопрос не поможет вам в выборе дистрибутива Debian. Но рано или поздно он встанет перед вами.

The stable distribution is currently buster; The next stable distribution will be called bullseye. Let's consider the particular case of what happens when bullseye is released as the new stable version.

Старый стабильный (oldstable) = stretch; стабильный (stable) = buster; тестируемый (testing) = bullseye; нестабильный (unstable) = sid

Нестабильный всегда указывает на sid, независимо от того, вышла ли новая версия или нет.

Пакеты постоянно переносятся из sid в тестируемый (то есть в bullseye). А пакеты в стабильном (то есть в buster) не меняются (за исключением обновлений безопасности).

По прошествии какого-то времени тестируемый замораживают. Но он всё равно пока будет называться тестируемым. В этот период никакие новые пакеты из нестабильного дистрибутива в тестируемый перемещаться не могут, за исключением лишь тех, что содержат исправления ошибок, критических для выпуска (release-critical — RC).

When testing is frozen, all the new bugfixes introduced have to be manually checked by the members of the release team. This is done to ensure that there won't be any unknown severe problems in the frozen testing.

Количество критических ошибок в 'замороженном тестируемом выпуске' необходимо снизить до нуля, либо если их число больше нуля, то эти ошибки отмечаются как игнорируемые для этого выпуска или как отложенные до следующей редакции этого выпуска

The 'frozen testing' with no rc-bugs will be released as the new stable version. In our example, this new stable release will be called bullseye.

На этой стадии старый стабильный = buster, стабильный = bullseye. Содержимое стабильного и «замороженного тестируемого» в этот момент одинаково.

Новый тестируемый выпуск основывается на старом тестируемом выпуске.

Пакеты начинают поступать из sid в тестируемый, и сообщество Debian начинает работать над следующим стабильным выпуском.

3.1.10. У меня на настольном компьютере/кластере установлен Debian. Как узнать, какой дистрибутив используется?

В большинстве случаев это очень легко сделать. Посмотрите файл /etc/apt/sources.list . Там будет строка, подобная этой:

Третье поле («unstable» в вышеприведённом примере) указывает на отслеживаемый дистрибутив Debian, установленный в системе.

Также вы можете использовать команду lsb_release (из пакета lsb-release ). Если вы запустите эту программу на компьютере с нестабильной системой, то получите:

Однако, это не всегда так легко. В некоторых системах могут быть файлы sources.list с несколькими строками, указывающими на различные дистрибутивы. Так бывает, когда администратор следит за различными пакетами из различных дистрибутивов Debian. Это часто называется apt-pinning. На таких компьютерах может использоваться смесь дистрибутивов.

3.1.11. I am currently tracking stable. Can I change to testing or unstable? If so, how?

Если вы используете стабильный выпуск, то третье поле в файле /etc/apt/sources.list будет содержать 'buster' или 'stable'. Вам нужно изменить это значение на название того дистрибутива, который вы хотите использовать. Если вам нужен тестируемый дистрибутив, то замените значение третьего поля в /etc/apt/sources.list на 'testing'. Если нужен нестабильный выпуск, замените третье поле на 'unstable'.

Currently testing is called bullseye. So, if you change the third field of /etc/apt/sources.list to 'bullseye', then also you will be running testing. But even when bullseye becomes stable, you will still be tracking bullseye.

Нестабильный всегда называется Sid. Поэтому, если вы измените значение третьего поля в /etc/apt/sources.list на 'sid', то у вас будет отслеживаться нестабильный выпуск.

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

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

Тем не менее, после того как были произведены вышеуказанные изменения, вы можете запустить aptitude update и затем устанавливать нужные вам пакеты. Заметим, что установка пакетов от другого дистрибутива может привести к обновлению половины системы. Если вы устанавливаете отдельные пакеты, то получите систему, работающую на смеси дистрибутивов.

В некоторых ситуациях лучше выполнить полное обновление до нового дистрибутива, запустив apt full-upgrade , aptitude safe-upgrade или aptitude full-upgrade . Подробнее об этом можно узнать из справочных страниц по apt и aptitude.

3.1.12. Сейчас я использую тестируемый дистрибутив (bullseye). Что произойдёт после выпуска следующей версии? У меня по-прежнему будет отслеживаться тестируемый дистрибутив, или на моей машине будет новый стабильный дистрибутив?

Это зависит от записей в файле /etc/apt/sources.list . Если сейчас у вас отслеживается тестируемый дистрибутив, то там будут строки вида:

Если в третьем поле файла /etc/apt/sources.list стоит «testing», то даже после выхода нового выпуска у вас будет отслеживаться тестируемый дистрибутив. Поэтому после выхода bullseye вы будете работать на новом дистрибутиве Debian с другим кодовым именем. Сначала изменения будут незаметны, но они проявятся, как только новые пакеты начнут переходить из нестабильного дистрибутива в тестируемый.

Но если третье поле содержит «bullseye», то вы перейдёте на стабильный дистрибутив (так как bullseye станет новым стабильным дистрибутивом).

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