You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
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.
The text was updated successfully, but these errors were encountered:
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
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:
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.
The text was updated successfully, but these errors were encountered: