Центосей расплодилось

CERN откопает Scientific Linux.

Нет, уже слишком поздно откапывать.

Не очень понимаю зачем трогать то, что работает. Это может быть интересно только тем, кому нравится процесс перестановки ОС. Ну и в случае CERN вопрос стоит не про сервера, а про сайты GRID. Разница в их количестве и необходимой однородности. А на локалхосте и на ноутбуке можно ставить всё что угодно. Я вон убунту предпочитаю.

Где говорится, что CERN выбрал стрим. А то ваши слова несколько похожи на трындёшь.

Не очень понятно нафига. Там и так всё стабильно. Правильный выбор — взять для работы тоже окружение. Разводить же стороннюю НЁХ — это напрашиваться на гарантированные дополнительные проблемы там, где их как бы и нет.

Где говорится, что CERN выбрал стрим. А то ваши слова несколько похожи на трындёшь.

Не трындёшь, а предположение основанное на их же словах:

CERN and Fermilab have been evaluating a number of options in view of the sudden change of end of life of CentOS Linux 8 in December 2020 and the move to Stream. A migration path for servers already running CentOS Linux 8 is being provided to CentOS Stream 8 for those needing this release and latest features.

Не очень понимаю зачем трогать то, что работает.

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

Не очень понимаю зачем трогать то, что работает.

Потому что у этого что-то должна быть поддержка и гарантии. Поддержка у CentOS 7 пока ещё есть и есть время сделать и обдумать дальнейшие шаги.

Сотрудники CERN’а и прочих Fermilab’ов должны заниматься наукой и не должны формировать отделы «мейнтейнеров» для разработки и поддержки их собственного дистрибутива или для латания дыр в CentOS 7 после того как завершится цикл его поддержки.

Ясно. То есть просто выдача рассмотрения одного из вынужденных вариантов за «решение». Основа всё равно CentOS 7, а 8ка просто будет деприкатед, пока не будет принято общее решение.

Ты не догоняешь. На CentOS 7 CERN будет сидеть до тех пор, пока это будет нужно для завершения текущего цикла обработки эксперимента (та самая наука). И если для этого будет нужно завести несколько человек для латания дыр, то это будет сделано. Определяющим здесь является собственный CERNовский цикл, а не какие-то там внешние календари.

Про это и думают. Раньше думали, что это будет CentOS 8, но Redhat всех обманула удивила. С другой стороны альтернатив уже достаточно, чтобы обойтись минимальной кровью.

Много букв для «ненужно».

Там и так всё стабильно.

В RHELе? Да, довольно-таки. От фиксов в glibc или ребэйза nss твой график далеко не уедет.

А вот только прткладной софт тоже замораживать надо. Можешь точно воспроизвести какую-нибудь свою теховскую документину из прошлого века?

А вот только прткладной софт тоже замораживать надо.

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

Да забудь про графики, вёрстку сможешь не поехать?

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

Какое это имеет отношения к воспроизводимым _научным_ результатам?

Научные хрупче.

Числа хрупче? Арифметика не воспроизводится? Если калибровки поменялись, то результат очевидно поедет, но ровно для того, на каждую калибровку накладывается свой уникальный тег. Используй их и будет тебе счастье, а если ты за этим делом не следишь (или не можешь это сделать по причине что следить нет возможности), то никакая стабилизация софта тебе не поможет.

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

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

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

Воспроизводимость нужна просто как мытье рук. Обидно потом ехать кукухой от тривиально избегаемых проблем. Буквально половина моих ежедневных рабочих проблем растут из того, что её сочли опциональным nice-to-have и построили домик с таким же как у тебя ковбойским оптимизмом.

Да не, это просто ты не в курсе как анализируются экспериментальные данные. Та самая физика. У тебя нет верного решения — асимптотика к нему находится в процессе анализа и поэтому в какой-то момент встаёт противоречие: воспроизводимость заведомо ложных результатов сделанных из ошибочных предположений или просто наиболее точные на сегодня результаты, которые гарантированно завтра придётся пересчитать. Выбор IMHO очевиден. Естественно вся эта полемика в пределах систематических неопределённостей. Если их каким-то чудом удастся задавить (ну или если выборка очень мала), то можно потребовать и воспроизводимости в пределах статистических погрешностей вестимо.

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

Да не, это просто ты не в курсе как анализируются экспериментальные данные. Та самая физика.

Забавная предъява.

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

Угу. Не раскидывать поверх неидеальной ситуации еще бонусных граблей.

