One of the things I work on is a signage/display solution. I really don’t understand where a snap solution fits into this space.
I took a small look around this setup, and it’s… weird. I think there is MASSIVE room for improvement in this space around the display server and maintaining the health of Chromium-based browsers. This solves a massive amount of needs by most people.
NEC and a few other manufacturers provide most of what you need to provide a managed self-service system for signage. We do this today with RPi Compute Modules w/ the NEC carrier boards so you get your display in a box and use a QR code to register it (so you don’t leave keys on the device,) and the device onboards and comes up without any interaction after registration.
The issues we’ve had are primarily:
1. Chromium Health management when inside a container
2. Memory (not an issue in cm4, was with cm3)
3. Display server
X11 was the hardest issue for us when we did not control the display (raspberry pi non-compute module), as you had to deal with KMS and weird TV stuff. This became MUCH more problematic once it was deployed globally.
I don’t see why someone would want to use snaps in this way since you have to publish your snap on the snap store OR install locally as far as I can tell. (Please correct me if this isn’t the case, I cannot find otherwise ANYWHERE.) This means you are making it MUCH harder for large enterprises or corporations to adopt this out of the gate.
I think there is MUCH MUCH more support and room for adoption for good OOTB display server containers. That’s really all this is, right? I honestly don’t see why you wouldn’t go for ‘here’s the dockerfile!’ first, and just package your snap, unless you are pushing snaps. Maybe it’s not viable to do LTS on a generic container for Canonical?
don’t see why someone would want to use snaps in this way since you have to publish your snap on the snap store OR install locally as far as I can tell. (Please correct me if this isn’t the case, I cannot find otherwise ANYWHERE.)
You can pay Canonical and have your own private snap store for your devices. How much of that is on-prem and how much hosted is I imagine part of the negotiation.
That’s why it’s such a big barrier to adoption in large orgs. It’s probably fine for startups or companies that this would be core to a single product, but it really deadstops others in my opinion.
Comments
One of the things I work on is a signage/display solution. I really don’t understand where a snap solution fits into this space.
I took a small look around this setup, and it’s… weird. I think there is MASSIVE room for improvement in this space around the display server and maintaining the health of Chromium-based browsers. This solves a massive amount of needs by most people.
NEC and a few other manufacturers provide most of what you need to provide a managed self-service system for signage. We do this today with RPi Compute Modules w/ the NEC carrier boards so you get your display in a box and use a QR code to register it (so you don’t leave keys on the device,) and the device onboards and comes up without any interaction after registration.
The issues we’ve had are primarily:
1. Chromium Health management when inside a container
2. Memory (not an issue in cm4, was with cm3)
3. Display server
X11 was the hardest issue for us when we did not control the display (raspberry pi non-compute module), as you had to deal with KMS and weird TV stuff. This became MUCH more problematic once it was deployed globally.
I don’t see why someone would want to use snaps in this way since you have to publish your snap on the snap store OR install locally as far as I can tell. (Please correct me if this isn’t the case, I cannot find otherwise ANYWHERE.) This means you are making it MUCH harder for large enterprises or corporations to adopt this out of the gate.
I think there is MUCH MUCH more support and room for adoption for good OOTB display server containers. That’s really all this is, right? I honestly don’t see why you wouldn’t go for ‘here’s the dockerfile!’ first, and just package your snap, unless you are pushing snaps. Maybe it’s not viable to do LTS on a generic container for Canonical?
You can pay Canonical and have your own private snap store for your devices. How much of that is on-prem and how much hosted is I imagine part of the negotiation.
That’s why it’s such a big barrier to adoption in large orgs. It’s probably fine for startups or companies that this would be core to a single product, but it really deadstops others in my opinion.
A shot in the dark but... are you from France ?
USA, sorry! :)