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."
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."
Re: You seem like a flaming faggot. (Score:2)
Cramming stuff in a man's ass will massage his prostate, which is pleasurable. Females don't actually have a prostate. So, men are more able to enjoy stuff rammed in their ass than females. It's just basic biology.
I know you're now going to be curious about this. I recommend you try first with a zucchini.
Gnome 3 & systemd (Score:4, Funny)
Gnome 3 & systemd aren't boring, more's the pity.
Re: (Score:2)
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)
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: (Score:1)
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)
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
Re: (Score:2)
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:
Perhaps you should get the latest on the breaking news.
Re: (Score:2)
Now it's "We've got our design, if you don't like it..."
I see your concern, but the systemV vs systemd debate in Debian showed that keeping both systems as options was not practical, since the maintainers will have to maintain both systems, which is expensive. It is unreasonable to demand people to maintain options just because you in particular want to. What you need is a momentum of consensus (at least in community projects). It's just that right now I don't see any of the switched distros moving back to SystemV or OpenRC any time soon. What are the long term
Re: Gnome 3 & systemd (Score:2)
I'd wager you're a poor developer. Why? You'd know nothing on your computer is random, other than by name, if you were a good developer. At best, you have pseudo random and unpredictability. Neither is really random, however. Very few things, if any - depending on your school of thought, are random. The breakage of systemd is, by no means, random.
A good developer would know this. Maybe you'll find Windows to be a bit easier? Then again, judging by your comment, I doubt that you're a developer or that you us
Re:Gnome 3 & systemd (Score:5, Informative)
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: (Score:1)
""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.
Not quite (Score:3)
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.
Re: (Score:2)
Re: (Score:2)
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.
Re: (Score:2)
Still if you hose up a system with over configuration and say to a point where you need to reboot, then you bring down everything just to fix one application.
Re: (Score:2)
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
Re:Gnome 3 & systemd (Score:4, Insightful)
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 (Score:4, Interesting)
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: (Score:2)
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: (Score:1)
"systemd was designed for support staff" is the lamest anti-systemd conspiracy theory ever.
True.
There's no evidence systemd was designed at all.
"Oh, crap. Didn't think of that. Now we need our own kernel-based DNS system because we didn't think ahead!"
Re: (Score:2)
While there are good practices in there, it's not exactly a good thing to say 'it's ok if things are more likely to go to reinstall than before because best practices means low risk'. The even better thing is 'still as unlikely to need reinstall, but even if you do it's no big deal'.
Re:Gnome 3 & systemd (Score:4, Insightful)
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 (Score:4, Insightful)
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: (Score:2)
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
Re: (Score:2)
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
Re: (Score:2)
Wouldn't a competent administrator already know that bar has to be started before foo, and then add that to systemd?
Re: (Score:3)
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
Re: (Score:2)
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
Re:Anamoly (Score:5, Interesting)
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:Anamoly (Score:5, Informative)
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.
Re: (Score:1)
What "peace of mind" do you get? CentOS issues the same security updates that RedHat does, they track upstream closely. You're paying for a bunch of RedHat tools that you aren't using in a single-node instance, and some gui tools that simply aren't all that worthwhile.
For someone with such a tight budget, I'd suggest you use the free alternatives as much as possible. Paying for RedHat is stupid for a single-node home use. Seriously, I thought you were a miracle worker. Miracle workers don't need to pay
Where is the wheelbarrow? (Score:1)
Re:Where is the wheelbarrow? (Score:4, Insightful)
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: (Score:2)
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
Re: (Score:3)
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.
No anomaly (Score:1)
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.
Re: (Score:2)
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)
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: (Score:2)
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
Re: (Score:2)
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.
Re: (Score:2)
It's one thing to do software collections to yourself for the sake of getting your pet python project to work.
It's another thing to *require* a customer to do it. Software collections aren't an utterly trivial thing like 'use the python that comes with the base repo'
We have some internal use of software collections and it's not for the faint of heart. The nature of the beast is that the 'normal' python working is priority #1 for the os, and software collections have to inevitably work around that. Softwa
Good For Red Hat (Score:1)
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)
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
Too bad it is an 'anomaly' instead of common (Score:2)
Who actually wants "exciting"? (Score:2)
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
Re: (Score:2)
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