s/project/process heh
On Thu, Sep 8, 2016 at 9:23 AM, Tone Kastlunger
wrote:
> QML plugins in a separate project - something is amiss here; but anyways.
> It is fairly easy to evaluate a technology for a certain use in my
> opinion; especially if that technology is not new and has been used
> (S
QML plugins in a separate project - something is amiss here; but anyways.
It is fairly easy to evaluate a technology for a certain use in my opinion;
especially if that technology is not new and has been used (SELinux has),
and ESPECIALLY if it has been used in the same context already (i.e.
Androi
Great, thank you for the information.
Best regards,
Franck
nb: I also asked on the Jolla Blog, but the question was unanswered, so
I'm going to update the blog in case someone see it and to avoid FUD :-)
Le 07/09/2016 à 14:35, James Noori a écrit :
Hi Franck,
The simple answer is yes. Th
On Wednesday, September 7, 2016 4:20:04 PM MSK, Slava Monich
wrote:
Hi Andrew,
To make matters worse, the plugin requirements may change over time,
meaning that a system upgrade may break the app because the app
didn't request access to some features required by the updated plugins.
Applica
Hi Andrew,
To make matters worse, the plugin requirements may change over time,
meaning that a system upgrade may break the app because the app
didn't request access to some features required by the updated plugins.
Application shouldn't know/care about how does plugin work. Plugins
are part
s/archives/achieves/g
On Wednesday, September 7, 2016 3:56:15 PM MSK, Andrew Penkrat
wrote:
Hi Slava,
On Wednesday, September 7, 2016 3:20:23 PM MSK, Slava Monich
wrote:
Hi,
Access to contacts is actually quite a good example. It may or may not
require access to the network, depending on
Hi Slava,
On Wednesday, September 7, 2016 3:20:23 PM MSK, Slava Monich
wrote:
Hi,
Access to contacts is actually quite a good example. It may or may not
require access to the network, depending on how it's implemented at Qt
plugin level. Should every app that needs contacts declare that it
Hi Franck,
The simple answer is yes. The Jolla C ships with AlienDalvik otherwise
known as Android app compatibility.
Cheers,
James
On 9/7/2016 2:33 PM, Franck Routier (perso) wrote:
Hi, well, it's all in the title: Does Jolla C ship with AlienDalvik ?
(I was under the impression that I re
Hi, well, it's all in the title: Does Jolla C ship with AlienDalvik ?
(I was under the impression that I read otherwise somewhere, but I
really don't know...)
Franck
___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-u
Hi,
Access to contacts is actually quite a good example. It may or may not
require access to the network, depending on how it's implemented at Qt
plugin level. Should every app that needs contacts declare that it needs
network access even if the app itself doesn't use the network?
Or it coul
Slava,
Apps would have to declare what they need to function, and then the sandbox
is in place to ensure that they can only use what they declare.
This doesn't solve apps declaring they need full access to everything, but
at least there are some assurances to the user that if they expect an app
w
I feel a bit sceptical.
If the system supports plugins, i.e. shared libraries discovered at
runtime and getting loaded into the process context without executable
knowing it in advance (like Qt does), then the application doesn't even
know what kind of resources it actually needs at runtime to
Hello,
During the discussion, we never hard-committed to SELinux. Instead, we wanted
to experiment a bit with it, and see if it suits our needs.
SELinux was the first choice to consider because of Android using it.
My goal is to just evaluate how it can be used in the context of SFOS, as a
sa
Yeah, the main issue of SELinux for me is the necessity of compiliing the
policy in the first place;
in turn for doing that, you need to pull in all the SELinux toolkit (which
is huuge).
On Wed, Sep 7, 2016 at 9:50 AM, Michal Hrusecky wrote:
> James Noori - 12:21 5.09.16 wrote:
> > Hi everyone!
14 matches
Mail list logo
