There is a need for repositories that provide those packages. They could possibly be the Fedora repositories, but RedHat needs to provide something to avoid having people compile stuff that they will never update, even if their official advice is strictly to stick to the supported repositories.
For Red Hat servers, you can generally get away with running off official repositories only, with the occasional server needing some specific software that you should have paid support for in the first place (meaning access to updates).
In other words I think I agree with the other poster that mentioned that perhaps Red Hat is not for you, and you should be looking at a Debian distro if you want access to so many thousands of packages. Red Hat is for organisations that want a fully supported, paid for, reasonably secure solution to use and this is the market they target (and they obviously do a good job!).
Also your point about having the package manager recompile an installed application against a targeted CPU architecture - it would be nice, but how is this even possible unless you're using a source RPM? Normal RPMs generally only contain pre-compiled binaries, man pages, configuration files and pre/post exec scripts.
either make a free version (like OpenSuse) or point people to CentOS and pay a few people to sit in their IRC. Also, Do they need build servers? Help them with that also. You don't have to supply money just hardware. You can't compete with Ubuntu without doing this. Perhaps you should improve your relationship with ubuntu and SuSE. You have been doing well about pushing kernel updates to source as well as to your clients. Instead of being antagonistic about Ubuntu, you should show appreciation for their support in userland.
As for recompilation being possible, it is simple. RedHat can extend both the repository format and their package manager. The repositories would store instructions on how packages are built and what the dependencies are. The package manager needs to understand those instructions to be able to build packages from them. At that point, they can simply tell the package manager to build packages and it will build them. They can then distribute them and others can recompile them as they see fit. If it is never used to improve performance, it would still make for a good hardware sanity test, because compilation will more than likely fail on bad hardware.
Honestly, I don't see why people wish to deride a suggestion that would increase the number of organizations using RHEL for its intended purpose. From what I have been told by people with whom I have spoken, the current repository situation keeps organizations on Windows and remedying that situation would eliminate a major factor preventing migrations to RHEL. I think it is quite obvious that my wishlist is meant to cover things that make RHEL for large organizations and not the typical end-user. All of the things I listed are things that I think would be useful for large organizations. Even if one item could be beneficial to end-users, that doesn't render it useless for enterprise use.
[QUOTE=allquixotic;225753]Fantastic list. To this, I would add
[list][*]First party support for cutting-edge but well-tested open source graphics drivers (backport DRM, Mesa, Xorg drivers and components as needed) and continually update and backport from the latest drivers for each point release
We already do that, if you pay us. RHEL6 rebases X.org/Mesa/kernel drm each revision to support new hardware and fixes. So it sounds like you aren't actually a customer or you don't read our docs.
[*]The ability to get paid Red Hat support to fix any application compatibility issues that arise with the open source graphics stack, and ensure that the Red Hat contributions are upstreamed
Pretty much do that as well for paying customers with a lot of installations. Everything we do is upstreamed.
[*]Support for the latest mice, keyboards, motherboards, sound cards and peripherals in each point release
[*]Adopt a more liberal update policy for graphical desktop software, especially with point releases (e.g. a point release could upgrade from Gnome 3.0 to Gnome 3.2, but not from Gnome 2.30 to Gnome 3.0)[*]Hand-select a small number of extremely popular packages that will be continually integrated into the RHEL update chain as they evolve, based on the quality of upstream QA & testing and level of backwards compatibility. Examples: Firefox, Virtualbox. Major new releases (e.g. Firefox 5.0 -> 6.0) would ship in point releases of RHEL, while point releases of the programs themselves (e.g. Firefox 5.1) would ship as normal updates through RHN without even waiting for a RHEL point release.
Already do this, firefox and openoffice are dropped in as they are released. We don't ship virtualbox.
It sounds like you don't actually follow RHEL at all, and are just someone who runs CentOS.
Things that affect me as a RHEL customer:
1) (Already been mentioned, but I'll expand) a decent Single Sign On implementation. It took ages for FreeIPA to get off the ground, but 2.0 has finally made it into RHEL6.1. Even so, it's still clearly an afterthought for RedHat. A decent, secure, Kerberos based SSO system, simple server configuration, simple client registration/configuration (management of sssd, etc) would all be super. Whether it's done via FreeIPA or Samba4, I don't care. Samba4 needs to be recognised as more than just a Windows DC option, and seen as a potential Linux SSO system as well.
When setting up a Windows domain, Active Directory is a must-have feature. It's a mystery why we're in 2011, and I can still count the number of medium to large enterprises I've seen that have no centralised account control for Linux (and I've worked for quite a few). My last job involved managing 700 RHEL5 servers (mixture of physical and virtual), and talking to RedHat about Enterprise Linux SSO got a pretty poor response.
What's odd about all of it is that tools like RHEV-M and RHN Satellite can all happily authenticate via AD. Yet RedHat don't seem to have any desire to provide an alternative that they'll push/support themselves.
2) A strong focus on an enterprise capable database. RedHat provide a virtualisation layer (RHEV), the OS (RHEL) and fantastic middleware tools (JBoss/JBEAP). What's missing from the picture is better support for a database. Sure, PostGRESQL and MySQL are installable, but again they're just treated as customer problems. A strong focus on PostGRES (RedHat/PostGRES training, and support to the same level as JBoss) would be great.
http://fedoraproject.org/wiki/EPEL, for instance. EPEL can certainly be improved, and RH would perhaps benefit from putting some (more?) people to work on it, but I don't think trying to have an official repo (as in fully supported) that competes with the likes of say Ubuntu is feasible.