I am hoping someone can educate me. I do enjoy Jeff's articles and videos, but I fail to see what these could be used for. I concede that this is entirely due to my ignorance.
A few of the most pertinent applications would be running an application at a live event, where you might run off battery / solar / small generator, and you don't have much of a power budget, but would still want to replicate a small K3s cluster setup locally for simplicity's sake. (I realize the irony of including Kubernetes in a line about simplicity...).
But in general, it would be more focused on a lower budget / lower power option for exploring small cluster ideas. Much more fun to test things out or learn on a platform that costs $600 all-in and doesn't suck down a few hundred watts of power all day, than to buy four used PCs that use more power, take up a little more space, and cost maybe a little less, all-in.
It is a niche product, but nowhere near as niche as the Seaberry board I showed last week :)
I'm going to sheepishly wonder out loud if too much sponsored content will be to Jeff's channel's long-term detriment. I would be excited too to have a popular channel growing and being offered these cool toys but I have also seen blow-back of late.
Perhaps it's just par for the course on HN though. Or perhaps we're missing the more down-in-the-kernel hobbyist Jeff.
Don't worry, been doing my other stuff too, but this month for some reason all this gear showed up within a couple weeks and I wanted to make sure I gave it some air time before I go towards some more fun (to me) projects.
The key I think will be trying to make the blend be 'learning/teaching something new' along with finding the right way to fund it.
While I am extremely appreciative for every dollar that comes in through Patreon/GitHub Sponsors, the reality is that isn't enough (and except for maybe like 0.2% of creators/devs won't ever be) to cover all the bills. So I do need to work with more deep-pocketed sponsors from time to time.
It is a bit of a delicate balance, though, because it's easy to run the risk of being a hypocrite depending on who I work with and what projects I take on ;)
Cheers for this, I really enjoy the collaboration to play against the "big toys" Patrick has.
Maybe I missed it, but are there I2C or GPIO broken out for each module? I remember being really excited to the V1 Turing board in regard to the mashup potential with cluster-type things and the "Physical Computing" sensor / IO, but I didn't see anyone try to solder in those pins.
Each board has a UART header exposed, and through the MCU it can be rebooted / flashed over the network. Full GPIO is only exposed in a 40 pin header on node 1, though.
Might be interesting combined with VMware's ARM hypervisor "fling" here https://flings.vmware.com/esxi-arm-edition to make a toy "datacenter in a box", using the third node as a NAS datastore.
There are a lot of industrial and commercial applications. My interest though is in running a low power cluster at home for testing random applications that I build.
For example I'm writing an app for hosting documentation for household items and integrating it with a label printer. It would be great if I could host this and many other applications locally on a K8s cluster instead of stringing together a bunch of raspberry pis with a network switch, or hosting it on a cloud service
> It would be great if I could host this and many other applications locally on a K8s cluster instead of stringing together a bunch of raspberry pis with a network switch, or hosting it on a cloud service.
Pardon my ignorance, but why couldn't you run this on a NUC or a NAS? Do you need HA for testing random apps? Or is it just that this is more fun and a learning experience?
My interest in this space is in the opportunity to test assumptions when scaling wide. Those of us without University compute access or Cloud budgets ( like neighborhood STEM classes ) can plunk down for a desktop learning environment that can run k8s or slurm and you can learn / teach MPI programming patterns with hands-on, and minimal risk.
Sorry about the late reply but this is something I've been thinking about for a long time and something for which I have been trying to design my own carrier board while waiting for the turing pi 2.
Think about Qubes OS where you define different "security contexts" for diferent workloads where each of these run in isolated virtual machines. If properly implemented it's a pretty sturdy solution but you're one hypervisor away from total compromise regardless of what you do.
Now think of the same thing except this time you have one main system that acts as a firewall, shared resource, pxe and window server and a few secondary nodes that boot up from lightweight static images they get from the main node and mount specific resources from it to achieve a sense of persistence (ie. firefox / thunderbird profiles, etc).
There you have a pretty decently marked attach surface so you know which services you need to audit and isolate in the main box.
In my mind I'd love to have the same thing but with the compute modules laying parallel to the main board to be able to fit it in an oversized laptop form factor (kind of like the mnt reform) but this would be a really cool middle ground.
I plan on getting to the software side of it as soon as I have some spare time because even if this doesn't work or isn't ever in stock the whole thing could be put together in a ghettoish way using regular PIs and it'd still be something that could be fit in a mini tower with a small switch which would be good enough for me.
"Can I do it with a Pi?" is very similar to "Can I run Doom on it?" Most of the projects exist just to see how far the capabilities of a tiny computer can be stretched. However, someone may realized that their five-figure project could be done much cheaply with a Pi and HAT.
I think one thing that would be interesting would be a fully native build environment and full native development tools for the Raspberry Pi.
Building Ubuntu OS images from scratch on a Raspberry Pi server equivalent machine would be very interesting.
For the non-embedded firmware engineer it is a-trivial to wrap your head around initially w.r.t. cross compiling Linux distros using ARM compilers running on an x86 host.
But in general, it would be more focused on a lower budget / lower power option for exploring small cluster ideas. Much more fun to test things out or learn on a platform that costs $600 all-in and doesn't suck down a few hundred watts of power all day, than to buy four used PCs that use more power, take up a little more space, and cost maybe a little less, all-in.
It is a niche product, but nowhere near as niche as the Seaberry board I showed last week :)