Hacker News Reader

Comment by mrmondo | Hacker News Reader

I wonder if it'll actually finally have useful a SELinux implementation and policies like they promised they'd have before releasing Jessie (8), or remotely up to date clustering software such as pacemaker, corosync, ha resource agents and DRBD which is pretty much unusable in any modern in 7, or 8. Jessie (8) was such a flop of a release so many people and business's I know that were loyal to Debian moved to CentOS 7 + EPEL/Elrepo with great success and given how hostile the Debian community (mainly packing community) has become over recent years and how helpful and inclusive Fedora and RHEL's community and bug tracking ecosystem has become I can't see many of us moving back.

View on HN

SELinux is currently packaged in Stretch and doesn't have any release critical bug reported. Same for pacemaker and corosync. Dunno if it's actually good enough, but Debian is a community distribution and if nobody cares enough, nothing will be done. If businesses rely on this aspect, they should find some time to help.

Seconded. Migrated from Debian to Fedora after Jessie. And to CentOS on my servers. Stretch isn't as bad now, but... I don't think I'm switching from RHEL for a long time. So much just works out of the box, including SELinux, and all of the documentation seems to be security-focused.

idk. I have been recently setting up some new RHEL/CentOS systems both at home and work. While the base system and documentation both feel really good, the experience still has been somewhat frustrating to the point that I'm moving to Ubuntu LTS at home. The biggest pain point is the amount of stuff that is missing from the main repos, like:

* Python3

* Nginx

* ZFS (this I can understand)

* LXC

RHSCL is supposed to alleviate the pain, but using them also loses one of the big reasons of using RHEL in the first place because RHSCL releases are only supported couple of years. For example for Python3 the RHSCL version is 3.5 and supported until May 2019; even Python.org supports 3.5 series longer than that!

You would be better off with Ubuntu LTS or Fedora at home. For client usage, RHEL will always feel old within a couple of years of its release. That's just how fast things move on the client side. You may find something like OpenSUSE Leap a better fit since it is a hybrid between LTS and rolling releases.

But it's not that it is old, that I planned for and can live with. The stuff I mentioned was already included in e.g. Ubuntu 12.04 which was released two years before RHEL7 and in Debian 7 which was released a year before RHEL7.

All the stuff that you mentioned is already there in some capacity. python3 is at 3.4 in the main channel. SCL would likely have newer versions. SCL is mostly for development. I wouldn't expect crazy long support for the SCL stuff. That's by definition though. Use the main channel for long support. nginx is in epel. zfs is in the zfsonlinux repos. LXC used to be in main channels, but they deprecated it in favour of docker. You can still get it from epel. RHEL + EPEL should cover most of the useful stuff. There are also some multimedia and nvidia driver packages packaged by negativo17 if you really need them.

> python3 is at 3.4 in the main channel

Sadly, nope. Only in EPEL.

> LXC used to be in main channels, but they deprecated it in favour of docker

Docker is hardly a drop-in replacement for LXC. In Debian I can just have both and make my own decisions.

> zfs is in the zfsonlinux repos

Which reminds me of another missing piece; DKMS

Overall your comment feels to confirm my view; RHEL/CentOS installations tend to end up being a frankestein patchwork of different repos with varying degree of support.

Please don't take me as a RH/CentOS hater, I do still plan to run CentOS VMs for the software they do support. But I've now learned that I can't easily use it as a default go-to system to run whatever springs to mind.

> RHEL/CentOS installations tend to end up being a frankestein patchwork of different repos with varying degree of support.

Yes, that is kind of true if you need to push the boundaries of RHEL into client/workstation use. However, I've found EPEL to be quite stable and mature. I would say that the quality of packaging is on par with Ubuntu's universe and other auxiliary repositories. Ubuntu makes it less obvious that their non-core packages are not actually supported. EPEL fits sort of in a similar category.

Isn't that what EPEL is for?

> given how hostile the Debian community (mainly packing community) has become over recent years

Could you clarify? What changed wrt packaging?

I don't know what the above comment refers to, but the drama around the live cd subsystem left a bad taste in my mouth, and the decision to only support systemd got me to switch away.

There were claims that Canonical subverted the Debian voting process by having too many committers, and then forced through votes that let then treat upstream debian as a dumping ground for unreviewed Ubuntu breakage. (And also force out existing subsystems, etc).

I am not sure how true the allegations are, but I am hoping that Shuttleworth helps improve the situation now that he has re-taken the helm at Canonical. The changes I've heard of seem positive from an outsider's perspective. Concretely, they had that HN thread, and got rid of unity (I am happy as an end user, but am sad for the developer team).

Reply on news.ycombinator.com