http://www.redhat.com/ - A $1 billion a year revenue company

For the same reason that people buy RHEL even though CentOS exists? RHEL exists and is successful because of the support it offers. For users who don't want full support, CentOS fills that gap. So in effect, CentOS *is* the LTS version of Fedora. It just happens to be an LTS version that has a ten-year life-cycle and benefits from whatever fixes are driven by Red Hat Enterprise Linux customers.

That said, if we focus our efforts on the Fedora Server as a primary target (instead of an afterthought), I can very easily see Fedora being used as a real server for medium-term needs (such as deploying some software that has requirements that are too new for RHEL/CentOS).

Stephen Gallagher (Fedora Engineering Steering Committee)

I strongly recommend that you try upgrading with 'fedup' next time around. It's far-and-away better than our historical upgrade processes and works in-place. I've personally gone from F17->F18->F19 using it with no ill effects.

That's going to depend on your definition of Enterprise. Would I recommend Fedora today as your long-term FreeIPA or other core infrastructure server? No, probably not. On the other hand, would I recommend it for DevOps and rapidly deployed-used-and-killed VM instances for newer technologies such as Ruby on Rails or Node.js? Absolutely. Fedora's rapid development cycle is much more in line with those DevOps behaviors. It's actually a myth that "Fedora isn't for production". I know a great many DevOps deployments using Fedora successfully.

That all said, the major piece that was missing from this incredibly (and clearly intentionally) misleading summary is that the purpose of splitting off Fedora into three targets is to provide better support for those who want to use Fedora in production (the cloud image), those who want to develop their layered software so that it will run on the next version of RHEL/CentOS (the server) and people who want a comprehensive desktop for getting stuff done (the workstation/client).

Stephen Gallagher (Fedora Engineering Steering Committee)

It's not surprising that you are confused here, since the original poster went out of his/her way to omit all of the substance of the proposal and instead focus on screaming "Fedora Core!". Of the three targets that were proposed, one of them (Fedora Server) is intended to be *exactly* what you just asked for. A clearly-defined server OS that is essentially snap-shots on the road to Red Hat Enterprise Linux/CentOS stability. Then, there are two other targets: cloud images suitable for use in an IaaS or PaaS infrastructure and the Client Workstation which will be targeted at creators and IT specialists.

The whole point of this proposal is that many of us in the Fedora Project agree with you: One-size-fits-no-one isn't a lasting solution.

Furthermore, the original poster misrepresented two compatible-but-not-identical proposals that came up at Flock. The splitting of the target audiences into separate, isolated deliverables was actually my proposal (Stephen Gallagher), not Matthew's (though he and most of the Fedora Engineering Steering Committee support it). The intent here is to have specific goals for sections of the Project and work towards meeting them. This is a large shift from Fedora's historical behavior which was to ship whatever the upstream projects shipped. With this proposal (backed by a design that is still in progress), we're going to make changes where they need to be made to produce a more cohesive whole.

In the end, we're working hard to ensure that Fedora is relevant in a changing age of cloud infrastructures and DevOps deployments, without ignoring our downstream RHEL and CentOS consumers as well. Certain other Linux OSes have decided to go the route of consumer electronics, but we as Fedora still believe that free software should be the infrastructure that powers those consumer products. And Fedora is a means to that end.

Stephen Gallagher (Fedora Engineering Steering Committee)

That's actually only partially true. Fedora 18 didn't include MATE as an option while doing a DVD install, but if you changed the package location in Anaconda to "closest mirror", you would suddenly get a much larger set of available desktops, including Cinnamon, MATE and others. The reason for this should be obvious: there's only so much space on a DVD, so we tend to keep the set of packages on it limited to the most popular set. Which at the time of Fedora 18's release did *not* include Cinnamon or MATE.

We're definitely accepting criticism for how we can clean up the interface and make important options more visible. That's very nearly the whole point of the Alpha release. Please file bugs at http://bugzilla.redhat.com/ against the "anaconda" component of the Fedora project.

GOTO is certainly very useful in some circumstances. For example, a common pattern in the samba and SSSD sources is this (taking advantage of the talloc() hierarchical memory allocator):

tmp_ctx = talloc_new(parent_ctx).
*allocate memory on tmp_ctx *
do stuff or fail and goto done.
*allocate more memory on tmp_ctx *
do stuff or fail and goto done.

done:
                talloc_free(tmp_ctx);
                return result;

It's really handy to be able to just jump directly to the done: tag on any error and know that any memory you allocated is cleaned up appropriately.

There's a nice article here on setting up the LAMP stack on Fedora (or its relatives, Red Hat Enterprise Linux and CentOS):

http://fedorasolved.org/server-solutions/lamp-stack

There are two primary reasons to require logins:
1) A registration system with a captcha is highly-effective at preventing spam on your blog comments or forum posts.
2) To a greater or lesser degree, it prevents people from impersonating you. Sure there are ways to trick this (create a username that's one lookalike character off, etc.) but on the whole it makes it easier to recognize who you're talking to.