RPM -- plans, goals, etc. [LWN.net]

RPM -- plans, goals, etc.

Posted Dec 15, 2006 15:07 UTC (Fri) by smoogen (subscriber, #97)
In reply to: RPM -- plans, goals, etc. by drag
Parent article: RPM -- plans, goals, etc.

In the case of multilib packages, it works it out because one is an .i386 or .i686 and one is a x86_64. It then upgrades the right one. To see what the packages are in each listing you can do a 'rpm -ql <package name>'.

The unbearable slowness of yum is not something I can help with. Especially the older yum that is on the Centos-3.8 boxes.. the difference in speed with python gui and python yum is one is dealing with a database and the other is moving pixels.

(Log in to post comments)

RPM -- plans, goals, etc.

Posted Dec 15, 2006 20:41 UTC (Fri) by drag (subscriber, #31333) [Link]

Well that's what I was saying about pyrex.

Python is one of those things that kicks-ass and is plenty fast, but you have to know it's limitations.

One of those is dealing with a lot of math and such. Lots of intense calculations is not good for it.

So the basic idea of it is:
A. that you write the entire program in python.
B. Run it, benchmark it, profile it, optimize it as much as you can in pure python.
C. Once you are sure that you have it as fast as it can go and if it's still slow then you find out which parts are the most intense and rewrite them in C as modules.
D. make sure everything is fine.

It's just what you do. This is why it's possible to use python for things like programming game logic and physics. It's used by all sorts of stuff like that.

Rewriting stuff in C is a huge pain in the ass though. So they invented Pyrex. Pyrex is something were you have a python-like syntax, but you can do C-like syntax also and it's something you have to compile. It's specificly designed to create python modules.

Doing straight compile from python-like code doesn't offer much of a performance enhancement, but with proper optimizations and such you can actually get within the realm of pure C program.

There have been cases were pyrex is faster then C because you don't need a lot of the boiler-plate code and it's cleaner and more easier for the programmer to understand.

Of course you would like to avoid using Pyrex and such and do as much as you can in Python before you give up on it, otherwise with inapropriate use of pyrex can defeat much of the benifits of using python.

http://www.cosc.canterbury.ac.nz/greg.ewing/python/Pyrex/

http://www.cosc.canterbury.ac.nz/greg.ewing/python/Pyrex/...