Hi Dave, On Sep 15, 2010, at 1:51 AM, Dave Neary wrote: > Hi Mark, > > Skarpness, Mark wrote: >> It actually does matter to those deploying devices. A few examples of why: >> >> If compliant apps are allowed to have external dependencies - then >> someone has to pay to host and maintain those dependencies so they are >> available worldwide to many millions of devices. > > Won't that be the MeeGo repository? No, probably not - the meego project infrastructure is not set up to support commercial product deployments. The device vendor and / or service provider would need to host this (as they would also host updates, etc).
But my point was really that this decision does matter and does have an impact - if we allow applications to have external dependencies then someone has to pay to host them in a commercially scalable and reliable way. > >> As someone building a device - how do I know how much storage is required >> for the OS in order to run compliant apps (as Arjan pointed out earlier in >> the thread)? > > This reminds me of an epiphany I had a few years ago when working with a > buy who was an embedded developer. He told me stories about doing > real-time development & having to turn off all caching for the OS and > applications for an embedded application that was going into space - it > didn't matter that the average response time was going to be increased > from 0.01s to 0.5s, what mattered was that he could give, with absolute > certainty, a *maximum* response time. Being better in theory was less > important than being predictable & reproducible. Yes, we are in a similar situation - being able to tell someone building a device the maximum space required for the OS is more important than having the most optimal solution for the size of apps + OS (though we should look at creative ways of achieving both). > > In theory, depending on external apps will raise the average space used > when installing 100 apps, but it does not give any decent way to > evaluate the maximum space that will be needed for 100 apps. However, > including all dependencies in packages will always give a higher space > requirement for the 100 apps than splitting them out... either all > dependencies are used by exactly one package (in which case the result > of including them or splitting them is the same) or at least one > dependency is shared by at least two packages (in which case splitting > them out is better). There is no situation where having > separately-packaged dependencies will use more space than dependencies > wrapped in the package. > > It occurs to me that going in this direction would be like returning to > the early days of Linux when there were no dominant distributions or > common base packages or decent dependency resolution, and WordPerfect, > Applix, Oracle and all the other commercial apps that started supporting > Linux used to ship huge statically linked packages. Can we all agree > that the world was a worse place for Linux users back then? Yes - but we are in a better position that that - via compliance, we are going to provide a guaranteed set of packages that will be available on every device. And I'm hopeful we can find a creative solution to make this really work better while still meeting the needs of everyone using MeeGo. > > <snip> > >> Absolutely - but MeeGo also needs to meet the needs of people >> building commercial device products and applications - so the rules for >> how you build and distribute that GPL application may be a bit different >> then they would be for a "standard" Linux distro. > > I guess I can assume that most people here have not been in the business > of building commercial device products and applications - it seems like > there are not a lot of people from that segment here to defend their own > needs. Perhaps it would be useful to go over the core requirements that > these constituencies have? > > I can get that a commercial application developer wants to be able to > build a package which will install on any MeeGo device... we're not > talking about requiring that people split off dependencies, but allowing > that things can be done like that. The problem is that once we allow it, then we require everyone building a compliant device to support it. Otherwise we will miss the primary objective of compliance: every compliant app will run on every compliant device. > > I can get that an app store might require these single packages for > billing purposes, as you said. And I think that would be fine for anyone > wanting to get into an app store. But that would mean that app stores would not be able to sell all compliant apps - which is not what we want. > > I'm still not very clear on what requirements a device > vendor/distributor (or software strack provider) might want to impose on > the software that would be installed on the device. Are there > distributors who want to have a single approved source of applications > for their devices that they support? And they don't want to be required > to enable some wild hairy community repository? Or am I missing the point? No, you are hitting on the key point - the decisions we make in compliance have a direct impact on those building / distributing devices. I've heard a few concerns repeatedly when talking to people building and deploying devices: "we need to know the maximum footprint of the OS on the device", "whatever you do, don't fragment - the compliance promise is critical", "delivering software to devices in the field is complex and expensive - and needs to be managed carefully" > > A clear list of the constraints & requirements of commercial developers > & distributors would be, I think, useful. > Agree - we've received some good input indirectly and we need to continue to encourage everyone to provide their feedback on the list. Thanks, -Mark > Thanks! > Dave. > > -- > maemo.org docsmaster > Email: dne...@maemo.org > Jabber: bo...@jabber.org > _______________________________________________ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
