Проект FreeBSD намерен сменить GCC на LLVM+Clang

> Раз Linux - не Windows, а FreeBSD - не Linux, значит FreeBSD - Unix

Раз Unix-FreeBSD, FreeBSD не Linux, а Linux не Windows.
значит Unix - Windows.
Поздравляю тебя шарик ты -осел

> А еще?

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

> Кстати, где-то был скрипт, который выкачивает и собирает qmail автоматом на линухах.

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

> Ну это поделие как раз для извращенцев. О нём написал Федорчук:http://alv.me> > /?p=413

О Федорчука с его неприкрытым и ничем неаргументированным фанатизмом можете не продолжать. Человек знающих только одну систему - FreeBSD не может ее корректно сравнивать с теми системами в которых он толком не разбирается. Его перлами - полрунета и пол-bash.org а забито

проект Debian GNU/kFreeBSD еще слишком молодой на мой взгляд что бы его сравнивать на равных. На сайте debian вам обещают только "The base system is fully functional". Я так понимаю релиза как такового не было - это только эксперементальная ветка.

Все притензии Федорчука сводятся к: * отсутвии выбора ZFS в инталляторе - у вас поголовно все BSD-образные дистрибутивы поддерживают выбор ZFS на этапе инсталляции? По моему нет. К тому же чудеса "sysinstall" он и во фряхе может чудеса вытворять. Далеко не самый идеальный инструмент на мой взгляд, впрочем некоторых устраивает из за того что выбора то особого у freebsd шников нет - поэтому надо срочно начинать от него фанатеть - по любому. * Поддержка оборудования - то же самое.

Вобщем он ожидал там увидеть нечто уже готовое к практическому применению. Очень забавный путь у него я смотрю - сидеть и смотреть что за манна небесная упадет с неба. Если бы так поступали все остальные в мире кроме Microsoft ничего бы не было вообще.

> Поздравляю тебя шарик ты -осел

С логикой серьёзные траблы, эрго: Поздравляю тебя, Шарик, ты - осел

>>если уж придётся пользоваться BSD, то скорее всего это будут Debain GNU/kFreeBSD

>Ну это поделие как раз для извращенцев. О нём написал Федорчук:http://alv.me/?p=413

Федорчук - бздун и знатный тролль. От него редко можно услышать что-нибудь хоть сколь-нибудь объективное. Основное направление его мыслей в любом сравнении можно выразить такой сентенцией: "Во FreeBSD этого нет. И этого нет. И вот этого конечно тоже нет, тут вы тоже правы. Однако если подумать, а так ли оно нужно?"

>>или NetBSD.

>Сферический конь вакуума для экспериментатствующих физиков. DragonFly — из той же серии, правда, для математиков.

Да ты ведь её даже в глаза не видел. Ъ-SMP теперь не в Linux или FreeBSD, а в NetBSD. К версии 6.0 она станет труднодостижимым идеалом как для Linux, так и для FreeBSD - сейчас там осталось переписать на новую SMP-модель драйверы. Благодаря большому количеству поддерживаемых архитектур у неё удивительно чистый код и очень крохотное ядро.

Девиз Linux и FreeBSD: "Мне некогда точить пилу, мне надо пилить." Плодят новые костыли на-гора. А вот NetBSD точить пилу время есть и результаты заточки пилы в последнее время сильно радуют. Я довольно внимательно присматриваюсь к этой системе.

DragonFly BSD пока что находится на стадии исследовательского проекта. Там до сих пор ещё очень много работы, но очень мало разработчиков. Её перспективы крайне мутные, но уж во всяком случае она более походит на промышленную ОС, нежели лабораторный хомячок Minix 3.

>> Я не смог юмом поставить ... qmail

>г-н троль - у вас с головой плохо - кумыл через юм поставить нельзя если только сам для себя репо не держишь. см. лицензию на QMAIL.

Насколько я знаю, Бернштайн передал Qmail в Public Domain. Теперь его вроде можно найти в двоичных пакетах с уже наложенной горой патчей, необходимых для полноценной работы. Только, ИМХО, поздно уже. Большинство пользуется Postfix, некоторые - Exim.

> Ъ-SMP теперь не в Linux или FreeBSD, а в NetBSD

И что там такого Ъ-вого?

>> Ъ-SMP теперь не в Linux или FreeBSD, а в NetBSD

>И что там такого Ъ-вого?

Ъ-ое там то, что работа идёт планомерно, выполняется практически одним человеком (Эндрю Дораном), работающим на full-time и пронизывает всю систему насквозь. Вместо большой блокировки ядра, последовательно реализуются мелкозернистые блокировки на уровне различных подсистем. Под новую SMP-модель переписываются ВСЕ драйверы, а не так как в Linux или FreeBSD - часть драйверов продолжают пользоваться общей блокировкой, часть блокирует только соответствующие подсистемы.

К 6.0 вся эта работа будет завершена. Вот здесь: http://www.netbsd.org/~ad/smp/tasks.html можно наблюдать прогресс. К 6.0 также ожидается порт ZFS. Если сейчас эта система может быть не особо привлекательно, то к моменту выхода 6.0 на неё как минимум следует посмотреть очень пристально.

Возможно и FreeBSD к 8.0 тоже окончательно избавится от GIANT-LOCK, но FreeBSD, на мой взгляд, идёт немного не в том направлении. Использование LLVM+Clang будет Ъ в понимании BSD, но для меня лично это - лишнее звено, не дающее никаких преимуществ. Мне не нравится ещё и то, что в погоне за количеством портов, уделяется мало внимания их качеству.

Судьба Solaris неопределена, да и не нравится он мне. В первую очередь опять-таки из-за оригинальной пакетной системы и системы инициализации на XML-файлах.

Так что В ПЕРСПЕКТИВЕ мне интересны пока только Debian GNU/kFreeBSD и NetBSD.

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

И что? Во-первых, это общеизвестный подход, во-вторых, в Linux это было сделано к 2.4.

> Под новую SMP-модель переписываются ВСЕ драйверы, а не так как в Linux или FreeBSD - часть драйверов продолжают пользоваться общей блокировкой, часть блокирует только соответствующие подсистемы.

В Linux старая система блокировки (с lock_kernel()) осталась только в подсистеме tty. И ведется работа по устранению lock_kernel() и оттуда.

> К 6.0 вся эта работа будет завершена.

К тому времени и в Linux она будет завершена.

Так что непонятно, что такого особо Ъ-вого в общеизвестных подходах, давно реализованных в Linux. Я бы еще понял, если бы Ъ-SMP приписали DragonFlyBSD - там действительно делается что-то новое. Но никак не NetBSD?

>И что? Во-первых, это общеизвестный подход, во-вторых, в Linux это было сделано к 2.4.

Не всё так гладко, как кажется. Почитайте новость годичной давности: http://www.linux.org.ru/view-message.jsp?msgid=2744340 Что характерно - о завершении работ пока ни слуху ни духу.

>В Linux старая система блокировки (с lock_kernel()) осталась только в подсистеме tty. И ведется работа по устранению lock_kernel() и оттуда.

Во FreeBSD это уже сделано.

>К тому времени и в Linux она будет завершена.

С нетерпением ждём.

>Так что непонятно, что такого особо Ъ-вого в общеизвестных подходах, давно реализованных в Linux.

Реализованных, но почему-то до сих пор не доведённых до конца. В NetBSD один человек сделает это один раз, а потом к этому вопросу возвращаться уже не придётся.

>Я бы еще понял, если бы Ъ-SMP приписали DragonFlyBSD - там действительно делается что-то новое. Но никак не NetBSD?

Ну я не говорил, что Ъ - значит что-то принципиально новое. Здесь Ъ означает, что за дело взялись по-настоящему серьёзно. Если честно, пару лет назад считал эту систему окончательным R.I.P., но вот уж очень активно зашевелилась.

В DragonFly BSD действительно реализуется принципиально новый подход к SMP, но со скоростью черепахи - интерес затухает. Она интересна больше, чем Minix 3, но они обе являются скорее исследовательскими проектами, а не "промышленным" мэйнстримом.

>>В Linux старая система блокировки (с lock_kernel()) осталась только в подсистеме tty. И ведется работа по устранению lock_kernel() и оттуда.

> Во FreeBSD это уже сделано.

Но ты почему-то не назвал ее Ъ. Не потому ли, что понимаешь - блокировка ядра в некоторых драйверах (вернее, ее отсуствие) на Ъ-вость не влияет просто никак.

>>К тому времени и в Linux она будет завершена.

> С нетерпением ждём.

