Red Hat Enterprise Linux 7 Released

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.

Comments

Red Hot Linux

[Anonymous Coward]

Careful, it's hot!

So CentOS will be out in 2016?

[Anonymous Coward]

That would still be faster. But seriously, Red Hat is slow and CentOS lags far behind even that. glibc 2.12 is just too old to run much of what I need to run on Linux.

Re:So CentOS will be out in 2016?

[Anonymous Coward]

rhel7 comes with glibc 2.17.

Re:So CentOS will be out in 2016?

[Anonymous Coward]

Debian is the GNU for you.

Re:So CentOS will be out in 2016?

[Anonymous Coward]

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.

Re:So CentOS will be out in 2016?

[kthreadd]

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:So CentOS will be out in 2016?

[kthreadd]

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?

[Anonymous Coward]

We have been waiting to see if 7 will give us a speed increase with postgresql - the older kernels are supposed to be slower with io. Still, we haven't changed because as others have said, it's nice and stable and we need that more than speed.

Re:So CentOS will be out in 2016?

[Anonymous Coward]

Scientific Linux will probably still beat CentOS to the punch. They did with 6.

Re: So CentOS will be out in 2016?

[Anonymous Coward]

As we move towards a stable core os and containerized applications, some long time users are going to get outdated quickly on how linux is being used in the real world.

Re:So CentOS will be out in 2016?

[TheCarp]

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 development and try something newer.

Add in that XYZ may even be a third party component that is only supported on RHEL5, and going to that adds even more risk, because now we are not only risking that it wont work, but that it might cause an issue down the line where I, or one of my co-workers, will be left in the lurch by the support we pay for....and they will be right to do it!

THAT is why RHEL exists and why you think its old. It is old. You are right, your mistake is only in thinking that what matters to you matters to everyone else or what matters to others should matter to you.It isn't because anyone likes running and supporting systems that old, its because the ecosystem is so large and we have other priorities than staying on top of the bleeding edge.

Yes if I was responsible for even 100 systems, maybe keeping up to date would be a priority. Try an environment with over a few thousand with multiple customers and multiple offerings, with support organizations that need to be kept up to speed.

Hell I have had to fight people about patching. "We need RHEL5.4, and we need it patched to the latest" "SO you want 5.9?" "No we want 5.4" "so don't run updates" "no, it has to be patched to the latest!"

Or even "why are we deploying 5.5?" "because we run updates after install and after updates it becomes 5.5" "but we only ever approved 5.4" "So you don't want us to run updates" "no we have to be patched to the latest!"

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.

Re:So CentOS will be out in 2016?

[blane.bramble]

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:So CentOS will be out in 2016?

[Rob Y.]

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 flashy, but no surprises.

Re:So CentOS will be out in 2016?

[thule]

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:So CentOS will be out in 2016?

[Anonymous Coward]

RHEL8 will upgrade. Upgrade to RHEL8, RHEL9, .... when needed.

Re:So CentOS will be out in 2016?

[Anonymous Coward]

# cat /etc/redhat-release | sed 's/5.5/5.4/' > rh.tmp; mv rh.tmp /etc/redhat-release

You're now patched up to the latest on RHEL 5.4. ;)

Re:So CentOS will be out in 2016?

[CaptnZilog]

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:So CentOS will be out in 2016?

[TheCarp]

Actually I believe at the time we even talked about locking down the version of the rpm that updated redhat-release as a serious solution to the problem. Sometimes it just isn't clear if the answer is to laugh or to cry.

Re:So CentOS will be out in 2016?

[TheCarp]

oh and one more thing.... no need to pester the cat

sed -i 's/5.5/5.4/' /etc/redhat-release

Re:So CentOS will be out in 2016?

[Wdomburg]

s/the problem/the point/

Re:So CentOS will be out in 2016?

[Wdomburg]

Red Hat does the same thing. They provide ABI compatibility for major components (e.g. libc) two major releases back. For example, an application released against RHEL5 (first released in 2007) will continue to be supported until RHEL7 falls out of support in 2027.

Likewise, AIX does the same as Red Hat. Any given release of AIX is supported well past the release date of its successor. So even though AIX 7 became available in 2010, AIX 6 is still supported and AIX 5.3 was supported until 2012.

Ultimately ABI compatibility is a secondary concern for large scale and long running deployments. The question isn't whether an application will still work after an upgrade; it's why you should upgrade a working system in the first place.

Re:People still use Red Hat?

[armanox]

Stable is the word you are looking for.

Re:People still use Red Hat?

[Anonymous Coward]

Arch Linux does not provide the proper mission critical robustness and quality assurance. There's a reason why RHEL does not target the bleeding edge.

Re:People still use Red Hat?

[Anonymous Coward]

Stable, well-tested, and guaranteed ABI compatibility within major releases.

Re:People still use Red Hat?

[Anonymous Coward]

Red Hat stability is overrated. I have yet to see an Arch box crash. Just keep up to date on what's going on and read changelogs before installing updates, _which you should already do_ if you want stability.

Not a problem...

[Junta]

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.

Source RPMs

[kthreadd]

I was going to the FTP site to look at the sources, 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...

That's a bit cool actually.

Re:Source RPMs

[Anonymous Coward]

It's actually a flipping nightmare. *EVERYTHING* based on SRPM management and building for testing or modifying components is now broken, effectively unannounced. The new git repository effectly has only "master" branches, and you have deduce and guess or cast a ouija board to figure out what the SRPM package name is from the published .spec file. And there are no GPG signatures associated with the new git repo, and no tags.

So, if you're anybody but CentOS, who have verifiable internal access to Red Hat's internal repositories to run checks against, you are *shit-out-of-luck* trying to do a verified RHEL rebuild. There is no structure apparent for segregating RHEL clean vendor versions and specific package versions, you just have to try and guess from .spac files, and *pray* that no changes in the source code were made to the git repo after the .spec file was last altered.]

I'd like to go over to the telecommuting desks the CentOS guys are using and slap them upside with a cluebat, chanting "learn to use tags! learn to spell GPG! learn to separate your code from upstream". The CentOS crew has *never* been good about making clear which components are built from clean RHEL SRPM's, and which are built from their modified SRPM's, they've always casually kept them in the same directory of published source, and it is *nasty* to sort out the modifications.

The switch to git based publication is helpful to CentOS friends and community members, since in theory they'll get a better look at the change logs for CentOS modifications. But it has *none*, *zip*, *zero*, *nada* of the upsream RHEL git history, it's based on a pure "grab a copy of the files from upstream, import them into git". That cuts off git history, and is an undocumented process, so no one outside knows how the CentOS folks actually did it, or whether it was prone to git history errors. (Ideally, it would have been done form RHEL SRPM's, not from a git export, to avoid version skew.)

This is causing screaming among the folks who do RHEL rebuilds. It's understandable that RHEL need not make life easy for us, and the freeware and open source nature of RHEL have sometimes been abused and proprietized. (I'm staring at you and your "UnPatchable Linux", Oracle!!!) But this this approach was designed by a committee led by a pointy-haired boss.

And do not get me *started* on that user interface at https://git.centos.org/. It violates every single one of the design guidelines of Eric Raymond's guidelines on open source interface, "The Luxury of Ignorance", parts I and II.

... and with systemd.

[psergiu]

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/

Re:... and with systemd.

[Anonymous Coward]

But a lot of them will. It turns out that systemd is actually kind of good.

Re:... and with systemd.

[thaylin]

I see little good about systemd.

Re:... and with systemd.

[Peter H.S.]

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/

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:... and with systemd.

[armanox]

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/

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:... and with systemd.

[Junta]

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 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.

Re:... and with systemd.

[Peter H.S.]

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 basically over.

These days it is all about packing maximum of services on each hardware unit, with virtualization, OS containers, services on demand, plugging services into LSM's (Linux Security Modules). It is all about massive and fast deployment, cloud computing, and getting the most from the hardware you got, for the least amount of effort. Automatic supervising chains of all processes and services are simply a must, rate limiting and service hardening with minimal effort are required.

Old style script init systems simply aren't a good solution for present and future systems. Even BSD will eventually upgrade their init systems to something modern like systemd. OpenBSD already have a GSoC project for cloning part of it.

Re:... and with systemd.

[Tailhook]

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.

Re:... and with systemd.

[Peter H.S.]

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:... and with systemd.

[Anonymous Coward]

I am an admin, not a developer

Then you should respect the opinion of those that are objectively superior to you. System admins are little more than peasants.

Re:... and with systemd.

[armanox]

Define 'superior.' They can't do my job. I'd prefer not to do their job.

Re:... and with systemd.

[arth1]

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.

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 can go elsewhere.

Re:... and with systemd.

[Anonymous Coward]

They are taking our jobs. Developers do not have the skills we sysadmins have developed trough many years of experince, but they do have skills we sysadmins needs to learn. Sysadmins need to learn programming to develop more effective work methods. The sysadmins who do not do this will most likely see their work be outsourced to a more effective service provider.

Re:... and with systemd.

[Anonymous Coward]

I want what you are you smoking. It must be some good shit to say all of that with a straight face.

Re:... and with systemd.

[Anonymous Coward]

One of the biggest things is being able to maintain unit files upstream instead of having each distros package maintainers need to tailor init scripts. That, by itself, will save a huge amount of man hours.

Re:... and with systemd.

[Peter H.S.]

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).

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 different distros. It also shows that their are open to new ideas and code from outsiders.

So maybe your assessment of Lennart Poettering is wrong and based on the countless made up stories about the man circulated by the systemd detractors.

The point that gets across to Red Hat is our money. Money that can go elsewhere.

And Suse, and Debian, and Ubunty, and CentOS, and Arch Linux etc. etc. All major Linux distros are going to use systemd as their default init system and the vast majority of the smaller distros will follow suit too.

Systemd have won over all major distros because of its superior advantages, and because any opposition to it seems to consist of people in denial, claiming that sysvinit is perfect and should be used for the next 40 years so they don't have to learn anything new. With that attitude it isn't a wonder why no-one seems to develop any alternatives to systemd, or even maintaining critical non-systemd components.

Re: ... and with systemd.

[Anonymous Coward]

Lennart Poettering... Wasn't he the arrogant asshat that shat pulseaudio? What a steaming pile that was!

Re:... and with systemd.

[fnj]

Sure you can use another login manager

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:... and with systemd.

[caseih]

Have you ever written an init script? As an admin you should have written one or two in your day. You'll know how fragile init scripts are, reinventing the wheel over and over again to do basic things like prevent a service from running twice. Want to restart a service automatically when it crashes? Well you hack another script that runs in a cron that uses hackish ways of determining if the daemon has crashed: Check for a running process, find out if it's responding, kill it if necessary, start it again. Gets unsupportable in a hurry on production systems. So we resort to third party solutions like supervisord, which work pretty well, but aren't integrated into the init system at all, so they don't obey runlevels. The two largest unix vendors have not shipped sysv init for many years. Solaris replaced it with SMF, and Apple with LaunchDaemon. systemd is superior to both systems.

As an admin surely you can see the benefit to creating simple daemon definition files that can get your daemon up and running (with restart, with protection against multiple instances) all with two or three lines of a simple text config file.

From what I can see systemd is modular, and if you don't want to use journald, you don't have to. On RHEL7 it's set to small, ram-based log for crash reporting only, with the real enterprise-required logging going to rsyslog which is a conventional logging facility.

I personally cannot find fault with Pottering's work. It just works for me (I am an admin also). I also am extremely grateful for pulseaudio also. It just works now, and lets me do things that no other system currently does, like record one program's output to mp3 while listening to music or watching videos. Can't argue with results.

Re:... and with systemd.

[Anonymous Coward]

"These days it is all about packing maximum of services on each hardware unit, with virtualization, OS containers, services on demand, plugging services into LSM's (Linux Security Modules). It is all about massive and fast deployment, cloud computing, and getting the most from the hardware you got, for the least amount of effort. Automatic supervising chains of all processes and services are simply a must, rate limiting and service hardening with minimal effort are required."

Why on earth is that a job for init?

Re:... and with systemd.

[Anonymous Coward]

"instead of developing an alternative to systemd".

The "alternative" already exists. It is systemd that is attempting the status quo, therefore they have the burden of proving why this is necessary.
Aside from a small number of use cases with low deployment rates, in my opinion this hasn't been done yet.

The whole thing smacks of NIH on steroids.

Re:... and with systemd.

[Peter H.S.]

The problem is, that on a multi user system, something have to track user sessions, or else suspend, sleep and shutdown (and many more things) doesn't know when it is safe to operate. On Linux this used to be done by ConsoleKit, ("logind" is the systemd solution), but CK have been abandoned for almost 2 years now. It is bit-rotting and starting to break, and upstreams projects like KDE and Gnome are finding it increasingly hard to support.

So in order to run a multi-user or multi-seat Linux system in a way people expect, you have to use systemd.

There is also root-less X.org. It can't be done safely on Linux without systemd's "logind" because of eg. raw input devices needs to be tracked by a session manager. ConsoleKit could probably be extended to do the same, but nobody seems to try.

At the moment it also look like that Wayland Desktop Environments will be a systemd thing only. Eg. KDE KF 5 will support non-systemd systems running X.org, but only systemd systems with Wayland. Again, they don't do it because they are remote controlled by Poettering, but because all new development outside KDE is happening around systemd. There are no alternative developers actively supporting other solutions than systemd, so KDE simply have no other choice.

There are many more problems for non-systemd systems that will crop up, once all the major Linux distros and their developers shift their focus to systemd.

I have no problem with people preferring other init systems than systemd, in fact, some competition to systemd would be nice. But in order for people using eg. sysvinit in the future, they better start making a clear, technical analysis of what maintenance problems they have to deal with, and start working on them.

As it is now, even distros like Slackware that isn't so hot on systemd, will probably become systemd distros, simply because they have no real alternative, and are too small to pick up all the maintenance burden themselves.

Re:... and with systemd.

[Anonymous Coward]

>> 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.

I'm not a fan of systemd, its a pain in the ass to work on as a sysadmin. However, it does serve a purpose. I am adverse to reboots as a sysadmin, unless I have to for a kernel.

Systemd is suitable for the following types of users:

1) home users who reboot their machines regularly
2) cloud systems that need to scale horizontally and *quickly*
3) adhereing to 99.999 (five-nines) uptime SLAs because of contractual/financial penalties occur - this happens on big systems (a reboot can take so long that the fives-nines SLA is breached, systemd reduces the reboot times)

I hear and appreciate your opposition, but we live in a world where many people have many uses for the same thing. I use a spoon for my soup, others use it to dig holes. We cannot hold back progress because it is too complex, doesn't exactly meet our own needs, whilst disregarding other peoples needs.

The pain of working on systemd as a sysadmin is minimal and once off, we seldom ever need reboot our servers, so speeding up reboot times gives no real benefit to us. I'd rather not use systemd but the reality is the world has valid reasons to use it, and because I don't like it doesn't mean we should hold back progress.

Being harsh, you said:

>> it's works
true, but how could it be better?

>> it's simple
you work with computers, you must do more complex things than mess with init stuff.... come on... toughen up. computers are naturally complex, why get on a crusafe over one small aspect of it.

>> it's good
sure, but it's simple, but it no longer meets the needs of most users these days.

Stop holding progress back from near sightedness.

Re:... and with systemd.

[Peter H.S.]

"These days it is all about packing maximum of services on each hardware unit, with virtualization, OS containers, services on demand, plugging services into LSM's (Linux Security Modules). It is all about massive and fast deployment, cloud computing, and getting the most from the hardware you got, for the least amount of effort. Automatic supervising chains of all processes and services are simply a must, rate limiting and service hardening with minimal effort are required."

Why on earth is that a job for init?

Because it can't be done safely in any other way. This is why certified Unix'es like Solaris and Mac OSX have dropped old style init scripts; sysvinit and its brethren doesn't belong in the modern world. They are outdated and unsafe.

Re:... and with systemd.

[Anonymous Coward]

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.

Just like Toyota drivers have been smearing Ford drivers and trash-talking Ford, instead of building an alternative to driving a Ford.

Maybe we are not developing an alternative to systemd, because we already have an init system that works, adheres to the Unix way of do one thing and do it right, and is fully scriptable, unlike the ini-file infested blob called systemd.

Re:... and with systemd.

[Peter H.S.]

One reason why systemd simply routs any opposition is, that when people actually study it, they find that is has awesome new features and solve so many of the sysvinit shortcomings. From terminating services correctly http://0pointer.de/blog/projec...
to actually tracking and supervising all running processes http://0pointer.de/blog/projec...

And because of its design, it also offer superior security features, because as PID1 it can hook into advanced kernel features like "kernel capabilities" http://man7.org/linux/man-page... and "cgroup", and soon, also kdbus. Systemd works as a Linux plumbing layer, making all these features available for end users and distro maintainers, and making them easy to use by just adding simple keywords into a text config file.

Systemd is also a cross distro comparability layer; that means upstream projects can develop against systemd, and be sure it works across many different distros. It is easy to develop DE developers to make a GUI for setting networks or NTP/time or keyboard layout etc, on a systemd OS. On non-systemd distros, everything is scattered and fragmented, making it impossible to do.

The end result is, that all new development will be done with systemd. And because people like you think that nothing needs to be changed, the non-system distros will remain utterly fragmented and unsupported from upstream projects.

The bottom line is, that if people want to use non-systemd distros in the future, they better start getting off their couches and start develop an alternative. Not only do they need to maintain sysvinit infrastructure now that the "big boys" like Red Hat and Debian and Suse and Ubuntu are converting to systemd and therefore drops sysvinit/upstart development, but also extend the present infrastructure to deal with eg. safely using rootless X. They also ought to organize to help upstream projects like KDE and Gnome, by making a similar compatibility layer that work across the few remaining non-systemd distros.

Re:... and with systemd.

[rastos1]

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.

Strangely it reminds me of Metro UI on Windows that may be nice/useful on tablet/phone but was pushed by MS also to places where it does not belong: desktop or even server.

Similarly systemd may have it's uses for some specific systems and for all I care go ahead. But if systemd is going to take over my workstation and turn the boot process into something that is difficult to read/modify/log/... then I'm not going to be happy.

Re:... and with systemd.

[fnj]

Thanks for the thoughful reply.

I don't think it's quibbling to point out that you can have multiple users on a system with no GUI at all. By convention, none or only one of them has administrative access, or you maintain some kind of user discipline with respect to administration. This is mostly true for what are customarily called servers.

Ever see the text "Warning, system is shutting down in 10 minutes" splattered over your emacs screen, heh heh?

Anyway, as I reveal elsewhere on this page, init is not the ONLY login system I use. In fact my main desktop system runs arch with systemd, so I am reasonably comfortable with either system. And your points are well taken. I don't think there is anybody who thinks there is the slightest question that the "battle of init systems" for linux is over and systemd has won, and furthermore it's not going to be tenable for long to stay current with ANY distro and avoid systemd for whatever reason.

But I remain skeptical that a server "needs" systemd - witness that BSD servers work fine and none of them have systemd.

Re:... and with systemd.

[Peter H.S.]

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.

Strangely it reminds me of Metro UI on Windows that may be nice/useful on tablet/phone but was pushed by MS also to places where it does not belong: desktop or even server.

Similarly systemd may have it's uses for some specific systems and for all I care go ahead. But if systemd is going to take over my workstation and turn the boot process into something that is difficult to read/modify/log/... then I'm not going to be happy.

I don't think it is similar to the GUI formerly known as Metro. As I understand it, Metro removes abilities from the end user, while systemd actually enhances the end user by providing many more powerful features in an easy to use manner.
Also, systemd enhances both tiny embedded systems, servers and desktop systems. It doesn't have any weak points in that regard.

You shouldn't worry about "read/modify/log.." when it comes to systemd. It enhances early boot logging considerably since it is active from initramfs. All the config files are well documented text files with declarative statements that are easy to parse for both humans and programs. Systemd has a lot of really nice helper programs like "systemd-delta" that instantly tells which of the hundreds of service config files (unit files) that have been changed, and it is also smart enough to see whether it is a functional change, or just an added comment.

It is however a new way running and maintaining Linux. You can't avoid reading up on the subject if you want to modify or understand things. What many discussions on systemd makes clear is that many people are quite ignorant of its features and its design. They simply haven't studied it.

If you want to admin Linux in the future, it is simply mandatory to read up on systemd. The official systemd site isn't a bad place to start.
http://www.freedesktop.org/wik...

Re:... and with systemd.

[rastos1]

As I understand it, Metro removes abilities from the end user, while systemd actually enhances the end user by providing many more powerful features in an easy to use manner.

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.

Re:... and with systemd.

[Peter H.S.]

...But I remain skeptical that a server "needs" systemd - witness that BSD servers work fine and none of them have systemd.

"Need" is an elastic term. Sure, sysvinit worked on Linux servers for many years despite its many shortcomings, but it was always a very resource intensive endeavor to make it work and support it (think; all distros have different init scripts for each service and everybody of them hard to debug and prone to bugs). All the missing functionality of sysvinit had to be made up with complex scripting at each and every service.

But the old sysvinit model relied heavily on a certain way of doing computing, basically running servers directly on the metal with a few selected services and often with lots of "scripting" glue hand crafted for each server. They where individual servers, maintained by admins that needed a rather thorough knowledge about how a particular server worked.
But that model have changed considerably over the years and that is the main reason why old style script based systems no longer is working as well as it used to do.

Massive and rapid deployment of servers, virtualization, OS-containers, instantiated services etc. are becoming important. OS's needs to be automatically configured, or mass configured by machines. It is all about speed and hardware density in order to stay competetive. Take for example a hosting provider that has 10.000 Linux instances hosted. It used to be that they would have to run 10.000 instances of sshd or similar, even though only 1000 users where active at the time. With systemd they only need to run exactly the amount of services as there are current users, since services can be "on-demand socket activated". (no, it isn't like inetd, read here: http://0pointer.de/blog/projec... )

In short, the provider can pack more users into each hardware unit, that saves money.

systemd also makes it possible to upgrade a service and restarting it without breaking any end user connections (it buffers the client requests).

There are many systemd enhancements for servers because it isn't just simple init systems. I think that in order to stay relevant, BSD will have to start cloning a considerable amount of systemd features. It will be different on BSD because they don't suffer the same fragmentation chaos as Linux, but the main points of systemd, like (k)dbus service communication, intelligent PID1 that utilizes kernel features like security modules making them available to services without reprogramming, a total service and process superviser chain, early "metal-to-metal" logging etc. will be cloned by BSD. It is only a matter of time.

Re:... and with systemd.

[Peter H.S.]

As I understand it, Metro removes abilities from the end user, while systemd actually enhances the end user by providing many more powerful features in an easy to use manner.

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 pager for viewing log files is good old "less". You can easily disable the pager, or use another one of you like.

All the systemd tools are just normal Linux tools, just better implemented than average. So all the text utils and find utils etc. works absolutely fine with systemd tools. I really don't know where you got that idea that this wasn't the case.

Sure, you can't grep the structured journal directly, but that is what piping was invented for. "journalctl -b1 -p err | grep -i rpcbind" shows all instances of "rpcbind" in the previous boot log only, and only at error level "critical".
It is that easy.

Oh, and the structured journal is well documented with a interface stability promise, and many language bindings to read and write into it. Even rsyslog can read systemd journal files directly.
Here is how it is designed:
http://www.freedesktop.org/wik...

I don't think there are any aspect where shell scripting can't be used together systemd and its tools. In fact, systemd enhances the admins ability to gain secure knowledge about the system and executing programs depending on the state of the system.

No offense meant, but systemd opponents are usually badly informed about even basic points about systemd. They seem to get their opinions about systemd, not from the systemd documentation, but from other users on the net, and quite frankly, some of those users are just spewing random lies and made up stories about systemd because they are blinded by their hatred.

Do yourself a favor, and don't rely in random anonymous systemd haters for your information, but get it from the source instead.
http://www.freedesktop.org/wik...

It is worth getting a proper knowledge about systemd since this is the future of Linux, especially if one intends to poke around and make custom stuff.

Re:... and with systemd.

[Andrewkov]

Just ignore him, he's an XP user..

Re:... and with systemd.

[Wdomburg]

systemd is irrelevant here. RHEL6 has always had a committed lifecycle, ending on November 30, 2023.

Re:... and with systemd.

[Anonymous Coward]

And as an admin, I fail to see what was wrong with the BSD Init system.

Well, that there is your problem. You are stuck in the past and have stopped evolving. As you say, you fail. Yes, I am aware that this sounds rude. That's not the intention, believe it or not.

Re:... and with systemd.

[Antique Geekmeister]

RHEL 7 actually has a number of my corporate colleagues and partners looking more deeply at Ubuntu. If they're going to have to rewrite that much of their software and toolkits to switch to RHEL 7, it effectively lowers the threshold to switch entirely to a different distribution. And I'm afraid RHEL 7 is already behind the leading edge on many of its components.

Re:... and with systemd.

[Antique Geekmeister]

Yes, there are certainly advantages to a more intelligent daemon for starting, and managing, critical services. But weaving it into system logging is a support nightmare, at variance with the older UNIX and Linux approach of using simple tools to do very specific tasks, and chaining them together as needed, rather than making a monstrous "does everything" tool.

The approach of using simple 'daemon' files has been repeatedly engineered, and done well, by such experts as Dan J. Bernstein with his old "daemontools" package. That tool worked very well, it just never became part of standard Linux distributions due to his previously very strange licensing. He's since discarded that licensing and made it public domain: I'd have frankly preferred to see something much lighter weight and independent such as daemontools, perhsps with patches to provide a more sensible layout of components. Dan apparently considers the Linux File System Hierarchy to be irrelevant to his work and tended to put his components in some odd places, but that was easily patched.

Some nice looking features/updates

[B5_geek]

I have always admired RH for it's feature set and pursuit of enterprise-related features.
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? /etc/network/interfaces
vs /etc/sysconfig/network/networking/where/are/the/damn/config/files

Re:Some nice looking features/updates

[thaylin]

Because some people like /etc/network/interfaces and some people like /etc/sysconfig/network-scripts/. When you can fork the software people tend to start putting things where they want. You prefer the first, I the latter, as I have been working on systems with it for 14 years.

Re:Some nice looking features/updates

[Anonymous Coward]

More people uses the other one, Red Hat should learn and get in line with the de-facto standard.

Re:Some nice looking features/updates

[Peter H.S.]

I have always admired RH for it's feature set and pursuit of enterprise-related features.
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? /etc/network/interfaces
vs /etc/sysconfig/network/networking/where/are/the/damn/config/files

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... and "cgroup" https://www.kernel.org/doc/Doc...

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...

Re:Some nice looking features/updates

