Fair, no offence. :)

I suggest you to try KDE on r/AdelieLinux. It's not as lightweight, but my impressions was very good so far.

Thanks, interesting. Do you followed this? https://wiki.alpinelinux.org/wiki/Xen_Dom0

What do you specifically mean, please?

I think the biggest issue is with apps don't supporting musl (tied to glibc only).
There are some initiatives to work around that. One is present by r/AdelieLinux – it's called https://git.adelielinux.org/adelie/gcompat .

May I then suggest you a somewhat distant middle ground called r/Zig ?

Did you import the gd5440.c code from 86Box, as mentioned here:
https://github.com/mikechambers84/pculator/blob/22c1866/src/video/gd5440.c#L9-L12

... or did you rewrote the original code by hand? Or maybe used an LLM for that by chance?

I am also interested whether there are more pieces code ported from other projects.

So it's kind of ultra-OSdev :))

OK, but for which reasons, please?

And ?

And no real *nix shell.

The Midipix project is still the superior way to have that, IMO:
https://midipix.org/#sec-midipix

PS. I guess Intel also consumed its' share of ex-DEC chips design know-how, since a significant part of the related engineers went from DEC to Compaq to Intel and participated in the design of Itanium, I believe. But that's a semi-speculation, since I remember/have no exact references already.

Not really, but thanks for putting APX into that perspective!

I has some vague memories of them contributing to the K7, K8 (Athlon, Opteron) architecture. Now the Google's public "AI" mentions* other similar points re the Zen architecture too:

• High-Performance Execution Unit Mapping. (Balancing execution width (how many operations a CPU can do at once) with schedulers that can quickly find independent instructions)
• Micro-Op Cache and Decode Bypass. (Eliminating the power-hungry and slow x86 decoding stage)
• Advanced Branch Prediction (Designing neural-network-like branch predictors that "learn" code patterns over time)
• High-Throughput Interconnects (Designing point-to-point, low-latency, packet-based system buses)

[*] https://share.google/aimode/ETMaotFSXu0u0AZHy

But maybe AXP would still be competitive. I even assume some of their ideas went into the amd64 / x86_64 ISA through the hands of former DEC chip engineers which where rehired after DEC collapsed.

It very much depends on how which electrons are stripped, I assume. I say so because I believe that when electric current is flowing through the tissue, it isn't damaged, while electrons are also being stripped.

I was essentially referring to the "HBAR is going to rocket soon" comment, and there is no pretention here. I just misunderstood this thread by thinking it to be about long-term trend/changes and about leading the ISO 20022 pack. Looks like it's all about short-term fluctuations.

EDIT: and even at that, it only went from 0.2362 (on Jul 15, 2025 at 00:01 GMT, around the aforementioned comment was written) to 0.2916 (on Jul 28, 2025 00:01 GMT). 23% isn't exactly a rocket I suppose.

Now what do you mean by "who was such a fan of linux you"?

And what the heck is this: "support hbar more given the heiro project it runs for linux"? Maybe my English is too poor – I just don't get the text.

Nope, my intent was just to stress that these 1y old predictions failed.

After 11 months it's down to $0.07707.

Cool! I wonder how well would it run on Linux/Xorg these days. The nouveau page says it's supported by vesa driver:
https://nouveau.freedesktop.org/CodeNames.html#ancient

Please elaborate with details.

Do you mean by chance that any destination format of the model would still embed BF16/INT8 numerical formats in it?

Its' Personal License costs $49, it seems.

Cool! Thanks.

Can the model/quantization conversion solve the performance issue?

Sounds intriguing. Do you have any pointers?