Вместо того чтобы снести с уже работающей системы тормозной GNOME и поставить Fluxbox

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

А далее расписывается с чего началось использование FreeBSD - с поиска патча для драйвера сетевой карты.

Еще раз повторяю - речь идет об _очень_ нестандартном железе. Я имел дело (давно) с Делловскими ноутами (под Линуксом) - и с тех пор зарекся даже смотреть на эту лабелу. Навсегда.
Тем не менее, даже в этом клиническом, на грани летальност, случае, проблемы оказались решаемы.
А с ноутами стандартно-малоарнаутского розлива, которых прошло через мои руки без счета, проблем не возникает вовсе. Разве что с новомодными ныне встроенными веб-камерами - но это а) баловство и б) понятно.

>Вы уже второй раз повторяете, что рекомендованный способ установки ПО на FreeBSD - порты. Если вас не затруднит, объясните пожалуйста,  почему вы утверждаете что это так.

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

>http://vershinin.dyndns.org/doku.php?id=freebsd_on_dell1525

Автора этой статьи я знаю лично. Можно сказать, в своё время именно с его подачи мой выбор в пользу первой nix-системы склонился именно в пользу FreeBSD. О чём я ничуть не жалею - для обучения она попросту незаменима.

Ключевые слова этой статьи вот в чём:
>практически любой дистрибутив в установке по умолчанию показывал чудеса тормознутости…
А далее расписывается с чего началось использование FreeBSD - с поиска патча для драйвера сетевой карты.

В общем дальше можно и не читать. Автор даже не упомянул, были ли проблемы с железом в Linux. Но если он об этом не сказал, подразумевается, что проблем не было. Вместо того чтобы снести с уже работающей системы тормозной GNOME и поставить Fluxbox, который и был впоследствии установлен на FreeBSD, автор начинает по винтику выстраивать с нуля новую систему, подбирая патчи к ядру и драйверы. Где тут объективность?

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

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

А ещё OpenBSD лучше FreeBSD в том плане, что рекомендуемый способ установки программ - пакеты.

Вы уже второй раз повторяете, что рекомендованный способ установки ПО на FreeBSD - порты. Если вас не затруднит, объясните пожалуйста,  почему вы утверждаете что это так. Потому как, в хэндбуке информация такая: "FreeBSD provides two complementary technologies for installing third-party software on your system: the FreeBSD Ports Collection (for installing from source), and packages (for installing from pre-built binaries). Either method may be used to install the newest version of your favorite applications from local media or straight off the network".

>Топик больше похож на обяснение принципов эфективного создания искуственных проблем в Freebsd и debian в роли панацеи.

Debian - далеко не панацея, но к идеалу стремится. Есть другие системы, пользующиеся подобным принципом обновлений: CentOS и RedHat. Только они используют пакетную систему rpm, которая слабее deb по гибкости.

На роль панацеи в области безопасности претендуют скорее Танненбаум и ДеРадт. Они стремятся сделать свои системы настолько надёжными, что обновления будут не нужны в принципе А ещё OpenBSD лучше FreeBSD в том плане, что рекомендуемый способ установки программ - пакеты.

>Вы считаете, что httpd (Apache) на кэширующем сервере Debian не отнимает ресурсов? Я обратного мнения.

Ещё раз повторяю: для apt-cacher не нужен веб-сервер! И ресурсов он отнимает гораздо, ГОРАЗДО меньше, нежели билд-сервер.

>В отличие от Apache и lighthttpd, сетевая файловая система не имеет сторонних подключаемых компонентов. Грубо говоря, трояны не могут просто так внедриться в код nfs — у Apache и lighthttpd вероятность подхвата червя поболее. Следите за уязвимостями и вовремя закрывайте дырки в Web-серверах.

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

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

>Данные по NFS передаются в несколько раз быстрее, чем через вышеназванные протоколы.

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

Ладно, суть вообще не в этом. Я уже сказал, что вместо кэшера в Debian можно организовать зеркало и раздавать его файлы по тому же nfs.

>Хотите — используйте лишние сетевые сервисы у себя в сети.

Всего один несложный perl-скрипт, который закрыт фаерволлом так, что доступен только оттуда, где он непосредственно нужен.

>Кичитесь надёжностью залатанного ПО древнейших версий.

Работает? Не трогай.

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

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

Вообще, Вы меня сейчас порадовали, у Вас всё-таки бывают моменты, когда Вы не только говорите, но и умеете слушать

Hrafn
Стараюсь объяснить принципы эффективной работы, но тут все традиционалисты.

Топик больше похож на обяснение принципов эфективного создания искуственных проблем в Freebsd и debian в роли панацеи.

