Welcome! I hope you enjoy your Librem 5 like many of us do!
If you have any additional tips, I recommend sharing them in the Librem 5 wiki, particularly the Tips & Tricks section. Also, if you have any additional information about swap files, feel free to make edits or corrections to the section about them.
Again, welcome to the forums and I hope to see you around!
I wasn’t doing anything special. I was just catching up on Mastodon reading using Tuba and surfing the web. There were several other open apps but I wasn’t trying to use a lot of ram. Just doing what I do. So it seems this trick does have benefits for my use case.
I’d actually push back a tiny bit here. It has more to do with the operating system itself than the hardware.
By default, desktop Linux evicts no running apps from memory. In the case of both iOS and Android, the OS is very aggressive about killing processes to keep memory pressure low. They will issue warnings (iOS docs, Android docs) and then stop or kill processes as necessary.
Desktop Linux (and therefore PureOS) has no such mechanism. The closest built-in functionality would be the OOM-killer, which issues absolutely zero warnings and (in the case of the Librem 5) isn’t going to activate until it’s way too late to keep the system running smoothly.
A lot of this is just for historical reasons, and the historical solution has always been to make sure the machine has a reasonable amount of swap available. So to maintain compatibility with the current standards for Linux apps, Librem 5 really needs swap.
If we ever seriously wanted to eliminate the need for swap, we’d need something like the following:
The desktop (Gnome or phosh or some user-space component thereof) would need to keep track of which apps have been interacted with most recently, and which apps are most likely to be interacted with in the near future.
It would also need to have a process to keep a close eye on the system’s current memory pressure.
As the memory pressure went too high, it would start notifying the oldest apps that they are about to be closed. (I don’t think this API exists today, so it would have to be added.)
Apps which receive this signal would need to save their UI state and exit before they get killed.
Apps would need to also adopt a practice of restoring their previous UI state upon launch. (To make the user think they were running the whole time.)
At least, that’s how iOS handles this problem. I don’t know about Android, but I expect it’s similar.
You might expect applications to stay running in the background when you navigate away from them. And on desktop Linux, that is definitely the case. But on a mobile system with such limited memory, this would not be possible.
You really only have two options when a user opens an application and navigates away from it:
Kill the app and free the memory, making the user sad when they come back. (Unless you are sneaky like iOS.)
Let it run and continue taking up memory, eventually running the system out of memory. (Unless you can swap it out as necessary.)
Tradeoffs are everywhere! I don’t know what the right answer is.
Well I know the right answer for my security practices: after the intended function has been fulfilled, either manually or automatically terminate the process.
Easy as this: Power to users. I want to have the memory management in my own hands. I know better what I don’t need. A system may closes 3 apps from 15min ago with total amount of memory: 200mb. I may just kill the app I used 2 minutes ago that takes 500mb.
There is another issue for L5. Start up closed apps take some time. More time as modern Smartphones. So this is a strong reason not to close apps you may want to open again compared to iOS etc.
The real thing that I miss is to easy access background processes. While we can always open usage app to kill those processes, it would be nice to access them directly from Phosh to kill (or reopen) them. But I’m sure it’s coming some day - it’s something devs have also in mind.
And then people make entire websites dedicated to avoiding that behaviour. Both as Android developer and user I hated having my apps randomly killed (more and more aggressively release after release). I don’t miss it.
I hear you. I’ve dabbled in app development for iOS and Android and this behavior has definitely driven me crazy.
As a user, it’s not as seamless as Apple would like you to imagine. Even their first-party apps can do a very bad job of restoring the state of the user interface once the app has been killed. And the side effects can be painfully visible.
Official answer would come from Purism but I would think that getting a new phone is by far the easiest, particular as the eMMC drive is soldered on (so you have the hassle of migrating the contents with either approach) and also taking into account downtime if you send the phone in for Purism to replace the mainboard.
Indeed. With the loss of tone in online communications, it could easily be taken the wrong way. I certainly had a negative reaction to the topic, purely based on the title.
My suggestion (without moderator hat on) is that the topic title should have included either a smiley or a “/s” sarcasm indicator, with the former being more widely recognised.
[EDIT: I thought I was replying to alexmarkley’s original post, but the forum doesn’t seem to indicate that. The “Note” below is not my comment but the OP’s statement to which I am replying.]
Note: These commands are intended to be run from a root shell. I didn’t prefix anything with sudo because I would really not like for someone to blindly copy/paste and ruin their phone.
Not sure that this will actually make much difference. Anybody poking around this forum can easily find out how to obtain a root shell on the L5.
There are other ways to create and activate swap space, without touching the phone’s internal workings (other than adding the one line to /etc/ fstab). The SD card is in any practical sense a permanent drive, being such a pain to install, and is therefore a reasonable location for swap space. For example, gparted can be used on another computer to create a swap partition on a new SD card before it is installed in the L5.
Users who are concerned about carving swap space out of scarce internal storage might find SD storage preferable for that purpose.
The swap can be turned on either by a line in /etc/fstab or by a swapon command.
Copying and pasting the fstab addition is not itself a risky procedure. So long as the pasted command includes “none” in the right position (meaning no mount point), the worst that can happen is that the expected swap space fails to become active.
For a swap partition on SD, the additional fstab line should specify the partition’s UUID. Note that blkid doesn’t work on the L5, a further reason for getting another computer involved. On the other computer, the echo command can be set up in a text file and copied-pasted into an ssh terminal.
I am not sure if this will be good for the health of the EMMC? The EMMC IMO does not like a huge amount of write processes and a defective EMMC woul produca a brick - phone is dead