LINUX.ORG.RU

RedHat Enterprise Linux теперь бесплатен для малого бизнеса

 , , ,


2

2

Компания RedHat изменила условия бесплатного использования полнофункциональной системы RHEL. Если раньше это можно было делать лишь разработчикам и только на одном компьютере, то теперь бесплатная учётная запись разработчика позволяет бесплатно и совершенно легально использовал RHEL в продакшене на не более чем 16 машинах, с самостоятельной поддержкой. Помимо этого RHEL можно бесплатно и легально использовать в публичных облаках, таких как AWS, Google Cloud Platform и Microsoft Azure.

Источник:

Today we’re sharing details about some of the new no- and low-cost programs we’re adding to RHEL. These are the first of many new programs.

No-cost RHEL for small production workloads

While CentOS Linux provided a no-cost Linux distribution, no-cost RHEL also exists today through the Red Hat Developer program. The program’s terms formerly limited its use to single-machine developers. We recognized this was a challenging limitation.

We’re addressing this by expanding the terms of the Red Hat Developer program so that the Individual Developer subscription for RHEL can be used in production for up to 16 systems. That’s exactly what it sounds like: for small production use cases, this is no-cost, self-supported RHEL. You need only to sign in with a free Red Hat account (or via single sign-on through GitHub, Twitter, Facebook, and other accounts) to download RHEL and receive updates. Nothing else is required. This isn’t a sales program and no sales representative will follow up. An option will exist within the subscription to easily upgrade to full support, but that’s up to you.

You can also use the expanded Red Hat Developer program to run RHEL on major public clouds including AWS, Google Cloud Platform, and Microsoft Azure. You have to pay only the usual hosting fees charged by your provider of choice; the operating system is free for both development and small production workloads.

The updated Individual Developer subscription for RHEL will be available no later than February 1, 2021.

No-cost RHEL for customer development teams

We recognized a challenge of the developer program was limiting it to an individual developer. We’re now expanding the Red Hat Developer program to make it easier for a customer’s development teams to join the program and take advantage of its benefits. These development teams can now be added to this program at no additional cost via the customer’s existing subscription, helping to make RHEL more accessible as a development platform for the entire organization. Through this program, RHEL can also be deployed via Red Hat Cloud Access and is accessible on major public clouds including AWS, Google Cloud Platform and Microsoft Azure at no additional costs except for the usual hosting fees charged by your cloud provider of choice. Bringing RHEL to additional use cases

We know that these programs don’t address every CentOS Linux use case, so we aren’t done delivering more ways to get RHEL easily. We’re working on a variety of additional programs for other use cases, and plan to provide another update in mid-February.

We want to make RHEL easier to use and are removing many barriers that stand in the way, working to keep pace with the evolving needs of Linux users, our customers and our partners. This requires us to continuously examine our development and business models to meet these changing needs. We believe that these new programs – and those to follow – work toward that goal.

We’re making CentOS Stream the collaboration hub for RHEL, with the landscape looking like this:

  • Fedora Linux is the place for major new operating system innovations, thoughts, and ideas - essentially, this is where the next major version of Red Hat Enterprise Linux is born.
  • CentOS Stream is the continuously delivered platform that becomes the next minor version of RHEL.
  • RHEL is the intelligent operating system for production workloads, used in nearly every industry in the world, from cloud-scale deployments in mission-critical data centers and localized server rooms to public clouds and out to far-flung edges of enterprise networks.

We aren’t done with this work. We want to hear from you, whether or not your needs fall into one of the use cases described here.

Please contact us at centos-questions@redhat.com. This email address goes directly to the team developing these programs. We’ve heard you – and will continue to listen to your comments and suggestions.

>>> Подробности



Проверено: Shaman007 ()
Последнее исправление: alpha (всего исправлений: 3)

Ответ на: комментарий от alpha

Использование Stream требует гораздо меньших усилий.

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

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

Evgueni ★★★★★
()
Последнее исправление: Evgueni (всего исправлений: 3)
Ответ на: комментарий от alpha

Замена CentOS на CentOS Stream при наличии такой инфраструктуры (а у CERN например она есть) - это практически незаметное на общем фоне изменение.

