[compsciphd]

I used to defend snap with the idea that it makes sense for some apps, i.e. "firefox" where updating firefox while its running is bad news.

Except, snap can't update applications while they are running!

i.e. try to do a snap refresh while firefox is running, nothing to update, because its running, quit it wait for all processes to die and then refresh, and it will update and cause you to wait 30-60s while it does it, and then you can restart firefox.

This has to be one of the most idiotic design decision ever made by a containerized application system showing the designers don't understand containerization at all.

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.

Basically all firefox has to do is

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

2) if no container is running for the current user, create a new container

3) every so often, garbage collect old images that don't have containers running for them.

these concepts are so simple, even docker basically does it!

and that's my rant for the day.

[cgriswald]

> i.e. try to do a snap refresh while firefox is running, nothing to update, because its running, quit it wait for all processes to die and then refresh, and it will update and cause you to wait 30-60s while it does it, and then you can restart firefox.

Oh, it's worse than that. When there is an update available but firefox is running you get:

> % snap refresh

> All snaps up to date.

It doesn't even tell you there is an update and that you need to close firefox to get it. In fact, it tells you there isn't one.

[AaronFriel]

This seems broken, full stop.

Can Firefox itself, when installed via Snap, notify the user that it needs security updates? If so, can users effectively do that, or do they have to know this incantation of closing, waiting, running a terminal command, and restarting?

[rbanffy]

That’s a step backwards. The whole point of package managers is that the system manages software updates and the software itself can be completely oblivious to that.

Snap done properly it’d download and install the new version, point launchers to that and prompt the user to restart running snaps.

[a_t48]

This is what Slack does.

[Jenk]

Polite FYI:

When a statement has many examples it is correct to use "e.g.," which is an abbreviation of _exempli gratia_, which in turn is Latin for "for example." For example: There are many emotions a person may feel, e.g., happiness.

When a statement has only one logical conclusion it is correct to use "i.e.," which is the abbreviation of _id est_ which in turn is Latin for "that is." For example: It was the same colour as a clear summer's day sky, i.e., blue.

[elgenie]

My mnemonic is "i.e." = "in essence" and "e.g." = "example given". The real phrases being abbreviated are, of course, the Latin ones.

[Brian-Puccio]

Mine mnemonic is use e.g. when you could say “for eg-zample” and use i.e. when you could say “that is” — ie to is. Admittedly, the second half isn’t as good as the first. : )

[sumanthvepa]

Loved this. Sure it is language pedantry. But proper grammar really does improve comprehension.

[_carbyau_]

This had me conflicted.

It seems a bit trite to pick on a single element of language out of the whole post. But it was delightfully communicated and factually educational.

TIL.

[teekert]

Til, thanx.

[eagsalazar2]

jeeze please stop! e.g. and i.e. both have come to interchangeably and loosely mean "for example" in the very broadest interpretation. Why? Because way back when people who wrote those things did agree on a specific and distinct meaning for each, a lot of other people who didn't share that understanding co-opted those abbreviations to mean "for example". That interpretation has now exploded in popularity. At this point that simple and shared definition for both is overwhelmingly used and understood by the vast majority of the population - which makes it "right". A historically held understanding of how a word, phrase, or abbreviation was commonly used does not mean that historical belief is right today. That's not how language works. It evolves and that is a good thing. Grammar prissiness is both misguided and futile because language will continue to beautifully evolve no matter how much you try to label that evolution as "incorrect".

[funklute]

> e.g. and i.e. both have come to interchangeably and loosely mean "for example"

It seems you live on a completely different planet to me... "i.e." simply does not mean "for example", and no one who has a good, academic level of English would ever think so.

[eagsalazar2]

I'm not saying anything about what I do or don't know about the meaning of i.e. vs e.g., I'm just saying stand in front of any mall in America and poll people as they go in:

(Q1) "Do you, even occasionally, ever use e.g. or i.e. when speaking or writing?" Almost all people will answer yes.

(Q2) "Can you correctly define these abbreviations and explain their correct usage?" 1 in 10 will answer correctly.

(Q3) You (the interviewer), use one or the other in a sentence, ask people to correctly paraphrase your meaning to see if, in spite of their lack of academic understanding, they are still perfectly capable of understanding you. 9 in 10 will answer correctly.

