вот просто так вот. Как в винде.

В Винде не всё так просто. В 21H2 так тормозит проводник на HDD.. А наследующий день к «новембри» вышло накопительное обновление 🤭

И в который раз: либа в стриме не может отличаться от либы в RHEL. Они буквально собираются из одного git-коммита с точностью до хеша в одно и тоже время.

Означает ли это, что пакет packagename версии 1.2.3, попав в CentOS Stream, обязательно затем попадёт в RHEL? А если до попадания в RHEL в нём найдут уязвимость? Если нет, то в среднем CentOS Stream более уязвим, чем RHEL.

Любой дистрибутив с бинарями подходит под твоё описание.

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

Ну или вот рхел 8 получается бинарно совместима с рхел 7?

Бинарная совместимость это возможность работы софта скомпилированного под систему Х на системе Y, тогда Y бинарно совместима с X. Всё.

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

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

Но тут уже надо учитывать специфику стабильного дистрибутива и схемы разработки.

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

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

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

Наконец-то. Умер. Hallelujah.

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

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

Да можно наверное, почему нет. Можно и репу таким образом смастерить, можно на целевой системе с помощью dnf versionlock зафиксировать версии.

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

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

«good night sweet prince»

Можно получить список релизнутых в рхеле пакетов (хэши патчей или номера версий - не важно), а потом выкачать их из репозитория цэнтоси? Удаляется ли из репозитория центоси старая версия пакета после релиза новой версии, или при установке можно указать любую историческую версию?

Правда если ты умеешь такие вещи

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

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

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

Можно получить список релизнутых в рхеле пакетов (хэши патчей или номера версий - не важно)

Можно. По той же девелоперской подписке например.

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

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

собственно и в релизном RHEL тоже бывают баги

Не удержался. Вы хоть одну безглючную софтинку видели? Вопрос исключительно импакта и критичности (взаимосвязанные сущности), «я щитаю».

И кого с кем она должна совмещать.

В новой версии библиотеки может поменяться api. Так было много раз.

+1. Ну есть все таки практики у нас, а я уж думал только одни теоретики - админы локалхостов.

Что ж, выпьем не чокаясь.

Братка, я не большинство анонимусов, ты меня знаешь.

Ну вот скажи мне - ты epel или elrepo, ну или RPMFusion, или Remi и.т.д. по списку, подключаешь ведь?

Тогда про какую совместимость идёт речь? Ну я то параноик, но ты похоже не далеко ушёл от меня :)

А OS/2 помнишь же? :)

Я забил и работаю вот на новом компьютере в CentOS Stream 8 + EPEL + RPMFusion. Где у меня уязвимость?

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

+1 к bookwar.

То что я не теоретик, ты тоже знаешь. Но я помню как у меня обновился Scientific Linux на 7.3 с 7.2, и я сидел с глюками, в логах всё было замечательно, хотя я баг на RHBZ вешал, до 7.4.

Зато книжек за пол года перечитал :) А в Stream это грозит максимум на неделю, но не на пол года. Вот что bookwar тут старается до всех донести. А её никто не понимает, ну почти :)

PS: bookwar, на всех анонимусов не надо тянуть :)

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

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

Молодёжь то тут старая уже вся. Надо новые способы искать.

Без обид. Я про теоретиков в смысле админов-локал хостов. Которые сроду не админили кучу пролиантов в том числе и очень старых. И когда ты читаешь релиз-нотес на очередной RHEL X.y и список что выкинули из старого оборудования и что поменяли.

Это еще хорошо когда выкидывают что то и дают замену, приходится читать и все перенастраивать а если просто выкидывают ?

Тому кто ни разу ни юзал экзотические железки типа какой нибудь платы Е1 или очередного хв-контролера это не понять. И исходники его собираются только с версии RHEL X.Y а в RHEL X.Y+1 уже облом :(

Давай я с козырей сразу пойду? Ладненько? А то там всякие зелёные нубы с тобой пытаются общаться, а они маленькие, не опытные совсем.

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

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

Восславим же debian и ubuntu.

Да нету уже центоси, успокойтесь вы. Есть релиз-кандидат рхела. Не нравится - есть оракл линукс и другие варианты.

Братка, да я не обидчивый, ты знаешь :)

