[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4BFFC55B.5050908@nokia.com>
Date: Fri, 28 May 2010 16:30:03 +0300
From: Igor Stoppa <igor.stoppa@...ia.com>
To: ext Theodore Tso <tytso@....edu>
CC: Alan Cox <alan@...rguk.ukuu.org.uk>,
Peter Zijlstra <peterz@...radead.org>,
LKML <linux-kernel@...r.kernel.org>,
Florian Mickler <florian@...kler.org>,
Linux PM <linux-pm@...ts.linux-foundation.org>,
Thomas Gleixner <tglx@...utronix.de>,
Linux OMAP Mailing List <linux-omap@...r.kernel.org>,
"Balbi Felipe (Nokia-D/Helsinki)" <felipe.balbi@...ia.com>
Subject: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
ext Theodore Tso wrote:
>
>
> Well, yes, if the company strategy is to have a walled garden ala the Apple iPhone App store, life is much simpler.
No, the strategy is to try to merge commercial and community needs.
We do support signed repositories.
The community has control on the public one.
Members are encouraged to help by alpha/beta testing apps that are under
development.
They even organize testing marathons.
> But if the requirements mean that apps don't need preapproval, the requirements on the platform get harder.
That's a wrong way to put it. By installing something on your phone you
_do_ approve it.
> I think the take-home here is we have a requirement that the platform behave well even without someone screening the applications for the "default SW repository".
What it meant is totally different. Regardless how much effort you put
into twisting it.
It means that different repositories provide different level of trust.
As Debian user, I don't blame anybody other than myself is something
I've pulled from unstable or experimental breaks my system.
Debian by default doesn't ship with either unstable or experimental enabled.
And using suspend blockers doesn't really solve the problem of who to
trust to take the block and who not.
Or we'll have to have suspend-blockers-blockers and so on ...
Like it or not, QoS and resource management - in some form - are needed
to allow trusted application to provide valuable feedback, while
filtering requests from untrusted applications.
You might want to add dynamic profiling and try to use some heuristic to
have the system doing runtime evaluation of good vs bad applications,
but still some discrimination mechanism will be required.
igor
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists