Our hardware has its own problems.
We rely way too much on x86 and ia64 architecture, both of which have only two big manufacturers in the world. That’s not good because it’s almost monopolies.
It would be better to have simpler chipsets that can be produced by more manufacturers worldwide, and especially ones that can be produced by smaller regional manufacturers.
On top of that we shouldn’t distribute compiled binaries for the x86 and ia64 chipsets; instead program code should be distributed like
.wasm, in a hardware-independent way, and compiled on the target device. That would enable that hardware can use any chipset it wants and there are no software incompatibilities because of it.OpenBoot at Sun and Apple had a ggo thing going for a while. Too bad they didn’t release it as open source. In theory you could deliver architecture-independent drivers that ship as firmware on device.
RISC-V
- royalty free
- future-proof
- extensible
- base ISA is 40 instructions!
- beautifully documented
- can perform in a range of situations, from embedded to many-cores servers!
- can handle petabytes of memory (the higher schemes)
- no nonsense historic compatibility drag.
hell yeah risc-v is hella cool :)
i just looked into how it works:
https://en.wikipedia.org/wiki/RISC-V
seems very sane so far.
beautifully documented
i can attest, very nice indeed.
RISC-V is this
Those are called duopolies (yes it’s a very common thing)
I have been waiting impatiently for WASM to really take off. I’d imagine that some day, it will be the most popular way to build software.
But isn’t WASM for web browsers? How will it be used to build general software
But isn’t WASM for web browsers
not really, no. WASM is a generic hardware-independent format for instructions. it’s like instructions for a virtual CPU, not a real one. it gets translated into the instructions for the real processor on the target device. in this way, it can run on any hardware.
comparing it to other setups such as java or javascript (which are also both hardware-independent), it runs much faster because it is much hardware-oriented, while java and javascript require abstract features such as a garbage collector, which makes real-time processes impossible.
WASM was made for browsers but can run anywhere. You can cross compile any language to it.
The trickier problem is compiler time hardware optimization, but there’s talks about appending architecture specific optimization hints for the runtime, so you can let the compiler search for optimal implementations when creating the bytecode so the JIT engine doesn’t have to. (that does mean you’re essentially compiling multiple times while creating the bytecode, but for performance sensitive software it’s worth it)
A bunch of desktop apps use electron anyways as a runtime. WASM could allow us to have better/more reliable software that doesn’t rely on JS, which isn’t ideal for many use cases.
Is it efficient? Definitely not, but for system apps we have other choices which are more performant like C and Rust. These days 90% of the software people use are either web apps in a browser or web apps with an electron gui running outside their browser but inside the Electron browser: P.
On top of that we shouldn’t distribute compiled binaries for the x86 and ia64 chipsets; instead program code should be distributed like .wasm, in a hardware-independent way, and compiled on the target device. That would enable that hardware can use any chipset it wants and there are no software incompatibilities because of it.
You’re describing Gentoo Linux . . . which is not especially popular among Linux distributions even though it runs on just about anything. There may be a reason for that.
Well, they’re talking about something lower level than the operating system. For one.
Secondly, every distro is inferior to the only perfect thing mankind has ever created: Hannah Montana Linux. If you’re using anything else you may as well just break your computer and drink cyanide.
If you’re using anything else you may as well just break your computer and drink cyanide
Unless it’s TempleOS.
How is performance though?
And honestly ARM isn’t that much than x86 in terms of freedom and competition.
Does that mean I will have more choice in which surveillance agency I want to be spied by?
There’s no need to change mobo to have that, just install Temu app or similars.
UEFI is a standard, not a product. You could make your own even
Or use this…
This doesn’t support many boards.
True, but I really appreciate that someone is doing it. (It’s far beyond my capabilities…)
Tianocore open source uefi implementation exist for many years
could
could in the same sense that i could check all software i use for bugs and malicious code. realistically, i can’t, because it’s way too much work.
But you could work together with other people, and you could be many people that each checked his/her part for malicious code.
And you could trust them all!
Why would you do it with people you don’t trust?
So that just means UBIOS is explicitly for spying since UEFI is open source and a standard right?
Maybe not, if Intel goes tits-up
Implying Intel motherboards will ever support more than US govt approved technology now that they have a substantial holding in Intel
I think that’s their point. You wouldn’t have a choice again if Intel goes out of business.
Ouch.
Do we really need a UEFI replacement?
It’s about national security. They don’t want to risk using something that they don’t control for the same reason the US doesn’t want to risk using something they don’t control. It’s why Intel probably can’t fail. If Intel goes down then the US doesn’t have a strong native CPU producer.
Yeah we should replace it with legacy bios.
Probably not. At least not right now. But China needs one apparently.
My thoughts are “Why do they need one?”. It’s not like UEFI stops you doing anything.
UBIOS’s unique features over UEFI include increased support for chiplets and other heterogeneous computing use-cases, such as multi-CPU motherboards with mismatching CPUs, something UEFI struggles with or does not support. It will also better support non-x86 CPU architectures such as ARM, RISC-V, and LoongArch, the first major Chinese operating system.
[citation needed]
I would say this is about increasing the level of control of the platform, not about technological issues.
Edit: For example, here’s the RISC-V UEFI specification.
It’s about having a home grown option. Can’t trust Americans not to backdoor everything, and that generally conflicts with China’s desire to backdoor everything.
america cannot really backdoor a specification. uefi is not software, but a specification, upon which firmwares can be built. that’s another story that we happen to be calling the firmware on our computers “the uefi”, but really there are quite a few different proprietary uefi implementations out there already.
so, if that ws the reason, they could have just created their own UEFI firmware, and not something different
Control is the most important thing to the CCP so it makes complete sense from their perspective. We would be free to buy into it but they would definitely force it on devices within China.
For x86 or ARM?
