5 ms·

Is it? At $work we deploy thousands of pis each year across multiple use cases. They are truly great devices to get compute in hard to reach places as well as t

by hhh 6y ago

Is it? At $work we deploy thousands of pis each year across multiple use cases. They are truly great devices to get compute in hard to reach places as well as to throw Chrome on a display. The harder part of this is the orchestration and management of every device and making it simple to deploy. Since January 1 we have deployed around 600 new devices.

edoceo 6y ago
My network isn't nearly that large. I've got them all to phone home over wireguard so we can manage. Pi is a great way to ship a managed software solution.
- mindslight 6y ago
  What OS are they running that you can reliably remotely manage them and not end up with a bunch of failures? I've had too many Pis corrupt themselves with dist-upgrade churn.
  - hhh 6y ago
    Nothing special, just Ubuntu. We have a few devices that run into issues every few weeks or months. Typically devices that live in horrible environments that are staying undervolted and losing power during upgrades.
  - jon-wood 6y ago
    If you're shipping commercial products based on Pis and running dist-upgrade you're likely doing it wrong. Using something like [Balena](https://www.balena.io https://www.balena.io) you can ship full update images so that devices are always in a known good state, rather than potentially having some proportion of the OS in a half-upgraded state. The key thing is to support atomic updates - the device is either updated, or it isn't. There's then a bunch of other stuff you want to do like turning down log levels, and only logging super important stuff to the SD card, which will drastically improve the lifetime of your storage.
    - mindslight 6y ago
      Agreed. My use case is personal, but wanting to setup things and have them continue to just keep working, rather than having to tinker when they break. Last Raspbian failure was the files missing from /boot (old ones removed, new ones not put in place). Couldn't figure out the root cause. I'm thinking of going to NixOS. The filesystem will still be mutating, but in a much more atomic way. And if a host does die, I can easily rebuild an image from another host and pave over its whole sd card. The most robust way would be the embedded approach of two static flash partitions (update each one alternately), a separate partition for config, and another for mutable state. Alas that's more development work than I want to do for personal projects.
      - jakogut 6y ago
        > The most robust way would be the embedded approach of two static flash partitions (update each one alternately), a separate partition for config, and another for mutable state. Alas that's more development work than I want to do for personal projects. Just to let you know, this is the approach that balenaOS takes. Applications are containerized and deployed using Docker. The OS uses read-only system partitions to store the engine, kernel, firmware, etc, and has an A/B partition layout for resiliency and atomic updates. Applications are downloaded and stored on a separate data partition, and mutable configs are stored on another. The partition layout and a lot of how the OS functions is also well documented and public. [0] Additionally, the first ten devices are free and fully featured, and the same people that help create the product, including (but not limited to) engineers, monitor the forums to help users. I'm one of those engineers. :) [0]: https://www.balena.io/docs/learn/more/masterclasses/host-os-masterclass/ https://www.balena.io/docs/learn/more/masterclasses/host-os-...
        mindslight 6y ago
        > the first ten devices are free and fully featured Neat project, but this implies some sort of ongoing third party dependency/control that the devices would have, making it a non-starter for my use. The main reason I am using RPis as security cameras (for one use) is to avoid these type of security vulnerabilities.
- hhh 6y ago
  This is exactly what we use it for, it comes as a simple to setup device that almost anyone could set up in <5 min with no technical knowledge needed. It's all about getting them deployed effortlessly for us, and treating them as first class citizens in terms of management. Most of the devices like this you can pivot to another hardware platform if you wanted or needed. It gets much more complicated when you start doing video (especially if you try to containerize your application, but it is possible to do while remaining performant.) I think about 60% of our use cases boil down to "put chromium on the screen" though.

by hhh 6y ago

edoceo 6y ago

My network isn't nearly that large. I've got them all to phone home over wireguard so we can manage. Pi is a great way to ship a managed software solution.

mindslight 6y ago
What OS are they running that you can reliably remotely manage them and not end up with a bunch of failures? I've had too many Pis corrupt themselves with dist-upgrade churn.
- hhh 6y ago
  Nothing special, just Ubuntu. We have a few devices that run into issues every few weeks or months. Typically devices that live in horrible environments that are staying undervolted and losing power during upgrades.
- jon-wood 6y ago
  If you're shipping commercial products based on Pis and running dist-upgrade you're likely doing it wrong. Using something like [Balena](https://www.balena.io https://www.balena.io) you can ship full update images so that devices are always in a known good state, rather than potentially having some proportion of the OS in a half-upgraded state. The key thing is to support atomic updates - the device is either updated, or it isn't. There's then a bunch of other stuff you want to do like turning down log levels, and only logging super important stuff to the SD card, which will drastically improve the lifetime of your storage.
  - mindslight 6y ago
    Agreed. My use case is personal, but wanting to setup things and have them continue to just keep working, rather than having to tinker when they break. Last Raspbian failure was the files missing from /boot (old ones removed, new ones not put in place). Couldn't figure out the root cause. I'm thinking of going to NixOS. The filesystem will still be mutating, but in a much more atomic way. And if a host does die, I can easily rebuild an image from another host and pave over its whole sd card. The most robust way would be the embedded approach of two static flash partitions (update each one alternately), a separate partition for config, and another for mutable state. Alas that's more development work than I want to do for personal projects.
    - jakogut 6y ago
      > The most robust way would be the embedded approach of two static flash partitions (update each one alternately), a separate partition for config, and another for mutable state. Alas that's more development work than I want to do for personal projects. Just to let you know, this is the approach that balenaOS takes. Applications are containerized and deployed using Docker. The OS uses read-only system partitions to store the engine, kernel, firmware, etc, and has an A/B partition layout for resiliency and atomic updates. Applications are downloaded and stored on a separate data partition, and mutable configs are stored on another. The partition layout and a lot of how the OS functions is also well documented and public. [0] Additionally, the first ten devices are free and fully featured, and the same people that help create the product, including (but not limited to) engineers, monitor the forums to help users. I'm one of those engineers. :) [0]: https://www.balena.io/docs/learn/more/masterclasses/host-os-masterclass/ https://www.balena.io/docs/learn/more/masterclasses/host-os-...
      - mindslight 6y ago
        > the first ten devices are free and fully featured Neat project, but this implies some sort of ongoing third party dependency/control that the devices would have, making it a non-starter for my use. The main reason I am using RPis as security cameras (for one use) is to avoid these type of security vulnerabilities.
hhh 6y ago
This is exactly what we use it for, it comes as a simple to setup device that almost anyone could set up in <5 min with no technical knowledge needed. It's all about getting them deployed effortlessly for us, and treating them as first class citizens in terms of management. Most of the devices like this you can pivot to another hardware platform if you wanted or needed. It gets much more complicated when you start doing video (especially if you try to containerize your application, but it is possible to do while remaining performant.) I think about 60% of our use cases boil down to "put chromium on the screen" though.