Red Hat Cloud Forms migrating to IBM Cloud Pak | Hacker News Reader

Red Hat Cloud Forms migrating to IBM Cloud Pak

blog.christophersmart.com

140 pointstheonelinuxway119 comments

I work at Red Hat and I think your conclusion here is wrong, but I understand how you arrived there. I'm not involved with Cloud Forms directly, but its future was in flux before the IBM acquisition and making it part of the IBM Cloud Pak means that it will have a solid future with resources from IBM and Red Hat. And better yet, happening in the open source ecosystem.

Agreed. I don't think this is something that came from IBM... This is rooted in decisions that were being made before the acquisition was even announced.

Disclaimer: I work for Red Hat (but not on Cloud Forms)

I don't have any inside info, just grapevine and rumors, but this is not that unexpected and doesn't have a ton to do with the IBM acquisition either. Cloud Forms is complicated to use and not that popular. Its head was already on the chopping block.

I am not worried that IBM is going to start killing Red Hat products or "cannibalizing" them. IBM is going to adopt more Red Hat tech, and Red Hat may start using more IBM stuff internally, but I don't see big changes coming.

Disclaimer: I interviewed/hired/work in the same group with FreedomBen at Red Hat.

There's been lots of internal talk over the last 3 years of what to do with CloudForms. The customers who love it, REALLY love it and do amazing things with it. And our internal training group had the world's largest CloudForms installation(s), so we really ate the dog food. But you really do need to be of certain sizes to "grok" CloudForms value proposition.

That’s a dramatic title. Geez.

All of these console of console products are way complicated and expensive. IBM needs to keep theirs because it is used for their power platform and zlinux.

People who want to do the single pane of glass thing are probably better off with VMWare if they want to move workloads around or terraform if they want a recipie type system.

Openshift is the platform of choice for IBM products on linux right now.

The new IBM Cloud Paks run on Openshift (both for x86 and system Z hardware).

(Openshift)

Really disappointing to start seeing this after all the assurances that were made during the merger about strong support for open source.

But are you surprised?

Absolutely not, thankfully I fully believe that somebody else can take the reigns if things get dire.

I’m not terribly concerned over CloudForms, to be frank it’s an extremely complicated product that requires WAY to much work to use compared to alternatives like Terraform, Pulumi, etc, you might as well do some heavy handed customization of Service-Now for all the effort it requires in comparison.

If I start seeing them fuck with more core offerings I’ll be more concerned.

This sort of thing is inevitable, though, regardless of assurances.

This happens every single time. Founders that don't want to see this can't have their cake and eat it too. It just doesn't work like that.

Well, if you have a reliably profitable business, https://en.wikipedia.org/wiki/Dividend_recapitalization and similar lesser-known options can allow founders to retain control while providing liquidity. You can't have your cake, eat it too, and have the cake be made out of air... but you can pick two out of three.

This is true, but many(most?) of these companies aren't in that strong of a place yet. Red Hat might have been but a side effect of the investor driven rocket growth model is that even if you're setup to have a strong company, you often don't have the position to make these kind of deals.

Assurances are as good as the penalties attached to not meeting them.

Who made the assurances? Was it IBM people, or did the message come from the old C-suite of Red Hat?

This is a common trick. All the transition promises come from people who won't be in the org chart in a couple years. Nothing changes for most of the lock-up period during the transition, and as soon as that person is gone or a lame duck, the rules begin to change.

And what are you going to do? Complain to the people who made promises they no longer have the political standing to enforce, or in fact have already moved on?

Interesting, is the acquirer or acquired that leaves or is let go? Guess you are alluding to redhat.

The acquired. Near as I can tell they are made verbal promises and asked to relay them to their employees to calm things down. Once the dust settles these executives are often superfluous. They got their exit, why stick around instead of moving on to something new?

Now there is no person accountable for the promises the former employee/boss made. Therefore, the promises do not exist.

Exactly this happend at a former employer who got sold; employees were promised a lot, streamlining and new projects were put in motion, the buyers took and integrated the half of the company they were interested in, and then they repacked and resold the rest to the next competitor. The show however was always a good one, with C-suits flying in on private jets to "represent and reassure".

Assurances from corporations and their representatives, barring hard contracts beset with penalties, are not worth a dime. Moot, hot air, non-actionable.

I've not found anyone who has used them both, but if you're worried about Cloud Forms going away or dropping things, and don't want just ManageIQ, maybe look at OpenNebula. It seems to be something like tractable OpenStack+ManageIQ, from the point of view of someone who hasn't either of the latter. https://opennebula.org

