7 ms·

Release for CentOS Linux 7 (1708) on x86_64 derived from RHEL 7.4

99 points by gtirloni 9y ago

jlgaddis 9y ago
This is some great news that I've been waiting to hear! 7.4 has been a huge undertaking and I'm quite pleased that they've managed to get it out so quickly. > We had a record number of missing build requirements (that is, things required to build the release that are not actually in the distribution to run the released packages). These packages are not part of RHEL proper and each one has to be researched and an appropriate package found (usually from EPEL or the Fedora Archives) to build the packages. In the 1708 release, we had 11 of those source packages to find. In the previous four CentOS release cycles there were a total of 5. There was a large amount of software in RHEL 7.4 that was rebased to much newer versions (much more than is typical) which is a very welcome change. I'm glad to see that Red Hat (and, by extension, CentOS) are willing to put in the work to provide newer versions of popular software in point releases (and not just major releases). This makes using RHEL/CentOS an option for those who prefer newer software over long-term stability. HN'ers, particularly, may likely be interested in the new versions of OpenSSH, OpenSSL, libvirt, and rsyslog (along with their new features) that are included in 7.4. There was a separate announcement [0] regarding armhfp. Links to new (7.4) images (e.g., for the Raspberry Pi) are included in that announcement. N.B.: Those who use vagrant will want to skim over the list of "Known Issues" [1]. [0]: https://lists.centos.org/pipermail/centos-announce/2017-September/022534.html https://lists.centos.org/pipermail/centos-announce/2017-Sept... [1]: https://seven.centos.org/2017/09/updated-centos-vagrant-images-available-v1708-01/ https://seven.centos.org/2017/09/updated-centos-vagrant-imag...
- Crontab 9y ago
  > These packages are not part of RHEL proper and each one has to be researched and an appropriate package found Given that Centos is now owned by Redhat, isn't this really just theatre?
  - bonzini 9y ago
    Pretty much, but not in the sense that you mean. CentOS does the right thing in keeping a clean room. However, it's theatre to insist that RHEL as distributed need not self host. (I am on RHEL engineering, and fought unsuccessfully to include some package in RHEL6---unsuccessfully because "customers don't need it"---only to see it included in RHEL7 because some customer requested it...) That said, it's a dozen packages so it's not a huge deal.
    - jlgaddis 9y ago
      > ... unsuccessfully because "customers don't need it ..." And yet, as I noticed (yet again) earlier today while working on kickstarts, it is impossible to get rid of some packages that I will never want installed because they are listed as required dependencies when they really should be, at most, "recommends". For example, I'm currently putting together a kickstart file for a minimal "desktop" installation on ThinkPads -- well, as minimal as RHEL will let me, that is (which isn't saying much). There are numerous packages that I absolutely do not want on these systems but that I am stuck with, such as: bluez, cups-{libs,pk-helper}, gnome-bluetooth{,-libs}, gnome-online-accounts, libsmbclient, oddjob-mkhomedir, samba-{client-libs,common}, tigervnc-{license,server-minimal}, and probably some others that I'm forgetting at the moment. A few of these -- the Bluetooth-related ones -- are particularly relevant [0], yet I can't uninstall these packages (or, better yet, avoid installing them in the first place) without rpm/yum insisting on also taking out dozens of other, critical packages (no, "--nodeps" is not an acceptable solution). Yes, I can "hack" my way around it (disabling services/unit files, etc.) but it would be great if one didn't have to do that in the first place. Sorry, this wasn't directed at you personally, but rather Red Hat in general. > ...fought unsuccessfully to include some package in RHEL6 ... On a side note, I'm now curious which package you were referring to. </rant>
      - bonzini 9y ago
        The ACPI assembler if I remember correctly. BTW, an easy way to block Bluetooth is blacklisting the kernel module. RPM only got soft dependencies recently, so maybe you can check whether Fedora uses them for Bluetooth userspace packages and similar.
- ams6110 9y ago
  > This makes using RHEL/CentOS an option for those who prefer newer software over long-term stability. But there are already plenty of distros that provide that option. Long-term stability is precisely the advantage of RHEL, for people who value that.
nailer 9y ago
Cool. It has ALPN support, needed for HTTP/2 in Chrome. Also no ifconfig by default, which is good as it hasn't worked properly on any distro for a decade and people keep using it.
- 101km 9y ago
  As a public service I'll just leave this here: https://dougvitale.wordpress.com/2011/12/21/deprecated-linux-networking-commands-and-their-replacements/ https://dougvitale.wordpress.com/2011/12/21/deprecated-linux...
forapurpose 9y ago
As a user who wants an OS that 'just works' so that I can work on other things, why wouldn't I choose CentOS over Fedora for my laptop?
- xena 9y ago
  driver compatibility.
  - chowyuncat 9y ago
    RHEL provides a stable kernel ABI. "Once a symbol has been introduced into the Kernel Application Binary Interface (kABI) for a particular major release of Red Hat Enterprise Linux it will not be removed, nor will its meaning be changed during that kernel major release's complete life cycle." SLES is another distribution with a stable kernel ABI. Additionally, in practice a module (driver) that ignores the kABI will usually work for all patched kernel versions on a given minor release (~service pack). e.g. A minor release 6.X introduces a new kernel X' (2.6.32-X'.Y) and a module built against X'-0 will work for all Y.
    - noselasd 9y ago
      What xena means is that Fedora comes with more and newer drivers compared to CentOS, this means there are new hardware that might not work with CentOS, but does work in Fedora. (CentOS/RHEL 7.x is new enough that this isn't a big issue yet, but it normally does become a pain point the older the RHEL/CentOS major release gets - there are a lot of drivers that does not get backported to the RHEL/CentOS minor releases)
- TheDong 9y ago
  You wouldn't. CentOS is aimed at servers which are maintained by sysadmins who know RHEL well (e.g. RHEL certified), or who just want really friggin' stable shit. A developer usually wants someting that has a tradeoff closer to "newer" on the "stability vs upgrades" tradeoff. For a dev laptop, absolutely use fedora over centos.
smegel 9y ago
Do they not call it CentOS 7.4? I thought they did for the 6-series releases.
- rconti 9y ago
  I'm not sure of the exact specifics, but they have dropped the minor version numbering in favor of, I guess, build number. You'll find that you can no longer rely on a static repo for (say) 7.3 to stay static and instead 7 will be symlinked to latest.
- orev 9y ago
  The downloads are all under 7.4.1708, so the 7.4 is still there. They don't talk about it much because it's not the same as what RHEL calls 7.4. RedHat still patches older point releases, while CentOS does not so you always need to track with the latest to get updates.
emmelaich 9y ago
One major change is the move of various Kubernetes daemons to docker containers rather than rpm. Upstream change log here: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux_atomic_host/7/html-single/release_notes/ https://access.redhat.com/documentation/en-us/red_hat_enterp...
pharaohgeek 9y ago
I'm still waiting for Swift support on RHEL/CentOS. It's great that Swift finally runs on Linux, but my company has standardized on RHEL, so we can't run Ubuntu to get Swift support. If RedHat rolled out RPMS for Swift that would make my life SO much easier!
Tomte 9y ago
And as usual: let's shame CentOS for their embarassing manuals page and their unwillingness(!) to fix it: https://www.centos.org/docs/ https://www.centos.org/docs/

99 points by gtirloni 9y ago

This is some great news that I've been waiting to hear! 7.4 has been a huge undertaking and I'm quite pleased that they've managed to get it out so quickly. > We had a record number of missing build requirements (that is, things required to build the release that are not actually in the distribution to run the released packages). These packages are not part of RHEL proper and each one has to be researched and an appropriate package found (usually from EPEL or the Fedora Archives) to build the packages. In the 1708 release, we had 11 of those source packages to find. In the previous four CentOS release cycles there were a total of 5. There was a large amount of software in RHEL 7.4 that was rebased to much newer versions (much more than is typical) which is a very welcome change. I'm glad to see that Red Hat (and, by extension, CentOS) are willing to put in the work to provide newer versions of popular software in point releases (and not just major releases). This makes using RHEL/CentOS an option for those who prefer newer software over long-term stability. HN'ers, particularly, may likely be interested in the new versions of OpenSSH, OpenSSL, libvirt, and rsyslog (along with their new features) that are included in 7.4. There was a separate announcement [0] regarding armhfp. Links to new (7.4) images (e.g., for the Raspberry Pi) are included in that announcement. N.B.: Those who use vagrant will want to skim over the list of "Known Issues" [1]. [0]: https://lists.centos.org/pipermail/centos-announce/2017-September/022534.html https://lists.centos.org/pipermail/centos-announce/2017-Sept... [1]: https://seven.centos.org/2017/09/updated-centos-vagrant-images-available-v1708-01/ https://seven.centos.org/2017/09/updated-centos-vagrant-imag...

Crontab 9y ago
> These packages are not part of RHEL proper and each one has to be researched and an appropriate package found Given that Centos is now owned by Redhat, isn't this really just theatre?
- bonzini 9y ago
  Pretty much, but not in the sense that you mean. CentOS does the right thing in keeping a clean room. However, it's theatre to insist that RHEL as distributed need not self host. (I am on RHEL engineering, and fought unsuccessfully to include some package in RHEL6---unsuccessfully because "customers don't need it"---only to see it included in RHEL7 because some customer requested it...) That said, it's a dozen packages so it's not a huge deal.
  - jlgaddis 9y ago
    > ... unsuccessfully because "customers don't need it ..." And yet, as I noticed (yet again) earlier today while working on kickstarts, it is impossible to get rid of some packages that I will never want installed because they are listed as required dependencies when they really should be, at most, "recommends". For example, I'm currently putting together a kickstart file for a minimal "desktop" installation on ThinkPads -- well, as minimal as RHEL will let me, that is (which isn't saying much). There are numerous packages that I absolutely do not want on these systems but that I am stuck with, such as: bluez, cups-{libs,pk-helper}, gnome-bluetooth{,-libs}, gnome-online-accounts, libsmbclient, oddjob-mkhomedir, samba-{client-libs,common}, tigervnc-{license,server-minimal}, and probably some others that I'm forgetting at the moment. A few of these -- the Bluetooth-related ones -- are particularly relevant [0], yet I can't uninstall these packages (or, better yet, avoid installing them in the first place) without rpm/yum insisting on also taking out dozens of other, critical packages (no, "--nodeps" is not an acceptable solution). Yes, I can "hack" my way around it (disabling services/unit files, etc.) but it would be great if one didn't have to do that in the first place. Sorry, this wasn't directed at you personally, but rather Red Hat in general. > ...fought unsuccessfully to include some package in RHEL6 ... On a side note, I'm now curious which package you were referring to. </rant>
    - bonzini 9y ago
      The ACPI assembler if I remember correctly. BTW, an easy way to block Bluetooth is blacklisting the kernel module. RPM only got soft dependencies recently, so maybe you can check whether Fedora uses them for Bluetooth userspace packages and similar.
