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

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."

Comments

Gnome 3 & systemd

[Hognoxious]

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

Re:Gnome 3 & systemd

[jellomizer]

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.

Re:Gnome 3 & systemd

[Junta]

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.

Re:Gnome 3 & systemd

[Junta]

It's a simple reality:

'read me the output of systemctl status httpd' is much easier than trying to get them to grep through /var/log/httpd/ file.

In general, the move away from free-form text config and log files enables a huge number of these commands to rattle off. Commands that aren't any more capable than use of sed/grep/etc, but much much easier to tell people what to do.

Knowing use of the text utils combined with plain text things enables the text based strategies to be more discoverable and knowledge to be more generally applicable, but hard to convey that to others. Also doing things with the text strategies can lead an admin to do less robust things that will fail, so it's not entirely without justification apart from support.

Re:Gnome 3 & systemd

[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.

Re:Gnome 3 & systemd

[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! 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. Yeah, it's still around, but it's generally ignored and smart people use something else.

Re: Gnome 3 & systemd

[hey00]

Every major Linux distro adopted systemd. You are probably smarter than all of them, but maybe there is another option.

Yep they did. Why? Because RH has a long arm, because more and more stuff depends on it, and because it's easier to maintain by distrib maintainers.

The distrib maintainers made a smart choice, from their point of view, for their interest. That doesn't mean systemd is better for their users.

At the end of the day, we are left with less choice than we had before.

Re:Gnome 3 & systemd

[bill_mcgonigle]

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.

Re:Gnome 3 & systemd

[Junta]

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.

Re:Gnome 3 & systemd

[Etcetera]

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 community... Skipped by anyone who has any option to do so.

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.

Parallelism is indeed easier (as it should be, since that was the goal), but it's the appropriate solution in far fewer cases than one would think, often for little benefit. Parallelism in startup often increases risks of issues, depending on the daemon you're using, puts increased load on spinning disks ("We're not going to support readahead any more because all our laptops have SSDs!"), and resulted in a whole host (no pun intended) of intermittent, hard to isolate bugs for years before things shook out.

The only other thing systemd does *well* is cgroup isolation. But there are other ways to deal with that that don't involve all the other drawbacks, feature creep, and change that the rest of the systemd project has brought down.

I'm sure there is some edge case where systemd doesn't work, but that's fine - there's nothing stopping anybody from booting that, and hire third-party support if/when required.

Yes there is. Do you not understand what EL is? If the systemd "cabal" had wanted to allow choice in process launching/supervisor system, they would have had systemd hanging off of the existing init process a la xinetd to give it time to mature. As-is, they couldn't wait to burn the ships like Cortez and attempt to lock people in to systemd as soon as possible. A lot of smart people worked on Devuan and it still took a year to unwind systemd from the system. (This goes especially harshly for those with a need to run a GNOME environment on their systems.)

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.

I'm happy that systemd seems to work for you. We (users and sysadmins who were pretty fine with deterministic, shell-scripted, predictable boot initialization) would have preferred you isolate your code away from the rest of the community. If Fedora and Ubuntu wanted to have systemd as the preferred init system for their laptop-focused distributions, hey more power to them. But server administrators never asked for this crap and got it foisted on us against our will.

Re:Anamoly

[Austerity Empowers]

Their model is like this: News reporters work for free to create news stories. Then Red Hat delivers the newspapers to customers and charges for delivery.

The reporters work for free, but the editors, typesetters/web-publishers, press operators and delivery workers do not. Basically the parts of the job that aren't any fun.

's like a law firm where the janitors and legal assistants get paid, but the lawyers don't.

Lawyers hate themselves and their jobs, for the most part. They wouldn't be the kind of low-life scum they are but for the money. Not to mention actual costs lawyers have to do their jobs from legal fees to research to insurance. They will be paid or they will not do their job.

Not true for open-source developers which often do what they do simply because they can, or moon light under some pseudonym to avoid clauses in their employment agreements. It's FUN to develop and design. It's really not fun to turn the crank that makes those designs actually work for real people, to wake up in the morning and look through your issue tracker and fix your shit, etc. This is pretty much the same reason that "linux on the desktop" is always in the near future but only arrives in the present when some company (like Canonical) tries to make it happen. Once developers get the UI *they* want, they're done and walk away. It takes a lot of work to turn that UI into something that works for a larger audience of people whose jobs involve different things that the developers don't see or understand. That work isn't fun, so people have to be paid or won't do it.

This may be the shape of things to come. Quite a lot of technology can be summed up as "things that are fun to do, that we'd do for free" and "things that take a lot of work, that we hate doing". The former category has, in my observation, become somewhat harder to get employed for and is often contracted out, while the latter category ends up being fully staffed and internalized. This is true for open source or not.

Re:Where is the wheelbarrow?

[infolation]

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.

Re:Anamoly

[Junta]

Actually, relatively speaking they pay more open source developers than other 'open source' companies.

Now there are companies that pay for more open source developers, but of the ones seeking to use Open Source as the basis of their business model rather than incidental to their mission, RHAT is ahead.

This is one of the reasons why when RHAT declares a move, the other business oriented distributions have little choice but to follow, as they lack the resources to do much.

FWIW

[coofercat]

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.

Re:Where is the wheelbarrow?

[Mr Foobar]

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.

Re:Good For Red Hat

[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 be, before the systemd and GNOME 3 stupidity. I had used Debian for well over a decade before it was infected with systemd, on many workstations and servers, and the only time I had a problem getting it to boot properly was when a hard drive was dying and corrupted some of the init scripts. Systemd, on the other hand, caused me many problems that weren't due to hardware failures, but rather due to idiotic problems with systemd's philosophy and behavior.

FreeBSD is the best alternative for getting a traditional Debian-like experience these days. In many ways it's a lot better than Debian ever was. Once you get exposed to FreeBSD's excellent ZFS support it becomes painful to use Linux. FreeBSD's proper init system is also a huge win. Moving the servers and workstations I manage from Linux to FreeBSD took some effort, but in the end it was well worth it.

And don't even bother mentioning Devuan. In my experience it's an amateurish joke. It's not even worthy of consideration.

Not quite

[emil]

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.