И практическая цель этого - ... ? У тебя куча программ, которые интенсивно открывают/закрывают tty (ЕМНИП, lock_kernel() остался только в open и ioctl этих устройств)?

Впрочем, это будет раньше выхода NetBSD 6.0

>>Так что непонятно, что такого особо Ъ-вого в общеизвестных подходах, давно реализованных в Linux.

> Реализованных, но почему-то до сих пор не доведённых до конца.

Не "почему-то", а потому что это никому особо не надо. Почему в NetBSD вытеснение на уровне ядра не было до 5.0? Потому что особо не надо было.

> Здесь Ъ означает, что за дело взялись по-настоящему серьёзно.

Тогда единственный Ъ-SMP - в Linux. Масштабирование на 1024 проца - вот где серьезно.

>Мне не нравится ещё и то, что в погоне за количеством портов, уделяется мало внимания их качеству.

Я так и не услышал конкретные примеры "некачественности" портов. Но были приведены какие-то умозрительные предложения на тему сборки и сопровождения ПО aka "слоты Gentoo".

Что конкретно не устраивает портах?

Они собираются? Собираются.
Они работают? Работают.
Из них можно собрать пакеты и перенести на другую машину для установки и/или апгрейда? Можно, если не запрещает политика.

Так в чём проблемы-то? Ещё раз, для тупых. По пунктам. Можно?

> был скрипт, который выкачивает и собирает qmail
у меня был SRPM, лежал на public FTP - как выяснилось, DJB не имел ничего против SRPM.

>Что конкретно не устраивает портах?

>Они собираются? Собираются.

Не всегда.

>Они работают? Работают.

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

>Из них можно собрать пакеты и перенести на другую машину для установки и/или апгрейда? Можно, если не запрещает политика.

Можно. Только для этого приходится пользоваться извращением с chroot.

Короче - порты элементарно не удобны. На телеге с лошадью тоже можно возить грузы, но возят почему-то на автомобилях.

>> Во FreeBSD это уже сделано.

>Но ты почему-то не назвал ее Ъ. Не потому ли, что понимаешь - блокировка ядра в некоторых драйверах (вернее, ее отсуствие) на Ъ-вость не влияет просто никак.

В FreeBSD не пока не переработаны сетевые драйверы.

>И практическая цель этого - ... ? У тебя куча программ, которые интенсивно открывают/закрывают tty (ЕМНИП, lock_kernel() остался только в open и ioctl этих устройств)?

Не понял. Судя по прошлогодней новости, на которую я привёл ссылку, в ядре существует более 1300 устройств, использующих большую блокировку. По-твоему это драйверы терминала?

>Не "почему-то", а потому что это никому особо не надо. Почему в NetBSD вытеснение на уровне ядра не было до 5.0? Потому что особо не надо было.

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

>Тогда единственный Ъ-SMP - в Linux. Масштабирование на 1024 проца - вот где серьезно.

В NetBSD 6.0 обещают поддержку до 256 процессоров из коробки, без перекомпиляции ядра. Нужно больше - можно будет перекомпилировать под необходимое число.

Я пользуюсь Linux и хорошо осознаю, что других подходящих для меня альтернатив в настоящее время не существует. Мне просто не нравятся некоторые вещи в Linux-ядре. В частности - стек Bluetooth с привязкой к D-BUS, плохая или отсутствующая документация на некоторые специфичные вещи, подход к разработке некоторых подсистем, не имея плана. Я приглядываюсь к другим системам и меня заинтересовала NetBSD - там нет подобных проблем, хотя есть много других.

> Судя по прошлогодней новости, на которую я привёл ссылку, в ядре существует более 1300 устройств, использующих большую блокировку.

Не устройств, а codepaths. То есть 1300 вызовов. "The most mind-numbing part is literally all the ioctl crud", L.B.Torvalds. > По-твоему это драйверы терминала?

Подсистема tty - самый большой пользователь, IIRC.

>>Не "почему-то", а потому что это никому особо не надо. Почему в NetBSD вытеснение на уровне ядра не было до 5.0? Потому что особо не надо было.

>Надо было, надо. Они давно осознавали проблему, только это очень большая работа.

Сделанная в не-Ъ Linux несколько лет назад.

>>Тогда единственный Ъ-SMP - в Linux. Масштабирование на 1024 проца - вот где серьезно.

> В NetBSD 6.0 обещают поддержку до 256 процессоров из коробки,

Это лукавство. Суметь запуститься на 256 процессорах - это одно, а эффективно масштабироваться - совсем другое. При всем уважении к NetBSD, это слишком маргинальный проект, чтобы получить тот уровень тестирования, который есть у Linux.

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

Смешно говорить, но пакеты не привязаны к версии системы. Система поддерживает сквозную бинарную совместимость — опциии ядра GENERIC:
options COMPAT_FREEBSD4 # Compatible with FreeBSD4
options COMPAT_FREEBSD5 # Compatible with FreeBSD5
options COMPAT_FREEBSD6 # Compatible with FreeBSD6

>При вынужленном переползании с одной версии софта на другую бывает нужно что-то исправить, чтобы оно заработало.

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

>Сильно не хватает стабильной ветки портов и пакетов с долгоиграющей поддержкой.

Порты имеют "долгоиграющую" поддержку. Какие не имеют/заброшены/ — вы вольны написать мантейнерам таких заброшенных портов и предложить им свои услуги по портированию новых версий ПО и новых патчей.

>Можно. Только для этого приходится пользоваться извращением с chroot.

В пределах одной архитектуры гораздо проще
1) Собрать бинарные пакеты на эталонной машинке:
% portupgrade -afp
2) Смонтировать носитель с каталогом бинарных пакетов на другой машине и произвести установку:
% pkg_add -r /mnt/ports/packages/All/somepackage-version.tbz
или апгрейд:
% env PKG_PATH=/mnt/ports/packages/All portupgrade -aiPP

>Смешно говорить, но пакеты не привязаны к версии системы. Система поддерживает сквозную бинарную совместимость — опциии ядра GENERIC:
>options COMPAT_FREEBSD4 # Compatible with FreeBSD4
>options COMPAT_FREEBSD5 # Compatible with FreeBSD5
>options COMPAT_FREEBSD6 # Compatible with FreeBSD6

А система FreeBSD6 имеет сквозную бинарную совместимость с пакетами от FreeBSD 7? То-то же.

>>При вынужленном переползании с одной версии софта на другую бывает нужно что-то исправить, чтобы оно заработало.

>Что исправить? Правьте патчи в каталоге порта, пересобирайте порт, создавайте из порта бинарный пакет для распространения в узком кругу. Это разве сложно?

Правьте сами. Это не сложно, но зачем этим заниматься, если есть системы повёрнутые к человеку более приличным местом?

>>Сильно не хватает стабильной ветки портов и пакетов с долгоиграющей поддержкой.

>Порты имеют "долгоиграющую" поддержку. Какие не имеют/заброшены/ — вы вольны написать мантейнерам таких заброшенных портов и предложить им свои услуги по портированию новых версий ПО и новых патчей.

Дорогой мой человек, я правильно Вас понимаю, что я волен что-то сделать для FreeBSD или забить и воспользоваться той системой, где я волен ничего не делать?

>>Можно. Только для этого приходится пользоваться извращением с chroot.

>В пределах одной архитектуры гораздо проще
>1) Собрать бинарные пакеты на эталонной машинке:
>% portupgrade -afp

Мне бывают нужны пакеты под разные версии систем и разные архитектуры. Под каждую систему эталонных машинок не напасёшься. Сборка бинарных пакетов не происходит ли точно так же, как с make package - то есть с установкой порта в систему перед созданием пакета?

>2) Смонтировать носитель с каталогом бинарных пакетов на другой >машине и произвести установку:
>% pkg_add -r /mnt/ports/packages/All/somepackage-version.tbz
>или апгрейд:
>% env PKG_PATH=/mnt/ports/packages/All portupgrade -aiPP

А ещё я волен поставить на одной машинке apt-cacher, на всех остальных прописать эту машинку в качестве ближайшего зеркала и обновлять все машинки единообразно, не заморачиваясь "эталонными машинками", сборками пакетов с помощью portupgrade -afp, версиями систем и их архитектурами, монтированием каталогов по NFS.

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

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

>Подсистема tty - самый большой пользователь, IIRC.

А ещё, все PPP-соединения в Linux не существуют отдельно от TTY. Значит для PPP-соединений использовать ядро Linux кагбе не кошерно?

>Сделанная в не-Ъ Linux несколько лет назад.

