4 ms·

Forked software is usually reasonable, but for me, the sheer complexity of the graphical, interactive web sadly begets an exception for modern browsers. Even if

Forked software is usually reasonable, but for me, the sheer complexity of the graphical, interactive web sadly begets an exception for modern browsers. Even if much of the work is offloaded to the corporations backing modern free/libre browsers (e.g. keeping up with new web standards and technologies), it certainly goes without saying that rebasing with upstream or even just applying the latest security fixes is no trivial task I would entrust any browser fork with minimal developer backing with. This problem is especially worsened with the kind of user base that firefox forks tend to attract, from what I have seen. These users tend to ask very high-level questions e.g. "is waterfox more secure than pale moon" and will usually blindly switch from one fork to the next based on poorly-backed, unsubstantial crowd opinion. No userbase means waning support + maintenance. If you ask me, I think in the very special case of browser technologies, it would be more beneficial if the developers and users of firefox forks directed their energies towards making generally desirable changes in upstream.

elagost 8y ago
Not just the weird habits of the users, either. I have way more confidence that Mozilla will fix issues in a timely manner than the one developer behind Waterfox, or the several behind Palemoon. Especially when the forks are depending on upstream to fix things for them. A few years ago there was a build of Waterfox that was substantially late because the one developer had exams.
- kbenson 8y ago
  It seems like the solution to this would be to have the build system reproducible from a base image with everything other than the code repo required to successfully kick off a build other than the code repo itself. Uploaded (or made available to upload yourself) to any of the cloud providers (or run locally in a VM), it would allow you to sync the repo and kick off a build for any supported architecture. Dev not available to integrate a pull request and start a build? Download the appropriate build arch image, fire up VirtualBox, sync the repo (and apply a pull request if the dev hasn't had a chance to do that yet) and start the build script. This doesn't entirely solve the problem, if nobody has submitted a fix yet, and you don't know enough to pull in the upstream fix and merge it yourself, you're at the mercy of some other user having that knowledge and making a pull request. It does close the gap somewhat though. Are there existing projects to help get to this level of build reproducibility that can serve as a base to use? It would be awesome to know people are already working on making this easy to adopt.
  - JetSpiegel 8y ago
    THis is not the issue, I think. See: https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/firefox https://git.archlinux.org/svntogit/packages.git/tree/trunk/P... The problem is that it is a giant codebase, you need to compile C++, Rust for hours. Even pulling the latest code is an ordeal. It's not feasible on lowly workstations and garden variety cheap cloud VM builders, the performance is just crap.
    - elagost 8y ago
      When I ran Gentoo on my laptop, emerging Firefox took far longer than compiling even the Kernel. Around 90 minutes, I think.
    - kbenson 8y ago
      I was speaking more to the general case of projects with small bus factors for deploying. And slow is moistly irrelevant to the point, which is making something possible which largely wasn't before.
jammygit 8y ago
Some of the changes are alternative defaults however. That isn't something one can just merge upstream since there are busi ESS and product reasons for Mozilla to reject certain changes
Tsubasachan 8y ago
I am using Fennec F-droid and some of the things that the developers did are unlikely to be welcomed in the main branch of the FF tree.
- elagost 8y ago
  What's the difference between those branches? Any explanatory links, or care to elaborate?
  - Tsubasachan 8y ago
    "focused on removing any proprietary bits found in official Mozilla's builds" Yeah Mozilla isn't going to like that.

elagost 8y ago

Not just the weird habits of the users, either. I have way more confidence that Mozilla will fix issues in a timely manner than the one developer behind Waterfox, or the several behind Palemoon. Especially when the forks are depending on upstream to fix things for them. A few years ago there was a build of Waterfox that was substantially late because the one developer had exams.

kbenson 8y ago
It seems like the solution to this would be to have the build system reproducible from a base image with everything other than the code repo required to successfully kick off a build other than the code repo itself. Uploaded (or made available to upload yourself) to any of the cloud providers (or run locally in a VM), it would allow you to sync the repo and kick off a build for any supported architecture. Dev not available to integrate a pull request and start a build? Download the appropriate build arch image, fire up VirtualBox, sync the repo (and apply a pull request if the dev hasn't had a chance to do that yet) and start the build script. This doesn't entirely solve the problem, if nobody has submitted a fix yet, and you don't know enough to pull in the upstream fix and merge it yourself, you're at the mercy of some other user having that knowledge and making a pull request. It does close the gap somewhat though. Are there existing projects to help get to this level of build reproducibility that can serve as a base to use? It would be awesome to know people are already working on making this easy to adopt.
- JetSpiegel 8y ago
  THis is not the issue, I think. See: https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/firefox https://git.archlinux.org/svntogit/packages.git/tree/trunk/P... The problem is that it is a giant codebase, you need to compile C++, Rust for hours. Even pulling the latest code is an ordeal. It's not feasible on lowly workstations and garden variety cheap cloud VM builders, the performance is just crap.
  - elagost 8y ago
    When I ran Gentoo on my laptop, emerging Firefox took far longer than compiling even the Kernel. Around 90 minutes, I think.
  - kbenson 8y ago
    I was speaking more to the general case of projects with small bus factors for deploying. And slow is moistly irrelevant to the point, which is making something possible which largely wasn't before.

jammygit 8y ago

Some of the changes are alternative defaults however. That isn't something one can just merge upstream since there are busi ESS and product reasons for Mozilla to reject certain changes

Tsubasachan 8y ago

I am using Fennec F-droid and some of the things that the developers did are unlikely to be welcomed in the main branch of the FF tree.

elagost 8y ago
What's the difference between those branches? Any explanatory links, or care to elaborate?
- Tsubasachan 8y ago
  "focused on removing any proprietary bits found in official Mozilla's builds" Yeah Mozilla isn't going to like that.