seenitall

I know the data for one large cloud. There’s more Ubuntu than all the others put together, by some distance. Don’t see why it would be different on the other public clouds. They do a lot behind the scenes to make it work really well on each public cloud, which explains why people choose it.

In the end it was a tie in the Debian technical committee. The chairman’s vote was counted twice so systemd won. Then the people who had voted for systemd resigned rather than actually implement their choice.

Yup

Evidence? I don’t think that’s the case. There are plenty of non-commercial snaps with system access, it’s really a question of the nature of the snap. You would want something like Puppet to be able to read and write files all over the system, so the snap declaration and metadata needs to say that. I think the only interaction with Canonical is that they need to review snaps which do have filesystem access to check that it makes sense and ty to spot Trojan horse apps being published that way. It’s not perfect but it’s sensible.

The comment is mistaken. I suspect it’s being downvoted not because update control isn’t appreciated, but because it’s very much there with snaps. There are several ways to disable snap updates, and they are really quite nicely balanced for modern operations.

For example, if you publish a snap that depends on another snap, say an app which uses a database, you can set things up so the database won’t update until you publish a validation certificate that your app snap version X has been validated with database snap version Y.

Updates can be deferred by anybody, and I think there is a plan for snaps themselves to be able to defer their own updates (for example, a movie payer that is playing a movie at the scheduled update time).

Enterprise management systems can also control the flow of updates very nicely. For example, they can have a different snap revision as ‘stable’ or ‘beta’, which means they decide when a new revision of a snap will be considered for update by all the machines tracking those channels. They can also prevent any updates from happening on specific machines.

Device manufacturers also get a layer of control, similar to snap publishers with their dependencies. So an appliance that uses snaps might see specific revisions of snaps only once those have been certified on that device.

Considering how rich the actual reality of ‘software update distribution and managment’ is in practice, it’s nice to see that level of thinking built in to the system. We’ve had simplistic approaches around for decades and the results in practice are too or, there are millions of vulnerable machines out there because of neglect. I’m interested to see if these mechanisms achieve a better result all round, and the simple thing you are focused on is certainly already there.

Ubuntu used to add a kernel to the LTS from each subsequent release, but they were separate packages. Now there will be just one HWE package that will roll until the subsequent LTS.

No, just doing updates gets you all the benefits of the point release, as you would expect. If you want a newer kernel, install the hwe kernel when it appears, it will roll until the next LTS and stabilise then in line with 18.04 (it is basically later release kernels built on 16.04).

Sensible move, though I hope it's not too disruptive for Fleet users. Don't think they have any option though. The list of easy ways to try K8s should include conjure-up on Ubuntu for either laptop-scale or large cloud/Vmware/bare metal deploys

Snaps can now export libraries, so you can get a shared Qt framework for example if you don't want to bundle that. Up to you how much you trust the library snap publisher not to break you.

Snaps can be 'strictly confined' which means all their reading and writing happens in a limited set of directories exclusively for their use. So 'snap remove' cleans everything up perfectly. Ask your upstream for a strictly confined snap, it's a bit more work but once they have done it everybody wins.

Exactly. Snaps grew out of the work to make Ubuntu mobile phone apps secure and easy to update. They are a great way to publish software, worth creating regardless of all the anti-canonical trolling. And they work fine across distros except where RH has actively tried to cripple them. That's their right, but wow, toxic.