That is how I see it also. But graphical presentations can be handled through a web browser. So I hope there will be a good browser at least later. Firefox is quite good but a bit on the heavy side. On my old machines I use Midori which is much faster on less powerful hardware. But Midori has limitations.
I have an idea on that topic, but itâs a ways from realization. I despise both of the rendering engines that are currently maintained. Yeah, there is a fork of firefoxâs old rendering engine, but itâs bad too. The problem is I donât want a ârendering engineâ, which consumes lots of resources and renders everything into a buffer. What I want is a âlayout engineâ, which just figures out what goes were, in an abstract sort of way. Iâll probably then toss a curses frontend on it and call it a day. At the rate things are going, I may actually have it in a presentable state by the time I get my L5, but weâll see, itâs tedious and time consuming.
3 Likes
Well, it has to be compiled for the L5 of course, and Purism might not go through the trouble of recompiling everything there is. Of course the advantage with the L5 is that you can easily upload and compile any source code you get your hands on, but not every user may be willing to do so.
Many applications can work through a web browser indeed, but not all. Then as mentioned already everything with a GUI might not work on a smartphone screen without adaptations.
1 Like
https://developer.puri.sm/Librem5/Apps/Guides/Porting_GNOME_Applications/index.html
Isnât like make it from scratch but every app will need some fixes to make it touch friendly.
2 Likes
What do you mean by this?
You donât get quite the entire suite of standard debian applications. Some of them are x86/x86_64 only (on account of using x86 asm). A fair number more should work on arm, but no one has bothered to actually compile them.
At the same time, I think Sebastian thinks purism wonât be able to just use debian packages, without compiling them in house. This may well be the case (by purism policy, rather than technical restriction), but setting up the debian buildbot is pretty simple.
1 Like
Of course you should compile the programs for L5 even if there might be some simple programs that has ARM binaries that could run directly. I use Debian on my Raspberries too and that is quite straightforward. The hardware of L5 also has other components outside the processor so compiling is a good idea anyway. It depends on the program. If it uses library routines only which are already compiled for L5 it could run directly. But I suppose that I have to find out exactly what will run on L5 only when I get my phone.
This makes no sense at all. It would be a huge waste to just recompile perfectly good, compatible arm packages. What are you really taking about here?
As I wrote it should not be necessary to recompile if the program is using only library routines which are compiled and verified to be running on L5. I may be overcautious but I just read that Purism possibly has a policy of recompiling for L5.
Sorry, but I have seen some small hardware differences that make the use of binary packages difficult. In fact I use two computers with Debian and it complains every time I boot about some hardware problems - but it can be used anyway.
1 Like
Efficient apps are a program that gets compiled into something called machine language, but that âmachineâ is not known ahead of time by the programmer writing the program code that humans can read. A generalized machine with a specific set of internal solid-state electronic doohickeys on its processor and chosen operating system running on that machine needs a compiler program for it that goes from the readable program code that everybody wants into the machine code of that specific genre of machine. The thing that has been compiled is what people typically âone-clickâ install for personal use. Somebody goes to the trouble of precompiling programs to put in our app stores so we donât need to do that compiling step.
Yes, thanks, but I know what compiling means in general.
What Iâm trying to figure out is why anyone would want to compile packages specifically for the L5 when fully functioning distros are available for its architecture with binaries ready to use (e.g. Debian arm64).
1 Like
Personally, I plan to do exactly that. Like x86, ARM has a core of instructions common to all processors, and then per processor model extensions. The debian arm64 distro is compiled targeting the common ARM subset. Not sure how much performance gain there will be for setting -march=native, but I plan to find out.
Indeed, my assumption is that there is no complete distribution yet that works on the L5 CPU. I wasnât even aware the i.MX8M is an ARM CPU until now.
If it is compatible with the Debian ARM packages, even better, cause that would basically mean everything available for a Raspberry Pi should run on a L5, right?
I hope so, but unfortunately some vendors make small differences in the hardware and then precompiled packages get into trouble. So I will wait and see âŚ
Oh, then nevermind.
1 Like
To make sure what you see is what you get?
I think the point of this thread is for people to make suggestions in the hope that someone else will do the work, regardless of how little work it might actually be. Perhaps it will also help to avoid some duplicated effort.
I think the main point of incompatibility between the Librem 5 and distributions that have arm64 packages and a new enough kernel, is probably the boot process.
(https://www.debian.org/releases/stable/arm64/ch02s01.en.html#arm64-other-platforms)
(The Librem 5 doesnât use UEFI, AFAIK.)
3 Likes
That seems drastically paranoid even for a privacy enthusiast, and of questionable benefit unless you are auditing the code closely yourself and then compiling afterwards. Package checksums and signatures are sufficient for me personally, but I guess there are other views here.
1 Like
Not really, thereâs a difference between building binary package and just compiling the code. Package is supposed to be fully integrated into the system, with deps autoresolve etc. Source compilation usually allows using upstream directly (bleeding edge) rather that pre-packaged release tag.
Technically speaking if you have signatures and deb src - you can review the code and trust it is accurate. If you side-load package you donât have a luxury to verify signatures automatically unless you add a repo, so you need to go with manual verification (which sometimes is more complicated than just recompile 
)
2 Likes
Perhaps we will have (in the future) a L5-distribution with a special repository controlled by Purism. Of course it would be nice to use the existing system of Debian in some way. It is working very well. I suppose we need both binary packages which are tested and guaranteed to run on L5 for novices and sources for the more experienced that like to make some changes.When I think about it I almost exclusively use Debian binary packages without very much problems for many years. I have some hardware that needs special attention though. Mismatch with libraries is the most usual problem but it is fairly quickly solved.
If software updates for L5 are as easily handled as for Debian I see no problems.
2 Likes