Hacker News new | ask | show | jobs
by eptcyka 1339 days ago
> one of the primary points of containerization is the ability to have multiple copies of an application running in parallel using different "application images". One should be able to upgrade (i.e. install a new image in parallel to the old one) without disrupting existing execution environments.

Would you like to run a completely new Firefox with a completely new profile whenever you update it? You do know that you can't use the same profile even with the same version of Firefox in two separate Firefox instances concurrently, right? If the updater was aware of snap and snap aware of the application it's updating, you could have a graceful update procedure that serializes the current state and reloads the new container, but that's a lot of hoops to jump through, and the jumping must be coordinated between multiple stakeholders.

4 comments

No, but the issue here seems to be a problem with the underlying snap system, not with the concept. It should be possible to have multiple containers that, when run, access the same persistent data. So the workflow would be:

1. Install and start Firefox. There is one container and one directory full of profiles.

2. Start the upgrade. This creates a second Firefox installation (container) sharing the same profile directory.

3. Try to run Firefox without quitting the old one. Does nothing because the runtime is smart enough to know that the old one is running. Maybe pop up a message suggesting restarting Firefox.

4. Quit Firefox. Start it again. The new one runs. All the data is still there.

5. The old installation goes away.

The runtime has plenty of flexibility in how to make this work. There could be multiple containers. There could be one container with multiple parallel versions. There could be one container with a staged upgrade that can swap in essentially instantaneously once the container is idle (although this may fall apart on multi-user systems or where the containerized program regularly has multiple running copies of itself at once, e.g. a program like bash).

But the fact that snap apparently has trouble with this seems a bit embarrassing.

And snapd has all of the information it needs to do all of this. "Is Firefox Running?" is a tricky question in a traditional package install, because there's a number of ways you can launch a program and "ps |grep firefox" isn't quite right. But that's not the case for snapd! It is the executor and all launches to Firefox have to pass through it; If you launch Firefox while it's running and there's an update queued, it should be able to pass that on to the old version, while still being able to handle "This program is exiting and has an update queued, so let's update it now".

Every critical piece of information is available to Snapd, and yet, they have chosen the wrong and broken implementation.

literally the first point of parent post was:

> if a container is running for the current user, execute firefox in its context

So there is no need for snap to fancy serialization, just have new and old firefox ready, and keep using old one while it has running processeses. And if the old one exits for any reason, start new one instead.

That's all snap has to do! But it does not, because it really likes to make strange texhnical decisions for some reason.

(For "coordination", snap could make a common file in old app dir like "bin/new_version_availablec, and if firefox detects it, it shows that "your browser needs to be updated" button. I would not be surprised if something like this already exists in firefox. But I doubt snap would use this approach because it is not complex enough for it :) )

They're not asking for multiple uses of the same profile. Assuming one profile, then the old image would keep being used until firefox shuts down entirely, and once that happens the new image would be used the next time firefox is opened.

You don't need to serialize or reload anything.

Almost like copy on write hasnt been invented yet. Just copy the profile on creation of a new instance