But as long as they are RISC V chips, then they would run the same software as any other RISC V chips.

Not necessarily, RISC-V is permissibly licensed, so they could add proprietary extensions, that would make the binaries or even compilers only work with their implementation of the RISC-V ISA.

Embrace, Extend, Extinguish tactics would work on RISC-V, and I trust billionaires and huge corporations to enshittify it.

Big player joins RISC-V, creates design, introduces proprietary extensions, builds compilers that use them, software depend on them, other RISC-V designers need to license them, because the whole platform now depends on them.

Also based on how complicate it is to port Linux to different SoCs, which at least share a common ISA, it will be much more difficult if you need to support even more RISC-V ISAs with different proprietary extensions, not only in the kernel, but in the toolchain as well.

So a bit like extending Mozilla Application Suite aka Seamonkey instead of focusing on standalone products?

AFAIK, UEFI isn’t technically a requirement. However, TPM 2.0 is, and that requires UEFI.

TPM 2.0 does not require UEFI. I have a system here with TPM 2.0 and only legacy boot support. And you can just buy a TPM 2.0 module and connect it with any board, that has a SPI connector.

TBH, it is very difficult to me differentiating between the different flavors of authoritarians.

Maybe someone can make an easy to understand comparison matrix? You know, “Kills people because they have a different opinion.”, “Suppresses minorities.”, etc.

Interesting discussion about this on the OpenStreetMap forums.

The resolution is introducing “official_name” tags, referencing “en_us”, because “en” is not just the U.S.:

https://community.openstreetmap.org/t/gulf-of-america-gulf-of-mexico/124571/11

So when OsmAnd or OrganicMaps start to support them, maybe your locale settings will change the displayed name there as well.

Current description of that node: https://www.openstreetmap.org/node/305639190/history/80

So maybe that could be a reason for everyone around the world to stop using en_US locale settings. XD

There are different degrees of vendor lock in. If you use email (or Matrix) with a domain, you have no control over, you are soft-locked it. You can buy a domain, self-host or pay for a managed service and inform everyone that you are now reachable over some other address, but nobody else has to change.

If you use Signal (or Discord or whatever) and want to switch to a different domain. You cannot. If you switch to a different protocol, everyone in your contacts has to switch as well, or you lose that contact. The network effect forces you into the service of one provider. The only way out of there would be if the service get so bad, that a critical mass leaves, but you will have to deal with that bad service all the way.

As long as financial interest are there, non-federated services will sooner or later start to enshittyfy. So if you choose a communication medium, choose something that leaves your options open. If you don’t like Matrix, try XMPP, it has come a long way as well.

Matrix?

IMO the whole “metadata insecurity” stuff about Matrix is over exaggerated. Also Matrix is improving there.

If metadata security is really that important, you could try Tox or similar P2P chats.

AFAIK, Signal does not want anyone to use alternative clients, has that changed?

As far as I know moxie, signals lead dev, considers only the use of the officially build and distributed client authorized to use their servers.

So if they ever manage to detect someone using their services with an alternative client, they might delete your account.

https://techcrunch.com/2016/11/07/signal-app-maker-rebuts-criticism-of-dev-direction-by-calling-for-more-community-help/

Well, you can still insert client side decryption into the app.

But it isn’t really about the messages, it is about the control of the servers and the accounts. You cannot easily move away from their servers, because you will lose your contacts. This gives the people controlling the servers power over you. A sort of vendor lockin.

The company (Signal Messenger LLC) is fully owned by Signal Foundation, a 501©3 non profit organization.

OpenAI is also non-profit. Not really an argument.

Probably around 80-90% of Matrix users are on the matrix.org homeserver, so it’s absolutely not as decentralized and resilient as you think it is.

Well, the goal is that moving to your own server, will not mean that you will loose access to all your contacts. Which makes moving instances much simpler. If Matrix gets a hostile take-over, your don’t really need to reach a critical mass for an alternative server.

But you should also be aware that Signal does not federate, so the company can be bought. They have control over all accounts and the servers, without easy way to migrate away again. So it might just be another trap.

Try to use federated services (like matrix), they are more robust against hostile take overs.

If ARM is a small market, RISC-V is even smaller.

I personally like when boundaries are pushed, and welcome more independence on x86.

I would argue that it is about incentives. A market economy is about maximizing profit, so that (the class of) shareholders get more money out of it, than they put into it. Incentivising making money means you incentives a race to the bottom, producing lots of expensive and addicting crap that easily breaks for as little cost as possible. And you incentivise massive consumption of it.

A socialist economy should instead incentivise improving the world for all the people that live in it. Produce stuff that is robust, adaptable, sustainable and so on. Incentivise the mindfulness of the social and ecological impact of each product. And if someone needs something special, incentivise local makerspaces etc. that allows people to produce custom stuff in low quantities.

China is not communist, they are market-captialistic, one-party highly authoritarian state. “socialism” and “cmmunism” is just used to make them sound better and more legitimate than they are.

The first phone I bought myself (I had others before, but they where hand-me-downs) was the N900, which should have been the next generation of smartphones/devices. But because of Microsoft and Stephen Elop it wasn’t.

Not sure you understood my point. The “Gold” that people search for when trying to push “AI” is that they have to pay less wages, because they need fewer employees. Wherever they find it, or not is irrelevant.

Automation was always heralded as a time saver, but do employees really need to work less to get the same amount of money? No, because automation is always used to give the top percentages more money for less work, not the workers or the broad public.

Obsolescence of human workers/employees.

I haven’t looked into it (because Android repos are confusing), but I assume it allows just one specific signature to spoof one other specific signature. If so then I do not see such a security issue, because it wouldn’t suddenly open this mechanism up to everyone.

Even if it would require spoofing of multiple signatures, if there is a limited list of signatures to spoof as and a whitelist of signatures for the apps that are allowed to spoof them, then it would also be limited enough, IMO.

IIUC, you don’t need to patch LineageOS anymore for MicroG: https://github.com/lineageos4microg/android_vendor_partner_gms/blob/master/README.md#microg-mobile-services

Well it seems like a pretty natural fallacy to think that if something talks to us, in a language that we understand, that it must be intelligent. But it also doesn’t help that LLMs, aka. fancy text generators built with machine learning algorithms, are marketed as artificial intelligence.

Maybe an unpopular opinion here, the Android security model is based around trusting the vendor of the device or ROM more than the end-user, which I find wrong in principle. The origin of trust needs to be fully in the hands of the owner of the device. Otherwise you take away the self-determination of the users, and that should never be an option when it comes to security.

Users themselves should be able to give or take away trust however they choose, and if they are unsure on whom to trust for certain things, they should be able to delegate that trust-management to a third-party on their own accord and with the ability to revoke it at any point.

Everyone is different, and trusts entities to different degrees. For instance I would trust MicroG more to only transmit data that is absolutely required to google servers, than the gapps.

Also, modifying the kernel is already done by google, in order to provide hardware support, so patching it additionally doesn’t automatically make it more or less secure. That depends on what those patches do, and if those patches are properly maintained.