Slashdot Mirror

Sifting through the CVE and the write-up:

The kernel places an unmappable guard page just below the process's maximum-alloted stack space. Normally a process gets allocated only as much stack space as it needs. When the process's stack usage grows, the kernel maps additional pages to grow the process's stack space, but will not grow it beyond the maximum alloted stack size. If the process enters an infinite recursion loop, it'll hit the end of the alloted stack space, and the unmappable guard page segfaults the process out of its misery.

The problem appears to be if the process's heap is right next to the stack, with only the guard page separating it from the stack, and a single function call creates a stack frame that exceeds the size of the guard page. This effectively places the stack pointer into the heap. The function call thinks it has allocated its usual, large stack frame, but the stack pointer is in the heap.

At this point, usual code execution will typically make further use of the stack, so it ends up crapping all over the heap.

That's not good, of course. But I would expect the process in question to attempt to access its alleged stack frame before much happens. At this point the process will try to access the guard page, and gets segfaulted. That, at least, is my understanding of the vulnerability.

The overall design involving a guard page to limit the size of the process's stack is a traditional OS design, which is why the general approach affects both Linux and BSDs, here.

For this to be remotely exploitable, the attacker has to arrange for a process to execute a function call that creates a large stack frame so that the stack pointer jumps over the guard page. I would expect common, battle-tested free software that powers the intertubes to be well designed and written by experienced greybeards who fully understand how an operating system works, and the fact that the stack is not an endless resource, that it is quite a limited resource actually; with the resulting code minimizing automatically-scoped object usage on the stack, which should eliminate the vulnerability completely.

I find Red Hat's write-up somewhat puzzling. They appeared to have taken the tack of addressing the exploit by increasing the size of the guard area to a megabyte, rather than a single page.

That seems to be somewhat inadequate to me, in the brave-new 64-bit world of ours. It seems to me that the permanent fix would be to map the stack into virtual address space that's a terabyte, or two, away from the heap and everything else. Seems to be a no-brainer solution to me, dunno why they didn't do it.

Red Hat sent out a notification on Monday. Nice to see the Slashdot editors catching up on the news this weekend.

https://access.redhat.com/security/cve/cve-2017-1000364

Those that left SELinux enforcing are probably just fine (RedHat 7 CVE-2017-7494.) I've had my battles with SELinux, but I've left it enforcing. So often when I have an issue and find a solution on the Internet, step 1 is "disable SELinux". Yes, it can be a pain, but you really don't want to do that. Skip step 1.

(Replying to myself.) I've remembered that SELinux has a lot of power for application sandboxing (if not granular permissions), so Linux is half way there. I'm reading about it now.

It's too bad no one invented such a thing decades ago because by now we would have something that worked out of the box on Windows and Linux

When we forget our history, we forget ourselves. Before Red Hat hat took it over in hamhanded fashion, there was a community project called fedora.us, the real Fedora project, as compared to Red Hat's fake community project, which is actually Red Hat's fake community project, renamed. Now the real original project is so buried under Red Hat sediment that people like you post revisionism to public forums, blithely unaware of what really happened. But such hings leave tracks on the internet

Have you tried googling?

There is quite a comprehensive documentation available from Redhat: https://access.redhat.com/docu...

Also, Archlinux has always good wiki articles, and systemd one is here: https://wiki.archlinux.org/ind...

One good introduction is on Linux.com: https://www.linux.com/learn/un...

No, he's probably talking about 'Classic Mode', which is an alternative interface provided by gnome-shell that looks more like a Win98 / GNOME 2-style desktop. It exists more or less entirely because some Red Hat desktop customers (yes, we have some!) wanted to update to RHEL 7 but wanted a more 'classic' desktop UI.

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

I believe that's it. I'm away from my Linux machine at the moment and can't look it up. More than one distribution supports it, but not all.

No, he's probably talking about 'Classic Mode', which is an alternative interface provided by gnome-shell that looks more like a Win98 / GNOME 2-style desktop. It exists more or less entirely because some Red Hat desktop customers (yes, we have some!) wanted to update to RHEL 7 but wanted a more 'classic' desktop UI.

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

"I've yet to see a linux distribution supported for even 7 years, let alone the 10 minimum guaranteed by MS."

