zimon | # 171 | 2011-10-01, 13:51 | Report

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.

ahbarnasha | # 172 | 2011-10-01, 14:21 | Report

a little late but:
***=tiza
my ***=tizi
our asses=tizen

lma | # 173 | 2011-10-01, 15:29 | Report

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!

attila77 | # 174 | 2011-10-02, 02:14 | Report

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.

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.

lma | # 175 | 2011-10-02, 04:00 | Report

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

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?

onethreealpha | # 176 | 2011-10-02, 04:36 | Report

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.

AlMehdi | # 177 | 2011-10-02, 05:26 | Report

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.

attila77 | # 178 | 2011-10-02, 09:24 | Report

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.

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.

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.

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.

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

mr_jrt | # 179 | 2011-10-02, 12:50 | Report

Strange...on my desktop Debian install it works brilliantly with ~29050 binary packages.

attila77 | # 180 | 2011-10-02, 16:26 | Report

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.