maemo.org - Talk

maemo.org - Talk (https://talk.maemo.org/index.php)

- MeeGo / Harmattan (https://talk.maemo.org/forumdisplay.php?f=45)

- - Tizen? (https://talk.maemo.org/showthread.php?t=77986)

Quote:

Originally Posted by attila77 (Post 1102326)

That's an abomination :) What next, QEMU in JS ? :P

... to revisit one tidbit tho:

time apt-get update:
...
Fetched 13.9 MB in 49s (281 kB/s)
Reading package lists... Done
Command being timed: "apt-get update"
User time (seconds): 11.10
System time (seconds): 0.50
Percent of CPU this job got: 23%
Elapsed (wall clock) time (h:mm:ss or m:ss): 0:49.54
Average shared text size (kbytes): 0
Average unshared data size (kbytes): 0
Average stack size (kbytes): 0
Average total size (kbytes): 0
Maximum resident set size (kbytes): 15808
Average resident set size (kbytes): 0
Major (requiring I/O) page faults: 0
Minor (reclaiming a frame) page faults: 30862
Voluntary context switches: 13521
Involuntary context switches: 2412
Swaps: 0
File system inputs: 0
File system outputs: 159096
Socket messages sent: 0
Socket messages received: 0
Signals delivered: 0
Page size (bytes): 4096
Exit status: 0

attila@t410:~$ du -s -c /var/lib/apt /var/lib/dpkg/
83728 /var/lib/apt
68468 /var/lib/dpkg/
152196 total

On mobile, this simply won't do (13.9MB network traffic, 11 sec user time on a dual-core core i5, 160K file IO requests... just to find out if there is something new - on a repository that is almost TWO ORDERS OF MAGNITUDE smaller than what you can expect in mobile).

Sure, there has to be found some better approach. But:

OTOH; you wonder why individual packages ("apps") from other "ecosystems" are so huge. Because they are statically linked and therefore self-sufficient (without dependencies). This can't continue in all seriousness either.
(I mean, the Amazon Kindle application on the Touchpad is like, 17.4 MB compressed and extracted 94MB? WTF?)

Quote:

Originally Posted by don_falcone (Post 1103453)

Sure, there has to be found some better approach. But:

I think rpm is better in that sense also, that it doesn't need a command like "apt-get update" which just only retrieves package lists from the repositories and doesn't really do anything visual meaningful for a user.

The all information about the packages (in rpm system) are needed only if someone wants to search for example what package provides or requires some random file, even from some package which is not installed yet. (i.e.: yum -q --whatrequires /usr/lib/blahbleh.so) But seldom users need such an information so there is no use to force to download it often.

Why you have to do "apt-get update" first and then "apt-get upgrade/install"?

Just upgraded "some" 79 packages to one Fedora machine.
Notice also the transactions-part, which deb-systems are missing among other things.

"Running Transaction Test
Transaction Test Succeeded
Running Transaction"

Code:

# time yum -y update

Loaded plugins: auto-update-debuginfo, downloadonly, refresh-packagekit

Setting up Update Process

Resolving Dependencies

--> Running transaction check

---> Package abrt.x86_64 0:2.0.3-1.fc15 will be updated

---> Package abrt.x86_64 0:2.0.3-4.fc15 will be an updated

---> Package abrt-addon-ccpp.x86_64 0:2.0.3-1.fc15 will be updated



...(TOTAL 79 packages)



....



---> Package usbutils.x86_64 0:003-4.fc15 will be an update

---> Package xguest.noarch 0:1.0.9-4.fc15 will be updated

---> Package xguest.noarch 0:1.0.10-1.fc15 will be an update

---> Package xulrunner-debuginfo.x86_64 0:6.0.2-1.fc15 will be updated

---> Package xulrunner-debuginfo.x86_64 0:7.0.1-1.fc15 will be an update

--> Finished Dependency Resolution



Dependencies Resolved



================================================================================

 Package                      Arch   Version            Repository         Size

================================================================================

Updating:

 abrt                         x86_64 2.0.3-4.fc15       updates           197 k

 abrt-addon-ccpp              x86_64 2.0.3-4.fc15       updates            92 k

 abrt-addon-kerneloops        x86_64 2.0.3-4.fc15       updates            69 k



...



 strigi-libs                  x86_64 0.7.5-4.fc15       updates           407 k

 tar                          x86_64 2:1.26-2.fc15      updates           823 k

 usbutils                     x86_64 003-4.fc15         updates            71 k

 xguest                       noarch 1.0.10-1.fc15      updates            60 k

 xulrunner-debuginfo          x86_64 7.0.1-1.fc15       updates-debuginfo 113 M



Transaction Summary

================================================================================

Upgrade      79 Package(s)



Total download size: 431 M

Downloading Packages:

--------------------------------------------------------------------------------

Total                                           744 kB/s | 431 MB     09:52     

Running rpm_check_debug

Running Transaction Test

Transaction Test Succeeded

Running Transaction

  Updating   : libgcc-4.6.1-9.fc15.x86_64                                 1/158 

  Updating   : libstdc++-4.6.1-9.fc15.x86_64                              2/158 

  Updating   : 1:libreoffice-ure-3.3.3.1-6.fc15.x86_64                    3/158 

  Updating   : rpm-libs-4.9.1.1-2.fc15.x86_64                             4/158 

  Updating   : rpm-4.9.1.1-2.fc15.x86_64                                  5/158 



...



  Updating   : iw-3.1-1.fc15.x86_64                                      76/158 

  Updating   : libgcc-4.6.1-9.fc15.i686                                  77/158 

  Updating   : libstdc++-4.6.1-9.fc15.i686                               78/158 

  Updating   : libtool-ltdl-2.4-6.fc15.i686                              79/158 

  Cleanup    : 1:libreoffice-pdfimport-3.3.3.1-5.fc15.x86_64             80/158 

  Cleanup    : 1:libreoffice-draw-3.3.3.1-5.fc15.x86_64                  81/158 

  Cleanup    : 1:libreoffice-presenter-screen-3.3.3.1-5.fc15.x86_64      82/158 



...



  Cleanup    : libtool-ltdl-2.4-4.fc15                                  155/158 

  Cleanup    : gnome-screensaver-3.0.0-1.fc15.x86_64                    156/158 

  Cleanup    : 1:nfs-utils-1.2.4-2.fc15.x86_64                          157/158 

  Cleanup    : iw-0.9.22-1.fc15.x86_64                                  158/158 



Updated:

  abrt.x86_64 0:2.0.3-4.fc15                                                    

  abrt-addon-ccpp.x86_64 0:2.0.3-4.fc15                                         

  abrt-addon-kerneloops.x86_64 0:2.0.3-4.fc15                                   

  abrt-addon-python.x86_64 0:2.0.3-4.fc15                                       

  abrt-gui.x86_64 0:2.0.3-4.fc15                                                

  abrt-libs.x86_64 0:2.0.3-4.fc15                                               

  abrt-plugin-bugzilla.x86_64 0:2.0.3-4.fc15                                    

  abrt-plugin-logger.x86_64 0:2.0.3-4.fc15                                      

  autocorr-en.noarch 1:3.3.3.1-6.fc15                                           

  cheese.x86_64 1:3.0.2-2.fc15                                                  

  cheese-libs.x86_64 1:3.0.2-2.fc15                                             

  cpp.x86_64 0:4.6.1-9.fc15                                                     

  firefox-debuginfo.x86_64 0:7.0.1-1.fc15                                       

  gcc.x86_64 0:4.6.1-9.fc15                                                     

  gcc-base-debuginfo.x86_64 0:4.6.1-9.fc15                                      

  gcc-c++.x86_64 0:4.6.1-9.fc15                                                 

  gcc-debuginfo.x86_64 0:4.6.1-9.fc15                                           

  gcc-gfortran.x86_64 0:4.6.1-9.fc15                                            

  gcc-java.x86_64 0:4.6.1-9.fc15                                                

  git.x86_64 0:1.7.6.4-1.fc15                                                   

  gnome-screensaver.x86_64 0:3.0.1-1.fc15                                       

  gnupg2.x86_64 0:2.0.18-1.fc15                                                 

  grubby.x86_64 0:7.0.16-5.fc15                                                 

  icedtea-web.x86_64 0:1.0.5-1.fc15                                             

  iw.x86_64 0:3.1-1.fc15                                                        

  libburn.x86_64 0:1.1.4-1.fc15                                                 

  liberation-fonts-common.noarch 0:1.07.1-1.fc15                                

  liberation-mono-fonts.noarch 0:1.07.1-1.fc15                                  

  liberation-narrow-fonts.noarch 0:1.07.1-1.fc15                                

  liberation-sans-fonts.noarch 0:1.07.1-1.fc15                                  

  liberation-serif-fonts.noarch 0:1.07.1-1.fc15                                 

  libgcc.i686 0:4.6.1-9.fc15                                                    

  libgcc.x86_64 0:4.6.1-9.fc15                                                  

  libgcj.x86_64 0:4.6.1-9.fc15                                                  

  libgcj-devel.x86_64 0:4.6.1-9.fc15                                            

  libgcj-src.x86_64 0:4.6.1-9.fc15                                              

  libgfortran.x86_64 0:4.6.1-9.fc15                                             

  libgomp.x86_64 0:4.6.1-9.fc15                                                 

  libisofs.x86_64 0:1.1.4-1.fc15                                                

  libquadmath.x86_64 0:4.6.1-9.fc15                                             

  libquadmath-devel.x86_64 0:4.6.1-9.fc15                                       

  libreoffice-calc.x86_64 1:3.3.3.1-6.fc15                                      

  libreoffice-core.x86_64 1:3.3.3.1-6.fc15                                      

  libreoffice-draw.x86_64 1:3.3.3.1-6.fc15                                      

  libreoffice-graphicfilter.x86_64 1:3.3.3.1-6.fc15                             

  libreoffice-impress.x86_64 1:3.3.3.1-6.fc15                                   

  libreoffice-langpack-en.x86_64 1:3.3.3.1-6.fc15                               

  libreoffice-math.x86_64 1:3.3.3.1-6.fc15                                      

  libreoffice-opensymbol-fonts.noarch 1:3.3.3.1-6.fc15                          

  libreoffice-pdfimport.x86_64 1:3.3.3.1-6.fc15                                 

  libreoffice-presenter-screen.x86_64 1:3.3.3.1-6.fc15                          

  libreoffice-ure.x86_64 1:3.3.3.1-6.fc15                                       

  libreoffice-writer.x86_64 1:3.3.3.1-6.fc15                                    

  libreoffice-xsltfilter.x86_64 1:3.3.3.1-6.fc15                                

  libstdc++.i686 0:4.6.1-9.fc15                                                 

  libstdc++.x86_64 0:4.6.1-9.fc15                                               

  libstdc++-devel.x86_64 0:4.6.1-9.fc15                                         

  libtool.x86_64 0:2.4-6.fc15                                                   

  libtool-ltdl.i686 0:2.4-6.fc15                                                

  libtool-ltdl.x86_64 0:2.4-6.fc15                                              

  libvoikko.x86_64 0:3.2.1-2.fc15                                               

  nfs-utils.x86_64 1:1.2.4-3.fc15                                               

  pcsc-lite.x86_64 0:1.7.2-4.fc15                                               

  pcsc-lite-devel.x86_64 0:1.7.2-4.fc15                                         

  pcsc-lite-libs.x86_64 0:1.7.2-4.fc15                                          

  perl-Git.noarch 0:1.7.6.4-1.fc15                                              

  python-beaker.noarch 0:1.5.4-1.fc15                                           

  python-dateutil.noarch 0:1.5-3.fc15                                           

  python-matplotlib.x86_64 0:1.0.1-12.fc15                                      

  rpm.x86_64 0:4.9.1.1-2.fc15                                                   

  rpm-build.x86_64 0:4.9.1.1-2.fc15                                             

  rpm-build-libs.x86_64 0:4.9.1.1-2.fc15                                        

  rpm-libs.x86_64 0:4.9.1.1-2.fc15                                              

  rpm-python.x86_64 0:4.9.1.1-2.fc15                                            

  strigi-libs.x86_64 0:0.7.5-4.fc15                                             

  tar.x86_64 2:1.26-2.fc15                                                      

  usbutils.x86_64 0:003-4.fc15                                                  

  xguest.noarch 0:1.0.10-1.fc15                                                 

  xulrunner-debuginfo.x86_64 0:7.0.1-1.fc15                                     



Complete!

261.88user 73.99system 38:34.11elapsed 14%CPU (0avgtext+0avgdata 339580maxresident)k

4491024inputs+6856928outputs (18525major+914780minor)pagefaults 0swaps

Last time i tested Fedora my biggest caveat, other than buggs, was the slow Yum. The GUI was even worse. Apt is a lot better in this regard... but if i could chose i would go with Arch's Pacman or Yaourt for that matter. Fast, simple and informative. Haven't tried it after they added package signing though.

Quote:

Originally Posted by AlMehdi (Post 1103601)

Agreed: I couldn't stand Fedora because of Yum. Its features are brilliant but its speed... OpenSuSE's zypper, however, is rather good.

What's yaourt without pacman? ;) I also like pacman and I think PKGBUILDS are easier to create than RPM spec files and Debian's debhelper stuff

Quote:

Originally Posted by AlMehdi (Post 1103601)

Last time i tested Fedora my biggest caveat, other than buggs, was the slow Yum. The GUI was even worse.

The extra measures for system integrity, using transactions, do take little more time. But on the other hand, for example if you are doing this wireless with a laptop and battery goes empty middle of upgrading, transaction-support save the day and the system.

Haven't really needed to rollback ever yet, but its nice to have that too.

I haven't found it to be slow. The previous quote shows how much CPU-time upgrading 79 packages took, not much.
"261.88 user, 73.99 system, 38:34.11 elapsed, 14%CPU "
The actual time was long, because the system was downloading packages over slow net bandwidth.

I've read lots of comments -really most on this thread- saying/supposing that Tizen only allows HTML5 (and other web standars) programming. That is absolutely FALSE.

Tizen allows native code programming and a NATIVE DEVELOPMENT KIT will be available since Tizen debut.

In is clear in Tizen web site. It appears in the 1st page: https://www.tizen.org/
You can read: "For those who use native code in their applications, the Tizen SDK will include a native development kit. We will open the entire Tizen software stack, from the core OS up through the core applications and polished user interfaces".

I.e.: Native developement is available and we will have full access to the entire stack, from core OS upwards, not only the upper layers like it occurs on other OS where you can't touch low layers.

So really I think most of you are wrong about Tizen. Of course I undestand upset among Qt developers: you have inverted time and money (time cost more than money) in Qt.

Tizen encoyrages HTML5 and other web standars for programming, but doesn't block native code but allows it without penalities.

Also I think 90% (of more) of the applicactions available in Apple Appstore or in Android Market, could be done in HTML5 an other web estandar programming, and only much less tang 10% would need native programming/develpment. Even more, we know that having millions of applications is a good marketing point -althougt most of us agree it is not usefull for us as most of them are pure trash- and with web standars anyone can do a program to add to get millions of trash applicantions for marketing.

If Tizen would not allow native application I would turn my head to other place, but it isn't the case.

Even Tizen is much better (speaking about native code) than Windows Phone 7, because WP7 doesn't allow native code -WP7 only allows .NET (managed code) and Silverligh (like a refined but failed Flash copy)-. Even Tizen es better than Android (in native code) because Android didn't have native code since debut -Android NDK was added a year after- and Android NDK doesn't have the same chanes to acces to all APIs like Dalvik in Android.

On other hand I like Tizen give so much importance to HTML5 an other web standars because I suppose it will entail a very high quality in that standar implementayions in Tizen.

Also Samsung is a much better partner than Nokia: it appears that Samsung will not bought by Microsoft or under Microsoft's boot like Nokia; Samsung now is king in mobile and, what is even better, is king in other consumer products like TV, computers, have tablets, etc... all important items to Tizen as this is a versatile SO not only for phones, while Nokia only has phones and going down like sinkers.

So, I think Tizen is bright in native code and Samsung is the best partner. Of course I'll wait to see real products.

Quote:

Originally Posted by zwer (Post 1098845)

.....

When it comes to programming, there is a plethora of ways to skin the cat, and no tool is the best for all cases (and in some cases one and one tool only cannot do the job at all), which is why it is inherently wrong to restrict development to only one channel. Case in point, HTML is not even close to the best way to describe a layout (due to its top/down origins), and JavaScript is inherently difficult to manage, debug and reuse (due to its lack of extensive set of natives, strict typing and prototype-based OOP - some of which were changed only recently). Sure, it's easier to create an info page with some basic interactions in HTML/JS combo than it is, for example, in C++, but writing something more complex, for example a game engine or some face recognition software in HTML5 (even if it would provide direct access to the webcam's feed) is a daunting task to be taken only by enthusiasts to prove that it can be done at some level. Not to mention that you have to rewrite every single library, that has been brewing for decades, into JavaScript, if possible at all, just to use features that you're accustomed to. And that's only from development POV, performance is a whole other subject.

HTML5 suffers from the same problem that all previous iterations of HTML suffered - ....

I personally don't mind having an option of developing close-to-native HTML5 apps, for many use cases it is the most optimal solution, but making it prime-and-only development option is just wrong. Qt is probably the best of both worlds when it comes to portability vs performance, which is why I condoned that direction (as long as there is alternative, of course), HTML5 is a step in a wrong direction.

The main problem with Tizen is not its default toolkit but the very nontransparent decision-making without an input from the community.
Who knows what other brilliant idea they might get in a year and change the course again without any warning or discussion.

Like Nokia accepted any input from the community in Maemo/Meego development.

one way or the other even if they decide to dump Tizen there will be something left. MER has some benefits form the leftovers from MeeGo so they can move forward. Tizen might just give them a new boost.
ps
sory for typos and mistakes writing from N900 and it doesn't do any spellchecking

I don't see any need of transparency as long as I like the outcome. I rather see that they go all the way and do what nokia couldn't. Looking forward to tizen. Meanwhile, I will buy my first samsung device to show my support!