Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jacob's Musings #176

Open
faddat opened this issue May 9, 2022 · 1 comment
Open

Jacob's Musings #176

faddat opened this issue May 9, 2022 · 1 comment

Comments

@faddat
Copy link
Contributor

faddat commented May 9, 2022

Hey guys,

There's been a whole lot of chatter about gno, that even mentioned my involvement in Virgo, and I wanted to mention a bit about my big big hope:

https://twitter.com/notionaldao/status/1523525250654244865?s=20&t=WUZF7nJA-4Vk2KtPM7bceA

Context on virgo: I joined to work on hardware, though the original forum post I made in reply to Jae's tweet is now gone. Also, despite virgo kinda burning out, and Jae leaving tendermint, I've continued to work on hardware, self-funding its development. Right now the status is that I've paid an R&D retainer to PCBViet some months ago, and we get together every few weeks to see if there's a cosmos-suited product. Currently, the blocker is nvme storage for single-board computers. Cosmos nodes really do not perform well without NVMe storage, and I'd like for the eventual product to work up and down the cosmos stack.

Originally Jae and I had been looking into RISC-v cpu cores. The outcome of that work was the following conclusion:

It is possible to build an open source cpu core, but that cpu core would need to integrate various forms of proprietary perihiperal IP, and currently there aren't open source equivalents for those perihiperals

So, the stuff that I'm currently working on will use proprietary components, in the most conservative ways possible, and will include detailed information about the inner workings of the hardware.

It is my opinion that the main weakness of the majority of POS networks is in fact that there aren't enough nodes and users can't really run infrastructure.

With respect to gno, what that means is that I'd like to keep it lean over time.

This brings me to the code that I'd like to contribute to gno, which I mentioned recently in discord:

https://github.com/faddat/archlinux

That right there is an automated build system for amd64 / arm64 docker images using arch linux. I'd like to make that a part of this repository, in keeping with the audit requirements. It can build and push using github actions here.

but wait there's more

https://github.com/faddat/sos

Please pardon the dust on that repo. Before SOS was Seahorse, it was Starport Operating System.

It can also live in CI, using the arch linux build mentioned above, and create an image that can be flashed to a raspberry pi 4. It's also possible to support other device targets, including amd64 servers and the like.

At notional, all of our validators use basically the same setup, for conssitency's sake.

When we approach things like this, we get an open, auditable, predictable, rolling release OS that gno users can use over time.

I'm going to break up PR's as follows:

  • the docker-builder-thing
  • the rpi os image maker thing

Further followup musings

Right now the image build system uses arch linux. If we can be sure of a blob-free life, manjaro may be a better choice because they have much better mainline linux kernel device support, and that would allow gno to ship onto a wide range of devices, including several phones.

@sascha1337
Copy link

unbelievable to come across such an important and relevant quality post having absolute ZERO comments or feedback ?

rly' sad story,
a SHAME actually.

seems like 98% of all crypto users/devs are /bin/rly brain-jailed
inside their /r/cryptomoonshot || /r/wen/airdrop_ yet another ({spintax}swap) & useless NFT.jpeg hamster-wheel bubble world ...

With hardware x edge computing x experimental shit being my hobby and passion, i can't refuse to do lil bit R&D and testing, after reading this issue ticket here by accident -

just out of curiosity i could open the cabinet and do some testruns with countless dUSTy Xtensa // RISC-V's, ARM Cortex A0/4 STM32's, 3-4 rooted AmLogic S905(x2) Cortex-A52 SoC's with various customized buildroot/armbian distro's flashed on 'em,

obviously interesting too, are the few cheap ARM64 android devices with good old termux + docker (yes docker works on android, if you compile and flash a minimal patched kernel) or chroot kali linux on it

AND(!) 2 two older sub-A12 SoC apple devices, that had received enough libusb DFU stack heap feng-shui spray showers (#disabe_wxn_arm64) - to run any code incl. Wasm/WASI straight in/after BootROM on iPhones and iPads WITHOUT even touching iOS (XD) - super easy to replicate, thanks to PongoOS's linux kernel compile makefile OR just as plugin via boilerplate c code that is open-source

( i can recommend anyone into hardware to checkm8 and checkra1n, not really hard to do, and such fun :D )

Wondering now, how gn0lang with pebbledb would perform here lol

@moul moul added this to the 💡Someday/Maybe milestone Oct 20, 2022
@moul moul removed the enhancement label Dec 16, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: 🔵 Not Needed for Launch
Development

No branches or pull requests

3 participants