Disk usage and where should apps come from

I read an article opinion envisioning the future of app management - namely flatpak, snap, appimage… containers - and it seems likely to go that way: containers running in VMs, running in containers in VMs all the way down. Convenience is the enemy of security (not quite symmetrically) and now it’s slowly coming for the app management paradigms of linux world. Compiling from source is rare and distro specific packages and repos are harder to find. But as does the article note, and is noted in the comments section, the overhead that comes with containered apps is substantial.

The bigger picture is, this sort of behavior feeds the (Windows-like) cycle of “get the newest hardware”/“replace your rig every two years”, and even adds to the environmental impact - also via increased energy consumption (it’s not nothing even if it’s not at the same level than other factors). But at more micro level, at the subset of L5 users, this does get to a point: if we have limited resources on our devices, ca we live with this development? I think I remember reading that Purism and/or PureOS favors flatpaks, and with limited staff this seems reasonable from resource management standpoint. But very concretely at the user experience land (in my own device) I’ve noticed the effect of this as the L5 has suddenly come up against some hard limits. The 32Gib eMMC isn’t that big anymore - well, not as big as it once seemed to be, meaning that I didn’t see it as the most likely limiting factor of L5. Sure, even from the start “more is better” dreaming gets you imagining that 64 or 128 is better (they are after all bigger numbers) but to put it better to perspective, I’ve been running a decade or so my much more powerful desktop linux (gaming and all) with much less than that. And before you do the math, yes, home and files are stored in another castle - I’m talking about the root file system, the operating systems and apps that need the added benefit of using the same filesystem and quicker HW (compared to the separate other mediums like memory card in L5 that has plenty of room). The space in the eMMC, it is running out. I can’t fit all my apps there. This is a problem, and it seems to be because apps aren’t made available in a manner that L5 could more efficiently use.

Now, there are a couple of other factors here. I’m not going to cover how much more containers stress the CPU too - that is another limiting factor but gets also to heat and power management territories (and then this would be a reeeeaally long post). That is bad too. Also, there is no way L5 segment can (yet) pressure app maintainers to suddenly offer maintained packages for PureOS/L5 (although, they certainly can), which includes also that those packages are for aarch64. The containerization (and just to emphasize, I actually had to test an app by having to actually install it to L5 using docker) allows us to get apps that would otherwise be beyond the L5 realm. This is exactly what the android-ecosystem via emulators is too, as it’s not the most efficient way. Let’s face it, any device is useless piece of technical art if there it’s not able to do stuff that we want and need. Filling that void on the short term is a good excuse for going that route. But the long term consequences… that is where I see trouble brewing.

It’s all a matter of degrees. In this also. “How many apps do you really need”, is a silly question these days if you are using a “smart” phone (or device or computer - call L5 what you will). A better would be, “how do we manage the useable space best”, I think. Or, “how do we get the most out of it”. And it’s not by using containers. I did a quick disk usage analysis (Disc usage analyzer and Filelight are both available as flatpaks but baobab and filelight are also as a package via apt - make your choice) and wow - the /var/lib/ section is huge compared to what everything else uses. Now, this is faaaaaaar from conlusive or proof or rigorous data but compared to what I have in my desktop, it’s bad. It may not be similar with evereyone - your usage may vary and you may be smarter about it, but it is worth having a look.

Now then… I have already partly lost the train of my own thought while writing this and I’m trying to give it chase… but if I remember correctly, the point that I started making was something about how L5 is susceptible to bloat via relying too much on flatpak and others. It will make L5 already has caveats and this may seem to become one as well but somewhat unnecessarily. They shouldn’t be the automatic choice and relying on that technology might be a bit hasty. When installing (or recommending) apps, trying to find a proper package may be worth the trouble. This is not to say that flatpaks wouldn’t be useful or necessary (or, indeed the only option at times).

Beyond this warning though, we might need to hash out the best strategies or rules of thumb how to best manage the relatively limited resources of L5. This includes, how to maintain the eMMC space, how to keep it tidy. We’ve already had some comments that have touched this (individual use cases) but I think there is more to explore here. So… How do you make the most out of your space(s)? How to curate the number and size of your apps? How and what to clean from the memorybanks? How can we find the best alternatives? Are the security (sandboxing) benefits bigger after all?


Just a few small thoughts …

Given that the eMMC drive isn’t that fast, I would like to see the speed of the uSD card increased to match that of the eMMC drive. Is this possible? I don’t know.

Then one could contemplate unifying the storage across both i.e. the root file system on a single logical storage device spread across multiple (two) physical storage devices. The kind of thing you get with LVM. Is this possible? I don’t know. (Of course if you do this then you completely give up either removing the uSD card or having a set of uSD cards to flip in and out. So it would be just one way of working that a customer would choose, if giving priority to available space over other things.)

I doubt that, but have actually no idea. But for sure, there is some tiny difference in which filesystem you format your card to and if memory serves, in what setting you use (are blocks still a thing?). And what’s most efficient for you depends on what size files you are transferring. Someone more familiar with i/o operations might have better thoughts on this.

Regarding the speed difference, those who have tried multiboot using SD card: how was the experience regarding responsiveness vs. eMMC? SD would give more space but is the downside too inconvenient.

At one point there was some talk of trying swapping memory to modem or wifi card slot (probably needs an adapter to physically fit it). Or do I remember wrong? I don’t think anyone did. A curiosity in stead of a viable option with L5.

The Flatpak bloat - cleaning out? thread had a good link and the Low disk space - how to clean out garbage? had some good notes. But this important info is almost lost to the forum. It’s not for instance offered via an app (how about in mobile settings or shop the info : “this is how much your flatpaks take, here are the alternatives and this switch lets you clean not needed”, as a way to keep device in good condition?). Which leads my runaway train of thought to: is this partly a problem of the (un)curated software shop that is not serving the users efficiently?

Your doubts are entirely justified but the uSD card reads very slowly in the Librem 5 e.g. in a middling desktop: 85 MB/s but in the Librem 5: 12 MB/s i.e. literally the same card. So the problem is in the interface, not the card.

1 Like