Hacker News Reader

Comment by zelly | Hacker News Reader

It's compatible with cgroups v2 unlike the standard Docker. If you're using Fedora, you have to add a kernel parameter to Grub to use cgroups v1 instead.

RedHat seems to be pushing a standard ecosystem for Linux: systemd, Wayland, SELinux, GNOME, and now maybe podman. I've been on Linux for a while; it's a welcome change from all the fragmentation I'm used to. Whereas others try to work around the kernel and implement their own things in parallel (see: Canonical's AppArmor, LXC, OpenZFS), RedHat just goes with what Linux already has like SELinux/cgroups v2/btrfs, which I think is more likely to last and just feels better. If RedHat goes away, I'm fine since I'm ultimately only relying on Linux features. If Canonical goes away, then I'd have to switch to a different stack. That's probably why government, enterprises, Amazon, etc. still prefer RedHat.

View on HN

What you are noticing is the RedHat “upstream first” policy, and it’s very practical. They try to minimize RedHat specific modifications and instead contribute improvements directly to the original projects.

This reduces the amount of code they are responsible for maintaining, and everyone involved gets the benefit of open source collaboration.

They have a blog post about it here:

https://www.redhat.com/en/blog/what-open-source-upstream

> RedHat just goes with what Linux already has

More like, Redhat/IBM defines what Linux has simply by paying most Linux devs, and of course they take advantage of it in userspace and sys management.

