Certainly a valid and useful suggestion but
uuu would still be needed)A couple items i thought about but more nice to have or in case none of my top 5 items are being considered:
I’m opposed to this from a troubleshooting standpoint. It’s nice to know that when I pull the battery there’s no power going anywhere and having another battery to pull, maintain, replace, seems like it would be more inconvenience than convenience to me.
Ok how about not a battery but a super capacitor? Something if you need to deplete the component you can say hold the power button for 40 seconds or some other process to ensure you can trouble shoot without power present?
I’d rather see efficiency improvements making battery swaps irrelevant.
Please check: apt list systemd-timesyncd and if not there:
Impulse power for when the dilithium crystals are depleted Cap’n!
v247.3 installed, automatic
I believe the iphone does something similar, while it doesnt have a second battery i think it just shuts off with less than 4% remaining and doesnt turn on with less than 4% charge either.
That 4% will keep time even if the phone is powered off, so acts like your second battery. Its hard to know for sure though since the iphone turns everything on at restart sometimes (wifi, bluetooth, 4G probabbly to sync time right away)
The CPU we use now does not support more than 4 GiB RAM.
As for PCIe devices, it would be interesting to see a comparison of power usage versus eMMC.
That might be a contradiction in terms.
The point of killing something in hardware is that you are really cutting power to it / making it 100% guaranteed non-functional, even if the operating system software is compromised. The easy way of making it configurable would be to do it in software but then you lose some of the legitimacy of the switch.
Regarding turning GPS off, I think Kyle (? or someone from Purism) has spoken in this forum about the reasons they didn’t provide a fourth switch for that. I mean it’s always a valid opinion that there ought to be a fourth switch but there will also be valid opinions that three is enough.
However that is a separate discussion from the more general discussion about a fourth switch that is configurable and which can provide whatever software function the user assigns to it. (Flight mode? Silent mode? Notifications off? etc.)
4.2. Why are there only three hardware kill switches?
Pinephone solved the problem of “too many hardware kill switches” by making them tiny and hidden behind the cover. It makes them very inconvenient, but as an advantage, you can independently kill the selfie camera, for example. Maybe, the next Librem phone could have such switches in addition to the ones we already have.
I was thinking of just adding a chip on the board that is a Field Programmable Gate Array (FPGA), so like a ePROM this could be flashed and secured, but where the programming part will set the switch in a certain way to have a certain result. It would not be based purely on software.
For the purpose of security, an FPGA is effectively software, unless the only way to reprogram it is from outside of the phone.
What matters is that no software installed on the device can change the state if the user doesn’t want to. We had to find something that the user can do, and the software can’t. It’s physical switches.
For your reconfigurable switches, you’d have to find a way that your configuration (e.g. FPGA) can only be affected by manipulating extra hardware.
I’m waiting for the tricorder app.
Thanks for filling in the citation for me.
I would rather Purism used some of that space to move the SIM tray (i.e. SIM card and uSD card) to behind the battery (same as where the OpenPGP card is).
Exactly why I wrote “might” and emphasised it. The obvious implementation would be problematic. The non-obvious implementation (using programmable hardware) raises the question of how you provide a robust and workable interface. Maybe a souped up breakout board that gives access to this new chip?
However another approach on it is that … the fourth switch is not a hardware kill switch at all. It is a software kill switch. So it is convenient and customisable but nowhere near as robust against an attacker. You may be dead-set on having a fourth HKS - which is fine, since we’re just throwing around ideas.
Since we’re talking kill switches, some people might want to be able to hardware kill WiFi independently of Bluetooth.
You can use the three hardware kill switches like dip switches. You can get eight possible hardware configurations out of three of them. Sixteen with four.
128GB eMMC would be nice at the very least. Y’all have to compete with the PinePhone Pro…
I want Librem 4, not Librem 6 
I want Librem 4 (4.7) too. RYF.
Not Librem 6
or NVME but i agree with 64GB min, better 128GB, I have a NVME 1TB (i paid ~$150 for it) running as my main drive for a desktop computer and it is ridiculously fast compared to SSD SATA (2-5times about depending on what you do, based on benchmarks i ran). Is eMMC slower or faster than NVME (thats particularly relevant when it comes to latency for a phone)? One thing i have noted and not sure if that is related to the Apple Desktop i am running the NVME on (which barely supports it from 2013, requiring KEX updates), or because of Linux not providing good support, it seems to be more crashy and less reliable (e.g. system just freezes sometimes under heavy load, especially when processing large image files).