Is it possible to install Rust in a tmpfs with less than 1GB of RAM?

[guest271314]

Problem you are trying to solve

Install Rust in a live OS running on RAM where disk space is 1GB.

Solution you'd like

Minimal Rust installation for the ability to compile GitHub repositories written in Rust.

Notes

#3125 (comment)

[rbtcollins]

I think the answer to this is no.

The stable x86_64 toolchain with just cargo/clippy/rust-std/rustc/rustfmt is 550M.

To unpack that we need to hold a chunk in RAM, though we can be pretty efficient, and perhaps could be more, you'll still need space for your kernel and userspace themselves, plus linkers and other standard development tooling. From personal recollection a minimal debian chroot with development tools was ~300MB. So call that 850M. And thats before you invoke the compiler and ask it to do anything.

If rustup fails to perform the install, I think we can consider that a bug - we should work in quite low mem environments where rustc will be mem-mapped so the footprint at runtime is much lower - but I am skeptical that a live system will be able to actually build anything with so little RAM.

[guest271314]

I think the answer to this is no.

Thanks for the direct answer.

What I don't understand about the Rust install is that cargo and rustc appear to be duplicated in ~/.cargo and ~/.rustup for the OS-specific toolchain.

We begin with the recommended installation

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

Then, for example,

git clone --recurse-submodules https://github.com/denoland/deno.git
cd deno
~/.cargo/bin/cargo build -vv

I see cargo and rustup in ~/.cargo/bin are each 15.1MiB. cargo in ~/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/bin/ is 24.8MiB, rustc is 2.8MiB.

Right now I'm just trying to build this https://github.com/denoland/roll-your-own-javascript-runtime. I have 1.6GB available. During research over the past few weeks I've read that rustc alone can compile to an executable.

Can Rust folks somehow make this possible? Or, should I abandon the concept of building a minimal executable using Rust given the conditions?

Can you kindly explain why there appear to be duplicate cargo and rustc executables?

[guest271314]

Alternative solutions include instructions for how to build a GitHub repository to a release using GitHub actions; or providing a means to build an executable using Rust online playground, if either are technically possible or feasible. As it stands I don't see any way to install Rust per official instructions and compile an executable on a tmpfs.

[rbtcollins]

Many folk use github actions to build and release their rust code in CI/CD pipelines - its super common and well supported.

Those actions machines have 7GB or more RAM. https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners#supported-runners-and-hardware-resources

I think using such a size machine your use case of 'do it all in RAM' will work just fine.

The duplication isn't duplication - you are seeing the proxies https://rust-lang.github.io/rustup/concepts/proxies.html

If rustup fails to install a toolchain with 512MB of RAM not shared with the filesystem, I think we can consider it a bug, since thats what entry level raspberry pi's have.

Being actually usable at that point when all your build artifacts are going to subtract usable ram - thats a whole other question. Building the roll-your-own-js-runtime repository you linked creates 2G of files:

$ cargo build
$ du -sh target/
2.0G    target/

That would be fine if you were not using a tmpfs.

[guest271314]

If rustup fails to install a toolchain with 512MB of RAM not shared with the filesystem, I think we can consider it a bug, since thats what entry level raspberry pi's have.

I don't see how that would be remotely possible. The only way to determine if that is possible is to test and verify.

Many folk use github actions to build and release their rust code in CI/CD pipelines - its super common and well supported.

Those actions machines have 7GB or more RAM. https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners#supported-runners-and-hardware-resources

I think using such a size machine your use case of 'do it all in RAM' will work just fine.

A complete guide of exactly how to do that will be useful. Using the recommended install script ain't working.

The duplication isn't duplication - you are seeing the proxies https://rust-lang.github.io/rustup/concepts/proxies.html

For this project I don't think I need rustdoc, rust-lldb, rust-gdb, and rust-gdbgui, rls, cargo-clippy, or cargo-miri.

The idea is to build a minimal JavaScript runtime that does exactly one (1) thing - without carrying around linting, formatting, and testing in the executable, in this case, deno and a local HTTPS/WebSocket server. Then use deno compile to compile the working single-purpose JavaScript runtime application to a standalone executable. QuickJS after strip is less than 1MB, however is not shipped with networking functionality built in. deno executable is 99.4MB after strip is 69.7MB. I don't know what the minimla runtime will be starting without liniting, formatting, and other components that will not be bajed in to the executable. Havn't gotten that far yet.

