CentOS 8 EOL, in favor of CentOS Stream and its effect on vfxplatform

[blazej...@gmail.com]

Compare:

https://www.redhat.com/en/blog/centos-stream-building-innovative-future-enterprise-linux

From the look of it CentOS 8 original LTS will be pulled to 2021 as the model is being transitioned towards CentOS Stream only - which from my understanding does not have the same stability and support guarantees.

I am curious what the vfxplatform stance is, considering how closely it is defined towards a RHEL-like distro.

While I do believe that major studios are probably on a RHEL support anyway, I do fear what this could mean for smaller shops or general scalability cost vs. stability for larger deployments of compute instances.

Do you expect this to influence future vfxplatform recommendations and how?

Regards,

Blazej Floch

[Nick Cannon]

It's certainly been an interesting week in the Linux community. What is already clear is that there will be several drop-in replacements for CentOS in due course, the leading contender being Rocky Linux which is led by the original founder of CentOS, and already has significant support and traction:

https://github.com/rocky-linux/rocky

The impact on the VFX and Animation community of this week's news is that CentOS users will need to make a choice in the next 3 years of which distro they want to move to. A migration to another RHEL clone like Rocky Linux is likely to be quite straightforward, and I'm sure we will see some studios move to other distros or choose to move to RHEL to help fund development and support.

The VFX Reference Platform will continue to work with any Linux distro, albeit with varying degrees of effort. RHEL/CentOS is by far the most prevalent Linux distro used across our industry, both at studios and software vendors, so some Platform choices are made with lowering effort for that distro in mind. Some studios already successfully use other distros like SUSE and Ubuntu, and more may choose to do so in which case that would inform different choices for the VFX Reference Platform in future.

Ultimately the VFX Reference Platform is a community-driven initiative and we will always try to do what's best for the VFX and Animation community, including smaller shops and individual artists. In fact, the VFX Reference Platform was started in part to reduce the complexity and effort required to support Linux in VFX and Animation. We are always very interested in hearing ideas and suggestions for what more the Platform could do to better support the community...

Thanks,

Nick

[Pipeline TD]

here's a good article about the changes: https://freedomben.medium.com/centos-is-not-dead-please-stop-saying-it-is-at-least-until-you-read-this-4b26b5c44877

[Alvaro Castaneda]

As I mentioned in the 3DPro list, this could be a good moment to reconsider using RHEL/CentOS as the main linux platform, the libraries are old and conflict with modern linux distributions like Ubuntu which as you mention, is also widely use, this old libraries affect mainly Maya which is a pain to install in other distributions, but also affects any application compiled with this libraries because new patches and fixes aren't part of that, Also, compiling with modern versions of GCC and/or Clang is tricky to setup since CentOS most of the time is way behind the recent developments in said compilers.

I would suggest that even if there is no change in the base platform, there should be a compatibility criteria so those apps are better supported on other distros, Houdini as an example does a great job on this as many other apps.

Thank you

--
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/a7856ad8-37ec-4951-94be-f1aadc4fe223n%40googlegroups.com.

[Njordy Jovanovich]

I can't agree more with the statement about reconsidering RHEL-based semi-obsolete distos. I think without the push from vfxplatform the situation isn't going to change, and studios will choose the lazy... I mean cheap solution in the way of Rocky or alternatives. And that's the shame, because sudden CentOS death can become a catalyst for moving on more modern (without the need to google and download ancient lib files) OS. It might be painful, but nowhere near py3 slowpokeishness, and will be beneficial for many in the end.

In the comments on discord or facebook, I don't remember, were mentioned interesting idea about ASWF making it's own distro perfectly suited to VFX and vfxplatform itself. It's a bit crazy, but... Many popular distros come with different community flavors, usually it's "desktop environment" (gnome, mate, etc)/ Maybe, just maybe, ASWF can peak the distro, let's say Ubuntu (I prefer Pop!_OS) and maintain a special vfxplatform community driven flavor. With everything setup, all lib versions locked and os on. Maybe I'm naive, and don't understand jack sh*t. Just putting this idea here ;)

[ma...@marcomeyer-vfx.de]

Not sure if the old-compiler argument still applies for RHEL8/C8/Rocky8: The versions available through modules/appstreams aren't that far behind the latest releases. (eg. GCC 10, clang 11, python 3.9, ... )

I understand that it's not particularly a shiny-looking user desktop distro, even though I'm using it as one and I'm pretty happy with it so far. I think this is more about long term stability for pipelines and vendors. Therefore switching to something like Ubuntu would most likely result in locking into one of the LTS releases which will get dated about as fast as anything RHEL-based. So there wouldn't be any benefit here in that area. I'm not sure what Ubuntu LTS' update policy on those is but just a quick lookup of the gcc version of 20.04 LTS I can see that it's already lagging behind RHEL8's latest appstream version (9.3.0 vs 10.2.1).

