Вышла FreeBSD 9.2

Где я сказал, что это плохо?

Ну если не плохо, то собственно и спорить тогда не о чем.

Почему тебе хотелось бы видеть FreeBSD мертвой?

Ну с чего это ты взял? Мне нравится FreeBSD, я пользовался ей несколько лет назад.

Почему фанатики не умеют радоваться победам своего фетиша, а не недостаткам, часто выдуманным, «конкурента», который с ними даже не воюет?

Не знаю, я не фанатик и у меня нет фетиша. Но тоже частенько задаю себе этот вопрос.

Администраторам стало удобнее поднимать свои локальные хранилища пакетов и поддерживать собственные билды.

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

Ядро и окружение составляют общую основу всех дистрибутивов GNU/Linux.

Также как GCC и binutils, Gnome и KDE.

GCC - едва ли основа, по крайней мере бинарных дистрибутивов. И уж тем более GNOME и KDE.

Я говорю только и исключительно в рамках сравнения FreeBSD и GNU/Linux. «FreeBSD — это не дистрибутив чего-то ещё, это original work. Как и ядро Linux, на базе которого, используя стороннее ПО GNU и прочие сторонние original work, собирают с миру по нитке дистрибутив GNU/Linux».

Не совсем понятно только, к чему вы приводите эти очевидные факты.

Админ, который безоговорочно верит вендору и не тестирует перед внедрением — ССЗБ. Он профнепригоден.

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

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

Повторю: это проблемы любого роллинг релиза. То есть любой живой среды.

Это очевидно. Вопрос в том, зачем rolling на сервере, и перевешивают ли какие-то его преимущества данные недостатки.

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

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

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

вот для дебиана решить такую проблему немного трудно, пример: Steam и Debian Wheezy с тестинга подтянуть стим и он не запускается, а для пользователя надо новая версия стима, да и так надо наиграться с таким случаем в Debian.

Вы не ничего поняли из того, что написано в той теме. Если бы автор просто поставил Steam из testing, никаких проблем бы не было. Он же решил его пересобрать для stable, что в условиях отсутствия исходников и неподходящей версии glibc несколько затруднительно.

Это вы не поняли

я почитал новость про дебиан 8

Для исключения ситуации излишнего растягивания процесса подготовки релиза будут изменены правила поддержания пакетов в состоянии заморозки. Например, после трёх месяцев заморозки будет запрещён процесс возвращения в ветку testing удалённых пакетов; исправления важных ошибок (класс «important») в пакетах категорий «optional» и «extra» будут допускаться только в первый месяц после заморозки, далее будут исправляться только ошибки критичные для релиза (RC);

уже толком и тестировать в дебиане не будут, устали. А так да невозможно давать гарантии на работу ПО в любом компьютере, помню читал книгу «Искусство отладки» Метт Телес писал что основная проблема разработчиков это ответ «А на моем компьютере все работает нормально!»

Вы не ничего поняли из того, что написано в той теме. Если бы автор просто поставил Steam из testing, никаких проблем бы не было. Он же решил его пересобрать для stable, что в условиях отсутствия исходников и неподходящей версии glibc несколько затруднительно.

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

уже толком и тестировать в дебиане не будут, устали.

Это называется «толком тестировать не будут»?!

Все ошибки в Debian разделяются по категориям важности: wishlist, minor, normal, important, serious, grave, critical. Последние три являются RC (Release-Critical), пакеты с которыми в релиз не попадут. Так как исправить вообще все ошибки невозможно, в период «заморозки» концентрируются на самых важных ошибках, а остальные должны исправляться до «заморозки», благо времени на это с лихвой.

Что изменилось: wheezy провёл в «заморозке» слишком много времени (месяцев 9 где-то) из-за огромного количества серьёзных ошибок, поэтому было принято решение ужесточить правила приёма пакетов в testing, чтобы он всегда был почти готов к релизу. Дело в том, что ранее в самом начале новой ветки testing количество ошибок всех уровней всё накапливалось и зашкаливало, и только ближе к «заморозке» с ними потихоньку начинали разбираться; теперь же пакеты с серьёзными ошибками долго в testing не задержатся, и это заставит сопровождающих, если они хотят, чтобы их пакет попал в релиз, не откладывать исправление ошибок до «заморозки», а действовать сразу, что сделает распределение нагрузки более равномерным по времени, а заодно и позволит сократить время «заморозки», ибо придётся иметь дело с гораздо меньшим количеством ошибок.

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

Вы забыли перевести на русский, а на языке потока мыслей я не говорю, к сожалению.

Ну если не плохо, то собственно и спорить тогда не о чем.

Я с самого начала не спорил. Лишь уточнил по поводу «экосистемы» BSD, каких-то домыслов про переписывание той же BSD, размышлений про отличия FreeBSD от GNU/Linux.

Ну с чего это ты взял?

Наверное мне показалось после фраз о «загибании» FreeBSD, которую «скоро и не вспомнят».

Не совсем понятно только, к чему вы приводите эти очевидные факты.

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

Но если пакет уже прошёл тестирование … вероятность проблем с ним очень невелика.

Настоящего админа чужие УМВР не устраивают. Они точно тестировали на аналогичном железе с тем же набором ПО и той же нагрузкой?

Заниматься же сборкой там, где в этом нет необходимости - лишняя трата ресурсов

И я снова с тобой соглашусь. Надо советовать открыть для себя бинарные пакеты?

Вопрос в том, зачем rolling на сервере, и перевешивают ли какие-то его преимущества данные недостатки.

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

фигасе у вас тут бсдсрач! живенько...

