• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

why do you hate RPM-based distros??

Ok, I am not a total linux nobe. We were required to install it for school and they told us to use Fedora Core 4 since that was the lab environment. Now I am on co-op and I use Red Hat Enterprise everyday. However, the problem is even though i can find my way around linux real well, I am not familiar with anything outside the redhat world, and I would like to branch out and see what other distros have to offer. So why do people think RPMs are so bad and debian/ubuntu 's system is so much better? How is does ubuntu stack up in terms of hardware compatibility?
 
I don't. RPMs are fine, if combined with a decent package management system. This recent apt fancying is getting sickening.
 
I don't hate them either. I personally think they're easier to use than anything else. Maybe it's because I've been using RPM for too long. Apt is great for run-of-the-mill things which are non-version-critical like "KCalc" or something, but when I need the latest update of some relatively obscure program or driver I'm still going to have to download the .deb of it and install that with dpkg -i. I haven't screwed around with Debian lately (I should), so I can't exactly elaborate on its package system.

Holy crap n0cmonkey, you're about to hit 40000 posts. 😛
 
I used to LOVE SuSE (it is RPM based),.... but then they got seriously into crippling their product.

When Novelle took over SuSE and compiled out MP3 support I stopped buying the distro,....

I see no reason to ever buy or support it again,.....
 
Originally posted by: JohnBernstein
I used to LOVE SuSE (it is RPM based),.... but then they got seriously into crippling their product.

When Novelle took over SuSE and compiled out MP3 support I stopped buying the distro,....

I see no reason to ever buy or support it again,.....

LOL, that's why you don't use SUSE? Just install madlib then. 😉 Redhat also removes mp3 support by default but installing mp3 codecs again is very easy. SUSE is great for everything else IMO.
 
Originally posted by: JohnBernstein
I used to LOVE SuSE (it is RPM based),.... but then they got seriously into crippling their product.

When Novelle took over SuSE and compiled out MP3 support I stopped buying the distro,....

I see no reason to ever buy or support it again,.....
He's already ruined one thread with this crap and has his very own to rant in now. May I suggest that we all just ignore this one?