cgroups/namespaces, systemd, gnome (and it's integration with systemd) plus others are two-sided swords: one one hand they create new functionality, but on the other hand the price to pay is concentrating Linux know-how in one place, and greatly diminishing portability of Linux apps vs other Unix O/Ses and even other Linuxes that don't want to go with the program of absorbing ever more functionality into kernels and system frameworks for no real reason other than monopolization.

Unix was designed as a simple portable operating system in very short time. With 30 years of development, the situation today could also be interpreted in such a way that Linux devs just can't stop to add code. Time will tell if Linux can be maintained if the original generation of devs step down. I'd feel more comfortable if we've let kernels stay minimal rather than becoming kitchen sinks. Apart from better portability, this would've also enabled younger devs to start from scratch rather than having to maintain daddy-o's monstrosity.

>and greatly diminishing portability of Linux apps vs other Unix O/Ses

Thank's god for that! An OS should build on its strenghts, not be a least common demoninator for portabillity's sake. If that was ok we might just as well just use one OS

Indeed, for me the best UNIX experiences that have been created so far have been NeWS and NEXTSTEP (macOS), and I wouldn't mind if Linux would just standardize on one stack as well.

Having used several UNIX flavours since 1992, I can't relate to what is simple in UNIX, unless you are speaking about V6.

As a 23 y/old younger (well, young-ish) dev, it strikes me that this isn't anything new. Old commercial solutions since nearly the beginning have been predicated on proprietary solutions specific to some vendor's UNIX based OS. HP-UX, AIX, even back to the really early commercial releases of v7 all seem to have a common theme of having that unix core but with a lot of nice features added on, typically with pretty insane and convoluted frameworks. Tru64's clustering, AIX's management interface, all the competing UIs and management interfaces. All nice features deeply integrated into a proprietary solution as a form of vendor lock-in.

To your point, it seems like eventually this ends poorly for the incumbents, when they become too bloated and too difficult to extend or modify, since you have to work around some over-engineered high-availability process clustering to touch anything.

In Linux's case, I think the kernel itself is actually fine, but the user land is increasingly tightly glued to an increasingly convoluted set of RedHat stacks.

I mean, it always has -- RedHat made the modern posix threads library, Linux's PAM, and several other core parts, but at least those were pretty modular and "unixy", by comparison to the monolith being developed now.

Anecdotally, I've worked with developers at Redhat and Canonical, and the Redhat developers had passion. They really believed in open source and the linux community. In comparison Canonical seemed like Just Another Software Company to me.

My experience has consistently been the opposite.

With Redhat, Canonical, or both?

This sounds anecdotal to me.

As anecdotal as the person he is replying to.

I mean, yeah, thats what I said right?

Yeah so? Parent (and grandparent) talked about their direct experience. That's by definition anecdotal.

Woosh

I think governments prefer redhat because they are consistent and they accept gobs of cash to promise security patches to software that are past their support window.

Governments also prefer Redhat because they early on and continuing today have shown a commitment to the market by investing in getting their products certified to meet government required standards including developing the required capabilities when not already available in the Linux ecosystem, developing documentation and software to assist deploying systems in a manner consistent with government security requirements and participating in conferences, working groups, interoperability tests and other government targeted or sponsored forums.

Some other Linux vendors now also do so but started much later and even now do so to a much lesser degrees.

We have our LTSS -> Long term support at SUSE. Just in case you're a big government that wants to throw us lots of money.

Off-topic, but what’s you experience working at Suse? I know a former employee, and what he told me sounded hellish.

I'm an Ex-SUSE employee, and I quite enjoyed it - since I left a few years ago, I don't think there's been any turnover in my group since.

I know two people who work or recently used to work at Suse and they liked it quite a bit.

I love it. Not that it doesn't have it's issues. I've been here 10 years now though.

I don't know about the gobbles of cash, but I'm pretty sure Canonical supports Ubuntu releases way past EOL for paying customers - they call it the ESM (Extended Security Maintenance), which 'provides important security fixes for the kernel and the most essential user space packages in Ubuntu'.

Depends on your definition of support I suppose. Redhat employs so many more low level engineers they can generally get you a z stream patch or something to fix a legitimate bug. Canonical is an exceptional marketing company, but I've found their engineering to be lacking when it comes to enterprise. As someone who's worked as a linux monkey for companies who pay Canonical for support and for companies who pay Redhat for support, I've always found the Redhat support to actually solve the root cause. When we filed what we thought were legitimate bugs with Canonical, the common response was just to "upgrade to the latest version of Ubuntu". When we asked them to confirm that doing so actually fixed our problems we just got crickets.

It tends to also be in the opposite direction, big expensive enterprise software is supported on redhat forever and ever. And the issue isn’t just security updates, but full software and hardware support for the same stack for many years.

Lots of people don’t want to recreate their stack every few years for the latest cool thing.

Ubuntu ESM is 8 years, significantly shorter than RedHat's 12 year maximum.

Pretty much this, they know how the game is played and they play it.

FWIW, Docker support for cgroups v2 is coming in 20.10 AFAIK

Red Hat deprecated BTRFS in its products (and does not have anything like ZFS).

Its focuses on XFS from 1993.

Its Stratis idea is just a joke comparing to what ZFS is.

They should finally admin (like Canonical) that OpenZFS is the way of future filesystem for now.

Linux world should put their religion (GPL) aside here.

Besides above filesystem 'issue' the PulseAudio, systemd and SELinux are not hated without reason ... many people just 'love' what Lenny has to offer.

btrfs is depreciated in redhat distribution

They just made it the default in fedora. It is likely not deprecated for unreleased RHEL versions

I just installed Fedora yesterday and was pretty confused at that part, after reading many articles and posts about RH dropping btrfs.

Fedora is a community distribution despite what many think. It is not controlled by RH in any way.

"Fedora is developed and sponsored by Fedora Project and Red Hat."

https://www.redhat.com/en/topics/linux/fedora-vs-red-hat-ent...

Both of you are right. Red Hat pays for Fedora in a lot of ways, but does not control it. There are obviously a lot of personal and professional relationships that gives Red Hat influence over Fedora, but the purse strings are never used to control it.

*deprecated

On the other hand isn’t btrfs becoming the default in Fedora 33, thus eventually making a comeback in RHEL?

Yes that may well happen.

It's also noteworthy that the BTRFS change was driven by community members, mainly from Facebook.

We use it as the default at SUSE. In SLES and openSUSE.

If you want to use btrfs on RHEL8, you still can: go to https://elrepo.org/ and install elrepo-release, then install kernel-ml from their -kernel repo and btrfs-progs from their -testing repo.

... at which point you lose the support you're paying for from Red Hat, thus defeating the purpose of using RHEL in the first place.

So if you want to use Btrfs, you might as well use it on something besides RHEL.

Running an unsupported kernel doesn't mean that support won't help you at all. It just means they won't help you with kernel-related issues. There's still a lot of value in support for the rest of the system.

I have heard that they will still try to help you, they just won't guarantee it works on btrfs.

Reply on news.ycombinator.com