5 ms·

Please file in a calm and orderly fashion toward the exits and remember: IBM killed Centos for profit. Terraform users can pick up their new alternative here:

Please file in a calm and orderly fashion toward the exits and remember: IBM killed Centos for profit. Terraform users can pick up their new alternative here: https://opentofu.org/ https://opentofu.org/ and for those of you with Vault, you can find your new alternative here: https://openbao.org/ https://openbao.org/

otterley 2y ago
> IBM killed Centos for profit. That process began happening long before the IBM acquisition when Red Hat hired Karanbir Singh (CentOS's maintainer) in 2014.
- vram22 2y ago
  What's the story behind that? IIRC, I saw something about it on HN at the time, but did not read it, being busy.
  - bonzini 2y ago
    Red Hat had open source/community versions of their products, for example OpenShift Origin (now OKD) and RDO (for OpenStack). They wanted to use CentOS but it was not working well because release dates of CentOS were not predictable. So they acquihired CentOS, but in doing that they changed its target from "community of users [that don't want to pay for RHEL]" to "community of developers that target RHEL". CentOS Stream is much better (though not perfect) for the latter population. That said, there are many people using CentOS Stream in production (including myself).
    - vram22 2y ago
      Got it, thanks.
sethops1 2y ago
Do you even realize OpenBao is an IBM initiative?
- stuff4ben 2y ago
  It's not, it's a Linux Foundation initiative with some IBM developers involved. IBM cannot kill it.
dralley 2y ago
>IBM killed Centos for profit The community is better off with the combination of AlmaLinux + CentOS Stream. AlmaLinux provides differentiation by supporting hardware and patches that Red Hat doesn't necessarily want to. CentOS Stream provides a way for all downstream distros (Red Hat, Alma, Oracle, Rocky, whatever) to contribute back to the ecosystem in a way that is deeper than submitting bug reports to bugzilla.redhat.com The latter point is something people really miss. CentOS was not much of an "open source" project in the same way that Android isn't much of an "open source" project. There was few ways to contribute directly beyond filing a bug report and waiting for Red Hat / Google to handle it. CentOS Stream is vastly more open as a project.
- growse 2y ago
  Wasn't the value of centos that it was bug-yor-bug compatible with RHEL but without the license fee requirement?
  - dralley 2y ago
    >bug-yor-bug compatible with RHEL It was never quite that, but that was the theory. The problem is because it was an exact clone of RHEL, it's somewhere between difficult and impossible to have a proper community around it. Like I said it kind of revolved around "file a bug to Red Hat, wait for someone to pick it up, and then wait more for it to be shipped, which will be months away at best and could be years if it's not a paying customer's priority"
    - yencabulator 2y ago
      What I've seen people use CentOS for is testing a product intended to run on RHEL. For that, CentOS didn't need a separate community, and bugfixing at a pace different from RHEL would have been actively undesirable.
      - dralley 2y ago
        For that purpose, RHEL is completely free to begin with
vmatsiiako 2y ago
Do you know that OpenBao is actually funded by IBM? I'm biased (co-founder) but you should take a look at Infisical for secret management: https://infisical.com https://infisical.com
- stuff4ben 2y ago
  As I said elsewhere, it's not. It's an open source project, under the Linux Foundation umbrella, with all of the good licensing that goes along with that. It has some contributors who are also IBM employees, but to say they're "funded by IBM" is a bit of a stretch.
  - cipherboy 2y ago
    FWIW, most of the code and docs contributions have come from non-IBMers [0]. That said, IBM has done a lot of great work building the foundation and initial community and without them, OpenBao wouldn't be here. :-) Speaking for myself, but I do not get any monetary compensation from IBM and I suspect this is true for all of the other non-IBM contributors. [0]: https://github.com/openbao/openbao/releases/tag/v2.0.0-alpha20240329 https://github.com/openbao/openbao/releases/tag/v2.0.0-alpha...
thayne 2y ago
What about Packer? Vagrant? Consul?
andrenth 2y ago
Is someone working on a Nomad fork?
- hpb42 2y ago
  Maybe Incus[0] as an alternative instead of fork. - [0] https://linuxcontainers.org/incus/docs/main/ https://linuxcontainers.org/incus/docs/main/
- mdaniel 2y ago
  I don't have any further insight, but looking at <https://github.com/hashicorp/nomad/forks?include=active&page=1&period=1mo&sort_by=stargazer_counts https://github.com/hashicorp/nomad/forks?include=active&page...> coughed up https://github.com/atlassian/nomad/branches https://github.com/atlassian/nomad/branches although confusingly it says "updated last week" but browsing any one of the branches seems to be stupid old so I got nothing Finding conceptual forks, e.g. $(git push --mirror ...) would be trickier but I bet sourcegraph could do it Ultimately, the question boils down to: what risk are you driving down: hitching your wagon to a dead stack, not getting security updates, not getting PRs merged, $other?
- bobo_legos 2y ago
  Off topic but how is Nomad for running production workloads? My org has been wanting to push into containerization, but we're finding the complexity of k8s a high barrier to entry given our small team and lack of in house knowledge.
  - mroche 2y ago
    Is there a specific aspect of k8s that's causing friction along the learning curve? I'm assuming your referring to the developer side of the equation, not the ops/admin workflows. Before jumping straight into production k8s, something you can mess around with is using Podman to generate[0] and run[1] Kubernetes resources that you can parse through and familiarize yourself with. Paired with Podman Desktop[2] can produce a nice graphical environment. After that you could take a look at more production-simulating environments with minikube[3], OpenShift Local[4] (very much recommend if you have the resources to run it), and the no-cost OpenShift Sandbox[5]. In general, the Red Hat Developer[6] site has a lot of good resources to learn from, both passive and interactive. I highly recommend going through the courses and tutorials available if it can help your team skill up (assuming k8s is the direction you want to go in). [0] https://docs.podman.io/en/latest/markdown/podman-generate.1.html https://docs.podman.io/en/latest/markdown/podman-generate.1.... [1] https://docs.podman.io/en/latest/markdown/podman-kube.1.html https://docs.podman.io/en/latest/markdown/podman-kube.1.html [2] https://podman.io/features https://podman.io/features | https://podman-desktop.io/ https://podman-desktop.io/ [3] https://minikube.sigs.k8s.io/docs/ https://minikube.sigs.k8s.io/docs/ [4] https://developers.redhat.com/products/openshift-local/overview https://developers.redhat.com/products/openshift-local/overv... [5] https://developers.redhat.com/developer-sandbox https://developers.redhat.com/developer-sandbox [6] https://developers.redhat.com/ https://developers.redhat.com/

otterley 2y ago

> IBM killed Centos for profit. That process began happening long before the IBM acquisition when Red Hat hired Karanbir Singh (CentOS's maintainer) in 2014.

vram22 2y ago
What's the story behind that? IIRC, I saw something about it on HN at the time, but did not read it, being busy.
- bonzini 2y ago
  Red Hat had open source/community versions of their products, for example OpenShift Origin (now OKD) and RDO (for OpenStack). They wanted to use CentOS but it was not working well because release dates of CentOS were not predictable. So they acquihired CentOS, but in doing that they changed its target from "community of users [that don't want to pay for RHEL]" to "community of developers that target RHEL". CentOS Stream is much better (though not perfect) for the latter population. That said, there are many people using CentOS Stream in production (including myself).
  - vram22 2y ago
    Got it, thanks.

sethops1 2y ago

Do you even realize OpenBao is an IBM initiative?

stuff4ben 2y ago
It's not, it's a Linux Foundation initiative with some IBM developers involved. IBM cannot kill it.

dralley 2y ago

>IBM killed Centos for profit The community is better off with the combination of AlmaLinux + CentOS Stream. AlmaLinux provides differentiation by supporting hardware and patches that Red Hat doesn't necessarily want to. CentOS Stream provides a way for all downstream distros (Red Hat, Alma, Oracle, Rocky, whatever) to contribute back to the ecosystem in a way that is deeper than submitting bug reports to bugzilla.redhat.com The latter point is something people really miss. CentOS was not much of an "open source" project in the same way that Android isn't much of an "open source" project. There was few ways to contribute directly beyond filing a bug report and waiting for Red Hat / Google to handle it. CentOS Stream is vastly more open as a project.

growse 2y ago
Wasn't the value of centos that it was bug-yor-bug compatible with RHEL but without the license fee requirement?
- dralley 2y ago
  >bug-yor-bug compatible with RHEL It was never quite that, but that was the theory. The problem is because it was an exact clone of RHEL, it's somewhere between difficult and impossible to have a proper community around it. Like I said it kind of revolved around "file a bug to Red Hat, wait for someone to pick it up, and then wait more for it to be shipped, which will be months away at best and could be years if it's not a paying customer's priority"
  - yencabulator 2y ago
    What I've seen people use CentOS for is testing a product intended to run on RHEL. For that, CentOS didn't need a separate community, and bugfixing at a pace different from RHEL would have been actively undesirable.
    - dralley 2y ago
      For that purpose, RHEL is completely free to begin with

vmatsiiako 2y ago

Do you know that OpenBao is actually funded by IBM? I'm biased (co-founder) but you should take a look at Infisical for secret management: https://infisical.com https://infisical.com

stuff4ben 2y ago
As I said elsewhere, it's not. It's an open source project, under the Linux Foundation umbrella, with all of the good licensing that goes along with that. It has some contributors who are also IBM employees, but to say they're "funded by IBM" is a bit of a stretch.
- cipherboy 2y ago
  FWIW, most of the code and docs contributions have come from non-IBMers [0]. That said, IBM has done a lot of great work building the foundation and initial community and without them, OpenBao wouldn't be here. :-) Speaking for myself, but I do not get any monetary compensation from IBM and I suspect this is true for all of the other non-IBM contributors. [0]: https://github.com/openbao/openbao/releases/tag/v2.0.0-alpha20240329 https://github.com/openbao/openbao/releases/tag/v2.0.0-alpha...

thayne 2y ago

What about Packer? Vagrant? Consul?

andrenth 2y ago

Is someone working on a Nomad fork?

hpb42 2y ago
Maybe Incus[0] as an alternative instead of fork. - [0] https://linuxcontainers.org/incus/docs/main/ https://linuxcontainers.org/incus/docs/main/
mdaniel 2y ago
I don't have any further insight, but looking at <https://github.com/hashicorp/nomad/forks?include=active&page=1&period=1mo&sort_by=stargazer_counts https://github.com/hashicorp/nomad/forks?include=active&page...> coughed up https://github.com/atlassian/nomad/branches https://github.com/atlassian/nomad/branches although confusingly it says "updated last week" but browsing any one of the branches seems to be stupid old so I got nothing Finding conceptual forks, e.g. $(git push --mirror ...) would be trickier but I bet sourcegraph could do it Ultimately, the question boils down to: what risk are you driving down: hitching your wagon to a dead stack, not getting security updates, not getting PRs merged, $other?
bobo_legos 2y ago
Off topic but how is Nomad for running production workloads? My org has been wanting to push into containerization, but we're finding the complexity of k8s a high barrier to entry given our small team and lack of in house knowledge.
- mroche 2y ago
  Is there a specific aspect of k8s that's causing friction along the learning curve? I'm assuming your referring to the developer side of the equation, not the ops/admin workflows. Before jumping straight into production k8s, something you can mess around with is using Podman to generate[0] and run[1] Kubernetes resources that you can parse through and familiarize yourself with. Paired with Podman Desktop[2] can produce a nice graphical environment. After that you could take a look at more production-simulating environments with minikube[3], OpenShift Local[4] (very much recommend if you have the resources to run it), and the no-cost OpenShift Sandbox[5]. In general, the Red Hat Developer[6] site has a lot of good resources to learn from, both passive and interactive. I highly recommend going through the courses and tutorials available if it can help your team skill up (assuming k8s is the direction you want to go in). [0] https://docs.podman.io/en/latest/markdown/podman-generate.1.html https://docs.podman.io/en/latest/markdown/podman-generate.1.... [1] https://docs.podman.io/en/latest/markdown/podman-kube.1.html https://docs.podman.io/en/latest/markdown/podman-kube.1.html [2] https://podman.io/features https://podman.io/features | https://podman-desktop.io/ https://podman-desktop.io/ [3] https://minikube.sigs.k8s.io/docs/ https://minikube.sigs.k8s.io/docs/ [4] https://developers.redhat.com/products/openshift-local/overview https://developers.redhat.com/products/openshift-local/overv... [5] https://developers.redhat.com/developer-sandbox https://developers.redhat.com/developer-sandbox [6] https://developers.redhat.com/ https://developers.redhat.com/