[jandrese]

I prefer /etc/rc.conf personally. I'm not sure why every interface needs its own config file.

Re:Some nice looking features/updates

[kthreadd]

It's much easier to handle large scale automation when you're using separate files.

Re:Some nice looking features/updates

[B5_geek]

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:Some nice looking features/updates

[thaylin]

How much did Lennart pay you? 8)

Re:Some nice looking features/updates

[Peter H.S.]

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:Some nice looking features/updates

[Anonymous Coward]

If you are using the right distribution it's of course /etc/rc.d/rc.inet1.conf

Re:Some nice looking features/updates

[armanox]

Except, when it comes to Enterprise, Red Hat is the standard.

Re:Some nice looking features/updates

[Anonymous Coward]

Be that as it may, it doesn't change the fact that systemd MOAR LIEK SYSTEM DICK LOLOLOL

Bitches can't keep their services or panties up, yo.

Re:Some nice looking features/updates

[Cramer]

It's like that because that's simply where they each "do their thing". Redhat was around long before debian, so the question should be "why did debian change it?" Redhat did it that way to simplify automation and deployment -- one config file per interface isolates interface configurations, and makes parsing far simpler. (if you need to setup or know anything about eth0, it's one file, and everything in it pertains to eth0.)

Re:Some nice looking features/updates

[Anonymous Coward]

In the distributed world Red Hat is the standard. In the financial world (System z) SLES is the standard, Red Hat lags behind.

Re:Some nice looking features/updates

[shadowknot]

Amen to that, all hail Bob!

Re:Some nice looking features/updates

[arth1]

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:Some nice looking features/updates

[styrotech]

Redhat was around long before debian,

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.

Re:Some nice looking features/updates

[PrimaryConsult]

That's what RH Clustering Services are for...

Re:Some nice looking features/updates

[arth1]

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: Some nice looking features/updates

[Anonymous Coward]

I rather use a system that likes to suck dick than having to use SysVInit

Re:Some nice looking features/updates

[fnj]

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:Some nice looking features/updates

[fnj]

The only thing that keeps me from switching to OpenBSD for all my servers: apt-get dist-upgrade

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 packages, "pkg upgrade".

The really nice thing with BSD is you can update userland to latest on any base OS release - whether you use ports or packages.

Re:Some nice looking features/updates

[fnj]

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 systemd as my main desktop at this point. The pointers from you and other knowledgeable supporters did help a lot. I'm not sure there is an adequate systemd FAQ/pointers site yet.

Re:Some nice looking features/updates

[PrimaryConsult]

In that case it should be even easier with separate files: copy the ifcfg-eth0:1 for whatever service you want (if necessary restoring from a backup if the original server is dead) and just ifup it... I fail to see any situation (other than initial learning curve) where one file would be significantly easier than multiple, but can see many where multiple files are significantly easier than one.

Re:Some nice looking features/updates

[Tough Love]

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.

It's because the linux kernel network maintainer isn't exactly the best designer in the world. Great at maintaining compatibility while loading on the features, good at keeping it relatively bug free, passable at micro-optimization, but sucks beyond belief at design.

Re:Some nice looking features/updates

[x_t0ken_407]

Agreed full-heartedly. It broke my heart when Arch caved. Luckily I'm also a FreeBSD aficionado...but still...

Re:Some nice looking features/updates

[Anonymous Coward]

I'm afraid that /etc/sysconfig/network-scripts is a nightmare of interwoven shell scripting. Do actually read the "ifup" and "ifdown" scripts to understand them better, they've been "feature" encrusted for years and have become unreadable. And every single network configuration tool has its own guidelines for where, and how, to store information that may override, aggregate with, or unset other options

And don't get me *started* on the debris NetworkManager creates with these settings.

Not the same LXC

[DeHackEd]

There's two projects named "lxc" - the one linked in the article ( https://linuxcontainers.org/ ) and one that's part of libvirt as a hypervisor driver. RHEL 7 includes the latter.

Now, time to download it and see how much has changed since the RC.

Re:Not the same LXC

[kthreadd]

Maybe I'm missing something but what good is the libvirt driver if you don't have anything to connect it to?

Re:Not the same LXC

[DeHackEd]

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:Not the same LXC

[gmuslera]

The big thing about this release is not that they include LXC, that is been around for years, but that they included Docker, that simplifies and goes beyond what LXC does.

Very excited announcement

[NaCh0]

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...

[Junta]

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 with XML over SOAP and all sorts of other nastiness). It represents drinking the kool-aid after much of the ecosystem has moved on (microsoft has de-emphasized CIM, many of the enterprise vendors that once always provided and demanded CIM providers have come around to a viewpoint that CIM style instrumentation isn't perhaps the best idea).

Re:Good and bad...

[bluefoxlucid]

systemd is nice since it can keep your services running, alert you to problems, and tell you why they failed when there's no logs coming out.

Re:Good and bad...

[thaylin]

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.

Re:Good and bad...

[iggymanz]

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:Good and bad...

[thaylin]

hey I am with you, just saying the bloatware that is systemd is not needed, and in my case not wanted.

Re:Good and bad...

[thule]

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't know that they understand that Chef/Puppet do much more than handle providers. If anything Chef/Puppet would use the CIM objects created with DSC. CIM abstracts the complexity of changing the configuration of Windows. Microsoft provided CIM configuration objects are a huge win for scripting configurations!

I'm not sure that the OMI people envisioned large configuration scripts being called through CIM. It would be like configuring an OS via SNMP. SNMP would be the mechanism to call scripts on a remote machine (net-snmp can do this). You could do it, but why? MS could just have easily exposed the objects directly without going through CIM. The advantage I suppose is that OMI provides an open transport to call CIM objects. Only problem, Microsoft uses WS-Management, not WBEM.

Re:Good and bad...

[Peter H.S.]

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 systemd isn't modular, even though a simple look at the source files could have told them otherwise. At the same time they also accuse systemd for being too modular, in that since systemd runs as PID1, it can utilize advanced kernel features like cgroup and let other modular parts of systemd (like logind), or third party deamons take advantage of that.

Re:Good and bad...

[amorsen]

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 edits survived. Not nice.

A replacement for init was sorely needed.

Re:Good and bad...

[arth1]

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 more ways to do things, not fewer.

Re:Good and bad...

[Anonymous Coward]

> This just wrong; systemd dramatically increases security by eg. making use of "Kernel Capabilities"

Etc., etc. 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. It took 5 years for SELinux to be thoroughly integrated for most tools, and I'm afraid that this over powerful and overburdened toolkit is likely to prevent RHEL users from wanting to update. It's complex and powerful features sets are incompatible with the ease of comprehension and use that most developers need, and require extensive post-development integration for most developers.

I'm afraid that most companies I work with are saying "holy crap, for all that work, do we get anything? Why don't we just switch to Ubuntu like those fanboys have been saying"? And I don't have much to block them with, Yes, it's the only thing supported on Fedora for the last few years, but we couldn't switch to Fedora anyway *precisely* because of this kind of unnecessary and undesired forklift change.

Re:Good and bad...

[Peter H.S.]

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 "/usr" read-only for the service; even if the service is exploited to run code with root-privileges, the /boot and /usr directories will be read-only for that root executable (and all other instances/processes that stems from that).

This is great stuff; even the distro maintainers can turn on powerful "Kernel capabilities" as default. There is no need to patch code, or ask the service developers to understand anything about it, or develop against it.

Same with "cgroup". It is a one-liner to enable powerful system usage limits, or giving a certain service net/cpu/IO priority.

"Capabilities" are meant to be used together with a MAC like SElinux, and normal ACL's, but thanks to systemd, it is extremely easy to use. No need for compiling custom kernels, hand crafting scripts that are distro specific, or similar barriers; just adding simple keywords to a text config file, and systemd will take care of all the behind the scene magic.

Re:Good and bad...

[Anonymous Coward]

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.

Re:Good and bad...

[arth1]

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/snapshots everything including all visible storage when a single process dies. Doable, but not very feasible or economical.

Re:Good and bad...

[fnj]

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:Good and bad...

[Peter H.S.]

At the moment, http://www.freedesktop.org/wik... is the best site for systemd information. It could have a better organization, but there is an awful lot of information about systemd, even the nitty gritty details needed for developers.

Re:Good and bad...

[Anonymous Coward]

That's why systemd is smarter than the traditional init based on inittab; It see how fast the process respawn and act on that. Also, having a "human operator based restarting" is usually followed by "if it doesn't fix, then escalate to another person", which may be "wake up your sysadmin at night", cause not all company have proper 24/7 around the globe where someone is working and awake in his location..

And sure, a coredump can be useless. It could just be a memory corruption that corrupted and the backtrace serve nothing, it could be anything. But then, you have to decide between the money you lose when something is down because you didn't start, and the money you spent to fix that so it doesn't fail later. There will always be hard to reproduce problems.

Re:Good and bad...

[Peter H.S.]

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=, StartLimitBurst="

You can even make systemd clean up core dumps after a failure if that is what you want.

Here is a overview of the many fine grained service control mechanisms that systemd supports;
http://www.freedesktop.org/sof...

Re:Good and bad...

[Anonymous Coward]

You are using the developer view of "modular", rather than the admin view of "a bunch of small programs each doing only one thing (the Unix model).

If systemd had followed the Unix model, people would be able to take good old init, the rc-replacement from systemd, and syslog, and hook it all together. As it is, if you want one thing systemd, you get all of it.

If not for the Gentoo people who forked udev, "if you want one thing from systemd" would have included systemd.

Re:Good and bad...

[Peter H.S.]

You are using the developer view of "modular", rather than the admin view of "a bunch of small programs each doing only one thing (the Unix model).

If systemd had followed the Unix model, people would be able to take good old init, the rc-replacement from systemd, and syslog, and hook it all together. As it is, if you want one thing systemd, you get all of it.

If not for the Gentoo people who forked udev, "if you want one thing from systemd" would have included systemd.

First of all, let me say that "Unix model" and all similar references to Unix philosophy etc, are totally content free platitudes in my opinion. There is no canonical "Unix" book where a Unix-pope have decreed ex catedra what "Unix" is. Heck, Unix was even born without support for "piping" between programs. The "Unix model" end up as 1990's time freeze because that keeps some old sysadmins happy that they don't need to learn anything new.

So it is easy to argue that systemd actually follows the "Unix model" in every way, and is modular, even in the "admin" sense of the word as you describe it.

Systemd is an umbrella project with many small programs collected in one utility box, just like "busybox" or "kernel-utils". It consist of many small binaries, like "systemctl" "localed" "timedated" etc. All these binaries behaves exactly like any other Linux/Unix binary tools; they tend to do one thing only (and do it very well), and can easily be combined with any other standard GNU tools like grep, sed, tee, ed, less and so on, by utilizing piping (eg. "systemctl | grep -i foobar") . They are in fact indistinguishable from any other Unix tool in the way they behave.

You are off course also wrong about systemd requiring the whole package or nothing. Just look at the compile switch options. There is even an official page about how to reduce systemd even further http://freedesktop.org/wiki/So...
One of the key drivers behind systemd is the embedded market, and they want minimal systems. On desktop and servers, it doesn't make much sense removing systemd options, since they are basically zero-overhead and provides options that nobody else does.

And yes, systemd works fine with together syslogd, in fact it enhances it considerably because systemd is able to get early and late boot log info since it is active from early boot in initramfs.

What you can't do is ripping random elements out of the systemd toolkit and expect it to work unmodified together with any other random system.

Re:Good and bad...

[Antique Geekmeister]

> This just wrong; systemd dramatically increases security by eg. making use of "Kernel Capabilities"

Just like SELinux, which I'm afraid most developers and many admins turn off as their first step in setting up new systems. Using internal security structures requires extra development time: it may be well invested, but it's extra work that is already discouraging people form upgrading or activating such security features. Please do not assume that simply because a security structure is available that it will be welcomed, or used, by most developers.

Re:Good and bad...

[Antique Geekmeister]

> You are off course also wrong about systemd requiring the whole package or nothing. Just look at the compile switch options.

"Compile switch options" are entirely irrelevant to published binary system components, such as systemd in RHEL 7. It's certainly possible to compile many system tools without specific features: this does not make them "separate" from the systemd monolith.

Re:Good and bad...

[Peter H.S.]

> You are off course also wrong about systemd requiring the whole package or nothing. Just look at the compile switch options.

"Compile switch options" are entirely irrelevant to published binary system components, such as systemd in RHEL 7. It's certainly possible to compile many system tools without specific features: this does not make them "separate" from the systemd monolith.

No, "Compile switch options" are entirely relevant for every distro. The distro has full control over which part of of systemd they want to include and with which options switched on as default. Systemd can be tailored in many different ways to fit both super computers and clusters, servers and VM's and OS containers, and desktops and tiny embedded systems. It is extremely flexible.
Just look at the documentation and the source code; it is all there for everyone to see.
http://www.freedesktop.org/wik...

If you don't want how RHEL are distributing systemd, just get another distro, or talk to Red Hat and explain you particular user case.

Re:Good and bad...

[Peter H.S.]

> This just wrong; systemd dramatically increases security by eg. making use of "Kernel Capabilities"

Just like SELinux, which I'm afraid most developers and many admins turn off as their first step in setting up new systems. Using internal security structures requires extra development time: it may be well invested, but it's extra work that is already discouraging people form upgrading or activating such security features. Please do not assume that simply because a security structure is available that it will be welcomed, or used, by most developers.

I am aware that some turn of SELinux, because it is "easier" and they don't understand how it works, and they don't want to learn anything new. Yes, there a many SA's that lack both the technical skills and the ability to learn new skills.

But frankly, uneducated people with lack of skills, shouldn't hold back the development of Linux, just because they can't be bothered learn anything new even though they as SA's are paid to keep up with technologies (let's use SysVinit the next 30 years too, hooray!). They will be punished by life and left at the wayside. I have seen this happening to a lot of people in the IT business since the 1980's; they stagnated and stayed in their comfort zone and was later ejected out of the IT business because of outdated and obsolete skills.

