3 ms·
> (I'm writing it from snapped firefox and it works perfectly and faster that .deb and flatpak alternatives) That's impossible, the snap runs through a loop ba
by mixmastamyk 4y ago
> (I'm writing it from snapped firefox and it works perfectly and faster that .deb and flatpak alternatives)
That's impossible, the snap runs through a loop back image. Which makes the other claims suspect.
Yes, snap spamed my mounts, runs a daemon, forces ~/snap... probably other things I'd like to forget.
I got tired of cleaning that up every time and finally decamped to Mint last year after ~15 years of using Ubuntu.
The experience was so bad with snap I'm actually afraid to try flatpak and so far haven't. So far just download/untar an archive if in a pinch. Also odd, because I'm open to the need for adhoc installs.
- selivanovp 4y agoJust check yourself. Canonical and Mozilla spent a lot of time optimizing snaps and firefox inside specifically. The last time I run tests was about two months ago and snapped ff performed better than flatpak and deb versions. The main reason for that is more optimal compilation flags they were able to use in a snapped environment.
- mixmastamyk 4y agoNot able to because my main machine is Mint now. But, even on the Ubuntu box, running the deb version is not (generally) possible any more? Also, I see no reason a compilation flags could be used inside a snap but not out of it, other than a policy choice. Finally, what about every other program that uses snaps? This doesn't solve any of the other poor design issues. Like I said, I used Windows for years and ad-hoc is how software is installed there. But even on Windows, installing a program doesn't involve bullshit like spamming Explorer with disk images.