I'd be interested if anyone can compare and contrast.

Who really uses RedHat? (serious question) ..I haven't used it since the 90's and can't evem begin to grasp why they are such a big player. What does it offer that other distros don't?

Actual long term support and stability. It's used in projects which are meant to work for years (medical, infrastructure, power generation, science) and not on electronics meant to be discarded after two years.

I mean, which other distro out there is comparable for these use cases? Even Ubuntu LTS doesn't really fit the bill. The only other OS with long term update commitment is Windows.

My professor always called it "3 O long term support" - looong term support

> The only other OS with long term update commitment is Windows.

This is absurd. Here's just one single counterexample - SuSE, which supports for up to thirteen years I believe https://www.suse.com/support/policy/. Is that longer than RedHat at twelve years https://access.redhat.com/support/policy/updates/errata?

SuSE never took hold in the United States. RedHat did.

The world is bigger than the US.

As a long-time SuSE user, I agree. But the US Government would rather sign an SLA with a US company.

That doesn’t make the GP point untrue (though they also could have toned their post down and made the same point)

As an aside, it’s a pity SLES didn’t gain more traction because it’s a nice alternative to RHEL.

Not entirely true, I’ve worked at a number of suse only shops in the us. Ostensibly I found their support leagues better than red hat.

Several years ago, when I was CTO of an ML startup, we got slapped on the wrist by NVIDIA -- NVIDIA refused to even service our [very expensive GPU cluster] unless we used Red Hat Linux. Apparently none of the Ubuntu releases were supported distros.

So we purchased Red Hat Linux, the exact version NVIDIA mandated for support, and used that, just so we could get a warranty supported machine. I did learn that a whole lot of "scientific computing" happens on Red Hat or CentOS and not debian distros, though I'm not sure why.

This was 4yrs ago, perhaps things have changed now.

Red Hat (and by extension Centos) is pretty much the only thing I see in larger installations like CERN and other big industry. It's mostly connected to the fact that the distribution has a very long paid support for security patches and other bug fixes without demanding whole distribution upgrades.

You don't want your proprietary medical/science software to break on your whole cluster just because you had to upgrade whole Debian to fix a security patch.

Red Hat is prepared to maintain their distribution for far longer than pretty much anyone else outside Microsoft.

Yep, I ended up speaking with HPC folks running big NVIDIA GPU rigs at Oak Ridge and they also confirmed, there is no realistic option aside from Red Hat.

Ubuntu has been officially supported on nvidia GPUs (cuda, really) for over 5 years. What did you need serviced?

https://developer.nvidia.com/cuda-toolkit-60

So yes, CUDA may have been supported for Ubuntu, but we had a 16x K-80 cluster which apparently needs more hand-holding.

There were issues with cards dropping and becoming unavailable during use (turned out it was a slight power-imbalance from the power supply to the cards.) We encountered this within a month of purchase from an NVIDIA-listed Preferred/Authorized Enterprise Reseller. They couldnt fix the issue and escalated it to NVIDIA who promptly yelled at us for even trying to run Ubuntu.

They also noted that if there were overheat-related damage they would refuse to honor the warranty. On a side note, apparently they were very upset at the Authorized Reseller and soon that reseller was no longer on the NVIDIA list of Authorized Resellers.

On a side note, features like GPU-Direct were not even available on Ubuntu.

Did switching to Red Hat Linux resolve your problems?

>> Did switching to Red Hat Linux resolve your problems?

The core issue for random k80s dropping out of our cluster at random times was a power imbalance from the power supply to the cards, so technically no.

However -- for NVIDIA to even diagnose the machine and figure out root causes, they required RHEL (Red Hat Enterprise Linux) before they would help. Secondly, the NVIDIA diagnostic utilities such as "GPU-Burn" were not supported on Ubuntu, so NVIDIA would not even take results from those if we were still running on Ubuntu.

Also, consider the cost. This cluster was a $100k+ CapEx for a fledgling startup. We were not going to risk losing support on that for several hundred dollars of RHEL license costs.

Finally, consider uptime. We purchased this complicated cluster because we were a healthcare ML startup and had locality restrictions associated with underlying medical data and had no Cloud Service Provider local nodes available in said country. If the server was down or -- heavens forbid, needed to be sent back for servicing -- we weren't training models and we were no longer making progress and burning thru valuable runway.

The RHEL license was the a drop in the bucket.