Systemd is now the new defacto Linux plumbing system, and SA's either learn it, including its security features, or they will have to stop being Linux SA's.

Besides that, using "Kernel Capabilities" are very simple. Just put a single keyword into a text file and restart the service. Most end users will never have to edit anything since the services will come with some standard "kernel capabilities" features turned on, like "ReadOnlySystem=" and "ProtectedHome="

So yes, people will use systemd's many new security options, since they will be turned on by default in their distro, and it will increase security dramatically compared to old legacy Sysvinit systems, that are hard to protect. And yes, in the future there will be more kernel security features that systemd can utilize like kdbus, making services ever more hard to exploit, and making the defense ever deeper, practically sandboxing exposed services.
Systemd will make Linux more secure, it is a simple fact.

Re:Good and bad...

[Antique Geekmeister]

The existing compilation settings are, of course, in the SRPM's published by Red Hat. Manipulating them and replacing core utilities means maintaining an internal fork: it would no longer be part of, nor supported by, Red Hat's distribution. I'm afraid that it would also be like removing a car's battery. One can jumpstart the car, but it will cause a host of other problems because the rest of the operating system is now integrated with such a core component.

Re:Good and bad...

[Peter H.S.]

The existing compilation settings are, of course, in the SRPM's published by Red Hat. Manipulating them and replacing core utilities means maintaining an internal fork: it would no longer be part of, nor supported by, Red Hat's distribution. I'm afraid that it would also be like removing a car's battery. One can jumpstart the car, but it will cause a host of other problems because the rest of the operating system is now integrated with such a core component.

Either you have an actual user case for not using eg. RHEL's setup and version of systemd, and then you act upon that, or you don't have an actual user case, and there the problem just disappears.

You seem to try to make a problem out of nothing, what exactly is the precise problem you have since you want to configure systemd differently from RHEL?

The problem with discussing with systemd opponents like you is that you are hopelessly uninformed about systemd. That is why the critique seems so vague and imprecise.
Stop getting your information from ignorant systemd haters, and study the project itself. I can recommend the video talks on the systemd page if you want to understand the design of systemd. In a few years, all Linux distros will use it, so it is worth investigating.
http://www.freedesktop.org/wik...

Re:Good and bad...

[Antique Geekmeister]

I do not "want to configure systemd". I want to not replace several decades of daemon and log management integration in dozens if not hundreds of distinct environments with an entirely distinct, complex, and poorly integrated system.

The idea that "in a few years, all Linux distros will use it" is completely irrelevant to the upfront cost of switching now.

Re:Good and bad...

[Peter H.S.]

I do not "want to configure systemd". I want to not replace several decades of daemon and log management integration in dozens if not hundreds of distinct environments with an entirely distinct, complex, and poorly integrated system.

Those old and crusty daemon and log management integration tools are simply crap compared to systemd's integrated approach. You obviously don't have any real experience with systemd if you think otherwise. Everything is at least 100 times better than compared to SysVinit/Upstart (and Syslog etc).

The idea that "in a few years, all Linux distros will use it" is completely irrelevant to the upfront cost of switching now.

No it is not. The point is that if you will continue to use Linux, you have to switch to systemd. The development of components needed to run non-systemd systems have been stagnated and bit rotted for years.

So you have to switch to systemd at some time or another, so you better get started as soon as possible with learning systemd. Yes, there will be a cost for doing so, namely that you will have to learn something new. But that really goes with the territory when working in IT. Staying in the comfort zone instead learning new stuff (which is getting harder the older you get) is a surefire way to become obsolete on the job market.

Systemd has really good backwards compatibility with old daemon init-scripts and is it possible to use it with syslog if you have many logwatch scripts. It is quite possible to have a gentle upgrade of the environment by keeping backwards compatibility with legacy programs while slowly out-phasing them.

Re:Good and bad...

[Antique Geekmeister]