А тебя прекрасно понял.

Сам вот даже это, на экзотике пишу, хотя и современной. Которая не должна на 4.18 ядре работать с FHD монитором. Но почитал чэйнджлог на RHEL 8.3 и понял что под процессоры Renoir пропатчили.

Вот не поверишь, но я 9 месяцев на Убанде от космонавта работал с ядрами 5.8.0 HWE и 5.11.0 HWE. А как я к тем, кто Убандой пользуется, относился - ты знаешь :)

Я тебя понял прекрасно. Вы просто с bookwar не на одной волне разговариваете тут.

А нам понятно всё. Но я всё же выбрал CentOS Stream 8 и всё работает. И как-то, мне, посты bookwar внушают доверие. Сам знаешь сколько лет в одной комнате jabber просидели.

PS: У тебя Jabber аккаунт остался, кстати? А то я сейчас в комнате с таким же почти названием, только .ru, но на jabber.de сервере сижу. Ник мой тот же. Нас пока там мало, но адекваты, надумаешь - заходи, вход свободный. Pidgin сейчас тоже хорошо допилили, если не считать того, что не выкинули лишние пртокола, в CentOS 8.х он есть, в основных репах.

Ну так и надо его своими словами называть, а не вводить людей в заблуждение.

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

Ну т.е. раньше CentOS немного (дни, иногда недели) отставал от RHEL, и пользователи последнего «тестировали» обновления для пользователей CentOS. Теперь CentOS получает обновление раньше и уже «бесплатники» «тестируют» для «платников». В принципе понятно с точки зрения бизнеса, но непонятно на чём основана позиция RH/IBM: «вы не понимаете своего счастья, CentOS стал лучше!» (общий CI мягко говоря ничего не даёт)

Я правильно улавливаю суть? Если да - то тут однозначно Alma или Oracle

p.s. Пользовал CentOS на серверах раньше и ловил ситуации когда обновление разваливало сервер по сути (где-то в районе 6.2-6.4 bond интерфейс не поднимался при загрузке при использовании скриптов вместо NM, если ничего не перепутал), а ещё помню проблемы привнесенные «исправлениями исправлений» так что аргумент про низкие риски проблемных обновлений мягко говоря неубедительный

Бредишь? Какой релиз кандидат? Сказали же явно, что синхронизировано с RHEL. Поменялось только то, что теперь обновления идут сразу с гита RHEL, текущей, в Stream. Если железо не экзотическое, то и не заметишь, хотя апдейты пакетов будут, не раз в пол года, а почаще на много

Для меня это хорошо, ибо я помню ожидание с 7.3 до 7.4 со светящимся монитором и виснущими рандомно программами. Читая при этом полезные бумажные книги.

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

не завсегдатай ЛОРа

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

При чём здесь давинчи господи. Если в репах манжары есть твой давинчи, то запущу, есть?

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

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

Ну или вот рхел 8 получается бинарно совместима с рхел 7?

Получится что любой RHEL X как и Manjaro xx.xx.xx repo date бинано совместимы у всех своих пользователей.

Ты высасал преимущество из пальца, ты давай лучше назови дистрибутив который бинарно не совместим в рамках одной версии у нескольких пользователей, а?

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

При чём здесь вообще версия ядра ? Эту грань ты сам придумал. В windows 10 по твоему где-то в глубинах ядро версий winxp крутится что ли? Или протухшие версии либ таскаются ?

Хвастаться тем, что админишь старьё — это как хвастаться что вышел на пенсию в 23 года.

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

CentOS был всегда не нужен

Обострение вялотекущей шизофрении. Ну закончились у шапки деньги на ЦентОС, как штабильный дистр для сертифицированных RHEL серверов от всяких Ленов/Делл/НР, вон у Спуффи спросите 😀.

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

Малым конторам так ваще сам Шатллворт велел каждые 2 года LTS релизы менять.

Почему это хвастаюсь ? Я про говорю как есть. Куча серваков с G2 до G11 и все прекрасно работает и справляется со своей ролью.

Увы я не привык выкидывать и списывать то что еще хорошо работает. Причем как ни странно с каждым годом процент брака все больше и больше …

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

Ты реально тугой. Ессно любой дистр бинарно совместим (или пытается) со своими репами, ради этого их и наполняют.

