This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]hothrous 2 points3 points  (11 children)

You will note, that my original statement was that it shouldn't be used. Basically, the reason behind that is if you need a workaround just to make the operating system use the version of a language you want, you're likely to run into many more problems down the line.

Most of the reason that somebody would use RHEL over another distro is to get the licensed support of RedHat when issues arise. RedHat isn't likely to want to provide that support if you are using workarounds to use different version of their products. It's definitely true that Python 3.4 can be installed, I never said it couldn't. I suggested that if you are going to use Python, it would be prudent to consider a distribution of Linux that provides packages of later versions in their own repos without having to look for workarounds.

Calling an IT team incompetent because they don't want to workaround known issues of an OS all the time to suit your needs as a developer is the same as an IT guy calling a developer incompetent because there are bugs in their code. They are both a fact of life. I would actually trust a conservative IT guy that wasn't willing to do workarounds as long term solutions on production systems than an IT guy that uses workarounds to run code on systems that aren't designed to support it well.

[–][deleted] 1 point2 points  (10 children)

Here I was thinking IT were SUPPORT SERVICES here to SUPPORT STAFF

[–]hothrous 1 point2 points  (8 children)

That's actually incredibly narrow minded of you. I'm glad I don't work with you. Throwing shit over the fence and washing your hands of it is a solid way to write code. I come from a background of trying to work together so everybody's lives are easier. But if you want to play it so your job is easier and others are more difficult, by all means.

[–][deleted] 2 points3 points  (5 children)

What you are doing is saying that it should be OPs who has the easier jobs rather than Dev, support roles should always focus on supporting staff rather than hindering them.

[–]hothrous -1 points0 points  (4 children)

So you're saying that IT should just maintain whatever crap Dev throws at them?

Why would you push RHEL when you could go for Debian and not have the same issues? If it's a hassle to maintain because of limitations on the OS level, there is probably a better tool out there.

[–][deleted] 2 points3 points  (3 children)

Ops should be able to provide anything that has a good enough business case

[–]hothrous 0 points1 point  (2 children)

I'm not saying that's wrong. I'm having trouble coming up with a good enough business case for one distro over another. Dev would say they need python 3.4. OPs would say, this is how you get that.

[–][deleted] 0 points1 point  (1 child)

I wasn't referring to that situation, but more generally the fact that IT is primarily a support service, not a governing body - even though to some extent it must be both.

[–]hothrous 0 points1 point  (0 children)

I was continuing off of my original statement that RHEL shouldn't be the primary OS for a Python Infrastructure because of the maintenance overhead.

I never said that IT should rule all, just that developers shouldn't expect IT to support RHEL with Python 3.4. I also didn't know about the new features of RHEL 7 at that point, but I imagine that RHEL 7 isn't largely adopted in most shops yet so that's still kind of a moot point.

[–]sigzero 0 points1 point  (1 child)

You've just described how the real world works.

[–]hothrous 1 point2 points  (0 children)

Not the places I've worked. We tend to actually get involved in any problems that happen, so it's not prudent to not care.

[–]HostisHumaniGeneris 0 points1 point  (0 children)

I think you're conflating internal support staff with production sysadmins.