Exactly... The big reasons I've seen people using Red Hat is because most of the core Linux developers either currently work at Red Hat or have worked at Red Hat. So when serious complex issues arise (like in kernel drivers), the support is there and these issues get fixed. These same customers might have been using HP-UX, AIX or Solaris previously and have migrated to Red Hat because of the great support.

Indiana University uses Red Hat for Carbonate large memory cluster. I’m sure many universities still use Red Hat for various projects like this.

https://kb.iu.edu/d/aolp

IU uses RHEL quite extensively, for a variety of projects. Many years ago, Gentoo was actually very widely used (much to my surprise).

Once IU got a site license for RHEL -- one of the first .edu's to do so, IIRC -- they pretty much standardized on that. In addition to all "official" University systems, their RHEL license also covers personal systems for faculty, staff, and even students (my first "real" RHEL boxes were registered to their newfangled Satellite server).

Ironically they are using some sort of Clay Linux and SUSE for the new Big Red III

Non-IT person here but their security updates seem very nice if you are dealing with systems that store sensitive data?

In my experience, Redhat's security updates are slower than Canonical's most of the time.

I don't necessarily equate "slower" with "bad" when it comes to any patches. My speculation is that Redhat may more thoroughly test security updates.

yep -- Centos [which distro I favor for servers] is verrry slow with patches, upgrades, and other additions -- but it is 100% rock solid with no surprises. I use other distros for desktop and various uses, but for servers, I stick with CentOS for stability [or Debian, if CentOS not available]

Exactly, I’ve found RedHat (and CentOS)‘s security patching for be very well tested and packages are often provided with far more sane and safer defaults than say Ubuntu. Additionally SELinux with RHEL/CentOS has excellent coverage and tooling, if you want to harden your servers it’s a good platform.

Meaningfully better than other distributions?

Meaningfully longer. Ubuntu/Debian will demand you update the whole distribution sooner than Red Hat. And there's not a lot of people insane enough to upgrade full OS on a train, x-ray machine, radiation treatment machine, powerplant control system or particle accelerator every two or three years. Especially if software running on them is proprietary and wasn't certified for new set of dependencies.

Exactly. The FDA is willing to dance around security updates but updating the OS completely triggers all sorts of expensive reviews and testing.

Stable updates are nice in general. If you're looking for a distro with old software with bare updates then use RHEL. If you're looking for a modern distro with frequent stable updates then use Arch.

Unfortunately, Red Hat has a successful "Enterprise Edition" (with its free variant being CentOS). A bunch of companies think that's somehow better to have that than to hire people to support general-use distributions.

I've had quite a bit of experience with Debian and Debian-derived distributions, a little experience with CentOS 8. I heavily disapprove of CentOS based on this experience and see it as not just restrictive, but also kind of flaky and shaky.

> A bunch of companies think that's somehow better to have that than to hire people to support general-use distributions.

Why 'somehow'?

Is that not conceivable?

How much does a qualified person cost you? Maybe quarter of a million dollars a year or so all-in with salary, stock, benefits, recruitment cost? How many of them do you need to get 24x7 support? Five of them? That's $1.25 million. You can buy a lot of 24-hour support from RedHat for a lot less than that.

I think it's also having deeper expertise than is available even for that $1.25m/year.

In a previous life, we paid perhaps $25k to a postgres consultancy that did support. They employed some of the core devs, and their promise was that you could escalate to a core dev within perhaps 24h. My employer hit a very weird performance regression when a database crossed a boundary size and having that deep expertise on call to diagnose, figure out a short-term fix, and help get a long-term fix deployed was invaluable and worth every penny.

The type of people who have millions of dollars of hardware under management pay for support so they can get super deep expertise on hand when they need it.

Right - I presume if you pay RedHat enough and you have a serious problem with, say, JRuby, that they ping the JRuby lead and it gets fixed. What's your generalist support person that you directly employ doing? Poking around in the JRuby code base for the first time in their lives while your business is offline?

I would hope those 5 people have other responsibilities besides babysitting the OS all day long every day.

And when you consider that those 5 people have a bigger vested interest in preventing problems than Red Hat does, their cost to value ratio gets less dire.

> their cost to value ratio gets less dire

Yes I'm sure it sometimes pays off and sometimes doesn't.

But it doesn't deserve a mocking 'somehow.'

> I would hope those 5 people have other responsibilities besides babysitting the OS all day long every day.

Then you are unlikely to hire 5 people with deep expertise.