You haven't heard of Red Hat, or CentOS?

RHEL5 reached end of standard support yesterday, after just over 10 years. Extended support is available for anothwr 2.5 years:
https://access.redhat.com/supp...

CentOS 5/6/7 have the same lifecycle:
https://linuxlifecycle.com/

  https://wiki.centos.org/About/...

  "Windows can guarantee you a decade of security updates for a platform. I have to get it the edge here."

Only because you seem uninformed or too lazy to do any research.

"Additionally, if you're hosting yourself, and you run VMs, once you've licensed data center edition on the basic hardware, you can spin up as many Windows VMs on that hardware as you need at no extra cost."

Red Hat has similar options, and subscriptions on their RHEV+unlimited supported VMs gives you the same capabilities as VMWare vSphere Enterprise for less than just the vSphere licensing/SnS (so you basically get unlimitrd supported VMs for free).

I didn't compare to HyperV because MS was anal enough about licensing a Windows VM for the vCenter server (must pay per CPU-month for every CPU that could potentially run the VM) that we migrated as soon as possible to the vCenter Server Appliance because we spent almost as much licensing one Windows VM as on vSphere for a 6-machine vSphere cluster.

Of course, if you don't need support, you can run ovirt (community version of RHEV) on CentOS (or Debian) with unlimited CentOS (or Ubuntu or Debian) VMs, for no software cost. Or there are other options for containet-based clusters.

Note also that the study supporting the move back to WIndows was carried out by Accenture (some of us know them better by their old name, Andersen Consulting). Accenture was Microsoft's Alliance Partner of the Year in 2016, so I'm sure that they have a neutral, objective reason for recommending Microsoft software.

Yes, well, Accenture is also a Red Hat strategic partner, as well as partner of Google, Salesforce etc. Studies like these are not carried out by the same branch that specializes in a partner technology.

An alternative to conspiracy theories could be that the employees of Munich actually want to switch to another system with less problems with standard software and drivers. Maybe they want to be able to use fingerprint readers, ID/chip card printers etc. Or maybe maintaining your own distro (Limux) was not such a good idea.

See my subject & this link: No denying it /https://it.slashdot.org/comments.pl?sid=9995967&cid=53488785b [slashdot.org] & it's FAR from a complete list (even though it shows 100's of router security + inefficiency issues).

Your argument is so old and tired I get a /. 404 error, seriously I do. That said anyone who is using the factory provided firmware on a consumer router/firewall is dumb. OpenWRT or DDWRT are much better choices that offer better security and better options. Or if you prefer go and drop pfSense on some "powerful" but inexpensive hardware. As you will have a device like these between your computer and the internet I don't see how an argument about cost is an issue as you have your modem connected to the internet (DSL or Cable) and then either a router or firewall that your other gear sits behind. Depending on what hardware you have and layout your setup behind the router or firewall will vary greatly. * LMAO - again, that's you "networking menials" (that can't program their OWN solutions because you're limited) to a tee

Not a millennial (I assume that it what you meant) by a long shot I do actually program and have through my employer contributed to a number of open source projects. You may have heard of a few of them.

WRONG! I don't understand "layered-security"/"defense-in-depth"? I wrote guides on it that even GOT ME PAID https://www.google.com/search?... [google.com]

Guess what I have contributed to guides on securing systems and am paid by my employer to do so when new versions and updates are sought. The difference is that what I have contributed to are respected and well known.

Also it looks like you are a bit to copy/paste happy as I see you are getting frustrated and double posting (see above and below). You really should look into getting treatment for your ails as something does appear to be wrong.

(Disclaimer: I work for Red Hat on virtualization)

Red Hat and Fedora have a strict "upstream first" policy. We also have a large team working on KVM and qemu. A natural consequence of this is that we implement many features and fix many bugs in KVM/qemu, and these go upstream, and every other distribution benefits. This is great for open source. But I think your question is How is it good for Red Hat? since your implication is you can free ride on Red Hat's efforts.

