1. Do you worry that open sourcing will make it difficult for you to monetize?
2. Can you describe your tech stack more?
3. How long has your team been working on this?
11–20 of 68 posts
1. Do you worry that open sourcing will make it difficult for you to monetize?
2. Can you describe your tech stack more?
3. How long has your team been working on this?
I can't wait to get the time to sit down and play with it!
I don't know a ton about the embedded/IOT world, but it's an area that has been coming up more on my radar recently. This project seems like a super interesting solution to the problems of deployment, updates, and monitoring. Could you talk a bit more about the focus on linux? How much of the ecosystem is running a full OS vs a small embedded program?
For embedded systems, you'd have to include the command and control elements in, which then gets into concerns about the amount of memory (both RAM and flash consumed).
For example, the ESP* devices historically have had challenges because you don't have enough flash storage to hold a proper SSL anchor chain. Suffice it to say there is a LOT of nuance when working in the embedded world which vanishes if you (even if just for the purposes of minimal viable product) focus on a full OS.
What about Balena? How are you different or the same?
We're in the same space as Balena and tackling some of the same problems, but with a different approach. Here are some of the big ways we defer from Balena (though these points really just scratch the surface).
Balena ties you into their ecosystem a bit too much. They require you to use BalenaOS which means they only support a fixed number of devices. In contrast, Deviceplane can be used with any Linux distro, meaning that as long as your device runs some form of Linux than it can be used with Deviceplane.
What's more, we've found that in most cases people really need the choice of what underlying Linux distro to use. For example, if you're using Jetson Nano devices and don't use the distro provided by Nvidia then you'll be fighting quite an uphill battle. Their distro includes a custom version of Docker (nvidia-docker) that adds support for using CUDA inside of containers.
Deviceplane also doesn't tie you to any specific container builder. We make it easy to integrate with popular CI systems so you can inherit all of their best features: build secrets, fully scriptable pipelines, etc...
Balena also lacks some of the core infrastructure that Deviceplane provides, such as our monitoring and bulk provisioning support.
Lastly, we're 100% open source and easy to host unlike Open Balena. Open Balena doesn't include user management or a UI. If you read through its installation guide you'll quickly get a sense that its architecture is needlessly complex and difficult to self-host. In contrast, Deviceplane was engineered to be self-hosted from day one and can be run in a single Docker command.
Are there any plans in the future to support more linux distributions?
I tried to enroll a server into deviceplane but there is a hard requirement on systemd. Are there any plans in the future to support more linux distributions?
We've really wanted to add OpenRC support to our installation script for a while but haven't gotten to it yet.
If you know your init system well, you could always write your own service file. Here's the unit file for systemd as a reference: https://github.com/deviceplane/deviceplane/blob/master/insta....
Let me know if you end up getting this to work. Would love to upstream to our install script!
That's great! I was thinking of writing something like this for a few months as Balena seems really over complicated. Glad to see Go :) will definitely try it out for my projects!
Let us know if there's any feature you were planning to build for your upcoming project that Deviceplane doesn't currently have.