CentOS 8.1 подает признаки жизни!

А чего бы ему не быть? IBM будет поддерживать CentOS пока есть Oracle Linux (иначе побегут на него). Более вероятная концовка CentOS - RHEL сделают бесплатным, просто без коммерческой поддержки. Или поддержка, но за деньги.

Сейчас истеришные набегут и напишут что это всё неправда.

Сейчас поддержка если и есть — то по остаточному принципу, похоже.

Потому что это ну попросту явная нехватка ресурсов — то, что у OL заняло всего 10 дней, у команды CentOS до сих пор не закончено.

И это не стартовый этап, когда всё с самого нуля из исходников! OL в этом плане проще — у них и на старте билд-сервера на RHEL готовом были, по слухам.

пфф.. а что есть какие-то предпосылки, что centos помирает?

ранее при возгласы 6.4 - 6.5 были какие-то истеричные крики, и ничего, потеснее стал с redhat и выпуски стали шустрее выпускать после выхода rhel

Ну они релиз прошлый чуть ли не пол-года делали. Или у них всегда так?

да, у них бывают такое, вот 6.0 вышел у centos 10 июля 2011, у rhel 10 ноября 2010. С 8.0 тоже видимо как-то не задалось ) Как сами объясняли (https://lists.centos.org/pipermail/centos-devel/2019-September/017693.html)

Более вероятная концовка CentOS - RHEL сделают бесплатным, просто без коммерческой поддержки. Или поддержка, но за деньги.

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

Почему тогда эти клиенты не ставят OL или Cent? Там же те же самые обновления безопасности и фиксы критичных багов, что и в родителе.

Так эффективным менеджерам нужен договор с крупной компанией, а не «васяноподелие».

Но в этом случае они и за rhel точно заплатят? Да и оракл тоже как бы не маленький. Раньше же шапки (до ibm) были совсем мелкие — всё-равно покупали. Может быть есть ещё какие-то факторы, о которых не принято всем рассказывать?

Опять эти окаменелости шевелятся… По сравнению с ними, даже debian stable это блидинг хипста эдж.

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

Рановато ты новый год встретил..

иначе побегут на него

Почему на него не убежать уже сейчас?

Серьёзные люди на них серьёзную работу делают, а не гонятся за циферками.

Иди лесом ;) Мне приходится работать почти каждый день с рхелом, ибо на него (причем на семёрку) завязаны сапры кэденса, лет за 10 наелся уже. В двух словах: древние версии библиотек, из-за чего в /usr/local приходится устраивать слаку ради свежих версий питона, cmake, ccache, ffmpeg/libav, lua, openocd, ninja. ksh из основных репозиториев собран так, что падает с сегфолтом, когда звёзды встают не так при запуске сапра. Многих пакетов вообще нет в репах и приходится подключать чуть ли не репозитории от васяна (ffmpeg и мультимедиа особенно). Наконец даже (выдано цензурой) bash-completion работает через одно место и автодополнение целей из gnu make я так и ниасилил запилить.

bash-completion работает через одно место и автодополнение целей из gnu make я так и ниасилил запилить

У меня семёрки под рукой нет, но в восьмом работает. Только что проверил.

из-за чего в /usr/local приходится устраивать слаку ради свежих версий питона, cmake, ccache, ffmpeg/libav, lua, openocd, ninja

Может быть инструмент выбран не верно? Рхел как бы не для этого выбирают.

Ключевое - САПР cadence. Либо рхел, либо никакой тех. поддержки. Но их тулы только часть в общем тулчейне инструментов, и не все можно разнести технически по разным машинам. Так что жрем кактус.

Либо рхел, либо никакой тех. поддержки.

Сурово

Почему на него не убежать уже сейчас?

А вы пробовали? Там сложнее немного всё. iso'шки только после регистрации, ещё какие-то свои патчи на ядра накладывали. Но если альтернативы не останется...

По моему сторонние репы уже успешно заменяются докером.

Ничего страшного в регистрации не вижу. Как и в патчах.

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

Я докер ставил на семёрку. А вот podman просто так не завёлся. :)

Лишнее телодвижение как фактор выбора. :)

Мне более не понравилось, что в их EULA вроде как прописано, что часть инструментов из ОС, например DTRACE, ЕМНИП, платные. Не хотелось бы ненароком что-то установить, а потом получить письмо счастья с тербованием денег — в CentOS с этим проще.

По тикету от конторы, в которой я работал, Красношапка пинала разрабов в vendorname, дабы они пофиксили баг в прошивке оптического интерфейса, из-за которого выбиралась скорость в 100Mb/s при определяемых поддерживаемыми вплоть до 40G. Мы с помощью реверса починили на второй день, разрабы вендора управились за 2 недели, если в компании не окажется упоротых инженеров и сервера на CentOS - бокс по переписке шёл бы ещё медленнее т.к. контактировать пришлось бы через вендора серверов.

Вру, у нас пара машин на 6.4 ещё из-за необходимости запускать сапры с запашком, которые не семёрке не взлетают.

Это знакомая и больная история. Сами регулярно в боксе по много месяцев участвуем.

podman работает на 7 «просто так». Даже rootless.

У меня ругнулся на отсутствие каких-то атрибутов в xfs. Можно ли их добавить без переустановки разбираться не стал. Сейчас работает doker, а при переходе на восьмёрку будет уже другой разговор...

ещё из-за необходимости запускать сапры с запашком, которые не семёрке не взлетают

Может как раз стоит попробовать разобраться с AppImage? Пока совсем поздно не стало?

Не поможет. САПР собирает верилог модель микросхемы и специфические vpi расширения. Система сборки - cmake. Внутрь vpi расширения линкуются некоторые библиотеки, которые по понятным причинам должны быть достаточно свежими.

Конечно, в контейнер можно вынести часть инструментов системы сборки, но это во-первых усложнит и так не особенно простую систему, а во-вторых сделает планирование операций ещё сложнее. На серверах материнки с двумя сокетами. Экспериментально было выявлено, что бутылочным горлом для моделирования является ширина канала памяти и кэш, потому был создан планировщик, в который оборачиваются запуски и который прибивает процессы моделирования к наиболее свободному сокету и учитывает особенности конфигурации, в которой собирается проект (ртл, нетлист, нетлист с задержками). Последний вариант может отжирать под сотню гигов памяти на один запуск и идти неделю элементарно. Если где-то в этой цепочке будут задействованы контейнеры, то сообщения о проблемах останется писать только санитарам.

Это если вкратце.