Oftentimes this ends up being something like aggressively caching file data so that it doesn't have to write to disk very often. While this does get labeled as "used" memory, it can very quickly be freed up by the operating system by evicting this cached data back to disk if that memory is needed elsewhere.

This can make Linux appear more memory-hungry, but in actuality a better description might be that Linux is more effectively using the resources at its disposal. I'm not saying that this is what's happening in this case, but it's a possibility.

Active is fully-fledged in use memory, mapped into one or more processes

Inactive is where Active goes when it's less in-use. Cheap to reactivate, but relatively costly to free: can still be mapped into processes, and may be dirty (modified) and thus require writing to disk before being unmapped and cleared for reuse.

Cached is where lesser used Inactive cached data goes before it dies. More costly to reactivate, but cheap to free: No longer mapped directly into any process, and strictly consists of only clean (unmodified) pages that don't need writing back to disk before clearing.

Wired is pinned-down memory that can't be swapped out. ZFS's data and metadata caches are counted here, since it maintains its own (known as the ARC - Adaptive Replacement Cache, after the algorithm it's based on) instead of just relying on the traditional VM page cache.

    free -h

An application doesn't magically allocate less memory when running under a different kernel. The underlying idea must be that LLVM wins over gcc in a real world scenario, which certainly would be interesting, but there is really nothing to suggest it here.

The kernel VM is all about heuristics. In a memory pressure situation, it's constantly discarding cached pages that it thinks are better used for other data, making decisions about whether to swap out some data to make room for more cache, etc.

If you remember/look at the history of Linux VM and swap behaviour tuning and algorithms, there have been large improvements and regressions in this area historically.

But even the server part, due to vague phrasing, could mean that his VMs are doing OK with 500MB under FreeBSD and needed more with Linux.

But yeah, it might be due to different configurations or misinterpretation of memory stats too.

Different default allocator can make a difference, though - FreeBSD defaults to jemalloc iirc.

Yes, Linux uses spare memory extensively as caches which can be dumped immediately as applications need the memory for usage.

Unfortunaltely, he didn't mention how he measured memory usage on both OSes.

Functionality like this is basic OS design knowledge.

The modern VM architecture was definitely introduced after 3BSD or 4BSD, since NetBSD only introduced a unified buffer cache in 2000 and is also derived from 4.4BSD.

[1] https://www.usenix.org/legacy/publications/library/proceedin...

I don't think anyone's trying to say that Linux is so special and glorious (beyond BSD).

Most likely I'd have used the system monitor that comes with KDE.

Yeah I could get some more RAM, but this box is a good testbed for software with a leaner streak, bloat does not excite me as much, sorry. Funnily enough this seems to offend a whole lot of people, as if I owe it to them to have more RAM on my m/c. It is probably worth it just for that amusement.

Definitely interested in giving *BSD a shot. The thing that has stopped me so far is the difficulty in sharing data between them.

EDIT @DanBC

> 70 tabs is not normal and 700 is just, well, weird.

So I have been told :)

Firefox manages it well enough though, I would assume Dillo would too. Dont want to hijack the thread with why I abuse tabs so, but I still contend that 1 GB is enough if the code is tight. 1 GB is a huge freaking load of memory if you think about it.

I'd be interested in what happens if you run 700 Dillo instances?

I'm willing to bet that the vast majority of computer users don't ever have more than 5 tabs open at any time.

Totally off-topic, but Yes :-)

.Net has a compiler built-in (you may need the SDK to get the command-line version), many systems have a compiler for a shader language, and your packet filter may ship with one.