Pyra without decent web browser?


(on the Pandora, you should try NetSurf, it's fast, but has some compatibitly issue with some JavaScript).

I tried every browser I saw, and QupZilla was the only one which rendered minds.com and was also somewhat usable. It's still shockingly awful, but it works.

I've been using Pale Moon as my desktop browser for some time now, so that would be my preference. I just think a "name brand" browser would be easier for other users, even if that were a lot of work. Unfortunately I don't know enough to help. :(
 
I'm successfully using PaleMoon on Eee PC 900. This is a 900MHz i686 Celeron. With quite large probability Pyra will be computationally faster.
The key things here:
1. Do not use more than 3 tabs for applications.
2. Enable JS on one or two.
3. Use obsolete Flash player for YT.

Details:
1 - there may be more than 3 tabs open, but unloaded or without complex things (viewing static page or sites generated locally from other sites are OK).
2 - NoScript + whitelist. And I recommend it for everyone as it greatly improves security by the cost of knowledge who is trying to mess with your computer :).
3 - Seriously, on every slower PC I found Flash videos running faster than HTML5. I don't know why. Probably HTML5 implementation uses some optimizations/accelerations/instructions not present since some Core iX revisions.
 
On slower computers, I've found you-get (or any other youtube downloader really, but you-get is what I use currently) piped into mplayer gives me even better results than flash does. Twitter vids play kind of strangely, but they do play at least.
 
I think the more capable the device, the more I will be tempted to push what it can do. Right now I'm fine for downloading things before playing them. (Though I'm glad I'm not like Stallman for the internet). The various adblock/noscript are defaults for qupzilla, which was nice.

The Pyra will be substantially faster, so maybe my demands will be greater.
 
Digging the topic again.
Recently YT hidden their Flash version in another place again and I found that for smooth playing of HTML5 video in 720px resolution, two 64-bit cores of my AMD CPU (old Turion at 2.2GHz) are burning in 100% usage. 360px videos eat about 75%. Would Pyra's SoC be able to play videos in such requiring technology?
 
I'm using qutebrowser on Linux (and Firefox on Windows). It's like the vim of browsers in terms of how it's controlled, I think it could be a good fit for the Pyra. (We could have a deb in the official Pyra repo.)
 
I'm using qutebrowser on Linux (and Firefox on Windows). It's like the vim of browsers in terms of how it's controlled, I think it could be a good fit for the Pyra. (We could have a deb in the official Pyra repo.)
I love it! But only with the webengine backend
 
Digging the topic again.
Recently YT hidden their Flash version in another place again and I found that for smooth playing of HTML5 video in 720px resolution, two 64-bit cores of my AMD CPU (old Turion at 2.2GHz) are burning in 100% usage. 360px videos eat about 75%. Would Pyra's SoC be able to play videos in such requiring technology?

I don't know for sure, but I'll just note that html5 video also eats more CPU on my 1.6GHz atom cored netbook than the old flash version does, but then again these days I use you-get to pull a video url out of any youtube url (and a few others too), and I pipe that into mplayer using the -p flag, and then I can play full 720p versions of things (albeit downscaled to the 600 vertical pixels of this screen) just fine. I suspect the Pyra may need a dedicated app to play the things well, like my netbook, my Pandora and my 3DS.
 
I don't know for sure, but I'll just note that html5 video also eats more CPU on my 1.6GHz atom cored netbook than the old flash version does
That's because the browser developers keep failing at integrating the HW acceleration APIs for video decoding into their sandboxing design, it's the same reason why Firefox lost its ALSA support entirely - piping data to an entirely different process is simply much easier to isolate.

Chrome only supports VA-API on ChromeOS, you need a compile flag for Chromium to enable it otherwise - and it is utterly broken on non-Intel GPUs, other APIs aren't supported at all. Firefox doesn't support anything on Linux to begin with. Flash at least had buggy VDPAU support.

Not sure how it's on Windows, but they face the same problems there - and Flash generally runs more efficient than on Linux.
 
That's because the browser developers keep failing at integrating the HW acceleration APIs for video decoding into their sandboxing design, it's the same reason why Firefox lost its ALSA support entirely - piping data to an entirely different process is simply much easier to isolate.

Chrome only supports VA-API on ChromeOS, you need a compile flag for Chromium to enable it otherwise - and it is utterly broken on non-Intel GPUs, other APIs aren't supported at all. Firefox doesn't support anything on Linux to begin with. Flash at least had buggy VDPAU support.

Not sure how it's on Windows, but they face the same problems there - and Flash generally runs more efficient than on Linux.
Hmm, I guess this is why watching youtube through the app on my phones and tablets makes them last longer than in the browser. I like the experience better in a browser but man that drains the battery.
 
This is not working in Debian 10 because it needs more recent libc6 and libstdc++6 packages only available in Debian 12 or Sid.
So only the ESR version is officially provided.
However, there are still armhf builds for Ubuntu 18.04 Bionic which is even older than Debian 10 Buster.
 
The recent non-ESR Firefox can be installed from the "Mozillateam" repository on Ubuntu's Launchpad platform.

If you're on Debian 10, choose the package for Ubuntu 18.04 (firefox - XXX+build1-0ubuntu0.18.04.1~mt1)

To find the actual .deb file you have to scroll to the bottom where you find the armhf.deb.

Install with
$ sudo dpkg -i firefox-----.deb

Here's a quick download -> link <- to Firefox 117.0.1.

If you like, you can also try the beta versions:


It is faster than the ESR browser you get officially in Debian and has comparable performance to Vivaldi!
 
Last edited:
Can you build firefox from the source on the pyra it's self? That would be cool... I'm wondering how long it would take to do a full clean build.

I used to build mozilla on a 500MHz powerpc and it took 10 hours.
 
Can you build firefox from the source on the pyra it's self? That would be cool... I'm wondering how long it would take to do a full clean build.

I already tried, that's what you get
Bash:
ifeq (armhf,$(DEB_BUILD_ARCH))
ifeq (,$(shell grep -l cpu:type:aarch64 /sys/devices/system/cpu/modalias))
    # There is not enough memory in armhf userspace with a 32-bits kernel.
    $(error Unfortunately cannot build on armhf. Try a 64-bits kernel)

I also tried cross compiling non-ESR versions on AMD64 and ARM64, but in my case they fail after several hours...

So the Mozillateam builds are the best we can get at the moment.
 
Last edited:
Can you build firefox from the source on the pyra it's self? That would be cool... I'm wondering how long it would take to do a full clean build.

I used to build mozilla on a 500MHz powerpc and it took 10 hours.
I've just built latest FF ESR under Slackware ARM 15.0 on a Pyra-like devboard. It's long !
Next time I'll try to do that in one pass and check the time it takes.
 
The new Vivaldi 6.2 promises to be much faster. I tested and it now starts the browser with my open tabs approx. 5 seconds quicker!
But I also recommend the non-ESR Firefox from here if you appreciate a browser not based on chromium.
 
Back
Top