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

[Campbell Barton]

On Wed, Jan 30, 2013 at 4:56 PM, Chad Fraleigh <chadf at triularity.org> wrote:
> 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

Hi Chad,
If theres enough interest to support less common setup's (including
other operating systems or older hardware), making blender builds
available shouldn't be so difficult, blender remains very portable if
you accept switching off some library dependencies.

As for maintaining older blender versions, I'd guess there isn't much
developer interest to do this, but if someone was motivated, I don't
see why not.
Personally I prefer to support disabling features as build options so
`lite` blender builds can be made from the latest source. These should
run better on systems with limited resources.

-- 
- Campbell