Translation(s): Dutch - English - Français - Italiano - Polish - Русский - Spanish - 简体中文

(!) ?Discussion


Вы можете спросить: «Почему Debian?». Debian это еще один дистрибутив GNU/Linux и еще одна Unix-подобная операционная система. Что делает его лучше остальных? Почему я должен использовать Linux везде? Отлично, этот документ описывает это:

http://people.debian.org/~srivasta/talks/why_debian/talk.html

Чтобы обеспечить доступность этого документа для всех, он сохранен здесь:

Почему Linux? Почему Debian?

Автор Manoj Srivastava (srivasta at debian.org)

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

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

Учитывая характер целевой аудитории для этого рассказа, я не буду тратить много времени на рассуждения почему кто-то должен выбрать UNIX-подобную ОС вместо операционной системы от Microsoft. Достаточно сказать, что от мне однозначно не хватало в Windows: безопасности, гибкости, контроля параметров. Меня не устраивали её философия, стоимость, скорость, эффективность, надежность, доступность и выбор приложений. В ней не было устойчивости к червям и вирусам, открытости, системы оперативного решения известных проблем, кластеризации, многопользовательской среды, графического интерфейса и HTTP-браузера, которые не являются частью ОС.

На http://www.michaelhorowitz.com/Linux.vs.Windows.html находится относительно беспристрастное сравнение Linux и Windows, которое может служить введением в Linux для пользователей Windows. Статья более подробно сравнивает экономические аспекты, чем данный рассказ (например, интересны истории успеха разных дистрибутивов и компаний, использующих Linux).

Философия и Общество

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

Я должен признаться, что эта философия и общество — то, что побудило меня перейти вначале в лагерь Linux, а затем в Debian. И я думаю, что они все еще являются наиболее важными критериями и часто недооцениваются.

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

Но я думаю, что здесь забыта главная причина существования свободного программного обеспечения — возможность «стоять на плечах гигантов». Я хотел бы привести аналогию с тем, как проводятся научные исследования. Если бы исследователи были обречены постоянно заново изобретать колесо и открывать для себя то, что не содержится в учебниках, то прогресс в научном обществе замедлился бы. Большинство моих коллег начинали свои исследования поиском в литературе, обзором интересных исследований и, возможно, поиску взаимосвязей между несвязанными документами, на основе идей и технологий других исследователей в это области. Засекречивание исследований в большинстве лабораторий существует только до момента публикации — и то люди делятся своими техниками, идеями и результатами — более того, воспроизводимость является основным критерием успеха.

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

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

Это убеждение заставило меня выбрать GPL и точку зрения Free Software Foundation вместо лицензии BSD, также являющейся лицензией свободного ПО, и в конечном итоге именно это привело к выбору Debian. По моему личному мнению, лицензия BSD в основном тешит личную гордость за написанно свободное ПО, без забот о том, что станет с этими программами в будущем. Я хочу больше, чем это. Хочу, чтобы мои труды помогли построить синергетическое сообщество, я хочу сам делать вклад в бьющий ключом источник полезных программ.

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

Сообщество — другая причина, по которой я пришел к Linux вместо BSD. В то время я оглядывался вокруг в поисках свободных UNIX-подобных ОС, чтобы поставить на выданный университетом новый 386, BSD были намного устойчивее, выглядели гораздо лучше и у меня были друзья, молившиеся на BSD. Меня оттолкнула кастовая система, которой было пропитано сообщество BSD. Там были основные разработчики на самой вершине, и вы где-то в самом низу со скромными новичками-помощниками. Сообщество Linux, несмотря на буйность, представляется намного более открытым — ваш возраст значит меньше, чем код, который вы создаёте. И я мог сразу вносить свою лепту в разработку ОС, которую буду запускать. Думаю, это еще одна причина, по которой мне нравится Debian — я в проекте достаточно долго, чтобы и самому направлять его, и чтобы Debian был устроен соответственно моему образу мысли.

Полезность и удобство

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

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

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

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

Я обнаружил, что машины с Debian при работе требуют меньше ручного вмешательства, легче в обновлении, и просто не ломаются так часто, как платформы с Red Hat или Mandrake, которые я обслуживаю. И мне говорили, что решения SunOS, к примеру, намного более «интересны».

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