If you only need a deep expert two weeks out of the year (Especially when you can't predict what those two weeks are), it makes a hell of a lot of sense to pay for a support contract, then an in-house expert.

You probably drive a car every day, but you're not a certified auto mechanic. You outsource that expertise, for situations when you need it.

>A bunch of companies think that's somehow better to have that than to hire people to support general-use distributions.

I work for a Fortune 50 and we're one of those companies that made that decision. Having someone to call when things go south is worth every penny. It's not that you can't hire completely competent people to deal with any issue, it's just outsourcing the staffing and expertise needed to do it globally is IMHO cheaper. Even if you have a large company you're still probably gonna have a kernel guy and a filesystem guy and some CEPH guys who are all familiar with the code base. Redhat has a phalanx of people in their employ both contributing code to upstream projects and backporting features to their version of Linux. There's a whole room of kernel guys, filesystem guys, etc, etc, etc. Hiring and keeping that bench of talent happy is someone else's problem when you buy Redhat.

>I've had quite a bit of experience with Debian and Debian-derived distributions, a little experience with CentOS 8. I heavily disapprove of CentOS based on this experience and see it as not just restrictive, but also kind of flaky and shaky.

CentOS 8 may be "flaky and shaky", dunno... haven't used it. But RHEL 5, 6, and 7 have been rock solid in my experience. If anything Redhat was too conservative and I was delighted to see Redhat adopt a different and much more aggressive patch and update lifecycle for RHEL 8. But moving faster does sometimes break things as the mantra for HN will tell you.

While I was in undergrad (early 2010s at a major public university) the engineering machines dual-booted Windows and RHEL. We also had servers running RHEL, accessible via VNC and SSH. I liked the setup, it was very reliable and I found it quite productive.

IIRC, a place I interned during that time also had some RHEL machines.

These days, I have no idea what those places are running.

Our university used RedHat (2018), I think they used it mainly for the enterprise support...

A support contract.

Enterprises.

We don't consider large-scale boring ol' enterprises much in HN; but I wouldn't be surprised (I have no data one way or another) if boring RHEL instances in boring Enterprise/Government datacentres and clouds doing boring things outnumber shiny linux instances in more glossy usage.

What does it offer - support. And support is important when you have something important, when you need to hold somebody accountable, when your core expertise or market value is not patching and fixing your backoffice software yourself, or when you simply need to pass an audit, security policy, regulation, etc.

Also, stability. Not in the software/OS stability sense (although it's pretty good there); but in the "I'm going to put RHEL on my roadmap and invest in education and processes and procedures and documentation and ecosystem based around it, because I believe it'll still exist in 10+ years, which is the timespan some of my projects and certainly my company are based on".

(Edit - I mean, hell; Enterprises run AIX, which many of you kids will have to Google;). And for what it needs to do AIX is freakin' awesome. And for most other things it's wildly inappropriate and ineffective:)

This.

I worked at a defense contractor who was wondering what the next platform was going to be since parisc/hpux was our platform.

We were working with red hat and a bunch of us low level code group had a week long class at redhat on Linux kernal internals) it was excellent, and they higher ups got a happy feeling for the support they offered.

The project was delayed and I ended up leaving that company.

They told us in the class the open secret that centos is basically red hat

This is the answer. I run a shop where most systems are on a 1, 3 or 5 year upgrade cycle and all operating systems and applications get security patches within 30 days of release. It’s considered cutting edge in my industry. That includes servers and every last workstation in the place. Hell, even firmware on zero clients gets updated for security fixes. We are doing multiple major upgrades every year and patching the shit out of dozens of applications on over 1000 endpoints on a monthly basis. The applications are more important than the OS. I can’t be in a situation where I’m forced to upgrade or migrate a major system because the operating system no longer receives patches. It screws up everything - and not just my stuff. Users and corporate trainers don’t like unexpected and unnecessary upgrades either.

There are distributions I prefer for personal projects that I won’t touch at work. An environment like mine is where Red Hat and Microsoft shine, although Microsoft has been a pain in the ass lately with their cumulative updates and 6 month rolling releases on the desktop.

Listen, you are entirely right, but in a backward-looking way. The entire industry is moving in the direction of lambdas/functions and containers. The value of OS support is racing toward irrelevancy.

Which industry, there’s no blanket all-encompassing “industry”? There are still those who don’t live purely the web. Every place I’ve worked at has used RHEL (public university and Film/VFX/animation), and it’s for the exact reasons as written above and sibling/child comments.

