Support for ARM servers

https://github.com/discourse/discourse_docker/issues/121

Continuing on from the discussion on ARM support at GitHub.

ARM support would be extremely useful for owners of small communities like myself because of the extremely low price (like the Scaleway 2GB ARM servers for €2.99) and for those who can’t afford the move from cheap shared hosting to the dedicated or KVM machines that Discourse requires.

https://community.scaleway.com/t/discourse-instantapp/452

There has also been some discussion of this on the Scaleway forums, although much of this has been around getting Discourse working without using the Docker method.

5 « J'aime »

As @erlend_sh said, this is a blocker. No updates so far? Maybe Discourse could provide a list of non-ARM gems so far so that we could track here the process with respect to blocking dependencies?

1 « J'aime »

Simplest thing to do is install Ruby on a scaleway copy our Gemfile and do a bundle install… what happens?

bundle install is not an issue.

However, the therubyracer and v8 gem requires some patches/different version. Otherwise, the
RUBY_GC_MALLOC_LIMIT=90000000 RAILS_ENV=production bundle exec rake assets:precompile
does not finish, but break with a stack trace.

Purging temp files
abort:

==== JS stack trace =========================================

Security context: 0x3fd36f3d <JS Object>#0#
    1: /* anonymous */ [<eval>:~56513] (this=0x3fd36fe5 <JS Global Object>#1#,data=0x4f74cec5 <JS Array[2]>#2#)
    2: intersection [<eval>:57141] (this=0x4f74d431 <JS Object>#3#,argument=0x4f74ce7d <JS Object>#4#)
    3: /* anonymous */ [<eval>:58617] (this=0x4f70b199 <an Object>#5#,_dereq_=0x4f70b0f1 <JS Function>#6#,module=0x4f70b1a5 <an Object>#7#,exports=0x4f70b199 <an Object>#5#)
    4: arguments adaptor frame: 7->3
    5: s [<eval>:~2] (this=0x3fd36fe5 <JS Global Object>#1#,o=591,u=0x3fd08091 <undefined>)
    6: arguments adaptor frame: 1->2
    7: /* anonymous */ [<eval>:2] (this=0x3fd36fe5 <JS Global Object>#1#,e=591)

stacktrace.txt (291 KB)

This seems to be the upstream bug: TheRubyRacer 0.12.1 Segmentation Fault · Issue #317 · rubyjs/therubyracer · GitHub
I posted recently a comment, but did not get a response.

Scaleway patches the Gemfile and Gemfile.lock in order to use local versions that have been downloaded from elsewhere: https://github.com/scaleway-community/scaleway-discourse/blob/master/Dockerfile#L53

5 « J'aime »

For those looking into this, a fair amount of progress has been made on this front:

https://community.scaleway.com/

7 « J'aime »

Nice looks like mini racer helped here @sam!

7 « J'aime »

Ça fonctionne maintenant sur ARM ?

Est-ce simplement une question de modification des scripts d’installation, ou y a-t-il vraiment des blobs binaires x86 utilisés ?

Tout le monde a désormais des lignes de 100 Mbit, et beaucoup de gens disposent de la fibre optique gigabit à domicile. Vous pouvez acheter une box TV Cortex-A55 pour 30 , brancher votre ancien disque SSD via USB 3.0 avec un adaptateur à 3 , installer Linux et vous êtes prêt à partir. Cela consomme pratiquement aucune énergie. La vitesse de traitement et la vitesse du disque sont incroyables. Souvent, le ping est même inférieur à celui d’un centre de données. Ce n’est même pas l’avenir de l’hébergement, cela existe depuis un bon moment. C’est totalement supérieur à n’importe quel serveur milieu de gamme. Il n’y a littéralement que des avantages.

1 « J'aime »

Tout le monde n’a pas la chance d’avoir accès à une telle vitesse de connexion (sans parler de la fibre optique). Certaines personnes ont même encore un accès par ligne commutée. Cela commence à changer aux États-Unis, mais pas dans les régions pauvres. Je pense qu’il serait utile de mentionner Starlink cependant.

1 « J'aime »

Vous soulevez un excellent point, mais je pense que c’est encore plus important dans le centre de données.

Une adoption généralisée d’ARM dans les centres de données pourrait réaliser d’énormes gains d’efficacité énergétique (> 2x ?) et réduire les coûts, ce qui pourrait avoir un impact massif. C’est un objectif vraiment responsable.

Au fait, cela a été récemment discuté dans ce sujet : Require ARM64 Support - #3 by david, suggérant que plusieurs dépendances (binaires gem) ne sont pas disponibles en dehors de l’architecture x86.

3 « J'aime »

Ceci est maintenant pris en charge

5 « J'aime »