Collabora Blog

I have recommended SUSE Linux Enterprise Desktop in contexts where people have talked about supporting desktop openSUSE financially. I have also previously mentioned SUSE as an option in other forums.

As an engineer-centric Linux distribution vendor, they are also well-equipped to do engineering work upstream (and have an upstream-first mentality, which I appreciate). Red Hat and SUSE engineers often work hand-in-hand upstream in many communities, including desktop ones like GNOME and KDE.

They're a perfectly fine option if you want to go that way.

But in this context, we're talking about Red Hat's ability to invest in desktop Linux. And that is directly mapped to RHEL Workstation sales and (to a lesser extent) adoption of Fedora Linux (as a halo driving RHEL server/cloud and OpenShift adoption).

People also seriously underestimate how much work Red Hat puts into virtually every sphere of the Linux space[1], including the desktop. Many engineers spend a lot of time working in projects that don't directly pay off for RHEL because it either benefits the larger community or feeds into something they do care about in RHEL. It continues to surprise me how remarkably altruistic Red Hat is for a company. But that can only go so far. People still need to live and eat.

To give an idea of something that wouldn't have been possible without Red Hat: NVIDIA opening up their drivers last year[2][3]. Red Hat has been furiously working to rework Nouveau to take advantage of the…

> your compiler

Compilers of languages like C, C++, Rust, Go etc go above and beyond to maintain backwards compatibility. It is extremely likely that you will still be able to compile old code with a modern compiler.

> your processor

Hardware is common enough that people go out of their way to make backwards compatibility shims. Things like rosetta, qemu, all the various emulators for various old gaming systems, etc.

> your hardware

Apart from your CPU (see above) your hardware goes through abstraction layers designed to maintain long term backwards compatibility. Things like opengl, vulkan, metal, etc. The abstraction layers are in widespread enough use that as older ones stop being outdated people start implementing them on top of the newer layers. E.g. here is OpenGL on top of Vulkan: https://www.collabora.com/news-and-blog/blog/2018/10/31/introducing-zink-opengl-implementation-vulkan/

> [Your kernel]

Ok, you didn't say this part, but it's the other big unpinned dependency. And it too goes above and beyond to maintain backwards compatibility. In fact Linus has a good rant on nearly this exact topic that I'd recommend watching: https://www.youtube.com/watch?v=5PmHRSeA2c8&t=298s

> Pinning a dependency only _guarantees you rot the same or even faster_ because now it's less likely that you can use an updated version of the dependency that supports more recent hardware.

Dependencies are far more likely to rot because they change in incompatible ways than the…

> On that last point, I felt it necessary to justify why RK3576 is an interesting target. Many more casual observers seem to see an SoC with older licensed core designs and miss the forest for the trees in the process. The talk details how RK3576 is more than a cost-optimised little brother: it's a stepping stone towards future designs.

Unfortunately I bought a bunch of Radxa Zero 3W's, which use the RK3566. An older design though, from around when RK3588 was also arriving. Mainline support is not that bad. But I don't think there's much focus on improving it. Mostly I just want video encoding; my original use case was using it as an HDMI -> wireless transmitter.

As we head into this computing crunch, alas, these lesser chips are going to be quite important. There's some really nice Allwinner A733 chips too, but I don't think support is nearly on par with what Collabora has cooked up for Rockchip. That's a huge advantage, and it's fantastic.

There was a really scary time a year ago when it felt like Rockchip was going to disappear from open source. There's still a question of availability of SBC systems, but where we are is so much better than it looked like things were going to be, 15 months ago. Great follow up post here, on the post 5 days ago about the great progress with video decoding going to mainline. I wonder how Allwinner is doing with their A733 & maybe upcoming A737. https://mastodon.social/@geerlingguy/113698847221483936…

Thanks for the analysis.

> That repo is for an opaque blob

Marvell patches have been going to upstream u-boot for a subset of CN-9130 functionality. Some were rejected as unwanted SoC-unique features, but that code is still public and could be consolidated into a public git repo for evaluation. Support for core features was merged, e.g. this thread from 2020 to 2023, https://lore.kernel.org/u-boot/ddd355c2-344e-4fbd-ace9-29d10f3966d3@denx.de/

> the notorious will-never-be-open-source highly-radioactive "snps blob" .. ARC core

Thanks for highlighting snps+eula. While we all want blob-free hardware like the expensive Talos OpenPOWER, all modern CPUs from Intel (ME) and AMD (PSP, MS Pluton) have management cores and firmware blobs (Intel FSP, AMD Agesa). AMD has a public roadmap for open firmware with OpenSIL, but PSP code is not public. One mitigation is to keep the device offline.

> Marvell.. good at hiding it

While this obfuscation is undesirable, many Arm vendors don't even bother with a fig leaf of upstream support. Would you recommend any Arm SoCs that have ongoing upstream Linux and u-boot coverage/fixes? Ideally, the SoC would also have OSS code for TrustZone (TF-A) and support for ECC memory. RockChip RK-3588 looks promising, https://www.collabora.com/news-and-blog/blog/2024/02/21/almost-a-fully-open-source-boot-chain-for-rockchips-rk3588/

> Is it more efficient resource and time-wise to rewrite everything in [Language of choice], or to comb through the currently existing code manually and with special tools to find bugs and fix them?

This is for the NVK project, which is creating an open source GPU driver for NVIDIA GPUs. The project has a number of considerations that are not in the blog post:

> The unfortunate reality is that, while the original nouveau drivers were written by some amazing engineers and were state-of-the-art a decade ago, they have fallen behind in the last several years. The few developer hours it gets are mostly spent on basic hardware enablement and trying to get new OpenGL versions, leaving the systemic and architectural issues unaddressed.

You can find more complete rationale in their announcement blog post, and it seems very thoughtful: https://www.collabora.com/news-and-blog/news-and-events/introducing-nvk.html

If you want Yet Another Example of using Rust to write GPU drivers, you can look at the other Mesa driver in development (for the Apple AGX GPUs): https://asahilinux.org/2022/11/tales-of-the-m1-gpu/ (see "Rust is magical!")

Collabora | Low-level Software Developer | Taipei, Taiwan | Full-time, REMOTE | https://www.collabora.com/careers.html

Collabora is a leading global consultancy specialising in delivering the benefits of open source software to the commercial world. For over 10 years, we’ve helped our clients navigate the ever-evolving world of Open Source, enabling them to develop the best solutions.

We are looking for a low-level software developer with expertise in Intel and/or AMD system architectures, UEFI programming and debugging. The candidate should be able to review and apply kernel patches, analyse electrical schematic diagrams, debug and troubleshoot issues with debugger/ITPS, scopes, and logic analysers, and be familiar with various hardware bus interfaces (USB, SMBus, LPC, I²C, etc).

Spoken Mandarin Chinese and being located in Taipei, Taiwan or mainland China is a plus.

More details: https://jobs.lever.co/collabora/bc35c5e5-c510-4b67-9866-cdb5c7b85d3b