Also I don't think creating a full distro is a feasable thing to ask from the ASWF. From what I've seen in recent talks is that there are some planned packaging efforts for each ASWF project, though. So I'd rather suggest to just stick with a RHEL8-like base system and piggy back on its module system. VFX packages and their lib dependencies could then be bundled into VFX-Platform-based module streams via a COPR repo. That way they can be easily installed in parallel and/or updated to a new version. (haven't thought this all through but in my head it sounds reasonable 8] )

[Larry Gritz]

As far as directly managing a Linux distro, my recollection is that ASWF quickly reached consensus to run as quickly as possible in the opposite direction of that dumpster fire.

On Jul 14, 2021, at 3:05 PM, Njordy Jovanovich <njo...@gmail.com> wrote:

In the comments on discord or facebook, I don't remember, were mentioned interesting idea about ASWF making it's own distro perfectly suited to VFX and vfxplatform itself. 

--

Larry Gritz

l...@larrygritz.com

[Alejandro Enriquez]

Hello everyone,

It would be interesting to know what do you think about other distros such as OpenSuse. I also believe RHEL/CentOS distros are semi-obsolete. Artists don't like it visually, but because we try to stick to the VFX platform we are following the tendency. 

OpenSuse Leap, for example, offers packages that are pretty stable but not too old, also offers the possibility of nice desktops, modern which is something that artists care about, and of course pretty stable. Having an ASWF Linux OS would be another good idea, not sure if it is possible but it would give the industry freedom. Another idea, kind of crazy! haha, team up with PopsOS devs! haha, that OS is amazing, maybe because it is one of my favourite distros.

Cheers!

[Nick Cannon]

This thread nicely highlights the challenge we face with platform choices in production environments as it's always about striking a balance between needing stability and wanting the latest and greatest features.

Studios tend to want stable long term support releases like RHEL or Ubuntu LTS but they can often feel stale to independent artists and developers who want to use, or build on, the latest tech. The more progressive distros like Pop!_OS or Fedora are updated much more frequently and are great ways of easily using the latest releases but they do not easily offer a consistent, robust platform that software vendors can reliably target to ensure compatibility for their studio customers.

The introduction of CentOS Stream offers a middle-ground, upstream of RHEL but downstream from Fedora. It remains to be seen whether that will see much adoption by studios but initial signs are that it's still considered to be too fast-moving for ad hoc adoption. To the question of OpenSuse, I have heard about one or two studios using it but it's less common than Ubuntu which a few more studios use, and RHEL/CentOS which up to now has had the majority market share in studios to my knowledge.

As Larry mentioned, the topic of a community distro targeting the needs of VFX and animation has been discussed by the ASWF TAC, and elsewhere, but it doesn't really have any strong advocates because of the significant effort and commitment required.

At the VFX Reference Platform we are starting to have more active discussions with various distro providers to highlight the specific needs of our community to see if we inspire them into action. Red Hat's change of strategy with CentOS actually presents an opportunity as many studios are now considering changing distros in the next 1-2 years and we may have the opportunity to align for our mutual benefit, rather than fragment more and further increase the challenge of supporting Linux for software vendors and smaller studios.

We are at a critical moment, and the sustainability of Linux as a platform for professional high end graphics workstations is at stake. This is going to be the main topic of discussion at the VFX Reference Platform Birds of a Feather session at SIGGRAPH this year. Save the date - it'll be on Wednesday August 11th at 12:30pm PT / 3:30pm ET / 8:30pm GMT and will be hosted on Zoom. Currently it looks like a Basic SIGGRAPH registration is required for people to attend at a cost of $50, although keep an eye out for vendors providing promo codes for free Basic registration. More details to follow soon...

Nick

[Pipeline TD]

Hi Nick,

I agree, we are currently heading hard times. From my point of view more smaller studios are actually swichting to Linux (mainly Ubuntu LTS or CentOS 6 or 7) and use this as main operating system. Not sure if I am inside a bubble but also more indivisuals are trying different Linux OSes for various reasons. There are now more hardware vendors (DELL & Lenovo) planning to support and sell preinstalled Linux devices.

Rocky Linux is the most popular replacement for CentOS. For big studios there might be uncertities that it will be disconinued too soon. Is anyone here who can confirm it RHEL could work for big studios and Rocky for smaller studios?

It's hard to tell which distribution makes more sense but wouldn't be the smartest option to support more modern versions so some cutting edge versions and stable versions are supported? The future should be to become more independent from single distros so every studio can choose their own flavor.

In the end it looks like the decision has to be made by Autodesk, The Foundry etc to show their commitment for the next couple of years.

If I find a promo code I will happily join the discussion.

