How are you measuring the memory usage? 15 GB sounds like a count of virtual memory that includes lots of mappings that aren't physical memory.
On my FreeBSD desktop box right now, the main Firefox process has 1890MB RSS, and the content processes have anywhere from 248MB to 675MB. (Swap is completely unused.)
> if your don't have swap configured then virtually none of the Linux sleep mechanisms work. When the device sleeps, it stores the RAM contents in swap. If you don't have swap, you can't sleep.
???
Suspend-to-disk / "hibernation" (S4 in ACPI terms) is a really unpopular way of "sleeping" these days. FreeBSD outright does not support S4 (except S4BIOS).
The usual sleep is suspend-to-RAM. These days there's also S0ix which means turning as much as possible off but not changing system power state. Mobile phones are probably doing something like that.
> on low-RAM systems that can't keep the entire git folder cached for faster lookups
If you rely on caching for the git directory, the first time you navigate to a repo would be very frustrating too. You can't always rely on caching. Sometimes you have huge repos. Sometimes they are mounted over NFS and git status takes >10s. :D
IMO git status shell plugins are unnecessary and not worth it.
> HiDPI is a known weakness in Linux
Maybe stop using the ancient terrible windowing server ;) It's a non-issue with Wayland.
On my FreeBSD desktop box right now, the main Firefox process has 1890MB RSS, and the content processes have anywhere from 248MB to 675MB. (Swap is completely unused.)
> if your don't have swap configured then virtually none of the Linux sleep mechanisms work. When the device sleeps, it stores the RAM contents in swap. If you don't have swap, you can't sleep.
???
Suspend-to-disk / "hibernation" (S4 in ACPI terms) is a really unpopular way of "sleeping" these days. FreeBSD outright does not support S4 (except S4BIOS).
The usual sleep is suspend-to-RAM. These days there's also S0ix which means turning as much as possible off but not changing system power state. Mobile phones are probably doing something like that.
> on low-RAM systems that can't keep the entire git folder cached for faster lookups
If you rely on caching for the git directory, the first time you navigate to a repo would be very frustrating too. You can't always rely on caching. Sometimes you have huge repos. Sometimes they are mounted over NFS and git status takes >10s. :D
IMO git status shell plugins are unnecessary and not worth it.
> HiDPI is a known weakness in Linux
Maybe stop using the ancient terrible windowing server ;) It's a non-issue with Wayland.