There are three cases where you might benefit buying RHEL: Firstly if you call support with a serious bug, then eventually it'll get escalated likely to the person who actually wrote the original code. Secondly RHEL subscribers influence the future development direction (of course, the larger ones have a bit more influence). We really care about how our customers are using the tools. Third, you're probably not just using a single KVM host, you might want to try out OpenStack or oVirt, and we have systems architects who help customers with these larger deployments - the same architects who previously worked with large telco subscribers using OpenStack or huge bank deployments of oVirt, so they have loads of real world experience.

However if you're happy to free-ride, then us developers are happy too, because at the end of the day we really care about Free software.

Why has Red Hat spoken out against HB2? Don't you think our daughters deserve to be safe in their locker rooms from perverts? Does Red Hat condone penises in the ladies rooms of your corporate offices? Do you say "Merry Christmas", or do you say "Happy Holidays"? Jesus is watching, so answer carefully.

"I mean they offer cloud installs of RHEL, but few will be clicking that button.

2016 Red Hat Innovation Awards winners

I have been exploring, testing and thinking of fully transitioning to openSUSE. SUSE should not be overlooked. If by chance they are number two, then realize, that number two always tries harder, and responds more quickly when a response/action is required. They were first with the UEFI solution, for example.

"I mean they offer cloud installs of RHEL, but few will be clicking that button.

2016 Red Hat Innovation Awards winners

That's not exactly true ... that 's only if you specifically pay for the Extended Lifecycle Support subscription (which incidentally still supports RHEL4) ...

Red Hat Support Policy

Without that specific extra subscription RHEL5 goes EOL March 2017... and CentOS5 will get the last of its updates then as they don't get and rebuild the ELS packages.

No 3D is one of the reasons I use XFCE. :-) Besides that it probably would not work well as I have to use fb (FrameBuffer IIUC) driver as Intel driver does crash for me.

AIUI the arm based surface tablets (surface RT and surface 2) are locked down to the hilt with forced secure boot that will only boot windows

Not quite. They will only boot Microsoft-signed bootloaders. Such as Red Hat's shim which in turn launches GRUB or what have you.

CAPTCHA: shared

> But if you encrypt email with PGP/GnuPG

Stealing PGP keys is its own interesting security problem. It's quite intriguing how many people sill store them on unprotected media, especially on NFS shares without NFSv4 based Kerberized access, because "we trust the people we work with". Stealing them off of build servers for software packages is a particularly enlightening penetration test, or subverting the build servers themselves to publish false packages in a vendor's name.

The penetration of the RHEL and Fedora servers is a very good example of the risk, and of how a security aware vendor deals with it. It was quite interesting at t he time.

                        https://www.redhat.com/archive...

It's called the RedHat model. You give away Fedora and let the world beta test. Then you take the most stable bits and sell it at high price as the Enterprise version. Note how they (Microsoft) are taking out some Pro features and making them available only in Enterprise?

You obviously have no idea how Redhat works.

I suggest you go to Rehat's site and find out. At least they are quite open about their products and there are no hidden costs.

"In Red Hat Enterprise Linux 6, init from the sysvinit package has been replaced with Upstart, an event-based init system." https://access.redhat.com/docu...

Yep, you know, it's a thing. A business has got to make money, no problems. But smaller businesses that rely at least in part on the goodwill of their customers make exceptions on proper occasions. To make those exceptions, however, somebody with authority has to sign off on it. Finding someone with that kind of authority is easier in a small organization than a big one, let alone a huge one. And in a huge one, there is a magnified fear that any fuck-up, taking of responsibility, or bending of a rule will be used by some snot-nosed rival to take your job in the next restructuring... because the value of the deed is not easily measurable for being graphed in a PowerPoint chart.

But on the consumer-end, the same rules apply as for the small business. Make a fella feel good, he'll come back with a smile. McDonald's gets your order wrong, gave you a Big Mac instead of a Royale with Cheese, screw it... you can have the Big Mac for free. Turns out your date loves Big Macs. Well, hot damn! Next week at 3AM when you're out with your girl with the munchies, you'll remember this small act of kindness, swing by those golden arches.

