Slashdot Mirror

OpenSuse LEAP had SLES components rolled in on version 42.1, which was superseded by version 15.

LEAP has support for 36 months (major versions) and 18 months (minor releases). It's a different upgrade cycle then CentOS or RH. In RH, if you just pull from the repos, you will automatically roll from minor to minor release. This is not the case with OpenSuse. For example, 15.0 repos are distinct and separate from 15.1. In RH, both versions would be in the same repo and Yum finds the most current.

This gives you a bit more control, you have 6 months to upgrade between minor version as they are generally release every 12 months and supported for 18. You have to run a different command to upgrade the version zypper dup vs zypper up. In RH your version will increment without you noticing if your not paying attention.

IMHO, the biggest differentiator is the the Kernel Version.
RedHat's is pretty old, the newest kernel the ship is 3.10.0-957.
The SLE kernel (note the change from SLES 12 to SLE 15 - to track OpenSUSE better) is 4.12.14-23.1.

You have to go all the way back to 2014 to get a 3.12 kernel on SuSe.
I'm a big fan of SUSE, I use OpenSUSE at home and have managed some HPC systems that use SLES 11/12, but most systems I manage us RH at work.

Charge for support? Evil Microsoft!

The Open Source Initiative, contrary to some folks here on Slashdot, has expressed its purpose as the preservation of software freedom.

The OSI (for most of its existence) called the efforts of advocating for software freedom "ideological tub-thumping", hardly language I'd associate with preserving software freedom. Every now and then there's also some organization which calls itself an open source distributor that boasts of its association with a proprietor. Like the time Red Hat told us it was "partners" with Microsoft (Canonical did similarly with Microsoft) and did not frame the issue in terms of software freedom but "choice and flexibility" instead—apparently the flexibility to install a GNU/Linux on a Microsoft VM thus allowing the VM owner (Microsoft in this case) to know everything one is doing on that system. This is a position indistinguishable from granting considerable control to a proprietor over the possibly free GNU/Linux system. These are not the choices nor the language I'd expect from people choosing to frame what they're doing in terms that intend to remind people to learn about software freedom or request software freedom for their organizations so that their organizations can retain their own data and fully control what their organization does with their own computers. As the older "Why 'Free Software' is better than "Open Source" essay points out, "This manipulative practice would be no less harmful if it were done using the term 'free software.' But companies do not seem to use the term 'free software' that way; perhaps its association with idealism makes it seem unsuitable. The term 'open source' opened the door for this."

What I see is not precisely the same but much more in keeping with what is described in a GNU Project essay in the section "Different Values Can Lead to Similar Conclusions...but Not Always":

Radical groups in the 1960s had a reputation for factionalism: some organizations split because of disagreements on details of strategy, and the two daughter groups treated each other as enemies despite having similar basic goals and values. The right wing made much of this and used it to criticize the entire left.

Some try to disparage the free software movement by comparing our disagreement with open source to the disagreements of those radical groups. They have it backwards. We disagree with the open source camp on the basic goals and values, but their views and ours lead in many cases to the same practical behavior—such as developing free software.

As a result, people from the free software movement and the open source camp often work together on practical projects such as software development. It is remarkable that such different philosophical views can so often motivate different people to participate in the same projects. Nonetheless, there are situations where these fundamentally different views lead to very different actions.

The idea of open source is that allowing users to change and redistribute the software will make it more powerful and reliable. But this is not guaranteed. Developers of proprietary software are not necessarily incompetent. Sometimes they produce a program that is powerful and reliable, even though it does not respect the users' freedom. Free software activists and open source enthusiasts will react very differently to that.

A pure open source enthusiast, one that is not at all influenced by the ideals of free software, will say, "I am surprised you were able to make the program work so well without using our development model, but you did. How can I get a copy?" This attitude will reward schemes that take away our freedom, leading to its loss.

The free software activist will say, "You

Indeed Microsoft *was* forced to provide security updates for Windows 7 when nobody wanted to downgrade from Windows 7 to Windows 8 or 10.

If you do go to Windows 10, MMicrosoft says your new OS will be supported for 18 months.
https://support.microsoft.com/...

Redhat provides security updates directly from them for at least 10 years.
https://access.redhat.com/arti...
After 10 years, updates would be from upstream.
One could back port Linux security patches for 20 years if you needed to. Ten years from Red Hat is probably enough.

