On Thu, Jan 21, 2021 at 6:04 AM Ljubomir Ljubojevic <centos at plnet.rs> wrote: > > On 1/20/21 2:14 PM, Mike McGrath wrote: > > Hi all, I know this was a hot topic on the list so I thought I'd share > > today's blog post which covers no-cost RHEL for small production > > workloads and no-cost RHEL for customer development teams. Keep in mind > > there are other programs coming, these just got done first. > > > > https://www.redhat.com/en/blog/new-year-new-red-hat-enterprise-linux-programs-easier-ways-access-rhel > > <https://www.redhat.com/en/blog/new-year-new-red-hat-enterprise-linux-programs-easier-ways-access-rhel> > > > > Bullet Points: > > > > * Self-Support RHEL for no-cost in production use cases of up to 16 > > systems. > > * No-cost RHEL for customer development teams (larger number of > > systems for non-production cases). > > * Available no later than February 1 > > * Single Sign-on via a Red Hat account, or Github, Twitter, Facebook > > or other accounts (You'll soon not need to provide all kinds of > > personal information like you used to). > > > > Hi. I am glad our relentless pestering was not for nothing, no-cost for > small production use is what will appease many who did not already > decided to switch to other distros (maybe even though who did not start > to actually convert to other distro's). Based on comments about 'what to > do next" some ~30% stated they will move to Debian/Ubuntu. I personally > have only one personal web/mail server and the rest are Samba + Windows > VM internal servers so I have to chose between TrueNAS that has ZFS + VM > + excellent web config vs classical Linux server (at this point no-cost > RHEL is real option). > > And I guess with no-cost RHEL's after a while RHEL market share will > rise and Red Hat will be able to see direct impact of no-cost > production servers on market share. The "no-cost RHEL's will still require registration. Registering every member of a cluster was always a burden for RHEL users. It was why, commercially, I urged my employers to buy generous bulk licenses, rip the registration tools the hell out, and use an internal RHEL mirror built with my published reposync tools to reduce the registration burden and to reduce bandwidth costs and *vastly* improve the performance of running "yum" to our corporate mirrors. It's what I expect to do with CentOS 8 stream, to generate locked internally mirrors for pointing to a stable point release. The tools are at https://github.com/nkadel/nkadel-rsync-scripts . > I read announcement and few articles and comments on Facebook, and I > have few comments and questions. > > 1. Wording of the blog article has left me confused what exactly > "small-use production" means (exact definition) since no-cost license is > tied to "Developer" license which is for next 10 days still "no > production use". I had read it later somewhere on Red Hat site but the > blog it self is not explicit enough. So make sure texts clearly state > "Developer" status is only a legacy and production systems are allowed. The confusion may be deliberate. There have been various details of this whole mess with different interpretations, including from Red Hat and CentOS leadership. > 2. It is not clear if only server variants are allowed or if RHEL > Workstation variant will be able to register under Individual Developer > license. I use CentOS 8 on my laptop and have Apache + MySQL + > PostgreSQL installed although rarely used. What variant > Workstation/Server should be installed in such case and will there be > any limits what can be installed if one is chosen instead of the other > (I never installed RHEL aside from initial beta releases and will have > to research this first)? CentOS has all the packages from all the RHEL > variants accessible in single variant. > > 3. Users that register Individual Developer licenses should be warned > that they need to renew subscription every 365 days and that they should > not miss the date(?). Someone commented that if subscription is not > renewed before it expires they might be problems? Is that true, and what If you're setting up more than one such host, set up an internal reposync mirror "just in case".. It also profoundly improves the performance of "mock" for building RPM's internally.