И за бинарно совмесимостью им самим просто будет смотреть? Ну что бы еализовать типичный случай:

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

anonymous
()
Ответ на: комментарий от bender

И про тот и про другой.

Прямо сейчас CentOS 8 Stream пересобирает исходники RHEL 8 с некоторым опозданием.

Для CentOS 9 Stream мы работаем над реализацией процесса таким образом, чтобы коммит в CentOS Stream и коммит в RHEL были полностью синхронизированы. То есть git sha с которого собирается пакет в стриме и в rhel один и тот же и сборка происходит практически в один и тот же момент.

alpha ★★★★★
()
Ответ на: комментарий от Evgueni

Ну опять же у тебя неправильное представление о стриме. Stream не Gentoo. Всё что приходит в Stream уже проверено, принято и протестировано инженерами RHEL. Да, оно ещё не выкачено в самом RHEL, но вся работа по этим пакетам уже выполнена.

alpha ★★★★★
()
Ответ на: комментарий от alpha

ну что? переобулись?:) менеджеры, блин)

crypt ★★★★★
()
Ответ на: комментарий от alpha

O'k, что бы было понятно вот такой вот кейс: кто-то написал процедуру обработки данных, оттестировал на том, что предоставляет CERN в рамках кластера lxplus на малой порции данных. Далее запускает обработку данных на статистике, скажем, 2015 года и эти задания шустро уползают в Японию, где радостно падают из-за отсуствия бинарной совместимости, так как в Японии «не обновили роллинг». Примерно через пару суток ты это узнаёшь, так как в Японию уползло только часть заданий и не менее радостно начинаешь искать причину, запускаешь опять и теперь падает та часть заданий, которая уползла в Дюссельдорф.

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

Evgueni ★★★★★
()
Последнее исправление: Evgueni (всего исправлений: 5)
Ответ на: комментарий от Evgueni

Всё так и планировалось с самого начала?

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

crypt ★★★★★
()
Ответ на: комментарий от anonymous

И за бинарно совмесимостью им самим просто будет смотреть?

Реальная бинарная совместимость у CentOS Stream с RHEL лучше чем была у CentOS Linux, по той простой причине что buildroot-окружения для сборки стрима и rhel синхронизированы. У CentOS Linux пересборка выполнялась совсем в другом порядке и это могло влиять на результат.

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

alpha ★★★★★
()
Ответ на: комментарий от crypt

Формально они намекали на бесплатные плюшки в почти изначальном посте, только вот сейчас определились с раземером этих плюшек. IMHO бес толку, пока не сделают RHEL в плане использования прежним CentOS, да и то будут нос воротить.

Evgueni ★★★★★
()
Ответ на: комментарий от Evgueni

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

crypt ★★★★★
()
Ответ на: комментарий от Midael

Чисто теоретически, что мешает регать подставные аккаунты, для получения Nx16 лицензий? Зачем это ограничение вообще нужно?

Слушай кончай уже а?

anonymous
()
Ответ на: комментарий от Evgueni

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

crypt ★★★★★
()
Ответ на: комментарий от alpha

Ну вот не надо. А то ты сейчас договоришься, что между версиями RHEL тоже есть бинарная совместимость. Совсем не интересно как оно есть сейчас. Интересно как оно на протяжении лет для конкретной базовой платформы и совершенно пофиг что это. Выбор RHEL в CERN был сделан не из каких-то расчётов, а чисто по историческим причинам.

Evgueni ★★★★★
()
Ответ на: комментарий от alpha

Реальная бинарная совместимость у CentOS Stream с RHEL лучше чем была у CentOS Linux

А ну раз сказала альфа поверим на слово.

anonymous
()
Ответ на: комментарий от alpha

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

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

Может это ты под бинарной своместимостью пытаешься туфту гнать?

anonymous
()
Ответ на: комментарий от Evgueni

А то ты сейчас договоришься, что между версиями RHEL тоже есть бинарная совместимость.

Повторюсь, размахивание термином «бинарная совместимость» без объяснения что конкретно ты имеешь в виду бессмысленно.

А после того как ты это объяснишь, тебе придется объяснить почему ты считаешь что у CentOS она есть.