You realize that since version 3, OpenShift is a distribution of Kubernetes under the hood, right? Here is the CVE for OpenShift for the k8s vulnerability from today

Red Hat disagrees with you.

Depends on how you look at it. Red Hat's subscription is to get support with an SLA, 10-year product lifecycles with assistance for migrations to new versions if needed, checkbox-compliance for industries that have compliance requirements, and explicit hardware testing and certification. Sure, Red Hat does this through paywalling their OS and letting Cent and Fedora handle folks who want to roll the dice, but it's not like Red Hat is only providing the functional equivalent of getting a new version of Windows Server as an ISO download every release and that's the end of it, or an OS that requires a metric ton of neutering to prevent inconvenient downtime in order to prevent the addition of otherwise-undesired functionality.

Beat me to it:

CVE-2016-5195
CVE-2013-2094

Seriously, this has nothing to do with "Linux is more secure than Windows". If you're running this old ass code in the wild, you sort of deserve it at this point.

Red Hat disagrees with you.

If you have to use WIndows upgrade to pro under "This PC" and enable Hyper-V. It supports Linux and even FreeBSD at the kernel level without guest tools automatically.

Uh, no. Integration components is MS's term for guest tools and are automatically installed. Linux has its own tools which MS went out of its way to make sure were compatible with Hyper-V. Linux also has native support for its own para-virtualized devices, its term for guest tools, so it supports KVM "natively" since many, many years ago. For Windows, you install guest drivers. In short, you don't get out of using host to guest drivers.

Both KMS and Hyper-V are type-1 hypervisors unlike the shitty VmWare Workstation and virtualbox. No guest tools and run bare metal near native speeds.

Unless you want to be able to use a Windows VM on Windows, move it to Linux, then move it back again. The only reasonable way to get near native speed without guest tools is to do hardware pass-through, and that's generally not worth it for anything but graphics cards and possible network cards. Seriously, argue at least something sensible like standardizing on guest tools across KVM, Hyper-V, VMware, and Virtualbox to make it all pretty moot. Don't spout bullshit.

Just to clarify and quantify... what exactly does Red Hat contribute to?... here's their list: https://community.redhat.com/s... Not only do they contribute by funding development here and there, they have created many projects themselves and sustained them until they successfully made them into an upstream community. I'm not sure where to find that list but it is a subset of the above link. Any of the upstream project web sites that have a "Powered by Red Hat" type logio in the top right is a good indicator. Red Hat over the years also purchased / acquired a few handful of companies... and if those companies already had open source products, they remained open source... and if those companies had some proprietary products, in most all (if not all) cases, even though it took quite a bit of work... over time those proprietary products were opened up... and upstream projects were created for them. Red Hat Directory Server used to be Netscape's proprietary product but is now upstreamed as 389. Quranet's SolidIce management system was all Windows server/technology-based and although it took a couple of years to completely re-write it in Java... it became RHEV and later RHV... and upstreamed as oVirt. The list goes on and on. Then there are the big Enterprise class products Red Hat started from scratch and then over multiple releases adapted to use other's technologies where appropriate (they aren't afraid of not-invented here) like with OpenShift. At first they had their own container like entity that was called a "gear" and mostly namespaces, cgroups and SELinux policies strung together. Then they adopted Docker... and later Kubernetes. When they found issues with the development model of Docker Inc, they started developing completely open alternatives like podman, buildah, skopeo, etc. In any event, their story has always been combined with Free and Open Source software and believing in it. They did have one challenge when they made their own Red Hat Network backend based on Oracle DB... but that was fixed over time and eventually completely open sourced for use with other databases... and even forked to be used as a commercial product by SUSE. And then there was the whole Oracle Enterprise Linux fork of RHEL... and CentOS... (in no specific order)... and their eventual sponsoring of CentOS. And of course, don't forget Fedora. It took them a while to get to Fedora but they did. BTW, a commenter's mention of systemd... Red Hat did not originally agree with the idea of starting systemd... but Lennart P. continued developing it on his own time... and got it into Fedora and it proved itself... and was eventually adopted by RHEL... but it was never a given. Some people think systemd is a cancer others really appreciate the wide range of features it enabled (welcome modern world!)... and still others seek to emulate it on other OSes. One thing is for sure, systemd makes sysadmin easier to teach, learn and do across all of the distros that have adopted it. I'm sure there are many developers who have gotten paid by various companies to write both proprietary as well as open source applications on top of RHEL... and to sysadmin RHEL... and to devops it... and to support it... as an alternative to Red Hat's paid support. It has created all kinds of opportunities outside of RHEL and their various other products. As previously mentioned a whole lot of that work has made its way into the greater Linux and FOSS ecosystems and is enjoyed by pretty the vast majority of Linux users everywhere.

