[Bf-committers] Minimal Blender specs - 5 year old systems & OS

[Chad Fraleigh]

On Tue, Jan 29, 2013 at 3:59 PM, Campbell Barton <ideasman42 at gmail.com> wrote:
> On Wed, Jan 30, 2013 at 9:53 AM, Chad Fraleigh <chadf at triularity.org> wrote:
>> On Tue, Jan 29, 2013 at 7:11 AM, Thomas Dinges <blender at dingto.org> wrote:
>>> I can only fully agree with this.
>>> It becomes a pain to support old systems, especially Windows XP and old
>>> GPUs.
>>>
>>> Not only do we support hardware / software longer than other 3D
>>> software, as Blender is free people can also always stick to an older
>>> version.
>>
>> A question then.. if some older versions use bundled libs with
>> security bugs in them, how do they use blender on old hardware without
>> the risk of being hacked (perhaps just from opening an image file)?
>
> They would have to build (or get someone to build) an older blender
> version linking to newer libs.
> This shouldn't be too hard, I still have 2.49 building on arch linux
> with recent libs.

What about windows? While some blender users could eventually figure
out how to do everything needed to compile an old svn branch with
current(ish) trunk libs.. most I expect wouldn't have a clue what MSVC
or MinGW is (they just want to be artist -- or at least "play one at
home").

I can imagine cases where parents give their older computers to their
[younger] kids, since they'd be less worried of being broken.. and if
we'd like those kids to become hooked on blender. ;) Same for schools
that might not be able to upgrade computers as often due to budget
cuts. If M$ can give schools free or cheap software to try trick kids
into using their junk, why not ensure as many of them also use
something useful (the CG movie market isn't going away any time soon).

So if blender officially drops support for old hardware in trunk,
would it be unreasonable to at least continue limited support for some
of the older versions (i.e. 2.49, 2.59, eventually 2.69, ...)? At
least when there are security updates for ones they had bundled (when
the corresponding libs in trunk get updated), or if a serious security
hole is every found in the blender code itself. So we might (well,
definitely if freetype gets fixed in them) have a 2.49c (and so on)
binary release. Of course for any platform where a patch doesn't
affect it (maybe it was a standard system lib for that OS), it would
just skip that patch version (e.g. windows might get a 2.49d while
linux stayed with 2.49c, then later linux (and others) would have a
2.49e (where applicable). This is why I've mentioned that I think each
release should have a "bundled lib" manifest included with each
build/install so that anyone can see what versions of what are there..
it would also make things like this easier to track.

Also, re-reading part of the initial statement regarding GPU's.. Maybe
we would want older GPU support (in some form). I mean you hear about
someone that took and made a high scale cluster out of some legacy
hardware now and then. With cycles having parallel support, it would
be nice [for some] to use cheap[er] hardware in a cluster (or at least
one to augment their workstation). Does blender have built-it support
for offloading rendering yet? I know I've seen add-ons for some, but
typically are 3rd party renders. It would be cool if, out of the box,
one was able to run a blender process in background on one or more
machines, then just configure their workstation blender with the other
host names (and maybe ports, auth key) and it would just use them. No
complicated cluster config, extra software, or anything like that.
Just a [pipe] dream thought moment there. =)

Oh, and if GPU (well, really co-processing hw in any form) support was
more generalized [long term] to be able to support a wider range of
venders (still just Nvidia?), it may need less overhead to support
legacy GPUs (with-in reason of course).


-Chad