> Просто если это надо в промышленных масштабах, в дебианообразных через пакетную систему
> можно сделать сие покультурнее, имхо.опишите, сравним.
> В общем случае ничем существенным не воздается а вот затраты труда обеспечивает.
затраты труда в чём состоят? кинуть нужный конфиг ядра и команду собрать?
> Реально нужно только в сильно некоторых, очень специфичных случаях.
да как бы встречается, тем не менее.
> А все нужное обычно и так есть в дефолтном ядре. Бывают исключения но их опять же едва ли 1% наберется.
опять-таки - встречалось.
> Кому нужно? Вам?
именно.
> А то вон гугл например наоборот уже работает по нему. Можете и IPv4 выключить, чтобы уж наверняка.
О, сэр учится на острослова?
> Тем более что отключить его можно и без перекомпила ядра.
Задача была не отключить. Выпилить. Совсем.
> Интересно, что за параметры такие. Вот так сходу даже придумать затрудняюсь что
> нельзя подкрутить через sysctl что нужно на практике и чисто hardcoded
> в ядре. Это бред какой-то: если параметр реально надо менять -
> с фига ли его нельзя настроить через sysctl?
бывает и так.
> У убунтуев есть свои патчи на ядро.
Странно. Вы им напомните про sysctl.
> Вот только они могут проделать намного больший объем тестирования нежели я. Поэтому лично я не горю желанием накладывать патчи самолично.
А sysctl в этом плане ничуть не безопаснее.
>> А тут опенсорс, тут могут и ядро собрать.
> Этот синдром называется "когда в руках молоток, все вокруг кажется гвоздями" ;).
Вам виднее, конечно. После конфигов через пакетный менеджер это более чем очевидно ;)
> Я вполне в состоянии собрать ядро, в том числе изменив параметры и запатчив.
верю
> Просто я понимаю что делать это долговременно и (полу)автоматически, в виде когда факапы исключены - это довольно большой объем работ.
(внимательно смотрит) так бывает, когда человек не разбирается в том, что технически способен сделать.
> Пока я из вышеперечисленного этой нужды в упор не вижу -
я могу описать только то, с чем имел дело, но именно это по определённым причинам не могу описать. Факт остаётся фактом - с такими вещами сталкивался, и наличие доп.возможностей сильно радовало.
> том вы даже не указали во сколько РАЗ выигрыш. Да, чтобы
> окупать все это прыгание - выигрыш просто обязан быть в РАЗЫ.
в каком-то случае это были требования, в каком-то возможность вернуть работоспособность при выросшей в 100 раз нагрузке.
> Фундаментальная проблема - в том что апстрим в общем случае понятия не имеет о вашем патче. Поэтому апстрим не парится вопросами совместимости с ним.
в каком месте это проблема?
> Это ваши проблемы как он там наложится и как все это будет потом работать. Проблема - на
> стыке апстрима и вас, она есть независимо от SB или BB.
она есть в вашей голове, гипотетически. Например, я работаю с патченым ядром. Прикладной софт пишут отдельные от меня и от апстрима граждане. Насколько известно апстрим не тестит ядро "под весь любой софт". Если я знаю, в чём заключается новый функционал или к чему приведёт изменение того или иного параметра - в чём проблема?
> В bb дебиане получить сорц любого пакета и всех зависимостей для его
> перестройки - вопрос едва ли пары команд. Как и запатчить/пересобрать.
озвучьте, плиз.
> Проблема в том что апстрим вовсе не обязан делать изменения в виде не приносящем проблем. А вот убедиться в том что проблем реально нет
Я вот никак всё не пойму. Либо у вас есть некое правило всё тестировать по определённой, очень сложной и всесторонней схеме, и вы уже замахались это делать после каждого изменения, либо у вас депеша от господа Б*га лично, что всё, что идёт в упаковке *.deb Он лично проверил на всех режимах и благословил.
>> Скажите Киса, как программист - программисту. Вы хоть раз вносили изменения в
>> чужой код?
> Да, вносил. И чего? В ситуации когда нечто крутится на боевом сервере, наложения кастомных патчей на это следует максимально избегать, из соображений минимизации административной работы и уменьшения риска факапов. А вы почему-то напротив считаете что это основной род деятельности.
Напротив. Кастомизацией приходится заниматься в случаях необходимости. Но хочется это делать не через опу-опу, а штатно.
> Виртуализация - отдельный специфичный случай. У виртуалок мало железа и оно заведомо
> известно, поэтому избыточно переть в виртуалку поддержку всего железа вообще. Не
> то чтобы дефолтное ядро там будет работать хуже, оно просто будет
> избыточным.
Т.е. виртуалка это лично ваша отдушина для технического онанизма.
> Как-то жирновато. Бывают конечно специфичные задачи типа эмбеддовок всяких, где например
> максимально урезанные ядра и самому собирать не зазорно, но там фрями
> вообще и не пахнет :P.
в общем-то - пахнет.
> Вас кто-то обидел?
Вас, милейший.
> ИМХО очень хорошо что мне не придется проделывать за них ту же самую работу + тестирование.
Опять 25. Команда Дебиана тестирует вашу конфигурацию на вашем железе? Нет. У вас с ними договор, по которому вы держите их железными перчатками за тестикулы? Нет. Тогда давайте закроем вопрос: у вас просто слепая вера в команду дебиана.
>> а как только админ фряхи - сразу детское "хочу и всё тут"?
> Именно! Ресурсы целой команды против ресурсов 1 или нескольких админов совершенно не
> сравнимы. А набирать такую же по силе команду - дорогое удовольствие.
Формально это так. Нет, не так. Команда пилит свои, широкие задачи. Местные спецы - свои, менее широкие. Да, они стОят дорого, дороже чем пяток хрюнделей, которые лепят по книжке и имеют вполне адекватную привычку не лезть туда, где не понимают. Но спецы экономят ресурсы и сильно. Ну если, конечно, они спецы. Попадались варианты "затюнингованых насмерть" ОС, в том числе с "фирменными патчами от админов датацентра", часть проблем с которыми решалась простым откатом на к дефолту: да, в этом смысле я понимаю о чём вы говорите.
> Вот яндексы и рамблеры кажется начали осознавать, что простому эксплуататору ядерного
> реактора совсем не нужна в здании конкретной АЭС целая команда из докторов наук которые проектируют реакторы с нуля.
яндексы и рамблеры ооочень большие конторы. размер конторы накладывает свои требования. я не в курсе их внутренней кухни, посему не могу сказать чего именно им так не хватало. Вполне возможно что в их случае действительно функциональнее убунтодебиан. Но из того, что изложил слоник-в-домене безоговорочно согласен только с виртуализацией. Претензии к портам для меня не только неубедительны - но и смешны. Повторюсь ещё раз: порты, как смешанная бинарно-сырцовая система умеет не менее, чем любой функциональный пакетный менеджер. Остальные аргументы я бы не взялся обсуждать, не зная тамошней "кухни".
> Да никак. Принимают и хорошо. Идеальный случай - это когда ничего патчить
> не надо. К нему надо стремиться всеми когтями и зубами. Что
> яндексы и рамблеры и делают, судя по всему.
когда идеальный, когда нет.
>>> Нет, если это надо - я не вижу никаких проблем это сделать. И даже оформить как +1
>>> пакет с еще одним видом ядра.
>> но это не геморрой, это нормальное решение, правда? в отличии от ШТАТНОЙ
>> установки кастомного ядра в недосистемах, правда?
> Прости, конечно, человек, но я не верю что ты сможешь за разумные
> сроки произвести внятные тесты стабильности своего самопала и качественное регрессионное
> тестирование. Такой вот я козел. Конечно есть любители действовать "на авось",
> ну и флаг им в руки ;).
Ну тут я спокоен. Дело, похоже из области религии, ну что тут поделаешь. Видимо, команда дебиана отчитывается перед тобой что они там тестят. Но лично я им доверяю менее, чем трём-четырём известным мне спецам, один из которых автор 16 патчей к ppp и сейчас, кстати, работает в рэмблере. И да, судя по не работающей в 2 релизах подряд empathy в нетбучной версии убунты есть подозрение что тестирование командами дебиан/убунты не ограничивается, захватывая толпы хомячков. Нет, я не питаю иллюзий относительно прочего опенсорса, но просто надо как-то... без иллюзий.
> Очень здорово когда часть работы делают за тебя другие ;).
Не вопрос, главное чтоб работодатель был в курсе, кого сношать, если что.
> Мы, мы. Просто хорошо когда шишки собирают те кому невмоготу до свежака
(вспоминает претензии к gcc во фре)
на вас, блин, не угодишь.
> Ну и на дебианообразных существование пакетов под разные архитектуры ничему не противоречит.
> И чего?
Да ничего. Лично мне кажется логичным сборка пакета на месте с имеющимися либами и нужными модулями, и нелогичным держать 100500 версий пакета.
> Да как сказать, имхо примерно один хрен получится. Вопрос предпочтений. Если заморачиваться
> серьезно, с пакетами гибче. Например можно перекрыть системный пакет своим, если
> оно вдруг станет надо.
это что-то из разряда специфики, которую другим не понять?
> Ну а на дебиане можно собрать пакет под нужные архитектуры и указать
> в зависимостях оного libmysql не менее энного и нжинкс не менее
> эмного. При попытке установить такой пакет из системных репов будет вкачен
> нжинкс (если его еще нету) и libmysql (если еще нету). При
> этом не придется самому следить за секурити фиксами нжинкса и libmysql.
т.е. до системы портов таки доросли в этом месте? :)
> В конечном итоге все придет к apt-get install mysuperduperpackage на каждом из
> серверов. Мне вообще не надо знать какая у него архитектура в
> этот момент, лишь бы пакет в репах был. Пакет может быть
> и всеархитектурным, например если там конфиги/скрипты/платформонезависимые данные.
хрен вас поймёшь. то вам компилятор мешает на сервере, то с радостными визгами мультилиб тащите.
>> после внесения изменений в порт всё ещё проще. Я представляю, как это реализовать
>> на Дебиане :) Ровно так же как и на фрев случае собственных бинарных пакетов:
>> т.е. фря умеет и так и так. И любой SB умеет и так и так. Так в чём тогда
>> преимущество убунты/дебиана?
> В том что
> 1) во первых, сам пакетный манагер явно более вменяемый, удобный и фичастый.
"всё равно армяне лучше, чем грузины"
"чем?!"
"чем грузины!"
из фич пока только подписи, всё.
> 2) в 99% случаев вообще нахрен не надо тратить время на пересборку
> чего либо.
Это в общем-то вопрос политический. допустима вообще сборка или нет, и сколько времени на это тратится и какого. такими темпами можно к фичам винды отнести "не тратится время на синхронизацию реп".
> 3) в том что нет никакого тупого и искусственного разделения на "базовую
> систему" и "все остальное". Все универсально и логично. Все и вся
> - пакет.
разделение совершенно логичное. со своими плюсами и минусами. к плюсам я отношу отсутсвие свалки "всё в /etc". например.
> Где-то больше, где-то меньше. Ты вот захоти проверить целостность файлов базовой системы - сколько у тебя будет прыжков?
Много.
> Мне то debsum в два счета доложит что, где и как. Для всех пакетов, что системы, что установленного софта.
И из сырцов поставленного - тоже? Круто. Это подразумевается, что сервер поломали, суммы не поправили?
> Просто и удобно. А ты как будешь в этом случае выкручиваться?
Не приходилось. На скомпрометированном серваке не суммы надо считать, нет. Файлуха развалилась - ну так тоже чуток поздно бальзам хлебать. А так - да, прикольно.
> Более того, gpg ключи и подписи более-менее гарантируют мне, что я получаю именно то что хотел, а не что попало и откуда попало. А у тебя в системе как это разруливается для различных частей оной?
порты по дефолту не подписываются
>> проблема в том, что система сборки из исходников (BSD это, или SB
>> линукс) заточена на такие ситуации.
> Я повторю, нормальные люди стараются чтобы это было исключением а не правилом.
(вспоминает нормальных людей) да нет
> Продакшн должен работать а не пересобираться постоянно.
система отправлена в продакшн и работает. если требуется некое обновление - оно делается. штатно. что значит "постоянно" - неясно. у тебя вообще есть понимание как оно всё в SB устроено?
> У некоторых похоже проблемы с пониманием этого момента. Расстановка приоритетов ИМХО неверна.
каких приоритетов? o_O ты про то, что люди не начинают биться в коматозе, узнав, что портапгрейт собирает из исходников? так это нормально. при чём тут приоритеты?
> Вы так говорите, как будто в продакшне главное не работа а постоянная
> пересборка, тудыть-растудыть. Вы явно путаете приоритеты, имхо.
как раз наоборот. вы так настаиваете на бинарных пакетах, как будто установка софта идёт круглосуточно и наперегонки. ну или у вас в продакшне 386SX.
>> Там где всё по стандарту - например на десктопе - там BB предпочтительнее. Но опять
>> таки лично я на десктопе предпочитаю преимущества BB сочетать с гибкостью SB,
>> т.е. DesktopBSD(PCBSD)/Calculate. чем оно хуже дебиана решительно не понимаю.
> Ну если тебе надо не десктоп юзать а постоянно полсистемы пересобирать (зачем?)
> - преимущества будут. А у меня вот при юзании десктопной системы
> нет цели пересобрать в ней все пакеты.
Алё, на палубе. У вас упала способность читать. Поднимите, плиз.
> никем не тестированная конфигурация, где все баги я
> буду сам ловить (и сам чинить, если пороха хватит).
ну это да, чёрти что получается. тестированная убунту куда как веселее: empathy нерабочая с рождения, баги чинит дедушка Мороз.
> А жаловаться придется в спортлото, поскольку остальные за мою криволапость и глюки специфичные для кастомной конфигурации не отвечают.
ну с убунтой куда как веселее. пишешь письмо дедушке Морозу, он, почесав репу говорит 1) у меня всё работает 2) попробуй обнови 3) попробуй снеси, поставь заново 4) пошёл нафиг, превед Виндовс. Удобно.
> поддержке железа и современных технологий типа виртуализации.
интенсивно нужная на десктопе фича. надо же запустить виртуалку с другой версией убунты, убедиться, что empathy так же успешно не работает и там.
> Не, не спорю, можно и самому софт собирать.
Я не мешаю разговаривать с самим собой, нет? Ну если способность читать ещё валяется на палубе, я повторюсь. На десктопе я предпочитаю бинарные пакеты, но хочу сохранить возможность ставить из исходников. Штатно. Без мучительных гримас. DesktopBSD пока не сдохла имела внушительный список бинарных пакетов. Но сдохла, так что можете кусать, PC-BSD можете обойти стороной - разрешаю. И да, для BSD софт пишут отдельно два марсианина, в репозитариях дебунты он размножается сам, урожай два раза в день, да.
> А по-моему с отрывом от реальности, при котором кажется что основная цель существования системы - это пересбор всего и вся,
Твои слова бы да б-гу в уши! Ведь не дают пересобирать всё и вся! в Calculate вон бинарный профиль, гады, всунули. В генте... ну стоит на домашнем сервачке, за последние пару недель только busybox да таймзоны обновились... не те уже SB, не те. Надо бы мне 386SX прикупить, а то получается ты фигню сморозил.
Вариант для распечатки