Cheers,

Jérôme

[Njordy Jovanovich]

I'm so happy the discussion if alive again! :)

Ok, the latest and greatest RHEL (and I assume Rocky) has linux kernel 4.18. It's not even long-term kernel, and it became obsolete in 2018. And even if it was LTS, it would have been 4th LST down the list. And talking only about the kernel for example, and I don't know what exactly RH have backported, I don't know how the choose it, I don't know if my modern CPU is supported, and I don't know how much *^@#&@ will I get by manually updating the kernel from elrepo. Again, VFX is not like accounting (no disrespect), and powerful & modern hardware (especially for people who doesn't use farms) is a requirement for a vast majority of departments. Saying that, I also don't think what studios (the bigger = the slower) should adopt fast changing, cutting edge, rolling release distro. My guess it would be hell for support, TD, pipeline engineer and developers to support something like Fedora. But right now, I'd say RHEL-based distros are a bit ancient and... unpleasant for remore/freelance workers (and there are a lot of them, including me). 

RHEL updates every 4-5 years, not including insignificant minor versions. Ubuntu LTS do so every 2 years on strict schedule. I don't think these two are comparable. 

>> "ASWF Linux OS"

...is crazy, I agree. But teem up with some distro, like Pop!_OS, sure, loving them, and contribute to Pop!_OS VFXp Community Flavor -- that would be awesome. Plus, those guy might be happy to help, since they produce really powerful machines, and sometimes market if to CG people, having Blender on a screen with some speed tests. Maybe they would like a badge of "official blah-blah of Academy, please, buy our perfect for heavy VFX work laptops". Who knows...

>> "we are currently heading hard times"

But hard times often bring a necessary change for a better future. Maybe it's the push we all needed, romantically speaking :)

>> "decision has to be made by Autodesk, The Foundry etc"

Being independent is also nice, sure. But I am not sure it's possible. Those programs can't work in the form of AppImage. 

I actually don't know, both Foundry (Nuke, Katana, etc) and SESI (Houdini) products work perfectly on whatever system. They have just (I assume) bash scripts what take care of business on any platform. It's admirable. But Pixar can't even make an installer app, whose purpose it only to login check system, and download other rpm's, not to be in rpm itself. Jesus. I did try to unpack (alien), add some missing millenium-old libraries, and it still can't work on .deb machine. It sound like a problem in 90s, not in the modern era, and it's one of the core linux problem.  Sorry for my rant.

[Alejandro Enriquez]

I agree we are not doing bank accounting, we need stable systems but maintaining those ancient OS comes with a toll, and to be honest, a partnership with the devs of PopOS could work, not like a joke. Else we can look other systems OpenSuse is also a great option. 

Rocky Linux is too new as a project, I am not sure how long term project it will be, and again, it feels like we would move to back the same old thing that many dislike instead or something that could be better. RHEL is stable yes but also other distros, we don't need to go to the bleeding edge Fedora but I think there are really good midpoints.

I am pretty sure Foundry and other developers want to hear where everyone wants to go and they will move towards there.

I would really like to understand better why aside of the stability, RHEL is still a good candidate for VFX nowadays.

Best, 

Jose

[Bob Davis]

Quick intro - Hi, I'm Bob, I'm the product manager for RHEL Workstation at Red Hat. I've been quiet, because I want to listen to you vs. try to tell you how "Red Hat can solve all of your problems" or something like that. 

This is a fascinating conversation for me. 

What I'm seeing is the conflict between "we want fast moving evolution" vs. "I want to start a 5 year project on an OS, and have that OS be fully supported for the whole time". 

It's a super tough balance, but we're trying to manage it. 

What would a hypothetical "perfect VFX Linux" look like?

Oh, and one correction to what Njordy said - we release major versions of RHEL every 3 years, with two point releases per year (roughly Q2/Q4) with quarterly updates to application streams and errata for CVEs, bugfixes, and other critical updates. The change to every 3 years came with RHEL 8, where we realized the "no new updates before they're ready" communication wasn't serving our customers and that, for most, 3 years was in a roughly defined "Goldilocks zone". 

Please let me know if there are specific questions I can answer, and I'll do the best I can to give you answers.

Bob

--
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/c6512b57-c311-4b0e-8282-dad6be24b4f0n%40googlegroups.com.

--

Bob Davis

Principal Product Manager, Red Hat Enterprise Linux

bobd...@redhat.com | 210-452-8945

[Michael Rochefort]

Hi all,

Well, Bob beat me to the punch, I just finished authoring a monster of an email that I was going back and forth on sending.

In the interest of saving inbox space, I've posted it here, it came out a lot longer than I was expecting:

https://gitlab.com/-/snippets/2151548

In it I touch on a few points that I've seen in conversations with other admins and my experience in the industry, namely:

