Live data from Hacker News

Ubuntu stops shipping Flatpak by default

lwn.net

621–624 of 624 posts

Re: Ubuntu stops shipping Flatpak by default

#621

Earlier quoted context omitted.

Can you share bit more details? I have no issues with that setup or at least I cannot notice the issues.

There were a few things wrt to clustering (which I don't need) and storage pool management that tripped me up at first, but not too bad. However, it made me worry about the fact that I might not be the target audience for the LXD project (I just need simple lightweight machines with snapshots, nothing more). When they decided to stop officially distributing debs, and promote Snap as distribution channel, that was the…

Clustering/storage pools are very optional, defaults are rather sane to my taste (I don't use clustering, may be yet, but use storage pool to define LXD stuff should reside on btrfs which has dedicated LV for that).

Auto update happens and I can understand your pain here with sealed machines/testing updates. Most small to medium companies around don't care though (from what I see) and probably have unattended upgrades on anyways.

Bit more on autoupdates - just to align yourself with how people care on keeping versions, you can imagine and check yourself of how many dockerfiles contain `latest` or no any specification of versions of pulled images. Many, many, not giving a shit.

In practice, though, autoupdates are not bringing VEs/VMs down and I find update happened after my `lxc shell some-ve` sessions are disconnected from time to time (I tend to keep those in tmux and it could be attached for weeks or even months).

As for use cases and audience - both Desktop/Server works for me - on desktop I use LXD under my WSL (it has systemd support for ~ 6 months now) to quickly play around with something and on servers to split one big machine into smaller ones/limit access to system for other users. Even had the case using it in CI/CD - custom Linux software to be packaged and doing basic installation test for centos6/7/8, Ubuntu 16/18/20.04 and so on. Package installs were done via dynamic creation of fresh VE each time, to ensure system is "clean".

Re: Ubuntu stops shipping Flatpak by default

#623
post #615

Earlier quoted context omitted.

It updates, not restarts. That can lead to problems after restart.

Sounds like a SRE nightmare. Updates happening when you didn't expect them guarantees problems. I'm starting to get a clearer picture of Canonical now.

That said, if they are working very hard to ensure that the updates don't break anything, then this is perfectly fine. Are they doing that? Has anyone been bitten by a bad Linux daemon update? Unless things are breaking in reality, it's foolish to dismiss snaps on the server outright.

Re: Ubuntu stops shipping Flatpak by default

#624
post #156

Earlier quoted context omitted.

Another way to look at this situation is that canonical comes up with innovative solutions that are reasonably well engineered out of the box but they are rejected just because they are from canonical. I'm struggling to find a way to characterize the difference between Red Hat/IBM and canonical's approach to the community. The most succinct I can come up with is that canonical releases projects and assumes that they…

I don't think it is a pissing context between them, they can both happily exist in the same world, it just interesting to see the difference in approach and try and figure out why one seems more successful than the other. I think you're right that Canonical creates and releases projects and assumes they are in charge of them, but I disagree about Red Hat (honestly not sure what you mean by "rough ideas and code"), I…

What I mean by rough idea and code is simple. Is a project something complete you can take and just use or is it a bag of parts. xcp-ng is a take it and use it project. KVM is a bag of parts.

My experience with Red Hat is that it's frequently IKEA level assembly required. Canonical projects tend to be read the docs and just use it. Although there are some exceptions. For example a couple of years ago, cloud-init was not documented well enough for my taste. Took a second look just now and found new documentation that may revise my opinion.

Post reply on HN