Unreal Engine 4 and Linux

[RCL]

While the Unreal Engine has enjoyed Linux support in the past, with Unreal Engine 4 we want to make Linux a first class member of our platform family. Our plans regarding the Linux platform balance the needs of both our internal projects and some partner projects, alongside the larger needs of the Linux community. This roughly translates to four large areas of Unreal Engine4 Linux development (each with its own unique challenges):

• robust, secure and CPU-effective Linux game servers
• full-featured Linux client support
• feature-rich, native Linux development tools
• enhancing our tools on Windows and Mac OS to make targeting Linux easy

When hearing about Unreal Engine 4 supporting Linux, it is easy to only think about the first three. However, if we want Linux to take off in the game development industry at large, we need a seamless integration with existing workflows of game companies, so that costs of shipping a Linux version of the game are minimized. That is why, somewhat counter intuitively, we need robust Windows and Mac OS tools that would allow anyone to target Linux by just recompiling and repackaging the project. This is also why we started out with cross-compilation and are planning to continue to support it, while also working to make native development easier.

We believe that this ability to target Linux (and, particularly, SteamOS) with cross-tools using the existing development environment is needed in order for it to get broader traction.

COMMUNITY ENGAGEMENT

When we released 4.0 two months ago, we only supported Linux dedicated servers; by now official support includes running packaged games (both standalone game and client). Having SteamOS in mind, we consciously limited ourselves to the x86-64 architecture with the officially supported way of developing being cross-compilation from Windows (Mac OS toolchain will be added in the future). Documentation (admittedly scarce) of the process is maintained through the community wiki.

Needless to say, the vibrant Linux community wanted more from the very beginning :-) Once the Unreal Engine was out in the wild, enthusiastic developers (some of them working for much bigger companies than ours!) quickly picked up the slack and started with their own initiatives, which concentrate on getting development tools running on the platform. While we had (and have) that in our plans (take a look at the engine roadmap that we recently made public), quite frankly we did not expect that to happen so soon. Yet the community managed to beat us to getting Unreal Editor to start under Linux. ;-)

I feel obliged to mention by name the most active folks who were driving the community effort:

• Sam ‘sbc100’ Clegg
• Wesley ‘JKnife’ Hearn
• Andrei Barbu
• Andreas Bergmeier

Of course there are many more folks who frequent the #ue4linux IRC channel on Freenode and our forums. Thank you so much for all the pull requests (which of course will be reflected in the credits), feedback and invaluable advice! We feel honored to have people from Google, Red Hat and MIT donating their free time to improve Unreal Engine 4 on Linux! Also special thanks to the folks at DarkSide, particularly Michael Liebenow, who have been working shoulder-to-shoulder with us on UE4’s Linux support.

ROADS TO BE EXPLORED

Having an AAA-grade game engine available for tinkering and experimentation benefits both us and the open source community. We are stressing a lot of components of the Linux software stack (and of course drivers), which sometimes can get improved as a result (e.g. Valve’s very handy OpenGL debugger). We are looking forward to engaging with a wide variety of projects!

We believe the engine is a fertile field for all kinds of research related to compilers, and we hope that both the gcc and clang communities will take advantage of our vast code base, especially considering that we are keen to embrace the latest and newest C++11 features.

There are so many things we would like to do with Unreal Engine 4 on the Linux platform, but currently don’t have time for:

• Improve Unreal Engine 4 scalability by running a game server on a large, NUMA machine with tens (hundreds?) of CPUs and analyzing how we could utilize them
• Port it to some exotic architecture like Loongson and see what you will run into
• Port it to Linux-based devices like GCW Zero handheld or Raspberry Pi (I have partially done that in the past, and can help with building third-party libs)
• Create a freely available (yes, the license allows that, provided that you don’t distribute the sources or tools) benchmark that could be included in Phoronix Test Suite and/or used to improve Linux graphics drivers
• Port it to other *nix (FreeBSD, Solaris)