requires the availability of the Red Hat repositories which they aren't obliged to make public to non-customers

...and this is why Richard Stallman Calls Open Source Movement 'Amoral'. But RH must make the source publicly available under the GPL.

RH/Centos do offer software collections with more modern versions[ if they want it.

Lots of enterprises rely on RHEL 7 / CentOS 7, and those are currently shipping PHP 5.4.16.

And if you stay up to date, they are patched (but frequently lacking newer features), at least for RHEL. The Package Versions - Why our package versions are (almost) never bumped up?.

IBM says they've vulnerable to Meltdown. And, hmmm, adding this item from them it's much worse than the one new microarchitecture ARM discovered was vulnerable to a Meltdown variant, looks like POWER 7+, 8, and 9 processors, can't confirm if 7 is affected, but this is clearly pretty much all of their currently supported CPUs. The first item also implies problems, without mentioning Meltdown specifically, with POWER 4 through 6 CPUs. Ah, and following a link in that first one, per RedHat z/Architecture CPUs are also vulnerable to one or both.

I'm not sure the problem occurred in the IBM 1960's design, for I don't know if it included speculative execution as well as out-of-order execution, in those days IBM built its computers with discrete silicon transistors, 1 or a very few of them along with resistors and maybe capacitors on a single module. Played well to their manufacturing strengths when true single die silicon integrated circuits were just too new, and no one could make them in the volumes IBM needed. So gates were very expensive, and they might have satisfied themselves with just out-of-order execution. Especially since this was just for the FPU.

By the time of the Pentium Pro in 1995, gates were a lot cheaper, so adding speculative execution when you already had all those anonymous registers, and doing it for your integer instructions wouldn't have been hardly as expensive. Or as complicated or gate intensive, since you could afford to use microcode, the top 2 IBM System/360 CPUs didn't, and fared less well in the marketplace because they couldn't emulate earlier IBM CPUs using some additional microcoded instructions.

Redhat as well.

And it's usually a mistake to accept the claims of a random shill without verifying. What does "if you want to do it yourself" mean? The $299 is for "developer workstation" including "incident reports" (means access to Redhat's bugzilla?) not a "workstation license". In fact, Redhat doesn't sell a "license", they sell a "workstation" for $49. Presumably you pay for Redhat putting it onto a disk because "license" is a loaded term, sounding too much like additional restrictions.

Redhat store

Redhat is in the bottled water business... what they sell is free, you pay for getting it conveniently in a bottle with somebody at least minimally attesting as to its quality. Funny business that, selling free stuff for money, but it works. You pay for it if you want to. If you don't want to pay, download the exact same thing from Centos, also run by Redhat. I don't begrudge Redhat their business model at all. Compared to Microsoft, there is no such thing as being sued by Redhat for a license violation, that is, unless you go full evil on GPL license violations, that's another thing.

Let's be real here: if you're paying someone a lot of money, you're going to get a lot of support. If you pay someone a little bit of money, you'll get a little bit of support. Government wants support.

Take Red Hat: they're not very expensive support wise, ergo, good luck getting any feature requests or what they deem "minor" bugs fixed. Not to mention, enjoy re-learning how to troubleshoot every major version (systemd). Let's look at a huge customer: DoD. Oh look, it can take years to get things fixed for them, mind that you need to pay for access to a bulletin stating a product doesn't support a feature..

Now let's take Microsoft: they'll bend over backwards to keep government agencies onboard. Sure, they'll own you in licensing, but you'll own them in obtaining support that doesn't suck (except for their technet documentation of course), and you also tend to get a lot of things thrown in with Software Assurance (e.g. in-person training).

Let's be real here: if you're paying someone a lot of money, you're going to get a lot of support. If you pay someone a little bit of money, you'll get a little bit of support. Government wants support.

