@da_667 Can't bring myself to buy anything online, and have my wife do it for me.

Don't allow my phone to handle money, ever.

Visit places in person and talk to a human for anything important wherever possible.

Just assume everything is always exploited, keylogged, monitor read via yagi antenna, and just try to make them _work_ for it a little, and maybe annoy them.

Care about "countering trusting trust": http://lists.landley.net/pipermail/toybox-landley.net/2020-July/011898.html

Did that with hardware too for a bit: https://j-core.org/

[Toybox] Countering trusting trust.

@kkarhan If you mean j-core it was pretty decent a year ago? I've been busy with other projects since, last checked in with those guys around new years. (They were working on a battery controller project.)

Getting _hardware_ for j-core was always the hard part, unless you feel up to porting a VHDL project to a new FPGA dev board? (Looks like the numato mimas v2 is still available but inflation's upped it to $70+shipping. Turtle was way better but limited production run.)

@kkarhan @stman Aboriginal Linux used to have sparc binaries built against uclibc, but sparc isn't supported by musl. (Ask @dalias why not...)

Sigh, I can do riscv. I just have trouble taking it seriously because it SMELLS to me like an open source version of itanium.

http://www.catb.org/~esr/halloween/halloween9.html#id2867629

Halloween IX: It Ain't Necessarily SCO

@landley @kkarhan @stman It's not because it's a wishlist item on a project built almost entirely by volunteers, and the person researching sparc and trying to get a working port made some progress a while back but hasn't finished it.
@kkarhan @landley @stman musl is designed so that it's "easy" to add archs, but it requires at minimum some testing capability and some asm & ABI expertise for a couple nontrivial things like sigsetjmp. In the case of sparc I think there's also an issue of poking the compiler tooling not to do stuff we don't support wrt how it does dynamic linking.

@dalias @kkarhan @stman The library stuff I might be able to do. The gcc stuff is nuts. I've never got llvm+musl to build for anything except Hexagon.

But mostly I look at things like
https://github.com/jcmvbkbc/musl-xtensa/commits/xtensa-1.1.16 which is still out of tree despite having a qemu-system-xtensa, a "guy who did it" contact email, and both qemu_xtensa_lx60_defconfig and qemu_xtensa_lx60_nommu_defconfig booting in buildroot, and go "I guess it's hard if that isn't enough to add support".

Commits · jcmvbkbc/musl-xtensa

musl port for xtensa. Contribute to jcmvbkbc/musl-xtensa development by creating an account on GitHub.

GitHub
@landley @kkarhan @stman There's a lot of stuff wrong in that port and they never engaged about making it upstreamable. I'd love to see it move forward especially since this is a very relevant arch (ESP), but I've had things I wanted to do more than fixing it up myself and setting up test environments to confirm I didn't break anything.
@dalias @kkarhan @stman Hmmm, the guy who did the patch posted to linux-kernel form the same email address 6 days ago (about an fdpic patch)... Ok, taking this thread to email.

@kkarhan @dalias @stman @OS1337 Nope, PowerPC is the highest-end open hardware solution. Here's a 3ghz at 45 nanometer SMP chip:

https://github.com/openpower-cores/a2i

There's various other open powerpc implementations as well: https://github.com/antonblanchard/microwatt

GitHub - openpower-cores/a2i

Contribute to openpower-cores/a2i development by creating an account on GitHub.

GitHub

@kkarhan @dalias @stman @OS1337 There are three interesting performanc metrics: 1) linear singlethreaded performance, 2) price/performance ratio, 3) power consumption/performance ratio. You can be fastest, you can have the best bang for the buck, you can have the best bang for the watt.

The linear singlethreaded performance thing was never quite my area and kinda wandered over to GPUs some years back. I mostly focus on power/performance because batteries, cooling, cluster density...

@kkarhan @dalias @stman @OS1337 Absolute linear performance is fab node as much as anything else: a 28 nm chip will never beat a 7nm chip unless somebody really screwed up. Then being willing to run wall current through it and use water cooling, and parallelism out the wazoo (SIMD and big busses and cache... when using SMP it's all about the interconnects.) That's its own thing, and usually involves throwing money at the problem.

@kkarhan @dalias @stman @OS1337 A lot of mainstream stuff is price/performance, because ever since beowulf clusters in the 1990s you can speed up a lot of things by making your cluster bigger, and beowulf was to "cloud" as Altair was to PC.

But price/performance is primarily a matter of unit volume, which is why people made supercomputers out of Playstation 3 clusters. Riscv is trying to do a self-fulfilling prophecy there, but who's going to cough up the $5 billion for one big production run?

@kkarhan @dalias @stman @OS1337 Power/performance is your phone battery life, and you can't get rid of much heat without a fan (power consumed becomes heat) which will cook your batteries, and in compute clusters the power+aircon costs as much per month as high-end hardware depreciating (getting RID of the heat again is $$$), and a big limiting factor on your cluster's density is heat dissipation...

Cloud switched from x86 to arm for better power/performance ratio.

@kkarhan @dalias @stman @OS1337 The other thing is userbase translates to R&D budget. When laptops overtook desktops in 2004, the "blade server" was invented to deploy laptop hardware in the server space because that's what was getting all the research and development funding. The rise of phones made something like the raspberry pi inevitable.

All of this says the network effects (feedback loops) are very much AGAINST riscv. Linux ran on existing PC hardware for a _reason_.