What's the point of using CentOS these days? Scientific Linux is basically compiled from the same sources and doesn't lag months behind RHEL. Did I miss something?
The "why" is that CentOS has brand recognition, and many who don't want to purchase an RHEL license, but want to run software that's been qualified/RPM'd for that platform, will naturally turn to CentOS.
I've been following Linux Distros for 10 Years, Have built my own LFS, have a couple slicehost servers, one linode server, and a bare metal server at Server Beach - This is the first time I've heard that "Scientific Linux" could be used in place of CentOS.
Now that almost certainly means that I'm ignorant of something that those more clued than me would consider obvious, but, in terms of knowledge of Linux Distributions among your typical IT crowd, I'm probably in the 95+ Percentile - so you can imagine how many others out there haven't heard of Scientific Linux and just turn to CentOS without knowing better.
I have about the same time in Linux as you but how I found out about SL was due to the delays CentOS has been having. Previously, the CentOS releases were not far behind RHEL releases as far as timing. But when 6.0 failed to show up I visited the CentOS forum.
For whatever reason that only the internal developers know, announced milestone after milestone were delayed. The chief complaint about CentOS has been the lack of openness or transparency with the devs. Numerous offers to help and contribute to the project have not been accepted. With little feedback or request for help, users became antsy if the CentOS project was dead in the water. That's where Scientific Linux seemed to have found some new users when they were the first out of the gate with a version 6 based on RHEL.
While it's great that CentOS 6.0 is out, maybe the better question is to ask why not 6.1 which was already released by RHEL some time ago (May 19th) that addresses some security issues.
I used CentOS quite a bit but have moved off to distributions as I'm happy to pay for some software and contribute to other ecosystems where there is an openness to them.
The real brand is RHEL. Otherwise people don't care much what the brand of the binary compiled Linux they are using. We switched from CentOS to SL to CentOS.
To be honest, the staff @ CERN and Fermilab inspire more confidence in their commitment to their distro than the CentOS. I understand the guys have full time jobs and do this on the side, but in the end that becomes kind of irrelevant for some new end user who is just looking for binary compatibility with RHEL.
> This is the first time I've heard that "Scientific Linux"
Then you haven't followed the linux distros (especially RHEL binary compatible clones) close enough. SL is actually older than CentOS.
Re: Haven't followed the linux distros close enough.
Yes, that is my point. I'm not challenging the fact that SL is a credible, (possibly much more so) alternative to RHEL than CentOS - I'm just trying to point out that if _I_ didn't know that SL was a goto distribution for people who needed a rebuild of RHEL, then I'm fairly certain 95% of the IT population doesn't either - and that's why _they_ go to CentOS - it's a name they know and trust (for better or worse)
BTW - in my defense, I just hopped onto my SliceHost/Linode Dashboard, and, of the 56 version/distros they offer, Scientific Linux is nowhere to be found.
But now that you know about it do you care really what it is called, if it is just a binary compatible RHEL distro. If CentOS disappeared tomorrow you could just run your software on SL, or buy a RHEL license. I certainly do not want to trivialize the work that CentOS and SL do (and it is a lot of work to maintain these distros) but when the main point of the distro is to be a binary clone of another distro, brand names become meaningless. We could switch from SL to CentOS and then go back. It wouldn't be that hard. If another clone appeared tomorrow we could switch to that. The only criteria is reliability of release and promptness.
The "Brand" CentOS says to me "This distribution is binary identical to RHEL - you can do all your development on it, and deploy hundreds of servers running it - and be able to run all of the software qualified for RHEL. You can also write, and test, software on this platform, and have your _customers_ then run that software on their instances of RHEL"
I don't have that level of faith in SL's distro, it will probably take a year or so of observation before I would consider it a potential replacement for CentOS.
Even convincing engineers, and developers, that they could develop on CentOS and have some assurance that their code would run fine on RHEL without extensive regression testing was a challenge.
And even with all this - Oracle won't provide you support if you run their RHEL qualified Database Server on CentOS.
I guess this is just a long way of saying, I _don't_ know that SL is a binary compatible RHEL distro, but I do know that about CentOS. That's what the brand name does for me.
Here's another data point. I've been using Red Hat since 6.0 (and later RHEL and Fedora). I have used CentOS in the past. This is the first time ever I've heard about Scientific Linux. Also, none of the VPS services I use support it. They all support CentOS.
What I'm saying is that it's really not a a "mainstream" distro.
> This is the first time I've heard that "Scientific Linux"
"Then you haven't followed the linux distros (especially RHEL binary compatible clones) close enough. SL is actually older than CentOS."
I was trying to explain that your average Linux sysadmin is aware of RHEL and Centos, but not "Scientific Linux". That's all. I stand by that statement.
Probably because your comment added nothing. FWIW, I hadn't heard of SL either, despite having used and administered Linux distributions for the past 15 years. Feel free to use that fact to call my entire career into question, too, though.
I think the main difference is that Centos strives to be "100% binary compatible." We write software targeted to enterprise users that are generally running Redhat. Our development and test platforms are Centos.
Scientific Linux, while compiled from Redhat sources, does not strive for binary compatibility with Redhat.
They compile the same SRPMS after they strip the logos and Redhat references out. Yes, they add extra optional packages like OpenAFS and others, but you can just disable those repos.
M5 Hosting does offer Scientific Linux for dedicated servers: http://www.m5hosting.com/scientific-linux-dedicated-server.p... But you are correct, it is hard to find. Some dedicated server hosts will install it if you ask, but larger hosts and VPS providers might not be so eager to depart from their standard images/platforms.
Billion dollar companies spend money to buy Red Hat Enterprise Linux licenses, because promising 100% binary compatibility with RHEL isn't as good as being RHEL. If CentOS is even an option, Scientific Linux should be as well.
The "lag" you speak of actually can be thought of as a feature. For example, you don't want doing a 'yum upgrade' to upgrade PHP from 5.2 to 5.3 and break software you are running. You want your core operating system to actually be fairly stable, and not have to worry about upgrades randomly breaking things.
When it comes down to it, you really don't need the latest and greatest software on a server. Aside from security fixes, there's very little reason to upgrade software on a server just because a new version was released.
A 9 month lag behind RHEL is a feature? You are either misunderstanding something or just trolling.
> When it comes down to it, you really don't need the latest and greatest software on a server.
It is really great when others tell me what I need to run on my server.
Just to be clear, you do know that CentOS is a binary compatible compilation of RHEL? The distro is not about adding feature or improvements or spinning their own from scratch. There is no need to wait for it to become "fairly stable" it just tracks RHEL. If RHEL is unstable, then CentOS is going to be unstable. That is the point of it. Claiming that their lag was on purpose is a little dishonest I think.
Are you saying that RHEL break PHP by upgrading from 5.2 to 5.3?
That would be very strange, RHEL's reknowned for very strict binary compatibility and backporting every security fix to whatever they shipped originally. Lagging behind RHEL updates would normally just mean you're insecure / have bugs for longer.
OK, but unless you have evidence that Red Hat have specifically broken their release policy that won't happen in the middle of a major release, so that's no reason to lag behind on updates.
You realize that CentOS is based on RHEL which is already extremely stable and conservative in updates? Even if new CentOS was released on the same day that RHEL, it wouldn't be 'the latest and greatest software'. CentOS lagging RHEL doesn't add anything of value.
The lag is indeed not a feature, its due to the fact that Red Hat is an organisation with people whom are salaried, compared to the people who work on CentOS that do so for free.
The idea of a monolithic base operating system has got to go. A machine as a unit of encapsulation wastes resources and forces a needless race towards lowest common denominator bug compatible versions of packages.
If application A needs PHP 5.2 and application B needs PHP 5.3 they should both be able to exist on a "machine" w/o resorting to complicated maintenance or having separate OS instances per app.
Witness, http://nixos.org/ a purely functional package management system. Use it either in userland or as an entire OS. You decide.
Isn't this continuing the debate about centralised libraries vs. localised ones? Then you have PHP 5.2 and PHP 5.3 to bug fix, and new applications then need their own PHP interpreter or they add dependency crosslinks. That doesn't sound like it's getting rid of "complicated maintenance".
That's the point of the nix package manager, it manages that complexity for you. The libraries are centralized in that each is stored in a path that is the checksum of all it's inputs. It really is an interesting system, they've published several papers on it that are worth reading.
Yeah, one issue with CentOS/Redhat was that yum required Python 2.4 so you had to keep it around and install python 2.7 as python27.
Thankfully Python makes it easy to run applications in a virtual environment so you can install different versions of libraries into the virtualenv without worrying about breaking things somewhere else.
Virtualization solves this. You just install two OS instances with the differing requirements, and then run it all on some super-stable host OS (RHEL 6.1 being ideal). The host OS doesn't get involved in details of what web app requires what, because that has all been pushed up to the VMs.
Edit: Yes I do implement production servers like this. Apache + mod_rpaf + mod_proxy runs on the host to act as an accelerator, cache and to direct requests to each VM webserver.
You are probably joking but at least 2.6 is still supported by some major projects. Many have dropped 2.4 support already (NetworkX for instance). So I am pretty exciting about 2.6 actually ;-)
Having just spent the better part of a day setting up Django on a Centos 5.5 machine I am doing a happy dance at this news. The amount of work to get things up and running is truly painful. Especially if you are on a x64 system.
A completely reworked security framework; among other major changes. We've had a RHEL 6 installation for a few months and are still working thru the changes. Basic Linode users might want to wait unless you really need the Python updates.
This release includes transparent large page? This will hugely increase the performance of memory-consuming applications (c,f. Redis, HBase, MongoDB, etc.). I confirmed at RHEL6.
