So nothing? Ok

You then execute that SNARK on your local device with your current exact GPS coordinates

No, that’s what I’m suggesting. The proposed method in the paper makes no use of GPS, instead it’s some peer-to-peer network.

You mean the hexagon? What prevents you from mapping your GPS output to a hexagon?

We just re-elected a fascist tyrant who wants to close as many avenues of education and free speech which can be used to educate, organize, and publish against him as he possibly can

Can you point me to instances of Trump closing avenues to education and free speech during his first 4 years? Can’t find any, but I’m curious.

How is this better than just mapping GPS data to a hexagon and sending that to the third-party?

Don’t see the point of this standard which runs over an inferior type of networking

Inferior how? Matter is not comparable to Z-Wave. Z-Wave is a mesh network, Matter is just a standard which would allow Alexa, Siri, Google, etc. to control the same devices. To allow Z-Wave like functionality, Matter is able to work on top of Thread, which is in fact superior to Z-Wave.

is brought to us by the companies that created the interoperability problem in the first place

Of course. You don’t want to be the company known for refusing to participate in an open standard, even if you secretly don’t want it to succeed. Anyways, there’s no reason for companies to not want an open standard for controlling smart devices, since it literally helps everyone support more devices for basically no effort once you add support for Matter.

What part of the OS should managed the packages?

The OS package manager. This is already a thing with Python in apt and pacman, where it will give you a fat warning if you try to install a package through pip instead of the actual OS package manager (i.e. pacman -Syu python-numpy instead of pip install numpy)

This has probably been in the works for years, and RISC-V’s profile (RVA23) for proper user application support was only released a few days ago.

Politicians when they realize the commercialized espionage they’ve allowed also applies to them:

making the support situation worse

The support situation is so bad that both GCC and LLVM have extensive for RISC-V.

Well technically there’s already a few out there, most notably Alibaba (found in DC-ROMA laptop), but these are slow relative to what’s available in other architectures and are there mostly for developers to test the software and make sure it’s ready for RISC-V. But nothing is stopping from buying one and daily driving it, it would just probably be a horrible experience.

And it does not concern you that this RVA profile is version 23

Not sure where you got that information. There are only 5 RISC-V profiles.

And they are incompatible, with version 23 because they lack instructions?

Like all the x86 CPUs from a few years ago that don’t have all the new extensions? Not supporting new extensions doesn’t mean the CPU is useless, only that it’s worse than new ones, as things should be when there’s progress. Or I guess you throw out your x86 CPU every time Intel/AMD create a new instruction?

So a compiler would have to support at least a certain number of those profiles

Do you think compilers only target one x86 version with one set of instructions? For example in x86, there’s SIMD versions SSE, SSE2, SSE3, SSSE3, SSE4, SSE4.1, SSE4.2, compilers support all of them, and that’s literally just for the SIMD instructions. What’s new?

It’s getting there but running a full on PC is such a complex task over micros or special purpose devices.

Design application ready CPUs are hard, but not really for these companies. The main issue was the need for a standard, given how many optional extensions are available for RISC-V. The RVA profiles fix this problem by giving a set of required extensions to be user-mode application ready, and they have been a thing for a while. However, these were lacking one important capability for modern applications: vector extensions. RISC-V already had SIMD support (similar to what x86 has), but the vector extension is so much better there’s really no need to even bother with it except with some microcontrollers .

The RVA23 profile, ratified 4 days ago, addresses this by adding the vector extension to the list of required extensions for an application ready CPU. This should be enough for running modern applications, so maybe we’ll see some nice stuff in the next 1-2 years.

That’s a good thing, meaning you can design RISC-V CPUs without functionality you don’t need (like microcontrollers that only need basic operations). However, for those who want a complete CPU, there are RVA profiles (latest being RVA23), which are a list of extensions required to be an application-ready CPU. So there’s really just 1 “standard” for general purpose computing, everything else is for specialized products.

What do you mean by standards?

ISPs have nothing to do with what the article talks about, this is about logical gates. Anyways, this tech sounds like a research toy to secure some grants for the laboratory.

Government comprises many departments and organizations, which do many things. It’s not a single blob of all good or all bad.

I don’t remember saying the contrary. When one part of the government does something, it was still the government.

not all back doors and CPU bugs are government-imposed

Don’t remember saying every single backdoor is government-imposed. Fact is there’s at least one backdoor that is for the government, whether there’s 1 or 5 doesn’t really matter.

They don’t allow 3rd party clients, as per their ToS:

You must not (or assist others to) access, use, modify, distribute, transfer, or exploit our Services in unauthorized manners, or in ways that harm Signal, our Services, or systems. For example you must not (a) gain or try to gain unauthorized access to our Services or systems; (b) disrupt the integrity or performance of our Services; © create accounts for our Services through unauthorized or automated means; (d) collect information about our users in any unauthorized manner; or (e) sell, rent, or charge for our Services.

You need authorization to access Signal servers, which they don’t give:

we really don’t want forked versions of the app maintained by other parties connecting to our servers. Not only could the users using the forked version have a subpar experience, but the people they’re talking to (using official clients) could also have a subpar experience (for example, an official client could try to send a new kind of message that the fork, having fallen out of date, doesn’t support). I know you say you’d advocate for a build expiry, but you know how things go. Of course you have our full support if you’d like to fork Signal, name it something else, and use your own servers.

In my opinion, this is a horrible decision from Signal.

it may take legislation to give us back control of the computers we supposedly own

The government is the reason why you have backdoors built into your computers and routers.

I guess you know more about hardware nomenclature Linux kernel developers, because they call modern Intel/AMD and ARM CPUs amd64 and aarch64, respectively.