Active Topics
| The Following User Says Thank You to zimon For This Useful Post: | ||
|
|
2011-10-01
, 14:21
|
|
Guest |
Posts: n/a |
Thanked: 0 times |
Joined on
|
#172
|
Originally Posted by marxian
a little late but:
What is the singular. Tize?
Intel and the Linux Foundation can kiss my tizen.
***=tiza
my ***=tizi
our asses=tizen
|
2011-10-01
, 15:29
|
|
Posts: 2,802 |
Thanked: 4,491 times |
Joined on Nov 2007
|
#173
|
Originally Posted by zimon
Openness isn't quite enough in this era of (spit) "ecosystems". If the device vendors and app stores don't support it, and if the app compliance policy is anything like meego's (and it probably will be, since the same people are behind it) then every Qt app will have to bundle its own private copy of the entire Qt stack. You'll have to download several 10s of megabytes each and every time you install or update one of those apps, and you'll have to take the storage and RAM hit of having all those independent but more or less identical copies of Qt libs around. Fun!
As it has been said, (if) Tizen is open, so Qt (and *sigh* QML) will end up to Tizen anyway if there is a community or person to do it. Officially companies using Tizen of course won't support or provide it then unless they make an exception.
| The Following User Says Thank You to lma For This Useful Post: | ||
|
|
2011-10-02
, 02:14
|
|
Posts: 3,319 |
Thanked: 5,610 times |
Joined on Aug 2008
@ Finland
|
#174
|
Originally Posted by lma
Sorry, been there, done that (with Qt, Mobility and PyQt). It's a nightmare, it's just so easy to break/drive the upgrade mechanism into an error that it's not even funny. As for several copies, again, in a weird sense it's the lesser of two evils. When you have a thousand (yes, I'm exaggerating) apps using a shared lib, they will inevitably be using multiple, maybe mutually exclusive versions. When these apps and libs are open source, and have maintainers, all is well - you ping people, they repack, patch, etc. In a store, that doesn't happen - you mostly only have binaries, the users expect them to work even after upgrades, you must rely on the original author to fix whatever is broken, etc. MeeGo compliancy was right about what matters for stores - where it was wrong is that it was linked to logo and name usage and didn't take into account that stores and FOSS repositories can't be managed the same way.
Only if have you have drank really large doses of the meego-compliance kool aid. Some of us beg to differ and still cling to "historical" system maintenance practices. You know, like the ability to install/uninstall/upgrade software and all its dependencies cleanly, or like having one copy of a particular library even if 30 apps use it.
Fundamentally, a package (rpm/deb/ipkg/opkg/whatever) consists of some blobs that need to be installed somewhere on the filesystem, and some metadata like a manifest, dependencies and perhaps pre/post-install/remove instructions. Why do you think that is a hack and how do you propose to have a sane system without it?
are horribly unsuited for large package counts (take a look how much time and memory it takes to update/refresh on an N900 that has all extras* repos enabled). A modern package format (and corresponding repositories) should be streamable, resumeable, filterable, downloadable and installable in parallel, support selective part-downloads, multi-arch, reconstructable, delta-upgradeable, have indexed and easily accessible metadata, etc, etc.
__________________
Blogging about mobile linux - The Penguin Moves!
Maintainer of PyQt (see introduction and docs), AppWatch, QuickBrownFox, etc
Blogging about mobile linux - The Penguin Moves!
Maintainer of PyQt (see introduction and docs), AppWatch, QuickBrownFox, etc
|
|
2011-10-02
, 04:00
|
|
Posts: 2,802 |
Thanked: 4,491 times |
Joined on Nov 2007
|
#175
|
Originally Posted by attila77
I'm not familiar with that stack so can't comment. What makes it so fragile?
Sorry, been there, done that (with Qt, Mobility and PyQt). It's a nightmare, it's just so easy to break/drive the upgrade mechanism into an error that it's not even funny.
As for several copies, again, in a weird sense it's the lesser of two evils. When you have a thousand (yes, I'm exaggerating) apps using a shared lib, they will inevitably be using multiple, maybe mutually exclusive versions.
When these apps and libs are open source, and have maintainers, all is well - you ping people, they repack, patch, etc. In a store, that doesn't happen - you mostly only have binaries, the users expect them to work even after upgrades, you must rely on the original author to fix whatever is broken, etc.
Anyway, this whole topic was discussed ad nauseum in meego-dev when/where it was more appropriate, we certainly won't solve it here. Besides, it doesn't matter much anymore, what with the wench being dead and all.
Apt-repositories (and for zimon, rpm correspondents are not much better
A modern package format (and corresponding repositories) should be streamable, resumeable, filterable, downloadable and installable in parallel, support selective part-downloads, multi-arch, reconstructable, delta-upgradeable, have indexed and easily accessible metadata, etc, etc.
| The Following 5 Users Say Thank You to lma For This Useful Post: | ||
 |
|
2011-10-02
, 04:36
|
|
Posts: 434 |
Thanked: 990 times |
Joined on May 2010
@ Australia
|
#176
|
Originally Posted by zimon
To my understanding, Tizen will require HTML5 + WAC API's for HTML5 applications, and there the compliance aspect ends.
As it has been said, (if) Tizen is open, so Qt (and *sigh* QML) will end up to Tizen anyway if there is a community or person to do it. Officially companies using Tizen of course won't support or provide it then unless they make an exception.
Having a fork/build of Tizen core with a Qt stack won't necessarily make any such build non-compliant, as long as Qt isn't called or used in HTML5 applications.
Intel will be fully supporting Arm and Zehjotkah has indicated on another thread that although they will be prefering HTML5 Applications in the Appup store, they won't have any issues with GTK+ or Qt stuff residing there, thus companies like Novomak having no problem shipping Tizen with Qt.
__________________
Always remember you're unique, just like everyone else.
Always remember you're unique, just like everyone else.
|
|
2011-10-02
, 05:26
|
|
Posts: 1,751 |
Thanked: 844 times |
Joined on Feb 2010
@ Sweden
|
#177
|
Originally Posted by ossipena
whoa... first we were talking about "apps" and then comes... photoshop...
By the time Tizen have theoretical chance of coming to shops, the world as we know it probably has changed. if nothing happends, you can still cover 99,9% appstore items with HTML5 easily...
I would say this is kinda slick Run Gimp through Web Browser
And yes, more and more are moving toward the web either we like it or not. I don't see a big problem except maybe resource wise of HTML5. But then.. i am using Gnome-shell which is similar in many ways.
If they are true about what they say.. that they will use open governance i am with them. I think this is the great shot we all have been waiting for. If we do not like the shell.. well then we could make our own.. community based one. We could even make a dist probably. The most important part with Tizen is not the OS but that the biggest hardware producer stands behind it.
__________________
You like what i do? Donate!
Make your desktop look awesome - use the AwOken Theme with the AwOken Icon Theme.
Add me on twitter @almehdin
Visit the swedish maemo/meego community forums
You like what i do? Donate!
Make your desktop look awesome - use the AwOken Theme with the AwOken Icon Theme.
Add me on twitter @almehdin
Visit the swedish maemo/meego community forums
| The Following 3 Users Say Thank You to AlMehdi For This Useful Post: | ||
|
|
2011-10-02
, 09:24
|
|
Posts: 3,319 |
Thanked: 5,610 times |
Joined on Aug 2008
@ Finland
|
#178
|
Originally Posted by lma
It's inherent. As an example of why I regretted for splitting PyQt for Fremantle into packages like on the desktop - application X uses modules A and B, application Y uses A and C. Now, since A B and C have to be from the same build, if you installed X, and A or C got upgraded later, you can't install Y without upgrading/installing new versions of A B C. Now, *IN THEORY* in an ideal backward-compatible world this should work. In practice, there is always this little regression or change that makes this not work (being able to point fingers at upstream or the application relying on buggy behavior is NOT really a solution). Plus the bonus that any QA that was done was done with a different version so all bets are off just what you get.
I'm not familiar with that stack so can't comment. What makes it so fragile?
Which is fine, on a sane OS you can have multiple versions of any particular lib installed in parallel for whichever app depends on them. You'll still end up with just a handful of them rather than a thousand. More importantly that's maintainable - if a security issue is discovered in libfoo, you just update that and the user is safe again. The "modern mobile" user on the other hand will have to update each app separately, and will never know whether all libfoo bundlers bothered to issue updates, or how many and which
<snip>
Even in a "store", why shouldn't I be allowed to package my own libs sanely for my own packages to use?
Anyway, this whole topic was discussed ad nauseum in meego-dev when/where it was more appropriate, we certainly won't solve it here. Besides, it doesn't matter much anymore, what with the wench being dead and all.
Well, if you draw your conclusions based on that particular implementation... IME it was even perceptively slower than the Diablo version on Diablo hardware, and that was 18 months ago when fremantle extras was still young. Heck, even my lowly access point (a 125MHz MIPS with 16MiB of RAM) can process its package repository (1439 packages right now) faster than the N900 could its own.
Apart from parallel installation (for which I don't see the point, having seen it on Android where it simply caused heavy I/O contention and actually slowed things down) which of the above aren't provided by say a yum/rpm repository?
__________________
Blogging about mobile linux - The Penguin Moves!
Maintainer of PyQt (see introduction and docs), AppWatch, QuickBrownFox, etc
Blogging about mobile linux - The Penguin Moves!
Maintainer of PyQt (see introduction and docs), AppWatch, QuickBrownFox, etc
|
|
2011-10-02
, 12:50
|
|
Posts: 249 |
Thanked: 277 times |
Joined on May 2010
@ Brighton, UK
|
#179
|
Originally Posted by attila77
Strange...on my desktop Debian install it works brilliantly with ~29050 binary packages.
Apt-repositories (and for zimon, rpm correspondents are not much better
| The Following User Says Thank You to mr_jrt For This Useful Post: | ||
|
|
2011-10-02
, 16:26
|
|
Posts: 3,319 |
Thanked: 5,610 times |
Joined on Aug 2008
@ Finland
|
#180
|
Originally Posted by mr_jrt
Yes, as said, desktop is a whole different story. Different limitations, different requirements, different usage patterns. The hardcore desktop linux user can of course say that having a familiar package management mechanism (and package format) justifies the speed, memory and bandwidth drawbacks. In reality, I'd say a good (responsive, non-intrusive) way of dealing with packages that benefits all users is more important. Feel free to disagree, I know packaging format/management is a religion, I just voiced how IMO mobile packaging should work, based on the lessons I learned while dealing (suffering
Strange...on my desktop Debian install it works brilliantly with ~29050 binary packages.
through Fremantle, Harmattan and MeeGo repository management.
__________________
Blogging about mobile linux - The Penguin Moves!
Maintainer of PyQt (see introduction and docs), AppWatch, QuickBrownFox, etc
Blogging about mobile linux - The Penguin Moves!
Maintainer of PyQt (see introduction and docs), AppWatch, QuickBrownFox, etc
HTML5 will get there too.