It depends what you’re trying to accomplish. For me, having the ability to essentially use Lego to put together my system is one of the great features of both snap and nix that Flatpak doesn’t cover.
It depends what you’re trying to accomplish. For me, having the ability to essentially use Lego to put together my system is one of the great features of both snap and nix that Flatpak doesn’t cover.
There are plenty of use cases that snap provides that flatpak doesn’t - they only compete in a subset of snap’s functionality. For example, flatpak does not (and is not designed to) provide a way to use it to distribute kernels or system services.
That is the behaviour that’s built for when an upgrade through a “classic” package manager (e.g. apt, dnf) updates Firefox while it’s still running. The only way I can think of that you’d get that with a snap is if you’re intentionally bypassing the confinement (e.g. by running /snap/firefox/current/usr/lib/firefox/firefox
directly, which can also massively mess with other things since Firefox won’t be running in the core22
environment it expects).
If you’re using the snap as expected (e.g. opening the .desktop
file in /var/lib/snapd/desktop/applications/
, running /snap/bin/firefox
or running snap run firefox
), snapd won’t replace /snap/firefox/current
until you no longer have any processes from that snap running. Instead you’ll get a desktop notification to close and restart Firefox to update it, and two weeks to either do so or to run snap refresh --hold firefox
to prevent the update (or something like snap refresh --hold=6w firefox
to hold the refresh for 6 weeks). Depending on what graphical updater you have, you may also have the ability to hold the update through that updater.
Are you sure you’re running the Firefox snap? Because that sounds pretty much precisely like the expected behaviour if someone had gone to lengths to avoid using the snap.
Containers are great, but I find Docker’s way of making container images to be pretty bad, personally. Fortunately you can use other tools to create OCI images and then copy them into Docker, as the runtime is pretty nice for dev machines.
The updates download in the background and will install when you exit the snapped app. If you really don’t want automatic updates, you can run snap refresh --hold
to hold all automatic updates or add a snap name to hold updates for that snap.
A built-in way to have services running (which is why openprinting can make a snap of CUPS but AFAICT can’t make a Flatpak).
Many US states got their capital chosen because when the territory became a state it happened to be the closest to the centre of population of the state. Jefferson City, MO is a good example of this. The three major population centres at the time were St. Louis, Kansas City and (to a much lesser extent) Joplin. So Jefferson City was right by the centre of population.
Meanwhile, most European capitals (including at the provincial level - think German states or French regions) came to their state by being the capitals and cultural centres of feudal states, which gives them more depth.
I don’t mean any offense to Iowa (this time), but there’s not a huge amount going on there. It exists almost exclusively as an administrative division.
Yeah, adding a separate microarchitecture like amd64v3 would be a separate item. They might be able to do that with amd64v3 overlay repos that only contain packages that most benefit from the newer microarchitecture.
Personal stuff goes in ~/Projects
Work stuff goes in ~/Work/Code
Still pretty important given how many systems are using the 1.0 series.
Snaps have had a permission system for at least 5 years now.
I don’t have a good comparison for this since my Intel CPUs are from 2014 or earlier, but I was thoroughly impressed with how well my new AMD laptop did video encoding (compared to the only-as-expected bumps in performance otherwise). Do you have examples of how much better QuickSync is than VCN?
You’re making my point for me though. Each of the other things you’ve suggested is more work than requires more expertise. Popping up an emulator on an existing box and dumping a ROM in there is something an intern can do.
All of these other things can be done, but they’re not as quick and simple, and that’s why we’re seeing this in the first case - Nintendo went with a quick and simple solution, and someone found a bug (it still plays Windows noises).
I generally use avocado and horseradish that I dye green for some reason.
I take it you’ve never ported an application to a different platform running on a different hardware architecture before.
Better to put thin slices of raw fish on it.
Next time use arborio rice. It sticks together nicely and creates a protective layer for your keyboard.
This looks a whole lot like it’s probably some random emulator they grabbed and full screened?
Making an FPGA for all of this is far more work than pulling an open source emulator and sticking it on a machine…
Flatpak has long had the ability to dump the contents of a snap into it, because snaps had already solved many of the build issues flatpaks were struggling with and they used similar runtimes for their sandboxing. It’s also a convenient way to convert apps over, since many apps got packaged as snaps before flatpak was really usable.