Live data from Hacker News

Ubuntu Core 22 is now available – optimised for IoT and embedded devices

ubuntu.com

101–110 of 110 posts

Re: Ubuntu Core 22 is now available – optimised for IoT and embedded devices

#101
post #96
post #64

Earlier quoted context omitted.

Aren't they only using it for security updates though?

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.

You can make a boot-enviroment-snapshot for active/backup.

If anything goes wrong you boot backup, then again snapshot and repeat. That way you don't need anything more then apt/pkg etc.

Re: Ubuntu Core 22 is now available – optimised for IoT and embedded devices

#102
post #10

For alternatives, I’ve been running opensuse microos in some test deployments and am really happy so far.

Have you seen? There is Leap Micro now (the not rolling release, based on SLE 15 sp4), if you need something more predictable/long-term.

Re: Ubuntu Core 22 is now available – optimised for IoT and embedded devices

#103

Earlier quoted context omitted.

> canonical needs to go public and do IPO. why?

it's their long term goal, to answer your question: everyone needs more money, after all it's not a charity, canonical is a legit business.

>it's their long term goal

Why do you know that?

>everyone needs more money

But canonical need's more employees first...but please good ones ;)

Re: Ubuntu Core 22 is now available – optimised for IoT and embedded devices

#104

Earlier quoted context omitted.

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, makin…

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.

Re: Ubuntu Core 22 is now available – optimised for IoT and embedded devices

#105
post #32

Earlier quoted context omitted.

> We all know which one of these usually results in a broken installation. And yet they're promoting snap. Have they given us the ability to stop automatic updates?

It looks like Ubuntu Core lets you disable automatic updates for snaps: https://ubuntu.com/core/docs/refresh-control .

"Refresh control can be accomplished by using a gating snap"

I bet those only come from brand stores.. so $20k/year for an ability to disable updates?

Re: Ubuntu Core 22 is now available – optimised for IoT and embedded devices

#106
post #75
post #69

Earlier quoted context omitted.

Nope, it's reviled because of its hostile user experience. Try finding an official, working way to stop automatic snap updates!

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.

I am not aware of the high memory usage issues. Also, rhe permissions issue is related to poor packaging, more than anything else.

Re: Ubuntu Core 22 is now available – optimised for IoT and embedded devices

#107

Earlier quoted context omitted.

I've never used anything in the product space, but I've read through some of the docs because IoT deployment interests me in the context of most network devices having terrible deployment and update strategies. 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 ho…

First 10 devices on balena are free, its used by many thousands of hobbyists. 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 engine…

I still don't think the pricing makes sense for anything that doesn't have a solid plan and a sales team. If you graph the cost per device / month it'll be free for 10 users, then a huge jump when you need a paid plan, then an increasing slope until you hit the peak at $14.39 per device / month on the Production plan, then a decreasing slope trending towards $1.00 per device / month (for essentials).

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.

Re: Ubuntu Core 22 is now available – optimised for IoT and embedded devices

#108
post #13
post #3

Do you still have to have a canonical sso account just to login to your own devices? 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 dist…

For individuals and hobbyists Ubuntu Server would likely make more sense than Ubuntu Core. I used to recommend it for use on headless Raspberry Pi's over Raspberry Pi OS. Use of cloud-init and netplan made it much easier for deployment of headless RPi's. 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 reco…

What were the changes in 22.04 on the Pi server images that severely impacted you?

(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)

Re: Ubuntu Core 22 is now available – optimised for IoT and embedded devices

#109
post #13

Earlier quoted context omitted.

For individuals and hobbyists Ubuntu Server would likely make more sense than Ubuntu Core. I used to recommend it for use on headless Raspberry Pi's over Raspberry Pi OS. Use of cloud-init and netplan made it much easier for deployment of headless RPi's. 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 reco…

What were the changes in 22.04 on the Pi server images that severely impacted you? (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)

Maybe severely was the wrong word to use. I use RPi's in my home lab so any impact no matter how significant is limited in real world impact. In this case it was limited to loss of access to several services in my home lab for a few hours due to a complete loss of network connectivity to the server and a few hours of my time troubleshooting the issue.

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.

Re: Ubuntu Core 22 is now available – optimised for IoT and embedded devices

#110
post #109

Earlier quoted context omitted.

What were the changes in 22.04 on the Pi server images that severely impacted you? (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)

Maybe severely was the wrong word to use. I use RPi's in my home lab so any impact no matter how significant is limited in real world impact. In this case it was limited to loss of access to several services in my home lab for a few hours due to a complete loss of network connectivity to the server and a few hours of my time troubleshooting the issue. The major issue was caused by moving some of the kernel modules to…

Fair comment; and you're correct that (to the best of my knowledge) we don't specifically test VLANs on the pi platform at the moment (the majority of the automated testing performed directly on pis is pi-specific hardware compatibility: boot, wifi, bluetooth, etc. etc.)

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).

Post reply on HN