- Age of RHEL
- Desktop/Workstation situation
- AWSF/Industry distribution
- Vendors


Cheers

--
Mike Rochefort
Junior Solutions Architect
Red Hat - Northeast Commercial



---- On Mon, 19 Jul 2021 12:36:47 -0400 Bob Davis <bod...@redhat.com> wrote ----

[Deke Kincaid]

To be frank it is the 10-year support level is the benefit of Centos/RHEL, etc....  At larger facilities changing os's is a big deal.  It is like turning an ocean liner.  It feels like 10 years is too long but 5 years is too short.  Somewhere in the 6-7 year range is about right as it takes all the vendors at least 2-3 years to change operating systems then another 2-3 years for large facilities to make that change after they see all the vendors have settled in.

--
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/c152cd22-a3d6-453b-b1ca-6e1d298300aan%40googlegroups.com.

[Bob Davis]

That's what we're always hearing, Deke. In fact, there are many customers who pay for additional time (our Extended Lifecycle Support) on RHEL. 

Someone brought up Fedora earlier - it's a fantastic option for people who need the latest versions of everything, and don't need a long lifecycle, but for most RHEL users, the 6 month release cycle with support lasting only to n-2 (so 18 months) is not long enough. 

Lifecycles are a difficult balance - we try as much as we can to make sure that there's an option available in RHEL for what everyone needs though.

Bob

To view this discussion on the web visit https://groups.google.com/d/msgid/vfx-platform-discuss/CAOOm49Q3e6oyA7Xk8Nq2zMCdo2UpXxwgqwk3REcboFHZc7r7sA%40mail.gmail.com.

[Bob Davis]

Awesome write up, Michael - thank you!!

Bob

--
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/17abfd43922.ff8f9be3326020.7789685498890771131%40michaelrochefort.com.

[Edward Lam]

Sorry for the noob question: How hard is it for a distro to be able to support newer glibc versions? This would allow a vendor to use newer third party dependencies which have dropped support for older glibc versions. (I'm looking at you, Intel OpenCL CPU RT.)

-Edward

To view this discussion on the web visit https://groups.google.com/d/msgid/vfx-platform-discuss/CAOOm49Q3e6oyA7Xk8Nq2zMCdo2UpXxwgqwk3REcboFHZc7r7sA%40mail.gmail.com.

--

Support GOToronto by rating us in the App Store!

[Njordy Jovanovich]

Bob, Mike, thanks for making the situation much clearer, at least for me. 

# Age

3 years cycle is very reasonable I'd say! It's a good change. 

# Desktop.

Mike, I don't know where are you getting your information, but I'd say most of the artists use Gnome. It's actually the only desktop environment I like on Linux (not without it's issues, of course). Every studio I work had Gnome (CentOS), and again, and the people I know too. Ok, I have one big fan of KDE among my friends, but he's a exception :) 

And Gnome 40 is a good step in (mostly) right direction.

# ASWF/Industry Distro

Noted. I withdraw my proposal :)))

# Vendors 

Let me add to your list 

Arnold Renderer -- system independent .run installer with CentOS 7 in mind. 

Pixar Renderman -- .rpm package

And the one vendor what puzzles me BorisFX:

Mocha Pro is in .rpm packaging, but Silhouette has system independent .sh installer. 

Boris bought the latter one about two years ago, and still can't have its products in... one style. A bit of a mess IMHO.

>> "vendors need to be more flexible" 

This is exactly the biggest problem. I mean there would not be as many problems of vendors at least give a, simply saying, .rpm support for studios, and .deb support for freelancers, or just do exactly what SESI and The Foundry are doing.

Thanks everyone :)

[Sean Wallitsch]

Linux distros and desktop environments have been hotly debated since shortly after Linus was born- we can have this email discussion until we die of old age. (Cinnamon for the win, btw)

CentOS, for better or worse, seems to be either in the lead or heading there in our industry for linux distros. This is in no small part due to the fact that some vendors have it and RHEL specifically listed as supported. It updates at a nice cadence that is both too slow for an engineer's taste and too fast for support's- sounds like a nice compromise to me.

The idea of creating a VFX distro is a tempting idea but realistically unworkable. It's hard and expensive enough for our various studios to support their systems using widely adopted distros, and what open source contributions the studios can afford are typically (IMHO) better spent on tooling such as ASWF contributions.

The opinions above are my own and do not represent my employer.

-Sean

To view this discussion on the web visit https://groups.google.com/d/msgid/vfx-platform-discuss/1428c55c-7722-4f22-a647-6b8aa9555464n%40googlegroups.com.

[Michael Rochefort]

On Mon, 19 Jul 2021 16:38:51 -0400 Njordy Jovanovich <njo...@gmail.com> wrote

> Mike, I don't know where are you getting your information, but I'd say
> most of the artists use Gnome.

As I mentioned in my post (rather less clear than I intended once I reread
it), I'm speaking from things I've seen at my last two studios of
employment and from those I've spoken with, primarily on StudioSysAdmins.
If my memory serves me right, I've seen pretty much null on that front for
GNOME usage for those who have mentioned what they have in use.

Obviously that's not a global statistic, but it's all I've had to
extrapolate from. It is encouraging to know that GNOME does see its use in
the daily workflow, it's just not something I've personally seen at all in
art prod, only on the systems side. I'm writing this email myself from a
Fedora 34/GNOME 40 system.

I should have phrased that section better, I usually try to avoid sounding
authoritative in any capacity and I missed my mark there.

On Monday, July 19, 2021 at 9:02:38 PM UTC+3 triplequ...@gmail.com wrote:
> Sorry for the noob question: How hard is it for a distro to be able to
> support newer glibc versions? This would allow a vendor to use newer
> third party dependencies which have dropped support for older glibc
> versions. (I'm looking at you, Intel OpenCL CPU RT.)

I'm not a developer, but I have done my fair share of software building
when I was working on an HPC cluster. glibc is probably one of the
libraries you do _not_ want to mess with on a system, or try bundling as
you would with Qt. I spent some time trying to do this for certain projects
before just throwing my hands in the air and using Singularity containers
(our cluster ran on RHEL 6). While from a technical standpoint there are
ways to make this work, it is not a trivial undertaking (can't just
LD_LIBRARY_PATH it and call it a day), and requires touching a lot more
than the end application you're linking against and will end up causing
more pain than gain from my experience. glibc is comprised of the linker,
the C library, dynamic NSS, etc that are very tightly integrated. _Maybe_
static linking can be a way past this, but it's never something I've never
tried to do before, and from the things I've read in the past it's not a
100% surefire solution depending on what your application uses.

If I'm off on that, I would like to know. But so far my experience in life
has been don't mess with glibc.

Cheers

--
Mike Rochefort

[Michael Rochefort]

@Edward Lam

On Mon, 19 Jul 2021 17:39:46 -0400 Michael Rochefort <mi...@michaelrochefort.com> wrote
> Stuff about glibc

I realize I wrote this mainly from the perspective of a software provider
or maintaining multiple glibc versions, rather than what your question
was asking from a distribution perspective in terms of "upgrading" glibc.

And the following should be taken with a grain of salt, I am not an expert
in this field, so this is mostly my understanding of things. I would
greatly appreciate anyone correcting my information here if they know
what's up.

The short of it is glibc is such an integral library to a system that it is
difficult to touch it once released. For a platform like RHEL that
guarantees 10 years of support, and a strict ABI for certain parts of its
systems a change in glibc would likely invalidate that promise. Sure there
are rolling release distributions like Arch and OpenSUSE Tumbleweed where
glibc is upgraded over time, but most distributions do not follow that
methodology for a given release of the operating system. glibc is also not
always 100% backwards compatible (symbols do get removed at times)[0], so
depending on what symbols your application uses and how it uses them,
things could break. Keep in mind glibc is a smattering of libraries, not
just libc, which in and of itself is very backwards compatible. And this
could lead to an application running on one sub-version of a distribution
and not on another system before/after the glibc update. This is not an
ideal situation to be in. Historically upgrading glibc on a system has
lead to issues and system instability, so most people tend to avoid
these kinds of changes to an existing functional distribution.

So, yes it's possible for a distribution to upgrade its glibc version, but
many won't due to various reasons about how the distribution is designed
and intended to be used. It's much easier to not touch it once provided. I
think some distributions do backport feature APIs in glibc, but I don't
believe RHEL does this (based on the following blog post):

https://developers.redhat.com/blog/2016/02/17/upgrading-the-gnu-c-library-within-red-hat-enterprise-linux

[0] https://abi-laboratory.pro/?view=timeline&l=glibc


Cheers

--
Mike Rochefort

[Njordy Jovanovich]

Bob, your reply did show up in my email, but I can't see it in the thread. And as far as I can tell it wasn't suppose to be a private, or for my own eye only, not it consist of anything of this sort. // I actually kinda getting annoyed by Google Groups and wish it was on Slack/Discord/anything else, but I don't wanna give a contrarian vibe :)

>> "If there are hard opinions on Mate, Cinnamon, xfce, Gnome, etc. etc., I'd certainly love to hear them."

Gnome all the way, even after...

>> "With the introduction of Gnome 3, there were some performance issues"

... this debacle. Believe me, I witnessed it. Something bad happened to my Xeon/64Gb Ram PC at studio, so they had to run some checks, possibly replace HDD, and whip the whole system out. If I'm not mistaken, next day I had CentOS7 instead of 6 as most of the people in the studio. Jesus, it was such a pain. I'm not even talking about crashes and freezes, but the performance wise... I've lost 1/3 of my PC's power. And I was working in Maya and Houdini with a bit of Nuke, and had a few projects running at he same time. In the end I had to change my workflow and be careful about system resources. I hated this change, and I hated Gnome 3. But half a year later things started to change, and in the end I'd say I didn't notice any difference between how it was and grow some love for this version of Gnome. Yes, it has a rough transitioning. 

>> "Is anyone talking about Flatpaks"

I love flatpaks. I prefer to install flatpaks, generally because flat repo has more modern versions. The only issue I found was what something is in the wrong location. I might be wrong, but Blender installed from flatpak puts it config in a weird .var location... O_o

But, yes, flatpaks are very welcome! 

[Bob Davis]

I must have hit “reply” instead of “reply all” - sorry!

Bob

--

Bob Davis

On Jul 19, 2021, at 3:55 PM, Bob Davis <bod...@redhat.com> wrote:



On Mon, Jul 19, 2021 at 3:38 PM Njordy Jovanovich <njo...@gmail.com> wrote:

Bob, Mike, thanks for making the situation much clearer, at least for me. 

# Age

3 years cycle is very reasonable I'd say! It's a good change. 

Great!

 

# Desktop.

Mike, I don't know where are you getting your information, but I'd say most of the artists use Gnome. It's actually the only desktop environment I like on Linux (not without it's issues, of course). Every studio I work had Gnome (CentOS), and again, and the people I know too. Ok, I have one big fan of KDE among my friends, but he's a exception :) 

And Gnome 40 is a good step in (mostly) right direction.

With the introduction of Gnome 3, there were some performance issues that showed up in high-use environments (such as animator workstations) that weren't apparent in a typical install, but when we heard that it wasn't good we worked hard to address those issues and I think we've gotten Gnome 3 (and 40, by extension) to the point where it performs as well as Gnome 2 (or Mate, which is probably more commonly used now). 

I do get requests from some customers to explore xfce though, and I know Mate for RHEL/CentOS 8 isn't available (the EPEL packager has stepped aside, from what I can tell). There's always a drive for smaller, lighter, less intrusive DEs for different use cases. If there are hard opinions on Mate, Cinnamon, xfce, Gnome, etc. etc., I'd certainly love to hear them.

 

# ASWF/Industry Distro

Noted. I withdraw my proposal :)))

Building and supporting distros is hard. :-) 

 

# Vendors 

Let me add to your list 

Arnold Renderer -- system independent .run installer with CentOS 7 in mind. 

Pixar Renderman -- .rpm package

And the one vendor what puzzles me BorisFX:

Mocha Pro is in .rpm packaging, but Silhouette has system independent .sh installer. 

Boris bought the latter one about two years ago, and still can't have its products in... one style. A bit of a mess IMHO.

>> "vendors need to be more flexible" 

This is exactly the biggest problem. I mean there would not be as many problems of vendors at least give a, simply saying, .rpm support for studios, and .deb support for freelancers, or just do exactly what SESI and The Foundry are doing.

Is anyone talking about Flatpaks? We are making it easier to use them, and, IMO, it'd be a huge usability lift (especially on the install side) for software companies to ship their desktop apps as Flatpak apps. 

Bob

 

Thanks everyone :)

On Monday, July 19, 2021 at 9:02:38 PM UTC+3 triplequ...@gmail.com wrote:

