Snap should be an extreme measure when there are no other means to use some obscure package that can't be run using the stock kernel or libraries. Resorting to it for common popular software is such a bad decision. I'm not a Ubuntu user as I rather prefer Debian and Manjaro; hopefully they'll never do the same.
snaps are one of a number of reasons why I'm moving away from an xubuntu based desktop to simply a base debian amd64 CLI-only install, then manually installing xorg+xfce4+misc things for a desktop environment that I really control.
there is simply too much extra crap launched from systemd (I don't have a problem with systemd, just all the extra ubuntu-specific stuff they've added as new daemons) and too many kinda-ubuntu-proprietary things shipped in xubuntu now.
I've been a very happy Ubuntu/Kubuntu user since more than a decade, but I'm seriously considering switching distros because the encroachment of snap, which I feel is not ready yet for such critical applications like Firefox.
I'm going to try 22.04 before deciding, but I'm eyeing Manjaro or Endeavor OS in case I jump ship. I'm also eyeing Qubes OS, but it looks needy and resource heavy.
I’m guessing Snaps are great for what they were designed. IOT devices.
They are good for server installations as well, except Docker/containers are almost always a better solution. Although the auto updating features make it a good solution for potentially creating self hosted services.
They’re just a terrible fit for the desktop. Unsurprising because they were never designed for the desktop.
Same here: Ubuntu was my first distro, and I've been using variants of it since 2006. This winter, I switched to OpenSUSE, with Ubuntu's insistence on pushing snap on me being the biggest reason.
I share the concerns about snaps. Ubuntu was the first Linux distro I actually started using as my daily driver in 2005, and I've been using it ever since. At first I used to upgrade all the minor releases, these days I'm just on whichever LTS release. It's funny how over the years I know less and less about Linux. It just works.
Why have you chosen OpenSUSE and how has your experience been? I've been eyeing Debian, as it's pretty similar and I already have it on a server. My main concern with switching to a completely different distro would be that the packages are sometimes named differently.
Or I could switch to NixOS if I wanted things to be actually better, but the idea that I'd have to spend time nurturing my system just doesn't sound that appealing in 2022.
I don't think I had any specific reason for picking OpenSUSE, at least none that I can remember. Their Tumbleweed rolling release seemed interesting to me.
As for the experience, I mostly like it. There is some re-learning to do (zypper not apt!), but the vast majority of things are the same. Since the distro isn't as popular, there are fewer asked-and-answered questions out there, but most Ubuntu answers work with minimal adaptation and the OpenSUSE wiki is pretty good.
Another downside of going non-Debian is that proprietary software may be less well-supported. I think I only have Steam and Spotify, and they have worked well so far.
I am trying Pop! on an old laptop, so far I have liked it, though I am not sure flatpak is a silver bullet for FF either - I upgraded another equally ancient (circa 2010) laptop to Jammy and discovered that the Firefox snap couldn't even play videos without skipping and freezing. I thought I'd try flatpak instead, but it was nearly as bad, and eventually I blew away both and went the PPA route.
I don’t think there are any distros that are pushing Flatpak as the ultimate solution the way Ubuntu is snaps.
Ubuntu’s aggressive approach with snaps would have been bad enough if snaps were the perfect desktop app solution. It’s a lot more frustrating considering snaps are probably the 3rd best new packaging option behind Flatpak sand appimage.
For sure, I do agree that Flatpak is better than Snap in general (and appimage works fine too, I guess its lack of a, uh, 'snappy' name for the format has kept it from getting as much mindshare...) In principle all three of them seem acceptable for apps I don't use much, or don't need maximum performance from, but for my main browser...
You can install a sysvinit based stock debian if you wish. I've done it a few times recently, on low memory systems (<512MB) it does make a noticeable difference. It's mostly supported in terms of running, though the install is a bit manual:
There's also instructions for converting a running system, but I've had no luck with that. It just resulted in an unbootable system for me as it couldn't fully remove systemd there.
edited post, didn't mean that I have a problem with systemd, just all the extra stuff that canonical has created as "launch on boot" daemons/services which are unique to ubuntu only and no other linux.
Very frustrating just how much CPU/memory a blank Ubuntu install uses while idle vs Debian. For largely the same resulting system. I always prefer Debian because of crap like that.
I believe you need to install xfdesktop4 and then select that in your login manager. If that doesn't work go through other packages that would have been installed: https://packages.ubuntu.com/jammy/xubuntu-desktop
Agreed - I think it is weird a distro would do this. To me, these sorts of tools are reserved for app owners who want to make the trade off to hit more distros more easily with known trade offs. Distro owners have a full pkg management system and this should be integrated into that, like it was previously.
'hit more distros' also means hitting old distro releases. We have a laptop here running a nearly EOL LTS version of Ubuntu, but thanks to the snap packaging is still running the latest release of Firefox (the most important piece of software on this machine).
That's a highly commercial story they're telling there. It's all PR. I'd bet that it was canonical who approached Mozilla and offered compensation. After all Mozilla is always looking for money.
If offering a Deb is such a major issue for Mozilla, why are they still offering a distro-agnostic one that works just fine?
This whole story just doesn't make sense but fits in perfectly with Canonical's obsession with making snap a success.
Ubuntu has been looking for ways to differentiate themselves (and arguably lock users in) for many years and Snap is their latest go at it. Consider that Debian (i.e. Ubuntu's upstream) has been providing Firefox .debs for a very long time, so it takes effort not to offer .debs for it on a Debian derivative.
Your information is outdated. It hasn't been called IceWeasel for a while now and that only had to do with a trademark issue[1] but it was still based on the Firefox sources. Source: running Firefox via .deb (firefox-esr in the Debian repo) on Debian stable to write this.
[1] IIRC, it had to do with using the Firefox name even though Debian was lightly modifying sources to remove a couple of things. This was resolved a while ago and the Firefox branding resumed.
Mozilla doesn't directly offer a .deb file. They offer precompiled binary tarballs for Linux. Mozilla doesn't make distribution specific packages as far as I am aware and it was Canonical that was packaging it for all of their supported distributions. It's less work for Canonical now to package Firefox, and Mozilla has more control over pushing updates so it's mutually beneficial for them.
Most of that work is done by package maintainers that have an interest in the project and package the update for each release.
The projects that usually do make their own debs/rpms/whatever are usually backed by companies that have a strong interest in making their software easy to access. I guess mozilla should be in that group but they aren't.
MS releases full versions of code, Google Releases Chrome, you can get a terraform deb you can get neovim. Not really sure why FF doesn't release one but the way I understand it, FF is kinda back burner for Mozilla so who knows.
Lots of projects seem to producing DEB files. I think they're the most common shared distribution format except for maybe PKGBUILD files for Arch.
Loads of projects have their own package repositories but cross distro distributions like Flatpak and Snap tend to be recommended before the docs refer to the repositories. The extra two or three clicks necessary to get the repository URL seem to make a big difference in popularity.
Because other distros have different ideological reasons for packaging Firefox their way than Canonical. Fedora, for example, applies patches to Firefox before distributing their rpm.
I use Ubuntu because no free packages are built into core repos, meaning I don’t need to add dubious repo sources. I don’t like nonfree software, but need it to use my nvidia backed laptop (the oss driver is useless). Sure the fedora community repo is probably okay, but they have no public statements on assurance or security, so who knows.
Martin Stranksy specifically does most of the Firefox packaging and additionally does a lot of upstream development work to keep Firefox running on Linux.
Which is crazy because Mozilla provides an official flatpak and Fedora has flatpak installed by default, but if Fedora developers want to be masochists they are free to do so.
Additionally, it is being done by the same folks who drive development of linux-specific features (like wayland support or video decoding acceleration) anyway.
Building the binaries themselves do. Mozilla does it few days in advance, so at the release they can push everything (and the binaries are available on the ftp.mozilla.org day before, uusually around 16:00 UTC). Other parties can start building their binaries only after the release.
In case of Fedora, it is pushed into the testing stream and only after positive feedback (or few days) it is pushed into the release. If you want it earlier, you can get the tested builds from bodhi (bodhi.fedoraproject.org). You can also see the status of all builds there.
> “This is the result of cooperation and collaboration between the [Ubuntu] Desktop and Snap teams at Canonical and Mozilla developers, and is the first step towards a deb-to-snap transition that will take place during the 22.04 development cycle,” Ubuntu desktop team’s Ken VanDine explains in a Discourse post.
This quote does not in any way support the claim that "Mozilla asked for it". Maybe find better sources for your info.
Nix has been perfect in this respect, giving full control over how you want things installed. The line between distro maintainers and users is completely blurred - you can take as little or as much control over the installation and configuration of any particular package or service that you want.
Now that Windows and Mac got bad enough, and Linux got good enough, it's no longer always 100% quackenbarkers to say "switch to Linux" to ordinary minor grievances, so those people had to go somewhere.
I've never had any problems installing a browser on Windows. What's the problem? You run the installer and it installs itself in seconds, and the browser periodically updates itself on its own without having to figure out any dependency headaches.
Sure: if you don't spend thousands of hours editing text files, learning emacs would make for an expensive investment. It's a tool for the right use-case.
You aren't forced, but you are going against the grain of the OS if you start doing things that were not intended by the distribution maintainers. I used Ubuntu for a decade - I'm familiar with it. Every tweak ended up in a more and more unpredictable and unmaintainable system that I had to just dump and reinstall every once in a while.
No, it really isn't. There are a lot of issues with both snap and flatpak, but the issue at hand is performance, specifically boot times. Snap is far, far behind every other solution out there
I completely do not understand snap hate. Imo, snap is one of the best things Canonical have done. I'm trying to read comments here to find what everyone who hates it is talking about but I can't seem to find anything except for generic nothing.
I searched for a previous discussion: https://news.ycombinator.com/item?id=23439326. The linked article is nonsense... and most of the comments are either just as nonsensical or they actually like snap. The one criticism I find is that it is slow. The other seems to be around the idea that Canonical controls it too much for some people to feel comfortable... but other than that, I don't get it.
It's closed source on the server side, proprietary, and has various issues. I was pretty shocked when they forced it into a LTS release, and the implementation was not optional and was terrible. They handles upgrades poorly, polluted the mount space, required manually cleanup, and destroyed boottimes.
If you want containers, why would you go with a proprietary canonical technology instead of one of the better open source solutions? After all isn't one of the main promises of containers increased compatibility?
Even the ubuntu derivatives are switching away from snap.
Mint is based on ubuntu though isn't it? Looking around it looks like they balked at the Chromium snapification, but that's going to get more untenable as time goes on.
It's based on Ubuntu LTS so it changes less than Fedora does. Also it's not exactly cutting edge, for instance there's no support for Wayland because Cinnamon is based on a forked extremely old version of GNOME.
Which is fine, it does what people need it to do for now. Arguably it may fall further and further behind over time though.
Snap makes sense, because it deals with desktop application confinement. Any Firefox process launched as $user is able to use all the RAM, read and write all the files, access all the networks and basically do everything as that user. You don't want that, it's stupid and so Windows 95.
There are alternative solutions: QubesOS uses VMs as the isolation layer, desktop application confinement using firejail with its good selection of profiles tweaked to my liking, systemd-run confinement configured through the vast resource control options made configurable through systemd. There is no reason ~ or even / shouldn't appear completely empty to Firefox the process except for the resources you pass to it (open file, grant download permissions...) or which it needs to run (of course, those would be immutable as far as possible). SELinux and AppArmor are child's play; you don't have a lot of problems of those tools if there are no objects a process could acceess in its namespace to begin with.
macOS I believe is already there in terms of desktop app confinement. Windows is not but at least it has the controlled folder access layer available after they gave up on making store apps meaningfully secure as its own app category (too many escapes/config tweaks possible now). Desktop Linux though has not had squat in that field in the mass market for 2 decades. Basically, you guys run all applications unconfined. Snap is a way to work on changing that.
Not saying though that the current implementation is exceptionally good. It's too slow, and they should have reused systemd or whatever for a thin, tweakable resource control and container layer, not invent a container format from scratch.
I don't know if I'd agree; with Unity you could just install a new DE & switch environments without fuss.
My biggest problem with Snap is that trying to install something like Chromium via apt, will, most likely unbeknownst to the user, just install the Snap version instead.
I recently installed Chromium via apt, and it actually installed the snap!
I mean, if I wanted the snap I'll use the snap command. If it's not available via apt just say so and quit. I don't want it to install the snap version when I asked for the apt (.deb) thing.
In this particular case the means to the end matters.
Well ok, maybe "forced" was the wrong word choice, but I would still say Unity was a more in-your-face change than Snaps are, since the vast majority of software on Ubuntu is still distribute via proper .deb packages
Of course there is the option of moving away from Ubuntu
Canonical did good work with Ubuntu, bringing the first very good desktop distribution that was usable from a mass audience.
But time has moved on, and Canonical has moved on, too. Snap makes a of of sense for a lot of purposes. But for geeks and their desktops, not so much. Canonical is no longer interested in us.
A breakdown of a relationship is always stressful, but in this case we have just grown apart, and now we both need change.
I wish Canonical all the best in their pursuit of profits in cloud software and systems, and in the IoT world (where snaps are ideal).
I am in another relationship now. We have both moved on
What makes snaps so ideal for IoT? I'd think all the extra overhead causes major headaches on resource constrained platforms. But I'm not really in IoT.
The containerization of snaps allows for easier control of different types of permissions. Of course the flip side of that is that snap packages often lose features because either the permissions aren't properly setup or the security model doesn't allow them. For example, the XSane (scanner) plug-in for GIMP was discontinued because GIMP moved to a containerized distribution, and the XSane developers aren't able to enable the permissions required to use scanners.
I think the real issue isn't making it work for IoT, it's making their devs spend less time on making desktop things work, so they can devote more time to IoT things.
I stopped using ubuntu on my servers and in my containers the day I tried to install a package, and it "succeeded", but then at runtime the binary I thought I'd installed just printed "This is now provided by a snap package, use that instead" and exited.
I consider ubuntu completely unsuitable for server and cloud. I don't think there is any use case they are suitable for anymore. Which is definitely sad.
This is an extreme overstatement. I have used Ubuntu LTS server editions for years without issues. It's widely without much issues. Sure, things could be better, but "completely unsuitable" is laughable. You're free to pick something else if you don't _like_ it, but that doesn't mean that it's unsuitable for server usage for a fact.
The fact Snaps are automatically updated in the background, and users have to resort to half-assed workarounds[1], should be an absolute deal breaker for server use, where you want total control over when and if packages should be updated.
I cannot remember what software it was, but some of our Ubuntu servers 2-3 years ago tried to auto update from a running piece of software to a snap based version, which failed, and then the process was killed or shut down. Needed manual intervention to rescue. It was a bit shocking at the time and I should have made some notes about this.
You're right. Self-inflicted was the wrong term to use here. I just meant that Canonical themselves, in some part, have been pushing the desktop crowd away, even if it's a feedback loop between Canonical and the community like you allude to.
I just wish they had followed a similar approach as Red Hat have, where they're still able to place a significant amount of effort into the desktop side of things thanks to their enterprise offering and specialized focuses, like embedded systems for automobiles, which I believe is where much of the Pipewire work came about for example.
That's not to say Red Hat is perfect or a crowning example of a Linux company "done right". Rather, it's just an example.
For Red-Hat naturally there needs to exist some form of desktop for enterprise customers, but that is as much as they care, which also reflects on GNOME decisions, as they have most of the main developers on their payroll.
I'd say that's a bit harsh - they've been employing a lot of the Wayland, Pipewire and Gnome people for example. I'm pretty sure they've been involved in a lot more core Linux Desktop projects but those are the examples I could think of in a minute.
Definitely this. As much as I like Linux, the community hasn’t been that great. So much man-hour wasted on reinventing the wheel. There’s just too much diversity in the Linux world, from distros to desktop mangers to package mangers to …
That feels most correct to me, too. Snaps are an easy way to deallocate personnel from Desktop duties without harming Server. It sounds more like an attempt at a cost-saving measure than something that benefits customers.
For the last 20 years the the only things which made the difference between the Windows Server and Windows not-server were the things which weren't available on the client SKUs at all (like Active Directery and so on).
The worst offenders were the software which doesn't allow you to install if you aren't running a servrr SKU, oyherwise I haven't any difference between a client or a server SKUs
I don't think installing software through snaps or deb packages makes a difference in terms of geek street cred. It's a linux system, you can still do with it whatever you want, they're not locking your machine down. The idea that something can't be for a mass audience and nerds is strange.
The snaps update according to their own schedule ant it is not in the control of the owner of the machine. That is enough, do you not think, for most computer geeks to prefer another system?
Comes down to definition of Computer Geek.
> The idea that something can't be for a mass audience and nerds is strange.
Really? I completely disagree. The requirements of nerds and civilians are different
This is much better than the Snap. Snaps are slow and tend to ignore themes and preferences of various kinds.
> Since the package comes from a PPA unattended-upgrades will not upgrade it automatically, unless you enable this origin:
You probably don’t want Firefox to update automatically, without your knowledge. A Firefox upgrade means you must immediately restart the browser. If this happens in the background while you’re doing something important, it can easily ruin your day.
My Firefox updates automatically, and it never told me to immediately restart the browser. Most of the times I don't notice it at all, and sometimes I notice a small blue dot on the top right hamburger menu that asks me to restart. Never forced me, just asks.
Moving from Arch to Debian I was disappointed not to find a Developer Edition package, but the official Linux release works just fine and I personally enjoy the auto-update mechanism.
> My Firefox updates automatically, and it never told me to immediately restart the browser.
It happens all time time for me. Literally happened just a few minutes ago. It happens when you open a new tab or window, not when you're browsing within an existing tab.
> Restart to Keep Using Firefox Developer Edition
> An update to Firefox Developer Edition started in the background. You’ll need to restart to finish the update.
> Your windows and tabs will be quickly restored, but private ones will not.
> You probably don’t want Firefox to update automatically, without your knowledge. A Firefox upgrade means you must immediately restart the browser. If this happens in the background while you’re doing something important, it can easily ruin your day.
I run into this issue very often. I use private browsing heavily, so the forced restart is very disruptive to my workload. I lose all my tabs and saved state.
It's subtly worse than that, I had unloaded tabs from a restored previous session, and the page it redirects to reminding you to restart overwrites them entirely when I tried to switch to them. At least private browsing tabs you were warned are a bit ephemeral.
> You probably don’t want Firefox to update automatically, without your knowledge. A Firefox upgrade means you must immediately restart the browser. If this happens in the background while you’re doing something important, it can easily ruin your day.
No not really?
If I update it here on FreeBSD it stays working and it prompts me to restart the browser when I'm ready so it can start using the latest version which just got installed.
Firefox can upgrade in the background in two ways: Through its own internal mechanism, or (as Ubuntu did it pre-snap) with apt using unattended-upgrades. It's the unattended-upgrades one that does it without confirmation and blocks you from doing anything until you restart firefox.
I'll be sticking with Ubuntu b/c A) it's relatively stable B) it ships w/ ZFS by default and C) it's so popular that software creators often put it at the top of the priority list for Linux OS support.
I understand the concerns about snaps. Look, if you want control, you have it. Uninstall it and find other installation options including reviewing and building yourself.
What I've realized over time is that for the far majority of things, I just want it to work b/c I have better things to spend my time on. I can appreciate that software devs have the same feeling regarding supporting the various Linux distros. It's less time and troubleshooting to just pick a single target like snap. Many of us want Linux desktops to gain in popularity...I can see how snap (or it's competitors) can help make that come true.
I have my doubts about something like LXC being shipped as a snap, I'm curious to see how things will play out with shipping more server software through snaps. I understand why the push towards snaps would be viewed more negatively for server applications.
I would like software to be heavily sandboxed by default. Why should any software I want to use have access to my ssh agent or all of my files? Firefox should have access to almost nothing except a limited part of the file system and the network, right? I'm not sure we are there yet, but I think this type of software packaging, "containerization", and isolation is a good direction to be heading.
There are things I don't like about snap and I kind of wish one of the alternatives would win. At the very least, hopefully they will challenge snap to be better and the ecosystem itself will benefit.
Ubuntu has unattended-upgrades, which installs security updates through apt without user intervention. Firefox is included in this, it doesn't use firefox's auto-update mechanism.
Is the linked PPA [1] actually maintained by Mozilla or is it volunteers? I can't tell. The uploader looks like a freelancer and the PPA owner hasn't been active on Mozilla's Bugzilla in over a decade.
People in this thread (and the author of the article) are under the assumption that Mozilla is running this PPA, it's run by the community.
That being said ricotz has been participating in the Ubuntu community for a very long time, and from a practical standpoint you'll probably be ok.
There's a good reason for Ubuntu to push people away from PPAs as distribution methods for end users and instead use them for what they were original supposed to be used for, make it easy for distro developers to fire up repos for testing/development with the intent of that work making it back into distro and Debian. Snaps have lots of problems but using the distro-staging PPA isn't a good idea either.
I'm pretty sure the owner of the “Mozilla Team” team PPA [1] has been dead since 2013 [2]. He is also listed as an Administrator. If someone were to comprise his account via his old email, e.g. if he used a now expired domain that could be registered, they could use this PPA to deliver a backdoored Firefox build to thousands of users and steal their passwords, tokens and SSH keys.
Community support is great but without a proper security team and enforced secutiry processes the PPAs are very dangerous.
Thanks for the links, which do seem to check out. I've marked John's Launchpad account as "deceased", so it's still visible for archival purposes but even if somebody gains control of his former email address it's no longer possible for them to make any use of his Launchpad account using it.
Debian 7 was the first Linux distro that just worked on my old PC. Believe it or not, only Debian had no screen flicker on my old NVIDIA GeForce MX 440.
Plus, it was the only distro in 2013th that had a non-free driver for that card (96-something-legacy). Imagine how old that card is when they considered it legacy in Debian 7.
Well there's another reason to shill Pop OS.. they have been de-snapping Ubuntu with great success for a while now.
With that said their 22.04 isn't out for a while and it sounds like there is a lot more involved for them this time around (just from reading this hn discussion)
I switched to Pop about a year ago and absolutely love it so far. It’s been one of the most flawless experiences I’ve had with a Linux distro (as a life long “user” but not very good at the fiddly stuff).
This was a deal-breaker for me. I don't want a firefox packaged by mozilla themselves as a snap or deb, because I don't consider them trustworthy. At least when it's packaged by the distribution someone has reviewed the changes and can flag up and disable any nonsense that mozilla is adding.
I switched to debian instead. Debian packages firefox ESR, which means my config will be stable for longer.
You don’t consider Mozilla trustworthy so you’ll use their browser but not if it’s packaged by them?
> At least when it's packaged by the distribution someone has reviewed the changes and can flag up and disable any nonsense that mozilla is adding.
For something the size of Fx, that’s probably not happening as much as you think, unless it’s something publicly announced in changelogs. Your distribution maintainers aren’t reviewing every line of code changes between Fx releases, ESR or not.
I think there is some merit to it, at least as far as dubious features with auto opt-in go. It's not so much that the distro will save you from a hostile firefox or chromium. Rather, it'll give you the modicum of dignity by preventing you from being enrolled in these. In the best case, it prevents upstream from further rolling out such features due to the pushback. In the worst case, you get a small heads up about what's coming down the pipe inevitably anyway and you can plan accordingly.
> Your distribution maintainers aren’t reviewing every line of code changes between Fx releases, ESR or not.
Actually, Redhat and SuSE guys are active in the development, especially the linux-specific functionality. However, when they package it, they don't have to follow Mozilla's agenda.
> You don’t consider Mozilla trustworthy so you’ll use their browser but not if it’s packaged by them?
I have to use a web browser.
> For something the size of Fx, that’s probably not happening as much as you think, unless it’s something publicly announced in changelogs. Your distribution maintainers aren’t reviewing every line of code changes between Fx releases, ESR or not.
Reading and respoding to the changelogs is substantially better than no review.
No you don't, I suggest getting a different career outside the IT department, if it really bothers you that much. No reason to take the path of most resistance with something that makes you unhappy.
>Reading and respoding to the changelogs is substantially better than no review.
No, not really. The reason this stuff with snap is happening to begin with is because distro maintainers don't have the resources to maintain a ton of patches on top of a giant browser that releases every month, even if they knew there was something objectionable in the changelog there may not be anything they can do about it in a reasonable amount of time.
Just posting in agreement. I'd like my Firefox direct from Mozilla, without being molested by some rando 'maintainer' who could do things like null-out SSL code or include their personal "standard violating" config (and has). As ultra-paranoid as some people on HN are, they suddenly weirdly trusting of mostly unaccountable volunteers. Backdooring some distro firefox would be a lot easier than backdooring your CPU.
>You don’t consider Mozilla trustworthy so you’ll use their browser but not if it’s packaged by them?
Yea, I think this is silly.
Apps have the power to update themselves out-of-band from the package manager, so, even if you only install it via the package manager, it can do whatever it wants while short-circuiting the maintainers' oversight.
Well, not directly: they'd need root to overwrite /usr/bin/firefox, which it wouldn't normally (hopefully) run as.
They could have latent malicious code which gets packaged and that could download a payload and execute that (or already contains the attack). But a program without such a pre-existing ability won't be able to update itself to a version that does.
> At least when it's packaged by the distribution someone has reviewed the changes and can flag up and disable any nonsense that mozilla is adding.
Unfortunately, Mozilla has enough power that AFAIK they've pretty much run roughshod over the distributions. Pretty much the only software I know of that can do that. It's mostly through enforcing their trademark.
If you know of a mainstream Linux distribution where the maintainers actually care enough to patch Firefox to remove all advertisements (including Pocket), sponsorships, and other by-default telemetry, I would love to hear about it and would consider switching to such a distribution for that reason alone. (Not because I'm incapable of patching Firefox myself or using LibreWolf, but because this shows that the maintainers care and have the correct priorities.)
Are distributions more trustworthy here? Mint for example has in the past fiddled with Firefox's default search to IMO anyways to an annoying degree that I stopped using it.
Oh cool, I guess this headline saved me from the frustration of upgrading any of my computers to ubuntu 22.04. Bad enough chrome was in a snap in the last (couple?) if firefox is now too I have to assume the whole OS is basically unusable if you force snap off.
Give the latest Fedora a spin! After 10 years of Arch I have been pleasantly suprised by the completeness and performance of Fedora since version 34. Version 36 is set to be released in a couple of days.
Given that the main contention with Snap is the first-launch performance, a viable alternative is Flatpak. I run nearly everything from it.
The bizarre thing about the Snap performance issue is that it isn't present on other distros. I have heard that Snap is really, uh, snappy on Arch (although I am seriously not bothered to try it myself).
It loads however a lot more, either a Gnome or KDE base, and it shows. I've tested a few apps with their tarball/rpm versions vs Flatpak, and the latter takes seconds more, consistently. Pretty fast NVME drive too.
Wow, this kind of article shouldn't be a thing in 2022. It reminds me of the old days of Linux when you had to hack xorg.conf to get your second monitor to work -- but now it's a hack to get your web browser to work!
I hate how Ubuntu is pushing snap. There is only disadvantages installing Firefox from snap. I am glad I am using Linux Mint which shields me from this insanity for now.
Solutions like flatpack/snap/appimage are great (though I like snap the least) but they are for extra stuff. As much as possible should be handled by the native package manager.
I don't think they're great at all. Maybe great for devs, not for the end user. It makes it much harder to update a vulnerable version of OpenSSL for example in all your apps. Because every maintainer needs to do update the included version in their snap. In the apt system you just update the library and that's it, everything's fixed.
Also, the dynamic loader has much better performance if it doesn't need to juggle different versions. I can see the benefit for some packages that are super complex or have really special requirements. But not for every little thing like Ubuntu is doing.
But Canonical doesn't own apt. They own snap and the store can be run only by them. I think they just try to insert their own IP into mainstream linux so that they can eventually charge other distros and/or commercial customers for access. I think they're just looking for ways to monetise. Inserting your IP into the mainstream is a common way to do that when it comes to FOSS. It worked for RedHat though they are a lot more successful at it. I hate this kind of monetisation, though I wouldn't mind paying for a distro if it were made with my interests in mind. Ubuntu is going the complete opposite way though. They're serving their own commercial interests first.
It's not working out at all though because everyone hates snap and even ubuntu-based distros remove it. I hope they will give up soon, just the way they've given up on Unity, UpStart, Mir and Ubuntu Mobile.
I find them horrible from the dev side too. Canonical gate keeps you from publishing your app. Their patches to system components to make snaps work break stuff. Their stack to build snaps like multipassd is buggy beyond belief and adds another daemon i never asked for.
As many problems as AppImages have, they're probably the least insane solution. And AppImages are quite insane, so that sais something about linux packaging.
Not directly, but having a lot of IP in the game makes a company much more interesting for investment and acquisition. It's viewed as an asset even though it's open source. RedHat has successfully mainstreamed some of their IP like systemd which is now practically everywhere, where Canonical has tried the same with UpStart in this case and failed.
This makes RedHat somewhat of an 'authority' on Linux. And indirectly, they have been making it harder to get official versions without paying, like what they did with CentOS.
I just don't get why they keep doubling down on snaps. Most people really, really hate them. Most people find them slow. They used to just reply their testing doesn't find it slow, too bad so sad. I say 'used to' because I gave up long ago so haven't bothered checking.
Likely the idea is to let upstream to package once and ship it on all supported platforms. This way there is no constant support/packaging required from distro itself.
As to why snap format specifically, that’s probably allows them to make changes as needed without asking anyone.
Right, but if in the process you take your great code and turn it into a crappy deliverable, that's on you. You don't get praise for taking serviceable software and bogging it down while locking out end users on an open source platform. You don't give a f*k. We get it.
Further, if you are tunnel-vision focused on profit, remember that if you lose your end users, you lose your only means to eventual income.
There is now a very nice summary comment from worik elsewhere in the thread, but basically end-users are no longer the same from Canonical’s perspective and so it’s probably wise to thank them for good things they did and move on.
These companies need to be reminded that users are the sina qua non condition for any customer whatsoever, and that their disinterested to hostile attitude towards users is a poison pill for them. "Users aren't the customer" is tired corporate-speak for "I want to be an a*hole", and needs to die.
As to Canonical, the only reason I use FF anyways is because it is the lesser evil. They are far from stellar with their constant attempts to inject invasive monetizers into the browser.
> Since the package comes from a PPA unattended-upgrades will not upgrade it automatically, unless you enable this origin
For anyone still on 18.04 or 20.04 and not yet ready to upgrade or move off of ubuntu, you can add firefox to the "Unattended-Upgrade::Package-Blacklist" list in /etc/apt/apt.conf.d/50unattended-upgrades
I used to love ubuntu and have been a xubuntu promoter between friends for quite a while, but now I am considering moving away from it, given that they are more and more aggressively pushing people to use their halfbaked binary store solution, which sounds insane, given we already have a pretty "apt" package manager which can install and solve a dependency graph just fine.
People that moved away from Ubuntu because of the same crap, what are you using now?
What other distros can I use without getting too crazy on configuring shit? My use case is booting a Linux box to develop Python/Rust apps, maybe a docker/docker compose in there and that's it.
Don't get me wrong, I love what distros like Nix are doing, but I don't have 16 years anymore and all the free time in the world to tweak my environment to oblivion. I just want to boot an environment which is somewhat standard, run Pycharm, VSCode, and code my shit on.
The core of my system is now Debian Stable. For the handful of packages that I want to be newer, I either pull from Debian backports or backport the Debian Unstable package myself (just a simple rebuild in most cases).
Flatpak is my last resort for one or two apps that aren't yet available in Debian. Since I don't trust the flathub/pypi/npm "accept software from anyone" model, I try to mitigate the additional risk with a few extra steps: I'm choosy about which flatpaks I'm willing to use, I scrutinize the permissions they try to grant themselves, and I install them only after rebuilding them myself with any unwanted components or overreaching permissions stripped out. (Flatpak's permissions model is broken in my view, but I think it could be fixed, and it is at least a starting place for working toward decent app isolation.)
I'll miss some of Ubuntu's Launchpad services (free multi-architecture build farm, free package hosting, user-friendly bug tracker) but I don't value those conveniences as much as I value the benefits of traditional packaging for my core tools. Overall, I'm happy with the switch.
I moved to using Fedora and its been pretty solid. Recently started using the Silverblue variant which is pretty well suited to do things in containers due to the readonly nature of its root filesystem. There are some aspects that are annoying (like installing software) but that not something I do frequently so its fine.
And if you're not a GNOME fan, there's a KDE version of Silverblue called Kinoite or something similar that's basically the same thing but with KDE instead of GNOME.
My reasons weren't necessarily because of Snaps because Fedora has Flatpaks which are the same useless crap from my perspective. It was mostly just because I wanted things to be closer to current releases.
(I personally went radical and run Void Linux. It has no systemd, basically every package is just built from upstream sources nightly, etc. Surprisingly, it's about as fiddly as a Debian box.)
The Valve Steam Deck, which runs a fork of Arch Linux, is, I hope, going to be the final decider in the sandbox format war. It comes preconfigured to run Flatpaks, and while you can install stuff via Arch's Pacman, anything installed that way is erased whenever there's a software update, while Flatpaks persist.
So it's in the user's interest to use Flatpaks, and on mine, the Flatpak of RetroArch, as an example, works perfectly with zero extra configuration.
They don't specify, but it seems frequent enough in my experience. Here is what the Web site says:
"LibreWolf is always built from the latest Firefox stable source, for up-to-date security and features along with stability."
> How does it fight against the duopoly of Google and Apple on the web?
It uses Gecko rather than Blink or WebKit if that's what your question is asking. It's just standard Firefox with privacy tweaks and patches applied out of the box.
> It uses Gecko rather than Blink or WebKit if that's what your question is asking.
By not using Firefox, you remove the funds from the WebKit development. And it costs millions. If LibreWolf doesn't present itself as Firefox, it also decreases the visible Firefox usage, helping the duopoly.
What's wrong with their mobile app's quality and extensions? FF is essentially the only good browser on Android AFAIK, plus it supports extensions on Android.
It's nice that we can fork these things, but I don't see the point for browsers, where even well-paid teams like Google's can't avoid regular vulnerabilities.
Docker, and I think it is the one most dumb af. You are fxxking sandbox another sandbox system mean to control the data storage and resources assignment from the rest of system resources?? How do I suppose to use it? It waste me 30 minutes wondering why dir mounting didn't work and it turns out it is packed into snap package.
It never hit me before now, but I just realized that "constantly upgrading software" is only a thing because corporations are cheap and impatient.
Web browsers need to be constantly upgraded mostly because they need constant feature add-ons. They need constant feature add-ons because they want the browser to be able to render all the features of native apps with JavaScript/HTML/CSS, but they can't possibly develop every feature all at once. So they drip, drip, drip out the features. They also can't thoroughly test all the features ahead of time (permutations would require hundreds of millions, if not billions, of tests per release) so they kick the releases out to beta users and collect bug and crash reports, and fix enough of them to call it stable and then kick a release out.
Imagine if cars worked like that. "We know you're driving on the highway, but we need to reboot your car because we have a new feature (radio shuffle mode!)"
Browsers need to be constantly upgraded because of security vulnerabilities being found, disclosed and fixed as a steady, busy stream. To just keep up with features you could have at least an order of magnitude slower pace of updates.
I see frequently on HN this idea that big company behind said web browser can simply throw more devs at it, adding things and features (useful or not) and simply drown any competitors with churn of changes. But you still want security patches too, so you have to install and keep up to date with upstream. Is this also causing relentless update cycle? I think so.
On my dev box, it's chromium, golang, ripgrep, restic, lxd, flutter.
I don't really notice the startups for the rest (although I get irritated when lxd auto updates and restarts my containers), but chromium does palpably take several seconds to load vs firefox .deb
I know. This screwed me over. I had an lxd cluster that was working very nicely. Then 1 of the 5 cluster members failed to upgrade when snap forced an upgrade and it put the whole cluster in a degraded state.
I rather feel like we are making things more complicated than needed in recent years. In ubuntu 14.04 8 years ago firefox plus treestyle tabs and adblock plus made a nice combination. Firefox was installed by default and one could go to the addons menu and in about 30 seconds install those 2 and have right off a decent experience.
Unattended-upgrades wasn't part of the default ubuntu install and everything updated at once. When you told it to.
Now to have the same experience you need to understand the difference between snap and apt and why you would want one vs the other. You need to understand ppas. You need to know how ppas interact with unattended-upgrades. You need to understand config files are in etc. You need to know how config file directories work. You need to know how to pin a package. It appears but I'm not sure that you need to know the difference between purge and remove.
Now if you want treestyle tabs to actually hide top tabs you need to figure out the weirdness of firefox profile dirs where its in ~/.mozilla/firefox/my-cat-walked-right-over-my-keyboard-and-had-a-fight-with-my-other-cat. Create a folder called chrome and inside it userChrome.css and either understand css or just blindly paste in some css someone else provided.
Then you need to open up about:config and change an arcane setting to make the above actually do something.
90% of that is actually useful understandings. Hey its not like css is only for themeing firefox and knowing about:config exists exposes useless things out of scope of normal configuration but in no universe should I wish my browser wasn't half as fast as windows and I wish tabs were on the side lead to that exiting 3 hour tour 1.
We can start having the professor run this ship instead of Gilligan any time now.
Firefox should be a Debian package by default. Installing a package from a PPA shouldn't bear on how its updated. Installing should be via a singular cli. If snap is to be integrated it should be an argument to that cli even if its not apt. Explicitly telling it to install the deb version should simply cause it to prefer that version thereafter. Absolutely none of this should require touching a config file in /etc.
On the firefox they should have found a way for an addon to hide the tabs a while ago and if the user explicitly drops a css file in their profile directory it shouldn't be gated by a setting in about:config. Meanwhile your firefox profile should be something like ~/.config/firefox/default-profile
> Now if you want treestyle tabs to actually hide top tabs you need to figure out the weirdness of firefox profile dirs where its in ~/.mozilla/firefox/my-cat-walked-right-over-my-keyboard-and-had-a-fight-with-my-other-cat. Create a folder called chrome and inside it userChrome.css and either understand css or just blindly paste in some css someone else provided.
Also it's not just "understand CSS" - if you want to do it yourself you have to enable a special firefox debug mode to be able to inspect its UI and find the right IDs/etc.
As a recovering long-time Ubuntu user, I encourage everyone to strongly think about whether they need to stick with it. If you need stability, there are plenty of RHEL offshots (e.g. Centos, whatever became of "old Centos" that was relaunched elsewhere), and my personal recommendation as a "drop-in"-ish replacement: OpenSUSE Tumbleweed. It's a rolling distro that has the heck tested out of it by SUSE, and I've been rolling forward an install on my laptop for years without any issue. No more worrying about whether I need to dedicate some time to clean-install my Ubuntu workstation after the dist-upgrade inevitably doesn't work correctly...
I thought I needed that, because I quickly went back to the repo .deb version when they initially switched to the snap version, but actually the snap version in 22.04 works pretty well for me, I still have not found a broken usecase.
It starts up way slower. I didn't notice at first but then I installed the deb version trying to troubleshoot other issues, it didn't solve those problems, but I immediately noticed how much faster it starts, even with the same settings and extensions installed as before.
Yes it did previously (when it was forced the 1st time with...20.10 I guess?) but on 22.04 at least the feeling is basically the same that with the .deb I had on 21.10. I upgraded a month ago when it was still in beta so my memory might be already tricking me.
I have been pushing Ubuntu on the server, even in places where CentOS was more popular and I was pushing it in the container world as well. When they started forcing snaps, I could no longer use it for containers, therefore I started abandoning it for servers as well in favour of Debian.
Snaps are horrible for containers because of their moving parts and I don't believe that they are any good for the server either because last time I checked: you could not have your private snap repository.
Who packages it and how do you know you can trust them?
Fun fact: the Jetbrains flatpak images are _not_ packages by Jetbrains. If you ask Jetbrains about them, they will tell you it's a random third party (/enthusiatic community volunteer) who packaged them up. Flatpak is a shitshow and should be avoided until and only if Flathub gets better control over packaging.
No, they are not from the original vendors... but also the original vendors were not interested in providing flatpaks themselves, so the community stepped in.
I have yet to see any volunteer to refuse handing off maintenance of the flatpak package to upstream.
If they listened to your advice, there would be no flathub at all.
There should be no flathub under this setup - it's bad for security, and wastes community energy. The useful aspect of application packages is to give vendors a path to get updates to users out of band from distro updates. If vendors aren't going to use it, then leave the packaging to the distros.
The value prop for me is a stable runtime environment that’s reproducible. For example, in the Linux ecosystem, you need to use either the same exact version or a future version of glibc. Having multiple glibc versions is not possible without extreme headaches. It could be solved with static builds but there are cases when you cannot do that.
Nix has it's cake and eats it too. You can very easily store multiple versions of glibc (automatically, as a matter of fact) and it will dynamically link the different versions to the applications that require it. All of that happens without the overhead of a sandbox, and runs on everything from Denuvan to Void to Arch to Ubuntu to MacOS.
It's a big archievement that the snap sandboxing has gotten seamless enough to support this. Looking forward to having more sandboxed apps. But the snap system needs more transparency and auditability so we can know what goes into them, like the ppa system does has.
I wish there was a distro that packaged Firefox with all of the must have extensions already installed (especially uBlock and Sideberry - I don't understand how anyone could use a browser with ads or without side tabs).
The most visible difference, even to people who don't care about software freedom or technical differences, is that the Snap version of Firefox takes a while to start after clicking on the icon, while other versions (including the Flatpak-packaged version) are zippy to start.
