Slashdot Mirror
How Red Hat Can Recapture Developer Interest
snydeq writes: Developers are embracing a range of open source technologies, writes Matt Asay, virtually none of which are supported or sold by Red Hat, the purported open source leader. "Ask a CIO her choice to run mission-critical workloads, and her answer is a near immediate 'Red Hat.' Ask her developers what they prefer, however, and it's Ubuntu. Outside the operating system, according to AngelList data compiled by Leo Polovets, these developers go with MySQL, MongoDB, or PostgreSQL for their database; Chef or Puppet for configuration; and ElasticSearch or Solr for search. None of this technology is developed by Red Hat. Yet all of this technology is what the next generation of developers is using to build modern applications. Given that developers are the new kingmakers, Red Hat needs to get out in front of the developer freight train if it wants to remain relevant for the next 20 years, much less the next two."
From working in Linux-based IT for nearly a decade now, IT departments get very frustrated by Red Hat's package management and the concept of needing both an Entitlement and various Channels to get updates; on the flip side of this summary is Ubuntu, which IT departments can't stand due to it's constant change and instable nature. Every IT department I've worked in and with seems to prefer administering and deploying Debian and battles with devs on Ubuntu and management on Red Hat.
Every one of these is supported by Red Hat. Call them out for other things, but do your research first. I'm upgrading MySQL from 5.1 to 5.5 and many of these are specifically in new Red Hat Collections.
https://access.redhat.com/documentation/en-US/Red_Hat_Software_Collections/1/html-single/1.1_Release_Notes/index.html#sect-Installation_and_Usage-Install
I don't think that's a cut-and-dry sort of thing. As a developer, I hate the fact that Ubuntu is changing so quickly that I can't keep up. Leading edge is fine, but bleeding edge gets blood everywhere.
The great benefit of Red Hat is that it's stable and supported for a very long time, like 20 years. They don't change anything major in a release, and releases are few and far between. This is great for 'Enterprise' stuff, but the web is moving quickly and package support for RHEL boxes isn't great.
Having said that, where I work we have lots of stuff on RHEL/CentOS, and more and more stuff on Ubuntu. The Ubuntu stuff keeps me awake at night - literally. It's always falling over. I have never experience a kernel like the one the Ubuntu team are putting are. It's absolutely atrocious. The biggest problem is that the software we need to use has better support for Ubuntu than RHEL, so we're stuck using a dire OS to run it on.
The RHEL and CentOS boxes we have are rock solid stable and have never really given us significant issues. I walk into the office and get a new Ubuntu problem every day.
(FWIW I use Debian for all my own stuff exclusively, so I know my way around Debian-derivatives - this isn't a configuration issue).
That last sentence should have been, "....remain relevant for the next two years, much less the next 20."
Ask a developer who has recently made or tried to make the transition from Windows to Linux and they expect inconsistency, plus doesn't everyone use it? Ask a seasoned Linux dev and they wouldn't touch Ubuntu with Bill Gates' $INSERT_APPENDAGE_HERE
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
The tension is stability versus the latest tech. RedHat purposely moves very, very slowly. The same can be said about Debian stable. As an admin I like slow moving targets. The problem is that developers want to use the latest stuff. So what does RedHat do about this? I think they are trying to solve it in two ways. First is their Software Collections. These are packages that site outside the base OS and are easy to pivot to the newer version. This allows for multiple versions of things like Python to be installed in parallel. Very handy!
Another thing that is helping quite a bit is Docker. RedHat is big on Docker. By packaging containers as apps, this allows a developer to easily control the dependencies outside of the OS that the app is running on. This makes everyone happy! Fedora is tracking some interesting tooling with Docker (geard, os-tree).
I like that RedHat tries to solve bigger problems than just packing and releasing a distro. They are trying to make things manageable (see FreeIPA, OpenLMI, RDO, CloudForms, oVirt)
Personally, I like RedHat. I like Debian. I run Fedora on my desktop and notebook. I maintain a CI/CD pipeline on RedHat at work. I never jumped on the Ubuntu bandwagon. It seems to me that Ubuntu has made quite a few more mis-steps in their short existence than RedHat has over the years. I get the feeling that a lot of people are just dropping back to Debian, which is just fine with me!
Why? Red Hat has been the one distro that spearheaded Linux adoption in the enterprise. It's stable has very long support life cycle and if you do not want to pay licensing you can (and many startups do) use Centos.
I hear people complaining about rpm/yum. Guess what. Many of us have extensive experience with it and have no problems with it. Creating repo cache is fairly easy and allows you to have a total control of what is deployed to your server. And yes I do like dpkg and apt-get. They are very nice tools.
The main reason I see ubuntu getting traction is because of RedHat making RHEL not available for download and because developers got their first steps in ubuntu. because "it's easier" and has a nicer "desktop".
I think RedHat needs to backpedal in Fedora/RHEL and go back to a single distro. Something like *Desktop/Developer edition (RHDE) and *Enterprise Edition (RHEL) and build a nice and focused distro with all the common repos already enabled in RHDE. So that newbies can have a better experience. Developers need to easily get running thing need on a fresh build of (RHDE). Something like this: yum install passenger-puppet-master (and bam!) yum install maven
yum install django
yum install passenger-rails-app
yum install saltstack
yum install eclipse-openjdk-stack
Just a few samples but you get the idea. Make it easy for the developer and they will come.
BSD licensed software can't be stolen....
I think you're kind of missing the point. Developers don't think "hey, I know Ubuntu/Mint, and it works great for me, but yum just got a little bit friendlier? Forget everything I know, I'm installing Red Hat."
People change distributions with a purpose. For me personally the odyssey was:
Mandrake: because (I kid you not) it came on a CD in a Linux magazine
Gentoo: because of the performance gains
Mandrake: because (unlike Gentoo) you don't have to spend half your life compiling
Ubuntu: they did all the annoying stuff (eg. making Flash work) for me
Mint: Shuttleworth gave the middle finger to Ubuntu community vs. Mint 3s their community
The point is, no one is going back to Red Hat unless it offers something significant that their current distro doesn't (besides just yum). Making Red Hat one distro instead of two doesn't give me a reason to leave Mint. Making yum friendlier doesn't give me a reason either. At best changes like that might help stem the tide of departing Red Hat users ("why do I need Ubuntu, Red Hat finally got friendly") but if Red Hat ever wants to become a dominant distro again they have to offer a compelling reason to switch.
Agile developers expect agile everything. Ubuntu happens to just be a happy compromise between agile and waterfall.
If you look at RHEL, it's 5-10 year old packages, kept alive by an enormous engineering team that backports fixes to old, dead software, which creates a huge pile of technical debt for any developer trying to use "modern", highly modular frameworks.
As far as developers go, In the Ruby, Python, and Node ecosystems, anything that's not the latest doesn't exist. They don't use the system package management, they use gem, pip, and npm. They really don't care about the underlying OS, until it gets in the way, and getting in the way is exactly what a decade-old OS does.
Just to throw out an example. Take some modern ruby on rails application, say Discourse. (discourse.org). Go download a tarball from github. Now try to make it work with nothing but software from the official RHEL repository. Let me know how that works out for you. After you tear out all your hair and skin trying to do that, try to get the pieces from 3rd party repos that will make that work. See how much you have to bring in as far as new libraries and new packages just to make it work. It's still a nightmare even with the 3rd party repos, and that RHEL support contract doesn't cover them - every single piece that's likely to break your application, is now outside of your support agreement, so your company is now wasting at least $799/year for support.
As soon as they start trying to develop on RHEL, the dirty hacks start. There are things missing - the versions of software that they need to make their dependancies work don't exist on RHEL. They end up in a kind of dependancy hell fighting with libraries that are a decade too old to compile their dependancies. One thing leads to another. Eventually, you recreate an entire current OS in /usr/local, or install one piece by piece from 3rd party repositories. At that point, it's not RHEL anymore. It might still say it's RHEL, but it's a bastardized system that looks more like an evil child of Gentoo and Fedora. (both of which are fine distributions by the way, just they aren't meant to crossbreed). The only thing you have left of RHEL at that point are the parts your application doesn't care about, which is probably not much.
Or, you can attempt to containerize with kvm, chroots, or lxc, which, while not breaking the underlying system as badly, means the application is really running on something other than RHEL.
If Red Hat wants developers back, they are going to have to be able to deliver a product with an agressive delivery schedule, maybe even a rolling release, and be able to deliver the kind of support to make operations feel good. That's a whole new territory, that nobody has touched yet, but if they are up to the challenge of keeping decade old software on life support, they are probably up to the challenge of an agile OS.
The whole point was that developers influence the choice of distro on the server
There must be cases where this is true. However, it's really unclear to me why most developers would care and why they would feel themselves qualified if they have competent sysadmins to work with.
When I've got my sysadmin hat on, most of the developers I work with are developing on Macs. They have no hangups about their code being deployed on EL systems in a big data center. Nobody is clamoring for a shelf full of MacPro tubes to deploy on.
When I've got my developer hat on, I usually write on a Fedora machine. But I'm not daft enough to try to run Fedora on a server and have to worry about the maintenance cycle. I put my configs in a puppet module that pushes the code out to whichever VM I'm going to run it on, regardless of the OS, hypervisor, hardware, or country that code is bound for.
If my code doesn't run on a particular distro, then my code is probably broken (or my devops is hosed).
Maybe there are some startups with a bunch of kids and one third-careeer CEO and they all tell him what's going to happen. Good for them, I guess. Someday a sysadmin might come in and help them fix their stack. Let's not speak of the failwhale.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
It's very hard to avoid a snarky response, but I'll try.
* Developers are not kingmakers
* Developers are not system administrators
* Developers don't understand operations
* Developers often don't understand scale engineering unless they can abstract it away by not thinking too hard about anything
* Red Hat Enterprise Linux (and its derivatives) are not intended to be shiny new, but to be reliable
* Use Fedora if you want bleeding edge, or re-package things yourself. RPMs aren't hard.
Hire a Linux system administrator, systems engineer,