да нет это рефлекс такой, только напиши FreeBSD и [img]http://lurkmore.so/images/thumb/e/e4/Freebsd_hw.jpg/180px-Freebsd_hw.jpg[/img] да нет это рефлекс такой, только напиши FreeBSD

Вялотекущий какой-то :3

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

Да всё просто: если вы приводите какие-то факты, естественно предположить, что это несёт какой-то смысл, соответствующий теме разговора, заключающейся в сравнении FreeBSD и GNU/Linux. Так как вы BSD'шник, то вероятно, что сравнение FreeBSD и GNU/Linux подразумевается не в пользу последнего. Можно легко найти вероятную интерпретацию ваших слов, подходящую под это предположение. Вот с ней я и спорил. И не только я, заметьте. Просто нам, видимо, представлялось маловероятным, что вы просто излагаете общеизвестные факты без особой цели.

Но если пакет уже прошёл тестирование … вероятность проблем с ним очень невелика.

Настоящего админа чужие УМВР не устраивают. Они точно тестировали на аналогичном железе с тем же набором ПО и той же нагрузкой?

За многоточием скрыт важный нюанс, который позволяет по-иному взглянуть на вопрос:

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

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

Надо советовать открыть для себя бинарные пакеты?

pkgng - это, конечно, шаг в правильном направлении. Посмотрим, как оно будет дальше.

Вопрос в том, зачем rolling на сервере, и перевешивают ли какие-то его преимущества данные недостатки.

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

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

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

Хотя соглашусь, что в данном случае преимущество «замороженности» не так очевидно.

потому что все друг другу уже все доказали =) хотя, очередная новость о freebsd спровоцирует абсолюто аналогичное...

Ага, так доказали что каждый остался при своём. Бессмыслица.
А 10тка выйдет со шлангом и годным пакетником, так что думаю да, постов на 500 может что выйдет.

я с нетерпением жду 10-ку из-за USB Audio 2.0
X-fi наконец-то заработает не хуже, чем в линуксе. Да и другие вещи радуют...

вероятно, что сравнение FreeBSD и GNU/Linux подразумевается не в пользу последнего

Понятно: комплексы и «лучшая защита — нападение».

За многоточием скрыт важный нюанс

За многоточием скрыт момент, который никак не должен влиять на политику обновления ПО в компании. В конце концов #define true false — тоже «минимальные изменения по сравнению с уже работающей версией».

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

Админ с такими идеями вылетает с работы с волчьим билетом. «Мы только привели memcpy в соответствие с маном…». Нахрен-нахрен.

Справедливости ради, далеко не везде ведётся какая-то разработка.

Я не видел ни одной более или менее крупной компании, в которой отдел IT не занимался бы хотя бы одним in-house проектом. И во всех была зафиксирована на бумаге политика обновления ПО.

Понятно: комплексы и «лучшая защита — нападение».

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

В конце концов #define true false— тоже «минимальные изменения по сравнению с уже работающей версией».

Хватит заниматься буквоедством. Изменения, имеющие минимальную область влияния - так понятнее?

Админ с такими идеями вылетает с работы с волчьим билетом.

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

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

Понятно: комплексы и «лучшая защита — нападение».

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

В конце концов #define true false— тоже «минимальные изменения по сравнению с уже работающей версией».

Хватит заниматься буквоедством. Изменения, имеющие минимальную область влияния - так понятнее?

Админ с такими идеями вылетает с работы с волчьим билетом.

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

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

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

вам всё понятно, и вы запросто определяете подсознательные мотивы

Зачем, если человек сам признает, что спорил с собственными фантазиями? :)

Изменения, имеющие минимальную область влияния - так понятнее?

У админа нет достаточной компетенции, чтобы определить, как повлияет исправление бага где-нибудь в pam на работу всего комплекса ПО. Разработчики очень часто неосознанно полагаются на недокументированное поведение, пример с memcpy ты зря игнорируешь: исправили баг, функция полностью соответствует документации, но такой облом.

Если админ не проводит оценку рисков и занимается … тестированием обновления, которое уже протестировано вендором

Оценками рисков пусть занимается тот, кому положено. Админ берет сковородку в виде перечня инструкций и прикрывает ей жопу. Не использовать такой удобный инструмент — это и есть недостаточно оценить риски. «Вендору нельзя доверять целиком» записано потом и остатками вазелина.

У админа нет достаточной компетенции, чтобы определить, как повлияет исправление бага где-нибудь в pam на работу всего комплекса ПО.

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

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

пример с memcpy ты зря игнорируешь: исправили баг, функция полностью соответствует документации, но такой облом.

На практике такое не попадалось, и статистики нет, но это должно ловиться ещё на этапе тестирования вендором.

У меня почему-то всё яснее вырисовывается ощущение, что мы говорим в принципе об одних и тех же вещах.

У меня почему-то всё яснее вырисовывается ощущение, что мы говорим в принципе об одних и тех же вещах.

Вы еще в десны чмокнитесь

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

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

Вы еще в десны чмокнитесь

Странные у вас фантазии...

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

Рассуждения дилетанта. Вы, наверное, считаете, что вероятность встретить слона на улице равна 0,5: либо встретишь, либо нет.

Хорошо, попробую объяснить «на пальцах». (Вероятность поиметь проблемы) = (вероятность допущения и необнаружения ошибки разработчиком) * (вероятность необнаружения ошибки вендором) * (вероятность необнаружения проблемы админом). Если практикуется схема «сам себе вендор», то второй множитель равен единице; если же вендор есть, то данная случайная величина поддаётся статистической оценке и на практике ближе к нулю, что уменьшает риск в разы.

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

Анонимус выступает за бан reprimand