JRepin

joined 2 years ago
MODERATOR OF
[–] JRepin@lemmy.ml 4 points 15 hours ago

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.

[–] JRepin@lemmy.ml 2 points 2 days ago* (last edited 1 day ago)

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.

 

One of the RISC-V SoCs we have been most looking forward to this year is the SpacemiT K3 that features the X100 RISC-V cores that are RVA23 compliant and among the first readily available RVA23 RISC-V platform for running on the likes of Ubuntu 26.04 LTS. In this article is a preview of some very early benchmarks of the SpacemiT K3 with the new Pico-ITX single board computer offering.

The SpacemiT K3 features eight X100 RISC-V cores as well as eight ultra-wide parallel AI computing A100 cores. The X100 cores clock up to 2.4GHz and are RVA23 profile compliant and largely associated as delivering similar performance to the Arm Cortex-A76 cores. The A100 AI cores support INT4 / INT8 / FP8 / FP16 / BF16 and rated for around 60 TOPS API performance. The A100 cores are also among the few RISC-V cores so far available that support RVV 1.0 vector processing.

The SpacemiT K3 Pico-ITX is an interesting little board that pairs the K3 SoC with 10Gb networking, UFS storage, dual M.2 expansion slots, USB Type-C with power delivery and 4K DisplayPort output, and dual channel LPDDR5-6400 memory with 16GB and 32GB configurations offered.

[–] JRepin@lemmy.ml 1 points 4 days ago (1 children)

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.

[–] JRepin@lemmy.ml 1 points 4 days ago

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.

 

cross-posted from: https://lemmy.ml/post/47499847

BayLibre is proud to announce a successful collaboration with SpacemiT to enable initial functionalities of Android 16 on the SpacemiT K1 (RISC-V RVA22 + RVV 1.0) System-on-Chip (SOC). This achievement marks a significant step toward validating and accelerating Android enablement on high-end RISC-V platforms.

The main objective of this project was to validate the feasibility of porting modern Android to recent, high-performance RISC-V platforms. Furthermore, this work serves as crucial preparation for Android enablement on upcoming RISC-V profile RVA23 SOCs, as much of the effort and code will be directly reusable.

 

BayLibre is proud to announce a successful collaboration with SpacemiT to enable initial functionalities of Android 16 on the SpacemiT K1 (RISC-V RVA22 + RVV 1.0) System-on-Chip (SOC). This achievement marks a significant step toward validating and accelerating Android enablement on high-end RISC-V platforms.

The main objective of this project was to validate the feasibility of porting modern Android to recent, high-performance RISC-V platforms. Furthermore, this work serves as crucial preparation for Android enablement on upcoming RISC-V profile RVA23 SOCs, as much of the effort and code will be directly reusable.

 

cross-posted from: https://lemmy.ml/post/47263342

The investment will be used to strengthen the structural reliability and security of KDE's core infrastructure, including Plasma, KDE Linux, and the frameworks underlying its communication services.

 

cross-posted from: https://lemmy.ml/post/47263342

The investment will be used to strengthen the structural reliability and security of KDE's core infrastructure, including Plasma, KDE Linux, and the frameworks underlying its communication services.

 

cross-posted from: https://lemmy.ml/post/47263342

The investment will be used to strengthen the structural reliability and security of KDE's core infrastructure, including Plasma, KDE Linux, and the frameworks underlying its communication services.

 

cross-posted from: https://lemmy.ml/post/47263342

The investment will be used to strengthen the structural reliability and security of KDE's core infrastructure, including Plasma, KDE Linux, and the frameworks underlying its communication services.

 

The investment will be used to strengthen the structural reliability and security of KDE's core infrastructure, including Plasma, KDE Linux, and the frameworks underlying its communication services.

 

Current approaches to addressing deceptive design largely focus on visible interface manipulations, commonly referred to as "dark patterns". With the rise of generative AI, deception is becoming more difficult to spot and easier to live with, as it is quietly embedded in default settings, automated suggestions, and conversational interactions rather than discrete interface elements. These subtle, normalised forms of influence, which Simone Natale frames as "banal deception", shape everyday digital use and blur the line between AI-enabled assistance and manipulation.

This position paper explores banality as a lens through which to reason through deception in generative AI experiences, especially with chatbots. We explore what Natale describes as users' own involvement in their deception, and argue that this perspective could lead to future work for introducing friction to safeguard users from deception in generative AI interactions, such as empowering users through raising awareness, providing them with intervention tools, and regulatory or enforcement improvements. We present these concepts as points for discussion for the deceptive design scholarly community.

Full paper: PDF | HTML | TeX source

 

cross-posted from: https://piefed.world/c/europe/p/1102854/european-union-surveillance-technology-sold-to-rights-violators

cross-posted from: https://piefed.world/c/tech/p/1102847/european-union-surveillance-technology-sold-to-rights-violators

Languages

54-Page Report “Looking the Other Way: EU Failure to Prevent Surveillance Exports to Rights Violators": HTML/OnlinePDF.

  • EU member states host many companies that produce dangerous surveillance technology that can be used to violate rights, the export of which necessitates robust controls.
  • The implementation and oversight of the EU regulatory framework governing export of surveillance technologies have serious flaws, resulting in the technology being sold to those who use it in violation of international human rights and humanitarian law.
  • The EU should tighten the controls requiring states to do greater human rights due diligence, block risky exports, and enforce the transparency and reporting requirements so they provide meaningful oversight and accountability.
 

