Active Topics

 


Page 18 of 21 « First 81617 18 1920 Last »
Closed Thread
Thread Tools
zimon is offline zimon
2011-10-01 , 13:51
Posts: 1,341 | Thanked: 708 times | Joined on Feb 2010
#171
I am more interested if it supports Python and PyQT or PySide. The future in apps is JIT runtime optimized interpreted languages anyway.
HTML5 will get there too.
 

The Following User Says Thank You to zimon For This Useful Post:
ahbarnasha
2011-10-01 , 14:21
Guest | Posts: n/a | Thanked: 0 times | Joined on
#172
Originally Posted by marxian View Post
What is the singular. Tize?

Intel and the Linux Foundation can kiss my tizen.
a little late but:
***=tiza
my ***=tizi
our asses=tizen
 

The Following 3 Users Say Thank You to For This Useful Post:
lma is offline lma
2011-10-01 , 15:29
Posts: 2,802 | Thanked: 4,491 times | Joined on Nov 2007
#173
Originally Posted by zimon View Post
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.
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!
 

The Following User Says Thank You to lma For This Useful Post:
attila77 is offline attila77
2011-10-02 , 02:14
Posts: 3,319 | Thanked: 5,610 times | Joined on Aug 2008 @ Finland
#174
Originally Posted by lma View Post
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.
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.

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?
I didn't say you shouldn't have packages, just that debs, rpms (and jars, ipkgs) are unfit (and that's why they were hacked/extended). See how f.e. icons were added into the metadata on Maemo. Apt-repositories (and for zimon, rpm correspondents are not much better 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
 

The Following 4 Users Say Thank You to attila77 For This Useful Post:
lma is offline lma
2011-10-02 , 04:00
Posts: 2,802 | Thanked: 4,491 times | Joined on Nov 2007
#175
Originally Posted by attila77 View Post
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.
I'm not familiar with that stack so can't comment. What makes it so fragile?

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.
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 ones remain exploitable. Never mind the storage, RAM etc cost (why on earth does a phone need 1GiB of RAM and compcache and flash-based swap again?)

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.
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.

Apt-repositories (and for zimon, rpm correspondents are not much better 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).
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.

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.
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?
 

The Following 5 Users Say Thank You to lma For This Useful Post:
onethreealpha's Avatar
onethreealpha is offline onethreealpha
2011-10-02 , 04:36
Posts: 434 | Thanked: 990 times | Joined on May 2010 @ Australia
#176
Originally Posted by zimon View Post
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.
To my understanding, Tizen will require HTML5 + WAC API's for HTML5 applications, and there the compliance aspect ends.

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.
 

The Following 7 Users Say Thank You to onethreealpha For This Useful Post:
AlMehdi is offline AlMehdi
2011-10-02 , 05:26
Posts: 1,751 | Thanked: 844 times | Joined on Feb 2010 @ Sweden
#177
Originally Posted by ossipena View Post
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
 

The Following 3 Users Say Thank You to AlMehdi For This Useful Post:
attila77 is offline attila77
2011-10-02 , 09:24
Posts: 3,319 | Thanked: 5,610 times | Joined on Aug 2008 @ Finland
#178
Originally Posted by lma View Post
I'm not familiar with that stack so can't comment. What makes it so fragile?
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.

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?
Now we get to the point that not all packages are created equal. There is absolutely no need for a dependency resolver to work with million-sized package lists, try to avoid circular upgrades, and triggering an upgrade tsunami. How this is going to be solved is a different matter.

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.
I'm not talking about MeeGo, luckily there are and hopefully will be enough mobile Linux systems that could take advantage of a mobile oriented approach for large repos.

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.
Let me put it this way - an iOS device know what to upgrade/install in less time than my Ubuntu box with a core i5 and 4 gigs of RAM even though it has to deal with ways more packages. 1-2 thousands of entries should be almost zero-load, you really-really need to plan for millions of entries.

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?
Roughly none. Again, I understand I'm probably too terse here and would have to explain what I mean under the terms - here's an example. Let's say you have a large game. An oldschool rpm/deb process would be - download repository list, get package file, get dependencies of it, download all files (network heavy), extract all files (disk heavy), install all files (CPU heavy). A next-gen approach would be - have a remote call to determine what is needed for the given package (yes, servers can and need to be smarter than just being a dumb http server), and then stream it - extracting it on the go and installing in parallel (I didn't mean installing multiple packages but having the download/extract/install phases happening in parallel) - being able to resume if connection lost. All the while it could skip getting parts it already has (say from a previous install, in rsync style manner) or doesn't need to minimize download size. Such a process would use less CPU, less network bandwidth and be faster than what is possible with yum/rpm (or apt/deb, etc). Yes, bold and slightly smelling of a brand new wheel, but would really be nice
__________________
Blogging about mobile linux - The Penguin Moves!
Maintainer of PyQt (see introduction and docs), AppWatch, QuickBrownFox, etc
 

The Following 2 Users Say Thank You to attila77 For This Useful Post:
mr_jrt is offline mr_jrt
2011-10-02 , 12:50
Posts: 249 | Thanked: 277 times | Joined on May 2010 @ Brighton, UK
#179
Originally Posted by attila77 View Post
Apt-repositories (and for zimon, rpm correspondents are not much better 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).
Strange...on my desktop Debian install it works brilliantly with ~29050 binary packages.
 

The Following User Says Thank You to mr_jrt For This Useful Post:
attila77 is offline attila77
2011-10-02 , 16:26
Posts: 3,319 | Thanked: 5,610 times | Joined on Aug 2008 @ Finland
#180
Originally Posted by mr_jrt View Post
Strange...on my desktop Debian install it works brilliantly with ~29050 binary packages.
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 through Fremantle, Harmattan and MeeGo repository management.
__________________
Blogging about mobile linux - The Penguin Moves!
Maintainer of PyQt (see introduction and docs), AppWatch, QuickBrownFox, etc
 
Closed Thread
Page 18 of 21 « First 81617 18 1920 Last »

Tags
déjà vu, tizen

« Previous Thread | Next Thread »

 
Forum Jump


All times are GMT. The time now is 07:17.

Contact Us - Home - Archive - Top