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.
The way they are advertising snap in a completely unrelated product is so weird. Their marketing team needs to learn that it would only push the developer's mind into thinking it is forced upon and not actually useful. I would expect similar push by companies like Oracle to their clients not Canonical to free developers.
Their entire IoT program seems to revolve around hooking companies on using Snap. This makes sense financially, because if you can trick a company into rolling out their IoT network through Snap, a store Canonical is the only one in control of, they practically lock these customers into their business model.
Once you've deployed a thousand IoT devices, you don't just re-develop the entire system to use Docker/Balena/whatever when Canonical announces it'll start charging money for something that's currently free. The price difference needs to be smaller than the added development cost or it'd be a waste of company resources.
Canonical is pretty open about the limitations of any free offering and pretty open that this is really intended for a paying audience. I don't see any attempt to bait and switch going on.
I don't think it's unrelated, I think they think the snap format is good for distributing and updating embedded applications, such as those you'd use with signage, easily. But no idea how realistic that is.
Am I missing the broader picture here? This seems to be a lot of fanfare for something which is around 1000 lines of code to set up a minimal Wayland server: https://github.com/MirServer/ubuntu-frame
The more impressive thing to me seems to be the continued progress being made on Mir that has enabled this work.
> Ubuntu Frame comes with 10 years of security updates.
I think this is great and a needed thing, but I've seen signage in airports and other places that has crashed to Windows XP which is like 10 years beyond its end-of-life date.
Let me be the first to say that this is so fucking weird.
I used to work in digital signage and... it sucks? There is no fun here. Of all the things Ubuntu/Canonical could be investing in I would never have guessed digital signage.
I assume it is a massive market. Every fast food restaurant, clothing store, mall, arena, train and airport station, and so on has or will have it in the near future.
Indeed, it is if you are an IoT device manufacturer. IoT is a bit of a laughing stock due to poor security and updates, which is what snap is trying to bring to the table with reliable, automatic updates for the OS and software components, and containerization.
Yeah, that seems to be my takeaway too. This strikes me as the sort of project you'd throw together last-minute to show your boss that you haven't been watching Netflix on company time for the past 6 months.
I've seen plenty of pictures of digital signage with kernel panics and system v/systemd errors too. Ironically, most of them on /r/linux as a sign of pride.
i have installed a variety of such kiosks systems, i think my preference goes to a lightweight linux where i install just an x server with no window manager, then a simple flask web app and a startx chromium. simple and reliable. i looked at the previous iteration of their snap thing but added a lot of complexity for little added benefit.
also had a raspberry pi controlling an escape room with several video streams, dmx and sound. worked for 4 years flawlessly with zero maintenance. it's nice when things work.
i always searched for off the shelf solutions like these but always end up building my own, namely a minimal linux install and add the bare minimum.
Have a look at my company https://info-beamer.com. It operates a Pi based signage platform with lots of possiblities to completely customize what happens on the screen. It can directly import packages that control what happens from github, where you also find a lot of the code for the existing solutions: https://github.com/info-beamer. The OS is minimal (~40MB currently) and trivial to install.
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?