Bla, bla , bla .. FUD .. bla bla bla
Harbour QA input is allways binary blob! And as security specialist i
say: Harbour QA not able to force true security. Too many security holes
is in OS - for now Jolla's/SailfishOS security is tragic. And after
afera with internet connectivity from simple app for LED light .. passed
thru QA without any problem .. sorry no one believe to Harbour QA .. LOL
When developer make app from git on OBS .. and binary blob have right
checkum in Openrepos .. this is better then Harbour. And Openrepos
working on connect/bridge with OBS. OBS bulding is only one true
bin-blobs control. With OBS we know: THIS blob is builded from THIS
source. Harbour way is bullshit. .. sorry ..
In short: Openrepos with OBS provide better security then harbour ..
Howgh ..
For people with brain Openrepos is not problem.
Jolla make too many wrong decisions and in combine with lack of
informations .. i am two steps to go to furture with fully open Nemo.
Maybe take my work to this diretion will be better decision ..
Kaacz
Dne 21.1.2014 13:15, Joona Hoikkala napsal(a):
Openrepos doesn't have any QA process, and you can publish your own closed
source blobs through it.
Meaning that someone could potentially push an application that steals or
destroys users data.
Harbour is very much needed.
--
Joona
On 21 Jan 2014, at 12:59, kaa <k...@iol.cz> wrote:
Thank you for quick answer.
But now i have other question: after this way .. why we need Harbour ? Nope ..
Openrepos with own client is better on both sides.
Openrepos backend/repo use standard linux rules, Harbour is too much
restricted. Mainly for lack of many Jolla decisions. Or for example terrible
decision about naming convention. :(
Openrepos client is better also, easy and user friendly with more info and very
clear. Harbour client is confused and buggy - still show me nonclearable
notifications about app updates .. but i have better version from openrepos.
Harbour client see :different: not :higher: version. And client not able to
solve this situation. Crap.
Who cares about problematic Harbour when we have OpenRepos? Jolla missed chance
..
When developer use OpenRepos, have not one reason for move to bloody Harbour
after ...
Kaacz
Dne 13.1.2014 13:34, Jonni Rainisto napsal(a):
Again not official answer: but with current rules right way is to setup
application 1st in Openrepos or OBS which uses root capas, and after 1000+
people have installed it and found it working and stable, then push it to
Harbour, and apply for exception for intake rules. As applications with proven
track record and demand can have exceptions to approval rules.
In a long run we hopefully have some better API or rules to solve this. I'm
only saying current situation.
re, Jonni
________________________________________
From: devel-boun...@lists.sailfishos.org [devel-boun...@lists.sailfishos.org]
on behalf of kaa [k...@iol.cz]
Sent: Monday, January 13, 2014 2:22 PM
To: Sailfish OS Developers
Subject: Re: [SailfishDevel] Scriptlets in RPM hot allowed to Harbour
.. runned as root .. because doing work on root level.
Simple apps like "life years/months/days" are nice, but we need many
better, stronger, "under-skin" apps..
Like Profilematic, call blocker/recorder/assist, PhotoSync & many others
with daemon running.
Without this kind of apps Jolla phone is crap worse than Android...
As N9 user .. now I may use Jolla phone only with pain and frustration.
Then I have question:
What is right way to set-up "run daemon now and after boot" right after
install .. without post-inst script in RPM ?
And I want answer, please ...
Thanks
Kaacz
Dne 11.1.2014 11:41, Jonni Rainisto napsal(a):
because they are runned as root.
________________________________________
From: devel-boun...@lists.sailfishos.org [devel-boun...@lists.sailfishos.org]
on behalf of Andrey Kozhevnikov [coderusin...@gmail.com]
Sent: Saturday, January 11, 2014 11:22 AM
To: Sailfish OS Developers
Subject: [SailfishDevel] Scriptlets in RPM hot allowed to Harbour
Why RPM scriptlets not allowed to harbour?
_______________________________________________
SailfishOS.org Devel mailing list
_______________________________________________
SailfishOS.org Devel mailing list
_______________________________________________
SailfishOS.org Devel mailing list
_______________________________________________
SailfishOS.org Devel mailing list
_______________________________________________
SailfishOS.org Devel mailing list
_______________________________________________
SailfishOS.org Devel mailing list
_______________________________________________
SailfishOS.org Devel mailing list
