• URL mail-archive.com — Re: FreeBSD :)
    """
    [...]
    Вопрос номер три. Какие недостатки ?

    Преимущественно от "ничем не лучшего" до "невменяемого"
    сообщества, в зависимости от географии, застарелости и редкости
    профессии. Это из тех, кто обожает "послать в маны", не уточняя
    ни названия manpage, ни тем более ключевого слова в ней, и потом
    ржать всем каналом (наблюдал такое — ещё звали "поприкалываться
    над лохом"). Из тех, кто врёт или просто самодурствует.
    Хорошо, если попадутся нормальные, вменяемые, интересные люди
    (которых много в Киеве, например) — но они как раз обычно
    могут внятно изложить, почему сами на фре, но не станут кого-то
    перетягивать с того же дебиана. См. тж. [1].

    Застарелость. В первую очередь в плане поддержки железа.
    Правильно, человеку компьютер нужен не чтоб работало, а чтоб
    угробить на него кучу времени и потом старательно пытаться
    выглядеть круто, подсовывая ту же гадость другим и приговаривая
    "это тебе не лялих" [где всё и так работает]. См. тж. [2].
    (NB: применимо и к фанатам линукса, тянущих на него виндовозников
    без разбору-ответственности)

    Тупиковость. Фря — это не платформа, по заключению одного
    сотрудника IBM, заодно Samba-хакера, которого многие здесь знают.
    Обоснование — проект замкнут на себе и враждебно относится к тем,
    кто пытается строить на основе (те же NAS appliances, о которых
    те несколько лет назад и шла речь). См. тж. [3].

    Да, если будут утверждать, что "фря — это юникс" — не юникс,
    см. сайт OpenGroup со списком UNIX(TM)-систем.
    [...]
    """

