Active Topics
-
Firefox with Leste (10)
to Maemo 7 / Leste by teroyk - 3 days, 11 hrs ago - more...
|
2011-10-05
, 18:02
|
|
Posts: 1,341 |
Thanked: 708 times |
Joined on Feb 2010
|
#192
|
Originally Posted by don_falcone
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.
Sure, there has to be found some better approach. But:
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 edited by zimon; 2011-10-05 at 18:16.
|
|
2011-10-05
, 21:07
|
|
Posts: 1,751 |
Thanked: 844 times |
Joined on Feb 2010
@ Sweden
|
#193
|
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.
__________________
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 User Says Thank You to AlMehdi For This Useful Post: | ||
|
|
2011-10-05
, 21:47
|
|
Posts: 235 |
Thanked: 339 times |
Joined on Nov 2010
|
#194
|
Originally Posted by AlMehdi
Agreed: I couldn't stand Fedora because of Yum. Its features are brilliant but its speed... OpenSuSE's zypper, however, is rather good.
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.
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
|
|
2011-10-05
, 22:04
|
|
Posts: 1,341 |
Thanked: 708 times |
Joined on Feb 2010
|
#195
|
Originally Posted by AlMehdi
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.
Last time i tested Fedora my biggest caveat, other than buggs, was the slow Yum. The GUI was even worse.
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.
Last edited by zimon; 2011-10-05 at 22:16.
|
|
2011-10-23
, 13:44
|
|
Posts: 1 |
Thanked: 4 times |
Joined on Oct 2011
|
#196
|
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.
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.
Originally Posted by zwer
.....
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.
|
|
2011-10-23
, 13:51
|
|
Posts: 1,548 |
Thanked: 7,510 times |
Joined on Apr 2010
@ Czech Republic
|
#197
|
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.
Who knows what other brilliant idea they might get in a year and change the course again without any warning or discussion.
__________________
modRana: a flexible GPS navigation system
Mieru: a flexible manga and comic book reader
Universal Components - a solution for native looking yet component set independent QML appliactions (QtQuick Controls 2 & Silica supported as backends)
modRana: a flexible GPS navigation system
Mieru: a flexible manga and comic book reader
Universal Components - a solution for native looking yet component set independent QML appliactions (QtQuick Controls 2 & Silica supported as backends)
| The Following User Says Thank You to MartinK For This Useful Post: | ||
 |
|
2011-10-23
, 17:28
|
|
Posts: 584 |
Thanked: 700 times |
Joined on Jan 2010
|
#199
|
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
ps
sory for typos and mistakes writing from N900 and it doesn't do any spellchecking
__________________
per ardua ad astra
per ardua ad astra
 |
|
2011-10-23
, 17:39
|
|
Posts: 7,074 |
Thanked: 9,069 times |
Joined on Oct 2009
@ Moon! It's not the East or the West side... it's the Dark Side
|
#200
|
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!
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?)