VMware just created its first Linux OS and it's rubbish

I don't know, poor documentation? the toolchain check works for me on Fedora 20. I think it was a silly reason to stop reading the article so early at the mention of "yum"

RPM is really a great packaging system. It has a lot of features that DEB's do not, for example you can roll back yum/RPM transaction's if you like (yum history undo ${id}). Another example is to get a list of the last packages that were installed "rpm -qa --last". DEB's seem to prefer to write things to files instead, so they'll write to /var/lib/dpkg/info/*

One place where I think that DEB's win, is in building a new package. It was pretty easy for me to make a DEB than an RPM, and the fact that I had a hard time finding which RPM macros did function XXYY.

I think the reason why many don't like fedora/centos is the fact that packages aren't easily accessible, because Ubuntu will enable the universe repo by default whereas fedora/centos you would have to install that on your own.

If I can help you, feel free to reach out to me.

So you've never had to edit a broken maintainer script under /var/lib/dpkg/info/* from bad post/pre install / removal bits? I've used both extensively on somewhere around 30k machines over my career and have to say I see rpm make a mess impossible to fix with just rpm 0 times. I most definitely can not say the same for Debian / Ubuntu systems. I think yum wins in that it has real plugins, not quasi plugins. There is a sort of debdelta-upgrade command, where as yum deltarpm is part of yum natively (you don't have to know about it to use it). The same can be said for the fastest mirror plugin, where yum will ping several mirrors and choose the fastest one for you. I can go on and on, but the moral of the story is that in 2015, from a technical standpoint, yum simply beats apt-get.

Bonus points that you have things like rpm -V and rpm -qf (which dpkg -S don't really replicate much at all).

Sure, ad populum is a fallacy when you are arguing a point, but when you are trying to decide on a toolchain to use, why wouldn't you go with the one that most of your customers use? You might like another toolchain better (and I happen to agree with you about rpm), but that doesn't necessarily mean it is objectively better.

> I don't like RPM or Yum. In my experience with using it, it has usually done more harm than good.

How is:

yum install <package> -y

And worse than:

apt-get update && apt-get install <package>

A lot of people like to say RPM's are horrible, and maybe they are right... but if you use the package manager, what does it matter to you how the packages were made? It just works...

I can't think of a single example where something blew up simply because it was an RPM.

As a side-note -- the other comments are right, RPM is use an awful lot more in business because most businesses are running some flavor of RHEL/CentOS. If it were really that bad, then it would have been changed by now.

"Argumentum ad populum is a fallacy."

Yes, but when choosing tech it can be a good dimension of analysis if paired with other variables. Popular tools that are maintained if not bug-free can have a better understood bug-portfolio than a more elegant-but-still less used ones.

Choosing the devil one knows over the one one don't know and all that.

This stat is skewed by the default instance on things like EC2 being Ubuntu or Debian (should note that EC2 is built on RHEL/CentOS). There's an awful lot of people's blogs and one-off websites running on Ubuntu or Debian, sure. Those aren't really "business" use cases.