Announcement

Collapse
No announcement yet.

Red Hat Enterprise Linux 8.0 Reaches General Availability

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

  • #21
    I'd really appreciate if a checksum could be posted for the 6.6 GB ISO

    Comment


    • #22
      Originally posted by darkbasic View Post
      Is it possible to use zfs with Red Hat Enterprise 8?
      It should be possible in the near future (after the release of EPEL8).
      https://github.com/zfsonlinux/zfs/wiki/RHEL-and-CentOS
      https://fedoraproject.org/wiki/Infra...re_2020/EPEL-8

      I doubt it will ever work OOTB. Red Hat has invested a lot money in Stratis, so it is very unlikely that they will now support ZoL (ZFS on Linux). Btrfs has been deprecated in RHEL.

      Comment


      • #23
        Originally posted by edwaleni View Post

        Red Hat backports certain fixes into their kernel releases. So do not judge based on kernel number alone.
        So, yet another distro that has maintainers wasting time polishing a turd rather than just upgrading?

        Comment


        • #24
          Originally posted by FishB8 View Post

          Clearly you've never had to pay hundreds of thousands of dollars due to that 15 min windows of service down-time caused when that out-of-tree kernel module that your storage depends on caused the cluster nodes to core dump after the upgrade, violating your SLA requirement stipulating 99.9975% uptime. When a few min of downtime costs more than you make in a year's salary, you do not just upgrade on a whim.
          Not a problem if you have a staging environment. "testing in production" (which is what you're implying) should sound like your nightmare if you've even considered whether it's possible to do things right. I assume you consider deploying on Fridays to be a good idea, what are weekends anyway, right?

          Comment


          • #25
            The "Desktop" version of RHEL doesn't have any development packages at all. It's not just the lack of access to RHSCL/RHDTS repositories, there are no development-related packages in the main repos either. As far as I know, "Workstation" has the missing dev tools, but please keep in mind that RHSCL/RHDTS are still not available with Self-Support subscriptions (Red Hat Enterprise Linux Workstation, Standard - $299 per year). And believe me, using RHEL as your main system on desktop will require you to build A LOT of packages on your own. RHDST can be very helpful here thanks to the GCC and LLVM/Clang toolsets (in the main repo there is only GCC 4.8, which doesn't even have full support for C++11), and SCL would provide you nodejs10, which is important for building Electron apps (you can use npm to create package-lock.json, and then use the flatpak-npm-generator on it to create generated-sources.json, which is required to build Electron app on Flathub). Of course, you could use COPR to build RPM packages in the cloud. However, there is no i386 version of EPEL, nor i686 CentOS setup in mock, so it will be a pain in the ass to build wine and required deps for it (WINE in the main repo is broken by design - it applies to Fedora as well), quickbms, 32-bit version of openal-soft, etc. You can also forget about all of proprietary things, unless you decide to use Flatpak/Snap/AppImage.
            Maybe "Desktop" version can perform well in a corporation environment or in a state institution, where you have a strict list of programs that you can use. However, it is not suitable for normal desktop usage. To be honest, I would recommend CentOS instead. You could also try a no-cost RHEL Developer Subscription for development purposes. It will give you access to Red Hat Enterprise Linux Server, which is essentially a super set of the other editions. This includes also access to the RHSCL/RHDTS repos.

            See also:
            https://access.redhat.com/articles/911363
            https://developers.redhat.com/articles/no-cost-rhel-faq
            https://copr.fedorainfracloud.org/coprs/scx
            https://wiki.winehq.org/CentOS/RHEL#Notes_on_EPEL_7

            Comment


            • #26
              Originally posted by DoMiNeLa10 View Post
              What's with everyone's fetish to use ancient software (Linux 4.18, really?) and keeping it up and running for way too many years? Linux has a stable release, and it's called stable for a reason.
              That's because the target is the Enterprise market and enterprises often buys very expensive applications and drivers (or rather hardware that requires drivers) from companies that do not do releases very often (since ordering just a single change can costs lots of money, sometimes in the million range) so they want a stable Kernel and Userspace ABI to which the suppliers certify their products and then keep them there for years.

              This is i.e why you will find some places that still run Windows XP because that is the latest version that can run the software/hardware that is in use.

              Comment


              • #27
                Originally posted by scineram View Post

                Why wouldn't it?
                Because if you select RHEL, it's because you want 1) support and 2) rock solid reliability. Third party kernel modules like ZFS invalidate the former and seriously jeopardize the latter.

                Comment


                • #28
                  Originally posted by edwaleni View Post
                  I saw RHEL 6.x break a few applications and it caused a delay in getting off 5.x at the time. The decision was made to push up to 7.x rather than wait on 6.x to get resolved. Everyone's appetite to upgrade is different.
                  Fortunately, this is becoming less of a problem as more applications migrate to containers.

                  Comment


                  • #29
                    Originally posted by jacob View Post

                    Because if you select RHEL, it's because you want 1) support and 2) rock solid reliability. Third party kernel modules like ZFS invalidate the former and seriously jeopardize the latter.
                    I would avoid third party kernel modules as well but just to be clear, you don't lose support for RHEL just because you load up a third party kernel module. Red Hat will not support the third party kernel module itself unless there is a support contract that covers that and might ask you to unload the kernel module and reproduce the problem if you report something that touches on the usage of the module but you would have no issues in getting support in general. Also reliability of the overall system would be dependent on the third party kernel module but a lot of enterprises systems routinely load up kernel modules not provided by the distribution (Oracle DB servers for example for users of Oracle ASM) and I wouldn't call it jeopardizing the stability of the system. In general, I would seriously think twice about using any kind of unsupported components and especially kernel modules for something as critical as a filesystem but there are large organizations doing such things with the understanding of the tradeoffs involved.

                    Comment


                    • #30
                      Originally posted by edwaleni View Post
                      Red Hat backports certain fixes into their kernel releases. So do not judge based on kernel number alone.
                      Not just fixes, but new features, and new hardware support as well.

                      Comment

                      Working...
                      X