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

RPM -- plans, goals, etc.

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

Ya but how can it work out that i have two versions of a libsdl lib installed?

How does RPM deal with that conflict? Were in the filesystem are these two things support so coexist.

It's all confusing and mysterious to me.

The only other thing that bugs me is the unbearable slowness of Yum. I know it's python and all, but I also use GUI python apps that feel nearly as fast as anything else.

This lead me to the original problem I had. I have a older machine that I use CentOS on as a desktop at work. It's very old, probably 300 mhz or whatnot.

Normally the speed is irritating, but it's mostly a glorified terminal so it's not a big deal.

But there was a bunch of updates flashing on that little red button and I decided I needed to update it.

I thought I gave myself enough time, but I underestimated the unbareable slowness of the beast and after a while I just plain ran out of time and had to cancel the upgrade.

A week later I was able to get back to it and lo it took me freaking 3-4 hours to resolve the issue. I work evenings and I didn't get finished with the stupid thing until like 4 or 5 AM in the morning.

gaw...

(otherwise I like CentOS)

Maybe you (or someone, maybe I'll look at but I can't make any promises, it'll take me a few months to figure out this stuff as I am no programmer) need to rewrite the math-intensive portions or something in C or Pyrex and import it back into the program as a module. I expect that there is only certain functions that take up 90% of the time..

(Log in to post comments)

RPM -- plans, goals, etc.

Posted Dec 15, 2006 13:29 UTC (Fri) by rvfh (subscriber, #31018) [Link]

What bothered me most when I had to use CentOS 3 was that yum install would always grab the latest info from the servers (which took for ever).

For deb users, it's as if apt-get install was always running apt-get update beforehand.

RPM -- plans, goals, etc.

Posted Dec 15, 2006 14:47 UTC (Fri) by smoogen (subscriber, #97) [Link]

Interesting. This must be a configuration option then as most of the Debian systems I have helped maintain had to have a 'apt-get update' run before I could get useful information. I wasn't the primary admin so this could have been something the other admins did for some obscure reason.

RPM -- plans, goals, etc.

Posted Dec 15, 2006 17:57 UTC (Fri) by Zenith (subscriber, #24899) [Link]

> had to have a 'apt-get update' run before I could get useful information

What he meant was that what rpm does is LIKE apt doing an 'apt-get update' first every time you used apt. It does of course no this, as it is, well, annoying :)

RPM -- plans, goals, etc.

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

The first thing about yum that I learned was the '-C' (or is it -c?) option which runs it using cached information so it doesn't pull down new headers each time.

RPM -- plans, goals, etc.

Posted Dec 15, 2006 21:02 UTC (Fri) by Zenith (subscriber, #24899) [Link]

Neat, I did not know about that little trick, which probably comes from the fact that I have spent way too little time administrating a Fedora/Red Hat system :)

But thanks for the tip anyway.

RPM -- plans, goals, etc.

Posted Dec 15, 2006 15:07 UTC (Fri) by smoogen (subscriber, #97) [Link]

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.

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