Речь о бинарной совместимости дистрибутивов между собой а не дистра и его репок - т.е. если я возьму официальный бинарник резолва под рхел7, он у меня гарантированно запустится на рхел7, центось7 и ол7 (ну и прочих там «совместимых») и ещё некоторых дистрах (с недавних пор на убунте работает) но полная повторяемость результата при одинаковых входящих будет только на «бинарно-совместимых», резолв запущенный на рхел7 и убунте20.04 будет работать по разному ибо у них разный набор либ разных версий с разным апи (банально начинается с куды) т.е. если у меня отваливается определенная панелька под рхел7 то я могу чиркнуть багрепорт с последовательностью действий, и на компе разработчика эта последовательность приведёт к точно такому же падению панельки, а вот если у меня убунта то повторяемость результата ни разу не гарантирована и у меня может падать то, что работает у разраба и наоборот

При чём здесь вообще версия ядра ? Эту грань ты сам придумал. В windows 10 по твоему где-то в глубинах ядро версий winxp крутится что ли? Или протухшие версии либ таскаются ?

Версия ядра тут притом что она гарантирует 100% повторяемость работы своего апи. Ессно не обязательно тянуть одну и ту-же версию если ты разрабатываешь ядро сам и контролируешь каждое изменение обеспечивая однотипный результат на выходе, но в линухе этого никто не делает
В вин10 не крутится ядро от хп, но повторяемость апи довольно неплохо сохранена, ибо для мс процесс разработки ядра полностью подконтрольный а не «давайте все на расте перепишем просто чтоб было не скучно» :-)

Не надоело еще молодежи, лапшу на уши вешать ?

Запятая не лишняя?

Нет. Я его давно знаю и вообще-то надо было, после «ещё», поставить ещё одну, для ясности.

непонятно на чём основана позиция: «вы не понимаете своего счастья, CentOS стал лучше!» (общий CI мягко говоря ничего не даёт)

Ну если отбрасывать все попытки объяснения как «мягко говоря» несущественные, то неудивительно совсем что вопрос остаётся непонятным.

p.s. Пользовал CentOS на серверах раньше и ловил ситуации когда обновление разваливало сервер по сути (где-то в районе 6.2-6.4 bond интерфейс не поднимался при загрузке при использовании скриптов вместо NM, если ничего не перепутал), а ещё помню проблемы привнесенные «исправлениями исправлений» так что аргумент про низкие риски проблемных обновлений мягко говоря неубедительный

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

Если да - то тут однозначно Alma или Oracle

Я не оспариваю ничей выбор, если что. До тех пор пока выбравший не начинает использовать некорректные аргументы, типа той же «бинарной совместимости». Alma так Alma.

полемики можно было избежать

не завсегдатай ЛОРа

Оно и видно, что необстреляный :)

Так-то ликбез на тему бинарной совместимости как это понимается в RHEL есть по ссылке:

https://access.redhat.com/articles/rhel8-abi-compatibility

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

Но полемика - это святое.

В прошлом обсуждении уже все выяснили, но нет, все снова - «Вы не так все понимаете».

Повторю.

1. Centos Stream - Поддержка 5 лет, плюс потенциальные проблемы совместимости со сторонним ПО. Centos Stream ставить и забывать нельзя т.е. он никому не нужен и не замена RHEL.

2. RHEL - Поддержка как и прежде 10 лет, ставить и забывать можно т.е. все разбегутся по его клонам.

Ссылку надо добавить

Бета-версия Red Hat Enterprise Linux 9 (комментарий)

Но да, не первое обсуждение и не последнее, а анонимусы продолжают высасывать из пальца «проблемы совместимости со сторонним ПО».

Лютейшее EEE от IBM

на тему совместимости на три мажорных релиза вперёд

Т.е. RHEL 8 будет совместим с 9, 10 и 11, а RHEL 10 будет совместим с RHEL 11, 12 и 13? Т.е. RHEL 8 будет совместим с 13, который совместим с 14, 15 и 16? Или я не правильно тебя понял?

ликбез на тему бинарной совместимости как это понимается в IBM

FTFY

