top 51 comments

sorted by: hot top controversial new old
[–] 61 points 1 year ago* (21 children)

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.

  • source
  • hideshow 21 child comments
  • [–] 52 points 1 year ago (2 children)

    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.
  • source
  • parent
  • hideshow 2 child comments
  • [+] 5 points 1 year ago (7 children)
  • [–] 2 points 1 year ago (6 children)

    But isn't WASM for web browsers? How will it be used to build general software

  • source
  • parent
  • hideshow 6 child comments
  • [–] 3 points 1 year ago

    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)

  • source
  • parent
  • [–] 5 points 1 year ago (3 children)

    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.

  • source
  • parent
  • hideshow 3 child comments
  • [–] 3 points 1 year ago (2 children)

    See the main issue with that is you need to bundle everything into the app.

    Modern computing is inherently cross-dependent on runtimes and shared libraries and whatnot, to save space. Why bundle the same 300MB runtime into five different apps when you can download it once and share it between the apps? Or even better, have a newer, backwards compatible version of the runtime installed and still be able to share it between apps.

    With WASM you're looking at bundling every single dependency, every single runtime, framework and whatnot, in the final binary. Which is fine for one-off small things, but when everything is built that way, you're sacrificing tons of storage and bandwidth unnecessarily.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 3 points 1 year ago* (1 child)

    With WASM you’re looking at bundling every single dependency, every single runtime, framework and whatnot, in the final binary.

    you just don't know what you're talking about. wasm has a module-import structure with which you can link libraries at program start-up, and some wasm runtimes also offer possibilities for linking libraries at run-time.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 1 point 1 year ago

    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.

  • source
  • parent
  • [–] 3 points 1 year ago (2 children)

    On the high performance compute / GPGPU side the AdaptiveCPP JIT compiler seems very good for cross-platform operation

  • source
  • parent
  • hideshow 2 child comments
  • [–] 7 points 1 year ago (2 children)

    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.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 22 points 1 year ago* (last edited 1 year ago) (1 child)

    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.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 2 points 1 year ago* (last edited 1 year ago)

    OpenBoot at Sun and Apple had a good 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.

  • source
  • parent
  • [–] 41 points 1 year ago (11 children)

    Do we really need a UEFI replacement?

  • source
  • hideshow 11 child comments
  • [–] 29 points 1 year ago* (7 children)

    Probably not. At least not right now. But China needs one apparently.

  • source
  • parent
  • hideshow 7 child comments
  • [–] 47 points 1 year ago* (6 children)

    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.

  • source
  • parent
  • hideshow 6 child comments
  • [–] 9 points 1 year ago (4 children)

    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.

  • source
  • parent
  • hideshow 4 child comments
  • [–] 11 points 1 year ago (3 children)

    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

  • source
  • parent
  • hideshow 3 child comments
  • [–] 1 point 1 year ago (2 children)

    Hey you sound like someone who knows what they are talking about - is UBIOS also a specification like UEFI is a specification? Hypothetically could others also build firmware that adheres to this UBIOS specs?

  • source
  • parent
  • hideshow 2 child comments
  • [–] 2 points 1 year ago (1 child)

    this post was the first time I heard about UBIOS, so I'm not sure, but if the article is right then yes it is a specification. and if the documents are publicly accessible, then others could hypothetically make their own firmware that is (on paper) compatible.

    but there's more to it. the reason libreboot and coreboot support so few boards is that unless you can get technical documentation from the board manufacturer about how do the components on the motherboard work, its very hard to create a working firmware. reverse engineering this kind of thing is very hard and very time consuming. even the UEFI specification only tells what should the firmware present to the user and the operating system, it leaves lots of things undefined about how should it interact with the hardware, but that's ok because that's not the point of it.
    then the board manufacturer is able to implement firmware verification that cryptographically prevents third party firmware from being used. on android, the boot process is a long chain of bootloaders, where the first one is stored in physically read-only storage and does not continue booting if the secondary bootloader has been replaced with an unauthorized implementation. when you unlock your phones bootloader to install a better android, you basically configure the secondary bootloader to accept booting a third party system. but if the manufacturer didn't want to let you do it, they could just take this function away. also, the UBIOS specification could be incomplete, missing specification for some functionality that is necessary for an operating system to work with it. that can be a mistake or intentional.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 1 point 1 year ago

    Thanks for the info. Usually information like this is locked in forums that are too technical for me. I've had a newborn interest in bootloaders after having some issues with grub some time ago and more recently, migrating to grapheneOS.

  • source
  • parent
  • [–] 7 points 1 year ago

    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.

  • source
  • parent
  • load more comments (1 reply)
    [–] 113 points 1 year ago (16 children)

    Does that mean I will have more choice in which surveillance agency I want to be spied by?

  • source
  • hideshow 16 child comments
  • [–] 42 points 1 year ago (3 children)

    Maybe not, if Intel goes tits-up

  • source
  • parent
  • hideshow 3 child comments
  • [–] 31 points 1 year ago (10 children)

    UEFI is a standard, not a product. You could make your own even

  • source
  • parent
  • hideshow 10 child comments
  • [–] 33 points 1 year ago (3 children)
  • [–] 5 points 1 year ago (4 children)

    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.

  • source
  • parent
  • hideshow 4 child comments
  • [–] 10 points 1 year ago (3 children)

    But you could work together with other people, and you could be many people that each checked his/her part for malicious code.

  • source
  • parent
  • hideshow 3 child comments
  • [–] 1 point 1 year ago (2 children)

    And you could trust them all!

  • source
  • parent
  • hideshow 2 child comments
  • [–] 2 points 1 year ago

    You could do it with enough people that there is several sections overlapping between unrelated people that it becomes infeasible even for state actors to compromise EVERY person attesting any one piece of software

  • source
  • parent
  • [–] 1 point 1 year ago

    I for one welcome this development. China, even if just out of national security interests, has proven to be quite a valuable partner in championing open source alternatives to Western technologies locked under key, proprietary licensing, and other such arrangements, which led to monopolies. China first started doing this with designing and actually building RISC-V architecture devices as a way to move away from x86 and ARM architectures. Now let's hope that UBIOS will be supported in a similar, open source way, so that we can gain more sovereignty over our own devices.

  • source
  • 13 comments in c/hardware@lemmy.world view that post
    [–] [S] 9 points 1 year ago

    Surprised they didn't call it XiBIOS.

  • source
  • [–] 9 points 1 year ago (4 children)

    If it has secure boot, is opensource, and not dependent on having a single entity approve of self compiled binaries OE blobs (like UEFI forcing Microsoft's approval of bootloaders), then heck yeah, this might be great! Otherwise, if it's just some proprietary, closed source alternative to the existing crap, my enthusiasm is limited.

  • source
  • hideshow 4 child comments
  • [–] [S] 3 points 1 year ago (2 children)

    The machine translated version of the Fast Technology/mydrivers article does not mention any of this.

  • source
  • parent
  • hideshow 2 child comments
  • [+] 5 points 1 year ago (6 children)
  • [–] 1 point 1 year ago (5 children)

    Does BIOS have secure boot? Or can secure boot be built upon anything?

  • source
  • parent
  • hideshow 5 child comments
  • [+] 0 points 1 year ago (4 children)
  • [–] 3 points 1 year ago (2 children)

    No. And that is a good thing.

    Sure. If you want your boot sector to be a super effective attack vector.

  • source
  • parent
  • hideshow 2 child comments