Hacker News new | comments | show | ask | jobs | submit login
Release for CentOS Linux 7 (1708) on x86_64 derived from RHEL 7.4 (centos.org)
99 points by gtirloni 5 months ago | hide | past | web | favorite | 38 comments



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-Sept...

[1]: https://seven.centos.org/2017/09/updated-centos-vagrant-imag...


> 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.


> 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?


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.


> ... 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>


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.


Yeah, the "bluetooth" module is one of several that I disable ("install bluetooth /bin/true" in /etc/modprobe.d/disabled.conf) but -- from a paranoid security perspective -- I'd much prefer to not have the software installed in the place. I also have BT disabled in the BIOS. Many, many years ago I'd compile my own kernels and leave out all the stuff I didn't want but that's not worth my time nowadays.


It's still extra work that must be done in order to push out a release -- and by a couple of folks, at an already busy time. It's not like they have all of the Red Hat staff assisting them with it. Personally, I'm pretty impressed that they manage to get releases out as quickly as they do (except for, perhaps, the .0 releases; I wish those dropped quicker but I certsinly understand why they take as long as they do).


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_enterp...


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!


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?


If it's an old laptop, you might not. But, I can't run CentOS on my laptop as a third of the hardware, including the GPU, wouldn't work. At least, I couldn't when I got it.

But, Fedora is pretty darned good about Just Working, in my experience. Because my laptop was a super new design when I got it, things were a bit shakey (I ended up using the Windows it came with for about a month because GPU drivers weren't working under Linux and running at any high res caused it to lock up frequently). But, once I was able to get all the right drivers and everything was working, I haven't had to do anything, even through a Fedora 25->26 upgrade (I have the nvidia drivers, but I got them from the rpmfusion-nonfree repo, so they update in the normal way).


I ran Fedora on my home server for years -- and found the upgrade process between FC's really difficult over time. Stuff I'd configured and had working would break. FC upgrades would take days of fiddling to get stable again. Not upgrading left me open to security vulnerabilities.

Some examples are major changes to config files by certain apps - like rsyslog or squid. I also went through the transition from init.d to some other one I can't recall and then to systemd.

But I also had a pretty heavily configured/customized system...

In the end, I decided it was too bleeding edge for continuous upgrades in my specific environment.

I switched to CentOS7 and I keep my configuration in ansible scripts. I also use EPEL and ELRepo for the mainline kernel.

But if you're just running a laptop desktop ... and you're willing to reinstall at major revs, or you just don't customize it that much, yeah, give it a try!


Been using Fedora since 24 and every upgrade went flawlessly.


I don't remember what I was at, but I think I'm talking single digits to teens. It also might have migrated through rhel free to FC.

It was a very battered OS when I was done :)

Again, Fedora is great -- but for my use case, I wanted something with a longer life cycle. CentOS7 is great!


I'm a centos user, not fedora, but from various threads here and elsewhere I gather that most people agree upgrading fedora was a garbage fire up until like 20 or something and since then it's been fantastic.


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.


I'm running a RHEL 7.3 desktop to type this comment on with 3 30" Dell monitors. I'll have you know that CentOS 7 and RHEL7 make a fantastic desktop.


>or who just want really friggin' stable shit.

Critically for potential desktop users, this means you can't necessarily expect things like touchpad drivers to work. Hardware support, especially consumer hardware support, can take years to trickle into centos releases.

That stability may well be deeply desirable in a server that has to undergo security audits every so often, but it won't help you install it on a laptop.


> consumer hardware support, can take years to trickle into centos releases.

Not necessarily, after all non-technical Red Hat employees run RHEL on bog standard Lenovo ThinkPads and model choice includes pretty recent hardware (and even some models with Optimus, lately).

Technical employees mostly run Fedora, though some use RHEL and others are die hard Debian or Gentoo fans.


Many ALPS touchpads (very common) should work well in CentOS 7 these days. Back when I worked at Red Hat, making that happen was a side project that had good results.

Main due to my using a Dell laptop with an ALPS touchpad at the time, and getting fed up with the crappy support it originally presented. ;)


I haven't used Fedora in years -- how does Fedora make it easier for people who don't know RHEL well, vs. CentOS? (I had expected the sysadmin experience to be very similar.)


Not just to be contrarian, but because this is how I have lived for a while... Why wouldn't you run Debian Sid on your laptop?

