[sf-lug] Brave browser

Rick Moen rick at linuxmafia.com
Sun Apr 26 15:05:43 PDT 2020


Quoting Akkana Peck (akkana at shallowsky.com):

> I used Palemoon for a while, but I got increasingly frustrated with
> some of its quirks that weren't configurable; and then I started
> seeing noise about
> https://github.com/jasperla/openbsd-wip/issues/86
> about how Palemoon has to use its own forks of a bunch of system
> libraries. First, using forks of system libraries seems odd and
> makes me wonder why it would be needed, and second, the bug
> discussion seemed to suggest an unfriendly developer community.

I see a lot of spilled virtual ink complaining about Pale Moon's
'branding policy', including loud complaints on Devuan Project's 'DNG' 
mailing list (_not_ anything like your comments, to be clear, Akkana)
asserting that this somewhat truculent policy makes the software
proprietary.

And, with no objection to what _you_ said, I just wanted to comment that 
there's an obvious end-run around the branding policy, and in no way
does said policy prevent it from being open source. 

In fact, the somewhat surly remark opening that GitHub bug (obviously
written by one of the Pale Moon devs) points to that end-run:

   You must comply with the directive or you must disable official
   branding for your builds.

Just so.  Pale Moon wants all _official_ Pale Moon builds, ones with
their trademark branding, to be compiled the same way, using bespoke
libs.  Those of us who don't like that (including me) can easily have it
our way by swapping out the trademarked images for different ones and
giving the resulting binary a slightly different name -- exactly the
same way CentOS and Scientific Linux have always done with RHEL.

In this case, it'd be a lot easier than what RHEL rebuilds do:  You'd
basically maintain a patch script consisting of about a dozen or fewer
sed edits, and that's it.

Call it Pale Luna, or whatever.  Not exactly brain surgery.




More information about the sf-lug mailing list