Я не понимаю что Вы хотите мне доказать? Да, Linux - Ъ, в нём SMP появилось раньше. Однако мне не нравится, что однажды начатая работа не доведена до конца. В моём понимании - это не Ъ. В общем я так понимаю, что весь спор возник только из-за разного понимания понятия Ъ.

>Это лукавство. Суметь запуститься на 256 процессорах - это одно, а эффективно масштабироваться - совсем другое. При всем уважении к NetBSD, это слишком маргинальный проект, чтобы получить тот уровень тестирования, который есть у Linux.

Ознакомьтесь с тестами: http://www.netbsd.org/~ad/50/img11.html, http://www.netbsd.org/~ad/50/img13.html, http://www.netbsd.org/~ad/50/img15.html Ещё в 6.0 планируют организовать поддержку NUMA-архитектур - думаю эффективность масштабирования будет неплохой. Количество тестеров этой системы, конечно, мало, но ведь и сама система разрабатывается не эволюционным Linux-способом: её разрабатывают не под влиянием текущих насущных потребностей, городя костыли. Поживём - увидим.

В общем, хватит меня убеждать в том, что Linux - наше всё. Когда в треде было заявлено о том, что во FreeBSD SMP более Ъ, нежели чем в Linux, я лишь хотел обратить внимание на NetBSD, где в области SMP прогресс идёт семимильными шагами, а работа будет доведена до конца.

Я стал уважать NetBSD (вкупе с правильным подходом к разработке pkgsrc) сильнее, чем FreeBSD (с её портами) - это всё, что я хотел сказать.

Давайте перестанем спорить ни о чём? =)

>А система FreeBSD6 имеет сквозную бинарную совместимость с пакетами от FreeBSD 7? То-то же.

Может и имеет.

>Правьте сами. Это не сложно, но зачем этим заниматься, если есть системы повёрнутые к человеку более приличным местом?

Случайно не ошибусь, место это называется Synaptic/apt-get?
И в каком же репозитории мне искать, к примеру, gcc-4.4.1_20090512, gcc-4.5.0_20090507, cups-base-1.3.10?
Их нигде в Linux'ах нет, а что есть, собрано красноглазыми гиками и пока только "экспериментальное". Для вас.
Это всё уже есть среди портов FreeBSD, собирается и работает.

>Мне бывают нужны пакеты под разные версии систем и разные архитектуры. Под каждую систему эталонных машинок не напасёшься.

Скажу по секрету: роль эталонной машины может занять одна и рабочих.

>Сборка бинарных пакетов не происходит ли точно так же, как с make package - то есть с установкой порта в систему перед созданием пакета?

Почти. Утилита portupgrade собирает пакеты в зависимостях, если и они тоже требуют обновлений.

>не заморачиваясь "эталонными машинками", сборками пакетов с помощью portupgrade -afp, версиями систем и их архитектурами, монтированием каталогов по NFS.

Вот уже "заморочки" с монтированием NFS-шар. Как-будто, apt-cacher завести в тыщу раз проще. :))

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

Задроты это те, кто разводит бурную деятельность с apt-cacher вместо автоматического монтирования NFS-шар.

>И мне абсолютно не нравится, что из-за лени сотен мэнтейнеров, миллионы пользователей FreeBSD вынуждены орудовать напильником на пустом месте.

"Напильников" в релизах FreeBSD давно уже нет. Просыпайтесь из анабиоза.

>> Подсистема tty - самый большой пользователь, IIRC.

> А ещё, все PPP-соединения в Linux не существуют отдельно от TTY. Значит для PPP-соединений использовать ядро Linux кагбе не кошерно?

Ну если говорить об идеальном SMP - наверное, нет. А если учесть, что BKL остался только в вещах типа open/ioctl, то кошернее не найдешь.

> Ознакомьтесь с тестами: http://www.netbsd.org/~ad/50/img11.html, http://www.netbsd.org/~ad/50/img13.html, http://www.netbsd.org/~ad/50/img15.html

Там 8 ядер, не 256.

> Я не понимаю что Вы хотите мне доказать? Да, Linux - Ъ, в нём SMP появилось раньше.

Судя по фразе "Ъ-SMP теперь не в Linux или FreeBSD, а в NetBSD", в NetBSD есть нечто такое, чего в Линуксе нет совсем вообще. Вот я и пытаюсь понять - что же это. Прихожу к выводу, что Linux попал в эту фразу случайно.

>>А система FreeBSD6 имеет сквозную бинарную совместимость с пакетами от FreeBSD 7? То-то же.

>Может и имеет.

Не имеет. Нельзя заранее сделать совместимость с тем, чего ещё нет.

>>Правьте сами. Это не сложно, но зачем этим заниматься, если есть системы повёрнутые к человеку более приличным местом?

>Случайно не ошибусь, место это называется Synaptic/apt-get?

Это место называется правильный подход к разработке. Конкретные пакетные менеджеры тут побоку, хотя я и считаю dpkg/apt весьма неплохими.

>И в каком же репозитории мне искать, к примеру, gcc-4.4.1_20090512, gcc-4.5.0_20090507, cups-base-1.3.10?

Вам циферки или ехать? Если программа позволяет мне успешно решать мои задачи и каши не просит, я буду продолжать ею пользоваться. Лучшее - враг хорошего.

>Их нигде в Linux'ах нет, а что есть, собрано красноглазыми гиками и пока только "экспериментальное". Для вас. Это всё уже есть среди портов FreeBSD, собирается и работает.

Экспериментальное оно и во FreeBSD, или вы думаете что во FreeBSD тот же самый софт чудесным образом вдруг становится стабильным и отлаженным? Во FreeBSD нет стабильной ветки для портов, благодаря чему, выражаясь по-дебиановски, вы сидите на вечно немного поломанном Sid'е и не можете выбрать более доведённые до ума testing или stable.

>>Мне бывают нужны пакеты под разные версии систем и разные архитектуры. Под каждую систему эталонных машинок не напасёшься.

>Скажу по секрету: роль эталонной машины может занять одна и рабочих.

Лучше если её нет вообще. Нет машины - нет проблемы.

>Утилита portupgrade собирает пакеты в зависимостях, если и они тоже требуют обновлений.

Ну так перед тем как выдать собранный пакет, он устанавливается в систему или нет? Если устанавливается - мне это не нужно.

>Вот уже "заморочки" с монтированием NFS-шар. Как-будто, apt-cacher завести в тыщу раз проще. :))

Настройка NFS займёт несколько минут, но нужно будет наполнять шару самостоятельно. И заниматься этим придётся постоянно.

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

ИМХО, аналог apt-cacher'а был бы полезен и во FreeBSD для кэширования двоичных пакетов и дистфайлов.

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

>Задроты это те, кто разводит бурную деятельность с apt-cacher вместо автоматического монтирования NFS-шар.

Задроты - это те, кто вручную наполняет NFS-шары самосборными пакетами под несколько архитектур и версий.

>"Напильников" в релизах FreeBSD давно уже нет. Просыпайтесь из анабиоза.

Они есть в портах.

>Ну если говорить об идеальном SMP - наверное, нет. А если учесть, что BKL остался только в вещах типа open/ioctl, то кошернее не найдешь.

Если Linux будет в этом плане продолжать стоять на месте, то его скоро догонят и перегонят.

>Там 8 ядер, не 256.

Я и не говорил, что их там 256. Поддержка 256 ядер и NUMA из коробки планируется к 6.0.

>Судя по фразе "Ъ-SMP теперь не в Linux или FreeBSD, а в NetBSD", в NetBSD есть нечто такое, чего в Линуксе нет совсем вообще. Вот я и пытаюсь понять - что же это. Прихожу к выводу, что Linux попал в эту фразу случайно.

Ну всё-таки не совсем случайно: Linux'у в плане SMP есть к чему стремиться.

> Я и не говорил, что их там 256. Поддержка 256 ядер и NUMA из коробки >планируется к 6.0. >Ну всё-таки не совсем случайно: Linux'у в плане SMP есть к чему стремиться.

Обьявление. Срочно куплю 256 ядерный процессор. Нужен для отладки и разработки SMP (c) Торвальдс. Звоните!

>Обьявление. Срочно куплю 256 ядерный процессор. Нужен для отладки и разработки SMP (c) Торвальдс. Звоните!

Дурачок. Есть специализированные микропроцессоры с ещё большим количеством ядер, kilo-core - это лишь самое известное название.

Кроме того, ядро - это логически самостоятельный микропроцессор. Находятся ли 256 ядер на одном кристалле в одном корпусе или на 16-64 кристаллах/корпусах - для операционной системы абсолютно не важно. Она оперирует логическими микропроцессорами - ядрами.

