this post was submitted on 24 Oct 2025
242 points (98.8% liked)

Technology

76388 readers
1740 users here now

This is a most excellent place for technology news and articles.


Our Rules


  1. Follow the lemmy.world rules.
  2. Only tech related news or articles.
  3. Be excellent to each other!
  4. Mod approved content bots can post up to 10 articles per day.
  5. Threads asking for personal tech support may be deleted.
  6. Politics threads may be removed.
  7. No memes allowed as posts, OK to post as comments.
  8. Only approved bots from the list below, this includes using AI responses and summaries. To ask if your bot can be added please contact a mod.
  9. Check for duplicates before posting, duplicates may be removed
  10. Accounts 7 days and younger will have their posts automatically removed.

Approved Bots


founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[–] gandalf_der_12te@discuss.tchncs.de 62 points 2 days ago* (last edited 2 days ago) (8 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.

[–] AdrianTheFrog@lemmy.world 3 points 1 day ago (1 children)

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

[–] Amir@lemmy.ml 1 points 5 hours ago (1 children)

What does this do that C# doesn't?

[–] AdrianTheFrog@lemmy.world 2 points 2 hours ago

GPU stuff and ideally easier parallelism. The same binary could be executed on a GPU from any vendor, any CPU, anything that supports OpenCL, and could maybe even be extended to support FPGAs in the future.

[–] certified_expert@lemmy.world 52 points 2 days 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.
[–] gandalf_der_12te@discuss.tchncs.de 15 points 1 day ago* (last edited 1 day ago)

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

[–] atthecoast@feddit.nl 3 points 1 day ago

Yes, RISC-V largely forms the basis for china’s future tech “independence”. Most CPU’s are Chinese brands and SBC’s like SiFive are Chinese too.

[–] fluffykittycat@slrpnk.net 35 points 2 days ago

RISC-V is this

[–] eleitl@lemmy.zip 2 points 1 day ago

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.

[–] uairhahs@lemmy.world 19 points 2 days ago

Those are called duopolies (yes it's a very common thing)

[–] nyan@lemmy.cafe 7 points 2 days ago (1 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.

[–] krooklochurm@lemmy.ca 22 points 2 days ago* (last edited 2 days ago) (1 children)

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.

[–] Alaknar@sopuli.xyz 6 points 1 day ago

If you’re using anything else you may as well just break your computer and drink cyanide

Unless it's TempleOS.

[–] melfie@lemy.lol 5 points 2 days ago (1 children)

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.

[–] embed_me@programming.dev 1 points 1 day ago (3 children)

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

[–] gandalf_der_12te@discuss.tchncs.de 5 points 1 day ago (1 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.

[–] fonix232@fedia.io 3 points 19 hours ago (1 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.

[–] gandalf_der_12te@discuss.tchncs.de 5 points 9 hours ago* (last edited 9 hours ago) (1 children)

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.

[–] fonix232@fedia.io 2 points 8 hours ago

Oh, good to know. Last time I checked around WASM this wasn't really an option.

[–] Natanael@infosec.pub 3 points 1 day 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)

[–] eldebryn@lemmy.world 1 points 1 day 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.

[–] Alphane_Moon@lemmy.world 3 points 2 days ago

How is performance though?

And honestly ARM isn't that much than x86 in terms of freedom and competition.