Building the roll-your-own-js-runtime repository you linked creates 2G of files:

Then this won't work anyway. Nonetheless I think you should exclude the possibility you do have a bug re that RaspberryPi scenario. I don't see how that would be possible to successfully achieve - just given the roll-your-own JavaScript runtime case, not even the full deno repository. I suggest you verify in the field.

In the mean time I have no idea how to set up GitHub Actions to build a release executable from a fork. I think it's reasonable that Rust folks create a MVCE of how to do that since we can't use the standard recommended approach on tmfs and do anything afterwards.

[rbtcollins]

So, two things:

I'm not sure where

standard recommended approach on tmpfs
is originating: I haven't seen any documentation recommending installing or developing on tmpfs.

For this project here, the scope is 'can the installer run' - and for that, I'm asserting that either using an 8GB machine with tmpfs, or a 1GB machine with persistent storage - such as an RPi - should work, but 1GB without persistent storage won't.

if someone encounters either of the cases we expect to work not working, will happily work with them to figure it out. Installing on a 1GB without persistent storage isn't something I think we can or should try to make work given the size of development artifacts.

Second thing: I think that a lot of this conversation really isn't about rustup so much as what you should expect from Rust, or how to approach things in Rust, and for that I'm going to recommend https://users.rust-lang.org/ the general community site. Designing the best way to get deno installed into a tmpfs based machine is exactly the sort of thing that warrants discussion, rather than a bug.

[guest271314]

I begin with a 64GB USB drive with a live OS written on it. After downloading Firefox Nightly and Chromium Dev Channel, build-essential, libtool, texinfo, libcurl4-openssl-dev, python3, curl (which is what is recommended to fetch Rust install script though we probably could use wget) I wind up with around 1.6GB of available disk space. I understand work is underway to get Rust in Linux at the kernel level, we ain't there yet though.

For source code that relies on clang instead of gcc I can install clang (LLVM) and have a little space remaining. Rust is just too voluminous to install just to compile source code to an executable. That s the reason QuickJS is being embedded in applications using WASI/WebAssembly by so many disparate developers and organization - and not Node.js or Deno - nobody wants to contend with carrying around V8 in a embdedded, portable scenario. It simply doesn't make sense to carry around 60-100MB JavaScript runtime when QuickJS can provide a solid building block JavaScript runtime for 1-5MB. Does that make sense to you?

If the girth of Rust really is necessary and useful then we should be able to upload a GitHub repository to the online Rust playground and the Rust compiler should spit out the executable after building. Then I don't have to be concerned with running out of disk space just to install a compiler to build a minimal JavaScript runtime. Do you see the issue with this scenario? I am trying to build a minimal application, yet to do so using Rust have to use over 1GB for the compiler. Somehow the author of QuickJS managed to write a compiler that accepts JavaScript input and spits out C in far less than 1GB. SO, there has to be a way to get rid of some of the bloat involved.

I've noticed over the years the Chromium executable steadily increasing in size. That is the trend. So eventually I can see Rust compilation chain growing until we need more and more disk space to compile a minimal program.

If you Rust folks really can't build a program without over 1GB of source code, then I don't think your RaspberryPi scenario is realistic. And Frankly, not worth it to fight Rust along the way. I can start with QuickJS source code at around 5MB and build up rather than starting with Rust at 1GB just to build anything.

[guest271314]

@rbtcollins BTW, thanks for your time and effort in this matter. I just thought it was appropriate to ask the source (Rust experts) for a solution to this case. If no viable solution is possible, and no compromise can be reached then as you and others have stated it is not possible to install Rust in minimal-type systems and function thereafter. I don't think Rust users in the field can come up with a solution when the canonical source can't. If that is it, no compromise, no way to get rid of liniting, formatting, testing, etc. from even the "minimal" profile, then just close this issue and I will have to abandon trying to build with Rust and move on to explore other solutions. I am merely exhausting my remedies.

[thomcc]

If you're building a minimal application, you should try and find a way not to need to compile Rust code from source. Compiled Rust programs don't need the Rust compiler present, and should be considerably smaller. This fact is why your use case has not really been catered to — most folks who have size-constrained applications don't need to compile Rust code at runtime.

If you must compile Rust code, and reducing compiler size is required, you could mrustc, which is an alternative Rust compiler. But note that (IIUC) it pretty much exists for the purposes of bootstrapping rustc, so it might have issues for whatever you are trying to do. It also won't support the latest version of the language.

[thomcc]

This seems off topic for this repository's issue board.

[guest271314]

I deleted the context. I'm seeking the minimal means to compile Rust source code. Looking at what is downloaded for recommended install, are linting, formatting, and debugging really needed?

Is there a way for you to create a minimal compiler, less MB than the "minimal" profile, so I can test writing and compiling Rust in my environment?

Or, is that just not possible?

[guest271314]

If you must compile Rust code, and reducing compiler size is required, you could mrustc

Before

git clone https://github.com/thepowersgang/mrustc
make RUSTCSRC

I had over 1GB of space on the tmfs, after 250MB.

make -f minicargo.mk 

At 189MB space remaining right now and the compilation is not completed.

[ChrisDenton]

I really think you would be better served by asking on one of the user help forums. This issue tracker is really not designed to provide that kind of support.

[guest271314]

I did. More than once; e.g., https://www.reddit.com/r/rust/comments/10tojxt/building_minimal_deno_executable_for_a_local/

Then I had no choice but to ask the canonical source.

I havn't observed thus far enthusiasm for somehow reducing the at least 1GB currently required to install Rust tool chain for the use case I described and similarly situated environments.

I think the answer is "No".

[thomcc]

deno executable before strip 99.4MB, after 69.7MB. I still have the sense this can be reduced by excluding tests, linting, etc. from the original build.

Note that whether or not tests, linting, etc. are present in the compiler has no impact on the size of the executables the toolchain produces... To get smaller executables, you should start by adjust the compiler settings, not changing the items installed with the compiler. But this is definitely the wrong forum for this discussion still.

[guest271314]

Note that whether or not tests, linting, etc. are present in the compiler has no impact on the size of the executables the toolchain produces... To get smaller executables, you should start by adjust the compiler settings, not changing the items installed with the compiler. But this is definitely the wrong forum for this discussion still.

This is the only forum for my question. Everything else is just hearsay and sidebar. You Rust experts are the canonical source. All roads lead back here.

I don't need those items. I would be carrying them around for nothing. Yes, eliminating those items must reduce executable file size.

[thomcc]

They are not present in the output executable, they're just part of the build toolchain.

[guest271314]

They are not present in the output executable, they're just part of the build toolchain.

The deno executable winds up with linting and formatting baked in to the executable.

That is the philosophy I'm talking about.

Those should be optional features not even in the build toolchain. If I want to import them into my build then I can.

All of that is just more disk space used on systems running on RAM and temp file system.

We don't get to the part of compiler flags because your compiler toolchain is too immense for me to even install.

Instead of defending your current practices you could instead focus on trying to come up with a solution for this issue. I don't see that happening though.

You suggest I ask users in the field how to builf with Rust. If the canaonical source can't craft a solution there is a problem with that proposed solution A wild goose chase. Come up with a minimal official Rust compiler.

[thomcc]

The deno executable winds up with linting and formatting baked in to the executable.

If this is true, it has nothing to do with the rust toolchain. Rust does not bake formatting, linting, or testing into output executables. There is not even an optional feature to do so, let alone one you need to disable, so if deno does this it has implemented that feature entirely separately of the work of this or any other rust-lang repository.

We don't get to the part of compiler flags because your compiler toolchain is too immense for me to even install.

Your complaints seem very confused. The best analogy I have is that you're complaining that because the factory is large, it can only build large cars. That is not the case. The factory (the rust toolchain) may be bloated from your perspective, but this fact is entirely unrelated to the size of what it produces.

If you wield Rust correctly, you can get very small executables, even though the compiler itself is large. See https://github.com/johnthagen/min-sized-rust.

[Diggsey]

For this project I don't think I need rustdoc, rust-lldb, rust-gdb, and rust-gdbgui, rls, cargo-clippy, or cargo-miri.

Those are not installed in the minimal profile. The proxies are still present but they do not actually take up any space because they are all hard-links to the same executable. It sounds like you are incorrectly counting these towards the size of the installed rust toolchain.

Somehow the author of QuickJS managed to write a compiler that accepts JavaScript input and spits out C in far less than 1GB. SO, there has to be a way to get rid of some of the bloat involved.

This comparison makes no sense. When you translate JavaScript to C, the heavy lifting is being done by the C compiler to take that C code and compile it into an actual executable. If you want an apples-to-apples comparison, you should compare the size of the Rust toolchain to the combined size of QuickJS + C compiler (clang or GCC) + size of installed C header files and libraries. If you actually do that comparison, you will find that there is not so much difference...

[guest271314]

Your complaints seem very confused. The best analogy I have is that you're complaining that because the factory is large, it can only build large cars. That is not the case. The factory (the rust toolchain) may be bloated from your perspective, but this fact is entirely unrelated to the size of what it produces.

If you wield Rust correctly, you can get very small executables, even though the compiler itself is large. See https://github.com/johnthagen/min-sized-rust.

I ain't complaining. I am sharing with Rust folks that I can't even install Rust tool chain without running out of disk space .

The fact that Rust tool chain is at least 1GB on Linux is not debatable.

I am looking a minimal Rust tool chain. That is the purpose of this issue. Then i can testing removing what I don't need from various repository source code before I build. I never get that far because Rust eats up available space on temporary file system running in RAM.

I think repositories constructed with Rust tend to bake in what Rust bakes in to the tool chain.

Users in the filed should be able to import Rust linting, formatting, debugging executables without those executables being in the default cargo directory - unless they are actually needed to build with Rust. Then minimal versions of those executables should be provided as an option for the use case of low disk space devices. That is reasonable. Let's say something around a half to a third of what the current Rust tool chain is - if anything can be removed and the tool chain still builds correctly. I havn'e gotten a square answer to that question. That is the purpose of this issue.

[guest271314]

Those are not installed in the minimal profile. The proxies are still present but they do not actually take up any space because they are all hard-links to the same executable. It sounds like you are incorrectly counting these towards the size of the installed rust toolchain.

Those are installed when the default installation script is run. Then downloaded again when cargo build is run.

What I am trying to determine is how to not download all of those "proxies" when cargo is run.

This comparison makes no sense. When you translate JavaScript to C, the heavy lifting is being done by the C compiler to take that C code and compile it into an actual executable. If you want an apples-to-apples comparison, you should compare the size of the Rust toolchain to the combined size of QuickJS + C compiler (clang or GCC) + size of installed C header files and libraries. If you actually do that comparison, you will find that there is not so much difference...

There is Tiny C Compiler, et al. I am asking if there is anything that can be done to reduce the 1GB size of the Rust tool chain, during or after the suggested installation process.

I don't think LLVM is 1GB. Even though the distribution is shipped with GCC I have also installed clang and LLVM and still been able to build repositories from GitHub. I am merely sharing with Rust folks what I have experienced trying to do the same thing with Rust. I havn't been successful thus far and nobody has offered a roadmap to install a minimal Rust tool chain, not the "minimal" profile because I do select that and still get over 1GB of Rust tool chain. It was stated earlier that the answer is "No" to my question. I seconded that conclusion. If you have a roadmap to refute those conclusions kindly share here.

On a difference machine with more disk space I wouldn't have this issue. Right now I am experimenting with compiling on minimal disk space devices running on only RAM.

[thomcc]

I think repositories constructed with Rust tend to bake in what Rust bakes in to the tool chain.

This is untrue. You said you are coming to the source because we are experts on Rust, and we are telling you this is not happening. There is not even an option to do this, and for users to do it manually would be very difficult.

The size of deno is not coming from rustfmt/clippy/etc being baked into the deno executable, it is coming from something else.

[guest271314]

The philodophy of the Rust tool chain is reflected in deno built-in tools, See the compiler, doc, formatter, linter. I will get rid of those as well as at least testing, benchmarker.

This issue ain't about Deno. Deni is just an example of an executable built with Rust, reflecting the features baked in to Rust tool chain that cannot easily be removed - no option to do so - even if you don't need or use them.

This issue is about the size of Rust tool chain. I can't even get to the point to remove those items from the build to prove you and me right or wrong re unneeded "features" being baked in to executables compiled with Rust.

Does that make sense to you?

https://deno.land/[email protected]/tools

start new project (deno init)
benchmarker (deno bench)
bundler (deno bundle)
compiling executables (deno compile)
installer (deno install)
dependency inspector (deno info)
documentation generator (deno doc)
formatter (deno fmt)
linter (deno lint)
repl (deno repl)
task runner (deno task)
test runner (deno test)
vendoring dependencies (deno vendor)

[guest271314]

Fresh live OS running on RAM.

3.1GB after sudo apt update.

Install and run bleachbit to get rid of locales, etc.

1.9GB after running Rust install script with default profile.

1.4GB after downloading Chromium Dev Channel.

1GB after downloading release zip file from https://github.com/denoland/roll-your-own-javascript-runtime.

cargo run

Compiling libc v0.2.126
error: linker `cc` not found
  |
  = note: No such file or directory (os error 2)

After installing build-essential 701MB.

cargo run

cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR
  run pkg_config fail: "Could not run `\"pkg-config\" \"--libs\" \"--cflags\" \"openssl\"`\nThe pkg-config command could not be found.\n\nMost likely, you need to install a pkg-config package for your OS.\nTry `apt install pkg-config`, or `yum install pkg-config`,\nor `pkg install pkg-config`, or `apk add pkgconfig` depending on your distribution.\n\nIf you've already installed it, ensure the pkg-config command is one of the\ndirectories in the PATH environment variable.\n\nIf you did not expect this build to link to a pre-installed system library,\nthen check documentation of the openssl-sys crate for an option to\nbuild the library from source, or disable features or dependencies\nthat require pkg-config."

  --- stderr
  thread 'main' panicked at '

  Could not find directory of OpenSSL installation, and this `-sys` crate cannot
  proceed without this knowledge. If OpenSSL is installed and this crate had
  trouble finding it,  you can set the `OPENSSL_DIR` environment variable for the
  compilation process.

  Make sure you also have the development packages of openssl installed.
  For example, `libssl-dev` on Ubuntu or `openssl-devel` on Fedora.

  If you're in a situation where you think the directory *should* be found
  automatically, please open a bug at https://github.com/sfackler/rust-openssl
  and include information about your system as well as this message.

  $HOST = x86_64-unknown-linux-gnu
  $TARGET = x86_64-unknown-linux-gnu
  openssl-sys = 0.9.80


  It looks like you're compiling on Linux and also targeting Linux. Currently this
  requires the `pkg-config` utility to find OpenSSL but unfortunately `pkg-config`
  could not be found. If you have OpenSSL installed you can likely fix this by
  installing `pkg-config`.

  ', /home/user/.cargo/registry/src/github.com-1ecc6299db9ec823/openssl-sys-0.9.80/build/find_normal.rs:191:5
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...

25MB after above.

There is no way I can install pkg-config and complete the cargo run call.

[guest271314]

I removed some language packages to get 266MB

--- stderr
  thread 'main' panicked at '

  Could not find directory of OpenSSL installation, and this `-sys` crate cannot
  proceed without this knowledge. If OpenSSL is installed and this crate had
  trouble finding it,  you can set the `OPENSSL_DIR` environment variable for the
  compilation process.

  Make sure you also have the development packages of openssl installed.
  For example, `libssl-dev` on Ubuntu or `openssl-devel` on Fedora.

  If you're in a situation where you think the directory *should* be found
  automatically, please open a bug at https://github.com/sfackler/rust-openssl
  and include information about your system as well as this message.

  $HOST = x86_64-unknown-linux-gnu
  $TARGET = x86_64-unknown-linux-gnu
  openssl-sys = 0.9.80

  ', /home/user/.cargo/registry/src/github.com-1ecc6299db9ec823/openssl-sys-0.9.80/build/find_normal.rs:191:5
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

libdev-ssl is also a Rust dependency.

sudo apt-get install libssl-dev

Preparing to unpack .../libssl3_3.0.2-0ubuntu1.8_amd64.deb ...
Unpacking libssl3:amd64 (3.0.2-0ubuntu1.8) over (3.0.2-0ubuntu1.6) ...
Setting up libssl3:amd64 (3.0.2-0ubuntu1.8) ...
debconf: DbDriver "templatedb": could not write /var/cache/debconf/templates.dat-new: No space left on device
Warning: unable to close filehandle $fh properly: No space left on device at /usr/share/perl5/Debconf/DbDriver.pm line 55.
dpkg: error processing package libssl3:amd64 (--configure):
 installed libssl3:amd64 package post-installation script subprocess returned error exit status 1
