> On Mar 19, 2015, at 3:18 AM, Russell Keith-Magee <russ...@keith-magee.com>
> wrote:
>
>
>> On Thu, Mar 19, 2015 at 2:27 PM, Mike Dewhirst <mi...@dewhirst.com.au> wrote:
>> Maybe ... some effort to solve the infrastructure issue would make it worth
>> kickstarter funding.
>>
>> A couple of colleagues are pushing me towards Docker as a packaged Python
>> 3.4 environment but that is beyond my interest atm.
>>
>> I am running a dedicated production server on Ubuntu 14.04 which more or
>> less forces me to stick with Python 2.7. I would like to move to Python 3.x
>> using virtualenv but I don't want to mess with stuff which is working.
>>
>> Maybe a really nice solution would be a kickstarter project to develop a
>> deployment tool to create a predictable, supportable modern environment on
>> "old" boxes and to vaccuum up the existing Django sites running on bare
>> metal.
>>
>> In my case, Ubuntu does support Python 3.4 (I think) so the virtualenv
>> approach would be covered by standard Ubuntu support. I have only glanced at
>> Docker so I don't know how valid that might be.
>
> Docker isn't needed for any of this, especially on Ubuntu 14.04. Python 2 and
> Python 3 can co-exist, and Python3.4 is part of the standard repo for Ubuntu
> 14.04. Even if it wasn't, you could install Python to a user-space directory,
> and create a virtualenv based on *that* version of Python.
>
> However, in a broader sense, I think you'll find that the audience of people
> who need this tool are almost by definition the set of people who wouldn't be
> able to use it.
>
> If a company is locked into Python 2.6, it's because they're on a Enterprise
> Supported Version (tm) of some operating system; in that sort of environment,
> installing and using *anything* that isn't provided by the vendor is a
> non-starter. Even if a tool *was* developed, you'd need to get it deployed
> in-channel - and that could take years... or you could just upgrade your
> system :-)
>
I think you'll find that this is a bit overstated. Customers install plenty of
software that isn't provided by Red Hat. I think you might be amazed at how
popular the public Extra Packages for Enterprise Linux repository is (it's a
sub-project of Fedora that provides many packages from the Fedora collection
built for RHEL).
What they don't do (except in dire need) is install alternative versions of
software that *is* provided by their support contract. This is because for most
companies, the added features aren't worth the self-maintenance. No one who
isn't an OS vendor can keep up with the security issues on all of that software.
> FWIW: This is the exact type of problem that RedHat software collections are
> designed to fix - RHEL wore a lot of flack for being so pathologically behind
> the times (the Python interpreter being one key component). RedHat's response
> has been to introduce software collections - an officially mandated set of
> tools that can be updated much more regularly, official blessed by the
> manufacturer.
>
> https://access.redhat.com/documentation/en-US/Red_Hat_Software_Collections/
>
> Obviously, this won't help if you're not on RHEL6 or 7 - but it's an
> indication that some enterprise vendors are listening.
>
Yes and no, but it's not much of an answer because the double-edged sword here
is that the Software Collections also have a much shorter supported lifespan
than the main operating system (which guarantees a stable platform for at least
ten years). For most companies, rebuilding "that one internal app we maintain"
every three years is unrealistic. Not everyone is Twitter or Netflix, doing
multiple deploys an hour.
Speaking anecdotally, the average lifetime I've seen of customer-produced
internal apps is usually about 7-8 years (generally equivalent to whenever they
moved to the latest RHEL release until the moment it goes out of support...
sometimes past that, unwisely). You do not want to know how many datacenters
are still running RHEL 4 and even RHEL 3.
> Yours,
> Russ Magee %-)
>
> --
> You received this message because you are subscribed to a topic in the Google
> Groups "Django users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-users/B74QJaqA0b4/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/CAJxq848g%2BUavE0giY2cogrh%3DwY2OzxbeHX9Bv0_SXFD0v0L0oQ%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/4F0DADE6-C0AE-4EDB-9EEF-29F8C40A0A4C%40gallagherhome.com.
For more options, visit https://groups.google.com/d/optout.