>Как это "примерные"?
>Одна в libc, другая в apt.

По значимости. И ту и другую надо закрывать "вчера". Что утечка кусков памяти в .db, что кривая проверка подлинности - одного поля ягоды.

>Не имеет. Нельзя заранее сделать совместимость с тем, чего ещё нет.

А вы попробуйте и удивитесь.

>Вам циферки или ехать? Если программа позволяет мне успешно решать мои задачи и каши не просит, я буду продолжать ею пользоваться. Лучшее - враг хорошего.

Мне — ехать с красивыми циферками, осознавая то, что в крайних минорных версиях правятся баги ВСЕХ предыдущих версий, делая продукт более стабильным и эффективным (а иначе минорный номер в версиях лишён всякого смысла).

>Экспериментальное оно и во FreeBSD, или вы думаете что во FreeBSD тот же самый софт чудесным образом вдруг становится стабильным и отлаженным?

Неверно.

В коллекции портов несколько версий того же gcc, firefox, linux-flashplugin с своевременными обновлениями минорных версий — есть из чего выбрать и спрогнозировать риски. А вот "полусистемное" ПО (оболочки, DE, языковые движки Perl и Python) тестируются весьма тщательно, прежде чем окончательно и бесповоротно заменить устаревшие версии.

>Ну так перед тем как выдать собранный пакет, он устанавливается в систему или нет? Если устанавливается - мне это не нужно.

Сказали же: устанавливается. В то окружение, какое выбрано — общесистемное или chroot'овое.
Как вы себе представляете сборку бинарного пакета Eclipse, если она требует установки и запуска Java SDK для собственной сборки?

>Настройка NFS займёт несколько минут,

У меня настройка NFS-доступа занимает от силы три минуты, да ещё прописывание разрешённых портов в файерволе — минуту с небольшим.

>но нужно будет наполнять шару самостоятельно. И заниматься этим придётся постоянно.

Вот уж бредятина.
Вам делать нечего? Так трудно расшарить каталог $PACKAGES и больше не вспоминать об этом?

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

Прекрасно (но почему не apt-proxy?) Скажите мне, требует ли он Apache Server для своей работы и, если да, то зачем?

>ИМХО, аналог apt-cacher'а был бы полезен и во FreeBSD для кэширования двоичных пакетов и дистфайлов.

Кому трафика жалко — да.
Альтернативы: синхронные каталоги /usr/ports/ на всех машинах, либо единый репозиторий-зеркало бинарных пакетов с удалённым доступом от всех машин в локальной сети.

>Задроты - это те, кто вручную наполняет NFS-шары самосборными пакетами под несколько архитектур и версий.

Угу. И они тоже.

Я предпочитаю сделать один раз шару $PORTSDIR, прописать автомонтирование, команду "portupgrade --use-packages-only --batch" в крон и забыть об этом.

>По значимости. И ту и другую надо закрывать "вчера". Что утечка кусков памяти в .db, что кривая проверка подлинности - одного поля ягоды.

Странно, у меня под вопросом только это:
% portaudit -F
auditfile.tbz 100% of 55 kB 2860 Bps 00m00s
% portaudit
Affected package: thunderbird-2.0.0.21_1
Type of problem: mozilla -- multiple vulnerabilities.
Reference: <http://www.FreeBSD.org/ports/portaudit/3b18e237-2f15-11de-9672-0030843d3802.html>

1 problem(s) in your installed packages found.

You are advised to update or deinstall the affected package(s) immediately.
%

Кстати, сегодня обновился порт gcc45 до версии 4.5.0_20090514.
Формулировка к обновлению: "Update to the 20090514 snapshot of GCC 4.5.0.

Extract SUFFIX from PORTVERSION.  Use SUFFIX for TARGLIB (and thus for
the library path used by this port).  Also use SUFFIX for the libexec
directory instead of the full port version and flatten the directory
structure and simplify the logic along the way.

Tinder-tested by:       itetcu@"

>>Не имеет. Нельзя заранее сделать совместимость с тем, чего ещё нет.

>А вы попробуйте и удивитесь.

Пробовал. Удивился. mpd из FreeBSD 6.x не работал в FreeBSD 5.x, пока его не пересоберёшь из портов.

>В коллекции портов несколько версий того же gcc, firefox, linux-flashplugin с своевременными обновлениями минорных версий — есть из чего выбрать и спрогнозировать риски.

Пожалуйста, в репозиториях Debian есть несколько версий тех же gcc, firefox - можно выбирать из stable, testing, unstable или experimental. Причём даже в одном и том же репозитории бывает несколько версий одного и того же ПО. В чём разница?

>>А вот "полусистемное" ПО (оболочки, DE, языковые движки Perl и Python) тестируются весьма тщательно, прежде чем окончательно и бесповоротно заменить устаревшие версии.

Тут вот один товарищ говорил у него во FreeBSD при обновлении из портов X.org поломался. Он пока ручками не поправил - не заработало. А если бы это было автоматическое обновление на 50-200 машин? Достаточно ли хорошо тестируется всё необходимое?

>Как вы себе представляете сборку бинарного пакета Eclipse, если она требует установки и запуска Java SDK для собственной сборки?

Но сам-то Eclipse для этого зачем ставить?

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

>У меня настройка NFS-доступа занимает от силы три минуты, да ещё прописывание разрешённых портов в файерволе — минуту с небольшим.

Поздравляю - очень нужный навык.

>>но нужно будет наполнять шару самостоятельно. И заниматься этим придётся постоянно.

>Вот уж бредятина.
>Вам делать нечего? Так трудно расшарить каталог $PACKAGES и больше не вспоминать об этом?

Простите, а откуда этот каталог вдруг взялся? В случае apt-cacher есть внешние зеркала, которые просто существуют и поддерживаются их хозяевами, не требуя с моей стороны никаких усилий. Там есть ВСЕ пакеты, даже те, которые мне не нужны.

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

>Прекрасно (но почему не apt-proxy?) Скажите мне, требует ли он Apache Server для своей работы и, если да, то зачем?

apt-proxy мне не понравился - слишком дутый функционал. apt-cacher - самое то, Apache не требует - умеет работать как автономный специализированный веб-сервер, даже сам обновляет страничку со статистикой кэша.

>>ИМХО, аналог apt-cacher'а был бы полезен и во FreeBSD для кэширования двоичных пакетов и дистфайлов.

>Кому трафика жалко — да.

Допустим трафика не жалко - используется безлимит. НО! Безлимит ограничен по скорости - а значит будет постоянно грузить канал, а обновления будут приходить с некоторым опозданием.

Кому ничего не жалко, тот раскошелится и на билд-сервер для сборки портов и на UPS, и на место в стойке, и на отдельный канал, и на электроэнергию, и на оплату времени админа, уходящего на поддержание билд-сервера, и на систему кондиционирования. Но! Есть ваше субъективное понятие "жалко/нежалко", а есть понятие экономической эффективности и целесообразности.

>Альтернативы: синхронные каталоги /usr/ports/ на всех машинах, либо единый репозиторий-зеркало бинарных пакетов с удалённым доступом от всех машин в локальной сети.

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

>>Задроты - это те, кто вручную наполняет NFS-шары самосборными пакетами под несколько архитектур и версий.

>Угу. И они тоже.

>Я предпочитаю сделать один раз шару $PORTSDIR, прописать автомонтирование, команду "portupgrade --use-packages-only --batch" в крон и забыть об этом.

Ладно, принято. Только опять же - пакеты для старых версий FreeBSD периодически пропадают с официальных зеркал.

>Пробовал. Удивился. mpd из FreeBSD 6.x не работал в FreeBSD 5.x, пока его не пересоберёшь из портов.

Правильно. Потому что последняя версия MPD 5.3 использует подсистему NetGraph, опционально узел NG_CAR (Commited Access Rate netgraph node type). И когда вы указываете в опциях сборки MPD использовать этот модуль, то на FreeBSD 7.x ничего дополнительно собирать не нужно, так как модуль ng_car.ko есть в системе, а на FreeBSD 6.x и 5.x как зависимость к MPD будет собран порт ports/net/ng_car.
Чтобы исключить (ненужную) зависимость и освободить MPD 5.3 от версии операционки, нужно правильно отметить/оставить пункт опций сборки NG_CAR "Use ng_car kernel module from port (< 7.0 only)".

Число портов, так или иначе зависимых от версии FreeBSD:
> grep "OSVERSION" -r /usr/ports/ | grep Makefile | wc -l
695
ВСЕГО_ТО!

