Just my 2 cents here. My personal opinion which is by no means reflect the opinion of the united penguin federation of the southern hemisphere.
I understand the need for certain components being closed source due to manufacturer limitations. If the meego OS is being pushed to a certain device that requires closed source drivers in order to function, I don't expect Nokia to develop/acquire the drivers in order to make it a true FLOSS solution. (Though it would be a nice perk) What I would like to see out of meebo is a platform that is extensible and flexible in how it is used. I presume meego will use a Linux kernel, plus some arbitrary proprietary drivers of one sort or another in order to make the device function as expected. What I would love to see out of meego is a modular design where one could port to various architecture, replace the closed drivers with an open source solution, and basically be what android promised to be. A true open source platform that gives the developer and user the freedom to use the OS as he sees fit, and let it grow in any and every direction they choose to take it. I do hope that Meego will not be just another API/ Java stack (like the iPhone/Android seem to be) and will really let the user/Developer push the limits of both the hardware and technology. -- Samir Faci On Mon, Mar 22, 2010 at 2:31 AM, <[email protected]> wrote: > >>________________________________________ >>From: [email protected] [[email protected]] On Behalf Of >>Vollmer Marius (Nokia-D/Helsinki) >>Sent: Monday, March 22, 2010 9:11 AM >>To: Poussa Sakari (Nokia-D/Helsinki) >>Cc: [email protected] >>Subject: Re: [MeeGo-dev] N900 Questions... >> >>"Poussa Sakari (Nokia-D/Helsinki)" <[email protected]> writes: >> >>> Reason for closed/binary components ? There are components like 3D graphics >>> acceleration libs which are closed. As said, this is something that we can >>> not >>> do anything in the short term. This is the case also in N900 maemo repos. If >>> developers wants to use those components they should be available in the >>> repos, >>> right ? >> >>I think it is important that all the non-free packages are very clearly >>optional, and very clearly separable from the free ones. > > When UI is based on OpenGL, how OpenGL drivers can be optional ? Or should we > sacrifice > usability of 99.9% of end users not using any OpenGL jost for making OpenGL > drivers optional ? > >>I.e., it must be possible to get MeeGo running on the reference >>platforms without any non-free package. The result might not perform >>optimally, and not all hardware might be accessible, but it must boot to >>the UI and be generally useful. > > Do you really think that Meego in N900 with SW accelerated Mesa OpenGL would > be usefull ? > >>In other words, it should be possible to remove all non-free packages >>from MeeGo without losing anything essential, and we should consider >>actually doing this. > > That will be impossible in pocket sized device. Removing all OpenGL from UI > removes > also all usability features with compete aggainst iPhone and Android. > > I think that it is best to make as good UI as possible using all OpenGL > tricks, > if someone does not like closed OpenGL drivers, then s/he should vote with > his/her valet > and buy HW where is open source OpenGL drivers. > >>If the non-free packages are essential and can not be removed, MeeGo >>would be a farce, in my opinion. > > Don't blame MeeGo about bad decisions of silicon makers. > I hope that Intel reads this thread and we shopuld have > Intel based reference platform with OSS OpenGL drivers. > > Kate > _______________________________________________ > MeeGo-dev mailing list > [email protected] > http://lists.meego.com/listinfo/meego-dev > _______________________________________________ > MeeGo-dev mailing list > [email protected] > http://lists.meego.com/listinfo/meego-dev > -- -- Samir Faci *insert title* fortune | cowsay -f /usr/share/cows/tux.cow _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev
