RockPi Raspberry Pi hardware messaging

Staking & Delegation Operate a Stake Pool
,
1

I realize that it’s great marketing to say that Cardano could be really low power system and run on these devices. However, we’re trying to build the world’s next financial system here. Shouldn’t we be pushing pool operators to run on more powerful hardware?

We’re going to have multiple revenue streams in the future and these systems will likely take more processing power than these hobby devices can deliver. Why continue to tell people they should be using these devices?

I love them too and run a tiny NTP server on one of them to give accurate time to my nodes, but I wouldn’t run a stakepool on them.

What do you think?

1 Like
3

My understanding is that the main reason Rock PI support is so difficult is because the Haskell compiler has bugs in the Runtime System. This has been a long running issue https://gitlab.haskell.org/ghc/ghc/-/wikis/arm64

The haskell node wiil run correctly on an Intel Nuc box (which is x86_64).

3 Likes
4

I would argue a bit on this as you only pointed out the cross-building on Android, but forgot to mention the cross-building on RaspberryPI (which I think is possible) even the cross-compiling issue, which is, I think, a much much bigger issue than cross-building.

Because, almost all components, libraries use TemplateHaskell (or use other modules that depends on TemplateHaskell) which prevent them to be cross-compiled to different targets (e.g. to iOS, Android, RockPi etc.).

I can understand why Plutus Core use that feature, but cannot why the low level libraries or components should.

Why is this an Issue? Cos no any mobile device could use any part of the haskell code and therefore all these parts must be completely rewritten in different languages if we want to use them on mobile devices.

Means, mobile devices are not first class citizens (if they are citizens at all) in the Cardano, therefore, how we would like to have adaption, then? Pls, do not come up /w Yoroi or any other centralised wallets.

I know I know, and pls do not talk about ghcjs, but that’s not a solution.
A better would be, for example, having low level libraries, componenst (e.g. ouroboros-consensus, ouroboros-consensus-shelley, coin-selection etc. etc. etc.), that could be used in any native code in IOS, Android etc. But, for long we would not be able to do that.

That was a f*ng bad Design decision at last.

1 Like
5

Do you see communications and promotion about this recently?

I would say that’s up to everyone, and not just the hardware. 24x7 IT-Services usually and practically is delivered and handled by a team of system operators.

I personally prefer the RockPi over the RaspberryPi because of the much better permanent storage options. (eMMC, and PCIx NVMe). But of course this will never be a Xeon, error correcting memory, hardware and battery backuped Raid60 system, not to talk about virtualized systems running on redundant storage, computing and networking platforms.

What is the goal of aarch64 class SMB computers?

  • Inclusion. Show that it is possible, if you agree with the limitations. But also know the limits and boundaries
  • Show practically the advantages of PoS vs PoW (smart vs brute force)
  • demand development for different hardware/plattform environments, not just one ideal case.
4 Likes