Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
Red Hat Software Businesses Cloud Open Source

Analyst: Enterprises Trust Red Hat Because It 'Makes Open Source Boring' (redmonk.com) 105

Tech analyst James Governor reports on what he learned from Red Hat's "Analyst Day": So it turns out Red Hat is pretty good at being Red Hat. By that I mean Red Hat sticks to the knitting, carries water and chops wood, and generally just does a good job of packaging open source technology for enterprise adoption. It's fashionable these days to decry open source -- "it's not a business". Maybe not for you, but for Red Hat it sure is. Enterprises trust Red Hat precisely because it makes open source boring. Exciting and cool, on the other hand, often means getting paged in the middle of the night. Enterprise people generally don't like that kind of thing...

Red Hat remains an anomaly -- it makes money in open source. It has new revenue streams opening up. It is well positioned to keep doing the basics, but also now have a conversation with the C-suite about transformation.

The article notes the popularity of OpenShift, Red Hat's Kubernetes distribution for managing container-based applications. (OpenShift Container Platform, Red Hat's on-premises private PaaS product, now has 400 paying enterprise customers). And it also applauds Red Hat's 2016 launch of Open Innovation Labs -- a enterprise consulting service "to jumpstart innovation and software development initiatives using open source technology and DevOps methods."
This discussion has been archived. No new comments can be posted.

Analyst: Enterprises Trust Red Hat Because It 'Makes Open Source Boring'