Do we integrate with/use cloud and container solutions for services that align with that? Yep. But you can’t just dismiss the foundation, no matter how recursively down the chain you need to go, that it all runs on just because you don’t have to deal with it (“you” in the general sense).

The IT industry. Companies that aren't primarily focused on technology tend to lag years behind the tech sector with tech adoption, but they follow eventually.

Not really. At least not always. No offense, but you sound like someone relatively new to IT (as in a few to several years). Stay in this field long enough and you see history repeating itself. After you witness a few cycles you will have a completely different perspective.

Some of these companies - I’m excluding the ones that are just hopelessly out of date and out of touch - simply have different needs. This is especially true when a significant portion of the tech - maybe the majority - faces inward. There’s not much value in elastic cloud computing when your workload is relatively stable over a period of years and it’s running a bunch of back office stuff that’s not part of your company’s product.

20 years in tech at leading companies here. Nobody is building new workloads on the old model. I'm not talking about fad following startups here.

It is a simplification to the point of being wrong to say everything in tech is cyclical. Some things are in some ways, but for the most part we progress forward, not back.

You seem old and out of touch. No offense. But when people aren't able to keep up they sometimes invent fantasies that their skills will remain relevant forever. That's never really been true unless you actively search out confirmation bias and ignore the vast majority of what's happening in the field.

I stand by my previous comment. I was like you once, thinking everyone else who isn’t on the bleeding edge is an out of touch idiot with an outdated, irrelevant skill set. There’s a time and a place. It really depends on your requirements. Maybe your experience has been more focused so that you haven’t had to deal with much with more diverse requirements. Or maybe you’re not the guy on the hot seat who risks budget, company performance and people’s jobs with tech decisions. Call me a dinosaur. I don’t care. I use the right tool for the job whether it’s new or not.

> The entire industry is moving in the direction of lambdas/functions and containers.

So you're not running a kernel anymore? Interesting.

The main reason why I've seen people at $WORK interact with Red Hat or Suse support is to figure out weird kernel behaviors (both actual kernel bugs and also what turned out to be suboptimal configuration).

Also, do you run your desktop Linux in containers? Desktop Linux is certainly a smaller market than server Linux, but it's large enough for Red Hat to service it.

Somebody owns the bottom of the stack, but that is a smaller and smaller number of people.

At work I inherited the job of maintaining several internal web apps that are run on OpenShift and it has not been a good experience at all. These are the smallest and least important servers that I'm responsible for, but have taken by far the most time.

To be fair, OpenShift should probably never have been used for these low traffic apps in the first place and I could see it being a good tool for a product that anticipates needing to scale up or down quickly. But for a relatively simple CRUD app with modest traffic I haven't seen any benefit to using OpenShift over a simple Linux server running Apache/Nginx, and it adds a lot of unnecessary complexity.

OpenShift is basically Kubernetes LTS edition with some of the sharp edges filed down. It is absolutely overkill for a few small apps, as you said.

Disclaimer: I work for Red Hat Consulting as an OpenShift Architect.

Be sure to utilize your Support Cases, the OpenShift Users mailing list, your Solutions Architects/Sales Reps to get you connected to people that can help. You're paying for the Support, it's ok to use it. :D Also, if you're struggling with concepts, you can try (https://learn.openshift.com).

In my experience, OpenShift is awesome, once you know it. Now that I know OpenShift I can deploy a simple app in minutes (as long as the cluster itself is setup), including externally facing routes. It makes standing up new services almost trivial. There are also enormous benefits for performance, security, and scalability of a micro-service ecosystem or SOA.

But, there's a lot of abstraction over a traditional server, so for simple cases where you only need one instance it is definitely overkill. If you don't know OpenShift/Kubernetes then that is a lot to learn.

From personal experience I can say universities and large science collaborations are heavy Red Hat users.

Tier 1 ERP provider - Its Microsoft, Oracle Linus or Redhat.

Nothing else is supported.

I've been to several universities and other research labs with "Linux machines" which were running Redhat.

The US Government uses a lot of Red Hat. Every thread on every blade of every DoD HPC machine under the HPCMP program. Pretty sure a bunch of the DoE systems as well. I'd look at it as a national security investment: whether you agree with it from a business or engineering perspective, the US Government pretty much runs on contracts with vendors. In that version of reality you need an OS, and ideally you want a US-based OS vendor who will sign an SLA. Ubuntu is in the UK, so enjoys the US-UK special relationship, but still not "made in the USA".

This. I bet Government is a large percentage of their entire revenue. SELINUX, STIG profiles come ootb, and if something breaks they have a number to dial.