And of course, we encourage the UE4 community to use the opportunity to beat us again and be the first to ship an Unreal Engine 4 Linux game! :-)

[Syed]

I have pm-ed someone on this matter.. but basically the fix is just a matter of rewording:-
'We cannot find the public repo (note that you have not logged in). If you are accessing a private repo, then please login first'.

So this way, if a user want to brute force to check if the repo exist, he/she has no idea whether the brute force actually result in something. So security-wise, it is still good.

[Gwenn]

You can't ever have a different behaviour on a private repo and a non-existing repo because it confirms its existence and can be bruteforced.

Are we done on this ? This isn't the place to discuss the secucity and convenience of GitHub, especially for explaining the same thing over and over. Please ?

[Syed]

I understand what he meant, I am saying that it would enable attackers to know the existence of a repository without access rights to it. You would be able to try random URLs like "unrealengine5" or "halflife3", and by getting a login prompt, you would know that such a repository exists.

This isn't dumb at all.

What github should do is like what I said please login first (which is what most user perplexed when they click the UE4 github link - they found 404 error). And then when they login, they will find the repo. But if the repo doesn't exist or inaccessible (private repo etc), then github can display 404 - it is good enough. No one mentioned about fixing the 404 error by returning a list of repo, even if they are private.

[franktech]

but if Microsoft has a WindowsWithLinuxKernel repo, that's probably not information they want to be public. Private means private.

The URL check will always fail at 'Valve' anyway not 'Half-Life', no?
Plus surely leaks like this put everything else into perspective etc...

Can we go back to Linux discussions instead of feature requests for GitHub ?

No worries...

[Gwenn]

I just explained it - if it returned a different code than 404, you could automatically generate a list of private repositories for an organization by just probing all possible URLs. While not a real risk in the classical sense, it's still private information. Everyone knows Epic has an UnrealEngine repo, but if Microsoft has a WindowsWithLinuxKernel repo, that's probably not information they want to be public. Private means private.

Go to GitHub's issue tracker to see other people say the same thing (one with the same Half-Life 3 example I jokingly gave above) : https://github.com/dear-github/dear-github/issues/162

Can we go back to Linux discussions instead of feature requests for GitHub ?

[franktech]

I understand what he meant, I am saying that it would enable attackers to know the existence of a repository without access rights to it. You would be able to try random URLs like "unrealengine5" or "halflife3", and by getting a login prompt, you would know that such a repository exists. This isn't dumb at all.

Security wise there's new attack vectors everyday.
But are Github paths like probing existing Logins?
Its not like malware probing 135 / 445 open ports...
What use would that information really be Gwenn?
Explain to us where you see the real security risks...

[Gwenn]

I understand what he meant, I am saying that it would enable attackers to know the existence of a repository without access rights to it. You would be able to try random URLs like "unrealengine5" or "halflife3", and by getting a login prompt, you would know that such a repository exists.

This isn't dumb at all.

[Syed]

I think what he meant was the error should be 'Please login first' instead of 404 error (which doesn't look professional).

[Gwenn]

It's not dumb, it's basic safety. You're not going to give away the existence of a file by outputting a different error if it does exists.

[franktech]

Well, are you logged in ?

Returning 404 for every repo behind a login-wall is a real dumb way to trip devs up.
How does Github distinguish between real 404 errors or a deleted repo / branch etc!

[thadkinsjr]

we arent getting a launcher any time soon. Epic replied that they have an interest in making a unified flatpack for all distro's.

[leotada]

Epic should provide at least the Launcher with compiled binaries of UE4, or Flatpak package for example will run in any Linux distribution. Sad the lack of support.

[mike444]

How cool is that:
http://phoronix.com/scan.php?page=ne...VR-Vulkan-GNUX

I'll try to run the ocean examples with Vulkan once I've finished some other stuff.

Anyone has set up VS Code for Unreal?

[Gwenn]

Well, are you logged in ?