Replies (56)

  • @stanislavv, Фря всё меньше и меньше используется, хотя система замечательная, я с неё начинал.
  • @caban, я с неё не начинал, но несколько лет всё ж имел дело... Если "поставить и забыть" — не отличается от линуксов. А вот если "поддерживать" — уже наблюдается геморрой.
  • @stanislavv, Сейчас ужен нет. Там с этим борются, роутеры на ней можно хорошие делать. Да и с nginx они круто работали.
  • @caban, роутеры нынче и на линуксах неплохие... Да и nginx на них тоже неплохо работает...
    Потому на первое место выходят затраты усилий на поддержку. И тут фря сливает...
  • @stanislavv, Согласен, за скоростью никто не гонится.
  • @caban, Скорее, никому не надо ещё полпроцента скорости, если заменой железа добавляется 20%.
  • @stanislavv, Последний раз у меня было 5% :)
  • @caban, Я утрирую :-)
  • @stanislavv, ровно наоборот. поддержка линуксов это непрерывный костылизм. а если линуксов зоопарк, это очень печально.
  • @SolderStain, Имел дело и с тем и с другим одновременно (правда, под разные задачи всё же).
    Если разводить зоопарк (да хотя бы и разные версии фри) — будет костылизм в любом случае. При этом apt-get update && apt-get upgrade в том же стабильном дебиане почему-то требует меньше внимания, чем обновление портов во фре (не в курсе, как оно сейчас с пакаджами) и точно не обновит серверное ПО на следующую мажорную версию. К портам — бааальшие претензии есть... И не только у меня.
    Далее, коммунити. Наименее адекватное, к сожалению. ЧСВ завышено до небес, хотя в лучшем случае — админ конторского роутера (сравнивая текущий контингент фидошных ru.unix.bsd и ru.linux).
    Поддержка железа. Будете спорить или признаете, что у фри есть отставание?
  • @stanislavv, в серверной части с поддержкой железа всё хорошо.
    pkg update работает достаточно хорошо.

    ps: большая часть бесплатных NAS applaince таки freebsd-based
  • @solhov, "достаточно хорошо" — можно развёрнутей? Можно ли доверять обновлениям на уровне "запустил и забыл" при наличии работающей сети или вообще засунуть в крон с запретом автообновления некоторых софтин?
    Есть ли стабильная ветка репозитория, где вносятся только патчи безопасности, а не новые фичи и новые баги (через новые версии софта)?

    Про серверную поддержку железа в курсе. Мне б более консамерское железо...
    Ну а nas... Если оно хоть как-то увидело диск и сеть — пофиг на чём собрано. На фре начали раньше делать, вот и всё.
  • @stanislavv,
    Если разводить зоопарк (да хотя бы и разные версии фри) — будет костылизм в любом случае.
    всегда имел дело именно с зоопарком фрях. не вижу проблем. относительно сложный вариант — нагруженные 7/24 протухшие фряхи с убитыми портами, но тут и дебианоподобные ровно в том же положении.
    apt-get update && apt-get upgrade
    это если нет самосборщины. а она есть. и тут обновление портов рулит и педалит. ну и помнить, что обновлять порты раз год — это боль и печаль. ну и да — вот стоит дебиан древний (современник FreeBSD 8.0). 8.0 в 10 я обновляю норм, про дебиан я не уверен. есть конечно вариант с реинсталлом, но...
    и точно не обновит серверное ПО на следующую мажорную версию
    если ты про собственно ось — то не вижу разницы с убунтодебианами. обновление оси это обновление оси. ну разве что во фре подготовка займёт время (сборка мира,ядра)
    К портам — бааальшие претензии есть...
    вообще никаких. опять же если нужен нестандарт (а он нужен, не всё решается модулями) вообще без альтернатив.
    Далее, коммунити. Наименее адекватное, к сожалению.
    У фри? Ну как сказать. я бы сказал — беспощадное к новичкам. На самом деле конечно в 99% случаев не собственно к новичкам, а к попыткам загрузить комьюнити решением проблем, которых при нормальных подходах просто нет. Но это тонкости, в которых никому разбираться не интересно и потому всё воспринимается как воспринимается — как высокомерие вплоть до неадекватности.
    Поддержка железа. Будете спорить или признаете, что у фри есть отставание?
    Я не в курсе, добивайте меня примерами. На железе HP/Supermicro я с неподдерживаемым железом лет за десять сталкивался пару раз. Так как у меня на линукс аллергии нет и втыкнуть вместо предпочитаемой фри лялих — без проблем, могу сказать что по причине железа линукс вставал только раз восемь-десять лет. Чаще по причине софта. 1С под линукс, дотнетокрап по видеонаблюдению, виртуализация — вот с моей т.з. показания к однозначному использованию линукса. А вот например собрать сеть серваков с kerberos/ldap и потом их обновлять штатно это во фре КМК полегче.
  • @stanislavv,
    Есть ли стабильная ветка репозитория, где вносятся только патчи безопасности, а не новые фичи и новые баги (через новые версии софта)?
    Чем плохи новые фичи и откуда уверенность, что бэкпорт "патчей безопасности" чем-то лучше новых версий?
  • @solhov,
    в серверной части с поддержкой железа всё хорошо.
    ну не всё. сталкивался с HP блейдами, у которых неподдерживаемые на тот момент сетевухи были. но в целом да, разница невелика.
  • @SolderStain,
    если ты про собственно ось — то не вижу разницы с убунтодебианами. обновление оси это обновление оси. ну разве что во фре подготовка займёт время (сборка мира,ядра)
    Да нет, я как раз про софт, так как в базовой системе обычно нет того, ради чего собственно сервер и ставится. К тому же, я против того, чтобы иметь компилятор на хосте, не предназначенном для сборки своих собственных пакетов.

    вообще никаких. опять же если нужен нестандарт (а он нужен, не всё решается модулями) вообще без альтернатив.
    Гм... У меня есть сомнения, что в процессе сборки с нестандартными опциями я не получу кучу портов в системе, которые предпочёл бы ставить бинарниками.

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

    А вот например собрать сеть серваков с kerberos/ldap и потом их обновлять штатно
    Таки будете смеяться, но делал. На Centos5. Следующий после меня админ недавно обновил до Centos6. Вот как именно он делал — не уточнял, но, подозреваю, штатными средствами и без прерывания работы сервиса.

    Про поддержку железа — насчёт серверного согласен, уже лет 5 нормально, разве что редкие сетевые или дисковые контроллеры могут попасть. Десктопное... Не уверен, тут железо меняется чаще.

    Далее, та же виртуализация. Вы всё ещё ставите по железке под каждую задачу или пихаете NN сервисов в одну ось?
    Я в курсе про jail, но этот chroot-переросток всё ж недотягивает до openvz, пожалуй.
    bhyve — в догоняющих до kvm, судя по Features Under Development и в продакшне не применим.

    То есть, ниша фри — либо таки действительно NAS, либо ситуация "одна железка — одна ось" и то при нескольких условиях, из которых первое — наличие минимум двух админов фри в конторе, иначе линукс обойдётся дешевле и надёжнее в долгосрочном плане. Остальные условия — технические и без первого их нет смысла рассматривать.

    Вот где фря имеет преимущество — там, где имеет смысл поднимать netgraph. Другой вопрос, что бОльшей части роутеров он нафиг не сдался.
  • @SolderStain, Плохи они тем, что 1) вносят новые баги, причём фикс старых — не всегда производится, 2) иногда меняется формат конфигов, что важнее.
    То есть, после обычного обновления сервисов во фре есть вероятность того, что что-то нужное не поднимется.
  • @stanislavv, Твою ж мать! Надо поставить всё ж клиента под жуйк...
  • @stanislavv,
    К тому же, я против того, чтобы иметь компилятор на хосте, не предназначенном для сборки своих собственных пакетов.
    source-based без компилятора — это нонсенс.
    которые предпочёл бы ставить бинарниками.
    не вижу преимуществ в установке бинарями. всё ставлю из портов. ну за исключением трёх пакетов screen sudo ansible при начальной раскатке.
    Чаще всё ж неадекватное.
    Это дело восприятия и спорить тут бессмысленно. По ходу пьесы про маны приходилось и говорить и выслушивать и наверняка кто-то мог счесть меня неадекватом, а кого-то неадекватом считал и я. Но в целом — независимо от т.з. на причины проблема скорее есть, чем нет.
    Таки будете смеяться, но делал.
    Смеятся не буду, но возможно дело привычки, но делание чего-либо требующего сборки на чистых BB (binarybased) я зарёкся. С моей точки зрения простой, штатный и удобный процесс сборки превращается в грёбаный цирк. Опять же хорошо если он один (один дистр). Могу, но для меня это как троллейбус из хлеба: зачем? если можно спокойно штатно сделать на фре?
    Десктопное...
    Не вижу проблем на серверах держать фрю, на десктопе линукс. А чтобы не изменять привычке всегда иметь ручной контроль над сборкой софта — что-то максимально близкое к портам — gentoo/Calculate.

    Далее, та же виртуализация. Вы всё ещё ставите по железке под каждую задачу или пихаете NN сервисов в одну ось?
    Когда как. На особо важные можно и нужно выделять железо и даже резервировать. Если пара сервисов связаны и не требуют какой-то изоляции — почему не запихнуть в одно железо? Если хватает jail — можно jail. Если не хватает — ставим линукс (я уже про это писал, что обязательность виртуализации лично для меня — показание к установке линукса).

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

    т.е. ниша линукса — виртуализация и десктоп :) по поводу наличия каких-то специфических админов фри я не понимаю. может конечно у меня профдеформация и взгляд замылен, но за всю практику коллеги приходят и уходят, и если люди вменяемые, без специальных загонов — все прекрасно работают под FreeBSD/Linux. Ну вот я подосвобожусь через пару месяцев — начну плотно втыкать в DragonflyBSD, есть идея некритичные внутренние сервисы на ней погонять. Коллега вот дома солярку мучает. Кто-то по опёнку тащится. Когда на аутсорсе работал так вообще на граждан "я линуксоид, я фрю не знаю" "я фряшник, мне ваш линукс не нужен" и прочих "я специалист по дебиан, а не centos/rh" вообще смотрели с подозрением. Админ? Специалист? Почини/разберись/поставь. Понятное дело предпочтения у всех, но работе это мешать не должно.
  • @stanislavv,
    Плохи они тем, что 1) вносят новые баги, причём фикс старых — не всегда производится,

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

    2) иногда меняется формат конфигов, что важнее.
    (пожимает плечами). если сервис некритичный ты сразу об этом узнает и тут же исправишь. если сервис критичный, то обновлять на продакшене это какой-то нездоровый риск. я даже не буду говорить, что я много читал про "опасность смены формата конфига" но а) я честно уже не помню где он так радикально менялся, чтобы я запомнил б) дефолтный конфиг с расширением .sample кладётся в /u/l/etc. сравни, коль боишься и откатись, коль проблемы. делов-то.
  • @SolderStain,
    source-based без компилятора — это нонсенс.

    poudriere

    Если хватает jail — можно jail. Если не хватает — ставим линукс

    VirtualBox
  • @SolderStain, о, я вспомнил проблему, которая действительно есть: наличие в системе софта, поставленного нештатно: самосборный из тарбола, pip/gems/cpan. вот тут бывают грабельки.
  • @solhov,
    poudriere
    как вариант
    VirtualBox
    коммерческое же
  • @SolderStain,
    коммерческое же

    нет
  • @solhov, ну хз. мы семь лезвий загнали в proxmox — там и виртуалки и докеры и в переспективе Live Migration
  • @SolderStain, Хе... Тут гораздо хуже бывает. Но таки да, на тестовой машине.
    Решили обновить rspamd, так как текущая версия течёт — на конфиг не ругается (точнее, при проверке утверждает, что всё ок), в процессе работы — падает. С дефолтным конфигом — не падает, но и не ловит чего надо.

    А вообще, из ваших слов делаю вывод: фрю нельзя обновлять массово даже из штатных источников.
  • @SolderStain, А вот это — где угодно грабли... Такое мы допускаем только в домашних каталогах клиентов, которые не хотят платить за вдс.
  • @solhov,
    poudriere
    Это уже не сорс-базед, это по факту — подготовка своих пакетов из чужих исходников.

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

    VirtualBox
    Живая миграция в опенсорсной версии (честно, не в курсе, как оно именно в опенсорсной)? Живая миграция без общего стораджа? Изменение параметров работающей виртуалки без её перезагрузки (память в обе стороны, количество процессоров и объём диска — в большую)? Запуск ос другой архитектуры (да хотя бы arm на хосте x86)?

    Тут я перечислил то, что умеет kvm на линуксе. Хорошо бы, если б это умел ещё и bhyve.
    И да, я этими фичами пользуюсь регулярно и по работе (кроме последней, которая для извращений с образами под RaspberryPi)
  • @SolderStain,
    т.е. ниша линукса — виртуализация и десктоп

    А контейнеры? :-)
    Докер нынче модно, блин...
    Я бы сказал — общего назначения уже... Пихают даже туда, где есть более подходящие альтернативы (я вроде говорил, что на роутеры лучше фря?).

    Специализация — это когда въезжаешь не только в то, как поставить сервис через make install из выкачаных руками исходников (не примите за пинок в сторону фри, скорее слакварь), но и в неочевидные тонкости системы.
    Общий POSIX — это хорошо, но в случае того же дебиана/rh неплохо бы разбираться, как правильно собирать свои пакеты не через checkinstall (он, кстати, делает это неправильно) и создавать свой репозиторий, например. Ну и мелкие тонкости на тему "как правильно запустить сервис не из rc.local в системе, которую в предыдущий раз видел три дистрибутива назад", которые, конечно, можно выяснить, но, как обычно, когда надо выяснять — уже нет времени.
    Во фре — порты и пакаджи (в смысле создания, а не использования). В солярке — работа с dtrace и контейнерами.

    Уметь сделать базовые вещи везде не означает, что нет предпочтений или, если сказать по-другому, специализации. Моя специализация — Debian. Это не означает, что не поставлю фрю при необходимости или что принципиально не буду иметь дело с Centos, но и там, где особых преимуществ у чего-либо нет — поставлю дебиан, как наиболее знакомый и чью инфраструктуру я могу поддерживать с минимальными усилиями в том числе и по времени обслуживания. В случае другой оси мне придётся отдавать больше времени на сиё обслуживание. Причём, если в центоси в худшем случае — отладка сервиса под systemd или одноразовое выяснение изменений при переходе Centos6->Centos7, то во фре приличное время сожрёт именно обновление системы, не говоря уже о портах, так как доверять процессу обновления в ней нельзя и требуется организовывать тестовый стенд для любого обновления, а не только отдельного рабочего сервиса, под который система развёрнута.

    И под админами фри я понимаю тех, кто хотя бы 1) сможет сделать И поддерживать свой репозиторий портов/пакаджей (свой — со своими версиями/своим софтом, а не копию штатного), 2) использует его в повседневной работе, а не тех, кто бегло прочитал хендбук и сумел поставить фрю через штатный инсталлятор и немного побаловался с make install в портах.
  • @stanislavv,
    Это уже не сорс-базед, это по факту — подготовка своих пакетов из чужих исходников.

    это какое-то настолько тонкое религиозное отличие, что я его не улавливаю

    И, кстати, лет 12 уже не вижу смысла в именно общесистемном сорс-базед.

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

    Живая миграция в опенсорсной версии (честно, не в курсе, как оно именно в опенсорсной)?

    а то у нас есть не опенсорсная версия? не центр управления, а сам VB?
    да, есть.

    Живая миграция без общего стораджа?

    либо ты жулишь, либо не бывает (теоретически виртуалка может писать быстрее, чем ты будешь копировать).

    память в обе стороны, количество процессоров

    никогда не пробовал

    объём диска

    всгда по iscsi цеплял, как понимаешь в этом случае проблем нет по определению.

    Запуск ос другой архитектуры (да хотя бы arm на хосте x86)?
    Тут я перечислил то, что умеет kvm на линуксе.

    это не kvm. это qemu и это он умеет в юзерспейсе на любой ос.

  • @stanislavv,
    то во фре приличное время сожрёт именно обновление системы, не говоря уже о портах, так как доверять процессу обновления в ней нельзя и требуется организовывать тестовый стенд для любого обновления,

    ой не надо, когда на какой-нибудь центоси типа 5 или 6 надо в условный редмайн добавить модулек, то такой цирк начинается! там же уже добавили стронние репы, что бы условный php (я в курсе что редмайн на руби) был не окаменевшей версии и любон неловкое движение стремится снести тебе системную libc или что-то подобное.

    обновление системы во фре перепроверять не надо — в stable его ломают исключительно редко. а для портов давно есть poudriere
  • @solhov,
    либо ты жулишь, либо не бывает (теоретически виртуалка может писать быстрее, чем ты будешь копировать).

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

    > память в обе стороны, количество процессоров
    никогда не пробовал

    гм... автоскейлинг вебсервисов при изменении нагрузки.

    всгда по iscsi цеплял, как понимаешь в этом случае проблем нет по определению.

    Гм... Внутри виртуалки или к виртуалке?
    Просто, если внутри виртуалки средствами гостевой ос — да, проблем нет в любом случае, но и производительность диска в виртуалке поменьше будет.
    А к виртуалке — надо сделать так, чтоб средства виртуализации 1) это прочухали, 2) иметь возможность пробросить изменения внутрь виртуалки. Вопрос больше про это.

    это не kvm. это qemu и это он умеет в юзерспейсе на любой ос.

    Угу. А работающий модуль к нему для случая совпадающей архитектуры? Не, что модуль вообще был — я помню. Но и помню, как он вешал систему...
  • @stanislavv, VB штатно имеет клиентскую юзерспейсную iscsi часть, ну а потом отдает это как ide диск в виртуалку. запросы он при этом просто тупо транслирует.

    А работающий модуль к нему для случая совпадающей архитектуры

    ты уже сказал, что архитектура другая, определись уже
  • @solhov, Читай /29, я этой фичей в продакшне не пользуюсь.
  • @stanislavv,
    А контейнеры? :-)
    а это такая виртуализация хитрая :)
    Специализация — это когда въезжаешь не только в то, как поставить сервис через make install
    слака уже давно на slapt-get, во фре уже давно portmaster/portupgrade
    Уметь сделать базовые вещи везде не означает, что нет предпочтений или, если сказать по-другому, специализации.
    есть такое. и я про это пишу.
    то во фре приличное время сожрёт именно обновление системы
    если брать самый крайний случай — обновление из сорцов на живом серванте — то оно идёт параллельно с работой. если сервант уже не в работе, а время критично, то тут хочешь реинсталл, хочешь бинарями апнись. не думаю, что это проблема.
    так как доверять процессу обновления в ней нельзя
    походу это и есть основной камень преткновения. я собственно считаю ровно наоборот. самый надёжный пакет — собранный в твоём окружении.

    И под админами фри я понимаю
    на мой взгляд это слегка крайности и между ними спокойно пара промежуточных вполне годных вариантов. кроме того, фря спокойно позволяет ставить бинарями пакеты и быть вполне себе binary based, и если админ организовал всё бинарями и нет нужды собирать вообще — значит ли это, что он не админ? имхо нет. я вообще не такие критерии использую.
    "Админ обычный" — умеет ставить систему без торчания на форумах, умеет штатно ставить софт, читать логи, смотреть состояние системы, конфигурирование, знает и понимает про мониторинг, первичная диагностика сбоев. (упор на поддержку)
    "Админ системный" дополнительно умеет в отладку и написание патчей, субд, оптимизации, глубокие знания протоколов (чем больше тем круче). (упор на систему)
    "Админоархитект" по сравнению с обычным умеет грамотно строить инфраструктуры, в т.ч. для массового развёртывания и обновления. (упор на инфрастуктуру, систему серверов)
    Это грубо и коряво.
  • @solhov, [...про бардак с установкой стороннего поскипано...]

    обновление системы во фре перепроверять не надо — в stable его ломают исключительно редко. а для портов давно есть poudriere

    Систему — да. К базовой системе обычно претензий нет, но без всего остального она нахрен не сдалась со своим отдельным процессом обновлений.
    Хотя есть претензии к её монолитности, которые вполне себе совпадают с описанными в: groups.google.com — с тех времён практически ничего не изменилось.

    А вот порты... Наличие poudriere означает, что тебе придётся иметь билдхост под все пакеты, которые ставятся хотя бы на один сервер. Соответственно, все пакеты потребуется пересобирать. Это требует времени и внимания админа. Отсутствие poudriere — ещё бОльший геморрой для админа.
    Как я уже сказал, не вижу смысла пересобирать то, что не принесёт улучшений больше ошибки измерения.

    С бинарными пакетами несколько лучше, к pkgng как системе управления пакетами претензий нет. Могут быть к репозиториям, но тут уже проблемы не зависят от того, через как ставились пакеты.
  • @SolderStain,
    слака уже давно на slapt-get, во фре уже давно portmaster/portupgrade

    Вот про портапгрейд не надо вспоминать! Шаг вправо, шаг влево — геморрой был...
    Уж лучше собирать пакеты и ставить через pkg...

    походу это и есть основной камень преткновения. я собственно считаю ровно наоборот. самый надёжный пакет — собранный в твоём окружении.

    Только если у тебя есть достаточные ресурсы времени и своего внимания на это. Иначе — выбираешь, кому доверяешь и ставишь его пакеты. Ну или компромисс на тему "что дешевле". Да, ключевые пакеты я собираю. А вот накой мне собирать какой-нибудь dialog или системные утилиты, запускаемые один раз за ребут?

    "Админ обычный"

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

    "Админ системный"

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

    "Админоархитект"

    А это вообще отдельная специальность и водится больше в интеграторах... До неё редко кто дорастает в обычных предприятиях.
    Если дорастает — уже неинтересно копаться во внутренностях всего подряд. И обычно точно неинтересно тратить своё время на пересборку того, что может пересобрать кто-либо из предыдущих разновидностей или вообще мантейнер дистрибутива.
  • @stanislavv,
    Хотя есть претензии к её монолитности, которые вполне себе совпадают с описанными в: groups.google.com — с тех времён практически ничего не изменилось.

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

    А вот порты... Наличие poudriere означает, что тебе придётся иметь билдхост под все пакеты, которые ставятся хотя бы на один сервер. Соответственно, все пакеты потребуется пересобирать

    во-первых билдхост у тебя и так будет, если ты не хочешь его с кем-то совмещать (это возможно) — у тебя все равно будет свой собственный софт, не на своем же рабочем месте ты его собирать собрался?

    Это требует времени и внимания админа.

    не требует

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

    какая еще ошибка измерения? о чем ты? с кем ты споришь?
    poudriere позволяет тебе контролировать опции, с котрорыми пакеты собираются. к примеру, включить полный хинтнинг у fontconfig. или отрубить x11 для серверных пакетов. отрубиьть нахер cups. контролировать версии пакетов. накладывать свои патчи (FF у меня к примеру с патчем который его затыкает на тему ключей <1024 бит)

    Могут быть к репозиториям

    вот для этого poudriere и нужен
  • @solhov,
    там нет никаких внятных претензий, а пример с xorg особенно показателен — хотели как лучше, а получилось как всегда: при каждом чихе обновляется все xorgовое говно.

    Так... Понял, что не сумел сделать ссылку на нужное сообщение. Про xorg в том месте нихрена не было.

    цитирую:

    1. Единственный путь получить систему без каких-либо излишних
    компонент — самостоятельная пересборка с src.conf и инсталяция в
    новое место.

    минусы: попадая на так поставленную систему нельзя понять чего именно
    там нет и как нам ее повторить (последнее нужно в том случае, если
    проблема звучит как "все хорошо, но надо добавить XXX"

    2. единственный путь получить базовую систему с расширенной
    функциональностью — пересборка из сырцов, после чего опять же не
    сохраняется никакой информации о том, что за функционал расширен. вот
    многие ли в курсе, что sendmail нынче штатно собирается с поддержкой
    TLS?

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

    4. невозможность обновить пакет штатным обарзаом (т.е. просто с
    заменой файлов, но с сохранением REQUIRED_BY

    5. отсутствие в пакете инофрмации о дополнительных фичах (например
    apache с SSL, русским и еще три, например патча). не закодированным в
    имя! если мы кодируем в имя — зависимости начинаю завязываться на имя
    пакета и у нас получается куча гемора с тем, что есть апач с русским и
    ssl, а для одного пакета нужен апач с русски, другому — апач с ssl,
    но по именам их не удоволетворить нормально.

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

    7. как следствие — было бы полезно умение в зависмостях указать
    компонет системы с некоторыми свойствами (sendmail с поддержкой socket
    map, например)

    8. После самостоятельного обновления из сырцов хочется иметь
    возможность накатить бинарный апгрейд.
  • @stanislavv, 3,4,5 уже не актуально
    6,7 всё ещё хочется, но кажется вообще ни у кого нет

    я уже не помню конечно ту дискурсию, судя по тому часть пунктов меня цитируют, а часть — нет, это вероятно пост Vadim Goncharov?
  • @solhov, 6 — дебиан и его dpkg-divert. Извращение, но позволяет поменять файл в пакете.

    Нет, Slawa Olhovchenkov
  • @stanislavv, да? охренеть, уже и не помню что выдавал некоторые из этих формулировок.
  • @solhov, Бывает. Меня больше интересуют 1 и 2, для остального обычно можно найти обходной путь, кроме 8.

    Про ошибку измерения: берём tar и пересобираем с максимальной оптимизацией. С учётом того, что один хрен упрётся в диск/сеть — на сколько процентов улучшится время работы? И насколько изменится время работы, если просто перезагрузить и повторить?

    Ну а "не собирать с x11 для сервера" для меня, если честно, неактуально уже. С учётом того, что разработчики для тестов развёртывают и прибивают виртуалки/контейнеры по N раз на дню с разным составом софта — проще таки ставить из пакетов и хрен с ним, что ssh имеет зависимость от иксов и умеет их пробрасывать, libX11 занимает не так много места на диске по сравнению с теми данными, которые кладутся рядом...
    Тут ключевые слова "повторяемость" и "затраты на инфраструктуру", а не "кастомизируемость", к сожалению.
  • @stanislavv, 1,2 в полном виде кмк ни у кого не реализованно.
    в линуксах ты тоже не знашь что там отмечали в инсталяторе, когда ставили и что потом обновляли. нет, список установленных пакетов — это не то.

    для 8 достаточно что бы не было заблокированно "а теперь накатываем бинарные пакеты".

    Про ошибку измерения:

    еще раз, вот с кем ты тут споришь?

    что ssh имеет зависимость от иксов и умеет их пробрасывать

    на самом деле не имеет и пробрасывет без всякой libX11.

    ну хорошо, тебя не волнует что список пакетов на сервере (особенно после распиловки X11) не помещается в 100 экранов, но что делать если нужный тебе модуль в nginx не включили в дистрибутиве твоего линукса, а динамическим его еще не сделали?

    Тут ключевые слова "повторяемость" и "затраты на инфраструктуру"

    вот для этого и poudriere
  • @solhov,
    1,2 в полном виде кмк ни у кого не реализованно.

    Угу. В линуксе хотя и ближе, чем во фре, но тоже не то. Накладывает условия "все файлы из пакетов, всё конфигурилось только средствами системы". Если первое условие я могу обеспечить, то со вторым обычно облом.
    Но, хотя бы вне /etc можно определить какой бинарник к чему относится и откуда установлен его пакет, если первое соблюдено.

    для 8 достаточно что бы не было заблокированно "а теперь накатываем бинарные пакеты".

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

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

    на самом деле не имеет и пробрасывет без всякой libX11.

    А, это я с дебианом таки перепутал. Там оно рекомендует xauth и если ставить инсталлятором — ставит не спросясь.

    что делать если нужный тебе модуль в nginx не включили в дистрибутиве твоего линукса, а динамическим его еще не сделали?

    Вот этот случай и попадает под "сервис, ради которого ставится ось". Его и пересобирать так, как надо для работы. В пакет. Который вместе с его исходниками класть в местный репозиторий. Вероятно, в публичный, доступный по http.
  • @stanislavv,
    Гм... Поставили сервер хз когда и хз кто описанным методом. Как узнать, что там есть вообще? Без этого накатывать бинарные пакеты чревато, по-моему...

    ну вот как-то так, помедитировал, накатил, посмотрел на неприкаянных, накатил еще.

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

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

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

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

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

    Мда...
    Мне не настолько не лень...

    и все равно не поможет. проверочное действие: повторить то же самое в новой версии дистрибутива на другом железе.

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

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

    В лучшем случае — лог устанавливаемых пакетов + лог инсталлятора...

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

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

    а поскольку poudriere может жрать дерево портов по svn, то все твои патчи будут по возможности сохраняться и мержиться автоматом

    Только кошерный git :-)
    Впрочем, тут до лампочки, где именно лежат исходники, лишь бы это было достаточно удобно и надёжно.
  • @stanislavv,
    В репозиторий кладётся уже после того, как версия пакета была отлажена. Не собрана, а отлажена, иначе незачем собирать свою версию. И именно версия пакета, а не софта в нём, т.е. либо свои патчи, либо, как минимум, свои флаги конфигурации.
    Ну а так как для тестов требуется пакет — нахрена его пересобирать ещё раз ради выкладывания в репозиторий? Он уже собран как надо и это протестировано.
    При обновлении версии софта — аналогично.

    по-моему мы с тобой какие-то слова употребляем по-разному, потому что я тут вообще твоих переходов не понял
  • @solhov, poudriere — тулза для создания репозитория пересобранных пакетов для соответствующей фри. Так?
    Если да, то она не вписывается в техпроцесс разработки новых версий пакетов.
  • @stanislavv, poudriere — тулза, которая на вход берет список портов и может [опционально] дать тебе выбрать диалогово опции для них и потом выполнять пересборку портов с выбранными опциями по списку. "либо, как минимум, свои флаги конфигурации" — т.е.е как минимум один признак из твоих есть
  • @solhov, Значит, я ошибся и это не средство для создания своего репозитория бинарных пакетов (тогда что-то не то написано в 4.6.2 хендбука).

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

    P.S. чем-то мне напоминает альтовский hasher или дебиановский pbuilder, но, судя по документации, всё же умеет делать репозитории из собранного и не умеет собирать каждый отдельный пакет в чистом окружении.
  • @stanislavv, результат его работы — репозиторий, да.
    но он больше чем просто создание репы.
    тесты он тоже умеет запускать, если они в порте прописаны.
    пакеты он собирает в максимально чистом окружении (т.е. установлены только необходимые для пакета зависимости)
  • @solhov, Посмотрел, что там имелось ввиду. Не то. Невозможно провести хотя бы примерное тестирование сложного сервиса таким образом.
    У нас тестирование проводится путём установки на спец-сервер, где 1) пользователей немного, 2) они в курсе происходящего и не возражают. Там тот же nginx должен отработать хотя бы несколько дней без проблем перед тем, как попадёт в репозиторий.
  • @stanislavv,
    Там тот же nginx должен отработать хотя бы несколько дней без проблем перед тем, как попадёт в репозиторий.
    какой тип проблем вы пытаетесь так поймать?
  • @SolderStain, Проблемы встравиваемого в nginx lua и написанного на lua приложения (блокировка отдельных ддосеров + немного автоматики для антиддоса).
    Просто уже наступали на изменение поведения при смене версии nginx без смены версии lua и наоборот. Само приложение менятся в последнее время реже, чем версии nginx.
  • @stanislavv,
    и написанного на lua приложения
    что-то подобное я и предполагал.