This, almost by definition, represents linguistic evolution. And that is ok. I would go so far as to argue that "academic level of English" should be rephrased as "academic style of English" and that that stye has zero relationship with any notion of "correctness" at all. Telling the 9/10 from Q2 that they are "wrong" is, again, very misguided and pretty jerky honestly.

[funklute]

> Telling the 9/10 from Q2 that they are "wrong" is, again, very misguided and pretty jerky honestly.

I disagree. I do see your point about linguistic evolution. But I don't think it applies here.

In my native tongue, the word for "and" and the word for "to" (the infinitive marker) are very similar. As a result, tons of people mix the two up. But probably not even the most progressive and liberal linguist would agree that this represents linguistic evolution. It is pretty much universally understood to be symptomatic of a poor technical understanding of the language.

I think the same applies to "i.e." vs "e.g.". They are both used predominantly in academic style or level (whichever you prefer) of English. And in that context, their respective meanings are often quite important for understanding the precise details of a text.

I don't think that paraphrasing a text is a good test here btw - even with an A1 or A2 level of English you can get a pretty good rough understanding. Besides, paraphrasing often loses the precise meaning, which I would argue is to answer incorrectly. Logical hierarchies and implications really do matter when it comes to conveying information, and if not everyone understands the subtleties of the language, the go-to response should be "more education is needed" rather than "let's give up and have all words mean the same thing".

[eagsalazar2]

A more appropriate preamble to gp comment might be "It might be of historical interest to you that e.g originally stood for <blahblah> and meant <blahblahblah> and i.e. <blahblahblah>". It would be even more interesting to include some information about the history of its usage and influences leading to its modern (and perfect acceptable) usage.

[eagsalazar2]

And, in case you think I'm being pedantic here, I'm not making a stink just because I think you are misguided, I'm making a stink because grammar prissiness is a favorite pastime of liberals (which I am BTW) but the real social impact of grammar prissiness is social classism (putting it nicely) and gross racism (putting it less nicely). You nitpick the grammar of your fellow tech bros on HN (which I also am) but when someone goes so far as to say "I ain got nuttin but deeze bags uh sasage", they get this condescending attitude on full blast like "OMG so uneducated and uncultured!!" while failing to recognize that that manner of speaking is a dialect and is most commonly associated with our poorest and most disenfranchised peers. You may not mean it this way but it is equivalent to saying "white rich conformist == right, poor and different == trash".

[6510]

The proper way is to down vote everything that isn't about Ubuntu.

We are all wrong.

[thomaslord]

Firefox is a particularly interesting case because it has a bunch of issues that only exist when it's installed via snap. I just recently ripped out the default snap version and installed via the official PPA, and Firefox seems to be running much smoother now.