Take Red Hat: they're not very expensive support wise, ergo, good luck getting any feature requests or what they deem "minor" bugs fixed. Not to mention, enjoy re-learning how to troubleshoot every major version (systemd). Let's look at a huge customer: DoD. Oh look, it can take years to get things fixed for them, mind that you need to pay for access to a bulletin stating a product doesn't support a feature..

Now let's take Microsoft: they'll bend over backwards to keep government agencies onboard. Sure, they'll own you in licensing, but you'll own them in obtaining support that doesn't suck (except for their technet documentation of course), and you also tend to get a lot of things thrown in with Software Assurance (e.g. in-person training).

... Linux is also taking over the world of IoT.

I don't think that there has ever been another operating system that has been used across such a wide range of systems with such a range of scales.

Red Hat Enterprise is tough on the wallet:

https://www.redhat.com/en/stor...

That could be a candidate for piracy...

Not that I would bother with such a thing.

I thought it was explained on /. before (there was a really informative post one time) that linux doesn't really ask you to reboot after non-kernel upgrades was simply because there's no mechanism to know and do this. This was a big reason for many servers getting patched for shellshock and other related bugs around that time still being vulnerable because of some sort of library/dependency type thing that kept the existing files running until reboot. Were those special cases? I think one of the openssl patches. This page refers to exported bash stuff, but other similar use cases likely exist. https://access.redhat.com/arti...

• List of things created by LP & KS
• PulseAudio/PolypAudio - Linux sound - to replace ALSA or OSS 4.0 - complete, took about 4 years to finish
• Avahi - Linux ZeroConf - complete (abandoned?)
• systemd - Linux init system - to replace Upstart, initd, and openrc - WIP
• journald - Linux logging system - replaces syslog-ng and rsyslog. Replaces text logs with new, improved binary format - WIP
• logind - Linux user authentication - replaced ConsoleKit because it was unmaintained - WIP
• networkd - Linux networking - replaces isc-dhcp-server, dhclient, dhcpcd, ifconfig, etc... because the previous code was too slow or unmaintained
• tempfiles - Linux temp file cleanup (this was needed?)
• timedated - Linux time & date functionality, including network time - because the code was 'old'
• udev - Linux device support. At one time a useful, standalone project, this as been absorbed into systemd. Cannot work without it.
• gummiboot/systemd-boot - Linux bootstrap support. Gummiboot will (eventually) replace Grub2/LILO/eLILO/PLoP and other boot managers. Supports secure boot (assuming kernel is signed with the appropriate key), and booting to encrypted LVM2 file systems
• nspawn - Linux chroot support. Replaces chroot - because it was insecure; perhaps idea taken from BSD jail
• machinectl - Linux user masquerading / privilege escalation utility - replaces su because "'su' is a broken concept". Perhaps he hadn't heard of sudo, then?
• systemd-firewall - Linux Firewall - to replace iptables, ufw, firewalld, etc...

In my experience, LP and KS are great at getting code out the door. Revisiting code to fix bugs - less so. I'm not the only person that thinks like this. Even if your log files are getting filled up with Avahi warning messages about IP address blah sent an invalid request Y, ignored' messages. Which, of course, is fixed in the next version, instead of patched in the current version. Therefore, this patch was not backported to CentOS 6.

Aiming for +5 funny I see. It's a kernel module called VDO: https://rhelblog.redhat.com/20...

It looks like they have a 3.10.0-862 kernel and a 4.14.0-49 kernel-alt.

https://access.redhat.com/docu...

Release announcement.

Or like being incapable of running GUI apps as root - which breaks among others gparted, and won't ever be fixed for native Wayland apps, but you need to "think of the children" - https://bugzilla.redhat.com/sh...

The did not "stop distributing the microcode", they "rolled back to the last known stable release".

What CPU microcode is available via the microcode_ctl package to mitigate CVE-2017-5715 (variant 2)?

The latest microcode_ctl and linux-firmware packages from Red Hat do not include resolutions to the CVE-2017-5715 (variant 2) exploit. Red Hat is no longer providing microcode to address Spectre, variant 2, due to instabilities introduced that are causing customer systems to not boot. The latest microcode_ctl and linux-firmware packages are reverting these unstable microprocessor firmware changes to versions that were known to be stable and well tested, released prior to the Spectre/Meltdown embargo lift date on Jan 3rd. Customers are advised to contact their silicon vendor to get the latest microcode for their particular processor.