Вы можете выбрать степень надёжности, которую хотите получить, так как в Debian есть три отдельные версии: стабильная (stable), тестируемая (testing) и нестабильная (unstable). На некоторых наших машинах (сервер, интернет-киоск) мы используем stable. На других машинах (индивидуальные рабочие станции) запущены различные комбинации testing и unstable. (Примечание: для testing отсутствуют обновления безопасности). Я запускаю некоторые вещи из версии experimental на моей личной рабочей станции. Особенно хороша возможность выбирать разные версии для разных программ. Это удобно, потому что разные машины выполняют разные функции. Но даже более рискованный выбор обычно достаточно надёжен, и практически всегда «работает». Ну а «stable» вообще никогда не ломается ;-).

Debian предоставляет много возможностей для связи с разработчиками. К примеру, проект XFree самостоятельно не поддерживает и не отлаживает X на всех архитектурах, поддерживаемых Debian — они в этом полагаются на Debian. Там же проектом Debian был сделан ряд глубоких исправлений в libc (там была ошибка с подсчётом количества ссылок, проявлявшаяся при вызове динамическом связывании совместно используемых объектов с определёнными ELF-зависимостями, которая была найдена разработчиками Debian). Любому другому дистрибутиву Linux сложно состязаться с Debian в таком внимании к деталям. Уровень знаний, скорость и дружелюбность помощи для конечных пользователей просто чрезвычайные — и, насколько я знаю, просто несопоставимо с качеством поддержки коммерческих компаний «старой школы», вроде DEC, если только вы не платите им действительно большие деньги. Эта особенность сообщества позволяет поддержать тех, кто не имеет ещё опыта с Debian, скажем, предприятия, которые решают его внедрить.

Для создания основанных на Debian систем DFSG и основной архив («main») упрощают построение систем с предсказуемым лицензированием.

Качество воплощения

Люди часто говорят, что они пришли к Debian из-за apt-get, или что apt — это «главная фишка» Debian. Но не apt-get делает использование Debian удобным. Apt-get — это особенность, которая без труда воспроизводится (и, по-моему, никогда в точности), другими дистрибутивами — вот некоторые аналоги: urpmi, apt4rpm, yum. Что действительно отличается, так это политика Debian и строгий регламент процесса проверки качества (QA, Quality Assuarance). Посмотрите на apt-listchanges, apt-list-bugs, dpkg-builddeps, pbuilder, pbuilder-uml — ни одна из этих вещей не может быть реализована без чёткой политики (представьте listchangelog без ясного формата changelog). Именно эта работа делает установку любого ПО в Debian действительно лёгкой.

Это напоминает религии культа карго: так же, как apt-get является видимым аспектом системы политик Debian, так и культ карго считает взлетные полосы и другие части источником западных благ («карго») и строит свои собственные копии, дополняя их поддельными деревянными наушниками для контрольных вышек. То есть остальные дистрибутивы воссоздали видимый аспект инфраструктуры пакетирования Debian, проигнорировав глубокие аспекты социальных и политических механизмов Debian. Хуже: часто возникает конфликт технических требований и маркетинговых или экономических, которые просто тянут проект в разные стороны. Для большинства дистрибутивов GNU/Linux этот конфликт технических и маркетинговых интересов не настолько извращает проект, как это бывает в собственническом ПО, но этот конфликт всё же явно присутствует.

В Red Hat, Mandrake и других дистрибутивах этого класса базовый объем установки по-настоящему огромен. Почему? Я думаю, это из-за боли в заднице при установке ПО. Даже с RPM это довольно кривая процедура, которую невозможно как-то привести в порядок. В Debian же установка программ — глоток свежего воздуха.

