RPM maintainer Jeff Johnson publilshed a reply to Claudio Matsuoka’s Top 10 Problems in RPM article, adding more interesting points to the discussion. If you value politeness, skip this discussion.
RPM maintainer Jeff Johnson publilshed a reply to Claudio Matsuoka’s Top 10 Problems in RPM article, adding more interesting points to the discussion. If you value politeness, skip this discussion.
All of a sudden this moron starts giving analogies to Bush and Rumsfeld and all sorts of other nonsense.
I don’t actually see any word that offends my sensibilities. Possibly it’s his forthright manner that may offend.
Funny that he decides to mix in his view on politics on technical matter. First of all, he sounds like an idiot for doing so because people reading technical documents don’t read them for political view points. Second of all, he immediately loses his points because his equating of technical points to political points forces people who disagree with him on the political points to disagree with him on the technical points. Anyways, he is an idiot. Stopped reading almost immediately.
Hey its a blog… he’s ranting, not providing a formal reply or even trying to represent any offical organization so its going to be more blunt.
Too much trolling inside
Oooo, I don’t like his politics so I discount everything he says about the root issue of RPM’s supposed failings.
WTF??
Politics aside, they were allegorical and not germaine to the topic. Judging the topic under discussion solely on a dislike for the allegory is pathetic and displays an inability to either understand the main topic or to effectively argue on it’s merits.
He makes a number of valid rebuttals.
RPM is an absolute pile of steaming crap, and everyone knows it. Some people will defend anything though. I didn’t think it was political – just lots of stupid references to Bush and Rumsfeld. He simply spouts some stuff about RPM being great because it uses Berkely DB, faster performing. Period.
What he didn’t tell us though is why exactly he thinks RPM is so damn slow, unreliable and crap.
Jeff needs to get whatever it is that’s stack up his ass out and put down the crack pipe.
Claudio could of done some more reading-up/testing on the matter but as Han said its a blog. Its a rant. Not the best technical doc, but a decent rant. So hard core trolling and diving off the deep end as a official person is rather dodgy.
Personally I like debs and APT, I run my own Apt archive at work for all the in-house projects. Debconf rocks my world. That doesn’t stop me from being envious about portage interactive merges and I could think of a few thing I’d like dpkgs to do.
> RPM is an absolute pile of steaming
> crap, and everyone knows it.
Everyone? I don’t. Do you know any reasons or just sware-words like “crap”?
> RPM is so damn slow, unreliable and crap.
Slow? I don’t notice it. Unreliable? In which way?
> Personally I like debs and APT, I run
> my own Apt archive at work for all the
> in-house projects.
What does apt have to do with the RPM vs. DEB debate? apt sits a layer on top of both(!).
Christ, it’s like he’s not trying to convince anyone. Was the smaller text still his sentence, or a response to the original comment or what?
How many threads of conversation are posted in the argument? It looks like 3 or something, but then sometimes the 2 and 3rd are agreeing which wouldn’t make sense with the anger going on between them.
…with apologists running the show. Jeff Johnson comes off as one of them.
I always valued, the high quality of osnews. So please stop right now, if you wanted to continue this. There is just one more thing to say, editors! No ofense, but use your brain not just google. People here are not interested in rants like this…
I switched to using .deb and Synaptic long ago. RPM sucks.
but still couldn’t find the answer :/
http://distrowatch.com/weekly.php?issue=20050704#2
who’s the dolt who set up a webserver on port 8080?!?!?
Some of care about our firewalls, you know.
RPM sucks…
deb sucks…
Well, if those are fact based, qualified statements, I don’t know what is…
IN all seriousness…
I have been an RPM user since RH 5.2. I work in a company that uses debian a great deal, I even sys admin a public server that runs debian. I am most definitly pro rpm.
rpm vs dpkg… they BOTH suck equally. What makes and breaks them is the use of tools like “apt”, “yum”, “smart” and so forth.
There is *NO* silver bullet for package managment.
Its best to use the tool that you feel is the right one for the job. If you like rpm and its issues, then use it. If you prefer dpkg and its issues, then use that.
We really need to move on from the “mine is better than yours” approach in package managment.
I didn’t read the whole thing in detail, but one thing caught my eye.
In the top ten list: “Non-intuitive (or plain broken) algorithm to compare package versions (example: 1a > 1B). Epoch zero is considered newer than no epoch at all.”
So there’s behavior, when such behavior should be undefined, and unintuitive behavior otherwise.
The response: “The “1a > 1B” comparison is due to strcmp(3) from glibc. Blaming rpm for glibc behavior is like blaming the atomic bomb for the cold war.”
This is why Red Hat lags behind. Why is a string comparision operation being used for version numbers, and, when it doesn’t work as expected, they shoot the messenger?!? I’m speechless.
This must be why most of the people who grew up on Red Hat in the 90s dropped it for other distros or BSD in the 21st century. I know I dropped it after discovering Slackware, Debian, and OpenBSD (and Solaris, too).
About the “The “1a > 1B” issue, I think the biggest problem is the insane version numbering is mostly at fault. Why would one number versions like that, using a mix of caps and small letters. You can’t legislate for some wierd situations. The stupid version numbers will be to blame there sorry.
”
This is why Red Hat lags behind. Why is a string comparision operation being used for version numbers, and, when it doesn’t work as expected, they shoot the messenger?!? I’m speechless.
”
Its quite odd that you dont even see the point of reasoning. The comparison in not even handled by RPM. It is handled by glibc. Shooting the messenger?. Thats exactly what “Claudio” did
did you even bother reading the article or did you decide to jump on a chance to tell everyone that RPM sucks in comparison to apt-get like comparing apples and oranges?
rpm is a tool similar to dpkg in Debian
Yum/up2date is a tool similar to apt-get in Debian
Yumex is a tool similar to synaptic
Now will everyone discuss this is a sane manner. What is being compared in the implementation of the RPM FORMAT in a BLOG. get it?
I’ve had bad experiences with BerkeleyDB. If it doesn’t suck, please tell me why I have had to rebuild RPM database several times in the past, but so far have never had the need to do something like it with dpkg. Also I’ve lost one BDB-based Subversion repository (and couldn’t recover it) but ever since I’ve switched to FSFS-based repository have never experienced it again? Search Google and you’ll find numerous corruption cases with BerkeleyDB. I wonder why…
Also, I wouldn’t say Perl or Python *chooses* BDB. They just come with a library to access BDB databases.
And Subversion had to create a non-BDB backend lately probably because BDB *does* suck.
The comparison in not even handled by RPM. It is handled by glibc.
Geez, this is like deciding to build a bridge out of paper and then complaining about the paper supplier when the bridge falls down.
glibc’s strcmp works perfectly fine and does exactly what it says in the manual: compare two strings character by character.
The manual says nothing about strcmp’s suitability for comparing version numbers, the responsibility for using it in this way lies squarely with rpm’s designers.
”
The manual says nothing about strcmp’s suitability for comparing version numbers, the responsibility for using it in this way lies squarely with rpm’s designers. ”
Upstream has a version of software x called x.1a then they release a new version called x.1b. RPM compares these to determine which one is newer. If you call that a fault of RPM, how is it NOT shooting the messenger?
Uhm. Why the heck should someone write a new tool to be better than RPM? How about improving RPM instead?
I mean come on. How card can it be to add support for different db backends, plain text being one of them. Probably very trivial. Besides, I never found RPM that slow.
The contacting of PGP keyservers he mentions can easily be disabled through macros.
I bet most of his issues can be resolved with little effort.
”
Because RPM could make a call to lower() before the strcmp() (OMFG HOW SIMPLE), or they could parse out the string into numbers and letters and make numerical comparisons where it makes sense and letter comparisions where it makes sense and avoid the whole mess.”
guess you havent even seen the actual implementation. good luck with playing by the ear
Both the original article and the response miss the point… None of the criticisms of RPM in the original are really meaningful — the response is correct, despite being reactionary and poorly composed. But the response doesn’t point out that dpkg/deb is functionally identical but for differences in implementation that don’t really differentiate their suitability for the task.
As someone else noted, neither is useful in and of itself, tools like apt (RPM and DEB) or urpmi (RPM only) make the package management acceptable.
What *IS* an issue, not just for RPMs, is the lack of a standardized cross-platform macro set. In part, because there’s lack of a standarized cross-platform utility set.
Case in point, Mandrake ships with RPM macros for adding applications to the desktop applications menu, but RedHat doesn’t. Would it kill everyone involved to implement a common macro set that performs all the useful things that one might reasonably want to do? The macro should call a script that “Does the Right Thing ™” for whichever distribution.
This article was far below the standards I have come to expect from OSNews. Please be more careful in the future.
My self & several other members of my family including 3 brothers and both parents have gradually moved off Monopoly$oft onto Linux & then onto Mac’s. Why? because as nice as Linux is, installing & removing applications is fragile & complex to fix. Compare this to Mac’s where app’s are almost always distributed as ‘Fat Binaries’ – installing is just a matter of copy the fat binary into your applications folder & double click to launch the app. Removing it is just as easy – just delete the fat binary & maybe a preference file which is easily located in a folder called “preferences” & you’re all done. It’s a dream come true in ease of use. Once you get used to it EVERYTHING else seems primitive.
“Upstream has a version of software x called x.1a then they release a new version called x.1b. RPM compares these to determine which one is newer. If you call that a fault of RPM, how is it NOT shooting the messenger?”
Because RPM could make a call to lower() before the strcmp() (OMFG HOW SIMPLE), or they could parse out the string into numbers and letters and make numerical comparisons where it makes sense and letter comparisions where it makes sense and avoid the whole mess.
> RPM is so damn slow, unreliable and crap
Slow, yes; unreliable, no; crap, certainly not.
I’ve never had a problem with RPM since the stale lockfiles issue a couple of years back – and that was only a denial of service. I’ve never had a corrupt DB, and I’m delighted that RPM uses the Berkeley DB backend. What’s the alternative – to roll your own database? Go ahead, try it – perhaps you can capture some of Sleepycat’s market share.
//obligatory Gentoo plug