[HN Gopher] Improving Firefox stability on Linux
___________________________________________________________________
Improving Firefox stability on Linux
Author : TangerineDream
Score : 384 points
Date : 2021-05-19 14:48 UTC (8 hours ago)
(HTM) web link (hacks.mozilla.org)
(TXT) w3m dump (hacks.mozilla.org)
| sloshnmosh wrote:
| Strange. I've never had an issue with Firefox crashing on Linux.
|
| Firefox on Android is a different matter and is unusable on some
| devices.
| justaguy88 wrote:
| Does firefox provide an official appimage?
| Darmody wrote:
| Now it would be cool if they didn't break the number inputs with
| Bootstrap's form-control class.
|
| There's something wrong with the padding and the up and down
| arrows simply don't work.
|
| I think it's already fixed on beta/nightly but this can't happen.
| We can't wait months to have our inputs working again.
|
| Also there's another bug introduced a couple versions ago. If you
| select some text with you mouse and a the next line, when you
| open a new tab with the middle button it'll paste the whole thing
| you selected in the direction bar.
|
| I usually select text or code when I read it and every time I
| open a new tab with my mouse, boom. I have to delete everything,
| or select a single word somewhere and close that tab to reopen a
| new one. And if I'm not looking and start typing I end submitting
| a long text to duckduckgo.
| johnchristopher wrote:
| It's been a long time since I have seen a firefox crash on Linux.
|
| What's killing me is the memory leak that just renders the whole
| computer unusable and almost frozen. Almost because if I can grab
| a terminal and killall firefox then I get the machine back.
|
| https://bugzilla.redhat.com/show_bug.cgi?id=1597028 something
| like that, not sure about the root cause. But I don't let imgur
| tab with running vid opened for too long now.
| TacticalCoder wrote:
| Same here... I very rarely see Firefox crashing or a tab
| crashing on Linux. It happens once in a very rare while that I
| see a tab crashing but the whole browser never crashes.
|
| Memory leaks can be bad indeed and here are two tricks that
| work fine for me: either run Firefox inside a Docker
| container... Docker container on which I put CPU and RAM quota.
| It's IMO way easier than try to put resources quota directly on
| Firefox. The other one: Firefox has zero issues reopening all
| my tabs, so I simply kill it from the terminal when I see that
| it's going wild on memory. Now I've got 16 GB and Firefox
| rarely eats it all and it's usually not sudden: it's a slow
| bleed over the course of a few days... So when I get to
| something like 10 GB of memory used by just one Firefox
| instances (I typically run several Firefox instances, from
| different user accounts) , I just kill it and restart it, while
| choosing to reopening all the tabs (usually tens of tabs).
|
| I'm sure there are other methods too but this works fine in my
| case so I haven't looked much into it.
| zeotroph wrote:
| I also notice the mem leaks, but I can usually leave my
| Firefox process running until there is the next update to
| install.
|
| What works for me is having the `about:memory` tab open and
| clicking on "Minimize memory usage" at the end of the day
| when I suspend the machine. And, I have a lot of tabs and
| windows open, strewn over various virtual desktops. Though
| most tabs are not loaded but more expensive bookmarks, but I
| have no add-on which actively unloads tabs.
| timbit42 wrote:
| Have you tried the "Auto Tab Discard" addon?
| jeroenhd wrote:
| I've been encountering a similar memory leak on Windows, so I
| don't know if it's really related to Linux.
|
| What I do know is that the way Linux GUI distros deal with low
| memory situations is absolutely garbage. The new systemd OOM
| daemon that's shipping with systemd 248 will hopefully improve
| this situation, but for now I'm left running nohang[1] on my
| dev machine, where I'm consistently running out of RAM
| (IntelliJ + tons of Java frameworks + huge React code base + a
| web browser all take up way too much space!). Enabling zRAM
| also seems to work, but I haven't measured the effectiveness of
| that yet. On my home PC with double the ram (32GiB) everything
| runs smoothly, but the way Linux on the desktop deals with OOM
| situations is still atrocious. Besides, none of these tools
| should be consuming such ungodly amounts of RAM anyway.
|
| For server situations, Linux handles OOMs better than Windows,
| IMO. On desktop, the same strategy just doesn't work and only
| makes working on it more painful.
|
| [1]: https://github.com/hakavlad/nohang
| Barrin92 wrote:
| > _" When it comes to Linux things work differently than on other
| platforms: most of our users do not install our builds, they
| install the Firefox version that comes packaged for their
| favourite distribution.
|
| This posed a significant problem when dealing with stability
| issues on Linux: for the majority of our crash reports, we
| couldn't produce high-quality stack traces because we didn't have
| the required symbol information. The Firefox builds that
| submitted the reports weren't done by us. To make matters worse,
| Firefox depends on a number of third-party packages (such as GTK,
| Mesa, FFmpeg, SQLite, etc.). We wouldn't get good stack traces if
| a crash occurred in one of these packages instead of Firefox
| itself because we didn't have symbols for them either.
|
| To address this issue, we started scraping debug information for
| Firefox builds and their dependencies from the package
| repositories of multiple distributions: Arch, Debian, Fedora,
| OpenSUSE and Ubuntu. Since every distribution does things a
| little bit differently, we had to write distro-specific scripts
| that would go through the list of packages in their repositories
| and find the associated debug information_"
|
| This is why I'm glad that a lot of Linux software is moving
| towards distro agnostic containerized applications maintained by
| developers. Linux already does not have a large market share and
| if you have to deal with a dozen distro-specific quirks it seems
| hardly economical.
| timbit42 wrote:
| Snap, Flatpak and AppImage all suck! Fix this first.
| bogwog wrote:
| I don't know what you're talking about, AppImage is great!
| [deleted]
| AnIdiotOnTheNet wrote:
| Unfortunately they are solutions designed for a platform and
| ecosystem with a lot of suck built-in. For my money, AppImage
| has the most sane approach, but without support from the
| wider community they are still a bit of a pain.
| _jal wrote:
| > This is why I'm glad that a lot of Linux software is moving
| towards distro agnostic containerized applications
|
| To me, it entirely depends on the specific packaging job, not
| even who is doing it. Entirely too often, they ignore distro
| convention, and can introduce bugs and other security issues
| through ignorance, laziness or mistake.
|
| Long term, flatpack and its ilk will devalue distro differences
| and put pressure on uniformity. Whether or not you consider
| this is a good thing may depend on your opinion of/relationship
| to RedHat/IBM.
|
| For me, if it isn't in the Debian repos, I'm probably going to
| ignore it.
| deckard1 wrote:
| I'm not holding my breath. The Linux Standard Base is 20 years
| old now. That was supposed to get us there. If Canonical and
| Red Hat cared, they'd probably go through the Linux Foundation
| instead of creating competitors to AppImage. Speaking of,
| AppImage is from 2004. So... see you guys in 20 more years.
| diegocg wrote:
| This will stop being a problem when/if all distros start using
| symbol servers
| 2OEH8eoCRo0 wrote:
| This is great! Looks a lot like Fedoras crash statistics:
|
| https://retrace.fedoraproject.org/faf/summary/
| maweki wrote:
| Since I've upgraded to Fedora 34 (been on Walyand before though)
| Firefox disconnects from Wayland and crashes whenever there's a
| bit of IO going on.
|
| Haven't had a tab crash in quite some time though.
| gsvelto wrote:
| I think I started scraping symbols from Fedora 34 builds on
| Monday, we probably haven't looked at those crashes yet.
| VadimPR wrote:
| One of the issues of running an open-source C++ project is the
| difficulty in obtaining stack traces from users - hoping to re-
| use the work that Mozilla did here for Firefox, so thanks team
| for paving the path there for others.
| gsvelto wrote:
| You're very welcome! If you're interested in the topic we've
| got a working group [1] and a very active channel on
| chat.mozilla.org [2]. Besides the actual stability work we've
| also been busy either rewriting some of this tooling in Rust
| (see [3] and [4]) as well as contributing to Sentry's excellent
| symbolic crate which we leverage during symbol extraction.
|
| [1] https://wiki.mozilla.org/Data/WorkingGroups/CrashReporting
| [2] https://chat.mozilla.org/#/room/#crashreporting:mozilla.org
| [3] https://github.com/mozilla/dump_syms/ [4]
| https://github.com/luser/rust-minidump
| alpaca128 wrote:
| The only issue I have with Firefox(and a regular one) is that its
| UI seemingly cannot handle tiling window managers. Unless I
| manually resize each Firefox window after startup the UI won't
| properly adapt to the actual window size.
|
| But that is really a minor nitpick compared to the tons of issues
| I have with other browsers; Firefox runs insanely stable, and
| easily handles a large number of tabs.
| preek wrote:
| I think that's specific to your setup. I run Debian SID with i3
| as tiling window manager and FF is the primary browser I use.
| As a web dev, I have quite a few instances of FF open all the
| time.
|
| I can't recall an issue with FF behaving badly when tiled. So,
| it's unlikely that FF generally doesn't work with a tiling WM.
| eikenberry wrote:
| That might be a bug in your window manager. Window resizes,
| whether automatic or manual, should send the same notifications
| to the software about the need for a redraw.
| alpaca128 wrote:
| I doubt it. It happens in every tiling window manager I've
| used, and only ever with Firefox. Also I've seen the same
| issue mentioned once by a user of a normal desktop
| environment, who had to toggle fullscreen in Firefox to get
| it to update the UI after startup.
|
| But it's just another visual bug users of tiling WMs have to
| deal with. Many programs handle this much worse, either
| crashing instantly because the WM doesn't let them have their
| favorite hardcoded window size, or becoming unusable from
| epilepsy-inducing glitches. Before I went down that path I'd
| have never guessed UIs(both on desktop and on websites) are
| so damn flimsy.
| zamadatix wrote:
| FWIW I've never seen this issue on Sway (can't say for
| others as I haven't used them).
| ComputerGuru wrote:
| If anyone from Mozilla is reading this: the thumbnails are
| unreadable but can't be clicked to open the full-size image in a
| lightbox or new tab.
| amenod wrote:
| Great work Mozilla! I can't remember the last time Firefox
| crashed for me (Linux). I am using the upstream version though,
| as I prefer security fixes in my browser to be applied as soon as
| possible.
| smoldesu wrote:
| Firefox is _great_ on Linux. It kinda whoops Chrome 's ass for
| what it provides (though Chrome on Linux is a nice experience),
| and Mozilla has consistently been one of the most charitable
| organizations towards the Linux foundation. Here's to another
| decade of Firefox and an open web!
| rurp wrote:
| This is great. I've done my fair share of griping about Firefox's
| many UI and functional regressions, but these types of stability
| improvments are very welcome and much appreciated.
| mousepilot wrote:
| I use firefox but haven't had sound since they dropped alsa
| support. Occasionally I'll run palemoon to get sound but while I
| like the browser, its not totally stable.
|
| Probably need to try chromium.
| mousepilot wrote:
| lol awesome, not only do I have the misfortune of no sound,
| people here want to rub it in with downvotes for mentioning it.
| thanks guys
| nix0n wrote:
| We're just jealous you don't have to listen to ads :)
| simias wrote:
| I've had the same issue and finally bit the bullet and
| installed pulseaudio. I was semi-pleasantly surprised: it
| actually works most of the time on my computer these days.
|
| I still have to mess with a billion things when I want to do
| anything more complicated than basic music playback, but for
| that it sorta works which is already pretty great by Linux
| audio standards.
| globular-toast wrote:
| I run a minimal Gentoo system and it includes pulseaudio. It
| just works. No problems with it whatsoever. But on Ubuntu
| work machine it can be a pain. I don't know why this is.
| kaba0 wrote:
| I mean, the days are long gone when pulseaudio was buggy as
| hell. It is quite stable for years now, so much that now
| there is another unifying audio stack: pipewire. It will
| still require pulseaudio for most software (it provides a
| stub for it), and it is very early release but I've been
| using it with only occasional bugs.
| simias wrote:
| I've had pretty terrible experiences with pulseaudio only a
| few years ago. As often on Linux I was probably unlucky
| with hardware support.
|
| More generally I've always been frustrated with Linux audio
| because in my experience for basic audio playback OSS
| mostly Just Worked and every single API that came after it
| was buggier and harder to configure for the simple cases
| while still usually not good enough for professional use.
|
| One exception was Jack which I like quite a lot,
| unfortunately it's also not natively supported by a lot of
| software, and that adds a lot of complications in my
| experience.
|
| But again, I've been running pulse for about six months now
| and I haven't had any major issues, so credit where it's
| due.
| kaba0 wrote:
| The great thing about pipewire is that it provides a jack
| stub as well -- you can use both pulseaudio and jack
| software side by side, and even pipe them to each other.
| I truly believe that once it stabilizes, linux will
| potentially be the best platform for audio production.
| mousepilot wrote:
| I'm really into music as a hobby and I don't want to mess up
| one of my few working computers. I do admit to using a
| youtube downloader some when I want to view a video.
| simias wrote:
| Yeah I definitely see where you're coming from,
| unfortunately I just cowardly reboot on my Windows
| partition when I want to do "serious" audio work because
| Linux is just an exercise in frustration in my experience.
| blaerk wrote:
| Or you could install pipewire for a pulseaudio free experience,
| if that's what you're after (that's what I did).
| khc wrote:
| does it work on ubuntu?
| blaerk wrote:
| It should, however not sure about installation
| documentation. As always, the gentoo and arch wiki should
| get you there, even on ubuntu
| mousepilot wrote:
| Interesting, I might give this a shot, thanks!
| lapsis_beeftech wrote:
| While not officially supported Firefox can still be built with
| ALSA support and with no pulseaudio requirement at buildtime or
| runtime. I suppose this might stop working at any point but it
| still works for me (currently on Firefox 88.0.1).
| pwg wrote:
| You might try apulse:
|
| https://github.com/i-rinat/apulse
| evmar wrote:
| I noticed that the two bugs they linked [1] [2] are both due to
| the distros introducing bugs by applying patches -- one for hurd
| support (!) -- that were not shipped by the upstream projects
| that the distros were repackaging. As we have discussed earlier
| [3] I think the way distros inject themselves into this software
| development process produces these bad outcomes due to getting
| the incentives wrong.
|
| [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1679430
|
| [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1633467
|
| [3] https://news.ycombinator.com/item?id=26216917
| AnIdiotOnTheNet wrote:
| Agree wholeheartedly. As far as I am concerned the whole
| repo/package manager model is the root cause of most of the
| reasons the Linux Desktop experience is as awful as it is.
| intrepidhero wrote:
| I'm not sure I agree. To quote one of the cases:
|
| >For example, at some point, Debian updated the fontconfig
| package by backporting an upstream fix for a memory leak.
| Unfortunately, the fix contained a bug that would crash Firefox
| and possibly other software too. We spotted the new crash only
| six days after the change landed in Debian sources and only a
| couple of weeks afterwards the issue had been fixed both
| upstream and in Debian. We sent reports and fixes to other
| projects too including Mesa, GTK, glib, PCSC, SQLite and more.
|
| That sounds a lot like Linus' "many eyes make all bugs shallow"
| idea working as intended.
| gsvelto wrote:
| Yes, that's one of the benefits. Firefox has a very large
| user-base compared to other FOSS projects so we will often
| spot bugs that others haven't noticed simply thanks to the
| sheer volume of crash reports we get.
| eikenberry wrote:
| Even more to the point is that these bugs were found in
| Debian's unstable/testing distribution. Reiterating that the
| release process is happening as it should and the bugs are
| being found by people who volunteered to help test the
| software.
| khuey wrote:
| This is exactly why historically Mozilla has required
| distributors to distribute an unmodified version of Mozilla
| software to use Mozilla trademarks such as the name Firefox,
| which (unlike the code) are not freely available.
|
| Unfortunately the specific bugs here are in library packages
| that Firefox uses and those have no such restrictions.
| IshKebab wrote:
| If I were Mozilla I would strongly consider bundling more
| dependencies.
| vetinari wrote:
| Ironically, that was one of the reasons why distributions
| wanted their own builds.
| jcastro wrote:
| The blog post could be titled "Why the Linux distribution model
| is totally broken for end user software".
|
| As a linux user I appreciate the work, but it's tough to read
| this blog post and not think about the wasted effort that could
| be used to fix the bugs in the upstream software itself.
| ohthehugemanate wrote:
| Really? Because I just think about how impossible this would
| be on Windows, where shared or external libs are inscrutable,
| as are OS build chains, version differences, etc etc.
| gsvelto wrote:
| We do gather symbol information on Windows too, but it's a
| lot less detailed than what we get from Linux. It also
| requires jumping through a lot of hoops. For example we get
| minimal information from Windows graphics drivers and we
| have to semi-manually scrape them ourselves.
| kevingadd wrote:
| To get symbols for basically any MS library I just add the
| official MS symbol server to my symbol search list. Chrome
| has one too, there's no real reason other vendors couldn't
| do it. You can also just ship a .pdb file next to your
| binaries, and I think the only good reasons for not doing
| that are keeping download sizes small (use a symbol
| server...) or paranoid secrecy.
|
| For example, NVIDIA's windows drivers are like 600mb at
| this point yet they don't even include function name
| symbols. It's inexcusable.
| phendrenad2 wrote:
| Has Windows ever broken Firefox? Do you think it's more or
| less likely to happen in Windows (or Mac) or Linux?
| dan_quixote wrote:
| > the way distros inject themselves into this software
| development process produces these bad outcomes
|
| As a former maintainer of packages in an enterprise Linux
| ecosystem, I agree. But...the patches are often meant to solve
| a dependency mismatch and the maintainers can't easily pull
| related dependencies forward without breaking other
| applications. It's great that other distros like Arch just
| simply upstream the patches - it's the right thing to do after
| all - but that takes time that the enterprise distributions
| don't always have.
| vngzs wrote:
| Arch Linux does not do this, instead preferring to upstream
| patches [0]:
|
| > Arch Linux defines simplicity as without unnecessary
| additions or modifications. It ships software as released by
| the original developers (upstream) with minimal distribution-
| specific (downstream) changes: patches not accepted by upstream
| are avoided, and Arch's downstream patches consist almost
| entirely of backported bug fixes that are obsoleted by the
| project's next release.
|
| It's one of the core things that has kept me on Arch as a daily
| driver, even long after I've lost the urge to endlessly tweak
| my system configuration. I can trust that the software I use is
| simply vanilla upstream software with little or no
| modifications, and that's a great advantage when it comes to
| filing upstream bug reports and working on patches. In
| addition, it means the Arch Wiki is fairly general in its
| applicability, and effort spent documenting software for Arch
| can apply equally well to, for example, Void Linux (which also
| has this "vanilla software" philosophy).
|
| [0]: https://wiki.archlinux.org/title/Arch_Linux
| evmar wrote:
| As a former Debian enthusiast (I even helped staff a Debian
| booth at a conference once!) who also tends to be
| conservative with new technology and who is consequently also
| skeptical of all these random Linux distros, I eventually
| tried out Arch and found it ... super awesome, I really love
| it!
|
| I highly recommend it to anyone else like me, who is
| generally cranky about new things. They did a really great
| job with Arch. This policy you mention is a great example of
| what I like about it.
| joana035 wrote:
| I used Arch a lot back in the days there was no dkms (got a
| new kernel? Recompile your gpu module otherwise no desktop
| on the next reboot, specially with nvidia) and Arch is a
| very good place to learn Linux, but I eventually went to
| Debian because everything just works.
|
| For the topic I think is good to have dfsg and to patch any
| software with the goal to provide better integration with
| the system and for user's freedom.
| The_rationalist wrote:
| Archlinux is far from being up to date though e.g openjdk
| is stuck with release from last year (15 instead of 16)
| It's a quite miserable experience in 2021 to not have a
| single distro that is universally up to date with software
| development. Windows has this since day 1 if we talk about
| auto updating software and the windows store apps, being
| owned by the app makers instead of by a poor middleman (the
| distro village) are by design up to date.
| ticviking wrote:
| So pay for open source. Or volunteer.
|
| As engineers we have no one but ourselves to blame for
| this one
| vngzs wrote:
| Yeah, sorry, the openjdk situation sucks. It's an "extra"
| package, which means the maintainer is a community member
| rather than being part of the Arch core group.
|
| The nice thing about Arch packages, though, is that
| they're basically just bash scripts. And if all you need
| is a simple version bump, it's usually quite easy:
| download the package tarball from [0] and change [1] to
| the version you want, then do a `makepkg -s` in the
| directory of the package. It will build the package in a
| (usually reproducible) chroot. If it builds without
| errors, then you'll end up with a tarball that you can
| `pacman -U ${pkg}.tar.zst` to install the produced files.
|
| If you need help, makepkg documentation on the wiki[2] is
| pretty great. And don't forget to send a patch to arch-
| dev-public[3] and CC the maintainer. At the very least,
| it'll kick off a discussion that will get the package
| updated.
|
| Rolling your own packages is easy in contrast to, say,
| Red Hat - where compiling an RPM is easy if you've done
| it a bunch, but really difficult to get bootstrapped on.
|
| [0]: https://archlinux.org/packages/extra/x86_64/jdk-
| openjdk/
|
| [1]: https://github.com/archlinux/svntogit-
| packages/blob/packages...
|
| [2]: https://wiki.archlinux.org/title/Makepkg
|
| [3]: https://lists.archlinux.org/listinfo/arch-dev-public
| bscphil wrote:
| > Yeah, sorry, the openjdk situation sucks. It's an
| "extra" package, which means the maintainer is a
| community member rather than being part of the Arch core
| group.
|
| This is incorrect. Packages in both core and extra are
| maintained by the core Arch developers. You're probably
| thinking of the community repository, which is maintained
| by a group called Trusted Users. These are still heavily
| vetted, it's not just anyone from the community. Or maybe
| you're thinking of the AUR, which is a completely
| untrusted repository of build scripts, which anyone can
| submit to.
|
| In this case, the issue is that anthraxx, one of the Arch
| developers [1], has not updated many of their packages in
| some time. I don't know if a reason is known, but you
| might find something in the mailing list links someone
| else has posted.
|
| [1] https://archlinux.org/people/developers/
| iruoy wrote:
| There've been questions about this on the mailing lists
| recently
|
| https://lists.archlinux.org/pipermail/arch-
| general/2021-May/...
|
| https://lists.archlinux.org/pipermail/arch-
| general/2021-May/...
| jpetso wrote:
| With packaging technologies such as Flatpak and Snap, app
| makers now have the option to distribute a bundled-
| everything version of their software to Linux users.
|
| This has drawbacks too though, in that it's now up to app
| makers to take care of keeping supporting libraries up to
| date and secure. That's not necessarily their top
| priority though, which is a risk for the end user. Also,
| unnecessary duplication of libraries increasing memory
| use, when the distro is able to share most of them. Plus
| the poor middleman has an incentive to set user-friendly,
| privacy-preserving defaults that I wouldn't trust as much
| when the package is provided by a commercial company with
| different incentives.
|
| It's great to have the option, but overall I would still
| prefer to use distro packages except in the rare special
| case.
| rjzzleep wrote:
| I've been using arch for a few years as daily driver, and I
| mostly like it, but I would be lying if I said it doesn't
| break at random intervals during system updates. Nothing
| unrecoverable, but it's definitely a thing that comes with
| frequent upgrades.
| matheusmoreira wrote:
| Could you post more details about what broke, why and how
| you fixed it? I'm curious.
|
| I've been using Arch for years and I never experienced
| any breakage. I update it every month or so and it's
| still stable even after these huge updates. There's
| nothing for me to do other than merge .pacnew files.
| nemetroid wrote:
| What part of it breaks for you? It's not that I don't
| believe you, and I've seen this sentiment before, but
| I've used Arch as my daily driver for about five years,
| and can't recall a single time where it broke from a
| system update.
| maddyboo wrote:
| I was an XMonad user during the time that Arch switched
| from statically linked Haskell packages to dynamically
| linked and oh my god was that a nightmare. Other than
| that I've had far, far fewer issues with Arch than any
| other distro I've used.
| Lex-2008 wrote:
| not OP, and not Arch, but Manjaro (so you can take it
| with a grain of salt), reporting from memory so details
| might be incorrect.
|
| * after "BootHole" GRUB vulnerability, I've read that
| upgrade requires re-installation of the bootloader. And
| just in case, did run `sudo grub-install ...`. After
| reboot, system didn't boot. Had to use installation USB
| to restore.
|
| * More recently, during routine upgrade pamac (Manjaro's
| pacman alternative) GUI showed me some "transaction can't
| be completed" error message. Shuddered it away - few days
| later pamac wasn't starting at all. Starting it from
| terminal showed error message about some missing *.so
| file. Googling showed that this is a required file for
| pacman (Arch package manager) to function. Typing
| `pacman` in terminal showed "command not found" error
| message. Restored the missing *.so file from snapper
| snapshot (thanks btrfs!), after that pamac started fine
| and happily upgraded my system.
|
| I'm not sure what happened in second case and why pamac
| left system in broken state (looks like it wanted to
| upgrade pacman by first removing old files and then
| putting new files in place, but aborted in the middle),
| but first one might be quite distro-independent.
|
| Also, reading through recent Arch news, I believe this
| could bite someone:
|
| https://archlinux.org/news/sshd-needs-restarting-after-
| upgra...
|
| > After upgrading to openssh-8.2p1, the existing SSH
| daemon will be unable to accept new connections. When
| upgrading remote hosts, please make sure to restart the
| SSH daemon right after running pacman -Syu. If you are
| upgrading to openssh-8.2p1-3 or higher, this restart will
| happen automatically.
| majewsky wrote:
| > I'm not sure what happened in second case and why pamac
| left system in broken state
|
| FWIW, as a vanilla Arch user, I have not encountered this
| issue. I remember a time when pacman updates were kind of
| iffy (and in fact, pacman itself asked you to update it
| first before proceeding with the rest of the updates),
| but since 5.0, all subsequent updates have been
| completely unremarkable in the best way.
| paulfurtado wrote:
| I use arch on all my machines and there are really a lot
| of ways it has broken.
|
| - Arch will release a new version of Xorg before the
| graphics card vendors release new drivers that are
| compatible with it. Same for kernel versions too.
|
| - I've had gedit start crashing in new minor versions of
| gnome due to a setting being incompatible, needing to
| track that down and unset
|
| - If you have python virtualenvs for development and
| system python is upgraded to a new major version, all
| your virtualenvs break
|
| - If arch upgrades the major version of glibc during some
| random package install (rather than a system upgrade),
| and you don't upgrade the whole system at once, every app
| that didn't get upgraded will fail to start due to soname
| mismatches... and that can mean that pacman, sudo, etc
| are all busted (this has actually happened to me)
|
| - If you do a full system upgrade and have AUR stuff
| installed, you need to be sure to upgrade the AUR stuff
| otherwise it could break due to being incompatible with
| any library that was upgraded.
|
| - In general (not specific to arch linux), new versions
| of software break stuff all the time. You tend to hit way
| more of this on arch if you keep your system up to date.
| mixedCase wrote:
| I'm sure you know all this, but just to give other people
| some context on how Arch expects one as a user to handle
| this:
|
| > - Arch will release a new version of Xorg before the
| graphics card vendors release new drivers that are
| compatible with it. Same for kernel versions too.
|
| You accidentally put a plural in "vendors", but in
| practice this is just Nvidia.
|
| If you are forced by circumstance to deal with an Nvidia
| card, use the LTS kernel and most of your problems go
| away, and you can also pin your X.org version and
| manually update it. The real solution is to use a GPU
| vendor that has mainline drivers, the only valid reason
| nowadays not to do that being CUDA or being unable to
| acquire hardware with mainline support.
|
| > - I've had gedit start crashing in new minor versions
| of gnome due to a setting being incompatible, needing to
| track that down and unset
|
| That's a gedit bug. Complain to gedit devs or stop using
| it.
|
| > - If you have python virtualenvs for development and
| system python is upgraded to a new major version, all
| your virtualenvs break
|
| You should not be using system python for non-system
| tasks. Use asdf, Nix, Docker, pyenv or a similar tool for
| projects requiring their own non-system environment.
|
| > - If arch upgrades the major version of[...]
|
| Partial upgrades are explicitly unsupported by the
| distro. Pacman allows you to do this, but you're on your
| own.
|
| > - If you do a full system upgrade and have AUR stuff
| installed
|
| AUR is not Arch, it's up to each AUR maintainer to keep
| their scripts up to date and you as a user to keep up
| with those external dependencies. A common approach is to
| use an AUR helper to handle both system and AUR upgrades.
|
| > - In general (not specific to arch linux), new versions
| of software break stuff all the time. You tend to hit way
| more of this on arch if you keep your system up to date.
|
| And this is why as an Arch user you will be nudged by
| experience to use software that gives a crap about
| quality.
| paulfurtado wrote:
| Yes, all of this is definitely true and I'm not actually
| complaining about it, I have used arch on all my machines
| for 7 or 8 years and don't plan to change that anytime
| soon, but these problems are actually unique to using
| arch and other rolling distros. Ubuntu, Fedora, etc have
| coordinated releases with some level of testing that
| things are compatible with each other. On arch, these are
| problems one must deal with though. I don't mind dealing
| with it, I live for Linux stuff, but the point is that it
| does happen to real users and it's not for everyone.
|
| > Partial upgrades are explicitly unsupported by the
| distro. Pacman allows you to do this, but you're on your
| own.
|
| Definitely correct, the issue is when you're trying to
| install a package to get something done, and suddenly
| your faced with the proposition of either upgrading your
| whole system while trying to get work done or attempting
| to upgrade just the required libraries. The latter often
| carries less risk, but occasionally is very problematic.
|
| > And this is why as an Arch user you will be nudged by
| experience to use software that gives a crap about
| quality.
|
| The issue is that this is true of so many very major
| pieces of linux software. Upstream vendors don't
| necessarily test their stuff in a ton of contexts, plenty
| of bugs occur in the
| kernel/xorg/wayland/gnome/glibc/python/etc. All of these
| are very mainstream projects that are difficult to avoid.
| formerly_proven wrote:
| > - If arch upgrades the major version of glibc during
| some random package install (rather than a system
| upgrade), and you don't upgrade the whole system at once,
| every app that didn't get upgraded will fail to start due
| to soname mismatches... and that can mean that pacman,
| sudo, etc are all busted (this has actually happened to
| me)
|
| Okay I just wanna point something out here, partial
| upgrades in Arch are broken by design because they simply
| can't work. Don't do it.
|
| That being said...
|
| > - Arch will release a new version of Xorg before the
| graphics card vendors release new drivers that are
| compatible with it. Same for kernel versions too.
|
| ... kernel ABI is stable and even ancillary interfaces
| are usually stable, so usually it's quite A-OK to not
| immediately upgrade the kernel.
| Liskni_si wrote:
| Can you elaborate why has Arch chosen to not support
| partial upgrades by design? They do work in Debian and
| it's saved my day a number of times. They let me roll
| back a broken upgrade without holding back upgrades of
| the rest of the system, and my computer then continues to
| be usable until the package in question is fixed.
| Quekid5 wrote:
| They choose not to officially support it precisely
| because of the types of issues that upgrading e.g. glibc
| or openssl can cause.
|
| That said, the vast majority of the time only upgrading a
| particular application/package (and its dependencies)
| will work just fine. It's just that there are no
| (official) guarantees.
| Liskni_si wrote:
| The types of issues upgrading e.g. glibc or openssl can
| cause are largely predictable, aren't they? That's why
| there's libtool and sonames and that kind of stuff. The
| only missing piece is support for this in the package
| manager...
| nemetroid wrote:
| Pacman _can_ roll back packages, and does let you stop
| certain packages from being upgraded. As you say, you
| could probably get away with doing it, if the package in
| question has "boring" (i.e. ABI stable) dependencies.
| paulfurtado wrote:
| Yeah, definitely usually fine to avoid kernel upgrades,
| so that is a saving grace. The issue is just that pacman
| -Syu is going to be full of surprises
| nemetroid wrote:
| Thanks.
|
| > - Arch will release a new version of Xorg before the
| graphics card vendors release new drivers that are
| compatible with it. Same for kernel versions too.
|
| I imagine this is mainly a problem if you have an Nvidia
| card (which would explain why I haven't had the problem).
|
| > - In general (not specific to arch linux), new versions
| of software break stuff all the time. You tend to hit way
| more of this on arch if you keep your system up to date.
|
| More often, sure. But for software delivery from the
| production side, the common viewpoint seems to be that
| deploying more often leads to less pain in total, because
| you're making smaller increments so the individual
| failures are smaller as well.
|
| As such, aside from integration issues like Xorg and the
| drivers, I would expect Arch to have fewer _major_
| breakages than (e.g.) using LTS releases of some distro
| and upgrading every second year.
| ohazi wrote:
| I use Debian testing as my daily driver at home and at
| work, and have found it to be plenty stable over the
| decade or so that I've been using it.
|
| I've also been using Arch on a "for messing around; I
| don't care if it breaks" laptop for about two years, and
| haven't had any major breakages.
|
| For me, the most noticable difference has been that
| Debian will install new kernels as new packages, will
| suggest removing old kernel packages, but won't suggest
| removing the currently booted kernel. I like this
| behavior. By default, Arch will swap your currently
| booted kernel and modules out from under you. You don't
| necessarily _need_ to reboot right away, but if you don
| 't, you can run into issues loading modules or recovering
| from hibernation.
|
| You can work around this once you realize what's
| happening, but it seems like a needlessly dangerous
| default.
| nemetroid wrote:
| See https://bugs.archlinux.org/task/16702 for a
| discussion about versioned kernel installs in Arch.
| bachmeier wrote:
| I used Arch many years ago as my main OS. I eventually
| had to give up on it because (i) several packages I
| needed were badly out of date, combined with (ii) a rule
| against AUR having packages that were only updates of
| something in the repos. I was left handling the
| compilation process all by myself.
|
| When several of us raised the issue in the forum...I'll
| just say we didn't get a warm reception. That was more
| than a decade ago, so things may be completely different
| now, but it left a bad taste in my mouth.
| bscphil wrote:
| > I noticed that the two bugs they linked [1] [2]
|
| This is misleading and in fact not even strictly true. They
| link _three_ bugs, not two:
| https://bugzilla.mozilla.org/show_bug.cgi?id=1633459
|
| This third bug was not due to Debian patches. And in fact the
| two Debian patch cases in the article were included to make the
| point that they can now catch issues caused by distribution
| patches, not to claim that most of the issues they find are
| caused in this way. Assuming on the basis of an article written
| to make a wholly _different_ point that because 2 /3 were the
| result of distribution patches that this must be a huge problem
| in general for Linux software development just shows your bias
| on this issue.
|
| I like and use Arch Linux on my desktops. But I'd defend the
| choice by Debian to patch. Most of Debian's changes are
| intended to improve support for certain setups or introduce bug
| or security fixes that upstream _hasn 't_ backported. These are
| both good things. Furthermore, problems that are created tend
| to be caught while they're still in unstable or sid: if I'm not
| mistaken that's exactly what happened in these cases, which is
| the process working as intended. (Mozilla is certainly free to
| disregard bug reports from Debian users if they feel that
| Debian's patching process is simply causing too many problems.)
| miohtama wrote:
| Switching to static binaries would solve some of these issues.
|
| Earlier discussion:
| https://news.ycombinator.com/item?id=27009044
| JoshTriplett wrote:
| I think it's a good thing that there's enough information to
| easily correlate things like crash reports from the latest
| bleeding-edge packages with uploads of dependency packages:
|
| > the libfontconfig1 package was updated on Debian on the 21st
| of April and the first crash we have on record was sent on the
| 22nd. Here's the changelog:
|
| I think that's a good argument for this kind of crash-
| telemetry, working in conjunction with Linux distributions. And
| it _helped_ , in this case, that the dependencies could be
| updated independently from Firefox.
|
| On the other hand, the libdrm hurd patch breaking things on
| Linux seems like an _excellent_ example of how portability to
| obscure platforms has a non-zero cost, and it isn 't as simple
| as "just accept portability patches".
| duhi88 wrote:
| I've never had an issue with it crashing on Linux, but I've had
| this bug for months that causes the scrollbar to jump around.
| Usually it jumps up 10-20px every couple of seconds. I've tried
| removing all plugins, refreshing, changing mice, etc. until I had
| to switch to Brave.
|
| Anyone else come across this issue? I'm using Solus.
| dEnigma wrote:
| I haven't encountered that issue on Solus Budgie. My first
| thought was an issue with your mouse, but since you've ruled
| that out, and it apparently works for you in Brave, I'm
| stumped.
| rowanG077 wrote:
| How about fixing GPU acceleration. This is THE main issue why I
| don't use Firefox.
| garaetjjte wrote:
| What's wrong with it?
| rowanG077 wrote:
| It only works under GNOME officially and that only since
| January. And I have in fact never gotten it to work, and I'm
| not alone.
| aosmond wrote:
| As of bug 1702301 [1], and Firefox 89 currently in beta, we
| are shipping hardware accelerated WebRender by default on
| Intel (Mesa 17+), AMD (Mesa 17+) and NVIDIA (Mesa 18.2+,
| Binary driver 460.32.03+) GPUs, as well as lifting the
| desktop restriction. KDE and XFCE are allowed by default in
| 88. Wayland anything for a while. There are some particular
| GPUs with issues which we block, and there are a few more
| coming due to reported issues (mostly older/weaker GPUs).
|
| There are open bugs I know. Some of which that are getting
| attention, others we haven't gotten a chance to prioritize.
| Is there a bug filed about your particular problem?
|
| [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1702301
| kroeckx wrote:
| Will VAAPI get enabled (on X11) by default too?
| aosmond wrote:
| VAAPI requires DMABuf, which requires EGL. We want to
| ship hardware acceleration using EGL instead of GLX, but
| CI issues have held it up (we are otherwise pretty much
| there for testing on nightly).
| rockdoe wrote:
| I use it under KDE.
|
| Or are you on Wayland?
| bool3max wrote:
| Works for me on sway (Wayland).
| heavyset_go wrote:
| It would be nice if Firefox played nicely with cgroup memory
| limits. Right now, Firefox will freeze, crash or freeze while
| swapping heavily when it starts allocating near or at the limit.
| Same thing with Firejail.
| gsvelto wrote:
| That's a really tough problem to solve on Linux. We're actively
| working on it in order to make Firefox better behaved when
| memory gets tight but it's not easy. You can follow the work in
| these two bugs:
|
| https://bugzilla.mozilla.org/show_bug.cgi?id=1532955
|
| https://bugzilla.mozilla.org/show_bug.cgi?id=1587762
| nix0n wrote:
| I've also seen Firefox freezing and swapping heavily when real
| physical RAM is depleted.
|
| I was able to reduce RAM usage by reducing the number of
| content processes, so that might be helpful to you also.
| heavyset_go wrote:
| > _I was able to reduce RAM usage by reducing the number of
| content processes, so that might be helpful to you also._
|
| Yeah, I dropped dom.ipc.processCount by half a while ago, but
| I think Fission[1] overrides that setting.
|
| [1] https://wiki.mozilla.org/Project_Fission
| nathias wrote:
| I've been using firefox nightly on arch linux for 5 years, never
| had an issue (except some changes that broke my customization).
| nyanpasu64 wrote:
| How do you extract symbols from official binary builds of Arch?
| According to official documentation
| (https://wiki.archlinux.org/title/Debug_-_Getting_Traces and bug
| report threads I've seen), Arch lacks both debug packages and
| symbols bundled with binary packages. As a result, if you want to
| debug an app crash on Arch, you need to quit the program,
| recompile the app from source with your makepkg.conf set to
| !strip, then try to reproduce the bug in your new build.
|
| It seems Firefox has a script at
| https://github.com/gabrielesvelto/symbol-scrapers/blob/maste...,
| but I haven't investigated what it does. In any case, this
| information should be integrated into the Arch Wiki.
| input_sh wrote:
| Oh cool! Now that I think of it I haven't seen the crash window
| in quite some time. Well done!
|
| Now if I could only disable Ctrl+Q and prevent it from asking for
| a restart after update...
| kevincox wrote:
| > prevent it from asking for a restart after update
|
| This isn't just nagging. The API between the main browser
| context and content processes isn't stable between builds. This
| means that Firefox can't spin up a new content process if the
| update has replaced the executable with a different version.
| Therefore Firefox has the tough choice of trying anyways and
| risking misbehaviour (including possibly security bugs) or
| forcing the user to restart the browser process so that it can
| spawn new content processes.
|
| It also depends on how your distribution updates Firefox. For
| most distributions they have this problem, however NixOS
| doesn't because the new version is installed in a new
| directory.
|
| IIUC Firefox's self-updater also doesn't have this issue, and I
| think it supports Linux.
| phendrenad2 wrote:
| Why can't they keep the old version around and continue using
| it? It just sounds like excuses.
| jgraham wrote:
| The problem isn't Firefox updating itself; it occurs when
| the distro update, or other external process, replaces
| running Firefox.
|
| A workaround would be to use Firefox directly from upstream
| instead of the distro packaged version (I understand some
| people are not happy with this tradeoff).
| kaba0 wrote:
| You mean the distros, right? It's not firefox's job.
| the8472 wrote:
| > This means that Firefox can't spin up a new content process
| if the update has replaced the executable with a different
| version.
|
| Couldn't it spin up another one from the old version by doing
| _execve( "/proc/self/exe", ...)_? Or by keeping a template
| process around with all the libraries loaded from which a
| child process can then be forked.
| kelnos wrote:
| On my system, /proc/self/exe is just a symlink to wherever
| the program is on disk, not a copy or a reference to the
| image in memory.
| makomk wrote:
| If I remember rightly, some of the things in /proc that
| look like symlinks don't actually behave like them -
| opening them opens the actual file that the process has
| open, even if it's been deleted and a new file created at
| the same location.
| kevincox wrote:
| I don't know about the `/proc/self/exe` but I think it
| would work if they use the same binary (I think they do). I
| don't know how many other config files or libraries may
| also be read, but maybe those have better comparability.
|
| As for the template process one major issue is that this
| means that you only get ASLR once on browser start, instead
| of for every content process, which somewhat reduces the
| benefits.
| rockdoe wrote:
| _Couldn 't it spin up another one from the old version by
| doing execve("/proc/self/exe", ...)?_
|
| 99% of the Firefox code is in libxul.so, so you'd need to
| get the file handles from the original process or something
| similar.
| dblohm7 wrote:
| Completely possible, but that's not how it works ATM.
|
| EDIT: And at the risk of stating the obvious, the fact that
| it _doesn 't_ work this way should be a hint that there are
| complexities involved that make it more complicated than
| "just" doing it.
| phendrenad2 wrote:
| I don't agree. The fact that it doesn't work is not
| necessarily a hint that there are complexities involved.
| There are a myriad of other possible reasons, such as no
| one really cares that Firefox forces you to restart the
| app whenever it updates. People just get used to it.
| dblohm7 wrote:
| I've been privy to the discussions at Mozilla about this
| topic. I can assure you, things are not the way they are
| out of either laziness or ignorance.
| kaba0 wrote:
| Or you know, most apps dislike having the executable file
| itself replaced under them and getting into an unknowably
| bad state, for basically null benefits. Distros should
| handle multiple versions of the same program, a la nix,
| and programs should not optimize for random things like
| that.
| phendrenad2 wrote:
| That's just a defeatist attitude. Why does the executable
| need to be replaced? Why can't the new executable be
| called firefoxNext, and when firefox starts next time, it
| checks for this file, and if it exists, it quickly starts
| that instead, which renames itself to firefox,
| overwriting the old version? What would be wrong with
| that?
|
| EDIT: Oh, I see. This happens when the distro package
| manager updates firefox. I don't have a solution, since
| there isn't an easy one that will satisfy all people. So
| nevermind. _shrug_
|
| Maybe Firefox could create a temporary executable copy of
| itself and run from there, and run that, so when the
| original is replaced, it doesn't affect the running
| process. But, that probably comes with a host of
| complications that I'm unaware of.
| MawKKe wrote:
| It does not really ask, it straight up bricks the whole browser
| session until you do.
|
| But otherwise, FF has been really stable for years now
| kelnos wrote:
| Per a sibling comment, browser.quitShortcut.disabled in
| about:config works. For me, I just never disabled the option to
| ask before quitting when more than one tab is open, so that
| dialog always catches me before I quit by accident.
| coldpie wrote:
| Sadly it's not enough. If I have one tab open, I still don't
| want ctrl-q to kill Firefox; and it doesn't count pinned tabs
| as open tabs, so it will still kill even if you have several
| pinned tabs open. It's a really, really dumb shortcut to have
| on by default and I'm thrilled it's finally dead.
| Vinnl wrote:
| I haven't been able to disable it, but the option "Warn you
| when quitting the browser" at the top of preferences has
| already saved me numerous times. Not as perfect as disabling,
| but far better than nothing.
| cpeterso wrote:
| There is a new "browser.quitShortcut.disabled" setting in
| about:config to disable Ctrl+Q.
| deadbunny wrote:
| I've never really had an issue with restarting Firefox, it
| remembers all my tabs when I restart it either after an update
| or just a close/open. Perhaps it's a setting I toggled years
| ago and have since forgotten but I'm not sure what the
| complaint is about restarting after an update?
| Abishek_Muthian wrote:
| Unless there's a private window, which gets lost during these
| forced restart after updates.
| randlet wrote:
| At least for me after FF updates itself it won't let you open
| a new tab or anything until it restarts. According to this
| Reddit post this is due to it being updated by the package
| manger so maybe it's a Linux only issue?: https://old.reddit.
| com/r/firefox/comments/jwx54y/firefox_for...
| lazulicurio wrote:
| It's due to the "unattended upgrades" feature. You can
| blacklist FF from getting those upgrades with a change to
| /etc/apt/apt.conf.d/50unattended-upgrades. Add "firefox" to
| the "Unattended-Upgrade::Package-Blacklist" section. I find
| manually upgrading much less annoying than having my
| browser randomly lock up on me.
| input_sh wrote:
| It remembers the tabs, but it loses my vertical position
| within the tabs. When reading articles or a thread on some
| forum, that's quite annoying. Even Pocket doesn't save my
| progress on a desktop but does on my phone.
|
| It's nothing that would make me stop using it, just an
| annoyance that I wish I didn't have to deal with on a semi-
| regular basis.
| tux3 wrote:
| >Now if I could only disable Ctrl+Q
|
| Good news! =)
|
| Set browser.quitShortcut.disabled in about:config
| amlib wrote:
| Since when was that added? Anyway, my days of closing the
| whole damn browser instead of a single tab are finally over!
| input_sh wrote:
| Yeah this must be new-ish. I remember searching for this
| and only finding some plugins that didn't work on Linux.
| sylvestre wrote:
| Indeed, 3 months ago:
| https://bugzilla.mozilla.org/show_bug.cgi?id=52821#c319
| [deleted]
| [deleted]
| kevincox wrote:
| I would absolutely love a shortcut manager for Firefox. For
| example I use this shortcut enough that something like
| Ctrl+Shift+Q would be useful. (And the dozens of other things
| that I would like to rebind, including custom shortcuts).
| Dunedan wrote:
| I second that. I'd love to be able to configure a shortcut
| to move tabs to new windows.
| darkwater wrote:
| Oh god thanks for this!! How many times I misstyped a q for a
| w!
| reidrac wrote:
| Coincidentally, I have experienced 4 crashes already since
| 88.0.1 was released.
|
| But I agree with you, I can't remember when was the last time I
| had a crash before these!
| MrRed wrote:
| Congrats on shipping Gabriele and all LLT team and colleagues :)
___________________________________________________________________
(page generated 2021-05-19 23:00 UTC)