dpkg: error: failed to write status database record about 'alsa-base' to '/var/lib/dpkg/status': No space left on device
E: Sub-process /usr/bin/dpkg returned an error code (2)

43MB left on device.

sudo apt-get clean
sudo dpkg --configure -a

4.7MB left on device.

[guest271314]

Run bleachbit. Try to delete files from cache directory in ~/.cargo when I see unpacked files in src

Compiling serde v1.0.152
LLVM ERROR: IO failure on output stream: No space left on device
error: could not compile `swc_ecma_parser`
warning: build failed, waiting for other jobs to finish...
LLVM ERROR: IO failure on output stream: No space left on device
error: could not compile `openssl`
thread 'rustc' panicked at 'assertion failed: pos.get() <= self.position()', compiler/rustc_metadata/src/rmeta/encoder.rs:426:9
error: could not compile `serde`
thread 'rustc' panicked at 'assertion failed: pos.get() <= self.position()', compiler/rustc_metadata/src/rmeta/encoder.rs:426:9
error: could not compile `swc_ecma_visit`

[Diggsey]

Those are installed when the default installation script is run. Then downloaded again when cargo build is run.

What I am trying to determine is how to not download all of those "proxies" when cargo is run.

This is simply not true. cargo build does not do anything with the proxies that are installed by rustup (and which are only hard-links in the first place).

Users in the filed should be able to import Rust linting, formatting, debugging executables without those executables being in the default cargo directory - unless they are actually needed to build with Rust.

As already mentioned, these executable do not take up any space as they are simply hard-links to rustup itself, so whatever you are measuring is wrong.

It was stated earlier that the answer is "No" to my question. I seconded that conclusion.

The answer is still "No". Nobody on this thread is arguing that you can install Rust and compile anything useful using only 1GB of RAM and no persistent storage... What we are saying is that your assumptions about why that is the case are wrong. When you install the minimal profile there is no additional "testing" or "linting" stuff that is taking up space and could be removed.

These are the things that do take up space:

1. The cargo registry. This takes ~800MB for me and is a git repository cloned by cargo on first use, and which contains the version information about every package on crates.io. This is used in order to resolve dependencies in your Cargo.toml file. There is already work underway to allow this version information to be fetched on-demand rather than requiring the git repo to be cloned in its entirety, but it hasn't landed yet. If you vendor your rust dependencies and have an up-to-date Cargo.lock file, then it is not necessary to clone this registry at all, and you can pass the --offline flag to cargo.

2. The rust toolchain itself. This is found in ~/.rustup/toolchains/*. Within that you have:

2.1) The compiler and it's dynamic libraries. These take about ~238MB on my machine, although this includes the debug files (I'm on windows so PDB files). If I exclude debug symbols, it's ~139MB. If I were to "strip" those binaries removing all symbols, I imagine the size would go down even more.

2.2) The rust standard library. This takes about ~200MB on my machine, again including debug files (although there are fewer savings to be made by deleting those).

Having said all that, you are likely to still be out of luck: you will probably still run out of space if you try to build anything non-trivial, as intermediate build artefacts can easily take up a few hundred MBs on their own (symbols take a lot of space...)

In summary, you can save some space by stripping binaries in the .rustup directory, but the majority of space usage still comes from the cargo registry. If you want to avoid that you can either not use any dependencies, or vendor them (see cargo-vendor). If you don't know what dependencies you will need in advance then unfortunately you will have to wait until the new HTTP-based registry lands. And even then, it's not going to allow you to do a whole lot with only 1GB of total storage.

[rbtcollins]

I'm going to lock this conversation, it has become far off-topic for rustup.

• rustup cannot install rust in 1GB of RAM when a tmpfs is backing RUSTUP_HOME, and we're ok with that. RAM-only software development isn't something we're targeting. If you can build some consensus amongst the user community that that is something we should focus on, we can reopen this, or open a new bug to discuss the details of making it work.
• if someone has an error installing rustup in a 1GB RPi or similar, with RUSTUP_HOME on SSD/flash/HDD or similar, then they should file a bug, and we'll see about fixing that.
• for challenges with using rustc once it is installed, please see https://users.rust-lang.org/