> Those old and crusty daemon and log management integration tools are simply crap compared to systemd's integrated approach. You obviously don't have any real experience with systemd if you think otherwise. Everything is at least 100 times better than compared to SysVinit/Upstart (and Syslog etc).

Can I safely assume that you never used Dan Bernsteiin's "daemontools", which stayed of the complexities of logging and worked very well for daemon management.? If SysV init was due for replacement, then there are much lighter tools that could have done just _that_ task.

Re:Good and bad...

[Peter H.S.]

Can I safely assume that you never used Dan Bernsteiin's "daemontools", which stayed of the complexities of logging and worked very well for daemon management.? If SysV init was due for replacement, then there are much lighter tools that could have done just _that_ task.

Oh I know Dan Bernsteins "Daemontools" like "supervise". With all due respect for the man, those tools are an ugly hack that tries to make up for the almost non-existing functionality of SysVinit. Systemd are so much better in any respect compared to "Daemontools" that has no rate-limiting, no intelligent restarting, no total supervising chain (who monitors "svok"?), no resource control etc. etc.

SysVinit has been on the official UNIX kill list for decades with every Unix OS getting something else. Only Linux kept on using it long after it should have been killed off, only because there where no central Linux development outside the kernel. It wasn't because SysVinit was good it lasted so long, it was lack of development.

Come on, if anyone said: lets mix config statements and executable code in a free form, unstructured executable config file, people would laugh at them. Nevertheless, this is exactly what Linux has done with script based init systems like SysVinit and OpenRC and the rest of the lot.

With systemd we finally have separated code and config statements. You configure the init-system (systemd) handling of services by adding simple keywords in a structured text file that can easily be parsed by both humans and machines.

With systemd there finally is a central, coherent development of the "system glue" outside the kernel. It is exactly what the "Linux Plumber Initiative is all about. Systemd allows end users, SA's, developers and Distro maintainers, to enable powerful Linux kernel features in userland (like cgroup, Capabilities and soon, IPC's like kdbus) with simple keywords added to config files.

SysVinit and all those script based init-systems are effectively dead.
The discussion is over what the new Linux default init-system and plumbing system is; systemd won by a landslide because of its technical superiority.

You will doing yourself a disfavor if you keep on listening to all the systemd haters; they don't know what they are talking about, and their religious hatred against Linux changing will mean they will get left behind. Don't fall for that trap, stay sharp and hone your skills on systemd.

Re:People still use Red Hat?

[Trepidity]

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:People still use Red Hat?

[bluefoxlucid]

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.

timing is everything in PR

[Anonymous Coward]

handy timing - Docker 1.0 yesterday, RHEL 7 today

Highly subjective...

[Junta]

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:Highly subjective...

[arth1]

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.
A system with hundreds of Windows .INI files and three layers of abstraction isn't particularly sysadmin friendly..

Re:Highly subjective...

[Anonymous Coward]

Sure, that's why Debian and Ubuntu adopted it. And that's because they want to annoy their customer that RH did adopt it too. In fact, that's because every body who make a distribution is stupid on Linux that they didn't follow random website from non developpers. because despites doing that since years and despites having their job at stake, they choose bad decisions.

Re:Highly subjective...

[arth1]

Developers aren't sysadmins - administrating your own laptop through gratuitous use of sudo does not make one a sysadmin.
A developer's idea of 24/7 uptime is 24 days a month, 7 months a year.

While there have been sysadmins contributing to systemd, it has mostly been damage mitigation, where developers not understanding why something was done the way it was had broken things through ignorance.

Re:People still use Red Hat?

[Trepidity]

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?

500 TB?

[iggymanz]

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:500 TB?

[Anonymous Coward]

Go with ZFS or ZFSonLinux and you wont need to worry about those sort of limits.

Re:500 TB?

[chuckymonkey]

It's not what it's capable of, it's what's been tested and is supported. You can certainly go bigger if you want, but don't expect support.

Re:500 TB?

[silas_moeckel]

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:500 TB?

[iggymanz]

funny, a couple of their competitors have no such limitations. That is like Cisco charging you for switch port use

Re:500 TB?

[iggymanz]

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

Re:500 TB?

[Anonymous Coward]

There's a difference between paying to be able to use something and paying to have someone to help you when you break it.

Re:500 TB?

[Anonymous Coward]

The difference is that Red Hat actually takes the time to test and validate their supported numbers, whereas many vendors will claim they can do X but don't actually test it and when you call into support, they'll be happy to take your call but won't have any actual experience with it and will promise to get back to you maybe next week once somebody bothers to try it out.

Re:500 TB?

[fnj]

no support for FreeBSD systems in the Enterprise, other than hiring consultants

This lack seems to spell o-p-p-o-r-t-u-n-i-t-y. I am currently running 2 big multiple-RAIDZ2 file servers for my own personal storage, using ZFSonLinux on RHEL6. I am definitely going to switch one to FreeBSD/ZFS. There must be A LOT of enterprises that could benefit enormously from ZFS, but are hesitant to say the least about adopting ZFSonLinux, and unlike me cannot handle their own support.

Re: 500 TB?

[buchanmilne]

It'swould be more like Cisco requiring ypu to buy a software/feature licence to use 10Gbps ports on hardware you already paid for.

Oh wait, they do that already (e.g. on ASA-5585-X, probably other ASA nodels too)

Re:500 TB?

[Blaskowicz]

Isn't it some very generic recommendation? i.e. meaning you can expect to run a 400TB volume without your software and system crashing or running like shit.

Re: 500 TB?

[Anonymous Coward]

Except it's not like that at all. Red Hat doesn't make you pay to unlock higher file size limits. They simply tell you it's unsupported but won't stop you.

The need for 8EB sized files or volumes doesn't exist by anybody currently, or if it does, it's an extremely small niche that isn't worth Red Hat's time and effort to create the testing environment for and the associated test cases for it to validate their releases against.

That's actually a very good policy - as I stated in another post in this thread, many other vendors will CLAIM they support some maximum theoretical limit but they've never actually tested up to that limit.

You can decide to be the one person in the world who needs multi-EB files/volumes and run into some quirkiness, call into 's support line, and they'll hem and haw about it and tell you it's not really possible or it's only possible under or whatever and never really actually get support for it and end up with a lot of disappointment because you believed the vendor's sales pitch. They were, of course, never actually expecting you to actually try to push those limits.

