[CentOS-devel] Feedback on Red Hat Enterprise Linux 10 plans

Thu Jan 11 05:50:53 UTC 2024
Carlos Rodriguez-Fernandez <carlosrodrifernandez at gmail.com>

My company has available Red Hat Linux available for SWE, and SRE 
workstations along side with Macs. The main reason being compatibility 
with security and other compliance tools. Fedora couldn't be an option 
because of that.

As far as I know RedHat used to target Developers too with their 
Workstations. We also use FlatPak, and third party official repos for 
some software.

When buying Workstation computers, we look for those that are certified 
for RedHat. My guess is that when RHEL 10 comes with the new micro-arch 
requirements, the Certified Hardware program will adjust accordingly.

I also see a general trend for "Immutable OS", keeping only a core of 
applications, and unloading the burden of packing to the upstream. 
OpenSUSE, and Ubuntu are sort of doing it already with alternative 
distros. The question is whether the users would accept and receive that 
change.

Regards,
Carlos.

On 1/10/24 16:54, Mike Rochefort via CentOS-devel wrote:
> On 1/9/24 9:16 AM, Leon Fauster via CentOS-devel wrote:
>> I just gave a hint and also mainly about "productivity applications"
>> (not widget toolkits). For instance, Libreoffice is gone in the future
>> (EL10). Evolution (nativ e-mail client) is deprecated already. rhythmbox
>> not in EL9 anymore. Even my tech docs written in LaTeX can't be build
>> anymore (missing TeX parts). I could investigate more scenarios where
>> RHEL as workstation would not fulfill the requirements (its off-topic
>> already). Just a week ago, I build gnome-network-displays for EL9
>> locally to stream my display to a screen for productivity proposes.
> 
> Something to keep in mind is the intended target of RHEL Workstation. 
> It's not really meant as a general desktop replacement kitted out with 
> apps for the average users' workloads. Per the product page[0]:
> 
> * Red Hat® Enterprise Linux® for Workstations is optimized for high
> * performance graphics, animation, and scientific activities–with all
> * the capabilities and applications workstation users need to focus on
> * their tasks and not workstation administration.
> 
> As a sysadmin in the animation industry, none of the usual non-core 
> applications get used within our workloads unless by accident. We use 
> dedicated, industry oriented tools in our environments for playback, 
> image viewing, etc. Generally speaking, Files, GNOME Terminal, and GNOME 
> Text Editor are really the only provided tools used. Eye of GNOME does 
> get opened for image types that aren't redirected to our tools, but it's 
> pretty much just used to quickly view reference images downloaded from 
> the internet.
> 
> Workstation is really focused on providing a solid platform for end 
> users and administrators to build and integrate their specific workloads 
> onto. It's part of the reason why Fedora is commonly recommended for 
> more general purpose scenarios, even within Red Hat. That's not to say 
> it can't be used for such workloads, but it's not a core focus. The 
> direction being taken became pretty clear after RHEL Desktop was dropped 
> from the product lineup with RHEL 8 (necessitating an upgrade to 
> Workstation subscriptions).
> 
> Some of the traditional applications being dropped/deprecated are also 
> seeing a shift from distribution packaging to Flatpaks provided directly 
> by the upstream providers. LibreOffice and Evolution are good examples 
> of this, along with other GNOME apps in general. Some of them are also a 
> royal pain to maintain for packagers, so this lifts a burden off of Red 
> Hat engineers to focus on more customer-valued components.
> 
> That being said, Red Hat also has their own experimental Flatpak 
> registry[1] containing a handful of applications as well as the RHEL 
> runtime and SDK. Currently, there is:
> 
> - GIMP
> - Inkscape
> - LibreOffice
> - Firefox
> - Thunderbird
> - Red Hat Platform (8/9)
> - Red Hat SDK (8/9)
> 
> I do not know what the future plans for this registry are.
> 
>> Someone could argue that this should be all in containers (its the
>> future right? - My prediction is, that some day RHEL will be an
>> Immutable OS).
> These are my own thoughts, but I'm not expecting a RHEL Silverblue any 
> time soon. It's not outside of the realm of possibility, though. As a 
> former Red Hat Solution Architect, the way we approached immutability 
> was really around edge and server workloads using the Image Builder 
> toolset[2,3]. RHEL for Edge isn't a prebuilt distribution, but a toolset 
> enabling users to create their own platforms to best serve their workloads.
> 
>> I don't think that RH thinks that nobody is using RHEL on desktop
>> computers. Its just a matter  of resources that pushes such decisions.
>> So, you a right, if just the half of the server variant subscriptions
>> would exist for the workstation variant ...
> 
> Looping back to my first section, this is really what it is. Workstation 
> usage is definitely less than Server and its needs are driven by its 
> customer base. If a non-trivial segment of the base isn't actively using 
> or relying on certain applications, those are development resources Red 
> Hat could reallocate towards projects that matter to their customers.
> 
> 
> [0] 
> https://www.redhat.com/en/technologies/linux-platforms/enterprise-linux/workstations
> 
> [1] 
> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/administering_the_system_using_the_gnome_desktop_environment/assembly_installing-applications-using-flatpak_administering-the-system-using-the-gnome-desktop-environment
> 
> [2] 
> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/composing_a_customized_rhel_system_image/index
> 
> [3] 
> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/composing_installing_and_managing_rhel_for_edge_images/index
> 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 665 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20240110/8efdf2bb/attachment.sig>