So many Microsoft employees and shills want to dismiss it all as just a business. But like it or not, Microsoft is in the faces of everyone in the Western World and then some. Even the most avid FOSS-head has to bow to the Bill Gates empire every so often, when he takes money out of an XP-driven ATM or has to mount a FAT-formatted thumb-drive. And further like it or not, there just isn't a viable alternative, because having plural incompatible standards is a pain in the ass and, at least in the office (doctor's offices, law offices, banks, retail, media, government) nobody wants to step up. IBM used to have alternative products to Microsoft's Exchange and Office, they were called Notes and Symphony. For one reason or another, IBM threw in the towel and gave up, years ago. Apple seems to avoid the workplace altogether... I'm sure in Cupertino they got a BSD/Mac OS X paradise, but damn if they want to take responsibility for supporting it for anybody else. Linux? Does Red Hat offer products or support for anything outside the server room?

Yeah, there's Google Docs and it's online ilk, but businesses have to consider customer privacy and, oh, damn, the Internet's flaky again, somebody get on the phone and call Comcast (business-class internet... yeah right).

Microsoft has squished all its competition on the desktop (OS/2, Notes, 1-2-3, Word Perfect) until it really has no incentive to compete anymore. But the old Microsoft magic doesn't seem to be working with the Console, and mobile has been nothing short of a train-wreck.

All I'm sayin', it woudn't hurt if they were a little less dickish. Not holding my breath, but it would be nice. Cause if you work, you probably have to deal one way or another with Microsoft.

Most recent on slashdot was breaking the backgrounding of processes.

Which is disabled by a simple option in the config file. Which Debian has done, btw.

Yes, but I won't how long until this non-default config breaks something else. I don't trust them.

My product had our (once) portable init script broken in RHEL7.2 by a systemd change that now declares that the init.d script cannot be a symlink to the product installation area

Really? Are you sure? I just tried that and it works.

Yes. From https://bugzilla.redhat.com/sh...
"Note that the real location of the init script must be on the partition that is mounted in the initial ramdisk (initrd)"

https://www.debian.org/
https://devuan.org/
http://redhat.com/
http://www.ubuntu.com/
https://www.suse.com/
https://getfedora.org/

To list just a few...

MS is just making the choice more binary - either you choose to let them do anything they want with your computer, or you choose to let them do NOTHING.

THAT'S EXACTLY THE POINT. Need something /sbin/init didn't already do? Have it launch another, specialized service manager of your choosing. Have it launch several! Original inetd, xinetd, crond, supervise/daemontools, linux-ha / heartbeat, ... plenty of options. Have it integrate with other systems however you need it to. That's why you're an administrator.

