[HN Gopher] Firefox on Ubuntu 22.04 from .deb (not from snap)
___________________________________________________________________
Firefox on Ubuntu 22.04 from .deb (not from snap)
Author : zdw
Score : 118 points
Date : 2022-04-23 20:51 UTC (2 hours ago)
(HTM) web link (balintreczey.hu)
(TXT) w3m dump (balintreczey.hu)
| lin83 wrote:
| 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.
|
| [1] https://launchpad.net/~mozillateam/+archive/ubuntu/ppa
| ailtonbsj_ wrote:
| I already had done this where I work. We are using a own build
| version of Xubuntu.
|
| https://github.com/winunix/xubuntu-winunix
| mise_en_place wrote:
| I just use chromium from flatpak, never had any issues with it. I
| can also switch to Ungoogled Chromium if I wanted to.
| smallerfish wrote:
| 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.
| tedunangst wrote:
| Why not use the tgz file directly?
| sp332 wrote:
| Dependency checking?
| tedunangst wrote:
| I guess. It's not hard to figure out what it needs and
| install them, though. It's what I do on my debuntu systems.
| auraham wrote:
| Wonder what other applications are from snap by default.
| GekkePrutser wrote:
| A ton... Even basic console apps with nearly no dependencies
| are being snapped now. They are going totally crazy.
|
| Seriously, why does htop need to be a snap??
| hypothesis wrote:
| Chromium I think. Basically anything that is a moving target.
| 0xbadcafebee wrote:
| 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!)"
| suprjami wrote:
| I've been using the Linux Mint Chromium deb for ages with
| similar tricks to this post.
|
| The Mint Firefox package is more difficult, it needs an
| override package which breaks Ubuntu, but Chromium is
| standalone.
| xarope wrote:
| 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
| asddubs wrote:
| the webkit based midori browser too
| dtparr wrote:
| lxd has only been available by snap in ubuntu for a couple
| major versions.
| depingus wrote:
| You can install LXD on Alpine without snap and it works
| great.
| Thaxll wrote:
| Since Firefox can auto update itself you can just download the
| tar.gz directly.
|
| https://www.mozilla.org/en-US/firefox/all/#product-desktop-r...
| jcastro wrote:
| I get people don't like snaps but adding a third-party repository
| with root access to your computer is not doing anyone any favors.
|
| Even if it is run by a trusted community member a PPA will never
| have the guarantees of the packages in the distro.
| zamalek wrote:
| 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).
| wheelerof4te wrote:
| This is why I love and still use Debian.
|
| 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.
| okasaki wrote:
| 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.
| daenney wrote:
| 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.
| bubblethink wrote:
| 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.
| okasaki wrote:
| > 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.
| throwaway82652 wrote:
| >I have to use a web browser.
|
| 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.
| vetinari wrote:
| > You don't consider Mozilla trustworthy so you'll use their
| browser but not if it's packaged by them?
|
| Exactly. The distribution maintainers are reviewers, who can
| remove the unwanted parts: https://pagure.io/fesco/issue/1518
|
| > 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.
| shrimp_emoji wrote:
| > _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.
| plonk wrote:
| > Apps have the power to update themselves out-of-band from
| the package manager
|
| Isn't that disabled in Ubuntu's Firefox APT package?
| adhesive_wombat wrote:
| 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.
| anothernewdude wrote:
| Not when Mozilla will just disable things like ublock origin
| and umatrix, without telling the user.
|
| browsing the web is *dangerous* without them.
| IceWreck wrote:
| The do change the defaults and enable/disable features during
| compile time.
|
| This is very different than going through every line of code
| and patching something they dont like.
|
| I'm not OP, but I too consider Firefox published by my
| distribution (Fedora) to be more trustworthy than Mozilla's
| official distribution channel.
| goosedragons wrote:
| 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.
|
| Knife can go both ways here.
| worik wrote:
| 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
| sgt wrote:
| If geeks and their desktops are out, the only thing remaining
| for Ubuntu is server and cloud. That is okay, actually, but a
| bit sad.
| nvrspyx wrote:
| I mean, that's where large majority of their efforts have
| been for the last couple of years, at least. It's self-
| inflicted.
| pjmlp wrote:
| There is no money in desktop, it is self inflicted by the
| Linux community themselves.
| pjmlp wrote:
| Ubuntu has long realised that Red-Hat was right in that
| regard.
| ekimekim wrote:
| 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.
| Andys wrote:
| Except with snaps, its like using a desktop OS on a server,
| which is not really OK.
| GekkePrutser wrote:
| 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.
| plorg wrote:
| 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.
| fuckcensorship wrote:
| I prefer to just use LibreWolf [1] instead.
|
| [1]: https://librewolf.net/
| plonk wrote:
| 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.
| fsflover wrote:
| How fast does it get the security updates? How does it fight
| against the duopoly of Google and Apple on the web?
| Quarrel-Cactus wrote:
| > How fast does it get the security updates?
|
| 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.
| fsflover wrote:
| > 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.
| tomrod wrote:
| I'm okay with this. Firefox makes enough money without my
| marginal contribution further enriching Mozilla execs,
| your FOMO/FUD notwithstanding.
|
| I used Firefox until they lost site of their core target,
| and killed their mobile app's quality and extensions.
| Kwpolska wrote:
| 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.
| GekkePrutser wrote:
| > 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.
| adhesive_wombat wrote:
| On Arch, it's 50:50 on if it will prompt for a restart, or
| just start having crashing tabs.
| riquito wrote:
| I update Firefox on Fedora and nothing happens until I manually
| restart it
| Seattle3503 wrote:
| > 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.
| yoavm wrote:
| 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.
| ghostly_s wrote:
| Mine prompts me to restart when I load a new page, no option
| to postpone as fat as I've seen.
| ameminator wrote:
| I hate snap. I hate how they are being pushed by Ubuntu. Here's
| the link I followed to completely remove snap from my Ubuntu
| installation: https://askubuntu.com/questions/1280707/how-to-
| uninstall-sna...
| cardanome wrote:
| 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.
| [deleted]
| GekkePrutser wrote:
| 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.
| angus-prune wrote:
| What is this startegy of monetising upstream contributions
| that you mention redhat having done?
|
| This isn't something I've heard of before.
| lawl wrote:
| > Maybe great for devs
|
| 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.
| timbit42 wrote:
| I switched to Linux Mint.
| silisili wrote:
| 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.
| hypothesis wrote:
| Are those people paying customers?
|
| 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.
| sgc wrote:
| 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.
| hypothesis wrote:
| I'm just acknowledging the reality.
|
| 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.
| carlsborg wrote:
| The .tgz has never failed me across various distros and time.
| darkwater wrote:
| 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.
| kgwxd wrote:
| 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.
| darkwater wrote:
| 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.
| g105b wrote:
| 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!
| rubyist5eva wrote:
| I've seen enough people putting off the chrome zero day updates
| to understand why Mozilla is resorting to a snap package for
| updates.
| squarefoot wrote:
| 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.
| Seattle3503 wrote:
| My experience with Snap pqckages hasn't been great. For example
| the Snap version of 1password couldn't find my Yubikey, but the
| deb worked just fine.
| nu11ptr wrote:
| 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.
| rubyist5eva wrote:
| The distro (canonical/Ubuntu) didn't do it: Mozilla did.
| ghostly_s wrote:
| Source? Why would they do so only on Ubuntu?
| rubyist5eva wrote:
| My guess is that Ubuntu (and derivatives) is the only
| major distribution that installs snapd by default.
|
| > Source?
|
| https://discourse.ubuntu.com/t/feature-freeze-exception-
| seed...
| kd913 wrote:
| https://www.omgubuntu.co.uk/2021/09/ubuntu-makes-firefox-
| sna...
|
| The reason probably being that for Canonical and Mozilla,
| it is a pain to support/backport multiple ubuntu
| versions, so why not just support 1 build.
|
| It makes it simpler for them to release as it's directly
| integrated in their build system.
|
| Considering how small a percentage linux users are, it
| isn't an illogical decision.
| GekkePrutser wrote:
| 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.
| kyrofa wrote:
| Ding ding!
| rubyist5eva wrote:
| 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.
| gnufx wrote:
| Fedora, a volunteer project, currently has packages for
| four different current and future releases.
| rubyist5eva wrote:
| 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.
| vetinari wrote:
| Fedora build is slightly different that the upstream one;
| in a way that many FOSS users appreciate:
| https://pagure.io/fesco/issue/1518
|
| Additionally, it is being done by the same folks who
| drive development of linux-specific features (like
| wayland support or video decoding acceleration) anyway.
| berkut wrote:
| Wasn't it Mozilla who wanted this general change, so they could
| provide more up-to-date versions more easily, and more
| directly?
| kyrofa wrote:
| That's Canonical's PR line. As someone working at Canonical
| during the discussions, I can tell you that's not true.
| colordrops wrote:
| 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.
| madeofpalk wrote:
| Ubuntu also gives you full control over how you want things
| installed also, right?
|
| You're not forced into one method?
| umvi wrote:
| Nix as in the Linux distro or package manager?
| anothernewdude wrote:
| Canonical love making bizarre decisions like this. Just look at
| Unity and Mir.
| Darmody wrote:
| Unity made sense, snap doesn't.
| GekkePrutser wrote:
| Yes unity wasn't bad and it wasn't shoved down your throat.
| resoluteteeth wrote:
| > 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.
|
| It's a container not a vm so I don't think it would help if a
| package can't be run using the stock kernel.
___________________________________________________________________
(page generated 2022-04-23 23:00 UTC)