TL;DR: managing package change: in distro or around distro I've written a long message because I think that this is one of the key tensions in the Linux world. I'd like to understand the solution space better. | From: o1bigtenor via talk <talk@gtalug.org> | Given what you have described I'm wondering if 'Go' functions | similarly I believe go is statically linked. But I don't know that for sure. I haven't yet programmed in go. | - - - and then maybe that is why LXD is currently only supported | when its installed using Snapd and the miasma forces updating - - - | no matter what (max 2 months). I don't remember what distro you are using. If I remember correctly, LXD is part of the Canonical world. So is snapd. It would seem to be on-brand to distribute LXD as a snapd. (My impression is that Canonical has trouble sharing with others. After a few failures (Unity, Upstart, ...), they kind of get that sharing is needed for success.) ================ The conventional linux model is that distros deliver a curated collection of packages. They also mediate updates. You pick your distro based on how much you like their selecting, testing, and updating of their collection. That's a pretty course knob to adjust. Stable distros typically are slow to adopt some upstream improvements. RHEL is *really* slow but *really* reliable and stable. Red Hat puts a whole lot of effort into backporting and validating fixes (as opposed to improvements). This is often without "upstream" segregating such changes. That's where they really earn their fees. Fedora, on the other hand, mostly tracks upstreams (with some checking). That means tremendous package churn. Not recommended for production use. I haven't seen Ubuntu's principles clearly and precisely enunciated. But LTS seems to be like CentOS, but not as stern. Non-LTS is like Fedora, but mostly staying with upstream-as-of-release freeze. Ubuntu seems to do much less engineering but has done a good job within that constraint. Of course lots of that engineering is really done by debian. | I don't check weekly for system updates here but I do try to keep my | systems updated for security reasons but I am very very uncomfortable | when the right to control the timing of the updating is taken from me. If your machine is connected to the internet, especially if it offers services to the internet, you probably need to be able to do certain updates very quickly. When a fix comes out, exploitations may follow within hours. Typically distros make the update available when or before the vulnerability disclosure is published (it is hoped that this reduces the vulnerability window). So you may want security updates applied ASAP, perhaps through automation. Note: you may find out when your security is compromised but you may not. So saying "it has never been a problem for me" is naive. ================ I am a contributor to the Libreswan ipsec implementation for Linux. RHEL and Fedora include Libreswan. We have one development tree. Security fixes, bug fixes, and feature changes are all piled in. It's hard work for Red Hat to separate the fixes from the feature changes and then backport the fixes. debian does a bit of that too (I'm not sure how much). I don't know of any other distro doing that with Libreswan. ================ If you remember, we were invited to a recent debian bug squashing party. I attended. The purpose was to remove release-blocker bugs from packages. I picked the poppler package to work on. There were a number of CVEs, some considered release blockers. Naively, I would have considered all CVEs to be release blockers, but that wasn't the case. All the CVEs were fixed in newer versions of poppler. But since debian had frozen the packages for release, we could not just adopt the newest version of poppler. Instead, we had to import each changeset that fixed a blocking CVE and backport it to the frozen version of poppler. The logistical friction was considerable. I didn't manage to actually accomplish anything in the day. It is very important for a distro to get the process right. The application of process, on a micro scale may look silly, but the discipline surely makes for more predictable and consistent results. ================ distros have been struggling with a few problems: - some customers want stability EXCEPT for a few things key that are critical to their use. For example, they might wish a current PHP. - it is a lot of work for a project to get their package adopted by all the distros that they care about. As a user, you may find that a package has not been ported to your distro of choice. - some organization might wish to deploy a package of their own creation internally, on several different distros. Snaps, flatpaks, and containers are all attempts to address these (and other problems). Example: I recently wanted Gargoyle (interactive fiction player) on Fedora. The .rpm didn't work (the wrong name for a shared library). So I had to figure out how to build it from the git tree. If they had provided a flatpak, I would not have had to do that.