Comments Filter:
  • by Hognoxious ( 631665 ) on Monday September 25, 2017 @07:38AM (#55258427) Homepage Journal

    Gnome 3 & systemd aren't boring, more's the pity.

    • Gnome 3 & systemd aren't boring

      Gnome 3 and systemd are 7 years old. The vision of both projects haven't changed much and both projects have been slowly and boringly going in those directions. What was the last outrage about in the last GNOME release? Emojis or was it tan suite?

      If you just don't those projects, I've heard good things about FreeBSD.

      • Re: (Score:3, Insightful)

        by Anonymous Coward

        Gnome 3 and systemd are 7 years old. The vision of both projects haven't changed much and both projects have been slowly and boringly going in those directions.

        First Lennart pushed systemd into Red Hat, and I did not speak out ---
        Because I did not use Red Hat.

        Then Lennart pushed systemd into Arch, and I did not speak out ---
        Because I did not use Arch.

        Then Lennart pushed systemd into Debian, and I did not speak out ---
        Because I did not use Debian.

        Then Lennart pushed systemd into my favorite distro ---
        and there was no one left to speak for me.

        • and there was no one left to speak for me.

          You forget that Linux is about choice. It seems you would like to restrict the distributions to choose their preferred init system. I have changed distros because I didn't believe in their technical and political decisions and that is fine.

          As for the choice of the poem — trying to compare changing init systems to literal slaughter of millions of people really puts this systemd issue in perspective. Alas, this is trivializing horrors of the Nazi regime.

      • Re: (Score:2, Insightful)

        by Anonymous Coward

        I think we can consider GNOME to be pretty much a dead project at this point.

        Shit, early last month Slashdot reported that the GNOME project was having trouble finding maintainers for its text editor, gedit [slashdot.org]! It's really pathetic when what was once the most successful open source desktop environment is having trouble maintaining its own text editor!

        Any sensible GNOME 2 user has moved to MATE, Xfce, KDE, or one of the many window managers instead of wasting their time with GNOME 3. GNOME 3 is like Firefox. Ye

        • early last month Slashdot reported that the GNOME project was having trouble finding maintainers for its text editor, gedit

          In the gedit home page I found this gem:

          About gedit maintenance: gedit has been marked as unmaintained recently, now two new developers have proposed their help to become new maintainers. If you want to help, reach us on the IRC channel or the mailing list, thanks!

          Perhaps you should get the latest on the breaking news.

    • Re:Gnome 3 & systemd (Score:5, Informative)

      by jellomizer ( 103300 ) on Monday September 25, 2017 @08:19AM (#55258599)

      Are you still pissed that you lost a VI vs Emacs debate?
      For a normal Red Hat implementations the system is going to be mostly headless so Gnome isn’t a big deal if even used at all. And if you are administering a system and you are constantly tinkering with its systems init setting. You are doing it wrong for the 21st century.

      On an enterprise system the system is loaded into a VM and the OS is configured to run one process and do it well. It isn’t like the 1990s where you had one system that was your database, web server, email server, login authentication, file server and print server. Where we more or less configured a PC to work like a mainframe. And if one part needed a new library then you needed to check all the systems because it was all integrated one one server. If someone got in they hit the mother load of data.

      • by Anonymous Coward

        ""loaded into a VM and the OS is configured to run one process""

        and thats why we remove systemd from the vm or container. It's just not needed in this context.
          We remove it from the host as well but thats for other reasons.

      • by emil ( 695 )

        Oracle will burn you at the stake in license fees if you use any VM other than their Xen port. A DBA's nightmare is some idiot mandating VMWare or HyperV.

        Expensive packages dictate the system. Cores get ripped out, VMs disabled, and the system is otherwise extensively corrupted to obtain the cheapest licensing configuration.

      • On an enterprise system the system is loaded into a VM and the OS is configured to run one process and do it well. It isn’t like the 1990s ...

        It is sad that this is indeed the modern way. Apparently it is too difficult to run applications without their own dedicated OS, probably because the OS cannot protect apps against shared library version dependencies, and because greedy apps assume they're the only important process on the OS (hey let's use ALL memory or CPU because leaving any free for other

        • It is also about portability. Where you can upgrade one component or rebuild a component to a fresh install without having worrying about other systems. Also you can clone a VM and put the file onto an other server and perhaps some setup and you have a redundant system, or at least a backup of a working system.
           

        • by jabuzz ( 182671 )

          No it's about long term ease of maintenance. Eventually your OS will be out of support and you will need to upgrade. I would rather upgrade 10 VM's one at a time than one with 10 services in one go. If you can't see the advantages of option one then you have not been through option two. In fact I have never been through option two because the services where spun out into single service VM's one at a time till I could turn the physical server off.

          Further Linux high availability sucks (this is from bitter exp

    • by Junta ( 36770 ) on Monday September 25, 2017 @08:37AM (#55258669)

      Gnome 3: At some point RHAT realized that the desktop just doesn't matter to their business, so the engineers are pretty much free to do what they wish. That's why in RHEL7 the desktop packages are no longer so conservative as they were previously. All RHAT's revenue is on the server side, which brings us to...

      systemd: Here's an example of a design that alienated a fair amount of the linux population. However, that population is folks who were interested in self supporting. Not RHAT's revenue stream. However, for those really knowing systemd inside and out, there's things in there that are easier to help support staff support *someone else*, particularly if the only convenient communication path is voice over a phone line. Sure, systemd can go off the rails and be inscrutable even to support staff, but that's when they break out 'just reinstall the thing', and honestly speaking if things are that bad and you need RHAT's support, it was going to be that bad anyway.

      • by bill_mcgonigle ( 4333 ) * on Monday September 25, 2017 @10:09AM (#55259085) Homepage Journal

        Here's an example of a design that alienated a fair amount of the linux population. However, that population is folks who were interested in self supporting.

        No, it's a tiny, very loud subset of that population that just enjoys rolling in their own noise at this point. Most people I know greatly prefer the ease of use, predictability & reliability (greatly reduced race conditions) of CentOS 7 to CentOS 6, for instance.

        I still do some admin part time and I haven't found a single thing that I could do with shell-based startup scripts that I can't do with systemd units (including calling shells scripts), while things like pre-requisites/requirements and parallelism are way easier with systemd.

        I'm sure there is some edge case where systemd doesn't work, but that's fine - there's nothing stopping anybody from booting with init=/some/shell/script and rolling their own.

        Current linux distros still follow the "make most things easy, make everything possible" axiom. Yeah, you might not get support from upstream when you roll your own init, but the people who are crying "but I want to roll my own init" ought to expect that, and hire third-party support if/when required.

        Most people are happier with systemd than SysV init and the people who are insisting that they should be unhappier based on some academic theory are not looking out for the best interests of the community. We use unix to make our lives more satisfying, not less.

        • by Junta ( 36770 ) on Monday September 25, 2017 @10:24AM (#55259171)

          predictability

          I would say systemd could be called many things, but not that. The boot process is far less deterministic, by design. If one service takes a variable amount of time to execute, no longer does it block another so boot performance is improved as you no longer serialize a bunch of long-running service startups.. On the flip side, a missed dependency relationship means race condition, and a lot of the migration growing pain were services that had some implicit dependency that wasn't described at first. As time goes on, this baptism by fire does lead to a more robust understanding of service interdependencies.

          This may be a sane tradeoff, but I don't understand why we aren't willing to rationally acknowledge design tradeoffs, rather than going off at a hint of a mention that there exists a downside to anything.

          • On the flip side, a missed dependency relationship means race condition, and a lot of the migration growing pain were services that had some implicit dependency that wasn't described at first. As time goes on, this baptism by fire does lead to a more robust understanding of service interdependencies.

            This is one way to describe it. Another way to describe it is "the existing init services didn't even document their own dependencies correctly and the only reason things worked out was because they were accidentally serialized".

            This may be a sane tradeoff, but I don't understand why we aren't willing to rationally acknowledge design tradeoffs, rather than going off at a hint of a mention that there exists a downside to anything.

            I mean, I acknowledge for sure that if services do not properly document their own dependencies, things will not work. This is a lot like saying saying that (C) programs which do not check for NULL before dereferences ma crash. No one should be "going off", and the rudeness of syste

            • by Junta ( 36770 )

              The major problem being a race condition can pass an initial test, and then bite you later. So a screwed up implicit dependency that failed 100%, not so bad, but the nature of the beast has been looks good at a glance, fails later.

              The problem being that the benefit (faster boot) is generally limited in benefit, but the risk of another vector for common boot time failures is made higher.

              I will confess my biggest gripe is journald's binary-only format for log data (yes, I know journalctl will do nifty things

          • Wouldn't a competent administrator already know that bar has to be started before foo, and then add that to systemd?

        • by Etcetera ( 14711 )

          Here's an example of a design that alienated a fair amount of the linux population. However, that population is folks who were interested in self supporting.

          No, it's a tiny, very loud subset of that population that just enjoys rolling in their own noise at this point. Most people I know greatly prefer the ease of use, predictability & reliability (greatly reduced race conditions) of CentOS 7 to CentOS 6, for instance.

          That's funny -- my experience has been the exact opposite. Many folks (ie, companies) I know are dragging their heels on the EL7 migration (far more than they did from EL5 to EL6) and systemd UNpredictability, UNreliability and greatly increased race conditions has been a big part of that. (The other parts are either firewalld-based, the large number of other changes that happened, or general enterprise conservativeness.)

          I honestly wouldn't be surprised if EL7 ends up as the Windows Vista of the Enterprise

          • by Junta ( 36770 )

            I will confirm that on my end, I'm still having to support a *lot* of new deployments on EL6. By the time EL6 was this old, *new* deployments of EL5 were pretty much unheard of.

            I will say I have not questioned them as to why. systemd certainly stands tall as one difference, though it could be a more 'el6 was good enough', and generally the upgrade treadmill has been slowing down as the industry has 'grown up' with linux (same curse as microsoft, who faced more and more uphill battles upgrading their custo

  • Open source certainly is a business for Red Hat - they charge a ton of money for it!
    • by infolation ( 840436 ) on Monday September 25, 2017 @08:20AM (#55258603)
      Money is the reason companies trust Red Hat, not 'boringness'.

      Paradoxically, companies find free things scary. When a supplier charges for a product or service, companies feel the supplier has a greater contractual obligation to provide what was asked for.
      • by Junta ( 36770 )

        I'd say it's both.

        Churn is the enemy of the enterprise. A comfortable feeling that their staff will only need to retrain every 5 years or so, and even then it's not going to be particularly severe is important.

        The businesses that are ready to push the envelope and get the latest and greatest technologies at a breakneck pace do exist. The problem being that such companies aren't interested in paying an external company like RedHat for support, they want the talent in-house. Even in theory, efforts to supp

      • Paradoxically, companies find free things scary. When a supplier charges for a product or service, companies feel the supplier has a greater contractual obligation to provide what was asked for.

        My large national Fortune 500 company uses both RedHat and Microsoft contracted-service products at very high tiers. Guess which one we hardly ever need the service, yet they provide it in an instant to us? And guess which other usually can't be the least taxed with picking up our phone calls for support? RedHat has been a solid supporter of our IT operations.

  • by Anonymous Coward

    Red Hat remains an anomaly -- it makes money in open source.

    IBM makes money in open source. Hell, so do Microsoft. In all three cases (and many more) it isn't the license to the software that's the product. That's all.

    • by Junta ( 36770 )

      I think the point is pure-play open source companies. IBM nor Microsoft are anywhere near pure-play open source. Open source is largely incidental to their value proposition when it comes up.

  • FWIW (Score:4, Insightful)

    by coofercat ( 719737 ) on Monday September 25, 2017 @08:54AM (#55258731) Homepage Journal

    FWIW, I tend to agree - most of my recent jobs have been on Centos* - it's whatever it is, and it does that thing pretty well. The devs complain because they can't get QT to work on it, or some other 'shiny', and that "we never had these problems when we used ubuntu", but Centos offers long supported lifespans, decent update schedules and for the most part it's pretty solid (I found a machine not so long ago with process that were 6 years old on it - that's pretty awesome, even if it's a complete security fail).

    So yes, Centos is good for what it does, and so Redhat is good for making it. How Redhat really benefts from all this Centos is not really clear though.

    * one such job was at a very wealthy stock traders. I did have something of a moral objection that they were cheaping-out on Centos (which at the time wasn't sanctioned by Redhat, and so we had a few problems upgrading the OS). It's harder to begrudge a 5 person company doing that, and I'm not sure where on 'the scale' my objection would sit. Either way though, Redhat still aren't getting much out of the deal.

    • by Junta ( 36770 )

      Particularly from the perspective of having to support devs from *entirely different companies*, supporting folks is a pain. Over a half-dozen iterations of Ubuntu are likely, and beyond that a myriad of random ppas and random install-from-tarball or gems or pypi...

      Supporting customers on CentOS/RHEL is so much easier because we generally only have to support two camps for new software: RHEL6 and RHEL7. Of course some of my python devs *hate* having to continue to be compatible with python 2.6 for the sake

      • by Junta ( 36770 )

        I will also say that this isn't a horrible thing for those using Ubuntu or Debian. It's just that it's best to live with efforts to support RHEL being close enough to support Ubuntu for free, and some self support to bridge the gap.

  • I'm glad to hear that Red Hat has revenue sources outside of the operating system, as Red Hat is, for better or for worse, a standard-bearer for Linux. That said, we can't finish our migration away from that monstrosity fast enough.

    I used to think that Debian proponents were just jealous that Red Hat was the leader, and stayed with Red Hat for years; but after having given Debian a trial-run (initially through Ubuntu, then Kubuntu, then Debian servers) several years ago, I realized how wrong that thought w

    • Re: (Score:2, Insightful)

      by Anonymous Coward

      Debian servers are a breeze to manage, because everything is consistent and well thought out.

      That Debian is long dead. Debian 8.0 Jessie included systemd. At some point the default desktop was switched from Xfce to GNOME 3, too. Once those things happened Debian essentially became a clone of Fedora. The main difference between the two is that you type "apt" to install packages when using Debian, and "dnf" when using Fedora.

      In my experience, the Debian of today is a pathetic imitation of what Debian used to

  • "Red Hat remains an anomaly -- it makes money in open source." I still think the biggest flaw in the open source model is that too many people think that all software should be free (as in free beer). Somebody spends massive amounts of time and money to get some software working really well and customers won't pony up an even trivial amount for a license. They would rather dump your elegant solution for a half-baked one that happens to be free instead. When there is almost no money to be made, where does th
  • Really? Speaking as a programmer and systems administrator, who actually wants it to be "exciting", and why? Certainly, what you *do* can be exciting, from writing new systems to pr0m, but why would you want the o/s and all the tools to be "exciting"?

    Do you *like* an o/s that crashes, that doesn't do today what it did perfectly well yesterday, due to last night's bugfix/bugmake update? Will it work again tomorrow?

    And for the huge numbers of people who use, or want to use it at work, "exciting" is utterly th

    • Nobody is looking for "exciting" in the breakfix sense, per se. But product teams and devs are looking for cool features for their users. This will help them with checklists full of buzzwords, but it's in detriment of the stability of the product. The rest of this post may or may not reflect what's happening at your company, but it's reflected on a larger scale of failures seen all over the place prioritizing "cool/exciting/BROKEN" over "stable/boring." Then, forcing it on your users by stopping support for

The time spent on any item of the agenda [of a finance committee] will be in inverse proportion to the sum involved. -- C.N. Parkinson

Working...