"[T]he reason most software remains locked up within the four walls of enterprise firewalls is that it's too costly with too small of an ROI to justify open-sourcing it."

Talk about damning with faint praise. A novel interpretation and the first I've ever heard of this analysis. The worlds top supercomputers all run on a variant of Linux and the makers still manage to make a profit. If I was paranoid I would suspect Matt Asay was put up to join the Open Source Initiative and subvert it from the inside.

Linux totally dominates supercomputers

Red Hat on the NYSE

78 percent of companies run open-source software

On Red Hat they can be disabled by kernel command line switches: noibrs, noibpb, and nopti. REF: https://access.redhat.com/arti...

I believe there are similar kernel command line switches for a lot of other distros though you'll have to Google them yourself.

They aren't:

https://access.redhat.com/secu...

Yes ;)

https://access.redhat.com/secu...

Uh...there are quite a lot of official documentation repositories you can look at, including this very good one,
https://wiki.archlinux.org/ind...

And this one,
https://access.redhat.com/docu...

Oh, look! In the cleverly disguised "Migration Planning Guide", there is a section titled "2.2.5. Changed mount behavior at boot". And sure enough, it describes exactly the changed fstab behavior the GP experienced.

I set my root account to /bin/false

That's always been a problem IMHO with any vendor pre-installed bullshit of any kind. Most of this turn-key OEM-installed bullshit isn't for the most of the crowd here, it's for the people who want that computer to 'just work' out of the box, and pre-installed with not-even-free versions of software packages anymore. This is such a non-story to me personally because over the last 20 year I've been into the tech/IT/computing realm of things, there's just way too many instances of this to cite of this going on at the big player level. It's here, and here for the 30 seconds of googling it too to refresh my memory.

I saw a lot of banter about installing Linux on this or that or 'Linux solves this issue' --- no it doesn't. I've ran Linux + X-windows + gnome/evolution/xfce window manager mixes since late 1990's on all my laptops and desktops to now in 2017; that's a preference. And the way Linux installs have become super mega friendly, tell me if you're in any worse a boat knowing every waking package you got installed on there? A great example is goa-daemon in Gnome Window Manager builds the last two years on most distros --- fuck that package. May not be spyware, but with all it's seemingly conspiracy-driven build-deps around it, I mind as well be trying to remove spyware.

My long winded point is: Please have that nephew, niece or some half savvy ass person in your life just put in a fresh install of Windows on that pre-bundled piece of OEM shit HP/Dell/Lenovo and anyone else in that space calling an 'Windows OS deployment'. I don't trust that shit and no one else should.

Active Directory

Red hat Directory Server

Group Policy/Centralized Software Management

You have to be kidding me. Are you familiar with software repositories? Windows is still 20 years behind Linux. We deploy using SCCM and it's a joke compared to the simplicity of RPM and yum/dnf.

CIFS/Windows File Sharing

SAMBA has been supported on Linux for ... jesus I don't even know how long now.

Terminal Services, BitLocker, AppLocker

Not sure why these three are lumped together. There's a dozen encryption options for Linux, for free by the way, not only in some "Ultimate/Pro" edition. Take your pick. Terminal services? VNC, Spice, etc, etc.

Tight integration between various components

Now you're just babbling.

Ability to run your OS for years without reinstallation while retaining the ability to install new software

Do you think you can't upgrade Linux? You understand Windows 10 is just copying rolling-release distributions that have existed for years, like Arch, right?

Ability to open Microsoft Office documents in their original formatting

You can run Office Web Apps or Google Docs using pretty much any browser on Linux.

Excellent compatibility with most modern hardware

Check.

What else you got?

Cray supercomputers run CrayLinux.

Others... Red Hat has a presence.

As you may know, RedHat has deprecated BTRFS in RHEL7.4 whereas many distributions like Ubuntu fully support ZFS.

I woud say that the status of BTRFS is worse than that of OpenZFS on Linux. See also here for an interesting article.

Redhat had it covered first. Debian now has it patched. I would imagine that MS Server, Win7 and Win10 might not be too far behind considering that the real danger of this exploit is access to corporate networks that use bluetooth devices. Fortunately most thin clients do not have bluetooth built in otherwise this could become another update nightmare for MS admins. Either way I don't think this will effect the Microsoft servers users too much. What I do foresee is a rapid removal of bluetooth mice and a server side disabling of the usb bluetooth stack happening in major business until Microsoft patches the windows bluetooth stack.

