Basilisk was reforked by the Pale Moon team and a new release is available

5 points by AnarchistNode7 ↗ HN
http://basilisk-browser.org/download.shtml

Moonchild productions have decided to refork their Basilisk browser code in form of the Firefox 52 Esr Base code, as their first attempt using a code beyond FX 52 was impossible to use for their reasons because of all the new code (Rust and so on) was too hard to remove.

https://github.com/MoonchildProductions/UXP - the new repository of Basilisk new

UXP will be also coming to Pale Moon - The old V24 based UI with a more modern engine behind.

But there is a big issue:

TLS 1.3 can not be implemented because Mozilla did a rewrite of NSS in a newer version of Visual Studio and Pale Moon and Basilisk, being created with an older variant of that program are so far not compatible with the requirements for TLS 1.3 related files and a work-around must be found.. if it is possible at all, which is yet highly unsure.

What is present since the first release of the new fork-point:

http://basilisk-browser.org/releasenotes.shtml

7 comments

[ 3.8 ms ] story [ 10.2 ms ] thread
Would anyone of you use a browser which is not able to support TLS 1.3?
That would be ok for now, but I wouldn't use one with what sounds like an unsupported fork of a core security library.
Right now, yes.

Once even TLS1.2 becomes deprecated, it is time to switch if it would be clear that an upgrade would be impossible from the makers side of affairs.

Or the moment you have to learn from the makers that they simply can't do that on their own.

Why not use mingw64 which is actively maintained instead of some ancient visual studio version? It certainly looks possible [1]. Taking a look and Pale Moon's dev page [2] I see that they are using VS2012.

[1] https://developer.mozilla.org/en-US/docs/Mozilla/Developer_g... [2] https://developer.palemoon.org/Developer_Guide:Build_Instruc...

My personal guess is that the Pale Moon/Basilisk team has no clue how to use other compilers.

I mean, what for another reason... logical... reason would be around for staying with an ancient version?

And that is rather sad that they are seemingly unable to broaden their knowledge.

If you maintain a browser project you should have at least a more broad know-how or you should have someone on board who provides you with that if you on your own are missing that.

I value more choice in the browser market away from the Chrome or Chrome clones or almost Chrome clones - but at the same time i think also that the Pale Moon team is way too arrogant and sharp tongued against Mozilla and others seen from their own lack of abilities to find a work-around or being able to get a more complex job done.

In that you are right. Moonchild, Tobin and the other ones may be able to solve browser internal issues, but everything which is reaching a certain size is "patches welcome".

And to make it worse, they are rather rude against Seamonkey developers or Mozilla, or Brave or Vivaldi or against guys who dare to fulfill not 1000% the branding rules of Moonchild when creating an own version of Pale Moon/Basilisk.

While i would defend Pale Moon against Firefox trolls as i am in support of minorities, i am less than appalled to see how they are acting towards certain Linux guys or even own users who are insulted for creating forks for XP.

The whole Pale Moon project is a double edged sword.

https://github.com/jasperla/openbsd-wip/issues/86

That says more than anything.

My personal reason not to use Pale Moon - and instead Otter-Browser. I also would recommend Vivaldi more than Pale Moon.

If you are creating a browser it is pure illusion to think you can also handle engine stuff. That is such a complex matter - HTML5, CSS3, ecmascript - Take a look in the past. Moonchild, Tobin and the others had to re-base Pale Moon to be able to be compatible with today's web.

And now that should be possible when they are basically just doing it another time? Stuff does not stay complex, it gets worse the more time is progressing.

And if they have been unable to implement promises or shared array or whatever on their own.. how they actually could believe they can implement upcoming features?

If you are forking something, make sure the engine work is done by someone else. That is the only valid way to get stuff done and not becoming outdated.