Ubuntu Core 22 is now available – optimised for IoT and embedded devices
ubuntu.com
ubuntu.com
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.
No one uses snap but Ubuntu.
Flatpak fits the same niche, but better.
snap set system proxy.http="http://127.0.0.1:1111"
snap set system proxy.https="http://127.0.0.1:1111"
https://discuss.linuxcontainers.org/t/disable-snap-auto-refr...
Yup.
The guys at Nitrokey did a nice write-up about this last year.[1]
(TL;DR in the end, they chose Debian instead)
[1] https://www.nitrokey.com/news/2021/nextbox-why-we-decided-an...
If anything goes wrong you boot backup, then again snapshot and repeat. That way you don't need anything more then apt/pkg etc.
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
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.
Then, put dwm/[your fav. wm] on top of it, with some autoservices for bluetooth, mtp and stuff.
If AlmaLinux (or any other clone) dies for some reason, you can always move to another clone without re-installation (using their tool `elevate`).
Ideally though, Canonical would let anyone run their own "brand store" on their own hardware.
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.
And yet they're promoting snap.
Have they given us the ability to stop automatic updates?
I bet those only come from brand stores.. so $20k/year for an ability to disable updates?
https://xon.sh/appimage.html#building-your-own-xonsh-appimag...
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).
> "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?"
Honestly wondering if a System76 box or laptop would play nicely with openSUSE.
I don't really remember ever doing this, but I still miss it somehow.
EDIT: The answer appears to still be yes. I don't know who canonical is making this for, but no company is going to want to deploy IoT devices that hand over the root of trust for authentication to a third party. And I have to believe that many individuals/hobbyists that would otherwise be excited to use this will choose another distro for the same reason.
Canonical seems to be out of touch with what people actually want, and is happy to build things it likes that will ultimately be irrelevant.
Unfortunately for 22.04 they made some changes on the RPi which severely impacted my deployments causing me to move away from Ubuntu on the RPi and to no longer recommend it to others.
(disclosure: I'm probably the one that made those changes, so apologies for that, but I'd like to know what they were in case there's anything I can do about them)
The major issue was caused by moving some of the kernel modules to linux-modules-extra package. It caused an issue when I upgraded because the 8021q module needed for vlan support was moved to this package. I lost network connectivity to the first Pi I upgraded due to this. The Pi in question had an ip address assigned to the interface and to vlans configured for the interface. When networkd could not create the vlans on the interface it failed without assigning the ip address to the interface itself. I filed a ticket regarding this.
I consider the ability to use vlans to be a fairly basic expectation of a server os especially when it previously worked out of the box. I would also think vlan support to be an expected feature for the IoT gateway role pushed as appropriate for Ubuntu Core. Luckily I was able to connect to the serial console, troubleshoot and eventually correct the issue. When the module which supports a commonly used part of the ethernet family of protocols is moved to an optional package, I would expect testing of the impact to connectivity to existing deployments to take place. This led me to lose some faith in the testing done of Ubuntu on the RPi and the stability of the platform going forward. Switching platforms was easy to do in my case and so I did.
Hopefully the recommendations I made in my ticket of either moving the module back to linux-modules or adding an explicit warning to the release notes happens. The current warning regarding some modules having been moved to linux-modules-extra, without any detailing of them including the functionality they tie back to, is completely inadequate.
Something vaguely similar came up back in hirsute with the veth module (preventing containers from configuring ethernet): another thing that wasn't pi specific. That got resolved by moving veth back (which will almost certainly be the resolution in this case). I've found what I suspect is the ticket you mentioned (LP: #1973485) and though it looks like the kernel team have picked it up, it's not resolved yet. I'll see what I can do to get it some more priority (at the very least it should be dealt with prior to the point release).
I've added VLANs to the release notes in the meantime, however, I can't add the full list of functionality because the list is frankly enormous (well over 1000 modules).
Well that's not true, if the solution is a success 20k is not much....problem is it rarely is with canonical.
You have not written anything about upfront or IoT.
AWS IoT? Is that even a thing? (pun intended)
We had a much better experience with https://www.balena.io – quite a different service, but achieves a sweet-spot combination of having an open core with good management tooling that I'm more than happy to pay for.
My favorite sales pitch was always Mender (https://mender.io) because it can be as simple as .img files and slice based booting. Unfortunately they changed their pricing a couple years ago and went from a hobbyist friendly pricing structure where you could scale down to $120 / year to charging for scale and features where the minimum cost to use delta updates is $3k per year. If you want something like mutual TLS authentication it's "call us" pricing.
When I looked at Balena I thought the whole architecture looked like a mess of complexity and containers when a simple .img would suffice for most use cases (IMO). It's also too expensive to get into without having a well understood target market for whatever IoT product you're planning to build. IE: No hobbyists or enthusiasts that just want to learn without having something sellable planned out.
IMHO all of the IoT deployment solutions charging tons of money for features and scale are a good example of where platforms like Cloudflare could reshape the industry. I think by going "all in" on Cloudflare Pages/Functions/Workers, etc. someone could build a "Cloudflare Native" platform that can afford to dominate the unserved (low-end) portion of those markets, but with the ability to scale up to accommodate the large deployments these companies are trying to attract as customers.
I would kill for firewalls and switches that use a slice based, watchdog monitored deployment system like Mender has, but with pricing that's closer to the reality of the small business world.
For example balenaSound is very popular, for multi-room audio with rapsberry pi's https://sound.balenalabs.io/
There is also balenaHub, which hosts many community projects and introduces the concept of "open fleets", bring your device and join the fleet, instead of managing it yourself https://hub.balena.io/fleets
Disclosure: I am an engineer at balena.
In something like the digital signage market, where IoT device management makes sense, I can buy hosted solutions that include the signage SaaS for around $10 per device / month. On Balena Pilot I'd be paying $6.50 per device / month (initially) and competing against large providers who have costs closer to $1.
The pricing page looks even worse than that at a glance. The thing I see immediately is $1439 / month for 100 devices. The plan is named Production and it's the only one where I can calculate the per device cost without thinking (divide by 100), so it gives me the expectation of $15 per device / month until I read the fine print and pull out a calculator to figure out an actual cost average based on projections.
My gut reaction after spending 5 minutes on the pricing page is that I would need to get into the range of 500 devices before I could be cost competitive unless I'm in a specialized market where I can justify charging a really large monthly fee per device.
A hobbyist trying to deploy a few dozen devices is probably going to have a tough time doing cost recovery in the beginning. If someone is trying to manage a couple dozen devices as a pure cost (just simplified maintenance), I think it would take a lot to justify moving away from doing things manually. I deal with a lot of small business network devices and I value a firmware update on a network device as 3 minutes of labor.
I also have a huge dislike for tiered features and functionality, but that's endemic to the tech industry in general and I can't imagine any established companies being able to move away from it. The reason I dislike it is that anything I would build would be on the scale of a weekend side project and I feel like I have to adjust my strategy based on the scale of my project. For example, I might start with manual device management to keep costs low initially and then move through the different tiers of something like Balena as I grow.
Compared to something like the old Mender pricing where IIRC it was a linear cost per device with all features included and a minimum cost of $10 per month, the current pricing, scaling, and tiering strategies are awful for small developers. I know anything I build as a side project has a limited chance of being successful. I don't want to pre-plan a cost minimizing scaling strategy, but I don't want to YOLO it and hope for the best if if I end up with something successful.
What I'd want out of a platform like Balena is a setup where I can just build the best solution on day one and throw money at it to scale if it becomes necessary. However, the reality is I'll probably end up stuck in those low scale scenarios I described above, so, IMHO, that pricing is built for you to make money off of me failing, not for mutual benefit.
To be fair, I assume Mender couldn't sustain their old pricing, but I think platforms like Cloudflare could make that kind of pricing more tenable in the future. At least I hope so.
Canonical seems to completely have lost touch with what the community wants, and with the non-free installer, I find Debian working equally well OOB as Ubuntu has done in the past.
The only machines I still keep on Ubuntu are the ones already running it where migrating them will be too much hassle.
For my latest laptop, out of curiosity, I also tried Arch. It seems to work fairly well, but I haven’t had enough experience with it yet to “dare” put it on servers.
Yeah... no.
If you fork it and remove the connection to Ubuntu's cloud ecosystem, you'd probably be end with a barebones Ubuntu Server install. When all you need is Ubuntu Server with Livepatch, you're probably better off using that.
It's fantastic for small-scale IoT deployments, but you very much need to play nice in their ecosystem, and there's many features missing for deployment and version management still, and balenaOS and the balena supervisor can often introduce breaking quirks, and managing networking is a nightmare. We're very happy with how it allowed us to get off the ground and running quickly, but are moving to a more "traditional" build using yocto on its own moving forwards.
Disclaimer: I work on Apertis.
Are you able to provide a short summary, and maybe compare it to Ubuntu Core and BalenaOS?
Would it be suitable for shipping appliances? How do you folks make money?
Thanks :)
There's a lot of concept documents on the website going into details on those.
https://ubuntu.com/certified/devices
It does contain raspberry pi's but the list isn't all that great.
I had trouble finding 32 bit ARM precompiled binary distributions from ubuntu (that is not a rpi), and had to compile my own kernel + inline it with debian to get 32 bit arm support.
One alternative is Fedora CoreOS.
canonical needs to go public and do IPO.
ubuntu core is one approach to make some money out of the (free) ubuntu brand.
Personally I don't use Ubuntu Core, but I understand why it is there.
why?
Why do you know that?
>everyone needs more money
But canonical need's more employees first...but please good ones ;)