3 ms·

Snap remains the more capable tool: it supports server apps on machines with no GUI Ah, yes - who wouldn't mind their web server, rdbms, hypervisors, etc going

Snap remains the more capable tool: it supports server apps on machines with no GUI Ah, yes - who wouldn't mind their web server, rdbms, hypervisors, etc going down while they are upgraded and restarted automatically whenever snapd decides it is time to do so? gag

jacooper 4y ago
And I don't why Snap exists when everyone already uses docker and OCI containers.
- kramerger 4y ago
  Those are completely different things.
- jacooper 4y ago
  I don't get*
lproven 4y ago
I wrote the line you're quoting. You are imputing meaning to it that I did not put there. Ubuntu is a very popular and successful server Linux, used on millions of VMs. I strongly suspect that those VMs are not built with Snap and don't use it for much. I think they're build from .deb packages, probably deployed with Puppet or Chef or Juju or something. But Snaps work on servers, and Ubuntu Core is built only from Snaps. That is all I said. I didn't make any claims of how people deploy Ubuntu on servers. Please don't put words in my mouth.
- alyandon 4y ago
  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.

jacooper 4y ago

And I don't why Snap exists when everyone already uses docker and OCI containers.

kramerger 4y ago
Those are completely different things.
jacooper 4y ago
I don't get*

lproven 4y ago

I wrote the line you're quoting. You are imputing meaning to it that I did not put there. Ubuntu is a very popular and successful server Linux, used on millions of VMs. I strongly suspect that those VMs are not built with Snap and don't use it for much. I think they're build from .deb packages, probably deployed with Puppet or Chef or Juju or something. But Snaps work on servers, and Ubuntu Core is built only from Snaps. That is all I said. I didn't make any claims of how people deploy Ubuntu on servers. Please don't put words in my mouth.

alyandon 4y ago
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.