i am interested in the librem 5 out of a software-developer perspective. i would like to do my own development on top of already existing functionality (like gsm access, grafic drivers and such).
so i am curious about decisions that the development team takes: how is the modem driven (will ofono be used)? will dbus be the rpc (ok, that’s quite certain)? will there be x11 or wayland? how is power managment done? how is the storage organized? will there be an apps-idea where apps run under different users (like android does it)? …
btw: i wonder about the mantra that the os will be PureOS - this is a desktop OS and doesnt fit well with small displays and touchscreen handling. how will this be adapted?
there are so many decision purisms team has to take and i am really curious to learn early about those. maybe even a archiutectural chart would be nice with completion state showing if these components already work succesfully (could be even automated with the tests ).
Let’s begin at the bottom:
PureOS is a perfect choice, as you can attach a screen and use it as a desktop. As they are now partnering with Gnome and KDE, the quest is to enhance existing stuff so it can adapt itself to the small form factor.
For that reason, I’d expect the “normal” Linux scheme of having as many users as you like with their own home directory.
I have no idea about ofono, but I’d definitely expect Wayland and DBus.
And I, too, was thinking about energy management. So, last night I thought about a proposal for that instead of counting sheep
How about introducing something like org.freedesktop.Economy ?
It would have properties such as
PollingPolicyInstant (0…30601000ms) // recommended range rather 1…60 seconds, for IM-like communication
PollingPolicyRegular (1…60m) // for email-like communication
PollingPolicyNews // for news apps, maybe weather apps?
PollingPolicyUpdates // checking for system updates
That would be cooperative, the apps can take the values as hint.
But possibly, an app could even register, like “I want to do Instant-class polling”, and then be signaled by the Economy server “poll now!”. This way, it is possible to orchestrate all the polling/network accesses, which should allow longer (and possibly deeper) sleep states.
This interface could then be used by all applications (also desktop apps) and might even benefit laptop battery lifetime daydream
sure, that’s exactly my guesses, but i did not ask for a brainstorming of us customers with a wishlist but the team at purism to transparently let us take part in their progress.
Of course, I too would wish for more updates, but again the team is small and they have to focus.
What I would have wished for is a post for reaching $1,800,000 / 120% / 2500 preordered phones, hoping that this would push the preorders closer to the 2 million mark (drive has gone down a bit).
Hm… in the spirit of John F. Kennedy, let me say Don’t ask what Purism can do for you, ask what you can do for Purism
For example, we could collect all the data and specs that have been explicitly or implicitly stated, somewhere on the net (including Todd’s interviews on Youtube and the FAQ), put it together in a table, then ask a staffer to verify it, put it on a page and update it during the process. This way, all the relevant information and status would be in one place.
I would also include a list of all the software that Purism and its partners are planning to work on (partly exists in the timeline https://puri.sm/shop/librem-5/)
As an addition, I think it would be awesome to have a list of community projects. Both, wished-for projects and projects that actually exist. Like “Create a weather app” “Enhance existing map app by adding GPS navigation” “Make KCalc work on small form factor”.
That would be awesome. It could help us to have more useful apps when the phone comes out and maybe reduce redundant work.
@Caliga and @shagreen thanks for sharing the links to the posts but these are quite high level marketing babbles. i was asking for more in depth information.
as @Caliga said with kennedy: i asked for what can i do for purism. to do so one needs some transparency in what’s going on (agreed, i did not find the timeline, good to see that).
i told openmoko once to build a house from bottom up, make a stable basement before even thinking of a roof. they had a nice roof, no basement and failed.
another word about “apps”. yes, these are the holy grail in computer business today but why should a free phone follow that? so if someone wants to implement a completly different design, the only thing that must be there for that is the base functionality (back then i had to develop a gsmd for theGTA01 myself to place a call, send sms, … because they did not have a working one). this should be accessible via dbus (i agree the question about dbus was an bad example) and thorrowly tested. once that is done gui elements (like a dialer) can be developed on top.
so my offer to purism is to participate in the testing of the base functionality plus develop automated tests and (probably less interesting) develop a different way of handling a mobile phone.
I think, making the relevant stuff accessible is what is missing most.
If you scroll down a bit on https://puri.sm/news/
there are some more technical articles, admittedly only two on the phone. But it’s still pretty early.
maybe we have different oppinions on “technical article” but: i do not push or put any pressure. i just ask for this kind of mindset when the project is running. we expirienced different in the past with similar projects. there are people around with experience on mobile phones that can suggest improvements early. and i dont talk about people that ask for this or that app but for people supporting in a positive way the long way until a bunch of hardware gets a usable phone.
i just ask for this kind of mindset when the project is running.
we expirienced different in the past with similar projects. there are people around with experience on mobile phones that can suggest improvements early.
and i dont talk about people that ask for this or that app but for people supporting in a positive way the long way until a bunch of hardware gets a usable phone.
I mostly agree. But apps are important, too. If not for yourself, then for people around you that you would like to get excited about it. And I hope we, the backers, get involved in both. Like “this is our approach to power management, what do you guys think?” and also “We can only do the most vital stuff, but if somebody can work on an Alarm/Calendar/Notes/Calculator app, please let us know”
Out of interest, in your OpenMoko picture, what would be basement and roof? My current understanding would be that we have a pretty solid basement, from the kernel that should already support most/all components that shall be used up to the desktop environment. Of course I know, there is still A LOT that needs to be thought about. Will there be a daemon that handles incoming calls and starts an agent in the current user session? Power management etc. That could also be considered basement. And as I am a developer for a Linux application myself, I know how much difference there is between “basically works” and “works pretty nicely”. I hope it all goes well…
you touch the topic quite well: it’s an architectural question. be aware that apps where invented to have a sell-able portion that is detected as such by a non-technical because of its appearance as an icon. but it involves a special structure as you point out: you integrate gui and power managment, alarm and calendar. if you take a look at current apps you see a incredible bad design of a mix of different level of abstraction. i would like to prevent that.
i would like to have a design where function (alarm managment, power managment) and gui are strictly and cleanly separated. that introduces problems for marketing because nobody would pay 5$ for something that is not even visible in his launcher. but are not forced to follow a marketing architecture.
i would say the kernel is the cellar, the basement is user space daemons, the roof is the gui…
the kernel may drive network devices, input devices and such. as you say: phonecall handling (and all modem handling) may be handled by a daemon. even network configuration is user-space and not kernel. exactly network handling is very, very specific on a mobile phone (failure is expected). you have to hand over between all different devices with no interruption for the user. dhcp, dns, routing, … NM cant do that reliable as of today. developer have to rethink the way they implement stuff if failure is the normal case. and the story goes on for higher-level stuff like contacts or even media. you /need/ a central contacts database to gain an integration between phone, email, chat and on.
so i would like to have a solution for the topic with a clear api that can simply be used by a gui program.
you name it: there is alot to do on top of what a desktop environment could provide. i think the road coming from a desktop environment like gnome down to a mobile phone is long and you wont make it in one and a half year (other projects already proofed that ).
instead if one provides the groundwork and define common APIs its much simpler for the community to provide GUIs on top. and a look into other solutions isn’t bad. android has alot nice design decisions (and bad ones as well) that can help to understand what to do…
just look at this thread: Replacement for Google Maps? - it’s a good example for what i mean: people talk about gui (…using qt…) when talking about map provider. i see a map provider as a service in the phone which has no gui at all but provides maps via api for a potential gui. so you can choose both ends: decide to use google maps and qt or osm and whatever or anything else.
on a phone it’s vital to separate things correctly.
I think there are two ways to fail. Not thinking and overthinking (one may replace thinking with designing/engineering)
Let’s take the energy-management API and the address book. If you go the full way with these, like official freedesktop endorsement, Gnome/KDE adoption, common libraries… It may very well be that you have nothing to publish in 15 months. That really does not mean I’m against it. If it can be done, it should be done. But you can still switch a backend at a later time (if you reasonably well separated stuff). [EDIT] And of course, a roadmap for such stuff would be mandatory!
About the map provider / service:
Like a “default map service” that other apps can activate, like the default browser? Yes, definitely.
Like a backend that provides (and possibly caches!) OSM data: Yes, awesome!
But as an abstraction for different types of map data sources? I’m not too sure about that. If the data formats are sufficiently similar, then probably yes. But I would expect the way you can access OSM and Google Maps API it is rather different.
I think it would make more sense one layer higher, similar to the Kate editor-view component which is used by various other applications that automagically have syntax highlighting for for everything Kate has. So, that would be a map view that every app can use and it doesn’t matter where the data comes from. If you mean like that: Yes, totally.
But that would most likely be Gnome/KDE specific. And it might take too long for a first release.
If basic useful stuff takes too long, people might lose hope/interesst. That would be my fear, not oppsing your thoughts, just as a balance
Finally, after oh-so-many days, there’s a new blog post. The most interesting thing for me was actually the link to the plasma mobile roadmap. I wasn’t aware that they already have quite a lot. It also seems like it’s a good place to get involved. (If only I had more time )
Also, quite a few questions that were raised here are (partially) adressed in that post.
EDIT: If all the things shown in this plasma mobile video would work (plus some polishing) on the initial Librem 5 release, that would be at least as much as I was hoping for
I’m disappointed with the amount of information that Purism has given. It’s not a very good start to the project.
As a minimum I was hoping for some description of what the next steps would be for hardware selection, a discussion of technical challenges and some sort community engagement regarding software.
It’s great to see blog posts about hardware testing and the roadmap for Plasma mobile. More please.
I would probably at times like to rely on services that don’t match the spirit of the Librem… even Google Maps perhaps. Or even a Firefox browser. At least as I get started with the 1st generation of the phone. Being able to choose a default provider/app for various features, like @Caliga said would be useful.
Privacy is the ideal and the guiding principle, but we need a phone that appeals to non tech minded people. In other words… Users need the option to give up degrees of privacy to bigdata… Is a cost/benefit choice for each individual.
We can’t let the pursuit of Perfection be the enemy of Progress if the Librem Phone is to have mass appeal.
(my phone won’t always be used in an ‘absolute privacy above all else’ mindset… But I will be glad when I am no longer forced to give location permissions to apps that have no business (haha: that IS their business plan) tracking me.
Ideally I could buy a Librem phone for my 70+ year old Mom and she could take to it easily… without her HAVING to go without (for example) the Google Apps she is familiar with".
[forgive me if things like Google Apps are not feasible on the Librem… I run Linux at home but am not a programmer]
Shouldn’t a device built to empower the user allow the user to do as many things as possible? With option to change how it is used when and as time goes by?
exactly: freedom of choice includes the evil side. but that is far away as there are so many topics to consider when doing mobile that stuff that is discussed here in the forum does not even show at the horizon. if you cant do proper modem handling, wakeup from suspend, configuring the audio path, … why should you care about a ringtone?
we saw that with openmoko: the gui was fancy but there was no way to reliable control the modem beside the fact that the battery emptied after 1-2 hours.
and this thread asks: hey purism, where are you? what is your groundwork to solve such demands? can we develop testcases to prove reliabilty of your solution?
and after that we can talk about gui.
after that we could care about themes, backgroundpictutes and ringtones.
i know that marketing goes other way around, i’m only a developer.
salve
Sono, sicuramente, molto più anziano di voi e non sono un programmatore ed uso linux da ormai 23 anni sempre come principiante Io penso, diversamente da voi, che mi dispiacerebbe trovarmi la possibilità di usare google apps sul cellulare librem. Io desidero un cellulare con Gnu/linux e l’ho comprato per questo motivo.
bye bye
Brings to mind a practical question… How feasible is the running of android apps anyhow? Could Google make changes that render the development work for Android compatibility moot?
We know Google is removing user control, and even the illusion of privacy, systematically and incrementally.
Example- On my Android it recently became impossible to turn off location in Google play services. (which is the backbone for Google apps on my phone). Can’t even toggle it off with the GUI after recent updates.
Would Google App compatibility (if built into a Librem phone) be hanging on by a thread…? Where Google could make its apps basically unusable? Aka would Librem users have to rely on a spirit of goodwill on Google’s part? Could Google opt to force incompatibility with the phone? Or make their Apps go Bananas and drain batteries etc.
(am assuming that they might want to strategically ‘make a phone look incapable’ rather than ‘push for as many users as possible’.)
Just a question that someone might weigh in on. I don’t know if there could be a foolproof technical ways to make part-time Android compatibility an option.
For me the option to fall back on Google apps could be nice just for Infrequent use, but only if it did not run in background unless called upon specifically. Not sure about the science of it making it real though. Even when it comes to later versions of a Linux phone.
@MrFriday: Google apps or Android apps? For their own apps they can easily do whatever pleases them. But I’m rather uninterested in Google apps anyway. Those are the generic ones that will hopefully have libre, native replacements. And if you saw the progress of Plasma mobile (see my post above), I think it looks quite promising.
Android apps are only interesting for special purposes. Maybe your favourite game or messenger that you want to continue using, a certain news or shopping app. For these, Google can make it harder by changing the APIs (more likely by adding new ones and wait that they get adopted), but they have to stay compatible mostly. So it might be harder and harder to use Android apps, but they cannot really switch the light off from one day to another.
Actually, I think it’s rather unlikely that they take the effort to purposefully make it harder for alternative Implementations. It’s just not worth the effort for them. And if Linux-phones really become a thing (notable market share), then it’s too late anyway. Then, you don’t need Android apps anymore - you will get any app you need natively. - On the other hand, I’m not sure if I ever want closed source native apps to become mainstream. As long as they are Android based, they are (more) easiliy sandboxed
).
daydream
).