Bash is slow.
Also, bash is not a real language. You will start talking about programming in bash when it will have a proper namespacing system, because even php got namespace support.

Not to mention the need for forking a gigantic amount of software as soon as you want to make anything relevant such as parsing output of any others process, because bash is also unable to understand any complex data structure.

That's a fine language for those whose programming is not a job, and for small software, but as soon as you talk something more critical like the boot of a modern system, bash is holding change, due to various problem ( like a total lack of testing framework, and a given the fact that no one wrote one, lack of will to write one from the whole community of bash aficionados ). Any kind of network operations is just a hack, trying to put everything under the unix pipeline model ( like the whole /dev/tcp/ stuff that Debian disabled ).

Systemd unit file are vastly more easier to edit and go straight to the point, you declare the binary and it fucking take care of the rest. That's why we invented computers, to do stuff, not to force us to do their work.

So that would be a problem of Cadence if they decide to only support RHEL instead of SLES, not of Red Hat.

No, Apple trained the phone to give the middle finger, not to recognize it.

Not for free. The campaign had to be organized, the buzz too. Basically, it would have been cheaper to make a proper market study rather than losing credibility, time and money into that. Especially since they hired someone to design the phone in the first place.

So in this case, this is showing that there is almost no one that want it, since there is less than 10000 persons who pledged money for that. That's a bit sad, i would have pledged if I didn't changed my phone just before ( ie, if Canonical did communicate in the open, I would for sure waited a bit more, but I guess that 1 person wouldn't have changed much ).

I guess there is not enough Linux geeks for every company, I guess even experts do not know everything, and as long as you can do everything, we just ask you to do more for the same price.

Sure, and admins do not need to make sure the OS is properly funded, cause everything come for free and most of them have so much time to contribute.

And of course, admins do not need any training, do not need to have certified hardware cause they can perfectly guess what is working just by looking on specifications. And of course, none of them never read the documentation, nor call the support for complex problems, because all admins are experts in every possible domain.

You mean like having this :
http://developerblog.redhat.com/2013/01/28/software-collections-on-red-hat-enterprise-linux/
( also, something that Fedora refused to have, so the whole idea of "fedora is a redhat product" is proved a bit wrong )

To be honest, you need more than just a puppet recipe to make a mail server. There is several how to because everybody has a different view on what to use. Dovecot, cyrus, ldap/mysql/simple user, postfix/exim/sendmail, what spam filtering, how, etc, etc. People are asking what module they should use to do this or that, and everybody is replicating module because the current one do not work like they want. So the issue is not solved, it just moved elsewhere.

The live spin are made using kickstart. So someone could already use that to replicate the setup, and there was some proposal to use ansible on the fedora-devel ist, not sure how far this went.

You can try openstack on Fedora, or look at RDO ( http://openstack.redhat.com/Main_Page ).

And Fedora is as broken as the community make it broken. If there is no one to make bug reports, triage them, make QA, then yeah, this slip. There is lots of way to help on this part, from giving karma to update testing and testing prerelease.

Technically, JBoss has compatible competitors with Websphere and others.

And there is plenty of competitor on openstack, be it Suse openstack offering, or stuff like cloudstack.

I am sure that your company policy should include "do not use Technology preview on production servers". If it doesn't, then I suggest to add it, and then complain that using RHEL do not have the packages you need, if you want to switch to Debian. That would be much more smoother. than trying to blame the vendor for your lack of clue regarding what is supported and what is not ( especially when comparing to Ubuntu, where you do not even have the guarantee that Mark will not change his mind and just stop the project, or focus it on something else, like they did on the desktop, on bzr, and several stuff )

Your analogy is totally wrong. That's more :

- here is a list of stuff, we will do our best to support, but you have no guarantee on anything
and the other
- here is a list of stuff, we plan to guarantee this. Also, as we know that you may want to plan and deploy the technology for testing in advance, so here is a preview for testing, we wait on your feedback, but that's too new to guarantee much.

That you have a business case do not change much. People have business case for lots of stuff, that doesn't mean this can done or supported in the long term.

In the end, you can turn that as much as you want, you seem to just rant because you have no one to blame for your lack of understanding of the current documented policy.

https://access.redhat.com/support/offerings/techpreview/

What part of "no garantee" is hard to understand ?Seriously, if you cannot spare a system to test, that's not a reason to test it on production when the vendor explictely say "do not do it".

Well, that's the point, ie you need more than hobbyist. IE, when it come to be "enterprise" ready, people expect documentation, training, certification, support, and this is not free ( because while some people enjoy writing documentation or making support, there isn't that much people doing it for free ). And also, when you start to pay, you tend to expect someone to handle the sales, someone to negociate, etc, etc.