Speed at which Sailfish apps launch

Using invoker still works though, change exec in advanced-camera .desktop file to:
Exec=/usr/bin/invoker --type=silica-media,silica-qt5 – /usr/bin/harbour-advanced-camera
And it starts in 0.5sec vs 2seconds you get by just calling the binary

Sorry for spam but that significant decrease in launch time does actually require disabling sailjail, so add:
[X-Sailjail]
Sandboxing=Disabled
And it starts almost instantly, even view finder starts quicker than jolla-camera (there sailjail seemed to have no impact)

Thanks for the clarification! So we just need to run Sailjail with the invoker :slight_smile:

It’s a bit weird as jolla-camera doesn’t care about sailjail, then again it also has something extra baked into the binary (the -A from invoker pulls the booster name from it(?), without it it loads at around 2sec), wonder if a megabooster that loads all possible qml elements would have significant impact for the average app, but again the loading times on XIII are pretty short as it is
edit: probably won’t, stacking unnecessary boosters is counterproductive it seems as adding “generic” on top of silica-media and silica-qt5 results in longer loading times, funnily enough you can also invoke sailfish-qml, SailTRON uses canvas so has pretty long loading time for a 2 page qml-only app (front of the loading line reaches 3:00) with invoker’ing sailfish-qml and the two boosters doesn’t reach 12:00

I do have it set for initialPage in one of apps and that page gets loaded and displayed automatically, anyway. So I guess that it works as usual and all values in it should be normally set (unlike in other pages which in such case get loaded only ‘on demand’). In my case that initial page is just a menu (a screen with a column of buttons) so it doesn’t actually do anything and doesn’t set any properties, but I assume that as it still gets automatically launched then everything in it gets normally processed.

Anyway, in that app besides the initial page (menu) I have around 20 other qml pages (around 10 actual pages with some funtionality + a help page with some text for each of them). I remember that after changing all of them from preloaded Components to manually opened using Qt.resolvedUrl I was literally amazed by how it shortened the launching time. Like from 4 seconds to half a second or so.

But then I enabled SailJail for it and it went back to 2-3 seconds :slight_smile:

Yes… but how do you pass values to that page?

For pageStack.push() we can use a second argument for passing attribute settings… but for the initialPage property i don’t see how i could. I.e. normal does not apply.

Well, I must say that I haven’t really tested it as in that specific case it was just a simple menu page not requiring any values from other pages. Moreover, in that app all the calculations are being done in C++, then exposed to all QML pages via Q_INVOKABLE, Q_PROPERTY, setContextProperty and such.

So I’ll need to further test it.

But if in pure QML I need to use some properties / values accross multiple QML pages, I set those properties in the main qml file of an app. A property defined in that main QML file is then directly accessible to all other QML pages.

Also, just a quick thought without checking… Regardless of the method the initialPage is invoked, doesn’t it get added to the pageStack anyway?

I also wonder if it doesn’t make sense to use QtObject? I do that for connections a bunch.

When sandboxing was implemented it was clear that the old way of boosting (compiling QML components before loading the application) doesn’t work any more. This was mentioned in Koli blog post, under “Firejail app permissions”. To mitigate that for some of the apps application boosting was developed. It combines sailjail and application boosting (provided by mapplauncherd and boosters derived from that) in a way that we can have boosting for a predefined set of applications. This comes with memory consumption tradeoffs so it’s not practical to have it enabled for all applications. This is also why jolla-camera has that -A argument in its .desktop file, unlike many other Jolla apps or Harbour apps, and there is no simple switch to toggle it on or off per application.

1 Like

I’m not sure I understand this. ‘What is clear’? Assuming that the compiled QML is ‘equivalent’ to the src QML, why is it not possible to compile it before ‘using’ it as you launch the jail? Was the boosting not always based on mapplauncherd? Isn’t there a distinction between application invocation stages?

Whatever the case is vis. the current mechanisms, how do I compile QML if it’s not possible dynamically? Just a hint in the documentation direction will do. Thanks!?

So, the compilation I mentioned happens when you load a QML file. This is done when starting the application and causes a lot of the delay that you see. Boosters speed this compilation up by compiling common QML components before the application is started so they can be reused when compiling application specific QML code. When application is launched with a booster, the booster loads the application like a library and executes main(). With sandboxing there is firejail between booster and application main() and that cannot be just loaded as a library and executed. (Firejail is what sailjail uses for sandboxing.)

Ok, so I’m guessing that it’s a bit different with ‘pure qml’ apps? What I understand now is that the ‘booster’ is comparable to firejail as a binary that sits between the app and execution. So, like a shell. So, like the kernel? I miss the days where I swapped the ‘Finder’ for an arbitrary app to get the most out of my hardware (mac classic).

Naive question, why not booster before firejail? The obvious answer is ‘security’. But, a lot of applications/services start in one mode and drop privs. as soon as it’s ‘feasible’. This seems like it must be plausible with jailing (I speak as a BSD jails user of yor).

Where should I go to look at the ‘booster’ code? Thanks!

So, just to be clear, I’m ‘assuming’ that libsailfishapp-launcher / sailfish-qml is NOT Sailjail/firejail. Which suggests another pipe/facade, etc.

Not really. They are still launched by a small binary that does pretty much the same stuff.

Boosters are actually services that are running all the time and then they become applications. Firejail is suid application that does all sorts of “magic” to setup a sandbox, enter it and then executes the application.

Firejail would basically throw away anything that was done by the booster when it enters the sandbox and executes the application.

That would be mapplauncherd and then the booster repositories. Silica booster is probably the most interesting [of the boosters]. Note that there is also generic booster in mapplauncherd which is actually not boosting anything, it just execv() the binary.

Edit: Sorry, forgot to write a few words there.

1 Like

I don’t believe in magic but I know the cgroups relevant bits of the linuxVserver extensions.

What does that mean? I obviously need to go read code. Sandbox is a metaphor.

And that’s where I’ll go now! Thanks!

True. It’s basically setting up Linux’s various namespaces to isolate the application from the rest. There is fairly good and short description in Firejail’s readme.

Perhaps you can shed some light on this. I’m not sure what to make of this.

ExecStart=/usr/bin/invoker --type=silica-session -- /usr/bin/sailjail --profile=%i -- /usr/libexec/mapplauncherd/booster-silica-qt5 --application=%i

Read that long ago. It’s not germain. As my last post suggests, it’s not clear what’s going on. Invoker, session typ → sailjail → booster → app? errr.

Having read all the above and facing some other limitations introduced by Sailjail (e.g. how it affects certain D-Bus functionality) I just hope that in some future OS update Jolla doesn’t get an idea to enforce Sailjail for good, i.e. without the possibility to take advantage of Sandboxing=Disabled.

1 Like

That would be application boosting. It’s not quite what I described above as the booster is actually executed in a sandbox.

Btw, you may have noticed, but I’ll mention it here anyway: these commands (invoker, sailjail) have --help argument to give short descriptions of their use that should help a little bit at deciphering them. Invoker code is in mapplauncherd repository and sailjail command code is here.