Hello all.
Does anybody have experience with pushing CentOS in enterprise?
I have the following situation. I tried to promote CentOS to local bank. They have now a couple of Gentoo-based systems and I tried to explain them that CentOS is much better option for enterprises.
IT department is interested in stability of the system, so they are ready to give CentOS a try. But the problem came from management and information security division.
That guys look much affected by FUD created by M$. They tell the story like "you can not rely on this open source, it is built by just few community geeks, you never know what will happen if the developer will be hit by bus tomorrow" and so on. They especially refer to the last year FUD story published at ZDNet (http://goo.gl/y0LBi). So, IT guys are allowed to use open source only if they can prove that it has stable community and transparent development and build process they can reproduce on their own if necessary.
I guess, I'm not the first who encounter this issue. Could you share your experience how to deal with it? Are there any public resources that can be used as proofs of CentOS stability?
--
Zdenek
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Zdenek said the following on 12/12/10 17:45:
Are there any public resources that can be used as proofs of CentOS stability?
Are there about Windows stability?
Ciao, luigi
- -- / +--[Luigi Rosa]-- \
To iterate is human, to recourse, divine.
On Sun, Dec 12, 2010 at 10:45 AM, Zdenek zdenek.w@o2.pl wrote:
Does anybody have experience with pushing CentOS in enterprise?
I have the following situation. I tried to promote CentOS to local bank. They have now a couple of Gentoo-based systems and I tried to explain them that CentOS is much better option for enterprises.
IT department is interested in stability of the system, so they are ready to give CentOS a try. But the problem came from management and information security division.
Do they know about the Gentoo systems?
That guys look much affected by FUD created by M$. They tell the story like "you can not rely on this open source, it is built by just few community geeks, you never know what will happen if the developer will be hit by bus tomorrow" and so on. They especially refer to the last year FUD story published at ZDNet (http://goo.gl/y0LBi). So, IT guys are allowed to use open source only if they can prove that it has stable community and transparent development and build process they can reproduce on their own if necessary.
I guess, I'm not the first who encounter this issue. Could you share your experience how to deal with it? Are there any public resources that can be used as proofs of CentOS stability?
Start with Red Hat as the source of the stability and long term support. And in fact, RH may be more acceptable in this scenario if they are willing to pay to have support from a big company. Functionally it shouldn't make any difference since it is the same code either way. I don't think there is any 'proof' that Centos will continue to be stable in the future, but you can look at their excellent history of getting updates out immediately after the RH release. You shouldn't have any problem mixing RH/Centos systems if you have some systems where the paid support is critical and some that you can support yourself.
At Sun, 12 Dec 2010 17:45:23 +0100 CentOS mailing list centos@centos.org wrote:
Hello all.
Does anybody have experience with pushing CentOS in enterprise?
I have the following situation. I tried to promote CentOS to local bank. They have now a couple of Gentoo-based systems and I tried to explain them that CentOS is much better option for enterprises.
IT department is interested in stability of the system, so they are ready to give CentOS a try. But the problem came from management and information security division.
That guys look much affected by FUD created by M$. They tell the story like "you can not rely on this open source, it is built by just few community geeks, you never know what will happen if the developer will be hit by bus tomorrow" and so on. They especially refer to the last year FUD story published at ZDNet (http://goo.gl/y0LBi). So, IT guys are allowed to use open source only if they can prove that it has stable community and transparent development and build process they can reproduce on their own if necessary.
I guess, I'm not the first who encounter this issue. Could you share your experience how to deal with it? Are there any public resources that can be used as proofs of CentOS stability?
Have you pointed the bank people at Red Hat itself. Red Hat is NOT a 'few community geeks' -- they are a thriving business. Also, you probably can mention that IBM support Linux. IBM is most certainly NOT a 'few community geeks'...
--
Zdenek
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Sun, Dec 12, 2010 at 12:26 PM, Robert Heller heller@deepsoft.com wrote:
At Sun, 12 Dec 2010 17:45:23 +0100 CentOS mailing list centos@centos.org wrote:
Hello all.
Does anybody have experience with pushing CentOS in enterprise?
I have the following situation. I tried to promote CentOS to local bank.
They have now a couple of Gentoo-based systems and I tried to explain them that CentOS is much better option for enterprises.
IT department is interested in stability of the system, so they are ready
to give CentOS a try. But the problem came from management and information security division.
That guys look much affected by FUD created by M$. They tell the story
like "you can not rely on this open source, it is built by just few community geeks, you never know what will happen if the developer will be hit by bus tomorrow" and so on. They especially refer to the last year FUD story published at ZDNet (http://goo.gl/y0LBi). So, IT guys are allowed to use open source only if they can prove that it has stable community and transparent development and build process they can reproduce on their own if necessary.
I guess, I'm not the first who encounter this issue. Could you share your
experience how to deal with it? Are there any public resources that can be used as proofs of CentOS stability?
Have you pointed the bank people at Red Hat itself. Red Hat is NOT a 'few community geeks' -- they are a thriving business. Also, you probably can mention that IBM support Linux. IBM is most certainly NOT a 'few community geeks'...
--
Zdenek
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-- Robert Heller -- 978-544-6933 / heller@deepsoft.com Deepwoods Software -- http://www.deepsoft.com/ () ascii ribbon campaign -- against html e-mail /\ www.asciiribbon.org -- against proprietary attachments
Management types like numbers. Here's a Cnet article that gives you the breakdown of who contributes to Linux:
http://news.cnet.com/8301-13846_3-20024219-62.html
That article, in turn, refers to a Forbes piece on Red Hat and open source in general:
http://blogs.forbes.com/ciocentral/2010/11/30/red-hat-at-1-billion/
_______________________________________________
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
2010/12/12 Zdenek zdenek.w@o2.pl:
Hello all.
Does anybody have experience with pushing CentOS in enterprise?
Yes and no. Maybe you should select RHEL for enterprises?
-- Eero
I have the following situation. I tried to promote CentOS to local bank. They have now a couple of Gentoo-based systems and I tried to explain them that CentOS is much better option for enterprises.
We deployed a CentOS based virtualized appliance for a (non-critical) application developed by us in a bank which had similar policies. Actually they even had an explicit official policy against any open-source software.
We finally convinced them with the following arguments: - we could support RHEL if they would prefer to have a big company behind the OS and they could always decide to switch to it - we said that we were ready to deploy it on Solaris, but they should pay us more for that and take responsibility for any issue
I guess, I'm not the first who encounter this issue. Could you share your experience how to deal with it? Are there any public resources that can be used as proofs of CentOS stability?
Out of common sense, and as others have suggested, I would tell them: - if you are willing to pay and want to be safe, take RHEL (Red Hat is about to reach $1 billion revenues http://bit.ly/eb4igX) - if not, what makes you think that Gentoo is more viable?
CentOS definitely addresses a need in the market, and even if the project should collapse (God forbids...), so many people needs it that an equivalent would probably pops up quickly, based on the amazing work which as already been done and is available.
The following chart shows for example that CentOS is very popular for web servers: http://w3techs.com/technologies/history_details/os-linux
On Dec 12, 2010, at 11:45 AM, Zdenek zdenek.w@o2.pl wrote:
Hello all.
Does anybody have experience with pushing CentOS in enterprise?
I do, but I have it easy because I am the IT management.
I have the following situation. I tried to promote CentOS to local bank. They have now a couple of Gentoo-based systems and I tried to explain them that CentOS is much better option for enterprises.
IT department is interested in stability of the system, so they are ready to give CentOS a try. But the problem came from management and information security division.
They are OK with the roll-your-own style of Gentoo?
Especially with it's cutting edge versions, bugs, security holes and the only way to overcome them is to upgrade to an even newer version that may break compatibility, introduce new bugs, zero-day vulnerabilities, the list goes on and on.
Gentoo is a great distro for learning Linux, in a computer lab, or for a home hobbyist, but not quite enterprise stable.
That guys look much affected by FUD created by M$. They tell the story like "you can not rely on this open source, it is built by just few community geeks, you never know what will happen if the developer will be hit by bus tomorrow" and so on. They especially refer to the last year FUD story published at ZDNet (http://goo.gl/y0LBi). So, IT guys are allowed to use open source only if they can prove that it has stable community and transparent development and build process they can reproduce on their own if necessary.
CentOS is a recompile of RHEL with the intellectual property stripped, so you can drop-in replace it with RHEL.
I guess, I'm not the first who encounter this issue. Could you share your experience how to deal with it? Are there any public resources that can be used as proofs of CentOS stability?
You can mix up RHEL and CentOS in the same environment. Use RHEL on key mission critical systems and CentOS on one-off systems to reduce license costs, but maintain 100% compatibility between the two.
It really is the perfect combination for my environment and I run the IT operations for a financial group which includes a commercial bank.
-Ross
They are OK with the roll-your-own style of Gentoo?
Especially with it's cutting edge versions, bugs, security holes and the only way to overcome them is to upgrade to an even newer version that may break compatibility, introduce new bugs, zero-day vulnerabilities, the list goes on and on.
So, you are saying that other OSes, even other Linux distributions, have no bugs, security holes, compatibility issues and zero-days? Looks like we don't need M$ to spread FUD about Linux, we're well capable of doing it ourselves ;)
Gentoo is a great distro for learning Linux, in a computer lab, or for a home hobbyist, but not quite enterprise stable.
There are in fact people who run Gentoo in the Enterprise, and it's up to the sysadmin to decide which upgrade policies to implement. While this would not necessarily be my personal choice, it's perfectly legit. As is running Windows should the powers that be require it.
You can mix up RHEL and CentOS in the same environment. Use RHEL on key mission critical systems and CentOS on one-off systems to reduce license costs, but maintain 100% compatibility between the two.
Agreed.
--------------------------------------------------------------- This message and any attachments may contain Cypress (or its subsidiaries) confidential information. If it has been received in error, please advise the sender and immediately delete this message. ---------------------------------------------------------------
On Mon, Dec 13, 2010 at 5:02 AM, lhecking@users.sourceforge.net wrote:
They are OK with the roll-your-own style of Gentoo?
Especially with it's cutting edge versions, bugs, security holes and the only way to overcome them is to upgrade to an even newer version that may break compatibility, introduce new bugs, zero-day vulnerabilities, the list goes on and on.
So, you are saying that other OSes, even other Linux distributions, have no bugs, security holes, compatibility issues and zero-days? Looks like we don't need M$ to spread FUD about Linux, we're well capable of doing it ourselves ;)
Now, now, sports fans, let's be nice.
Gentoo *is* a problem in production use, due to factors such as feature creep and component discrepancies. Its constant influx of "secret sauce" to correct layout skew and component inconsistency between differentn upstream projects, and that constant update and possible overlap and overwriting by the installation tools, is begging for pain in stable environments.
RHEL is much better about that, although by now the "production" RHEL 5 is 4 years out of date, the "leading edge" RHEL 6 is now one year out of date after the lengthy release testing, and CentOS will always lag that.
You can mix up RHEL and CentOS in the same environment. Use RHEL on key mission critical systems and CentOS on one-off systems to reduce license costs, but maintain 100% compatibility between the two.
Agreed.
Also, don't forgot to contribute or actually *purchase* the licenses for the one you use. Explaining to freeloaders that companies, and projects, will die and leave them alone and unsupported without some return of value from them is a big issue. Sadly or not, a lot of my recent clients have considered my sending patches upstream to open source projects to be as much as they're willing to provide. This can actually work out in hourly rates.....
On Mon, 13 Dec 2010, Nico Kadel-Garcia wrote:
RHEL is much better about that, although by now the "production" RHEL 5 is 4 years out of date, the "leading edge" RHEL 6 is now one year out of date after the lengthy release testing, and CentOS will always lag that.
I believe "out of date" is the wrong wording. RHEL/CentOS 5 is maintained, i.e. security issues and bugs are fixed. There's nothing "out of date" about a tool that works and is cost-effective. RHEL 6 still has to prove itself.
In my day job I support dozens of developer desktops that run CentOS 5 with a modified kernel supporting non-standard devices. It takes a few hours a week. Trying to track the bleeding edge supporting, say, Ubuntu would take much more time.
Ge'
2010/12/13 Gé Weijers ge@weijers.org:
On Mon, 13 Dec 2010, Nico Kadel-Garcia wrote:
RHEL is much better about that, although by now the "production" RHEL 5 is 4 years out of date, the "leading edge" RHEL 6 is now one year out of date after the lengthy release testing, and CentOS will always lag that.
I believe "out of date" is the wrong wording. RHEL/CentOS 5 is maintained, i.e. security issues and bugs are fixed. There's nothing "out of date" about a tool that works and is cost-effective. RHEL 6 still has to prove itself.
RHEL provides 10 year support cycle, I hope Centos can do same :)
-- Eero
On 13/12/2010 19:03, Eero Volotinen wrote:
2010/12/13 Gé Weijersge@weijers.org:
On Mon, 13 Dec 2010, Nico Kadel-Garcia wrote:
RHEL is much better about that, although by now the "production" RHEL 5 is 4 years out of date, the "leading edge" RHEL 6 is now one year out of date after the lengthy release testing, and CentOS will always lag that.
I believe "out of date" is the wrong wording. RHEL/CentOS 5 is maintained, i.e. security issues and bugs are fixed. There's nothing "out of date" about a tool that works and is cost-effective. RHEL 6 still has to prove itself.
RHEL provides 10 year support cycle, I hope Centos can do same :)
Not a problem. CentOS dies then you just change the repositories in yum and force update. RedHat have knowingly provided support for 'adopted' servers in the past for us.
On Mon, Dec 13, 2010 at 1:37 PM, Gé Weijers ge@weijers.org wrote:
On Mon, 13 Dec 2010, Nico Kadel-Garcia wrote:
RHEL is much better about that, although by now the "production" RHEL 5 is 4 years out of date, the "leading edge" RHEL 6 is now one year out of date after the lengthy release testing, and CentOS will always lag that.
I believe "out of date" is the wrong wording. RHEL/CentOS 5 is maintained, i.e. security issues and bugs are fixed. There's nothing "out of date" about a tool that works and is cost-effective. RHEL 6 still has to prove itself.
From harsh experience, I'm afraid it's the right wording. You can only
go so far with "backporting", and critical feature additions (such as the availability of GSSAPI in OpenSSH, warnings of local password storage in Subversion, git emacs macros incompatible with the out of date Emacs, and PHP dependencies unfulfilled for contemporary tools make it quite stale.
In my day job I support dozens of developer desktops that run CentOS 5 with a modified kernel supporting non-standard devices. It takes a few hours a week. Trying to track the bleeding edge supporting, say, Ubuntu would take much more time.
Well, yes. But the edge on RHEL 5 is 4 years old,a nd RHEL 6 (end eventually CentOS 6) will have been blunted for a year by the time it's published. It's a problem if you try to backport contemporary tools (which I do).
On 14/12/10 02:15, Nico Kadel-Garcia wrote:
On Mon, Dec 13, 2010 at 1:37 PM, Gé Weijers ge@weijers.org wrote:
On Mon, 13 Dec 2010, Nico Kadel-Garcia wrote:
RHEL is much better about that, although by now the "production" RHEL 5 is 4 years out of date, the "leading edge" RHEL 6 is now one year out of date after the lengthy release testing, and CentOS will always lag that.
I believe "out of date" is the wrong wording. RHEL/CentOS 5 is maintained, i.e. security issues and bugs are fixed. There's nothing "out of date" about a tool that works and is cost-effective. RHEL 6 still has to prove itself.
From harsh experience, I'm afraid it's the right wording. You can only go so far with "backporting", and critical feature additions (such as the availability of GSSAPI in OpenSSH, warnings of local password storage in Subversion, git emacs macros incompatible with the out of date Emacs, and PHP dependencies unfulfilled for contemporary tools make it quite stale.
In my day job I support dozens of developer desktops that run CentOS 5 with a modified kernel supporting non-standard devices. It takes a few hours a week. Trying to track the bleeding edge supporting, say, Ubuntu would take much more time.
Well, yes. But the edge on RHEL 5 is 4 years old,a nd RHEL 6 (end eventually CentOS 6) will have been blunted for a year by the time it's published. It's a problem if you try to backport contemporary tools (which I do).
RHEL/CentOS isn't supposed to be cutting-edge. That has never been the intention. It's supposed to be stable for 7-10 years. And I believe CentOS strives for the same, as they basically just re-wrap and re-brand RHEL packages.
That means that some of the software will stay behind, especially if there are no nasty bugs and security issues with them. Other critical software pieces will be updated, especially when it is related to bugs which endangers the stability or security of the system. But for an update of the software to happen, developers and tester strive to make sure it won't break compatibility or cause instabilities.
The kernel itself is a brilliant example. It's based on 2.6.18, but it contains a lot of features and hardware support which even came as late as in the 2.6.3x series. Just look at the KVM support which came in RHEL/CentOS 5.4. KVM was first introduced officially in the 2.6.20 kernel, IIRC. In addition, security issues which has been located in all kernel versions which also affects the 2.6.18 based kernel is backported.
See this link for a more info: https://access.redhat.com/support/policy/updates/errata/
What makes some of these backports tricky is that they work hard to maintain ABI (Application Binary Interface). That means that if you have an application using a specific library on RHEL/CentOS, that application should not need to be rebuilt at all if an updated library is installed. This gets even more difficult when looking at kABI (Kernel ABI), where the kernel can not change things in a way which breaks user space tools or libraries.
And this stability has its cost ... that you will not find bleeding edge versions on most of the software. There are some exceptions, but that is very seldom (Upgrading from Firefox 1.5 in RHEL5 to a 3.x based one, comes to mind).
When it comes to git support in Emacs, that is most probably due to that you try to install a newer git module in Emacs than what is supported. And IIRC, you even need to pull in git via EPEL, as git is not even a part of the standard RHEL5 package set. So in this case, git support isn't even expected in a standard RHEL/CentOS installation. Like it or not, but that's how the RHEL/CentOS world is defined.
And also take into consideration that RHEL6 is shipped with approx. 2.000 packages. And there are over 10.000 packages available for Fedora. Such a limited package scope is needed to be able to provide stability. And this stability is why so many loves to run RHEL/CentOS/ScientificLinux instead of many other Linux distros on their servers.
For the desktop side, I personally do see this restricted package list and long lasting package support (7-10 years) as a much more difficult barrier. But for the server side, I'm happy it is as it is. It gives me less to worry about.
So if you want a bleeding edge environment, go for Fedora. What goes in here might go into RHEL and then CentOS with time. What's not going into a new RHEL release might show up in EPEL, especially if you take care of that to happen. You can have that power if you want to.
kind regards,
David Sommerseth
And also take into consideration that RHEL6 is shipped with approx. 2.000 packages. And there are over 10.000 packages available for Fedora. Such a limited package scope is needed to be able to provide stability. And this stability is why so many loves to run RHEL/CentOS/ScientificLinux instead of many other Linux distros on their servers.
The fact that the number of packages is pretty limited in core RHEL/CentOS also makes that with additional repos such as EPEL (or RPMForge) you can have a lot of recent software. EPEL additionally guarantees that the base OS won't be updated.
Then you can always decide to backport some software for a given field, using the rest as a stable basis. As Karanbir Singh pointed out in a recent interview in DistroWatch, it can be much easier to innovate and be cutting edge in a given field if the rest stays stable, instead of doing so when the whole distribution is a moving target as in Fedora.
On Tue, Dec 14, 2010 at 4:40 AM, David Sommerseth dazo@users.sourceforge.net wrote:
On 14/12/10 02:15, Nico Kadel-Garcia wrote:
Well, yes. But the edge on RHEL 5 is 4 years old,a nd RHEL 6 (end eventually CentOS 6) will have been blunted for a year by the time it's published. It's a problem if you try to backport contemporary tools (which I do).
RHEL/CentOS isn't supposed to be cutting-edge. That has never been the intention. It's supposed to be stable for 7-10 years. And I believe CentOS strives for the same, as they basically just re-wrap and re-brand RHEL packages.
That means that some of the software will stay behind, especially if there are no nasty bugs and security issues with them. Other critical software pieces will be updated, especially when it is related to bugs which endangers the stability or security of the system. But for an update of the software to happen, developers and tester strive to make sure it won't break compatibility or cause instabilities.
The kernel itself is a brilliant example. It's based on 2.6.18, but it contains a lot of features and hardware support which even came as late as in the 2.6.3x series. Just look at the KVM support which came in RHEL/CentOS 5.4. KVM was first introduced officially in the 2.6.20 kernel, IIRC. In addition, security issues which has been located in all kernel versions which also affects the 2.6.18 based kernel is backported.
Backporting tiny bits of kernels to get a feature isn't enough, when you refuse to upgrade the components that interact with it. Take a good look at wireless device and graphics tablet support for examples of tools that require more than just one "fix". This kind of thing is a long standing issue since RHEL and Fedora splilt. Stability is good, but wasting engineering respinning installation media is not.
See this link for a more info: https://access.redhat.com/support/policy/updates/errata/
Been there, done that, submitted patches to EPEL and RPMforge on a regular basis.
And this stability has its cost ... that you will not find bleeding edge versions on most of the software. There are some exceptions, but that is very seldom (Upgrading from Firefox 1.5 in RHEL5 to a 3.x based one, comes to mind).
Well, true. But it's so stable it's pushing up daisies. RHEL 6 was long overdue.
When it comes to git support in Emacs, that is most probably due to that you try to install a newer git module in Emacs than what is supported.
Not. Emacs incorporated the vc-git.el module directly into emacs-22. The later git modules are also not backwards compatible with the older vc-git.el module, formerly published in git, and the older set of git modules are not compatible with contemporary git. So unless I plant to spend a lot of time going back and re-writing Lisp code (and I *HATE* Lisp code), or find someone else more comfortable with it who's not simply using Debian, Ubuntu, Fedora, Mandriva, or even CygWin, the emacs modules are not usable in RHEL/CentOS 5 with git.
And IIRC, you even need to pull in git via EPEL, as git is not even a part of the standard RHEL5 package set. So in this case, git support isn't even expected in a standard RHEL/CentOS installation. Like it or not, but that's how the RHEL/CentOS world is defined.
True. I've been trying to get it updated there: the EPEL version is stuck at 1.5.5,
And also take into consideration that RHEL6 is shipped with approx. 2.000 packages. And there are over 10.000 packages available for Fedora. Such a limited package scope is needed to be able to provide stability. And this stability is why so many loves to run RHEL/CentOS/ScientificLinux instead of many other Linux distros on their servers.
And they're actually supporte, rather than happenstance assembled and published, which is great. i don't discount this. It's just gotten too darned *old*. I went through the same thing with RHEL and CentOS 3 and 4, but RHEL 6 is particularly late.
For the desktop side, I personally do see this restricted package list and long lasting package support (7-10 years) as a much more difficult barrier. But for the server side, I'm happy it is as it is. It gives me less to worry about.
So if you want a bleeding edge environment, go for Fedora. What goes in here might go into RHEL and then CentOS with time. What's not going into a new RHEL release might show up in EPEL, especially if you take care of that to happen. You can have that power if you want to.
I find RPMforge more workable and responsive: The "we refuse to replace any RHEL published components" general policy of EPEL is unacceptable for tools like Subversion and MRTG and Nagios.
On Mon, Dec 13, 2010 at 07:48:51AM -0500, Nico Kadel-Garcia wrote:
Also, don't forgot to contribute or actually *purchase* the licenses for the one you use.
http://www.centos.org/modules/tinycontent/index.php?id=23
"CentOS is currently reviewing our cash donation program. In the mean time we are not accepting any financial donations. We hope to have a process in place by the middle of 2010 that allows us to change this and go back to accepting cash donations, so do check back later."
Does anyone know what the main issues are that need to be addressed before CentOS can accept cash donations? Are the issues mainly technical, mainly administrative, or an almost even split?
--keith
On Dec 13, 2010, at 5:02 AM, lhecking@users.sourceforge.net wrote:
They are OK with the roll-your-own style of Gentoo?
Especially with it's cutting edge versions, bugs, security holes and the only way to overcome them is to upgrade to an even newer version that may break compatibility, introduce new bugs, zero-day vulnerabilities, the list goes on and on.
So, you are saying that other OSes, even other Linux distributions, have no bugs, security holes, compatibility issues and zero-days? Looks like we don't need M$ to spread FUD about Linux, we're well capable of doing it ourselves ;)
You got me all wrong here. I'm only saying that in Gentoo
Gentoo is a great distro for learning Linux, in a computer lab, or for a home hobbyist, but not quite enterprise stable.
There are in fact people who run Gentoo in the Enterprise, and it's up to the sysadmin to decide which upgrade policies to implement. While this would not necessarily be my personal choice, it's perfectly legit. As is running Windows should the powers that be require it.
On Dec 13, 2010, at 5:02 AM, lhecking@users.sourceforge.net wrote:
They are OK with the roll-your-own style of Gentoo?
Especially with it's cutting edge versions, bugs, security holes and the only way to overcome them is to upgrade to an even newer version that may break compatibility, introduce new bugs, zero-day vulnerabilities, the list goes on and on.
So, you are saying that other OSes, even other Linux distributions, have no bugs, security holes, compatibility issues and zero-days? Looks like we don't need M$ to spread FUD about Linux, we're well capable of doing it ourselves ;)
You got me all wrong here, I'm merely trying to say that Gentoo doesn't backport bug fixes and security updates to the current versions and therefore to fix these one has to upgrade to newer versions which may break compatibility with the existing environment.
Gentoo is a great distro for learning Linux, in a computer lab, or for a home hobbyist, but not quite enterprise stable.
There are in fact people who run Gentoo in the Enterprise, and it's up to the sysadmin to decide which upgrade policies to implement. While this would not necessarily be my personal choice, it's perfectly legit. As is running Windows should the powers that be require it.
Agreed, if the risk is acceptable for the purpose then of course run the software you wish.
-Ross
On Sun, Dec 12, 2010 at 11:45 AM, Zdenek zdenek.w@o2.pl wrote:
Hello all.
Does anybody have experience with pushing CentOS in enterprise?
I have the following situation. I tried to promote CentOS to local bank. They have now a couple of Gentoo-based systems and I tried to explain them that CentOS is much better option for enterprises.
IT department is interested in stability of the system, so they are ready to give CentOS a try. But the problem came from management and information security division.
That guys look much affected by FUD created by M$. They tell the story like "you can not rely on this open source, it is built by just few community geeks, you never know what will happen if the developer will be hit by bus tomorrow" and so on. They especially refer to the last year FUD story published at ZDNet (http://goo.gl/y0LBi). So, IT guys are allowed to use open source only if they can prove that it has stable community and transparent development and build process they can reproduce on their own if necessary.
I guess, I'm not the first who encounter this issue. Could you share your experience how to deal with it? Are there any public resources that can be used as proofs of CentOS stability?
-- Zdenek
This sounds a lot more like a religious war from the people who think that using Gentoo is the "right" way to do things because it's pure from source, etc... The fact that they already have Gentoo means they are not opposed to Open Source per se, just that they seem to look at Redhat as the "MS of the Linux world", and have some kind of prejudice against that.
The only way to combat this view is to highlight all the problems of maintaining things from source code, and to show the benefits of a standard platform. Be prepared for a high amount of dismissiveness, attitude, and flat out accusations that "maintaining from source isn't that hard and if you can't do it you're obviously not qualified for the job". This is a sure sign of an amateur sysadmin or someone who thinks a sysadmin is just a person too dumb to be a programmer. As for the standard platform thing, just look at what all major vendors support for Linux, and you can bet that Redhat is #1 on the list.
As for concerns about the community going away, it's quite easy to point out that all commercial software also has this risk, and that risk could actually be higher since they have to maintain profits. And since when can you build any commercial software from source if the company goes out of business?
On Mon, Dec 13, 2010 at 12:22:28PM -0500, Brian Mathis wrote:
On Sun, Dec 12, 2010 at 11:45 AM, Zdenek zdenek.w@o2.pl wrote:
Hello all.
Does anybody have experience with pushing CentOS in enterprise?
I have the following situation. I tried to promote CentOS to local bank. They have now a couple of Gentoo-based systems and I tried to explain them that CentOS is much better option for enterprises.
IT department is interested in stability of the system, so they are ready to give CentOS a try. But the problem came from management and information security division.
That guys look much affected by FUD created by M$. They tell the story like "you can not rely on this open source, it is built by just few community geeks, you never know what will happen if the developer will be hit by bus tomorrow" and so on. They especially refer to the last year FUD story published at ZDNet (http://goo.gl/y0LBi). So, IT guys are allowed to use open source only if they can prove that it has stable community and transparent development and build process they can reproduce on their own if necessary.
I guess, I'm not the first who encounter this issue. Could you share your experience how to deal with it? Are there any public resources that can be used as proofs of CentOS stability?
-- Zdenek
This sounds a lot more like a religious war from the people who think that using Gentoo is the "right" way to do things because it's pure from source, etc... The fact that they already have Gentoo means they are not opposed to Open Source per se, just that they seem to look at Redhat as the "MS of the Linux world", and have some kind of prejudice against that.
The only way to combat this view is to highlight all the problems of maintaining things from source code, and to show the benefits of a standard platform. Be prepared for a high amount of dismissiveness, attitude, and flat out accusations that "maintaining from source isn't that hard and if you can't do it you're obviously not qualified for the job". This is a sure sign of an amateur sysadmin or someone who thinks a sysadmin is just a person too dumb to be a programmer. As for the standard platform thing, just look at what all major vendors support for Linux, and you can bet that Redhat is #1 on the list.
As for concerns about the community going away, it's quite easy to point out that all commercial software also has this risk, and that risk could actually be higher since they have to maintain profits. And since when can you build any commercial software from source if the company goes out of business?
Anyone who advocates maintaining from source has simply never administered more than a handful of machines at a time.
Great way to learn, but impractical for hundreds to thousands of machines.
Ray
Anyone who advocates maintaining from source has simply never administered more than a handful of machines at a time.
Great way to learn, but impractical for hundreds to thousands of machines.
http://en.wikipedia.org/wiki/Portage_%28software%29#Binary_Packages http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2&chap=3#doc...
Most useful if the machines in question are identical or near identical.
--------------------------------------------------------------- This message and any attachments may contain Cypress (or its subsidiaries) confidential information. If it has been received in error, please advise the sender and immediately delete this message. ---------------------------------------------------------------
On Mon, Dec 13, 2010 at 05:47:53PM +0000, lhecking@users.sourceforge.net wrote:
Anyone who advocates maintaining from source has simply never administered more than a handful of machines at a time.
Great way to learn, but impractical for hundreds to thousands of machines.
http://en.wikipedia.org/wiki/Portage_%28software%29#Binary_Packages http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2&chap=3#doc...
Most useful if the machines in question are identical or near identical.
Sounds like Gentoo would provide infrastructure to automate much of maintaining and distributing errata to systems... probably even on source built packages (?)
Definitely won't scale if you're having to do it by hand though :)
Ray
lhecking@users.sourceforge.net wrote:
Anyone who advocates maintaining from source has simply never administered more than a handful of machines at a time.
Great way to learn, but impractical for hundreds to thousands of machines.
http://en.wikipedia.org/wiki/Portage_%28software%29#Binary_Packages http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2&chap=3#doc...
Most useful if the machines in question are identical or near identical.
And all on the same side of the firewall(s). On the other hand, how can they be against "OSS", when they've ok'd gentoo. I mean, have they gone through *all* the code? <g>
mark
On Sun, Dec 12, 2010 at 11:45 AM, Zdenek zdenek.w@o2.pl wrote:
Hello all.
Does anybody have experience with pushing CentOS in enterprise?
What does 'enterprise' mean to you?
-Kristopher Kane
On Mon, Dec 13, 2010 at 12:55:12PM -0500, Kristopher Kane wrote:
On Sun, Dec 12, 2010 at 11:45 AM, Zdenek zdenek.w@o2.pl wrote:
Hello all.
Does anybody have experience with pushing CentOS in enterprise?
What does 'enterprise' mean to you?
Space. The final frontier...
Ray Van Dolson wrote:
On Mon, Dec 13, 2010 at 12:55:12PM -0500, Kristopher Kane wrote:
On Sun, Dec 12, 2010 at 11:45 AM, Zdenek zdenek.w@o2.pl wrote:
Hello all.
Does anybody have experience with pushing CentOS in enterprise?
What does 'enterprise' mean to you?
Space. The final frontier...
Hey, that's the question, when you're trying to get new, bigger disks!
mark
On Monday, December 13, 2010 01:03:03 pm m.roth@5-cent.us wrote:
What does 'enterprise' mean to you?
Space. The final frontier...
Hey, that's the question, when you're trying to get new, bigger disks!
What we need is a working warp drive. These magnetic impulse drives are still too sublight....
That or a ThinkGeeks enterprise pizza cutter.
Lamar Owen wrote:
On Monday, December 13, 2010 01:03:03 pm m.roth@5-cent.us wrote:
What does 'enterprise' mean to you?
Space. The final frontier...
Hey, that's the question, when you're trying to get new, bigger disks!
What we need is a working warp drive. These magnetic impulse drives are still too sublight....
That or a ThinkGeeks enterprise pizza cutter.
Oog... I just looked that up.... http://www.thinkgeek.com/homeoffice/kitchen/dea2/?source=google_home_office&cpg=ogho1&gclid=CLiQtsPt6aUCFRVx5QodJHRAYQ
mark "not sure I want to know where no man has gone before...."
On Tuesday, December 14, 2010 02:28 AM, m.roth@5-cent.us wrote:
Oog... I just looked that up.... http://www.thinkgeek.com/homeoffice/kitchen/dea2/?source=google_home_office&cpg=ogho1&gclid=CLiQtsPt6aUCFRVx5QodJHRAYQ
mark "not sure I want to know where no man has cut before...."
There, fixed that for you.
-
Brian Mathis -
Christopher Chan -
David Sommerseth -
Eero Volotinen -
Gé Weijers -
Keith Keller -
Kevin Thorpe -
Kristopher Kane -
Lamar Owen -
Les Mikesell -
lhecking＠users.sourceforge.net -
Luigi Rosa -
m.roth＠5-cent.us -
Mathieu Baudier -
Negative -
Nicholas -
Nico Kadel-Garcia -
Ray Van Dolson -
Robert Heller -
Ross Walker -
Zdenek