[del]
>> дебиан нетинсталла, который будучи забутявленым (в идеале по чему-то типа PXE?)
> Я знаю методы решения этой задачи. И знаю, как решить проще на
> фре, и как проще на линуксе. Мне непонятно разделение: методы решения
> под фрю - геморрой, под дебиан - так и надо.Просто если это надо в промышленных масштабах, в дебианообразных через пакетную систему можно сделать сие покультурнее, имхо.
>> А давайте по полочкам?
>> 1) Зачем надо кастомное ядро?
> выкинуть ненужный функционал,
В общем случае ничем существенным не воздается а вот затраты труда обеспечивает. Реально нужно только в сильно некоторых, очень специфичных случаях. В 99% случаев это просто ничем не оправданный технологический онанизм, уж извините.
> втащить нужный.
А все нужное обычно и так есть в дефолтном ядре. Бывают исключения но их опять же едва ли 1% наберется.
> например обязательно нужно выпилить IPv6.
Кому нужно? Вам? А то вон гугл например наоборот уже работает по нему. Можете и IPv4 выключить, чтобы уж наверняка. Тем более что отключить его можно и без перекомпила ядра. Если вы маны совсем уж не любите читать - конечно можно и перекомпиляцией его вырубить, только это довольно странный и геморройный метод, имхо.
> или специализация сервера такова, что некоторые ядерные ресурсы нужно задрать или
> наоборот, порезать.
Интересно, что за параметры такие. Вот так сходу даже придумать затрудняюсь что нельзя подкрутить через sysctl что нужно на практике и чисто hardcoded в ядре. Это бред какой-то: если параметр реально надо менять - с фига ли его нельзя настроить через sysctl?
>> Стоковое что-то делает сильно плохо?
> иногда - да. или патчи на ядро, по-вашему, присылаются марсианами в зависимости
> от фаз Фобоса и Деймоса? Или вы не в курсе, что не все пользуются ванильным ядром
> и набор патчей разный?
У убунтуев есть свои патчи на ядро. Вот только они могут проделать намного больший объем тестирования нежели я. Поэтому лично я не горю желанием накладывать патчи самолично. Потому что потом все это майнтайнить, следить чтобы ничего не отвалилось и тестировать как сие работает - прорва работы.
>> Настолько, что трах с самоличной пересборкой каждой новой версии
> Уважаемый, вам надо использовать MS Server 2008.
Не, не надо, спасибо. Я умею это админить, но предпочитаю по возможности держаться от этого подальше. В плане удобства администрирования это полный ахтунг. Если вы такой умный - поадминьте Win2008 server core, чтобы оценить по полной ;)
> А тут опенсорс, тут могут и ядро собрать.
Этот синдром называется "когда в руках молоток, все вокруг кажется гвоздями" ;). Могут != обязаны. Я вполне в состоянии собрать ядро, в том числе изменив параметры и запатчив. Просто я понимаю что делать это долговременно и (полу)автоматически, в виде когда факапы исключены - это довольно большой объем работ. Поэтому их надо избегать без какой-то реальной нужды. Пока я из вышеперечисленного этой нужды в упор не вижу - некие высосанные из пальца предлоги пострадать фигней с "типа оптимизацией", при том вы даже не указали во сколько РАЗ выигрыш. Да, чтобы окупать все это прыгание - выигрыш просто обязан быть в РАЗЫ.
>> с секурити фиксами
> Легко. Вам, упёртому, тут объясняют, что за то и ценится SB, что
> сборка кастомного ядра софта ВООБЩЕ не является проблемой.
Как бы это сказать? Фундаментальная проблема - в том что апстрим в общем случае понятия не имеет о вашем патче. Поэтому апстрим не парится вопросами совместимости с ним. Это ваши проблемы как он там наложится и как все это будет потом работать. Проблема - на стыке апстрима и вас, она есть независимо от SB или BB.
> Включая ядро. И что именно ЭТОГО в BB не хватает.
В bb дебиане получить сорц любого пакета и всех зависимостей для его перестройки - вопрос едва ли пары команд. Как и запатчить/пересобрать. Проблема не в том. Проблема в том что апстрим вовсе не обязан делать изменения в виде не приносящем проблем. А вот убедиться в том что проблем реально нет - это уже довольно большая административная задача. Которую по возможности стоит избегать, имхо. Хотя как известно, "бешеной кобыле и 7 верст - не крюк".
> Скажите Киса, как программист - программисту. Вы хоть раз вносили изменения в
> чужой код?
Да, вносил. И чего? В ситуации когда нечто крутится на боевом сервере, наложения кастомных патчей на это следует максимально избегать, из соображений минимизации административной работы и уменьшения риска факапов. А вы почему-то напротив считаете что это основной род деятельности.
>> Тем паче что у убунтов есть несколько ядер под типовые задачи
> Странно. Чуть выше вы удивлялись, как это дефолтное ядро может что-то делать
> недостаточно хорошо.
Виртуализация - отдельный специфичный случай. У виртуалок мало железа и оно заведомо известно, поэтому избыточно переть в виртуалку поддержку всего железа вообще. Не то чтобы дефолтное ядро там будет работать хуже, оно просто будет избыточным. Грубо говоря, майнтайнеры проделали работу по урезанию осетра за задротов которые вечно хотят что-то откусить в ядре для одной популярной ситуации. Поскольку гемор не у меня а у майнтайнеров - я могу только порадоваться этому факту :)
> быть достаточно для каждого.
Как-то жирновато. Бывают конечно специфичные задачи типа эмбеддовок всяких, где например максимально урезанные ядра и самому собирать не зазорно, но там фрями вообще и не пахнет :P.
> это след от мужских обид... :)
Вас кто-то обидел?
>> <b>рациональная цель</b> а не детское "хочу и все тут".
> в смысле как только "параметрами щёлкает" команда убунты, так сразу это "рациональная цель",
Вообще - да, щелкание обычно имеет какую-то рациональную цель. Про виртуализацию см.выше. ИМХО очень хорошо что мне не придется проделывать за них ту же самую работу + тестирование. Виртуализация все-таки довольно типичный сценарий (кто не отпустил ручник - сам виноват).
> а как только админ фряхи - сразу детское "хочу и всё тут"?
Именно! Ресурсы целой команды против ресурсов 1 или нескольких админов совершенно не сравнимы. А набирать такую же по силе команду - дорогое удовольствие. Вот яндексы и рамблеры кажется начали осознавать, что простому эксплуататору ядерного реактора совсем не нужна в здании конкретной АЭС целая команда из докторов наук которые проектируют реакторы с нуля.
> а если патчи на ядро от этого чела принимают в апстрим - как быть?
Да никак. Принимают и хорошо. Идеальный случай - это когда ничего патчить не надо. К нему надо стремиться всеми когтями и зубами. Что яндексы и рамблеры и делают, судя по всему.
>> Нет, если это надо - я не вижу никаких проблем это сделать. И даже оформить как +1
>> пакет с еще одним видом ядра.
> но это не геморрой, это нормальное решение, правда? в отличии от ШТАТНОЙ
> установки кастомного ядра в недосистемах, правда?
Прости, конечно, человек, но я не верю что ты сможешь за разумные сроки произвести внятные тесты стабильности своего самопала и качественное регрессионное тестирование. Такой вот я козел. Конечно есть любители действовать "на авось", ну и флаг им в руки ;).
>> делают же. Чем остальные хуже? Но я бы этого избегал, из соображений что это куча
>> работы которая сильно пригрузит достаточно квалифицированых специалистов на
>> существенное время (==дорогое удовольствие для компании).
> повторю вопрос: вы когда-нибудь вносили изменения в чужой код?
Да. И и даже собирал кастомные кернелы. И даже представляю себе объем работ потребных для того чтобы оттестировать кастомные патчи. И даже видел какие бывают прикольные баги от безбашенно наложенных патчей. Поэтому - извини конечно, но я, будучи ленивым, совсем не хочу взваливать на себя майнтайнерские обязанности без реальной на то нужды. Очень здорово когда часть работы делают за тебя другие ;).
>> И вообще, одно дело когда толпа хомяков баги вытопчет
> это да. и ядро и софт из репозитариев - это не вы
> толпа хомяков, вытаптывающих баги, да?
Мы, мы. Просто хорошо когда шишки собирают те кому невмоготу до свежака (у таких обычно нет продакшна критичного к завалу). Я иногда таковым тоже бываю, в случае когда я морально готов к тому что оно может оскорбить соседа и съесть его собаку и согласен на такой результат.
> Ни в каком месте с ними проблемы нет. Пишется отдельный порт и
> раздаётся на сервера с разной архитектурой.
Ну и на дебианообразных существование пакетов под разные архитектуры ничему не противоречит. И чего?
[del]
> Симметрично. И кстати, если где-то нгинкс собирается с разными модулями и вдобавок
> один и тот же самописный - так проще, верно?
Да как сказать, имхо примерно один хрен получится. Вопрос предпочтений. Если заморачиваться серьезно, с пакетами гибче. Например можно перекрыть системный пакет своим, если оно вдруг станет надо.
>> Не вижу как пакетная система дебиана мешает этому начинанию и чего там такого
>> некультурного, мешающего людям жить.
> никак не помогает. в SB такой расклад явно проще и логичнее, ИМХО.
> смотрим сами. есть 3 сервера. на них надо накатить модуль к
> nginx, использующим, например libmysql. на всех трёх разные версии мускуля, архитектура
> где i386, где amd64. на SB это решается установкой из порта.
Ну а на дебиане можно собрать пакет под нужные архитектуры и указать в зависимостях оного libmysql не менее энного и нжинкс не менее эмного. При попытке установить такой пакет из системных репов будет вкачен нжинкс (если его еще нету) и libmysql (если еще нету). При этом не придется самому следить за секурити фиксами нжинкса и libmysql.
> типа deploy <список серверов>, который пихает команды по ssh. это быстрее
> и удобнее BB дистра, любого. Не так ли?
В конечном итоге все придет к apt-get install mysuperduperpackage на каждом из серверов. Мне вообще не надо знать какая у него архитектура в этот момент, лишь бы пакет в репах был. Пакет может быть и всеархитектурным, например если там конфиги/скрипты/платформонезависимые данные.
> после внесения изменений в порт всё ещё проще. Я представляю, как это реализовать
> на Дебиане :) Ровно так же как и на фрев случае собственных бинарных пакетов:
> т.е. фря умеет и так и так. И любой SB умеет и так и так. Так в чём тогда
> преимущество убунты/дебиана?
В том что
1) во первых, сам пакетный манагер явно более вменяемый, удобный и фичастый.
2) в 99% случаев вообще нахрен не надо тратить время на пересборку чего либо.
3) в том что нет никакого тупого и искусственного разделения на "базовую систему" и "все остальное". Все универсально и логично. Все и вся - пакет.
> да можно. только прыжков будет больше.
Где-то больше, где-то меньше. Ты вот захоти проверить целостность файлов базовой системы - сколько у тебя будет прыжков? Мне то debsum в два счета доложит что, где и как. Для всех пакетов, что системы, что установленного софта. Просто и удобно. А ты как будешь в этом случае выкручиваться? Более того, gpg ключи и подписи более-менее гарантируют мне что я получаю именно то что хотел, а не что попало и откуда попало. А у тебя в системе как это разруливается для различных частей оной?
>> мне кажется что единственной проблемой является то что "это делается не
>> так как в привычной BSD".
> проблема в том, что система сборки из исходников (BSD это, или SB
> линукс) заточена на такие ситуации.
Я повторю, нормальные люди стараются чтобы это было исключением а не правилом. Продакшн должен работать а не пересобираться постоянно. У некоторых похоже проблемы с пониманием этого момента. Расстановка приоритетов ИМХО неверна.
> BB можно заставить делать то же самое, и в принципе, если есть другой профит,
> возможно имеет смысл напрячься. Но другого профита лично я - не вижу. Т.е. там
> где гибкость нужнее - имеет смысл SB.
Вы так говорите, как будто в продакшне главное не работа а постоянная пересборка, тудыть-растудыть. Вы явно путаете приоритеты, имхо.
> Там где всё по стандарту - например на десктопе - там BB предпочтительнее. Но опять
> таки лично я на десктопе предпочитаю преимущества BB сочетать с гибкостью SB,
> т.е. DesktopBSD(PCBSD)/Calculate. чем оно хуже дебиана решительно не понимаю.
Ну если тебе надо не десктоп юзать а постоянно полсистемы пересобирать (зачем?) - преимущества будут. А у меня вот при юзании десктопной системы нет цели пересобрать в ней все пакеты. Времени надо дохрена, результат почти ноль + никем не тестированная конфигурация, где все баги я буду сам ловить (и сам чинить, если пороха хватит). А жаловаться придется в спортлото, поскольку остальные за мою криволапость и глюки специфичные для кастомной конфигурации не отвечают. А оно мне надо? Если бы я хотел майнтайнить свой дистр - я бы давно это делал, только не для 1 локалхоста (ибо маразм). Кому надо - флаг им в руки. Ну а популярность вполне себе показывает расклад сил и предпочтений. Чем хуже DesktopBSD? Да тем что софта под нее с гулькин нос, и готовые пакеты под этот пепелац ни один придурок не собирает (а это не они ли все либы в свои пакеты валят? Так и представляю себе все кеды в комплекте к кедовой программе). А бсдевое ядро как "бонус" обеспечит отставание в поддержке железа и современных технологий типа виртуализации. Не вижу реалистичного юзкейса. Не, не спорю, можно и самому софт собирать. Просто чем больше данной деятельности - тем меньше похоже на юзеж и больше на какую-то майнтайнерскую деятельность без особых причин и внятных целей. А это довольно странно и глупо.
> выберем другое, какие проблемы.
Ну попробуй выбери. А чтоб было размером с кредитную карту и без вентиляторов, например - слабо? А то в современном мире компьютер вовсе не обязан быть гробом которым можно зашибить :)
>>> Непонятно с чего вы взяли, что FreeBSD исключение.
>> С того что у бсдшников какие-то свои, очень специфичные понятия о отсутствии геморроя.
> Связаны они исключительно с отсутствием убеждения, что всё, что не убунта/дебиан всё
> очень, очень плохо.
А по-моему с отрывом от реальности, при котором кажется что основная цель существования системы - это пересбор всего и вся, а юзер - это такой закамуфлированный майнтайнер.
