Be sure to follow @FediTips@social.growyourown.services and also check out Fedi.Tips website

Nope not yet, we can still fight it. We can help others figtht it like the Linux and other people in libre/free and opensource communities are. And the best way to fight it is to boycott using any platform or product that requires it and use good alternatives that resist it.

As far as I found out about this until now is that the X100 (normal cores) and A100 (AI core) are almost the same RISC-V cores, mainly only different in th RVV vector registers length spec VLEN (256 vs. 1024). The RISC-V Unprivileged specification in chapter 31.1.2. Implementation-defined Constant Parameters says this about cores with different VLENs:

The vector extension supports writing binary code that under certain constraints will execute portably on harts with different values for the VLEN parameter, provided the harts support the required element types and instructions.

NOTE: Code can be written that will expose differences in implementation parameters.

NOTE: In general, thread contexts with active vector state cannot be migrated during execution between harts that have any difference in VLEN or ELEN parameters.

So regarding this there may not be so much of a problem.

Another probably bigger problem is that the A100 cores are not really RVA23 compliant, since they do not support Hypervisor Extension: RVH 1.0 which is required by RVA23 and is only supported on normal X100 cores. But then again usual user-level code does not use the H extension instructions. So maybe even this might not be such a problem for most user-space code.

Anyways as things currently stand : the code only gets executed automaticaly and scheduled onto 8 X100 cores, A100 cores are ignored, even if it could also run on A100. If you are sure the code can run on A100, you must manualy move/execute them on A100 (and again they are confined to only the A100 cores).

Probably the Linux kernel and scheduling needs to get some upgraded logic to make it able to freeely move code among X100 and A100 in the future. And again it depends on how VLEN is treated, is it fixed in the code or can it dynamically acommodate depending on the core it is currently on.

Oh and A100 cores have support for vendor-specific SpacemiT IME (Integrated Matrix Extension) , which is based on some proposals for future RISC-V extension, but yeah nothing official yet. And looks like these are not supported on X100.

As for SIMD. RISC-V does not have anything official yet, since the normal and more general V vector extension should be used in most (if not all common) cases to replace the SIMD instructions. There are some good cases for SIMD way of ding things but yeah RISC-V has nothing official yet, they are working on a P Packed-SIMD extension that may be available sometime in the future. As far as I could see neither X100 nor A100 support any of these P instructions.

There is a UEFI Requirements section in the RISC-V Boot and Runtime Services Specification (BRS) specification. But this is optional and as far as I know most SBCs don’t use it. So yeah because of poor mainline Linux kernel and other components (like SBI) upstreaming by RISC-V systemproviders it is still a sad case that often you need a system specific image. So yeah I think we will need to wait until RISC-V breaks more into PC-like and server space before BRS and similar specs get used more.

There is a UEFI Requirements section in the RISC-V Boot and Runtime Services Specification (BRS) specification. But this is optional and as far as I know most SBCs don’t use it. So yeah because of poor mainline Linux kernel and other components (like SBI) upstreaming by RISC-V systemproviders it is still a sad case that often you need a system specific image. So yeah I think we will need to wait until RISC-V breaks more into PC-like and server space before BRS and similar specs get used more.

Well for x86 software still needs to be testing if some instructions are supported dynamically if they want to take adventage of the latest ones. For example you still neeed to test for different versions of AVX or even older SSE versions, since not all the x86 CPUs support everything. In 2020 something similar to RISC-V profiles was also defined for x86: microarchitectural levels. And most software just is compiled for the lowest commonly supported set of x86 instructions, in essence x86-64-v1 or x86-64-v2, depends on the software or GNU/Linux distribution. Although recently some distributions started to provide additional higher levels of packages for programs that benefit most from the use of latest x86 instructions. And then glibc HWCAPS feature enables the system to load the most optimized binary of the appliation. For example see openSUSE Tumbleweed gains optional x86-64-v3 optimization.

To make this easier RISC-V has profiles (the latest being RVA23), which specify a base extension set. So software can target a specific profile, and CPUs advertises which profile they support (+ possible additional extensions). Regarding naming schemes, AMD and Intel are not so clear here either, so it would not be so much different :)

On openSUSE they have snapper snapshotting integrated into package management, so it automatically creates a snapshot before and after updates. And if something would go wrong you could easily select an old snappshot to boot from in the GRUB menu.

Oh yeah. Can’t wait for this. Bad session management/restore is basically the only major thing I still miss a lot on Wayland. Hopefully Firefox and other apps will gain support for this soon (I guess all Qt/KDE apps will get support at once when they also add support to Qt and KDE Frameworks). Anyways I just opened the enhancement request for Firefox for this just hoping they will add support soon.

Read more about it here Boycott, Divest, Sanction movement, details about BDS on Microsoft

Well as they mention it, they do know.

It does not break anything. Just uses C++ and builds upon it and improves it. And MOC comes in when some niceties are required that are hard to do with plain C++ (and be backwards compatible) or when more flexibility is required. If you know how to do it better, well Qt is free (as in freedom) and opensource and you can join the project and replace MOC with a better implementation. Until then it is a not so important detail and foolish to throw away entire Qt and all the numerous goodies and nice things that it brings just for this small detail.

What’s wrong with it? It is basically invisible and all done automatically in the background by the build system.

Why are you sad?

Yes.

Yeah, most newcomers don’t even know about the spins and labs since they are quite hidden. So this is a great thing for getting Fedora KDE Spin on an equal footing in visibility and promotion.

Yeah they are more visible/promoted and offered for downloads on the same equal level as other editions. Otherwise spins and labs can be quite hidden from peopel who do not know they exist.

Install pam_pkcs11 package, which contains the missing library

And even if you are paying for it… Unless the product is opensource and free as in freedom so you can for example self-host it, study the code, change the code (or contract someone else to change it for you) so the product runs just as you want.

I am also gaming a lot and used nvidia in the past and by the description you give I would say openSUSE Tumbleweed is the one. It is rolling release, but they also have extensive QA tests before letting packages get released as updates so it is very stable for a rolling release. And another thing that openSUSE is awesome for is that they have BTRFS snappshotting very nicely configured out of the box so before and after each update it creates a snappshot and if something goes wrong you can just select an old working snappshot from GRUB boot menu. And with Nvidia this breakage was happening well more often the I would like. I also like their Open Build Service where you can find many additional packages which might not be packaged by distro people themselves.