Таким образом, «главная фишка» на самом деле — это политика Debian, команда безопасности, механизм формального приоритета ошибок и политика ошибок (например, любая исполняемая программа без странички руководства man вызывает автоматический отчет об ошибке; любое взаимодействие с пользователем без использования стандартного средства debconf является ошибкой). На странице Wiki Why Debian Rocks (http://twiki.iwethey.org/Main/WhyDebianRocks) есть следующее:

This is the crux, the narthex, the throbbing heart of Debian and what makes it so utterly superior to all other operating systems. Policy is defined. It is clear. It is enforced through the tools you use every day. When you issue apt-get install foo, you're not just installing software. You're enforcing policy - and that policy's objective is to give you the best possible system.

What Policy defines are the bounds of Debian, not your own actions on the system. Policy states what parts of the system the package management system can change, and what it can't, how to handle configuration files, etc. By limiting the scope of the distribution in this way, it's possible for the system administrator to make modifications outside the area without fear that Debian packages will affect these changes. In essence, Policy introduces a new class of bugs, policy bugs. Policy bugs are release-critical -- a package which violates policy will not be included in the official stable Debian release.

Let me reiterate, because that is the whole secret: A package which violates policy will not be included in the official stable Debian release.

Это суть, нартекс, трепещущее сердце Debian и то, что делает это совершенно превосходит все остальные операционные системы. Политики определены. Это понятно. Это осуществляется через инструменты, используемые вами каждый день. Когда вы запускаете apt-get install foo, вы не просто устанавливаете ПО. Вы применяете политики, и эти политики состоят в том, чтобы дать вам лучшую систему из возможных.

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

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

Вдобавок, команда проверки качества (Debian QA) делает самостоятельные обновления пакетов (non maintainer uploads, NMUs), помогая в удалении ошибок, выполняя обновления безопасности и гарантирует, что есть кто-то, смотрящий на систему в целом и работающий над созданием интегрированной ОС, а не просто правящий отдельные изолированные пакеты. Это то, что позволяет людям избрать Debian и положиться на него. Есть очень много средств в подсистеме QA для помощи разработчикам в заботе об их пакетах — просто взгляните на http://qa.debian.org/developer.php?login=srivasta

Каждый пакет подвергается оценке в нестабильной ветке перед тем, как попадет в тестируемую, что добавляет качества конечному продукту. Как только пакет не проявил важных проблем в течение некоторого периода времени, он переносится в тестируемую ветку. Эта версия становится кандидатом для будущего стабильного дистрибутива, который будет выпущен только когда все критические ошибки будут устранены. Из-за такого тщательного многоуровневого тестирования у Debian более длинный период между выпусками стабильных версий по сравнению с другими дистрибутивами. Однако в терминах надёжности — это преимущество. (Примечание: по видимому, у RH Enterprise Linux цикл выпусков колеблется между 12 и 24 месяцами. Ближе к тому, что было в истории Debian.)

Тот факт, что Debian поддерживает столько архитектур, сколько он поддерживает, также влияет на качество пакетов: перенос программного обеспечения часто раскрывает изъяны в основном коде. Добавим к фактам, что всё программное обеспечение в Debian проходит через 10 или около того демонов автоматической сборки и необходимо, чтобы оно было свободно от ошибок, чтобы могло собраться в различных окружениях. Необходимо, чтобы скрипты сборки и установки были хорошо отлажены, а зависимости для сборки строго отслеживались. Добавим зеркала архивов исходников и слежение за версиями — и у вас довольно устойчивая система (есть snapshot.debian.org для простых откатов).

Ключ к качеству дистрибутива — система отcлеживания ошибок Debian. Так как выпуски связаны с количеством критических ошибок в системе, это обеспечивает качество выпуска лучше, чем у любого, запускавшегося мной, собственнического UNIX. Менеджер выпуска абсолютно безжалостен и выбрасывает любые не необходимые пакеты с ошибками, блокирующими выпуск, если они не исправляются, или откладывает выпуск, если это необходимый пакет с ошибкой.

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

По словам недавней истории на Slashdot, сейчас больше дистрибутивов, основанных на Debian, чем на рыночном лидере, ?RedHat (63 и больше, включая Ubuntu, Xandros, Knoppix, Lycoris, Lindows (Lind--s?), Libranet, mophix ...).

Восстановление после сбоев в Debian лучше всех (см. http://www.linuxworld.com/story/32607.htm). Также гляньте скрипт (http://linuxmafia.com/faq/Debian/package-database-rebuild.html), восстанавливающий систему без бекапа /var/lib/dpkg.

Набор признаков и выбор программ

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

Debian имеет огромное достижение в интернационализации, переводится не только документация (у меня есть люди,которые отправляют мне перевод справочных страниц для пакетов, которые я поддерживаю), но также конфигурационные и установочные скрипты (все взаимодействие с debconf вполне может быть переведено). Это помогает иметь массивное, географически распределенное, сообщество. Я думаю достижение интернационализации в Debian соответствует Gnome и KDE.

Other notables, for which I have too little time to pay proper attention to, are: The Debian documentation project, Alioth, Debian installer, Debian CD, Lintian, and the package tracking system.

Some other things which will keep me using Debian until they're supported by something else:

  1. debconf and the ability to pre-seed the database
  2. make-kpkg with all the install-time prompts turned off
  3. /usr/share/doc/{Changelog.Debian,changelog,copyright,README.Debian}

Debian also has a great set of tools for kernel or distribution hackers and systems integrators debbootstrap, chroots, user mode Linux, Xen. All kinds of neat tools to help hack on installation mechanisms, kernels and drivers.

There are a number of niche communities that have found a home with Debian. These are sub projects; Debian-Jr, Debian-med, Debian-Edu, Debian-non-profit, and Debian-lex. A number of Debian developers are blind, and as a result, Debian is very very friendly to the blind. There is additional material on Custom Debian distributions (http://people.debian.org/~tille/debian-med/talks/paper-cdd/debian-cdd.html/)

Kernels

The BSD kernels, from all accounts, seem to be stabler, and of better quality than Linux kernels seem to be. BSD kernels are much easier to read and understand. On the flip side, Linux kernels more feature rich, and the quality has improved significantly, seem to perform much better, and better hardware support than the BSD kernels do. Indeed, I've heard comments that when it comes to driver support, the BSD's are where Linux was 5 years ago. I'll talk more about hardware support below. Personally, the supposed added bugginess of the Linux kernels have not exceeded my threshold of acceptability. And, overall, I don't think that a Debian box feels any less robust and stable than, say, a FreeBSD box. Of course, the recent spate of holes in Linux kernels are beginning to strain that. (However, we should keep in mind that having more features is a contributory factor: the two latest holes were in the mremap(2) call that is not available for any of the *BSD.)

Of course, Debian Gnu/FreeBSD may provide the best of both worlds.

User Land

The BSD user land is different from the GNU user land. I have grown up with the GNU user land installed on Ultrix/Aix/HP-UX boxes for consistency, and for me the GNU userland feels far more comfortable.

It should be noted that you can install the GNU userland on a BSD box, and a number of people do so (/usr/local/gnu/*, for example). Of the installations that do have both sets of utilities installed, the reports are that the user-base overwhelmingly uses the GNU utilities, even though that's not the default. In general, the FreeBSD utilities appear to be lighter weight but feature poor, and on modern hardware the small amount of memory savings just doesn't matter.

It also doesn't help that they don't provide good command line help; it's much easier to tell a newbie that if they type foo --help they will get something that might be useful.

OpenBSD's base userland is quite complete. I prefer the GNU userland because I am used to it, but OBSD's base system is quite workable. FBSD is quite a different story - In FBSD they strive to produce a minimal base system, and they don't expect people to only use that - they expect people to install many ports. FreeBSD becomes the most Debian-like system in the BSD family - you have a base system and you build on top of that. Its userland is whatever you choose it to be.

Maintenance and administration

Upgrades have been said to be the killer advantage for Debian. More than most other OS's, the network is the distribution and upgrade mechanism for Debian. Policy, the thought that has gone into the maintainer scripts, and the ways in which they can be called, the full topographical sorting over the dependency web done by apt and friends, all work together to ensure that upgrades in place work smoothly (I've never had to reinstall my machines, though some have been upgraded in place for over 5 years). Reinstalls are not unheard of in an recommended BSD upgrade path (Since 2.8 or 2.9, OpenBSD said at least two times to i386 users "upgrade not supported / not recommended, do a fresh install").

This ease of upgrades also plays into security of the system; security upgrades are far more convenient on Debian than they are on other systems, thanks to the Security team. For us mere mortals not on vendor-sec, having security.debian.org in our sources list ensure that our boxes get updated conveniently, and quickly, after any exploit is made public -- since the security team was already working on a fix before the details went public. This means that systems get updated in minutes, whereas the recommended way to do an upgrade on a BSD OS involves recompiling the entire system (at least, the "world").

Debian attempts to ensure smooth upgrades skipping a major release - which is not something that I have seen supported elsewhere. I keep coming back to quality of packaging

Administering Debian is the primary reason most people stay with it. I know no other distribution where you can type in apt-get install sendmail, and walk away with a fully functional mail server, complete with SASL and TLS, fully configured, complete with certificates. All administration can be done over SSH given only dial-up speeds.

The Debian guarantee that user changes to configuration files shall be preserved, and that all configuration files shall live in /etc (as opposed to being all over the file system) makes for easier backups (I have my /etc living under version control).

Debian is compliant with the FHS, and LSB compliance is a release goal.

The distributed nature of Debian development and distribution makes it really easy to set up a separate repository of custom packages that can then be distributed in house; and the policy and build mechanisms ensure that third parties can build the system just as easily in a reproducible fashion.

Portability and Hardware Support

Linux tends to support more of the esoteric hardware than BSD does. whether that is a problem, depends on your needs. Support for the high quality hardware is mostly the same. A notable exception is for RAID hardware; the 3ware RAID cards are just becoming supported in BSD, but have had Linux support for a while. IBM's assurance of Linux support on all their hardware, and that of HP, is also an advantage for Linux. I also like the multiple journaling file systems that have come into the Linux kernel recently. For desktop, the killer factor is drivers. And Linux leaves all the other X86 Unixes behind by a mile.

When it comes to portability, NetBSD is supposed to be the byword. However, I went and had a good, hard look at what is supported by NetBSD, and Debian: I found that Debian supports ibm s/390 and ia64, while NetBSD has support for sun2 (m68010), PC532 (whatever that is [apparently a custom machine of which only 200 models were ever made]), and VAX. I am sure which set I am more interested in (though it might be cool to have a VAX puttering around in the basement). Note that what NetBSD call architectures are often labeled sub-architectures by Debian, and thus do not count in the 11 supported architecture count.

Source Builds

I have heard a lot of things about the ports mechanism of BSD, and the portage systems of gentoo. I have also heard about how people have problems actually getting things to compile in the ports system. Apart from the fact that compiling everything rapidly gets old (I have been there, done that, when I used Soft Landing Systems (SLS) distribution back in '93).

It is not as if you can't do a port like auto build of Debian -- we have auto-builders on 11 architectures that do that, continuously, every single day -- the question is why would one want to? I have yet to see a single, replicable test demonstrating any palpable performance improvement by local, tailored optimized compilations -- and certainly none that justifies, in my eyes, the time spent tweaking and building the software all over.

Someone said that when they were younger and felt like playing a prank they would adjust some meaningless parameters on someone's computer and tell them "this will make it run about 5% faster, but you probably won't notice it". With such a challenge they usually responded by becoming totally convinced that their machines had been improved considerably and that they could feel the 5% difference!

Conventional wisdom seems to indicate overall system performance increases are less than 1%. Specific programs can benefit greatly, though, and you can always tweak a critical app for your environment in Debian. I think whatever time is saved by running an optimized system is more than compensated for by the time spent building the system, and building upgrades of the system (I've heard of people running doing their daily update in the background while doing other things in the foreground.)

Not to mention how integration suffers by not having a central location where interoperability of the pieces can be ever tested well, since every system would differ wildly from the reference.

A source build system is also far more problematic when it comes to major upgrades -- I have anecdotal evidence of it not being as safe and sane as the Debian upgrade mechanisms.

Anyway, if I do want to build packages from source on Debian, I can use apt-get source -b, apt-src, or any of a number of tools. And when doing local builds I do trust that locally built deb's will be installed in a safe and sane way, replacing properly the old stuff. The build depends pull in any required dependencies for builds, and I routinely build in pbuilder-user-mode-linux to ensure uniform builds.

The real point here is that Gentoo is a distro for hobbyists and übergeeks / hard-core linux users, who can spare the time building their apps. I know Gentoo also provides pre compiled binaries -- but does that not defeat their supposed advantage? For an enterprise environment where down time does cost money this is simply inadmissible and Debian provides the best solution. Those of use which administer more than a handful machines can really appreciate how convenient it is to be able to issue apt-get update && apt-get upgrade at once instead of having to go downloading, configuring, compiling and installing software machine per machine, without any sort of automated help ( I am not completely doing justice to emerge / portage here, but the point is clear, I hope ). I can emphasize this enough: for "serious"/production usage, binary distros are the best and only viable solution; Amongst them, Debian ( not only because of APT but also because of all the hard work done by DD to ensure correctness of the packaging ) is the best [I have tried SuSE, ?RedHat and Mandrake, and I wouldn't go back even if offered lots of money; Gentoo is not an option either]

Security and Reliability

There is always a trade off between security and convenience -- the ultimately secure computer is one that is never turned on. Secure, but not very useful. You have to decide where your comfort zone lies.

What does one think of when one says Security and Unix like OS? OpenBSD, with some justification. It is audited and has the small size, small system requirements AND the pure text based install. If you stick to the core install, you get an audited system, with no services turned on by default and an assurance that there are no holes in the default install that can lead to a remote root compromise. However, you tend to end up with old software, and the default install really does very little. W^X and protection against stack overflows (?ProPolice) on OpenBSD http://www.openbsd.org/33.html, and exec-shield and Adamantix (PaX) patches for Linux (you may have to recompile your kernel on Debian for these). Most people agree that the secure and audited portion of OpenBSD does not provide all the software they require. Also, OpenBSD's performance numbers are, umm, poor, compared to SELinux on a 2.6.3 kernel.

OpenBSD's secure reputation is justified - but only when you know the project, when you are familiar with what does it really cover. OpenBSD may be a great firewall, maybe even mail or static Web server - As long as you keep out of the ports tree, you do have an audited, security-conscious system. I know few applications, however, for such a system. The OpenBSD userland ports break more often than stable Debian -- but, in OpenBSD, ports are officially not part of the system, and should a security problem appear in one of them, you are on your own.

Arguably, Debian stable equals or beats the exact claims -- and there appears to be little real world difference between Debian and openbsd at this time. One has to work a bit to harden the default Debian install with just Standard priority packages, but this is just a few minutes work for experienced admins. Code audits are in a more advanced stage for OpenBSD; though one must bear in mind that despite all the audits there have been high profile bugs in OpenSSH recently -- so take the audited label with a pinch of salt.

The Debian GNU/Linux distribution has a strong focus on security and stability. We have an Security team, automated build systems to help the security team quickly build versions across all the architectures that are supported, and policy geared towards those goals. Here is more on a security oriented comparison (http://lists.debian.org/debian-user/2003/debian-user-200308/msg00541.html) of OpenBSD and Debian.

Even though you don't quite need a tool chain on every target BSD system to roll out security updates ("make release", or "make package" to build on one machine and install elsewhere), it is quite a bit more inconvenient than the Debian packaging system. Debian handles binary package distribution much better. One can have his own aptable archive and feed all productive servers from is, using Debian's native mechanisms.

When it comes to real security, however, without mandatory access controls you have very little assurance. So SELinux (and the still nascent TrustedBSD) would be far better choices than OpenBSD or base Debian Stable.

Even without SELinux, I find the rock solid stability of Debian stable, with the peace of mind that comes from back ported security fixes provided by the Security team, very persuasive. It is easy for an untrained recipient to keep up to date with security; and reduces the likelihood of compromise. This is very important in a commercial environment with a large number of computers, where is it important that the software NOT be upgraded every few months.

There is another benefit of the Debian's Security team when it comes to the stable distribution. There is, however, only one version of the ports tree. Whereas in Debian, you have multiple versions of, e.g., apache, KDE, and X11 -one for every suite with security updates for the stable suite- there is no such thing on FreeBSD. Although, of course, the port makefile will be updated if a vulnerability has been found in a given package, the only way to plug the hole on your system in such a situation is to install the new version of the package, with all possible problems that may cause. Compare to Debian, where you have the ability to install the same version of the software, with the security fix back-ported. Also, if you're working with a ports-installed version of the vulnerable package, you'll stay vulnerable for as long as the compilation runs, which may or may not be a considerable amount of time.

I have some data comparing Linux distributions and the time to patch known security vulnerabilities, no data of BSDs, however. It's available at http://people.debian.org/~jfs/debconf3/security/data/.

Scalability and Performance

I was not initially going to talk at all about performance and numbers, since these have mattered little to me personally, and performance numbers change from release to release. However, I realize that these are important decision criteria for some people, and I have attempted to look up a recent look at the numbers.

The full set of benchmarks, complete with code, is available here. http://bulk.fefe.de/scalability/ Here are his words, from the conclusion section, updated to reflect the latest benchmarks.

Linux 2.6 scales O(1) in all benchmarks. Words fail me on how impressive this is. If you are using Linux 2.4 right now, switch to Linux 2.6 now!

NetBSD has better scalability than FreeBSD.

FreeBSD 5.1 has very impressive performance and scalability. (Note that it is as yet unreleased) I foolishly assumed all BSDs to play in the same league performance-wise, because they all share a lot of code and can incorporate each other's code freely. I was wrong. FreeBSD has the second best performance of the BSDs and it even comes close to Linux 2.6.

Linux 2.4 is not too bad, but it scales badly for mmap and fork.

OpenBSD 3.4 performed really poorly in these tests. The disk performance sucks, the kernel was unstable, and in the network scalability department it was even outperformed by it's father, NetBSD. OpenBSD also gets points deducted for the sabotage they did to their IPv6 stack. If you are using OpenBSD, you should move away now.

Conclusion

There is no other OS or distribution that I know of which has just this mix of properties (ease of maintenance, affordability, stability, size, customizability, strong support). For the most part, I do not want to tinker with and Debug my workstation, I want to get my job done, easily, safely, and with minimal concern about the infrastructure I use. Debian helps me accomplish that.

And that's still the primary reason I use it today, from a technical standpoint. Software installation and upgrade. The packages are top-notch, they as a rule install and upgrade perfectly. Software maintenance is still a really large part of any sysadmin's job, and with Debian it's simply trivial. It's a non-issue. Don't even bring it up when talking about any problems with Debian, it's not worth the effort. Borderline flawless.

Acknowledgement

  1. Wouter Verhelst <wouter@grep.be>

  2. José Luis Tallón <jltallon@adv-solutions.net>

  3. Andrew Suffield <asuffield@debian.org>

  4. Javier Fernández-Sanguino Peña <jfs@computer.org>

  5. Russell Coker <russell@coker.com.au>

  6. Andreas Metzler <ametzler@downhill.at.eu.org>

  7. Steve <sgbirch@imsmail.org>

  8. Toni Mueller <toni@debian.org>

  9. Marc Haber <mh+debian-devel@zugschlus.de>

  1. George Danchev <danchev@spnet.net>

  2. Lionel Elie Mamane <lionel@mamane.lu>

  3. Greg Folkert <greg@gregfolkert.net>

  4. Rudy Godoy <rudy@kernel-panik.org>

  5. Andreas Tille <tillea@rki.de>

  6. Nathanael Nerode <neroden@twcny.rr.com>

  7. Mark Ferlatte <ferlatte@cryptio.net>

  8. Gunnar Wolf <gwolf@gwolf.cx>

  9. Jim ?McCloskey <mcclosk@ucsc.edu>

  10. Bill Wohler <wohler@newt.com>

  11. Bill Richardson <bill@bothan.net>

  12. Alex Perry <alex.perry@qm.com>

  13. Woodrow Kirton <wkirton@surfwayx.net>

  14. David B Harris <dbharris@eelf.ddts.net>

  15. Joost van Baal <joostvb@mdcc.cx>

  16. Bill Allombert <allomber@math.u-bordeaux.fr>

  17. <root.man@earthlink.net>

  18. Viktor Rosenfeld <rosenfel@informatik.hu-berlin.de>

  19. "Adrian 'Dagurashibanipal' von Bidder <avbidder@fortytwo.ch>

  20. Razvan Petrescu <rpetrescu@montran.ro>

  21. s. keeling <keeling@spots.ab.ca>

  22. Karsten M. Self <kmself@ix.netcom.com>

Thanks also to the participants in the thread (http://lists.debian.org//debian-devel/2004/02/thrd2.html#00594) on the developers mailing list for their input.

Other Resources