ams6110 9y ago
> This makes using RHEL/CentOS an option for those who prefer newer software over long-term stability. But there are already plenty of distros that provide that option. Long-term stability is precisely the advantage of RHEL, for people who value that.

nailer 9y ago

Cool. It has ALPN support, needed for HTTP/2 in Chrome. Also no ifconfig by default, which is good as it hasn't worked properly on any distro for a decade and people keep using it.

101km 9y ago
As a public service I'll just leave this here: https://dougvitale.wordpress.com/2011/12/21/deprecated-linux-networking-commands-and-their-replacements/ https://dougvitale.wordpress.com/2011/12/21/deprecated-linux...

forapurpose 9y ago

As a user who wants an OS that 'just works' so that I can work on other things, why wouldn't I choose CentOS over Fedora for my laptop?

xena 9y ago
driver compatibility.
- chowyuncat 9y ago
  RHEL provides a stable kernel ABI. "Once a symbol has been introduced into the Kernel Application Binary Interface (kABI) for a particular major release of Red Hat Enterprise Linux it will not be removed, nor will its meaning be changed during that kernel major release's complete life cycle." SLES is another distribution with a stable kernel ABI. Additionally, in practice a module (driver) that ignores the kABI will usually work for all patched kernel versions on a given minor release (~service pack). e.g. A minor release 6.X introduces a new kernel X' (2.6.32-X'.Y) and a module built against X'-0 will work for all Y.
  - noselasd 9y ago
    What xena means is that Fedora comes with more and newer drivers compared to CentOS, this means there are new hardware that might not work with CentOS, but does work in Fedora. (CentOS/RHEL 7.x is new enough that this isn't a big issue yet, but it normally does become a pain point the older the RHEL/CentOS major release gets - there are a lot of drivers that does not get backported to the RHEL/CentOS minor releases)
TheDong 9y ago
You wouldn't. CentOS is aimed at servers which are maintained by sysadmins who know RHEL well (e.g. RHEL certified), or who just want really friggin' stable shit. A developer usually wants someting that has a tradeoff closer to "newer" on the "stability vs upgrades" tradeoff. For a dev laptop, absolutely use fedora over centos.

smegel 9y ago

Do they not call it CentOS 7.4? I thought they did for the 6-series releases.

rconti 9y ago
I'm not sure of the exact specifics, but they have dropped the minor version numbering in favor of, I guess, build number. You'll find that you can no longer rely on a static repo for (say) 7.3 to stay static and instead 7 will be symlinked to latest.
orev 9y ago
The downloads are all under 7.4.1708, so the 7.4 is still there. They don't talk about it much because it's not the same as what RHEL calls 7.4. RedHat still patches older point releases, while CentOS does not so you always need to track with the latest to get updates.

emmelaich 9y ago

One major change is the move of various Kubernetes daemons to docker containers rather than rpm. Upstream change log here: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux_atomic_host/7/html-single/release_notes/ https://access.redhat.com/documentation/en-us/red_hat_enterp...

pharaohgeek 9y ago

I'm still waiting for Swift support on RHEL/CentOS. It's great that Swift finally runs on Linux, but my company has standardized on RHEL, so we can't run Ubuntu to get Swift support. If RedHat rolled out RPMS for Swift that would make my life SO much easier!

Tomte 9y ago

And as usual: let's shame CentOS for their embarassing manuals page and their unwillingness(!) to fix it: https://www.centos.org/docs/ https://www.centos.org/docs/