Re: [MeeGo-dev] Meego Bugs Access Denied
On Thu, Oct 28, 2010 at 2:17 PM, Ryan Ware ryan.r.w...@intel.com wrote: There are a number of bugs in the MeeGo Bugzilla that are restricted specifically to the security group. I suspect everyone understands the need to limit access to security bugs - I certainly do. However, the OP and the immediate follow up made no mention of security issues... If the only issues with restricted access are security issues, that's great - but Eric's follow seems to imply that there are non-security bugs that will be restricted, and that we can expect more until some non-described problem is sorted out... If some bugs are being restricted without a good reason - I'd agree with Bradley that it's a pretty serious issue. Warren -- Warren Baird - Photographer and Digital Artist http://www.synergisticimages.ca ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On Sun, Sep 19, 2010 at 3:30 PM, Skarpness, Mark mark.skarpn...@intel.com wrote: As I said earlier in the thread - compliance isn't a statement of worth - it simply means that the app follows the rules of compliance so that it will run on any compliant device. I think there is a big disconnect here... I think the vast majority of people - devs and users, *WILL* view 'compliance' as a statement of worth... A compliant app will be viewed as safer and better than a non-compliant app by almost all users... That's been the core driver behind most of my posts here, and I suspect a lot of other people's. If you really don't believe that 'compliance' will be viewed as a statement of worth, why are you arguing so much about it's definition? As several people have said, I think we need to establish exactly what 'app compliance' is trying to accomplish. I think your goal is something like 'inform commercial app developers and users which apps will run on all meego compliant devices'. Personally, I think that's a good goal, but that it isn't sufficient. I think it also needs to cover Inform users which apps will run reliably on all systems that have access to the meego repository. I definitely agree that we need to provide a way for commercial devs to be successful... but I think the beauty and power of a system like MeeGo will also come from the open source devs, and we *need* a way to indicate which of those applications are safe and reliable for end users... I also still haven't seen any discussion about the UX's here... Is the intent that a meego compliant app will run well on *all* UXs? Warren -- Warren Baird - Photographer and Digital Artist http://www.synergisticimages.ca ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On Thu, Sep 16, 2010 at 2:44 PM, David Greaves da...@dgreaves.com wrote: I think we need to achieve 2 things: * permit the open-source development model to work for compliant applications * define the spec in a way to minimise the imposed burden on vendors Thanks for trying to pull things back to the basics --- I think the discussion has kinda gone all over the place... From what I've seen, I at least do agree with these two goals --- We definitely need a model that will work for hardware vendors - otherwise we won't get anywhere... However, I also think that for many use cases, mandating full inclusion of all dependencies will hurt a lot - it'll cause package bloat, and cause tonnes of old, bug ridden copies of libraries to be floating around on users drives. Earlier in the thread there was discussion around 2 levels of compliance - a 'strict' compliance that requires inclusion of all dependencies, and a more relaxed compliance that allows dependencies on an 'Extras' style repository... To me, this still seems like the best approach - I think we need some kind of official recognition for well-formed, tested apps that include dependencies... Thoughts? Warren -- Warren Baird - Photographer and Digital Artist http://www.synergisticimages.ca ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On Thu, Sep 16, 2010 at 4:42 PM, Warren Baird wjba...@alumni.uwaterloo.ca wrote: Earlier in the thread there was discussion around 2 levels of compliance - a 'strict' compliance that requires inclusion of all dependencies, and a more relaxed compliance that allows dependencies on an 'Extras' style repository... Just to be clear - 'strictly' compliant apps would then be able to run on all devices - 'relaxed' compliant apps would be able to run on all devices that can access the 'Extras' style repo... To me, this still seems like the best approach - I think we need some kind of official recognition for well-formed, tested apps that include dependencies... Thoughts? Warren -- Warren Baird - Photographer and Digital Artist http://www.synergisticimages.ca -- Warren Baird - Photographer and Digital Artist http://www.synergisticimages.ca ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On Tue, Sep 14, 2010 at 1:22 PM, Alexey Khoroshilov khoroshi...@ispras.ru wrote: let's leave UX profiles out of the consideration for now Hmm - that raises something that doesn't seem to be covered by the spec --- does a 'MeeGo Compliant App' have to run well on *all* UX's? That could be a lot of work for some apps - anything designed specifically for netbooks for instance might not work on a Handset or Vehicle UX without a lot of tweaking. Do we need to have MeeGo Compliant - which implies all UX's as well as MeeGo NetBook Compliant / MeeGo HandSet Compliant, etc? Thoughts? Warren P.S. I don't know how many times I've nearly typed MeeGo Complaint in this thread... -- Warren Baird - Photographer and Digital Artist http://www.synergisticimages.ca ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On Mon, Sep 13, 2010 at 3:53 PM, Quim Gil quim@nokia.com wrote: - Should we have several grades of MeeGo compliance applications? And what is a purpose of the MeeGo compliant application concept? For clarity, I would restrict the word compliance to the official MeeGo compliance based on the official API. A MeeGo compliant app runs on any MeeGo compliant device. If we dilute this we are opening a Pandora's box. The MeeGo Extras stable repository would contain apps tested to work on top of official MeeGo releases. No compliance word needed: they are extras. Hmm. That does solve the problem --- but it seems to me that having Extras - which might well be the vast majority of MeeGo apps, at least initially - not have some kind of official 'stamp' is a weakness, at least on the PR side... App developers might well view it as a slight that their apps aren't compliant, and users might well be less inclined to run apps that aren't officially compliant... I think it's valuable to have a set of rules to define A well behaved app that should be safe for a user to install while not going as far as the current definition of 'MeeGo Compliance', and some kind of official recognition of such apps. I've seen other programs like this that have different levels of compliance... I could see something like: MeeGo Conforming App: depend only on things in Extras, compile successful on the build system and pass a series of automated tests, etc. MeeGo Compliant App: what's currently in the compliance spec. Apps on the app store would need to be compliant, apps on Extras need to be Conforming. Thoughts? Warren -- Warren Baird - Photographer and Digital Artist http://www.synergisticimages.ca ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On Mon, Sep 13, 2010 at 4:38 PM, Quim Gil quim@nokia.com wrote: I think we agree on the principles even if we still need to fine tune the words. :) I'm not super caught up in exactly what words are used... I just think it'd be useful to have a term and some kind of official 'seal' to distinguish well vetted, tested apps, from 'this python script I downloaded from my cousin Bob's website'... maybe if the criteria for getting into Extras is sufficiently strong, it's enough to do what you suggested and call them a 'MeeGo Extra App'... Warren -- Warren Baird - Photographer and Digital Artist http://www.synergisticimages.ca ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On Tue, Sep 7, 2010 at 8:56 AM, Wichmann, Mats D mats.d.wichm...@intel.com wrote: Warren Baird wrote: Lines 60-62 seem to disallow the possibility of producing apps using byte-code compiled languages like java or C# - is that intentional? No, indeed the fuzzy wording at the end is supposed to allow that: or any other supported language format. (an early reviewer objected to calling out bytecode, at least partly because the languages you mention aren't in the current required stack) If that's the intent, I think you need to restructure the paragraph - I read the or any other supported language format as modifing 'scripts written in one of the interpreted programming languages listed in this specificiation --- i.e. allowing other scripting languages. If I understand your intent correctly, it sounds like you could just remove 60-62. Are you saying it should be read as Object files, scripts, or anything else? Doesn't really narrow it down much, does it? Warren -- Warren Baird - Photographer and Digital Artist http://www.synergisticimages.ca ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On Tue, Sep 7, 2010 at 6:19 PM, Wichmann, Mats D mats.d.wichm...@intel.com wrote: Someone else said there are simply two different models: the repository-based model where the installer resolves certain dependencies (and it's easy enough to SAY something like may only depend on components of MeeGo core, or from MeeGo compliant packages); and one where an app may have no dependencies at all, basically depend on MeeGo is it, everything else is self contained. It seems like the wind is blowing in the direction of the latter, for all that it's easy to envision very useful uses for the former. It went in the spec that way based on what people who worked on this were told; hoping the discussion will make it clear what the spec actually needs to forbid/allow in this area. Seems to me like the wind is blowing in the other direction, at least on this mailing list... For commercial dependencies it might make sense to include everything in one package, just to simplify pricing and distribution. But for open-source dependancies I really don't think it makes sense to disallow non-meego dependancies... Take a look at any modern linux distro. How many packages are there that depend on other 3rd party libraries and tools? It's going to make the open-source developers life a lot more complicated if they have to bundle *everything* in their package - not to mention the wasted disk space, which can be at a premium on a handset... Warren -- Warren Baird - Photographer and Digital Artist http://www.synergisticimages.ca ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On Wed, Sep 8, 2010 at 10:00 AM, Wichmann, Mats D mats.d.wichm...@intel.com wrote: Warren Baird wrote: Seems to me like the wind is blowing in the other direction, at least on this mailing list... yes it is, I didn't mean to imply otherwise. more that the architects has seem pretty set on this idea. As others have said - who are 'the architects'? Can they step up here and give some strong rationales for this approach? I haven't seen anything remotely convincing yet... Take a look at any modern linux distro. How many packages are there that depend on other 3rd party libraries and tools? It's going to make the open-source developers life a lot more complicated if they have to bundle *everything* in their package - not to mention the wasted disk space, which can be at a premium on a handset... I think if there's something used widely enough there's a space wastage issue by it not being shared then there's a case it belongs in the core after all. That seems horribly inefficient... you are proposing that we automatically add 'widely used enough' libs to the core? Does that mean that when a library is used by N apps, each of the N apps has to bundle it? But when the N+1'st app starts using it, we'll move it into the core, and the other N apps need to redo their packaging to make use of the lib in the core? Limiting commercial dependencies makes perfect sense - no one wants to buy a program for $5, and then find out they need to buy another $40 worth of dependancies to use it... Even limiting dependencies to things available from a 'standard' meego repository might make sense... But having to limit dependancies to the meego core seems like a very bad idea. Warren -- Warren Baird - Photographer and Digital Artist http://www.synergisticimages.ca ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
Looks like a great start... I agree with a lot of the other comments here - especially about splitting it up into two sections for apps and implementations. Lines 60-62 seem to disallow the possibility of producing apps using byte-code compiled languages like java or C# - is that intentional? Warren On Fri, Sep 3, 2010 at 6:59 PM, Wichmann, Mats D mats.d.wichm...@intel.com wrote: There's a rough early version available on http://wiki.meego.com/Quality/Compliance We'd like to ask for feeback on this at various levels, the most important being the highest level: does it get anywhere close to describing an implementation of the basic principles, as presented most recently at the TSC meeting: http://trac.tspre.org/meetbot/meego-meeting/2010/meego-meeting.2010-08-18-18.58.html (follow to full logs to see the discussion) and mainly the reference: http://wiki.meego.com/Technical_Steering_Group_meetings/Compliance_Update_8-18-10 Probably it's not worth worrying about small items (spelling, grammar) at the moment as there are likely to be large changes which could make those disappear as a side effect. For the moment this is too rudimentary for it to make a lot of sense to tie it in to bugzilla entries, but we'll add a category there later as the document matures. So I'm proposing we just follow up to this thread - edits, questions, comments, etc. Thanks, -- mats ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev -- Warren Baird - Photographer and Digital Artist http://www.synergisticimages.ca ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Annoying behavior with current way to answer a phone call on Maemo, hope for improvement for N900.
On Thu, Jun 17, 2010 at 11:54 AM, Sivan Greenberg siv...@gmail.com wrote: Dear List, I hope this is a proper forum to bring this up - but I have been annoyed with the fact that once a phone call is arriving in N900 (currently with Maemo Fremantle) there is a rather large room for error when you need to take the device out of a pocket or a backpack's drawer. Also not sure this is the proper venue --- but +1 to the annoyance you mention. Warren -- Warren Baird - Photographer and Digital Artist http://www.synergisticimages.ca ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] MeeGo Packaging Policy : A process proposal
On Wed, May 19, 2010 at 5:25 PM, David Greaves da...@dgreaves.com wrote: (resend - first post rejected as list is closed) (2nd resend - 2nd post seemed to go to /dev/null) A conversation earlier today got me the action to submit a request for the TSG: http://wiki.meego.com/Technical_Steering_Group_meetings#Backlog_of_Proposed_Topics The intention is simply to clarify that the wiki policy is authoritative and mandatory and formalise that we shouldn't change the packaging policy on a whim. Seems to me that using a wiki to host a formally controlled policy document doesn't make a lot of sense - seems like we aren't using the right tools for the job. I suspect that the packaging policy isn't the only place this might come up. Should formal policies be hosted on the non-wiki part of the site, with a few people able to make updates through the CMS? The wiki could have a page like Packaging_Policy_Proposal where proposed changes are made - the discussion about the proposed changes can be either in the ML, or in the 'talk' page on the wiki, and when things are finalized, someone copies the changes to the CMS? Warren -- Warren Baird - Photographer and Digital Artist http://www.synergisticimages.ca ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] MeeGo compliance
On Wed, May 19, 2010 at 6:21 AM, Thiago Macieira thi...@kde.org wrote: Em Quarta-feira 19 Maio 2010, às 11:34:58, Cornelius Hald escreveu: If yes, each application, that makes use of NokiaFancyButton API will no longer be compatible with other Meego Handset products. So how will compatibility be ensured? Adding new libraries is ok. I expect that to happen all the time. What developers need to understand is that those libraries are not part of the MeeGo API. If they choose to use them, they will be subjecting themselves to whatever binary guarantees and release schedules those libraries provide, as well as being deployed only on certain devices. I don't think this is a compliance issue. It's a communication issue. I disagree here - I think we need some kind of compliance stamp indicating that an application is MeeGo compliant - indicating that it will run happily on all MeeGo devices. And I would definitely expect that 'vendor specific' applications would not qualify as a 'MeeGo compliant app. I haven't seen any details on standards for MeeGo compliant apps yet, but I'd assume that our friends at Nokia and Intel have plans around this - hopefully we'll hear more as part of 'the Big Reveal'... And I think the SDK should not include by default those extension APIs. But it should be possible to add them later, *consciously*. (I know what I'm doing, please install this library) Yeah, that makes sense - Maybe even show a visual indicator that you are running in 'non-compliant mode' when you do this. I'd like to see some kind of automated or semi-automated testing to ensure MeeGo compliance for applications - Perhaps running a series of tests in the simulator from the stock SDK could be part of that... Warren -- Warren Baird - Photographer and Digital Artist http://www.synergisticimages.ca ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] MeeGo compliance (was Re: Questions for TSG regarding big reveals...)
{adding Ibrahim to the cc-list}
On Wed, May 19, 2010 at 5:04 AM, Dave Neary dne...@maemo.org wrote:
Hi,
Quim Gil wrote:
Ibrahim from The Linux Foundation is driving the MeeGo compliance
definition. Hopefully we can have a first version of the guidelines
published soon, currently under private drafting and review to sync
legal, technical, marketing and resourcing aspects.
This is the kind of thing I think could benefit enormously from being
written revised in the MeeGo wiki. It's of vital importance to all
contributors, and yet only a privileged few will see anything but a
finished product/fait accompli.
+1
Also - even if it isn't possible to release this before the 'big
reveal', I'm quite curious to know whether the compliance definition
is purely from the perspective of what an OS needs to do to be
considered a MeeGo OS, or if it also covers 'what an app needs to be
do to be considered a MeeGo App'
I think that's an important part of encouraging a vibrant MeeGo app community.
Warren
--
Warren Baird - Photographer and Digital Artist
http://www.synergisticimages.ca
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] multiuser login
On Mon, May 17, 2010 at 4:11 PM, Michał Sawicz mic...@sawicz.net wrote: Another use I can see is in-vehicle systems that MeeGo seems to be quite interested in. People often share their cars, but not the same music taste etc. It would be nice if everyone could have their own personalized space on such a device. Logging in with a custom touch gesture or fingerprint if available (reader, not finger). Yeah, same use case for home entertainment systems also... And for in-vehicle systems, you might not need a gesture or fingerprint --- I think a lot of cars these days personalize the key fob, and adjust things like the seat position as soon as the door is unlocked with the right keyfob --- could also have your favorite music queued up at the same time... Warren -- Warren Baird - Photographer and Digital Artist http://www.synergisticimages.ca ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Questions for TSG regarding big reveals and impact on open development
On Sun, May 16, 2010 at 9:45 AM, Jeremiah Foster jeremiah.fos...@pelagicore.com wrote: MeeGo is a 'curated computing environment' where the file system is the best of breed but the only one and MeeGo will not listen to the debate. Its a lot like Flash on the iPhone - ain't gonna happen. I don't think that's fair at all... From everything I've seen, there is no intent to make 'MeeGo' a curated environment like most flavours of Android or the iPhone. Neither Maemo nor Moblin put any constraints on the software you install, and both let you easily get root on the device. It certainly looks to me like there are no plans to change that in MeeGo. I definitely don't think that having a maintainer decide what the default filesystem will be is the same as having only Apple decide what applications you can run on your device... Maybe your definition of 'curated computing environment' is different from how I've seen it used? Warren -- Warren Baird - Photographer and Digital Artist http://www.synergisticimages.ca ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Btrfs as default file system
On Wed, May 12, 2010 at 3:37 PM, Greg KH gre...@suse.de wrote: Neil, what is the specific problems you are having with btrfs on real sized storage devices (not for 1-2Gb devices, that's a different issue.) Greg - on an N900, 1-2Gb *is* a real partition size...If Brtfs doesn't work well on that size partition, I don't think we can standardize on it as *the* filesystem for MeeGo. Warren -- Warren Baird - Photographer and Digital Artist http://www.synergisticimages.ca ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Brief status of MeeGo to N900 project
On Thu, Apr 22, 2010 at 10:07 AM, harri.hakuli...@nokia.com wrote: Hello MeeGos ! This is brief status update of MeeGo to N900 project. This project is currently running as Nokia project, and I am Nokia project lead for it. The current closed mode of development is not the target for us at all, but rather transitional condition. As already discussed by Valtteri in TSG meeting, we are looking into going more open mode shortly. One reason why we have done this on this way is that at the same time we have been trying to handle opening of many currenly closed components that are needed in MeeGo and to build feasible MeeGo images for N900. Thanks for sharing, Harri - very interesting and promising stuff. I'm very glad to hear about the dual-boot option --- I use my n900 as my daily phone, and I'd love to test out meego on it, but I have a sneaky feeling it might be a little while before I'm willing to give up my maemo 5 capability... -- Warren Baird - Photographer and Digital Artist http://www.synergisticimages.ca ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] MeeGo Security
On Tue, Apr 13, 2010 at 7:58 PM, Sebastian Lauwers sebastian.lauw...@gmail.com wrote: obviously I would love it if Nokia or Intel would buy a bunch of hardware tokens that contributors could acquire for a diminished price (Vasco would be the cheapest provider, with batches going for around $12-$16 per unit, second would be [my previous company], third would be RSA), as having OTPs would have rendered the Apache attack useless, but I doubt we are anywhere near such measures. Even hardware OTP generators might not have stopped the Apache attack... Blizzard has been selling World of Warcraft OTP 'Authenticators' for a while now, and recently[1] someone came up with a man-in-the-middle attack that allowed them to access someone's account while they were logged in. True - it would have made it useless to steal the password list, but there is still quite a bit of damage they could have done if they were stealthy and smart... Warren 1: http://www.crunchgear.com/2010/02/28/world-of-warcraft-hackers-embrace-man-in-the-middle-attacks/ -- Warren Baird - Photographer and Digital Artist http://www.synergisticimages.ca ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] MeeGo Screenshots and other info
Don't know if everyone here is on the forums, or reads engadget, so I thought I'd signal boost this here. there's been a bunch of info on MeeGo provided at the intel developer forum - including what look like screenshots of the netbook and handset UX's. More details at : http://carrypad.com/2010/04/13/meego-at-idf-netbook-and-handheld-eye-candy-chrome-fennec-and-lots-of-developer-details/ and http://www.engadget.com/2010/04/13/meego-gone-wild-features-detailed-companies-come-on-board-at-i/ I'm a little surprised that all this info has been provided publicly, but as far as I can tell, none of it is available through meego.com --- I hope that is updated soon! Warren -- Warren Baird - Photographer and Digital Artist http://www.synergisticimages.ca ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Instructions for ARM / N900 (was Re: Day 1 is here ...)
I've taken a look at http://wiki.meego.com/ARM/Meego_chroot_install_on_N900 - and I must admit that I'm not at all an expert with chroot, but do you really do the mounting of the system directories before you do the chroot? I would assume they happen after the chroot. Can we safely do the various commands on this page in the order executed to get the chroot env up and running? Warren On Wed, Mar 31, 2010 at 1:52 PM, quim@nokia.com wrote: I've a N900 and I'd like to test MeeGo, but I don't know which file to download from here: http://repo.meego.com/MeeGo/devel/n900/images/ and how to flash it into my device. Could you please give us some instructions? Thanks. http://wiki.meego.com/ARM -- Quim Gil ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev -- Warren Baird - Photographer and Digital Artist http://www.synergisticimages.ca ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Day 1 is here - opening up the MeeGo development
Congrats! This is quite exciting - I'll check it out on my N900 as soon as I figure out the chroot thing... ;-) Of course, I'm very interested to see the UX's when they are available. Warren On Wed, Mar 31, 2010 at 1:27 PM, Sousou, Imad imad.sou...@intel.com wrote: Hi everyone... Today is the culmination of a huge effort by the worldwide Nokia and Intel teams to share the MeeGo operating system code with the open source community. This is the latest step in the full merger of Maemo and Moblin, and we are happy to open the repositories and move the ongoing development work into the open - as we set out to do from the beginning. What are we opening? The MeeGo distribution infrastructure and the operating system base from the Linux kernel to the OS infrastructure up to the middleware layer. The MeeGo architecture is based on a common core across the different usage models, such as netbooks, handheld, in-vehicle, and connected TV. The MeeGo common core includes the various key subsystems including the core operating system libraries, the comms and telephony services, internet and social networking services, visual services, media services, data management, device services, and personal services. More on this will be described on meego.com over the next few days. The downloaded images will boot from a USB stick or directly flashed on the device from your Linux PC, but since the MeeGo User Experiences for the usage models mentioned previously are not yet included in today's MeeGo core, these images will boot into terminal. After Day 1, the rest will follow soon - in the next few days, we will post the next steps leading to the first release of MeeGo in May. The images available today are: ARM-based Nokia N900, Intel Atom-based netbooks, and Intel Atom-based handset (Moorestown). These images can be downloaded from http://meego.com/downloads The corresponding package (RPM) repositories are at repo.meego.com/MeeGo and the git source repositories are available at http://meego.gitorious.org/. Bugzilla is at http://bugzilla.meego.com/ Please download, test, and provide feedback. The wiki on meego.com (http://wiki.meego.com) and the MeeGo mailing list (http://lists.meego.com/listinfo/meego-dev) are excellent ways to share information and ask questions. We'll post a proposed timeline soon which should answer your questions about opening the user experience, applications, and application framework repositories. For now, please take a look and let us know what you think. Imad Sousou Director of Intel's Open Source Technology Center Co-chair of the MeeGo TSG ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev -- Warren Baird - Photographer and Digital Artist http://www.synergisticimages.ca ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] [Meego-community] [Updated] Proposal: MeeGo User Experience Framework
On Fri, Mar 19, 2010 at 12:04 AM, Randall Arnold tex...@ovi.com wrote: Thanks to everyone who has provided valuable guidance for this effort to improve the MeeGo user experience in feedback, testing and related activities. Hey Randall, Hope it's not too late to provide some feedback... For the user feedback on slide 14, I might suggest triggering the feedback on the N+1 startup, rather than the N shutdown. For me, when I'm shutting down an app, it's often because I'm about to run off and do something else... I'd guess that on average I'm more likely to be receptive to a brief disruption on startup rather than shutdown. I'd also suggest that the default N should perhaps be more like 5 than 1 --- if you want meaningful feedback, you probably want people who have used the program at least a few times... The 'buzzard' sounds great --- IF you can reliably find existing bugs... One potential challenge you might want to explicitly address in the slides is that you could end up creating so many duplicate bugs that it wastes a lot of developer/bug triage time tracking down the dups... one possible approach would be to have a fairly limited number of choices for categorization so that it's more likely that the user can find any similar bugs within the same categorization... To be honest - the 'gaming experience' thing feels like a bit of a bolt-on - and I'm not sure it really fits in the same bucket as the rest. I'm not saying it's a bad idea --- just that you might want to keep your scope fairly well constrained initially - I think it'll increase the chances of success... Hope that helps. Warren -- Warren Baird - Photographer and Digital Artist http://www.synergisticimages.ca ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego Market?
On Mon, Mar 29, 2010 at 6:39 AM, David Greaves da...@dgreaves.com wrote: The barrier to entry in the community is very low. A criminal (individual or organisation) who have identified Meego as worth targetting because they've heard the announcements about using the phone for 'money transactions' may already be amongst us and contributing good code. I think an important point to consider here is more than just 'criminals', it's legitimate people who might want access to data you don't want to share to them. A friend who runs a couple of Android devices has mentioned how when he downloads open source software he often sees things like 'this app has requested access to the network, and to your contact list', and he can choose whether to run it or not. A properly sandboxed security model will help to both protect against 'hackers' who are trying to steal your bank account, and also help to identify apps that might want to 'phone home', or find your location for targeted advertising, etc. You might still choose to run the apps in the later category - but it will be an educated choice... I would hope that there are plans in MeeGo to provide a similarly fine-grained security model to what is in android... I think I saw similar discussions previously. Warren -- Warren Baird - Photographer and Digital Artist http://www.synergisticimages.ca ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] MeeGo on 'Generic' or otherwise-branded phone hardware
I've seen a couple of side-discussions on something I'm kind of interested in - whether MeeGo will run on hardware that wasn't explicitly designed for it to run on... From what I've seen on the list so far, I expect that MeeGo will run quite well on most modern netbooks, laptops, and probably on most generic ARM based tablets, etc. What I'm a little more interested in is cellphones.I think I've seen someone post that they expect MeeGo to install fine on things like the Nexus One, and other android phones. I can believe that it would *install*, and would probably run reasonably well as a hand-held linux box. The big question is - would it work well as a phone? I know from my experience with my OpenMoko Freerunner that it can be non-trivial to build a reliable phone software stack even when you are working with a very open and well documented hardware stack. Is it really reasonable to expect that the generic MeeGo Phone UX reference implementation can be dropped onto a 'generic' phone, and give reliable phone service? If not, is it understood yet how much effort it would take to support a specific phone stack? Will it even be feasible? I mean, I love my N900 (most of the time) - but I'd like to know how wide my range of choices will be when I finally decided to upgrade my phone... Warren -- Warren Baird - Photographer and Digital Artist http://www.synergisticimages.ca ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
