Poll: Anyone using another E-node as boot-server and file-server?

Erlang News & Announcements Official Proposals
1

In Erlang/OTP there is support for loading modules via another Erlang node acting as boot-server and file-server.
This feature has been there for a very long time and it complicates the startup, the file module and the code server (erl_prim_loader).
This functionality might have been very useful and motivated 20 years ago when running on small memory restricted and disk less systems, but I suspect that there in no usage or interest for this functionality now.

The boot server (and remote file server) is activated with the -loader inet and -hosts Hosts flags to the erl command.
I have been working with Erlang for +20 years and have never used this.

We in the OTP team want to remove this functionality , but first I want to ask if someone really is using this. I would be really surprised if that is the case.

Are you using another E-node as boot-server and file-server?
  • Yes (or you intend to)
  • No (or you don’t intend to or don’t mind it being removed)

0 voters

3 Likes
2

We have been using it and would continue to do so if its there: its useful for small embedded nodes without local storage: We can run the GRiSP executable directly in NOR flash (which is usually too small for storing all the BEAM files) and load the modules from a neighbor node. It would be cool if we can keep using that or have it built in optionally

5 Likes
3

Hi,

This code here phoenix_pubsub/cluster.ex at master · phoenixframework/phoenix_pubsub · GitHub uses erl_boot_server. I just want to understand better which part of erl_boot_server might be impacted. For the such code, if OTP team decides to remove erl_boot_server, code like that will stop to work right ?

1 Like
4

keep this feature, it is usefull in some situation especially while developing on embeded devices

5

Does the code server need to load code from another node, or can it be replaced with something that (say) loads from not-a-filesystem?

To clarify: we’ve talked about persuading k8s pods running the BEAM to load code modules on demand from things that aren’t filesystems. I know that’s vague; we’ve got nothing more concrete than that. And most things you’d want to load from (e.g. S3) can be mounted as filesystems anyway.

3 Likes