For basically any app I use that's installed via snap, I eventually run into a gamebreaking issue and have to remove the snap version and find a normal .deb to install from. Whether it's customization issues (setting up custom fonts in VS Code didn't work) or stability issues (the tab bar in Firefox windows freezing up), there always seems to be some kind of problem

[Zardoz84]

Also, there is the funny thing that when you updated to 22.04 and Firefox it's replaced by the snap version, you lose access to your previous Firefox account on the computer! The account isn't deleted... If you remove the snap version and install the normal version from a PPA, you get back your account with all the settings.

[asddubs]

they seem to have fixed that at least. I had the same problem with a computer I updated immediately, but not with one that I waited a bit on. Incidentally you can fix this by copying your .mozilla directory in the correct place in the snap directory in your home folder

[echelon]

Snap makes sense, but it'll take time for the dust to settle. Just like Unity / Wayland.

Applications like Firefox, IntelliJ, Chromium, etc. shouldn't be tied to system dependencies managed by apt. They should be entirely monolithic and hermetic.

Long term this deb vs snap approach will make sense and be good for Desktop Linux.

[theamk]

Is snap enough of improvent over deb to replace it? Sometimes yes.

Is snap enough of improvement of Flakpak to ignore community standard and deal witb all the user hostile craziness like non-removable updater? No way.

I hope it goes the way of the Mir and upstart - replaced with a competitor and silently removed.

[talideon]

Upstart predates systemd by four years. It solved real problems at the time and they kept it going until Debian transitioned to systemd. Unlike systemd, upstart supported sysvinit scripts, so it made sense to transition when Debian did. Bringing that up is maybe not the best example you could choose to bash them with.

[theamk]

I am not saying anything about decision to _start_ using upstart... All I am saying is that in the past, Ubuntu made the right decision multiple times and switched from Canonical-only software to a more common alternative once that alternative became widely used.

And I think that it's a grand time to slowly wind down snaps and switch to flatpak. Linux ecosystem does not need more fragmentation, and given proprietary nature of snap store, there is approximately 0% chance that anyone except Ubuntu derivatives would adopt it.

Maybe snap was better than Flatpak back in the beginning; I can easily believe that when the snaps were introduced, they were better than flatpaks. I am not going to judge. All I want to see a right decision made going forward.

[padraic7a]

If Ubuntu and it's derivatives go for Snaps then while that's a minority of distros it's probably a majority of the Linux user base.

[nrclark]

Fwiw, systemd actually supports sysvinit scripts pretty well. You can mix and match, and write unit files that depend on init scripts or vice versa. And you can manage them all with systemctl.

[ratsmack]

Funny thing is that systemd just calls the scripts in /etc/init.d, but I'm told that it is an improvement.

[bayindirh]

> Snap makes sense...

No. When we have flatpak and appimage, snap makes zero sense. I just see it as a way to implement a centralized walled garden into the OS, and don't install Ubuntu systems even in VMs for five minute test drives.

The way Canonical rolled it out is flat out insulting to the free software community and distro culture, IMHO.

It's too late here to write about its technical problems, so I'll leave it at that.

[hsbauauvhabzb]

I don’t disagree but that won’t change the fact that snap completely broke my Firefox workflow, and doesn’t gracefully allow me to restart Firefox (rather inconsistently have tabs crash unexpectedly).

Snap is immature, and not ready for production deployment. The way Ubuntu/parent company have pushed snap has been damaging to its image.

[throwup]

> it'll take time for the dust to settle. Just like Unity / Wayland

There's a particular irony to this statement. Before adopting Wayland, Canonical tried to do their own thing with Mir[1]. Years later they gave up and reluctantly adopted Wayland. Their investment in Snap rhymes with this. Snap is an inferior competitor to Flatpak, and in the end it's likely the dust will settle for Snap the same way it did for Mir—in the dirt.

Canoncial as an organization has some serious NIH syndrome and they are putting "Linux on the Desktop" through a lot of unnecessary pain.

[1]: https://en.wikipedia.org/wiki/Mir_(software)

[asdajksah2123]

I don't think Snap is an inferior solution, as much as Canonical is trying to put Snap where it doesn't belong.

AFAICT, Snap is a pretty good solution for server side apps. This is pure speculation (and I don't even know if the timelines line up), but I suspect Canonical developed Snap for server apps, but something made it economically non viable (maybe the popularity of Docker?) and so they now needed to generate money through it some other way and they decided to do it by using it as a workstation app distribution mechanism, and by locking it down for enterprise.

[Arnavion]

"Server apps" can just be systemd services with isolation configured to your liking. Even if it's necessary that the service include some arbitrary subset of userspace, that can still be done with systemd portable services.

[padraic7a]

Mír still exists. It's a Wayland compositor now for IoT but it's still there.

[Arnavion]

throwup is referring to Mir the display server that implemented Mir the display protocol, because Canonical didn't understand Wayland, didn't talk to anyone that did, and so decided they needed their own protocol.

[yjftsjthsd-h]

> Just like Unity / Wayland.

So, flatpak will win, after years of Canonical messing about with snaps?

[HideousKojima]

If you say so, but I don't see why it should be forced on Ubuntu users by Canonical until then.

[rbanffy]

It’s just 6 or 7 years. Give them time.

[seiferteric]

Actually brings up a good question of why can't dpkg/.deb just support having multiple library versions? My understanding is that it is not support, but if it was, then couldn't that obviate the need for snap?

[bayindirh]

Many people are unaware that "so naming" [0] solves multiple versions of the same library problem.

My Debian installation regularly has two or three versions of the same library (e.g. libx264) installed while packages update and start to use newer versions of the same library.

[0]: https://tldp.org/HOWTO/Program-Library-HOWTO/shared-librarie...

[echelon]

The point is that some apps should be 100% hermetic and not have package dependencies whatsoever. The browser is a prime example.

[bayindirh]

I don't think user facing programs needs to be hermetic. If you want to limit behavior of a software there's always AppArmor and SELinux.

Trying to make a set of applications can't interact on an (desktop) environment which built on the promise of cooperation and inter-application communication is backwards from my perspective.

I understand that the browser is a significant vector for attacks, but there are other and more elegant ways to counter these attacks, and these can be layered from application itself to kernel and to hardware. This layered approach is more integrated, universal and applicable to a broader surface area in the OS and application stack.

    <rant> Romanticizing isolation and immutability, trying to apply it everywhere in the software stack is a big step backwards in usability and productivity. These technologies are useful in some (and mostly in) server/service scenarios. Trying to apply these principles to everywhere is akin to only having a hammer and seeing everything as a nail. Just because they're easy, they're not the correct and best solution for anything and everything. Maybe we shouldn't be that lazy and try to create more useful and transparent user sandboxes built on cgroups, SELinux and AppArmor, and works with the package managers or traditional distro layouts seamlessly. </rant>

[elcritch]

I don’t know. I sorta like my browser to be able to use my system fonts. Snap and friends appear to struggle with that.

[makapuf]

You said that several times but why is that? What programs should be isolated and why are those not a static binary installed and updated with apt?

[rbanffy]

> but it'll take time for the dust to settle.

I remember seeing it demoed at Canonical in 2015 or so. It’s been 7 years. How much longer should we wait?

[asddubs]

I personally hope AppImage wins over snap, it seems to be the best of its class, and isn't so centralized. It would still need to be paired with a package manager for updates, of course

[donio]

> Snap makes sense, but it'll take time for the dust to settle. Just like Unity / Wayland.

That comparison is not helping to sell it.

[midoridensha]

>Snap makes sense, but it'll take time for the dust to settle. Just like Unity / Wayland.

How much time? We've been waiting for over 10 years for the dust to settle with Wayland.

[pikelet]

I've been using Wayland happily for the last few years. I'm missing colour management but I know it's (slowly) being worked on and I can wait, as everything else I need works better than it did for me under X11. Can't say the same for Snap. Wayland has become progressively better over the years. Snap just seems to get progressively more intrusive as they force it more and more. Longstanding complaints go unaddressed. Flatpak has been more or less pleasant. Feels very similar to the Mir/Wayland days to me.

[binwiederhier]

I've been on Ubuntu 22.04 for a few weeks now, and every now and then Firefox will create a popup notification that says "Firefox needs to be closed to update (12 days left)". When I close it and re-open, Firefox is still not updated. Even when I go to the Software Center and update all apps, it apparently doesn't update snaps.

I'm not entirely sure if Firefox is updateable via the UI. It's truly awful; and that's coming from an Ubuntu lover.

[hellcow]

Yup, you need to shutdown firefox, open a terminal, run ‘sudo snap refresh’, wait for it to complete, then re-open firefox.

Agreed that the process sucks :)

[midoridensha]

>Yup, you need to shutdown firefox, open a terminal, run ‘sudo snap refresh’, wait for it to complete, then re-open firefox.

No, you don't need to do this at all. You need to shut down Firefox, open a terminal, run 'sudo snap remove firefox', then 'sudo apt install firefox', wait for it to complete, then re-open Firefox.

(I might be missing a step here)

[lern_too_spel]

The step you're missing is to add the Firefox PPA. Ubuntu's Firefox deb is just a Snap installation script.

[maccam94]

You also need to futz with apt repo priorities to force it to install the deb package instead of the snap installer -_-

[PenguinCoder]

Does running a standard `apt update/upgrade` update the snap packages, even it they're in use?

[Avshalom]

apt doesn't touch snaps at all afaict

[mrighele]

Ubuntu 22.04, got fed up with snap firefox, removed it and installed it from a ppa, pinning appropriately

I still get notifications that to update the snap ai need to close firefox, so I wonder what is really happening…

[huggingmouth]

I uninstalled the snap version and installed the flatpak one. No more lying pop-ups (I close firefox but it never updates when I reopen it).

Bonus, I don't need to be root to update it!

[neltnerb]

Oh god, I have yet to figure out what it even wants. I assume it is asking me to close firefox to run an update, but I do and nothing is run. And apt upgrade doesn't somehow catch it?

It's amazing that they're managing to make it so confusing that someone who wrote .xsession files can no longer understand it without doing a bunch of research. This shouldn't be tricky... that message, in particular, is absurd. Why would you show that and then not have a button that says "update"?

[noasaservice]

> I used to defend snap with the idea that it makes sense for some apps, i.e. "firefox" where updating firefox while its running is bad news.

> Except, snap can't update applications while they are running!

What's worse is the unblockable notifications.

And I just de-snapped my xubuntu 22.04 , and doing so upgraded firefox-snap v113 to their repo v116 ! I mean, I thought the purpose was fully updated. Evidently not.

Snap needs to die in a fire.

https://haydenjames.io/remove-snap-ubuntu-22-04-lts/

[curt15]

Flatpak updates work pretty much the same way. The new version is installed into a parallel directory and takes effect the next time the application is restarted.

[tetha]

So I'm not nuts. My work laptop recently changed from Fedora using flatpak to Ubuntu using snap and with flatpak, I'd get a couple notifications "Hey, XYZ was updated" and on the next reboot, it was new. With snap, I have to shutdown the application, update it in a console and relaunch it. Meh.

[xorcist]

If it was that simple, why wouldn't the deb package work like this? There is no technical reason a new version of a software can't execute in parallel to the previous.

Firefox can't do that. The simplest reason being that it is stateful and keeps records of history, bookmarks and whatnot which not only can't be accessed concurrently, but the specific storage model chosen can only be forward migrated. Accessing this data from two different versions of Firefox would inevitably lead to corrupt data, even when concurrency is not an issue.

That's just the obvious reason with profiles. But there are also various other issues where Firefox interacts with the plugin system and other external data. All of these could probably be fixed, but it would require a radical redesign of the software which right now no one has stepped up to do.

The least problematic method of using Firefox on Linux for most users is probably the official tarball. It's the trivial method of unpacking a software and running it from the destination folder. It has implications for freeness and DRM, and the obvious problems bundled dependencies bring, but Firefox is unusually well maintained software with the manpower to make it work.

And containerization or producification on top of Firefox will only make it more complicated and worse supported than upstream is.

[compsciphd]

simple binaries yes, firefox installs a whole lots of dynamically read stuff that is specific to the version installed (was more of an issue in the xul days, but I think still exists).

i.e. you install a new firefox, the data on disk (i.e. file xyz) is no longer what the firefox version running expects and bad things happen. It could cache everything in memory (I guess) and never have to read anything from disk, after it starts up (relative to it, cache/cookies in local profile shouldn't matter in regards to disk).

so when you update the deb you are replacing file 'xyz' and old xyz no longer exists (as opposed to unlinking and replacing "/usr/bin/firefox" as even though unlinked it will still exist (for paging purposes) until every execution of it terminates and only then will it actually be removed from the file system.

this is where containerization can help on a "multi user" system, if everyone ran firefox in a container, every time they started it fresh, they would get the most up to date copy installed (in a non "multi user" setting, its less important, but can still have some value). (quotes because I mean multiple simultaneous desktop graphical desktop users, which if we're honest, most desktop linux users aren't doing).

[eptcyka]

> 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.

[amluto]

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.

[GauntletWizard]

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.

[theamk]

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 :) )

[Dylan16807]

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.

[dtx1]

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

[sumitgt]

Agreed!

Snap can't even update snap-store because it is running in the background.

There is no way for a non-tech savvy person to even figure out how to get past that error.

[znpy]

in the specific case of firefox, two different instances of firefox (no matter their version) cannot both use the same firefox profile at the same time (i tried).

You either have to ask the user to restart firefox (that would be the sane choice) or corrupt user data.

But i agree that snap sucks. Snap sucks particularly bad because they also push it where it's not only unnecessary but also detrimental to the user experience.

Simple dumb example: i had gnome-calculator in my toolbar. I sometimes need to make basic calculations, it's easy and I keep it handy. I realized that gnome-calculator (a 500k binary) was taking 30 fcking seconds to appear. Turns out it was "updated" to a snap, and now launching it meant for stuff to be mounted around and for snap to do whatever it wanted with my time.

[mxkopy]

I thought it was really funny when I tried to update some stuff with the snap gui, and it threw the error - "Can't update snap-store, the application is running" or something like that