И ответ скорее всего будет в виде «потому что CentOS никто не обновлял». Ну так CentOS Stream тоже можно не обновлять. Если дело именно в этом то единственное что тебе нужно сделать чтобы работа с CentOS Stream не отличалась от CentOS - это завести своё зеркало CentOS Stream, и настроить 100500 японско-дюссельдорфских машин брать контент только с него.

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

alpha ★★★★★
()
Ответ на: комментарий от alpha

Ну так CentOS Stream тоже можно не обновлять.

Нельзя. Это не от тебя зависит а от тех, кто твой продукт будет использовать.

anonymous
()

историческая справка с opennet:

Был Red Hat 7.2, на который массово переходили во всём мире. В России же ценились легковесные дистрибутивы, потому что у многих были Celeron и 32 Мб ОЗУ. Но все они имели совместимость с Red Hat 7.2. Потом был Red Hat 9.0 с переходом на многобайтовые кодировки, Linux 2.6, ALSA и ext3. Что-то сродни переходу с Win98SE на Win2000.

А потом РедХат закопал RedHat Linux и вместо этого выкатил RHEL со словами «нет-нет, всё, дальше - только за деньги». И Fedora. Для бесплатного тестирования.

Все успешно свалили в мандрейк, сусю и дебиан.

Потом Ред Хат такой в 2005 «вы решили совершить революцию в линуксе! devfs на udev, везде понапихаем модный XML, dbus, policykit, avahi, NetworkManager, HAL!».

Все такие «Новелл, там ред хат долбанулся! Спасай!». А Новелл такой «Перехожу с KDE на GNOME, чтобы Mono во все поля!». И все такие «ну блиииин!», и перешли на Ubuntu.

Потом все поняли, что GNOME Desktop неплохой, и начали на него массово переходить, а ред хат такой «мы решили всё сломать и начать пилить с нуля!».

я это к чему? RedHat - это стабильно! Стабильная политика и четкий курс!

crypt ★★★★★
()
Последнее исправление: crypt (всего исправлений: 1)
Ответ на: комментарий от alpha

А после того как ты это объяснишь, тебе придется объяснить почему ты считаешь что у CentOS она есть.

Кейс я выше давал. Ровно для того, чтобы проблем не было в частности и делался Scientific Linux, чтобы по возможности свести к нулю проблемы с запуском программных сборок в большом временном промежутке. То, что Scientific Linux дропнули в пользу CentOS (точнее его CERNовского подмножества) объясняется тем, что стабильность этого решения была оценена как достаточная.

Evgueni ★★★★★
()
Ответ на: комментарий от AleksK

Ты с бухгалтера и работал? Хотя бы в конторе от 2500 человек? Если бы работал, то знал бы как происходит работа в реальных условиях.

Документ, таблица не обязательнано на 100500 листов. Можно сделать небольшой документ с таблицей, графаком в Microsoft Office и в LibreOffice этот же документ поплывёт с форматированием и т.д.

anonymous
()
Ответ на: комментарий от alpha

настроить 100500 японско-дюссельдорфских машин брать контент только с него.

Ясно понятно, а пока это обновление на 1М хостах идёт все стоят и сосут лапу (прибивая уже запущенные задачи, которые могут висеть в штатном режиме месяцами), а затем дружно пересобираются. Прекрасная перспективка.

Evgueni ★★★★★
()
Ответ на: комментарий от Evgueni

Кейс я выше давал.

Я тебе на него ответила.

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

Такой вариант «совместимости» обеспечивался не CentOS-ом самим по себе, а процедурой обновления. Применив точно такую же процедуру обновления к CentOS Stream, ты получишь ровно такой же уровень совместимости.

alpha ★★★★★
()
Ответ на: комментарий от alpha

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

Evgueni ★★★★★
()
Ответ на: комментарий от Evgueni

Давай ты добавишь в эти рассуждения сравнение с тем как это происходило с CentOS и почему в CentOS Linux это не было проблемой а в CentOS Stream вдруг стало.

alpha ★★★★★
()
Ответ на: комментарий от alpha

ты получишь ровно такой же уровень совместимости.

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

Это ложь! Ролинг на такое не способен.