Бинарная совместимость, если откинуть всю лирику, это когда я могу заменить один бинарник другим бинарно совместимым и у меня гарантировано ничего не сломается.

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

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

Т.е. нет гарантии, что с обновлением в CentOS не прилетит баг, который пропустили при тестировании, и который, возможно, не пофиксят и следующие пару релизов. А в RHEL этот баг не попадёт, т.к. туда попадёт только последнее из обновлений.

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

Что делать конечному пользователю CentOS всё то время, когда до RHEL оно ещё не дошло, а в CentOS уже сломалось, но для IBM это не критичный баг?

Зачем нужен CentOS, если он теперь не даёт той гарантии ради которой он создавался?

И, если цель изменения политики, не согнать с CentOS на RHEL пользователей, которым нужна подобная гарантия, а «оптимизировать и улучшить», что мешает релизить в репозиторий RHEL и CentOS одинаковые пакеты? Создали бы CentOS Alpha/Beta/Gamma Stream и в нём бы выкатывали все тестовые релизы.

Или я не правильно тебя понял?

Прочитай текст по ссылке. А потом приходи обсуждать.

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

Если обновление вышло в CentOS Stream - это значит что оно уже вошло в следующий минорный релиз RHEL. Его можно перекрыть следующим обновлением этого же пакета до момента релиза, но нельзя вообще не зарелизить.

Там документ для разработчиков, не для конечных потребителей. И в нём декларируют стабильность api и abi некоторых конкретных библиотек в 11 пакетах. А из твоего комментария, если по ссылке не ходить (а Ъ по ним не ходят, это ж ЛОР), можно подумать про совместимость релизов дистрибутива.

Если обновление вышло в CentOS Stream - это значит что оно уже вошло в следующий минорный релиз RHEL.

Фуфф, успокоила, а то я уж переживать начал. Смотрим https://access.redhat.com/articles/3078

RHEL 8.5 2021-11-09
RHEL 8.4 2021-05-18

и в https://koji.mbox.centos.org/koji/packageinfo?packageID=3236

centos-stream-release-8.5-1.el8 2021-03-17
centos-stream-release-8.4-1.el8 2020-10-29

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

Из зала

Я когда-то сидел на федоре с активированными репами testing-update и не заметил никакой разницы — софт просто переезжал из тестинга в основную и это никак на системе (десктоп) не отражалось, то есть никаких резких движений.

Такое ощущение, что Стрим похож на RHEL, как федора+testing-update на федору.

если по ссылке не ходить (а Ъ по ним не ходят, это ж ЛОР), можно подумать про совместимость релизов дистрибутива

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

И в нём декларируют стабильность api и abi некоторых конкретных библиотек в 11 пакетах.

В нём декларируют разделение всех пакетов RHEL на четыре класса, каждый с собственными гарантиями стабильности api и abi.

И это действительно документ для разработчиков того самого «стороннего ПО», о котором так волнуется местный потребитель.

А если ещё чуть-чуть подумать, то можно понять что баг будет пофикшен раньше. Потому что баги чинятся в процессе разработки в том самом стриме, а не в момент публикации минорного релиза RHEL на зеркала.

Зачем нужен CentOS, если он теперь не даёт той гарантии ради которой он создавался?

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

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

Заьто как фиксятся баги, до выхода минорного релиза RHEL?

В Stream они появляются гораздо раньше, и те кто отбросил предрссудки и перешёл на Stream, докладывают о выявленных багах в RHBZ.

А потом вуаля, и профит. В следующем минорном релиже нет этих багов уже.

Можете закидать меня тапочками, но я вот только по этому и буду пользоваться Stream. И вешать обнаруженные баги в RHBZ.

Понятно, что это всё на добровольных началах, но я и в RHL -> FC3 -> Fedora 21 -> Scientific Linux 6.x -> 7.x и сидел всегда, и работал, и отдыхал, и делал всё, чтоб выявить баг, локализовать, и устранить, а по невозможности самому -> отправить на RHBZ с логами и.т.д.

Так я чувствую себя полезным для сообщества, а не просто пользователем. А Red Hat и IBM (я OS/2 пользовался долго в дуалбуте с купленным ключом), я многим обязан в этой жизни.

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

Я всё сказал.

+1 bookwar.

У центос (не стрим) была гарантия

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

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