My own employer (I'm AC for a reason, folks) has the same shitty behavior. We advertise a list of limits/capacities on our niche IT product that we've never actually tested against (we've only tested up to a fraction of them, since all of our current customers run under those limits). Occasionally we'll get a customer who wants to push those boundaries and whoops, it doesn't work and we have to scramble to try to make it work in order to complete the sale, or worse, we tell them it was a mis-print and try to convince them to accept a lower limit.

Re:500 TB?

[Anonymous Coward]

Red Hat doesn't stop you from breaking the supported limits.

They'll just tell you to either open a feature request with some $$$ attached or otherwise take a hike if you try to do it and it doesn't work.

Red Hat has a very comprehensive suite of validation tests they run. That universe of test cases factors into mind what they deem to be reasonable to the current state of the market of what should be expected to work and function before they release software to the market.

The only people who might fathom 8EB file systems are NASA, CERN, and etc (all of whom have dedicated on-staff Linux geeks and kernel gurus who could do it themselves without vendor help). Likely not worth the cost / reward ratio to them to go to such trouble to try to address what is basically a non-existent market.

Re:500 TB?

[iggymanz]

I'd agree all of FreeBSD is opportunity. I'm a long time Linux enthusiast/architect/admin but honestly things are done a little loose and fast in the Linux realm, problem getting worse in the last two years. This bloated soon coming systemd rubbish, the Perl 6 of boot/management, might be last straw for me

BSD way more mature and stable.

Re: 500 TB?

[iggymanz]

absolutely false, Red Hat did indeed do that until recently

across IT shops across the nation

[nimbius]

C-Level: Red Hat has a new version of internet, we should install it.
PHB:right away! PM! Red hat has an OS! lets install it
PM: Of course! Engineering! how are we on the RHEL 7 project!?
Senior Engineer: I dont remember getting one did I give it to you?
Infrastructure group: you never approved our upgrade to RHEL 4 because it required Oracle downtime. You never agreed to the RHEL 3 upgrade because our proxy cant go down or the PHB cant get to facebook. We were told not to upgrade the RHEL 2 fileservers because the PHB keeps his motivational MP3's there. The only machine we have running RHEL6 is the one you made us install four days ago because you attended a webinar..so...i guess we'll have it upgraded by the end of the week.
PHB: whoa there pump your brakes guys...dont touch that server. if you take it offline i might not be able to get to the webinar next year!

Re:across IT shops across the nation

[philip.mather5551]

You've been on that Real Life ITIL 101 course as well huh? Did your certificate have little perforations at top and bottom as well?

Re:People still use Red Hat?

[Anonymous Coward]

Hah! Yeah, that'll work *great* in a production server, particularly when arch makes a breaking change.

Re:People still use Red Hat?

[Anonymous Coward]

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...

[Junta]

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 you want 'stuff that never changes while still giving new hardware support', you are pretty much stuck with AIX or mainframe at this point.

Re:Graded on a curve...

[bluefoxlucid]

Ubuntu works pretty well with the 6 month release cycle on 18/60 month support. They only ever have 4 versions to support, and their absolute policy of not changing anything unless it's very broken makes this manageable.

RHEL's model is 20 year support cycles. With a 10 year release, there's usually only 2 releases to support; but they upgrade things, change the kernel around, mess with the base system, and break ABIs during that release, so they're more challenging to support. For the end user, these changes mean increased risk.

Ubuntu's 2 year released LTS distributions provide 3 years to transition in the worst case. The user can manage risk by beginning test transition across multiple versions. Rather than move from 10.04 to 12.04, the user can begin testing and preparation for 12.04 when released; when 14.04 becomes available, the user can also test on that. If moving to 14.04 takes too long, the user can deploy on 12.04 with 2 years remaining, and with transition work to 14.04 already begun; otherwise, they can move directly to 14.04.

Risk management is flexible in this structure. A particular user (corporation) may have historical data of 6-12 months transition, and so may delay migration until 14.04 beta is out. They may also see the upgrade path as lower risk, and so transition every 2 years. They may mix deployments, transitioning some systems or deploying new systems on the newer platform so as to generate organizational knowledge, lowering risk of upgrading.

RHEL doesn't allow for this. Instead, the organization accepts the risk of lag. That risk is very real: RHEL 6 is missing a lot of new stuff that technology companies are leveraging in production right now. It's been like that for more than half its life. That kind of risk is what causes some companies deploying Ubuntu to go to an STS release and upgrade 6 months later, until they land on an LTS release. Companies running long-term mainstays--PostgreSQL servers, Web servers, and such--with no use for the newer versions are at lower risk by taking a 20 year supported platform, although RHEL exposes them to the already-discussed risks from shoddy release policy.

I strongly favor Ubuntu's model. If RedHat followed Debian-style release discipline, I would find their distribution more acceptable. It would be old, but it would supply long-term risk.

Re:Graded on a curve...

[Junta]

For my personal workstation, I favor the Ubuntu cycle, though I know the cycle is too short for a lot of other scenarios. So RHEL more closely hits those sensibilities in schedule. Unfortunately I've become less and less enamored of the content of the ubuntu cycle as they seem to try to steer things toward things like Unity and Mir.

However, as you say, RHEL will go crazy back porting features to old codebases without an appropriate level of risk relayed. An update from 6.4 to 6.5 is a lot more drastic than a service pack for most competitors, and then RH will refuse to support 6.4 claiming that '6.5 is a safe update', even if some third party stack cannot work correctly with 6.5. I do believe RH has enough expertise to backport features better than anyone else, but it is a bad idea for *anyone* to do it. I wish Fedora and RH weren't so disparate and Fedora would behave more like a typical Ubuntu release in terms of how conservative it is and how change averse it should be post release.

Re:Graded on a curve...

[bluefoxlucid]

Ubuntu has a 'backports' and 'updates-proposed' repository. RHEL forces that risk on you. That's something I often forget about.

Notably, there is no such thing as RHEL 6.4 and 6.5. They slap the versions on a release note, and dump them right into the RHEL-6 repository: it's impossible to get a RHEL 6.0 DVD and install RHEL 6.4 with all 6.4 updates; you can get a full RHEL 6.4 DVD and install your system as it was at RHEL 6.4 release, with no security updates, and no way to get to RHEL 6.4 plus all updates released prior to 6.5.

This is why I don't talk about point releases: they're imaginary. Ubuntu 12.04.1 isn't Ubuntu 12.04.1; it's Ubuntu 12.04 re-rolled with all current updates later in the release, so you can install right from the CD without having to download 80% of the software again immediately. If you installed 12.04 and ran updates, you'd get the same result.

Re:People still use Red Hat?

[Anonymous Coward]

Hummm... No. You are talking about Debian instead.

Re:People still use Red Hat?

[rafjaimes]

Comparing apples to oranges when it comes to linux distros. RHEL is for mission critical stability and especially servers where you don't want stuff changing all the time. Rolling release distros are dangerous in production environments. Especially a distro like Arch takes way too much effort to setup and maintain. Not every computer is a hobby.

Re:People still use Red Hat?

[bluefoxlucid]

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 fix backported if much software predicated its behavior on Perl 5.14 behavior. By contrast, a bug in Proftpd which completely ignores IdleTimeout would get a fix: IdleTimeout does nothing, is not working, and thus Proftpd is broken and nothing predicates on this unique lack of proper function.

RedHat is more likely to upgrade a kernel header, causing defined values in perl and C programs to become undefined or different, leading to arbitrary breakage. This has happened a few times.

tight coupling

[Anonymous Coward]

systemd is nice since it can keep your services running, alert you to problems, and tell you why they failed when there's no logs coming out.

I already have an alerting system, and if a process crashes I (more often than not) want it to stay down until I can go in and see why it died.

I'm sure having the functionality there is nice, and I'm hoping it's turned off by default, but systemd seems to be adding many, many features that seem all tightly coupled to each other. It's this last point that annoys me the most: the tight coupling.

40G ethernet

[banjer]

From the overview PDF:

Red Hat Enterprise Linux 7 beta supports 40G Ethernet link speeds, which enables faster network communication for systems and applications.

What was the max supported link speed previously in RHEL 6...10G?

Re:40G ethernet

[amorsen]

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:40G ethernet

[Junta]

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...

Which kernel version?

[sentiblue]

Has anybody gotten a confirmation whether kernel version 3.x is used in this release?

I read the press release from Redhat site but still didn't see any mention about it.

Re: Which kernel version?

[Anonymous Coward]

Yes. 3.10.something

Re:Which kernel version?

[kthreadd]

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:Which kernel version?

[Anonymous Coward]

https://git.centos.org/log/rpms!kernel.git/refs!heads!c7
kernel-3.10.0-123.1.2.el7

Re:Which kernel version?

[armanox]

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:People still use Red Hat?

[kthreadd]

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.

theguy

[Anonymous Coward]

Why to buy a Unix wannabe when you can get a full featured UNIX (Solaris) ?

Re:theguy

[kthreadd]

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:People still use Red Hat?

[Anonymous Coward]

You think a hobby distribution that didn't even have package signing until 6 months ago is a competitor to RedHat?

Is this still a good OS for desktop?

[guacamole]

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:Is this still a good OS for desktop?

[kthreadd]

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:Is this still a good OS for desktop?

[armanox]

Use ext4 for a laptop over the default, XFS. XFS is prone to data corruption when improperly shut down.

Re:Is this still a good OS for desktop?

[kthreadd]

That's true, although I would suggest that you also don't improperly shut down your laptop. :-)

Re:Is this still a good OS for desktop?

[Eric Smith]

XFS is prone to data corruption when improperly shut down.

Really? Ugh. I thought most modern file systems were consciously designed to avoid that sort of problem.

Re:Is this still a good OS for desktop?

[armanox]

Being a laptop leaves it vulnerable to dieing batteries in my experience.

Re:Is this still a good OS for desktop?

[armanox]

I'd hardly consider XFS modern. SGI introduced it on IRIX 5 back in the mid 90's.

Re:Is this still a good OS for desktop?

[arth1]

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.

Re:Is this still a good OS for desktop?

[raxx7]

Not any more than ext4.

ext3 was an odd ball. It defaulted to a behavior where creating a file, writing into it and then renaming over into another file would _guarantee_ that after a crash you'd either get the old file or the new file.
XFS (and AFAIK all the other Linux journaled file systems) implemented did not provide such guarantees unless the application used an fsync/fdatasync before the rename.

However, since a) ext3 was popular and b) fsync could be pathologically slow on ext3, many applications became reliant on ext3's behaviour.
The net result was that, for other filesystems, after a crash users would be faced with files full of zeros.
It became a widespread problem when ext4 became the default, as it used much of the same policy of XFS. http://lwn.net/Articles/322823/

Meanwhile, this has mostly been fixed.
Partially, because ext4's widespread usage, applications began to use fsync properly again.
Partially, XFS and ext4 developers patched the filesystem to, under some circumstances, emulate ext3's behavior.

Re:Is this still a good OS for desktop?

[ancientt]

Seconded. Do NOT just go with defaults. XFS is really good for serving large files like video, but when I last used it regularly, it wasn't very nice after a power loss. That isn't to say it got corrupted like resiserfs or anything, but the self check and correction process was tedious. Ext4 is pretty fast, has the journaling you'd expect and has been tested pretty well now. Btrfs looks cool, and seems to work well, but I don't know that I'm ready to trust it yet. ZFS is nice too, but I don't think it's native yet (is it?) so I wouldn't want to put it on anything I couldn't do without for a few days.

Re:Is this still a good OS for desktop?

[kthreadd]

I have this problem more frequently with desktops and servers during power outages.

Re:Is this still a good OS for desktop?

[Anonymous Coward]

Oh, please, if I wanted to suck 2 Gig of RAM down the gobbling, slurpy, open sore festooned throat of Gnome, I'd pay it $20 and wear some protection.