>Критические обновления к самой системе выходят приблизительно раз в месяц — на это всё тратиться час; на компиляцию лишь одного ядра — десять-пятнадцать минут вместе с разбором/заданием конфига.

Ну вот недавно в списке рассылки промелькнуло несколько уязвимостей ядра Linux 2.6.24, в Debian скопом закрытых одним обновлением. Я гляжу иногда в список рассылок посвященный обновлениям в стабильной ветке Debian, просто чтобы быть в курсе. Как Вы думаете, если бы у меня стояло это ядро (мне везде хватает ядра 2.6.18), сколько времени я бы потратил на компиляцию? Ответ: да мне даже конфиг ядра вспоминать бы не пришлось!

Понятно. Всё забыли.

Согласен. В этом вы правы. Может быть из-за этого Debian делится на стабильную, тестовую и экспериментальную ветки.

Ага. Это "+" Debian. Во FreeBSD нужно уповать на правильность автообновления (если оно запущено) и версии обновляющихся программ не слишком разнятся.

Хотя, вот обратный пример: трудно спутать ports/www/tomcat55 и ports/www/tomcat6 — это два разных порта. И команды старта у них другие. И скрипты настроек отличаются. Так что один другого обновить не сможет. И ещё, при деинсталляции, в одноимённом каталоге приложения/сервиса останутся вручную отредактированные скрипты — pkg_delete не будет удалять каталог приложения, если контрольная сумма удаляемых файлов не совпадает с той, что зарегистрирована в базе данных уст.приложений — предложит удалить вручную "остатки".

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

Из статьи по ссылке видно, что структура каталогов у этого кэширующего сервиса отлична от принятой в Debian.
На билд-машине FreeBSD это не так — дерево пакетов соответствует тому, что может быть в локальных каталогах /usr/pors/packages/ любых машин. Так что опять ничего лишнего настраивать не надо.

Вы считаете, что httpd (Apache) на кэширующем сервере Debian не отнимает ресурсов? Я обратного мнения.

В отличие от Apache и lighthttpd, сетевая файловая система не имеет сторонних подключаемых компонентов. Грубо говоря, трояны не могут просто так внедриться в код nfs — у Apache и lighthttpd вероятность подхвата червя поболее. Следите за уязвимостями и вовремя закрывайте дырки в Web-серверах.

SAMBA — это, очевидно, из другой оперы и как-то неспортивно, то ли...

Во-первых, это всё транспортные протоколы. Причём NFS родная сетевая файловая система Unix. И считать её аналогом протоколов более высокого уровня (FTP и HTTP), а тем более SAMBA, по меньшей мере неожиданно. Данные по NFS передаются в несколько раз быстрее, чем через вышеназванные протоколы.

На это и порешили.

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

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

>Ребята, вы не устали еще?

Я устал. Стараюсь объяснить принципы эффективной работы, но тут все традиционалисты. Всё таки привычка - плохая вещь...

Пожалуй пора уйти отсюда. Свою позицию я высказал, даже неоднократно. Кто хотел понять - уже понял, остальным это не нужно.

Ну вот недавно в списке рассылки промелькнуло несколько уязвимостей ядра Linux 2.6.24, в Debian скопом закрытых одним обновлением. Я гляжу иногда в список рассылок посвященный обновлениям в стабильной ветке Debian, просто чтобы быть в курсе. Как Вы думаете, если бы у меня стояло это ядро (мне везде хватает ядра 2.6.18), сколько времени я бы потратил на компиляцию? Ответ: да мне даже конфиг ядра вспоминать бы не пришлось!

>Во FreeBSD принято: раз порт программы обновился, то программа залатана, исправлена в ней какая-либо ошибка. Списки рассылки читать необязательно, но желательно быть в курсе событий, читая верхние строчки файла /usr/ports/UPDATING для ПО (там описываются только критические причины обновления и нюансы) и соответствующий файл для исходников системы.

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

В стабильной ветке Debian любой пакет обновляется только по причине залатывания дырки. В формате конфигов или чём-либо ещё, изменения не могут произойти в ПРИНЦИПЕ. Стало быть мне не нужно при обновлении ничего читать и проверять работоспособность сервисов после обновления, обновления вообще можно производить во время моего отсутствия в автоматическом режиме (допустим нет меня - я в отпуске).

>Возможностей много == сложность растёт в геометрической прогрессии от числа этих самых фич и их комбинаций.

Не всегда так. Это зависит от взаимной зависимости компонентов. Но вообще в apt-cacher'е нет ничего сложного - это небольшой perl-скрипт. Пожалуй даже ntpd и тот на порядок сложнее.

>Ну вот, видите. Сервер (http) всё-таки нужен.

