Being able to replace the battery easily is a must. Being able to replace the screen should be at least possible. For example, both is easy in the Fairphone 2.
I personally, do not care if it takes a little bit more space as long as I can replace the battery and screen. As @amosbatto pointed out a damaged screen and battery degradation are the top most common problems.
It looks like it will be relatively easy to change the battery. It appears as though the rear cover can be removed without tools, and the battery contacts against sprung contacts.
Easy as it gets. Last time I had them swapped like this was with GS3 and Note 4.
Canât ask for more.
Great job
Yes, it looks promising. I would love to see a very simple mechanism to replace the screen. Maybe similar to what Fairphone uses.
In general I would like to see Purism working together the company behind the Fairphone. Mainly, because both companies have expertise in different areas. Purism focuses on the software and privacy. The company behind the Fairphones focus on sustainability and the fair sourcing of parts for the phone.
So if the battery is replaceable, what is the highest capacity available for purchase? Can I get a 6000 mAh battery in my Librem 5, even if it means the case bulges?
Iâm pretty sure 3500mAh is the maximum available with the given dimensions, but maybe in a year you can buy 4000 in the same size?
For 6000 you would probably have to cut off the lower part of the back 
Or 3D print a different back cover that accounts for the thicker battery
Or in some years batteries are more dense� #thefutureisbright ?
You say that as if thatâs a joke, those things have been around for a while.
A few years ago they made third-party battery packs just like that, you didnât even need to 3D print it yourself. Mine for the LG Optimus 2X looked like this.
Those 3500 mAh batteries were of crap quality though so the battery life was just slightly longer than the original which was a shame, would they be true 3500mAh the battery life would be phenomenal.
Almost off topic here, but does anybody know if more used storage in the phone has an effect on how long a battery lasts on a single charge? I used to suspect that a phone was dying faster because I had a shitload of music in storage on the device.
The joke was more aimed at @Caliga for saying to cut the back cover XD the 3D printing part I absolutely meant as a legit better suggestion than cutting up your phone 
No, whether the bit in flash is set or cleared does not affect power consumption. Indexing lot of files - yes, so if player does not use smart indexing (eg incremental) it may book a bit more cpu cycles to walk through vast pile of music.
SD card though does affect battery as itâs yet another periphery. And if it does not use filesystem which supports suspend (eg btrfs) - it wonât allow to power-manage itself (by default itâs exfat).
Years ago, I used to read about differences un electricity consumption based on how many 1s your RAM had to hold 
.
To be honest, I donât think the amount of data in your flash storage makes any difference. If you donât insert an SD-card at all, yes, but how full it is? I would be rather surprised.
Edit: Future readers: please read ruffâs reply and my next post. I didnât think this through!
That must be true if the flash controller is blind to the meaning of the bits that the operating system gives it. It would just have to treat the entire capacity of the storage as one giant file, all of it important and needing to be carefully preserved, with no concept of empty or full; it is always full!
But operating systems can often tell the controller which bits represent useful data and which are free space (i.e. TRIM). So perhaps the controller could use that information in a way that affects power consumption. I have absolutely no idea if this is done in practice. Iâm just speculating from abstract principles.
I share the hunch that any noticeable difference in power consumption probably comes from applications that read the files rather than from the actual storage of the files.
Trim is a bit different, trim is like free() call in c - it just says - return the block of memory back to the pool of available (heap). It doesnât touch the actual memory content. Similarly trim just marks the blocks as free in the flash overlay map. Which is the reason it is always warned - itâs not a secure delete, the content remains in the disk.
What does consume memory is flipping the bits (write) and checking their status (read). Assuming it is flash technology - writing a single bit may trigger zeroing of entire block and rewriting it. But again itâs part of write.
flash memory is nonvolatile - keeping the bit status is achieved by charge trap, that does not consume board memory (unlike RAM).
Yes youâre quite right. Flash does not require energy to maintain the state of bits, being non-volatile. I have vastly over-stated the possibility that trimming could affect power consumption, forgetting that the memory does not need to be actively refreshed. Perhaps it can affect the power efficiency of some read and write operations, but the difference will be tiny.
I started out intending to make the point that, from the point of view of the hardware, there was no concept of being empty or full. Then I realised itâs more complicated than that with Flash and ended up confusing the matter! Shouldâve thought more before opening my mouth! 
Looking at these statistics, it seems like a small wonder that Iâve never broken my screen in the 4 years or so that Iâve had a smartphone of some kind, despite never using a case. It might help that for a lot of the time I was using a ZTE Zinger with a tiny screen, and another lot of the time using a OnePlus One that already had an unusably cracked sceeen when I got it (I used a mouse for input). This phone was later stolen and destroyed, though, so for the past two years I have been using another handed-down OnePlus One, but even this one still doesnât have a cracked screen, despite getting too close for comfort a couple of times.
My old ZTE Zinger had a fairly immersed screen, which I really liked, but my newer used OnePlus One sadly has a much less immersed screen than it.
Depending on the flash controller, TRIM will preemptively zero sectors. It can also prompt re-organization of the physical sectors in non SLC drives, both for wear leveling and because the drive will write in SLC mode for speed, but then want to re-pack the data using all available layers, which is a slow operation. As for why it zero sectors, changing a single bit requires zeroing the entire sector, then rewriting it with the bit flipped. The 1->0 transition is slower than the 0->1 transition, and even if it were the same speed, not doing it in advance would cut the speed in half.
The reason you canât rely on it being a secure delete on any arbitrary drive is the spec doesnât require the drive to do anything, the firmware is closed source so we canât tell when it will do something, and even on drives which do actually pre-zero sectors, they wait until the drive is idle to zero and repack data, and there is no way to ask what the status of that process is.
On a related note, SSDs do require power to maintain their state; they are not perfectly non-volatile. The potentials internal to the cells drift over time, which will cause bit-rot if left unpowered for long enough (for most drives, multiple years). While powered up, but idle, the controller will keep track of how long itâs been since a cell was written, and periodically check its potentials, rewriting the data when they drift too far. The energy required for this is tiny, but it is why using SSDs for long term data storage is not a good idea.
Yes, sure there are various implementations but as you rightly noted - spec does not require doing anything so you cannot rely on it. Usually thereâs lazy zeroing as part of background garbage collection but again it uses its own logic which considers power state, leveling score, free space, etc.
And yes, some smarter controllers are doing recharge of the blocks to improve data integrity - again as background task which preemptively tries to re-locate bad blocks. Which is again subject to wearing and power policy.
So gathering all facts - full disk may consume more power because it does not have luxury of freely choosing new blocks, space pressure will require more aggressive zeroing. But this would be implementation specifics and may change with a new controller firmware release, as vendors are trying to balance power/wearing/speed, which is endless chase for perfection.