Yep, there are a bunch of RHAT employees that are "cleared" and work exclusively on/with .gov projects.

Used in finance for sure.

And the reason is the extensive (and expensive) paid support. It acts as an insurance for these businesses that are all about risk management.

In addition to the other comments, Red Hat (and SUSE, Oracle Linux UEK) have cemented partnerships with many hardware providers like Dell, HP, Broadcom, Emulex and similar. New hardware kernel module needs are routinely backported to their production stable kernels (low risk to adopt), and in reverse many of these companies only make tooling which works on these distros. Ubuntu / Debian do not have that kind of support - it's a gamble; Red Hat is not a gamble for the Enterprise, this even extends up the stack into Oracle DBA, SAP Solutions (HANA etc.) and other large Enterprise ecosystems.

RHEL is the only linux on the security approved list. So if you run classified, it is the only game in town. (easy game; if it is on the list you can use it vs. having to justify something else) Not CENTOS, but RHEL. You see, the binary is what is approved, not the source..

Amazon Linux is based on centos/fedora. So, yeah, lots of people use Red Hat even if they don't realize it.

I work for Red Hat, so am biased but also exposed a lot to customers. A ton of big companies and government use Red Hat. Most of the startup space uses Ubuntu/Debian, but things are changing a bit there. CentOS is starting to get more traction in the startup space.

Fedora on the desktop is also one of the top used distros (and Fedora is the upstream of RHEL).

What does it offer that other distros don't? Meticulous attention from some of the best linux engineers in the world. Tons of out-of-the-box stuff to make using it easy for non-linux experts. Also guarantees of extremely long-term support, so enterprises can rely on having a supported/patched OS for years and years.

It's interesting that even on an article about a non-Linux Red Hat product, the answers to your question predominately focused on only the Linux part of the picture.

From this I take it that most of the folks complaining about what is happening to CloudForms in here at least don't actually know what it is.

I think Open source will win in the long run. Simply because there are more software engineers working on open source software than there is on closed software. So from an economic standpoint closed software cannot compete. This is true of even very large corporations.

Hopefully IBM will open source Spectrum scale / GPFS general parallel file system and integrate that with Red Hat.

> there are more software engineers working on open source software than there is on closed software

I would have thought that the opposite is the case; most engineers work on closed source software

By orders of magnitude. The OPs talking point sounds like the typical one of someone who has not been in the belly of the beast to see how corporate is using open source. Which is endless unofficial forks of everything forever.

Open source has lost. It's time for something new.

Not in areas where it has become a commodity.

I wouldn’t hold my breath waiting for that. Besides being an enormous old code base, IBM is well aware that it’s their primary unique storage value prop for an installed base they hold by the dangly bits (with Oracle-like surprise license audits too!). Many of whom would jump to an open source version and ditch the dubious support that today’s IBM offers.

It might be better to use the linked post's title?

From one “audit as a profit center” vendor to another. They’re both brands milking their glorious past at the expense of the present.

CloudForms is Red Hat’s supported version of upstream ManageIQ, an infrastructure management platform. It lets you see, manage and deploy to various platforms like OpenStack, VMWare, RHEV, OpenShift and public cloud like AWS and Azure, with single pane of glass view across them all. It has its own orchestration engine but also integrates with Ansible for automated deployments.

As best I can tell, their CloudForms updated Statement of Direction article (behind paywall, sorry) shows that Red Hat is killing off support for non-Red Hat platforms like VMware, AWS, Azure, etc. The justification is to focus on open platforms, which I think means CloudForms will ultimately disappear entirely with Red Hat focusing on OpenShift instead.

We made a strategic decision to focus our management strategy on the future — open, cloud-native environments that promote portability across on-premise, private and public clouds.

CloudForms updated Statement of Direction However to me this is still a big blow to users of the platform, where I’m sure most will have at least some VMWare to manage. Indeed, when implementing CloudForms at work and talking to Red Hat, they said that their most mature integration in CloudForms is with VMWare.

According to the Red Hat article, CloudForms with full platform support is being embedded into IBM Cloud Pak for Multicloud Management and users are encouraged to “migrate your Red Hat CloudForms subscriptions to IBM Cloud Pak for Multicloud Management licenses.” Red Hat’s CloudForms Statement of Direction FAQ article lays out the migration path, which does confirm Red Hat will continue to support existing clients for the remainder of their subscription.

