On Jan 17, 2022, at 3:52 PM, Neal Gompa <ngom...@gmail.com> wrote:* ASWF is attempting to maintain a development platform and runtime alone
--
You received this message because you are subscribed to the Google Groups "vfx-platform-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vfx-platform-dis...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vfx-platform-discuss/CAEg-Je9bxEz4yhSaOfqwdGmOidtiqzC2wNGB-b64CquTnd9y8g%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vfx-platform-discuss/CAAoNwLSnYrdwxGrG1qb%3DH3wzVD6SRDdy3Yu6P3H7OG9QiRyjfg%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "vfx-platform-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vfx-platform-dis...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vfx-platform-discuss/CAEg-Je_4S0tHzf4%2BhV%3DPr%2BTKe92k_apFL2-bjj7kPWTbrxq%2ByA%40mail.gmail.com.
Currently, we have shows using VFX Platform 2017 all the way up to cy2021 going on at our facility right now depending on the current lifecycle of the show.
To view this discussion on the web visit https://groups.google.com/d/msgid/vfx-platform-discuss/CAOOm49RNdjGkQ087ABdnMSAoK8t_sX35pNhvNPzt8PjkbNcRuA%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vfx-platform-discuss/CAOZ7%3DV3DzAaO3SX%2Bo7B0VxrVE%2B_4wNy4Qu7KvA6awZRx2M0r7w%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "vfx-platform-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vfx-platform-dis...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vfx-platform-discuss/CAEg-Je_4S0tHzf4%2BhV%3DPr%2BTKe92k_apFL2-bjj7kPWTbrxq%2ByA%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vfx-platform-discuss/172C617C-4827-47C5-B1A3-ED6DD01106DE%40larrygritz.com.
Out of curiosity, has anybody explored rootless container runtimes as a way of running DCCs in hyper-controlled environments?Is anything holding this back technologically? (Is the GPU support very poor for example? I remember Nvidia had some containerized GPU passthrough support years ago, but never tried running anything too advanced on it.)
--
You received this message because you are subscribed to the Google Groups "vfx-platform-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vfx-platform-dis...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vfx-platform-discuss/fb6e4784-61ef-413d-ac73-8826faae54c0n%40googlegroups.com.
My 2 cents - with the caveat that I am a developer not an IT
person, last thing I want to have is an opinion on containers...
That said, whatever you decide, as we support like 15-20
applications with maybe over half of them with some linux version,
so eventually what you decide indirectly affects us, SO might as well have an opinion, seems the
best idea is to stick to a downstream version of RHEL. Right now I know of but have not used them, Alma and Rocky Linux that showed up to fill the gap of CentOs going upstream from RHEL. That
is already 3 guaranteed to be binary compatible choices including
RHEL. All I care at first degree I think is total binary compatibility.
Let them deal with upstream distros bugs and variants.
Since CentOS is the most supported in this neck of the world and developed on, seems a bad idea to go to Ubuntu/Debian etc... for a reference platform. Maybe (?) actually the better idea is to work with IBM/RHEL on a plug-and-play distro that includes the VFX platform tested downstream (as in even pre-install gcc 6.3.1 and 9.3.1 if they are in last 5 years supported as opposed to the version that is default of a current dot release with standard distribution)? .... I also see RHEL now has 16 seats free dev licenses: https://developers.redhat.com/articles/faqs-no-cost-red-hat-enterprise-linux . Maybe I should go back on RHEL? I mean I pay for Parallels so I can multi-OS on a mac laptop on the road, and it if you are a developer as opposed to an IT/pipeline person makes life so easy like that. Which is my next point, For deployment I understand the value of having Linux packages particularly for render farms and cloud equivalent, to quickly push a new workstation live - the biggest value of linux is deployment, not development. I am still curious how you sliced in year slots Windows though :) [KEEP THIS A SHORT EMAIL]
SO, again some of this thread is above my head - all I need
is what flavor.version to work in...
On a meta-level, I guess there would an advantage for market acceptance (and actually support in my case) to have only one desktop, and at this point (it's not 2002 anymore), I don't care if it's KDE or gnome... Thinking like that would also substantially increase the usefulness of all this (maybe make it worthwhile for drivers etc to pay attention,someone mentioned HDR as an example).
On Tue, Jan 25, 2022 at 3:50 PM Pierre Jasmin <pierre...@gmail.com> wrote:
>
>
> My 2 cents - with the caveat that I am a developer not an IT person, last thing I want to have is an opinion on containers...
>
> That said, whatever you decide, as we support like 15-20 applications with maybe over half of them with some linux version, so eventually what you decide indirectly affects us, SO might as well have an opinion, seems the best idea is to stick to a downstream version of RHEL. Right now I know of but have not used them, Alma and Rocky Linux that showed up to fill the gap of CentOs going upstream from RHEL. That is already 3 guaranteed to be binary compatible choices including RHEL. All I care at first degree I think is total binary compatibility. Let them deal with upstream distros bugs and variants.
>
> Since CentOS is the most supported in this neck of the world and developed on, seems a bad idea to go to Ubuntu/Debian etc... for a reference platform. Maybe (?) actually the better idea is to work with IBM/RHEL on a plug-and-play distro that includes the VFX platform tested downstream (as in even pre-install gcc 6.3.1 and 9.3.1 if they are in last 5 years supported as opposed to the version that is default of a current dot release with standard distribution)? .... I also see RHEL now has 16 seats free dev licenses: https://developers.redhat.com/articles/faqs-no-cost-red-hat-enterprise-linux . Maybe I should go back on RHEL? I mean I pay for Parallels so I can multi-OS on a mac laptop on the road, and it if you are a developer as opposed to an IT/pipeline person makes life so easy like that. Which is my next point, For deployment I understand the value of having Linux packages particularly for render farms and cloud equivalent, to quickly push a new workstation live - the biggest value of linux is deployment, not development. I am still curious how you sliced in year slots Windows though :) [KEEP THIS A SHORT EMAIL]
>
While I don't work for Red Hat, I actually agree that going to RHEL
would be a good move. As for the idea of a plug-and-play distro with
integrated VFX platform components in there as "plug-and-play", that
was essentially the crux of my idea that started this thread. :)
I think that it's a good idea to do it, not just for deployment
purposes, but also to make it so ISVs actually *want* to support your
industry on Linux. My suggestion is to work with Red Hat and the
community in a CentOS SIG to produce something with CentOS Stream that
people could use and develop against, and leverage that same work in
production with RHEL to make a plug-and-play deployment system.
On Wed, Jan 26, 2022 at 3:34 AM Neal Gompa <ngom...@gmail.com> wrote:On Tue, Jan 25, 2022 at 3:50 PM Pierre Jasmin <pierre...@gmail.com> wrote:
>
>
> My 2 cents - with the caveat that I am a developer not an IT person, last thing I want to have is an opinion on containers...
>
> That said, whatever you decide, as we support like 15-20 applications with maybe over half of them with some linux version, so eventually what you decide indirectly affects us, SO might as well have an opinion, seems the best idea is to stick to a downstream version of RHEL. Right now I know of but have not used them, Alma and Rocky Linux that showed up to fill the gap of CentOs going upstream from RHEL. That is already 3 guaranteed to be binary compatible choices including RHEL. All I care at first degree I think is total binary compatibility. Let them deal with upstream distros bugs and variants.
>
> Since CentOS is the most supported in this neck of the world and developed on, seems a bad idea to go to Ubuntu/Debian etc... for a reference platform. Maybe (?) actually the better idea is to work with IBM/RHEL on a plug-and-play distro that includes the VFX platform tested downstream (as in even pre-install gcc 6.3.1 and 9.3.1 if they are in last 5 years supported as opposed to the version that is default of a current dot release with standard distribution)? .... I also see RHEL now has 16 seats free dev licenses: https://developers.redhat.com/articles/faqs-no-cost-red-hat-enterprise-linux . Maybe I should go back on RHEL? I mean I pay for Parallels so I can multi-OS on a mac laptop on the road, and it if you are a developer as opposed to an IT/pipeline person makes life so easy like that. Which is my next point, For deployment I understand the value of having Linux packages particularly for render farms and cloud equivalent, to quickly push a new workstation live - the biggest value of linux is deployment, not development. I am still curious how you sliced in year slots Windows though :) [KEEP THIS A SHORT EMAIL]
>
While I don't work for Red Hat, I actually agree that going to RHEL
would be a good move. As for the idea of a plug-and-play distro with
integrated VFX platform components in there as "plug-and-play", that
was essentially the crux of my idea that started this thread. :)
I think that it's a good idea to do it, not just for deployment
purposes, but also to make it so ISVs actually *want* to support your
industry on Linux. My suggestion is to work with Red Hat and the
community in a CentOS SIG to produce something with CentOS Stream that
people could use and develop against, and leverage that same work in
production with RHEL to make a plug-and-play deployment system.Something that could be really helpful IMO would be multiple prebuilt component sets that track the major vfxplatform releases.This means not one set of packages, but several with perhaps redundant packages across them.As a consumer of these third-party applications it's really super annoying that Nuke requires exactly Qt 5.12.1 and Maya+Houdini don't work with that version but require 5.12.6+.This inevitably leads to geometric growth in the permutations of builds that a studio has to perform.Wouldn't it be great if there was a neutral, vfxplatform2021-qt5 package that all three of these apps could reliably target so that they wouldn't have to ship their own redundant dependencies? As a consumer I personally think that would be great.I don't think any of the ISVs particularly cares to build and provide their qt5, python3.7 and other platform components.It happens because there's no other option.It's also important that the individual components are separable. eg. someone might want to use just a subset and replace some slice of it, so there's some benefit to having things like the compiler or other bits in package-specific installation prefixes so that the user can compose things just-in-time.
On Thu, Mar 10, 2022 at 8:39 PM Kevin Constantine
<kevin.co...@gmail.com> wrote:
> I always wondered how effectively we'd be able to leverage something
> like a RedHat SCL that provided the VFX reference platform
> dependencies every year.
As a question on that, who would the target consumers of the SCL be?
I toyed around with creating a VFX Platform SCL back for CY2018 or so.
Besides the issue of distribution portability, a larger issue that
comes up with such a task is asking for industry standardization for
every main component from all vendors and consumers.
Vendors and studios may choose different compile options depending on
what they need, or apply custom patches beyond the projects' released
sources. An SCL effectively forces a shared opinion on every consumer
of the given package (whether that's a good thing or not is a
different debate). Every vendor is going to have their own QA process
and pipeline for dependency updates, including bumps to x.y.Z versions
of software, and may not appreciate losing that control. And that's
not touching on the actual delivered application schedules.
Relating to delivery schedules, this would also call into play
determining an appropriate lifecycle for updating the platform SCL
over time, to account for patch releases, custom patches, security
updates, etc. On paper it's a relatively simple prospect, but when
looking at the larger picture it would require a lot of buy-in and
communication from the broader ecosystem.
I don't think any of the ISVs particularly cares to build and provide their qt5, python3.7 and other platform components.It happens because there's no other option.