4 ms·

That wasn't a dig at you - that was a dig at snaps. My primary objections to snapd are: * updates are pushed/applied and services restarted on an arbitrary sc

That wasn't a dig at you - that was a dig at snaps. My primary objections to snapd are: * updates are pushed/applied and services restarted on an arbitrary schedule which means you can't test updates prior to rolling them out or otherwise control when a service is taken offline by an update * snapd doesn't log the actions it takes to standard OS logging facilities and the internal logs accessible via "snap changes" are cleared after 72 hours so you can't tell what actions it has taken * snapd pollutes home directories with a directory called "snap" that can't be moved/symlinked/hidden. snapd is a poorly conceived project written by people that are profoundly ignorant of how real services and servers are actually operated. Despite having the above flaws repeatedly pointed out, the developers have shown zero interest in taking actual concrete actions to address them.

lproven 4y ago
OK, these are valid points. Are there any bugs open on Launchpad for any of these? If not, and you seem both knowledgeable and opinionated on this, open some! I will happily mark them as affecting me too. Personally, I run an `apt full-upgrade -y` every day on my working boxes, and I update snaps and flatpaks in the same command, so this never affects me personally, but they are valid points. I can also write about them and possibly spur Canonical into some action, but I'd need some public discussion of the issues with Canonical staff. E.g. bug reports on Launchpad. ;-)
- alyandon 4y ago
  Appreciate the willingness to raise these issues but Canonical has flat out rejected the idea of allowing sysadmins to disable automatic updates and run them during an arbitrary maintenance window. They offered up a mechanism to defer automatic updates to occur within specific windows but that does nothing to alleviate the problems for critical services run as snap packages that require coordination with other parts of the fleet. Additionally, you have to configure snap on each system ahead of time for a maintenance window to take advantage of that feature and of course any system changes have to have their own maintenance windows and change process paperwork so now you have 2x the amount of work to do just because Canonical thinks they are in the right. The home directory pollution problem was pointed out by many people at the very beginning of the project specifically complaining that that needed to change immediately because of the concern of that decision becoming ossified into the codebase. The developers promised to look into it and now here we are almost a decade later with that stupid directory still polluting home directories because now it's too hard to revisit and would break too many things. :-/ Finally, the whole issue with snapd not explicitly logging package updates and other actions to OS facilities (that can be forwarded to security services) in favor of its own internal log that it self-purges every 72 hours is just pure insanity. There is simply no way having snapd running in any sort of regulated environment would ever pass an audit.
  - lproven 4y ago
    > Canonical has flat out rejected the idea I need citations. I am not saying I doubt you, but if these objections are to be reported upon, I have to be able to point to the receipts. I need to see the bug reports, or the mailing list posts, and specific examples of the "home directory pollution" and so on.
    - alyandon 4y ago
      I've long since stopped tracking the current state of snap related issues so I don't have any relevant links to provide. 1) For auto updates, you can find plenty of examples via Google/Reddit searches that eventually tie back to discussions on the Ubuntu discourse forums where the snap developers weigh in and explicitly state they are not going to provide a way to disable snap auto updates. 2) For home directory pollution, IIRC the objections were raised on the bug tracker for snapd so once again it should be possible to dig up the discussions around that pretty easily. 3) For the 72 hour thing, you can find people complaining about the lack of proper logging easily enough where eventually someone mentions the 72 hour auto purge problem. I verified it myself by going through the source code for snapd with the comments in the code mentioning trying to keep memory usage down. I recall scarcely believing anyone would do something that bone headed but here we are. This may be a case where no one has "officially" raised an issue on their forums or bug tracker though that ties the two things together though. Hope that helps you track that down.

lproven 4y ago

OK, these are valid points. Are there any bugs open on Launchpad for any of these? If not, and you seem both knowledgeable and opinionated on this, open some! I will happily mark them as affecting me too. Personally, I run an `apt full-upgrade -y` every day on my working boxes, and I update snaps and flatpaks in the same command, so this never affects me personally, but they are valid points. I can also write about them and possibly spur Canonical into some action, but I'd need some public discussion of the issues with Canonical staff. E.g. bug reports on Launchpad. ;-)

alyandon 4y ago
Appreciate the willingness to raise these issues but Canonical has flat out rejected the idea of allowing sysadmins to disable automatic updates and run them during an arbitrary maintenance window. They offered up a mechanism to defer automatic updates to occur within specific windows but that does nothing to alleviate the problems for critical services run as snap packages that require coordination with other parts of the fleet. Additionally, you have to configure snap on each system ahead of time for a maintenance window to take advantage of that feature and of course any system changes have to have their own maintenance windows and change process paperwork so now you have 2x the amount of work to do just because Canonical thinks they are in the right. The home directory pollution problem was pointed out by many people at the very beginning of the project specifically complaining that that needed to change immediately because of the concern of that decision becoming ossified into the codebase. The developers promised to look into it and now here we are almost a decade later with that stupid directory still polluting home directories because now it's too hard to revisit and would break too many things. :-/ Finally, the whole issue with snapd not explicitly logging package updates and other actions to OS facilities (that can be forwarded to security services) in favor of its own internal log that it self-purges every 72 hours is just pure insanity. There is simply no way having snapd running in any sort of regulated environment would ever pass an audit.
- lproven 4y ago
  > Canonical has flat out rejected the idea I need citations. I am not saying I doubt you, but if these objections are to be reported upon, I have to be able to point to the receipts. I need to see the bug reports, or the mailing list posts, and specific examples of the "home directory pollution" and so on.
  - alyandon 4y ago
    I've long since stopped tracking the current state of snap related issues so I don't have any relevant links to provide. 1) For auto updates, you can find plenty of examples via Google/Reddit searches that eventually tie back to discussions on the Ubuntu discourse forums where the snap developers weigh in and explicitly state they are not going to provide a way to disable snap auto updates. 2) For home directory pollution, IIRC the objections were raised on the bug tracker for snapd so once again it should be possible to dig up the discussions around that pretty easily. 3) For the 72 hour thing, you can find people complaining about the lack of proper logging easily enough where eventually someone mentions the 72 hour auto purge problem. I verified it myself by going through the source code for snapd with the comments in the code mentioning trying to keep memory usage down. I recall scarcely believing anyone would do something that bone headed but here we are. This may be a case where no one has "officially" raised an issue on their forums or bug tracker though that ties the two things together though. Hope that helps you track that down.