On Wed, Feb 26, 2014 at 5:05 PM, Alexander Arlt <centos at track5.de> wrote: >>> >> Much of the point of free software is the fact that once something has >> been done once, any number of copies of it 'just work' for no extra >> cost. So, the missing piece here is just a reasonable way for >> someone else to duplicate the setup. > > Again, there is the assumption that there is a reasonable way for > duplicating this setup. There is a way. If you were to hand yum the right package revisions in the right order with the right repos enabled for each, it would build a matching system for you. The low level bits are there. > RHEL and CentOS have a very clear focus on what > they want to achieve. Which currently doesn't involve helping users avoid shooting themselves in the foot. >> No, that's really only relevant after something goes wrong. The point >> of it is the effort that goes into avoiding/fixing the things that go >> wrong. And the more people that run exactly the same code and report >> their bugs, sometimes with fixes, the better that turns out. > > Not in my world. CentOS is accepted as a full blown RHEL-alternative by > nearly everyone doing audits. You will be able to achieve SOX-compliance > with almost any auditor I have met so far by using CentOS. Enterprise > nowadays is far more than just having a hotline to call when things go > wrong. And - at least in my opinion - CentOS is the only community > driven Linux today fulfilling enterprise requirements without big time > hassle. Are there restrictions on content from EPEL? Oracle Java? Your own applications? Where do 3rd party additions become a problem in this context? >> Adding additional applications doesn't hurt the base. It is just >> better testing for it. > > It depends on the application. You will have the effort of backporting > patches if you are not able to bring current versions of several > libraries to the game. Or you will have to update core libraries. Or use static linkage - or alternate locations like software collections. There are ways that don't break the base... >> >> I assume the 4 is a typo there. RHEL 4's EOL was 2-29-2012, But >> that's all kind of irrelevant to what we should be preparing for after >> a new install of CentOS 7 and what to expect from it. > > No, RHEL 4 has Extended Life Phase till 2015. And will probably be even > longer supported - at least that's what we're all hoping for. And that > is not irrelevant, because - basically - that's what enterprise is > about. Getting long term support and that's maybe 10+ years. Interesting - I just got the 2012 EOL date from a Red Hat google hit. But I had some early problems with Centos4 and moved to 5 as soon as it came out. I think they mostly involved perl module packaging, though, and might not have affected other uses. -- Les Mikesell lesmikesell at gmail.com