a dangerous idea: Force e10s on Basilisk

Board for discussions around the Basilisk web browser.

Moderator: Basilisk-Dev

User avatar
Disil07
Moon lover
Moon lover
Posts: 76
Joined: 2021-03-31, 05:15
Location: Indonesia
Contact:

a dangerous idea: Force e10s on Basilisk

Unread post by Disil07 » 2022-01-11, 11:00

It is possible to "force" multiprocess (yeah e10s) on basilisk. Although I don't recommend using this on your daily profile (unstable), this will increase performance on "that heavy-bloated chromey website, like discord, facebook, and those big boys.

How to enable multiprocess
1. Go to about:config, and type in browser.tabs.remote.autostart. Set them to true
2. Now go to preference dom.ipc.processCount, set the value to limit how much process you want (e.g if you set it to 1, that means it will only use 2 process at the time).
3. Restart the browser, and try to open sites (especially heavy sites), and take a look at Task Manager (on windows). If the basilisk.exe process still showing 1 process, then go to about:config, create a new preference (boolean) called browser.tabs.remote.force-enable and set it to true.
4. If the basilisk.exe process are more than one, then you're finished. Compare the performance to the usual one-process mode.

Consequences
A lot more crash will happen. A LOT. You've been warned. This 'experiment' that i found today is pretty interesting, maybe those with the good ol' FF 52.9 users will get a performance boost.

Edit: thanks for 'reprimanding' my behaviour. Am aware that this idea was a very dumb idea :angel:
Last edited by Disil07 on 2022-01-11, 13:44, edited 2 times in total.
Debian 12 Bookworm - KDE Plasma 5.27
Intel Celeron N5100 - 4 gigs of RAM - 256 gigs of SSD

I can barely speak english, so bear that in mind when talking to me

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 35402
Joined: 2011-08-28, 17:27
Location: Motala, SE
Contact:

Re: Force e10s on Basilisk

Unread post by Moonchild » 2022-01-11, 11:24

You're doing something really stupid AND dangerous (from a security perspective).
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite

User avatar
athenian200
Contributing developer
Contributing developer
Posts: 1481
Joined: 2018-10-28, 19:56
Location: Georgia

Re: Force e10s on Basilisk

Unread post by athenian200 » 2022-01-11, 11:33

If you think e10s is a good idea or "the right move," then you are sort of opposing yourself to some of the project's main goals. That was Mozilla's stance, and if you support it then logically you should use modern Firefox because they have taken that idea to its logical conclusion.

A major part of our goals include finding alternative ways to improve performance because e10s is considered undesirable. I would think anyone would understand that activating half-baked e10s support in a codebase where it has been deprecated for years rather than further developed is probably not the best idea, even if you do agree with it conceptually.
"The Athenians, however, represent the unity of these opposites; in them, mind or spirit has emerged from the Theban subjectivity without losing itself in the Spartan objectivity of ethical life. With the Athenians, the rights of the State and of the individual found as perfect a union as was possible at all at the level of the Greek spirit." -- Hegel's philosophy of Mind

User avatar
Disil07
Moon lover
Moon lover
Posts: 76
Joined: 2021-03-31, 05:15
Location: Indonesia
Contact:

Re: Force e10s on Basilisk

Unread post by Disil07 » 2022-01-11, 11:43

athenian200 wrote:
2022-01-11, 11:33
If you think e10s is a good idea or "the right move," then you are sort of opposing yourself to some of the project's main goals.
I still agree on this project main goals. But this is only as a 'technical alternative'. Of course I don't support this whole e10s idea, but this is interesting.
I would think anyone would understand that activating half-baked e10s support in a codebase where it has been deprecated for years rather than further developed is probably not the best idea, even if you do agree with it conceptually.
It is not the best idea, but it does work. For me I also don't use them in general, only for a rare occasion where lags are unbearable.

For those who interested in trying this, again, don't use them in everyday use.
Debian 12 Bookworm - KDE Plasma 5.27
Intel Celeron N5100 - 4 gigs of RAM - 256 gigs of SSD

I can barely speak english, so bear that in mind when talking to me

User avatar
Disil07
Moon lover
Moon lover
Posts: 76
Joined: 2021-03-31, 05:15
Location: Indonesia
Contact:

Re: Force e10s on Basilisk

Unread post by Disil07 » 2022-01-11, 12:43

Moonchild wrote:
2022-01-11, 11:24
You're doing something really stupid AND dangerous (from a security perspective).
I do, this is just a fun experiment to do. Imma check the security perspective later.
Debian 12 Bookworm - KDE Plasma 5.27
Intel Celeron N5100 - 4 gigs of RAM - 256 gigs of SSD

I can barely speak english, so bear that in mind when talking to me

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 35402
Joined: 2011-08-28, 17:27
Location: Motala, SE
Contact:

Re: Force e10s on Basilisk

Unread post by Moonchild » 2022-01-11, 12:44

It's not an alternative.
You should never run Basilisk, Pale Moon or any other application that builds on our platform code in "multi-process" mode. It's wholly unsupported, unsafe and can easily lead to system-wide data loss or security vulnerabilities.
Our development has not accounted for this kind of use, does not have the necessary safeguards, and forcing it into using the vestiges of our Mozilla legacy's plumbing for it will not work safely or reliably. You shouldn't even pretend this is a viable way to run our software. It is not.

EDIT: In fact, it shouldn't even be possible to start it in this mode the way you describe; I double-checked our code and it was already hard-disabled. It is however possible that it still gets enabled regardless (in some other location, based on the pref) which is a really really bad idea.
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite

User avatar
Disil07
Moon lover
Moon lover
Posts: 76
Joined: 2021-03-31, 05:15
Location: Indonesia
Contact:

