I am a solution architect at Red Hat with some prior experience as a sysadmin in the animation industry. I am biased towards the Red Hat ecosystem as I use it nearly exclusively for all my personal and work related needs, but in this document I will attempt to remain as impartial as possible when discussing generic topics. I am not writing this on behalf of my employer; my goal is to be able to provide as much information as I can to help industry members make their decisions, and be a potential reference for discussion. The content of this document will veer towards the Red Hat side of things as that's just where my experience and knowledge adds up, and it's where I can provide the most information. Any corrections, suggestions, or information regarding other ecosystems would be greatly appreciated.
When I use the term"RHEL" in this document, I am generally referring to the Red Hat Enterprise Linux platform/ecosystem which includes CentOS Stream, RHEL, and downstream rebuild distributions. I am also speaking from the stance that the CY2023 draft will remain as is from the point of view of the distribution touching components.
As a general reminder, there is a VFX Linux Task Force working on making a Linux distribution recommendation this summer to help with the transition off of RHEL 7 for CY2023. This working group is also focusing on reducing distribution fragmentation across the industry and providing guidance to help expand the adoption and support for Linux.
Reference Spec and Distributions
When it comes to the VFX Reference Platform, there is really only one component that has an affect on the end distribution selection: glibc. GCC also comes into play, and it's easier when it's provided by the distribution but custom built toolchains are always an option.
Stepping into CY2023, there is a sub-component added to this matrix, the C++ ABI. The"new" C++ ABI(_GLIBCXX_USE_CXX11_ABI=1) is not available on the RHEL 7 platform and this will be the major breaking change for the industry. If it wasn't for this ABI requirement, technically RHEL 7 with DTS-11 would be a valid build environment for applications(though would break the runtime requirement). With the way the VFX Reference Platform defines versioning for glibc and GCC, technically any distribution that uses up to glibc-2.28 with an available GCC 11 toolchain will be compatible with the platform as a build environment. However, in reality this will be rather pointless for those looking to eek out a bit more life from RHEL 7 considering the applications built won't run on the platform due to the C++ ABI change. Between the glibc bump, the C++ ABI change, and the upcoming mid-2024 EOL of RHEL 7 we are entering the"rip the band-aid off" aspect of the timeline for the migration off of the current platform. So in the spirit of the glibc bump, I'll focus on distributions that simply match this requirement.
The only two distributions I found that match the spec are RHEL 8 and Debian 10(Buster). It's no secret that this industry is pretty RHEL heavy, so in my frank opinion RHEL offers the path of least resistance to most parties.
RHEL 8
Ships with glibc-2.28 and GCC 8.5(initially 8.2). GCC 11.2 is available directly from AppStream, eliminating the SCL repos. Setting up a basic CY2023 compliant build environment on a fresh RHEL 8 system looks like the following:
$ yum -y install gcc-toolset-11 # or gcc-toolset-11-toolchain
# Use 'scl enable gcc-toolset-11 "<command>"' as usual
Debian 10
Ships with glibc-2.28 and GCC 8.3. From what I have been able to find, there is no newer GCC provided in the distribution or as part of the backports repo. For a CY2023 toolchain, GCC 11 will need to be built from source manually(if there is a third-party repo I am not aware of it).
Ubuntu
Taking the reference spec into account for both build and runtime environments, there really isn’t a good target release that meets the platform’s requirements. Ubuntu 18.04 would meet the build-time requirements as it ships glibc-2.27, but this fails the runtime requirements of >=2.28. A custom GCC 11 toolchain would also be required, or the use of a third party PPA as GCC 11 is not shipped in 18.04. Ubuntu 18.10(a non-LTS release) is where glibc-2.28 was first introduced, and the first runtime compatible LTS release is Ubuntu 20.04 with glibc-2.31.
Thoughts for Software Providers
Personally I recommend sticking with RHEL 8 as the base build environment, reason being ease of transition considering existing industry experience, familiarity, and knowledge. I don't really have much more to add on that front other than to suggest verifying that all the system level dependencies you need exist, and if they don't please notify and work with your distribution of choice to resolve it. From the Red Hat side of things we would like to avoid the need for EPEL by vendor applications, so please reach out to us if there are missing dependencies. There are some other topics I would like to touch on, however.
Support Guidance
Support is a two way street that impacts both the software providers and consumers. Providers have to spend extra development resources in order to support multiple platforms properly, and end consumers need to find a common ground across all of their applications and solutions in order to maintain a supported environment. When it comes to the Linux ecosystem, it doesn't help that there are so many choices of platforms to choose from to compound the issue.
While the industry has largely proven to be RHEL-centric, the VFX Reference Platform survey demonstrated that it's not a complete and total summation of the industry, with about 18% deployed today(well, 2021) within the Debian family of distributions(mainly Ubuntu). I believe it's worth investing in supporting more than one distribution if the means to do so exist, or at the very least, removing barriers to deploying on alternate platforms. Accepting bug reports for those platforms while not directly or officially supporting them would be a bonus.
Revisiting the RHEL side of things, something we see software vendors do(across industries; this is not a call out at any specific VFX vendor here) is specifying RHEL minor versions they will support their applications against. Unless you have a very good reason to do this(of which there are very few), please refrain from doing so. I cover some of the technical reasoning for this at a high level in the other notes section later on, but some other things to think about:
The consumers of your tools knows their infrastructure needs best.
The consumers of your tools knows their platform needs best.
The consumers of your tools are running more than just your application in their environment.
Minor releases only receive about six months of updates, these end once the next minor release is available. As most RHEL platform consumers in this industry don't possess RHEL EUS subscriptions(see RHEL Life Cycle in other notes section), they don't have access to extended minor release support. Though we all like to believe in our security practices, it's best not to artificially hamper access to security updates.
As such, my recommendation from a RHEL platform support perspective is when specifying system requirements, use minimum versions and not static versions. Examples being"RHEL 8.4+","RHEL 8.4 and later", or simply"RHEL 8" if you either can be fully ABI compliant starting with the first release(again, see the other notes section) or will generally support your application across the entirety of the major version.
When it comes to RHEL rebuild distributions, I would personally not recommend calling out specific distributions as the baseline goal of these projects is to be 1:1 bug compatible with RHEL. Allow the consumer to make the choice of their platform for themselves rather than choosing for them. I suggest using a phrase like"RHEL #.# and later(and compatible rebuild distributions)".
Wayland
Another topic I believe merits investigation is looking into what implementation support software providers have today and what they will need in the future for the use of Wayland. Many application use Qt which has a Wayland QPA plugin(which may need to be built and provided by those bundling the framework), so out-of-the-box there should be preliminary support for the Qt stack on Wayland. I don’t know how well this translates to custom code/extensions. It would also be worthwhile testing how well applications work running under XWayland.
I would encourage participating in the Wayland development efforts, either of your own accord in the upstream projects or via a partner like Qt and Red Hat to ensure that your needs will be met. This will reduce friction as the platform shift from Xorg to Wayland takes place over the coming years. For example, Red Hat is actively working on enabling HDR support on Wayland but we would appreciate feedback and communication on the needs of the industry to make sure the solution we're providing covers your needs from both the technical implementation and the end-user perspectives.
In RHEL 9, Red Hat has deprecated the Xorg display server. The intended path is to focus on continuous improvements to Wayland with XWayland being the supported X11 application environment. The Xorg server has not been removed from the distribution and will be available for the full 10 year life cycle of the release.
Disclaimer
Reference Spec and Distributions
$ yum -y install gcc-toolset-11 # or gcc-toolset-11-toolchain# Use 'scl enable gcc-toolset-11 "<command>"' as usualThoughts for Software Providers