Для apt-cacher'а - не нужен. Для зеркала вместо web-сервера можно использовать nfs, samba или ftp-сервер.

>Билд-сервер — это всего лишь РОЛЬ, которую может на себя взять одна из машин в сети.

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

>А вот установка отдельного кэш-сервера и http/ftp-сервера на машину чревата куда большими заморочками по обеспечению безопасности и согласованности (доступности).

Приведите пример, чем http/ftp-сервер сложнее nfs/samba в плане безопасности? Их всех можно ограничить фаерволлом - вот вам безопасность. Согласованность - это единое зеркало, какая может быть рассогласованность? Кстати NFS далеко не безопасен, т.к. основан на протоколе UDP и поэтому подвержен спуффингу, и не имеет механизмов авторизации.

И вообще, http/ftp/nfs/samba нужны для полноценного зеркала, которое для личных целей создавать неоправданно - это опять же принцип микроскопа и гвоздей. Для личного использования внутри фирмы или дома достаточно поставить и настроить apt-cacher, он не требует ничего сверх самого себя и легко настраивается - достаточно подрихтовать под себя две строчки в конфиге.

В общем Вы мне предлагаете взамен
варианта 1. установки apt-cacher, исправления двух строчек в конфиге и настройки автоматического обновления
вариант 2. потратить деньги на железку под build-сервер, тратить деньги на электроэнергию (вместе с дополнительной мощностью кондиционирования серверного помещения), настроить этот сервер, использовать небезопасный NFS, регулярно читать UPDATING, обновлять вместе с дырявыми пакетами ещё и пакеты с обновлением версии, проверять после обновления работоспособность каждого сервиса.

Где смысл?

iZen:

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

Ну то, что Ваши интересы ограничиваются только Apache и PostgreSQL, это ещё не значит, что кроме них ничего никому не надо.

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

Вы не поверите, но у меня каждый день синхронизируется локальная копия дерева портов и запускается portupgrade. И это всё делается в ФОНЕ, нисколько не мешая интерактивной работе за компьютером. В среднем обновляется от двух до семи установленных пакетов. Самое большее время компилируется OpenOffice (порядка пяти-шести часов), но и его обновления выходят редко — может быть раз в полгода.

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

Во FreeBSD принято: раз порт программы обновился, то программа залатана, исправлена в ней какая-либо ошибка. Списки рассылки читать необязательно, но желательно быть в курсе событий, читая верхние строчки файла /usr/ports/UPDATING для ПО (там описываются только критические причины обновления и нюансы) и соответствующий файл для исходников системы.
(Я не подписался ни на один из списков рассылки.)

Возможностей много == сложность растёт в геометрической прогрессии от числа этих самых фич и их комбинаций.

Ну вот, видите. Сервер (http) всё-таки нужен.

Напротив, сервер FreeBSD, иногда исполняющий роль билд-машины, не нуждается в выделенном http-сервере и его сопровождении.

Да не о том я.

Билд-сервер — это всего лишь РОЛЬ, которую может на себя взять одна из машин в сети.

А вот установка отдельного кэш-сервера и http/ftp-сервера на машину чревата куда большими заморочками по обеспечению безопасности и согласованности (доступности).

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

Ну то, что Ваши интересы ограничиваются только Apache и PostgreSQL, это ещё не значит, что кроме них ничего никому не надо.

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

>А другие машины и будут избегать компиляции. Что ещё нужно? О каком микроскопе вы говорите?

А в моём варианте другие машины будут избегать компиляции без билд-сервера.

>А я прочитал недавно, что там всё гораздо многословнее и сложнее:
>http://habrahabr.ru/blogs/ubuntu/46449/

Там не так уж и много написано, просто подробно, чтоб до всех дошло.

>Я просто упал от конфигурационного файла.

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

>Да ещё "Второй минус — необходимо наличие Веб-сервера Apache. ". Ну это вообще никуда не годится.

Ну я лично Apache уже год с хвостиком не использую. Возможностей Lighttpd мне вполне достаточно.

Если же говорить о прокси и зеркале, то apt-cacher'у веб-сервер не нужен, а для использования с зеркалом вполне пригоден даже анонимный ftp-сервер.

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

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

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

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

А другие машины и будут избегать компиляции. Что ещё нужно? О каком микроскопе вы говорите?

А я прочитал недавно, что там всё гораздо многословнее и сложнее:
http://habrahabr.ru/blogs/ubuntu/46449/

Я просто упал от конфигурационного файла.

Да ещё "Второй минус — необходимо наличие Веб-сервера Apache. ". Ну это вообще никуда не годится.

Чего вы, линуксоиды, любите так усложнять простые вещи?