>Причём даже в одном и том же репозитории бывает несколько версий одного и того же ПО. В чём разница?

Так я о том же! Если всё есть, то о чём говорить? Но в случае популярных дистрибутивов Linux всё же не хватает скорости портирования на них новых версий/веток программ. Похоже, только Arch Linux в этом преуспел больше всех, но у него и идеология разработки и продвижения как у FreeBSD.

>>расшарить каталог $PACKAGES
>Простите, а откуда этот каталог вдруг взялся?

Вот откуда:
man portupgrade
...
ENVIRONMENT
...
PORTSDIR Alternative location for the ports tree. Default is
``/usr/ports''.
...
PACKAGES Base directory where portupgrade creates packages.
Default is ``$PORTSDIR/packages''.

>В случае apt-cacher есть внешние зеркала, которые просто существуют и поддерживаются их хозяевами, не требуя с моей стороны никаких усилий. Там есть ВСЕ пакеты, даже те, которые мне не нужны.

А в случае portupgrade -ap появятся только те пакеты, которые реально нужны для работы.

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

Что мешает сопровождать не общее хранилище, а отдельные хранилища пакетов для разных архитектур? Архитектур-то всего две: [i386] и [amd64] (просто сомневаюсь, что в вашем распоряжении окажется ещё [sparc] и [mips], выделенные под FreeBSD).

>Только опять же - пакеты для старых версий FreeBSD периодически пропадают с официальных зеркал.

Спрашиваете что делать? Windows 2000 тоже уже не поддерживается, Windows XP до окончания поддержки осталось совсем ничего.
Как везде: смотреть на версии поддерживаемых операционных систем и решать своевременно проблемы аппаратного апгрейда, а затем и программного; приобретать новые знания и навыки.

>Странно, у меня под вопросом только это:
>% portaudit -F
[skiped]

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

P.S.: "Вобщем, все вокруг педерасты, один я д'Артеньян" - достаточно безпроигрышная с точки зрения ее занявшего. Только опасная очень с точки зрения психического здоровья - заиграться можно.

>Правильно. Потому что последняя версия MPD 5.3 использует подсистему NetGraph, опционально узел NG_CAR (Commited Access Rate netgraph node type). И когда вы указываете в опциях сборки MPD использовать этот модуль, то на FreeBSD 7.x ничего дополнительно собирать не нужно, так как модуль ng_car.ko есть в системе, а на FreeBSD 6.x и 5.x как зависимость к MPD будет собран порт ports/net/ng_car.
Чтобы исключить (ненужную) зависимость и освободить MPD 5.3 от версии операционки, нужно правильно отметить/оставить пункт опций сборки NG_CAR "Use ng_car kernel module from port (< 7.0 only)".

>Число портов, так или иначе зависимых от версии FreeBSD:
> grep "OSVERSION" -r /usr/ports/ | grep Makefile | wc -l
>695
>ВСЕГО_ТО!

Смысл всей этой сентенции для меня сводится к следующему: если я не хочу обновлять базовую систему с 5.x до 6.x, то двоичных пакетов для 5.x я не найду. Пакеты из 6.x на 5.x заработают не всегда и мне придётся их пересобирать из портов. Стабильной ветки портов не существует, поэтому для установки ещё одной программы мне скорее всего придётся обновить часть других программ (поскольку требования к версиям программ-зависимостей постоянно растут). Далее - ещё не факт, что удастся собрать, поскольку поддержку моей базовой системы уже могли выкинуть к текущему времени, а если собрать удалось - не факт что заработает. Если же я имел неосторожность тупо обновить свою систему, не сделав бэкапы предыдущих версий пакетов, мне таки придётся заняться обновлением уже базовой системы. Или, чтобы избежать всего этого, придётся заморачиваться с построением пакетов в chroot'е или на отдельной машинке.

Извините - я лучше для самого древнего Debian найду необходимые пакеты в архиве и поставлю, а при желании (когда я буду готов заняться исправлением глюков вызванных переходом на новые версии ПО) обновлю систему, изменив одну строчку в /etc/apt/sources.list, затем обновлю всю систему двумя командами.

>Причём даже в одном и том же репозитории бывает несколько версий одного и того же ПО. В чём разница?

>Так я о том же! Если всё есть, то о чём говорить?

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

>Но в случае популярных дистрибутивов Linux всё же не хватает скорости портирования на них новых версий/веток программ. Похоже, только Arch Linux в этом преуспел больше всех, но у него и идеология разработки и продвижения как у FreeBSD.

Эта идеология мне не нравится. Я не гонюсь за новыми версиями программ, поэтому скорости портирования мне хватает.

>>В случае apt-cacher есть внешние зеркала, которые просто существуют и поддерживаются их хозяевами, не требуя с моей стороны никаких усилий. Там есть ВСЕ пакеты, даже те, которые мне не нужны.

>А в случае portupgrade -ap появятся только те пакеты, которые реально нужны для работы.

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

Мне вот ещё что интересно. Ведь portupgrade придётся запускать на каждой машине и каждая машина будет иметь право записи в этот каталог, каждой машине нужен будет доступ к внешнему зеркалу. А пакеты в FreeBSD, насколько я знаю, не имеют цифровых подписей. Стало быть взломав одну машинку можно будет подменить в этом каталоге пакет, добавив туда трояна, а все остальные машины радостно воспользуются этим пакетом. В случае apt-cacher'а для подмены пакета нужно будет взломать или внешнее зеркало или машинку с apt-cacher'ом, но даже проделав это, подписать подменённый пакет не удастся - для этого нужно обладать приватным pgp-ключом.

>Что мешает сопровождать не общее хранилище, а отдельные хранилища пакетов для разных архитектур?

Мешают всё те же экономические соображения. Зачем создавать дополнительную инфраструктуру, если можно обойтись без неё?

>Архитектур-то всего две: [i386] и [amd64]

Йа сломалсо =D

>(просто сомневаюсь, что в вашем распоряжении окажется ещё [sparc] и [mips], выделенные под FreeBSD).

Бывают ещё железки с ARM. И уж точно я не стану ставить на них FreeBSD - ещё не хватало мне заниматься компиляцией из портов на процессоре ARM или городить кросскомпиляцию.

>Спрашиваете что делать? Windows 2000 тоже уже не поддерживается, Windows XP до окончания поддержки осталось совсем ничего.
Как везде: смотреть на версии поддерживаемых операционных систем и решать своевременно проблемы аппаратного апгрейда, а затем и программного; приобретать новые знания и навыки.

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

Аппаратный апгрейд не требуется до тех пор, пока аппаратура справляется со своими задачами: работает без сбоев и справляется с нагрузкой. То же и с программным апгрейдом - сам по себе, в отрыве от приносимых им преиумществ, он не нужен. Другое дело если в программе закрыли дырку, исправили глюк, добавили новую возможность, которой не хватало конкретно _тебе_ - тогда да.

А вот если я попрошу назвать с ходу пару новых преимуществ тех программ, которые вы недавно обновили, то вы без чейнжлогов и ответить-то ничего не сможете. Вы будете невнятно мямлить: "стало ещё лучше... быстрее... исправлены глюки..." Что лучше? Что быстрее? Какие глюки - вы их видели?

Я вот при переходе с Etch на Lenny заметил совсем немного: в Amarok пропали обложки тех музыкальных альбомов, которые я удалил из фонотеки; перестал падать KNetwalk при завершении игры; Transmission перестал быть монолитным пакетом и теперь можно ставить отдельно демон, отдельно графическую морду к нему. Всё. Это развитие? Это то, из-за чего нужно постоянно обновлять систему? Я уже даже не говорю про серверы. В большинстве случаев там вообще всё как работало, так и после апгрейда продолжает работать - иногда только конфиги поправить бывает нужно. Зачем в таком случае вообще нужны обновления, если их не замечаешь?

>Смысл всей этой сентенции для меня сводится к следующему: если я не хочу обновлять базовую систему с 5.x до 6.x, то двоичных пакетов для 5.x я не найду.

В общем, да. Ветка 5.x уже не поддерживается официально, но бинарные пакеты для 5.x можно найти и/или собрать самостоятельно на 6.x — проверка работоспособности их на неподдерживаемой системе в ваших интересах.

>Извините - я лучше для самого древнего Debian найду необходимые пакеты в архиве и поставлю, а при желании (когда я буду готов заняться исправлением глюков вызванных переходом на новые версии ПО) обновлю систему, изменив одну строчку в /etc/apt/sources.list, затем обновлю всю систему двумя командами.

