High performance microarchitecture is never going to be open source. They cost hundreds of millions to design and the design stays relevant only 4-5 years.
RISC-V will bring much needed diversity to spaces currently dominated by two titans.
https://en.wikipedia.org/wiki/Intel_Management_Engine#Claims...
With RISC-V, it is reasonable to expect multiple vendors to provide CPUs. There is a very good case to expect non-backdoored chips.
That's true, but the way they do that is in a way that requires minimal changes. In terms of the management engine, that means not including AMT module (software) but keeping the rest of the ME (hardware). After all, it also does some essential things like power management and the bootloader. Removing it completely would also mean re-implementing the essential functionality.
The best you can hope for if you want to use mainstream parts is something like me cleaner where the management engine is only there for the boot, but is disabled afterwards. Something without an management engine would certainly possible, but would be limited to niche products like the librem.
I don't share this forecast. I think many private customers would view a machine without the ME and it's capabilities as a plus for a product when the marketing is done right. Especially since most don't care for the capabilities.
A lot of people say they value privacy, but when push comes to shove, they'll willingly trade privacy for convenience and cost. See: any facebook/instagram user, or iOS users who use google maps. iOS/Mac is marketed as the private phone/computer, but their market share shows how little consumers are willing to pay a premium for privacy (except in the US where iOS share is surprisingly high). You can try to convince consumers otherwise, but in truth, a management engine with backdoors/0days isn't really applicable to most consumers' threat model. The risks from social engineering attacks or unpatched software is a much greater threat.
Even today, with hardly any hardware, there's (to various degree of completion): Debian, Fedora, Slackware, FreeBSD, and seL4.
Ideally, once there is a JVM that runs on riscv, those apps are ported for free. An openJDK port is underway.
I have no idea how much work it would be for Android to port its APIs, but Google certainly has the manpower if this is something they want.
The major pain points today are the JITs, which applies to Java and JavaScript in particular. There has been preciously little (public) progress on these.
But the compiler (openjdk in this case) still needs to be ported, no?
EDIT: I think we are talking about two different things. The Java compiler (which emits Java bytecode) should be ported for convenience but that is not necessary. The compiler which compiles the actual JVM into an executable doesn't need to be ported, but it does need to have support added for emitting riscv machine code.
[1] https://www.scmp.com/tech/innovation/article/3022747/heres-w...
I got one interview out of it, but I feel like maybe the Foundation is the right place for that. They'd have to delegate the hiring and management to a member, but I think it could work.
Huawei has their own VM for Android, so they would likely port that for their effort.
People love to come up with fantasies and try to work backwards from them, but sometimes you really can't get there from here.
You have a surplus of condescension and a lack of imagination.
They didn't until now, but the US government just told them commercial OSes with a connection to the US can not be trusted, so they might very well be rethinking that.