Red Hat Enterprise Linux 7 Released 231
An anonymous reader writes: Today, Red Hat unveiled Red Hat Enterprise Linux 7, with new features designed to meet both modern datacenter and next-generation IT requirements for cloud, Linux Containers, and big data. The new version includes Linux containers (LXC), which let Linux users easily create and manage system or application containers, improved MS Active Directory / Identity Management (IdM) integration, XFS as the default file system, scaling to 500 TB (additional file system choices such as btrfs, ext{3,4} and others are available), a new and improved installation experience, managing Linux servers with OpenLMI, enhancements to both NFS and GFS2, optimized network management, bandwidth, the use of KVM Virtualization technology and more. See the complete list of features here (PDF). CentOS 7 shouldn't be lagging too far behind due to recent cooperation between Red Hat and CentOS project.
Source RPMs (Score:5, Informative)
I was going to the FTP site to look at the sources [redhat.com], but apparently they have moved.
Current sources for Red Hat Enterprise Linux 7 have been moved to the following location:
https://git.centos.org/project... [centos.org]
That's a bit cool actually.
... and with systemd. (Score:3, Interesting)
I bet they'll have to support RHEL6 for many and many years as a lot of companies won't upgrade to RHEL7.
http://boycottsystemd.org/ [boycottsystemd.org]
Re: (Score:2, Insightful)
But a lot of them will. It turns out that systemd is actually kind of good.
Highly subjective... (Score:2)
For a large chunk of users, no diffence.
For people who dig deep in, huge difference with very polarizing attributes. Some people like the goodies it brings, but it changes a whole lot of stuff in the process without much of a care for appeasing those that appreciate how things worked.
Basically, systemd is building something different. Some say better, some say worse. I happen to be in the latter camp even after using it at significant length.
Re: (Score:2)
For a large chunk of users, no diffence.
Thing is, though, Red Hat Enterprise Linux isn't run by users, it's run by sysadmins, for whom it makes a huge difference. And not for the better. .INI files and three layers of abstraction isn't particularly sysadmin friendly..
A system with hundreds of Windows
Re:... and with systemd. (Score:5, Informative)
I bet they'll have to support RHEL6 for many and many years as a lot of companies won't upgrade to RHEL7.
http://boycottsystemd.org/ [boycottsystemd.org]
Systemd is the new future toolbox for maintaining and running Linux: All major enterprise Linux distros are using or are about to use systemd. Sure, a few companies will delay their transition to systemd if they have a lot of custom stuff they need to change, but systemd just have so many new awesome features that most will embrace it with joy; systemd simply means faster and better maintenance, and being able to pack more services in each hardware unit.
Those who dislike systemd are just a tiny but vocal minority; they have also spend the last couple of years smearing named open source developers like Lennart Poettering and trash-talking systemd, instead of developing an alternative to systemd. As a group they accept how the most extreme voices against systemd are unopposed, meaning that all the swivel eyed loonies with their paranoid ranting have become spokespersons for them, resulting in that nobody wants to work with them. So not only are the systemd detractors a small group, but they alienate most of the potential developers they could have had.
The end result is that almost nobody works on alternatives to systemd. Critical software like "ConsoleKit" is bit-rotting, nobody tries to help upstream projects supporting anything else but logind, despite that eg. Gnome developers have warned about this for years.
Instead of helping KDE and Gnome supporting non-systemd systems, the systemd detractors just rant on how NSA/The Greys/Poettering are controlling Gnome and KDE, and that everybody should boycot them and use CDE instead.
Like it or not, systemd will be in any Linux distro of importance in the future. Sysvinit (and X) are on life support and will be killed off at first opportunity people get. Even OpenBSD are starting to clone certain parts of systemd, and there is no doubt that all BSD's will have their init-system upgraded to a modern version inspired/cloned from systemd in the upcoming years. It is simply that good.
Re: (Score:3)
I bet they'll have to support RHEL6 for many and many years as a lot of companies won't upgrade to RHEL7.
http://boycottsystemd.org/ [boycottsystemd.org]
Systemd is the new future toolbox for maintaining and running Linux: All major enterprise Linux distros are using or are about to use systemd. Sure, a few companies will delay their transition to systemd if they have a lot of custom stuff they need to change, but systemd just have so many new awesome features that most will embrace it with joy; systemd simply means faster and better maintenance, and being able to pack more services in each hardware unit.
Those who dislike systemd are just a tiny but vocal minority; they have also spend the last couple of years smearing named open source developers like Lennart Poettering and trash-talking systemd, instead of developing an alternative to systemd. As a group they accept how the most extreme voices against systemd are unopposed, meaning that all the swivel eyed loonies with their paranoid ranting have become spokespersons for them, resulting in that nobody wants to work with them. So not only are the systemd detractors a small group, but they alienate most of the potential developers they could have had.
The end result is that almost nobody works on alternatives to systemd. Critical software like "ConsoleKit" is bit-rotting, nobody tries to help upstream projects supporting anything else but logind, despite that eg. Gnome developers have warned about this for years.
Instead of helping KDE and Gnome supporting non-systemd systems, the systemd detractors just rant on how NSA/The Greys/Poettering are controlling Gnome and KDE, and that everybody should boycot them and use CDE instead.
Like it or not, systemd will be in any Linux distro of importance in the future. Sysvinit (and X) are on life support and will be killed off at first opportunity people get. Even OpenBSD are starting to clone certain parts of systemd, and there is no doubt that all BSD's will have their init-system upgraded to a modern version inspired/cloned from systemd in the upcoming years. It is simply that good.
Systemd is not "that good." As an opponent myself, I am an admin, not a developer. And as an admin, I fail to see what was wrong with the BSD Init system. It works. It's simple. It's good.
And as far as Mr. Poettering goes, I much prefer to trash talk his work. Attacking him, no matter what you may think of him, doesn't get the point across.
Re: (Score:2)
Systemd is not "that good." As an opponent myself, I am an admin, not a developer. And as an admin, I fail to see what was wrong with the BSD Init system. It works. It's simple. It's good.
And as far as Mr. Poettering goes, I much prefer to trash talk his work. Attacking him, no matter what you may think of him, doesn't get the point across.
There are many not so nice things about old style init scripts. Come on, executable config files where code and declarative statements are mixed? Who thought that was a good idea? Many people also find that debugging such scripts are hard etc. But the main thing isn't so much that old style script init systems are inherently bad, but that they don't work well with modern day computing.
The days of running a handful of services on a single server, directly on the metal, while hand crafting scripts, are basica
Re: (Score:3)
As an example: systemd removes the ability to run a grep on the plain text log file. And replaces it with something else. Metro also takes away the ability to do some stuff and replaces it with something that the marketing department claims to be just as capable or even more. And perhaps it's all fine when you are within the boundaries that the marketing department envisions. But Linux was never about keeping yourself within some borders. We want tweak and poke, replace X with Y and customize to no end. You can't beat flexibility of a shell script combined with textutils/binutils/fileutils.
No it doesn't. If you need text files logs for some legacy reason, just direct all logging output from journald to syslogd. It enhances the logging info while keeping standard syslog text logs. It is a simple one liner in the systemd config file to enable that behavior.
Furthermore, the journal viewer, "journalctl" can easily be combined with any standard unix tool like grep; that way you can have all the advantages of having an indexed logfile while using standard GNU text utilities.
In fact, the standard pa
Re: (Score:2)
Attacking Lennart Poettering is a bit like pouring water on a duck. I think the ability to consider the opinions and experience of others is completely missing. Input is only accepted if it's praise or furthering the direction he's already staked out (and even then he's thrown ego tantrums).
The point that gets across to Red Hat is our money. Money that
Re: (Score:2)
Around 500 different developers have contributed to the systemd project. It just shows that the project have excellent leadership with Lennart Poettering since he can attract so many developers across so many differen
Re: (Score:3)
Define 'superior.' They can't do my job. I'd prefer not to do their job.
Re: (Score:2)
instead of developing an alternative to systemd
The stance amongst those opposed to systemd was that what wasn't broken didn't need fixing. Some people disagree and think it needs to be fixed and systemd is it. People objecting to systemd largely don't have to create an alternative, they are content with the linux distributions as they were.
Instead of helping KDE and Gnome supporting non-systemd systems,
KDE at least I thought purported to continue supporting non-systemd systems already. Gnome 3 developers very linked in with the systemd developers and as a whole they prioritize the purity of their vision over any
Re:... and with systemd. (Score:4, Funny)
instead of developing an alternative to systemd
The stance amongst those opposed to systemd was that what wasn't broken didn't need fixing. Some people disagree and think it needs to be fixed and systemd is it. People objecting to systemd largely don't have to create an alternative, they are content with the linux distributions as they were.
Of course you need to develop alternatives to systemd in order to decay into non-functionality. AFAIK, running a multi-user non-systemd OS these days, depends on a old bit-rotting version of ConsoleKit. There are many more features that will break and bit rot in the future for lack of maintenance; Red Hat, Suse, Debian, Ubuntu, etc. won't put resources into developing for non-systemd systems.
Instead of helping KDE and Gnome supporting non-systemd systems,
KDE at least I thought purported to continue supporting non-systemd systems already. Gnome 3 developers very linked in with the systemd developers and as a whole they prioritize the purity of their vision over any criticisms. Perhaps appropriately electing to focus on bringing their vision to life to serve those who would follow the vision and letting the rest go on to KDE or xfce or MATE or whatever. I personally don't care about gnome shell as it doesn't serve my needs anymore either, but I can accept that they are caring after their user experience. I also wouldn't mind systemd so much except for the fact it is becoming unavoidable whilst retaining compatilibity with ongoing projects in linux.
KDE will support running on non-systemd distros, but it will be with reduced functionality. Not because the KDE developers are evil, but because they are offered no alternatives to systemd. Take fx. the new KDE login manager; KDE simply couldn't afford spending developers so that it also supported the rather broken and bit-rotting ConsoleKit. And nobody else has stepped up and offered help.
Sure you can use another login manager, but it is just an example on how bit by bit, non-systemd distro will have to step up and start doing their own development in order to have functional software. Networking and ntp DE modules, and log viewers, etc. will all be systemd based, with no common alternative in sight.
Gnome developers have warned for years about current problems; systemd offers really good and compelling features that can enhance their DE, while non-systemd distros doesn't. And because non-systemd distros seems to be sticking their head in ground and denying the reality that status quo can't be maintained, they don't offer any help at all. In fact, snarky remarks and vague conspiracy insults are all they are getting.
Re: (Score:2)
My "login manager" is init calling getty which calls login which gets me to bash. If I want pretty pictures, from there I just run startx, which gets me into KDE or whatever else is configured. AFAICT, KDE doesn't care how it gets started. My way seems the most straightforward to me. How is it sticking my head in the ground?
Re: (Score:2)
I bet they'll have to support RHEL6 for many and many years
Red Hat is committed to supporting RHEL6 until Nov. 2020, and Nov. 2023 with extended support, nearly 9 more years,. What, exactly, is your point?
Long term support is one of the appeals of Red Hat..... they get paid for it.
Some nice looking features/updates (Score:5, Funny)
I have always admired RH for it's feature set and pursuit of enterprise-related features. /etc/network/interfaces /etc/sysconfig/network/networking/where/are/the/damn/config/files
I do however have one gripe: All the config files are in the wrong place!
This isn't a real complaint, more akin to a whine. I have been using Debian for too many years on far too many servers; my muscle memory demands that the config files that I need to edit be located in the same place across distros.
Does anybody know why there is such a difference in file locations?
vs
Re: (Score:2)
Re: (Score:3)
Re: (Score:2)
It's much easier to handle large scale automation when you're using separate files.
Re: (Score:2)
It's much easier to handle large scale automation when you're using separate files.
And much harder to admin heterogenous networks where different services are normally run on each system, but you want them installed in case you need to take over a service during maintenance or otherwise.
Re: (Score:2)
That's what RH Clustering Services are for...
Re: (Score:2)
That's what RH Clustering Services are for...
I said "heterogenous", not "homogenous".
Not HA for failover when something goes wrong, but manual changes to services on different boxes with different primary functions.
Re: (Score:2)
Since I have have started seriously working on BSD systems I have enjoyed the simplicity/straight-forwardness of it's configuration setup. The only thing that keeps me from switching to OpenBSD for all my servers: apt-get dist-upgrade
I have only been bitten in the ass once by this (15'ish years ago), and it makes keeping the system updated so easy.
Re: (Score:2)
All of them are fucked up when it comes to network interfaces - linux, BSD, Windows, OSX, you name it. Why should a network interface device be some kind of black magic rather than a node in /dev like every single other device? I never understood the point of this.
At least in BSD it's pretty straightforward to figure out what the fucking NAME of the goddam ethernet device is.
Re: (Score:2)
If you had gone FreeBSD rather than OpenBSD, you would have freebsd-update and pkg. It's not QUITE as straightforward as "apt-get dist-upgrade", but pretty damn close.
To update base OS, "freebsd-update fetch && freebsd-update install". With the right syntax, you can even upgrade your base OS across minor and major releases. Don't worry, that only happens if you deliberately call for it.
To update userland p
Re: (Score:2)
Except, when it comes to Enterprise, Red Hat is the standard.
Re:Some nice looking features/updates (Score:4, Insightful)
I have always admired RH for it's feature set and pursuit of enterprise-related features. /etc/network/interfaces /etc/sysconfig/network/networking/where/are/the/damn/config/files
I do however have one gripe: All the config files are in the wrong place!
This isn't a real complaint, more akin to a whine. I have been using Debian for too many years on far too many servers; my muscle memory demands that the config files that I need to edit be located in the same place across distros.
Does anybody know why there is such a difference in file locations?
vs
I think the differences are just the normal fragmentation between different distros, with everyone having their own idea of the "correct" place to put the config files. The systemd project is trying to establish a cross distro standard for some of the important config files, making it easier for upstream projects to know where e.g. /etc/os-release is (on non-systemd distros it can be "hidden" almost everywhere).
Systemd is the most important new feature of RHEL 7, since the core of the OS now have been making a huge leap forward in security and reliability regarding processes and deamons. It is now a piece of cake to utilize advanced kernel features like "capabilities" http://man7.org/linux/man-page... [man7.org] and "cgroup" https://www.kernel.org/doc/Doc... [kernel.org]
All major distros are about to change to "systemd"; Red Hat, Suse, Ubuntu, Debian. Their derivatives like CentOS, Sci-Linux, Fedora etc. are also changing to systemd, so in a few years, systemd will simply be the new standard toolbox to maintain and run Linux distros, and part of the new future Linux development stack; systemd, Wayland, cgroups and kdbus.
So every Linux System Administrator who have been to procrastinating regarding learning systemd, better start reading up on the subject. A good place to start is : http://www.freedesktop.org/wik... [freedesktop.org]
Re: (Score:2)
Re: (Score:2)
How much did Lennart pay you? 8)
Hey, lets look at your sig:
--
When you cant win, ad hominem.
Had you forgotten all about your own sig?
This is exactly why systemd detractors have lost every technical argument and lost out on all major Linux distros; you are wasting time on negative campaigning against systemd instead of getting off your asses and start coding alternatives.
You have lost wholesale to systemd because you wasted time smearing open source developers like Poettering behind your anonymous handles instead of working.
Re: (Score:3)
As one who has taken strong exception to both the form and substance of the systemd steamroller, I readily volunteer that Peter has a point. If you don't think any alternative to some form of init scripts is necessary, just say that. Peter and other proponents will make a strong well-supported point-by-point case for the alternative-IS-required viewpoint.
Peter - hi - I still dig BSD with init scripts, particularly FreeBSD, but I'm not manning the barricades against linux with systemd. I do run arch with sys
registryd (Score:2)
Will registryd be part of systemd soon? I can't wait having some centralized binary configuration only readable by systemd utilities.
Re: (Score:2)
Well, journald is sort of the mirror of the hypothetical registryd, and journald is quite well established and doing fine at this point. The comparison is far from perfect; for example you can still run syslog in parallel with journald, but on the mirror side you pretty much would need to pick one-and-only source of config data.
A case can certainly be made for a registryd. It is appealing to have all your config info nicely hierarchically arranged in a single tree, rather than hunting for scattered files am
Re: (Score:2)
Re: (Score:2)
Just curious, how do you figure that?
Date of project/company founding? Date of first public announcement? Date of first public 0.x release? Date of first 1.x release?
As far as I can tell, they both had various milestones before the other and their initial development overlapped somewhat - eg Debian started first and (probably) got prereleases out earlier, but Redhat got to 1.x quicker. But I can't see any way to claim Redhat was around long before Debian.
Very excited announcement (Score:2)
Their use of bold and italics in the announcement makes me feel like I'm reading an old John C Dvorak pcmag column.
Good and bad... (Score:2)
XFS and PCP are good things to include.
systemd and OpenLMI I find worrisome. systemd being the one impossible to ignore so OpenLMI at least gets something of a pass for the ability to totally ignore it.
systemd has been hashed out time and time again, but OpenLMI is something rarely discussed. DMTF has championed CIM for eons, and the architecture shows in that it clearly defines things as you would see a buzzword compliant enterprise define an architecture amidst the dotcom boom of the late 90s (complete
Re: (Score:2)
Re:Good and bad... (Score:5, Insightful)
Re: (Score:2)
funny I can do a parallel start up with init script if I really wanted to, don't need fancy bloated startup/system/session manager
Re: (Score:2)
Re: (Score:2)
Systemd is not nice because it does all that stuff. Init is not supposed to do all that stuff, because it makes it bulky, gives additional avenues of attack, and is just all around a pain. What would have been better would have been to make systemd a modular system so that if you want it to handle all that, it can, but if you dont, it just does the parallel start up.
This just wrong; systemd dramatically increases security by eg. making use of "Kernel Capabilities", sand-boxing deamons so that privilege escalation is impossible, or forking etc. It also makes it a breeze to use cgroup, making it easy to control system resources to keep the system up and stable in case of DoS'ing, it has rate limiting, and a total supervising chain of all processes and deamons, including itself, etc. etc.
It is also very modular. For some reason systemd-detractors keep on saying that syste
Re: (Score:3)
Like SELinux, I'm afraid that it's complex, incomprehensible and unusable to the average developer, and is immediately thrown away or never even usable to most developers. ...
You are absolutely right, that advanced kernel features like "capabilities" and "cgroup" are hard to use for developers. That is the exact reason for why "systemd" was made as a "Linux plumbing layer" that makes advanced and powerful new kernel features easy to use for everybody.
With systemd, it is a one liner in a text config file to turn on really powerful service sand-boxing features like preventing the service, even if exploited, to gain new privileges.
Or use the "ReadOnlySystem=" to make "/boot" and "/
Re: (Score:2)
As usual, an excellent exposition of stuff a lot of us still aren't familiar with. Do you have a systemd FAQ/exposition site? Could we get you to open one?
Re: (Score:3)
init IS supposed to know whether services are running and restart them if they fail or exit. It used to do that way back when; you would edit /etc/inittab to specify what runs at which runlevel. Unfortunately /etc/inittab was sufficiently crap that all sorts of things were pushed into shell scripts instead, which lost the the ability to recover from failed services. Then you could install Monit and edit those shell scripts to get that ability back, but every time you upgrade you have to check whether your e
Re: (Score:2)
init IS supposed to know whether services are running and restart them if they fail or exit. It used to do that way back when; you would edit /etc/inittab to specify what runs at which runlevel. Unfortunately /etc/inittab was sufficiently crap that all sorts of things were pushed into shell scripts instead, which lost the the ability to recover from failed services.
One reason why stuff got moved out of inittab was precisely to avoid apps being restarted if they died. The admins needed to find out why a process was dead.
Also the ability to stop and start processes without modifying inittab and doing "telinit q".
And now we're back to modifying files again, in a monolithic system with more arms than an octopus, sucking everything in. No, thanks. The Unix toolbox approach is that apps should be small, do as few things as possible, and do them well. Give the admins mor
Re: (Score:2)
You can restart a process and still look on why it died by looking at the log or the core. In fact, there is company where that's exactly the process, if something fail at supervision, the guy in charge during the night just restart the process, and the team look in the morning to see what happened.
Thus speaks someone who has never seen a crash/restart loop. Large apps like databases can take several minutes to start up and recover, and then immediately die again. The next morning you have several terabytes of core dumps, and a corrupt database, and have to restore the latest backup.
Also, a core dump can be of little value if external data that triggered the crash has changed because you restarted the process. You need a full snapshot of the entire system, i.e. a virtual machine that dumps/snapsho
Re: (Score:3)
Thus speaks someone who has never seen a crash/restart loop. Large apps like databases can take several minutes to start up and recover, and then immediately die again. The next morning you have several terabytes of core dumps, and a corrupt database, and have to restore the latest backup.
That situation is easily handled by systemd since it has total knowledge and supervision of all running processes and services, and has extensive capabilities for various ways of restarting crashed services. This included ways to limit restarts, so as if a services crashes more than eg. two times within eg. 10 minutes it wont restart that service again (or reboot the entire system, or many other actions). This is controlled by simple keywords added to the config files like "StartLimitInterval=, StartLimitBu
Re: (Score:2)
Microsoft de-emphasized CIM? DSC (Desired State Configuration) is entirely based on CIM. It works by creating CIM objects with Powershell. It will create a corresponding .mof file from the provider written in Powershell. Once you have the mof and the provider, the provider can be called from Powershell. DSC will manage the state of the provider based on the parameters passed by the configuration script.
MIcrosofties where I work are all excited about DSC. I think they think is Chef/Puppet for Windows. I don'
Guess it depends on situation... (Score:2)
I will say I didn't mess with DSC, but a lot of the .NET calls no longer rely upon WMI working. WMI like sfcbd and Pegasus will completely cock up if a provider so much as looks at it funny. Previously, only utilities like ipconfig and stuff would keep working and any thing making WMI calls was just SOL. I noticed in one of the various scenarios where WMI had gone belly up that the calls I had moved to in .NET didn't mind at all for a lot of the stuff. Someone at MS suggested that WMI/CIM was being step
Re: (Score:2)
Very, very interesting. I don't work in the Windows world, but I will pass along this information about WMI on Windows to the people testing DSC. If WMI isn't right all the time, then DSC is not going to work.
What .NET calls used to require WMI?
500 TB? (Score:3)
XFS on 64 bit linux can go to 8 EB for files and volumes, a tad bigger than 500TB. Did Red Hat cripple it (for a while they even charged extra for XFS!)
Re: (Score:2)
Re: (Score:2)
funny, a couple of their competitors have no such limitations. That is like Cisco charging you for switch port use
Re: (Score:2)
Yea because having something with zero support is something people want on there enterprise grade servers. Do not get me wrong used ZFS on top of centos to scratch and itch here and there that does not mean I'm spooling it up in production for giggles.
Re: (Score:2)
oh really, for ZFSOnLInux have they made a notification system so spare pools can get used in event of failure? or how about the occasional runaway memory issues?
no support for FreeBSD systems in the Enterprise, other than hiring consultants
Comment removed (Score:5, Funny)
Is this still a good OS for desktop? (Score:2)
I really don't like the fast release cycle of many Linux distros, so I used to stick with CentOS or RHEL on my desktops as well. What about RHEL 7? By the way, what filesystem should be used on a laptop?
Re: (Score:2)
I really don't like the fast release cycle of many Linux distros, so I used to stick with CentOS or RHEL on my desktops as well.
It's Gnome 3.8, which is a good desktop in my opinion. But you take some time should try it out yourself.
What about RHEL 7? By the way, what filesystem should be used on a laptop?
Any file system should be fine. Go with the default if you're not sure you want something else.
Re: (Score:3, Interesting)
Use ext4 for a laptop over the default, XFS. XFS is prone to data corruption when improperly shut down.
Re: (Score:2)
That's true, although I would suggest that you also don't improperly shut down your laptop. :-)
Re: (Score:2)
Being a laptop leaves it vulnerable to dieing batteries in my experience.
Re: (Score:2)
Really? Ugh. I thought most modern file systems were consciously designed to avoid that sort of problem.
Re: (Score:2)
I'd hardly consider XFS modern. SGI introduced it on IRIX 5 back in the mid 90's.
Re: (Score:2)
Use ext4 for a laptop over the default, XFS. XFS is prone to data corruption when improperly shut down.
No, it isn't. It is prone to data erasure, which is different. XFS log playback will, by default, zero any data that cannot be played back in full, because it may be data that should not be exposed. It's a feature that makes XFS largely immune to some power-yank attacks that other systems are vulnerable to.
You want to use barriers, and if possible, keep at least your log areas on battery backed storage.
Reverting to init (Score:3, Insightful)
Re: (Score:2)
What do you mean by init? There's still a binary called init if that's what you want. And RHEL 6 used Upstart, but I don't know if that's more init than Systemd. So yes in theory you can since you have access to the source code and can modify it any way you want. This will be cumbersome in practice.
Re:People still use Red Hat? (Score:5, Insightful)
Stable is the word you are looking for.
Re:People still use Red Hat? (Score:5, Informative)
Red Hat aims not only for stability in the sense of "not crashing", but in the sense of "doesn't change a lot within a major release", especially in the core libraries and language runtimes. Companies often like that kind of stability, because they have miscellaneous in-house or commercial software running on top of the base system, which has a habit of breaking when anything is upgraded under it. So within a major version, Red Hat carefully rolls out only non-ABI-breaking changes, e.g. by backporting bugfixes to previous major versions of libraries.
Re: (Score:2)
Hah, that could be. My own experience with "stability" in the sense I'm explaining above is actually almost all with Debian stable, rather than Red Hat. And Debian is actually pretty good at keeping breaking changes out of point releases. It sounds like Red Hat is not as disciplined on that?
Re: (Score:2)
Debian policy filters down to Ubuntu. Even on Ubuntu's 18 month releases, on their 5 year LTS releases, on anything labeled as release, the policy stands: there shall be no changes which make any action which produced a working result prior now produce a non-working result, unless such a change is absolutely unavoidable when removing a security vulnerability.
Even some predictable bugs may not get updates, for example, a bug in Perl 5.14 which produces consistent incorrect results would likely not get a
Re: (Score:2)
The kernel package in particular is one of the things that Red Hat changes a lot, but usually only between minor releases. A small addition such as KVM was introduced in 5.2 for example.
Comment removed (Score:5, Informative)
Re:People still use Red Hat? (Score:5, Informative)
BULL SHIT.
Redhat routinely changes shit horrendously within release. They removed the crmsh configuration and replaced it with a completely different configuration tool in RHEL6, breaking a bunch of shit. They do this continuously: upgrade software, change some shit around, deprecate old tools for new tools, and tell you it's improved.
crmsh was in tech preview. Red Hat never committed to supporting that. Pay attention to the support status of what you are deploying.
Graded on a curve... (Score:3)
RHEL is about as change averse as a *Linux* company gets. They have the unfortunate balance to play between fulfilling the mission of a solid predictable experience and not appearing to lag so much compared to the base people are well aware of. At times, I will say RHEL is in denial about ABI-breaking changes (e.g. swearing up and down that a kernel driver should compile and work against their rather dramatically backported base just as if it was really the kernel version advertised in uname output).
If yo
Re: People still use Red Hat? (Score:3, Informative)
Pacemaker (which provides crmsh) is a tech preview and unsupported in rhel. But don't let that stop you from blaming them for something that you know, is unsupported...
Comment removed (Score:4, Interesting)
Comment removed (Score:4, Insightful)
Re: (Score:3, Insightful)
You think a hobby distribution that didn't even have package signing until 6 months ago is a competitor to RedHat?
Comment removed (Score:4)
Re: (Score:3, Insightful)
rhel7 comes with glibc 2.17.
Not a problem... (Score:5, Informative)
There are scenarios in which a meticulously backported base with few to no functional changes is valuable. That is the entire point of RHEL, to be able to have support lifecycle that more closely matches Microsoft or Unix offerings.
If you need more rapidly updating content, then a distribution like Ubuntu or Arch or Fedora is a better fit. Ubuntu LTS might be a decent approach for some. The good thing about this ecosystem is you can select an experience based on your needs.
Re: (Score:3)
Yep, but the problem is that for the next ten years it will _still_ come with glibc 2.17. Some people actually new new apps too.
This is where containers is a good idea. Use RHEL as a stable base system and run something like Fedora in a container for the few apps that need it.
Re:So CentOS will be out in 2016? (Score:4, Informative)
You are missing the whole point - the idea is that throughout the 7.x release the glibc (/ other software) version will not change, so in 10 years time your *current* software investment will still work, rather than being force to upgrade. Stability means not changing what is deployed *now* in the future. For many deployments this is crucial. If you do not need this form of long-term software stack stability, then, yes, RedHat is not for you - however there is no point criticising RedHat for a policy that is deliberately enforced for a good reason.
Re: (Score:3)
I agree that long-term ABI stability is important. But on AIX, they've managed to maintain backward compatibility for years. Almost everything built on way old versions of AIX runs on the latest version. If they have to provide multiple versions of some libraries to handle broken old behaviors, they do that too. Maybe I'm missing something here - like maybe AIX includes a much smaller set of libraries than RedHat. But for the purposes of our apps, AIX has been a really nice, stable platform. Nothing f
Re: (Score:3)
Re: (Score:2)
Re: (Score:2)
It is a balancing act. I agree with you completely....if we are talking about my desktop. On my desktop, or often, even my development box, I want something new. I want bleeding edge.
However, when the customer says they need a deployment of product ABC that depends on component XYZ that we have only ever deployed on RHEL5..... right now, in production, with a customer waiting, is NOT the time to try it on RHEL7 or even RHEL6. Now is the time to install RHEL5, give the customer his system.... then go back to
Re: (Score:2)
Seriously....makes me want to scream (or did, I left that place), and you really think having the latest wiz-bang tools available is anything but the least of my worries? Not in production it isn't.
Yup, having been in a production environment with 1000's of machines, you get very 'risk averse' - your job is 24/7/365 uptime, making sure nothing breaks, *NOT* having the latest whiz-bang tools to play with.
Re: (Score:2)
Debian is not always that fast. Just take Gnome for example, sid is still on 3.8 which is getting kind of old by now. And not to mention that they are still in the process of switching to systemd. Debian is great, but the stable release is usually what you want and then you're back in RHEL territory.
Re: (Score:3)
Scientific Linux will probably still beat CentOS to the punch. They did with 6.
Initially, yes. CentOS narrowed and then beat SL with each point release
Now that CentOS is part of RedHat, I would expect that CentOS should be able to keep pace.
Re: (Score:2)
Maybe I'm missing something but what good is the libvirt driver if you don't have anything to connect it to?
Re: (Score:2)
I guess I didn't explain that very well.
Libvirt provides its own container launcher under the name "lxc". As I understand it this software is developped and maintained with libvirt. This is different software from the standalone project known as "LXC" as linked in the article.
Re: (Score:2)
Re: (Score:2)
Because RHEL includes the source code, which can be kind of an important feature. But apart from that Solaris should be fine. They lost a lost of talent during the Oracle takeover, and I have a number of ZFS support incidents due to that; but to be honest things have been much better starting about a year ago.
Re: (Score:3)
It is 3.10. But keep in mind that this is only where Red Hat essentially forked their version. Each minor release adds major changes to the kernel, including both hardware support and new features.
Re: (Score:2)
That's an easy one -
[armanox@rhel7test ~]$ uname -a
Linux rhel7test 3.10.0-123.el7.x86_64 #1 SMP Mon May 5 11:16:57 EDT 2014 x86_64 x86_64 x86_64 GNU/Linux
Re: (Score:2)
RHEL 6.5 supports at least one 40Gbps ethernet driver (Mellanox). I have no idea whether it can achieve 40Gbps in practice, but it can certainly connect to a 40Gbps switch.
Re: (Score:2)
It can actually sustain 40 gb of throughput. All the tools report link accurately as well. I confess to have no idea why RHEL would call out 40 gb as 'new' since it has been around already...
Re: (Score:2)
Just use straight Winbind with an RID backend to consistently generate UID/GID from SIDs. You can even automate the join to the domain in the kickstart. SSSD just caused more problems than it solved....