Hacker News Reader

Comment by bovermyer | Hacker News Reader

I'm very glad that SUSE bought it and not Red Hat (or Microsoft).

This might give SUSE more inroads to the North American market, considering it's largely a European player at this point.

View on HN

I was actually a bit behind on the current SUSE ownership: last I remember was it getting acquired by Novell and entering into an agreement with Microsoft. I was thus confused by your comment.

For those like me, SUSE was sold off again in 2018 after like 5 acquisitions, and has been an "independent business unit" for a while now.

TL;DR: https://www.eqtgroup.com/Investments/Current-Portfolio/suse/

But we are mostly independent now. I.e we choose the directions.

> mostly independent

Sounds like something Red Hat could say too...

SUSE's owner (EQT) is not doing anything in the IT sector themselves, unlike RedHat's owner (IBM).

With RH/IBM IBM certainly wants to leverage the RH brand and separate it a bit from the IBM brand, while leveraging customers and technologies across the company.

Suse's current owner won't have much synergies between Suse and their real estate business (except that Suse probably rents office space there) You don't do deals like "rent an apartment, get a Suse license for free" Thus Suse, under obersight can likely set their business strategy and objectives more freely.

> You don't do deals like "rent an apartment, get a Suse license for free"

Well maybe they should? That'd certainly sweeten the deal for me.

SUSE is owned by EQT which is an investment organization. They basically provide the capital and resources to grow a business and then get out when it reaches a target. This is very different from IBM/Red Hat.

interesting...why a real estate group invest in software company?

It's a private equity company.

Why would Red Hat (who created OpenShift) want to buy an inferior competitor?

You may well ask, but you are far, far too late.

Red Hat already bought CoreOS in January 2018, some 18 months before IBM bought Red Hat.

The question would have been more relevant to either of those.

CoreOS was not a direct competitor to RHEL, it was intended to be a "next-gen" rearchitecture of the OS. No one was going to seriously consider using one in place of the other; if you were considering CoreOS, then RHEL was already off the table.

It replaced Project Atomic for them, some parts from atomic ended up in core os though.

You can buy an "inferior competitor" and integrate their feature set into your own products, and end up with a much better integrated solution for your customers, which will strengthen your business.

But switch "inferior" to "superior" and your question makes sense. Red Hat's products mostly suck balls. I can't think of a single one which has been an enjoyable experience to use. People paid for them because they were the IBM of the Linux world.... And now they're the Linux of the IBM world.

Or people just trust Red Hat for being always "heart, mind and soul" of the community of contributors that makes open source great. And keep doing the same thing, that inspired many others such as SUSE, Rancher, etc.. and IBM :)

Red Hat is great - they have done some great things, however -

Heart, Mind and Soul of the Open Source community is possibly a bit of hyperbole.

and - SUSE is (slightly) older than RedHat, so I am not sure you can say RedHat inspired them :)

IBM was inspired by RedHat's earnings (pre acquisition, open source in IBM was .... interesting ... ) and their ability to have a relevant product in the cloud space.

It wouldn't be Red Hat as such... it would have been IBM. And the same question can be asked there with IBM Cloud Private and the UbranCode suite.

Look at it from IBM's perspective - battling business units are good and one of them will certainly be the best.

... and a potential competitor is no more

OpenShift is expensive and requires a significant O&M investment. If you want to use standard tools it’d be nice to have a managed standard Kubernetes option without paying for a lot of complexity your teams don’t want.

OpenShift Container Platform removes the need to build your own platform around Kubernetes, which would also require a significant O&M investment. If you don't want that, there's OpenShift Kubernetes Engine: https://www.openshift.com/products/kubernetes-engine

> OpenShift is expensive and requires a significant O&M investment. If you want to use standard tools it’d be nice to have a managed standard Kubernetes option without paying for a lot of complexity your teams don’t want.

The parent's point though is that this isn't the space IBM wants to be in. They're in the business of selling high margin, enterprise-y stuff that includes all the bells and whistles, so there's no reason for them to gobble up something like Rancher (RHAT's OpenShift solution is what they want to be selling already).

> If you want to use standard tools it’d be nice to have a managed standard Kubernetes option

What standard tool doesn't work on OpenShift? It's certified to have 100% compatibility with Kubernetes, it just adds stuff, doesn't it?

It takes away privileges which arguably is a good thing but some things that require root containers wont't run. They pass the Kubernetes conformance suite only by removing those constraints.

And you can do the same for your environment. You can run root containers on OpenShift, it's a settings, not a baked-in compiled choice or something similar.

That is true. It's a tradeoff when you consider to turn off SELinux, too, however.

That's not true at all. You can read their CNCF results yourself, nothing is disabled. And the conformance tooling works around these constraints by defining their own PSPs.

It would help if you provided a link to the CNCF results.

From what I see in https://github.com/openshift/origin/blob/master/test/extende... there are additional policies granted (search for "Disable container security").

Yes, to run tests that root your whole cluster, the test running for conformance grants “root your cluster” permissions.

I occasionally regret the defaults we picked because people get frustrated that random software off the internet doesn’t run.

That said, every severe (or almost every) container runtime vulnerability in the last five years has not applied to a default pod running on OpenShift, so there’s at least some comfort there.

To grant “run as uid 0” is a one line RBAC as assignment. To grant “run as uid 0 and access host” is a similar statement.

https://github.com/openshift/origin/blob/master/test/extende...

I think there are some things which are either disabled or complicated by policy, not to mention the lag between Kubernetes updates shipping and OpenShift updating, but I was more going at the angle of paying for things you're not using. OpenShift's license costs are enough that you really have to justify it based on those services. The people I know who've avoided it did so because they couldn't justify the price when they mostly wanted Kubernetes but their teams had no interest in going away from their current build tools.

It's also open source.

Yes, but then you’re still supporting the additional platform components. If you’re using those services, that’s reasonable but if you have other tools you might reasonably want something smaller which doesn’t require you to learn and support things which you aren’t using and which delay upstream k8s releases shipping.

Reply on news.ycombinator.com