Release for CentOS Linux 7 (1611) on x86_64 derived from RHEL 7.3 | Hacker News Reader

Release for CentOS Linux 7 (1611) on x86_64 derived from RHEL 7.3

lists.centos.org

54 pointsgtirloni45 comments

Glad this is finally out. I still think Red Hat should just make their builds completely free without a subscription, and charge only for support. CentOS then wouldn't need to exist (and neither would Oracle Linux). That would help it compete with Ubuntu in the startup world.

You can bet your behind that Oracle Linux would still exist.

The thing is though, Redhat really doesn't need to compete with Ubuntu in the startup world. For the millions of Ubuntu AMIs that run, how much money is Canonical making from them? Compare that to RedHat, a two billion dollar open source company.

Ubuntu was focused too long on markets that simply aren't viable from a fiscal standpoint (See: Ubuntu Phone or much of the excellent desktop work they've done). Redhat meanwhile has been continuing to focus on the enterprise and their revenue continues to grow.

Ubuntu server usage has been growing thanks to AWS AMIs, so actually both have been growing.

I think Ubuntu are just going with a more long term approach.

RedHat just leveraged Oracle compatibility, if you needed Oracle RedHat was and is the only sane choice; but remove the need for Oracle, and Ubuntu is then a very strong competitor.

I believe that CentOS doesn't release sooner when these point releases happen upstream (compared to regular errata updates) may have to do with ensuring packages outside the ones sourced directly from RHEL don't break.

Packages in point releases may sometimes force some packages higher in the dependency tree to be rebuilt, or perhaps may change the dependency chain in some way. Red Hat likely takes care to release only when this doesn't violate stability guarantees for the stuff they support.

If there was no CentOS, I'd say you could end up in a situation where EPEL and IUS (just to mention the most popular - almost indispensable - external repos out there) would be broken for the lastest point release for a while. That would be bad for users.

Red Hat customers are less likely to be using them. After all, if you're going to use unsupported packages, why do it on RHEL instead of CentOS which is mostly the same minus support?

(Also, you can follow the CentOS CR repository if you really want to keep up more closely with upstream RHEL.)

https://lists.centos.org/pipermail/centos-announce/2014-Janu...

CentOS is essentially official. I'm not exactly sure how the relationship works.

No-Cost RHEL Developer Subscription now available

https://developers.redhat.com/blog/2016/03/31/no-cost-rhel-d...

Also, Desktop Self-support Subscription (1 year) is $49 USD.

Yes but it's really messy. Only 1 host, no 'production' traffic, and if you want to run RHEL in production, you're left with a mix of CentOS/RHEL machines all over. Compare that to startups that use Ubuntu everywhere.

CentOS is maintained by Redhat for awhile now. It's an easy way for them to acquire customers that don't have to go through the trial subscription process.

Here is the press release from 2014 when Redhat took on CentOS officially: https://www.redhat.com/en/about/press-releases/red-hat-and-c...

CentOS is managed by Redhat, but it's still a separate project. The RHEL 7.3 release that this is based on was released over a month ago.

We have both RHEL and CentOS servers (RHEL for production, CentOS for analysis and development). Red Hat is happy to work on issues that we submit even if they happened on one of the CentOS boxes. It's a symbiotic relationship too. I had an issue with a SAS driver and CentOS pushed a fix upstream before RedHat could merge it in.

I find that strange. CentOS is supposed to be downstream. They're not supposed to do anything except compile from Red Hat sources. Are you suggesting that Red Hat fixed the issue, released the source code, and CentOS compiled and published before Red Hat could compile?

From what I recall, a few of the CentOS devs are actually Red Hat employees. Also, I think Red Hat has taken a much more active position in CentOS in the last few years[1].

1: https://community.redhat.com/centos-faq/

Be aware before upgrading that this includes an update to sssd that doesn't keep backward compatibility with the previous release.

It seems that the default autofs ldap schema in sssd was rfc2307, but had the wrong default values. So they've fixed the values, but that effectively changes the defaults of sssd.

This broke autofs where I work ...

See:

https://bugzilla.redhat.com/show_bug.cgi?id=1372814

(...I'm not sure why they just didn't make a new setting called 'legacy' as default and put the old (wrong) values in there.)

This brings some really nice updates to IPA, particularly regarding replication. I'm stoked.

