[maemo-developers] MeeGo, unity or fragmentation?

[From: Christopher Intemann]

I would rather see the benefits from the merge.
The different package format does not really matter, since developer tools
allow to create packages automatically and it won't need much efforts for
developers to provide both a deb and a rpm release.
Having a OS which is not bound to a single device such as the N900 but
available on several platforms is a great benefit for both endusers -
imaging having both a netbook and a phone running virtually the same OS,
allowing to use the same applications (and even packages) on both devices -
and developers, which can then provide applications for a far bigger
community.
Since Maemo is already more mature than Moblin (IMHO) and does already
provide a telephony interface, I guess the first MeeGo release will be
widely based on Maemo but use rpm as packaging format.
I don't see a cross platform/hardware (ARM vs. Intel) issue as well, since
the package format is absolutely independent from the platform (and I
personal have had no issues with using SuSE on Sparc a while ago, which was
rpm based).
Finally, Moblin utilizes yum, which is very similar to apt-get / apt-cache,
and IMHO far better than SuSE Yast, as it is more handy and easier to use
from the prompt. It's probably very likely that MeeGo will come with yum as
well, great news for Fedora users!
Regards,
 Chris

On Mon, Feb 15, 2010 at 7:05 PM, Ville Reijonen <vilre at cs.tut.fi> wrote:

>
> Just analyzing the news..
>
> "Many devices" - Tablets, cars, phones, televisions:
> * Different screen sizes require different UI designs, and often more.
> * On small mobile devices energy consumption is more acute problem than on
> tablet, tv or car. Software originating from other device family might suck
> phone battery dry..
> * The devices won't have the same input devices, there might be devices
> without any touch screen or hardware keys.
> * Software for one device can not be guaranteed to be ok on another device.
> What will the QA be like, can there even be a single QA? It it hard to
> develop for a device which one does not have. Additionally, who even cares
> about some devices they do not have?
> * GTK and QT need to learn to live together even better than before.
> * Single software stack will help to convince developers seeking a market.
> * Ovi Store and Intel AppUp Center, already two separate places for
> software, what if one more store comes out? How about Repositories?
> * Will I be able to move my DRM'd programs and files from Nokia MeeBoo to
> Intel MeeToo?
> * MeeGo GTK will not not compute on S60.
>
> => code once, use every does not apply? Will it be necessary to port
> software from MeeGo to MeeGo to get it work on different devices? How these
> internal boundaries will be defined and made secure?
>
> Two corporations make better cake than one?
> * Does moblin really have "community" or just paid drones? Moblin-dev, the
> only mailing list they have had 3 mails today, yesterday 1, last friday 1.
> Didn't bother to check the irc channel.
> * It might be more natural for maemo to swallow moblin, but it seems that
> as there is two corporation in helm, a third instance has to be created.
> (MeeGo even has a dictator duo, that is one "benovolent dictator" per
> company)
> * How much there will be "design by commitee"?
> * MeeGo, is it distribution or a platform? Add a lot of old software
> components and few new software components.. rpm faq entry on packaging
> sound more like a distribution than platform.
> * Where is the nice and soft .org? Corporations say, community follows?
>
>
> p.s. "Meego is a short-lived American science fiction sitcom... 1997... was
> canceled half way through its first season."
>
> --
> VRe
> _______________________________________________
> maemo-developers mailing list
> maemo-developers at maemo.org
> https://lists.maemo.org/mailman/listinfo/maemo-developers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.maemo.org/pipermail/maemo-developers/attachments/20100215/01fd960f/attachment.htm>