Librem 5 v2 spec-ulation


#41

No, power is proportional to frequency squared.


#42

Then I must be misunderstanding your equation 15.92 above.


#43

Sorry folks, I was going by memory, and well… I got things backwards. Power is proportional to frequency and proportional to voltage squared, not the other way around.

Also, this is only useful for eyeballing, as it’s based on a very simple model: a CMOS circuit is basically a capacitor that gets recharged at the switching frequency. In reality, stuff happens and it gets complicated.

According to the simple model, power is the product of voltage and current. Current, in turn, is proportional to frequency and voltage (I = C∙U∙f). I.e. P = U∙U∙f∙constant .

I have edited my reply above to reflect this. Sorry for the confusion.


#44

Why anybody absolutely needs 8 GB of RAM on a smartphone eludes me. I am on my Tuxedo Laptop now with MX-18 and have 16 GB of RAM some 14 of which are sitting unused while I have three applications up and running besides this browser.

I think you’re forgetting it’s a phone, and some, maybe even most, are gonna use it like a phone. They’re going to leave instances open, and play games, and have multiple things running in the background all at once without thinking about it. Linux isn’t ram hungry like most, but I’ll wait till I see how 3gb serves the v1 before I judge, though my gut says 6gb would be better for what they have in mind.


#45

If it works anything like Android, this is inescapable. You don’t quit things in Android, it goes off to the background, and you have to go to whatever the hell the call the thing that shows you what’s running and tell it that goddamn it, you wanted the app to QUIT.

Since I generally want apps to quit and quit draining my battery and using up bandwidth in the background, this is very aggravating to me.

I hope the Librem 5 is not like this.


#46

Yet to be seen but I liked the way it was done on sailfish - the application is either active (has focus) or inactive (automatically minimized onto desktop). Application needs to maintain its inactive state and minimized icon/animation/status (basically you have a canvas to draw on whatever you wish to be displayed on minimized state icon) but if you abuse it (update too frequently) you won’t pass QA and hence will not be allowed on app repo. of course there are side repos and there you can do whatever you want. If you don’t want the app you simply close it with simple gesture (which unfortunately has been removed in recent versions)

System/user services are just like normal daemons except need to be aware of low power state to avoid confusion (or prevent entering such state and hence draining battery). The state change is advertised via dbus and better to handle it properly as in LP all your timers and clocks are screwed - you cannot rely on waking up on the timer (poll/select/alert), only when system wakes up. So need to prep for suspend and quickly do the needful in wakeup slot.

Needless to say if any app is keeping active state (being interacted with) system does not enter LP state. Inactive apps however need to assume they are already in LP and not do any active processing.

In other words

  • Full linux multitasking is maintained
  • Apps need to care about battery, system will not force any app to sleep if it is busy
  • system enters LP state if all apps yield and apps/services better to be aware of it
  • if battery drains fast it is usually some app preventing system to go to sleep (LP) which could easily be checked by commands like top (app in D/R state)

but for people who do not pay much attention which apps they install/use not forcing sleep could disadvantageous.


#47

I should respond and note that your preference is yours and is not mine to criticize. My use for a smartphone, being different, requires less memory. While I can chose to game-though I generally do not do so- I am unclear that it would consume much memory. I would rather, in the rare instance that I play a game, do so with a larger screen where the experience is enhanced. To use a smartphone with a monitor means either anchoring to a base or seeking a mobile experience of more heft in transport. To each his own.


#48

WiFi 6 is Intel marketing it’s actually 802.11ad at 60GHz instead of 2.4 or 5, so it won’t penetrate walls but it will allow for way more bandwidth / channels.


#49

:slight_smile:


#50

To each his own, but you’re more than welcome to criticize my opinions; they’re not perfect. I agree with you that 3gb RAM should be plenty for Librem5 in 2019-2020, and we know Purism plans to support them for 5 years. Consider then that the v2 won’t be out for another year before it’s 5-year support. That’s 6 years of uncertain future, and I’d rather not start it lowballing the RAM when they finalize the PCB.

We don’t know what apps will exist in the future or how much RAM they’ll need, and we can guess but have no way of knowing what people will actually DO with Librem5. After all, no phone with it’s abilities has ever been on the market before afaik. Let’s not be too hasty in saying 3gb is enough for all. Flagship specs are not a priority, but a little more headroom for memory is justified.

TLDR: 3gb for Librem5 v1, perfect. Librem5 v2 should have 4-6gb. Extra headroom for an uncertain future.


#51

No.

When I leave an app I USUALLY want it to shut down completely. Not iconify, not go to sleep. I want it to GO AWAY.

That’s why there are separate “close” and “minimize” buttons on a window. They should do two different things. I noticed a fad about 20 years ago for disregarding the close button and pretending it was an iconify button and I still want to slap the jackass who first pushed that. Perhaps someone at Real Player. (Now that was an obnoxious, cancerous piece of crapware!)


#52

Yes, and that’s how it still is in sailfish (but not in android or iPun) - you either minimize the app (by pushing back button) or close it (by swiping down or longtap+close after minimized). Essentially you have similar possibility on android as well by going to task list and swiping out the task - it’s supposed to be closed whether it was inactive or hybernating.
Which is why I said unfortunately - because now you need to make similar number of gestures to close the app on sailfish as on android (back longtap tap vs back tap swipe), while earlier it was one downward swipe.
And please don’t tell me you want backbutton to close the task. I would accept it only if there’s similarly simple gesture to minimize it - I definitely need multitasking and ability to switch between tasks. Single-tasked smartphone is nonsense.


#53

Which is exactly my issue.

I’m continually having to go to the task list and clear out crap that should have closed when I wanted it to go away.

There ARE some things I want to keep around, so NO I am not advocating for single tasking, but that shouldn’t be the default behavior by app writers who seem to think my only purpose in owning a phone is to run their damned app.

Ironically the only thing that works properly on Android is incoming phone calls!! (Which is actually why one owns a phone, right?) When the call ends, the app GOES AWAY.


#54

Thank you for your thoughtful reply, more timely than mine. I understand your point completely and do hope that the flexibility for RAM delivery might follow. Engineering will determine this as much as both the reception and the marketing success of a first version of Librem 5. It is hoped that the people at Librem can have enough success to justify the development of a second iteration as well as enough fortitude to go through the support and the development of yet a second generation of the device.
Should both battery size and phone hardware efficiency allow the extra power drain which is represented by the extra RAM, it is hoped that this may be possible. Advances in efficiency of battery design, RAM power consumption and development of IC design in both energy consumption and heat sink diversion may allow for economies of both energy storage and use may allow for such power as may forward your desires. I suspect that some limits will be reached which will compromise the absolute maximum functions of devices and the constraints of what may be possible. We certainly have not reached these yet and hopefully we will not reach these for some time to come.


#55

I’d certainly like it. I think a lot of people would. Maybe even the Purism design team would like it. But it just might not be possible in time due to budget constraints and power draw, as you pointed out.

But hey, I’ve been willing to accept from the beginning that in order to acclimate an freer operating system normally used for computers to a phone, corners gotta be cut, yo. A Librem5 with only 3gb of RAM is better than the Librem5 not existing, considering what it actually means.


#56

Thank you for clearly stating the problems with apps (for a phone in contrast to programs on a computer). So it is not simply moving Linux programs to Librem 5 by adjusting for a small screen, There must also be a new handling of battery drain which has not been a problem in the computer world. It could be complex if you want it to stay alive but draining very little power.

Of course the user can kill the process manually in order to save power but it is easily forgotten and there you are with an empty battery. In Android I often have to go to the app list and force some badly behaving apps to stop so I have some understanding of SteveC.

Unfortunately I never got into Sailfish because I was so disappointed by Nokia killing the N900 series that I went to Android. The new versions of Android are better at saving power but there still are problems with badly behaving apps.

So there could perhaps be a need for an option where the system will watch the apps draining battery and alert the user according to some criteria.


#57

you can still do that closing swipe gesture from above, but you have to do it at the left or right corner


#58

Modern Android aggressively kills applications in the background. Android apps have to be designed around this paradigm: That is the app can be killed at any moment when in the background, and must be able to seamlessly restart and pick up where things were left off.

It is easiest to see this happening with your browser. Open it, navigate to a page, and then go back home and do something else for about 3-5 minutes. Open the browser again, and you’l notice ho the page has to load again. This is because the browser was killed.

This is all done in the name of battery savings, and is very effective. I would be very surprised if Linux doesn’t develop a system very similar.

So if you are using Android from 6 and on, you don’t need to quit your app, because android does this for you. (You can make exceptions for certain apps however.)


#59

Oh yey! thanks for the hint, now that new battery just arrived it’s time to sail again :slight_smile:


#60

Absolutely! Smartphones may achieve some PC like status in some future world, but both size and power limitations make having 3,4 or more applications open at the same time a much more difficult business in the form factor supplied. It is not always easy for a PC, but it is definitely workable.
I use my smartphone for at most 2 functions at one time, and that to some limited extent. Otherwise, I would need to use multiple instances of recharging or some power bank as well.
It would be wonderful if applications could be placed into some ‘hibernation mode’, frozen in time at a set point for restart, much as a PC can be placed into hibernation as a whole. Perhaps this may allow for some lessened processor use if some retention of a task can be had as frozen input awaiting an applications address and if some limited application function drain is involved to such a function at a diminished power consumption. Neither iOS nor Android have had this capacity so far as I know and I am not sure that it can be managed in Linux. If there is any reasonable possibility of this whatsoever, it is likely to emanate from an Open Source community.