Announcement

Collapse
No announcement yet.

Red Hat Enterprise Linux 7 Ideas Are Needed

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Red Hat Enterprise Linux 7 Ideas Are Needed

    Phoronix: Red Hat Enterprise Linux 7 Ideas Are Needed

    Red Hat is beginning to look for feedback and ideas from their enterprise customers about what they would like to see from Red Hat Enterprise Linux 7, the next major release of their flagship Linux operating system...

    http://www.phoronix.com/vr.php?view=OTg1OA

  • #2
    Here is my wishlist:
    • Official repositories that rival other distributions in having up to date software and a large variety (e.g. >15,000 packages).
    • The ability to have the package manager recompile installed software with -march=native to take better advantage of the CPU. (e.g. AVX Support)
    • SAMBA 4 so that legacy Windows 7 systems can use RHEL servers as domain login servers.
    • First party support for the installation of Microsoft Office in a multiple user configuration via a compatibility layer (e.g. CrossOver, WINE)
    • An open source flash plugin like what IcedTea is for Java so that legacy software can be used without compromising security.
    • RDP support in KVM-QEMU to enable access to virtual infrastructure from legacy Windows machines on which installing the SPICE client is not always an option.
    • Proper KVM PCIe Passthrough Support so PCI devices behind PCIe-to-PCI bridges will work.
    • The ability to run the KVM SPICE server on a UNIX domain socket.
    • Improvements in the KVM vmware graphics device so that Windows Aero works via the VMWare WDDM 3D Windows driver, both in situations where the host lacks a GPU and in situations where one is installed.
    • Virtualized GPGPU functionality in KVM (e.g. CUDA, OpenCL).
    • Better POSIX support (e.g. implementation of gettid() in libc, proper implementation of UNIX System V syscall codes, etcetera).
    • Better written manpages that explain how signal handling works in conjunction with threads.
    • An IDE for UNIX systems that functions similarly to Microsoft Visual Studio in both performance and ease of use.
    • First party support for alternative compilers such as LLVM/Clang.
    • The ability for system administrators to use GRUB with UEFI systems, without any need for the much more cumbersome GRUB2 (e.g. do the work to push the Fedora UEFI GRUB patches upstream)

    I am not a RedHat customer, but I hope that my wishlist will make it to RedHat. I know some organizations that do not use RHEL specifically because of items on my wishlist.
    Last edited by Shining Arcanine; 08-31-2011, 01:30 PM.

    Comment


    • #3
      Here is an addendum:
      • Generic improvements to power management so that the air conditioners in datacenters do not have to work as hard and the electric bills better correspond to the actual work done.

      Comment


      • #4
        Proper NFS4 support.
        Legal mp3 and h.264 codecs.
        Stop enabling Lennart Poettering.
        Keep Ulrich Drepper away from the public.

        Comment


        • #5
          Originally posted by Shining Arcanine View Post
          Here is my wishlist:
          • An IDE for UNIX systems that functions similarly to Microsoft Visual Studio in both performance and ease of use.
          Keep dreaming. Eclipse/NetBeans/QtCreator are the tallest leprechauns in the Unix/Linux world.

          As to the System V compatibility - all the stuff that was worth supporting is already supported in Linux. Linux was meant as a Unix-like platform, not as a free Unix swap solution, so the policy is - change your source code to use the (better) Linux solution. On the desktop - Linux is already _the_ OS from which the "true" Unixes like BSD and Solaris copy code and adapt to their needs (graphics drivers, KMS). Get used to it - upgrade your code to the new reality, not the OS (Linux) to the old API.

          Comment


          • #6
            I'd love it if they would stop their FUD and shipped Mono with RHEL7. Preferably packaged in a manner more consistent with Upstream (and what debian/Ubuntu does) rather than the backwards Fedora packaging.

            Comment


            • #7
              Originally posted by cl333r View Post
              Keep dreaming. Eclipse/NetBeans/QtCreator are the tallest leprechauns in the Unix/Linux world.

              As to the System V compatibility - all the stuff that was worth supporting is already supported in Linux. Linux was meant as a Unix-like platform, not as a free Unix swap solution, so the policy is - change your source code to use the (better) Linux solution. On the desktop - Linux is already _the_ OS from which the "true" Unixes like BSD and Solaris copy code and adapt to their needs (graphics drivers, KMS). Get used to it - upgrade your code to the new reality, not the OS (Linux) to the old API.
              You probably have never programmed on Linux. The kernel supports gettid(), but gettid() is not available in userland. It is something that makes threaded programming a pain on Linux and it also introduces unnecessary issues when porting software to Linux.

              http://www.kernel.org/doc/man-pages/.../gettid.2.html

              With that said, I would like to ask that you refrain from making such ignorant comments, or better yet, that you use Windows. Software developers don't have time to deal with this nonsense.
              Last edited by Shining Arcanine; 08-31-2011, 02:05 PM.

              Comment


              • #8
                Originally posted by Shining Arcanine View Post
                Here is my wishlist:
                • Official repositories that rival other distributions in having up to date software and a large variety (e.g. >15,000 packages).
                • The ability to have the package manager recompile installed software with -march=native to take better advantage of the CPU. (e.g. AVX Support)
                • SAMBA 4 so that legacy Windows 7 systems can use RHEL servers as domain login servers.
                • First party support for the installation of Microsoft Office in a multiple user configuration via a compatibility layer (e.g. CrossOver, WINE)
                • An open source flash plugin like what IcedTea is for Java so that legacy software can be used without compromising security.
                • RDP support in KVM-QEMU to enable access to virtual infrastructure from legacy Windows machines on which installing the SPICE client is not always an option.
                • Proper KVM PCIe Passthrough Support so PCI devices behind PCIe-to-PCI bridges will work.
                • The ability to run the KVM SPICE server on a UNIX domain socket.
                • Improvements in the KVM vmware graphics device so that Windows Aero works via the VMWare WDDM 3D Windows driver, both in situations where the host lacks a GPU and in situations where one is installed.
                • Virtualized GPGPU functionality in KVM (e.g. CUDA, OpenCL).
                • Better POSIX support (e.g. implementation of gettid() in libc, proper implementation of UNIX System V syscall codes, etcetera).
                • Better written manpages that explain how signal handling works in conjunction with threads.
                • An IDE for UNIX systems that functions similarly to Microsoft Visual Studio in both performance and ease of use.
                • First party support for alternative compilers such as LLVM/Clang.
                • The ability for system administrators to use GRUB with UEFI systems, without any need for the much more cumbersome GRUB2 (e.g. do the work to push the Fedora UEFI GRUB patches upstream)

                I am not a RedHat customer, but I hope that my wishlist will make it to RedHat. I know some organizations that do not use RHEL specifically because of items on my wishlist.
                Fantastic list. To this, I would add
                • 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
                • 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
                • Support for the latest mice, keyboards, motherboards, sound cards and peripherals in each point release
                • Officially licensed support for an emulated Internet Explorer (wine) - perhaps a deal with Crossover
                • Officially licensed support for non-free media decoders - perhaps a deal with Fluendo
                • GUI management of container-based virtualization to compete with Parallels' proprietary offering
                • 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.

                In a nutshell, I think RHEL is already the obvious winner for servers, and they should continue along the obvious linear path for improving and deepening their server-side support. What I would really love to see is RHEL being a relevant, up-to-date, aggressive competitor for the enterprise desktop, which is much more prevalent than you think. Practically every white collar office worker in America has a copy of Vista Enterprise, XP Professional or some similar Windows operating system. I want Red Hat to uproot some of that market share that has been owned by Microsoft for two decades. People who use Linux at work will be much more likely to be comfortable using it at home. The beautiful thing about most corporate work environments is that, often, you can't choose which OS you want to run on your computer. It can be a damning, miserable trap if your office insists on using Windows XP through 2050, but on the flip side, if you have an open-minded, forward-thinking IT department, it can also win over a lot of willing Linux users by forcing a standard RHEL Desktop image on all the users and making them get used to it. They will hate the transition, but by forcing them through it (and paying them for the time they spend figuring things out), they will eventually get familiar with it.
                Last edited by allquixotic; 08-31-2011, 02:22 PM.

                Comment


                • #9
                  Originally posted by Shining Arcanine View Post
                  Official repositories that rival other distributions in having up to date software and a large variety (e.g. >15,000 packages).
                  What part of "Enterprise Linux" don't you understand?

                  If you want up-to-date packages, go with Fedora. If you want umpty-thousand packages, Debian might be a better bet.

                  Comment


                  • #10
                    Originally posted by dsmithhfx View Post
                    What part of "Enterprise Linux" don't you understand?

                    If you want up-to-date packages, go with Fedora. If you want umpty-thousand packages, Debian might be a better bet.
                    +1, the OP hasn't really grasped one of the fundamental points of RHEL: provide a stable environment for Enterprises. This means you don't change major software versions, introduce major new features or support a tonne of software that only a tiny, tiny percentage of your customers will actually use.

                    Comment


                    • #11
                      Originally posted by dsmithhfx View Post
                      What part of "Enterprise Linux" don't you understand?

                      If you want up-to-date packages, go with Fedora. If you want umpty-thousand packages, Debian might be a better bet.
                      Well, I'd qualify that - it should have up-to-date packages as of release (allowing for some delay from the testing cycle). But yeah, the people who actually use RHEL don't want major package updates to be pushed out, the way they are on Fedora and other desktop-oriented distros. Enterprise customers see that as a feature - the system is static, no unexpected changes coming in to surprise them.

                      Comment


                      • #12
                        Originally posted by allquixotic View Post
                        Fantastic list. To this, I would add
                        • 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
                        • 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
                        • Support for the latest mice, keyboards, motherboards, sound cards and peripherals in each point release
                        • Officially licensed support for an emulated Internet Explorer (wine) - perhaps a deal with Crossover
                        • Officially licensed support for non-free media decoders - perhaps a deal with Fluendo
                        • GUI management of container-based virtualization to compete with Parallels' proprietary offering
                        • 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.

                        In a nutshell, I think RHEL is already the obvious winner for servers, and they should continue along the obvious linear path for improving and deepening their server-side support. What I would really love to see is RHEL being a relevant, up-to-date, aggressive competitor for the enterprise desktop, which is much more prevalent than you think. Practically every white collar office worker in America has a copy of Vista Enterprise, XP Professional or some similar Windows operating system. I want Red Hat to uproot some of that market share that has been owned by Microsoft for two decades. People who use Linux at work will be much more likely to be comfortable using it at home. The beautiful thing about most corporate work environments is that, often, you can't choose which OS you want to run on your computer. It can be a damning, miserable trap if your office insists on using Windows XP through 2050, but on the flip side, if you have an open-minded, forward-thinking IT department, it can also win over a lot of willing Linux users by forcing a standard RHEL Desktop image on all the users and making them get used to it. They will hate the transition, but by forcing them through it (and paying them for the time they spend figuring things out), they will eventually get familiar with it.
                        Those are all things that I would like to see happen, but RedHat is a heavily focused company and these things are not very useful for their core market, which basically consists of servers and workstations.

                        Originally posted by dsmithhfx View Post
                        What part of "Enterprise Linux" don't you understand?

                        If you want up-to-date packages, go with Fedora. If you want umpty-thousand packages, Debian might be a better bet.
                        I understand that many packages in need of security fixes are installed outside of the system package manager on RHEL, which causes security vulnerabilities to persist for years. I also understand that such a situation is a very bad situation for any enterprise environment.

                        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.

                        Originally posted by tomm3h View Post
                        +1, the OP hasn't really grasped one of the fundamental points of RHEL: provide a stable environment for Enterprises. This means you don't change major software versions, introduce major new features or support a tonne of software that only a tiny, tiny percentage of your customers will actually use.
                        The original poster in this topic is the phoronix news bot, which lacks the ability to grasp fundamental points by definition.
                        Last edited by Shining Arcanine; 08-31-2011, 07:10 PM.

                        Comment


                        • #13
                          Originally posted by Shining Arcanine View Post
                          I understand that many packages in need of security fixes are installed outside of the system package manager on RHEL, which causes security vulnerabilities to persist for years. I also understand that such a situation is a very bad situation for any enterprise environment.

                          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.
                          Generally if you're using Red Hat Enterprise Linux workstations you will be mainly using official supported repositories from Red Hat which AFAIK include backported security fixes, and in the organisations I've been in, you might also see some custom developed applications. For custom apps, the developers should be keeping these up to date and providing these updates, figuring out their own deployment strategy in conjunction with the System Administrators of the company.

                          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.

                          Comment


                          • #14
                            A commiunity supported, free version not quite as bleeding edge as Fedora

                            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.

                            Comment


                            • #15
                              Originally posted by Kamikaze View Post
                              Generally if you're using Red Hat Enterprise Linux workstations you will be mainly using official supported repositories from Red Hat which AFAIK include backported security fixes, and in the organisations I've been in, you might also see some custom developed applications. For custom apps, the developers should be keeping these up to date and providing these updates, figuring out their own deployment strategy in conjunction with the System Administrators of the company.

                              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.
                              I think you misunderstood why I listed that item. I have spoken to people that make decisions on what software their organizations use and most of them find that the software that they need is often missing from the official repositories. They then need to compile software from tarballs; doing that is a pain and introduces security vulnerabilities because the software is virtually never patched. I could care less about whether or not RHEL has any packages in their repositories, but the organizations I know using Windows do care. They don't want to compile software outside the package manager. It makes them responsible for dependency resolution and patches; both of those are things that they loathe doing. It also defeats the purpose of having a package manager because the security fix situation becomes the situation they have on Windows.

                              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.
                              Last edited by Shining Arcanine; 09-01-2011, 12:13 AM.

                              Comment

                              Working...
                              X