anonymous
()
Ответ на: комментарий от alpha

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

crypt ★★★★★
()
Ответ на: комментарий от anonymous

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

Ещё раз:

  1. почему ты думаешь, что она была?

  2. почему ты думаешь, что она пропала?

alpha ★★★★★
()
Ответ на: комментарий от alpha
  1. почему ты думаешь, что она была?

Потому что все работало годами и проблем с этим не было.

  1. почему ты думаешь, что она пропала?

Потому что Stream это ролинг, а ролинг дистрибутивами проблемы были почти всегда.

anonymous
()
Ответ на: комментарий от anonymous

Потому что все работало годами и проблем с этим не было.

Железная техническая аргументация пошла.

Потому что Stream это ролинг, а ролинг дистрибутивами проблемы были почти всегда.

И тут тоже.

alpha ★★★★★
()
Ответ на: комментарий от alpha

Железная техническая аргументация пошла.

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

Если интересно - смотри Qt’ную. У других анологичные

И тут тоже.

А вот тут все просто. Обновляются версии библиотек не глядя на бинарную своместимость.

anonymous
()
Ответ на: комментарий от alpha

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

anonymous
()
Ответ на: комментарий от anonymous

Что ты нашей Шурочки докопался, клоун? Ее никто не назначал подмахивать за весь RedHat.

Она в это на добровльных началах впряглась.

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

anonymous
()
Ответ на: комментарий от anonymous

Я так понимаю, остальное вопросов не вызывает.

anonymous
()
Ответ на: комментарий от anonymous

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

А можно без махания руками а по существу?

Обновляются версии библиотек не глядя на бинарную своместимость.

Это где они так обновляются по-твоему? В RHEL?

alpha ★★★★★
()
Ответ на: комментарий от crypt

историческая справка с opennet:

Был Red Hat 7.2, на который массово переходили во всём мире…

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

hummer
() автор топика

Ну всё ждём наплыв редхат юзверей.

MaxPower ★★
()
Ответ на: комментарий от alpha

А можно без махания руками а по существу?

По существу. Есть куча правил для разработки библиотек. Большинство основных библиотек их пытаются всеми силами соблюдать. Это когда программа скомпилированная с Qt 4.6.2 без проблем работает с Qt 4.8.7. Есть нюансы, но в основном без проблем.

Это где они так обновляются по-твоему? В RHEL?

Это так во всех ролингах. По существу Stream стал ролингом.

Что RH будет обещать - совершенно не важно. Они общали 10 лет поддержки для CentOS 8 и где она?

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

anonymous
()
Ответ на: комментарий от anonymous

Это так во всех ролингах. По существу Stream стал ролингом.

Это взаимоисключающие параграфы. Либо первое, либо второе. Потому что таким роллингом как ты описываешь Stream не стал.

alpha ★★★★★
()
Ответ на: комментарий от alpha

Это взаимоисключающие параграфы. Либо первое, либо второе. Потому что таким роллингом как ты описываешь Stream не стал.

То есть он выполняет роль ролинга, но он не ролиг. :)

Всякое бывает, конечно, но с какого перпуга мне верить в это? У других это не так. Почему должно быть так у RH? Потому что они так сказали? Они и о 10-ти годах поддержки CentOS говорили. Это более формализуемое утверждение, но они и его не выполнили.

anonymous
()
Ответ на: комментарий от anonymous

Ты мне объясни накой это бухгалтеру надо? У тебя бухгалтера рефераты на заказ пишут?

И я работаю в конторе где только в одной из 1с-овских баз 770 пользователей.

AleksK ★★
()
Ответ на: комментарий от anonymous

Шикарная аргументация. «Все врут, поэтому я создал выдуманную реальность и буду верить в неё»

Ну удачи тебе на этом пути.

alpha ★★★★★
()
Ответ на: комментарий от Evgueni

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

Midael ★★★★★
()
Ответ на: комментарий от alpha

Шикарная аргументация. «Все врут, поэтому я создал выдуманную реальность и буду верить в неё»

Ну удачи тебе на этом пути.

То есть ты хочешь сказать, что RH будет 10 лет поддерживать CentOS 8?

И кто из нас в выдуманной реальности?

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.