А я обновлю систему из исходников (если позволит время) с древней 5.x на 6.x (там несколько стадий перехода), а затем с 6.x до 7.x и получу современную работающую систему с тем ПО, которое было установлено ещё в 5.x. Но это так, экзерцисы — винчестеры столько не живут, да и старьё пятилетней давности уже становится откровенно затратно по деньгам с точки зрения показателя производительность-энергопотребление. :))

>Мешают всё те же экономические соображения. Зачем создавать дополнительную инфраструктуру, если можно обойтись без неё?

Зачем исользовать apt-cacher, если это — потенциальная дыра в безопасности?

>>Как везде: смотреть на версии поддерживаемых операционных систем и решать своевременно проблемы аппаратного апгрейда, а затем и программного; приобретать новые знания и навыки.
>То есть вы хотите, чтобы я стоически преодолевал трудности, создаваемые маркетинговой политикой различных корпораций и поддался психологии потреблядства? Да вы для них просто дойная корова с салом вместо мозга.

Я прагматик. :)

>Аппаратный апгрейд не требуется до тех пор, пока аппаратура справляется со своими задачами... Другое дело если в программе закрыли дырку, исправили глюк, добавили новую возможность, которой не хватало конкретно _тебе_ - тогда да.

Вот поэтому я не вижу смысла держать на серваках устаревшие и неподдерживаемые операционные системы. А вы всё ещё ищите какую-то совместимость между бинарными пакетами для 6.x и неподдерживаемой FreeBSD 5.x. Я не удивлюсь, что у вас где-то работают серверы на ядре Linux 2.4.x или 2.2.x. Что ж — бог в помощь.

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

portaudit говорит об этом.

>Вы будете невнятно мямлить: "стало ещё лучше... быстрее... исправлены глюки..." Что лучше? Что быстрее? Какие глюки - вы их видели?

Действительно, стало лучше (говорю о десктопе): стала заметнее скорость реакции интерфейса DE на действия пользователя (полгода-год назад была заметна большая латентность). Файловый кэш улучшен до того, что повторный запуск любой большой программы, как то: Firefox 3.0.10, Eclipse 3.4.1, OpenOffice3 (с отключенным "быстрым стартом") происходит мгновенно!

>Я вот при переходе с Etch на Lenny заметил совсем немного... Это развитие? Это то, из-за чего нужно постоянно обновлять систему?

Ну если вы не видите разницы между ПО и системой (в Linux так оно и есть), то да, обновления для Linux не важны.
С FreeBSD переход с ветки 6.x на 7.x весьма революционен как с точки зрения управления ресурсами железа, так и с точки зрения поддержки новых программно-аппаратных средств (драйверы и системное ПО). FreeBSD идёт на десктопы, где будут работать тысячи программ переднего плана, а значит проводится работа по улучшению интерактивности системы.

>Я уже даже не говорю про серверы. В большинстве случаев там вообще всё как работало, так и после апгрейда продолжает работать - иногда только конфиги поправить бывает нужно. Зачем в таком случае вообще нужны обновления, если их не замечаешь?

Обновления нужны для: 1) исправления выявленных уязвимостей и 2) улучшения эффективности работы программ. Без тестов старых и новых конфигураций невозможно почувствовать улучшения. Если не верите чейнджлогам и своим глазам, тогда пишите свои тесты, проделывайте ту же работу, что уже сделали разработчики, чтобы улучшить систему. :))

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

Что это даёт?

Непрерывные обновления (чаще — минорных) версий ПО, которые происходят в коллекции портов, даёт серию эволюционных изменений и более плавный переход с устаревших версий на последние версии без авралов и технических/временных сложностей с переустановкой всего и вся "разом", чтобы они нормально работали. Как это бывает в Ubuntu и Windows: без переформатирования винчестера переход с версии на версию в этих системах сопряжён с головной болью и болью в сердце от безысходности при обнаружении трудноидентифицируемых глюков, поэтому для них выбирают стратегию: "ничего не трогать", если всё работает, а если что-то сломалось и вызывает явное раздражение своей неисправимостью (рубикон сложности, ага) — всё под снос и ставить с "чистого листа".

Так вот, непрерывные обновления FreeBSD способствуют эволюционному развитию инфраструктуры без существенных затрат на время простоя и профилактического обслуживания.

Вижу обновления порта ports/lang/gcc43: gcc43 4.3.4_20090517
С формулировкой:
"Update to the 20090517 snapshot of GCC 4.3.4.

Extract SUFFIX from PORTVERSION. Use SUFFIX for TARGLIB (and thus for
the library path used by this port). Also use SUFFIX for the libexec
directory instead of the full port version and flatten the directory
structure and simplify the logic along the way.

Adjust Makefile header; nothing really left from the original."

Оперативненько...
Это базовый компилятор для новых программ.

>Ветка 5.x уже не поддерживается официально, но бинарные пакеты для 5.x можно найти и/или собрать самостоятельно на 6.x — проверка работоспособности их на неподдерживаемой системе в ваших интересах.

Debian Sarge тоже уже не поддерживается официально, но искать пакеты для неё не прдётся - они есть в официальном архиве, а проверять их работоспособность тоже не требуется. Единственное, что я теряю в случае использования Sarge - это латание дыр. В большинстве случаев я обновляю систему ТОЛЬКО ради того, чтобы в ней не было незакрытых известных дыр.

>А я обновлю систему из исходников (если позволит время) с древней 5.x на 6.x (там несколько стадий перехода)

Несколько - это сильно. Debian обновляется парой команд, в один этап. И только если обновилось ядро, придётся перезагрузить один раз систему. Всё.

>винчестеры столько не живут, да и старьё пятилетней давности

Не знаю где вы покупали свои винчестеры, одному из моих винчестеров объёмом 4,3 гигабайта уже больше 7 лет и он до сих пор работает. Использую его для экспериментов с операционками, когда нужно гарантированно сохранить рабочую систему и без лишнего геморроя вернуться к её использованию. Отключаю остальные винты - ставлю ОС на этот винт, после установки могу подключить остальные винты или вернуть всё как оно было.

>уже становится откровенно затратно по деньгам с точки зрения показателя производительность-энергопотребление. :))

Ну работал комп, загрузка не превышала 10%, энергопотребление - 150 ватт. И тут вы поменяли железо, загрузка стала возле 1%, а энергопотребление стало 200 ватт. Ведь не секрет, что вычислительной мощи, при грамотном её использовании, стало достаточно для комфортной работы уже очень давно.

С тех пор только порочный круг новых программ и нового оборудования заставляет периодически менять и то и другое. Купил железку - а оказалось в прежней операционке для неё драйверов нет. Что делать? Ставить более новую операционку. Поставил новую операционку, а у неё требования к памяти и процессору выше. Что делать? Покупать новую железку. И так без конца, работай за железки всю жизнь. Не железки для человека, а человек для железок.

>Зачем исользовать apt-cacher, если это — потенциальная дыра в безопасности?

Простенький специализированный веб-прокси-сервер, доступный только с конкретных локальных адресов - это дыра? Ну взломают его и что дальше? Пакеты подменят? Так ведь пакеты подписаны PGP-ключом - ни один из компьютеров-клиентов ставить неподписанные пакеты не станет.

>>То есть вы хотите, чтобы я стоически преодолевал трудности, создаваемые маркетинговой политикой различных корпораций и поддался психологии потреблядства? Да вы для них просто дойная корова с салом вместо мозга.

>Я прагматик :)

В чём прагматизм? Отдать кому-то деньги за ненужную (о сути) вам вещь?

>Аппаратный апгрейд не требуется до тех пор, пока аппаратура справляется со своими задачами... Другое дело если в программе закрыли дырку, исправили глюк, добавили новую возможность, которой не хватало конкретно _тебе_ - тогда да.

>Вот поэтому я не вижу смысла держать на серваках устаревшие и неподдерживаемые операционные системы.

В Debian под поддержкой имеется в виду прежде всего латание дыр. Оставаясь на том же железе в функционале система ни приобретает, ни теряет. Зачем менять то, что и так работает? Зачем чинить то, что не сломалось? В чём эта система устарела? Получается, что в этом случае её устаревание - это ТОЛЬКО лишь ВАШЕ СУБЪЕКТИВНОЕ представление.

>А вы всё ещё ищите какую-то совместимость между бинарными пакетами для 6.x и неподдерживаемой FreeBSD 5.x.

Я искал её больше года назад, сейчас я это упомянул просто для примера. Если хотите, можете читать вместо 6.x 7.x, а вместо 5.x 6.x.