So in short, CloudForms from Red Hat is being crippled and will only support Red Hat products, which really means that users are being forced to buy IBM instead. Of course Red Hat is entitled to change their own products, but this move does seem curious when execs on both sides said they would remain independent. Maybe it’s better than killing CloudForms outright?

We can publicly say that all our products will survive in their current form and continue to grow. We will continue to support all our products; we’re separate entities and we’re going to have separate contracts, and there is no intention to de-emphasise any of our products and we’ll continue to invest heavily in it.

Jim Whitehurst as Red Hat CEO

Disclaimer: I'm a Red Hat Consultant.

The TFA linked RH Article [0] is "paywalled" behind a "free cost" user registration. You just need a valid email. I've copied the text from that article

   As customers accelerate and scale their open hybrid cloud initiatives, management becomes
   increasingly essential. Given this requirement, we made a strategic decision to focus our
   management strategy on the future -- open, cloud-native environments that promote portability
   across on-premise, private and public clouds. With this strategy update, the roadmap for
   Red Hat CloudForms is summarized in three key points:

   1. To date, Red Hat CloudForms has managed both open source and proprietary technologies.
   2. Moving forward, Red Hat CloudForms will continue to directly support open Red Hat platforms
   like Red Hat OpenStack and Red Hat Virtualization. As of March 1, 2020, Red Hat will no longer
   offer NEW CloudForms subscriptions for non-Red Hat platforms. For renewal options, please
   see CloudForms Statement of Direction FAQ.
   3. For non-Red Hat technologies (VMware, AWS, Azure, etc.), IBM is embedding CloudForms in
   their Cloud Pak for Multicloud Management and will be working in the ManageIQ community
   (upstream for CloudForms). Beginning March 1, 2020, IBM will also be offering an easy migration
   path from Red Hat CloudForms to this Cloud Pak.

   Red Hat will continue to work in CloudForms’ upstream community, ManageIQ, to support our
   offerings. For management of non-Red Hat products, IBM is also working in the ManageIQ
   community and embedding CloudForms support in the IBM Cloud Pak for Multicloud Management. For
   Red Hat CloudForms customers interested in managing heterogeneous environments, IBM is
   offering an easy migration path from Red Hat CloudForms to this IBM Cloud Pak.

[0] https://access.redhat.com/articles/4639821

The headline is extremely editorialized and attempts to steer the discussion in a very specific direction. Can the mods change the title to match the article headline?

Is the article title accurate? What's an accurate and neutral title?

It obviously needs to be changed, but I'm not sure what to change it to.

How about "Red Hat's Cloud Forms is migrating into an IBM Cloud Pak"?

Ok, let's try that. Thanks!