I hope this fixes some problems I'm having with CentOS 7 as a desktop. At home, it's fine, but at work, where I'm joined to an Active Directory server for authentication, it doesn't work so well. Winbindd will slow to a crawl with 100% CPU utilization. Various suggested fixes I found on support sites don't help. I tried sssd, but had other problems and I don't like the clumsy override mechanism I have to use in sssd to set the GCOS field to something sane instead of the mess that the AD server hands back (and which I don't control). If this release isn't a significant improvement, I may have to go back to 6.8 for my desktop, which would be sad. (I am limited by policy with regard to which flavors of Linux I can run, so switching to Ubuntu, or Mint, etc., is, sadly, not an option.)

What about freeipa trust to the windows domain?

Is Fedora an option? I'm not sure if it will solve your problems in particular... but it's been working beautifully on my Thinkpad.

And still the documentation on the web site is only up to CentOS 5.

Even complaining to a team member did not nudge them towards maybe, just maybe adding a link to the RedHat documentation which they consider the CentOS documentation, as well.

Hell, if they don't want to help their users find documentation they should just purge https://www.centos.org/docs/ and let people google for it.

I understand why CentOS/RHEL is preferred by some server admins to Ubuntu (longer support cycles, hardware drivers etc), but I never got why individual devs run CentOS versus Ubuntu on their own machines.

Every time I have tried to get tech stacks up and running on CentOS, there is just more friction/pain than doing the equivalent with Ubuntu LTS.

Am I missing something?

I created and deployed a vagrant centos 6.8 development environment for our dev team because we are developing for RHEL 6.8. It was not very hard to do.

Group #2 (users/desktop users/developers) runs CentOS because of Group #1 (server admins/agencies). I'm sure you could find some if you looked, but I've never met anyone except RH employees who actively preferred CentOS/RHEL for personal usage.

Because odds are, you'll need to deploy onto CentOS if you sell your product to someone else.

Also, I like yum's cli more than apt-get's (less than pacman's though)

I mean, you said it yourself. I run a CentOS development machine because what I write will eventually deploy on a CentOS / RHEL server.

RHEL is comparable to running LTS Ubuntu. If you want bleeding edge latest, that's what Fedora is for, not RHEL.

Network effects and legacy. Redhat was around long before Ubuntu, and they have a lot of inertia.

For me it's pretty much all package management:

- I like that all the packaging stuff is done by a single command (yum, or more recently dnf).

- I find RHEL derivatives' packaging conventions easier to deal with than Debian derivatives' (<thing>, <thing>-dev, lib<thing> etc. isn't always consistent on Debian derivatives).

- EPEL gives me most of the packages I need and I don't have issues with them being dated as often as Ubuntu LTS.

- RHEL derivatives' don't tend to do weird nonsense like messing with nginx configuration layout to match Apache.

If you're deploying to physical hardware, most enterprise-y drivers and tools are only provided in RPM format by the vendors.

That, and I've had much better luck with RedHat on bare metal than any other distro.

Personally, I like Debian-based distros, but for physical hardware, RedHat is where it's at.

Specifically this is based on RHEL 7.3. CentOS 7 has been out for some time.

Thanks, this was really annoying me - I couldn't work out why something not new was somehow new again.

CentOS has a different versioning scheme now with v7. Indeed you're correct this is effectively CentOS 7.3, but in the project's own vernacular it's "CentOS 7 (1611)", therefore the OP is technically correct; however to appease all parties may have benefited from putting both 7.3 and 7 (1611) in the title.

OK I said based on, where the email the OP cited uses "derived from" - I'm uncertain there's a meaningful distinction.

openSUSE Leap 42.2[1] was also released fairly recently. This is the community version of SUSE Linux Enterprise 12 SP2. The openSUSE camp doesn't get enough love IMO (though I am biased).

[1]: https://software.opensuse.org/422

This is a point release that updates CentOS 7 to (1611). CentOS 7 has been out for a while now.

I was gonna say: what the hell have I been running on my laptop for the last 6 months?

Actually my original title was more precise because it included "(1611)" which should make that clear. But, apparently, it got changed.

Well of course it did, it was more than four centuries off.

(1611) is November 2016, not the year.

On HN, titles are appended with (YYYY) to indicate the year of the article. So, it was a joke. :P

Phew then it isn't my abacus that is broken!

One does not preclude the other, your abacus could still be broken.

Thanks, we've reverted the title to full one from the linked page.

May have been better to stick '7.3' in there to avoid the confusion I and others have had.

OK, done.

Reply on news.ycombinator.com