Re: Force e10s on Basilisk

Unread post by Disil07 » 2022-01-11, 13:16

I double-checked our code and it was already hard-disabled. It is however possible that it still gets enabled regardless which is a really really bad idea.
Then I think this should be very-hard-disabled right? But because basilisk is no more in development unless someone take it, then we need to keep this vulnerable trick (like Java applets back in the day) to be as secret as possible (although it was my fault for opening this whole pandora's box.
Debian 12 Bookworm - KDE Plasma 5.27
Intel Celeron N5100 - 4 gigs of RAM - 256 gigs of SSD

I can barely speak english, so bear that in mind when talking to me

User avatar
Eduardo Lucas
Moon lover
Moon lover
Posts: 94
Joined: 2021-07-08, 13:08
Location: São Paulo, Brazil

Re: Force e10s on Basilisk

Unread post by Eduardo Lucas » 2022-01-11, 13:16

Sorry, i've never wanted to join into this, but it makes me suffer in absolute horror to see someone suggesting multi-process inside this forum.

The only thing i have to ask is: Have you never thought about the possibility that "lags" (sorry but this term is not adequate for what you are complaining about) may only get "lighter" in this kind of browser operation because you are simply using a dirty way of boosting a software performance that forces your cpu to work more and waste more power (as using multiple processes to do the heavy JS stuff modern heavy websites do tends to harshly abuse of that, as sites are made for that), hogging your operating system.

Neither Windows NT nor Linux were expected to do that when all guys started them with early 90s views about operating systems. they were designed for multiple processes in applications, but one for any individual application (not aware of these system designers from the era supporting the opposite), using threads inside these processes, as that removes risks in doing messaging between processes inside userland, and is more adequate for counscious resource-efficient development and not pressing up classic system architectures and kernels. Not even messaging between modules in a microkernel design from the past this is viable, because messaging is usually inefficient and will only increase performance by brute forcing hardware to do the dirty job, which can have adverse consequencies in lifespan or raw performance in critical scenarios. In fact, messaging and complex interfacing between programs, APIs and modules with microkernels brought up difficulties in servers and desktop operating systems, which made most simply let them go to RTOS, embedded markets and others.

The idea of using multiple processes in a program for speeding up things and doing very hard jobs like web 4.0 tiktok video watching is something that is against everything i've learned in university and personal learning about operating systems, because it violates core concepts from OSes we use. Big companies likely adopted the 'solution' (for the problems they themselves created) for browsing safety and speed, because they had interests such as turning the internet into a proprietary network for entertainment purposes and do not give a crap about your computer, your security or your smartphone. (and even google got screwed as they saw china launching their 5-10 second video network and overtaking their search engine in traffic). Pale Moon tries to solve the issues by not using an absurd violation of software engineering and operating system principles, but dealing with it in the smart way. If PM (this is obviously not happening) ever started using multiple processes, i would not stay, because i want my hardware alive without busting up my motherboard with heavy voltages it's not designed for, and letting huge doors open by IPC to anyone who can break inside my computer by ways which do not directly involve the miraculous zeus-designed E10 or the browser at all, but OS vulnerablities that can expose the processes, exploited by outside attackers that can get into the machine even without using the browser as the front door by malicious JS or whatever but using its exquisite multi-processes as an weapon.

Sorry for the rant, moderators and developers, especially because i may be intrusive (as i'm not even close to the team in capabilities and have no part on it, being just an user) and harsh on this one

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 35402
Joined: 2011-08-28, 17:27
Location: Motala, SE
Contact:

Re: Force e10s on Basilisk

Unread post by Moonchild » 2022-01-11, 14:21

Disil07 wrote:
2022-01-11, 13:16
I double-checked our code and it was already hard-disabled. It is however possible that it still gets enabled regardless which is a really really bad idea.
Then I think this should be very-hard-disabled right? But because basilisk is no more in development unless someone take it, then we need to keep this vulnerable trick (like Java applets back in the day) to be as secret as possible (although it was my fault for opening this whole pandora's box.
Just stay out of about:config :P

And it will have to be something for whomever wants to take over Basilisk to tackle. I'm not going to go back in for something like this where you're doing something stupid to begin with.
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite

User avatar
CodeLurker
Hobby Astronomer
Hobby Astronomer
Posts: 28
Joined: 2022-02-16, 18:57

Re: a dangerous idea: Force e10s on Basilisk

Unread post by CodeLurker » 2022-02-17, 03:27

I for one support multi-threading in Basilisk/PM. FF got taken over by one guy when another said something that was considered "homophobic" in NewSpeak. That may have had something to do with the e10s debacle and the forced incompatibility with all the old plugins. I don't suppose it will be easy, but you have the opportunity to do something FF should have done: go multiprocessing without breaking all the old plugins. I envision that some just can't be made to work; and there would be a database of them. Either they would be run in single-processing mode, or blocked from being used when multiprocessing is enabled. Some PM addons could be re-written to be multiprocessing-safe or thread-safe. Maybe the idea is impractical. It seems like some might not have to be thread safe, since they are doing nothing that needs two threads. The thing about what FF did, is they broke all the old ones before they were sure they needed to, because they wanted to sabotage their old plugin ecosystem, and adopt Chrome's. If it is possible to not break XUL plugins but go multiprocessing, it would put the lie to FF sabotaging their old plugin ecosystem more or less; by making it clear that going to WebExtensions was a matter of choice, and there's nothing inherently incompatible about XUL plugins and multiprocessing. It can be the browser FF should have been, even though WebExtensions aren't supported - IF mixing e10s and XUL can play together nicely, on some level, in principle.

Locked