Fedora-34-Beta and Firefox

I used Ubuntu Budgie (up to 20.10) for years with Firefox and the only problem I had with it was its refusal to play BBC News videos (Youtube etc were fine). Now a bug in the installer Ubiquity has made it impossible for me to continue with Ubuntu 21.04. I haven’t used Fedora for years so I am effectively a Fedora newbie. I have a 3.4GHz x2 processor and 4GB memory of which only 3.2GB can be used because of a BIOS bug.

I am very impressed with Fedora-34 + Gnome-40 and would be very happy to stick with it now - except that Firefox keeps hanging. Chromium is fine. Not sure whether it’s worth posting a message on the Firefox forum as well.


Welcome, I also came from Ubuntu 20.10 :smile: Got scared away by the gorilla :gorilla:

I am also on Fedora 34. I use Firefox for my daily browsing and I have not had any issues after upgrading to F34 last week. I am using the flatpak from flathub.

Which Firefox are you using? There are at least 3 different available: RPM, Fedora Flatpak, and Flathub Flatpak.


Good question, from “Software” fedoraproject.org V87.10. It runs from a terminal with “firefox” so I assume it must be an RPM.
(I didn’t realise there could be two versions of a Flatpak!)

Yes, if it runs as “firefox” from a terminal, it is the RPM version. It is included in the default F34 installation.
You can try out the flatpak versions as well - they can be installed side-by-side with the RPM version. You need to launch them from the icon launcher (or write flatpak run org.mozilla.firefox in a terminal if you are having trouble finding the right launcher :sweat_smile: )

I guess the rest 800MB are reserved for graphics memory, if you use an integrated graphics card.

@eivinh Flatpak now installed, and it’s not seized up so far. It hadn’t occurred to me to try that.
Why did you switch from Ubuntu 20.10 (if you don’t mind me asking).

Good question — I’ll make an attempt at keeping it short not to become totally off-topic :cowboy_hat_face:
It was a combination of me changing jobs (they supported Ubuntu on the work computers), the graphics on my father’s computer becoming all messed up when he upgraded from Ubuntu 18.04 to 20.04, and I had grown a little tired of the “brown desktop” and was ready for something different.
Oh, I almost forgot — I also made an attempt at replacing Raspbian with Ubuntu IoT to get over to a proper 64-bit distro on my Raspberry PIs, but it kept segfaulting here and there. So I looked around for an alternative both for the desktop and for my embedded devices, and I ended up with 64-bit Fedora IoT for my PIs and Fedora Silverblue on the desktop. They are a bit different than what I was used to, since they are both based on having an immutable root filesystem.
There are some things which would be nice, like being able to install the odd snap application which would not be available as Flatpak or AppImage, but that’s not so important to me. I actually have an Ubuntu VM available, anyway. Overall I find the technology to be better and more current in Fedora.
It actually seems to be a better fit also on my father’s old computer, where he just needs a few applications extra installed as RPMs, and the rest can be from Flatpaks. Quite clean and easy to roll back if something gets messed up in an upgrade.

My reason for switching was that when installing 20.10 I got a “No EFI partition” error which went on to say that it would be risky continuing the installation. I re-installed 20.04 then did on online upgrade. When it got to installing 21.04 Beta I got the same thing again, but obviously couldn’t go back to 20.10 for the above reason. I suppose it might have been possible to go back to 20.04 then do two upgrades, but that didn’t occur to me.

A problem at the installation stage is very hard to fix, because you haven’t even got a working system. I didn’t want to take any chances at that stage because partitions are being selected and formatted so the data could get wiped (of course I had a backup or two, but it’s a bad idea to rely on those). This is a known Ubuiquity bug which has be around and unfixed for a while, I don’t think that is a satisfactory situation.

As an aside, I have been trying to get an application published as a Debian package for quite a while. but IMHO it was an “old boys’ club”. I also tried a Snap - but that is strangely complex and there are “Gurus” about but they don’t seem to know much. I then tried a Flatpak which is much more straightforward (apart from not being able to include dependencies) and got a great deal of help - it’s now been published. I have also had a go at an RPM package and may attempt to publish that later in the year. I get an impression of much more positive attitudes to developers in this community.

1 Like

Thank you for sharing your experiences, @chrisofbristol. Installer bugs which remain unfixed is as you say a quite unsatisfactory situation. :confused:

Although I haven’t experienced it first-hand, I did get a feeling the last few years that the Debian packaging process has gotten more and more stuck in old, inefficient ways - wasteful of good developer resources.
Fedora feels much more on top of the distro processes and flow - and I don’t expect bugs to linger around for long. The best part is that the fixes usually (as far as I know) are upstream fixes which have trickled down, not distro-patches being (proudly) carried around.
That being said, Debian of course also caters for long(ish)-term support, and needs to backport a lot of fixes to preserve stability. Running Debian unstable would be closer to Fedora regarding updates from upstream.

It’s great that you were able to publish your software! As an end-user, I like the cleanliness of the flatpaks - installation and removal are very straight forward, without leaving unused packages on the system. But sometimes the sandboxing can lead to confusing situations where drag-n-drop doesn’t work, but opening the file from inside the application (from the same location), works.

The installer has now allegedly been fixed. I don’t know whether my moaning about it helped prompt the developers to do so.

“the Debian packaging process has gotten more and more stuck in old, inefficient ways”
IMHO large organisations with a lot of power/monopoly tend towards bureaucracy and inefficiency.

I’ve given a lot of thought to the pros and cons of the packaging methods - only from the point of view of someone developing a small, simple user-oriented package obviously.

Flatpaks have many advantages - a straightforward method and non-reliance on what is already installed, and usable on any system that can run the platform. The snags I saw were 1) I couldn’t find any way to include a dependency without re-compiling that whole package. I wasn’t capable of that so had to publish a cut-down version without it. 2) The number of different platforms - earlier/later, with/without Gnome - that seemed no different to having to create a package for each distribution.

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.