The CentOS Project is pleased to announce the immediate availability of CentOS 7 for x86_64, including images for docker, and various cloud providers. There are many fundamental changes in this release, compared to previous releases of CentOS. Notably the inclusion of systemd, Gnome3, and a default filesystem of XFS. For more information about what makes CentOS 7 stand out, please see our release notes.
CentOS 6 can be upgraded to 7, but that functionality is still being tested.
Scientific Linux 7 alpha is also released. It does not depend on the Red Hat infrastructure, although it uses RHEL as upstream, so it is more independent than CentOS.
http://listserv.fnal.gov/scripts/wa.exe?A2=ind1407&L=scientific-lin…
I’ve personally never understood why we need more than one free clone of RHEL myself (ignoring that Oracle have a paid clone of it too!). CentOS 7 debuts new SIGs (similar to Fedora Spins) which points the way for those who want to produce a customised version of CentOS whilst benefiting from the CentOS infrastructure.
It makes me wonder if Scientific Linux might consider becoming a CentOS SIG in the future, since it’s effectively a third-party SIG really (changed artwork/branding, customised set of packages included – all exactly what SIGs do).
No, they rejected the SIG idea (and indeed did give it very serious consideration). There are pros and cons. They want the independence and a few tweaks for large computing farms. Maybe a SIG could work too, sure, it probably comes down to control and trust.
SL will be installed on *many* servers for serious computing work at Fermilab and CERN, so they cannot take (political) risks. The (tiny) risk being that CentOS will be more targeted to small server installations / testing.
For me, I just like the name and the artwork better 😉
That is untrue, CERN is moving to CentOS:
http://bit.ly/TRtkcz
and the 2 CERN Linux Admins are joining the CentOS team to run the CentOS Community Build Systems, which is where SIGs will build packages:
http://bit.ly/U2mq4I
Scientific Linux Fermi has decided to continue their Scientific Linux distro though, yes.
Nothing is final yet.
http://linux.web.cern.ch/linux/nextversion.shtml
Yes, as I wrote, they did give it very serious consideration, as your links also show. But the CERN guys also like to work with Fermi and now that Fermi has their own alpha in place, we have to wait on the final decision from the CERN admins.
OK .. I am one of the CentOS Developers, and I think it is pretty decided. They are running our Community Build Services.
That is not a decision at all. That is just giving it very serious consideration… by testing it. Something one definitely needs to do, given the number of compute nodes and workstations running SL.
Although my impression is also that CERN leans more towards forming a SIG then Fermi does. My bet is that they want to walk the same road.
We will have to wait to see the outcome. Now that Fermi has SL7 alpha, they will receive feedback that can still change opinions (in both ways).
What I mean is that 2 CERN Linux Developers are now installing and in charge of running the CentOS.org Community Build System for the CentOS Project.
They are setting it up right now .. they are not just forming a SIG .. they are running the build machines (owned by the CentOS Project) that every SIG will use to build packages.
http://bit.ly/U2mq4I
Edited 2014-07-09 19:11 UTC
Ah, I did not know that. That is indeed an involvement that exceeds mere testing.
And, 9 of the top 500 super computers in the world run CentOS … that is PRETTY serious (2nd most named Linux distro in the top 500).
Actually, many more than 9, but 9 of the systems that list OS other than the Generic “Linux” use CentOS:
http://bit.ly/1qFiSEr
Several of the 410 machines that just list Linux are CentOS as well.
Centos generally sticks to upstream = almost no updated packages.
Scientific Linux keeps the same base, but will potentially update some desktop packages at some point to keep pace with current releases, though base and other packages will remain the same as Centos/RHEL.
Edited 2014-07-09 02:09 UTC
That is false. Unless proven otherwise.
Sometimes I need RH clone fast. Scientific Linux helped a lot with their 6.0 release. Additionally I like Scientific repos with security and fastbugs updates, while CentOS has all on one bag.
And just like RHEL 7 (and recent Fedora releases), it has the worst installer known to man. Seriously, who actually enjoys using the RHEL7/Fedora20 installer?
The installer is the absolute least important part of an operating system.
And the CentOS/Fedora installer isn’t that bad. Solaris is much worse.
I disagree. Right now installing SL7 alpha, with that dreaded installer… The installer for Solaris 11.2 (beta) served me way better. YMMV.
Disagree. The new Anaconda is slow, unresponsive, unintuitive, and lacking in features. For example, try installing Fedora 20 on a system with an existing partition layout without formatting the root filesystem. If you can figure out how to tell the installer that’s what you want, it’ll helpfully refuse to let you do it with no real reason (except that the installer is specifically designed not to let you).
Care to cite the missing features?
This is a case of being used to the old installation method and fear of leaving own confort zone. The hub layout shows the ease of access. As for the slowness, how that happens and what specification is used?
I have no problem installing Fedora 20 which the existing partition including the preserved home directory once I figured out how it works. It is different given its advanced functionality compared to generic installer found on either Ubuntu or its variant Linux Mint.
For those looking at Anaconda installer, here is a good tour provided by ZDNET: http://www.zdnet.com/fedora-20s-anaconda-installer-hands-on-7000024…
Anaconda sucks ass in its latest iteration. I swear that the Gnome devs got hold of it and decided to remake it in Gnome’s image. Here is just some of what is missing:
No software raid tools
No add on repos
the list of software groups is incomplete
No specific package adding/deletion
One big one that I miss is being able to do a virt host install. Virtualization is not in the group list.
When I mentioned these missing features, I was first told that I was doing it wrong, and then told I needed to use a kickstart file to build. Why in the hell do I need to set up kickstart installs if I am building a one off? I know they say that less is more, but usually less is, well, less.
Except, software is available during install. Just make sure to create a /boot partition – Anaconda will automatically confine it to the boot device so booting works.
Except, if you go into the sources section of the install, it lets you add some.
Not exactly sure what you mean by that, but I’ll take your word for it.
Okay. Maybe not individual packages, but plenty of sub groups are available. For example, the Virtualization Host group has add-ons for:
Network File System clients
Remote Management for Linux
Virtualization Platform
Compatibility Libraries
Development Tools
Smart Card Support
Except, it totally is in the list.
How is the sysetm installer the least important piece of the operating system? If the system does not install properly, then the entire operating system is useless. Apart from the kernel, the installer is one of the most vital parts of the operating system and it needs to work properly. The fact that Red Hat so badly mangled their installer does not give me confidence RHEL 7 (and its clones) will be worth using.
I didn’t realize I needed to add “barring any crippling issues.”
I mean, anything that can be so broken as to make a system unusable can be considered the most important part.
As long as the installer manages to do the bare minimum, meaning, get your system on to disk in a bootable state, then the rest is just utterly unimportant. It’s something you generally do only once.
It’s something you generally do only once…. Yes, per box. Do you really want to go through the same broken installer hundreds of times over the course of the operating system’s life cycle?
The Fedora/Red Hat/CentOS installer is a horrible mess and administrators are not going to want to deal with it, especially since the previous installer worked so much better.
I do think that the latest Anaconda installer is a bit of a pain in the backside, even ignoring its *bold* SHOUTY headings (why are all the headings in capitals and some even in bold and all capitals?).
Its weakest point by far is the very confusing partitioning section – mixed units (yes, K and GB can be on the same screen) is a complete disaster, it’s not obvious how to use all the remaining space on a device for the final partition (answer: set an overlarge value for the size and it will truncate it) and if you’ve got existing OS’es/partitions on a device it’s not obvious that you’ve got to select them one by one and add in mount points manually.
It’s also a bit too easy to forget to config your networking in the installer (it’s unconfigured by default and doesn’t block or even warn about unconfigured networking) and then wonder why your installed CentOS 7 has no net connection when you first boot it. Yes, it’s easy enough to turn it on via the NetworkManager icon, but there’s very few OS’es now that don’t at least have DHCP/networking active on first boot.
If you’re installing on hundreds of desktops one at at time, you’re doing something wrong. You should be pushing images or using kickstart for that many machines.
Still, having used both the Fedora installer multiple times and now the CentOS 7 installer, I simply don’t understand the complaints about it.
It’s fairly straightforward considering the options it has to expose.
Is centos7 a good choice for a desktop?
I suppose these days yo no longer need cutting edge distros to ensure basic things like wifi and video replay works?
That is true, and if you have just basic needs and want stability, than yes.
But soon you might find yourself in the situation that you will add custom repositories because you just want some application or newer version or feature…
So yes, if you are sure about your future needs, and if you need stability, go for it. Otherwise, Arch / Mint / Ubuntu / Fedora / Mageia are just better choices.
Ubuntu, Fedora etc are better than CentOS?
Really?
Ubuntu seems to change according to the whims of Canonical. Mint wouldn’t be where it is today if it wasn’t.
Fedora, and I am a fan of the distro is not for the timid or newbie. It is unashamedly a bleeding edge distro. As such it is sometimes very fragile.
CentOS is my distro of choice these days. Stable and does the job I want it to. Yes, I use it on the desktop as well as servers and in VM’s. Sure the new Anaconda can throw a few people but honestly, how much of the life of a linux system is ‘Installation’?
(Unless you are a Journalist that is…)
Also, you get the updates that RH make to RHEL 5,6 and now 7. 10 years of updates should be enough for anyone in most circumstances.
Me, I am going for a Centos 7 workstation/desktop. Had to select if KDE or GNOME, GNOME to be fair with them is now better looking except from the gray button.
Try Fedora 19 in live mode. It’s what CentOS 7 was based on. The good news is that if you need proprietary GPU drivers, latest Enterprise Linux is always supported by nvidia and fglrx.
There’s also Gnome and KDE live versions of CentOS 7 to try out, no need to use Fedora 19 for that.
And the installer is not so bad, though I prefer the one on CentOs 6.
Depends. Do you value “stability” over having software that was released less than 5 years ago?
To be fair, some desktop software is actually kept up to date, like Firefox, LibreOffice, flash.
And then there is the Software Collections and Developer Toolset with paralell installable versions of server and development packages (mysql/mariadb, perl, python, ruby, gcc).
But yeah, if you want a current desktop you should consider other distros.
Well, CentOS is awesome for servers but I would not use it for desktop unless your workplace has a demand for conformity/uniformity software deployment. Unless something changed lately (I confess I had not used it for Desktop deployment on 4+ years), the obsolescence of some packages may become a problem.
To be fair, if you plan to use it on scientific activities, EPEL (https://fedoraproject.org/wiki/EPEL) provides you packages reasonably up-to-date. The only problems I had were mainly related to packages that would require more recent versions of what were on the core OS base/system set and this is quite uncommon for scientific packages. I ended moving from it because I wanted updated versions for development tools (compiler, IDE, etc).
One note about the previous paragraph: I explained the main problems I had, but there is one another even less common, packages that may need to be compiled against other libs whose licenses are “non-conforming” to expose some desired features you may want/need are, sometimes hard to “upgrade” because of dependence chains. Don’t know if it is still true, though (again, to be fair, it may be a problem for other distros too).
Anyway, For desktops I prefer very much openSUSE plus some extras repos from “http://download.opensuse.org/repositories/“ to keep packages classes you may need more up-to-date. Also, the community has extras packages on build.opensuse.org and you may even use OBS to compile your own packages set.
Edited 2014-07-09 15:44 UTC
COPR (Cool Other Package Repository) “http://copr.fedoraproject.org/“ is the equivalent of Suse OBS.
Sooner or later Chrome, Steam, or xyz will just say no without new libs.
And prepare for rebuilding tons of packages from Fedora 19/20 in near future. It doesn’t hurt, but takes a lot of time and you end with gazillion devels installed. Unless you will rebuild them on virtual machine and create your own yum repo there.
Also choose hardware very carefully, you will see new drivers rather sporadically.
Want more?
True, it already happend with CentOS 6 AFAIK, and with Ubuntu 10.04.
Why would you? Unless you can’t find those packages in EPEL (https://fedoraproject.org/wiki/EPEL) or some other 3rd party repo I don’t see the need to recompile software from Fedora (which is basically what EPEL does).
New drivers go in roughly every 6 months with the point releases, for the first few years. After that it’s just bug fixes mostly.
EPEL doesn’t have everything. Python-visual and avidemux are just two examples of dependency hell you’ll have on CentOS.
EPEL doesn’t have everything. Python-visual and avidemux are just two examples of dependency hell you’ll have on CentOS. [/q]
Fair enough, EPEL doesn’t have everything that Fedora carries, but you now went from “tons of packages” to just two examples.
If you add another 3rd party repo like repoforge, I’m sure you would avoid the need to compile anything.
Yesterday i downloaded and tried CentOS 7. It works (barely) in a VirtualBox instance. It’s slow and clunky, but useable. I tried booting it on a couple of physical machines and the operating system failed to boot. Dozens of other distros work on this same hardware, so I know it’s not a hardware problem. The media checksum passed, so it looks like there is something wrong with CentOS that prevents it from loading. Not a promising start.
A couple of kernel options to try (press Tab at the first installer boot screen):
nomodeset
I needed this for an ancient Dell Zino HD with a Mobility Radeon HD 4225/4250 GPU.
pci=noacpi
This magic incantation often helps too, particularly on older kit.
Unfortunately, the open source radeon driver can’t seem to detect the monitor dimensions, so defaulted to a bizarre setting of 1280×1024 (monitor was actually 1680×1050). At this point, I tried the Catalyst driver, which just borked things even worse to the point where I re-installed CentOS 7 and started again…
Personally, I think kernel mode setting is a Bad Thing(tm) – I seem to have to use nomodeset on an awful lot of Linux installs to work around the “blank screen on installer boot” issues. Linux installers should *not* use KMS to initialise their graphical environment and it’s even debatable whether it should be left in on the installed kernel.
Great news! I’m using RHEL professionaly at work, so this would be a great lab for me to use in home.
Also, inclusion of XFS is just awesome. XFS works thousand times better than any ext filesystem. I used to have problems with ext – it liked to ate most of my CPU and HDD time … XFS is different. It just works.