I highly discourage anyone to use Ubuntu Core as part of their solution. It is a secure environment, yes, but it is a nightmare to configure (snaps) and for everything, expect for the most basic stuff, you will need what is called a "brand store", which costs about $20k/year, regardless if you have 1 or 100 devices.
(We could not even make one snap talk to another snap, checking another snap status etc).
We had commercial discussions w/ Canonical and we basically moved away.
I like Ubuntu, and looked into using Ubuntu Core for an IoT architecture a few years ago - but the "brand store", which IIRC is mandatory for private deployments, are complete madness.
Plus, while the concept behind Snaps is interesting, in practice they seem to be nearly universally reviled.
> Plus, while the concept behind Snaps is interesting, in practice they seem to be nearly universally reviled.
It might be worth mentioning that a more open, community driven and decentralized option offering mostly the same concepts exists in the way of Flatpak and Flathub.
And that Linux Mint, a very good derivation of Ubuntu LTS, made the choice to ditch Snap and integrate Flatpak instead in their version of the Software Store.
it's reviled because nobody wants to learn yet another deployment tool. apt has been reliable enough for installing packages and good enough UX that people can't be bothered
Was going to say the same thing. IMO the snap concept would make it worth learning something new for some use cases - but forced automatic snap updates, high memory usage, long startup times and permission issues are not selling it. Moreover, Canonical is well aware of how snap is perceived, and has done diddly squat to fix it.
You can’t really compare the two wrt IoT. For Debian you need an additional OTA update mechanism. Luckily rauc is in the Debian repos but you still need to setup everything yourself: A/B partitioning etc.
I'm surprised they ended up going with a non-immutable distro. They say their Debian-derived system is as robust as Ubuntu Core, but seemingly immediately contradict this by saying they're using apt to manage updates.
apt updates are not transactional, so abort the update mid way and you have a partially applied update. Hopefully the packager was careful enough to ensure your system still boots and reapplying the update cleans everything up.
We had the some problem evaluating it for our startup. We were planning on using it to deploy ROS in the field and leverage the benefits. I was quoted $20k/year to get started and I think that also included 10 or 20 devices in the field. Then additional costs for that.
There was so many hacks to get it working with ROS since we rely on hardware for robotics to communicate with sensors, actuators, and network. Basically broke the security model to get our application working. We didn't go with it and went Debian as well :D
Been a huge fanboy since Warthog, but as of 20.04 I've sought refuge elsewhere. Turns out, Ubuntu isn't nearly as user friendly as it was back then, in fact, it's one of the least user friendly distros these days! Everybody progressed and you deserve t check it out yourself!
Not the one you're replying to, but started my Linux experience with Ubuntu 6.10, was using it all the way up to ~17, and started using Arch Linux after that since during my time of using Ubuntu, I learnt enough Linux that I could setup my own system (and of course, with the help of the awesome Arch Wiki).
Worth noting that Arch has had something resembling the OpenBSD installer for some time. Trying it out doesn't require reading 20 wiki articles as it did back in my day™. You answer a few questions, wait a few minutes, and it's done.
Wow, that's great, haven't seen that before! Granted, it was some time ago I did a setup from scratch.
Seems that installer is like 90% on the way to be useful as a general installer. At a glance, seems to missing things like networking setup (as most people use WiFi these days, it seems), but at least it takes care of most things you need for a install.
If you want to set it up and forget about it, just use any RHEL clone (AlmaLinux is by far the fastest with updates: it took them like a week to ship RHEL 9 after the official release). You set up the system, install & enable `dnf-automatic`, and forget that it exists for the next 10 years.
If AlmaLinux (or any other clone) dies for some reason, you can always move to another clone without re-installation (using their tool `elevate`).
Buying a Brand Store is also the only official way to have full control of snap updates. Someone at Canonical must have been taking notes from Microsoft -- take away control from users and sell it back in an "enterprise edition".
No issue with Canonical making some money from their OSS efforts, but as-is the pricing seems crazy. At the least, I wish they'd do something like make brand stores free for less than 100 devices. That would also serve to hook people in, then they pay as they grow.
Ideally though, Canonical would let anyone run their own "brand store" on their own hardware.
I completely sprinting away with anything canonical. SUSE/openSUSE/Micro RHEL/Fedora/CoreOS nothing else...no more canonical, too many disappointments and trickery into pay massive at the end of the day.
That is really ridiculous. I'm sure some companies out there will pay it without blinking, but how are the little people supposed to evaluate things, heck a former boss at a Fortune 500 I know for a fact will say no thank you, and move on. I would just use DEB packages and setup a package repository myself, what does snap bring that regular debian packaging does not?
> what does snap bring that regular debian packaging does not
Snap is like using a python virtualenv, while apt is like using global pip. We all know which one of these usually results in a broken installation.
Apt debs more often than not rely on some specific version of a third party package which becomes a headache when there's another package that needs a different version of it. Snap in theory solves that, making the deps local to the package you're installing.
If I had a dollar for every time I had apt bullshit me with "requires package, but it will not be installed" or something of the sort I'd probably have something over $20 which isn't that much but still infuriatingly high.
As an alternative just package everything up in an AppImage and use a AppRun shim script.. Then just deploy the AppImage to whatever. The LXD Snap bundles quite a few things, there's no reason you couldn't do the same with AppImage.
>If I had a dollar for every time I had apt bullshit me with "requires package, but it will not be installed" or something of the sort I'd probably have something over $20 which isn't that much but still infuriatingly high.
Completely unrelated but the exactness of this turn of phrase here delighted me so much and without your permission I’d like to steal it for my own use in my daily conversations (without credit).
It's an adaptation of Doofenshmirtz's line from Phineas and Ferb:
> "Wow! If I had a nickel for every time I was doomed by a puppet, I'd have two nickels. Which isn't a lot, but it's weird that it happened twice. Right?"
My favorite distro in this regard was openSUSE, Debian and Ubuntu are #2's for me. I just can't install it anymore, it doesn't support the right drivers before the install process finishes, which causes issues. I'm not a fan of having to do anything to trick a GUI based installer to work.
Honestly wondering if a System76 box or laptop would play nicely with openSUSE.
We are talking about IoT devices where (hopefully) the company knows exactly what is installed and what not, so I don't think it is a big issue. There may still be conflicts to solve, but you can manage them when you prepare the deb package, not when you install it
If you've only got one device then it probably doesn't make sense. But if you have a number of devices, you probably have a business and need to make sure that you can reliably and securely update them remotely. How many developer/ops hours do you think that would take? 20k doesn't buy you much in dev hours these days.