Review Redhat's annual report. They trail not only their peer group, but the S&P 500. And they turn about 10% net profit. Better than grocery stores, laughable for a tech company.

Does Windows count as a rootkit?

That "is Windows a virus"? joke has been around since the 90s.

Yes, a classy response to the issue, unlike the humourless maintainer who removed the ddate (Discordian Date) tool from util-linux: https://bugzilla.redhat.com/sh...

Eh? (checks.....)
WTF man?, no ddate? ok, so the last time I used it in anger was in a server added header on the MTAs I used to look after many, many years ago...
them: we got spam from your servers..
me: No worries, got an example in front of you?, good, tell me the contents of the X-MTA-FNORD header...
them:(typie typity type....)Errr, what X-MTA-FNORD header?
me: there's your problem, not my circus, monkeys etc. etc..

Really, again, WTF?, you know I'm now in the crazy position that the only machines that have ddate on them here in my house are the windows boxes and not one of my Linux boxes has it now by default?

Time to dig out the sources...fucking Greyfaces...GOBBLE, GOBBLE, GOBBLE, GOBBLE, GOBBLE!

To be fair, Nottingham also wrote the draft that's now reserving the error code.

He recognized there was popular support for the error code, and revised his position to remove the error code only if every other three-digit error code starting with 4 is taken.

Yes, a classy response to the issue, unlike the humourless maintainer who removed the ddate (Discordian Date) tool from util-linux: https://bugzilla.redhat.com/sh...

I don't believe you because you are wrong, and you actually just proved my point. You don't seem to understand that the $349 doesn't buy the software, it gives access to their tools and copyrighted errata, documentation, etc. If you can't understand this, stop misinforming people and wasting people's time trying to disprove the simple logic that you can't sell someone rights they already have.

Still does not prevent you from charging for the prebuilt binaries. Yes you have all the right in the world to download the sources of my derivative works if they are published somewhere (note that if none of my customers have decided to utilize their rights under the GPL then you have no sources to download!), but that fact does not prevent me from selling you prebuilt binaries of said sources.

It might sound strange that people would pay for something that they can get for free, but that is besides the point since you are falsely believing that this is somehow illegal under the GPL when it's not.

If you still don't believe my the go right ahead and create a class action lawsuit against Red Hat because they do exactly this, here: https://www.redhat.com/en/stor... you can buy a copy of Red Hat Enterprise Linux for $349 completely without their support (it's a "self-support" version).

https://www.redhat.com/en/abou... says "Red Hat plans to open source Permabit's technology." This may mean that Red Hat's https://www.redhat.com/en/abou... Patent Promise will apply. Possibly Red Hat will announce whether they will hold all of the patents on the Permabit technology, or whether any third-party patents remain relevant.

https://www.redhat.com/en/abou... says "Red Hat plans to open source Permabit's technology." This may mean that Red Hat's https://www.redhat.com/en/abou... Patent Promise will apply. Possibly Red Hat will announce whether they will hold all of the patents on the Permabit technology, or whether any third-party patents remain relevant.

Network interface naming has nothing to do with systemd. Reason why your ethernet adapter was suddently named as enp0s19 is because of this: "udev supports a number of different naming schemes. The default is to assign fixed names based on firmware, topology, and location information. This has the advantage that the names are fully automatic, fully predictable, that they stay fixed even if hardware is added or removed".

https://access.redhat.com/docu...

No, it actually is trash.

gnome doesn't end all processes in a login session, inducing the systemd-logind "let's kill EVERYTHING" patch in v230 that zaps background processes including detached screen. Here's an example report:
https://bugzilla.redhat.com/sh...

org.gnome.zeitgeist.* has a tendency to error all over the place causing other apps to do the same.

A quick google search for `gnome-shell crash 2017` gives something like 180k-190k results. This is probably the most irritating problem.

Why do I still use it? Tfiik, masochism I guess. The other users are used to gnome and user workflow fragmentation is bad.

Lots of free, high quality coursework can be found here:

Cisco Networking Academy

Redhat Academy

There are many more. You just have to look.

https://access.redhat.com/secu...

It is interesting to me that this issue did not affect the version of systemd as shipped with RHEL 7. Does this not seem rather suspicious?