If you look at that comment, there is nothing in it to suggest an open RISC V will arrive imminently. In fact, given that nobody is holding their breath for open RISC V, the comment could be seen as deliberately optimistic about Talos II boards running for years to come due to their quality.
Out main point was that the first part could be taken as RISC-V being the inevitable long-term succesor to POWER, when we're fairly certain that would not be the case, especially in the blob-free / owner-controlled sphere. Regardless, we do appreciate the note on quality -- that's an area we've put a lot of time, effort, and resources into.
There was nothing in the post to suggest people "hit back" at IBM
It is just a reality check, that is all. We can see the way people started building Alma Linux and other continuations of CentOS. That is not to "hit back" at Red Hat or IBM, they are building that because they need it and it was the right thing to do.
This wasn't directed so much to you as it was to the general developer community. We've seen some knee-jerk reactions when bad news comes out, including some people that basically just gave up and said "I'm doing x86 only, ME and vendor blobs are inevitable".
Speaking as a developer, I fully respect the right of any developer, whether it is a lone volunteer or a giant company like IBM to change their direction. It then raises the question about how other people work around that.
Indeed. For us, that's why we have such a stong requirement for owner control, including opening and standardization of the ISA itself. At least this removes all of the artifical barriers that would otherwise be thrown up. For example, Intel and AMD want to make gaming and streaming consumer systems -- they need the ME and PSP to do that, but since the ISA is not open that now steps on everyone else's rights to use the systems in other ways without effectively allowing Intel/AMD access to the data on them, because no one else can (legally) make compatible CPUs that also meet the blob-free / owner-controlled requirements.
For example, do you see the IBM POWER9 chips continuing to be available in sufficient quantities for the Raptor ecosystem?
Yes, there are many, many years worth of the CPUs available.
Do you see any other manufacturer coming along with a 100% open chip to continue from POWER9?
Short answer: yes. Long answer: [redacted] skunkworks [redacted].
They're still planned, just delayed from COVID and the recent macroeconomic meltdown. LibreSoC is also working in the background and contining to make progress, we're not looking at a single pathway to the required silicon here, just that all pathways produce 100% blob free ppc64le ISA 2.07+ compatible devices.
Could you define that? For example, which key software products need to commit to that statement? In practice, how many of the developers on that part of the open source ecosystem are employed by IBM / Red Hat and could that take them down a POWER10 path?
Great question! We'd say just having the main binary distros (Debian, Fedora, SuSE?) ensure they keep their package archives compatible with POWER9 vs. requiring POWER10 is enough. Then the only other group that needs to be on-board is the JIT writers -- don't use POWER10-specific instructions. To be honest, this is going to happen naturally anyway, since no one that we know of is making POWER10 systems that are would be desktop-class or exist outside of a cloud environment, let alone open systems. This all solely due to IBM's poor decision to close parts of the POWER10 platform, it's quite sad.
Does this mean the Chromium libs are now available for building other things? If so, I might have another look at some projects that were pending for me to port.
Yes, we've been investing significant resources in keeping a POWER build of Chromium available, tracking upstream Debian including the security patches but also including the Ungoogled patchset. Our thought was that since Google absolutely refuses to upstream the POWER port (our suspicion is because it is an owner controlled, blob-free platform, this would interfere with the long-term goal of mandated low-level tracking for advertising), why enable any of the Google services at all?
The patches are also fairly easy to unroll in debian/series if you did want to just build a stock Debian Chromium for POWER. In any case, we'd love to see the base patches integrated into the official Debian builds, maybe you could help us get some traction there?
Builds are currently here:
https://quickbuild.io/~raptor-engineering-public/+archive/ubuntu/chromium/+packagesdget -x / apt-get source work against that repository.
Google's unfortunate stance on upstreaming is basically "we won't do it and we won't tell you why".
https://chromium-review.googlesource.com/c/chromium/src/+/3133001Applying Occam's Razor against that yields a few concerning options, including the potential existence of a third party agreement that would prohibit it. As such, the remaining patches need to be carried downstream in various distros; they're already carried downstream for Gentoo etc., see e.g.
https://bugs.gentoo.org/669748 .
