??? Just wondering.

It might eat a tiny bit (very small nibble) but not enough to notice.Unleeeeeeess,it's Galaxy?

Well, if they have a taste for mutton...

I thought downloads were all vegan.

LOL, aha that made me chuckle a bit. nice one TinyE

If your download speed is very high and your hard drive is slow, the RAM will most assuredly fill up as it buffers. Other cases I think depends on the downloader program used.

It was a download straight from gog. I am on MINT. I was downloading the archivable version of a windows game directly from the site. I noticed my ram slowly went to were only like 30% was left.

And why would firefox eat up... 50% of my ram? (normal operating with nothing running uses 20%... so I think it's using 50%... seem like the longer the browser is open the more ram is used).

Most likely, the RAM usage from your downloads is the disc cache. Whenever files on disk are accessed, the files are read and saved in the disk cache; in the case of a download, the download is initially stored in RAM before being saved to disk. Since the file is already in RAM (since it has to pass through), the system might as well just keep the file in RAM in case it is accessed later; no sense in letting RAM go unused. As a result, your downloads will be taking up space in RAM.

This is not actually cause for concern; if, at any point, the kernel runs out of RAM to store things, it will look for some data in memory that can be freed. If the downloads are not accessed for a while, the kernel might decide that the download is not important enough to keep in RAM, and will therefore remove it from RAM (but not before writing to disk, if it isn't already there). This is similar to virtual memory; a clean (that is, hasn't recently been written to) page of disk cache can be discarded easily, while a page that isn't backed by a file will be written to swap instead if the system is running low on memory.

This is one of the ways in which Linux, from a perfomance standpoint, is better than something like Windows XP, which doesn't aggressively cache data.

If you use the "free" command, the most important thing is not the "free" column, but rather the "available" column; that's how much more memory can be allocated before you have to worry about the OOM killer kicking in.

Well said.
I am no expert, but your operating system determines the memory management scheme employed (moving data from storage to working set, and back again, pre-caching, etc). Your hardware setup (storage type, ram speed and size, etc etc) are also factors.
As is plugins/extensions that you may have running in firefox itself, and if you are running any other tabs/windows at the time while you wait for the DL to finish, or other software that is sniffing your downloads as they occur.
Memory usage is a tricky thing to diagnose. Does MINT have a performance diagnostic tool that you can look for memory faults too btw? Just throwing ideas until one sticks.

Ugh that's Firefox for you. I still use it (old non Quantum version) for setting up multiple downloads via downthemall (like when I'm downloading my games from GOG in multiple parts).

And yeah the longer FF is open, the more memory leaks.

Otherwise it's Vivaldi and Opera for day-to-day browsing. Oh and Chrome (only when tampermonkey extension is needed).

What is an "OOM killer"?

The OOM (Out Of Memory) killer is a part of the Linux kernel (don't know how other OSes handle this situation) that is called if the system runs completely out of memory and swap space and is unable to free any memory; it is the method of last resort.

Basically, if Linux runs out of memory, it tries to free up memory, and will first try the following things:
* If there's a clean page backed by a file (that is, the memory is a copy of the file, and neither has been altered), the kernel can just drop the memory page (it can be read from disk later if needed again).
* If there's a dirty page backed by a file (that is, the memory or file has been changed), the page can be dropped, but only if the changed data is written to disk first.
* If the page is not backed by a file, it can be saved to the swap partition or file. When a program tries to access that memory later, the CPU will trigger a page fault, and the kernel will read that page back from disk into RAM (assuming it can free up some memory, of course). This is what is commonly referred to as "virtual memory".

If the kernel can't free up memory this way, the OOM killer is then invoked. The OOM killer scores each process based off factors like how much RAM the process and its children are using, as well as how long the process has been running. The result of the OOM killer is that some process will be killed, and any unsaved data the process had will be lost. As you can see, the OOM killer is the kernel's method of last resort for freeing up memory if all else fails.
(Generally, if the OOM killer is ever called during normal operation, something has gone wrong. There might be a runaway process leaking memory (hopefully that one becomes the OOM killer's victim), or you might need to add more RAM or swap space.)

If even the OOM killer fails (this is rare, and typically involves something like a ramfs eating all phyical memory, or a kernel memory leak), then the kernel will panic. (A kernel panic is the Linux equivalent of a blue screen.)

If you want more details on how the OOM killer chooses its victim, including some source code excerpts from the Linux kernel, you can go to
https://linux-mm.org/OOM_Killer
or just go to your favorite search engine.

What does a kernal panic screen look like?

Like this