Hello,
Kinda confused, will CentOS new SIGs: CentOS Storage, CentOS Cloud, and CentOS Virtualization, CentOS Core,etc be a developmental path to future RHEL releases, or will they continue be an exact clone of RHEL, like Centos currently is?
http://www.zdnet.com/red-hat-reveals-centos-plans-7000027812/
Initial reaction: Crap!
One of the best things about CentOS, in my opinion, was not having to deal with all the different RHEL builds/releases/whatever they called them, and just having ONE distribution.
So much for that.
It didn't take long for Red Hat to get their mitts all over CentOS, huh?
On Mon, Mar 31, 2014 at 5:56 AM, Edward M edwardunix@live.com wrote:
Hello,
Kinda confused, will CentOS new SIGs: CentOS Storage, CentOS Cloud, and CentOS Virtualization, CentOS Core,etc be a developmental path to future RHEL releases, or will they continue be an exact clone of RHEL, like Centos currently is?
http://www.zdnet.com/red-hat-reveals-centos-plans-7000027812/ _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On 03/31/2014 07:28 AM, Phelps, Matt wrote:
Initial reaction: Crap!
One of the best things about CentOS, in my opinion, was not having to deal with all the different RHEL builds/releases/whatever they called them, and just having ONE distribution.
This doesn't change. It's the core sig.
So much for that.
It didn't take long for Red Hat to get their mitts all over CentOS, huh?
We were already doing this sort of thing with the Xen4CentOS build, and the plus repo before the RH agreement. We're simply able to expand on this type of effort now.
On Mon, Mar 31, 2014 at 8:58 AM, Jim Perrin jperrin@centos.org wrote:
On 03/31/2014 07:28 AM, Phelps, Matt wrote:
Initial reaction: Crap!
One of the best things about CentOS, in my opinion, was not having to
deal
with all the different RHEL builds/releases/whatever they called them,
and
just having ONE distribution.
This doesn't change. It's the core sig.
But the current "core" distribution has KVM/libvirt, and all the desktop stuff, and apache, etc. etc, each of which sounds like it will be broken out into a separate "SIG."
Please, please don't do this. Let us do our jobs and pick what we need from the same install depending on what kind of machine we're installing.
I don't want to have to change our whole installation environment, which we're take years of work to get the way we want it, based on someone else's arbitrary rearranging of what's needed for "Storage" or "Virtualization," etc.
So much for that.
It didn't take long for Red Hat to get their mitts all over CentOS, huh?
We were already doing this sort of thing with the Xen4CentOS build, and the plus repo before the RH agreement. We're simply able to expand on this type of effort now.
Both of those are additions to "CentOS." Please don't break up "CentOS" arbitrarily into separate "products" like Red Hat needlessly did. Let us pick and choose what we need easily.
The whole point of an "Enterprise " environment is to minimize the change so we don't have to re-tool everything.
(Sorry for all the sarcastic quotes, but I'm upset. This is exactly the sort of meddling I was afraid of when Red Hat took over.)
On 03/31/2014 08:16 AM, Phelps, Matt wrote:
On Mon, Mar 31, 2014 at 8:58 AM, Jim Perrin jperrin@centos.org wrote:
On 03/31/2014 07:28 AM, Phelps, Matt wrote:
Initial reaction: Crap!
One of the best things about CentOS, in my opinion, was not having to
deal
with all the different RHEL builds/releases/whatever they called them,
and
just having ONE distribution.
This doesn't change. It's the core sig.
But the current "core" distribution has KVM/libvirt, and all the desktop stuff, and apache, etc. etc, each of which sounds like it will be broken out into a separate "SIG."
No. The SIGs are community efforts where a newer or different version is needed. Core stays core.
Please, please don't do this. Let us do our jobs and pick what we need from the same install depending on what kind of machine we're installing.
This is exactly the intent. Right now there are a load of admins who want or need newer versions of things, be it php, python, libvirt, ruby, whatever. We're not changing up the core. We're trying to provide a better way to get updated features if they're needed.
I don't want to have to change our whole installation environment, which we're take years of work to get the way we want it, based on someone else's arbitrary rearranging of what's needed for "Storage" or "Virtualization," etc.
You won't have to. Stick with core, and you'll be fine.
So much for that.
It didn't take long for Red Hat to get their mitts all over CentOS, huh?
We were already doing this sort of thing with the Xen4CentOS build, and the plus repo before the RH agreement. We're simply able to expand on this type of effort now.
Both of those are additions to "CentOS." Please don't break up "CentOS" arbitrarily into separate "products" like Red Hat needlessly did. Let us pick and choose what we need easily.
The whole point of an "Enterprise " environment is to minimize the change so we don't have to re-tool everything.
Yep, and the "C" has been for 'Community', which has been a driving force in this. Xen was in el5, and when it was dropped in el6 we had a large hosting user-base who suddenly had no upgrade path to the new version. By adding Xen support back in, we've provided a method for them to update without re-tooling. We're trying to keep the need to change minimal, exactly as you want.
(Sorry for all the sarcastic quotes, but I'm upset. This is exactly the sort of meddling I was afraid of when Red Hat took over.)
This seems a bit "the sky is falling" to me. We're not changing what we've done in the past. We're adding (entirely optional) functionality to meet the demands of the community. You don't have to change a thing if you don't want to.
On Mon, Mar 31, 2014 at 9:36 AM, Jim Perrin jperrin@centos.org wrote:
On 03/31/2014 08:16 AM, Phelps, Matt wrote:
On Mon, Mar 31, 2014 at 8:58 AM, Jim Perrin jperrin@centos.org wrote:
On 03/31/2014 07:28 AM, Phelps, Matt wrote:
Initial reaction: Crap!
One of the best things about CentOS, in my opinion, was not having to
deal
with all the different RHEL builds/releases/whatever they called them,
and
just having ONE distribution.
This doesn't change. It's the core sig.
But the current "core" distribution has KVM/libvirt, and all the desktop stuff, and apache, etc. etc, each of which sounds like it will be broken out into a separate "SIG."
No. The SIGs are community efforts where a newer or different version is needed. Core stays core.
Please, please don't do this. Let us do our jobs and pick what we need
from
the same install depending on what kind of machine we're installing.
This is exactly the intent. Right now there are a load of admins who want or need newer versions of things, be it php, python, libvirt, ruby, whatever. We're not changing up the core. We're trying to provide a better way to get updated features if they're needed.
I don't want to have to change our whole installation environment, which we're take years of work to get the way we want it, based on someone
else's
arbitrary rearranging of what's needed for "Storage" or "Virtualization," etc.
You won't have to. Stick with core, and you'll be fine.
So much for that.
It didn't take long for Red Hat to get their mitts all over CentOS,
huh?
We were already doing this sort of thing with the Xen4CentOS build, and the plus repo before the RH agreement. We're simply able to expand on this type of effort now.
Both of those are additions to "CentOS." Please don't break up "CentOS" arbitrarily into separate "products" like Red Hat needlessly did. Let us pick and choose what we need easily.
The whole point of an "Enterprise " environment is to minimize the change so we don't have to re-tool everything.
Yep, and the "C" has been for 'Community', which has been a driving force in this. Xen was in el5, and when it was dropped in el6 we had a large hosting user-base who suddenly had no upgrade path to the new version. By adding Xen support back in, we've provided a method for them to update without re-tooling. We're trying to keep the need to change minimal, exactly as you want.
(Sorry for all the sarcastic quotes, but I'm upset. This is exactly the sort of meddling I was afraid of when Red Hat took over.)
This seems a bit "the sky is falling" to me. We're not changing what we've done in the past. We're adding (entirely optional) functionality to meet the demands of the community. You don't have to change a thing if you don't want to.
OK, I'll calm down. Perhaps what you've said could have been communicated by the article. This line is what troubled me:
"So what the newly united Red Hat and CentOShttp://www.zdnet.com/red-hat-incorporates-free-red-hat-clone-centos-7000024907 is planning on are multiple CentOS releases."
How will these "SIGs" be handled? Just additional yum repos? What if I want to use parts of the Storage SIG and Virtualization SIG together on the same installation?
Thanks.
Oh, does this mean we'll get a working chrome/chromium past version 31? :)
On Mon, Mar 31, 2014 at 09:49:53AM -0400, Phelps, Matt wrote:
OK, I'll calm down. Perhaps what you've said could have been communicated by the article. This line is what troubled me:
Do keep in mind that the article in question was written by a tech journalist and includes independent analysis and opinion. It isn't direct communication from Red Hat or CentOS.
On Mon, Mar 31, 2014 at 10:02 AM, Matthew Miller mattdm@mattdm.org wrote:
Do keep in mind that the article in question was written by a tech journalist and includes independent analysis and opinion. It isn't direct communication from Red Hat or CentOS.
Yes, I see that now.
Is the talk by Karsten Wade online somewhere so we can check the source material?
On 03/31/2014 08:49 AM, Phelps, Matt wrote:
<aggressive snipping>
OK, I'll calm down. Perhaps what you've said could have been communicated by the article. This line is what troubled me:
"So what the newly united Red Hat and CentOShttp://www.zdnet.com/red-hat-incorporates-free-red-hat-clone-centos-7000024907 is planning on are multiple CentOS releases."
Keep in mind they get more ad revenue the more clicks they get.
Also, we don't want to dictate when the SIGs do something, so they're free to set their own schedules and releases.
How will these "SIGs" be handled? Just additional yum repos? What if I want to use parts of the Storage SIG and Virtualization SIG together on the same installation?
Yes, they'll be additional repos. What you described is exactly one of our target use-cases. Using gluster or ceph as backend storage for virt. Granted, not all SIGs will be inter-operable, but most cases should be documented.
Oh, does this mean we'll get a working chrome/chromium past version 31? :)
Chrome/chromium is a completely separate headache because of the deps and build tools used. If someone wanted to take that up as a SIG/project, I'd be fine with it. I'd likely also call them a masochist, but hey.
Phelps, Matt wrote:
Initial reaction: Crap!
One of the best things about CentOS, in my opinion, was not having to deal with all the different RHEL builds/releases/whatever they called them, and just having ONE distribution.
So much for that.
It didn't take long for Red Hat to get their mitts all over CentOS, huh?
Oh, there were always some things - my pet peeve is the "minimal install" doesn't set up networking!
mark
On Mon, Mar 31, 2014 at 5:56 AM, Edward M edwardunix@live.com wrote:
Hello,
Kinda confused, will CentOS new SIGs: CentOS Storage, CentOS Cloud, and CentOS Virtualization, CentOS Core,etc be a developmental path to future RHEL releases, or will they continue be an exact clone of RHEL, like Centos currently is?
http://www.zdnet.com/red-hat-reveals-centos-plans-7000027812/ _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-- Matt Phelps System Administrator, Computation Facility Harvard - Smithsonian Center for Astrophysics mphelps@cfa.harvard.edu, http://www.cfa.harvard.edu _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On 03/31/2014 04:56 AM, Edward M wrote:
Hello,
Kinda confused, will CentOS new SIGs: CentOS Storage, CentOS Cloud, and CentOS Virtualization, CentOS Core,etc be a developmental path to future RHEL releases, or will they continue be an exact clone of RHEL, like Centos currently is?
The Core SIG produces the same CentOS everyone knows and loves.
The other sigs allow groups of like-minded community members to take CentOS, and modify it in an officially recognized manner to suit their needs. It also allows projects a method to distribute their applications using CentOS as the platform.
Examples: adding xen support, distributing cloud-init enabled images, or building in glusterfs support.
These are community driven efforts, and you don't have to use them if you don't want to.
On 3/31/2014 6:26 AM, Jim Perrin wrote:
On 03/31/2014 04:56 AM, Edward M wrote:
Hello,
Kinda confused, will CentOS new SIGs: CentOS Storage, CentOS Cloud, and CentOS Virtualization, CentOS Core,etc be a developmental path to future RHEL releases, or will they continue be an exact clone of RHEL, like Centos currently is?
The Core SIG produces the same CentOS everyone knows and loves.
The other sigs allow groups of like-minded community members to take CentOS, and modify it in an officially recognized manner to suit their needs. It also allows projects a method to distribute their applications using CentOS as the platform.
Examples: adding xen support, distributing cloud-init enabled images, or building in glusterfs support.
These are community driven efforts, and you don't have to use them if you don't want to.
Thank you for clarifying, now I've got a better understanding.
Best regards ed
-
Edward M -
Jim Perrin -
m.roth＠5-cent.us -
Matthew Miller -
Phelps, Matt