Edit: oh, and rpms never bothered me, just people that build and distribute them without testing properly (which hasn't happened that often) 😛
 
It used to be with Redhat 6.0-8.0 that you would like to install a program. But then you would need certain dependencies, which meant you had to find the rpm binaries of those dependencies (libraries, gui's, etc) Which was frustraing because you would end up installing 13 rpm's and find out one was the wrong version or was not available, so you would end up not installing the original program yuo wanted in the first place.
Apt-get came along and was configured to automatically download and install the needed dependencies. Then Gentoo came out with portage, and apt-get got better because it incorporated some features of Portage.
Now rpms are better at downloading needed dependencies, I use Opensuse and really have no need to go searching for obscure rpm's.
 
Originally posted by: kamper
Originally posted by: JohnBernstein
I used to LOVE SuSE (it is RPM based),.... but then they got seriously into crippling their product.

When Novelle took over SuSE and compiled out MP3 support I stopped buying the distro,....

I see no reason to ever buy or support it again,.....
He's already ruined one thread with this crap and has his very own to rant in now. May I suggest that we all just ignore this one?

Edit: oh, and rpms never bothered me, just people that build and distribute them without testing properly (which hasn't happened that often) 😛

Same thing with me.

It's the quality of the package makers and how well they cooridnate with others that matter, the actual package format is largly irrelevent.

As for the deb versus rpm.. the rpm package is probably technically superior and more sophisticated, but my favorite format is Slackware's format which is just tarball with a extra directory that gets deleted at install time.
 
I think it has to do something with the amount of control the user has with what to install and what not to install...but then again I'm probably wrong, having spent more of my time in Ubuntu instead of Mandrake/Mandriva.
 
Originally posted by: drag
As for the deb versus rpm.. the rpm package is probably technically superior and more sophisticated, but my favorite format is Slackware's format which is just tarball with a extra directory that gets deleted at install time.
There is really not that much difference between the various packages.

The main difference being the small amount of metadata that comes with the binaries.

It would be a simple matter to figure out how to change from one format to another if one set one's mind to it.

Starting with RPM's: use rpm2cpio to get a cpio package, extract the metadata and binaries,.... etc.

To get back to an RPM from the files, use rpmbuild.

To get to a DEB package you just wrap up the binaries but you would have to translate the metadata. You would have to study the different formats of the metadata to do this, but I can't see it being very hard.
 
Originally posted by: JohnBernstein
Originally posted by: drag
As for the deb versus rpm.. the rpm package is probably technically superior and more sophisticated, but my favorite format is Slackware's format which is just tarball with a extra directory that gets deleted at install time.
There is really not that much difference between the various packages.

The main difference being the small amount of metadata that comes with the binaries.

It would be a simple matter to figure out how to change from one format to another if one set one's mind to it.

Starting with RPM's: use rpm2cpio to get a cpio package, extract the metadata and binaries,.... etc.

To get back to an RPM from the files, use rpmbuild.

To get to a DEB package you just wrap up the binaries but you would have to translate the metadata. You would have to study the different formats of the metadata to do this, but I can't see it being very hard.

You can use Alien. I don't know how many times alien has come in handy for converting deb to rpm and vice versa.

I personally like debian based distros, such as Ubuntu or Debian stable. RPM's have left a sour taste in my mouth from their dependency hell days. I know apt-get and yum have made it so much easier, but I still refuse to use an RPM based distro. I feel like a fish out of water when using them.

I guess that would be my Debian fanatacism getting in the way from trying new things. What can I say... Debian does that to people 😛
 
Originally posted by: JohnBernstein
I used to LOVE SuSE (it is RPM based),.... but then they got seriously into crippling their product.

When Novelle took over SuSE and compiled out MP3 support I stopped buying the distro,....

I see no reason to ever buy or support it again,.....

Suse just didn't have mp3 support for 9.3 (although they did have real player which did have mp3 support). All you had to do was an online update (I'm sure you know how easy YOU is) that would install multimedia codecs, no recompiling necessary. They have mp3 support with their Suse 10.0 Eval.

And btw, Novell acquiring Suse was the best thing to ever happen to Suse. Suse now has a completely open-source version along with a version with proprietary software. Novell made Suse completely free (free as in beer and freedom). Novell is supporting a ton of OSS projects, most important of which being XGL. If there's a chance of a linux distro sitting next to Microsoft's Windows in retail stores, it'd probably be Novell's Linux Desktop. So stfu.
 
Originally posted by: angryswede
Ok, I am not a total linux nobe. We were required to install it for school and they told us to use Fedora Core 4 since that was the lab environment. Now I am on co-op and I use Red Hat Enterprise everyday. However, the problem is even though i can find my way around linux real well, I am not familiar with anything outside the redhat world, and I would like to branch out and see what other distros have to offer. So why do people think RPMs are so bad and debian/ubuntu 's system is so much better? How is does ubuntu stack up in terms of hardware compatibility?

I think people just have a bad taste leftover from "rpm hell". Its pretty much just as easy to install rpms as it is to install a deb. It mainly depends on the package manager and its just that tools like apt appeared for deb files sooner and pretty much all deb based distros have it while rpm based distros have different package managers like yum, apt4rpm, etc and they've appeared later.

Then again, I guess apt is better than the fragmented amount of package managers that rpm based distros have so that might be a reason.. And the fact that Debian/Ubuntu's repositories probably have a ton more packages.

What do you mean by ubuntu's hardware compatibility? Hardware detection and providing driver support automatically for the hardware? Most of it depends on the kernel; the newer the kernel the greater the chance of supporting (newer) devices.

However, from what I've seen, when first installing Ubuntu/Debian I've noticed that people with newer nVidia and ATi devices tend to be given older nVidia and ATi drivers so their video cards aren't supported and they have to do some configuring to get X running. That's what Ubuntu did with me and my Radeon 9800 and GeForce 6800. Suse gave me a vesa (generic) driver and I was able to install a better driver later. Other than that, most hardware should be detected similarly to other distros and should work well.
 
I like RPM just fine. I also like the ability to roll your own. If a new program or an update comes out that is not available in rpm, I just compile it from scratch and create an rpm package while I'm at it. It took a bit to learn the particulars of the spec file and rpmbuild, but it was worth it. This way I have all the rpm's I need for a reinstall or to put on other systems.


unmerited
 
How is does ubuntu stack up in terms of hardware compatibility?

All distros support about the same hardware, there might be some corner cases where one distro includes a driver earlier than the rest but that's pretty rare.

As drag said, the RPM format itself is fine and even superior to .debs in a few ways. But the problem is that FC has virtually no packages available in their base repository and the 3rd party repositories are crap. With Debian sid/Ubunutu you get nearly 18,000 packages available via apt. That and yum is crap, it's slow as hell and really annoying to work with.

There is really not that much difference between the various packages.

The main difference being the small amount of metadata that comes with the binaries.

That's the whole point though. The format of each is really just tar vs cpio, the real difference in the formats is in the metadata.
 
Originally posted by: Nothinman
How is does ubuntu stack up in terms of hardware compatibility?

All distros support about the same hardware, there might be some corner cases where one distro includes a driver earlier than the rest but that's pretty rare.

As drag said, the RPM format itself is fine and even superior to .debs in a few ways. But the problem is that FC has virtually no packages available in their base repository and the 3rd party repositories are crap. With Debian sid/Ubunutu you get nearly 18,000 packages available via apt. That and yum is crap, it's slow as hell and really annoying to work with.

[



thats why I was initially hating rpm also but pclos uses rpm....And It works great because Tex thouroughly tests each package first.🙂
 
Originally posted by: Nothinman
As drag said, the RPM format itself is fine and even superior to .debs in a few ways. But the problem is that FC has virtually no packages available in their base repository and the 3rd party repositories are crap. With Debian sid/Ubunutu you get nearly 18,000 packages available via apt. That and yum is crap, it's slow as hell and really annoying to work with.
Geez, you'd think yum ran over your favourite pet with it's car or something 😕

In the approximate year that I used fedora as a desktop I had to go outside the main repo only once or twice, to reputable repositories (dag and jpackage.org) that worked perfectly. The one time that I set up Ubuntu for my sister, I had to add extra repositories almost immediately and for a much higher number of packages. Granted, they all worked fine as well. Of course, I'm not everybody and my experience isn't the rule, but it's a little more reasonable than "virtually no packages available" :roll:
 
Originally posted by: hardcandy2
It used to be with Redhat 6.0-8.0 that you would like to install a program. But then you would need certain dependencies, which meant you had to find the rpm binaries of those dependencies (libraries, gui's, etc) Which was frustraing because you would end up installing 13 rpm's and find out one was the wrong version or was not available, so you would end up not installing the original program yuo wanted in the first place.
Apt-get came along and was configured to automatically download and install the needed dependencies. Then Gentoo came out with portage, and apt-get got better because it incorporated some features of Portage.
Now rpms are better at downloading needed dependencies, I use Opensuse and really have no need to go searching for obscure rpm's.

Why the hell would anyone let people download a program that wont work? Shouldnt they ALWAYS include the needed dependancies??

Im new to linux environments, never installed anything in emm yet.
 
Why the hell would anyone let people download a program that wont work? Shouldnt they ALWAYS include the needed dependancies??

No, but they should tell you where to get the dependencies. Otherwise you end up back in DLL hell where everyone includes their own version of whatever library and you have 6 of them installed for no good reason.

Im new to linux environments, never installed anything in emm yet.

Dependencies are pretty much irrelevant to the user these days, if you stick to the core repositories all of your dependencies will be automatically fulfilled. If you step out of those boundaries you're on your own though.
 
Originally posted by: Brentx
You can use Alien. I don't know how many times alien has come in handy for converting deb to rpm and vice versa.
Cooool,.... I don't use my Debian partition enough.
Didn't even know such a beast existed.
Thanks.

Originally posted by: SleepWalkerX
Suse just didn't have mp3 support for 9.3 (although they did have real player which did have mp3 support). All you had to do was an online update (I'm sure you know how easy YOU is) that would install multimedia codecs, no recompiling necessary. They have mp3 support with their Suse 10.0 Eval..... So stfu.
That wasn't true when I installed Suse 9.3.
One had to visit some site in Germany.
The hard bit was even finding out that the German site existed.
And,... stfu?

Originally posted by: Nothinman
But the problem is that FC has virtually no packages available in their base repository and the 3rd party repositories are crap. [/b]With Debian sid/Ubunutu you get nearly 18,000 packages available via apt. That and yum is crap, it's slow as hell and really annoying to work with.
That's just Redhat crippling Linux,..... until you pay.
 
That's just Redhat crippling Linux,..... until you pay.

A) you attributed the quote to the wrong person.
B) No, it's not. Even if you pay for RHEL you don't get a larger package list, you just get support.
 
Here's a story I feel is relevant to the topic at hand.

Last night I installed mplayer on Debian. Well, I promptly found a Debian repository for it, and put it in my sources.list file and did apt-get update. But it wasn't as easy as "apt-get install mplayer". It told me I had to pick either mplayer-386,mplayer-586,mplayer-skins,and something else. So I tried -586, which said it required skins. Well OK, I tried skins, and then it said skins-blue I required mplayer. Now I'm stuck. (386 didn't work either.) I found a tutorial on how to install it on Debian Sarge, so I went through it. It asked me to install ffmpeg, which was indeed as easy as apt-get install, and no packages were broken, so I was happy. It also wanted me to install libavifile, which I couldn't find using apt-cache search, nor did it work with apt-get install. So, I was lucky to Google up a Japanese repository that had libavifile0.7c102 (something like that) and 0.7-dev. After an apt-get update those also installed fine. Interestingly enough, the tutorial directed me to compile the source code and not use the repositories to install mplayer. So I did that, and finally after configure,make, and make install, all was well. I installed a front-end very easily by doing apt-get install kplayer. Debian has forced me out of my "rpm --nodeps --force" habits and a simple "apt-get install" reveals no package dependency problems, so that's good.
 
But it wasn't as easy as "apt-get install mplayer". It told me I had to pick either mplayer-386,mplayer-586,mplayer-skins,and something else. So I tried -586, which said it required skins. Well OK, I tried skins, and then it said skins-blue I required mplayer. Now I'm stuck.

The -586 and -386 packages have been removed and replaced with just 'mplayer'. And mplayer-skin-blue provides mplayer-skin so telling it to install mplayer should pull in the skin and 'just work', it always has for me.

It also wanted me to install libavifile, which I couldn't find using apt-cache search, nor did it work with apt-get install.

libavifile-0.7c2 is in the official repository and should have showed up with 'apt-cache search libavifile', it did here.
 
Back
Top