Sorry for the noob question: How hard is it for a distro to be able to support newer glibc versions? This would allow a vendor to use newer third party dependencies which have dropped support for older glibc versions. (I'm looking at you, Intel OpenCL CPU RT.)

-Edward

[Pipeline TD]

Coming back after the great presentation on Siggraph:

https://drive.google.com/file/d/1eUYcCqOa9EN-5eKM2Lh-Y1H7QjWK6MeX/view

So basically these are the priorities to attack:

• getting in touch with vendors to find a way that software can be supported in one / multiple distribution(s) = encourage and enable software developers and vendors to support Linux as a first-class platform
  
• Pushing Wayland development so it can be used for VFX/CG production
• Bringing awareness that Linux workstations are widespread for VFX/CG production
  

How to get the ball rolling?

[Bob Davis]

On Fri, Aug 20, 2021 at 8:40 AM Pipeline TD <ask.pi...@gmail.com> wrote:

Coming back after the great presentation on Siggraph:

https://drive.google.com/file/d/1eUYcCqOa9EN-5eKM2Lh-Y1H7QjWK6MeX/view

So basically these are the priorities to attack:

• getting in touch with vendors to find a way that software can be supported in one / multiple distribution(s) = encourage and enable software developers and vendors to support Linux as a first-class platform
  

Please do let me know how I can help here. We (Red Hat) have multiple programs aimed at making it simpler for software vendors to build software for RHEL, and are happy to help with packaging strategies as well. 

 

• Pushing Wayland development so it can be used for VFX/CG production

I'm putting together a gap analysis right now - A lot of the upstream Wayland and Gnome Desktop environment development is done by Red Hatters, so if we can make improvements there, it  benefits the entire ecosystem. 

 

• Bringing awareness that Linux workstations are widespread for VFX/CG production
  

I'm working on ways to do this as well. I have access to marketing resources that we can use to show how VFX/CG uses Linux. Obviously, it'd be RHEL focused, but it's something. I can try to work with different partners (hardware, software) and use VFX/CG use cases to show off what Linux and the partners can do together. 

I've also got a draft of a CentOS Sig (https://wiki.centos.org/SpecialInterestGroup ) for "Graphical Workstation", but we could be even more specific and talk about "Graphical Workstation for Visual Effects" or similar to really hone it to serve our specific interests. 

Let me know what I can do to help.

Bob

 

To view this discussion on the web visit https://groups.google.com/d/msgid/vfx-platform-discuss/45d32d9d-b165-4c5e-aa0c-22d918f721c0n%40googlegroups.com.

[Michael Rochefort]

In addition to Bob's points (I've always wanted to see a SIG for this), here is some extra information for getting started with the Wayland area. I'm purposely sidelining XWayland in this post.

1) People need to start testing with desktop environments/compositors that support Wayland. At the moment, the big ones are:

- GNOME 3+
- KDE (preferably 5.22+, EPEL8 has 5.18 LTS, see https://fedoraproject.org/wiki/SIGs/KDE/EPEL)
- Sway (wlroots based, it's i3 but on Wayland)

Other desktop environments are slowly making progress on the Wayland front.

I would recommend testing on distributions newer than CentOS 7, though it does have the GNOME Wayland session package available. I'm biased and would suggest spinning up a few Fedora 34 (Workstation, KDE Spin) systems just to mess about with some of the latest and greatest, though EL8 should be sufficient.

2) Supported graphics: If you're using NVIDIA graphics solutions (which I assume pretty much all are), Wayland support is going to be a bit shaky, but has gotten better with the latest drivers. It's got some quirks, but is much better than in the past and there will be improvements coming in the future.

3) Supported toolkit: Both GTK3+ and Qt5+ (through the qt5-qtwayland package) offer Wayland support. Since most applications use Qt, if you run the application with "-platform wayland" or export the environment variable "QT_QPA_PLATFORM=wayland", it should launch the application in a Wayland session rather than X11. However, since applications typically bundle Qt with themselves, I'm not sure how well this will play together with system libraries, or if vendors will need to ship the Wayland QPA plugin set with them. Doing a cursory look through Maya's 2022 package, it looks like Autodesk is shipping the X11 QPA plugin (among some others built by default), so this may be the case. EL7 ships 5.9, EL8 currently with 5.12, and EL8.5 is moving to 5.15.

Similarly, GTK uses the "GDK_BACKEND=wayland" environment variable to enforce Wayland usage.

The above is some baseline requirements for Wayland testing. As for other things happening in this space, things like HDR (which seems critical for the coming years) and color management seem to be dependent on what happens in this protocol addition:

https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/14

Any real world feedback/user stories and needs would probably be appreciated by the folks working on it. If my understanding is correct, decisions made here will cascade into what compositors and toolkits are able to do. There are some forum discussions about this protocol as well, but they are quite the read and can get... messy. The wayland-devel mailing list and Wayland site can provide more information into how Wayland works.

https://lists.freedesktop.org/mailman/listinfo/wayland-devel
https://wayland.freedesktop.org/

Cheers

--
Mike Rochefort


---- On Fri, 20 Aug 2021 10:25:58 -0400 Bob Davis <bod...@redhat.com> wrote ----

[Deke Kincaid]

As a person who worked for both vendors and in vfx, most are going to want a single base platform for testing.  Forcing multiple distributions feels like a non-starter.  Vfx is a very niche market, many applications have users in the tens of thousands or less.  QA teams are pretty small and things like GPU’s already make it really hard to test multiple configurations(especially in COVID).  Im sure we can work with vendors to make it easier to install on various distributions and maybe include more libraries and depend on the base os less.  If we identify troublesome libraries it may be a good idea to strongly suggest they include them, statically link or namespace them.  I just feel telling the industry they need to officially support and QA 3+ distributions is a high bar.

Second, why do we care so much about Wayland?  It is still a very immature product 10+ years in.  Many distributions do not support it yet, it is still not feature parity with x11. Lots of common Linux tools do not support it.  Why would vfx push on this when it is quite obviously not ready? Why is this a hill we want to die on?  We use Centos in the first place because we are risk obverse but we want to push on Wayland when the rest of Linux world isn’t there yet?