Похоже у вас некоторое недопонимание по поводу «воспроизводимости». В случае 2+2 воспроизводимость должна быть независимо от версии софта (если это не так, то этот софт выставляется на мороз) и уж тем более от версии glibc. Некоторые нюансы касаются используемых датчиков случайных чисел и если псеводопоследовательность по какой-то причине поменялась, то результат в получении которого используется эта самая последовательность очевидно поменяется. Эта неопределённость подавляется за счёт использования настолько большего числа сэмплов моделируемых событий или эквивалентных сущностей, чтобы вклад в ответ был как минимум 1/3 от вклада событий реальных. Так же может что-то поменяться в случае изменения алгоритма поисков экстремумов какой-либо зависимости, но тут это на самом деле хороший звоночек на тему, что этот самый поиск является неустойчивым и с ним необходимо разобраться, а не заметать под ковёр «воспроизводимости».

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

Иными словами, если вы что-то делаете «на коленке» в пределах локалхоста, то необходимость «в стабильности софта» и уж тем более glibc отсутствует как класс. Ubuntu ничем не лучше/хуже Redhat или другого любимого вами дистрибутива GNU/Linux или, скажем, прости господи, Open VMS. Гнаться до точностей совпадения превышающие, скажем 1/10 от имеющихся неопределённостей смысла нет от слова совсем. Если что-то от смены версии glibc поплыло сильнее, то это 99.99% ошибка в пользовательской программе, а не в glibc и это повод для разбирательства.

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

Иными словами, если вы что-то делаете «на коленке» в пределах локалхоста, то необходимость «в стабильности софта» и уж тем более glibc отсутствует как класс.

А если от версии scipy? numpy? ROOT?

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

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

Ubuntu ничем не лучше/хуже Redhat

С точки зрения воспроизводимости или импотентности ПМ — да.

или другого любимого вами дистрибутива GNU/Linux

А вот тут ты не прав =) Небо и земля.

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

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

А если от версии scipy? numpy? ROOT?

Есть проблема: если сдвиги условно большие (скажем 10% от минимальной систематической неопределённости), то какая версия правильная? Никакая воспроизводимость не решает её. Безотносительно того, что скорее всего, если такое приключается, то значит анализ с вероятностью 99.99% неустойчив и должен быть пересмотрен, никто не мешает создавать релизы основных инструментов (благо они все свободны) наравне с релизами компиляторов и версии glibc. Ровно это в случае CERN и делается.

Это не хороший звоночек, это обычный вторник.

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

Небо и земля.

Актуальные root, python и emacs ставится на любой хоть сколько-нибудь современный дистрибутив GNU/Linux. Если у вас от подкладки 2+2 поменялась, то это вопрос скорее к вашему выбору софта или его не целевому использованию.

Ну давай так.

Возможно, новые проекты имеет смысл начать с учётом «передовых» инструментов, хотя, лично у меня, аллергия к единственно верным путям. Старые, уже устоявшиеся проекты, лучше не перетряхивать на инструментальном уровне без веских на то оснований. В частности та же ликвидация CentOS таким веским основанием не является, так как альтернатив (включая возрождение Scientific Linux CERN Edition) предостаточно.

Есть проблема: … какая версия правильная? Никакая воспроизводимость не решает её.

А еще не кормит голодных и не приносит мир во весь мир.

Если у вас от подкладки 2+2 поменялась, то это вопрос скорее к вашему выбору софта или его не целевому использованию.

Страус-mode engaged.

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

Так и мой совет был индивиду, а не бегемоту.

У вас просто старый frr

7.5-1.

Значит слишком новый) у нас в проде frr 7.4-1. А что за баг?

Не может быть. был 7.0 и 7.5 (oel 8.4). Не работает point-to-multipoint в ospf. Там попатчили point-to-point и первый отвалился, есть баг за ноябрь прошлого года. В 7.0 отваливается роутинг раз в минуту, то есть он теряет все роуты, и потом восстанавливает сам. Непонятно с чем связанно такое моргание, такой же конфиг без проблем завелся на дебиане (11-м) с 7.5.1. Правда там сломали libyang, но то другая история, и я его уже сам ручками попатчил и багрепорт написал

Попробуй https://aur.archlinux.org/cgit/aur.git/commit/?h=frr&id=a6032dcb812cd35f39cecc0273dd4629a2b2fa70

Вместо ОС предлагаешь ему sosistemd запилить?)

cocucka, пиши альфе, пусть поможет тебе в айбихэт устроиться. Будешь Поцтеринга подсиживать.

А потом мы его всем ЛОРом дружно хейтить будем. Это ли не мечта?

отличный план!

Отлично! Уже обновляю резюме. Можете уже начинать слегка похейчивать.

Зачем? я уже решил вопрос. Кстати, баг в дебиане пофиксили, я так понимаю пакет пока в сиде, ждем в тестинге.