>Я не удивлюсь, что у вас где-то работают серверы на ядре Linux 2.4.x или 2.2.x. Что ж — бог в помощь.

У меня таких нет. Но я думаю такие системы могут существовать. Какой-нибудь древний RedHat может до сих пор официально полноценно поддержиаваться. В таком случае зачем его менять без серъёзных причин?

Я знаю, что до сих пор много где пользуются даже программами написанными на FoxPro, а FreeDOS - практически безальтернативная ОС для кассовых аппаратов.

>portaudit говорит об этом.

Во-первых portaudit говорит только об исправлениях в системе безопасности. А во-вторых, получается, что вы всё таки неспособны, не заглядывая в чейнджлог, сказать чем программа версии 2.1 отличается от программы версии 2.0. Вы точно знаете одно - "она лучше и поэтому нужно обновляться". Чего я от вас и добивался. Попробуйте хоть раз задуматься над осмысленностью тех действий, которые вы регулярно проделываете. Просто для того, чтобы убедиться, что вы сами понимаете зачем вы это делаете, а не делали так потому что "все вокруг так делают, и я тоже так делаю".

>Действительно, стало лучше (говорю о десктопе): стала заметнее скорость реакции интерфейса DE на действия пользователя (полгода-год назад была заметна большая латентность). Файловый кэш улучшен до того, что повторный запуск любой большой программы, как то: Firefox 3.0.10, Eclipse 3.4.1, OpenOffice3 (с отключенным "быстрым стартом") происходит мгновенно!

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

>С FreeBSD переход с ветки 6.x на 7.x весьма революционен как с точки зрения управления ресурсами железа,

Так, а что это за революция такая? Потребительские свойства каким образом улучшились? Конкретно для вас что изменилось? Я уже много раз при установке Windows слышал эту маркетинговую лапшу про "откиньтесь на спинку кресла".

>так и с точки зрения поддержки новых программно-аппаратных средств (драйверы и системное ПО).

А если железо не менялось и в прежней ОС оно определялось и работало, то что же вам дала новая версия ОС?

>FreeBSD идёт на десктопы, где будут работать тысячи программ переднего плана, а значит проводится работа по улучшению интерактивности системы.

Бла-бла-бла. Маркетинговый буллшит, вам хорошо промыли мозги.

>Обновления нужны для:
>1) исправления выявленных уязвимостей

В Debian stable уязвимости фиксятся, но софт фактически не обновляется. Что не так?

>2) улучшения эффективности работы программ.

А если меня в работе программ всё устраивает, мне всё равно прикажете обновляться хлопая в ладоши? И кроме того, вы прекрасно понимаете, что в большинстве случаев в новых "более эффективных" программах более эффективно будут работать новые функции, которые мне не нужны, а стало быть я опять ничего не выигрываю.

>Без тестов старых и новых конфигураций невозможно почувствовать улучшения. Если не верите чейнджлогам и своим глазам, тогда пишите свои тесты, проделывайте ту же работу, что уже сделали разработчики, чтобы улучшить систему. :))

Прогресс - это хорошо. Но я предпочитаю обдуманный и целенаправленный прогресс. Движение OpenSource в большинстве случаев мне напоминает движение тучи муравьёв - у него нет направления, туча просто расползается в разные стороны. Этакое вечное bloatware... Нет чтобы остановиться, закрыть уши от маркетинга, и хорошеньк подумать - а к чему же на самом деле стоит двигаться. Авторы и мэнтейнеры портов своей поделкой вполне готовы, а вот авторы pkgsrc (системы, основанной на портах) пошли дальше, но не в плане количества, а в плане качества.

Про Ubuntu - вы меня с кем-то путаете, я ей не пользуюсь.

>Так вот, непрерывные обновления FreeBSD способствуют эволюционному развитию инфраструктуры без существенных затрат на время простоя и профилактического обслуживания.

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

>Оперативненько...
>Это базовый компилятор для новых программ.

Старый не компилил? Яркий пример бездумного bleeding edge: полные штаны радости от новых циферок.

>Старый не компилил? Яркий пример бездумного bleeding edge: полные штаны радости от новых циферок.

"Старый" это какой? Системный что ли? Так он:
> cc -v
Using built-in specs.
Target: amd64-undermydesk-freebsd
Configured with: FreeBSD/amd64 system compiler
Thread model: posix
gcc version 4.2.1 20070719 [FreeBSD]

Для некоторых программ нужен GCC 4.3 и выше:
> grep "USE_GCC" -r /usr/ports/ | grep "4.3"
/usr/ports/Mk/bsd.gcc.mk:# USE_GCC= 4.3 # port requires GCC 4.3 to build with.
/usr/ports/net-p2p/deluge/Makefile:USE_GCC= 4.3+
/usr/ports/multimedia/miro/Makefile:USE_GCC= 4.3+
/usr/ports/graphics/enblend/Makefile:USE_GCC= 4.3+
/usr/ports/games/freeorion/Makefile:USE_GCC= 4.3+
/usr/ports/audio/py-tagpy/Makefile:USE_GCC= 4.3+
(в частности, меня интересует deluge)

>Затраты в случае FreeBSD _гораздо_ более существенные, просто они равномерно размазываются на большой период времени. Затраты на одно обновление раз в 3 года равны одной вашей итерации по обновлению системы.

Неправда.

Следует различать обновление системы и обновление программного обеспечения.

Обновление системы из исходников занимает порядка получаса-часа времени компиляции. Компиляция происходит во время работы системы, инсталляция новой системы из полученных бинарников происходит в течение пяти минут, mergemaster в интерактивном режиме при переходе с ветки на ветку требует порядка пятнадцати-двадцати минут на визуальный анализ совмещаемых конфигов. Обновления безопасности вообще могут происходить на автомате, по крону.

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

Итого: итерация по обновлению системы и ПО на FreeBSD производится прозрачно и быстро в силу непрерывности процесса поддержки и актуальности ПО.

Из-за отсутствия в популярных дистрибутивах Linux должного внимания к минорным обновлениям ПО (обновления производятся только по мажорным версиям и по закрытию критических уязвимостей) готовые бинарные пакеты в репозиториях запаздывают на месяц-два, если не на год, как в Debian. А итерация по обновлению ПО в каком-либо дистрибутиве Linux выливается в страх и ужас админа, производится в режиме "АВРАЛ" (чаще в выходные), естественно, с полным отключением пользовательских сервисов на время тестирования и разбора глюков обновлений.

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

Научите ставить новое ядро Linux без перезагрузки системы и "незаметно для пользователей".

[Поскипано про порты, требующие GCC4.3+]

>(в частности, меня интересует deluge)

А в Deluge что нового? Старый не качал?

> Научите ставить новое ядро Linux без перезагрузки системы и "незаметно для пользователей".

http://www.ksplice.com/

>Неправда.

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

>Итого: итерация по обновлению системы и ПО на FreeBSD производится прозрачно и быстро в силу непрерывности процесса поддержки и актуальности ПО.

Непрерывность обновлений мне в х..й не впилась, мне нужна непрерывность работы. Я хочу поставить сервак раз в год и чтоб работал без моего участия, сам патчился и т.п. Чтоб я только логи с него на почту получал. Если у меня сотни компов, на каждом устраивать 15-минутку обновления дорогого стоить будет.

>А итерация по обновлению ПО в каком-либо дистрибутиве Linux выливается в страх и ужас админа,

Пересадим того же админа за FreeBSD и его страх и ужас тотчас испарится? Не болтайте ерундой, его страх и ужас станут только ещё сильнее. Если у админа есть страх - ему не место в профессии. Или пусть учится делать бэкапы и всегда продумывает путь для отступления.

>производится в режиме "АВРАЛ" (чаще в выходные), естественно, с полным отключением пользовательских сервисов на время тестирования и разбора глюков обновлений.

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

>Научите ставить новое ядро Linux без перезагрузки системы и "незаметно для пользователей".

А, собственно, в чём проблема-то? Поставить его незаметно для пользователей можно. Старое ядро при этом никуда не денется - система продолжит работу со старым ядром. Чтобы загрузить новое ядро, потребуется перезагрузка. Но даже после перезагрузки старое ядро тоже никуда не исчезает.

>миллионы пользователей FreeBSD вынуждены орудовать напильником на пустом месте.
Насчет миллионов эт вы польстили

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

