Wouldn't a more proper approach be to bring the plug-ins forward rather than drag the browser backwards?
It's a maintenance challenge just keeping up with the browsers we currently have. I'm not sure adding yet another browser to maintain is the best idea.

freemor wrote:

Wouldn't a more proper approach be to bring the plug-ins forward rather than drag the browser backwards?
It's a maintenance challenge just keeping up with the browsers we currently have. I'm not sure adding yet another browser to maintain is the best idea.

In principle, yes, that would be the ideal solution. However, the number of such plug-ins is not small, the refactoring/rewriting effort required in many cases is substantial, and in some cases equivalent WebExtension APIs simply don't exist. A few have been slowly added, but some important ones have not (or may not ever be added, due to inherent changes of architecture).

Of course, that is not to say maintaining browsers is an easy/trivial task.

i would consider it a pretty poor assessment to say this is "dragging the browser backwards" - that is a hard fork (the "Pale Moon"/"Basilisk" browser) that was forked when that firefox (~v52?) was current - it is actively developed by that upstream and moving "forward" in its own direction - the hyperbola iceweasel version is mostly likely just some FSDG modifications to that

as eli suggested, many addon devs prefer the extra capabilities of the classic XUL system, which enjoyed a very long and fruitful life - the concept in of itself has merit, in that it would bring some unique capability to parabola - what remains to be seen is how widely the demand is for those "legacy" addons and the longevity of this browser strain

another thing i could say is "yes, parabola has too many browsers already" that is true; but this one does bring something unique to the table - if that is the main concern stopping this from being adopted; i would suggest dropping some of the others such as midori, qupzilla, epiphany, or any of several others that are all essentially webkit/webengine clones that offer nothing unique

bill-auger wrote:

i would suggest dropping some of the others such as midori, qupzilla, epiphany, or any of several others that are all essentially webkit/webengine clones that offer nothing unique

qupzilla(falkon) could very well be removed as it depends on webengine and qutebrowser will very soon drop support for webkit.

I was able to package iceweasel-UXP by using the sourcefiles from the hyperbola repos, and just changing icu to parabola's updated version and autoconf-legacy to autoconf2.13 in the PKGBUILD.

Nice work hnasiet

Feel free to attach the PKGBUILD you created to this BR

freemor wrote:

It's a maintenance challenge just keeping up with the browsers we currently have. I'm not sure adding yet another browser to maintain is the best idea.

I'm with freemor here. Just because we can, doesn't mean we should.

or, as i suggested, whether or not we do add this one, we could actually drop a number of others from the workload without sacrificing any use-cases, namely the numerous, barely distinguishable, light-weight graphical web browsers (mostly webkit/webengine clones), all of which are in [pcr] or being re-built in [libre]

• konqueror
• midori
• netsurf
• arora
• epiphany

of those above, only konqueror has dependents

note that the arch builds of the following apparently meet the FSDG:

• 'eolie'
• 'surf'
• 'dillo'

• 'elinks'
• 'w3m'
• 'links'
• 'lynx'

• 'icecat'
• 'iceweasel'

Joined this to #2287 As it is a very similar request.

It should also be noted that Mozilla had very good security reasons for making the switch away from the old plugin system.

I think we should include Iceweasel-UXP & Icedove-UXP, but drop Iceweasel and Midori.

i think we determined that iceweasel-uxp was a LTS (ESR)
browser; so if this would replace another browser in parabola,
icecat would be the one - many people want the rolling release
mozilla browser - we can not do without it

That's logical, but should we rename Iceweasel to Icedog? The names Iceweasel and Iceweasel-UXP are confusingly similar.

More importantly, basing a browser on such old code makes security patches harder. Pale Moon’s developer tries to keep up with Firefox security patches, but he’s maintaining old code that Mozilla has abandoned. Mozilla reportedly has over a thousand employees, while Pale Moon has one primary developer, trying to maintain a huge amount of code that’s becoming increasingly outdated. The older code also omits features that help make modern browsers so secure, like the multi-process sandboxing features that have finally arrived in Firefox Quantum.

Source: https://www.howtogeek.com/335712/update-why-you-shouldnt-use-waterfox-pale-moon-or-basilisk/

Not advocating against UXP-based browsers, but if this is true, I think it is something important to consider. I personally wouldn't like Iceweasel or Icecat to be replaced, or Epiphany to be ditched, because I don't think limiting browser choice would do any good for Parabola. In any case, I believe replacing Iceweasel with Icecat would be the best course of action, if there's really need to save maintenance.

I personally don't think XUL addons support is a strong enough argument to make a move like this.

Btw, I'm writing this from Serpent, an unbranded version of Basilisk I found in the AUR. Looks like it supports DRM and comes with search engines that are bad for privacy, so just like Firefox, it would need some patches to make it FSDG compliant.

Pale Moon has one primary developer, trying to maintain a huge amount of code that’s becoming increasingly outdated.

this is something of a digression; but i must qualify that
statement; because it is not a general truth - it is more of a myth,
true only in pathetic cases (like almost anything related to the web)

