Changes to theia-full-docker to run on arm64

[dm4tze]

Hello theia-ide team,

I've made some changes to your theia-full-docker Dockerfile to get it running on an arm64 machine (Raspberry PI4 #411 #130). Since some of these changes will affect builds for other architectures I want to discuss my solution with you. If we come to a conclusion I will adjust the Dockerfile to build on the other supported architectures too. Following changes have been made:

• Get Golang in the right architecture (I see no problems here)
• Downgraded LLVM from Version 13 to version 11 and use the distribution package form ARM64 build. (http://apt.llvm.org/bionic/ is not providing arm package)
• Get CMAKE in the right architecture (I see no problems here)
• Do not install python 2 (There seems no support anymore)
• Install .NET via tarball since there is no arm64 package (needs some work to support other architectures)
• Install DART via zip since there is no arm64 package.

Which of these changes are problematic? Is there a way to test all these changes to see if everything is working as expected?

[marcdumais-work]

@dm4tze have you considered starting with one of the more modest images, that would be easier to handle? Like theia-docker or theia-cpp-docker? The theia-full image is quite big (> 4GB) and seems at first look ill-suited for a rspb board, even the beefier v4 model.

[marcdumais-work]

What I would love is to have an Electron-based Theia app package that works on a rspb4, like VSCodium has (they have a bunch).

[dm4tze]

@dm4tze have you considered starting with one of the more modest images, that would be easier to handle? Like theia-docker or theia-cpp-docker? The theia-full image is quite big (> 4GB) and seems at first look ill-suited for a rspb board, even the beefier v4 model.

The idea was, first porting the full image then it should be easy to adjust the other images. At my rpi4 as backend it works without any performance issue. But I have to say, that I use a SSD as storage.

What I would love is to have an Electron-based Theia app package that works on a rspb4, like VSCodium has (they have a bunch).

I don't have a rpi with installed GUI at the moment. That's why I'm using theia :)

[marcdumais-work]

I don't have a rpi with installed GUI at the moment. That's why I'm using theia :)

There is something we're working-on that might be of interest to you. There is not that much info in the issue, but in short we're going to make available a browser app backend, in an easily packaged form. I hope the way we do it can work on raspberry pi and such, too. TL;DR the browser Theia app without Docker.

[stale[bot]]

This contribution has been automatically marked as stale due to inactivity, and it will be closed if no further activity occurs. Thank you for contributing to Theia!

[marcdumais-work]

@dm4tze Sorry - this PR fell between the cracks for a while. I'm interested in trying it on my own raspberry pi 4.

Can you give a bit of details about how one goes about setting-up the necessary environment (high-level steps)? I'm ok installing a new system from scratch on a new micro-sd card, if need be. I suggest adding the info in the PR description.

[marcdumais-work]

Which of these changes are problematic?

DOTNET and DART are the two that look suspicious to me ATM. We might need to supplement the pre-built binaries with OS--level dependencies that are expected to be present. Until we figure these out, I would be ok to keep the main architecture as-is for these languages, and having a custom setup for arm64.

If I understand correctly, GitHub workflows support arm64, to it may be possible to add that flavor of the full image to CI, by-passing the need to build on one's own board.

[marcdumais-work]

@dm4tze I wanted to mention that it's highly recommended to somehow secure access to your container and its Theia app.

You can use our "https" example image as inspiration: https://github.com/theia-ide/theia-apps/tree/master/theia-https-docker .

Without something like this, the Theia app's file-system API (among other things) would be accessible from your LAN and become a potential "access point" e.g. for exploits that can breach your LAN, such as those that use DNS rebinding.