А ты что, обновляешь сразу «сотни компов» боевых без проверки на тестовом стенде? Это многое говорит о профпригодности, если ты настолько доверяешь вендору «Debian», но при этом признаешь периодические «глюки». А если тестовый стенд есть, то держать свой build server ради редких случаев сборки из исходников ничуть не накладно. Тем более, что в любой системе рано или поздно ты столкнешься с необходимостью собрать что-нибудь с ключами отличными от любого имеющегося в репозитарии вендора бинарника. А уж если у тебя есть свои внутренние наработки, как у подавляющего большинства, то такой сервер просто необходим. Со своим кастомным деревом портов.

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

> Пересадим того же админа за FreeBSD и его страх и ужас тотчас испарится?

Во-первых, в продакшен на FreeBSD уже давно крайне редко приходится что-нибудь компилять: в пределах одного RELEASE — `freebsd-update fetch; freebsd-update install`, при переходе на следующий — `freebsd-update upgrade; freebsd-update install`.

Во-вторых, одна ветка STABLE FreeBSD практически аналогична одной ветке stable в Debian: переход x.y-RELEASE => x.(y+1)-RELEASE ни в какое сравнение не идет с переходом с etch на lenny. Последнее — это x.y-RELEASE => (x+1).z-RELEASE.

В-третьих, админу FreeBSD очень трудно понять твой «плачь Ярославны» по поводу отсутствия пакетов для 6.3-RELEASE, ведь вполне доступны свежие 6.4-RELEASE. В мире FreeBSD переход на следующую версию в пределах одного STABLE, признанного Production Release, — это всего лишь улучшение безопасности и стабильности. Без изменения функциональности и совместимости — редкие MFC привносят только тщательно выверенные модификации, не ломающие API/ABI для внесистемных приложений.

Вообще, совместимости API/ABI во FreeBSD без ущерба для нововведений многие могут только позавидовать: pathchar, собранный 10 лет назад для 3.0, работает в 7.2. Старинный официальный сервер quake 1, собранный для BSDI, заработает при включенной в ядре поддержке a.out.

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

> Поставить его незаметно для пользователей можно. Старое ядро при этом никуда не денется - система продолжит работу со старым ядром. Чтобы загрузить новое ядро, потребуется перезагрузка. Но даже после перезагрузки старое ядро тоже никуда не исчезает.

Если ты скажешь, что во FreeBSD не так, я сильно не расстроюсь, но сменю мнение об умственных способностях оппонента.

> А если тестовый стенд есть, то держать свой build server ради редких случаев >сборки из исходников ничуть не накладно. Тем более, что в любой системе рано >или поздно ты столкнешься с необходимостью собрать что-нибудь с ключами >отличными от любого имеющегося в репозитарии вендора бинарника. А уж если >у тебя есть свои внутренние наработки, как у подавляющего большинства, то >такой сервер просто необходим. Со своим кастомным деревом портов.

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

Это вы о ком? О себе что ли? Для начала сделайте "man apt-build" ага? Меня только всегда забавляла позиция поклонников freebsd насчет linux. С точки зрения администрирования отличия между freebsd и linux не такие уж гигантские. Иногда между разными дистрибутивами Linux отличия куда большие - с точки зрения администрирования. Сделали понимаешь ли философию тут.

>А ты что, обновляешь сразу «сотни компов» боевых без проверки на тестовом стенде?

Если это исправления в системе безопасности, то да. В портах FreeBSD отличить исправление в системе безопасности от просто обновления на новую версию программы эээ... как бы это сказать... трудновато. В Debian stable я накатываю обновления не глядя.

>Это многое говорит о профпригодности, если ты настолько доверяешь вендору «Debian», но при этом признаешь периодические «глюки».

Глюки бывают только при обновлении системы до нового stable. Когда выходит новый stable у меня есть год-два на то, чтобы неторопясь, вооружившись подробной инструкцией, делая бэкапы, перевести все машины с oldstable на stable.

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

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

Хорошие профессионалы ценят свое время и, в свою очередь, выбирают RedHat, CentOS и Debian. Допускаю что профессионал знает FreeBSD, но не могу поверить чтобы профессионал зная все её недостатки, в новых инсталляциях всё равно бы выбрал её. Если профессионал выбирает FreeBSD - есть повод задуматься.

>Во-первых, в продакшен на FreeBSD уже давно крайне редко приходится что-нибудь компилять: в пределах одного RELEASE — `freebsd-update fetch; freebsd-update install`, при переходе на следующий — `freebsd-update upgrade; freebsd-update install`.

А как безопасно обновить программы, если нет стабильной ветки портов/пакетов, где бы просто патчились дыры? А как часто нужно обновлять? Не превратятся ли эти обновления в перманентные обновления без ясной цели?

>Во-вторых, одна ветка STABLE FreeBSD практически аналогична одной ветке stable в Debian: переход x.y-RELEASE => x.(y+1)-RELEASE ни в какое сравнение не идет с переходом с etch на lenny. Последнее — это x.y-RELEASE => (x+1).z-RELEASE.

x.y-RELEASE => x.(y+1)-RELEASE в Debian просто не требуется. Если система уже работает и справляется с возложенными на неё задачами, смысла обновлять её нет. Нужно просто периодически закрывать уязвимости.

В Debian нет понятия базовой системы, поэтому при переходе x.y-RELEASE => (x+1).z-RELEASE обновляется всё. Или вы используете FreeBSD без портов и пакетов?

>Вообще, совместимости API/ABI во FreeBSD без ущерба для нововведений многие могут только позавидовать: pathchar, собранный 10 лет назад для 3.0, работает в 7.2. Старинный официальный сервер quake 1, собранный для BSDI, заработает при включенной в ядре поддержке a.out.

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

Например так. У меня есть старая система, допустим FreeBSD 5.x. Я подготовил другой сервер, на котором настроил полностью аналогичную конфигурацию. Я не хочу обновлять старый сервер, а всё что мне нужно - перенести с неё довольно много файлов, причём с минимальным перерывом в обслуживании. После переноса файлов система будет снесена. Допустим я выбрал для переноса файлов rsync. Я хочу поставить rsync, но не могу найти пакет rsync для версии 5.x. Приходится ставить из портов, а в портах может быть уже выкинута поддержка моей системы. То есть ради установки пакета rsync мне придётся заниматься обновлением ненужной мне системы?

Поняли мою претензию по этому пункту? Мне нужны архивы с пакетами под любую версию системы, вне зависимости от того поддерживается она или нет.

>> Поставить его незаметно для пользователей можно. Старое ядро при этом никуда не денется - система продолжит работу со старым ядром. Чтобы загрузить новое ядро, потребуется перезагрузка. Но даже после перезагрузки старое ядро тоже никуда не исчезает.

>Если ты скажешь, что во FreeBSD не так, я сильно не расстроюсь, но сменю мнение об умственных способностях оппонента.

Хэх! Посмотри сам, кто такие глупые вопросы задаёт.

>Когда выходит новый stable у меня есть год-два на то, чтобы неторопясь, вооружившись подробной инструкцией, делая бэкапы, перевести все машины с oldstable на stable.

Ж)))
Нифуя себе! Два года! ААААААААААААА!

>Допускаю что профессионал знает FreeBSD, но не могу поверить чтобы профессионал зная все её недостатки, в новых инсталляциях всё равно бы выбрал её. Если профессионал выбирает FreeBSD - есть повод задуматься.

Профессионал выбирает FreeBSD, потому что у него нет времени "год-два" разбирать глюки stable.

>А как безопасно обновить программы, если нет стабильной ветки портов/пакетов, где бы просто патчились дыры?

Ещё раз для слепоглухонемых: новая версия порта программы == патчи и закрытие дыр этой программы. Здесь работают два персонажа: тот, кто выпустил ПО (автор-издатель), и тот, кто интегрировал ПО в коллекцию (мантейнер). Два раза не ошибаются.

>А как часто нужно обновлять? Не превратятся ли эти обновления в перманентные обновления без ясной цели?

Как выйдет — так и обновляй. Хуже не будет. :))

>В Debian нет понятия базовой системы, поэтому при переходе x.y-RELEASE => (x+1).z-RELEASE обновляется всё.

Поэтому и риск обновлений в Debian большой.

>Например так. У меня есть старая система, допустим FreeBSD 5.x.

Ветка 5.x не поддерживается. Потому вменяемым администраторам ниразу не нужна, кроме линуксойдов-неудачников.

> Поэтому и риск обновлений в Debian большой

Cкажем так форум фряхи сообщениями от благодарных пользователей у которых нет вообще проблем не сильно то изобилует.

http://forums.freebsd.org/forumdisplay.php?f=5

Вобщем аргумент за freebsd один и он в основном эмпирический - "freebsd более надежная"