cross-posted from: https://lemmy.ml/post/47214950

The new report, Permission to Pollute, reveals how the European Commission is taking a chainsaw to permitting rules for energy and industrial infrastructure. This is part of a wider deregulatory push driven by some of Europe’s most polluting industries. Although the EU presents this agenda as the “simplification” of permitting laws, in practice, it risks eroding the hard-won social and environmental protections that underpin these rules.

Since European Commission President, Ursula von der Leyen, took up her second term in office, permitting rules have come under sustained attack from Big Tech, the fossil fuel industry, and mining lobby groups. What’s more, under labels such as “strategic” or “overriding public interest”, harmful projects are increasingly able to side-step normal permitting procedures. But who decides what sort of projects enjoy the label?

Documents obtained by CEO expose how major polluters have lobbied for easier access to permits – and public subsidies – for polluting infrastructure projects. They reveal how the European Commission has actively invited industry players to shape its permitting deregulation agenda. Europe risks not only living with more pollution but paying polluters to create it.

Some of the key industry demands being delivered include:

  • fast-tracked permitting for industrial and energy infrastructure, side-lining democratic participation;
  • simpler, quicker environmental assessments, meaning less protection;
  • more dirty projects classed as ‘strategic’ or ‘public interest’ and therefore getting special treatment in permitting processes, elevated above environmental or social concerns;
  • water protection and nature laws opened up to be weakened.
 

The new report, Permission to Pollute, reveals how the European Commission is taking a chainsaw to permitting rules for energy and industrial infrastructure. This is part of a wider deregulatory push driven by some of Europe’s most polluting industries. Although the EU presents this agenda as the “simplification” of permitting laws, in practice, it risks eroding the hard-won social and environmental protections that underpin these rules.

Since European Commission President, Ursula von der Leyen, took up her second term in office, permitting rules have come under sustained attack from Big Tech, the fossil fuel industry, and mining lobby groups. What’s more, under labels such as “strategic” or “overriding public interest”, harmful projects are increasingly able to side-step normal permitting procedures. But who decides what sort of projects enjoy the label?

Documents obtained by CEO expose how major polluters have lobbied for easier access to permits – and public subsidies – for polluting infrastructure projects. They reveal how the European Commission has actively invited industry players to shape its permitting deregulation agenda. Europe risks not only living with more pollution but paying polluters to create it.

Some of the key industry demands being delivered include:

  • fast-tracked permitting for industrial and energy infrastructure, side-lining democratic participation;
  • simpler, quicker environmental assessments, meaning less protection;
  • more dirty projects classed as ‘strategic’ or ‘public interest’ and therefore getting special treatment in permitting processes, elevated above environmental or social concerns;
  • water protection and nature laws opened up to be weakened.
[–] JRepin@lemmy.ml 9 points 1 year ago (2 children)

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.

[–] JRepin@lemmy.ml 3 points 1 year ago (1 children)

I have the BPI-F3 and it comes with Bianbu distribution by default. It is based on old LTS versions of Ubuntu with some updated packages (like Mesa) and some packages optimized for the X60/K1 CPU. The problem with this CPU/SBC is that SpacemiT is bad at upstreaming the support, they do support only in their own forks of Linux kernel and other software. So upstreaming is done by volunteers and is progressing very slowly (example only for the Linux kernel), so usual distros like Debian do not have support out of the box. Also it is a problem that the K1/X60 has some Imagination PowerVR BXE-2-32 integrated graphics and this one is not supported by Mesa and only has closed binary drivers which Imagination provides to SpacemiT and they then add it into Bianbu. Also keep in mind that even this driver does not support OpenGL (the normal desktop one). Only OpenGL ES and Vulkan. So in essence this means that the compositor/windowmanager and the toolkits like Qt need to be compiled with this support which is generaly not the case in more normal distros. Sometimes they provide two sets of compiled packags, one with normal desktop OpenGL which you then have to replace with the openGL ES variants. And these are usually not so well tested in the normal daily desktop use case.

So for daily use you more or less have to stick with Bianbu Linux on it. If you do that, I would it is quite usable, if you do not find GNOME-based desktop it has limiting as I do, since I am used to the power and plethora of features in KDE Plasma :) It is a bit slow for some more demanding tasks like video, graphics, games and stuff like that, but yeah, for simple office usecases, it is fine. So depends on what you would use it to do.

[–] JRepin@lemmy.ml 3 points 1 year ago* (last edited 1 year ago)

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.

[–] JRepin@lemmy.ml 9 points 1 year ago (1 children)
[–] JRepin@lemmy.ml 4 points 1 year ago

I would guess these are for device-tree specifications and run-time detection of what extensions some RISC-V CPU supports. Also might be some support for using these extensions in some common kernel code that is used by other parts of the kernel. But to be sure we would need to check the commits themselves.

[–] JRepin@lemmy.ml 1 points 1 year ago

Well as they mention it, they do know.

[–] JRepin@lemmy.ml 2 points 1 year ago (1 children)

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.

[–] JRepin@lemmy.ml 2 points 1 year ago (3 children)

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

view more: next ›