To view this discussion on the web visit https://groups.google.com/d/msgid/vfx-platform-discuss/45d32d9d-b165-4c5e-aa0c-22d918f721c0n%40googlegroups.com.

[Brecht Van Lommel]

Regarding the choice of Linux distribution, as a software vendor (Blender) I don't think it makes a huge difference to us. We want to support the multiple Linux distributions regardless of what the VFX platform recommends. Mainly I think we need:

* Low enough glibc version so that binary can run on a large range of Linux distributions.

* Availability of latest compilers and other development tools, ideally supported as well as on CentOS/RHEL.

The Linux distribution we build our software on and the most common one distribution that studios use does not strictly need to be the same, but it does make things easier.

Regarding Wayland, it is enabled by default in the latest Ubuntu, Arch (with GNOME) and Fedora. Those 3 and their derivatives are the most popular Linux distributions for individual users. So if you're making an application used by individual artists, I think Wayland is already here. But because of XWayland, most X11 applications continue working under Wayland. I don't know of a pressing reason for native Wayland support for most VFX applications, but I'd be interested in hearing if there is one now or expected in a few years?

We've been working on native Wayland for Blender, and creating portable executables that run on both X11 and Wayland has been difficult. It's unclear when we can ship that. It's not just Wayland itself, you need to support EGL and GLVND along with it.

To view this discussion on the web visit https://groups.google.com/d/msgid/vfx-platform-discuss/CAOOm49R7%3DPWT81OHYzOD3Ne0vvWoX7cXjBL2k8J4XfMQXCDdqg%40mail.gmail.com.

[Deke Kincaid]

Regarding Wayland, it is enabled by default in the latest Ubuntu, Arch (with GNOME) and Fedora. Those 3 and their derivatives are the most popular Linux distributions for individual users. So if you're making an application used by individual artists, I think Wayland is already here. But because of XWayland, most X11 applications continue working under Wayland. I don't know of a pressing reason for native Wayland support for most VFX applications, but I'd be interested in hearing if there is one now or expected in a few years?

Most people in vfx use Nvidia on Linux, especially because a large percentage of ML and Cuda is limited to that ecosystem.  Nvidia on Wayland still defaults to Xorg on Ubuntu as it is still a bit behind.  Ubuntu was the last hold out.  So hopefully we will start seeing more movement as globally it is the most popular distribution and so many other distributions depend on it (linux mint, etc...).

To view this discussion on the web visit https://groups.google.com/d/msgid/vfx-platform-discuss/CAKFUgC2uakV-YYaRt2VYGd9%3DKtf0MD4Z18P2j34B1u33trCcJw%40mail.gmail.com.

[Nick Cannon]

On Fri, Aug 20, 2021 at 9:16 AM Deke Kincaid <dekek...@gmail.com> wrote:

Second, why do we care so much about Wayland?  It is still a very immature product 10+ years in.  Many distributions do not support it yet, it is still not feature parity with x11. Lots of common Linux tools do not support it.  Why would vfx push on this when it is quite obviously not ready? Why is this a hill we want to die on?  We use Centos in the first place because we are risk obverse but we want to push on Wayland when the rest of Linux world isn’t there yet?

We care about Wayland because X.Org is unmaintained and increasingly broken over time. The concern is that X breaks properly before Wayland is ready, and also that Wayland development has not been focused on the high end needs of VFX/Post. We are trying to bring attention to accelerating Wayland development so it's ready for us before we have to jump from the burning platform that X.Org will be in years to come

So far the Wayland developers have probably not known about, or understood, our use cases so things that we need are missing. It's not urgent that everyone *adopts* Wayland right now, but it is becoming urgent for us to be responsible members of the Linux community and help the Wayland developers understand what we need, and perhaps help them build it so Wayland is ready for us by the time it becomes a more pressing need.

Nick

 

[Alan Fregtman]

I'd like to add that Wayland is also being embraced by Microsoft in their v3 of WSL (Windows Subsystem for Linux) to achieve a native-like integrated windowed graphical experience that doesn't lag like X11. Here's a good recent talk about their architecture for the curious:

https://youtube.com/watch?v=b2mnbyRgXkY&t=7975s

I know they did a lot of work directly with the Wayland folks and I am under the impression they are contributing improvements upstream, so everybody wins.

I haven't played with it yet but I would imagine that when it's stable it'll open the doors to better performance of remote-hosted graphical applications running in Linux elsewhere than the WSL local vm.

--

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/CABiBYoxUNfD8BwRVc3_Td4hnXE-Gwz-ZDbq16v%2BGv%3DpfRc3JWw%40mail.gmail.com.