such an opinion may be totally accurate for a behemoth like mozilla,
which essential job is to interact with arbitrary foreign machines;
but such software (software which is useless offline) is the exception,
not the rule (and let us hope that it stays that way)

if all software were designed like mozilla is currently, it would be
impossible to maintain any rolling distro; only because it's software
versions differ sufficiently from ubuntu - in the mind of web devs,
ubuntu is the only *nix (if any), which deserves even a paltry level
of support - luckily, most important software is not so opinionated
or as fragile as webby software

there is nothing about "old code" which makes it inherently
unstable, dangerous, or unmaintainable - well-designed code is
easily maintained indefinitely (it should still work in 100 years,
with only minor tweaks) - usually one maintainer is enough, for even
the largest code-bases in "maintenance" mode - "maintenance" mode,
being that no new features are being developed; but perhaps only
bug fixes and compiler compatibility tweaks are applied - presumably,
that describes palemoon: the only task at hand, is to keep it working;
which is usually accomplished quite easily

i maintain several such code-bases, in addition to parabola - i can do that,
because each requires only about one hour per year of my time to maintain
properly (because they are written with long-term sustainability in mind) -
for some projects, that hour of maintenance may also be enough to prepare
and build a new debian package, and find an uploader/mentor to publish it
to debian or librazik afterward (a task which is strictly extra, beyond
the scope of conventional upstream maintainance duties)

the common misconception that old code is dangerous, unstable,
or whatever, is nonsense - it is myopic development methodology
which perpetuates the fallacy (the fetish for novelty); by making
their program's compatible only within narrowly constrained
operating or build environments (with mozilla, that range seems to
be centered on the current ubuntu system) - that predicament is
easily avoided, if the author desired long-term sustainability/robustness
of their software; but some devs have no desire or interest to ensure
that this month's release still works next month (or even this month,
on any OS other than MS, apple, android, and ubuntu, and possibly redhat)

that is the source of the myth, that "old code" is "bad code"
or difficult to maintain - generally, it is not - any counter-examples
are unmaintainable by design, not by nature

there is nothing about "old code" which makes it inherently
unstable, dangerous, or unmaintainable - well-designed code is
easily maintained indefinitely (it should still work in 100 years,

But, is that the case with Palemoon and Basilisk codebases? They are based in old versions of Firefox, which means, they are as well-designed and future-proof as Mozilla wanted them to be at that time, plus however maintainable Palemoon devs have managed to get them to be.

the common misconception that old code is dangerous, unstable,
or whatever, is nonsense - it is myopic development methodology
which perpetuates the fallacy (the fetish for novelty)

Granted, old code is not necessarily dangerous or unstable. What I believe is potentially dangerous and unstable is a huge network-connected codebase. Web browsers have a huge surface of attack, and keeping them up in terms of security requires whole teams of security researchers actively detecting and patching vulnerabilities. Either you hire a team of security researchers, or you reduce the surface of attack of your browser (e.g. drop JS or WebRTC). The Internet is wild, and everyone is in danger.

but some devs have no desire or interest to ensure
that this month's release still works next month (or even this month,
on any OS other than MS, apple, android, and ubuntu, and possibly redhat)

I agree.

that is the source of the myth, that "old code" is "bad code"
or difficult to maintain - generally, it is not - any counter-examples
are unmaintainable by design, not by nature

In my experience, unmaintainable code is very easy to produce, even accidentally.

They are based in old versions of Firefox, which means, they are as well-designed and future-proof as Mozilla wanted them to be at that time,

agreed: they wanted that code to compile in 2016, but not necessarily in 2015 or 2017 or today

"as future-proof as Mozilla wanted" was apparently: zero - so the "plus" is absent; but "only", what the hard fork and distros can do (ideally, not vendoring the kitchen-sink of deps and compilers), to counter the upstreams's perishable design philosophy, and to preserve what remains yet uncomplicated by it (eg: forking before rust became essential, or when mozilla still gave sufficient attention to 32bit arches)

what one might expect to follow from that, after all the work is done, is a browser which is perpetually missing the newest sexiest webby capabilities - thats fine; but we already have those - the typical webkit browser was designed specifically NOT to have any fancy features, and to be MUCH leaner, and has no libre issues

if that is an accurate description of this case, then the choice is obvious: do nothing, because parabola already has several "web browser without newest fancy features" - also, keep in mind that this is a long-term decision - in 5-10 years, parabola may as well describe those "ancient" mozilla forks as

"web browser without newest fancy features; but with all 15 year old features in tact"

how many web fans would want to use that browser? - i do not see a user-base for web software matching that description - that was just reiterating it concretely - eg: if none of them ever support webrtc/opengl/whatever-users-want-next, there may be no unique niche for them to occupy (preserving the old addons?), which is not already covered by a more mature browser, in parabola repos already (netsurf, qutebrowser, epiphany, many others)

<GRAB>

In my experience, unmaintainable code is very easy to produce, even accidentally.

</GRAB>