The problem is that this results in race conditions and "who watches the watchdog" type of scenarios. Plus if the intermediate supervisor dies for some reason the children with then be reparented to PID1, ie the basic simple init, and the restarted supervisor would then lose sight of them properly (ie no longer a parent so can't wait() on them).

You're correct in that it can cause race conditions, but you're not giving sufficient weight to the fact that admins have heterogenous solutions for those. Who watches the watcher? Maybe a cron job. Maybe puppet. Maybe another service. Maybe monit or any other monitoring system you have. An administrator should look at their own likely failure states and automate accordingly.

How many times has xinetd crashed on you in the last 10 years? How often does daemontools or supervise crash on you? These types of servers are single-purpose designed and have well tested code. Small, simple, focused programs that do one thing and one thing well precisely to reduce the problems that can result. /sbin/init forking a shell and forking a small bit of C code (eg, svscan) with a monitor running via cron (and maybe a second monitor running persistently as a distinct service) is oodles more auditable, reliable, and understandable than a monoculture of systemd attempting to be responsible for everything.

Fedora can't even do that any more... Fedora IS the upstream and there's basically no one who can push back at the Fedora level for a dumb upstream systemd decision

Note quite. Fedora is not the upstream for systemd, systemd is its own upstream and frankly has been driven more by CoreOS needs than Fedora ones recently (with the whole resolved and networkd stuff which are not used in Fedora since we use NetworkManager). Check the number of patches in the F24 spec for instance. The discussion is ongoing at the moment and this will become a F25 change that gets debated by FESCO. It's likely that the Server and Workstation product, for instance, may split in their behaviours here given the different use cases.

Be fair. That entirely was the situation. It's a neat sophist trick, wearing the upstream hat and the downstream hat and claiming the other guy with the hat is tying your hands. (Not you personally, the collective "you".) https://bugzilla.redhat.com/show_bug.cgi?id=1170765#c58 The simple fact is that huge bits of what once had been Fedora-level policy is now more or less handled by "upstream" and there's continual pressure to not deviate from upstream. Anyone with any experience in any sort of team politics should be familiar with that.

systemd was and is a power grab, plain and simple

No it is an attempt to fix our broken init landscape (it's notable that no one wanted to keep sysvinit as the default in the Debian CTTE decision) and solved not only the sysvinit problems but the upstart ones as well.

Go back and look at any of the small decisions over time from Fedora 15 onward made to make it extremely inconvenient to use any other init system anywhere in the ecosystem.

Fedora is a well integrated distribution with

"PHP cURL module now supports TLS 1.1 and TLS 1.2" and "NSS now enables the TLS version 1.2 protocol by default"

(Yes, that's right, NSS, not OpenSSL.)
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/6.8_Release_Notes/new_features_security.html

I don't understand your emphasis on NSS.
FWIW, the version of openssl that shipped with CentOS 6.7 fully supported TLSv1.2. Their announcement that, "NSS now enables the TLS version 1.2 protocol by default", does not in any way imply that OpenSSL had not or did not do so. They happen to be building some items against NSS, thus that change affects things like pyCurl and phpCurl for them, though those could be rebuilt against OpenSSL (I rebuild php to get a more recent version, and link it to openssl instead of NSS).

Hosts have 3 weeks to roll it out:

"PHP cURL module now supports TLS 1.1 and TLS 1.2" and "NSS now enables the TLS version 1.2 protocol by default"

(Yes, that's right, NSS, not OpenSSL.)
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/6.8_Release_Notes/new_features_security.html

PayPal is upgrading the protocols used to secure all external connections made to our systems. Transport Layer Security version 1.2 (TLS 1.2) and Hypertext Transfer Protocol version 1.1 (HTTP/1.1) will become mandatory for communication with PayPal in 2017. You will need to verify that your environment supports TLS 1.2 and HTTP/1.1, and if necessary make appropriate updates.
DATE CHANGE - Act by June 30, 2017

https://www.paypal-knowledge.com/infocenter/index?page=content&id=FAQ1914

Oh wait, I see Paypal backed off on it, they have moved it ahead to June 30th 2017. Previously it was next month, June 17, 2016. Enough people must have complained. This change was going to break tens of thousands of eCommerce websites, if not more.

So hosts have more time now; a whole year. At least CentOS has addressed it now. I expect hosts are going to keep servers provisioned on 6.x on 6.x for as long as possible.

Quit and go work for a company that develops on Linux.

You're welcome

Now all the black hat hackers will reclassify themselves as red hats and blue hats.

Hopefully most will reach for blue hats. I wasted more than enough hours cleaning up the last red hat malware that targeted Linux machines.

The entire concept of open source is about flexibility but people think it's fine to blindly force one option down everyone's throats, regardless of what they want. It's surreal to watch. We have 9,000 distributions but only One True Init, apparently.

No it's not, never has been and never will be. Open source provides you the flexibility of choosing from a subset of system components and applications that a distribution provides and maintains for you. This has always been the case since the early days of Linux distributions. This is fundamentally the reason why we end up with different distributions and forks of distributions. It is also the reason why there's so many choices (not flexibility, there's a big difference between the two) out there.

This extends way back long before the idea of replacing the init system was even proposed. It was the reason why one distribution was better than another at certain things. You have choices provided by the maintainer and beyond that you're on your own. In some cases that means compiling from source and bypassing your package manager which is easy enough to do. For other things that means replacing such a fundamental component of the system that it is impossible to make it flexible enough that you can just tick a check box when you first install as to which one you want.

A Redhat developer said it a bit more technically than I did: https://www.redhat.com/archive... but ultimately I disagree with the words he used. Linux is about choice, but your choice is limited.

Also there's some 40 distributions out there that don't offer systemd. If that's not the init system for you then Fedora isn't the init system for you. You have a choice to use something else.

It is my understanding that it's been fixed in the latest version of imagemagick, the problem is that the distro maintainers haven't backported it yet. There is also a trivial mitigation technique: https://bugzilla.redhat.com/sh...

Fantastic article from Alexander Bokovoy on
how this thing was found and fixed !

http://rhelblog.redhat.com/201...

Just curious, did you *think* before you wrote that? Because redhat is definiately NOT bleeding edge or dropping support for anything while a major release is supported....

RHEL6 has entered the second phase of support, which means it won't get new software, and won't get updated software unless there are severe bugs or security fixes that can only be fixed with newer versions. Fair enough; I'd switch to RHEL7 for the machines where I need newer software. Except that Red Hat in RHEL7 has dropped support for a lot of packages that are still very much in use.

Red Hat can't make it any clearer than they have -- you must agree to the Developers Terms & Conditions to download or use the RHEL instance, and it is not for usage as a standard system -- development purposes only.

https://developers.redhat.com/... : (emphasis added)

" By participating in the Program and accepting these terms, you represent that you will be using the Red Hat Subscriptions(s) for development purposes only, and Red Hat is relying on your representation as a condition of our providing you access to the Subscription(s). If you use the Red Hat Subscriptions for any other purposes, you are in violation of Red Hat’s Enterprise Agreement set forth below and are required to pay the applicable subscription fees, in addition to any and all other remedies available to Red Hat under applicable law. Examples of such violations include, but are not limited to,

using the services provided under the Program for a production installation,

offering support services to third parties, or

complementing or supplementing third party support services with services received under the Program."

With the change to longer life cycles, the production phase ends on November 30, 2020 and the four-year extended support period goes to 2024.
https://access.redhat.com/supp...

You are correct that new hardware support will not be added as long as I indicated. However, GP specifically said security updates, and there are 8 more years of important security updates, including four years left in the ten-year "production" phase.

You would have to build binaries yourself and hope you get the settings for compilation "correct"

worth noting the binaries are NOT identical between redhat and centos and scientific linux

http://community.redhat.com/ce...

That seems to be a fairly misleading statement

Windows 7 isn't just a "Kernel", it's an Operating System. Ditto for FreeBSD 7. While the kernel may be the core of an OS, userland certainly plays a significant part as well, particular for a desktop OS. For example, on a Win7 64-bit machine, the actual kernel would probably be something like "6.1.7601.17592"

So comparing those three, it would be more fair to use something like a Linux distribution/version from that era, such as
* "Ubuntu Jaunty Jackelope" (EOL Oct 2010)
* "Debian Lenny" (Archived Feb 2011)
* RHEL6 (Production good until 2020, extended life-support not listed yet).

There was one many years ago. They probably realized that people just used the packaged PostgreSQL and there was no reason for a separate product

I do program a little bit but I am not a programmer - even though I have done a lot of programming in the past. While I was programming I was not really a very good programmer. Oh, it worked. Eventually. It even did much of what I wanted, in some fashion. I had someone with me at the start, he was a CS grad who did more "ops" than "dev." I just kind of asked him if he wanted to help so he doesn't really count for this metric. The first person I hired, after the business was running, was a programmer.

I programmed in C but I did some Perl, some BASIC, even some QBASIC at one point. Oh, I can bang out bad code in a handful of languages even today. I am not a programmer. I do not even have a passing familiarity with Java though, funny enough, I've been talking about learning it lately because I have a project at hand and it's more difficult than I thought it would be. I turns out, there are no handy dandy libraries for what I want to do in C. However, Java has a library for everything. Java has a library to optimize the efficiency of a sock gnome, complete with web interaction and remote hosting. And yes, you can bundle it into a .jar and have it work across all the major platforms...

At any rate, I mention that to basically tell you that I have no idea what you're talking about. So, I went to the all-knowing Google. The whole phrase as a search query was not refined enough. I took out the "Java" and it returned one result. That result might mean something - as it appeared to be sort of topical. It was a bug, on RedHat's bug-tracker about JBoss using too much memory.

https://bugzilla.redhat.com/sh...

I read it and I am still not entirely sure what is going on. It looks like they're setting some sort of Java setting via the terminal. At first blush, it looks like they're setting Java to use more than 128 GB. So, unless I'm missing something then I am lost. 'Cause I'm not exactly sure why you'd need to set Java to use that much RAM. I'm usually pretty imaginative but I can't even think of why someone'd want to do that on a workstation or a server. Being exactly the opposite of an expert, I'm pretty sure that if you're using 128 GB of RAM with your Java app then you're either doing something brilliant or you're doing something horribly wrong.

I guess I could benchmark it and use a burn-in test to get the RAM to peg out at full. I don't think I've done a benchmark or burn-in for a lot of years. I just don't bother any more. Hmm... I need a good forum to show them off. What's the point of doing all that if you can't show off the numbers? ;-)

But, really, I'm not really sure why anyone would want to run your command. Someone probably has a good reason. Not me. :/

You're honestly trying to tell me that RedHat can't change the systemd configuration (or code) to match their desires?

Won't, sadly, and for the record... https://bugzilla.redhat.com/show_bug.cgi?id=1304078:

Jóhann B. Guðmundsson 2016-02-02 16:42:09 EST

This got closed as WONTFIX upstream no need to carry on with this here...

Fedora's policy of trying to stay close to upstream is about 15% to blame, and the rest is simply what distros will end up doing: taking the easy path. This is why centralization is a bad thing... It's going from the Bazaar back to the Cathedral in terms of lack of meaningful ability to influence. The "systemd cabal" is exactly that.

I do not see this Bug would be fixed and I never said that. Why do you think it is fixed?

You have to reboot that box about each two weeks: Fedora kernel Bug 1183791 (it is probably not specific to Fedora)

Also as I RTFA, SELinux does not yet work with an Oracle DB. When it does it will be amazing, but it has not happened yet...

Wrong.

They could make a killing selling support for a Linux distribution . Lots of IT people are locked into Microsoft as a vendor and this would give them a good option.

Microsoft selling Linux certification? Well if it wasn't for two three letter acronyms with those being Fear Uncertainty Doubt and Embrace Extend Extinguish I would think that Microsoft is now being the good guy.

I can understand Microsoft providing and selling certification for an OS that is to work with their OS and products which is a common business practice. In fact Redhat requires Microsoft certification for their products to work with Redhat Linux as well. See the following here . Take a look at the blog links for Microsoft and Redhat in the provided URL.

Problems? You can yum install it. https://rhn.redhat.com/errata/... But that's an old version. They are up to GCC 5 now.

Wayland is a nice piece of software, but it needs some time before it can be in the spotlight.

The the middle click copy-paste functionality is just simply missing on wayland.

https://bugzilla.redhat.com/sh...

OS X, Solaris, IRIX, AIX, have turned a profit for a long time without [product activation] in place.

That's because these proprietary UNIX systems are meant to run on computers sold by the operating system publisher. Authentic hardware activates the operating system. "Don't Steal Mac OS X.kext" anyone?

a LTS release.

This already exists, provided that by "LTS" you mean something like Canonical providing security updates for each LTS release of Ubuntu for five years or Red Hat supporting RHEL for ten years. Microsoft has been providing extended support for Windows XP, Windows Vista, Windows 7, and Windows 8/8.1 for ten years after release or seven years after the successor release, whichever is longer.

SSH.

Coming.

The Red Hat Bugzilla link you want is Audit events in /var/log/messages.

(dnf-makecache.timer is basically a "systemd-style" cron job for periodically updating your DNF cache)

There was a problem involving systemd, networking, and aiccu.

The aiccu maintainer demonstrated how systemd wasn't properly making sure that networking was up before attempting to start aiccu

No they didn't demonstrate that. The relevant thread is this one, and the short version is that the aiccu author failed to understand that the network being unavailable temporarily is quite a different failure mode than, say, the configuration file having a syntax error. In the latter case, it's OK to terminate and require user intervention, whereas in the former case, if you're a long-running daemon that's supposed to keep a tunnel open, you keep running, backing off exponentially and waiting until the network becomes available again. Or at the very least, you exit with a specific exit code so that somebody can write a wrapper script that handles this particular error correctly and implements the backing-off thing in the wrapper script, and still terminates permanently for any other error condition (at which point it's fair to ask again why you wouldn't implement the exponential backoff in the daemon itself).

This whole thing is quite independent of the init system; sysvinit will expose just the same set of issues. What's broken is the daemon, not the init system.