Submitted title was "IBMs Cannibalization of RedHat Begins". That broke the HN guidelines by editorializing (https://news.ycombinator.com/newsguidelines.html). Accounts that do that eventually lose submission rights on HN, so please don't do that.

Points 1 & 2 in the RH doc linked from TFA [0] I believe were communicated to customers starting Spring 2019. Point 3 (IBM CloudPak integration) actually gives customers with CloudForms installations they care about a way to continue using CloudForms with support from IBM & RH.

[0] https://access.redhat.com/articles/4639821

Can you at least put an apostrophe between "IBM" and "s" while trying to figure out a proper title?

Edit: this is better.

IBM is a company that designed a human cataloging systems for the nazis for extermination purposes. I sincerely hope you love working for them.

edit: I’m not sure why I’m getting downvoted, I just stated a known fact. Did I do something wrong?

Your comment broke the site guidelines badly, being both extraneous flamebait and a personal attack. Please review https://news.ycombinator.com/newsguidelines.html and stick to the rules in the future. You've broken them frequently, and if you keep doing so we're going to have to ban you.

Using people's employment information to attack them is particularly bad for HN, since it disincentivizes users to show up and talk about their work, which is likely to be the thing they know the most about. That would make HN strictly worse, so it's a no-brainer not to allow comments like this.

https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...

We detached this comment from https://news.ycombinator.com/item?id=21830516 and marked it off-topic.

I for one am happy that RedHat is dying.

The most contentious and unfriendly projects in the Linux ecosystem are run by its employees and the interests of the rest of the community run directly counter to those of RedHat and by extension it's employees: software that doesn't need a gaggle of engineers to run vs software that you have to buy a subscription for.

If software is so easy to build, run and debug that you don't need support for you won't buy support for it. Every enterprise I've been at in the last 10 years had CentOS for the engineers who knew their way around Linux and RHEL for those that didn't. It was completely up to you which one you chose. The only push to anyone buying RedHat was how impossible it was to build your projects without someone holding your hand or wasting days reading documentation.

I was Red Hat ambivalent up until the point they bought JBoss, and as far as I'm concerned, Marc Fleury introduced the word 'astroturfing' to the vernacular.

At that point the confirmation bias started to settle in pretty quickly, and so it seemed like their choices just got weirder and weirder.

I like to think I understand how software businesses work, but then I think about Yahoo and Red Hat and realize I don't know shit, because I couldn't begin to understand why they have had legs when more seemingly valid concerns flamed out.

> but then I think about Yahoo and Red Hat and realize I don't know shit, because I couldn't begin to understand why they have had legs when more seemingly valid concerns flamed out.

A lucky investment into AliBaba for the former, and a good sales team for the latter.

This is complete nonsense. Enterprises like to buy from organizations like RedHat because it provides a safety net. On top of that, you typically appreciate the fact that your suppliers make money, because that increases the chance they will stay in business.

Unless what they are supplying is free already when you hire people that actually use Linux.

I just wish they'd died soon enough to take systemd and wayland down with them; it doesn't look like that's going to happen.

I seriously doubt there will be the manpower to keep pushing those projects once the money dries up. They are not intrinsically interesting and their implementation leaves a lot to be desired of.

There will be yet another huge mess left for the distros to deal with then things will be back to normal in two or three years with everyone remembering why the Unix philosophy is important and that 'this time it isn't different'.

Am open to improvements but not going back to a shell-script-based boot, thanks.

The predecessor for systemd on Fedora was upstart, not van Smoorenburg init.

I liked upstart, but it could stand a few improvements too.

Somewhat briefly, sure. Upstart was used in Fedora, in SysV compatibility mode, from 9 (2008-04)[0] up until 15 (2010-10)[1], or about 2.5 years.

Fedora prior to 2008 used classic Redhat runlevel init (what you're calling Smoorenburg). From the first release in 2003, through Fedora 9. So we have 4.5 years of "SysV init" followed by 2.5 years of Upstart in "SysV init" compatibility mode.

That said, your comment isn't especially responsive to GP; both Upstart and Systemd in Fedora continued to use a bunch of shell scripts to define startup actions. It wasn't until the systemd unit file conversion efforts[2] around 2012 that Fedora largely moved to services defined as data in "INI"-style configuration files.

GP's "shell-script-based boot" is not an unfair way to characterize Fedora's boot process prior to (and including the early history of) systemd in Fedora.

[0]: https://fedoraproject.org/wiki/Features/Upstart

[1]: https://fedoraproject.org/wiki/Features/systemd

[2]: https://fedoraproject.org/wiki/Features/Systemd-unit-cleanup

Miquel van Smoorenburg never worked for Redhat that I know of. It was not a "Redhat init" as you call it. Indeed, it wasn't even init. The things that we are talking about are rc, not init, in the van Smoorenburg system.

Nor was there the sort of exclusive "compatibility mode" that you are envisaging in order to make your argument that mixmastamyk was referring to Upstart. Upstart could employ van Smoorenburg rc scripts, but that was not a mode. Upstart was still event-driven with job files. The van Smoorenburg rc scripts were run via what was just another job file. Were your argument valid for Upstart, it would equally be valid for systemd's mechanism for invoking van Smoorenburg rc scripts, and you would have to say that systemd is shell-script-based boot, which really makes a nonsense of mixmastamyk talking about "going back" to it from systemd.

Quite clearly, going back to Upstart is not what mixmastamyk was talking about, which not least can be seen from xyr comment written, next to yours, 4 days beforehand.

I'd like to believe that, but things like https://www.debian.org/vote/2019/vote_002 really aren't encouraging (note the absence of any proposal for actually removing the toxic Big Ball of Mud, and that the top voted proposal is to drop support for any software that works correctly).

WTF is your problem with Wayland? Wayland is good, it's a brilliant protocol that you can actually understand, which has attracted a community of new developers to hacking on the free desktop platform.

As a result, we finally have a desktop situation that's not a pile of workarounds on top of a decades old crusty mess that nobody wants to touch that is Xorg, finally there's no fucking screen tearing, finally there's proper multi-monitor HiDPI, finally it's possible to actually sandbox GUI apps (unlike X11, having a Wayland socket does not give you the power to mess with the desktop and overlay a fake password prompt or keylog), finally there are no weird lags (because the protocol is fully async and does not involve a silly middleman broker that xorg ended up as).

Reply on news.ycombinator.com