Nothing wrong with using Fedora in production. It depends on what you want. If you want stable and boring the no, don't use Fedora. But if you want to use the latest technology and is OK with rolling forward every 6-12 months then Fedora is actually a great OS to run in production. There's a reason why "software collections" is a big feature in RHEL, and that is that it's more and more common that you actually need newer versions than what's in your "enterprise" distribution. And if that's the case then using a newer distribution could actually be the right solution. There are of course reasons why you wouldn't use Fedora. If you want a support contract or require certain certifications then use RHEL or something else.

They are not hidden, they have just moved to another place. The top-right corner is quite common nowadays to put these. Even Firefox has that now so it should be discoverable.

I can only agree. GNOME 3 was a bit rough around 3.0/3.2 and wasn't really that great until 3.8/3.10. Unfortunately, it was in the early days when a lot of people tried GNOME 3 for the first time. Debian with GNOME 3.14 will be a great desktop experience.

Why would you pin systemd to -1 if you use it to build debs? What part of systemd prevents you from building debs?

Of course it gets installed, it's the default init system in Jessie. Most users would expect to have it installed when upgrading, considering that it's a major new feature in Jessie and meant as a replacement for sysvinit.

Apache went from 2.2 to 2.4, which in Apache speak is pretty much a major version change. There were lots of changes in 2.4, especially making the event-based mpm the default. But there's also a lot of other changes so expect that you have to go through and possibly change a lot of configuration. I also have a number of custom Apache modules that had to be partly rewritten. But once that was done things have been running just fine.

The UI was redesigned but it still has the capabilities of the old UI, if you're willing to look for things in another place. Most things were moved to the app menu and the drop-down menus in the top-right corner of the viewer window. Keyboard shortcuts are of course still there.

Or use something like FAI. It's widely used in larger deployments and allows you to customize as much as you want of the system at install time.

GNOME applications works just fine with other desktop environments and window managers. What used to be the biggest concern, the app menu, is no longer handled by adding a separate menu bar in the window with just for that menu. Instead, most applications show it as a button in the headerbar when not run within GNOME.

The software probably works just fine. It's interacting with Apple's online services that doesn't work anymore.

Blame ISO. The gnu compiler modes named in the same scheme as the corresponding versions of the C programming language, C89, C99, C11.

OS X actually has perfectly fine support for shared libraries. They are supposed to be installed under /Library/Frameworks, and there are some applications that do that. There's no reason why they couldn't do that on iOS as well, just let developers share frameworks on the App Store and build a mechanism into the App Store where an app can require other apps or frameworks.

Nowadays that's more or less the default scenario.

Managing shared libraries across applications works fine in a GNU distribution where the distribution takes responsibility for all applications. With Apple's approach there's no good way to manage this, different applications might use their own specialized version of the library. At most you might have an opt-in system where developers can register the libraries they are using and the version they require, and have the system download and manage them for them.

Most non-free licenses are quite scary too, but they often get a pass since they are not that open to begin with.