That depends on your use case.
2 Likes
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. 
8 Likes
Well I know the right answer for my security practices: after the intended function has been fulfilled, either manually or automatically terminate the process.
See also:
4 Likes
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.
5 Likes
If money isn’t particularly a consideration, and there is not enough RAM for your use case, then you can upgrade from a 3GB model to a 4GB model.
2 Likes
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.
4 Likes
Does this need a new phone or can the mainboard be replaced?
1 Like
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.
3 Likes
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.
2 Likes
Classic clickbaiting. Really distasteful form.
1 Like
I think you may have missed OP’s use of sarcastic humor. 
(Unless you’re trying to be funny, too…?)
4 Likes
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.
2 Likes
Yes. Thank you.
1 Like
[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.
Here is the end result:
5 Likes
I definitely don’t have the space… but I’ve been meaning to install an SD card – had the phone over a year and don’t even know if the slot works.
Swap on SD card? Hmm… 
2 Likes
Ha! I should have read to the end before replying. 
1 Like
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
1 Like
The Micro SD will be defective in a short time. Problem is well known from users of the Raspi with apps that write lot of data to the SD Card
1 Like
I believe that was addressed in the OP. However it’s up to the individual customer as to how to prioritize things. For myself, I won’t be rushing to use eMMC or µSD card for swap. Swap-over-the-network anyone? 
(This is not as silly as it sounds, given that the µSD card is quite slow. The real problem there would be loss of connectivity, and the resultant hanging.)
1 Like
Yepp, on the Raspis most of the SDs fail after only 5-6 months 
1 Like