There are plenty of much, much lighter weight X window managers available. I'm personally fond of "vtwm", which is franly older than the "ooohhh shiny!!!" developers over at Gnome and is extremely stable and lightweight. Just the thing for an underpowered laptop or VM.

Re:People still use Red Hat?

[Anonymous Coward]

WTF? And who are you again? i have yet to see a f*ckin arch box in any mission critical environment ffs

registryd

[Nikademus]

Will registryd be part of systemd soon? I can't wait having some centralized binary configuration only readable by systemd utilities.

Re:registryd

[CaptnZilog]

Will registryd be part of systemd soon? I can't wait having some centralized binary configuration only readable by systemd utilities.

They're still working on a GUI version of RegeditSysdLinux so people that shouldn't be anywhere *near* sysadmin can get in and break things easily.

Re:registryd

[fnj]

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 amongst all the millions of other files for multitudes of other purposes, all mixed together in a single hierarchy based on filename. You would need highly portable tools for rescue and repair, but that is eminently addressable.

Re:registryd

[Anonymous Coward]

Would the coredumps then be stored in registryd or in systemd? Would I still need to get into root to get them for debugging? Oh, while doing these fabulous changes, would it be also possible to force the Gnome3 to the server installs, as MS did for its Metro UI and server versions of Windows?

Guess it depends on situation...

[Junta]

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 stepped around by design more and more over time, but it could be one portion of MS versus another.

Re:Guess it depends on situation...

[thule]

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?

Re:Guess it depends on situation...

[Junta]

I don't know if they ever required WMI. I think wmi is still supposed to be right, but some calls just go direct. I rarely dabble in windows world, but it was things like enumerating network devices and disks. Once upon a time, if the wmi provider was messed up, my stuff did not work. Now the wmi calls can hang and stuff does work. I might have also changed calls, I'm a bit vague in my recollection. I tended to review the MS documentation and change things around when it looked like the documentation was preferring an alternative strategy. Mind you, when the wmi calls do work, they were as accurate, just in my scenario WMI could hang completely. I am in a position to see wmi hang more often than I think most others are (i.e. before a device is actually shipped).

Which is mostly the nature of my complaint, that it takes extra development time and extra layers to enable something like WMI above and beyond assuring the functionality of the device and, for lack of a better word, 'native' instrumentation. It adds complexity and particularly a CIM broker that I have seen never be very resilient no matter who did it, which makes me suspect a broker has a harder job than I would guess it should.

Reverting to init

[hankypooh]

Can one revert to init, rather than using systemd?

Re:Reverting to init

[kthreadd]

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:Reverting to init

[Anonymous Coward]

Short answer? No.

Long answer? Some old applications that are not part of the base OS may still be portable to RHEL 7, but expect a serious forklift to systemd if you want to stay compatible with other RHEL based tools.

Re:People still use Red Hat?

[Anonymous Coward]

What medicine are you on and where can I get some? RHEL and Fedora aren't done until your computer won't run. They break things just for the sheer pleasure of breaking them.

Source RPMs

[Anonymous Coward]

Yes, since January, CentOS is part of RedHat.

Re: People still use Red Hat?

[Anonymous Coward]

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...

Re:People still use Red Hat?

[Anonymous Coward]

Debian (and Ubuntu)'s point releases are a completely different beast from Redhat's point releases. In Debian (and Ubuntu), a point release is essencially putting all the packages from the security repository in the main repo (Since 12.04, Ubuntu also releases backports for the kernel and graphics stack). Redhat's point releases ship new/backported software, as long as it doesn't break ABI compatibility (they also may deprecate/remove software if a better alternative exists, and has a relatively painless migration path). Should you be unable / unwilling to upgrade, you can keep running an older point release with full support for quite some time (~5 years from the release date IIRC).

Have they fixed AD auth (LDAP) yet?

[Anonymous Coward]

SSSD was horrible, single-threaded and slow. And buggy. Could not read ALL nested groups.
pam-ldap did work, but desperately needed nscd to be fast enough.
nslcd is a clunky hack and slow like hell.

SERIOUSLY, WHY?

Re:Have they fixed AD auth (LDAP) yet?

[PrimaryConsult]

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....

Re:Have they fixed AD auth (LDAP) yet?

[Anonymous Coward]

I tried SSSD, but couldn't get it to display the password change warning from the Sun DS server we had, so I moved back to pam_ldap, which worked properly.

Systemd is a non-solution to a non-problem.

[Anonymous Coward]

In the real world of making widgets for money, there's nothing that systemd does that's actually necessary.

SysV init is vastly more elegant and configuration is simpler and more robust. You can do anything you need to do with SysV init, except in contrived cases, and extreme edge cases.

I have been in the computer industry for 40 years, and have been a sysadmin for more than 30. I know hundreds of gainfully employed computer professionals. None of them have any use for systemd.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Comment removed

[account_deleted]

Comment removed based on user account deletion

Comment removed

[account_deleted]

Comment removed based on user account deletion

Comment removed

[account_deleted]

Comment removed based on user account deletion

Tried the RC

[Anonymous Coward]

I tried the RHEL 7 release candidate and it was really rough, rough enough that there is no way I will be using RHEL 7 in prodction. The new installer is buggy and slow, systemd is a heavy mess, the package management is slow and feels dated (even by RHEL standards). Usually I'm a fan of Red Hat and their releases, I was pretty hapyp with RHEL 6, but this release feels like a lot of little steps backward that add up to one big mess.

Re:Tried the RC

[Anonymous Coward]

Considering the bug in early releases of RHEL 6 that would cause the system to crash after so may days of uptime, I think you made the right choice. Give it until 7.2 or so to shake the worst of the bugs out.

Of course, I'll be installing it on a test system tomorrow, because I'll be expected to tell everyone else on my team how to work with it by the end of the week.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Systemd?

[Anonymous Coward]

NOOOOOooooooooooooooooooooo...

wowwww

[Anonymous Coward]

And i'm worried about the bluetooth support XD, Linux is beyond the daily use.

Re:People still use Red Hat?

[Anonymous Coward]

Admittedly, pacemaker (and thus crmsh and friends) have only ever been released on RHEL 6 as "technology previews" rather than stable and fully supported functionality.

Re:People still use Red Hat?

[Anonymous Coward]

Or just never upgrade the "redhat-release" RPM and tell the vendor you're still running 6.3.

RHEL is everywhere..

[enter to exit]

I don't think I've ever seen a large company use anything but RHEL..

Most smaller/mid-range orgs use CentOS or Debian/Ubuntu, maybe more Debian.
Those people comparing it to Arch Linux are cheerleaders/hobbyists.

Reverting to init

[Anonymous Coward]

Can one revert to init, rather than using systemd?

Init scripts are still supported. Even better: they still works.

Re:People still use Red Hat?

[segedunum]

So it's OK if they don't commit to supporting it? Fantastic.

Re:People still use Red Hat?

[segedunum]

For those who want to take control of their infrastructure then Gentoo works very well, especially if you find yourself compiling software without a package management system.

grats

[davethomask]

congratulations RedHat!

theguy

[Anonymous Coward]

Solaris is dead and buried. If you want to run it, you'll have to go to the cemetary and dig up its corpse by yourself.

The address of the cemetary is:
Oracle Corporation
500 Oracle Parkway
Redwood Shores, CA 94065

... and with systemd.

[Anonymous Coward]

That is typical with enterprise level servers. It's not like the desktop market. There are still companies running RHEL 5, probably some even older than that.

Thanks...

[Junta]

This is precisely the point I keep in mind but always forget to explicitly say...

Where open source has great strength is where people have had to scratch their own itches. Now as more and more people's livelihoods become 'developer supporting *other* people's needs that I don't actually live with day to day', a lot of stuff is evolving in an unfortunate direction. Additionally, when someone *lives* inside a problem too much they lose touch with the relative importance and the degree to which others deal with it and understand a complex way to avoid a nuisance.

kernel drivers shouldn't make assumptions

[Chirs]

For exactly the reason that you describe, a kernel driver that is intended to be built on many different kernel versions really shouldn't be making assumptions based on the version number, it should test for the actual desired functionality.

wasn't impressed with their driver

[Chirs]

The Mellanox driver code I saw was pretty messy, especially the SR-IOV support. And their device model is sort of weird for anyone used to "traditional" ethernet hardware. But they're really the only game in town for 40gig.

In contrast, the Intel 10gig drivers are reasonably clean, follow the same device model as their other ethernet hardware, and their datasheets are available for anyone to download.

Re:wasn't impressed with their driver

[Junta]

Perhaps, but from a 'we now support 40gb' statement, I don't see why that is accurate to distinguish 7.0 and 6.5 given that both included 40 gb drivers and all the reporting tools I knew already described 40 gb without issue...

Re:People still use Red Hat?

[armanox]

AIX and HP-UX still receive patches from IBM and HP, respectively. SGI only stopped releasing patches from IRIX in January this year (2014), for an OS that was initially released in 1998 (IRIX 6.5).