Re: Slow firefox and high cpu usage
On Wed 10 Oct 2018 at 21:04:58 (-0400), bw wrote:
> On Wed, 10 Oct 2018, David Wright wrote:
> > On Wed 10 Oct 2018 at 19:11:46 (-0400), bw wrote:
> > > On Thu, 11 Oct 2018, Ben Caradoc-Davies wrote:
> > > > On 11/10/2018 11:36, bw wrote:
> > > > > On Thu, 11 Oct 2018, Ben Caradoc-Davies wrote:
> > > > > > On 11/10/2018 11:15, bw wrote:
> > > > > > > How exactly do you think stretch users should run an adblocker when all
> > > > > > > the xul-ext-* extensions are now broken?
> > > > > > I see that there is a webext-ublock-origin for sid but I have never used
> > > > > > it:
> > > > > > https://packages.debian.org/sid/web/webext-ublock-origin
> > > > > p.s. and I use stable, because it is stable, not sid, which is unstable.
> > > > > thanks anyway but I think your advice is a little dubious.
> > I find a lot of adverts are blocked by my very long /etc/hosts file.
> > I download the bulk of it from http://someonewhocares.org/hosts/
> > occasionally. (The rest of the file is static addresses for my LAN.)
> > I originally did this because the adverts would totally overload a
> > browser running on a 1.5GHz laptop with 500MB memory. But I've kept
> > using it because the side effects are so minor: occasional nagging by
> > sites that notice you're blocking ads, and the inability to click on
> > the paid-for links at the top of google searches.
> > > > My point is not that you should use unstable, but that the evidence on sid
> > > > suggests that webext-* packages are coming to stable ... when stable is called
> > > > buster. I did not see any webext-* packages in stretch-backports. The
> > > > workaround is to install them directly from upstream via Firefox.
> > > >
> > > > I agree that it is sad that Firefox on stretch has been upgraded to break the
> > > > xul-ext-* packages before webext-* packages are available. Unfortunately
> > > > Debian is wedged between upstream dropping support for xul-ext-* extensions in
> > > > ESR 60 and the end of life of ESR 52. You do want security patches, don't you?
> > > > I think that ESR 60 with unpackaged extensions is the lesser evil. Normal
> > > > service will likely be resumed in buster.
> > I have noticed that the old xul…runner processes have gone, and that
> > plugin-container processes are pretty rare, presumably being replaced
> > by these Web Content processes.
> > But my experience is that FF on stretch is a lot more reliable than
> > the one on jessie ever was. The latter would crash about every couple
> > of weeks or so, and then there were all those scripts that "stopped
> > responding".
> > > I agree with this opinion, and also what Dan Ritter replied. Firefox is
> > > now unreliable on stretch and should be avoided. Security updates to a
> > > browser that crashes with strange processes named "Web Content" aren't
> > > really all that secure are they?
> > Well, I hope the Debian team ignore your opinions, take note of any
> > bug reports, and continue to support FF for all the happy Debian users
> > who are using it to do important work.
> > It's sensible to come here for help and advice with your problems, but
> > not to assume that everyone else is suffering in the same manner. If
> > you know of specific security problems, then report them. Meanwhile,
> > we'll carry on using FF as usual.
> > I routinely run two instances on this 4-core 1.6GHz laptop with 4GB
> > memory, one as myself for mainly financial and administrative sites,
> > and one as a different user for other sites. That's my nod to security.
> > > Why not just remove the package from stretch if it is insecure, or since
> > > it relies on pkgs from outside the repo, should it be moved to "contrib"
> > > until buster is released and we have working extensions?
> > Doesn't it have to Depend on packages, rather than just relying on
> > them, which would be more like a Recommend or Suggest. AIUI the main
> > difference between FF and more regular packages is that they take
> > upstream versions more frequently than normal, and that's in order
> > to increase security, recognising that applying all the security
> > patches to a static 2016/7 version is impractical.
> I would sure be interested in your method of running firefox on stretch,
> without using extensions or addons from outside the debian repositories?
After installing it, I type, say, my-cups to open up the browser for
CUPS administration. (Of course I get all the previously opened tabs.)
I have a slew of bash functions according to what I want to see come up,
like my-weather my-forecast my-radar … …
$ type my-cups
my-cups is a function
$ type -- -myfirefox
-myfirefox is a function
grep -q "$HOSTNAME-$MYCODENAME" <<< "$BROWSERCODENAMES" && printf 'myfirefox %s\n' "$1" && ( /usr/bin/firefox "$1" & ) || printf '%s\n' "Incorrect release for firefox"
As for other packages, here's a list of the origin of packages on this
stretch installation, but filtered with grep -v 'main_binary'
(it's massaged output from apt-cache dump.)
Package: amd64-microcode Version: 3.20180524.1~bpo9+1 File: /var/lib/apt/lists/ftp.us.debian.org_debian_dists_stretch-backports_non-free_binary-amd64_Packages
Package: emacs24-common-non-dfsg Version: 24.5+1-2 File: /var/lib/apt/lists/ftp.us.debian.org_debian_dists_stretch_non-free_binary-amd64_Packages
Package: firmware-amd-graphics Version: 20180825+dfsg-1~bpo9+1 File: /var/lib/apt/lists/ftp.us.debian.org_debian_dists_stretch-backports_non-free_binary-amd64_Packages
Package: firmware-ipw2x00 Version: 20180825+dfsg-1~bpo9+1 File: /var/lib/apt/lists/ftp.us.debian.org_debian_dists_stretch-backports_non-free_binary-amd64_Packages
Package: firmware-iwlwifi Version: 20180825+dfsg-1~bpo9+1 File: /var/lib/apt/lists/ftp.us.debian.org_debian_dists_stretch-backports_non-free_binary-amd64_Packages
Package: firmware-linux Version: 20180825+dfsg-1~bpo9+1 File: /var/lib/apt/lists/ftp.us.debian.org_debian_dists_stretch-backports_non-free_binary-amd64_Packages
Package: firmware-linux-nonfree Version: 20180825+dfsg-1~bpo9+1 File: /var/lib/apt/lists/ftp.us.debian.org_debian_dists_stretch-backports_non-free_binary-amd64_Packages
Package: firmware-misc-nonfree Version: 20180825+dfsg-1~bpo9+1 File: /var/lib/apt/lists/ftp.us.debian.org_debian_dists_stretch-backports_non-free_binary-amd64_Packages
Package: firmware-realtek Version: 20180825+dfsg-1~bpo9+1 File: /var/lib/apt/lists/ftp.us.debian.org_debian_dists_stretch-backports_non-free_binary-amd64_Packages
Package: intel-microcode Version: 3.20180807a.1~deb9u1 File: /var/lib/apt/lists/security.debian.org_debian-security_dists_stretch_updates_non-free_binary-amd64_Packages
Package: iucode-tool Version: 2.3.1-1~bpo9+1 File: /var/lib/apt/lists/ftp.us.debian.org_debian_dists_stretch-backports_contrib_binary-amd64_Packages
Package: xtoolwait Version: 1.3-6.2 File: /var/lib/dpkg/status
Package: youtube-dl Version: 2018.09.10-1 File: /var/lib/dpkg/status
> I never mentioned jessie, not sure what the reference is about?
Jessie is just a shorthand for "older versions of firefox" which is
what I'm comparing with FF on stretch. I've been running FF since at
least etch, and perhaps sarge and woody (I'm not sure what the package
mozilla-browser actually ran), woody being the last Debian where I ran
opera. I don't remember all the FF versions I have run, but they'll
all be listed in the mainline Debian distributions of the time.
There seems to have been a lot of criticism here of stretch, not just
per se (which is to be expected as it's the current version) but in
comparison with previous releases, and that's doesn't match my experience.
If anything, vanilla stretch has been better for me than recent releases.
> My point
> was that is ff needs extensions to be "secure" or reliable, and if the
> only place to get them is from outside the debian repo, then logically,
> the pkg belongs in "contrib" or plain kicked out of the repo.
It would surely be more to the point for you to indicate what it is
you think I'm missing. I can tell you that Themes is default and
Languages is English(GB). That's it. I don't count my doctored
/etc/hosts as an add-on because it's not a software component.