Add --no-sandbox to Linux Launch
#262
Conversation
|
By the way, the main process of Atom/Pulsar is pretty sophisticated about handing off launches of new main processes to be handled by the existing one instead... I wonder why we need this launcher at all??? I just about always use the absolute path to the real 🤷 (But strictly regarding whether or not to merge this PR, please ignore. Just taking a step back to look at the larger picture.) |
Yeah some aspects here do seem a little weird, especially considering this launcher seems to be only used on Linux and MacOS, so obviously Pulsar can handle it's own when launching on Windows, so weird that this isn't done here. We could always investigate simplifying this to just rely on the main process itself, but wonder if we would lose being able to do stuff like this PR does. But otherwise thanks for the approvals guys! I'll go ahead and merge this one |
|
@confused_techie and @DeeDeeG, windows by definition never locks the terminal when you're running a GUI app, where Linux and Mac do. This shell script basically avoids locking the terminal. More complex answer - the main entry point of a Mac and Linux binaries are always the same, regardless if it's a graphical or console app - on these systems, all apps start the same but they connect with the graphics server after launch. On Windows, there are two different entry points of the app, one for consoles and other for graphical ones. That's why it never locks the terminal - because, by all means, that app ISN'T a terminal app, so Thera why Windows doesn't need the sh file |
|
@mauricioszabo Super interesting insight, but so that does mean we have to keep the script around. But thanks for taking the time to explain |
|
Just to check, this PR is only valid for .deb and .rpm releases isn't it? Not sure how to do this with the .appimage, the internal .desktop already has |
|
@Daeraxa we can always add |
|
Yeah i was going to look at adding it to the yarn script when i got back as well as experimenting with the appimage. |
For the record, and not to bump a closed PR thread, but I am of the belief this is not at all related to which graphics card or which driver you have. It affects all Linux distros with the Happens for me on an old intel machine with an with integrated GPU and happens for @Spiker985 on NVidia discrete graphics, apparently. Haven't had a chance to test on AMD graphics, but I don't think that's the thing that makes this issue happen. I think it's a CPU code path coincidentally interfering with GPU process, but again I think that's a coincidence. EDIT: Eh, some people in the OpenSuse bug report say their nvidia driver had the issue while their intel driver didn't. Maybe the |
While I know there were talks about properly detecting what Linux Graphic Drivers were in use, and much more elegant solutions to this problem.
But realistically as those haven't been done yet, I feel it's likely in our best interest to find a solution to this problem rather than the perfect one.
That is until someone can come along and do this much more properly, which I highly implore anyone else to.
But otherwise this change will likely resolve the following:
GPU process isn't usable. Goodbye.issue on start #205--no-sandbox#199