<TimMc>
jfred: The downside of recycled hardware is that it's often pretty power-inefficient. :-/
<TimMc>
(as I'm finding out with a borrowed power meter)
<jfred>
Old x86 hardware is, but I feel like we're getting to the point where people's old phones are both pretty powerful and power-efficient
<jfred>
Like if you upgraded from a Galaxy S9 to an S20 recently for example, that S9 is still pretty dang powerful for what it is
<jfred>
And it's still an ARM phone with the power usage typical of one
<isd>
I see utility in an arm port, just not sure I see the point of the distributed version
<jfred>
the main point as I see it is 1) the base hardware could be cheaper because it doesn't have to be very powerful, and 2) upgrading/expanding wouldn't require completely replacing the hardware and could use a (pretty powerful) device that you're done using anyway
<isd>
I guess I would dispute (1); you could run the whole business on that hardware -- and if it's not powerful enough then you have to get a whole other machine to run the rest of it, so I'd be surprised if that worked out in terms of cost.
<ocdtrekkie>
I think the biggest constraint Sandstorm is likely to face on upgrading/expanding is probably storage, more than compute.
<ocdtrekkie>
Being able to store grains on multiple logical storage devices would probably get you the vast majority of expandability without excessive frustration.
koo6 has joined #sandstorm
<xet7>
Raspberry Pi 4 (maybe earlier models too) can boot from USB drive. I did copy microSD card content to external USB3 SSD and I do boot RasPi4 directly from that USB3 SSD. There are other arm64 devices that have SATA connections for harddrives etc.
<xet7>
Another way is to create symlink to USB harddrive directory
<isd>
A clearer advantage of doing an arm something is being able to recommend a stock "buy this exact machine," and maybe build stock images, rather than having to say "hunt around for something vaguely like this"
<isd>
I think for really broad adoption you should eventually be able to buy a computer with Sandstorm pre-installed.
<ocdtrekkie>
And probably with phone apps or something to get you though any initial setup prior to the welcome interface...
<isd>
Yeah, I could see a nice workflow where you print off a a sturdyref as a QR code sticker and stick it to the box...
<ocdtrekkie>
QR code was what I was thinking too, yeah.
<abliss>
i've long thought it should be built into a Chromecast-like device (and piggyback on its setup)
<isd>
By chromecast-like do you just mean something built on top of mDNS?
<isd>
(I have never actually set up a chromecast, though I vaguely understand how they work once set up)
<abliss>
i mean a small ARM computer that people buy and plug into their TV and control with their phone.
<isd>
Having monitor & keyboard would simplfiy setup, and the RPI has the hookups for those anyway.
<isd>
Tangentially related: we should be able to fulfill powerbox requests with stuff discovered via mDNS.
<isd>
Might be able to build this as an app using ipNetwork.
<abliss>
though nowadays i guess it's mostly built into the "smart tv", so maybe it makes more sense to put the sandstorm server in the TV. Easier to get power (unlike chromecasts which need a futzy extra cable for power).
<abliss>
(the chromecast setup is like (1) install the app on your phone (2) the app makes your phone connect to the chromecast over ad-hoc wifi and give it the password to your real wifi network (3) the phone hangs up and then both chromecast and phone connect to the main wifi and then they use mDNS or multicast or whatever
<isd>
Ok, yeah that's not far off from the workflow I had in mind.
<abliss>
i wager that most people do not own keyboards, and do not want to (they find buttons scary)
<ocdtrekkie>
I'd rather preprint a QR, and not assume one needs to plug it into a screen at all. I imagine the most likely location to place one is attached directly to the router.
<ocdtrekkie>
Of course, if Sandstorm mobile support doesn't improve, we can assume users have PCs, lol.
<ocdtrekkie>
I am shocked more TVs aren't pushing higher voltage USB ports to support stick PCs, mind you.
koo6 has quit [Ping timeout: 240 seconds]
<jfred>
++ to sturdyrefs on QR codes
<jfred>
IMO one of the biggest issues with home servers for the average person is "I plugged this in, now how do I connect to it?"
<jfred>
(FOSS home servers that is; devices that have a centralized system run by the manufacturer can piggyback on their infrastructure)
<ocdtrekkie>
Unfortunately, good Sandstorm setup also needs router config. And that's hard to automate without exploiting insecure bad ideas like uPnP.
<jfred>
if you suppose that users will interact with it via a mobile app or something like electron on the desktop, would it be possible to piggyback on an overlay network like tor to avoid the need for router config?
<jfred>
(I know sandstorm has some unique requirements re: subdomains)
<jfred>
and I know that's not how we reach a sandstorm server today
<jfred>
I feel like the problem of devices on NAT-ed home networks not having a globally unique IP has been a persistent thorn in the side of every home-server-box project
rektide has joined #sandstorm
<jfred>
. o O ( A small 128x128 LCD/OLED display would probably be big enough to stick a sturdyref QR code on + provide a basic status interface )
<isd>
I don't want to make that assumption; the fact that I can just send someone a sharing link and they can use it in their web browser is hugge
<isd>
But yes, if we could avoid web protocols a lot of this gets a lot easier.
<ocdtrekkie>
If bandwidth wasn't the most expensive thing on the planet, lol, Sandcats VPN/proxy.
<xet7>
Wekan runs on x64/arm64/s390x/ppc64le. It includes RasPi3/RasPi4 and I also have access to arm64 server that has 125 GB RAM, nproc 96, 309 GB SSD. I hope some day Sandstorm does also run on arm64/s390x/ppc64le. I don't yet have access to RISC-V.