Бета-версия Red Hat Enterprise Linux 9

Вот что меня поражает, это когда люди которые пытаются прикопаться к процессу выкатки CentOS Stream и найти там нестабильность и несовместимости с RHEL, при этом считают что EPEL является оплотом этой самой стабильности.

Если вашему супер-серьезному и супер-критичному продакшену всегда хватало стабильности вообще никак не тестируемого EPEL, то стабильности Stream-а вам хватит за глаза. А те улучшения, которые благодаря ему теперь возможны в инфраструктуре EPEL и всех прочих смежных проектов - позволят шагнуть сильно дальше.

bookwar, спасибо за то, что развеяла сомнения. Остался один глупый вопрос - Stream 8 на Stream 9 ролнется обычным апдейтом, или нет? И больше у меня вопросов не будет. То есть лично у меня. Ты знаешь, что я любитель стабильности и столько лет проработал в Scientific Linux 7.x :)

Обычным - нет.

Но есть разработанная в RH утилита LEAPP, которая позволяет делать апгрейд мажорной версии. Есть планы по поддержке в ней CentOS Stream. И есть Alma, которые уже выпустили на её базе собственную улититу ELevate, которая имеет все шансы стать универсальным инструментом апгрейда для всего семейства систем.

Спасибо! Вопросов больше нет. Пожалуй на некритичном сервачке, домашнем, попробую поставлю. А то там ещё Scientific Linux 7.9 вертится + epel.

https://www.debian.org/ не благодари.

С 3-го woody по 5 Lenny под ним был, потом 7-ой немного. Но всё равно к форку RHEL, Scientific Linux вернулся 6 потом 7.

Я не хочу сказать что Debian плох, нет, он очень хорош, но для меня лучше RHEL.

Мозги уже под RHL перестроены. А Debian хорош, но ставить его надо по старинке, а не новомодными установщиками, то есть покомпонентно, а с KDE 5 Plsma, да и с KDE 4, уже было сложновато. Зато всё только нужное.

Так что… Мой выбор очевиден.

Да и bookwar, я доверяю давно уже. Ни разу не подводила и помогала в тупиковых ситуациях. Ещё с начала 2000-х.

то стабильности Stream-а вам хватит за глаза.

bookwar, я поверил и установил на сервак CentOS Stream 8 + EPEL, вроде всё заработало. Но закончил только вот недавно, так что - никому рекомендовать не буду я, но тестовый аптайм пошёл.

До этого у меня там был Scientific Linux 7.9 + EPEL, аптайм год :) Проблем не было вообще.

Трудностей с установкой не было. Всё прошло с первого раза и гладко.

стабильности Stream-а вам хватит за глаза.

А срока поддержки хватит? CentOS Stream 8 тот же будет точно также обновляться 10 лет? Или все же через три года придется съезжать на CentOS Stream 9 и принимать все новые [s]ухудшения[/s] улучшения Linux по умолчанию и тестировать их?

Чего я никогда не мог понять, так это мегафриза на десять лет. То есть сперва все мегафризится, а потом начинаются специальные репозитории со свежим софтом. На кой черт тогда мегафризится?

И там же ещё не только мегафриз, там ещё и мега-прыжок по его окончанию.

Хотя наверное кому-то удобно - поставил, забыл на десять лет. А перед тем как становится необходимо обновлять то что ты сотворил, уходишь на пенсию. И то что там накопилось разгребать не тебе а новому поколению.

Вот похоже сейчас как раз с шестым centos такая ситуация. Уже год как end of life, а судя по трафику приходящему на зеркала, народ так и не понял что с ним теперь делать. А как обновляться не знает, потому что никогда в жизни не пробовал.

Именно так, целевая аудитория была - поставил на 10 лет и забыл, а там - то ли уволился, то ли на пенсии - разберемся потом. Не нужны даже были своевременные обновления, когда-то они все же приходили.

А в нынешних условиях вместо 10 лет - 5. Плюс потенциальные косяки с совместимостью, которая теперь не 100%, да, может 99, но не 100.

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

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

Именно так, целевая аудитория была - поставил на 10 лет и забыл

Ключевое слово - была. Но люди учатся на своих ошибках.

Как думаешь почему Red Hat перешёл на трёхлетний цикл мажорных релизов? Потому что те люди которым по твоему «ничего не нужно» пережив один раз миграцию с RHEL 4 и RHEL 5 задумались о том как сделать так чтобы не повторять таких проблем в будущем. А подумав запросили четкую схему релизов чтобы делать плановые регулярные обновления, а не полную переделку всего мира с непонятными рисками.

И сейчас например с RHEL 8 -> RHEL 9 все отмечают что девятая версия гораздо менее революционна в плане изменений, выходит раньше чем все привыкли, и позволяет апгрейды. Все эти вещи нужны индустрии, чтобы изжить идею о «поставил и забыл» и начать пилить инфраструктуру для изменений, а не против них.

Только в реальности все немного не так.

RHEL 8 поддерживается 10! лет - ставить и забывать можно.

Centos 8 Stream - поддерживается 5! лет (+ потенциальные проблемы совместимости) - ставить и забывать нельзя.

Итого Stream - тестовая версия коммерческого продукта с половинчатым сроком поддержки и без каких-либо гарантий -> народ разбежиться по клонам т.к. ему запретили ставить и забывать.

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

RHEL 8 поддерживается 10! лет - ставить и забывать можно.

Вообще, жизненный цикл RHEL 8 устроен несколько сложнее - это не одна сущность, это минорные релизы которые поддерживаются каждый по своему https://access.redhat.com/sites/default/files/images/rhel_8_life_cycle_8_0620_planning_0.png

Во-вторых, Full support для RHEL заканчивается как раз таки за пять лет. Последним минорным релизом восьмерки будет 8.10.

CentOS Stream после этого остановится даже не столько по политическим сколько по техническим причинам. Непрерывной разработки следующего минорного релиза после 8.10 не будет, не будет сборки пакетов для неё инженерам RHEL => не будет стрима.

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

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

Отвечаю как справятся клоны - будут как и прежде пересобирать из исходников RHEL.

Или планируется после Full support для RHEL не отдавать исходники?

Я не спорю, что Stream нужен и хороший, но это внутренняя кухня разработки, это никому не интересно.

Все хотят сразу готового и стабильного, бесплатно (да, халявщики). И в этом плане Stream не замена старого Centos, а что-то совершенно другое.

Сил может не хватить.

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

От появления клонов эти причины никуда не деваются и не исчезают в одночасье. И клонам тоже надо будет с ними жить и разбираться.

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

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

Я не хочу дальше спорить на эту тему честно говоря. Все кто хотят пользоваться клонами пусть идут и пользуются.

Стрим открывает новые возможности, клоны закрывают старые - все в выигрыше.

А то что вам нужен «супер стабильный» клон RHEL чтобы поставить на него пакет из EPEL - ну так ваши сервера, ваши правила.

судя по трафику приходящему на зеркала

Это ты ещё трафик кейсов в поддержке не видела (наверное).

Непрерывной разработки следующего минорного релиза после 8.10 не будет, не будет сборки пакетов для неё инженерам RHEL => не будет стрима.

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

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

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

А вот тут раскрывается истинная суть букваря - невежество и дилетантство или умышленное искажение фактов. Для клонов Red Hat Enterprise Linux абсолютно не имеет никакого значения есть ли платные клиенты и разработчики или нет, поскольку вся основная работа клона - это удаленно загрузить в сборочный сервер Koji пакеты из подписки RHEL, отдать команду на сборку .src.rpm и выпустить болванку раз в N-ый период синхронно с RHEL. И для этого не имеет никакого значения возраст дистрибутива или болванки, поскольку сборочному серверу все равно какие пакеты собирать. Т.е задача поддержки клона сводится к сборке пакетов RHEL без логотипов (Они же не вплетены в другие пакеты), передаче багов в Redhat Bugzilla (естественно не в стиле - я вот тут клон создал, а у людей вот это …), а также исключения из сборки вещей, вроде менеджера-субскрибера (ибо клону он ввиду публичной открытости репозитория не нужен). Соответственно и расходная часть клона не равна расходной части на содержание вторых 5 лет RHEL. Еще раз, клоны на стриме не базируются!

У CentOS справиться с этой задачей пока не получилось, но время покажет.

Конечно, потому что копейка ОС без Red Hat - чисто наколенная поделка, которая не включала субскрип на RHEL, а брала исходники с FTP.Redhat.Com, соответственно ни на что и не претендовала и баги от нее писать некуда и некому. Профессиональный же клон включает в себя и профессиональный подход к разработке, в том числе и выступление в роли посредника между Red Hat и пользователем клона.

Ну видишь, Red Hat всё правильно сделал значит - освободил поляну для «профессиональных» клонов. Чтобы настало вам анонимусам счастье.

Непрерывной разработки следующего минорного релиза после 8.10 не будет, не будет сборки пакетов для неё инженерам RHEL

чо нюхаете? отсыпете?

Red Hat всё правильно сделал значит

ага, начал медленное самоубийство. с учётом явно неверного выбранного пути , что явно видно по NetworkManager на серверах, оно и к лучшему.

Вангую, что 9 - последний RHEL.

Если вашему супер-серьезному и супер-критичному продакшену всегда хватало стабильности вообще никак не тестируемого EPEL, то стабильности Stream-а вам хватит за глаза. А те улучшения, которые благодаря ему теперь возможны в инфраструктуре EPEL и всех прочих смежных проектов - позволят шагнуть сильно дальше.

А вы никогда не думали, что EPEL пользуются просто потому, что альтернатив нет и что в исходном репозитории RHEL много чего не хватает? Все-таки есть разница между накатыванием целой системы из EPEL или пары пакетов, которым нет альтернатив, но они нужны на производстве. Ах да, EPEL является необходимостью при подключении RPMFusion. NTFS-3G тот же - без него нельзя примонтировать том с NTFS. А в случае с RPMFusion это например, замена нубодрайвера (который далек по качеству 3D-отрисовки от заводского ПО) на нормальный проприетарный блоб, поскольку Gnome оказывается, отрисовывает в 2D через llwmpipe. Или как вариант, установка окружения Flashback, не требующего этой самой 3D-отрисовки, но использование при этом штатного RH-гномософта. Еще раз, это не значит что и ядро, и systemd, и иксы (Wayland), и среда рабочего стола (для сервера - Apache, PHP) - все из EPEL у таких людей.

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

Я не поняла зачем ты решил мне доказать что EPEL нужен и полезен. Я вообще-то в курсе и никогда с этим не спорила.

Речь была не об этом.

Я не поняла зачем ты решил мне доказать что EPEL нужен и полезен. Я вообще-то в курсе и никогда с этим не спорила.

Как «гениально» извернули мысль наизнанку… Цель была доказать, не что EPEL нужен, а что существуют кейсы, где стабильность отдельных пакетов (доля которых может быть как в вышеописанных примерах равна 99%) также важна, как и в кейсах на стабильность всей системы. И соответственно, таким людям CentOS Stream не подходит, так как там все пакеты работают в рамках политики Stream.

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

Знает но не будет. Ибо нах не нужно.

Все итак работает.

Вот будут железо менять…