(FWIW I have also experimented with stable versions of Debian and, when I am not seeking the newest software which has been the case in the recent years, it works just as well for me as unstable distribution. But FWIW2, the Debian Sid on your Workstation paradigm has only bit me twice in nearing twenty years, and both times were valuable learning experiences.)

My advice would be to use whatever you're most comfortable with. With an addendum to use whatever you have running in production if possible, because that will maximize the chances that you discover a bug in production before it bites you hard.


RHEL (and thus usually centos) and Ubuntu (not Sid, not debian stable) are the two distros that companies distribute for. It's rarely but occasionally important depending on what your doing with your computers.

As to why not to use CentOS/RHEL: they're not supported by half the companies that Ubuntu is so if you buy commercial software (indie video games at least) Ubuntu is the better option.


Ubuntu is based on Debian, tho. I've used Ubuntu in production for years (because that's what companies use), and that hasn't dissuaded me from using Debian on desktop, or on my non-critical servers.

I've seen enough things that are "fine in sid" but broken in every Ubuntu distro including next, that your argument against Debian does not sound convincing to me.

Yeah, things can break in sid, but are you better off using Ubuntu Next? I don't know anyone who would seriously argue this.

Nobody develops on or targets Ubuntu Next that I am aware of, unless a release is imminent. Lots of developers pay attention to Debian Sid all the time, because that's where new releases land first (maybe you find them in rawhide first if the developers are RH-focused, I wouldn't know.) Debian Sid actually has the lowest barrier to entry for release managers, the changes just need to successfully make it out of Experimental.


I mean I certainly haven't done any sort of side by side testing, I just generally assume the various Debian releases (stable, testing, sid) are--at any given moment--not quite in-sync with whatever Ubuntu is doing with it's releases, and so assume problems are more likely when downloading shit off the Humble Store or whatever.

I'm sure they're usually close enough that I'm not going to dispute anecdata though.


No certainly! I never had a drivers issue when I was an Ubuntu user, to be sure (not one that was more solvable on Debian at least) and I have done some Linux games, I agree it was much easier after Ubuntu landed.

Hardware makers target Ubuntu and game makers target Ubuntu. Libc differences can give you a real hard time when it comes to running binaries that are not compiled on your target OS. I have definitely seen that! It's no fun and you may not be able to solve it based on strange timing of libc versions with respect to the Debian 2-annually release cycle. Game developers certainly don't care what versions of libc made it into Debian stable or Debian testing these cycles, so you may be out of luck for two cycles in a row and it's no better in Sid. I mean, this is anecdata too. But it's real and if you haven't had this problem, it's because you didn't use Debian, but used Ubuntu instead. I suspect RHEL/CentOS users didn't have this issue either for one reason or another, and Fedora users neither.

But it sure is a problem in Debian, if that's what you're into. To clear things up if it sounds like I'm talking in circles, I ran my share of games on Debian and I had definitely hit this type of issue, and ultimately failed to solve it for myself.

If I was using closed-source software or intending to play games, you'd get no disagreement from me I'd rather do it on Ubuntu, and that's a fundamental disagreement with Debian policy and any either closed-source or other than rolling release target (eg. one-and-done) game developer or realistically any other code system that needs either kind of g/libc as a specific version of shared library to link to.

You may genuinely be onto something here. But in my production systems, I tend to target using 100% open solutions, so I'm not sure I would have ever run into this at dayjob. Farewell!


I used sid on my laptop for several years with similar results. These days I use testing. Testing is usually only behind sid by a few weeks, but I've found that the more annoying breakages tend to get resolved in sid before anyone in testing sees them, so the already infrequent headaches are basically non-existent now.


They must have improved testing then, or improved their processes, because the last time I evaluated testing it was properly "half unstable, half unusable"

Admittedly that was a while ago! Testing, depending on what part of the release cycle you are in, can be a few weeks behind Sid or significantly more, though. Most upstream release managers probably pay some attention to the release cycles nowadays so, with luck you wouldn't notice this too much.

(The start date of the testing freeze is well publicized in advance and known, so competent release managers should avoid potentially breaking/broken updates immediately before that date, if I remember correctly how this works.)


driver compatibility.


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.


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)


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


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.


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.


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


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.


As a public service I'll just leave this here: https://dougvitale.wordpress.com/2011/12/21/deprecated-linux...




Applications are open for YC Summer 2018

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: